Re: [cc65] tgi_init functionality change request

From: Ullrich von Bassewitz <uz1musoftware.de>
Date: 2004-10-30 12:50:11
On Thu, Oct 28, 2004 at 06:56:01PM +0300, Karri Kaksonen wrote:
> I noticed that the tgi_init code will clear the screen and set the palette
> at startup. Unfortunately it does not set the draw page before clearing
> the screen resulting in wiping out random memory areas in the Lynx.

You can either have your draw page setup in the INIT entry of the driver, or
the C wrapper can be changed to set the page before clearing the screen. Maybe
the latter is the better idea.

> I would like to change the tgi_init so that it does not set the palette
> and it does not clear the screen.
>
> These things should not be done before we have set up the hardware
> pointers and the screen interrupts. The interrupts have to be set
> up outside the driver. So the recommended workflow maight be:
[...]

Not a good idea. The driver should work after calling tgi_init without
anything else. If this is not possible, we will have to think about changing
the TGI driver spec to make it possible. Mouse drivers can have an interrupt
routed to the driver. If interrupts are necessary for TGI to make it work on
the Lynx, my suggestion would be to make this addition, instead of ressorting
to additional driver specific calls. tgi_ioctl is nice for optional functions,
but if it is necessary to call tgi_ioctl to make the driver work at all,
something is wrong, and we have to rethink the API.

> The Lynx also has an image on screen at load-time. I don't like the idea
> that the screen is forced to black by the driver. Perhaps I would like
> a smooth palette fade from the original image to the applications first
> screen.
>
> Could these changes be made? To get the old behaviour you need to call:
>
> tgi_setpalette(tgi_getdefaultpalette());
> tgi_clear();
>
> after calling tgi_init().

I have to admit that I don't like the proposed changes. The idea is that after
calling tgi_init, the driver is initialized to some standard values, and the
"drawing paper" is empty. In detail, the following initializations are made:

  - Call the INIT function of the driver.

  - Set the palette to the default palette.

  - Set the drawing color to the maximum colour (assuming this is a visible
    color).

  - Set the text style and magnification to horizontal text with size 1.

  - Clear the screen.

While it is not a must, I think that people expect some sort of initialization
from calling tgi_init(). At least this is what I would do.

What we could do is to move the sequence above into the driver (it is
currently executed by the C wrapper). This would allow some drivers to
implement a different behaviour. The drawback is that all existing drivers
have to be changed, and that it leaves the door open to all sorts if minor
issues with initialization: One driver will not set the color or palette, the
other will not clear the screen, and the third needs an extra call after
tgi_init to do some driver specific initialization, otherwise it won't work.

Is it really so bad to have the screen cleared after the program starts? You
can still fade in your first application screen, there's nothing in the driver
concept that prevents this.

My suggestion would be to make the necessary changes so that the INIT entry of
the driver is able to really initialize the driver, even if this means adding
an interrupt entry (changes for other drivers are minimal, since this
"function" is just a vector that points to an RTS). Regarding the
initialization behaviour, I would prefer to leave it as it is (maybe add a
call to set the pages).

Maybe we should work out the Lynx interrupt issue when I'm back at home, so it
is clear how this works, and what is possible. Things may become clearer
after that.

Regards


  	Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sat Oct 30 12:50:15 2004

This archive was generated by hypermail 2.1.8 : 2004-10-30 12:50:25 CEST