Development of Nubus graphics card outputting to HDMI?

[Gorgonops]

Nope, if only 20 of the multiplexed lines are utilized for NuBus transactions from a card the others can be held at whatever state, they're null in both states. NuBus can also act in 16-bit mode if necessary, unless Apple borked that part of the spec as well.

Maybe you need to draw me a picture to explain what the heck you're talking about. If you're trying to share the same lines between the Nubus interface and VRAM refresh you'll need to have separate buffers isolating those lines from the bus most of the time, and video refresh is going to *stop* when you're handing the memory bus over to Nubus. Or are you trying to say something else?

Also, unless I misinterpreted what it was saying Apple's development docs actually seemed pretty explicit about saying that if you're interfacing a peripheral that's less than 32 bits wide you have to handle bus resizing on the card, the bus as implemented on the Nubus Macs is one size fits all. (I recall some specific verbage about the 68030's built-in bus sizing magic not applying to Nubus cards *and* that not being implemented natively on the bus itself.)

While DDR2 has a ton of latency, it runs crazy-fast compared to the old machines.   At 200/400 MHz, even if you need 6 cycles to execute a read or write, you can still get back to a 25MHz bus in one cycle with an acknowledge.   And that's ignoring buffered write schemes where you just immediately tell the  host it's done, while you finish the house keeping. 

I see the attraction of SRAM though.   It's a lot simpler.

Yes, the SRAM suggestion was mostly a suggestion for keeping as simple as possible if you decided to split the bus interface circuitry from the video refresh circuitry. (IE, using some PLDs or whatever for the Nubus/PDS glue "south" of the memory bank and an FPGA for the video generation.) Arbitration for that scheme would be pretty simple. But if you're going to let the FPGA do it all using the built in DRAM interface might totally work, expecially if you can set up some sort of FIFO buffering to handle the latency.

 

[dlv]

I think I found a cheap ($20) Chinese FPGA board on eBay that is comparable to the miniSpartan6+.

That's great news, inkage?

QMTECH's XC6SLX16 board available for sale from many vendors on eBay such as:

https://www.ebay.com/itm/XC6SLX16-Spartan-6-Xilinx-FPGA-Development-Board-w-Micro-SDRAM-Memory-32Mb/264229717341

You can find the schematics, documentation for the board and its components, and example code FPGA code, under their GitHub project for the board here:

https://github.com/ChinaQMTECH/QM_XC6SLX16_SDRAM

I chose this board because it is the closest to the miniSpartan6+ used in the VA2000 project:

• Xilinix Spartan 6 LX16 (the miniSpartan6+ came in either LX9 and LX25; specs say the LX16 is closer to the LX25)
  
• 32MB of SDRAM
  
• 108 user I/O pins
  
• SPI NVM for FPGA bitstream and ROM
  

For the proposes of this project, its only major shortcoming compared to the miniSpartan6+ is the lack of a built-in HDMI port but that could easily be provided by a carrier/daughter board. Of course, that means less than 108 I/O pins will be available for PDS/NuBus but there should still be enough?  There is a DDR2 version of this board but I want to reuse as much of the MNT VA2000 project as possible (including SDRAM controller code for the miniSpartan6+).

Anyway, I've been reading documentation of the three chips on the QMTECH board, understanding how it is all wired together, and comparing with the miniSpartan6+. The QMTECH board and Xilinx programmer are on their way. Baby steps... setup the development environment then see if I can program the board and blink some lights  

 

[Trash80toHP_Mini]

No. If data and address are multiplexed on Nubus then you'll need 32 lines for that function on Nubus, and *completely separately* you'll need data and address lines for your VRAM bank.

I was trying to ask if buffer and NuBus lines needed to be separate in figuring out how many lines mightpossibly be saved on the NuBus converted version.  The proposal I made for a 16-bit data/24-bit address, 24-bit color depth 720p LC VidCard development model (based on nic's card) has been  on my mind. It's an 020 PDS subset of the 32-bit IIsi/SE/30 PDS.

Maybe you need to draw me a picture to explain what the heck you're talking about. If you're trying to share the same lines between the Nubus interface and VRAM refresh you'll need to have separate buffers isolating those lines from the bus most of the time, and video refresh is going to *stop* when you're handing the memory bus over to Nubus. Or are you trying to say something else?

Nope, again, I'm not suggesting that.

Also, unless I misinterpreted what it was saying Apple's development docs actually seemed pretty explicit about saying that if you're interfacing a peripheral that's less than 32 bits wide you have to handle bus resizing on the card, the bus as implemented on the Nubus Macs is one size fits all. (I recall some specific verbage about the 68030's built-in bus sizing magic not applying to Nubus cards *and* that not being implemented natively on the bus itself.)

Not sure we're talking about the same thing. there was a mention of transfer modes in the BYTE article, but the CERN paper seems to be on point, it seems to do a good job of describing Apple's deviations from what became the IEEE 1196 Standard later in 1988.

______________________________________________________________________________________________________________________________________________________

p.18   Developing For The Macintosh NuBus-CERN-CM-P00062891

10.2 Non-aligned transfers

  

The NuBus interfaces of the Macintosh II family computers support all the non-alignment functionality of the 680X0 microprocessors. The interfaces generate multiple standard NuBus transactions with appropriate 680X0 dynamic bus sizing DSACK responses until the non-aligned access is completed. In addition to 680X0 longword accesses at odd addresses, non-aligned accesses are required for certain bit-field instructions which have 3-byte operands.

All non-aligned reads can be completed by a maximum of two NuBus transactions, since the additional bytes acquired by 32-bit word reads can be ignored by the processor. In the case of non-aligned writes however, up to three NuBus transactions may be required to split a 680X0 longword into component byte and halfword writes in the appropriate byte lanes. NuBus cards which can be accessed by non-aligned transfers must be able to support a full 32-bit read. In general, all RAM-like cards should support all NuBus data transfer types.

______________________________________________________________________________________________________________________________________________________

They stress the importance of 24-bit compatibility, Given the 16-bit data transaction limitation of LC PDS, The NuBus adaptation would need only handle 16 data bits using a couple less address bits than the 24 available in that transaction mode? So, is running the card/driver in 24-bit compatibility mode with a 16-bit data path a workable setup while the computer is running in 32-bit mode? Hope this makes some kind of sense? :blink:

On another note: there's no way a new NuBus VidCard will compete with the PDS version in terms of speed. Either the CERN paper or Byte article listed the maximum theoretical bandwidth limitations imposed by Apple's implementation of NuBus. It wasn't pretty.  Can't find it ATM, eyes are too tired. Can someone OCR those articles/Scan to PDF/whatever. Searchable text would be handy.

Anybody got a line on a source for Inside Macintosh Volume V?

 

[Gorgonops]

They stress the importance of 24-bit compatibility, Given the 16-bit data transaction limitation of LC PDS, The NuBus adaptation would need only handle 16 data bits using a couple less address bits than the 24 available in that transaction mode?

There are still two different things floating around in your head that are sort of irreconcilable. Yes, Nubus supports byte and halfword transfers. (And unaligned transfers, which on the Motorola 68k are a fact of life because even though the 68000 architecture was designed as a "32 bit" ISA the original implementations were effectively 16 bit CPUs (one variant of which actually had an 8-bit bus) and instructions can therefore be aligned "off" from 32 bit words. x86 has the same issue. So any bus for these systems needs to be able to handle the situation.) Here's the thing about Nubus, though: *by definition* it always uses 32 bit multiplexed data/address words. You can't run a "24 bit subset" of it even if your plan is to only land a 16 or 8 bit peripheral that only needs some subset of the address lines. "Unaligned data support" simply means that if a read/write is split on an awkward non-word border it's smart enough to do two bus cycles and use the correct byte lanes to complete the transaction, instead of just losing half the transaction.

Let's go crazy here and pretend that you're intending to stick something like a Motorola 6821 PIA on a Nubus card. This is an 8-bit chip that has two 8 bit parallel ports and two sets of control registers. This effectively means that on an 8-bit computer you need 2 "address lines" to select between the I/O ports and the control registers. (Obviously this does not include the address lines you need to decode the memory address at which the chip actually resides in the address space, but let's pretend we're doing this in something like an Apple II that has pre-decoded slots that give you a "this line is active if this card is supposed to be" line; I believe Nubus in the Mac also has this, which makes "simple" Nubus cards a little more straightforward to build than, say, ISA cards, which do have to have full address decode on them.) What that document is saying about "narrow cards" (which technically is a different issue from 'non-aligned transfers') is that, sure, with our incredibly brain-dead 8 bit card we can take some shortcuts and effectively not care about the upper 24 bits of data we get from *either* the address or data cycles of the multiplexed Nubus lines if we place the PIO's data lines on the correct side of a full 32 bit word and specify that when we're communicating with this chip we specifically address the parallel ports and registers on word boundaries. (IE, instead of the PIA occupying "32 bits worth" of memory address space it's going to occupy 128 bits.) This mechanism is explained on page 18 of that document you linked to, under the header "data byte placement". THESE SHORTCUTS SPECIFICALLY DON'T APPEAR TO APPLY TO RAM-LIKE CARDS, WHICH A VIDEO CARD IS.

Let's say you're sticking a video card with an 16 bit memory bus in a Nubus slot. You do not have the option of 32 bit word aligning a 16 bit RAM by declaring you're only using two of the four byte lanes, because that would effectively mean that every-other-halfword of the video buffer would be missing. Macintoshes expect packed linear framebuffers, and when they're doing a block copy, move, memory fill, whatever, they expect to treat the RAM on the video card just like it's main memory, IE, I can just copy this from here and splat it over there. I'm pretty sure this is where the comments about PDS having the advantage of working directly with the 68030's dynamic bus sizing mechanism come from in the Apple card development manuals; a Nubus card can declare in its declaration ROM that it's only 16 bits wide, which the Slot Manager will honor at initialization (IE, it'll know to do word-level hopscotch when reading the rest of the ROM and piece it together in RAM rather than trying to execute any code on it in place), but it doesn't actually flip any hardware bits that will automatically map full word writes to only use the two byte lanes you stuck your VRAM on, it'd be on you to write a unique video driver (and probably rewrite Quickdraw) to deal with your weird non-linear vide buffer. So unless there's something that says otherwise in the video card section it looks to me like that just flat out won't work, and if you want to have an 8 or 16 bit wide VRAM on a Nubus Mac you're going to have to do it by sticking a 32 bit buffer on the Nubus end and blocking the subwords into your narrow memory with additional cycles. This might not be a big deal if your VRAM can cycle massively faster than the Mac can (See Trag's comment about how fast the 16 bit DDR interface on some of these FPGAs can go), but this *does* pose a barrier to literally taking an LC-slot video card and adapting it to Nubus. Best case the card will run about half as if it were 32 bit, all else being equal.

I've gone through the Apple development documentation looking for more information about byte lanes and, again, I could be wrong but I don't any indication that declaring the card as "narrow" in the byte lanes specifier does *anything* other than affect how it handles the ROM (apparently even 32 bit cards like the Toby video card that's used as the video card example, and make no mistake, its VRAM is 32 bits wide, being composed of 8 or 16x 64kx4 RAM chips, might have an 8-bit declaration ROM). Every indication to me is that a RAM-like card (verses some sort of register/data port device) needs to be able to deal with 32 bit read/writes.
 

 

[Trash80toHP_Mini]

Nubus card can declare in its declaration ROM that it's only 8 bits wide, which the Slot Manager will honor (IE, it'll know to do word-level hopscotch when reading the rest of the ROM and piece it together in RAM rather than trying to execute any code on it in place), but it doesn't actually flip any hardware bits that will automatically map full word writes to only use the two byte lanes you stuck your VRAM on. So unless there's something that says otherwise in the video card section it looks to me like that

I'm thinking along the lines that though the card itself may "need to" field 32 bits of addressing for memory, the for that card can ignore that "requirement" in the hopes of finding more wriggle room for the decoding setup?

 

[Gorgonops]

I'm thinking along the lines that though the card itself may "need to" field 32 bits of addressing for memory, the for that card can ignore that "requirement" in the hopes of finding more wriggle room for the decoding setup?

No.

Here's where I think you're also a little confused: it feels like you think there's something "magical" about a "16 bit" card (like an LC PDS card) that can output 24 bit color, and that somehow matters to the CPU side interface bus. It matters *not in the slightest*. Only the output circuitry cares about 24 bit color, and the only aspect it cares about is that the backing store of RAM is fast enough to feed the output circuitry's (be that a DAC, a TDMS encoder, whatever) insatiable hunger for uninterrupted pixel data on a very strict timing schedule. The CPU interface bus could be a single-bit SPI bit-bang if that's all you have to work with, Honeybadger just don't care. The thing that kind of matters with Macs is the built-in video rendering system, Quickdraw, has specific ideas about what the framebuffer should look like logically to it, and it's actually a really simple requirement, IE, that the frame buffer appear to it as a continuous array of RAM with linear pixel arrangements, not some "weird" arrangement with bytes or words of VRAM scattered in non-linear chunks or weirdly interlaced, et al. (Which was actually really common back in the 80's.)

So, in a Mac, video RAM is "RAM", so a the constraint you face on the Mac side is the same as if you were making a RAM card. A "RAM Card" for 68030 can be 16 bit or, heck, even 8 bits wide, and it's completely a trivial affair because the 68030 has specific support for accessing narrower blocks of RAM exactly as if they were fully 32 bits wide; all you need to do is pull up a sizing line when the read or write is made and the CPU will happily and completely transparently-to-software do two or four bus cycles instead of one to read/write a 32 bit word into/out of a 16 or 8 bit wide block or RAM respectively. It's completely transparent, Honeybadger, IE, Quickdraw, just don't care, nor does it have to. The point about Nubus is that sizing mechanism is not in play, a RAM-like card has to at least fake being 32 bit.

Ironically this whole discussion is sort of pointless when you consider that Nubus actually just doesn't have that many lines, and depending on how we're intending to arrange our video card a Nubus version might require fewer FPGA I/O lines than PDS does. Nubus being multiplexed totally helps us here if we're planning to have the same FPGA handle the computer bus and the video RAM; The entirety of the 32 multiplexed data/address lines and all the control signals on a Nubus slot is only 51 pins, not counting grounds and power leads. For a 16 bit PDS video card with 4MB you're looking at at least 38-ish for just data and address, not counting any control lines *and* making the assumption that you can actually get away with partial address decode on PDS. (I'm not 100% sure on that? I though the PDS Macs all offered a slot enable signal that's lit up when the address range is inside some predefined slot area and thus you'll only need enough address lines for your VRAM range, but if I'm wrong about that then figure a full 48 bits for data/address.)

So, again, unless there's something I'm totally misunderstanding about this from page 95 of the 3rd edition "Designing Cards and Drivers blaw blaw":

In general, peer cards must be designed to support the maximum size of transfer that any of their peers are capable of supporting. In particular, a peer card that is designed to cooperate with the MC68020, MC68030, or Mc68040 microprocessor on the main logic board of a Macintosh computer must properly handle 32-bit (NuBus word) transfers. If such a card contains, for example, an Mc68000 and has a local bus that is naturally 16 bits wide, the card must provide the hardware support in its NuBus interface to handle such 32- bit transfers. This would involve doing two local bus cycles for each NuBus word request.

A card with an Mc68000 processor must make two NuBus halfword requests to satisfy an access to a NuBus word quantity (for example, a pointer value). A Macintosh computer properly responds to these two requests. The same instruction when executed by the MC68020, MC68030, or Mc68040 microprocessor makes one NuBus word request. If the card with the Mc68000 does not respond with the correct 32-bit quantity, the program obViously does not execute correctly.

You should clearly indicate in the card's documentation exactly which kind of card it is and what types of accesses it supports.

Memory devices, however, must support all transfer types except for block transfer; the devices should always respond with all 32 bits in the addressed NuBus word. This rule allows RAM cards to be used as if they were on-board RAM in order to support nonaligned transfers, 68020 bit-field instructions, 68030 caching, and so forth.

You are stuck. A Nubus video card needs to be 32 bit. Which may not be that huge of a deal when designing one from scratch, but is important if you're trying to adopt a 16 bit card for another bus.

 

[jessenator]

If this database information is correct, the University of Utah library has Volume V. I could check it out to be sure if you'd like. It's not far from me. If it's there I can make copies or scan select pages/sections.

 

[Trash80toHP_Mini]

Thanks, I was hoping !V and V were readily available online for anyone interested to peruse. I'm guessing I/II/III and x-Ref were released on developer CD and so are now available for download? Just ordered IV and V in paperback for less than $22 and they'll arrive this time next week. Something to thumb thru in downtime at work or to lull me to sleep.

Here's where I think you're also a little confused: it feels like you think there's something "magical" about a "16 bit" card (like an LC PDS card) that can output 24 bit color, and that somehow matters to the CPU side interface bus.

Not magical, just a sweet spot for development. If we might keep 68030 PDS development backward compatible with that 68020 PDS subset used in all LC slot Macs that would be the thing to do. Moving it to a NuBus slot doesn't seem all that daunting a prospect from what I've been reading all these years. However, as you pointed out this approach would pretty much cut performance in half as opposed to a full 32-bit NuBus implementation and that would be a big no-no. We might not want to hamstring a card for the IIsi/SE/30 PDS by adhering to the LC slot model either, especially if it will make it easier to move onto NuBus and the 68040 PDS.

A 24bit 720p VidCard design compatible with the 16bit video card connectors in 190/5300 and 1400 as well as the Blackbird PDS now  .  .  .  THAT would be magical!

I got stuck in a late Eighties, 8-bit ISA interface to a ROM emulator frame of mind. You could break it down and lash it up in the easiest possible manner in hardware and then smoosh it all around in the software to fix everything back up at the far end of the cable. Which would, of course, be pretty much what NuBus was intended to render obsolete.

Once again, thanks for the education, Eudi.

@trag did you take a look at those part numbers and the logo in the 040 PDS connector pic? I don't recognize that triangle maker's mark?

 

[Gorgonops]

I got stuck in a late Eighties, 8-bit ISA interface to a ROM emulator frame of mind. You could break it down and lash it up in the easiest possible manner in hardware...

For all its many faults ISA at least made good use of dynamic bus sizing. (A feature Intel retained in the 486, unlike Motorola with the 68040...) An 8-bit-only ISA card is automatically byte, not 16-bit word, aligned.(+++)

As I noted it is technically possibly to make *pretty stupid* 8-bit cards for Nubus too, if you're willing to write your driver to deal with the consequences of having your I/O ports word-aligned. It is simply not an option for video cards or other "memory-like" things.(*)

(*) I may be misremembering some details, but I vaguely recall a horror story written by a Linux developer who claimed he discovered when writing the driver for a Mac NuBus ethernet card which utilized a brain-dead 8 bit 3com(?) chip commonly used on XT cards that the card *did* use only 8 bits to access the 2k packet receive buffer. The result was that to empty it when you got the interrupt you couldn't just copy it in one swoop, you had to in the driver read the contents from every fourth address and reassemble it in system RAM the same way the slot manager reassembles 8-bit declaration ROM. (Writes to the transmit buffer worked similarly.) When I read that years ago I didn't really get why you'd build the card that way, but having read all this junk now I get it.

(+++) Edit: another note: VESA local bus, the closest to PC world had to 68040 local bus slots, also supported dynamic bus sizing. The extremely popular Tseng Labs ET4000 VGA chipset only had a 16 bit bus width for most versions but it could still perform pretty well when stuck on a 33mhz bus.

 

[NJRoadfan]

I haven't looked, but the 040 PDS connector looks very similar to the connector used on the Amiga 3000/4000 CPU cards.... which are available.

 

[modulusshift]

So, let me get this straight: in practice, a video card for one of these Macs is, from the Mac's perspective, a RAM expansion that includes one or more frame buffers, and then components that read those buffers and sends them to a display? And that expansion attaches to the rest of the system through either Nubus or PDS? Does the video card have any other necessary responsibilities?

Is it possible to make bare minimum hardware that uses internal RAM as the framebuffer like the IIsi? Obviously it's most likely worth *not* doing that, just getting my head around the problem space.

What is QuickDraw acceleration, and how hard would that be to implement? I take it we'd need to include a coprocessor (obviously might be same chip, but logically, anyhow) that implemented Atkinson's calls directly instead of just telling the Mac that the framebuffer is over here and letting it figure that out? Would we patch the QuickDraw in ROM to do that?

How much does the Declaration ROM do vs. a system extension like many of the contemporary cards needed? How much external display support is built in?

edit: to be clear, I'm just making my research questions public, if no one knows all this off the top of their heads I'll be poring through the documentation provided anyway, but I'd appreciate the answers as well.

 

[Trash80toHP_Mini]

So, let me get this straight: in practice, a video card for one of these Macs is, from the Mac's perspective, a RAM expansion that includes one or more frame buffers, and then components that read those buffers and sends them to a display? And that expansion attaches to the rest of the system through either Nubus or PDS? Does the video card have any other necessary responsibilities?

Yes and none that I can think of offhand.

Is it possible to make bare minimum hardware that uses internal RAM as the framebuffer like the IIsi? Obviously it's most likely worth *not* doing that, just getting my head around the problem space.

Dunno if it's possible, but you're right about *not* doing the unthinkable from the perspective of bandwidth. IIsi setup is called Vampire Video because it sucks the blood out of system memory along with the performance levels of much greater throughput of dedicated (double ported?) VRAM.

QuickDraw acceleration is beyond my ken, but I'd think a concurrently running development project for a second version of the VidCard would be dynamite

How much does the Declaration ROM do vs. a system extension like many of the contemporary cards needed? How much external display support is built in?

DeclROM set a board up at startup and contained the drivers for a VidCard at the same time so you could see happy/sad Mac machine state indication and then watch the system extension icons load/fail to load as they're read from disk.

edit: to be clear, I'm just making my research questions public, if no one knows all this off the top of their heads I'll be poring through the documentation provided anyway, but I'd appreciate the answers as well.

Making any and all questions public seems like the true path to enlightenment to me. Heck, my silly/misguided questions about saving I/O lines on a NuBus implementation helped G understand something wondered about back in the day. In that light,"reading "all this junk" and playing ping-pong with the tidbits that stick out would seem to be the point.

edit: the first Meg of IIsi memory is dedicated/buffered from main memory so its contents can't be stepped on while it's acting as the internal video's frame buffer. Now I'm wondering if hardware buffering would have been required if the Mac OS had had a protected memory setup?

 

[Gorgonops]

My "off the top of the head" answers. Your mileage my vary:

So, let me get this straight: in practice, a video card for one of these Macs is, from the Mac's perspective, a RAM expansion that includes one or more frame buffers, and then components that read those buffers and sends them to a display? And that expansion attaches to the rest of the system through either Nubus or PDS?

For a dumb framebuffer card that's about the size of it.

s it possible to make bare minimum hardware that uses internal RAM as the framebuffer like the IIsi? Obviously it's most likely worth *not* doing that, just getting my head around the problem space.

Definitely not with Nubus, it'd just be too slow and high-latency. It might be a *possibility* on 68030 or 68040 PDS, at least for a very low-res card, but it would be nontrivial. (This is the sort of thing you really want built directly into the system chipset's RAM controller.)

What is QuickDraw acceleration, and how hard would that be to implement? I take it we'd need to include a coprocessor (obviously might be same chip, but logically, anyhow) that implemented Atkinson's calls directly instead of just telling the Mac that the framebuffer is over here and letting it figure that out? Would we patch the QuickDraw in ROM to do that?

I'm too busy at the moment to Google for them, but I know there are several good articles out there that go into *reasonably* comprehensive depth about how Apple's 8*24GC accelerator worked, and it's basically the model for the breed. I don't know if there's strictly enough there to just sit down and start writing an extension for whatever hardware you stick on the card, but it's definitely a start.

(The 8*24GC used an AMD 29000 CPU on it, which was a general purpose RISC CPU that wasn't especially optimized as a graphics accelerator; its most common application for its relatively short market life was as a laser printer CPU. The 29000 family is stone dead so *replicating* the 8*24GC and using the same drivers probably isn't in the cards, but its architecture suggests some common modern CPU like ARM would be able to do the job just fine.)

How much does the Declaration ROM do vs. a system extension like many of the contemporary cards needed? How much external display support is built in?

DeclROM sets the board up at startup and contained the drivers for the card at the same time so you could see the happy/sad Mac machine state and then watch the system extension icons load/fail to load as they're read from disk. 

According to my reading of the docs strictly speaking a "dumb" video card doesn't have to have a "driver" per se in the declaration ROM, it only needs a bunch of resources that inform the built-in "Generic framebuffer support" in Quickdraw about the specific modes supported by the card and how to switch between them. It's not clear to me that any of this needs to be executable code.

This is for basic support, of course. I think even some "dumb" cards still required extensions to control some more advanced features? (Mode switching, refresh rate selection, etc?)

 

[Trash80toHP_Mini]

According to my reading of the docs strictly speaking a "dumb" video card doesn't have to have a "driver" per se in the declaration ROM, it only needs a bunch of resources that inform the built-in "Generic framebuffer support" in Quickdraw about the specific modes supported by the card and how to switch between them. It's not clear to me that any of this needs to be executable code.

Quick answer to that would probably be found in the extended documentation of the TOBY frame buffer card for the Macintosh II. That appears to have been added in the third edition of DCaD after the discontinued TOBY frame buffer card was discontinued and no longer available to developers from Apple. I'd think providing drivers for the Macintosh II  in System ROM. Brain is moosh ATM, so:







Online PDF of DCaDftMIIaMSE is scan format, so I screen capped the DeclROM section, leaving off the "Card connectors" page.

edit: Resized second page to better match the first in picture flip mode.

 

[dlv]

I've begun working on a schematic of the HDMI daughter board for the QMTECH FPGA, but I'm realizing that if I'm going to have PCBs made, it would make a lot of sense to wire in PDS (or NuBus), and save money and time... Guess I'll need to catch up and read the documentation you've all referenced. Stanford University (where I work) appears to have several of the "Inside Macintosh" volumes available, including one on QuickDraw, which I'm also curious about.

 

[Gorgonops]

Quick answer to that would probably be found in the extended documentation of the TOBY frame buffer card for the Macintosh II.

Yeah... and after reading that 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.(*)

(* I'm curious if the "stub" declaration ROM that's inside of an SE/30 has any driver code in it, because its video hardware actually basically fits this description.)

 

[Trash80toHP_Mini]

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.

.  .  .  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

 

[Gorgonops]

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.

 

[Trash80toHP_Mini]

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?

 

[Gorgonops]

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'?