• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Development of Nubus graphics card outputting to HDMI?

Trash80toHP_Mini

NIGHT STALKER
Indeed, wholeheartedly agree. There is already a thread for that. I simply requested he keep that resolution in mind during current development. ;)
 

Trash80toHP_Mini

NIGHT STALKER
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...
Again, yes, tired, very clumsily tried to make sure technical objections, suggestions or further discussion not tangent bomb this thread. :)

Not flogging the 2018 thread, linking to ensure no further discussion goes on in this one. Mac Portable Video: Where to tap the source?
 

Melkhior

Well-known member
Hello,
Just a picture of this last week-end rework (GitHub might be a bit out-of-date sorry). Larger CPLD to handle separated R/W lines on the open collector lines (discussion in another forum) using 74LVTs, some extra LEDs to visualize some of the CPLD<->FPGA signals, regular NuBus bracket support.nubus-to-ztex-3d-view.jpg
 

demik

Well-known member
Nice !

Looks like you had fun with differential PCB lines. Is it needed at theses frequencies ?
 

Melkhior

Well-known member
Looks like you had fun with differential PCB lines. Is it needed at theses frequencies ?
It might be for HDMI, at least that's the suggestion - data and clock lines are running at more than 1 Gbit/s there when you push the resolution to Full HD (which in fact is technically beyond the capability of the FPGA using regular I/O, lower resolution might be more realistic; it's theoretically possible for an Artix-7 to output 4K HDMI using the GTP pins and some signal translation magic but I've not found a reference design and my FPGA board doesn't have GTP anyway).
For VGA, it's probably overkill to tune all data lines, you only need 148.5 MHz for standard Full HD, but I don't know how the DAC behave so...
Also, NuBus board are quite large, might as well use the real estate :) (that lower left corner around the CPLD is quite crowded though).
 

Melkhior

Well-known member
Random notes:
(a) There's a version of Qemu that can be used to emulate a Quadra 800 ; it has enough NuBus support to plug a 'virtual' card with a DeclROM and use it in the emulated MacOS; that was enough for me to be able to generate a seemingly usable DeclROM for a 'dumb' framebuffer (of fixed resolution / fixed depth) that works in System 7.1, System 7.5.3 and MacOS 8.1 in Qemu (generated in Linux using Retro68 and tools from ns816-declrom)
(b) The software for vintage accelerated cards from the likes of Radius and RasterOps is available online, can can be studied/disassembled using MacOS tools like Super ResEdit or Resorcerer to see what was done back in the day, and in particular which A-traps were patched by the CDEV to (probably) implement acceleration; many of those A-traps are not documented by Apple (presumably for internal use only)
(c) There's a much more comprehensive list of A-traps in the source code of some Mac emulators
(d) The same list, in a less readable form but with the full implementation of every traps is available online in the form of the entire ROM source code. Some of the A-traps are used very deep for highly specific cases; e.g. 0xAB59 is called to do a right-to-left scrolling (rectangle copy, really) with the 'bLEFT0' quasi-function. Implementing some specific traps might be a better starting point that the full bottleneck functions (StdBits does a lot of different stuff, 'bLEFT0' is very simple) to add acceleration to a NuBus display device.
(e) Hardware cursor are usable on PCI PowerMacs, but it seems the related selectors are never used on 8.1/68k, so hardware cursor is probably not an option (shame on you Apple, the hardware support was available from higher-end Brooktree devices back then, could have offered the option to HW developers)

So it seems on the SW side there's enough stuff available online to actually get somewhere once the hardware is sorted out.
 

demik

Well-known member
Nice work ! I wonder if the other traps are documented somewhere in the released QuickDraw source code.
 

Melkhior

Well-known member
Nice work ! I wonder if the other traps are documented somewhere in the released QuickDraw source code.
If by 'released' you mean the stuff Apple sent to a museum, then no, that's only for the original QuickDraw, which is much simpler.

But the published ROM code I linked to contains a full 32-bits QuickDraw, with all the then-current traps. Whether the non-public/non-documented traps were stable between releases is an open question - it's perfectly possible older implementation of QD32 uses a different set of private traps, or the same one but with a different interface/call convention...
 

Melkhior

Well-known member
Honestly, patching QD not through the bottleneck routines sounds like a recipe for pain and compatibility issues to me.
Patching QD through the bottleneck routines means re-implementing them, and they can be very versatile so it's a huge job. The 8*24GC did that, but it seems some other accelerators didn't and merely accelerated some of the most common cases through the internal traps. E.g. the 'QCOD' resources in Radius QuickColor starts with a table of trap numbers/code offset, and there's a lot of internal traps in there if I interpret the resource correctly.
Also, people doing a for-profit NuBus device in 1987 hopefully cared about compatibility issues. People wondering if they should try to do their own for-fun NuBus device in 2022 only care about one version of the OS running on one model of machine :) And software on reconfigurable hardware can be done piecemeal, starting small and building up (although with Qemu's Q800 being as good as it is, it should be possible to build a full virtual model there before touching any hardware, but it's not as fun as messing with the 'real thing').
 

demik

Well-known member
If by 'released' you mean the stuff Apple sent to a museum, then no, that's only for the original QuickDraw, which is much simpler.

But the published ROM code I linked to contains a full 32-bits QuickDraw, with all the then-current traps.

Alright thanks. The museum code was the one I was referring to. Interesting that you can test that with QEMU right now. Should be handy to test Declaration ROMs !
 

Melkhior

Well-known member
Alright thanks. The museum code was the one I was referring to. Interesting that you can test that with QEMU right now. Should be handy to test Declaration ROMs !
Indeed ; I have now a working declaration rom for the simple case thanks to QEMU (so fixed resolution, 8-bits only), with embedded drivers supporting 7.1/7.5.3/8.1. I was able to test it with up to 5 extra screen in Qemu - not that it's usable. But with one extra screen of 1600x900 set as the primary, Qemu is the best SimCity 2000 platform I know :)
 

Melkhior

Well-known member
Very, very cool. Are you running QUEMU under LINUX (what distro) or Windows?
Linux - on my test machine running Debian 10. It's much faster than a real '040 even with a remote X11 display on my desktop, using a Xeon core (which tends to have lower frequency than their desktop counterpart) and storage on spinning rust (couple of SAS drives in a ZFS mirror).
 

Melkhior

Well-known member
@Johnnya101 If you're asking about my own design, sort of; the current status is:
(a) software: I have a good environment to develop in Linux, and a DeclRom that works to add a secondary 8-bits color, single-resolution framebuffer in 7/8 under Qemu;
(b) gateware: NuBus seems to pass simulation for slave r/w transaction (enough for a framebuffer), and the framebuffer device now has support for depth switching (1/2/4/8/24 bits), this is being tested in the SBusFPGA but should be directly usable in NuBusFPGA;
(c) hardware: I haven't found issues of late, just need to get some test boards from SeeeedStudio to see if it will talk to the host or not...

Even if it works, the per-unit cost will be unreasonably high :-(
 

Johnnya101

Well-known member
What's unreasonably high? You may be able to get 10-20 units sold at a high price...

We talking $500? $1000? More? I think $500 would be doable. $1000, you could still sell a few I'm sure. You've got to remember current prices on the top end cards are pretty much close to that $500 mark, on ebay at least. I'd rather splurge for a brand new card that does HDMI and plays nice with new monitors than buy an old card.

I may have missed it, and I'm sure it's buried in this thread somewhere, but what exactly would this card provide? I know HDMI... But it would be more than a stock Toby card could do I would hope. Would this be a super high end type of video card with lots of memory and capable of doing higher resolutions (1xxx by 7xx+) at millions of colors?

You also mentioned that it was a "wide" card in a past reply (to myself!). Did you mean long, like a stock Mac II card?
 

Melkhior

Well-known member
What's unreasonably high? You may be able to get 10-20 units sold at a high price...
Probably in the $500-$600 range per units between the carrier and daughterboard. But it's a toy project at the moment, I have not definite plan to make some for sales - but it will be (is) open-source.
I may have missed it, and I'm sure it's buried in this thread somewhere, but what exactly would this card provide? I know HDMI... But it would be more than a stock Toby card could do I would hope. Would this be a super high end type of video card with lots of memory and capable of doing higher resolutions (1xxx by 7xx+) at millions of colors?
The current HW design has connectors for HDMI, VGA, and USB - however getting a USB stack working in MacOS is highly unlikely, it's there because it's small and not very expensive and can help with some testing. All peripherals would live in the FPGA, so you could have additional features in there, including e.g. video acceleration (provided one can get some software support working!).
As for resolution, it the design works, the FPGA should be able to do 1920x1080 on either output - but probably less if trying to create a dual-head configuration (as the memory bandwidth available will become a bottleneck; with 256 MiB on the daughterboard space is not an issue, in the SBusFPGA the balance of memory is used to create a memory-based disk for e.g. swap or /tmp in NetBSD).
You also mentioned that it was a "wide" card in a past reply (to myself!). Did you mean long, like a stock Mac II card?
No, thick, as it's two cards in parallel separated by the 2.54mm (.1") headers. So it will likely take over 2 or maybe even 3 NuBus slots when plugged in. In length it's pretty much as short as it can be (ends right after the NuBus connector), and slightly less high than a full-size NuBus card.
 

Johnnya101

Well-known member
Probably in the $500-$600 range per units between the carrier and daughterboard. But it's a toy project at the moment, I have not definite plan to make some for sales - but it will be (is) open-source.

The current HW design has connectors for HDMI, VGA, and USB - however getting a USB stack working in MacOS is highly unlikely, it's there because it's small and not very expensive and can help with some testing. All peripherals would live in the FPGA, so you could have additional features in there, including e.g. video acceleration (provided one can get some software support working!).
As for resolution, it the design works, the FPGA should be able to do 1920x1080 on either output - but probably less if trying to create a dual-head configuration (as the memory bandwidth available will become a bottleneck; with 256 MiB on the daughterboard space is not an issue, in the SBusFPGA the balance of memory is used to create a memory-based disk for e.g. swap or /tmp in NetBSD).

No, thick, as it's two cards in parallel separated by the 2.54mm (.1") headers. So it will likely take over 2 or maybe even 3 NuBus slots when plugged in. In length it's pretty much as short as it can be (ends right after the NuBus connector), and slightly less high than a full-size NuBus card.
Impressive. Could call it a FatMak video card :)

I would be down for spending that much on one. Heck, I'd buy a couple. One to use, and one as trading gold on here.

You could always just do a small initial batch of cards just to make yourself a bit of money for your time spent on this. Like 5-10 cards. Don't have to continuously keep making them, just do a few.

Your target audience would vary depending on 2 vs 3 boards. With 2, I think you would be pretty much open to all nubus Macs? With 3, it would be more like the II series, bigger Quadras like the 950, etc, but would depend if the user wanted a nubus ethernet card.
 
Top