Jump to content

Photo

Stella getting into details - Help wanted!

Stella SuperChip RAM

13 replies to this topic

#1 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • 23,931 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Dec 7, 2018 9:49 AM

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!

Attached Files



#2 Muddyfunster OFFLINE  

Muddyfunster

    Moonsweeper

  • 278 posts

Posted Fri Dec 7, 2018 11:30 AM

This is my PAL Jr on Harmony

 

IMG_1241.JPG

 

 

 

 

 

This is my PAL Jr on UnoCart

 

IMG_1242.JPG

 

 

 

 

I got identical results on my PAL Light 6er


Edited by Muddyfunster, Fri Dec 7, 2018 11:30 AM.


#3 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • Topic Starter
  • 23,931 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Fri Dec 7, 2018 11:43 AM

Interesting: I got the same (weird) Harmony result. And your UnoCart has the same result as Stellerator.



#4 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,195 posts
  • Location:Italy

Posted Fri Dec 7, 2018 11:54 AM

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, Fri Dec 7, 2018 11:57 AM.


#5 DirtyHairy OFFLINE  

DirtyHairy

    Moonsweeper

  • 496 posts
  • Location:Germany

Posted Fri Dec 7, 2018 2:36 PM

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, Fri Dec 7, 2018 2:56 PM.


#6 Karl G OFFLINE  

Karl G

    Dragonstomper

  • 722 posts

Posted Fri Dec 7, 2018 3:14 PM

It looks like my Harmony cart result matches others: tested on a NTSC Jr.

 

20181207_160908.jpg



#7 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,195 posts
  • Location:Italy

Posted Sat Dec 8, 2018 8:19 AM

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.
IMG_0234.JPG IMG_0235.JPG

Super Football:
$FF everywhere, stationary
IMG_0237.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)
IMG_0236.JPG

Dark Chambers:
All $FF

Desert Falcon, Crystal Castles, Stargate, Millipede:

All $00 (black screen)
IMG_0238.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!)
testSC_ram.png testSC_ram_1.png
Attached File  testSC_RIOT.bin   4KB   46 downloads

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, Sat Dec 8, 2018 8:44 AM.


#8 stephena OFFLINE  

stephena

    River Patroller

  • 3,355 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Sat Dec 8, 2018 8:56 AM

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.



#9 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • Topic Starter
  • 23,931 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sat Dec 8, 2018 10:39 AM

Thanks for testing.

 

To me it looks like a static, random pattern is the best way to go. That should help developers best.



#10 DirtyHairy OFFLINE  

DirtyHairy

    Moonsweeper

  • 496 posts
  • Location:Germany

Posted Sat Dec 8, 2018 1:14 PM

Those are very interesting test results, and very different from what I expected. Thanks for the test, Alex!


Edited by DirtyHairy, Sat Dec 8, 2018 1:16 PM.


#11 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • Topic Starter
  • 23,931 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sun Dec 9, 2018 4:22 AM

@Alex: Can you repeat some of your tests using the code of the attached ROM? This tests how the RAM reacts to address wraparounds.

Attached Files



#12 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,195 posts
  • Location:Italy

Posted Sun Dec 9, 2018 3:09 PM

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.

IMG_0239.JPG IMG_0240.JPG

 

The other carts behave the same as they did before.

Attached File  testSC_1_F_inv_RIOT.bin   4KB   41 downloads
 



#13 Thomas Jentzsch OFFLINE  

Thomas Jentzsch

    Thrust, Jammed, SWOOPS!, Boulder Dash, THREE·S, Star Castle

  • Topic Starter
  • 23,931 posts
  • Always left from right here!
  • Location:Düsseldorf, Germany, Europe, Earth

Posted Sun Dec 9, 2018 3:14 PM

Thanks, that confirms my expectation.



#14 Mr SQL OFFLINE  

Mr SQL

    River Patroller

  • 2,068 posts

Posted Sun Dec 9, 2018 11:27 PM

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.

 







Also tagged with one or more of these keywords: Stella, SuperChip, RAM

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users