Jump to content
dlv

Development of Nubus graphics card outputting to HDMI?

Recommended Posts

9 hours ago, Gorgonops said:

Yeah... and after reading that  .  .  .

Reading what? MooshBrain mode had me neglecting to say that the "extended documentation" on the Macintosh II Video Card (TOBY?) was in DCaDftMF3e. The screencaps I posted wer from DCaDftMIIaMSE with a reference to dri9ver development in Chapter 9 of same.

 

Took a quick gander at both and it looks to me that all video mode settings are stored in DeclROM along with drivers for anything necessary. The Mac side consists of only the Monitors Control Panel remembering which video mode was last chosen and booting the system into that mode in single bit for Happy/Sad machine state indication before System/Drivers ever begin to load from disk. Presumably with a default setting of 640x480 for any worthwhile card at whatever silly frequency and 60Hz in the case of the proposed new development card.

 

Quote

.  .  .  I realized that, wait, any video card beyond an extremely simple fixed-function framebuffer would probably require at least a bare minimum of driver code to initialize the video chipset; the registers for programming CRTC functions are not standardized by any stretch of the imagination, so unless the card was hardwired to come up in a usable video mode *and* there was no reason to ever switch modes then, yes, you'll need a driver to handle that.(*)

The driver setup for any mode would reside in DeclROM per above with the Monitors Control Panel handling any mode switching. It looks like the only real purpose of coding an INIT for a card is to override whatever resides in DeclROM that may have become obsolescent.

 

This jibes with all my long experience with VidCards, NuBus and PDS. I've never NEEDED to load a driver to get basic function, most of the time at all resolutions/bit depth settings listed as available for any given VidCard. I'm sure a few exceptions have slipped through the cracks in my slowly crumbling mind, but the observation stands as a good rule of thumb.

 

Looking forward to having Volumes IV and V of Inside Macintosh arrive next week to confuse the crap outta me with info on driver coding. 8-o

 

< beats head on KBD in frustratiohn >

 

sad;lagjn;lrkg;oaerht;kjearhtk;jwe4ht;iowhaerfo[u3q4['otij34qlktn;qk34th;q3i4io;hg2q34jr'q23jh4rthq

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
1 hour ago, Trash80toHP_Mini said:

driver setup for any mode would reside in DeclROM per above with the Monitors Control Panel handling any mode switching. It looks like the only real purpose of coding an INIT for a card is to override whatever resides in DeclROM that may have become obsolescent.

Read the section you quoted carefully. It's pretty clear that there is, on a typical card,  a "driver" stored in the declaration ROM, along with initialization code. There's not much to this driver, but it's there to translate the "generic" mode setting API calls made by the system control panels, et al, to the actual register tickling that has to happen to program the video hardware to display the requested mode. As I noted in my previous "oh yeah" post this makes sense: different video hardware might use radically different methods. To do without some kind of driver code (ie, make initialization/modesetting at boot completely a high-level message passing affair) you'd basically have to put an embedded CPU on every card.

 

Roughly speaking this is the equivalent of the BIOS code there is on PC video cards from EGA onward that handles initialization and mode settings, it's not a "driver" in the "Windows driver" sense. (Or the "extension loaded from disk that enables enhanced functionality in the control panels or acceleration or whatever" sense.) On a typical card I doubt it took more than a few K in ROM. Quickdraw defines what the actual video modes need to look like and how they're manipulated so none of that is in the "driver" in the declaration ROM. All the driver does is program the raw registers to set up the field.

Share this post


Link to post
Share on other sites
9 hours ago, Gorgonops said:

It's pretty clear that there is, on a typical card,  a "driver" stored in the declaration ROM, along with initialization code. There's not much to this driver, but it's there to translate the "generic" mode setting API calls made by the system control panels, et al, to the actual register tickling that has to happen to program the video hardware to display the requested mode.

 

That's what I thought I'd said: The DRIVERS for a video card as in "Cards and Drivers" reside in DeclROM to bring the card online, allowing ?Mac machine state indication before disk access for loading the OS begins. Was that a comms error between us or am I missing something here?

 

Whatever "drivers" shipped on disk with the card set it up for special features via extensions a/o a provide a customized Control Panel replacement for the Monitors Control Panel.

 

I found a tidbit about VidCard Driver/INIT loaded at boot's ability to usurp function of the DRIVER in DeclROM to be interesting and possibly a handy development tool. Once a basic setup for implementing that is coded, up and working it might make tweaking DRIVER development possible w/o the need for removing and burning a new ROM for the card with each iteration. Might not be necessary if provision for updating an EEPROM on the development board via USB or the like would be better, Dunno about that stuff, but I thought I'd mention it. The latter would be better in terms of adding/tweaking display mode options in DeclROM, assuming that might not be possible to do from the host Mac?

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
18 minutes ago, Trash80toHP_Mini said:

Was that a comms error between us or am I missing something here?

I think it's that, because I interpreted your second post as a claim that you *didn't* need a "driver" (in the context of executable code on the card) right after I'd convinced myself that in most cases at least you probably did. (The edge case of a strictly single-mode fixed function framebuffer like that in the SE/30, which does have a declaration ROM and otherwise masquerades as a Nubus video card, is one possible exception.) Apparently you thought I meant drivers on a disk.

 

The reason I was turning this over in my head is I was pondering the possibility of, for an initial stab at developing an FPGA-based card, if one could start with something just as dumb as the SE/30, IE, say an 800x480 1-bit monochrome fixed framebuffer. This would require less than 64k of RAM, I'm pretty sure some relatively cheap FPGAs could handle this without external memory. A card like this would likewise need only a *very* minimal declaration ROM, my question was 'how minimal'?

Share this post


Link to post
Share on other sites
59 minutes ago, Gorgonops said:

The reason I was turning this over in my head is I was pondering the possibility of, for an initial stab at developing an FPGA-based card, if one could start with something just as dumb as the SE/30, IE, say an 800x480 1-bit monochrome fixed framebuffer. This would require less than 64k of RAM, I'm pretty sure some relatively cheap FPGAs could handle this without external memory. A card like this would likewise need only a *very* minimal declaration ROM, my question was 'how minimal'?

That sounds like a great Idea for a first run at this thing, baby steps. :approve: Since we don't need to use Apple's physical design guidelines we could get by with a generic adapter to PDS and smaller form factor carrier dev boards.

 

FitmentTrial.JPG

 

The mockup above was meant to have a PDS connector on the solder side for an outrigger development board plugged in thru the opening in the SE/30 chassis. Substitute a PCI connector for EuroDIN120 and all carrier revisions remain within the 10x10 SEEED square and are easily swapped out. Header/socket thruholes below the PCI connector would allow breadboarding a first rev "PCI" carrier board for the much shorter edge card connector. Keep the breadboard connector thruholes configured for EuroDIN120 and late model, much larger standalone carrier boards using those more expensive connectors would be handily installed/removed as well. A short run of adapter boards could be used through the entire development process.

 

edit: moving development boards onto 'PCI" was planned for major reduction in cost of development.

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

Anything interesting or even progress to report from anywhere on this? Volume IV of Inside Macintosh with its "relevant information" arrived today, but the meat of the matter is in the "indispensable" Volume V waiting for me at the rental office for pickup Monday morning.

Share this post


Link to post
Share on other sites

Not a whole lot from me. Work has been demanding a lot of my time as deadlines approach.

 

The FPGA and USB programmer arrived last week but I need to source a 5V power supply to begin playing with it. In the meantime, I've been learning about TMDS encoding (used in DVI/HDMI/DisplayPort) and following through its implementation in the VA2000 project. I also began drafting a schematic of the daughter board but need to better understand 68030 PDS in order to understand how best to wire it to the FPGA. Towards that end I've been making (slow) progress reading through DCaDftMF3e and Spartan 6 documentation.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×