Fun with DTACK

[cgfm2]

I'm trying to map a NVRAM chip within the $800000-$9FFFFF memory range, and don't want to use $000000-$7FFFFF or the other areas where /DTACK is managed by the hardware. So I'll need to assert it myself, but that's where things get confusing. I've been looking at other 68000 designs to see how this is done.

In one circuit I've seen, the CPU clock is used to clock a hex latch that has each output feeding into the next input (Q0->D1, Q1->D2, etc.). The first input is pulled low when a range of memory is enabled (in this case an EPROM) and R//W goes high. So the read access sets the timer (conceptually a shift register) in motion.

This way a '0' bit is shifted through the latch per clock cycle, and the output of each stage goes low after a specific unit of time such as 125ns, 250ns, 375ns, etc. Whichever output corresponds to the desired delay is fed to /DTACK. It makes sense but needs a few TTL chips to implement, I can't spare a lot of PCB space.

A simpler example has a flip-flop that latches /AS and outputs it to /DTACK, clocked by the CPU clock. Though I'm not clear if these means /DTACK follows /AS or is delayed by one cycle of the master clock (which would be 130ns for the Genesis, a reasonable delay). But this circuit also used the preset input of the flip-flop to delay /DTACK assertion by some host devices which seem to always be enabled so it's hard to tell how much time really passes.

Any ideas about easy ways to handle this?

Going by the NVRAM datasheet, there are delays between the time that /CS and /RD are asserted and it drives the bus during a read (isn't this called setup time?), and a similar delay from the time /CS and /WR are asserted and the moment when it actually latches the data bus.

So the /DTACK delay has to meet or exceed these two timing requirements, right?

 

[Mask of Destiny]

Just how slow is your NVRAM? You've got at least 3 cycles between a valid address and the /AS strobe and when the data is ready even if you just keep /DTACK low. That's ~390ns.

/DTACK is effectifely tied low all the time (unless some bit of hardware is driving it high). I don't think /DTACK is every managed for external hardware (except perhaps if the DRAM support is enabled). There's really no need.

 

[cgfm2]

Originally posted by Mask of Destiny@Mon, 2005-08-08 @ 12:06 AM

Just how slow is your NVRAM? You've got at least 3 cycles between a valid address and the /AS strobe and when the data is ready even if you just keep /DTACK low. That's ~390ns.

The datasheet says it can be accessed at 450ns - this is a really old part but the only thing I could find in a 16-bit organization (128 words x 16 bits). Modern NVRAM is faster but all 8-bit, it seems.

After some consideration I'm thinking I could get away with using both sections of a 74LS74 to double the time to 782ns. It's a bit excessive but I just want to see what works.

About the 3 cycle delay; I thought to properly do address decoding you had to use the address bus contents only when /AS is low. If the address bus is valid 3 cycles before /AS (meaning you could theoretically do the address decoding sooner), how can this be detected?

/DTACK is effectifely tied low all the time (unless some bit of hardware is driving it high). I don't think /DTACK is every managed for external hardware (except perhaps if the DRAM support is enabled). There's really no need.

When I try pulling /DTACK low and leaving it that way, the system is frozen - it doesn't lock up, but it just stays paused until I pull /DTACK high. So I'm sort of under the impression that I really do have to assert it only when needed.

Looking at the schematics, the VDP also has a /DTACK output so I wonder if pulling it low all the time interferes with the VDP's control of the 68000.

 

[Mask of Destiny]

450ns? Ouch. Wouldn't it be easier to just gang two faster 8-bit parts together?

Originally posted by cgfm2+Mon, 2005-08-08 @ 05:56 AM--><div class='quotetop'>QUOTE(cgfm2 @ Mon, 2005-08-08 @ 05:56 AM)</div><div class='quotemain'>About the 3 cycle delay; I thought to properly do address decoding you had to use the address bus contents only when /AS is low. If the address bus is valid 3 cycles before /AS (meaning you could theoretically do the address decoding sooner), how can this be detected?[/b]

You misunderstood what I meant. The /AS strobe and valid address occur at the same time, you then have 3 cycles before the 68K latches the data (for a read operation) or when the data bus becomes invalid (for a write).

<!--QuoteBegin-cgfm2

When I try pulling /DTACK low and leaving it that way, the system is frozen - it doesn't lock up, but it just stays paused until I pull /DTACK high. So I'm sort of under the impression that I really do have to assert it only when needed.[/quote]

I thought /DTACK low meant data is ready and /DTACK high means data is no ready? Either way, my point was that it doesn't normally manage /DTACK for external memories regardless of where in memory they sit and that it's held low so the 68K will default to a normal 4 cycle (3 useable cycles) read unless something pulls /DTACK high. Obviously if you're going to pull it high you'll need to only pull it up as long as needed.

Looking at the schematics, the VDP also has a /DTACK output so I wonder if pulling it low all the time interferes with the VDP's control of the 68000.

I bet the VDP uses /DTACK to freeze the 68K when the FIFO gets full. The VDP probably also needs to listen to /DTACK for DMA operations.

 

[cgfm2]

450ns? Ouch. Wouldn't it be easier to just gang two faster 8-bit parts together?

It would, but I'm doing this on a breadboard and don't have the room to spare.

If I knew a bit more about PCB routing it would be nice to stick this kind of stuff on a custom cartridge PCB instead of having wires everywhere.

You misunderstood what I meant. The /AS strobe and valid address occur at the same time, you then have 3 cycles before the 68K latches the data (for a read operation) or when the data bus becomes invalid (for a write).

Oops! I found the part in the 68K user's manual that describes this, so I see what you mean. However there's a distinction to be made: (using the read cycle as an example)

S2 - 68000 drives /AS, /UDS, /LDS

S3 - No-op

S4 - /DTACK or /BERR accepted to terminate cycle; CPU inserts wait states *until* either one is asserted

S5 - No-op

S6 - Data bus latched

So while there are 3 states between /AS valid and the data bus being latched, in reality state 4 is stretched indefinitely. (this is on page 5-4 BTW)

I thought /DTACK low meant data is ready and /DTACK high means data is no ready? Either way, my point was that it doesn't normally manage /DTACK for external memories regardless of where in memory they sit and that it's held low so the 68K will default to a normal 4 cycle (3 useable cycles) read unless something pulls /DTACK high. Obviously if you're going to pull it high you'll need to only pull it up as long as needed.

I guess I had envisioned the opposite; /DTACK is normally held high (inactive) and driven low by other peripherals in the Genesis or external hardware, depending on the memory range.

From what I've seen in some arcade games this is the kind of arrangement used. For example one system has several devices that have their DTACK outputs going through open-collector buffers of a 74LS07, and the resulting outputs are tied together, run through a pull-up resistor, and finally connected to /DTACK.

So any device can pull /DTACK low, even multiple ones without causing a conflict, but otherwise it remains high.

I bet the VDP uses /DTACK to freeze the 68K when the FIFO gets full. The VDP probably also needs to listen to /DTACK for DMA operations.

That's a really interesting point. I've never been able to fill the FIFO but if the 68000 was waiting for /DTACK during a full FIFO condition (assuming the VDP delays asserting it until it can flush part of the FIFO to VRAM) then the 'full' state in the status flags wouldn't be visible to the 68000.

In the same way, there are warnings about reading VRAM too quickly after setting the command but in practice it's not possible to do that. You can deliberately send some weird commands to the VDP to screw up timing, but otherwise it may be that it delays /DTACK when reading the data port (or after sending a VRAM read command) until it has internally read and latched the data from VRAM.

Just for the sake of testing I should look into any additional delays that are caused from VDP access. I can't think of any Genesis games with critical timing, though I know Monster World IV does some weird stuff with VRAM during H-Blank in it's intro sequence that doesn't work in any emulators.

Glad you pointed this out.