New Project: DoubleVision SE/30 Card

[Oliver_A]

Hello Mac community,

since I have gotten my first actual Macintosh last month (LC475), I must admit that the "Mac Bug" has bitten me, which is why I have now also pushed the trigger on getting a Macintosh SE/30 yesterday.

In order to have fun with it, I decided to port one of my other Amiga projects to the SE/30, therefore, I would like to announce today that I have started to develop a new graphics card for the SE/30 called:

DoubleVision SE/30

Technically, it is very much a Macintosh port of my Amiga graphics card, the P-Vision, but with some Mac SE/30 specific feature enhancements.

So what can it do? Well, here is the feature List:

• HDMI video plug using DVI video signalling
• 32MB VRAM framebuffer, clocked at 165MHz
• Supports 1bit,2bit,4-bit,8bit,15bit,16,bit and 32bit color depths
• All standard VGA and MAC resolutions, supporting up to 1280x1024@60p AND 1920x1080@30p
• Fast 64-bit BitBlt engine, pushing up to 130 Mio Pix/s (8bpp)
• 32 KB internal ROM for graphics drivers
• Firmware can be fully upgraded on the host system (via "FlashFPGA App" running on MacOS)
• Special MAC SE/30 features:
  • Card can work in dual-mode (second monitor to the SE/30 internal monitor) or route the SE/30 internal video output to HDMI
  • If MAC is booted, and no HDMI is connected, framebuffer memory is added as 32 MB system memory
  • Eleborate write-through cache to minimise read/write latency to VRAM
  • Makes full use of 68030 2-cycle 32-bit synchronous bus termination - yielding up to 32MB/s host memory performance using 16MHz bus!

I have seen that MAC SE/30 graphics cards using old and outdated graphics chips fetch high prices on the collector's market, so here is my offer to the community to provide a much more modern and better solution.

The card itself is low-profile and it has an internal HDMI port, which can be put outside of the SE/30 via a small bracket.

As I said, most of the development is already done, as the designs works great on the Amiga, therefore I expect that the most challenging part for me is to write the graphics ROM driver for the MAC in order to enable the display output. I have already started to look into this direction. ;-)

So for now, let's start with a first render of the board PCB, which I expect will be nearly identical to the final PCB.



As always, questions, comments, etc are always welcome.

 

[zefrenchtoon]

If only this would be also compatible with IIsi and A/UX ...

 

[Melkhior]

Dedicated chip(s) for video and/or acceleration, or are you using a FPGA for everything ? The rendering show quite a small chips for a FPGA (... but then I went a bit overkill I could probably get two Full HD output if I really wanted to... ).

@zigzagjoe has a SE.30 video board with a dedicated chip, the 30Color.

My IIsiFPGA is targeted at the IIsi; should work in a SE/30 but it might not physically fit. You can find the source code for the DeclROM in the VintageBusFPGA repository on GitHub. So is the firmware for the custom VexRISCV core used for acceleration. The acceleration INIT and the audio driver (when using the PHY with 'true' HDMI signalling, instead of the DVI-like PHY - though this last one supports many hardware resolution via PLL reconfiguring while the 'true' one is just one hardware resolution + windowbonxing) is in the NuBusFPGA repo. Maybe it can help getting you started with the software (... mine is GPL BTW).

Acceleration is the PITA part. You need to hack into QuickDraw in a very ad-hoc fashion, peeking and poking in memory... it's not pretty. That's why I only did blitting, when the hardware could theoretically do all of it (it's just a CPU and some C code!), same as the 8*24GC board did.

Edit: forgot to say, there's also a Rom patch for the IIsi to add an extra memory bank to use the FPGA spare memory as extra RAM. Testing an additional 240 MiB of RAM at boot takes a loooooong time.

 

[cheesestraws]

If only this would be also compatible with IIsi and A/UX ...

If the driver is well-behaved it ought to be, at least under A/UX 3. A/UX 3 runs the mac display driver in a kind of demented cradle, lying to it frantically to try to stop it realising it's not running under MacOS. Note though that this is not the same demented cradle that other bits of Mac software run in (that's demented in a rather different way) so things like anything patched in an INIT won't work. The driver will have to be self-contained, as it should be.

 

[Oliver_A]

Dedicated chip(s) for video and/or acceleration, or are you using a FPGA for everything ? The rendering show quite a small chips for a FPGA (... but then I went a bit overkill I could probably get two Full HD output if I really wanted to... ).

@zigzagjoe has a SE.30 video board with a dedicated chip, the 30Color.

As with all my projects, they are FPGA based. Inside the FPGA, I'm using a full 64-bit datapath for everything, and a highly pipelined memory transaction arbiter, controller, display engine and BitBlt engine.

Even without using the BitBlt engine, at least on Amiga, the design is fully usable even using an 68EC020 CPU at 14.3MHz using 8-bit color depth at 1920x1080. I expect that at least the same can be achieved on a stock SE/30, or even better using the full 32-bit synchronous data path.

My IIsiFPGA is targeted at the IIsi; should work in a SE/30 but it might not physically fit. You can find the source code for the DeclROM in the VintageBusFPGA repository on GitHub. So is the firmware for the custom VexRISCV core used for acceleration. The acceleration INIT and the audio driver (when using the PHY with 'true' HDMI signalling, instead of the DVI-like PHY - though this last one supports many hardware resolution via PLL reconfiguring while the 'true' one is just one hardware resolution + windowbonxing) is in the NuBusFPGA repo. Maybe it can help getting you started with the software (... mine is GPL BTW).

Wow, thanks a lot! I have started to read the "Designing Cards and Drivers for the Macintosh Family" guide, and have seen that there is actually exaple code for a skeleton graphics driver present there.

Acceleration is the PITA part. You need to hack into QuickDraw in a very ad-hoc fashion, peeking and poking in memory... it's not pretty. That's why I only did blitting, when the hardware could theoretically do all of it (it's just a CPU and some C code!), same as the 8*24GC board did.

It's actually very much the same on the Amiga as well. The OS provides hardware acceleration functions for the Amiga Blitter in the "graphics.library", but no interfaces to defer the functions to a different rendering target. That's why, in the 90's, several frameworks were developed to add this missing layer, which Commodore did not get around to implement. And it works really well!

Edit: forgot to say, there's also a Rom patch for the IIsi to add an extra memory bank to use the FPGA spare memory as extra RAM. Testing an additional 240 MiB of RAM at boot takes a loooooong time.

I can imagine, luckily, my card provides only 32MB of VRAM.

Thanks for your help!

 

[Melkhior]

As with all my projects, they are FPGA based

Hehe, me too. Much more fun to be able to fix/update/improve/extend the design even after the hardware is done

.Inside the FPGA, I'm using a full 64-bit datapath for everything, and a highly pipelined memory transaction arbiter, controller, display engine and BitBlt engine.

Neat. Is it purely for your own stuff or di you open-source it ?
My design is less efficient - it's essentially a CPU-less soft-SoC using Litex, with a bridge from the original bus (SBus originally, then NuBus, '030 and '040). Main bus is just a 100 MHz Wishbone, and the peripherals are mostly from Litex (e.g. the memory controller is LiteDram). I hadn't done any hardware before the original SBusFPGA, Litex was the reason I was able to do some "sophisticated" stuff.
The original accelerator was going through the Wishbone, but I eventually implemented a dedicated 128-bit bus from the VexRISCV D-cache to the LiteDram arbiter. Probably overkill - i meant to try NaxRISCV as the accelerator, but last time I looked it was still a bit too feature-rich (my version of the VexRISCV is really just a glorified micro-controller with some custom instructions to better support X11 acceleration including XRender and unaligned blitting in QuickDraw).

Even without using the BitBlt engine, at least on Amiga, the design is fully usable even using an 68EC020 CPU at 14.3MHz using 8-bit color depth at 1920x1080. I expect that at least the same can be achieved on a stock SE/30, or even better using the full 32-bit synchronous data path.

1920x1080 is OK on '030 in 8-bits or less on e.g. a IIsi, or anything with a NuBus slot (which is the bottleneck), but not fast. 32-bits is too slow without acceleration, and even with acceleration it's not super comfortable (I should so more acceleration...). It's much better on the QuadraFPGA where the FPGA connects directly to the '040 bus - BW and latency are almost good enough, and with acceleration it's usable even in 32-bits. Also fine on SBus using EXA/XRender on my SPARCstation 20 (on my incredibly large back-burner, there is supporting USB and accelerated X11 in NetBSD/mac68k...).

Though truth be told, unless doing vintage Photoshop, there's not mych reason for 32-bits on vintage Macs. If I had the skill for the PCB, I'd have a go at a much cheaper version with a Spartan-7 (instead of the Artix-7) with 1024x768/32, 1280x1024/16 and 1920x1080/8 as the targets. But designing the DDR[23] interface is too complex, and Spartan-7 aren't really designed to support single-sided (read: assembled for cheap by JLCPCB!) board with their decoupling requirements :-( But then I guess it's no longer a problem as you're about to fill that niche anyway

Wow, thanks a lot! I have started to read the "Designing Cards and Drivers for the Macintosh Family" guide, and have seen that there is actually exaple code for a skeleton graphics driver present there.

The example code is ... a starting point :-/ I had a lot of trial-and-error to figure out how everything worked in various OSes, and the godsend for me was QEmu. I just hacked a version of QEmu with could emulate a Q800 to create a model of my (unaccelerated) device, and developed the ROM on that. It helped a *lot*.

It's actually very much the same on the Amiga as well. The OS provides hardware acceleration functions for the Amiga Blitter in the "graphics.library", but no interfaces to defer the functions to a different rendering target

Even if not perfect, that sounds a bit more comfortable than the horror that is QuickDraw acceleration :-/ There's no provision for acceleration at all up to at least MacOS 8, and the functions you can substitute for (by gijacking the traps...) are quite high-level. I highly recommend sorting out all the dumb framebuffer stuff before even thinking about acceleration... it's a really deep rabbit hole to get into.