Development of Nubus graphics card outputting to HDMI?

[demik]

Easier to just go for 4 layers Also the cost of the PCB is sort of dwarfed by the cost of assembly and parts. One of the argument in favor of a resistor ladder for VGA is the 12.50€ list price (quantity of 1) at Mouser for the DAC chip... I didn't realize until I added it how expensive analog chips are. The CPLD is only 2.70€ if you get the fastest one (probably not needed, but not much more expensive than the slowest).

XC7A35 on the FPGA board I have, though they are available with the 50/75/100 as well. But a 35 is more than enough unless adding an heavy-duty crypto engine and/or a lot of acceleration to the framebuffer (even a 35 fit my custom VexRiscv core for the SBusFPGA's cg6 easily, if the crypto core is not present).

The 'fan' header is sort of just-in-case; some SPARCstation have borderline cooling (the 10 is famous for its overheating issue when fully kitted, the quad-CPU version was announced but never delivered because of that), and the stacked design of the SBusFPGA blocks airflow so I added a 5V fan header ; I figure it could be useful in a Mac as well. It could also be used if some NuBus signals needs a missing pull-up/down. The 3.3V/GND header is also there for emergency pull-up/down. I should also add some testing points to make using a logic analyzer easier, but I'm not sure where / how - and the 2.54" header to the FPGA board does give some reasonable level of accesses to its signals; ditto the large NuBus DIN connector.

... now that you've mentioned the fan, makes me think I should check how much power the 12V line offers, a 12V fan header could be useful as well (the 12V line on SBus is very limited in power). There's room on that board, might as well take advantage of it

Indeed. The DIP-44 was kinda a joke . Yeah a 12V fan header may be nice if there is enough current supply for hit, plus maybe you can PWM it with a softcore or something.

As for looking at NuBus signals, you can use the slot next to your board for emergency, besides the IRQ one, all pins should be common IIRC.

 

[Trash80toHP_Mini]

I think you've got that almost right, each slot has a unique hardwired hex identifier, but it's four lines for 16 IDs of which the Mac only uses $9-$E for NuBus. $9, the first slot is somewhat unique:



As I understand it, there's no unique /IRQ line as you'd have in a PDS implementation.



References are from baseline DCaDftMacintosh II and SE. Thought I'd document for folks following along.

I'll guess you're sticking with a simple Slave Mode card to avoid the complications of Bus Mastering implementation?

You can achieve QuickDraw Acceleration by using an accelerated, Bus Mastering VidCard like the Macintosh Display Card 8•24 GC in another slot if you implement 32bit slave NuBus Block Transfers, but you may not want to add that complication for prototyping?

Great fun to watch your progress!

 

[NJRoadfan]

Easier to just go for 4 layers Also the cost of the PCB is sort of dwarfed by the cost of assembly and parts. One of the argument in favor of a resistor ladder for VGA is the 12.50€ list price (quantity of 1) at Mouser for the DAC chip... I didn't realize until I added it how expensive analog chips are. The CPLD is only 2.70€ if you get the fastest one (probably not needed, but not much more expensive than the slowest).

I wouldn't even bother with VGA output. The whole point of the project is a card that natively outputs a digital signal. If someone wants to hook up a CRT, a cheapo HDMI-to-VGA adapter will do the trick. No need to add complexity to the project.

 

[ronan]

I wouldn't even bother with VGA output. The whole point of the project is a card that natively outputs a digital signal. If someone wants to hook up a CRT, a cheapo HDMI-to-VGA adapter will do the trick. No need to add complexity to the project.

Agree with that

 

[Trash80toHP_Mini]

Agree for the most part, but it's VGA->HDMI that's inexpensive, no? The other way is difficult to even search due to the proliferation of Analog->Digital cheapos in my experience. Anybody got a good search string for narrowing hits to HDMI Digital->Analog VGA converters?

Besides, adding a RAMDAC for VGA shouldn't be much of a problem, no? Maybe for a second rev?

What are you planning to use for drivers?

 

[NJRoadfan]

Amazon has dozens of HDMI-to-VGA adapters. I have one here that was $10 that I use with the RetroTINK and OSSC. Going from digital-to-analog is generally the easy direction. Just make sure the HDMI port on the finished card has sufficient amperage on pin 18 (+5V) to run such adapters.

 

[uyjulian]

Instead of VGA probably add an additional HDMI port instead for multi display output. Leave the DAC to be external

 

[Trash80toHP_Mini]

Might have gotten that backwards, thanks. I use VGA->HDMI converter that requires USB power input, nice to see that these don't require external power. Thanks!

 

[LaPorta]

If we get decent output, I don't care what the signal is!

 

[uyjulian]

Might have gotten that backwards, thanks. I use VGA->HDMI converter that requires USB power input, nice to see that these don't require external power. Thanks!

If HDMI pin 18 is correctly implemented it can supply +5V power to the HDMI to VGA converter without external power supply.
For the opposite, I don't really think there is enough voltage supplied by many cards. It's probably enough for reading the EEPROM information on the display with DDC and that's it.

 

[Melkhior]

When it comes to VGA and HDMI, the goal is redundancy - having both makes it likelier at least one of them will be functional hardware-wise.

I'll guess you're sticking with a simple Slave Mode card to avoid the complications of Bus Mastering implementation?

Right now the only thing not connected is the NuBus90 2x clock (and associated tm2 control signal), so there's no current known limit to implementing bus mastering in the FPGA design. However, I've not implemented it in my early verilog/migen draft design because it's not required for a video output device. (I probably still need to worry about interrupt because of VBL...).

You can achieve QuickDraw Acceleration by using an accelerated, Bus Mastering VidCard like the Macintosh Display Card 8•24 GC in another slot if you implement 32bit slave NuBus Block Transfers, but you may not want to add that complication for prototyping?

Just read about the 8*24 GC and the fact it was using an Am29k - never knew that Couldn't afford those back in the days. The cg6 acceleration I have for SBusFPGA is coincidentally very similar, but with a VexRiscv instead of Am29k.

The nice thing about using a FPGA is that you don't have to limit yourselves to what is working at first; you can add features later.
If made, early goals for the board would be:
(a) testing the video output(s) stand-alone (not inside a Mac), using a regular Litex SoC and the serial port as console;
(b) testing the NuBus interface by having a minimalist embedded Declaration ROM and driver to control the LEDs.
If (a) doesn't work then (b) can still be tested, but the board is much less useful - if (b) doesn't work, the card is expensive scrap.
if (b) works, then the Mac can read/write to hardware registers in the Wishbone space through NuBus. At that point, the problem becomes software; you can add Wishbone devices (such as a framebuffer) in the FPGA and give access to them through the NuBus-Wishbone bridge, but you still need a Resource in and driver for them in the Declaration ROM. Adding acceleration in that case would work the same; the on-board DDR3 can be accessed by a device through Wishbone or a native LiteDram interface, the hard part is writing the software...

 

[Melkhior]

In case anyone wants to have a closer look, I've pushed the current draft to https://github.com/rdolbeau/NuBusFPGA.
The Kicad project should be complete; the gateware may have some hidden dependencies (files from SBusFPGA, my local version of XiBus, modifications to Litex that I forgot to push, also I'm using a not-up-to-date version of Litex) - no intent to hide anything, I just didn't clean things up.

 

[ArmorAlley]

I'd honestly be happy with just a cheap VGA 1024x768 NuBus card myself. I don't have any CRTs that can do the wacky higher resolutions anyway.

I'd be happy with NuBus cards that play nicely with 1024x768 @ 60Hz LCD monitors with VGA or DVI outputs. They don't necessarily have to be cheap. Something that allows older Macs to use less old hardware would be great.
If they could help obviate the need for an expensive (and increaingly unobtanium) ADB KVM, that would also a big bonus.

 

[Trash80toHP_Mini]

Very cool stuff, Melkhior. Thanks for the in depth info and development strategy logic statement.

. . . but you still need a Resource in and driver for them in the Declaration ROM. Adding acceleration in that case would work the same; the on-board DDR3 can be accessed by a device through Wishbone or a native LiteDram interface, the hard part is writing the software...

Sounds like going for a Toby clone in FPGA would be the logical first step in testing. Completing that design example with its well documented Hardware/DECLROM/Driver development tools is something for which the gang might enlist for assistance while you're focused on the hardware side?

Fleshing out Apple's disjointed documentation of the Macintosh Frame Buffer as a complete, comprehensible manual would be useful for many in and of itself I think. I'd certainly enjoy having that tome available if only for educational purposes.

Parlaying that foundation into a more capable version would be your second iteration and then adapting Toby or jumping into one of the more complex, high resolution examples available like BUG Pickles would be a natural progression?

 

[Melkhior]

Sounds like going for a Toby clone in FPGA would be the logical first step in testing. Completing that design example with its well documented Hardware/DECLROM/Driver development tools is something for which the gang might enlist for assistance while you're focused on the hardware side?

For the Sun cg6 (a.k.a. GX / TurboGX), I went for cloning as there was a lot of documentation; not only there were some historical open-source drivers in X11, but the chips were made by a third-party (LSI) and the design was cloned by multiple companies; a couple years ago the original Sun documents on the architecture surfaced on bitsavers. And the Forth PROM can be disassembled to the original Forth easily (it's almost a one-to-one conversion between the language and the bytecode, you only lose some clarity on loop structure).

To fully clone Toby (i.e. being able to reuse the binary ROM and driver with no changes), one would need to know the exact addresses and behavior of the various hardware registers, the behavior of the interrupt line, and whether timings are important to the driver - the embedded DDR3 can have spike in latency, e.g. if a request arrives during a refresh cycle; that might be a deal-breaker for an exact clone. Also the link you posted says "up to 7.6.1" and I'm running 8.1 (joking, I could install an older system easily of course, I put a MacSD in the Q650).

It might be easier to create a new ROM/driver based on Toby, but without the constraint of replicating the hardware exactly. It will be needed to go beyond 640x480 anyway.

Parlaying that foundation into a more capable version would be your second iteration and then adapting Toby or jumping into one of the more complex, high resolution examples available like BUG Pickles would be a natural progression?

It would be, and hardware-wise no change would be required; only the FPGA gateware (and maybe CPLD) will need to evolve to support extra functions, that's the beauty of an FPGA. it's also why the software is the big sticking point - you need the same amount of work today to write the software that would have been needed back then, but with only volunteer work and a lot less knowledge floating around. On the other hand, designing and implementing hardware has become extraordinarily easier; VHDL only became a standard the year of the MacII and Xilinx was founded during the Mac 512k era. The speed at which we can design (and have built) SMD PCBs would have been mind-boggling back then - I did my own Mac-to-VGA adapter because it was cheaper to make a couple than buying one second-hand...

Back to NuBusFPGA; should a first version of the board work fully (i.e. NuBus, VGA, HDMI, USB all working at HW level), the only reason to re-spin it would be to change some critical parameters; one might be total cost. Cheaper FPGA and memory directly on the board for instance to be full-custom; there's a Spartan 7 board Kicad design from an eevblog forum member that could almost, but not quite, be a good basis; the 196-pins S7 doesn't have quite enough I/O for both DDR2 and talking to NuBus (only 100, DDR2 takes a full bank). But an Artix-7 in the FTG256 package *might* be doable on 4 layers by an experienced PCB designer (read: not me) and with 170 pins could certainly do the job - and is available in 15/35/50/75/100 flavors; the 15 might be enough for a basic framebuffer while the 100 could likely fit enough hardware to out-perform every vintage board.

Of course the ultimate solution doesn't involve a FPGA at all - after all the Skywater 130nm mixed-signal process whose PDK is open source now supports 5V I/O, so it doesn't even need those annoying level shifters. And we could get Google to pay for it . Mostly kidding, as the work needed to get a working chip with support for the required memory would be huge. Mostly...

 

[Trash80toHP_Mini]

It would be, and hardware-wise no change would be required; only the FPGA gateware (and maybe CPLD) will need to evolve to support extra functions, that's the beauty of an FPGA. it's also why the software is the big sticking point - you need the same amount of work today to write the software that would have been needed back then, but with only volunteer work and a lot less knowledge floating around.

That's why I'm still harping on Toby as a first step. With Apple's documentation tied up with a ribbon in a PDF with the missing parts list completed that would really be something! We'd have a great primer for volunteers (obviously above my pay grade!) to get their feet wet and then jump into the fray.

As you said, current hardware looks great for hooking PDS/NuBus under Slot Manager architecture I/O up to it these days. Firmware, Drivers and Control Panel development is likely some members might wish to get involved with in this quest. Apples examples and tools don't give a full enough picture for me to see anyway.

N.B. This looks like a great point for someone to start up a related, dedicated or general DCaD development wish list discussion here in hacks.

 

[Melkhior]

To fully clone Toby (i.e. being able to reuse the binary ROM and driver with no changes), one would need to know the exact addresses and behavior of the various hardware registers, the behavior of the interrupt line, and whether timings are important to the driver

It seems the nice folks over at MAME have done the job already for their own need: https://github.com/mamedev/mame/blob/master/src/devices/bus/nubus/nubus_m2video.cpp.
The Bt453 is AFAICT a low-end version of the silicon used by Sun in the cg3/cg6 (lower frequency, no hardware cursor), so should be easy. The memory map seems complete in the MAME code. The two issues remaining are (a) the VBL handling, which doesn't exist yet and (b) mode switching, currently my emulated RAMDAC is fixed-depth only.

 

[Trash80toHP_Mini]

Wonderful, when did you discover that gem? If you delve further into that and prototype along those lines I've a request. Could you take some notes on how it might be simplified so as to output 640x400 for driving the Portable's LCD? Single bit only required, though hardwiring 8bit would "suffice" for that Prototyping effort, very much if and when.

edit: to avoid the obvious objections. Project would be a much reconfigured SE/30 based replacement in the Luggable MoBo's form factor.

 

[Melkhior]

Wonderful, when did you discover that gem?

About 5 minutes before posting about it Emulators for period software are often a good source of information.

If you delve further into that and prototype along those lines I've a request. Could you take some notes on how it might be simplified so as to output 640x400 for driving the Portable's LCD?

The issue is the signaling; it the screen doesn't take VGA-like signals, then a new implementation is needed. If it does take VGA-like signals, then 640x400 instead of 640x480 is a trivial change given the proper timings.

 

[cheesestraws]

Yes: I'd suggest not getting sidetracked down the lines of the Portable LCD. It's either going to be trivial or painful, and there's not much in the middle, and either way it won't be of much use to many people because the Portable doesn't have NuBus, so it'll only be for people who want to do hacks...