*** M E M O R U M ***

That's a VERY interesting idea.

No HC165's in the box, but the are some HC166's I think I may have a play later.

Technical details of the problem:

We're both the VDP's own build in wait signal, It's supposed to hold up the CPU if it identifies a CPU to VDP transfer before the previous transfer completes. So SHOULD eliminate the need for the programmer to use software delays on the CPU side when writing to the VDP.

However, at higher CPU frequencies it's activated too slowly to be recognised by the CPU, and so misses a transfer and delays the instruction after instead!

Currently this is starting to happen somewhere between 11 and 12mhz. A little short of the 16mhz we were shooting for.

With software delays and the Z80 overclocked, CPU speeds of up to 40mhz have been possible with the much simpler CPU test board without any display corruption being evident.

So, what you appear to be saying, is you need a separate automatic (fast acting) wait state generator that holds the CPU in wait states when addressing the VDP until the VDP can produce it's own wait state.

So a 74xx74 flip flop may do the job when linked to the address decoding circuit for the VDP. May need a faster part than HC series logic though, like 74AC74.

So when the address decoding circuit for the VDP produces an active signal, flip-flop triggered to "wait" state, output from flip-flp holds Z80 /WAIT low. When VDP WAIT output goes active, flip-flop is returned to it's normal state. Z80 still held in a wait state, but directly by the control from the VDP. Note, a gate is needed to combine the two sources of wait control signals going to the Z80. Open collector/pull up operation will be far too slow.

Also does the VDP always produce a wait control signal? If no, a method of detecting a "no wait required" will be required to return the flip-flop to it's normal state or inhibit it.

Does that sound like it may work?

Mark

The 2 stage wait that's about it.

Although it may need a 3rd input from the sound chip at some point. However putting a 3 or 4 input AND at the last stage would take care of that.

The VDP wait only goes low if it's needed, if the VDP is ready it will just take the data and deal with it.

What the V9958 manual says about the wait signal is:

WTE
0: Disables the WAIT function. (Initial value)
Works in the same way as V9938.
1: Enables the WAIT function.
When the CPU accesses the VRAM, accesses to all ports on V9958 is held in the WAIT state until access to the VRAM of V9958 is completed.
However, WAIT function is not provided for incomplete access to the register and the color palette or for the data ready status of commands.

I read that as meaning it won't signal any wait on the 2 byte updates. So they might need the help of the auto-wait stage.

The time for wait to go low is given as 130ns. So the range of 1-8 extra waits from the shift register should be more than enough even on the test boards.

The data book also says that read and write signals *CSW and *CSR need to be low for 186 ns minimum. The Z80 book shows *RD, *WR and *IORQ, that we generate those signals from are low for 2.5 cycles with normal in/out timing. The cycle time at 16mhz, is 62.5 ns meaning 3 full cycles required. So an additional wait state, ought to be inserted anyway to meet that requirement too.

There's obviously a little leeway there though as the test boards have been running a lot faster than 16mhz and yet the VDP output was fine with just software delays and no extra waits

Hi Bill,

The schematic on the web is the last stable version, it works OK up to about 8MHz. My board currently has an additional GAL with additional logic for wait state generation, it's that bit that isn't working at the moment,

Regards
Dave