HomeForumsWhat's newResources 
 
 
Fun with DTACK
cgfm2 - Aug 7, 2005
  cgfm2 Aug 7, 2005
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 Aug 7, 2005
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 Aug 7, 2005

  
	
	

		
		

			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 Aug 7, 2005
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-->
QUOTE(cgfm2 @ Mon, 2005-08-08 @ 05:56 AM)
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).