Re: [MiNT] W and MacMiNT

[Oddie Jonathan <oddie@bvsd.k12.co.us>]

>> Is there a way to tell the PMONO driver that lines are longer than they
>> should be?
>
>Ie use padding for non-long aligned screens?  No, PMONO driver is
>'fully optimized', so it doesn't support that.

No, I meant when the byte offset from the beginning of one row to the next
is more than the pixel width of the screen  / 8, as it would be if there
was no gap  between the end of one line and the beginning of the next.
I've changed the mac init code so it now gets this offset from the GrafPort
rowBytes field; it works perfectly on the Performa now, and should probably
do so on other monitors too. (I used the bm.upl field to tell driver how long
the lines are)
The direct8 driver also works in the sense that it produces a picture on
the screen, just the colors are all screwed up :) Yellow-on-white is very
hard to read :)
>
>
>> Turns out that's not the problem, but I'll add some code for the BMONO
>> driver in mac.c in case someone has a screen which needs it.
>
>Ok :-).
>
When using BMONO, should bm.unitsize still be set to 4, or should it be
lower (2 or 1)? Mint.c sets unitsize to 4 whether using PMONO
or BMONO, so I wondered...

>
>> >A direct-8 driver would be nice :)).  What kind of graphics modes
>> >different Mac models (for which MacMiNT works) there are?
>
>> The upshot of all this is that there isn't currently a W color driver which
>> will work on a color Mac screen. How hard would it be to make a new driver
>> based on direct8 that would use a palette rather than direct values?
>> You could then run it in 256 color mode...
>
>The direct8 driver actually uses a palette.  I've been wondering
>TeSche's namings on other subjects too...
>
>The color indeces are 1-byte with direct8 driver.  Maybe it all
>will be easier than you hoped? :))

Cool, it shouldn't be too hard to get it work properly then. I just need
to write a putCmap function to mess with the color tables.


ttfn
Jonathan