"what-if" QL extended graphics

[Pr0f]

I've been following that one - he was inspired by the earlier KIWI 68K project from Germany, which used the incredibly rare V9990 MSX VDP with the version MSX3 specification - which could drive VGA directly.

No one ever has stock of the chip and whenever examples do surface they are snapped up very quickly.

The Kiwi project is here: https://www.ist-schlau.de/

[lliont]

Come on, where's the fun in that?

But thanks! I will take a look at the manual in case there's any interesting ideas.

Probably 100 people wanting to enhance the QL graphics abilities would come up with 100 very different designs, all valid.
I'm trying to add to the existing QL video design without disrupting or replacing it, so same pixel format and no additional VRAM (except if needed in practice for speed reasons). Also to learn a bit more about FPGA and how video coprocessor hardware worked in the early 80s.

I totally understand you, to explore FPGAs and what hardware I could build myself I created a CPU (the Lion CPU) and a working computer with sprites, sampled audio and vector graphics from scratch.
It's fun to do it your way, and you learn a lot.

[tofro]

To 'cut to the quick' (no disrespect) the V9958 off the QL ROMport would fit the bill exactly!

Come on, where's the fun in that?

But thanks! I will take a look at the manual in case there's any interesting ideas.

Probably 100 people wanting to enhance the QL graphics abilities would come up with 100 very different designs, all valid.
I'm trying to add to the existing QL video design without disrupting or replacing it, so same pixel format and no additional VRAM (except if needed in practice for speed reasons). Also to learn a bit more about FPGA and how video coprocessor hardware worked in the early 80s.

I think your idea of re(?)-creating the next evolution steps of QL graphics is a good one - The QL architecture already suffers a bit from its "dumb" plain frame buffer, loading the CPU with moving about large chunks of memory (even larger and probably getting into the unbearable when we consider larger color depths). If you're looking for inspiration, it would probably make sense to make yourself familiar with what the Spectrum Next guys have done to the ZX Spectrum architecture (a sprite and tile sub-system, but still with a compatibility layer that allows old programs to keep working), even if they've gone much farther than you would probably want to go - It could still be a source for good ideas. The manuals and descriptions are all available online.

And I go with you that looking into contemporary graphics chips which largely have become unobtanium during the last few years isn't the way to go (and definitely wouldn't have been the way Sinclair would have done it hat they done a "QL Next")

[Peter]

I think your idea of re(?)-creating the next evolution steps of QL graphics is a good one - The QL architecture already suffers a bit from its "dumb" plain frame buffer, loading the CPU with moving about large chunks of memory (even larger and probably getting into the unbearable when we consider larger color depths).

Graphics accelaration was the Commodore way, making those machines expensive. It contibuted to the ZX Spectrum's a huge success to avoid this, addressing the less monied audience.

Considering the QL was a low cost machine, not even aimed at games, and Sinclair had to cut costs somehwere, I think that hardware graphics acceleration was really not what the QL lacked much. Having a 68000 CPU while getting rid of the IPC and one SER would have come at no extra costs, while already providing a lot of graphics acceleration just by the double bus bandwidth! And of course massive advantage for overall speed. If I had the choice between the 68000 at the same costs, or the 68008 and a graphics accelerator at extra costs, I would surely pick the first one!

If you're looking for inspiration, it would probably make sense to make yourself familiar with what the Spectrum Next guys have done to the ZX Spectrum architecture (a sprite and tile sub-system, but still with a compatibility layer that allows old programs to keep working), even if they've gone much farther than you would probably want to go - It could still be a source for good ideas.

It is just not a technology that is connected to the Spectrum or QL era, or the "ZX Spectrum architecture", which was of course DRAM based. The Speccy Next guys simply use SRAM for this task - completely unffordable in the QL days, but of course making it easy for FPGAs.

[M68008]

I totally understand you, to explore FPGAs and what hardware I could build myself I created a CPU (the Lion CPU) and a working computer with sprites, sampled audio and vector graphics from scratch.
It's fun to do it your way, and you learn a lot.

Wow, that's seriously impressive! Congrats! Love that you added the vector graphics!

[M68008]

The QL architecture already suffers a bit from its "dumb" plain frame buffer, loading the CPU with moving about large chunks of memory (even larger and probably getting into the unbearable when we consider larger color depths). If you're looking for inspiration, it would probably make sense to make yourself familiar with what the Spectrum Next guys have done to the ZX Spectrum architecture (a sprite and tile sub-system, but still with a compatibility layer that allows old programs to keep working), even if they've gone much farther than you would probably want to go - It could still be a source for good ideas. The manuals and descriptions are all available online.

Yes, 32K video is a lot for the 68008 to handle, although most 8 bit computers had the same issue, for example you could not do full screen scrolling on a Spectrum in a single frame. That didn't block people from writing many good games, though.

I really love what they did with the Spectrum Next. While you can use it for emulation of the original machine, it sounds more like a Spectrum on steroids that should be fun to use and to code for.
On the graphics side, I remember reading that you can have over 100 sprites per scanline. Again, fun. So far, for my project, I've followed a different approach of keeping it small and not adding much more than would have been possible and affordable at the time (but I might change my view on that). From some back of the envelope calculations, I think, using a 16 bit data bus and fast DRAM from the 80s, a ZX8301++ should be able to transfer at least 128 bytes per scan line for sprites (without using RAM burst mode, to avoid stalling the CPU too much). That could be 16 sprites 16 pixel wide using the same pixel format as the QL.

[M68008]

Graphics accelaration was the Commodore way, making those machines expensive. It contibuted to the ZX Spectrum's a huge success to avoid this, addressing the less monied audience.

Considering the QL was a low cost machine, not even aimed at games, and Sinclair had to cut costs somehwere, I think that hardware graphics acceleration was really not what the QL lacked much.

Completely agree.

[Peter]

By the way, here is a simplified example why I didn't tinker with graphics accelleration on the Q68, although it is sometimes requested:

A MOVE.L CPU instruction fetch on the Q68 takes one cycle, if executed from fast RAM. (And 12 KB fast RAM are enough for basic software accelleration routines.)
4 x DRAM random accesses are needed to move one longword of video DRAM from A to B on the 16 bit bus. And each one takes 4 x CPU cycles.
So a total longword memory move from A to B takes 17 cycles if done by CPU. A graphics accelerator would take 16 cycles, a speed gain of only 6%.
Even if 16 bit words (corresponding to one highcolor pixel) are moved separately, the gain would be just 11%.
Of course the CPU has loop overhead, where no unrolling is possible, etc. etc. But CPU instructions are in many cases just single cycle plus memory overhead. So video DRAM is the main bottleneck, making a graphics acceletator quite disappointing. (Unless it is very complex, using variable length DRAM bursts etc.)

Stuff like cache or a separate video DRAM independent from the main DRAM would be more helpful in overall performance, and as a side effect also provide some graphics accelleration.

[M68008]

I've finally found some time to tweak some demo code I've had for a couple of years and make a video out of it that shows the extended QL graphics idea: https://www.youtube.com/watch?v=7EizW3ZWNqc[/youtube]

[dex]

Impresive video!