68K Refresh Delays

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
Mask of Destiny
Very interested
Posts: 558
Joined: Thu Nov 30, 2006 6:30 am

68K Refresh Delays

Post by Mask of Destiny » Sat Jan 30, 2016 9:09 am

So it's been fairly widely reported that code runs a little slower out of work RAM due to refresh delays. I've also mentioned that I've seen what look like refresh delays when accessing the cartridge slot as well. A little while ago I devised a test program that would run out of ROM for a while and then switch to RAM for the same number of instructions before switching back. This was written such that the 68K is always on the bus (not hard for obvious reasons). I did a simple capture logging VCLK (the 68K's clock), !AS, !DTACK, one of the address lines to distinguish where the code was running and the !CE and !OE signals for one of the Work RAM chips. This was sufficient to give me a fairly good picture of RAM refresh behavior and a partial picture of what is presumably refresh behavior for the DRAM based dev cartridge.

Work RAM Refresh
The timing of work RAM refresh is a bit weird. It seems there's a counter with two comparators. The counter seems to be driven by VCLK. When the counter reaches the value of the first comparator, a refresh cycle is triggered the next time the 68K attempts to access work RAM. This will cause a delay of 3 VCLKs on the access the 68K was attempting to perform. If the 68K does not access work RAM before the counter reaches the value checked by the second comparator, then a refresh cycle is performed independent of a 68K request. This second case does not result in any delays for the 68K.

In the second case, refresh cycles are seperated by 133 cycles. In the first case it varies based on how the 68K is aligned with the counter. In my tests I've seen values of 117 and 119 cycles. I suspect the minimum value is 116 cycles (116 cycles + 3 for the refresh delay itself is 119), but that's just a guess.

Cartridge Refresh
I have less data on this as my capture didn't include whatever signals are being used to indicate an actual cartridge refresh. I only see the delays that result. When executing from the cartridge, the delays seem to alternate between being 126 cycles and 130 cycles apart. The delays are only 2 cycles instead of 3 like it is with work RAM. More data is needed to understand the full behavior controlling the timing of this.

User avatar
TmEE co.(TM)
Very interested
Posts: 2286
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: 68K Refresh Delays

Post by TmEE co.(TM) » Sat Jan 30, 2016 12:28 pm

I would have thought RAM refresh had something to do with Hsync or EDCLK, at least for VA1 MD1 (VA0 MD1 is similar) : http://www.tmeeco.eu/SMD/MD1VA1_315-5339.jpg
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Eke
Very interested
Posts: 820
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Re: 68K Refresh Delays

Post by Eke » Sat Jan 30, 2016 2:50 pm

Mask of Destiny wrote:This will cause a delay of 3 VCLKs on the access the 68K was attempting to perform.
From my own tests (see this thread viewtopic.php?t=1411), the delay can vary between 1 and 3 VCLK (additional delay before DTACK is asserted) depending on when /AS was asserted relatively to the start of refresh cycle.
Assuming refresh duration is 4 VCLK, number of additionnal wait-states seems to be:
- 3 if /AS is asserted at the same cycle as RAM /OE is asserted
- 2 if /AS is asserted 1 cycle later
- 1 if /AS is asserted 2 cycles later
- 0 if /AS is asserted 3 (or more) cycles later
Mask of Destiny wrote:I have less data on this as my capture didn't include whatever signals are being used to indicate an actual cartridge refresh. I only see the delays that result. When executing from the cartridge, the delays seem to alternate between being 126 cycles and 130 cycles apart. The delays are only 2 cycles instead of 3 like it is with work RAM. More data is needed to understand the full behavior controlling the timing of this.
According to this thread viewtopic.php?t=1563, these are /CAS2 before /RAS2 refresh cycles. Although /RAS2 is only available on expansion connector, /CAS2 is available on both cartridge and expansion connectors. For some unknown reason, refresh period is shorter during VDP DMA, although I am not really sure if this is really caused by VDP DMA or something more generic when 68k has released his bus since the VDP is not connected to /RAS2 or /CAS2

Mask of Destiny
Very interested
Posts: 558
Joined: Thu Nov 30, 2006 6:30 am

Re: 68K Refresh Delays

Post by Mask of Destiny » Sat Jan 30, 2016 9:41 pm

TmEE co.(TM) wrote:I would have thought RAM refresh had something to do with Hsync or EDCLK, at least for VA1 MD1 (VA0 MD1 is similar) : http://www.tmeeco.eu/SMD/MD1VA1_315-5339.jpg
Yeah, I have no idea why the EDCLK generator is connected to !OE/!RFSH for work RAM. Is there anything else attached to !OE on your VA1 or is that chip the only one. It's also a complete mystery to me why the low byte RAM chip has it's A13 connected to that rather than directly to VA14.
Eke wrote:From my own tests (see this thread viewtopic.php?t=1411), the delay can vary between 1 and 3 VCLK (additional delay before DTACK is asserted) depending on when /AS was asserted relatively to the start of refresh cycle.
Assuming refresh duration is 4 VCLK, number of additionnal wait-states seems to be:
- 3 if /AS is asserted at the same cycle as RAM /OE is asserted
- 2 if /AS is asserted 1 cycle later
- 1 if /AS is asserted 2 cycles later
- 0 if /AS is asserted 3 (or more) cycles later
That makes sense, though presumably that only happens in the "timeout" case (i.e. when 133 cycles have elapsed and there were no RAM accesses after 116 cycles had elapsed). My test never hit that case (at least no tin the segment I captured anyway) so I always saw a 3 cycle delay.
Eke wrote:According to this thread viewtopic.php?t=1563, these are /CAS2 before /RAS2 refresh cycles. Although /RAS2 is only available on expansion connector, /CAS2 is available on both cartridge and expansion connectors.
Hmm, I wonder how that DRAM cart worked if the refresh signal wasn't available on the cartridge port. Maybe it is available on sufficiently early revisions when that memory control register is set?
Eke wrote:For some unknown reason, refresh period is shorter during VDP DMA, although I am not really sure if this is really caused by VDP DMA or something more generic when 68k has released his bus since the VDP is not connected to /RAS2 or /CAS2
Refresh for devices on the 68K's bus seems to be synchronized with VRAM refresh during 68K -> VDP DMA. You can see this pretty clearly if you do a capture of one of the direct color DMA demos.

User avatar
Sik
Very interested
Posts: 593
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: 68K Refresh Delays

Post by Sik » Sat Jan 30, 2016 9:49 pm

Mask of Destiny wrote:Hmm, I wonder how that DRAM cart worked if the refresh signal wasn't available on the cartridge port. Maybe it is available on sufficiently early revisions when that memory control register is set?
It's confirmed to work on the earliest revisions (later models don't do anything). It also nearly halves the 68000 speed when running from cartridge (ouch!), so avoid it like the plague.

What I wonder is if refresh is the same on all models? I doubt model 3 has the same RAM refresh cycles for instance.
Sik is pronounced as "seek", not as "sick".

User avatar
TmEE co.(TM)
Very interested
Posts: 2286
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: 68K Refresh Delays

Post by TmEE co.(TM) » Sun Jan 31, 2016 5:10 am

Mask of Destiny wrote:Yeah, I have no idea why the EDCLK generator is connected to !OE/!RFSH for work RAM. Is there anything else attached to !OE on your VA1 or is that chip the only one. It's also a complete mystery to me why the low byte RAM chip has it's A13 connected to that rather than directly to VA14.
RAM A14 is treated specially on all machines, because it has something to do with SMS mode, when I passed CPU A14 directly to RAM some SMS games failed to run properly. I'm not sure I traced the A13 right, it maybe A14 instead. It was a while ago since I traced things out.
SMS uses SRAM for main RAM, and has no refresh stuff, but on MD in SMS mode the high byte of 68K RAM is used as Z80 RAM not the memory chip on Z80 bus... low byte connects to cart data bus. Very odd stuff...
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest