Jump to content

Development of Nubus graphics card outputting to HDMI?

Recommended Posts

  • Replies 185
  • Created
  • Last Reply

Top Posters In This Topic

1 hour ago, balrog said:

Hope this makes for useful information!

It is excellent how that manual has a lot of the declaration ROM code in it, along with some descriptions about how the ROM, VRAM, and I/O spaces are broken up over the Nubus slot space. (Yes, it's a PDS card, but it's following the slot manager conventions.) In theory I suppose it's mostly what's in the Toby documentation in the Apple manual, but it still might help fill in some of the gray areas.

Link to post
Share on other sites
  • 68kMLA Supporter

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.


Link to post
Share on other sites
  • 68kMLA Supporter

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.

Link to post
Share on other sites
  • 68kMLA Supporter
6 hours ago, trag said:

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.

Link to post
Share on other sites

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.

Edited by balrog
added datasheet
Link to post
Share on other sites
  • 1 month later...

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.



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.

Link to post
Share on other sites
  • 2 months later...

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.



Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...