From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Making the screen one line
Date: 13 Apr 92 15:47:50 EST

In article <1992Apr12.191837.24409@convex.com>, rosenkra@convex.com (William Rosenkranz) writes:
> In article <A38834@MS.maus.de> Julian_Reschke@ms.maus.de (Julian Reschke) writes:
>>That depends on what you understand 'portable'. A truely portable GEM
>>application may not call anything but AES and VDI functions for graphics.
> 
> i was not asking about a portable _GEM_ program, just a portable _TOS_
> program. it appears that these are not necessarily the same thing.
> 
>>In particular, it may _never_ write directly to the screen (and there's no
>>GEM call to find out where the screen is).
> 
> I thought Physbase, by definition, tells this as does the _v_base_ad sys
> variable? why then do graphics cards break the rules? surely this info
> must be memory mapped somewhere, so that an address can be found, albeit
> in some contorted fashion depending on the sys config.

There are several problems with using Physbase() and writing directly to
the screen:
(1) As Julian pointed out, the number and layout of planes is not, in general,
    possible to determine, so you're restricting your program to working
    only in certain resolutions and with certain video boards if you do this.
(2) If you're multitasking and more than one program tries to write directly
    to the screen at once, you get a mess.

(2) is why I would say that Physbase is "read-only" under MiNT, just
as the line A variables and BIOS keyboard map tables are read-only; if
more than one program tries to write to any of these things, unpredictable
results occur.

I used to really hate GEM too. It's not so bad, though, once you've written
an object-oriented wrapper to hide all the guts (and that also means that
to re-compile for X or some other windowing system you just have to change
the wrapper).

>>The docs say nothing. This means: the old informations are still valid.
>>You CAN use this variables. But your programs WON'T run on add-in cards or
>>future Atari hardware. Simply because these informations aren't just
>>enough to access the screen.
> 
> ok. this is what i wanted to hear. i also believe that GEM will be gone
> anyway within 5 years, replaced with X. in any case, a GEM program will
> not run nor will an XBIOS program. only i can develop the latter in 1/3
> the time.

I don't know Atari's future plans, but I would guess that if they decide
to go with X then they'll still provide a GEM-like interface for backward
compatibility. It would be easy enough (I think) to catch trap #2 and
translate AES/VDI calls into X requests to a server. Digital Research
even provides a product called X/GEM.
 
> by the way: how do games do their thing? i can't possibly believe that
> games use only VDI and AES. i have to believe that they go for lower level
> stuff since speed is critical (realtime). do games run on the TT or on
> special graphics cards? if so, how do they do it?

A lot of games break every time the hardware or OS changes. A lot of games
cause problems in multitasking environments. They're bad examples :-).
 
--
Eric R. Smith                     email:
Dept. of Mathematics            eric.smith@uwo.ca
University of Western Ontario