What's on the other side of the NuBus glue IS a PDS card when you get right down to it. The Apple docs make it very clear that developing for the "newfangled" SE/30 PDS should be done in exactly the same manner as developing for NuBus. DeclROM/Drivers and "Card" can be grafted onto the NuBus easily with the Slot Manager handling the interfaces as if the same thing. I see working up the intermediary interface glue as an unnecessary concern until there's something proven to be working on the card end of the NuBus gimmickry.
Sort of feel like a broken record at this point, but here it is again:
this entire project (almost) is about the "intermediary interface glue". Basic non-accelerated Macintosh video cards are *extremely* straightforward devices; they're arrays of RAM with the pixels arranged in a linear, contiguous fashion and the pixel format is well documented. (it's
packed-pixel "chunky".)
Here is a project that implements the equivalent of a "Toby", IE, 640x480x256, using a single 144 macrocell CPLD. (And not just that, it can do widescreen 848x480 too, and it also handles 16, 4, and 2 color bit depths, all of which are interesting for smoke testing a Mac video solution, and although I'm not going to say this with 100% certainty my broad skimming of the docs suggests it uses the correct memory mapping, or at least very close.) Obviously this example isn't directly what we want for the final solution, but the reason I'm pointing it out is that this design implements a "Toby" in less than 1/10th the gates that are available in the FPGA the OP wants to use for this project.
Making a "video card" to stick behind the bus glue isn't the challenge here, the bus glue is. (And the Declaration ROM contents, but at least that is copiously documented.)
As to "what is on the other side of the NuBus glue being a PDS card", that might be broadly true (though not really) when you're talking about discrete electronics, but it's not true if we're talking about an FPGA. When you're done designing the video portion of your FPGA video card you're not going to be standing there literally holding a bunch of wires in your hands that directly correspond to the address and data bus of a Motorola 680x0 CPU, you're going to have a structure that essentially consists of a black box with some "holes" in it that stuff like data transactions and addresses need to come in and out of, and you need to build the bridge between those virtual holes and the I/O pins on the FPGA package. There is actually very little reason to think that building a 680x0 bus arbitrator is going to be inherently easier than a NuBus one other than you're significantly more likely to find example code from someone who built it already. (For instance, the Amiga 2000-targeted video card the OP opened with; Zorro II is *mostly* just straight-up 68000 so it probably *isn't* that hard to convert it to 68030 PDS; since 68030 PDS supports bus-sizing you can even keep it a 16 bit card. 68040 is another story.)
There are two totally valid ways of tackling this project:
Strategy One: concentrate on implementing a Mac-compatible (in terms of internal memory layout) framebuffer that outputs via an HDMI port (IE, build it, load it onto the FPGA, and demonstrate it making pretty pictures based on the contents of VRAM that you populate by stuffing in bytes via SPI or a serial port)
first and
then tackling writing the bus glue for whatever bus you think is easiest and coming up with the needful declaration ROM contents to get the Mac to see your device as a video card at boot (note there's an intermediate step possible here where you get the glue working and test it by writing a simple driver program that "pokes" pictures into the card's video RAM without the Mac "knowing" about it.)
Strategy Two: do the opposite. Figure out how to handle the voltage conversion and whatever issues to get your FPGA sitting on the bus lines (again, whatever bus floats your boat) and write a bus arbitrator that maps some trivial device into the Nubus slot space. (Either the space assigned to your real Nubus slot or the psuedoslot space if you went PDS.) Bang together a simple program that lets you poke bytes into the FPGA and blink a light or whatever.
Then pick some halfway milestones, like mapping a chunk of RAM into that space as if it were a framebuffer and verify you can read and write to it reliably, and playing around with declaration ROMs. And then,
FINALLY, worry about making the contents of your RAM card drip out the back of the computer via HDMI.
What is leaving me scratching my head is what exactly is the strategy you're advocating for here. Frankly my opinion is that strategy two might broadly be the better idea, but if playing with video cards sounds like fun then there's no harm in strategy one... although, frankly, it looks to me like strategy one actually turns directly into two as soon as you're happy with your video architecture. It seems to me like you keep saying all the steps in strategy/part two will be magically
much easier with PDS and I don't think that really follows. Maybe I'm terribly wrong about that, but at best it seems to me we're probably talking about, I dunno, a few percentage points of effort plus or minus off the total project.
G, you snarked me pretty good yourself about that iterative learning thing. I snapped back at that without realizing I'd not made it clear that I thought Apple's card was a very dumb idea.
I apologize for the breach in civility. I'm not going to justify it, but I was simply getting a little annoyed at all the off-topic editorializing about all the stupid terrible things Apple did with Nubus and how it was totally unknowable and... etc. All I was attempting to point out in bringing up the mono card is that theoretically at least it's possible to set a *very* low bar for what counts as a "working" video card, and if the point is to actually complete this project (or at least encourage someone to try) setting the targets as close as possible
just might help grease the wheels. Therefore I'm not sure that all the negativity about Apple and comments about how hard and terrible and unknowable Nubus is are really that helpful.
] 
