Thank you all for the discussion so far.
Developing a new VidCard would be the a fabulous project. That Amiga blog is very interesting and the FPGA board very promising. Dunno where we were talking about it but I suggested going straight to HDMI rather than bother with finding and interfacing VRAM with a RAMDAC to get analog video out. Looks like everything needed to do it is right there on that board outside of bus buffering and multiplexing on his carrier card.
You mean, interfacing with the VRAM built into the motherboard (or whatever)? I doubt Nubus/PDS has enough bandwidth to pull the contents of VRAM at any usable frame rate. A FPGA board providing its own frame buffer to the system and outputting the video signal independently is definitely the way to go.
Unfortunately, it looks like the miniSpartan6+ FPGA board used in the VA2000 project is no longer sold which is too bad because, from what I've gathered, it was particularly well suited for this type of application (and relatively cheap).
There are some boards (DE10-Nano, Zynq-7010/7020) that appear to be suitable (HDMI port, enough digital I/O pins, enough RAM, NVM to hold ROM) but these provide ARM cores that, from what I've gathered, share the memory on these devices and are therefore not suitable for low latency applications. Some projects (MiSTer for the DE10-Nano
https://github.com/MiSTer-devel/Hardware_MiSTer) have gotten around that limitation by attaching memory to the I/O pins. My recollection from skimming through documentation is that 56 pins are required in Apple's Nubus, which rules out the DE10-Nano, for example, because half of the 80 I/O pins available on that board would be used by the SDRAM daughter board. I haven't looked more closely at the Zynq-7010/7020 but I suspect it has the same problem.
With 32MB of SDRAM on that FPGA board, 1080p, Dual Head 720p or even Dual Head 1080p might be in the ballpark?
I suppose it's a possibility provided the FPGA has enough bandwidth.
To be honest, once you get to higher resolutions I think the classic MacOS experience degrades quite a bit, especially what can be powered by nubus/68k machines. Lots of picking the mouse up multiple times to get across the screen, and many apps/games either not being designed for those resolutions or too slow to run on this era hardware.
I agree. I think 1080p is probably the upper limit and there are still likely to be some issues, as you've pointed out.
Here is an interesting project for interfacing a Raspberry Pi to a simple eight or sixteen bit bus so it can act as a video card. Unfortunately the repository seems to be incomplete; there's some source code for the FIFO board (which is the really interesting part and it's on my to-do list to see if I can wrap my head around it) and a debug listener but no trace of the actual render code that I can see. Alas the whole thing appears to have been abandoned; I was really curious to see if he'd implemented a linear framebuffer in the graphics core (which is what you'd need for a Mac video card) or if it was implemented entirely as a display list processor. (IE, essentially something more along the lines of a TI 9918/A.) Still, even if it's of no real use as a graphics engine the idea of tacking a FIFO buffer on to let you snoop bus transactions without having to worry about exact timing could be super useful for other applications....
Nice find. It sounds like what the VA2000 is essentially doing, just... much slower. I'll check it out later.
Anyway. Strictly speaking a video card for a Nubus Mac should be a pretty low hanging fruit as long as you're happy with unaccelerated video (as it looks like that VA2000 card is). Macs require a linear framebuffer with "chunky" pixels (not planar like VGA modes higher than 320x200 originally were) for 8 bit-and-less color depths mapped into the Nubus slot space and, if I'm recalling the documentation in the book I downloaded off Archive.org at one point correctly, a *pretty* simple initialization ROM that just tells the Mac what modes the card supports and what bits to poke to select them. (There are some additional wrinkles, of course, such as how the bitmap will need to be able to map into both the 24 bit slot space and the 32 bit Superslot spaces, modes that require more than 1MB of RAM need special handling, etc, but I believe it *is* all documented.)
That's encouraging. I skimmed through the video card specific sections of the Nubus documentation the other night, and came largely to the same conclusion. I would be thrilled to have unaccelerated video; I think that would be a major accomplishment. Accelerated video can come later
Examples of FPGA video generator code are a dime a dozen so it's really all down to the Nubus interface code. Casual googling has yet to turn up for me an example of open FPGA/CPLD code for implementing Nubus but it may well be out there. (Don't forget you'll be needing some level converters too, given the lower I/O voltage of most modern FPGAs.)
Right, I think one of the main challenges will be either finding a Nubus implementation with permissive licensing, or implementing one from scratch. And yes, I saw a bunch of level converters in the VA2000's schematic.
A PDS card would indeed be somewhat simpler mainly because the 680x0 bus is more copiously documented.
Late at the end of the "PDS era" there were a few video cards made for LC PDS that used standard off-the-shelf VESA-bus VGA chips so, again, the requirements for actual video hardware itself are pretty loose. If it can do Chunky video with a linear frame buffer it'll probably work.
I'll look into it. One concern I have is whether a PDS graphics card can be used early enough in the boot process? There's a length discussion about that in the Nubus documentation for video cards.