Programmable IO waitstates experiments

Por lintweaker

Master (250)

Imagen del lintweaker

16-05-2020, 15:07

I have programmed a CPLD to insert additional waitstates to the Z80 to slow down I/O access. The additional waitstates can be set from 0 (disabled) to 255.

As a test I just let the Z80 run on 10MHz and play with number of needed extra waitstates to get a properly working screen.
Some findings I can use some help on explaining:
- With a certain amount of extra IO waitstates I get a normal basic screen but the area where the function keys are printed is always garbled (ie. list => iist').
- When I do a listing of a short basic program the list show up normal a few times on the screen until a get near the bottom lines then it appears garbled but then also the rest of the screen gets garbled.
with a CTRL-L to clear the screen and everything back to normal (except the function keys).

What could cause this issue?

Login sesión o register para postear comentarios

Por Parn

Hero (557)

Imagen del Parn

16-05-2020, 16:07

Maybe the RAM isn't keeping up with the Z80 speed? I don't know whether this is possible. Won't this issue go away no matter how many waitstates are inserted?

Por lintweaker

Master (250)

Imagen del lintweaker

18-05-2020, 08:30

For future reference:
the garbled screen is the well known scroll issue when the VDP is accessed too fast. It needs quite a big slow down to work properly. I've modified my CPLD code to make it an automatic switcher between 7.x and 3.58MHz based on VDP access. Up to 1ms seems to be needed (which seem a little big).

Por pgimeno

Master (176)

Imagen del pgimeno

18-05-2020, 13:02

1ms is too much. The TMS 99[12][89]A VDP datasheet mentions 2 to 8µs. Are you sure you're slowing down the access properly?

Data Manual wrote:

The CPU interacts with VRAM memory through the VDP. The amount of time necessary for the CPU to transfer a byte of data to or from VRAM memory can vary from 2 to 8 microseconds. Once the VDP has been told to read or write a byte of data to or from VRAM it takes approximately 2 microseconds until the VDP is ready to make the data transfer. In addition to this 2 microsecond delay, the VDP must wait for a CPU access window; i.e., the period of time when the VDP is not occupied with memory refresh or screen display and is available to read or write data."

Por Grauw

Ascended (9071)

Imagen del Grauw

18-05-2020, 14:05

I think the Z80 bus access times need to be slowed down to Z80 timing specifications, like the turboR does. This is not only important for the VDP, but also other cartridge slot hardware. Internal RAM can be accessed at full speed.

Additionally the VDP needs a wait on VRAM access (port 98H); I think the WAIT pin on the V9958 can be used for this, otherwise you need a time-out counter, also like the turboR has.

Setting the CPU to 3.58 MHz is what 7 MHz circuits always used to do, but I think it’s a bit of a "poor man’s" solution, also it probably doesn’t scale very well past 7 MHz. The turboR approach is more elegant.

Por sd_snatcher

Prophet (3270)

Imagen del sd_snatcher

18-05-2020, 14:02

What's the VDP in question, anyway? TMS912x, V9938 or V9958?

Por lintweaker

Master (250)

Imagen del lintweaker

20-05-2020, 19:55

sd_snatcher wrote:

What's the VDP in question, anyway? TMS912x, V9938 or V9958?

It's an V9958. The wait pin is connect but currently not automatically enabled in my current setup.

Por lintweaker

Master (250)

Imagen del lintweaker

20-05-2020, 19:59

Grauw wrote:

I think the Z80 bus access times need to be slowed down to Z80 timing specifications, like the turboR does. This is not only important for the VDP, but also other cartridge slot hardware. Internal RAM can be accessed at full speed.

Additionally the VDP needs a wait on VRAM access (port 98H); I think the WAIT pin on the V9958 can be used for this, otherwise you need a time-out counter, also like the turboR has.

Setting the CPU to 3.58 MHz is what 7 MHz circuits always used to do, but I think it’s a bit of a "poor man’s" solution, also it probably doesn’t scale very well past 7 MHz. The turboR approach is more elegant.

Can you elaborate on the Turbo-R time-out counter? My goal is to make some sort of 'DX2' like setup where the bus speed can be different from the CPU speed (like with the Z280 is possible).
I can now finally make some usable stuff with FGPA's so hopefully I can make it work.