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