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!