Z80 cycle accuracy

[Jusalak]

Can C128 MiSTer do Z80 raster-related things accurately? See the attached program. That defies current software emulators. Pretty cool if it could. a_little_128_raster_interrupt_demo.zip

[eriks5]

It also defies the MiSTer core 😕. All it does is change the second row of characters to white and then halts.

I've run it on a real C128 and it does work there. Can you explain how it's doing what it's doing? Any ideas of what's breaking it? Is the original source code available for reference?

[eriks5]

Seemingly related topics/issues:

• https://sourceforge.net/p/vice-emu/bugs/1979/ vice issue for original/similar report(?)
• https://c-128.freeforums.net/thread/1217/using-timer-measure-duration-switch core fails all tests of test program
• https://sourceforge.net/p/vice-emu/bugs/1985/ vice issue for timing test

[eriks5]

Hang was due to an incorrect address decoding in bank 2. With the MMU fixed, it now does this:

So.. it's close. But not perfect

[Jusalak]

The demo is basic raster programming stuff but done with Z80, at VICE repository there is C128 Z80 timing suite which is worth looking at. At VICE #1979 there are other testprograms with sources which are worth checking. Bank #2 was used because of Z80 access to 38h INT vector.

[eriks5]

The Z80 I/O timing is now correct.

The Z80<->8502 switch timing is still 1 or 2 cycles off, and why is eluding me for now. I might release as-is and come back to this later.

Thanks for your great little test programs over at the Vice issue tracker. Really helped me a lot in getting the I/O timing right.

[Jusalak]

Good work! Did you check also going across the bad lines? Testprogs for PAL attached (were also in the VICE thread). testcpuswitch.zip

[eriks5]

Yes bad lines work correctly. CPU and VIC access the RAM in the same way as real hardware on the MiSTer, so if bad lines wouldn't work correctly the VIC would display garbage or CPU would crash because it executes VIC data.

[Jusalak]

What causes the Z80 <--> 8502 timing difference i can only guess. It may be related to Z80 instruction decoding, or it may be due to some kind of safeguard which is to ensure the stability of running. But what seems to be important is that the time of the next Z80 startup seems to be dependent on whether the Z80 last time ended in odd or even cycle. And while the whole issue may seem inconsequental, it may become important if the CPUs are to work in tandem.

Also two other issues you may want to check:

MMU memory access issue: https://sourceforge.net/p/vice-emu/bugs/2022/

Char ROM issue: https://sourceforge.net/p/vice-emu/bugs/1987/