Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Johan Klockars <johan@klockars.net>]

> Johan, if you were to confirm the output of CLUT flag from the
> hardware you mention, would that be enough to "cast it in stone" (can

That CLUT flag from vq_extnd() can hardly be very important to worry
about. It really ought to be the same in every available graphics mode
(except ST mono) and, since it apparently hasn't been (due to
documentation problems), it is very likely that no one has ever looked
at it.

Still, it doesn't hurt to get it right.

> the ST stuff be checked on STeem, and the Falcon stuf on Hatari?)

Certainly. This is just a VDI data issue, so anything using an
original ROM will return the same thing when set to the same mode.

> guy who just posted recently a blog concerning certain parts of this
> particular conversation, and other VDI related ones too, he was the
> guy who came and handed you your official Atari documentation. He is

Huh? I have never seen, much less been handed, any official Atari documentation.

> It is issues like this, and other VDI related "merkyness" that is
> currently the legacy that Atari Corporation, COmputing Division, has
> left us with. Now is the right time to deal with it, as the new
> Coldari will not suffer these genetic deficiencies (in any part of its
> OS)

Compared to the rest of the VDI and AES, these are rather minor
genetic deficiences, IMHO. ;-)

> Johan: are you open to ASM code for specific function/algorithms where
> they would make a huge impact

People usually complain that I have too much assembly in fVDI as it is.  ;-)
(There are thousands of lines of it.)

If anyone thinks they can speed something up usefully, feel free to
contribute. fVDI is GPL:ed, after all, so it's not like I could stop
you if I wanted to.

As I mentioned elsewhere, I have not cared much about anything except
the monochrome (almost 100% assembly) and RageII (mostly C, but doing
everything I could think of to use the hardware acceleration as
efficiently as possible) drivers. Those two are blazingly fast, but
not of much use to most people, I suppose.
The bitplane driver (100% C) is likely OK:ish, the 16 bit one less so
(it was mainly written as an example).

/Johan