New Project: DoubleVision SE/30 Card

[olePigeon]

Just so you know, and sorry about that, but: Mac is short for Macintosh. You do not write it in ALL CAPS. Thank you.

But it could be if you're using a Backronym. MAC is not an ACronym.

 

[eharmon]

(How are you so fast?)

Have you considered a passthrough PDS slot and a physical card ID selection? Stacking SE/30 cards is very handy and the more cards with passthrough, the easier it is to customize (of course, you can't really get past a few cards or power and signaling issues crop up). Along with that you can have ID conflicts with multiple boards so it's common to provide jumpers or DIP switch so you can adjust before inserting.

 

[jjuran]

Indeed there is no support for hardware cursor in 6/7/8. I also have the hardware cursor (albeit smaller at IIRC 32x32, a clone of what available in Brooktree DACs in SPARCstations, also with a limited number of colors) but it's only useful in X11.
At that size, if the sprite is full-color (same depth and CLUT as the display), then it could replace the SW implementation.

Even if the sprite is too shallow, you could limit it to black-and-white cursors — which is most of them. A more significant limitation would be the lack of XOR mode in the blitter, used in the I-beam cursor for example.

Maybe it could be used by hijacking some of the QD functions - but it's likely going to be quite difficult to implement.

It's not out of the question. Here's a proof of concept for how it could work:

metamage_1/68k/modules/ams-core/cursor-core.cc at master · jjuran/metamage_1

Metamage open source, general repository, iteration 1 - jjuran/metamage_1

github.com

QuickDraw per se is untouched, and no traps are patched — only some jump vectors in low memory are rerouted. That is, in fact, how it works in my reimplementation of classic Mac OS — though just how closely it resembles the real thing is a topic I haven't investigated.

 

[Melkhior]

Even if the sprite is too shallow, you could limit it to black-and-white cursors — which is most of them. A more significant limitation would be the lack of XOR mode in the blitter, used in the I-beam cursor for example.

"True" hardware cursor, in the style of Brooktree, don't rely on a blitter - do you use what I would describe as an "offscreen cursor" ? (stored in additional VRAM beyond the picture, perhaps alongside a copy of the area it replaces?)

In the Brooktree style, the cursor bitmap is stored directly in the DAC, alongside its coordinate. When the HW cursor is active, inside the cursor area the DAC simply ignores the data coming from the framebuffer and use those from the cursor bitmap instead wherever the cursor bitmap is not set to "transparent". The content of the framebuffer underneath the cursor is never changed at all. It's very efficient.

It's not out of the question. Here's a proof of concept for how it could work:

metamage_1/68k/modules/ams-core/cursor-core.cc at master · jjuran/metamage_1

Metamage open source, general repository, iteration 1 - jjuran/metamage_1

github.com

QuickDraw per se is untouched, and no traps are patched — only some jump vectors in low memory are rerouted. That is, in fact, how it works in my reimplementation of classic Mac OS — though just how closely it resembles the real thing is a topic I haven't investigated.

Interesting. Does your reimplementation only cover the original QD, or the entire Color QD ? It appears to be mostly C/C++ (with a tiny bit of 68k ASM), and it makes me wonder whether some of it could be used as the basis for acceleration code. I limited myself to low-level variant(s) of BitBlit because the upper level stuff was too complex to reimplement, but if you already have done the work it might bear revisiting...