Thomas Jentzsch Posted November 8, 2023 Share Posted November 8, 2023 31 minutes ago, JetSetIlly said: I think for this kind of problem a trace is invaluable. No so much for writing 2600 games but for tracking down problems in the emulation itself, a trace is definitely useful. Agreed. I have reopened the issue. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 8, 2023 Author Share Posted November 8, 2023 I tried to redirect the console output into a file: ./stella -plr.timemachine 0 -dev.timemachine 0 /path/to/your-ROM-dir/CartridgePort.bin > myLogFile.log But Stella (or the cartridge and the PlusCart) are behaving different (black screen). Also the content of the files don't look like what I see on the terminal without a redirect. 🤷♂️ Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 8, 2023 Author Share Posted November 8, 2023 On 11/6/2023 at 9:03 PM, Kroko said: Not sure if it is relevant, but lets talk about step #3, especially the "(predecrement S?)" I thought this means that the stack pointer is decremented before it appears on the address bus, but in stella code it seems the original value of SP would appear on the bus ? I don't think the original value of SP ever appears on the bus on the real console. The way I understood above description of the cycles, in step #3 and 4, the wrong addresses would appear on the adress bus of our emulated console... Do you have a Decathlon cartridge? Can you provide a capture (log) from your logic analyzer, so we see what happens on the bus around accesses to $1FE? Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 8, 2023 Share Posted November 8, 2023 (edited) 6 hours ago, Al_Nafuur said: If the previous RTS is not doing the bank switching correct the execution continues at the correct return address in the wrong bank. If the code then hits a new RTS the stack pointer rolls over. Yes, but I cannot see this error in that log. All bank switches look fine until then. Edited November 8, 2023 by Thomas Jentzsch Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 8, 2023 Author Share Posted November 8, 2023 A Interface to peek/poke addresses manually (like discussed here) would be handy now. Alternatively we might build a FE test-ROM to use with the PlusCart. By the way, has anyone tested Decathlon with the Harmony cart on our setup? Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 8, 2023 Share Posted November 8, 2023 40 minutes ago, Al_Nafuur said: A Interface to peek/poke addresses manually (like discussed here) would be handy now. Not sure if I understand this. How exactly should that look like? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 8, 2023 Author Share Posted November 8, 2023 45 minutes ago, Al_Nafuur said: Alternatively we might build a FE test-ROM to use with the PlusCart. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 8, 2023 Share Posted November 8, 2023 (edited) Sorry, I don't get it. Again. This seems to test JSR, not RTS. Also, what do the JSR and RTS in the red blocks mean? And what are the error numbers meant for? Also, shall the code stop at an error? Or how should it continue? Edited November 8, 2023 by Thomas Jentzsch Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 8, 2023 Author Share Posted November 8, 2023 I think i have an Idea of what might happens. Our address bus changes are fast than the real 6502 ones. This might bei an issue if the same address is requested in two consecutive cycles, then it might look like one cycle for the cartridge Link to comment Share on other sites More sharing options...
Kroko Posted November 8, 2023 Share Posted November 8, 2023 6 hours ago, Al_Nafuur said: Do you have a Decathlon cartridge? Can you provide a capture (log) from your logic analyzer, so we see what happens on the bus around accesses to $1FE? Unfortunately I do not have a FE cart. To make it worse, I also don't have a flash cart that can emulate FE ... Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 8, 2023 Author Share Posted November 8, 2023 15 minutes ago, Kroko said: Unfortunately I do not have a FE cart. To make it worse, I also don't have a flash cart that can emulate FE ... PM me your address, I'll send you a PlusCart 1 Link to comment Share on other sites More sharing options...
Kroko Posted November 8, 2023 Share Posted November 8, 2023 (edited) I think these logs would be useful: * real console and real cart * emulated console and real cart * real console and PlusCart * emulated console and PlusCart For the emulated console logs .. I am a bit disconnected from the latest development. Is there some git repo commit that I can use out of the box without extra hardware to try it ? (got confused with all these NOP loops etc 😁) Edited November 8, 2023 by Kroko Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 9, 2023 Share Posted November 9, 2023 14 hours ago, Al_Nafuur said: I think i have an Idea of what might happens. Our address bus changes are fast than the real 6502 ones. This might bei an issue if the same address is requested in two consecutive cycles, then it might look like one cycle for the cartridge So a timing problem after all, as I suspected? Do FE carts work if you increase the delay? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 9, 2023 Author Share Posted November 9, 2023 33 minutes ago, Thomas Jentzsch said: So a timing problem after all, as I suspected? Not exactly. It is not about how long a cycle takes. It is about how long the 6502 needs to setup the address on the bus (30ns) and how long we usually need to setup the address (~5ns) 33 minutes ago, Thomas Jentzsch said: Do FE carts work if you increase the delay? No. I tried different delays (10-80 NOPs, ~20-180ns) in our address setup process, but I couldn't get Decathlon running stable (cartridge and PlusCart). I had a look into the logs again, and it looks that $1FE is not requested twice consecutively, so my idea is not relevant. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 9, 2023 Author Share Posted November 9, 2023 13 hours ago, Kroko said: For the emulated console logs .. I am a bit disconnected from the latest development. Is there some git repo commit that I can use out of the box without extra hardware to try it ? (got confused with all these NOP loops etc 😁) I switched to a new branch "feature/cartridgeportThread" for the threaded timer/counter. So you will have to switch to this branch. I'll update/check the setup instructions today: 1 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 9, 2023 Share Posted November 9, 2023 4 hours ago, Al_Nafuur said: Not exactly. It is not about how long a cycle takes. It is about how long the 6502 needs to setup the address on the bus (30ns) and how long we usually need to setup the address (~5ns) No. I tried different delays (10-80 NOPs, ~20-180ns) in our address setup process, but I couldn't get Decathlon running stable (cartridge and PlusCart). I had a look into the logs again, and it looks that $1FE is not requested twice consecutively, so my idea is not relevant. Are you still interested into a test program? If yes, please describe in a bit more detail what you need. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 9, 2023 Author Share Posted November 9, 2023 1 hour ago, Thomas Jentzsch said: Are you still interested into a test program? If yes, please describe in a bit more detail what you need. A test program would be good to test if it always fails on RTS or JSR (or both). 22 hours ago, Al_Nafuur said: 22 hours ago, Thomas Jentzsch said: Sorry, I don't get it. Again. This seems to test JSR, not RTS. Also, what do the JSR and RTS in the red blocks mean? And what are the error numbers meant for? Also, shall the code stop at an error? Or how should it continue? Basically we need three display kernels one when the bank switching runs correct and one in every bank if a RTS or JSR fails. In my example the start display kernel (just a green background?) runs at the beginning of the first bank. The main loop performs a JSR to "Sub1" at the middle of the second bank. "Sub1" performs a JSR to "Sub3" on the same bank. After returning to the main loop the loop does a test JSR to Sub2 on the first bank. The red areas are the areas where the PC jumps when a RTS or a JSR fails. Here the error number can be set and then a jump to the error display kernel of this bank (red background + error Nr.), maybe the error display kernel can restart the main loop if the joystick button is pressed (could be difficult for the error display in the second bank) Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 9, 2023 Share Posted November 9, 2023 Tricky. I can easily write code that executes if everything works as expected. But if anything fails, how can I prevent the code to crash? E.g. if an RTS doesn't change the bank, the code will continue in the same bank. So how can I get back to the correct bank? Only with a JSR. Now, if the fixing JSR fails, the code will still be in the wrong bank. And then I am screwed. I think we need two test programs. One that assumes that JSR is OK and tests RTS only. And one for vice versa tests. Would that be OK for you too? 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 9, 2023 Author Share Posted November 9, 2023 (edited) 1 hour ago, Thomas Jentzsch said: Tricky. I can easily write code that executes if everything works as expected. But if anything fails, how can I prevent the code to crash? E.g. if an RTS doesn't change the bank, the code will continue in the same bank. So how can I get back to the correct bank? Only with a JSR. Now, if the fixing JSR fails, the code will still be in the wrong bank. And then I am screwed. I think we need two test programs. One that assumes that JSR is OK and tests RTS only. And one for vice versa tests. Would that be OK for you too? The code in the two banks has to be aligned (with ORG and NOPs ?) like this: Bank0 Bank1 ORG $F000 ORG $D000 MainLoop ; Display OK Kernel ; e.g. green background JSR Sub1 CallTestSub1 ORG CallTestSub1 - $1000 NOP LDA #RTS_Sub1_error ; More NOPs to pad JMP DisplayErrorBank1 JSR Sub2 CallTestSub2 ORG CallTestSub2 - $1000 JMP MainLoop LDA #RTS_Sub2_error JMP DisplayErrorBank1 ORG TestSub3 + 1000 TestSub3 LDA #JSR_Sub3_error NOP JMP DisplayErrorBank0 NOP ; More NOPs to pad RTS ORG TestSub1 + 1000 TestSub1 LDA #JSR_Sub1_error NOP JMP DisplayErrorBank0 NOP ; More NOPs to pad JSR TestSub3 ORG CallTestSub3 + 1000 CallTestSub3 LDA #RTS_Sub3_error JMP DisplayErrorBank0 RTS . . . To show the alignment, I have written the code here side by side. To compile it, it must of course be placed one behind the other. Edited November 9, 2023 by Al_Nafuur Fix code (v1) Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 9, 2023 Share Posted November 9, 2023 16 minutes ago, Al_Nafuur said: The code in the two banks has to be aligned (with ORG and NOPs ?) like this: Bank0 Bank1 ORG $F000 ORG $D000 MainLoop ; Display OK Kernel ; e.g. green background JSR Sub1 CallTestSub1 ORG CallTestSub1 - $1000 NOP LDA #RTS_Sub1_error ; More NOPs to pad JMP DisplayErrorBank1 JSR Sub2 CallTestSub2 ORG CallTestSub2 - $1000 JMP MainLoop LDA #RTS_Sub2_error JMP DisplayErrorBank1 ORG TestSub3 + 1000 TestSub3 LDA #JSR_Sub3_error NOP JMP DisplayErrorBank0 NOP ; More NOPs to pad RTS ORG TestSub1 + 1000 TestSub1 LDA #JSR_Sub1_error NOP JMP DisplayErrorBank0 NOP ; More NOPs to pad JSR TestSub3 ORG CallTestSub3 + 1000 CallTestSub3 LDA #RTS_Sub3_error JMP DisplayErrorBank0 RTS . . . To show the alignment, I have written the code here side by side. To compile it, it must of course be placed one behind the other. Ah, so you want the code to stop in case of an error? That's much easier. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 9, 2023 Author Share Posted November 9, 2023 6 minutes ago, Thomas Jentzsch said: Ah, so you want the code to stop in case of an error? That's much easier. No JMP DisplayErrorBank0/1 A kernel at then end of every bank to show the RTS/JSR_SUB1/2/3_error numbers. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 9, 2023 Share Posted November 9, 2023 3 minutes ago, Al_Nafuur said: No JMP DisplayErrorBank0/1 A kernel at then end of every bank to show the RTS/JSR_SUB1/2/3_error numbers. Yes, and then stop. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 9, 2023 Author Share Posted November 9, 2023 28 minutes ago, Thomas Jentzsch said: Yes, and then stop. 5 hours ago, Al_Nafuur said: ..., maybe the error display kernel can restart the main loop if the joystick button is pressed (could be difficult for the error display in the second bank) Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 9, 2023 Author Share Posted November 9, 2023 Maybe we can include a counter (16bit ?) in the main loop to count the successful loops. Link to comment Share on other sites More sharing options...
Kroko Posted November 10, 2023 Share Posted November 10, 2023 (edited) Thanks to Al_Nafuur I can provide first logs: These are logs from a real 2600 console running a real Decathlon PAL cartridge. Once in 10Mhz sampling rate and once with 1 MHz. Not yet sure what is the best sampling rate ... any opinions ? So in 10MHz logs the sample number needs to be multiplied by 100ns to get the real time and in 1 MHz its 1us per sample. I am currently triggering on the reset vector $1FFC $1FFD. If there is a different trigger point you would like to see, let me know. Decathlon2600Junior_RealCartridge_1MHz.CSV Decathlon2600Junior_RealCartridge_10MHz.CSV Edited November 10, 2023 by Kroko 1 Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts