Peter Graf via Ql-Users wrote:
>> Yes, this is true. That's the reason I have built a prototype of a
>> bus-snooper that mirrors the QL screen on an HDMI monitor, but... damn
>> it, now that you know I will never finish it :-)
> Believe it or not, but when I wrote my remark this noon, I was actually
> thinking "that could be something for Marcel Kilgus" now that he started
> playing with FPGA. Really.
> My guess is that you'd use an FPGA with >=32 KB RAM, so why bus-snooping
> and not fully replace the video area? Just to keep the original video
> output alive?

I've been thinking about this but I'm still probably not good enough
to to pull this off using pure hardware, especially as my goal was
HDMI which makes the task pretty much out of my league especially as
not every FPGA can do the necessary TDMS signals (bought a Spartan
board nonetheless if I ever wanted to try it ;) )

This was supposed to be a pure fun project for 2 or 3 evenings, so I
got a GAL and a bunch of level shifter to connect a Raspberry Pi to
the QL bus and did the rest in software. This is still not trivial as
sampling the bus in the neccesary frequency can only be achieved bare
metal, i.e. without any operating system running. But the video
processor at least handles the whole HDMI stuff, which is neat.

It almost worked before I stopped tinkering with it, it just showed
ALL memory accesses, not just the ones to the screen memory ;-) Some
problem with the address decoding in the GAL. Looked funny, but one
could see the blinking cursor etc.

Then the idea was to use an XC9572XL chip to do both level shifting
and address decoding. After that I had the idea that instead of level
shifting all the signals the CPLD could output them using a very fast
SPI line instead as this would save a lot of lines. The Raspberry
actually has a SPI slave function block, unfortunately nobody ever
used it and therefore it seems to be pretty buggy. That's when time
ran out around Christmas.

Cheers, Marcel

QL-Users Mailing List

Reply via email to