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

Documenting the Macintosh hardware graphics stack (NuBus/built-in/SCSI, QuickDraw and OpenGL acceleration, etc.)

uyjulian

Well-known member
It seems like there isn't much information in one place on how the graphics on Classic MacOS work (relatively to modern graphics APIs like Vulkan etc).

I'd like to document this further, hopefully to fix graphics acceleration for newer processor/OS or to implement your own graphics interface over NuBus or SCSI (e.g. RaSCSI).

Let's start off with a few questions, and see if others can answer or provide documentation references.

---

On older Macintoshes, you can access the framebuffer directly. Which machines or system configurations started to make this not possible?

---

Does QuickDraw immediately display the operation on the screen, or is there a command queue?

---

For NuBus cards, how does the framebuffer get accessed? Is there a separate framebuffer on main memory and NuBus which need to be synchronized, or it is only on NuBus card? If it is the latter, is it memory mapped?

---

How does acceleration with cards such as Macintosh Display Card 8•24 GC work? Is there an API for providing your own implementation of QuickDraw commands for the specific card (like OpenGL ICDs), or does each INIT hook the traps?

---

Is there a unified API to read the framebuffer for both built-in and NuBus cards, or is it specific to the output method?

---

What possible APIs are used for graphics acceleration? (QuickDraw, OpenGL 1.x… any others?)

---

What are the most common cards or configuration that support graphics acceleration (e.g. with an INIT)?

---

 

Dog Cow

Well-known member
1.) On older Macintoshes, you can access the framebuffer directly. Which machines or system configurations started to make this not possible?

2.) Does QuickDraw immediately display the operation on the screen, or is there a command queue?

3.) For NuBus cards, how does the framebuffer get accessed? Is there a separate framebuffer on main memory and NuBus which need to be synchronized, or it is only on NuBus card? If it is the latter, is it memory mapped?


1.) The Macintosh II, released in spring 1987, was the first Macintosh that did not have built-in video.

2.) Immediately

3.) Framebuffer is accessed thru NuBus memory. The framebuffer is on the NuBus card. It is memory mapped into the CPU's address space.

Read Inside Macintosh volume V for details on NuBus and video for the Macintosh II. It should give answers to some of your other questions.

 
Last edited by a moderator:

cheesestraws

Well-known member
On older Macintoshes, you can access the framebuffer directly. Which machines or system configurations started to make this not possible?


As far as I know, 'provides dumb framebuffer that can be accessed directly' is the case all the way through, or at very least is necessary for being a boot screen all the way through (though I don't know much about OS 9). 

 

uyjulian

Well-known member
It seems like there is another method of GPU acceleration, with the DrawSprockets API, but it requires taking over the display output (e.g. "exclusive fullscreen"). I'm not sure which machines or cards supported acceleration with this API.

There is also QuickDraw 3D but support for it was dropped quickly, and I'm not sure how many cards support QuickDraw 3D but not OpenGL.

It would be nice if I could implement acceleration for a single API e.g. OpenGL and then operations for other APIs like QuickDraw, DrawSprokets, QuickDraw 3D would be piped into it. I wonder how the last e.g. ATI drivers are accelerating these APIs internally...

It seems like Retro68 doesn't support building PowerPC INITs yet, so that would be one roadblocker.
 

kitsunesoba

Well-known member
I don't have any sources to link to or anything, but anecdotally the heyday of QuickDraw 3D was the mid-to-late 90s. Most memorably most of the classic Pangea Software games (Mighty Mike/Power Pete, Nanosaur, Bugdom) rely on it.
 

Crutch

Well-known member
I’m not sure exactly what you’re trying to do, but of course you can developer PowerPC INITs with vintage tools easily (CodeWarrior).

QuickDraw generally routed graphics calls through a set of ”standard bottleneck“ routines: StdLine, StdArc, StdBits which were explicitly overrideable without going through the trap patching mechanism. The idea was that one could swap out the normal line-drawing implementation (which draws to the screen) with one that sends a line-drawing command to a printer, thereby making it possible to have all your usual graphics code “just work” when you want to print a document or, conceivably, send graphics instructions to some other device. This is documented in Inside Macintosh Volume I. It probably doesn’t help with the ’90s-era stuff you seem to be thinking about though.
 
Top