Jump to content
IGNORED

Stella getting into details - Help wanted!


Recommended Posts

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

  • Like 1
Link to comment
Share on other sites

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 by alex_79
  • Like 3
Link to comment
Share on other sites

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 by DirtyHairy
Link to comment
Share on other sites

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.
post-10599-0-74857800-1544277764.jpgpost-10599-0-57040100-1544277789.jpg

Super Football:
$FF everywhere, stationary
post-10599-0-38337400-1544277808.jpg

Secret Quest:
$FF almost everywhere, initially stationary, then the black pixels start to flicker and finally it becomes all $FF (after 2-3 minutes)
post-10599-0-66717700-1544277822.jpg

Dark Chambers:
All $FF

Desert Falcon, Crystal Castles, Stargate, Millipede:

All $00 (black screen)
post-10599-0-66589000-1544277848.jpg

 

 

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!)
post-10599-0-52376500-1544277876_thumb.pngpost-10599-0-50023300-1544277890_thumb.png
testSC_RIOT.bin

Finally, 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 by alex_79
  • Like 4
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

post-10599-0-44077300-1544389638.jpgpost-10599-0-79216600-1544389644.jpg

 

The other carts behave the same as they did before.

testSC_1_F_inv_RIOT.bin

  • Like 3
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...