FPGA replacment for the ZX8301 ULA and more

[lliont]

I fixed the sprites

1024x768 19" 4:3 Monitor

640x350 at the same monitor

For the 1024x768 I spend lot of time to adjust clock timings, the fpga is at the limits of its speed, I should go to the same model but faster grade of fpga only a bit more expensive. Or I can choose the 640x350 resolution.

[martyn_hill]

Great progress, Leon!

It's easy for me to say, but I'd opt for the 1024x768 every time...

Good luck!

[tofro]

Be aware that a 1024x768 screen also needs to be fed. To get a screenful of graphics, compared to the HiRes, a standard resolution needs to move 4 times the amount of bytes to there. (I guess sprite display doesn't quite suffer from the high res so much, though).

The high-res, high-colour modes of the Q68 are a good hint on the fact that you can choose slightly too much of a resolution for a specific CPU (not saying that, for some, maybe text-only applications that can easily live with slow update rates, that can still make sense).
So, please don't dump the 640x350 res in favor of 1024x768 - If you could implement options, that would, however, be ideal.

[martyn_hill]

Hey Tobias!

I may be wrong, but I think Leon is describing the VGA output res/timing as opposed to the actual QL screen res as seen from software...

In other words, the upscaling algorithm used differs, not the actual screen res.

[tofro]

Ah. I may have got that wrong, then, thanks.

[Peter]

I may be wrong, but I think Leon is describing the VGA output res/timing as opposed to the actual QL screen res as seen from software...

It must be that way. On the screenshots, I see at least 4 bpp.
And 1024 x 768 @ 4 bpp means 384 KB of screen memory.
Filling that would crawl with a 68008 - even with 10 MHz instead of 7.5 MHz.
I don't know which memory is used, but if it is normal 8 bit wide asynchronous SRAM, bandwidth on the output side is another limitation.
(The Q68, as slow as it gets with 1024 x 768 @ 16 bpp, has 160 MB/s throughput.)

[Pr0f]

But if a 512 x 256 screen is upscaled to 1024 x 768 - meaning the same pixel data is being pushed out twice horizontally and 3 times vertically - the screen resolution is still only 512 x 256 - so the bandwidth required is smaller.

[lliont]

Exactly, and the geometry of the screen is changed, with the 640x350 it's one to one pixel but it has borders.

When screen frequency increases sprite engine has to run at higher frequency also and it uses a lot of logic circuits.

Bandwidth is not a problem for the QL up-scaled to 1024x768 resolution.

[Peter]

Bandwidth is not a problem for the QL up-scaled to 1024x768 resolution.

Of course. I did not mean that, but actual 1024x768 @ 4 bpp.
Are you using FPGA block RAM, async. SRAM oder SDRAM?

[lliont]

I got a true dual bus internal video ram that fpga accesses at 16bit words totally independent of the cpu that can simultaneously read and write at it.
The fpga can read at it's top speed from this vram at 16 bit and even in 32 or more bits at a time, my choice.
i.e. the sprite engine reads it's memory 64bit words at a time.
so no problem

The only problem would be to find a fpga with the internal memory for the particular mode but you can make a shadow memory with external memory if you have enough i/o pins.