What is QuickDraw acceleration?

[ZaneKaminski]

Title says it all. How do the NuBus cards which advertise QuickDraw acceleration do it? I've read much of Designing Cards and Drivers for the Macintosh Family, but there is no mention of video acceleration in there. Is the acceleration just some blitter functionality, where the card moves memory around according to instructions given by the processor, or is it more involved than that?

 

[Gorgonops]

"Quickdraw Acceleration" is a pretty broad term. Basically any card that sticks a software shim into place to redirect Quickdraw primitives "somewhere else" rather than to be executed by the main CPU using the software inside the Mac's ROM can call itself "accelerated". Here's an article about the "definitive" Quickdraw card, Apple's 8x24GC. This card was capable of drawing low-level shapes like rectangles/ovals/arcs, etc, and could even speed up other video cards sitting on the Nubus by redirecting the primitives call to itself, rendering it faster than the Mac could, and DMA-ing it across the bus. (Nubus supported busmastering.) It's definitely more involved than just blitting pixels around.

Since I'm sure this is in reference to the Radius Rocket discussion, well, I have no idea what they're referring to when it comes to Rockets acting as Quickdraw accelerators. Radius offered a number of daughterboards for them, including a DSP card, perhaps there was a driver for offloading Quickdraw functions to that?

 

[Unknown_K]

The original Quickdraw accelerators were Nubus cards with DSP's and some RAM, they did the Quickdraw functions over the Nubus BUS instead of having the CPU do it. I have a couple of the boards made by Rasterops. It wasn't long before Nubus video cards did the acceleration onboard. Transfering data over Nubus for video is kind of slow.

 

[ZaneKaminski]

Here's an article about the "definitive" Quickdraw card, Apple's 8x24GC.

Great link. That really explains it. Especially nice to see was the list of all primitive operations accelerated by the 8x24GC. Thanks.

 

[Bunsen]

Are you looking into adding Quickdraw acceleration to your project, Zane?

 

[ZaneKaminski]

Are you looking into adding Quickdraw acceleration to your project, Zane?

Not exactly, at least I don't plan to do it personally, just trying to make the has the ability to emulate a video card with that functionality. I want the accelerator to have the capability either emulate any peripheral, with the Macintosh running on its own processor at normal speed (i.e. acceleration off), or run the 68000 code on the emulator (i.e. acceleration on) and still emulate any given peripheral device. I dunno if I'll define APIs supplied by the emulation engine for that, but I want it to be possible on the hardware I produce and I want to allow the easy addition of these features to the software.

I figured that allowing the accelerator to not only have cards, but emulate any card to the Macintosh gives the system greater relevance in terms of preservationism. I didn't like the fact that I was basically cramming a whole Linux PC into this poor old Macintosh to achieve my performance and flexibility goals. So the idea of being able to act like a card to the Macintosh, which really adds no cost or effort since I'm gonna leave it mostly unimplemented, somehow makes up for the ugliness of the Linux PC. Then maybe someone, someday, will implement Radius Rocket emulation hahah.

The way to get the best QuickDraw performance seems to be to re-write the time-critical routines by hand in ARMv8-A assembly, and then use that translation when the block of code is encountered and translated. So that's not really peripheral emulation, that's more of a feature of the emulator.

Doing it that way doesn't have the asynchronous quality that, for example, doing QuickDraw on the 8*24GC does, where the QuickDraw routine immediately returns and then the coprocessor works on the framebuffer while the Macintosh continues, but that's fine. It would be much easier to implement it in the synchronous code-replacement way, and it would retain compatibility with more apps, especially ones written for the 7.8336 MHz 128k-Plus and SE. But yeah, I don't know that I'm gonna write replacements for all the QuickDraw routines, maybe CopyBits since it's the most straightforward demonstrator. On the other hand, maybe the translation engine should, in service of being fast, be implemented so as to write really good ARMv8-A code for serial copying in the way that CopyBits might be implemented?

Hmm... Many questions are unanswered at this point, I've just gotta ensure that I allow as many different approaches as possible while still keeping the hardware cost low.