About !DTACK timings
Moderator: BigEvilCorporation
About !DTACK timings
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 ?
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 ?
-
- Very interested
- Posts: 2442
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
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.
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
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
I've already done this before. But pictures are dead. If you want, I can repeat that.
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
Open Bench is cheap and therefore rather limited as a "logical analyser" so I wouldn't mind to have more precise figures
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
please do, I remember this thread but never saw the pictures you postedI've already done this before. But pictures are dead. If you want, I can repeat that.
Open Bench is cheap and therefore rather limited as a "logical analyser" so I wouldn't mind to have more precise figures
Last edited by Eke on Tue Jan 27, 2015 4:47 pm, edited 1 time in total.
-
- Very interested
- Posts: 2442
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
What happens when you set or clear bit8 of $A11000 ?
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
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
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)
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)
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Let's do it.Eke wrote:I will try to make one to check if $A11000 bit (it's external RAM refresh register I think ?) has any effects.
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:I also want to observe banked access (from 68k to Z80 but also the opposite) by triggering VTOZ and ZTOV signals
Month ago I bought new probes. http://www.aliexpress.com/item/Wholesal ... 16829.htmlEke wrote:(they are still output by 315-5660 despite being only used internally but hardly accessible with the proble cables i have)
Now, I can attach it to QTFP IC pin.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar