Kroko Posted November 10, 2023 Share Posted November 10, 2023 This one is 100Mhz. 10ns per sample. It only reports a new sample if something is changing on the bus lines. Decathlon2600Junior_RealCartridge_100MHz.CSV Link to comment Share on other sites More sharing options...
Kroko Posted November 10, 2023 Share Posted November 10, 2023 (edited) Logs from a real 2600 Junior together with PlusCart Decathlon PAL: Decathlon2600Junior_PlusCart_10MHz.CSV Decathlon2600Junior_PlusCart_100MHz.CSV Edited November 10, 2023 by Kroko Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 10, 2023 Share Posted November 10, 2023 (edited) I have problems to understand what I am seeing. Can you explain what these values mean? Edited November 10, 2023 by Thomas Jentzsch 1 Link to comment Share on other sites More sharing options...
Kroko Posted November 10, 2023 Share Posted November 10, 2023 The first two lines of the CSV file contain a short description of what is to be found in the rest of the file. "SamplePeriod" is the time distance between two measurements. For the case of 100MHz its "0.00000001" which is 10 Nanoseconds. So every sample in the file represents 10ns of time. "TriggerSample" is the Sample that the logic analyzer started its measurement on. For example "158" that would mean sample 158 is the one where the trigger condition was true and the logic analyzer started to record the bus. Then in the following part of the file from Line 3 of the CSV the recorded data is found: Column 1 is the sample number: You can calculate from the "sample period" and the "SampleNumber" at what time the measurement has been made. So if you see 0 that means it is the first measurement at T= 0ns and if you see a different value, like 31 then its the 31st measurement that the logic analyzer made after 31* 10ns = 310 ns. In the end this means that the first column is the time column. It is just not the time but the sample number. If samples are missing, that means that there was no change for the samples in between. For example if you see 87 and next sample is 115 then it means that the content of sample 87-114 were identical and that the bus changed at sample 115. Column 2 is the Address on the VCS Address bus at the time of the sample Column 3 is the Data on the VCS Databus at the time of the sample Lets check the samples around the reset vector: "118","1FFCh","00h" "121","1FFCh","79h" "122","1FFCh","FFh" "126","1FBCh","4Eh" "127","1FFCh","4Eh" "203","1FFDh","4Eh" "207","1FFDh","FFh" "211","1FFDh","CCh" "284","1FCCh","CCh" "285","0F0Ch","CCh" "286","080Ch","CCh" "287","000Ch","CCh" Here you can watch how we needed a few nanoseconds to get the address and databus stable: T=118*10ns = 1,180us we first see 1FFC on the Address Bus during samples 121-122 the Databus tries to stabilize but unfortunately at sample 126 the address bus falls back to address "1FBC" .. one sample later at T=127*10ns = 1.27us we finally see a stable 1FFC on the address bus and "4E" on the databus. the bus is stable till sample 203, where the address lines change to 1FFD. Thats at 2,03 us . So we had stable address and data for 760 ns. it takes until sample 211 before the data stabilzes at "CC" 2,11 us I hope you are now not more confused than before 😁 Link to comment Share on other sites More sharing options...
Kroko Posted November 10, 2023 Share Posted November 10, 2023 One thing that I need to work on is my breadboard setup. The logs are only as reliable as by breadboard setup. While I made sure that the game is running fine on the console while I did the measurement, there are also wires to the logic analyzer and this is a weak point. If I have a sporadically loose connection or something of one of the lines, then the logs may be unreliable. So I will try to solder the connections to avoid such issues ... 1 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 (edited) Here is a simple FE Test ROM (following @Al_Nafuur's suggestion). Green means everything is fine. When the screen turns red and white, an error has happened. The error is displayed using the playfield. If PF1 is shows red, then a JSR error happened, if PF2 is set, a RTS error happened. The set bits indicate for which routine, "....X." means Sub1, "...X.." means Sub2, "...XX." means Sub3. The attached screenshot shows that "JSR Sub3" failed to switch bank (note that the bits are reversed for PF1). Press FIRE to continue testing. I could make it nicer, but I think it does the job. FE_Test_V1.bin Edited November 11, 2023 by Thomas Jentzsch 3 Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 To test this on the PlusCart, can i just upload it or do i need to tell the cart that this is FE ? When I just upload it, it looks like this on my TV: Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 8 minutes ago, Kroko said: To test this on the PlusCart, can i just upload it or do i need to tell the cart that this is FE ? I added one string from Decathlon used by Stella to detect FE. Maybe the PlusCart uses the same too. 8 minutes ago, Kroko said: When I just upload it, it looks like this on my TV: My code doesn't do any VBLANK, only VSYNC. Could that cause the trouble? Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 (edited) 3 minutes ago, Thomas Jentzsch said: My code doesn't do any VBLANK, only VSYNC. Could that cause the trouble? What you see in my image is what happens on TV when I upload the ROM to a plus cart and run it on a real 2600 Junior. In case FE is detected corretly, my PAL TV does not seem to be happy with it. "Why" ... you are the expert here I would say 🤣 Edited November 11, 2023 by Kroko Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 after a few seconds: Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 (edited) 3 minutes ago, Al_Nafuur said: after a few seconds: RTS of Sub 1 If wonder why it takes a few seconds. And is it always the same bug? Edited November 11, 2023 by Thomas Jentzsch Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 Meanwhile I made a new log of a real Decathlon Cartridge running on a Atari 2600 Junior. I noticed that Decathlon does not seem to have a valid reset vector in both banks, so I changed the trigger to $1000 which is, where the good reset vector should point to. Even if the Cartridge starts up in the wrong bank, it somehow recovers from that. I am not so much interested in this part, so here are the first 295 microseconds after the "real" start at $1000. Next step is to search for JSR and RTS and analyze how exactly the bus looks like on the real thing. Then compare it to what the emulated one does ... DecathlonPALCartridge_2600Junior_100MHz.CSV 1 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 Attached a version with correct screen display. Everything should be stable PAL-50 now. FE_Test_V2.bin 1 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: I noticed that Decathlon does not seem to have a valid reset vector in both banks, so I changed the trigger to $1000 which is, where the good reset vector should point to. Even if the Cartridge starts up in the wrong bank, it somehow recovers from that. I wondered about that too: It seems like pure luck. The code in the 2nd bank has no vector pointing to ROM. In my tests it always lands in RAM and there randomly modifies the stack. Eventually it hits $fe and (for whatever reason ) jumps to $f000 in the 1st bank. Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 18 minutes ago, Thomas Jentzsch said: Attached a version with correct screen display. Everything should be stable PAL-50 now. FE_Test_V2.bin 6.98 kB · 0 downloads This one crashes on the PlusCart ... it just returns to the title screen. Link to comment Share on other sites More sharing options...
Kroko Posted November 11, 2023 Share Posted November 11, 2023 13 minutes ago, Thomas Jentzsch said: I wondered about that too: It seems like pure luck. The code in the 2nd bank has no vector pointing to ROM. In my tests it always lands in RAM and there randomly modifies the stack. Eventually it hits $fe and (for whatever reason ) jumps to $f000 in the 1st bank. Yea, a miracle ...but thats not interesting to us I guess. So lets concentrate on the part after $1000 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 42 minutes ago, Thomas Jentzsch said: If wonder why it takes a few seconds. Maybe only one second. But it looks like that a few bank switchings (including RTS?) worked. That's why I wanted a counter. We don't need to show the counter (and the error Nr.) at the error screen, if we store them in RAM we can see them in the debugger if the ROM continues to run. The problem for me is that if the ROM in RTstella "crashes" then Stella crashes too and I can't use the debugger anymore (I have to use "kill -9" to end Stella manually then). @Thomas Jentzsch can you post the asm source code too? Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 second test (V1 ROM) on the PlusCart different error: Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 38 minutes ago, Al_Nafuur said: second test (V1 ROM) on the PlusCart different error: Again RTS, as expected. Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 46 minutes ago, Al_Nafuur said: Maybe only one second. But it looks like that a few bank switchings (including RTS?) worked. That's why I wanted a counter. We don't need to show the counter (and the error Nr.) at the error screen, if we store them in RAM we can see them in the debugger if the ROM continues to run. The problem for me is that if the ROM in RTstella "crashes" then Stella crashes too and I can't use the debugger anymore (I have to use "kill -9" to end Stella manually then). The V1 ROM should not crash. 46 minutes ago, Al_Nafuur said: @Thomas Jentzsch can you post the asm source code too? Sure. V2 seems to have a bug. So I post both versions.FE_Test_01.asmFE_Test_02.asm 1 Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 Here is V3. I did not find the bug in V3, maybe someone can provide some info what exactly happens? Anyway, V3 stores the first 120 bugs in RAM. The first nibble describes the opcode (1= JSR, 2 = RTS), the second nibble the subroutine (1..3). @Al_Nafuuris that what you are looking for? FE_Test_V3.bin 1 Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 17 minutes ago, Thomas Jentzsch said: Here is V3. I did not find the bug in V3, maybe someone can provide some info what exactly happens? Anyway, V3 stores the first 120 bugs in RAM. The first nibble describes the opcode (1= JSR, 2 = RTS), the second nibble the subroutine (1..3). @Al_Nafuuris that what you are looking for? FE_Test_V3.bin 8 kB · 2 downloads Yes, except for the counter that counts the good loops/successfull bank switchings. After about 2mins there were ~40 error entries in RAM, but then the ROM crashed: Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 11, 2023 Share Posted November 11, 2023 Can you post the RAM before the crash? I suppose the ROM crashes, because there is another error happening (e.g. a broken return address). This is nothing I can catch. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 4 minutes ago, Thomas Jentzsch said: Can you post the RAM before the crash? No screenshot. I am about to make a new one, but the crash is always faster than me.. 5 minutes ago, Thomas Jentzsch said: This is nothing I can catch. 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. Link to comment Share on other sites More sharing options...
+Al_Nafuur Posted November 11, 2023 Author Share Posted November 11, 2023 14 minutes ago, Thomas Jentzsch said: Can you post the RAM before the crash? Only 13 errors: 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