Thomas Jentzsch Posted December 7, 2018 Share Posted December 7, 2018 We are currently trying to find out, how real hardware behaves in a certain corner case. That is: Reads from SuperChip extra RAM using a write address cause unwanted writes to SC RAM. The exact values written are what we are looking for. Attached is a F8SC (8K + SuperChip RAM) ROM which returns different results in Stella, Stellerator and (my) console with Harmony. Since we do not know what affects the results (console type, cart used) we need your help. Especially if you are able to put the ROM onto a physical cart and/or have multiple consoles too test. Please post your setup and resulting pictures here. Thanks in advance! testSC_1_f.bin 1 Quote Link to comment Share on other sites More sharing options...
+Muddyfunster Posted December 7, 2018 Share Posted December 7, 2018 (edited) This is my PAL Jr on Harmony This is my PAL Jr on UnoCart I got identical results on my PAL Light 6er Edited December 7, 2018 by Muddyfunster 2 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 7, 2018 Author Share Posted December 7, 2018 Interesting: I got the same (weird) Harmony result. And your UnoCart has the same result as Stellerator. Quote Link to comment Share on other sites More sharing options...
alex_79 Posted December 7, 2018 Share Posted December 7, 2018 (edited) Same results with the Harmony here. I think Stellerator is correct: you're reading from a write-only address, so nothing is driving the bus and you (tipically) get the last value that was on it, that is the address MSB.Probably the harmony slightly drives bit 6 high and that's why it is always set with the test rom. Some eproms might affect the bus as well. Edited December 7, 2018 by alex_79 3 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted December 7, 2018 Share Posted December 7, 2018 (edited) The UnoCard / Stellerator result is what I would have expected as well. I have a suspicion that the harmony takes longer to float the bus and influences the resulting value this way. I think it might depend on the code path in the driver code, otherwise ROMs that read from invalid addresses should break. Edited December 7, 2018 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
+Karl G Posted December 7, 2018 Share Posted December 7, 2018 It looks like my Harmony cart result matches others: tested on a NTSC Jr. 3 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted December 8, 2018 Share Posted December 8, 2018 (edited) I did some tests with real superchip carts and the results are NOT what I would have expected.I hacked the test rom posted by Thomas so that it now runs from the RIOT ram and the test only starts after the console RESET switch is pressed. This allows to remove the cart containing the test rom (the Harmony in my case) and plug in the actual cartridge to test while the console is powered (WARNING! HOT SWAPPING CARTS CAN POTENTIALLY DAMAGE THE CONSOLE OR THE CARTS THEMSELVES. DO IT AT YOUR OWN RISK!)I tested 9 different superchip carts and in all cases the value read from the write port doesn't seem to be affected by the last value on the data bus.These are the results for two different "Dig Dug" cartridges. The pattern is almost stationary, with the exception of a few pixels flickering. I let it run a few minutes and didn't notice any change in behaviour.Super Football:$FF everywhere, stationarySecret Quest:$FF almost everywhere, initially stationary, then the black pixels start to flicker and finally it becomes all $FF (after 2-3 minutes)Dark Chambers:All $FFDesert Falcon, Crystal Castles, Stargate, Millipede:All $00 (black screen) Here is the hacked testrom: It will display a series of coloured horizontal lines. You can then unplug the cart with the testrom, and plug the one that needs to be tested. If the horizontal lines are still there, the console didn't crash and you can press RESET to start the actual test. (It seems that plugging in the cart sligthly slanted, so that the right part of the edge connector, where the ground pis are, makes contact first, helps reducing the chance of crashing. As I said, if you want to try this, you do it at your own risk!)testSC_RIOT.binFinally, here are a few dumps of the Stargate cart:reading from 1000-10ff: eveything gets zeroed like with the test rom. The result is always the same after each power-cycle. 1000-10ff 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Same as before, but using mirrors 5000-50ff. The result doesn't change, the last value on the bus doesn't cause a different behaviour. The result is the same after each power-cycle. 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 only dumping the read port (1080-10ff) results in random values. These are different each time the console is power-cycled. 1080-10ff 0000: 86 D0 F0 E6 87 A5 87 C9 F8 D0 E8 A9 F0 85 87 A5 0010: 82 C9 03 10 04 E6 82 D0 DA A2 F9 D0 02 86 9B BD 0020: E7 1F AD 00 F0 85 80 20 E8 00 E6 8B D0 EB E6 8C 0030: A5 8C C9 F8 D0 E3 A9 F0 85 8C A5 82 10 04 E6 82 0040: D0 D7 AD 20 02 AD 00 F0 85 80 20 E8 00 E6 85 D0 0050: F1 E6 86 D0 ED A9 F0 85 86 A5 82 C9 40 10 06 A9 0060: 40 85 82 D0 DD C9 FF AD FF FF AD FF FF 85 80 20 0070: E8 00 A5 87 C9 FF D0 06 A5 88 C9 FF F0 09 E6 87 finally I dumped skipping the first half of the write port, from 1040 to 10ff. The last 64 bytes of ram gets always zeroed, the first half is random and changing at each power-cycle 1040-10ff 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040: 26 FD D0 E3 30 8D FA DD 91 A3 CC 75 D9 6A 71 EA 0050: 1F 7C 93 C9 CA 0F 1C C2 1D A8 4B 71 10 1F 84 ED 0060: 7A E0 F3 51 11 61 9A 4A F1 92 F0 D1 72 80 D9 5C 0070: 63 2F 39 AD 3B 75 0E 6A 7B AF 0A 66 94 6F 17 7F 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 All tests and dumps are made using a non modified PAL 2600jr. All carts are PAL. EDIT: Updated the testrom. The one I originally attached wasn't the latest version. Edited December 8, 2018 by alex_79 4 Quote Link to comment Share on other sites More sharing options...
+stephena Posted December 8, 2018 Share Posted December 8, 2018 Hmm, nice testing! The very last picture is what Stella is doing right now. Unfortunately, there is so much variation in behaviour here that we can't (or at least I can't) see any reproducible pattern. And without a pattern, we can't create code to emulate it. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 8, 2018 Author Share Posted December 8, 2018 Thanks for testing. To me it looks like a static, random pattern is the best way to go. That should help developers best. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted December 8, 2018 Share Posted December 8, 2018 (edited) Those are very interesting test results, and very different from what I expected. Thanks for the test, Alex! Edited December 8, 2018 by DirtyHairy Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 9, 2018 Author Share Posted December 9, 2018 @Alex: Can you repeat some of your tests using the code of the attached ROM? This tests how the RAM reacts to address wraparounds. testSC_1_F_inv.bin Quote Link to comment Share on other sites More sharing options...
alex_79 Posted December 9, 2018 Share Posted December 9, 2018 I got slightly different results than before for the two "Dig Dug" carts, but I also tried the old test rom again and got these new patterns as well! I think it's just due to e.g. different temperature of the console and/or carts, while the address wraparound apparently makes no difference. The other carts behave the same as they did before.testSC_1_F_inv_RIOT.bin 3 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 9, 2018 Author Share Posted December 9, 2018 Thanks, that confirms my expectation. Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted December 10, 2018 Share Posted December 10, 2018 Excellent testing and results. I think if it's not consistently randomized then don't randomize it. Initialization seems to be the direction to go in to gain compatibility with the widest variety of real hardware just as was eventually done with the decimal flag on the CPU. One thing these results suggest to me is that reading just half the block may be a bad test influencing the results since they are different and the entire block is initialized otherwise. When I got SC RAM working on the Flashback Portable I couldn't dump it just had to theorize. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.