Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Paul Wratt <paul.wratt@gmail.com>]

There is some good info here, and now is a good time to "hit this nail
on the head", there is no point in going back in a couple of months or
years and changing it again.

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
the ST stuff be checked on STeem, and the Falcon stuf on Hatari?)

"Perhaps someone could verify what Atari actually did?" - There is a
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
still knowledgeable on the subject (and I dare say haunted by it), and
may have ideas or answers that can help pin this down.

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)

Right now AES  _AND_  VDI are being "redeveloped", time to fix it so
they are both talking the same language

(some of this applies to other parts of OS, like missing AES functions
in XaAES, and AES 4.1 support)

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

Helmut: same, how much have you seen of AES functions, alot of current
users need the extra speed.


Paul


On Wed, Dec 9, 2009 at 8:03 AM, Johan Klockars <johan@klockars.net> wrote:
>>> Well, I'm not reading this list all the time, and certainly don't
>>> often have time to look into "possible issues" with it. Still, the
>>
>> But who do you think has the time?
>
> I'm not saying that anyone has time, but we could hope so.
> Still, I do actually have a bit more time these days than I've had for
> the past couple of years, so...
>
>>> If you are talking about how vs_color() supposedly does not work for
>>> non-CLUT colour modes, that is nonsense. How would you expect any
>>> application whatsoever to be able to use any colour not in the
>>> standard palette on a true colour screen?
>>
>> I thought you would tell me! How is it possible to display TC with 256
>> colors (that's what fvdi claims to support)?
>
> As I said, fVDI does what every other true colour VDI has always done:
> uses a virtual palette.
> It is the same thing with NVDI and for that matter the Falcon VDI (in
> true colour mode).
>
>> I suppose they use a natfeat-function or whatever.
>
> fVDI is not an ARAnyM thing. It existed for years before there was an
> ARAnyM and has dealt with 16 and 32 bit true colour since around '97.
> There's nothing strange about it at all.
>
>>> What vs_color() will not do on a true colour screen is change the
>>> colour of any pixel alread on the screen, since the palette it is
>>> setting is just a virtual one (there must still be a palette/CLUT,
>>
>> Why does fvdi say there is no CLUT then?
>
> If you are talking about the data you get back from vq_extnd() (the
> CLUT flag), that flag is indeed set to 0 and the documentation I
> linked to earlier claims that:
>  0 = no CLUT
>  1 = CLUT or pseudo-CLUT (true colour)
>
> However, the two references I have to the VDI here on my bookshelves
> (Compute!'s Technical Reference Guide, Atari ST, Volume One, VDI, and
> Atari ST/STE Hårdfakta) say:
>  0 = look up table available
>  1 = look up table not available
> and
>  0 = look up table supported (as on color screens, where VDI drawing
> pen index numbers are different from hardware colour register numbers)
>  1 = Lookup table not supported (as on ST monochrome screen)
>
> I also sometimes look at PC GEM documentation on the internet, and
> just now I found this:
>  1 if palette based, 0 if true colour
>
> According to the mid two, returning 0 is correct for a true colour
> mode. That is, the zero means that there _is_ some kind of
> look-up-table, real or virtual. The fourth is a bit funny in saying 0
> for true colour and 1 for palette, but I think they do not refer to
> what we nowadays call "true colour".
>
> Given the errors I've found in online Atari references before, I tend
> to believe my books (and old PC GEM documentation). That said, I have
> not actually checked what the Atari VDI returns for the three original
> three modes, or the various ones on a Falcon (well, at least not these
> past 10 years ;-), and I just found the following note in the
> documentation for vq_extnd on the toshyp web page:
>
> "Atari originaly misdocumented the workout[5] (CLUT) element,
> reversing the values. The Falcon 030 and some third-party TrueColor
> boards return the correct values, but some older boards may not."
>
> So, there are different opinions on what the return value should
> actually be, and thus little point in checking that flag at all.  ;-)
> Anyway, AFAIK, the only non-CLUT mode (excluding true colour modes,
> since those do have a pseudo-CLUT) that has ever existed on an Atari
> machine is the original monochrome mode.
>
> After seeing the PC GEM vq_extnd() documentation mentioned above, I
> now lean towards the view that everything except ST monochrome should
> indeed have a 1.  ;-)
> Perhaps someone could verify what Atari actually did?
>
> I apparently changed this value in the true colour drivers for fVDI
> some time in its pre-CVS days (before 2001). The only thing that
> remains is this somewhat cryptic comment:
>
>        wk->screen.look_up_table = 0;                   /* Was 1 (???)  Shouldn't be needed
> (graphics_mode) */
>
>>> just a software based, or the VDI would be unusable). Still, anything
>>
>> vs_color surely isn't at this place.
>
> Are you saying that it isn't possible to use vs_color() in a true
> colour mode somewhere? Can you point to some display hardware where it
> doesn't work?
>
>>> drawn using that palette index (on that specific virtual workstation)
>>
>> I never said palette-index would not work.
>
> I am talking about setting the colour value for a palette index (any
> index, 0-255) and then drawing using that.
>
>>> See for example http://toshyp.atari.org/007004.htm#vs_color.
>>
>> "Note: The function can only be used if lookup table support is present."
>> ...
>> "If a device has more than 256 colours displayable simultaneously, it
>> usually does not have a CLUT."
>
> Please, read the whole paragraph:
> If a device has more than 256 colours displayable simultaneously, it
> usually does not have a CLUT. In that case the pixels do not contain a
> colour value or index but a direct colour value in RGB (e.g. a pixel
> with 32 bits has 8 unused bits, 8 bits for red, 8 bits for green and 8
> bits for blue). This means that the VDI creates a pseudo-CLUT with 256
> pens, and calling vs_color for one of these pens will not change the
> colour of the pixels which have been drawn with this pen, though it
> will change the colour of new pixels drawn with this pen.
>
> It says explicitly that when there is no CLUT, the VDI creates a
> pseudo-CLUT and things work the same way as usual (except, of course,
> that palette changes do not affect previously drawn pixels).
>
>> Maybe there has to be a palette and it isn't, I don't know.
>
> There will always be a (pseudo-)palette in a true colour mode. You
> couldn't use the VDI otherwise.
>
>>> So, how would you set which colours to use, if not via vs_color()?
>>
>> Use a palette-index. vs_color is used only at one place in whole XaAES.
>
> You don't set colours by using palette indices, you just use whatever
> has been set before.
>
>> XaAES uses only default-palette-colors.
>
> In operation, an AES does not normally change colours because it would
> be insane for it to do so on a system with an actual hardware CLUT. No
> application would know what colours it was using any longer.
> I suppose very few applications developed in the pre-true colour days
> ever changed any palette entries either, since that obviously would
> have affected the AES and any other applications that might have been
> running.
>
> /Johan
>
>
>