From: Julian_Reschke@ms.maus.de (Julian Reschke)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Making the screen one line
Date: 14 Apr 92 17:19:00 GMT
Organization: MausNet
X-Gateway: MausGate/News 1.05/beta

William Rosenkranz (rosenkra@convex.com) wrote:
>i was not asking about a portable _GEM_ program, just a portable _TOS_
>program. it appears that these are not necessarily the same thing.

OK, to make things clear. There is NO way to do portable (== portable to
new Atari machines or graphics cards) graphics on the ST/TT other than by
using GEM.

You ask for portable ways to do graphics without using the operating
system. There are no such ways.

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

(1) The frame buffer used by the graphics hardware is not necesseraly
    accessible from the CPU.
(2) Even if it would be accessible: you can't access the screen RAM
    without knowing how it is organized.

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

As far as the 'original' GEM philosophy is suitable to drive such hardware
(if you carefully read the VDI manual, you won't find any mention of how
to get the 'screen address').

>so is there a method to find this address for every graphics card (even if
>different for every card)?

No.

>and why is _v_bas_ad not what it is supposed to be?

Because it's not possible.

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

Nobody guarantees that for other hardware. it could also be in the lower
right corner.

>is it possible to tempararily install a different screen driver?

No, because the screen driver is used by the AES and in order to replace
the driver, you'll have to close it first (perhaps this can be done during
resolution change).

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

GEMDOS, BIOS, XBIOS and Line-A are _all_ different operating system
layers. Why do you think they are all invoked by different
traps/exceptions?

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

Yes, that's what I think.

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

It's obvious that it is better to access files with GEMDOS (rather than
BIOS or XBIOS). Why isn't it obvious that using VDI is better than writing
directly to the screen?

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

Both are in, but only for the TT's native graphics modes.

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

OK, that's a different topic. But you asked about portable ways to do
graphics on TOS systems. Do you remember?

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

Most don't.

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

Rwabs() is documented. Line-A is documented. I don't see the difference.

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

Why would you want portable Atari applications when you don't
think that Atari's going to stay for the next years?

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

Wrong. Novell/DR stil makes X/GEM (on top of FlexOS) and believe it or
not, they care about existing Atari programs (if you don't believe me:
contact Digital Research Monterey).

>and X is (all workstations and above, more than likely unix PCs en masse
>soon). the world wants open systems.

GEM has still significant advantages (Bezier stuff, device indepandence when
it comes to printing...). X has advantages, too. With Multi-TOS, you can
write a X driver that allows X programs and GEM programs to coexist on the
same screen.

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

You can put a self-made SCREEN.SYS in your ASSIGN.SYS file. But the
workstation remains open as long as the AES runs, so -- normally -- you
can't replace it once it is started.

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

Fine. Then, there's no problem to write these functions with VDI.

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

How?
Newsgroups: comp.sys.atari.st.tech