SDRAM refresh GSU

[paulb-nl]

I may have found something regarding the issue with unstable CX4/GSU. I was searching for behavior that is different from normal cartridge games.

The ROM read signal is faster when the GSU has ROM access. This triggers more refresh for the SDRAM.

When the GSU has ROM access and there is a WRAM read/write after the refresh is triggered then the bank activate command after a refresh command happens too quickly.

Here is a trace with a WRAM write and then a WRAM read right after. The time from refresh to activate command is only 4 cycles in these cases. In the Alliance AS4C32M16SB datasheet it says that the refresh cycle time should be at least 60ns which is 6 cycles.

What I also noticed and what you can see in the trace is that sometimes there is only 1 NOP between a write and refresh command. There should at least be tWR+tRP = 30ns (3cycles) NOPs between write and refresh. But this also happens on normal cartridge games so I don't think this is causing issues which I find strange.

[srg320]

Thank you. I'll check it out.

[paulb-nl]

The following is probably not an issue but could be with some slow -7 chips. My SDRAM has -7 chips but don't have any issues.

Sometimes when the GSU has ROM access the phase between ROM read and WRAM is different. In the above trace WRAM reads and writes happens when rd0 is low.

In the below trace the ROM read signal has shifted and rd0and rd1 are high at the same time. This causes 2 bank activate command cycles in a row. tRRD for Row bank to Row bank activate delay should be 12ns for -6 chips and 14ns for -7 chips. With the 85Mhz clock 1cycle delay is 11.6ns so -6 chips are ok but slow -7 chips might have issues.

BTW I am using the game Yoshis Island for these traces.

[paulb-nl]

Commit b8c3d4a fixes the refresh after a write but that also happened with normal cartridges so I don't think that was a big issue.

The big issue still left is the short refresh before WRAM reads/writes. I have added text in the trace below to make it more clearly.

[Zet-sensei]

I discovered that the commit breaks the SA-1 patched version of Mega Man X (Mega Man X (USA) [SA1 hack by Bosn v1.2]) if we let the intro run competely and then return to the main screen.

The core freezes completely without entering the game's demo mode.

EDIT : We could also see that the registered trademark logo on the right side of the screen being scrambled.

The previous stable versions from 2025-06-05 & before aren't affected.

[paulb-nl]

Yes I confirm. I also have crashing and weird behavior in Super Mario RPG and Super Mario World SA-1.

I have no problems with CX4 and Super FX.

I am guessing that after commit b8c3d4a with SA-1 the read_prev signal is almost always high and is preventing proper refreshing.

[paulb-nl]

@srg320 Do you think it is possible to only refresh the SDRAM when the SNES CPU is in refreshing mode? At least in that time the WRAM is idle and then WRAM interrupting refresh can be avoided that way.

[srg320]

@srg320 Do you think it is possible to only refresh the SDRAM when the SNES CPU is in refreshing mode? At least in that time the WRAM is idle and then WRAM interrupting refresh can be avoided that way.

That's a good idea. I'll think about it.

[paulb-nl]

@srg320 Thank you for working on this.

After commit e4aa69c I have tested to see how many refreshes there are per 64ms. Most games are around 9000 so that's good.

SA-1 is sometimes very low. Super Mario RPG is usually only around 4000 refreshes. It is because SA-1 is reading at 10Mhz and there is not much time to refresh. Usually executing a loop where it needs to read a new word almost every cycle. Maybe it is a good time to change SA-1 to read at 5Mhz .

[srg320]

SA-1 is sometimes very low. Super Mario RPG is usually only around 4000 refreshes. It is because SA-1 is reading at 10Mhz and there is not much time to refresh. Usually executing a loop where it needs to read a new word almost every cycle. Maybe it is a good time to change SA-1 to read at 5Mhz .

That does not solve the problem. The controller reads the word (bytes 0 and 1) at once when byte 0 is required. The next request to read byte 1 is replaced by a refresh, since byte 1 is already in the cache. However, a jump command can request byte 0 of the next word after byte 0 of the previous word (or the same with byte 1). This is exactly what happens in Super Mario RPG.
I see a solution to the problem as a cache of 4 (or 8) bytes instead of 2.

[TheJesusFish]

I just wanted to chime in and say that CX4 is still crashing for me on the latest unstable. This happens across 4 misters (3 De10s and 1 QMTech). My 4 Mister Pi's have no issues.

Building another seed to see if that still helps. Let me know if there is anything I can do to help test.

[paulb-nl]

That does not solve the problem. The controller reads the word (bytes 0 and 1) at once when byte 0 is required. The next request to read byte 1 is replaced by a refresh, since byte 1 is already in the cache. However, a jump command can request byte 0 of the next word after byte 0 of the previous word (or the same with byte 1). This is exactly what happens in Super Mario RPG. I see a solution to the problem as a cache of 4 (or 8) bytes instead of 2.

5Mhz read does solve the problem because then there will always be a second idle cycle for SDRAM because the read clock to the SDRAM is 10Mhz with SA1 so the address will only change after 2 cycles.

And as you know, SA1 is not supposed to be able to read ROM bytes at 10Mhz.

[srg320]

5Mhz read does solve the problem because then there will always be a second idle cycle for SDRAM because the read clock to the SDRAM is 10Mhz with SA1 so the address will only change after 2 cycles.

So you mean that the jump/branch command to an unaligned address will also be read at 5MHz and this will give an additional cycle?

[paulb-nl]

Well yes, it is also described here at "Note 2" https://github.com/VitorVilela7/SnesSpeedTest

This is just my understanding. Not verified:

SA-1 needs 1 wait cycle when the byte needed by SA-1 CPU is not in the ROM read cache.

This can be:

1. jump to byte 0 of unaligned word address
2. jump to byte 1 of unaligned word address, another extra wait cycle needed for the following word
3. SNES CPU is also accessing ROM.

[paulb-nl]

@TheJesusFish Have you ever tested your SDRAM with Jotego's tests? https://github.com/jotego/jtbin/tree/master/deprecated

It is really crazy that you have this issue on 4! Misters.

[birdybro]

@TheJesusFish Are all 4 of your MiSTer Pi's the kind with the SDRAM soldered on or do you have a mix of soldered-on and addon board style among the MiSTer Pi's? Is your QMTech using the soldered on SDRAM or an addon board? Just curious about trace lengths as a contributing factor here.