Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 (edited) 8 minutes ago, Al_Nafuur said: No screenshot. I am about to make a new one, but the crash is always faster than me.. ~8000 Frames, that's ~160 seconds, no? BTW: Can you post only Stella screenshots and not the whole screen. Makes it easier to read. 8 minutes ago, Al_Nafuur said: Since JSR seems to switch banks more reliable you could use a JSR MainLoop and "clear" the stack pointer at the beginning of the main loop. How would that help? If the game suddenly returns e.g. non ROM or to some random ROM address and bank, then I cannot control that. Edited November 11, 2023 by Thomas Jentzsch Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 Very weird. It crashes every ~1000 frames, but almost always at the 1st JSR then. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 16 minutes ago, Al_Nafuur said: 62x 11 JSR Sub1 (banking should have happened) 23x 21 RTS Sub1 (banking should have happened) 11x 22 RTS Sub2 (banking shouldn't have happened ?) 10 minutes ago, Thomas Jentzsch said: Very weird. It crashes every ~1000 frames, but almost always at the 1st JSR then. The time interval between crashes is very irregular. Sometimes there are multiple error screen flashes in a second, and sometimes it takes up to 20 seconds for the next flash. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 OK, 2/3 are JSR Sub1. But no JSR Sub2 or 3. And no RTS Sub3. Weird. It seems that the execution switches between OK and error states for longer periods. Which would explain why Sub1 is mostly affected and the repeated flickers. But what happens when the execution becomes wrong? Why does the code pass JSR Sub1, JSR Sub3, RTS (Sub3) and then fails RTS (Sub1)? Following my theory, it should be very rare that the state switch happens in between. Just to be sure: Can you repeat that and provide more data? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 V3 runs fine on the PlusCart and this is what happens on the real VCS200 Junior's bus. It displays a stable green rectangle ... PlusCart_FE_Test_V3_2600Junior_100MHz.CSV Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 3 minutes ago, Kroko said: V3 runs fine on the PlusCart and this is what happens on the real VCS200 Junior's bus. It displays a stable green rectangle ... PlusCart_FE_Test_V3_2600Junior_100MHz.CSV 25.35 kB · 0 downloads Anything else would have been quite embarrassing. 😀 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 1 hour ago, Kroko said: V3 runs fine on the PlusCart and this is what happens on the real VCS200 Junior's bus. It displays a stable green rectangle ... PlusCart_FE_Test_V3_2600Junior_100MHz.CSV 25.35 kB · 1 download It would be nice to have one triggered around $01FE (or better $01F0 to $01FF) Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 V3, Triggered during run in case address is between $01F0 and $01FF: PlusCart_FE_Test_V3_2600Junior_100MHz_1F0-1FF.CSV Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 (edited) So this should clarify the bus timing for a "JSR $D100" at address $F0B0: Timing of Address $F0B0 JSR $D100 ($20 $00 $D1) Cycle Address Delay Data 1 $10B0(PC) ~300ns $20 (JSR Opcode) 2 $10B1(PC+1) ~300ns $00 (Lo-Byte Target Address) 3 $01FF(SP) ~600ns $F0 (Hi-Byte Return Address) 4 $01FF(SP) ~ 0ns $F0 (Hi-Byte Return Address) 5 $01FE(SP-1) ~500ns $B2 (LoByte-1 Return Address) 6 $10B2(PC+2) ~400ns $D1 (Hi-Byte Target Address) The question is, does the emulated console do the same or similar ? Since the Cartridge is only interested in the "$D1" it needs to detect two stack hits and then on the next cycle after 2 stack hits it needs to wait for at least 400ns before it can fetch the "$D1" from the databus. I would say it is enough for Stella to put the two stack hits on the address bus, change the address on the cycle after the stack accesses and apply the hi-byte of the target address to the databus during this cycle. Maybe some of the emulator experts can check if we expect this to happen in Stella ? Edited November 11, 2023 by Kroko 1 Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 Timing of a RTS: This RTS returns to $F0BF or maybe $F0C0 Address $1300 RTS (To $F0BF) Cycle Address Delay Data 1 $1300(PC) ~300ns $60 (RTS Opcode) 2 $1301(PC+1) ~300ns $AA (Dummy Read) 3 $01FD ~600ns $D1 (Dummy Read from Stack) 4 $01FE ~600ns $BF (Return Address Lo Byte) 5 $01FF ~600ns $F0 (Return Address Hi Byte) 6 $10BF(PC after RTS) ~300ns $F3 (Opcode at return address) Since here the cartridge is only interested in the $F0, it would do the same as in case of the JSR... wait for two (different) stack hits in a row, then on the next cycle read the Hi-Byte of the return address. Stella would need to have to correctly emulate the 3 stack addresses and have the Hi-Byte of the return address on the databus latest after 600ns 1 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 12, 2023 Share Posted November 12, 2023 (edited) I had Stella's code for JSR and RTS posted towards the end page 20. @Kroko Can you spot anything wrong? Edited November 12, 2023 by Thomas Jentzsch Link to comment Share on other sites More sharing options...
Kroko Posted November 12, 2023 Share Posted November 12, 2023 4 hours ago, Thomas Jentzsch said: I had Stella's code for JSR and RTS posted towards the end page 20. @Kroko Can you spot anything wrong? For me it is best to simply measure what happens on the emulated console, because it is difficult for me to understand how the timing is supposed to be when I look at stella code. I understand a few basic concepts like peek and poke, but not really "when" I would see stuff on the bus ... When I measure it... is see everything that happens no matter why. Also if you make little changes, timing could change as well and you would probably not really be able to spot it looking at stella code (Or I would not). After I fixed my raspberry Pi setup I will try to spot a bankswitch that goes wrong, record it with the LogicAnalyzer and then see what is different to the real console. So we should be able to analyze what is the difference that makes the cartridge fail. 1 Link to comment Share on other sites More sharing options...
+MarcoJ Posted November 12, 2023 Share Posted November 12, 2023 I think it has to do with timing of the access cycles. If I vary the nop counter, Decathlon lasts slightly longer or shorter without crashing. It appears that the results are repeatable, though this is not conclusive. The best I found so far is g=580, and it ran for 8 seconds before it crashed. With g=650, it crashed much quicker, within 3 seconds. 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 12, 2023 Author Share Posted November 12, 2023 1 hour ago, MarcoJ said: I think it has to do with timing of the access cycles. If I vary the nop counter, Decathlon lasts slightly longer or shorter without crashing. It appears that the results are repeatable, though this is not conclusive. The best I found so far is g=580, and it ran for 8 seconds before it crashed. With g=650, it crashed much quicker, within 3 seconds. I also added a 10-80 NOPs delay before the data on the data bus gets deleted, it seems that this too had an impact on how often the errors with the test ROM happened (and which error mostly occurred -> 90% error 11). But I never got the test ROM stable and above 80 it crashed. I tested with g=450, maybe I should try another run with g=560 and an additional delay for the data bus of 20 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 12, 2023 Share Posted November 12, 2023 The current test ROM does only one test sequence (3 JSR/RTS) per frame. I could increase that number if that helps testing. Please let me know. 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 12, 2023 Author Share Posted November 12, 2023 7 hours ago, Thomas Jentzsch said: The current test ROM does only one test sequence (3 JSR/RTS) per frame. I could increase that number if that helps testing. Please let me know. The current test ROM is just fine. The loop counter I always demanded is not really necessary, because Stella has a "Frame" counter. But I wonder if we have a general reading problem from the data bus for the cartridge. The error rate is only ~0.5%, so it might not be recognizable for SC-RAM cartridges. Maybe a SC-RAM r/w test ROM would be interesting to run.. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 12, 2023 Share Posted November 12, 2023 29 minutes ago, Al_Nafuur said: But I wound if we have a general reading problem from the data bus for the cartridge. What would you? 29 minutes ago, Al_Nafuur said: The error rate is only ~0.5%, so it might not be recognizable for SC-RAM cartridges. What do you mean? 29 minutes ago, Al_Nafuur said: Maybe a SC-RAM r/w test ROM would be interesting to run.. Let me know what you need. The more details, the better. 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 12, 2023 Author Share Posted November 12, 2023 8 hours ago, Thomas Jentzsch said: What would you? Sorry, I would not I wounder 🤣 8 hours ago, Thomas Jentzsch said: What do you mean? We have ~40 errors per ~2000 frames and 6 JSR + RTS per frame. So we have 1 bad read from the cart every 300 "writes" from RTStella. I wonder if we have the same error rate for SC-RAM. 8 hours ago, Thomas Jentzsch said: Let me know what you need. The more details, the better. Simple writes to the SC-RAM and checking if all values are OK. Since RTStella doesn't know there is SC-RAM in the cart we will not see it in the debugger. We would have to copy the reads from SC to the RIOT-RAM in our loop too, so we can see something in the debugger. e.g. $90-$9F the values we have written to SC and $a0 - $af the values we have read back. We don't need to check all the SC-RAM I think a block of 16 bytes would be enough per loop. As long as the reads from SC are the same to the previous write value the screen stays green and the loop continues. As soon as a bad read back occurs the screen goes red and the code waits for the fire button to continue. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 14, 2023 Author Share Posted November 14, 2023 I think I found the issue. But not a solution for the RTStella console, only a workaround in the PlusCart firmware for the issue on FE banking: 1 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 14, 2023 Share Posted November 14, 2023 5 minutes ago, Al_Nafuur said: I think I found the issue. Cool. And what did you find? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 14, 2023 Author Share Posted November 14, 2023 2 hours ago, Thomas Jentzsch said: Cool. And what did you find? Delay/interrupt between clearing and setting the address. As I stated earlier this looks like a access to $00 for the cartridge and is for other cartridges not an issue. It looks like these delays (IRQs, clock ticks ?) happen a lot and usually they only make our cycle longer, but if they hit at the right moment it looks like an "extra" cycle for the cart. This most likely explains also why SuperCharger and GameLine are not working. We have to do more to isolate the CPUs that are running the CartPort driver and the counter. 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 14, 2023 Author Share Posted November 14, 2023 https://www.suse.com/c/cpu-isolation-introduction-part-1/ https://www.stephenwagner.com/2020/03/17/how-to-compile-linux-kernel-raspberry-pi-4-raspbian/ http://comfilewiki.co.kr/en/doku.php?id=comfilepi:improving_real-time_performance:index 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