From: rosenkra@convex.com (William Rosenkranz)
Subject: Re: Making the screen one line
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Sun, 12 Apr 1992 19:18:37 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

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 might even some day
>graphics cards where you can't access the frame buffer from the CPU at all
>(like cards that connect to the SCSI bus, as on the Mac).

there also may not be GEM any more. how far do you want to carry the future
argument?

>_v_bas_ad is guaranteed to point to the start of the physical screen
>memory on the system. But this is a low-level call. With a graphics card
>installed, it might point to a _different_ screen that is visible to the
>user (in particular to the built-in). Or it might really point to the
>screen, but you don't have any information about size and format...

so is there a method to find this address for every graphics card (even if
different for every card)? and why is _v_bas_ad not what it is supposed to
be? as i read my docs, they all say this is the address of the screen. if
i write to this address, i should get something in the upper left corner.
is it possible to tempararily install a different screen driver?

>Come on: using XBIOS or Line-A for graphics is simply wrong. You should
>never mix different OS layers, and you should always try to use the highest
>level (in application programs). You wouldn't use Rwabs() to access files
>on your harddisk, or would you?

i am not mixing layers. i am using GEMDOS and XBIOS only. if you like,
i can trash GEMDOS and just use BIOS and XBIOS (tho without GEMDOS, file
access would be for all intents impossible). i won't even use line A.
and no, there is a function to access harddisk via the file system provided
by GEMDOS. i have a choice, and in that case choose simplicity (Fopen).
i also have a choice with graphics (Physbase, Line A, VDI) and i also choose
simplicity here as well. do u really consider GEMDOS/BIOS/XBIOS to be
different layers? i agree that VDI is a different layer and AES is, too.

>It's sad that there are no clear words from Atari about that. But it's
>obvious.

agreed. but NOT obvious. how can it be obvious if there are no clear words?

>Please understand that some features of the low-level graphics interface
>simply can't apply to graphics cards (like the assumptions that Line A
>does about the max. number of planes (4) or the organization into
>bitplanes).

in this case, i could tailor my programs with switches like "-display 640,400"
and "-planes 4". this would allow "normal" users (with "standard" monitors)
and "special" users (with funky stuff) to all use the program. the alternative
is to simply write for myself. if i ever again plan to write a commercial
product, of course i would approach this differently.

>>will either of these work on a TT?
>
>Be assured that all cards that plug into the VME bus work fine with their
>drivers on the TT.

i was refering to Physbase and Line A. i think the latter is out, but does
the TT support Physbase?

>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.

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?

>If you are just programming for your own, do what you want to do. But
>using Line-A or XBIOS for graphics is just silly. Remember the Rwabs()/
>filesystem example.

this is an apples to oranges comparison. nobody accesses disk normally
via Rwabs since there already is a documented file system. there are also
multilayer graphics support that many people use, right or wrong. only at
least they are documented. you can't fault someone for writing this way,
except perhaps to say they are nearsighted. and i'd agree. however, it
is just as nearsighted to look at GEM as the future. it is not. if atari
does not have X in the next few years, i'd say they'd be out of business
since GEM is not an open system (atari is really the only one doing GEM
these days) and X is (all workstations and above, more than likely unix
PCs en masse soon). the world wants open systems.

>It's Atari's fault that they don't manage to tell the programmers about
>good ways to do things. But we _have_ to get rid of these interfaces;
>simply because they can't work correctly with modern hardware (new chips)
>or new software (multitasking).

don't get me wrong. i do agree with you in principle. only i don't think
we are yet going in the right direction. i don't think GEM is the right
direction. about the only thing GEM gets you these days is a somewhat
quicker understanding of the concepts behind X (events, windows, widgets,
etc). that is a big step from stdin/stdout.

[ about changing fonts ]
>There is no documented way. If you _really_ want to do this, put it into
>a small utility program, not into an application (btw: you can do it by
>_replacing_ the screen driver, NVDI does this).

do you have any more info on the screen driver? i can't recall how this
is done. this sounds interesting. can the screen driver be changed and
then changed back, say during program execution? i understand the multi-
tasking implications...

>Well. Why would you want do to that. Why not just open the workstation on
>start and close it when the program terminates?

yes, of course. i realized this would be as compartmentalized after i hit
"send".

>Nope. You can't mix BIOS/GEMDOS text output with graphics. You have _no_
>information where BIOS and GEMDOS output goes. With Gemini or MW, it might
>go into a window. The 'console' is not necessarily identical with the
>(full) screen you can access with VDI.

no, but you could mix GEMDOS/BIOS with XBIOS, if you know the screen address.

>Hope that helps.

certainly. thanx. i think i am going to see how far i can get with MiNT
and MGR. so far, MGR seems somewhat fragile. only thing is i have to
MiNT-ize an awful lot of code i wrote under TOS. note that i am not GEM-shy.
i have written a large GEM application (60k lines) several years ago. i
just find it exceedingly tedious, difficult to debug (i am a "printf" sort
of debugger :-), especially when i have so little time these days for
"recreational" programming...

-bill
rosenkra@convex.com
-- 
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: rosenkra@convex.com