Radius Rocket QuickDraw Acceleration and Bus Mastering

[Phipli]

Just wondering - where is the QuickDraw Acceleration processed on the Rocket? On the GAL version, there is only the 040 for doing serious lifting?


Is there a something we can copy to make just a quickdraw accelerator? Or does the implementation require the whole card?

Be interested if anyone has any insights.

 

[zigzagjoe]

While I haven't gotten into it myself, I've also been curious... intuition says it's using the 040 as there's nothing else that can be doing it. I don't have any radius video cards to test with, though. It'd be interesting to see both what the performance gain is and if it requires RAM on the card to function. If it needs RAM on the card you'd be pretty much stuffed as far as making any kind of a simpler card goes.

I'm curious what the 040-side software looks like - custom acceleration code, or some framework to run QD proper...? They did make the radius risc accelerator card, I'd expect significant overlap with whatever technique that used.

 

[eharmon]

I’ve never really gotten this to work, or not noticed a difference. Does it only function when specifically paired with an unaccelerated Radius card?

 

[Phipli]

I’ve never really gotten this to work, or not noticed a difference. Does it only function when specifically paired with an unaccelerated Radius card?

Yes it only works with a specific set of cards.

I've also never used it because I don't have an unaccelerated Radius card that supports block transfers

Rockets do also work better with PrecisionColors - but the PrecisionColors internal acceleration is better so you use that. You still gain in that the Rocket and PrecisionColor talk to each other more efficiently.

Edit - you know, I tell a lie. I forgot to give my dad is VideoVision back. That might be an unaccelerated Radius card that supports block transfers.

 

[Phipli]

While I haven't gotten into it myself, I've also been curious... intuition says it's using the 040 as there's nothing else that can be doing it. I don't have any radius video cards to test with, though. It'd be interesting to see both what the performance gain is and if it requires RAM on the card to function. If it needs RAM on the card you'd be pretty much stuffed as far as making any kind of a simpler card goes.

I'm curious what the 040-side software looks like - custom acceleration code, or some framework to run QD proper...? They did make the radius risc accelerator card, I'd expect significant overlap with whatever technique that used.

It's interesting - I read that some of the SuperMac gains were purely software patches. It would be nice to just make an extension with the software patches to have a software only performance bump.

 

[PappaDF]

intuition says it's using the 040 as there's nothing else that can be doing it.

That guess aligns well with some observation I made related to the 24AC card (also by Radius). I recently tried to put together an "emulated" model of 24AC, and the dedicated silicon acceleration on it is honestly pretty limited - it's a pattern/fill + block-copy engine that the CPU has to feed by hand. Nothing fancier than that. I.e. not an autnomous blitter. The CPU is still walking every scanline. Even though the card is marketed as "hardware accelerated", from what I can see, part of the speedup is just optimized 68K code running on the host (through the init/cdev).

It's interesting - I read that some of the SuperMac gains were purely software patches. It would be nice to just make an extension with the software patches to have a software only performance bump.

I think that's very doable, it's effectively what the 24AC cdev already do internally as one of the alternative execution paths:
It takes over some ~10+ of qd's internal blit "bottleneck" routines by swapping their entries in the trap table. Not the main/public CopyBits/StdBits calls - but the inner primitives underneath them, which Apple made replaceable through the dispatch table. Some of those patches seems to touch zero hardware/card registers - they're just tighter, more optimied 68K code.

Thinking about it, it's probably possible to take the 24AC init/cdev, patch it a bit to ignore the hardware (whether it is there or not) and simply use it as a pure sw qd accelerator

 

[Phipli]

The CPU is still walking every scanline. Even though the card is marketed as "hardware accelerated", from what I can see, part of the speedup is just optimized 68K code running on the host (through the init/cdev).

It's interesting because they're some of the faster cards, so it worked.

Another thing I guess is that it scales with host performance to a degree which means you don't have to worry about new computers being bottlenecked by the card so much.

All very interesting.

 

[PappaDF]

I’ve got my emulated 24AC working now, so I can put together a write-up about all the internals of the hardware acceleration, if there’s interest. However, note that I’ve been using AI tools in this reverse-engineering work, so this is indeed “slop”

 

[Phipli]

I’ve got my emulated 24AC working now, so I can put together a write-up about all the internals of the hardware acceleration, if there’s interest. However, note that I’ve been using AI tools in this reverse-engineering work, so this is indeed “slop”

I'd be interested to see anything you can share, thank you and congratulations on getting it working.

I'd be interested to know how differently the video benchmarks in Norton System Info (detailed breakdown) in emulation with and without the emulated 24AC.

 

[PappaDF]

I'd be interested to see anything you can share, thank you and congratulations on getting it working.

I put together a page with most of the content (again, see previous disclaimer re. AI use):

https://github.com/pappadf/granny-smith/wiki/Inside-the-Apple-Macintosh-Display-Card-24AC

I'd be interested to know how differently the video benchmarks in Norton System Info (detailed breakdown) in emulation with and without the emulated 24AC.

Agree, that would indeed be interesting - I will try to get it up and running.

 

[Phipli]

I put together a page with most of the content (again, see previous disclaimer re. AI use):

https://github.com/pappadf/granny-smith/wiki/Inside-the-Apple-Macintosh-Display-Card-24AC



Agree, that would indeed be interesting - I will try to get it up and running.

Thank you for sharing, an interesting read.

Are you sure the boot splash is in the CDEV? Surely that executes from ROM because it shows right at the start of boot, before the OS has even been identifed and loaded, let alone extensions and control panels. Perhaps it is a terminology issue.

 

[PappaDF]

Thank you for sharing, an interesting read.

Are you sure the boot splash is in the CDEV? Surely that executes from ROM because it shows right at the start of boot, before the OS has even been identifed and loaded, let alone extensions and control panels. Perhaps it is a terminology issue.

Sorry, bad wording; boot splash = boot splash for the init/cdev (what icon/state to show, etc.) not boot splash for the Macintosh ("Welcome to Macintosh") at large. I will clarify in the text.

 

[Phipli]

Sorry, bad wording; boot splash = boot splash for the init/cdev (what icon/state to show, etc.) not boot splash for the Macintosh ("Welcome to Macintosh") at large. I will clarify in the text.

Ah, drawing the loading icon, I get you. The routine is called "showIniticon" in Force32. I think that might be a terminology from other historic examples... I forget what the comments say at the top.