FUNKYWARE.ORG - TT_WHITE.TXT - 06.10.1997


-----
FUNKYWARE.ORG - TT_WHITE.TXT - 06.10.1997

NOTE: The following came to me from Mario Becroft, after reading
      my request for a patch to fix the "Polaroid" white border,
      seen on a TT's color screen modes.

***
Date: Mon, 4 Aug 97 12:52 NZST
From: Mario Becroft  mb@tos.pl.net
To: q-funk@citenet.net (Martin-Eric Racine)
Subject: TT white border patch 

I noticed on your WWW page mention of a TT white border patch.

I think that patch must be one that I was working on and obviously
someone said something about it and now everyone has heard of it.

You may as well post these details on your WWW page if you like,
editing them as necessary.

I find the white border annoying, so I thought of ways of fixing it.
Changing the palette has the effect of changing the border colour,
but the problem is exchanging the white colour in the palette to
black and black to white means that, while the border colour is
fixed, items drawn onscreen will come out in the wrong colour.

Therefore, a patch would need to change the palette and keep things
to still be drawn in the correct colours despite a changed palette.
In other words, it would have to swap colours 0 and 1 when drawing
to the screen.

I found two ways of doing this:

 * I could write a patch that intercepts all the VDI colour setting
   calls and swaps colours 0 and 1.

 * I could patch NVDI so that it's VDIhardware lookup tables are
   changed so that VDI colours 0 and 1 are swapped.

I tried both of these approaches, and here are the results:

* The patch of the VDI colour calls:

This worked reasonably well after I patched all vs?_color() calls,
but I found that there would be a major problem or two. Text, drawn
with v_gtext, still had its background when drawn in opaque mode
drawn with index 0, and there was no way of changing this.

This means that I would have to reqrite v_gtext, which is would be
rather a big job, if possible at all. Bitmaps were also, of course,
drawn in the wrong colours, and I think that to fix this it would
be necessary to patch vr_trnfm. This would also be a big job.

So I have given up on this idea.

* The patch of NVDI itself:

I looked all through the relevant parts of NVDI (the NVDI binary
and screen drivers) and I patched all the VDIhardware lookup
tables I could find.

Unfortunately, this did not work very well. In 16 colour mode, it
worked for the mouse pointer but nothing else, and in 256 colour
mode it worked for some things and not others.

Perhaps I patched the wrong lookup tables (although I could not
find any others anywhere in NVDI) or perhaps NVDI has some lookup
tables that are not recognisable as VDIhardware tables.

So, to summarise, neither of these approaches worked. The first
approach might be successful with a lot of work, but even then
it is doubtful.

I believe it would be relatively easy for a fix for the white
border problem to be included into NVDI, but I don't think NVDI
authors would want to include a fix, for a silly problem in a
machine like the TT.

I hope that clarifies the situation regarding the patch.

If you have any further queries, don't hesitate to contact me.

--
Mario Becroft                        Auckland, New Zealand
mb@tos.pl.net                 http://www.pl.net/user/mario
Tariland, Atari Support in New Zealand
tariland@tos.pl.net  http://www.pl.net/user/mario/tariland

.
-----
NOTE:  those who need to print this may crop HTML tags above and
       below the five dashes and re-save as straight ASCII text.



   HOME