• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Development of Nubus graphics card outputting to HDMI?

trag

Well-known member
Personally interesting, on page 16 at the beginning of the driver text it suggests that the XCEED SE/306-48 is a Micron XCEED Color 30.   Is that correct, or are there multiple products that map to one or both of those identifiers?

It is interesting to me because I have an XCEED SE/306-48 in my inventory, but I thought that I had confirmed years ago that it is not one of the cards compatible with the internal Grey scale assembly.  And I only have the card.  I don't have any video connector for it.  I think I got it either from a bin at Goodwill or in a large lot of video cards on Ebay a couple of decades ago.

I've seen these docs before and there's a lot of good information there.   

The good is that this gives one a basic framework of how to build a video card and fills in a lot of details that might otherwise be tedious or impossible to work out.  

The bad is that the internals of the main chip, Mavericks and the two ((?) GALs are not described in detail.   Also, it will take a lot of work to make use of the aforementioned details, even though they are present.

Still, knowing what a video card does, and understanding how the Mac sends frame buffer data (two tasks by themselves) and understanding how VRAM works, it should be possible to deduce what Mavericks and the GALs must be doing.

 

trag

Well-known member
Oh, one detail which may get overlooked, which I think is cool, is how interleaving  is used to improve performance.

On the host (PDS) side, incoming words get interleaved amongst multiple banks of VRAM.   So if the card has four banks, and the card receives 16 words, the words get written thusly:

Bank1:  1

Bank2: 2

Bank3: 3

Bank4: 4

Bank1:  5

Bank2: 6

Bank3: 7

Bank4: 8

Bank1:  9

Bank2: 10

Bank3:  11

Bank4: 12

Bank1:  13

Bank2: 14

Bank3: 15

Bank4:  16

Then when it's time to stream to the Output buffer (monitor side), all the banks can be made to output more or less in the same clock cycle, yielding 128 bits of video data in a single cycle.     Which cuts down the time that the VRAM is unavailable for frame buffer updates from the host.

That's not exactly what XCEED did, but it's the basic idea.

 

Bolle

Well-known member
on page 16 at the beginning of the driver text it suggests that the XCEED SE/306-48 is a Micron XCEED Color 30.
They probably just re-used some of the code.

They are different cards. The SE/306-48 doesn’t do internal gs and it also isn’t based on Mav/Goose. It’s using a few PALs/GALs for bus interfacing. There is another document flying around somewhere that lists all the equations.

 

balrog

Member
Looking at the schematic on the last page of the PDF, specifically the lower right hand corner:
J1 10PINPWRCON is the connection to the internal greyscale board

U12 IH5341 is the switch that controls whether built-in SE/30 monochrome or graphics card greyscale is used

The internal greyscale signal comes from the IOB line, which originates from the Bt478 RAMDAC. (family datasheet: http://www.citylan.it/wiki/images/9/90/Bt471.pdf) The IOB line is the Blue RGB channel that also goes to the external monitor output.

So basically — everything is pretty much the same as a standard graphics card (that is able to output at roughly 512x342), with the blue channel used for internal greyscale, and a switch IC used to switch back to monochrome when an external monitor is used.

There are some other lines going to that connector for sync but I don't think there's anything terribly special about them. Would need to see the schematic of the CRT neck board to know for sure.

 
Last edited by a moderator:

trag

Well-known member
Thank you, Bolle.   What is gs?  Oh, gray scale.  Morning brain.  Thanks.

 
Last edited by a moderator:

danpoarch

Well-known member
On the Micron Xceed docs:

I've reviewed some of the code in the .sit file and while I know a little Moto assembly from school, most of what's happening would require a lot more analysis to understand. However a couple things are crystal clear, the files in the includes list are not included in the .sit file [price is right loser sound]. Bummer, but there's still a sh!t-ton of things that can be figured out.

MAV (that we now know is Maverick) can be seen on the FPGA(?) on the Macro Color boards that have the 369-010 part number that matches some of these files. The FPGA part on the MacroColor boards with part number 390-010 has a different name GAM. Interesting. These, with the GAM, must be later boards. But... in another thread JDW has a side-by-side shot of an Xceed that I would expect to be an older board but it has the GAM label. Point being, maybe it's just a later revision that's backwards compatible(?). These boards are so confusing as far as specs and naming so I have no idea.

Just picked one up off of eBay with the GAM label with no grayscale adapter so I'll be interested to see what I find out. I may actually dive into ROM dumping the GAL that's on there. Have to find a ROM reader on eBay first, and having gone down this rabbit once before, that's not an easy expedition.

NUBUS:

Hard to find many pictures of the equivalent Micron NUBUS cards but perhaps the vector processor chips (MAV, GAM) on the NUBUS cards are cross compatible with the 030, but not the other way around. Hard to tell from the wording of the MAV/GOOSE section of the tech docs.

There's a lot here to be picked apart. If we have a ROM and a map of how the vector processor works, perhaps we can use the existing Xceed drivers to get a basic video board off the ground and then build up from there.

 

uyjulian

Well-known member
I think it would be nice to start up emulating the Toby graphics card, since it should be compatible with most software including A/UX.

About QuickDraw acceleration: What about emulating 68k code? It can possibly be quite a bit faster with little effort compared to reimplementing QuickDraw, and it could also work for other types of graphic drawing code like QuickDraw 3D or OpenGL.

 

Melkhior

Well-known member
Hello,

I was wondering if there were already some hardware and/or software resulting from discussion on this thread?

I've been thinking about rolling my own NuBus display board, based on the same idea as a previous project of mine, the SBusFPGA, an expansion board for my 90's SPARCstations. Basically I would just do a NuBus-compliant carrier board with an existing FPGA daughterboard (reusing the same daughterboard as for the SBusFPGA), with just level shifters and I/O interfaces on the carrier.

Everything is implemented in a single not-too-small FPGA to simplify development. In the SBusFPGA, all the code is now based on a cpu-less Litex SoC; it enables the board to offer a USB 1.1 port (OHCI-compliant), a micro-sd card slot, and a 256-MiB RAM disk in the FPGA board SDRAM, plus some non-I/O stuff (True RNG, draft crypto acceleration). I have also prototyped clones of a couple of Sun framebuffer (unaccelerated cg3 and accelerated cg6 with hardware cursor, acceleration is implemented by C microcode running on a customized VexRiscv core). The number of pins available on the SBusFPGA to implement the VGA output is too small (just 2 bits per color), so it's just a proof-of-concept.

For the NuBusFPGA, I was thinking of a couple of video outputs with full color support, VGA and HDMI (VGA I'm confident the FPGA daughterboard can handle, HDMI I'm not so sure due to more stringent requirements on routing, trace length, ...). I'll also keep the USB plug as it only takes 2 pins, but I doubt OS 8.1 for 68k has an OHCI driver (NetBSD/mac68k could probably use it more easily). First goal would be to get a dumb 640x480 framebuffer working with one output, then build up on that to get larger display and perhaps even some level of acceleration (and dual-head, but the SDRAM bandwidth won't be enough to support more than ~2.5-3Mpixels in 24/32bits). As NuBus is a bit annoying in its specifications (falling edge trigger, grr), the interface would reuse available Verilog code and interface to Litex' wishbone bus. Preliminary Vivado simulations seem to work, I can read a simulated Litex ROM from the bus through Wishbone and read/write the Led control register.

Beyond making sure I've understood NuBus enough that the board won't fry the host (Quadra 650 for me), the primary issue is the software. Trying to write a declaration ROM with MPW is not easy, and I have no clue about the driver yet even for the dumbest of dumb framebuffer (single resolution, single depth, ...).

Here's a screenshot of my latest draft design as seen by Kicad's 3D view (unfortunately all interesting connectors are missing 3D shapes, sorry):nubus-to-ztex-3d-view.jpg
 

LaPorta

Well-known member
I would like to see a NuBus graphics card that just outputs to a standard VGA port with multiple resolutions so that I can use more recent (2000s) LCDs without adapters, refresh rate issues, etc.
 

Johnnya101

Well-known member
I would like to see a NuBus graphics card that just outputs to a standard VGA port with multiple resolutions so that I can use more recent (2000s) LCDs without adapters, refresh rate issues, etc.
Same here, could always get a VGA to HDMI adapter. I'd love a new Radius Thunder style card with VGA, and would happily pay $100-$200. The old square monitors are VGA anyways.
 

LaPorta

Well-known member
Same here, could always get a VGA to HDMI adapter. I'd love a new Radius Thunder style card with VGA, and would happily pay $100-$200. The old square monitors are VGA anyways.

Exactly. I can get Dell, etc, nice 4x3 monitors for $10 at Goodwill, and, although they work, there's always some kind of finicky issue and its never quite just right.
 

demik

Well-known member
Beyond making sure I've understood NuBus enough that the board won't fry the host (Quadra 650 for me), the primary issue is the software. Trying to write a declaration ROM with MPW is not easy, and I have no clue about the driver yet even for the dumbest of dumb framebuffer (single resolution, single depth, ...).

Here's a screenshot of my latest draft design as seen by Kicad's 3D view (unfortunately all interesting connectors are missing 3D shapes, sorry):

Welcome to the forums. That's quite a good design. Following this !

Where is the declaration ROM on your board ?

I'm no help for NuBus as it's making my brain hurt, but read a few declaration ROMs around. I would argue that it's easier to write a declroms by hand with a hex editor than with MPW.

bbraun has made a few good tools to deal with declaration roms and a good article here

If it help, I gathered a few ROMs (some dumped by @Bolle ) on my github if you want to take a look. Some are xored with 1, like the Toby one (you need to invert all the bits)

Color and most grayscale boards are more complex because you have to deal with a CLUT for QuickDraw as well. I think you can run a fixed CLUT for grayscale like some PowerBooks, but don't quote me on that.

Maybe starting with a black and white board declaration ROM will be easier ? The Formac ProNitron GA2 is a CLUT-less 1024x768 B&W board. It should only have a few IO spaces : declaration ROM, programming the TMS which you can ignore, and the actual framebuffer.

Hope this is useful !
 

cheesestraws

Well-known member
Trying to write a declaration ROM with MPW is not easy, and I have no clue about the driver yet even for the dumbest of dumb framebuffer (single resolution, single depth, ...).

I'd suggest using a more modern development environment than MPW: CodeWarrior Pro is my personal poison for writing code. bbraun's tools are useful too. Have you got a copy of Designing Cards and Drivers? That has a 'worked example' video card that might be a good start if you haven't...
 

Melkhior

Well-known member
I'd love a new Radius Thunder style card with VGA, and would happily pay $100-$200
Unfortunately, the FPGA daughterboard is already near the top of that range... and the carrier can easily double the price if made in prototype quantity (2-3). Batches of a couple dozens are much, much cheaper per-unit but you need to test a prototype first - and then I doubt there will be demand for that many expensive, excessively wide (won't fit in some cases I suspect) new boards for utterly obsolete hardware.
Like the SBusFPGA it will be FOSH/FOSS (but probably not before I'm confident it won't fry the host...) so anyone will be able to make them if they really want to.
Where is the declaration ROM on your board ?
As a virtual ROM inside the FPGA, not dedicated hardware (and yes, those 3 lines of Python take care of that!). Theoretically, it could be in a file in the configuration Flash RAM (where the bitstream of the FPGA lives for power-up configuration), but I've never tried that. For SBusFPGA it's just some Forth for OpenBoot (later to become OpenFirmware, known to PPC Mac users) and that doesn't take much space so no need to worry about resource consumption.
I'm no help for NuBus as it's making my brain hurt, but read a few declaration ROMs around. I would argue that it's easier to write a declroms by hand with a hex editor than with MPW.
Seeing the end result, it would appear so - at least when there's no driver. But a driver might be needed, if just to configure the CLUT as discussed below. And I never did 68k assembly back in the day, either.
bbraun has made a few good tools to deal with declaration roms and a good article here
If it help, I gathered a few ROMs (some dumped by @Bolle ) on my github if you want to take a look. Some are xored with 1, like the Toby one (you need to invert all the bits)
Thanks for the pointers! Some I knew, but I hadn't found your GitHub. Examples are always good.
Color and most grayscale boards are more complex because you have to deal with a CLUT for QuickDraw as well. I think you can run a fixed CLUT for grayscale like some PowerBooks, but don't quote me on that.
Maybe starting with a black and white board declaration ROM will be easier ? The Formac ProNitron GA2 is a CLUT-less 1024x768 B&W board. It should only have a few IO spaces : declaration ROM, programming the TMS which you can ignore, and the actual framebuffer.
I haven't tried to reconfigure the Litex FB in B&W yet, but it's an idea. Original FB was 32(24) bits only; added 16-bits (trivial) and 8-bits which is harder because of the extra look-ups (and then some more for the hardware cursor, but we're not there yet). Theoretically 1-bit should be easy as well; just not sure whether/how Litex can/will handle the 128->1 bits stream conversion (the DDR3 controller has a 128 bits interface...).
In principle updating the CLUT by SW can be easy, either by direct byte/word update (exposing 768/1024 bytes in the address space), or by address/value (which is how the cg3 and cg6 operate). The question is, how to tell MacOS to call a specific function to do the update...
Doing 16 or 32(24) bits is also easy (no CLUT!), but there's not enough space in the "minor slot" in 24-bits mode, except perhaps for 640x480/16 which is only 600 KiB of FB. But then you need to tell where the R/G/B components are...
I'll definitely take a look at the GA2 ROM. Now that you mentioned it, B&W might be the easiest way at first for SW.
I'd suggest using a more modern development environment than MPW: CodeWarrior Pro is my personal poison for writing code. bbraun's tools are useful too. Have you got a copy of Designing Cards and Drivers? That has a 'worked example' video card that might be a good start if you haven't...
I also installed CWPro 2 and 4, might have to go back further as some headers changed for assembly at some points - maybe my old CDs still work :)
I believe I do have all the relevant Apple documents, at least the entire Inside Macintosh collection & the 3 variants of the Designing stuff that are now available on the Web.
 

Trash80toHP_Mini

NIGHT STALKER
So glad you found this thread, I'd meant to link it for you in your original thread.

IIRC, the books documenting the Macintosh II Frame Buffer Card (Toby) design example can be found here:
Macintosh Repository

Each version of DCaDftMF builds upon the original Designing Cards and Drivers for the Macintosh II and SE manual. Following editions expressly state a full understanding of previous versions is assumed as well as other related manuals. IIRC the most comprehensive detailing of Toby is in the third edition as it had gone out of production when the manual was published and so unavailable to developers.

Lots of tangential wish lists involved, including a couple of my own that will go unmentioned.
 

cheesestraws

Well-known member
I believe I do have all the relevant Apple documents, at least the entire Inside Macintosh collection & the 3 variants of the Designing stuff that are now available on the Web.

Good! The Toby worked example chapter in C&D isn't perfect but I found helped understanding. The other thing that may be of use to you is that the source code for both the ROM and the disk-loaded driver for the BUG Pickles surfaced recently—the BUG Pickles being a high-end for the time accelerated NuBus video card. The designer came and sent us lots of wonderful stuff, and as far as I know, this is the only complete example out there. Downloads and discussion here:

 

demik

Well-known member
As a virtual ROM inside the FPGA, not dedicated hardware (and yes, those 3 lines of Python take care of that!). Theoretically, it could be in a file in the configuration Flash RAM (where the bitstream of the FPGA lives for power-up configuration), but I've never tried that. For SBusFPGA it's just some Forth for OpenBoot (later to become OpenFirmware, known to PPC Mac users) and that doesn't take much space so no need to worry about resource consumption.

Seeing the end result, it would appear so - at least when there's no driver. But a driver might be needed, if just to configure the CLUT as discussed below. And I never did 68k assembly back in the day, either.

That's clever. Didn't think of the DDR limitations, that will be interesting.

I agree a driver is needed at some point, that was just for "let's start with something really dumb" and add features later.
Speaking of really dump, here is a disassembly of the SE/30 video ROM by @GeekDot, which is one of the simplest ever:

https://github.com/axelmuhr/Carrera040/blob/master/se30vrom.asm

Does anyone have a dump of the Macintosh II Monochrome Video Card by any chance ?
 

Trash80toHP_Mini

NIGHT STALKER
As LEM says: Why anyone would want to use one of these is beyond me.

There could be one very good application for reverse engineering it, but that's a very special case. Tweak its output just so and it might be able to drive the well documented Portable B&W LCD @640x400. No RAMDAC complications for analog output like VGA for that interface. Just TTL to TTL logic customized for that LCD alongside HDMI's all digital implementation.

I'll not rest until I find someone to figure out how to drive the Portable's LCD from an 030 PDS, but that's tangential here at best. :rolleyes:
 

uyjulian

Well-known member
The Toby card might be the easiest to get up and running.

You may want to also see about cloning the Macintosh Display Card 8•24 card.
If you write new drivers, you would need to write them for each OS like MacOS, Linux, A/UX, NetBSD etc.

I think it would be nice to "genericize" the protocol if a new driver is written so that it can go over SCSI also.
 

Trash80toHP_Mini

NIGHT STALKER
The Toby card might be the easiest to get up and running.
Indeed, I've been nagging @Bolle about this approach for years now. ;) However that Macintosh II Monochrome Video Card is likely a dumbed down Toby, possibly with the same ROM and drivers? If doesn't use Toby's socketed PGA ASIC, it likely would be able to employ it in limited fashion.

@Bolle Isn't there a fully documented PDS card in the Xceed family and another fully documented example from Germany(?) that might for another design example candidate?

Caffeine deprivation is killin' me ATM. :oops:
 

Melkhior

Well-known member
the source code for both the ROM and the disk-loaded driver for the BUG Pickles surfaced recently—the BUG Pickles being a high-end for the time accelerated NuBus video card. The designer came and sent us lots of wonderful stuff, and as far as I know, this is the only complete example out there. Downloads and discussion here:
Awesome, thanks for the link!
 
Top