FPGA replacment for the ZX8301 ULA and more

[Nasta]

I think I solved it.
I just delay 1 cycle bringing the DTACK low when PCENL is low and it now seems to work ok with 10Mhz cpu/ZX8301 clock and 7.5 Mhz ZX8302 clock.
Just made the access cycle longer when talking to zx8302.

This is the way to do it, and the way GC and SGC do it since their CPUs work at a much higher clock while appropriately delaying the DTACK signal to the CPU will slow down it's bus operation.
7.5MHz clock would be provided to the ZX8302 for serial and MDV compatibility. IPC and NET are bit-banged so timing is entiraly software controlled, though I suspect there is some hardware support for NET but probably buggy so not used.
Running the CPU at 8MHz would also increase the video base clock to 16MHz and pixel clock to 10.666 which would, with appropriate line timing result in the full 512 pixels in the horizontal direction visible without overscan on a PAL monitor or TV, at least according to PAL spec.
There are also other possibilities once a FPGA is used instead of the 8301, given that the 8301 is the main memory decoder.
I would honestly not bother with the motherboard RAM, or at least the part containing the screen, rather include a 128k SRAM on board since this is much faster and lower power and still makes it possible to manipulate the existing 8301 based signals to make the access not slow down the CPU at all. Even better if the whole thing was moved to the CPU socket and using the 8301 socket just to pass the basic signals.
One interesting possibility is mapping some RAM in the 16k region starting at $1C000, which makes it possible to move the base of the screen to that address and have a 48k sized screen RAM for some extra resolution. Another possibility would be to use the internal FPGA RAM as a line buffer and get a QL display shown on a VGA monitor using a base 1024x768 resolution using a 2x3 pixel area on the 1024x768 screen to display 512x256 QL resolution.
That being said, if one can get access to 48k of screen ram, this could be extended to 512x384 using a 2x2 VGA pixels for each QL pixel. There are even more interesting possibilities - if 4x4 VGA pixels are used, 256x192 resolution will result but a 48k screen area affords us 8 bit color for each pixel in this arrangement, which gets you a really interesting resolution for games...

[Nasta]

The other approach is to control the clock going to the CPU - you can use a flip/flop or two within the FPGA to gate the clock signal to the CPU such that you get a 'glitchless' clock change - then you can select between a fast and slow clock. Any access to the ZX8302 can slow the CPU clock down if needed, or if you have some compatability issue with certain software you can have a couple of new commands or just an I/O address to poke if you are not wanting to go the route of a new command - to switch between fast and slow CPU clocks.

https://www.programmersought.com/article/68545257095/

I think that one way to avoid "glitces" and use lower frequency to the zx8302 is to have a higher frequency as an integer multiple of the lower.
The integer ratio will allow constant phase between the 2clocks.
So if I use the MC68SEC000 at 15Mhz I maybe could use the 7.5Mhz frequency for zx8302 but then maybe with so big speed difference zx8302 will respond too late.

68SEC000 rated at 20MHz will happily work at 22.5 (7.5x3) especially at 5V...

[lliont]

Thanks for the info, many options to consider.

[tofro]

The other approach is to control the clock going to the CPU - you can use a flip/flop or two within the FPGA to gate the clock signal to the CPU such that you get a 'glitchless' clock change - then you can select between a fast and slow clock. Any access to the ZX8302 can slow the CPU clock down if needed, or if you have some compatability issue with certain software you can have a couple of new commands or just an I/O address to poke if you are not wanting to go the route of a new command - to switch between fast and slow CPU clocks.

https://www.programmersought.com/article/68545257095/

I think that one way to avoid "glitces" and use lower frequency to the zx8302 is to have a higher frequency as an integer multiple of the lower.
The integer ratio will allow constant phase between the 2clocks.
So if I use the MC68SEC000 at 15Mhz I maybe could use the 7.5Mhz frequency for zx8302 but then maybe with so big speed difference zx8302 will respond too late.

68SEC000 rated at 20MHz will happily work at 22.5 (7.5x3) especially at 5V...

Most of them (except the FU variants) will even happily run at 50MHz.

[lliont]

Although I have to de-solder, program and re-solder the flash chip every time since I damaged the jtag pins of the fpga I did some progress.

I used the following simple way to temporary change clock frequency of the zx8302 that seems to work:

for75<="00" when for75="1"&PCEN and rising_edge(CLKIN) else for75+1 when rising_edge(CLKIN);
CLKZX2<=for75(1);

a 30Mhz counter counts up to 3 or 4 depending on PCEN status and I use the high bit of the counter as a clock to zx8302.
This provides a 10 Mhz with 33.33% duty cycle or a 7.5Mhz with 50% duty cycle clock.

Serial mouse works

Maybe it's time for a sprites test-demo, I'm thinking of a simple game in C.

[martyn_hill]

That's a very creative solution to the problem of maintaining 100% compatibility with the 8302, Leon!

[lliont]

So there are 2 ways to address the problem that both seem to work, either slow the cpu access or speed the ZX8302 clock when they communicate as long as the zx8302 can work at that frequency, for faster clocks as I intend to try with the mc68sec000 only the first method will do.

[Derek_Stewart]

Hi,

Looks great, I am trying to HDL, mainly, Verilog, so I am interested in the development.

[lliont]

The development of a Galaxians clone game using the hardware sprites is in progress, I am porting it from my Lion computer, it was written in Java and for the QL version I use C68. First time I use C68 and there are things (i.e. printing at fixed position of the screen) I don't know how to do but I hope I'll find out.
The following is a small video of the unfinished game. Still no sound, no stars in the background and no score plus few bugs.
46 sprites are available using 6K of fpga ram.
It' s not easy to play with one hand and hold the phone-camera with the other.

https://drive.google.com/file/d/1MwFOXk ... sp=sharing

[thorsinclair]

WoW - great!

Well done!