Side Project: rPi (CosmosEx) as HDMI graphics card

[Gunstick]

Hi

this suggestion does not need any change to the ST board and could also be implemented on stock STs.

Some people have an rPi in their ST's with the CosmosEx.
There is a high speed DMA connection to transfer data between the CEx and ST.

The rPi has a HDMI port.

So a GEM graphics driver could write via DMA to the rPi instead into screen memory. This could be implemented as a VDI device.
If people are interested to make this a reality, we could create a separate forum topic.
People needed:
* GEM/VDI programmers who can create a driver (and define the protocol to transmit to the graphics card)
* linux hackers who could translate transmitted commands into graphics
* people understanding CosmosEx and how to create a communication channel ST<->rPi

Georges

[exxos]

A interesting idea. You would probably have to talk to jookie about that.

Though the data transfer is likely going to still be a issues as you are limited to ST-RAM speeds. You then have the overhead of the driver, interface protocol, then the rPi processing and conversation. I think from start to end it will probably run out of bandwidth. Even more so when accessing hard drive or floppy drive.

Normally a gfx chip is placed on the 68000 side of things, running the CPU at higher speeds along with fast-ram. Myself and Rodolphe actually talked about this some months ago. Though while it is hard to find a graphics chip, the main problem is someone to write drivers for it. From a hardware point of view, you can bang on the 68000 bus anything you want really, its generally not that hard. Though without the driver and software to use it there is no use even looking at hardware.

I think ideally, it needs to be some type of FPGA clone of the ET4000 graphics card. I think that is compatible with NVDI. So do not need drivers then. But then it needs someone to re-create the graphics card into FPGA. I think that would be the best direction to go down. Then at least with open source FPGA, it can be modified and more future proof than using old skool graphics chips.

[Anzac]

i also think FPGA is the way to go on the graphic side of things. preferably something that could be used on an ST(e) and hopefully MegaSTe/TT with a VME adapter...

[rpineau]

I have been talking to a use on Hackaday.io who's making a video card based on the iCE40 FPGA for his 68K board. He told me that we can use his code as we see fit (planing it for the 68020/68030 card). Adapting it for VME shouldn't be hard either once we have some working code.
This will be a lot faster than anything on the DMA port.
We also need to keep in mind that the bigger the resolution the more data the CPU has to move around and the slower it will be. But a good video mode in 8 bit chunky with a 256 color palette should give good performances.
The VHDl code is open source :
https://github.com/stuartatpeasy/m68k-s ... controller

Rodolphe

[exxos]

I have been talking to a use on Hackaday.io who's making a video card based on the iCE40 FPGA for his 68K board. He told me that we can use his code as we see fit (planing it for the 68020/68030 card). Adapting it for VME shouldn't be hard either once we have some working code.
This will be a lot faster than anything on the DMA port.
We also need to keep in mind that the bigger the resolution the more data the CPU has to move around and the slower it will be. But a good video mode in 8 bit chunky with a 256 color palette should give good performances.

Sounds interesting! Any more info on that ? I mean even a medium resolution with 256 colours would be awesome even by itself. I guess 640x400x256 would be good, though of course going to need a lot of CPU power to drive it. The falcon struggles with 256 colours, but its a crippled 030 in there. With proper 32 bit SRAM and 50mhz 030, it would be a pretty powerful setup.

[Gunstick]

my idea was more to the way of how X-windows works. The CPU is not doing anything to display on the graphics card. It sends the VDI calls through the DMA to the rPi which then does the rendering.
This will of course not be suitable for programs doing heavy photo editing.
One could be crazy and run hatari in a high resolution on the rPi (does hatari support that?) and just funnel the 68K Trap calls through DMA
Then no graphics card driver is needed, VDI is running on both sides. Hatari does the conversion to the HDMI resolution.

On a side note, I had the reverse idea, run a modern browser on the rPi, and transmit with VNC the rPi screen to the ST so you can "surf" using the ST but the ST is only displaying. Just for the fun of it. It not really makes sense to use it.

[rpineau]

@Gunstick : I totally understand what your intention is. And it would work for all text windows drawn via the VDI. But if you need to display a picture you still need to send the full bitmap ove the RPI (with palette info if needed).
So as you say, photo editing or even just viewing would be slow (web browsing, ....).
I'm not saying your idea is bad, just that there are some overhead.

@exxos : I have an iCe40 dev board but I haven't had time to dig into this. I agree that a 640x400x256 would be nice. The current VHDL code can go to 1024x768 in 16 bit I believe (need to re-read the code). It doesn't have a palette mode but that doesn't mean it's not doable. Then we need a driver (probably using fVDI would be our best bet at this point). This is all in the state of "I'm looking into it but haven't done anything" as I need to finish the 68020 V3 board (PCB have arrived), fix my 2 broken MSTE V2, write the interrupt controller code for the V3 , .... but yea .. one day

Rodolphe

[keli]

The FPGA idea is something that interests me.

A similar thing has been done on the Amiga 2000 with the VA2000 FPGA graphics card, which is based on a Xilinx Spartan FPGA plus 5V tolerant buffers and a SDRAM chip.

The entire project is open sourced on Github, so it should be possible to create a custom firmware that talks directly to the M68000 bus instead of the Zorro II expansion bus the card currently does. The Zorro II extension bus is basically a buffered superset of the M68000 bus with some auto configuration added to it. Looking at the HDL sources for the card, I can see it even doesn't use too much of the added features of the Zorro II bus (apart from autoconf, and autodetecting whether it is in a Zorro III slot, which is quite a bit different.)

I even considered creating a simple Mega ST expansion bus to Zorro II slot adapter with the bare minimum to get the graphics card working.

And then there is the question of drivers. That would of course have to be solved. I think I would be able to write at least a proof of concept FVDI driver. Having said that, NVDI seems to be more popular despite no longer being actively developed. Does anyone have any documentation resources available on creating screen drivers for NVDI?

[rpineau]

that's a great idea.
As for NVDI, I think that's the issue.. no docs that I know of.
fVDI is probably the best options for now.

Rodolphe

[tuxie]

I would suggest to wait until the Apollo Team has published the SAGA core files for the SAGA Project, the SAGA is very fast and there is already an optimized driver..