About !DTACK timings

Eke · Post by **Eke** » Sun Apr 21, 2013 4:34 pm

I just got my hand on an Open Bench Logic Sniffer and first thing I tried was measuring DTACK timings regarding !AS and VCLK on my PAL MD2.

Here is what I noticed:

(1) DTACK is usually asserted 1 VCLK after !AS is being asserted, which means zero wait-state and a bus cycle of 4 VCLK

(2) periodically, DTACK will be delayed by 1,2 or 3 (!) VCLK, which means the assertion of up to three wait-state

The delay "seems" to be periodic although I am not sure of the period: for example, with the Everdrive OS, which seems to only run from RAM, there seems to be constantly 3 wait-states repeating every 17 us approx. With other games, wait-states seem to occur more like every 8-10 us, regardless if CPU is accessing ROM or RAM.

That's said, I'm not sure if this is really a periodic "event" or just something indirectly caused by the game program, which would appear to be in a periodic loop. Could it be caused by periodic or random RAM refresh done by the console ?

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sun Apr 21, 2013 8:27 pm

It is a refresh period. The main memory is Pseudo Static RAM, and needs periodic refresh pulses. This can also be enabled in ROM area but I don't recall the register address that enables it.

HardWareMan · Post by **HardWareMan** » Mon Apr 22, 2013 2:51 am

I've already done this before. But pictures are dead. If you want, I can repeat that.

Eke · Post by **Eke** » Tue Apr 23, 2013 8:40 pm

Yes, it is indeed periodic RAM refresh, which will add from 1 to 3 wait-state when RAM access is done at that time

1 wait-state

3 wait-states

I verified there are no wait-states inserted if a ROM access is done during RAM refresh (which seems logical)

However, as you can see in the previous picture and the one below, there are still periodic wait-states inserted for ROM access, but they are not synchronized to RAM refresh

I couldn't figure what cause these wait-states, access is done to ROM area (not Z80, IO or VDP since A23 is low), they don't seem to be related to RAM refresh but still seem periodical as well

Here we can see the period is approximately 17 us for wait-states during ROM access and 17,5 us for RAM refresh, which cause wait-states on ROM and RAM access to be unsynchronized.

curious stuff

EDIT: those extra wait-states seem related to /RAS2 refresh cycles as described in this topic: viewtopic.php?t=1563&sid=fe4b45f4b78ee8 ... 379e4d1fac

refresh cycles apparently occurs more frequently during DMA (every ~9ms approx.), which matches with my observations

I've already done this before. But pictures are dead. If you want, I can repeat that.

please do, I remember this thread but never saw the pictures you posted
Open Bench is cheap and therefore rather limited as a "logical analyser" so I wouldn't mind to have more precise figures

TmEE co.(TM) · Post by **TmEE co.(TM)** » Tue Apr 23, 2013 9:09 pm

What happens when you set or clear bit8 of $A11000 ?

HardWareMan · Post by **HardWareMan** » Wed Apr 24, 2013 3:25 am

Make your own test PD ROM and I'll make diagrams.

Eke · Post by **Eke** » Wed Apr 24, 2013 8:43 pm

I didn't use any test ROM yet, only retail cartridges and everdrive OS.

I will try to make one to check if $A11000 bit (it's external RAM refresh register I think ?) has any effects.

I also want to observe banked access (from 68k to Z80 but also the opposite) by triggering VTOZ and ZTOV signals (they are still output by 315-5660 despite being only used internally but hardly accessible with the proble cables i have)

HardWareMan · Post by **HardWareMan** » Thu Apr 25, 2013 3:43 am

Eke wrote:I will try to make one to check if $A11000 bit (it's external RAM refresh register I think ?) has any effects.

Let's do it.

Eke wrote:I also want to observe banked access (from 68k to Z80 but also the opposite) by triggering VTOZ and ZTOV signals

Very interesting thing. I had some clones, that have some troubles with timing of bus arbitrage. That cause screen garbage in RRR with 2 player mode and Larry turned on. Then I figured out that one capacitor need to be changed with fewer capacitance. And that fix this glitch. So, original timing of bus arbitrage are very important thing and it needs to be measured.

Eke wrote:(they are still output by 315-5660 despite being only used internally but hardly accessible with the proble cables i have)

Month ago I bought new probes. http://www.aliexpress.com/item/Wholesal ... 16829.html
Now, I can attach it to QTFP IC pin.

HardWareMan · Post by **HardWareMan** » Fri Apr 26, 2013 1:08 pm

First approach.

It was Rocket Knight Adventures. Need to test Rock'n'Roll Racing, when Larry says.

Eke · Post by **Eke** » Tue Apr 30, 2013 8:47 pm

Interesting, so this is Z80 banked access to 68k bus ? The first picture seems different although (bus request seems to have no effect as !AS still works as usual and !BGACK active period is shorter).

What are BUSR and BUSA signals by the way ?

HardWareMan · Post by **HardWareMan** » Wed May 01, 2013 5:05 am

Eke wrote:What are BUSR and BUSA signals by the way ?

Z80 BUSRequest and BUSAcknowledge. Not only Z80 can request the M68K bus, VDP can too - remeber that.

notaz · Post by **notaz** » Sun Oct 26, 2014 7:41 pm

So, has anyone investigated the memory mode register? I don't have a logic analyzer, but from looking at spinning loops it seems it has no effect on 68k's bus access timings.

Nemesis · Post by **Nemesis** » Sun Oct 26, 2014 10:39 pm

No, never looked at it, and I'm curious about this too. I wouldn't be surprised if this feature was removed from later models, so we'd need to test on an early and late system for comparison.