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

William Rosenkranz (rosenkra@convex.com) wrote:
>while we are on the subject of portability, is using Physbase() to twiddle
>pixels considered portable these days?

That depends on what you understand 'portable'. A truely portable GEM
application may not call anything but AES and VDI functions for graphics.
In particular, it may _never_ write directly to the screen (and there's no
GEM call to find out where the screen is). 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).

>it is a documented Xbios function. what about _v_base_ad ($44E)? again a
>documented "guaranteed not to change" system variable.

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

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?

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

>if not, why? please don't tell me "because some add on graphics cards only
>grok VDI". they are the ones breaking the rules as i see it if this is the
>case.

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

>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 believe MiNT still defines Physbase() in <osbind.h> (correct me if i am
>wrong) so that this should work under MiNT at least.

OK. Let's say that you indeed get a 'screen pointer' (which isn't true
with some cards). How do you use this information? You have no guaranteed
ways to find out about the plane format (unless you don't want to support
anything that has a different format than the standard shifter format).

>what does the TT developer's docs say about Physbase and v_base_ad? are
>these ok? does this function and variable exist in the TT TOS? in the same
>location as other TOS versions?

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.

>since it is doubtful that i will ever have a TT or add-on graphics card, i
>really could care less for my own use. however, if i could make a program
>portable with relatively little effort, i'd like to know. otherwise, i will
>stick to accepted/sanctioned 1990 and earlier programming practice (line A,
>Physbase, etc).

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.

>i can understand not using line A since the TT does not support it (eventho
>this has previously been condoned by atari, even encouraged [see Dec 17,
>1989 S.A.L.A.D. docs]). not having access to Xbios or system variables is
>just plain unacceptable in my book. these were something we were supposed
>to be able to rely on from 1985 onwards. progress is one thing. major
>changes to common (at least by me) programming practices is another.

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

>what are the acceptable methods of changing system fonts, without GDOS or
>equivalent?

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 the VDI functions work without GDOS?

Yes (most, some restrictions apply).

>is there any way to change fonts in a portable way without GDOS or VDI?

As long as you want to output the font via VDI: no.

>how are fonts loaded on the TT?

With GDOS. The same way as on all TOS machines.

>does it come with GDOS or equiv?

No.

>does the TT have a termcap-like capability? vt52/vt100?

Exactly as a normal ST.

>in lieu of all of these methods, can someone post self-contained, portable
>routines to draw lines and set pixels? something like:
>
>        void draw_line (int x1, int y1, int x2, int y2);
>        void set_pixel (int x, int y, int on_off);
>
>i don't want to open a workstation anywhere else in the code. doing this
>with both line A and Physbase is trivial, well documented, localized to
>small areas of code, and fast. i am thinking monochrome, but a color
>solution would also work. can these be implemented like this:
>
>        void set_pixel(int x, int y, int on_off);
>        {
>                open_worstation();
>                do_pixel(x, y, on_off);
>                close_workstation();
>        }
>
>ie contain all the VDI functions in one routine.

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

>i realize this would otherwise be painfully slow, but at least a check can
>be made for "standard" config to bypass the VDI trash. this means that the
>workstation would be repeatedly openned/closed each time graphics were
>needed. text could be positioned with normal vt52
>(curses/termcap/whatever).

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.

Hope that helps.