



                        ATARI TECHNICAL POSTINGS

                                1988/89




This volume is a collection of postings to Usenet by Atari's technical
staff from November '88 through to October '89. Earlier postings, and
those from November and December '89 are unavailable. Postings from
1990 are available in ATARI_90.TXT.

The majority of these postings come from Allan Pratt and Ken
Badertscher, Atari systems software engineers. They are primarily
concerned with TOS, with various definitive answers to common problems
developers run in to, and advice on How You Should Do It. These are
often a useful supplement to the official developers documentation.
Those postings more to do with Atari policy and operations have been
ommitted. Note that "opinions expressed do not necessarily reflect
those of Atari Corp".

I hope this is of use to you. Share and enjoy!

Stephen Hebditch.


------------------------------


Date: 14 Nov 88 19:25:34 GMT
From: Allan Pratt
Subject: Re: Fdatime under Laser C

In article <992@ncar.ucar.edu> bovet@hao.ucar.edu (Ray Bovet) writes:
> I'm having a terrible time trying to get Fdatime to modify
> a file modification time and date stamp using Laser C.

Fdatime had some problems in TOS 1.0 and 1.2 -- it's been changed for
TOS 1.4 to be more sane.  I don't remember exactly what the problem was,
besides the documentation having the arguments wrong...  The new Fdatime
doesn't write to the disk at all: it writes to the open-file data
structure, which gets written to disk when you close the file.  This
means that checking your write with Fsfirst won't work, because what's
on the disk won't get updated until the file is closed.

The correct usage is:

        Fwrite(timebuf,handle,flag);
        int *timebuf;           /* ptr to two ints: time & date */
        int handle;             /* handle of file */
        int flag;               /* nonzero to write from timebuf */

If 'flag' is zero, the file's date & time are copied into the two ints
at timebuf.  If 'flag' is nonzero, the ints at timebuf are copied into
the file's date & time fields.  Since the date & time are updated each
time the file is written to, you should make this call immediately
before closing the file.


------------------------------


Date: 17 Nov 88 18:24:07 GMT
From: Allan Pratt
Subject: Re: illegal instructions

In article <881116021045.085584@DOCKMASTER.ARPA> Cothrell@DOCKMASTER.ARPA writes
> Well, I just tried to get cute and replace the 68000 in my 1040 with a
> 68010.  Didn't work.

No kidding.  The 68010's stack frame format for all exceptions is
different from the 68000's.  This means there is an extra word between
the stack pointer and the arguments to a GEMDOS, BIOS, or XBIOS call
made from Super mode.  It is possible to write code which deals with
this situation, and in fact it's been done here by way of prototyping,
but at this point it isn't planned for TOS 1.4.


------------------------------


Date: 15 Dec 88 21:43:48 GMT
From: Allan Pratt
Subject: Re: NULLFILL

In article <8812150429.AA21699@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET
(JOHN ZAFIRIS) writes:
> For those of you following the NULLFILL vs. FATSPEED saga:  The
> incompatibility can be avoided by using DISKFREE (by Tim Purves of
> Michtron) instead of FATSPEED.  DISKFREE seems to do things more
> 'legally'...   whatever that means.
>                                                   ...John

In the first place, NULLFILL and (FATSPEED & DISKFREE) do different
things.  In the second place, there is no "legal" way to do what
DISKFREE does.  (Note that Zoomracks, at least, doesn't work with it.)

I don't know if FATSPEED and DISKFREE do the same thing or not.

In any case, none of this is necessary with TOS 1.4.  I can't recommend
them even as stopgap measures, but if you want to take risks with your
data, that's your lookout.


------------------------------


Date: 15 Dec 88 21:48:36 GMT
From: Allan Pratt
Subject: Re: bios function 0x7f

In article <3767@druhi.ATT.COM> dlm@druhi.ATT.COM (Dan Moore) writes:
> in article <12076@hall.cray.com>, rosenkra@hall.cray.com (Bill Rosenkranz) say
> > after disassembling a code i found on some bbs which doubles the effective
> > on-screen travel of the mouse form, i found it ixecutes bios function 0x7F
>
>       There isn't a bios function 0x7f.  But it is a useful bios call
> if you intended to patch the bios handler on the ST.  When the ST bios
> or xbios handler receives an illegal function number it returns an error
> code and a pointer to the bios/xbios function pointer table.

Great! This is exactly the kind of "It works, so use it" philosophy
which makes it so hard to improve TOS in a backward-compatible way.
Please do not rely on crap like this in your programs.  If you do, don't
expect them to work in the future.  Maybe I should make sure the hack
described above stops working, but I'm not vindictive or petty, so I
won't.


------------------------------


Date: 30 Jan 89 23:05:29 GMT
From: Allan Pratt
Subject: Re: Attaching a CHINON drive to the ST

In article <973@laura.UUCP> scm1817%marvin.irb@unido.uucp (Chris Schmidt) writes
:
> I bought a chinon drive model FB 354 and attached it to my ST.
> Now my ST does not recognize a diskchange with this new drive (it only does
> with write-protected disks)

This is a known problem with some (all?) Chinon drives Atari bought
(and, alas, shipped).  Go back to where you bought it and/or an Atari
dealer to get it fixed or replaced.

You can tell you have the problem by doing this:

        Get into a shell or program (not the desktop).
        Put a blank, write-enabled disk in the drive.
        Get a directory of that drive (a file selector will do).
        Remove the disk, then put it back in (still write-enabled).
        Get another directory of the drive.

If the select light doesn't come on before the second (empty) directory
listing appears, you have the bad drive.


------------------------------


From: Allan Pratt
Subject: Re: Mfpint() and interrupts

In article <8901302240.AA10005@ucbvax.Berkeley.EDU>
ACPS5589@RYERSON.BITNET (George Borges) writes:

> How can I install my own interrupt routine (in C) for the Ring Indicator
> line and the Carrier Detect line?  Currently, my routines DO execute but
> the program bombs (usually two or three of them) immediately afterwards.

You can't do it in C unless your compiler or library have some tricks.
Specifically, C routines end with RTS (return from subroutine) while
interrupt handlers need to end with RTE (return from exception).  MWC
has a library call, I think, which arranges for the calling procedure to
end with RTE rather than RTS -- I think it plays games with the stack to
achieve this.  Check their documentation.

However, the problem goes even deeper.  Interrupt handlers must not
change any registers (except SR; that's on the exception frame).  Most C
compilers can't be told to save & restore *all* the registers they use.

Usually, if I *really* want to have the exception handler in C, I have a
little assembly language to save registers, call the C procedure, then
restore the registers and RTE:

        _ring:  movem.l d0-d2/a0-a2,-(sp)       ; alcyon clobbers these
                jsr     _myring
                movem.l (sp)+,d0-d2/a0-a2
                rte

Then use "extern int ring()" and "Mfpint(xx,ring)" to install it.

Better still, do the installation in assembly, so you can read & store
the old handler's address, and restore it when you leave.  Mfpint
(foolishly) doesn't return the old value of the vector, so you can't use
it to save & restore things.


------------------------------


Date: 7 Feb 89 01:50:58 GMT
From: Dan Scott
Subject: Re: TOS 1.4

in article <5321@homxc.ATT.COM>, dmk2@homxc.ATT.COM (D.KUSTER) says:
>
>
>
> A friend of mine just got the floppy version of TOS 1.4 and is having
> some problems making it work.  The disk has 2 files on it; TOS.IMG,
> and COLDBOOT.PRG.  In typical ATARI fashion the documentation describes
> what the changes are but not how to use the new version.  Running the
> COLDBOOT.PRG causes a reboot and the old TOS installs.  If he puts the
> program in an auto folder it causes "infinite reboots".  He has tried
> all possible combinations of .IMG file and COLDBOOT program in either
> root directory or auto folder with no luck.

You're right, COLDBOOT.PRG only re-boots the system.

>
> Question 1 - is it possible that you have to remove the old TOS ROMS
>              from your machine before the software version will load?
>          Does anyone know how to use this software version of TOS1.4?

No, that is not necessary when booting a RAM loaded copy of TOS 1.4
In order to use the TOS 1.4 disk, you mearly need to have it in drive
A: at power-on time for the computer.

>From the sound of it, your friend has an incomplete disk.  The disks that
are packed out of Developer Support have an AUTO folder w/ some HD
files needed, a disk caching program, the SPR folder w/ the SPRgen
program and of course TOS.IMG and COLDBOOT.PRG.  There is also an
active boot sector on the disk.

If your friend is a registered developer (which he should be in order to
have a copy of the OS at this point) then he should call Developer Support
for an immeadiate replacement disk.  Dev/Sup is the only place that
*REAL* updates to TOS 1.4 should be comming from.

>
> Assuming he can get the floppy version of TOS1.4 to work, my friend would
> like to attempt to make ROMS of TOS1.4.

Making ROMs out of the RAM loaded TOS 1.4 will not be supported by Atari
corp. in any fashion.  TOS 1.4 is still in beta test and updates are common
at this point.

>
> Question 2 - Can this be done using the TOS.IMG file?  How?
>

You do not use the TOS.IMG file, there is a boot sector on each TOS 1.4
disk shipped from Atari that calls in and runs the .IMG OS file.


------------------------------


Date: 15 Feb 89 22:38:36 GMT
From: Allan Pratt
Subject: Re: TOS Error 35 with mx2?

This is the second attempt at this posting...

One way to get TOS ERROR #35 is to double-click something with a
type of .TOS .TTP or .PRG which is not in fact a program, or which
is garbled, or truncated.  GEMDOS gives the error EPLFMT: invalid
program load format.  The Desktop says "TOS ERROR #35."  I don't
know why, and I don't know if this is the only way to get that
error message: there may be other ways.


------------------------------


Date: 16 Feb 89 19:35:58 GMT
From: Derek Mui
Subject: Re: TOS Error 35 with mx2?

in article <5440014@hplsla.HP.COM>, andyc@hplsla.HP.COM (Andy Cassino) says:
>
> .........
> (I have encountered TOS error 35 with other PD programs on my Mega. A copy of
> twister that runs on a 1040 won't run on my Mega).
>
> Has anyone got mx2 running on their Mega (or 1040)? Can anyone explain the
> meaning, if any, of TOS error 35?
>

    When the AES's shell launches a program ( by doing the Pexec() ),
it will check for certain error conditions.  Currently it checks for -33,
-34, -35, -36, -39, -41, -42, -46, -47 and if it matches, it will bring up
appropriate alert boxes to inform the users.

    The rest of the errors will be shown as "TOS error XX." The error
number XX is equivalent to the MSDOS error number as -32 is equal to 1,
-33 is equal to 2 and so on.  In this case, "TOS error 35" indicates there is
a GEMDOS error -66.


------------------------------


Date: 22 Feb 89 18:05:58 GMT
From: Allan Pratt
Subject: Re: Mfpint()

In article <336@wn2.sci.kun.nl> sommel@wn2.sci.kun.nl (Ron Sommeling) writes:
> In article <825@per2.UUCP>, dag@per2.UUCP (Daniel A. Glasser) writes:
> >
> > Although, technically, you can call BIOS and XBIOS functions from interrupt
> > level routines, it is not a good idea in general.  It is better to set flags
> > for the application "user-mode" routines to deal with.
>
> No, you can't safely call any BIOS or XBIOS function from within an
> interrupt.

That is not the case.  You CAN call BIOS or XBIOS routines from
interrupts.  The way to do it is documented (in the documentation, of
all places, not the disassembly!).  You subtract 46 ($2e) from the
system variable 'savptr' which is at $4a2.  THEN you use the TRAP
instruction.  When the trap returns, you add $2e to savptr again.

With this approach, one can write a BIOS call in C, because when the
dispatcher calls the [X]BIOS function, the arguments are right on the
stack, just as virtually all C compilers expect them to be.  A couple
of BIOS calls *are* written in C, notably Rwabs().

I don't know that I'd have made this decision if I'd designed the BIOS,
but it does work, and it *is* reentrant, if you do what the
documentation says to do.

THIS IS NOT AN ENDORSEMENT OF USING BIOS FROM INTERRUPT LEVEL.  If you
find your program is doing that, re-think your program.  There are not
very many reasons to call BIOS like that, and a number of reasons not
to: speed is the most important.  Furthermore, NEVER ATTEMPT PRINTER OR
DISK I/O FROM INTERRUPT LEVEL, because aside from the time it will take,
timers and things aren't running.


------------------------------


Date: 7 Mar 89 00:53:18 GMT
From: Ken Badertscher
Subject: bconinning

This is a reply to a mail query I recieved regarding hooking into the
system console input routines.  Basically the question boiled down to:
"How do I do something at the BIOS level before GEMDOS gets ahold of an
input character?"

================

As you may have guessed, GEMDOS gets all its character input by trapping
into the BIOS.  Not only that, but (thank goodness) the BIOS has a RAM
based jump table for its* character IO, and it actually uses that jump
table.

Starting at $51e, there are four sets of 8 vectors for character device
functions, as follows:

*--- "soft" console vectors
xconstat:   ds.l    8    ; (51e)  console status vectors
xconin:     ds.l    8    ; (53e)  console input vectors
xcostat:    ds.l    8    ; (55e)  console output-status vectors
xconout:    ds.l    8    ; (57e)  console output vectors

Each set of vectors consists of the addresses of the routines that
handle the BIOS character devices (in the following order):
0 - lst: (printer)
1 - aux: (rs232)
2 - con: (screen)
3 - midi
4 - keyboard (output only)
5 - raw console output (bypass vt52 pressure cooker)
6 - reserved
7 - reserved

and, as comments in the BIOS source indicate:
* No range checking is performed.  If a bogus device number
* is passed to the BIOS' character I/O handler, the system
* will crash or become funky duex.
*
* BIG BUG: ikbd and midi output status are reversed.  Sorry, kids.
* For compatibility, we won't fix it.  (But we should!)

Armed with all that information, you should probably be able to do what
you need at BIOS level by replacing the built-in input and input status
routines with your own.


------------------------------


From: Ken Badertscher
Subject: FATAL TOS 1.4 ERROR!

 (heh, I figured that title would get your attention... ;-)

 When somebody showed me what ST Report had to say about TOS 1.4 in the
latest issue, I just about fell out of my chair.  Something about a
"fatal hard disk error" that was corrected by Leonard Tramiel and myself.

  For those of you who don't know who I am, my name is Ken Badertscher,
and I'm a TOS software engineer at Atari.  In fact, for the past six or
eight months, I've been the guy who puts all the various parts of TOS
together and burns the result into EPROMS for us to test here at Atari.
I've also worked on many of the later enhancements that went into TOS
1.4, in the BIOS, Desktop and AES, primarily.

  The last thing that was holding up approval for TOS 1.4's release to
manufacturing a couple of weeks ago was a bug that bit Leonard Tramiel
(VP of Software at Atari).  Leonard had been running his system for
quite some time with a hard disk that was literally on its last legs --
it had several* hardware problems, as well as media problems, but he had
a lot of old stuff on it and never bothered to move it off to a
different disk.  It's too bad that he didn't, because a VERY OBSCURE bug
in TOS reared its ugly head, and sent his hard disk data into oblivion.

   Now before everyone starts to panic and think that TOS is going to
thrash their hard disk, I want to make something very clear:

  THE BUG IN QUESTION IS *VERY* RARE AND ONLY SHOWS UP IN
              EXTREMELY RARE CIRCUMSTANCES!

   Now that I've made that perfectly clear, on with the story.  Allan
Pratt looked into the guts of GEMDOS, the part of TOS that handles
files, and after a lot of looking, reconstructed the weird circumstances
that caused Leonard to lose his hard disk data.  Allan fixed the bug.
In fact, this whole episode started back in December, and Allan fixed
the bug in December.  Leonard wasn't convinced that it had been tested
thoroughly, however, so he was reluctant to proceed with releasing TOS
until it had been tested thoroughly.

   So, after weeks of writing test code, and trying to reconstruct the
problem that happened to Leonard, and performing extensive autopsies on
his hard disk, and running test programs for days at a time, I finally
concluded that the bug was fixed.  Not only that, but I cleared up
another minor inconsistency in the way GEMDOS deals with deleting files.
(Actually, I just discovered it; Allan finally upgraded the code).

  In conclusion, I'd like you to all remember two very important points.
NUMBER 1: The bug that bit Leonard has been around in GEMDOS since DAY
ONE.  If this were really a "FATAL ERROR" that could regularly cause
problems, IT WOULD HAVE BEEN FOUND AND CORRECTED A LONG TIME AGO, AND A
LOT MORE PEOPLE WOULD HAVE REPORTED THE PROBLEM.  In point of fact, it
was a very unusual bug, and to his immense credit, Leonard is such a
perfectionist that he would not allow TOS 1.4 to be released even with
such a obscure, rare bug in it!  NUMBER 2: ST Report reported that this
bug was fixed in the FEBRUARY 24 version of TOS 1.4.  In point of fact,
the FEBRUARY 24 version of TOS does not exist.  As you recall, I am
currently the person at Atari who builds these things, and I never built
a FEBRUARY 24 version.  You can rest assured, however, that the FINAL
RELEASE of TOS 1.4 will be as bug-free as we could possibly make it.

  The moral of the story is:
   Don't believe everything you read in the press!


------------------------------


Date: 12 Mar 89 03:47:21 GMT
From: Mark O. Jansen
Subject: Re: TOS 1.4 vs NEODESK and UIS-II

in article <418@ultb.UUCP>, clf3678@ultb.UUCP (C.L. Freemesser) says:
>
> I'd KILL to have TOS 1.4 in my machine to fix all the nasties I've got
> now.  But I will never see it in my machine (assuming Atari's track
> record for upgrading older machines doesn't change).


Everything I have heard has said that Atari _is_ planning to make TOS 1.4
available to owners of existing machines.  TOS 1.4 is a very different
animal than the 4/22/87 ROMs.  The main point of 4/22 ROMs was the support
for the BLiTTER.  TOS 1.4, on the other hand, is a significant upgrade even
_without_ a blitter; it makes sense to make it available to everyone.


------------------------------


Date: 13 Mar 89 20:42:22 GMT
From: Allan Pratt
Subject: Re: TOS 1.4 vs NEODESK and UIS-II

In article <418@ultb.UUCP> clf3678@ultb.UUCP (C.L. Freemesser (709ITP)) writes:
> If the size of the program is too big for the 256k chips we use now,
> Atari could:
>
> 1) Put out a smaller version (if this is possible) to fit into our
>    machines.

TOS 1.4 certainly DOES fit in 192K (the ROM space for all STs), and you
CAN upgrade a 520 or 1040 or Mega-2 or Mega-4...  I don't know why you
think you can't.

Some newer Megas have only two ROM chips, but that's because those two
parts are cheaper than six parts.  The addressable ROM space is the same
for all current ST machines: 192K.  The six-chip sets have 256K *bits*
per chip, or 32Kbytes, and 192K is 32K times six.  The two-chip sets
have 1024K *bits* or 128Kbytes per chip, 256K total ROM space, but the
ST can only address 192K of that.

TOS 1.4 will be available in both two-chip and six-chip sets, and can be
put in all machines.


------------------------------


Date: 27 Mar 89 00:52:36 GMT
From: Ken Badertscher
Subject: Re: 2K of disk space lost?

In article <2228@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes:
| [...] I would also like to see the desktop diskcopy function copy disks
|with 10 sectors per track.

  The TOS 1.4 Desktop will copy arbitrary format disks.  As long as you
feed it a destination disk with the same format as the source, no problem.


------------------------------


Date: 27 Mar 89 00:34:54 GMT
From: Ken Badertscher
Subject: Re: GDOS font format

The unsigned int font_seg variable which was (unfortunately) included in
some GDOS documentation does not belong there.  It is an internal
variable which is only used by GDOS.  Actual font headers on disk should
end after the "next_font" longword.

  One other thing you should know about GDOS fonts... the font data is
NOT guaranteed to be contiguous with the end of the header.  Whether on
disk or in memory, pointers/offsets are provided in the font header.
Use them!  (Except the memory ones... you really should leave the
manipulation of font data loaded in memory up to the VDI...)


------------------------------


Date: 26 Mar 89 23:42:18 GMT
From: Ken Badertscher
Subject: Re: News from CeBIT '89

In article <8903201139.AA00599@ucbvax.Berkeley.EDU> VBRANDT@DBNUAMA1.BITNET
 writes:
|...
|BTW: Maybe someone at Atari could tell us (many people in Germany already use
|this ROM version, so I use plural) if the abovementioned version does/does not
|include the 'rare fatal TOS 1.4 harddisk bug' Ken Badertscher told the net
|about a few digests back.

  Most Definitely Not.

  The German TOS release is exactly the same as what is being made for
France, Switzerland, USA, Canada, UK, etc. etc.  This is very much
the most bug-free TOS version yet.

  If we knew of any serious (or even small!) bugs, it would not have
been released!  That was the point of the "Fatal TOS 1.4 bug" message.
That, and correcting the incorrect TOS version date from ST Report.


------------------------------


Date: 27 Mar 89 00:49:05 GMT
From: Ken Badertscher
Subject: Re: desktop.inf

In article <435@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
|
|is there a ** legal ** way of obtaining the current desktop.inf information
|in memory.

As someone mentioned, there is the shel_get call.  However, it only
returns the address of the AES internal buffer which is sometimes used
to store DESKTOP.INF data, ***AND*** the format of that buffer is
SUBJECT TO CHANGE WITHOUT NOTICE.
  In other words, don't try to use what you find there, or your software
will surely break in the future.

|what i am wondering if it is possible to get the current window
|search mask information in memory, and being able to alter it at will. This
|would allow the window to search not only *.*, but also *.c, *.o, or anything
|that your heart desires. [...]

While that is an admirable goal, it is NOT a good idea to go peeking
around in the AES' private variable space.  The AES and Desktop are a
very tangled intertwining convoluted piece of work, and you stand a very
good chance of breaking something before you would add a useful
enhancement if you tried to modify the way the Desktop handles window
templates.  This feature is, in fact, on the slate for the next revision
of the Desktop!  In the mean time, might I recommend that you try
NeoDesk from Gribnif Software.  It has the "window template" feature,
and a host of other enhancements that Atari just didn't have room for in
192K worth of ROM space.


------------------------------


Date: 27 Mar 89 00:27:57 GMT
From: Ken Badertscher
Subject: Re: setenv on boot-up (how?)

Dale posts some very useful code for dealing with environment variables.
However, the part of the code that deals with the TOS environment will
hopefully be obsolete very soon.  The fact that there is a null after
the PATH= in the default TOS environment string is an anachronism left
over from a bug in earlier TOS versions, to wit; the BIOS variable which
holds the value of the boot device was used as a WORD instead of as
a BYTE when filling the startup environment string, hence you get a null
before the drive letter.
  This is not standard, nor should it be construed as a "TOS" format
environment.  The easiest way to check for the default environment is
with a couple of longword compares (look for "PATH" then
"=;\0<bootdev>" <- really four characters there, =, ;, <null>, A or C  ).
GEMDOS environment strings are:
    ...a series of null-terminated strings of the format
    "VAR=value"; the last string is followed by two zero
    bytes, indicating the end of the environment.
                        - Pexec Cookbook
Which is to say, they follow the somewhat universal environment string
standard, a'la UNIX(tm) or MS-DOS(tm).  The fact that semicolons were
required to separate path names was an oversight as well; TOS 1.4 allows
commas or semicolons to separate pathnames in the PATH environment
variable. In fact, the AES now uses the environment much more
intelligently, and will look down whatever paths you have specified for
shel_find and rsrc_load calls.

   Hopefully someday I'll get to release the auto/accessory environment
setting utility that I've written; I think people will like being able
to stick their resources all in one folder...


------------------------------


Date: 26 Mar 89 23:14:07 GMT
From: Ken Badertscher
Subject: GEMDOS Extended Argument Standard

Please excuse the length of this message (nearly a hundred lines -
sheesh!) but I consider Atari's role in setting software standards
fairly important...

  Since I'm taking over the mantle (or is it a yoke? <yuk yuk>) of
maintaining GEMDOS, I will be intimately involved in the pending
(admittedly belated) adoption of a standard for extended argument
passing in TOS.  It is a major concern of mine, for a couple of
reasons:
  - Two (or more) de facto standards exist
  - The proponents of these standards seem to have some emotional
    involvement in whose standard is best:
    "Since they (MWC) are bigger than I am..." Mr. Beckemeyer ;-)
    "Oh, I wish I had known about this conclave!" Mr. Schumacher ;-)
    "<expletive deleted>!" David Parsons ;-) ;-)
  - GEMDOS enhancements are coming that will require a robust means of
    passing lots of information between parent and child processes

  In fact, we have discussed this recently at Atari.  It came up because
of a bug in Gulam, which does something strange with the command line
length byte.  The MWC extended argument scheme not only puts extended
arguments in the ARGV environment variable; it also puts a length byte
of 127 into the command line.  Normally, this is no big deal, because a
command line string is null terminated anyways.  Even if a Pexec caller
passes a command tail that is not null terminated, GEMDOS makes sure
that the trailing null is there in the command line part of the basepage
of any process that it creates.  If, however, a program uses a command
line length byte that is unreasonable (like 127), that program is going
to have problems.  GEMDOS does nothing at all with the length byte
passed in a Pexec command tail except copy it along with the rest of the
command tail into the child's basepage.

  To quote the Pexec Cookbook (yes Virginia, there is a Pexec Cookbook),
the command tail string is a "null-terminated Pascal-style string."
This means that the maximum theoretical length of a GEMDOS command line
is 126 bytes (128 bytes in the basepage minus length byte minus null
terminator).  In fact, the *actual* maximum length of a GEMDOS command
line is 125 bytes, because that's the maximum number of bytes that
GEMDOS will copy into a command line when it creates a process during
Pexec.  Unfortunately, I didn't get that little tidbit into the Pexec
Cookbook before it went out.

  The upshot of all this is that it is* possible for a process to know
if the ARGV in its environment is meant for it and not left over from
one of its MWC/Manx/MT-C Shell spawned ancestors.  If its command line
length is something unreasonable, a program can take that as a clue that
it should go sniffing around in its environment for more information.
One can only imagine the multitude of meanings that could be assigned to
bytewise-negative command line lengths...

  HOWEVER...

  I still have problems with both ARGV and xArg command line extenders.
This whole iovector thing bothers me.  David Parsons came up with a
nice, clean isatty() that works just fine without cluttering up ones
environment with ???????'s.  As far as I can see, the iovector is not
necessary, nor does it belong in a scheme for passing arguments.  And as
Dale et. al. said in the xArg proposal, it "makes a mess of the
already confused environment string."  XARG also bothers me, because it
means that a child has to muck with its parent's address space.  Can you
say "virtual nightmare"?  Not only that, but XARG.xparent (pointer to
parent's basepage) is a needless duplication of information that a
process can get from its own basepage (although I guess it could be
useful for an extra level of verification).  And again, needless support
for the iovector string.  And both methods *require* the startup code to
search the environment for extra commands that may not even be there.

  Currently, I'm leaning towards the ARGV method with the iovector
yanked, a negative byte value for the command line length to flag it,
and a different name for the environment variable.  This saves
applications from needlessly hunting through their environments (if the
length byte isn't negative), and applications that don't understand the
significance of the negative length byte will get what they can from the
125 bytes that GEMDOS gives them.  Since the dLibs don't use the
iovector anyways, it only entails a small startup code change for them.
If the name of the environment variable is different, library code which
uses the iovector from ARGV can still do it, but I STRONGLY recommend
that people who are using iovector strings fix their libraries to use a
safer isatty().

  I am not formulating a standard on a Sunday afternoon, though.
I'll let this percolate through the net for a week or three, and see
what bounces back.  From here and other sources, we'll come up with
something that everyone can at least live with.  And to those of you who
have been bemoaning the lack of "strong Atari involvement" in matters
like this, I have but one thing to say:
    Be careful what you wish for, you just might get it!


------------------------------


Date: 28 Mar 89 23:59:08 GMT
From: Allan Pratt
Subject: Re: Problem with TOS recognizing media changes

In article <3938@druwy.ATT.COM> dlm@druwy.ATT.COM (Dan Moore) writes:
> Unfortunately many drives do not return valid write protect
> status for several milliseconds after they are selected, which is many
> times longer than the vblank code takes.  So these drives have problems
> on the ST since media changes aren't always detected.

Another failure mode is that some drives don't give a valid
write-protect signal when there is no disk present.  This means you can
take out one write-enabled disk and put in another, and the ST won't see
a transition on the write-protect line.

If you MUST use such a drive, have a write-protected disk handy.
Whenever you remove a disk, place the write-protected disk in the drive
for 1 second or so, then take it out again.  In this time, the ST will
detect the transition on write-protect and mark the media as "maybe
changed." When you put in the next (write-enabled) disk, the serial
number will be read, it won't be the same, and media change processing
will commence.

Note that going from one write-protected disk to another, the
write-protect line often doesn't change.  That's taken care of by the
floppy code, too: if the line has not changed from the write-protect
state and the last access was more than 1.5 seconds ago, the media's
state is "maybe changed."

These drives, and those mentioned by Mr.  Moore, are out of spec for the
ST: don't use them.


------------------------------


Date: 31 Mar 89 09:49:43 GMT
From: Ken Badertscher
Subject: Re: Obliterating your boot sector, Part I

In article <2938@brunix.UUCP> rjd@cs.brown.edu (Rob Demillo) writes:
|OK, here I am...peacefully working on a contract program. Suddenly,
|I decide that, for various reasons, it would be a useful thing to
|be able to detect whether GDOS is installed on the user's machine.
|
[stuff about HD boot sector mysteriously disappearing after TRAP #2]
|
|My question is: was this a co-ink-ee-dink, or did the TRAP #2 put
|my Atari into the twilight zone?

Coincidence?  Maybe.  But there is no way that a GDOS Trap #2 inquiry
could waste your hard disk's boot sector.  Got any other evil, insidious
memory resident tools lurking in your system?


------------------------------


Date: 2 Apr 89 02:52:48 GMT
From: Ken Badertscher
Subject: Re: Handling mouse button pushes

In article <8086@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes:
|[stuff about evnt_multi problems monitoring mouse buttons deleted]
|1) Use the documented extended Line A variable to sense the mouse button
|   state whenever it might be interesting.

  A better solution than using line A variables is to use the VDI
vex_butv() call, inserting an interrupt handler of your own which saves
the button states in your local variables and passes off to the original
vector.  After you have installed your handler via vex_butv(), the
system will jsr to your code any time the mouse buttons' state changes.
When you are done updating your local variables, you should jump through
the vector that was returned by vex_butv() so that the system gets the
button state change information as well.

  This is just a pet peeve of mine; people tend to indiscriminantly use
the line-A variables rather than the VDI calls that are there.  In most
cases, it is not necessary (and sometimes dangerous) to use Line A
variables.  In this particular case, even if you're being very
conservative with what you do with button changes, you may run into
problems.  The AES maintains its own button state information
which is independant of the VDI/Line-A variables, and it is possible (if
you aren't careful) to get "out of sync" with the AES.

  Good luck with your button handling code, Stephen!


------------------------------


Date: 2 Apr 89 14:31:48 GMT
From: Ken Badertscher
Subject: Pexec Cookbook, and pseudolegal system calls...

  Several people have asked how to get the Pexec Cookbook.  It is
available to registered developers, who can find it in the usual online
places.  It will also be included with the TOS 1.4 release notes, which
will be sent to all* registered developers.  It is also being folded
into the developer documentation, so if you buy that documentation, you
can get it that way too.  Complete Atari ST developer documentation (not
schematics, they are available seperately) is available from Atari Corp.
for $100.  If you're looking for "real" ST documentation, this is the
first and best place to get the inside facts.  Believe me, you get quite
a stack of documentation for your hard-earned C-note!

================

In article <1409@atari.UUCP> I wrote:
>As someone mentioned, there is the shel_get call.  However, it only
>returns the address of the AES internal buffer which is sometimes used
>to store DESKTOP.INF data, ***AND*** the format of that buffer is
>SUBJECT TO CHANGE WITHOUT NOTICE.
>  In other words, don't try to use what you find there, or your software
>will surely break in the future.
 ...
>it is NOT a good idea to go peeking
>around in the AES' private variable space.  The AES and Desktop are a
>very tangled intertwining convoluted piece of work, and you stand a very
>good chance of breaking something before you would add a useful
>enhancement if you tried to modify the way the Desktop handles window
>templates.

Ignac Kolenko writes:
 if the shel_get() call returns values which are *internal* to the desktop
 only, then why, oh why, is this call sitting around for us programmers
 to use???????????????? The tos 1.4 developer docs do not say that there
 is anything inherently wrong with using shel_get()!!! (i had to phone
 a friend who has the docs to find out this info)

Quite a few things in TOS are documented and have no useful function.
That does not mean that programmers can or should have carte blanche to
use these features.  Nor should anyone assume that the useless features
will retain the same behavior in future TOS revisions.  It is
unfortunate that the BETA TOS developer documentation was unclear on the
lack of usefulness of the shel_put() and shel_get() AES calls, but that
oversight will be corrected in the final release notes.

  Don't do illegal stuff with your software, please.  We are no longer
constrained to strict software compatibility in future TOS revisions,
and I, for one, intend to take advantage of that fact.  This means that
I will be implementing enhancements which will almost certainly break
software that either a) didn't follow the rules in the first place, or
b) was built on bad assumptions about the internal workings of TOS.

  P.S.  Have a nice day. ;-)


------------------------------


Date: 2 Apr 89 14:46:44 GMT
From: Ken Badertscher
Subject: Re: GEMDOS Extended Argument Standard

Here is a summary of some of the mail & messages I've seen in the past
week regarding the proposed GEMDOS Extended Argument Standard:


David Beckemeyer writes:
------------------------
What about the transition period?  There are a whole bunch of programs
that use the current MWC style ARGV.  MWC programs, and anything
compiled with their libraries use iovector and they don't always work
right when it's not there.  Also I bet even if MWC does implement the
new standard, it will take a while and many users won't change over for
a long time.  This leaves an ever increasing number of programs that
won't understand the new format (and probably won't work right).

The next issue is the idea of the "negative" command tail count.  I wonder
if some startup code might just take the value as 8-bit unsigned and attempt
to grab, say 254 bytes from the tail without checking and maybe bomb out in
attempting it (I've seen programs that do worse).

I don't see how [leaving just the iovector after ARGV] can work, since
the old MWC ARGV is *always* followed by the list of arguments.  If the
the new name has the arguments, you can't put them after ARGV too.


John Dunning writes:
--------------------
I think the scheme you outlined (use the magic env var "ARGV=..." as a
sentinel, and use a negative byte length in the command string) is sort
of ok, but but I'd advocate taking it one step further.  The thing I'd
worry about is old programs (or new programs using startup code that's
not quite 'right' etc) getting their caller's args, if they were spawned
with Pexec(0, foo, bar, 0).

I propose the following extension to your scheme:  When Pexec'ing, and
there's no environment passed to Pexec, instead of simply cloning the
current env, clone selectively, ie copy only up til the magic sentinel.
Do everything else the same, and I think you get all the same benefits,
with less risk of confusing programs that, for whatever reason, aren't
adhering to your new protocol.  You also don't even NEED to assign
meanings for oddball values of the command line length byte if you do
that.

Part of why I suggest this scheme is that I just re-wrote the system()
function for the GNU C lib to do just what I described.


David Parsons writes:
---------------------
  What if the program uses the length byte to figure out length of command
  line tail like so:

    for (length = *(tail)++; length-- > && ....

  ????

  It would be nice to be able to have the extended arguments code also
  be able to handle talking to processes that don't grok extended arguments
  and which don't clear sign-extension on the length byte (which is not
  an unreasonable thing to ignore, because the tail can't be >127 chars.)

 [...] at least xArgs doesn't carry the argument list to all the
 descendants of the process, which is what the Mark Williams `standard'
 does.  [...] The big problem with this is that you will get those
 strings propagated all over the universe, anyway, and if a process
 modifies the environment with putenv(), the ARGV= stuff will be
 scrambled around.

 [and he proceeds to describe just how ugly the argument propagation gets]

 If you're planning to do enhancements to TOS for extended argument passing,
 perhaps it's time to consider the basepage & additional gemdos traps for
 extended argument pexecing?


Pekka Sarnila writes:
---------------------
 if length is say FF the last long (after null) would contain
the pointer to unix like parameter structure. In that case
Pexec would count the length of that structure and allocate
that much more space and copy (and reloc pointers) it to the
new processes memory area.

================================================================

  The transition period is going to be ugly.  No two ways about it.  No
matter what new standard we adopt, we're going to break some software.
If the new scheme is sufficiently different from the old ones, however,
software which uses an older method will continue to work with other
software which agrees with that old method.

  The negative command tail count has been received negatively.  That's
OK, because there's still an "unreasonable" positive command tail
length that isn't in use: 126 bytes.  Remember that GEMDOS only ever
copies 125 bytes from the command tail passed to it in Pexec.

  The various suggestions that deal with changing the behavior of Pexec
are unacceptable for two reasons:
 1) Folks with an older version of TOS would lose big.
 2) We have just finished a TOS revision, and the next one won't be
    complete for quite some time.  I would prefer for this standard
    to be in place before that, so that the Desktop, et. al. can take
    advantage of it.
 It's just going to have to be the responsibility of library startup
code to comply with the new standard.  Period.

  Using the basepage, or additional GEMDOS traps, won't fly either, for
the reasons stated above.

  Finally, let's consider the sticky problem of environment-based
argument strings being propagated all over creation.  There are two
things that GEMDOS copies from a parent when it creates a process.  The
basepage (process descriptor) information, and the environment.  GEMDOS
allocates memory for these, then fills them in.  It would be nice if it
allocated an argv[] area as well, but it doesn't.  The only clean way
that I see to get around that problem is to put the extra args in the
environment.  This causes problems if the args take the form of a
standard argv[] array.
  BUT...
  If the extended argument string is not itself a series of null
terminated strings, the problem solves itself neatly.  getenv() and
putenv() will not confuse the environment, and can in fact be easily
used to pass a lot of args to a child.  The environment arguments should
consist of a regular command-tail style string, with arguments separated
by white space.  That way, arguments can even contain `='!

  So... here's GEMDOS Extended Argument Standard proposal #2:
----------------------------------------------------------------
  If a program wants to pass more than 125 bytes of arguments to a
child, it should create a command tail of (at most) the first 125 bytes
of the "real" arguments, and give it a length byte of 126.  This will
satisfy children which don't understand the extended argument standard.
The program should also place an environment variable called ARGS in the
environment it intends to pass to the child (its own, or a specially
created environment, per the Pexec spec).  The ARGS variable should
consist of the name of the child (argv[0]) followed by a space, followed
by the rest of the arguments (argv[1..n]), separated by spaces.
  The startup code of ARGS-aware programs is responsible for checking
the command line for the magic length byte, then searching the
environment for the ARGS environment variable command line.  It must
copy the ARGS command line somewhere so that it can be parsed into an
argv[] string.  IT MUST NOT BE PARSED IN PLACE, OR THE ENVIRONMENT WILL
BE CORRUPTED.  The startup code can then set the argument count and
argv[] array pointers, and do whatever else it needs to do before
starting up the mainline code.
----------------------------------------------------------------

  Hopefully, some time this week, I will be able to get in touch with
most of the compiler vendors to discuss this plan with them.  In the
mean time, please keep the e-mail coming!


------------------------------


Date: 3 Apr 89 23:26:12 GMT
From: Allan Pratt
Subject: Re: TOS bugs. Disk related.

In article <763@stag.UUCP> to_stdnet@stag.UUCP writes:
> From: omni!emh@stag.UUCP (Eric Hopper)
> Organization: Omnifarious software.
>
>     When using a shell program on the ST, I can't seem to delete a
> directory without going into it first. Before I go into the directory, it
> gives me a "directory not empty" message. I know the directory is empty
> though, because when I do go into it, and then back out, I can delete it
> just fine.

Yes, this is a GEMDOS bug.  In fact, if you try to delete the
subdirectory twice, the second time will work, even if you don't "go
into" the subdir.  It's fixed completely in TOS 1.4.  In fact, lots of
trouble can happen if you get a disk error or even disk full during a
mkdir operation; now those things are not harmful (or at least much less
harmful).


------------------------------


Date: 5 Apr 89 00:40:42 GMT
From: Ken Badertscher
Subject: ST docs

In article <1221@ncrcce.StPaul.NCR.COM> rogers@ncrcce.StPaul.NCR.COM (Bob
 Rogers) writes:
|Do you folks _ever_ intend to publish this information in a readily available
|and affordable format?

  Yes.

|From what I saw of the developer's docs (I saw a
|copy a couple of years ago) they're not professional quality documentation.

  The ST documentation is much better now than it was several years ago.

|Given the tiny percentage of the market that the ST has, and the tiny number
|of (mostly tiny) companies that write software for it, can you really afford
|to "certainly break software"?

  Context!  We definitely can afford to, and most certainly will, break...
|>software that either a) didn't follow the rules in the first place, or
|>b) was built on bad assumptions about the internal workings of TOS.

|Bob Rogers                    rogers@stpaul.ncr.com  or  rogers@pnet51.cts.com
|NCR Comten, St. Paul, MN      GEnie: R.C.ROGERS


------------------------------


Date: 4 Apr 89 19:45:19 GMT
From: Allan Pratt
Subject: Re: May I overwrite basepage

In article <766@stag.UUCP> to_stdnet@stag.UUCP writes:
> From: BROOKS%csss-a.prime.com@RELAY.CS.NET
>
> Sometimes I write very small stay-resident programs and, instead of
> allocating 2K of bss for an stack (and then only using 250 bytes) I set
> up the stack to overrun my startup code and wander down into the
> basepage.
>
> Does anyone know: Will this cause any problems?  Does TOS need anything
> in the basepage one I've started executing -- providing I don't Pexec
> anything?  Of course, I'd better not go *below* the basepage...

You'd better not go INTO your basepage, at least not past your command
line (which starts at offset $80 in your basepage).  GEMDOS needs to use
the basepage (not surprisingly), so you can't make any GEMDOS calls
after you clobber your basepage.  The GEMDOS call Ptermres, which you
obviously are using, definitely needs stuff in your basepage, like your
parent's basepage address so it can restart your parent.  You can
clobber your own command line area and the part of the TPA beyond that,
but leave the rest of your basepage alone.

Do NOT take the example I gave above and think, "Oh, if I preserve the
parent's basepage value in my basepage, I can use the rest of it." It is
intended as an example, not an exhaustive list, of what GEMDOS needs
from your basepage.


------------------------------


Date: 5 Apr 89 08:13:55 GMT
From: Ken Badertscher
Subject: Re: Screen Dump Stuff

In article <8904012328.AA04233@ucbvax.Berkeley.EDU> UNCSPL@UNC.BITNET ("Scott P
 Leslie") writes:
|Atari,
|   Could someone there comment on whether the TOS 1.4 hangs for
|30 seconds when ATL-HELP is inadvertantly pressed and the printer
|is not ready?

  The 30 second "hang" is a required timeout for dot matrix printers.
Yes, TOS 1.4 still does it, because it is necessary.  Even if you press
ALT-HELP a second time to cancel the screendump, the print screen routine
will do the timeout.


------------------------------


Date: 5 Apr 89 20:53:36 GMT
From: Allan Pratt
Subject: Re: GEMDOS Extended Argument Standard

In article <156@np1.hep.nl> t19@np1.hep.nl (Geert J v Oldenborgh) writes:
> I wonder why we could not use the present 'standard' with one small diff:
> let the sartup code of a program kill the extra part of the environment by
> putting a 0L on "_P(B=...)".  This unclutters the environment and avoids
> misunderstandings of its children, the main arguments against this scheme.

The only thing that fixes is a "smart" program finding surprising things
in its environment.  (That is, an argument FOO=3 will also look like an
environment variable FOO with value 3).

This doesn't help dumb programs at all.  A dumb program will still get
this funny thing in its environment, and will still pass that along to
its children.  Worse, if the dumb program actually tries to change its
environment, it might put a new (and important) variable at the end,
after the ARGV and the rest, and a "smart" program will lose this when
it nulls out ARGV.

So ARGV is bad for dumb programs.  We need something which does not
violate the format of an environment variable (i.e.  no embedded nulls
allowed) and therefore doesn't confuse either dumb programs which change
their environments or smart ones which use getenv().

We also need to address validation: finding ARGV in your environment
does not mean that the args were meant for you.  MWC kindly puts a
strange number in the command-line length byte ($7f), but, alas, doesn't
check it.  If it did check this would solve the problem, because a dumb
program might blindly pass along the ARGV in the environment, but it's
not likely to put the same number in the command-line length byte.

Another validation technique is to use the process' PID (basepage
address) to identify who put the args in the environment: eight bytes
can encode the PID of the culprit, and this number could be checked
against the "parent's basepage" field in the child's basepage; a match
means these args really came from your parent.  This removes the problem
of putting a funny number in the command-line length byte, which might
just happen accidentally.


------------------------------


Date: 5 Apr 89 21:23:58 GMT
From: Allan Pratt
Subject: Re: TOS bugs. Disk related.

In article <460@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
> when you install an application on the desktop (you know, click on a program,
> go to the menu entry for install application, type in the extender for the
> program and click install), and then click on a file with the correct
> extender for that application, the desktop seems to stick in a carraige
> return into the commandline for that application.
>
> ie: the commandline buffer in the base page will contain the length byte,
> the the filename clicked on, and then a carraige return before the null
> termination byte. the carraige return does not appear when you run the
> program from the numerous commandline shells in existence.

The command line is not null terminated.  The nulls just happen to be there.
The only correct assumption to make is that the command line length byte
tells how many valid characters there are in the command line.  You will
notice that an argument like "foo" will give a command line length byte
of three, and the CR is the fourth byte in the command line space.

Note that this convention is violated by MWC: they put $7f in the command
line length byte (and null-terminate the real command line) to indicate
that ARGV is in the environment.  See the discussion going on in this
newsgroup for more on that.

> also, say you were in a couple of subdirectories deep on a drive, and click
> on a file with the correct extender for that application. what seems to
> happen now is that the desktop will do a pexec load call to load the program
> into memory, change directory back to the directory containing the file you
> clicked on, and do a pexec go call. is this a correct assumption??
> (this is based upon the fact that only the filename appears in the commandline
> in the basepage, NOT the complete path to the filename!!) if it is true,
> will this mannerism change in the future?? it is a nice feature if it is true!

Your reverse-engineering of what goes on is admirable for its
complexity.  The truth is that you can call Pexec (or any other GEMDOS
function) with a full-blown pathname to the file in question, so no
changing of directories is required.  What you see on the screen or in
your command line and what got passed to GEMDOS can easily be two
different things.

Your current directory when the program starts is the directory where
the file was double-clicked.  The argument you find on your command line
is the name of the file which was double-clicked, with no path or drive
information.  This has always been true, and it is still true.

If you use the right button to double-click a document from a window
which is not the top window (did you know you could do this?), I don't
know what happens in original TOS or Mega TOS, but TOS 1.4 "tops" that
window before starting the installed application, making that the
current directory.  This is for clicking documents for installed
applications only: if you use the right button to double-click an
application outright, the current directory is still the top window.

TOS 1.4 has a new feature in this area: shell_find (which rsrc_load uses
to find resource files) now looks in more places, including the place
where the application was loaded from, even if that's not the current
directory.  Therefore an "installed" application will find its resource
file no matter where it lives, as long as the resource file and the
application are in the same place.  There are more details in this
area; see the TOS 1.4 release notes for full details.


------------------------------


Date: 7 Apr 89 19:33:59 GMT
From: Allan Pratt
Subject: Re: Problem with TOS recognizing media changes

In article <330@laas.laas.fr> ralph@nastassia.laas.fr writes:
> I often pop in and out floppy disks while running gulam.  This media
> change problem does hit me from time to time when I want to access a
> sub directory on A:.  Is there any way for to reread the disk?  An
> 'ls -l' does correctly show the root directory.  Is there any other
> solution to quitting gulam, clicking in GEM, and restarting gulam?

Gulam has a feature whereby it caches directories.  There should
be validation of the directory cache via a Mediach() call on the
pertinent device, but there isn't.  This is strictly Gulam's
fault.

Gulam's directory handling is really bad:  ever try "ls -lt" on
a directory with, say, 100 files?  It takes a LONG time.  That
time is not sorting; it's making two or three Fsfirst calls
for each file.  Fortunately, if you use TOS 1.4 and add directory
buffers, it doesn't hit the disk 300+ times...  The trouble is,
the code is so convoluted I can't hope to improve it.

I am really sorry Gulam is so good: it prevents me from writing a proper
shell.  Gulam's bugs are irritating, but the bulk of it is too good to
junk.  (Well, specifically, the code is badly unstructured and virtually
impossible to analyze, troubleshoot, and improve.)


------------------------------


Date: 11 Apr 89 00:30:35 GMT
From: Allan Pratt
Subject: Re: HELP!!!!!!!!!!!!!!!!

In article <6840@saturn.ucsc.edu> humtech@ucschu.ucsc.edu (Mark Frost) writes:
> Other than manually copying all of the files
> off of the floppies I can find no way to do this using Turtle (or any of
> the support programs).

You have hit on the only solution there is: copy the files from floppy
to your hard disk.  Too bad for you that TOS 1.4 isn't out yet:
it'd be a lot faster.

Did you know that you can use the desktop to copy a whole floppy to a
hard disk, including (recursively) copying directories, by dropping the
floppy disk's icon onto the open window of the hard disk's root
directory? That'll be fastest.


------------------------------


Date: 11 Apr 89 00:21:14 GMT
From: Allan Pratt
Subject: Re: (none)

In article <8904071506.AA22861@ucbvax.Berkeley.EDU> USQB015@LIVERPOOL.AC.UK
writes:
> I've heard talk about TOS 1.4. One of the "little" things about TOS that
> is very annoying is when a program returns to desktop the OS "always" reads
> the disk, even if the disk hasn't changed! Has this been rectified on the
> new TOS or will this little problem be explained away as "necessary" from
> somebody up on these things?

When you launch an application, you do it from an open window.  When you
return, the Desktop has to redraw that window.  To do this it has to
re-read the directory for the files in that window.  To do that, it has
to read the disk.

Well, not quite: if you have so many GEMDOS disk buffers in your system
that the directory is still cached, the Desktop's reads won't actually
hit the disk.  I don't know if this is ever true for current TOS,
because the cache is managed so badly.  Also, you only have four buffers
by default (two each in two different lists), so you rarely have
anything useful still cached.  If you add more buffers, GEMDOS
performance improves considerably, especially with TOS 1.4.

As an example, let's take copying a disk full of files onto your hard
disk.  With only a couple of buffers, you'll hear the floppy head seek
to the directory, to the FAT, out to the data area to read the file,
then back to the directory for the next file.  With more buffers in TOS
1.4, the FAT and directory are read once, and from then on the disk
simply steps through the data area, reading sector after sector of
file after file, without having to re-read the FAT or directory.

Naturally, copying *to* a floppy will involve more, because writes are
never delayed -- closing a file causes the FAT and directory to be
updated.  But reading a disk full of files is much faster & more
pleasant.


------------------------------


Date: 13 Apr 89 19:44:13 GMT
From: Ken Badertscher
Subject: Re: how to kill a mouse cursor

In article <8904051001.AA18434@ucbvax.Berkeley.EDU> USQB015@LIVERPOOL.AC.UK
 writes:
|Easy,
|     Use A-line instruction 10 $a i.e. opcode $a00a

That's also a good way to get the AES confused about how many times the
mouse has been hidden/shown.  The AES keeps its own internal count of
how many times the mouse has been hidden or shown so that it can clean
up after applications that go astray with the mouse.  This AES count
will get out of sync with the actual mouse state if you interleave
VDI/line-A show/hide mouse calls with AES graf_mouse calls.

  So the answer to the question how to kill a mouse cursor isn't all
that easy.  If your program uses the AES a lot, you should probably use
the AES graf_mouse() calls to hide and show the mouse.  If not, use VDI
or even line-A.  You could even disable mouse event reporting at the
IKBD level if you wanted to go so far.

|             Mark Powell


------------------------------


Date: 13 Apr 89 20:02:56 GMT
From: Ken Badertscher
Subject: Re: (none)

In article <8904120448.AA24499@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET ("JOHN
 ZAFIRIS ") writes:
|I am familiar with the line-A calls and the VDI ((or is it AES)... the GEM
|type) calls for mouse cursor handling.  None clear up the problem.
|I assumed that calling the hide mouse line-A opcode several zillion times
|and then using either the line-A show mouse code with a cleared "mouse hidden"
|counter or the VDI (?) code to show the mouse cursor no matter how many times
|it was hidden (which works otherwise) would fix the problem but it did not.
[...]
|The desktop does not have the problems my shell has.  What does it do?  I have
|tried all the leagal ways of fixing the problem that I can think of.  Does the
|desktop do something illegal?  But then that would actually be legal
|just undocumented.  (Atari-speak)

  The desktop, because it is an integral part of the OS, can get away with
some things that applications just can't do.  In this case, when
launching a program, the desktop terminates, the AES shell runs the
program, and when the program terminates, the AES shell starts up the
desktop again.  One of the first things that the desktop does, in order
to clean up after "unclean" applications, is to re-initialize the AES
window and mouse handlers.  This is something that an application just
can't do (legally...)

  Until TOS 1.4.  When TOS 1.4 becomes available, a new AES call will
become available with it.  The wind_new() call effectively does what the
desktop needs done after an application has exited; it cleans up after
the application, resetting the AES window and mouse handlers.

  I'm sorry that I can't provide an easy solution to your problem, but
that's why the wind_new() function was put into TOS 1.4!


------------------------------


Date: 13 Apr 89 22:26:53 GMT
From: Ken Badertscher
Subject: Re: Extended argument passing conventions in Pexec() [MWC]

In article <841@per2.UUCP> mwc.uucp!rec writes:
| My name is Roger Critchlow.  I work for Mark Williams.  I invented
| the MWC ARGV argument passing convention in October 1985.  I don't
| think either of the proposed replacements is an improvement.
| -----------------------------------------------------------------------
| Our convention is incomplete because you can't tell if the ARGV was
| actually passed by your parent or simply passed on by some intervening
| shell?
|
[ environment comparison code omitted ]
|
| This example is only the simplest of many procedural validations
| of the ARGV convention.  You can chase the parent pointers all the
| way to the desktop and determine who exactly is responsible for
| each part of the environment in each of the processes active.

It is simple, yes, and it simply won't work.  Using ARGV, a parent
is required to copy its environment before it execs a child.  What if
someone decides they'd like to sort the environment variables for the
child as they create the child's environment?  What if they want to
filter it?  The environment comparison fails, and validation goes out
the window.  The MWC tools already* provide a flag ("unreasonable"
command line length byte) which can be used to validate the ARGV, and it
is unused by the MWC startup code!

| I don't think that every program which uses ARGV needs be burdened
| with this sort of validation, but it's clearly possible.

One of the *main* reasons that xArgs came into existence in the first
place was that ARGV lacks validation that the arguments in the ARGV
pseudo-environment-variable really do come from one's parent.  You may
not find the validation necessary, Roger, but there are many people
who use tools which were not compiled using MWC libraries.  A typical ST
developer's toolkit contains sundry tools with a varied ancestry.  The
plain fact is that ARGV does not peacefully coexist with tools that
don't use ARGV.

| -----------------------------------------------------------------------
| Our convention is messy because it involves copying arguments around
| in the environment?
|
| But all three proposed argument conventions require copying, and all
| three pass linkage information in the environment, and the ARGV convention
| is the most efficient of the three.
|
[ enumeration of implementation requirements omitted ]
|
| The ARGS and xArgs proponents are proposing to load more code into the
| runtime startup to support their proposals.  [...]
| How many independent count-allocate-copies does it
| take to start a Gemdos process?

Who cares???  How long does it take an 8Mhz 68000 to copy 1k, or even
(gasp) 2k of memory, even with extra processing to parse it?  Somewhere
on the order of tens of milliseconds per program invocation, if that much.
God forbid that we should fritter away people's valuable milliseconds in
our wanton disregard of startup module code efficiency.

| -----------------------------------------------------------------------
| Programs which ignore the ARGV convention for arguments end up
| mis-interpreting ARGV specified arguments as environmental variables
| and passing screwed up environments on to their children.
|
| This problem is addressed differently by the ARGS and xArgs proposals.
|
[ means of addressing the problem omitted ]
|
| In article <156@np1.hep.nl> Geert J v Oldenborgh suggested truncating
| the environment after extracting the ARGV from it.  I think this is
| an excellent suggestion:  it adds one instruction, 2 words, to the
| runtime startup module and immediately cures one whole class of bugs,
| the class created by MWC compiled programs doing naive Pexec()'s.

Hah, I caught you!  You admit that ARGV is imperfect! ;-)  You are even
willing to change the startup code to make it more perfect!

| I have two solutions for binary programs which screw up the
| environment by ignoring the ARGV standard but cannot be rebuilt
| with the improved runtime startup.  Both involve the same
| transformation suggested above.
|
| Solution 1 - call the program indirectly through a second program [...]
| Solution 2 - rewrite the binary of the offending program to
| incorporate the environment truncation into the offending
| program's runtime startup.  [...]

That's very nice, but the other two methods of extended argument passing
don't require ANYBODY to be insulated from them.  In fact, all THREE
methods can peacefully coexist in one system, except that ARGV will
cause problems for programs which haven't been "innoculated" against it.

| -----------------------------------------------------------------------
| In summary, the ARGV convention can be validated by comparing the
| ARGV received in the environment to the ARGV received by the parent;

unless the parent has done anything to the environment...

| the ARGV convention rides for free on Pexec() while the new proposals
| both involve additional overhead;

negligible additional overhead...

| and it is trivial to fix programs
| which pollute the environment by ignoring the ARGV convention.

perhaps we disagree on the meaning of the word trivial; in any case,
the other two schemes don't cause any pollution, and thus don't require
any programs to be fixed...


| If Atari wants MWC to discard the ARGV argument convention, I hope
| they'll wait until they can find something better to replace it with.  :-)
|
|    -- rec --

If MWC wants Atari to adopt the ARGV argument convention, I hope they'll
come up with some better defenses for it. >;-)


------------------------------


Date: 24 Apr 89 04:32:13 GMT
From: Ken Badertscher
Subject: Flow control

In article <17401@cup.portal.com> BUGGS@cup.portal.com (William Edward JuneJr)
 writes:
| Anyone know if the new TOS will support flow control?

  RTS/CTS flow control was fixed in Mega TOS.
  As far as I know, it wasn't un-fixed in TOS 1.4.

--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>


------------------------------


Date: 24 Apr 89 05:32:58 GMT
From: Ken Badertscher
Subject: Re: GEM AES/Resource Questions

In article <13423@watdragon.waterloo.edu> achowe@tiger.waterloo.edu
(CrackerJack) writes:
| 1)    How do I get the address of a string contained in a dialog in order
|     to change its contents?

    #include <gemdefs.h>    /* R_TREE define        */
    #include <obdefs.h>    /* OBJECT, GRECT typedefs    */

    OBJECT    *dial
    int    i;
    GRECT    rect;
    typedef struct _prect { int *x, *y, *w, *h; } PRECT;
    PRECT    rectptr = { &rect.g_x, &rect.g_y, &rect.g_w, &rect.g_h };
    :
    /* start up application, load resource, etc... */
    :
    /* get the address of the tree containing the dialog `DIALOG' */
        rsrc_gaddr( R_TREE, DIALOG, &dial );

    /* put the string in the dialog object `DIALSTR' */
        sprintf( (char *)dial[DIALSTR].ob_spec, "%4d", i );

    /* redraw the dialog */
        form_center( dial, rectptr );
        objc_draw( dial, 0, MAX_DEPTH, rect );
    :

Make sure that the string object in your resource has MORE than enough
space to handle any strings that you're going to stick into it.


| 2)    How do I send myself a WM_REDRAW message?

>From the code you included describing how you were sending yourself the
message, it appeared that you wanted to redraw the dialog when you
changed the string values.  It's much better to redraw the dial (as above)
when you change the value of any string-type object.  However, if you still
want to send yourself a redraw message, try the following...
(untested code off the top of my head):


    #include <gemdefs.h>    /* WM_REDRAW define    */
    #include <obdefs.h>    /* GRECT typedef    */
    extern int gl_apid;    /* this application's ID */

    SendRedraw( whandle, rect );
    int whandle;
    GRECT rect;
    {
        int msg[8];

        msg[0] = WM_REDRAW;    /* message type    */
        msg[1] = gl_apid;    /* sender ID */
        msg[2] = 0;        /* buffer length (0 := 16 bytes) */
        msg[3] = whandle;    /* window to redraw */
        msg[4] = rect.g_x;    /* rectangle to redraw */
        msg[5] = rect.g_y;
        msg[6] = rect.g_w;
        msg[7] = rect.g_h;

        appl_write( gl_apid, 16, msg ); /* tell self to redraw */
    }

Then, when your application recieves the WM_REDRAW message, it can
do whatever redrawing needs to be done, based on the rectangle.


------------------------------


Date: 24 Apr 89 18:53:17 GMT
From: Allan Pratt
Subject: Re: Pexec question

In article <477@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
> In article <1927@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes:
> >i have a question on Pexec, specifically on load/nogo then go more than once.

> [I have the same problem...]
> ... the ability to do this would allow
> people to write really HUGE accessories, but instead of eating up 200K for
> the huge accessory all at once, the modules it need to run can be pexeced
> when needed into an internal buffer.

I will tell the net the same thing I told Bill Rosenkranz: don't try to
use Pexec to load overlays.

If you want to load overlays, do it some other way.  For example, demand
that the overlays be position-independent and load them anyplace you
want.  Alternatively, load them and fix them up yourself -- there is
enough information in the documentation to do this.  The normal startup
will not work, of course, because an overlay is a fragment, not a
program.  Certainly, an overlay should never call Pterm(), and should
not expect to have a basepage.

Some programs which have multiple printer drivers, like Degas and (I
believe) MicroSoft Write, use this trick.  The driver is a module, not a
program: the beginning of the module contains relative pointers to the
externally-visible entry points.

Your best bet is to load the driver code into memory and relocate it
yourself (unless it's position independent), JSR to it, and have it RTS
to you, and stop trying to think of it as a process.


------------------------------


Date: 28 Apr 89 18:47:42 GMT
From: Allan Pratt
Subject: Re: Hard drive synchronization with the ST

In article <890427.09095442.063770@SFA.CP6> Z4648252@SFAUSTIN.BITNET
(Z4648252) writes:
> wondering if TOS 1.4 ... detects a hard drive during power up

Nope.

Might be a good idea, but how long do you wait? If the computer and the
drive both power up at the same time, the hard drive may not reset
properly.  Some drives need to be allowed to do the whole power-up
sequence before they can take any commands or data, even just
request-sense (status) commands.

On the other hand, some don't.  If you put AHDI.PRG in the \AUTO\ folder
of a floppy, and put another program BEFORE that in the AUTO folder
which delays by 30 seconds (or whatever it takes), you could be in
business without any sequencer.  The ROMs will look for a hard disk, not
find one, and boot off the floppy.  By the time the delay has elapsed
and AHDI loads, the drive is ready.  Give that a try.

It might not work.  Warranty void if terms are violated.  Your mileage
may vary.  You may have some other rights which vary from state to state.


------------------------------


Date: 1 May 89 20:45:36 GMT
From: Allan Pratt
Subject: Re: Screen Saver

In article <1040@gmdzi.UUCP> kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes:
> I just wrote a Screen Saver Program for a friend. I used the trick to
> set the Vsync to external Signal. While testing I realized, that with
> Screen off (= no sync signal) the VBL Queue routines are not executed.
> Is that right?
>
>       Kloppenburg@kmx.gmd.dbp.de
> UUCP: kloppen@gmdzi


I'm not sure I understand your description, but if you're programming
the shifter to take Vsync from an external source, and there is no
external source, you can actually case MORE damage to your monitor
than leaving it on.  Monochrome monitors in particular don't like
being turned on without any synch information: they make a noise
like they're in pain, if your ears can pick it up.

Here's a good chance to say NEVER LEAVE YOUR ATARI MONOCHROME MONITOR ON
(for long) AFTER TURNING OFF YOUR COMPUTER.  A minute or two is fine,
but over the course of hours something gets hot inside and eventually
your monitor dies.


------------------------------


Date: 1 May 89 20:55:15 GMT
From: Allan Pratt
Subject: Re: Hard drive synchronization with the ST

Some people have mentioned that their non-Atari hard disks don't always
auto-boot.  Something came to my attention recently, and this might be
part of the explanation:

The boot sequence on the ST starts with a "move.w #$2700,sr" instruction
(to ensure IPL 7) and then "reset" to reset external devices.
Unfortunately, the "reset" instruction does not pull down reset as long
as the SCSI spec requires.  Furthermore, the time between letting go of
the reset button and the time the "reset" instruction gets executed is
too short -- that is, you get "reset" (the button is down), then "not
reset" (the instructions are executing), then "reset" (the reset
instruction), and the "not reset" time is shorter than the SCSI
minimum-time-between-resets specification.

A host adapter to a true, picky SCSI device would have to lengthen any
reset it gets to the minimum SCSI length, and possibly remove the brief
"glitch" it sees while the two instructions are executing.

Atari hard disks can take it (or the host adapter is doing the fiddling)
because, of course, they work.  I regret (retroactively) that this
timing problem exists.  The fact that the reset instruction is too short
isn't really our fault: it grounds "reset" for 124 clocks in the 68000,
512 clocks on the 68020 and 68030 (but remember, clocks are likely to be
shorter).  However, the too-short time between resets *is* under
software control.


------------------------------


Date: 3 May 89 00:24:52 GMT
From: Allan Pratt
Subject: using memory (was re: A REAL RamDisk)

In article <3694@nunki.usc.edu> rjung@sal61.usc.edu (Robert  allen Jung) writes:
> You're
> uncompressing a package, and send all of the bits into the RAMdisk.

Solutions like this are necessary because of problems like ARC.  ARC is
poorly implemented in that it reads & writes 512 or 1024 bytes at a time
(as far as I know).  You get HUGELY improved throughput if you read a
large buffer-full of your source, decode into another buffer, and write
large chunks at a time.  The chunks don't have to be very big: you get
dramatic improvements at 16K, and usually not much increased benefit by
going up to 1M or more.

Look how much faster UNARC.TTP is than the equivalent extraction using
ARC.  The entire difference is that UNARC reads the file in from the
archive, uncompresses it, then writes the plaintext.  It might not even
read & write the whole thing, and I don't care; it's a hell of a lot
more than 1024 bytes!

The extreme example of this problem is GFA BASIC, which reads and writes
text files ONE BYTE AT A TIME.  That is, they use

    Fread(fd,1L,&c);

to read a character from a file.  This is ABSURDLY slow, and you end up
with whole subcultures coming up with workarounds to make text file I/O
reasonably fast.

I know this doesn't directly address the RAMDISK problem; that's been
put to bed, I think (can't resize meaningfully under TOS).  My point is
this: you have lots of memory; use it!


------------------------------


Date: 4 May 89 19:39:41 GMT
From: Allan Pratt
Subject: Re: assemblers

In article <99@sdcc10.ucsd.EDU> cs163afu@sdcc10.ucsd.edu.UUCP (Some call
 me...Tim) writes:
> MadMac in the Atari Developer's kit, for one reason:  Speed.

You betcha.

> And if you really want it optimized--after you have it running, use
> the Alcyon assembler at that point.  They are completely code
> compatible.

They are NOT completely compatible.  It is possible to write code
which assembles the same (modulo optimizations) under both assemblers.
However, MadMac is more strict on some points (colon after label,
semicolon before comment) and AS68 doesn't have macros.  Furthermore,
the syntax for conditional assembly is totally different, and
the behavior of "=" and "set" and "equ" might be different.

MadMac has an option (-6) which lets you assemble Alcyon compiler
output.  It is NOT an AS68 compatibility mode; it is a C68 back-end
mode.  It simply ignores lines beginning with "%" and does some other
things (I forget what).

You can ask MadMac to inform you of unoptimized short branches, so you
can go back and put ".s" on them.

AS68 doesn't know about the XXXX.w addressing mode:

    INPUT          MadMac output            AS68 output
    ------------  ------------------------  --------------------------
    lea $1234,a0  lea $1234.w,a0 (2 words)  lea $00001234,a0 (3 words)


Lastly, AS68 makes at least one illegal optimization.  Assuming that a
missing size modifier means the same as .w, the optimization

    move #1,d0    -->    moveq.l #1,d0

which AS68 does is illegal.  MadMac does moveq, addq, and subq
optimization correctly.


------------------------------


Date: 9 May 89 18:32:10 GMT
From: Allan Pratt
Subject: Re: POWERUP HARD DRIVE/CPU SEQUENCING

I give in.  Please report us to the Better Business Bureau for Abuses
and Criminal Neglect of Hard-Disk Start-up Sequences.

Yes, we could issue the "Test Unit Ready" command to the controller, and
if there's no response, then there's no controller.  If there is a
response, and it's negative, we can keep asking until it's positive.
However, there's still a timeout -- it may be that the controller is
getting power but the drive unit is not, so it'll NEVER be ready.  How
long do you propose we wait?

At any rate, it's too late for TOS 1.4.  Sorry.  Use your "text file
causing reboot" trick.  Or, you can do it properly:

    ; This program causes a warm boot.
    ; Un-comment the clr.l for a cold(er) boot.

    move.l    #0,-(sp)    ; get into supervisor mode
    move.w    #$20,-(sp)
    trap    #1

;    clr.l    $420
    move.l    $4f2,a0        ; a0 -> OS header
    move.l    4(a0),a1    ; a1 -> reset handler
    jmp    (a1)        ; jump there.  That's a reset.

That's all there is to it.  No guessing, just a warm boot.  If you want
a cold boot, un-comment the clr.l instruction.  This will run in the
AUTO folder, as an accessory, or as something you can double-click from
the Desktop or start from a shell.


------------------------------


Date: 11 May 89 19:46:23 GMT
From: Allan Pratt
Subject: Re: Preloading revised

In article <1028@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes:
> For those who might be interested, here's a demo program that preloads
> some programs (whose pathnames are supplied on the command line), then
> executes them. It uses the Pexec variants 3, 4 and 5 to do so. Compiled
> with Lattice C.
> Enjoy!
>        Leo.

The program Leo posted should work fine.  It uses Pexec 3 (load/nogo)
once per program you're loading, but then uses Pexec 5 (create basepage)
followed by Pexec 4 (just go) on *that* basepage (after filling it in)
once per execution of a preloaded program.  This is fine; nothing
wrong with it at all.  Excellent solution.

Except for one thing: some programs expect their basepage to be $100
bytes below their text base.  In fact, virtually all programs make that
assumption to one extent to another, but most of them use it to
determine how to Mshrink, and being off by $100 bytes won't matter.

And another thing: a program which assumes any initial state for a
variable in the data or BSS segment will lose, because the second time
you start it the variable will have a leftover value from the previous
execution.  You can fix this problem by saving a copy of the initial
data segment and copying it into the process before starting it again,
and clearing the BSS (just the declared part; you don't usually have to
clear the whole heap).  If a program modifies its text segment, this'll
lose, but hell, at that point it'll be quicker just to load it off a
RAMdisk.

Very cool idea.  I might try to add some builtins to Gulam this way.


------------------------------


Date: 18 May 89 05:43:40 GMT
From: J. E. Patton
Subject: Becoming a developer

By popular demand the following information is posted for those interested
in becoming registered Atari developers. It pertains only to those located
in the U.S.   Atari has subsidiaries all over the world and you should contact
the appropriate one for more information about becoming a developer.
------------------------------------------------------------------------
To become a registered developer you must purchase one of the following
forms of the kit.

$ 112.50  Documents Only
$ 237.00  Above w/telephone support, online registration, hardware discounts
$ 300.00  All the above plus Mark Williams C compiler.

If you live in California please add 7% sales tax.  Checks will be returned
if tax is not included.  To purchase the Developer's Kit please send a
cashiers check or money order to the following address:

Atari Corporation
1196 Borregas Avenue
Sunnyvale, CA 94086
Attn: Developer Coordinator

The Developer's Kit will be sent back to you prepaid UPS Blue.  Allow
two weeks from the time we receive your check.  Please note:  UPS cannot
deliver to a P.O. Box.

The actual process of getting registered relies on the developer returning
a confidential disclosure form which is contained in the developer's kit.

The following is a list of some of the documents in the developers kit:

     o Question and Answer Newsletters
     o Introduction to GEM programming
     o A Hitchhiker's Guide to the BIOS
     o Atari GEMDOS Reference Manual
     o GEM Programmer's Guide, Vol. 1--VDI
     o GEM Programmer's Guide, Vol. 2--AES
     o Still Another Line-A Document (SALAD)
     o Engineering Hardware Specification
     o Chip specifications
     o SFP004


------------------------------


Date: 18 May 89 17:46:36 GMT
From: Allan Pratt
Subject: Re: HELP! (Damaged data)

In article <3475@ihlpm.ATT.COM> jshwang@ihlpm.ATT.COM (Hwang) writes:
> I have an atari 1040st. Sometimes when I try to run a program,
> the disk drive (built in the st) makes a sick sound (I don't
> know how else to describe it..it is not the normal rrrrrrr,
> but r..r..r..r), then a banner comes up saying the data on
> the disk may be damaged. The program will not run.

What's happening when it goes r..r..r..r is that it's trying to read a
certain sector, failing (after five revolutions), and the software
"reloads the head" -- that is, it seeks track zero, then seeks back to
the track where the data is supposed to be.  It does this three or four
times.

This can happen if the disk is damaged, if the floppy's heads are dirty
or damaged, and, most especially, if the floppy's heads have come out of
alignment with the "ideal" for 3.5" drives.  Take the machine to your
dealer; s/he can open the drive, clean the heads (don't use a "head
cleaner" disk; use the kind of kit that comes with Q-tip-style
applicators), and realign the drive if necessary.

There's a gotcha to realigning your heads: if you've been writing data
to disks with misaligned heads, then you fix the heads so they're in the
"standard" alignment, you might not be able to read your own disks any
more! This is usually not a problem, but something to watch out for.


------------------------------


Date: 24 May 89 15:55:32 GMT
From: J. E. Patton
Subject: Re: Becoming a developer

in article <43609a62.14a1f@gtephx.UUCP>, covertr@gtephx.UUCP (Richard E. Covert)
 says:
>
>
> Thanks to Atari for sending out the info about becoming
> an Atari developer, BUT (ain't there always a but :-) ),
> how current are they?? Do they reflect the Mega ST, TOS 1.2
> and TOS 1.4?? How often are they updated?? How accurate are they??
> Do you still get those old Digital Research Xeroxed manuals??
>
> And how much are the hardware discounts?? Can a new developer get a
> break on the new 68030 TT machine??
>
> Richard (UNIX hacker and eagerly awaiting the TT) Covert

The currently shipping docs. contain all the updates we've
made available to developers. Unfortunately the DRI manuals are still
present, but ( There is always a but :) specific information about
TOS 1.2 and 1.4 has been merged with more to come.

Developer pricing for the TT has not been discussed ... yet, but
you can understand that limited quantities of custom parts will
be a factor ( I have nothing to do with setting prices, so these are
MY thoughts ).


------------------------------


Date: 1 Jun 89 22:19:51 GMT
From: Allan Pratt
Subject: Re: ST @ 38400 baud???

In article <665@stag.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu)
 writes:
> [38KBaud on an ST]

> It's easy. You need to call Rsconf to reset a bit in the UCR, then you need
> to reset the baud rate timer... Basically, when you use Rsconf to set the
> baud rate of the serial port, it always puts the UART in divide-by-4 mode.
> Reset that to divide-by-1, then you need to set the correct counter values
> in the timer [yes, it's Timer D] to get the
> baud rate you want. You can calculate them pretty easily...

Actually, the UART is in divide-by-16 mode, not divide-by-4.  Timer D is
running as fast as it can; *that* is where the divide-by-4 comes in.  If
you change the bit in the UART to divide-by-1, you disable certain
synchronization logic in the UART and reliability goes down the toilet.
Talking to my VAX at 9600 with this trick, there is lots of noise.  19.2
is the pits, and I've hooked up two STs at 38 and it's unusable (too
many glitches).

If you can do it and are satisfied with the results, more power to you.
Personally, I would consider leaving the UART at divide-by-16 so the
synchronization logic works, and placing a different clock on the
68901's baud-rate inputs instead, but that involves finding a clock and
running a jumper, and makes the baud rate nonprogrammable.  (Just don't
put a different clock on the 68901's CLOCK input, since that controls
all the timers; there isn't a separate Timer D input.)


------------------------------


Date: 2 Jun 89 18:50:26 GMT
From: Allan Pratt
Subject: Re: Critical error handler

In article <757@sbsvax.UUCP> roeder@sbsvax.UUCP (Edgar Roeder) writes:
> You can install a normal C-routine as the error handler. But you can only
> call Bios-functions for terminal output, since the handler may be called
> from a GEMDOS-function and since GEMDOS is not reentrant (*), you can't use
> GEMDOS-functions like Cconout() (and most printf()'s in C-Compilers).
>
> (*) GEMDOS is not reentrant when called by the Bios because it uses a static
> (and undocumented (!)) storage location for the return address when it calls
> a Bios-function like for example Rwabs() from inside Fwrite() which
> eventually calls the critical error handler.

Give me a break! GEMDOS is not reentrant for more reasons than that! And
you don't expect us to document EVERY VARIABLE that GEMDOS uses, do you?

GEMDOS is not reentrant because (A) it sets SSP to the same address
every time it's called, and (B) it uses the basepage of the current
process to store the context (the registers, incl.  PC).  If you make a
GEMDOS call from within a GEMDOS call, the second one overwrites the
stack of the first one and overwrites the first caller's context.  NOw
that's what *I* call non-reentrant!

Given those two reasons, finding other reasons for non-reentrancy in
GEMDOS is little more than vanity or folly.


------------------------------


Date: 5 Jun 89 18:46:31 GMT
From: Allan Pratt
Subject: Re: Rsconf in TOS 1.4

In article <374*hofer@urz.unibas.ch> hofer@urz.unibas.ch ("Remo Hofer") writes:
> Some documentation about TOS 1.4 says:
> Rsconf(-1,-1,-1,-1,-1,-1) does return the old values of USART registers.
> (That was true for all TOS versions, but wasn't documented)
> Rsconf(-2,-1,-1,-1,-1,-1) does return the old value for the baud rate.
> (That is only true for TOS 1.4)
> Does this mean that you can inquire all settings of the RS232 except
> the setting of the handshake? I think, it would be nice, if we could inquire
> the handshake settings. Any comments? Maybe somebody at Atari?
>
> Remo Hofer
> hofer@urz.unibas.ch
>
> ----------------------------------------------------------------------------


That would have been a good idea, but it's too late for TOS 1.4.  Sorry.
I regret that so much of TOS is done piecemeal, and I regret further
having contributed to that, but that's the way it is sometimes.


------------------------------


Date: 6 Jun 89 22:47:41 GMT
From: Ken Badertscher
Subject: Re: TOS environment

In article <1232@infbs.UUCP> hafer@infbs.UUCP (Udo Hafermann) writes:
| What is the TOS variable 'the_env' (at 0x4be) used for?  The documentation
| says it is an evironment pointer and is 0L.  Does any software use it?


The system variable the_env is currently not used by the OS, but is
reserved for use by Atari.  It is documented as a "null environment;
four bytes of 0."  Back in the dark ages of TOS, before the environment
started getting set up later on in system startup, these four bytes
were a convenient place for GEMDOS to pick up a null environment
string.  It's done differently these days, but the cruft of the_env is
still lying about.

If you're looking for low memory space to put something, there are much
better places than at the_env.  Please don't use it.

I don't know of any software that uses it currently.  I am still
planning (someday) on releasing the DA/program environment-setter that
I have put together, and as system software, I may have it use the_en
for something meaningful.  If I do, I'll be sure to document its
purpose far and wide.

--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>


------------------------------


Date: 6 Jun 89 23:48:51 GMT
From: Allan Pratt
Subject: Re: Revolver/19.2K baud/awards

In article <8906050250.AA22171@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg
 Csullog) writes:
> 2. Alan Pratt says that 19.2K is the pits on the ST. Nonsense.
>
> 3. Since Atari folks read and respond to various items on the net, why
>    haven't I heard anyone from Atari respond to my idea about awards for
>    best PD and commercial software to reward ST code developers? Is Atari
>    selectively deaf?

2.  I said 19.2K is the pits when you put the MFP in divide-by-1 mode.
This is true, and it's true because the clocks on two machines won't be
exactly in synch.  See the discussion of 38KBaud on ST for more about
this.  When you use the normal 19.2K set up by Rsconf, you're fine.

3.  With the signal/noise ratio on the net, you should be more surprised
that something DOES get a response than that something DOESN'T.  We
can't take the time to respond to everything; as far as management is
concerned, netnews is somewhere between a perk and a necessary evil.
It's a huge time-sink with only minor payback.


------------------------------


Date: 6 Jun 89 23:06:03 GMT
From: Ken Badertscher
Subject: Re: WHICH TOS?

The best way to visually determine what TOS version you're running is to
look at the copyright date in the "Desktop Info..." dialog.  Here at
Atari, we like to call the versions by name; the first TOS release is
"ROM TOS" and it has a copyright year of 1985.  The TOS that was put
into the Mega computers is "Mega TOS" (we would call it "BLiT TOS",
because the only major difference from ROM TOS is BLiTTER support, but
that name is used by some German developers to refer to the hacked-up
TOS ROM that works with a 68020).  Mega TOS has copyright 1986,1987 in
the Desktop Info dialog.

When TOS 1.4 becomes available to the general public, it'll be pretty
obvious from the Desktop Info box what its name should be.  As far as
dates go however, it's copyright 1985,86,87,88,89.

Unfortunately, there are so many versions of TOS 1.4 floating around on
BBS's, being sold by Atari Dealers (yes, it's true *sigh* -- illegal
and bug-ridden copies of Beta Test ROMs are being foisted off on
unknowing Atari customers by a few money grubbing dealers), and
available from other channels that it might be worthwhile to have a
"version-checking program" so that people can know what TOS version
they're actually using.  This program could be useful to the majority of
honest dealers out there so they can prove that they've got the "real
stuff" ;-) and it could be a benefit to the wary customer.


------------------------------


Date: 7 Jun 89 22:59:51 GMT
From: Ken Badertscher
Subject: Re: WHICH TOS?

In article <801@orbit.UUCP> steve@pnet51.cts.com (Steve Yelvington) writes:
| The Sversion() Gemdos function allegedly provides this information, but on my
| STFM it returns a value of 0.19. Does anybody know whether Sversion() really
| works?

Hmm, Sversion is returning a float value?  Hmmm... ;-)

Sversion() returns the GEMDOS version number, not the TOS version.  The
GEMDOS version number for your machine should be 0x1300 (our version
numbers are all WORD values); I'm not sure how you get 0.19 from that,
but...   In any case, the TOS version number is in the OS header.  To
get the TOS version number, use the pointer to the OS header (sysbase) at
0x4f2.  The TOS version number is the second word of the OS header.

Offsets for the rest of the stuff in the OS header is documented in the
Hitchhiker's Guide to the BIOS.  The Pexec Cookbook also has a small
section on GEMDOS/TOS version numbers.

To add to the version number confusion, the AES has its own version
number too (returned in global[0] on appl_init)!

For those with a furniture fetish, here is a table:

Versions
==============
 ROM TOS  Mega TOS
 -------  --------  -------
  $0100    $0102     $0104      TOS version (from the OS header)
  $1300    $1300     $1500      GEMDOS version (from the Sversion call)
  $0100    $0120     $0140      AES version (from global[0] after appl_init)

Can you now see why we don't like to give OS releases specific version
numbers? ;-)


------------------------------


Date: 8 Jun 89 19:00:58 GMT
From: Allan Pratt
Subject: Re: Revolver/19.2K baud/awards

In article <37800008@hpbbrd.HP.COM> marcog@hpbbrd.HP.COM (Marco Gommersbach)
writes:
> / hpbbrd:comp.sys.atari.st / 01659@AECLCR.BITNET (Greg Csullog)
> >   I cannot disable REVOLVER's loader on boot up by holding
> >   down the LEFT SHFT-ALT combo like the manual says. Has this feature been
> >   disabled? (HISOFT BASIC's info program says I have ROM version 1.2)

This smells a lot like another case of being B.A.D.  (Broken As
Designed).  There is a perfectly legal and compatible way to find out
what shift keys are down: use Bioskeys(-1).  However, some developers
use the address in RAM where the BIOS keeps this information, without
regard for the fact that the address is not published and changes from
ROM to ROM (as you have discovered).


------------------------------


Date: 12 Jun 89 18:39:05 GMT
From: Allan Pratt
Subject: Re: TOS

In article <8906090105.AA10969@ucbvax.Berkeley.EDU> WOODALLP@VAX1.BHAM.AC.UK
writes:
> I have seen mention of TOS 1.0 and TOS 1.2, in Britain I have not seen
> any mention of these numbers [...]

Sversion() only gives the version number for GEMDOS, and that didn't
change between original ROMs and Mega ROMs.  The TOS version number is
available as the second word of the OS header, whose address can be
found at _sysbase, $4f2.  Original RAM TOS and also original ROM TOS
were both 1.0 (regrettably), but since RAM TOS is no longer supported
this isn't a big deal.  Mega TOS was 1.2 (with more changes than you
think), and the new TOS (available now to USA developers -- write J.
Patton at Atari for info) is 1.4.  By "x.y" I mean the first byte of
that word is x and the second one is y.

NEVER NEVER NEVER use an absolute address like $FC0000 because if we
ever move the ROM start address (HINT HINT) your program won't work! The
only absolute addresses in any TOS program should refer to published
system variables or hardware things like interrupt vectors.


------------------------------


Date: 13 Jun 89 00:09:53 GMT
From: Ken Badertscher
Subject: Re: Flow control in TOS 1.4

In article <43ad1ca2.14a1f@gtephx.UUCP> covertr@gtephx.UUCP (Richard E. Covert)
 writes:
| Does anyone know if Atari ever fixed the flow control problem in
| the last Developer's RAM version of TOS 1.4?? I recently purchased
| a new US Robotics 9600 baud modem which will go as fast as 14,400 buad
| BUT it requires flow control.
|
| I am told that the USR 9600 HST modem runs at the higher speed just fine
| on a Mega ST using TOS 1.2. But, it doesn't work with the Dec 1988
| disk-based TOS 1.4.

Whoever told you the above was confused.

Nothing in the flow control has changed since Mega TOS. There was a
problem with flow control in the original ROM TOS.  It didn't work at
all.  That was fixed in Mega TOS.


------------------------------


Date: 13 Jun 89 02:29:45 GMT
From: Ken Badertscher
Subject: Re: Pexec() and shel_write()

The current incarnation of shel_write is only useful to chain to
another program when you are run from the desktop.   If you need
to run programs which chain via shel_write from a shell program,
the shell program must intercept trap #2 and look for shel_write
calls, and handle them itself.

This is precisely the same problem NeoDesk was having. In my opinion,
the solution of having a "shel_write patch" program in your computer
all the time is suboptimal.  All that is necessary is for the "shell"
type program to perform the shel_write calls itself via Pexec.  That's
all the AES does when a program uses shel_write to chain to another
program.  Rather than restarting the desktop, the AES shell Pexecs
the program whose name was shel_written.

This and other sticky shel_stuff will be covered by the forthcoming
(yeah, it's been forthcoming for about 6 months now, so sue me...)
shel_games document.


------------------------------


Date: 13 Jun 89 04:16:37 GMT
From: Ken Badertscher
Subject: Re: versions

In article <865@stag.UUCP> to_stdnet@stag.UUCP writes:
|  kbad@atari.UUCP (Ken Badertscher) writes ...
|
| > Hmm, Sversion is returning a float value?  Hmmm... ;-)
|
| No, I'm not *that* silly.  [source code omitted...]

Of *course* you aren't.  *I* was being silly (note the smiley above... ;-).

| ... basing the above on the Sversion() documentation in Pollack & Weber's
| "Atari ST Application Programming," which says in part:
|     "The high byte contains the minor version number and the low byte
|      the major version number."

Oh my, I stand corrected.  That documentation is corroborated by the
GEMDOS documentation, which says that Sversion returns the GEMDOS
version number "in byte-reversed format."  Don't ask me why it's like
that...  In fact, the Pexec Cookbook is incorrect in this regard, it
states that the high byte is the major version number.  According to
the GEMDOS bible, the high byte is the MINOR version number.  So
byteswap it before doing any version dependancy tests.

| Heh... what IS the new version of TOS going to be called, Ken?
| Besides late, I mean. :-)

My lips are sealed until the general ROM release.  WhoKnowsWhen.


------------------------------


Date: 13 Jun 89 01:32:48 GMT
From: Ken Badertscher
Subject: Re: Communicating with Desk Accessories

In article <507@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
| what happens to this accessory when you switch resolution. what i've been
| able to trace myself is that the accessory will get an AC_CLOSE message,
| but what is it supposed to do with that??
|
| the reason why i'm asking is that only the accessories that i've written
| end up eating memory everytime you switch resolutions. the memory that is
| eaten is equivalent to the size of the accessory! (not a good situation to
| say the least).

An AC_CLOSE message means that any resources that your accessory has
open are about to go away.  Namely, any open files will be closed,
Malloc'ed memory will be released, etc.  Anything that your accessory
sets up while a program is running has a potential for vanishing when
the program terminates.  AC_CLOSE is the system's way of warning
accessories about programs terminating.

As far as memory-gobbling is concerned, this is unfortunately how the
system works.  Whenever you switch resolutions, accessories get
re-loaded, and the old ones just hang around using memory.  This is a
side effect of the way the AES treats res changes: not-quite-
a-warmboot.  Offhand, I can't think of any quick and easy ways around
it.  I usually use warmboots to switch resolution ;-).


------------------------------


Date: 13 Jun 89 16:25:06 GMT
From: Kenneth Soohoo
Subject: Re: Mark Williams C

In article <381@laas.laas.fr> ralph@laas.laas.fr (Ralph P. Sobek) writes:
>
>Since the previous postings were discussing what one complier supports
>or does not support, I have a simple question.
>
>Is it true that MWC does not support the IEEE floating point standard?
>Is it in the queue?  According to our local ST mag (precisely: ST
>Magazine), they stated that MWC uses the DEC standard.
>

Yes, Ralph, MWC _does_ support the DEC format, which isn't a heck of a lot
of help with the MC6881 floating point co-processor board, which uses IEEE
standard floating point.  As far as _I_ know, MWC has plans to support
IEEE in the near future (i.e. "we're working on it, OK???").

You should check out, oh, any number of other compilers if you _really_ need
IEEE... Aztec, Alycon... ;-) Oh, and regarding the expansion bus which the
'881 sits on in a Mega, it'd be _really_ hard to make the equivalent slot
for a 520/1040 style machine, sorry.


------------------------------


Date: 13 Jun 89 21:23:11 GMT
From: Ken Badertscher
Subject: Re: Version Number Confusion

In article <5440035@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) writes:
| |
| | Unfortunately, most software checks the version
| | date. For example, the ICD hard disk driver knows about the Beta ROM date,
| | but fails to recognize my 1.4 version, which is dated Feb 22, 1989.
| |
|
| Yikes! Does this mean that my ICD host adaptor won't work with TOS 1.4 until
| I get a new rev of ICDBOOT???


ICD did A Bad Thing.  Actually 2 bad things.  First, they shouldn't have
released ANY software that relied on ANY Beta TOS releases.  All
developers who got early releases of the latest TOS were warned and
foresworn not to base any software on any features of the intermediate
release; we sent it out to allow them to test their existing software.

DON'T BASE ANYTHING IN YOUR SOFTWARE ON INTERMEDIATE OS RELEASES.

Second, they shouldn't have based anything on the date of the TOS ROMs.
As I have said before, there are three supported OS releases; ROM TOS,
Mega TOS, and the one that is forthcoming.  Each has a different OS
version number in the OS header.  ROM TOS and Mega TOS have the same
GEMDOS version number, because GEMDOS didn't change between those OS
revisions.  What's worse, dates in the OS header will vary from country
to country, so by checking OS header dates, you not only make your
software version dependant, you make it country dependant as well.

USE THE OS VERSION NUMBER, NOT THE OS DATE, IF YOU MUST CHECK OS VERSIONS.

'nuff said.


------------------------------


Date: 16 Jun 89 03:19:33 GMT
From: Ken Badertscher
Subject: Re: Mark Williams C

In article <211@nikhefh.hep.nl> n62@nikhefh.hep.nl (Klamer Schutte) writes:
| In article <1557@atari.UUCP> kens@atari.UUCP (Kenneth Soohoo) writes:
| >You should check out, oh, any number of other compilers if you _really_ need
| >IEEE... Aztec, Alycon...
|
| Or you can try TURBOC...

Or you can use Laser C.  Laser supports IEEE format reals, and the software
FP libraries are very very fast.  Megamax has recently added 68881
support in their FP libraries, too!


------------------------------


Date: 16 Jun 89 03:25:46 GMT
From: Ken Badertscher
Subject: Re: v_dspcur

In article <6038@ka3ovk.UUCP> lake@ka3ovk.UUCP (Marshall Lake) writes:
| I'm having trouble getting v_dspcur() to work at all.  [...]
| The fix was supposed to
| be in an auto program provided with the European ST Tour ... but this
| fix doesn't seem to be the trick.

The patch program you're referring to was a fix to appl_tplay, which
didn't work correctly in the ROM TOS release.  Appl_tplay was fixed in
Mega TOS.

I'm not sure about v_dspcur(), but I seem to remember something odd
about it... I believe you have to call the function twice in order to get
it to work (don't ask me why!).

Luck...


------------------------------


Date: 15 Jun 89 18:14:22 GMT
From: Allan Pratt
Subject: Re: TOS

In article <2637@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes:
> In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
> >NEVER NEVER NEVER use an absolute address like $FC0000 because if we
> >ever move the ROM start address (HINT HINT) your program won't work!  The
> >only absolute addresses in any TOS program should refer to published
> >system variables or hardware things like interrupt vectors.
>
> Your not thinking of moving the I/O addresses are you?

Sorry, you're right, the I/O space is definitely nailed down.  That is,
any machine with, say, a Mega-style real time clock will have that clock
chip address at the same place as on a Mega.  That goes for all I/O
devices: if the hardware acts like an ST, it'll address like an ST.
Things which aren't in future machines will, of course, not be there,
and nothing funny will address at the same place.  Things which are
different will address at a different place.  Things which are both the
same and different (i.e. new features, but have a compatibility mode)
will address both ways.


------------------------------


Date: 16 Jun 89 20:42:11 GMT
From: Ken Badertscher
Subject: Re: Minix, ST, and forking...

In article <632@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes:
| Finally, If a blitter was used to copy in the active parent/child, this
| would become even faster on the ST.

Not necessarily.  Depending on how much context needs to be switched,
the overhead of setting up the hardware blit could actually slow the
process of context switching.

Be wary of the tendency to treat the BLiTTER as a panacea for speed
problems.  The 68000, when treated right, can be quite speedy.  The
Atari BLiTTER was designed primarily to aid with graphics processing.


------------------------------


Date: 16 Jun 89 20:17:46 GMT
From: Ken Badertscher
Subject: Re: Setting the seek rate

In article <8906151157.AA03321@ucbvax.Berkeley.EDU> ONM07@DMSWWU1A.BITNET
("Julian F. Reschke") writes:
| I wonder if there is a LEGAL way to set the current seek rate (for using
| 5 1/4''-drives...). What happened to the function Getdsb() in the
| original DR-Gemdos?


The newest TOS adds the Floprate() xbios call which does just that. For
earlier TOS versions, it is necessary to use the undocumented BIOS dsb
locations.  These will be described in the documentation that comes
with the new TOS.  Atari has also released a program (I believe it is
called PCF554.PRG, because it was released to support the Atari PC
external drives), available on several online services and probably from
Atari Customer Relations, which sets the correct seek rate for using the
PCF554 as drive B.

The Getdsb() call (if it existed) would have given you a different dsb
than the BIOS dsb.  GEMDOS also has a dsb, which is actually only an
extension to the bpb that you get from Getbpb().  The function went away
apparently because whoever was working on GEMDOS at the time felt it was
redundant.


------------------------------


Date: 16 Jun 89 18:02:30 GMT
From: Allan Pratt
Subject: Re: TOS

In article <4601@ttidca.TTI.COM> woodside@ttidcb.tti.com (George Woodside)
writes:
> In article <1550@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
> ...[edited]
> >Sversion() only gives the version number for GEMDOS, and that didn't
> >change between original ROMs and Mega ROMs.  The TOS version number is
> >available as the second word of the OS header, whose address can be
> >found at _sysbase, $4f2.
>
> The GEMDOS version is changed with the release of TOS 1.4, I see from
> and earlier posting.
>
> So, when software wishes to take advantage of TOS 1.4 features (such as
> the improved file selector), should the feature be enabled via the
> Sversion call, or a check of the OS header?
> --
> *George R. Woodside - Citicorp/TTI - Santa Monica, CA
> *Path:       ..!{philabs|csun|psivax}!ttidca!woodside

You should use the version number appropriate to what you're up to.  If
you want to know if you have the new file selector, you definitely
should NOT check the GEMDOS version number.  AES and GEMDOS are not
inseparable.  Check the AES version number (it has one) or the OS
version number (described above).

You could check the GEMDOS version number to see, for example, if a
Dfree() call will take all day or not (old ones do, new ones don't).  It
is possible to have new GEMDOS but not new anything else (e.g.  with a
RAM-loaded GEMDOS, currently only used for internal development).

It's best not to tie unrelated things, like the GEMDOS version number
and the file selector, together.


------------------------------


Date: 16 Jun 89 20:00:29 GMT
From: Ken Badertscher
Subject: Re: Communicating with Desk Accessories

Desk accessories eating memory on resolution changes is a mystery to
me.  I haven't witnessed the phenomenon myself, because I've never
looked (I don't switch res very often).  I have no idea why some DA's
exhibit this behavior and others don't.

To cover other questions brought up recently, though -

Because a desk accessory is *not* a process, it does not own memory it
allocates or files it opens.  GEMDOS doesn't know about DA's, so when a
DA allocates memory or opens files, GEMDOS assigns ownership to the DA's
parent process.  What this means is that if a DA allocates memory while
an application is running, that memory will be freed out from under the
DA when the application finishes.

If a desk accessory needs memory that won't be treated like this, it
must allocate that memory before it goes into its main event_multi loop.
That way, the allocated memory belongs to the AES shell, which is
actually the pseudo-process to which all DA's belong.  Memory allocated
in this way won't be freed until a resolution change or reboot.

The only thing a DA needs to free on an AC_CLOSE message is memory it
has allocated or files it has opened during the main event_multi loop,
because it is possible that such memory/files actually belong (as far as
GEMDOS is concerned) to the application that is about to terminate.


------------------------------


Date: 19 Jun 89 17:14:07 GMT
From: Allan Pratt
Subject: Re: Open Files at AC_CLOSE

In article <1158@gmdzi.UUCP> kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes:
> What about an open file? Is the file already closed when the AC_CLOSE
> comes or have I to close it? And when may I reopen it?

Unfortunately, there is a lot of confusion about how the various parts
of the OS interact, especially with respect to desk accessories.

One crucial thing to remember is that desk accessories are meant to
be like the Control Panel or a calculator or something -- you open
them, use them, and close them.  Desk accessories which do things in
"background" are an extension to this concept, and much trickier.

For one thing, a desk accessory is not a separate GEMDOS process, though
it is a separate AES application (it has a separate AP_ID (doesn't
it?)).  The things which AES handles, therefore, are pretty well dealt
with when it comes to desk accessories.  But GEMDOS simply doesn't know
the difference between the mainline application and the accessory.

There is [conceptually, at least] a sentence in the GEMDOS documentation
which says, "All of a process' open files are closed when the process
terminates, and all the memory it owns is freed." What it doesn't say is
that files opened by a desk accessory (and memory allocated by it) are
considered owned by the mainline process, so when the mainline process
terminates, they are closed (freed).

Therefore: DESK ACCESSORIES SHOULD NOT OPEN FILES OR ALLOCATE MEMORY
WHEN THERE IS ANY CHANCE OF THE MAINLINE PROCESS TERMINATING.

The Desktop never terminates, and it's the mainline process when your
desk accessory starts up, so it is safe to open files and allocate
memory when you start up, BEFORE YOU MAKE ANY AES CALLS (including
registering yourself in the Desk menu).

However, not all processes which run are AES processes, so you can't
count on getting AC_CLOSE before process termination.

What *is* safe for the event-driven part of your accessory, however, is
to open a file and/or allocate memory, do some work, then close/free
what you opened/allocated, without making any intervening AES calls.  If
you don't make any AES calls, you'll never stop running, and the
mainline never gets a chance to terminate.  This is not safe for any
interrupt-driven part of an accessory; that's a totally different kettle
of fish.

In the specific case of the serial-to-disk accessory, I recommend
allocating a buffer when you start up, filling that buffer at interrupt
level or with AES events (esp.  if you will never run any non-AES
programs).  Then, when the buffer is full, you can open a file, write
the buffer to it (even append the buffer to it) and close the file, all
at once, without ever giving the mainline a chance to terminate.

I hope this clears up some of the remaining confusion about desk
accessories.


------------------------------


Date: 20 Jun 89 04:22:33 GMT
From: Ken Badertscher
Subject: Re: Setting the seek rate

In article <8906191106.AA27714@ucbvax.Berkeley.EDU> ONM07@DMSWWU1A.BITNET
("Julian F. Reschke") writes:
| Is there a officially approved method to determine wether the TOS 1.4-
| enhancements to the AES are present

Yes, use the AES version number returned by appl_init in the first word
of your application's `global' AES array.

| (knowing that there IS an
| implementation of GEM 2.1 from a dutch company, that doesn't know
| about wind_new and fsel_exinput)...

We are not, nor can we be reasonably expected to be, responsible for
third party replacements for parts of TOS.  It is their responsiblity to
"follow the rules," not vice versa.

| Equally, IF one day there is an Atari-GEM <= 2.1, will it have the
| enhancements from PC-GEM (menu_unregister, Accessories with menus etc.)?

TOS and PC-GEM are divergent as of the first release of TOS.  Of
course we shall endeavor to be as compatible as we can with the newer
GEM versions, but TOS is not PC-GEM.  It is mostly compatible in terms
of the programming interface - but TOS has some enhancments over PC-GEM
and vice versa.  We shall continue to do our best to add whatever
enhancements ST users request, within reason.


------------------------------


Date: 23 Jun 89 20:27:27 GMT
From: Allan Pratt
Subject: Re: Open Files at AC_CLOSE

In article <599@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes:
> There are a lot of other potential "GEMDOS state" related things
> to consider, like changing directories or wiping out the Fsfirst()
> (DTA) buffer.  This could really screw up the "real" GEMDOS process
> if the ACC doesn't restore things.
>
> Do I hear you saying "Nah, that probably won't ever happen?"

No, you heard someone say, "If you change something, change it back
before you let the mainline program run!"

The current directory and DTA address can both be saved, changed, and
restored before making any AES call (AES can only change tasks during
AES calls).  And in the serial-to-disk application I was talking about,
you should allocate the memory at accessory-start time, and do the
open-write-close when you need to, without giving the mainline a chance
to terminate during this procedure.  By allocating your buffer at the
start of the world (mainly, when the Desktop is the current process,
because the Desktop never terminates) you know there'll be enough.  Yes,
there might not be any handles available when you want one, but that
*is* unlikely.


------------------------------


Date: 4 Jul 89 04:03:31 GMT
From: Ken Badertscher
Subject: Re: Is GDOS home?

wesw@ozvax.WV.TEK.COM (Wes Whitnah) writes:
|    Would someone please tell me of a way that an application can
|    _reliably_ tell if GDOS is resident (without killing the program!)?

Do a trap #2 with d0 set to -2.

If the trap call returns to you with d0 still equal to -2, GDOS is not there.


------------------------------


Date: 4 Jul 89 04:29:01 GMT
From: Ken Badertscher
Subject: AES things

to_stdnet@stag.UUCP writes:

| From: stag!thelake!steve@bungia.mn.org (Steve Yelvington)
|    89Jun24 9:37 pm from Ian@The Vale (We have returned!)
| [...]
|  About that Usenet message from Ken B. concerning AC_CLOSED messages and
| freeing up memory/file handles from within an accessory... I did a little
| playing with the concept recently, and it seems like you get the AC_CLOSED
| message **after** then main application has been Pterm'd by DOS.

Desk accessories get AC_CLOSED messages when an application calls
appl_exit.  That's the only time the AES sends AC_CLOSED messages.
Of course, if an application has already terminated, it can hardly
be calling appl_exit ;-).

The desktop itself also calls appl_exit on a resolution change and
just before* an application is launched (to tell the AES that it is
exiting).  The AC_CLOSED messages that the desktop sends to accessories
don't mean that they're going to lose anything, because the desktop
never really terminates as such (except on a resolution change).

|  Speaking of GEM and DRI docs... Here's one for you:  During form_do()
| (dialog) processing, if the user double-clicks on an object defined as
| TOUCHEXIT, the object index of the exit object as returned from form_do() has
| the high bit set.

Yup.  If you don't care about double click reporting, always lop off
the high bit of the return from form_do before using it as an object
index!


------------------------------


Date: 10 Jul 89 17:41:16 GMT
From: Allan Pratt
Subject: Re: legal way to find SPECIAL addresses

pvf@bridge2.ESD.3Com.COM (Paul V. Fries) writes:

> I need to know a "legal" way to determine the locations of
> the GEMDOS mouse variables.  I have a mouse trapping
> program that was written for the particular ROMS that are
> in my 1040ST.  As we all know, TOS 1.4 will soon be here.
> I want to fix up the program to be more general so I don't
> get bitten when the new TOS arrives.

You can do this legally, but you might not be able to do it from the
AUTO folder, and you can't do it legally the way you describe (linking
into the trap and clobbering the Y movement value).  What you should do
is use the VDI exchange-mouse-movement-vector call. It will have the
same effect as you describe, but will be legal.

Another way is to use the negative Line-A variables... If you're a
developer, get SALAD (Still Another Line A Document).  If you aren't,
then you should become one because you get cool stuff like Landon
Dyer's assembler, my linker, my debugger, and SALAD.


------------------------------


Date: 14 Jul 89 17:55:37 GMT
From: Ken Badertscher
Subject: Re: timer C

ignac@electro.UUCP (Ignac Kolenko) writes:

| does GEM not like it if you screw around with the 200Hz system timer??

It does not indeed.  If you turn off the 200Hz timer for any length of
time, the AES gets very confused.  The AES uses it to time mouse double-
clicks, and even to do dispatching between accessories and the main
application.

If you're going to turn off the 200Hz timer for very long, you need to
"feed" ticks to the system to be sure that the AES doesn't lose its mind.
This is documented in the Hitchhiker's Guide to the BIOS.


------------------------------


Date: 16 Jul 89 18:29:29 GMT
From: Ken Badertscher
Subject: Re~2: legal way to find SPECIAL addresses

uace0@uhnix2.uh.edu (Michael B. Vederman) writes:

| Speaking of mouse movement and the such...  Is there a way to *prevent* the
| AES from getting mouse clicks at the desktop?  In other words, can one turn
| off mouse packet handling to AES?  Like taking over the AES mouse handler?
| Unfortunately, the AES mouse handler is not at all documented (VDI, yes).

If you take the VDI mouse handler, *after the auto folder*, then you've
got it.  The AES gets clicks from the VDI mouse handling chain, you may feed
clicks to the AES or not, as you choose.  You have to be careful _when_
you take and give mouse clicks (or mouse movemement) because the AES has
several state variables that you can't get at, and it may be in the middle
of giving someone a double click, or it may restore an internally saved
mouse position when you don't expect it.


------------------------------


Date: 21 Jul 89 10:05:41 GMT
From: Ken Badertscher
Subject: Re: Quick-ST

ignac@electro.UUCP (Ignac Kolenko) writes:

| hmmm, i never heard of the ST's roms at addresses other than the regular
| addresses. nothing we can do about that. yell at atari   :-) :-)

And Atari will yell right back at you! >:->

There is a perfectly legal and documented way to get the base address
of the ROM if you really need it.  Which you shouldn't, for almost all
applications.

A pointer to the OS header is located at $4f2; the structure of the OS
header is documented in the Hitchhiker's Guide to the BIOS (contact
Gail Johnson at Atari 408/745-2568 for information on how to get ST
developer documentation).


------------------------------


Date: 21 Jul 89 22:16:47 GMT
From: Ken Badertscher
Subject: Re: Tiny screen; large border

calengr@cory.Berkeley.EDU (California Engineer Magazine) writes:

| My Atari 520ST is over three years old now, but I just
| realized that my screen size is much smaller than the
| monitor's screen size.

That's right, and there's a reason for it.

The monitor is adjusted at the factory that way so that it has a  1:1
aspect ratio.  That way, when you draw a circle on your monochrome
screen, what you see really looks like a circle.  And when the VDI
drivers draw graphical text, the characters can be scaled so that what
you see is the actual size of what you get, and not distorted.


------------------------------


Date: 26 Jul 89 16:31:45 GMT
From: Allan Pratt
Subject: Re: DOES TOS 1.4 DO THIS?

UUCJEFF@ECNCDC.BITNET writes:

>One thing there seemed to be no mention of, while TOS 1.4 formats disks
>100% compatible with MS DOS, does it also flag bad sectors so you can use
>a disk with bad sectors (as in MS-DOS)?
>i.e. in format, file copy, and disk writes.

TOS has always marked bad sectors when formatting, in exactly the same
way that MS-DOS does.  No other operation marks bad sectors, under
either TOS or MS-DOS, except perhaps a utliity which does that
explicitly.

This is a good time for the reminder that TOS 1.4's desktop format
operation is MS-DOS compatible, but other programs which format disks
are not necessarily compatible.


------------------------------


Date: 26 Jul 89 16:35:44 GMT
From: Allan Pratt
Subject: Re: Hard Disk Auto Boot Bypass

hcj@lzaz.ATT.COM (HC Johnson) writes:

>For 2 years I have auto booted off a hard disk.
>I have used the Bypass program by Small in Start magazine to save me
>when the /auto or .acc program went bad and the system wouldnt boot.

Why did you need that?  I'm not quite sure of all the oldest versions,
but most Atari hard disk drivers let you avoid booting from the hard disk
by holding down the "Alternate" key.  You can't do this too soon -- you
have to do it after the keyboard's initialized.  The procedure is to
turn on your machine and wait for the floppy disk's access light to come
on (the first time).  Then hit the Alternate key and don't let go until
you see the Desktop.  The hard disk shouldn't have booted.

This is a feature of the hard disk driver, not the ROMs, so a hard disk
made bootable by something other than HINSTALL may not have this
feature. Also, like I said, the very oldest bootable hard disk driver
might not have it.


------------------------------


Date: 31 Jul 89 17:38:02 GMT
From: Allan Pratt
Subject: Re: Mega ST EPROMS

schuster@dasys1.UUCP (Michael Schuster) writes:
>What are the EPROM equivalents for the 1 megabit ROMS used in the
>Mega ST (the ones with two of the six sockets filled)?

Evidently, there aren't any.  It's a pain the the rear for us, too.


------------------------------


Date: 31 Jul 89 17:35:44 GMT
From: Allan Pratt
Subject: Re: DOES TOS 1.4 DO THIS?

ignac@electro.UUCP (Ignac Kolenko) writes:
>if it has always marked bad sectors, why does the desktop stop and say that
>the disk is unusable sometimes, and other times it finished a format ...

If there are too many bad sectors, or if Track 0 of the disk is bad,
you get the "unusable" message.  I forget how many is "too many." As
for writing to these bad sectors, it shouldn't happen.  If it does,
perhaps the sectors in question are marginal: they formatted ok but
subsequent accesses were bad.

It's also possible that I'm totally wrong and old TOS didn't mark bad
sectors correctly.  What version are you using?  (Original) TOS 1.0 or
(Mega) TOS 1.2?

After a format of a disk with "known bad sectors" try looking at the
FAT. Are there any entries (after the first two) which are not $000?
$FF7 is the bad-sector mark, I think.  The alert after the format
should show the size of the disk after accounting for bad sectors and
the two unused clusters at the end of the disk.  (Don't open that can
of worms, please!)


------------------------------


Date: 1 Aug 89 18:25:46 GMT
From: Kenneth Soohoo
Subject: <<WARNING to DESK ACC Creators>>

TO ANYONE DEVELOPING DESK ACCESSORIES:

Don't use Fsfirst()/Fsnext() without first setting the DTA to your own local
buffer area using Fgetdta() and Fsetdta()!!!!!!!!

If you're a Desk Acc, you'll be overwriting the desktop's DTA, and you
never know what that can do to your desktop...

Now, once you're done with your Fsfirst() and Fsnext()ing, be sure to
restore the DTA to it's old value!!! That _too_ can cause problems...

SAMPLE CODE:
(Using MWC 3.0.6 Bindings. In some compilers "DMABUFFER" is "DTA".
 In any case, it's a 44 byte buffer that contains usefull info about
 file searches.)

	int 		err;
	DMABUFFER	*oldbuff, newbuff;

	oldbuff = Fgetdta();		/* Save old DTA for later */
	Fsetdta(&newbuff);		/* Tell GEMDOS about OUR buff */

	/*
		Insert Fsfirst() and Fsnext() calls here...

		err = Fsfirst("*.*", 0);	/* First DTA fill */
		while (err == E_OK) {
			/* Process DTA */
			err = Fsnext();		/* Fill DTA again */
			}
	*/

	Fsetdta(oldbuff);		/* Restore for desktop's use */


Hope this helps...


------------------------------


Date: 11 Aug 89 17:36:54 GMT
From: Dan Scott
Subject: Re: HDX301

in article <890807.19362146.008300@SFA.CP6>, Z4648252@SFAUSTIN.BITNET (Z4648252)
 says:
>
>
>     Could some kind soul please send to me the HDX utilities version 3.01?
>     There is no GEnie or CompuServe node here and I noticed that HDX301.ARC
> was available in the GEnie listings.
>     Send to my listed E-MAIL  address.
>     Many thanks!
>
> Larry Rymal in East Texas <Z4648252@SFAUSTIN.BITNET>

The ARCed set of the new utilities is also available on the Atari Base BBS
system run by Atari.  The number is 408-745-5308.  Expect a 12-24 hour
lock-out period (meaning, call back and you should be verified) because of
little hackers running amok the system.

Dan


------------------------------


Date: 14 Aug 89 23:21:11 GMT
From: John Townsend
Subject: Re: Archive bit

in article <8908091359.AA08065@ucbvax.Berkeley.EDU>, SQ79@liverpool.ac.UK (Mark
 Powell) says:
>
>
>   Bit 5 of a file mode is the archive bit. This is to do with backing up
 files.
> When a file is backed up it's archive bit is set. When it is next written to
> the bit is cleared. From this senario the disk back up program can tell
 whether
> a file has been modified since the last back up and if so back up the file
> otherwise leave it. This enables an incremental backup to be performed i.e.
> back up your hard disk totally every month, and backup just the files that
 have
> changed every week. Unfortunatley this procedure doesn't work on the old TOSes
> (or so I'm informed) TOS 1.4 is said to fix this.
>   I have seen plenty of files on my disks with this bit set. You may be
 running
> a different TOS from me though. I've got a UK TOS 1.0 dated 20/11/85
> i.e. 20th November for you in the US who don't put the date in ascending or
> descending order of significance (make your minds up!)
>

You have it backwards. In TOS 1.4, the bit is set when a file is created or
modified. The backup program should clear it after backing up the file.


------------------------------


Date: 23 Aug 89 17:42:37 GMT
From: Allan Pratt
Subject: Re: gulam bug

dennis@marge.math.binghamton.edu (dennis pixton) writes:
>I've noticed several problems with redirection in gulam (1.03.04.05) [...]
>I wrote a trivial program, args.prg (compiled with mwc) to dump out its
>args, the environment, and whether the file handles are ttys.  When I run
>	args a b > junk
> I then simply *rename* args.prg to shar.prg and run
>	shar a b > junk
>This time the output is to the screen [...]

Gulam has a serious bug in the code for launching programs.  There is a
table of the internal commands, and flags telling how to handle the
argument list for each.  Gulam looks your input up in this table, and,
in the case of an external command, won't find a match.  However, the
flags of the last internal command it looked at will be used to
parse your arguments!  Some flags mean "Don't expand wildcards" and
others mean "don't do anything."  I happen to have the source,
so I fixed this problem back in March, but I don't know if the
official types have noticed the bug yet.

There are other bugs in redirection, notably when you use shell_p to
exec a program and redirect its output.  Gulam is the shell I hate to
love: it's too good to throw out, and yet so bad in some ways.


------------------------------


Date: 28 Aug 89 16:55:09 GMT
From: Ken Badertscher
Subject: Re: A little detective work...

andyc@hplsla.HP.COM (Andy Cassino) writes:
[ List of TSR's used by Mr. Cassino deleted ]

| My point is, this is all great sport for us techies, but it's no fun for
| your average home/business user trying to DO SOMETHING besides play junior
| hacker.

Which is precisely why we fixed the majority of the problems you
mention in Rainbow TOS (a.k.a. TOS 1.4).  When you get it, you'll
be able to toss almost all of those TSR's you're using.

Available now at a dealer near you.  And if it isn't, please WRITE A LETTER
to Atari Corp. asking why Rainbow TOS isn't available at your dealer.


------------------------------


Date: 30 Aug 89 21:34:22 GMT
From: John Townsend
Subject: Re: ROM disassembly for TOS 1.4

in article <9401@chinet.chi.il.us>, saj@chinet.chi.il.us (Stephen Jacobs) says:
>
> One of the more useful tools in programming the ST is the commented ROM
> disassembly in the Abacus ST Internals book (English translation of the
> corresponding Data Becker book, I think, but I'm usually wrong).

I disagree completely. People should use the documented OS calls. They
shouldn't fumble around inside the Operating System looking for calls and
data structures that weren't intended for their use.

>    And a small love-note to the Atari contingent: IBM did it, even though
> some of them must nearly have died doing it: they published a complete,
> official ROM disassembly.  Many developers did exactly what you don't want
> us to do: they exploited internal code and data structures.  Their code
> broke when new DOS versions used the ROM code differently.  Some of them
> learned their lesson.  Near-clone ROMs took more victims.  But on balance,
> I think you'll find pretty nearly complete agreement that the published
> ROM code has helped the PC.  An Atari-authorized, commented disassembly of
> TOS 1.4 as of a given date (say the delivery date of the first production
> lot?) would help programmers enormously.
>                                 Steve J.

I can't believe what I am hearing! You state my case for me. Programmers
depended on the things they read in the IBM disassembly and when things
changed their code broke! Isn't that a good enough reason for not releasing
disassembled or source versions of sections of the Operating System?

My job at Atari is support. I am one of the people that has to take calls
from irate customers that are mad because their favorite program breaks on
their new computer (with MEGA TOS ROMs) and I am the one that has to tell
them that it's because the manufacturer of the software didn't follow the
rules when writing his/her program. Most of the time, Atari gets the blame
(in the customer's eyes) for these problems with software, when in reality
it's the software that is at fault.

Anyway, there's my position on disassembled versions of TOS.


------------------------------


Date: 31 Aug 89 01:19:58 GMT
From: Allan Pratt
Subject: Re: Duesseldorf: personal impression of the TT(T)

cmcmanis%pepper@Sun.COM (Chuck McManis) writes:
>Hmmm, the whole graphics capability question is really foggy so far.

Here's some really straight scoop about the TT from inside Atari:

The video palette has *4* bits per gun for color values.  That is, you
have a total of 4096 colors: 16 levels each of red, green, and blue.
(The ST has a palette of 512 colors: 8 levels for each gun.)  Another
"color" mode provides 256 levels of grey (actually green), for really
fine reproduction of a black-and-white image.  This is independent of
the resolution: if you're in a 16-color mode, you can pick any 16
levels from the spectrum of 256.  (We call this hyper-monochrome:
one color, but a lot of it!)

There are *6* video modes: the three ST modes (totally compatible),
plus 640x480 16-color, plus 320x480 *256* color, plus 1280x960
monochrome.  ALL of these modes except the last can be shown on a
single monitor.  That monitor need not be multisync.  It can be a
slightly modified VGA monitor, or (of course) the monitor which Atari
will sell for the TT.  The last mode needs a Viking monitor or
something similar.

ST high rez (640 x 400 x 2 colors) is not limited to black and white:
you can choose any two colors.

>Does this mean it has a "DMA" port like the 520/1040/MegaX ? Does it have
>a "real" SCSI port as well? What kind of through put can be expected from
>the hard disk interfaces? Can it do DMA and access > 4Meg ?

Yes, there is a DMA port like on the ST and Mega.  Your hard disk will
plug right in.  You can connect a bootable SH204 and it will boot!
There is also an external SCSI port.  The SCSI port can access the full
32-bit address space; the ACSI port is limited to 24-bit addresses.
The internal hard drive is connected to the SCSI bus.

>Is the
>VME slot the _only_ way to expand it, or does it have a Mega compatible
>expansion connector as well?

There are a number of ways to expand the TT: you can add 2MB of
dual-purpose (video and CPU) RAM, or 10MB when 4Mbit chips are
available.  You can add 4MB of REALLY FAST 32-bit nybble-mode RAM (not
video-capable), and there's the VME bus.

The number 2MHz that's been bandied about needs some explanation: The
CPU and memory clock speed is 16MHz.  There are four clocks in a bus
cycle.  For dual-purpose RAM, around half the bus cycles go to the
video or refresh.  Therefore, the CPU gets around two million MEMORY
ACCESSES per second, or 2MHz.  There are other architectural details
which make it a little faster than that.  And remember, each access
gets you 32 bits, not 16 as on the ST.  Also, since the CPU is
allocated half the bus cycles, it isn't ALWAYS postponed by video or
refresh: it might try to access the bus just as its turn comes up, and
not wait at all.  Therefore dual-purpose memory accesses run at MORE
THAN 2MHz.

"Fast" RAM does not have video taking up any of the cycles, so you
don't have to wait for that.  It takes 4 or 5 clocks (I think) to set
up a fast-RAM access, but "nybble mode" means that the CPU fills its
cache in "burst mode" at one cycle per subsequent access.

The VME logic introduces one wait state, so a VMEbus access takes 5
clocks. (Your mileage may vary: VME cards vary widely in response
time.)  But, again, you won't be held off the bus by video.  VME in the
TT shown in Germany is A24/D16 (24 bits of addess, 16 bits of data).

>[programs can load in fast RAM or dual-purpose RAM]

By a "loader option" the original poster means "load program off disk"
not "load .o files into a .prg file."  This is correct: there are flags
in the PRG header which control the behavior of Pexec and Malloc.  Most
program can run in fast RAM -- programs which change the screen base
pointer and some other things can't, though.

>[RAM on the VME bus]

You *can* put memory on the VME bus.  The performance penalty is not
bad.  TOS will recognize that memory and use it for programs if you set
it up right.

>Does it have a Blitter ?

No need for one.  The reason for the Blitter is to remove instruction-
fetch overhead from memory operations, and with the 68030 on-chip
cache, the TT does just fine without it.

>>It is the cheapest workstation of that power around (about 1/2 the price
>>of comparable competitors here in Germany).

You can say that again.  Please, people, remember that when you compare
the TT with a Next machine, for instance, you're talking about roughly
4x the price!  JT's motto is Power Without the Price, and we think
we're giving you just that.


------------------------------


Date: 4 Sep 89 03:12:41 GMT
From: Ken Badertscher
Subject: Re: Amiga and ST Reliability

mitchell@cbmvax.UUCP (Fred Mitchell - QA) writes:

| ... can you make the co-processor
| transparent, so that properly-written software can use it if there, and
| not die if not?

  Yes.
  The SFP-004 coprocessor interface card can be used transparently
by software which uses the libraries which Atari made available to
developers.  Third party compilers are also supporting the coprocessor,
including Laser and Turbo C.
--
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>


------------------------------


Date: 12 Sep 89 21:46:36 GMT
From: Allan Pratt
Subject: Re: TOS 1.4 bug?

VBRANDT@DBNUAMA1.BITNET writes:

>SYTANG%CSUGREEN.BITNET@Forsythe.Stanford.EDU asks:
>  - You don't have to use FOLDR100 with the new TOS 1.4, unless you want to
>    access hundreds of folders in the same 'session'.

I have to jump on this one: you don't need FOLDR100 unless you access
hundreds of folders AT THE SAME TIME.  When you open a file, the
directories from the root of that drive down to that file are "in use."
When you close the file, they're not "in use" any more, and the space
is reclaimed.  Better internal memory management like this, and some
other things (like way faster FAT code and program launching), is why
you should get TOS 1.4 in the first place.


------------------------------


Date: 13 Sep 89 18:02:16 GMT
From: Allan Pratt
Subject: Re: TOS 1.4 on disk

wardlaw@ucrmath.UCR.EDU (Johnie Wardlaw) writes:
>Now that TOS 1.4 (aka Rainbow TOS) is available, does this mean that the
>disk based beta version supplied to registered developers is "up for grabs"?

If by "up for grabs" you mean "freely distributable" the answer is no.
Besides being illegal (it was supplied to developers under their
nondisclosure agreements, and is copyright by Atari in any case) it's
dangerous.  The version on disk is not the version in ROM.  Also, it's
not good business to let people use lots of different, unofficial
versions: we don't want to be in the position of saying, "Sorry, we
can't help you; we don't support the OS you're using."

Please don't use or distribute disk-based versions of TOS 1.4.


------------------------------


Date: 15 Sep 89 02:20:24 GMT
From: Ken Badertscher
Subject: Re: TOS 1.4 bug?

hcj@lzaz.ATT.COM (HC Johnson) writes:

| 2. I found that it is absolutely necessary to REMOVE desktop.inf and reboot
| before doing a save desktop.  There are incompatibilities between how 1.1
| organized it and 1.4.

 There should be no incompatibility between the Rainbow TOS DESKTOP.INF
file and those created with previous versions of TOS.  If you're having
a problem, please let us know the details.  The DESKTOP.INF files should
be completely interchangable, with the obvious exception that
DESKTOP.INF files created with Rainbow TOS which have auto-launch files
won't cause an auto-launch with an older TOS version.

------------------------------

Date: 15 Sep 89 21:39:31 GMT
From: Allan Pratt
Subject: Re: adding a 68881

The product you want is the Atari SFP004 Floating-Point Math Peripheral
or some such name.  SFP004 should be sufficient for your dealer to
order one if he doesn't already have one.  It only goes into Megas; it
fits on the internal expansion bus.

Of course, on a 68000 you can't talk to it as well as a 68020 can;
you have to use it in "peripheral mode" where the handshaking protocol
is handled in software, not directly by the CPU.  Only programs compiled
specifically with the SFP004 in mind will run faster; others won't notice it.
(In that respect it is unlike the Blitter.)

The SFP004 comes with a disk, I think, containing the guts of a library
you can merge with Alcyon's libm to make lib81; link your Alcyon C
programs with that library and they will use the SFP004 if it's
installed, and Alcyon's software routins if it's not.  There is also
source for those routines, as examples you can use in assembly language
or for other compilers.  I *think* that disk is part of the SFP004
package; if it's not, it should be available from Atari.


------------------------------


Date: 13 Oct 89 17:44:24 GMT
From: Allan Pratt
Subject: Disk Speedup

hcj@lzaz.ATT.COM (HC Johnson) writes:
>In article <1725@atari.UUCP>, jansen@atari.UUCP (Mark O. Jansen) writes:
>> >  Is there a program that will speed up disk access on my hard disk? I
>> >  ...Does TOS 1.4 help with this ? What can I do in the meantime?
>> Yes, Rainbow TOS (a.k.a. TOS 1.4) helps with this.  A LOT.  ...

>... After 16-20 meg of copying, it gets noticeably SLOW!

It may be slow, but good lord, not as slow as TOS 1.2!

The "slow" part is the first write to a new file.  GEMDOS looks for the
first free cluster in the FAT, always starting from the beginning. When
there are 16 solid MB of allocated clusters, that's a lot of FAT
sectors to check before finding a free cluster.  On TOS 1.2, this is
REALLY APPALLINGLY SLOW!  On TOS 1.4, this is kind of slow. On TOS 1.4
with enough GEMDOS disk buffers to keep the whole FAT in RAM, it is
REALLY FAST!  Try Dfree on a 32MB partition in under 1 sec!

(Allocating the second, third, ... n'th cluster is not slow, because
there the search begins with the previous cluster, not the start of the
FAT.)

Ken Bad should have posted "CACHEXXX.PRG" here - if he hasn't, I'm
sure he will.  If you use it and be sure XXX is equal to the sum of the
FAT sizes (in sectors) of your disks, GEMDOS will load them  up once
and never have to hit the disk for reading a FAT again!

It is not the case that the FAT is written after each allocation. It's
written when a buffer is re-used or the file is closed.


------------------------------


Date: 13 Oct 89 20:36:06 GMT
From: J. E. Patton
Subject: TOS 1.4 features??? (Was Re: Disk Speedup)

in article <1728@atari.UUCP>, jpatton@atari.UUCP (J. E. Patton) says:
>
> in article <1113@electro.UUCP>, carlo@electro.UUCP (Carlo Sgro) says:
>>
>> In article <1725@atari.UUCP> jansen@atari.UUCP (Mark O. Jansen) writes:
>>>I'd recommend you get Rainbow TOS, for this and lots of other reasons.
>>
>> Well, what are those reasons??  I've seen a LOT of discussion about 1.4 but
>> I still haven't seen a summary of its new features and how to use them.  Is
>> this asking too much (honest question!)?
>>
>>
>> --
>>
>> Carlo Sgro                             ... but does Bo know nuclear physics?
>> watmath!watcgl!electro!carlo
Dealers are now receiving information sheets along with
their Rainbow TOS orders.  If your dealer hasn't ordered
the new TOS recently he may not have it, but his contact
in dealer services at Atari Corp. will be happy to send
it to him.

In short the addendum addresses:

   1. The file selector (expanded drive selector,improved wildcards).
   2. Moving files by holding down [Control] as you click on and drag
      selected files.
   3. Skip option available for group copying.
   4. Aborting group move, copy, or delete operation by holding
      down [Undo].
   5. Disks formatted are fully MS-DOS compatible.
   6. The Install Applications option allows you select an application
      to auto-boot.
   7. Copy and Format dialogs have been combined.
   8. Folders can be renamed.
   9. The [Control][Alt][Delete] sequence will reset your computer.
      The [Control][Alt][Right Shift][Delete] causes a cold boot.

The addendum does not address improvements such as improved
FAT searches or a more responsive mouse.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                            ...ames!atari!jpatton


------------------------------


Date: 16 Oct 89 20:30:08 GMT
From: Allan Pratt
Subject: TOS problem ?

piet@cs.ruu.nl (Piet van Oostrum) writes:

>I encountered a strange TOS behaviour (TOS 1.2):
>I Fcreate a file, then Fopen the same file (not very usual, I agree).
>... Finally I close the second handle, and forget to close the
>first one, (or close that last). Result: an empty file.

Well, that's interesting, but only just.  Opening the same file
twice is something which GEMDOS doesn't handle well (pun intended).

I can apologize for only so long for how bad GEMDOS is before the
blame shifts from the guy who wrote it (for introducing the bugs) to me
(for not fixing them).  I hope I haven't gotten to that point yet.


------------------------------


Date: 19 Oct 89 23:51:10 GMT
From: John Townsend
Subject: official tos 1.4 release

in article <4634aec9.14a1f@force.UUCP>, covertr@force.UUCP (Richard E. Covert)
 says:
>
> The problem Greg is that you just plain and simply can't count on
> Atari for support!! If Atari was going to support the ST, why didn't Atari
> license GPLUS from Charles Johnson and include it in TOS 1.4??
>
> Why didn't Atari make any improvments in GDOS for TOS 1.4?? I have over
> 3 megs of GDOS fonts for my SLM804 and if it wasn't for Charles Johnson's
> GPLUS I wouldn't use any of them!! The GDOS support in TOS, even TOS 1.4,
> is almost zero compared to what GPLUS offers. And GPLUS has been out for
> a year now, so Atari could have licensed it from Charles Johnson.
>
> And Atari didn't even want to admit that there was a bug in the serial
> port code in TOS 1.4 until the Canadian hacker showed Atari the actual
> bug in the code. Pretty responsive of Atari, huh?? And this is for an OS
> that has been under development for 2 years!! After 2 years, you would think
 that
> Atari would have it right!!!
>
> Boy, a good outline font system, aka the macintosh system, would really be
> great for the ST!! But asking Atari for anything like that is like jumping
> to the moon, you'll never get there!!
>
> I like the third party support starting to appear for the ST. My favorite
> product is the Turbo16 product from FAST TECHNOLOGY. T16 really speeds up
> my Mega ST!! It is great!!!
> So, lets support the good 3rd party enhancments to the ST and hope that
> things will get better IN SPITE OF ATARI!!
>
> Rich (Proud owner of a souped up T16ed Mega ST4!!) Covert

First, TOS 1.4 is a product. GDOS is a product. They are COMPLETELY
independent of each other.

As for the serial port, We found the problem and we fixed it via the
TOS 1.4 patch. Unfortunately, it was not found until after the release of
the ROMs. To verify this, we did not receive a single SPR on this problem
from the developers that had the Beta version of TOS 1.4 or any reports
from anyone until AFTER the ROMs had been finalized.

But, the end result is that the problem was reported, we looked into it,
found there was a problem, fixed it, and released a patch program via the
Networks and Dealer Network. What more do you want from us??

-- John Townsend				ames!atari!towns
   Atari Corporation


------------------------------


Date: 20 Oct 89 18:07:07 GMT
From: Allan Pratt
Subject: CACHEXXX, (FATs, etc.)

Ritzert@DMZRZU71.BITNET writes:

>According to Allan, XXX must be exactly equal to the size of the FAT.

Please, this is a gross misunderstanding.  If it *had* to be exactly
equal to anything, we would have written it to compute that thing
when it ran.

What I said is that there's little point in making XXX GREATER than
the sum of the FAT sizes.

>Related question: is it possible with tos14 to increase the cluster
>size, i.e. shorten the FATs dramatically and thus speed up the hd even
>further? Will CACHEXXX support such a configuration?

TOS 1.4 FAT handling is so fast, you wouldn't notice.  My God, it's
DOZENS of times faster than TOS 1.2 FAT handling, and certainly
acceptably fast in its own right!  When the FAT is entirely cached, a
Dfree() call on a 16MB partition takes under a second!  That's  fast
enough for me.

HDX on release 3.01 of the Atari Hard Disk Utilities disk allows you to
create partitions greater than 16MB in size.  It accomplishes this by
making "sectors" on the disk appear to be larger than 512 bytes. A
cluster is always two sectors, but larger sectors means more data per
cluster, and therefore fewer FAT entries.  Not all disk utilities use
Getbpb() to find out how big a sector is, so they won't all work with
this kind of partition. For maximum compatibility, therefore, this
feature only kicks in on large (>16MB) partitions.

CACHEXXX *does* support the larger sector size.  No other cache program
can, because it doesn't know where to look to find the sector size it
should use.  Don't use any other cache program if you have any
partition >16MB created by this HDX.

FYI: on the disk labelled 3.01 you will find HDX's version number is
3.00 and AHDI's version number is 3.01.  If you use HINSTALL to make
your hard disk bootable, the version number you will see when it boots
is 3.01.  This is all well and good.  If your hard disk driver, whether
installed by HINSTALL or loaded from your AUTO folder as AHDI.PRG, says
it's version 3.00, GET THE UPDATE.  AHDI and bootable disks version
3.00 are DEADLY to data.


------------------------------


Date: 25 Oct 89 17:07:10 GMT
From: Allan Pratt
Subject: 82 tracks, twister, etc.

krieg@jupiter.uucp (Andrew Krieg) writes:

>I have a few questions about disks and disk formatting for the ST.
>	1) [What is Twister format?]
>	2) [Why 82 tracks?]
>	3) [Are there any 1.4M drives out there?]

"Twisted" disks have sectors on successive tracks offset from one
another.  Instead of always starting sector 1 at the index mark, they
start sector 1 there on track 0, sector 3 on track 1, sector 5 on track
2, and so on.  This makes disk I/O faster, because there are only two
sectors of latency between reading sector 9 from track 0 and sector 1
of track 1, instead of 9 sectors of latency waiting for the whole disk
to spin around.

You get "Twisted" disks any time you format a disk from the Desktop
using Mega TOS or any newer TOS.  Once the disk is formatted it will be
fast no matter where you use it.

Atari disk drives are only guaranteed to handle 80 tracks.  Some people
have discovered that some drives can actually access 82 tracks, so they
have written formatters which will format 82 tracks.  This is not
recommended, and you can actually damage your disk drive by telling it
to seek so far that it bangs into something.  The Desktop format
operation will only format 80 tracks.

I am not aware of any 1.4M drives available for the ST.  I know you
couldn't just plug one in: they get 1.4M by doubling the data rate, and
the controller inside the ST couldn't handle it.


------------------------------


Date: 25 Oct 89 21:15:21 GMT
From: Allan Pratt
Subject: Which filehandle for stderr?

piet@cs.ruu.nl (Piet van Oostrum) writes:

>Which filehandle should be used for stderr? I have seen compilers that use
>2 and others that use -1.

>If you use 2: you can redirect stderr, but it is not official TOS usage (2
>is supposed to be stdaux). So you need a sheel that sets up 2 to default to
>the console. On the other hand it is Unix compatible.

>If you use -1: it is TOS standard, compatible with the desktop, but you
>can't redirect it to a file.

Boy, if only all the questions on the net were this well thought out
and concise.  Way to go, Piet!

My personal opinion, not to be construed as an Atari policy statement,
is that handle 2 is a fine choice.  I realize it requires a shell which
supports it, but I think it's worth the effort. You can even tell if
you've been run from the Desktop, and if you are, you Fforce handle 2
to -1 or something.

(You can tell if you're launched from the Desktop by checking for a CR
character just PAST the end of your command line.  It's not very nice,
but it works.  Here's the code you'd have to use in your startup,
before anybody munges the command line.)

-----

	move.l	<basepage>,a0
	lea.l	$80(a0),a0
	move.b	(a0)+,d0
	ext.w	d0
	cmp.b	#$d,(d0,a0)
	bne	notdesktop

	... launched from desktop ...

	bra	done

notdesktop:

	... not launched from desktop ...

done:

-----

Of course, if your shell puts a CR there in a misguided attempt at
being compatible with the desktop, you'll be in trouble. Another way to
tell is to see if there's anything but PATH in your environment: most
shells put SOMETHING there...


------------------------------


From: Ken Badertscher
Subject: GEMDOS Extended Argument Spec

GEMDOS EXTENDED ARGUMENT (ARGV) SPECIFICATION
---------------------------------------------

Introduction

The Pexec() function of GEMDOS allows a program to pass to a child
process a command line up to 125 characters long, with arguments
separated by spaces.  No provision is made in GEMDOS for the child to
know its own name.  This makes it difficult for C programs to correctly
fill in argv[0], the standard place where a C program finds the command
which invoked it.  Because the command line arguments are separated by
spaces, it is difficult to pass an argument with an embedded space. 
This document will specify a method of passing arguments which allows
arbitrary argument length, embedded spaces, and support for argv[0].

Standard Argument Passing

The Pexec Cookbook specifies how to use Pexec() to launch a child
process, passing a command tail (argument string) and an environment. 
Before getting into the extended argument scheme, let's review how
arguments are normally passed to a child.

A parent process builds a command line into an argument string - a null
terminated string whose first byte contains the length of the rest of
the string - and its address is passed as one of the arguments to
Pexec().  GEMDOS copies this argument string to the basepage which it
creates for the child.  Thus the parent is responsible for gathering
all the child's arguments into one string.  This is normally handled by
a library exec() function.  The child is responsible for parsing the
string of space-separated arguments back into an array of strings. 
This parsing is normally handled by the child's startup code.

Evolution

Several methods of bypassing the limits imposed by Pexec() have been
used by GEMDOS programs.  Some allow a user to specify a file on the
command line which contains the rest of the arguments.  Others get a
pointer to the arguments, or the arguments themselves, from the
environment string.  Most MS-DOS programs use a command file for the
extra arguments.  This can be inconvenient for a user, cluttering the
file system with command files, and making the operation of batch files
and makefiles more confusing.

Several "standards" have arisen on the ST which use the environment to
pass arguments.  While more convenient than command files, these
standards have other problems.  Some rely on sharing memory between
parent and child processes.  Some take advantage of undocumented
features of the operating system to get argv[0].  Others give the
child process no way to validate that the arguments it finds are
intended for it.

Rationale

In order to pass more than the standard 125 characters worth of
arguments to a child, or to let the child find its name, the parent
must place the extra information in a place where the child can access
it safely and legally.  The most convenient place is in the child's
environment string.  An environment string is a series of
null-terminated strings of the format "VARIABLE=value" (e.g.
PATH=c:\bin,c:\etc, or ShellP=YES).   The last null-terminated string
in the environment is followed by a zero byte, thus two consecutive
nulls indicates the end of the environment.   The environment is
allocated for the child by GEMDOS, it is owned by the child, and its
contents can be specified by the parent.

The child must have some way of knowing that the arguments which
it finds in its environment are intended for it.  The child may have
been invoked by a parent which does not conform to this specification. 
Such a parent would leave _its_ arguments in the environment, and could
pass that environment on to the child.  The child would mistakenly
interpret its parent's arguments as its own.

Placing arguments in the environment passed to the child gets around
all of the command line limits of the standard Pexec() command tail. 
Because there is no limit on the length of the environment, arbitrary
length arguments are supported.  Arguments placed in the environment
are null terminated, so they may contain spaces.  A parent can also
place the name of the command with which it invokes the child in the
child's environment, providing support for argv[0].  Validation of the
extended arguments can be placed in the standard Pexec() command line,
by assigning a special meaning to an invalid length byte.

The GEMDOS Extended Argument Specification

This specification uses the convention that the presence of an
environment variable named ARGV (all upper case) indicates that extended
arguments are being passed to the child in its environment.  This means
that ARGV is a "boolean" environment variable.  For the purpose of this
specification, its value is not significant, but its presence indicates
that the strings following it are the arguments for the child. 
Implementations of this specification are free to give the ARGV
environment variable any value.  The ARGV environment variable must be
the last one in the environment passed to the child, so that the child
can truncate its environment at that point, and treat everything before
the ARGV as environment, and everything after it as arguments.

The first argument to the child (argv[0]) is the first string in the
environment after the ARGV variable.  This argument is the "pathname"
parameter passed by the parent to Pexec().  The remaining arguments are
those that the child would normally find in the command tail in its
basepage.  Even if all of the arguments would normally fit in a child's
command tail, the parent should set up the arguments in the environment
to take advantage of the benefits of this extended argument scheme.

As many arguments as will fit in the command tail will be passed there
as well as in the environment, to support non-conforming programs.  As
a flag that arguments are also in the environment, the length byte of
the command tail will be 127 (hex 7f).  Non-conforming programs should
not have a problem with this length byte, because it is longer than the
maximum 125 bytes allowed by Pexec().

As an aside, the Pexec Cookbook erroneously implies that a command line
can be 126 or 127 characters long.  In fact, GEMDOS only copies to the
child's basepage up to 125 bytes, or until it encounters a null, from
the argument string passed to Pexec().  It ignores the length byte,
placing a null at the same place it found one or at the 126th byte if
no null is found.  This has several implications: the length byte is
not validated by GEMDOS (necessitating validation in the child's
startup code, but also making this extended argument spec possible),
and the null terminator _can_ be located after the end of the real
command tail (the Desktop places a CR character after the command tail
and before the null).  The ARGSTART.S startup code listing below
demonstrates how to correctly validate and parse a GEMDOS command tail.

A child which finds an ARGV environment variable can use the command
tail length byte value of 127 to validate that the arguments following
the variable are valid, and not just left over from a non-conforming
parent which left its own ARGV arguments in the environment.

Because the strings in the environment following an ARGV variable are
not environment variables, a child should truncate its own environment
at the ARGV variable by changing the 'A' to a null.  

Implementation: Parental Responsibilities

To pass arguments in the environment, a parent must create an
environment string for the child.  This can be achieved by first
allocating as much space as is used in the parent's own environment,
plus enough room for the ARGV variable and the arguments to the child,
and then copying the parent's environment to the newly allocated area.
Next, the ARGV variable must be appended, since it must be the last
variable in the child's environment string.  Following the ARGV variable
is the null-terminated pathname of the child as passed to Pexec(), then
the null-terminated arguments to the child, followed by a final null
byte indicating the end of the environment.

After setting up the arguments in the environment, the parent must
place as many arguments as it can fit in the command tail it passes
to Pexec().  This way, a child which does not conform to this
specification can still get arguments from the command tail in its
basepage.  When placing arguments in the environment, the parent must
set the first (length) byte of the command tail to 127 (hex 7f),
validating the arguments in the environment.

Here is an example execv() library routine in C.  It uses three local
utility routines, e_strlen(), e_strcpy(), and str0cpy() for getting
environment size and copying strings into the environment created for
the child.


/* EXECV.C - example execv() library routine
 * ================================================================
 * 890910 kbad
 */

long Malloc( long nbytes );
long Pexec( short mode, char *filename, char *tail, char *env );
long Mfree( void *address );

/* Return the total length of the characters and null terminators in
 *   an array of strings.
 * `strings' is an array of pointers to strings, with a null pointer
 *   as the last element.
 */
static long
e_strlen( char *strings[] )
{
    char    *pstring;
    long    length = 0;

    while( *strings != 0 ) {        /* Until reaching null pointer, */
    pstring = *strings++;       /* get a string pointer,        */
    do {                /* find the length of this string,  */
        ++length;           /* using do-while to count the  */
    } while( *pstring++ != 0 ); /* null terminator.         */
    }
    return length;          /* Return total length of all strings */
}

/* Copy a string, including the null terminator, and return a pointer
 * to the end of the destination string.
 */
static char *
str0cpy( char *dest, char *source )
{
    do { /* use do-while to include null terminator */
    *dest++ = *source;
    } while( *source++ != 0 );
    return dest;
}

/* Copy an array of strings into an environment string, and return a pointer
 * to the end of the environment string.
 * `strings' is an array of pointers to strings with a null pointer
 *   as the last element.
 * `envstring' points to the environment string.
 */
static char *
e_strcpy( char *envstring, char *strings[] )
{
    while( *strings != 0 ) {
    envstring = str0cpy( envstring, *strings );
    ++strings;
    }
    return envstring;           /* Return end of environment string */
}


/* Run a program, passing it arguments according to the
 * GEMDOS Extended Argument Spec.
 *
 * `childname' is the relative path\filename of the child to execute.
 * `args' is an array of pointers to strings to be used as arguments
 *   to the child.  The last array element must be a null pointer.
 * `environ' is a global array of pointers to strings
 *   which make up the caller's environment.
 */
long
execv( char *childname, char *args[] )
{
    long    envsize, ret;
    char    *parg, *penvargs, *childenv, *pchildenv;
    short   lentail;
    char    argch, tail[128], *ptail;
static  char    argvar[] = "ARGV=";
extern  char    *environ[];

/*
 * Find out how much memory we'll need for the child's environment
 */
    envsize = e_strlen( environ );  /* length of environment    */
    envsize += e_strlen( args );    /* plus command tail args   */
/* plus length of argv[0] */
    parg = childname;
    do { /* use do-while to include null terminator */
    ++envsize;
    } while( *parg++ != 0 );
/* plus length of ARGV environment variable and final null */
    envsize += 7;
    envsize += envsize & 1; /* even # of bytes */
/*
 * Allocate and fill in the child's environment
 */
    ret = Malloc( envsize );
    if( ret < 0 )
    return ret; /* Malloc error */
    childenv = (char *)ret;
    pchildenv = e_strcpy( childenv, environ );   /* copy caller environment */
    pchildenv = str0cpy( pchildenv, argvar );    /* append ARGV variable */
    pchildenv = str0cpy( pchildenv, childname ); /* append argv[0] */
    penvargs = pchildenv;            /* save start of args */
    pchildenv = e_strcpy( pchildenv, args );     /* append args */
    *pchildenv = 0;              /* terminate environment */
/* put as much in the command tail as will fit */
    lentail = 0;
    ptail = &tail[1];
    while( (lentail < 126) && (penvargs < pchildenv) ) {
    argch = *penvargs++;
    if( argch == 0 ) {
        *ptail++ = ' ';
    } else {
        *ptail++ = argch;
    }
    }
/* terminate command tail and validate ARGV */
    *ptail = 0;
    tail[0] = 127;
/*
 * Execute child, returning the return code from Pexec()
 */
    ret = Pexec( 0, childname, tail, childenv );
    Mfree( childenv );
    return ret;
}
/* End of execv() example code */


Implementation: Prenatal Responsibilities

A program's startup code must handle getting extended arguments out of
the environment.  The startup code should get the basepage pointer off
the stack, then get the environment pointer from the basepage, and
search the environment for "ARGV=".  If "ARGV=" is found, the command
line length byte in the basepage is checked.  If the command line
length byte is 127, then the arguments in the environment are valid. 
The first argument begins after the first null following the "ARGV=". 
It is important not to assume that the null follows immediately after
the "ARGV=", because some implementations may assign a value to the
ARGV environment variable.  After setting up an array of pointers to the
arguments, the startup code should set the 'A' of the "ARGV" variable
to null, thus separating the environment from the argument strings
(remember: a double null terminates the environment).

Here is some example C startup code which shows how a child could
look for arguments in its environment:

* ARGSTART.S - example C startup code
* using GEMDOS Extended Argument Specification
* ================================================================
* 890910 kbad

.globl      _main       ; external, C entry point
.globl      _argv0      ; external, name used for argv[0] if no ARGV
.globl      _stksize    ; external, size of application stack
.globl      _basepage   ; allocated here, -> program's basepage
.globl      _environ    ; allocated here, -> envp[]
.globl      _argvecs    ; allocated here, -> argv[]
.globl      _stklimit   ; allocated here, -> lower limit of stack
.BSS
_basepage:  ds.l    1
_environ:   ds.l    1
_argvecs:   ds.l    1
_stklimit:  ds.l    1
.TEXT
_start:
    move.l  4(sp),a5    ; get basepage
    move.l  a5,_basepage    ; save it
    move.l  24(a5),a0   ; bss base
    add.l   28(a5),a0   ; plus bss size = envp[] base
    move.l  a0,_environ ; save start of envp[]
    move.l  a0,a1       ; start of env/arg vectors
    move.l  44(a5),a2   ; basepage environment pointer
    tst.b   (a2)        ; empty environment?
    beq.s   nargv       ; yes, no envp[]

    lea.l   (sp),a4     ; use dummy return pc on stack for ARGV test
* --- fill in the envp[] array
nxenv:  move.l  a2,(a1)+    ; envp[n]
    move.l  a2,a3
nxen1:  tst.b   (a2)+
    bne.s   nxen1       ; get the end of this variable
    tst.b   (a2)        ; end of env?
    beq.s   xenv
* --- check for ARGV
    move.b  (a3)+,-(a4) ; get 1st 4 bytes of this var
    move.b  (a3)+,-(a4)
    move.b  (a3)+,-(a4)
    move.b  (a3)+,-(a4)
    cmp.l   #'VGRA',(a4)+   ; is it ARGV?
    bne.s   nxenv
    cmp.b   #'=',(a3)   ; is it ARGV=?
    bne.s   nxenv
    clr.b   -4(a3)      ; ARGV marks the end of our environment
    cmp.b   #127,$80(a5)    ; command line validation?
    bne.s   nargv       ; nope... and we're done with the env.
* --- got an ARGV=, create argv[] array
    clr.l   (a1)+       ; terminate envp[]
    move.l  a1,_argvecs ; save base of argv[]
nxarg:  move.l  a2,(a1)+    ; argv[n]
nxar1:  tst.b   (a2)+
    bne.s   nxar1
    tst.b   (a2)
    bne.s   nxarg
* --- end of environment
xenv:   move.l  _argvecs,d0 ; if we got an argv[]
    bne.s   argok       ; don't parse command tail
* --- No ARGV, parse the command tail
* NOTE: This code parses the command tail IN PLACE.  This can cause problems
*       because the default DTA set up by GEMDOS for a program is located
*       in the command tail part of the basepage.  You should use Fsetdta()
*       to set up your own DTA before performing any operations which could
*       use the DTA if you want to preserve the arguments in the command tail.
nargv:  clr.l   (a1)+       ; terminate envp[]
    move.l  a1,_argvecs ; base of argv[]
    move.l  #_argv0,(a1)+   ; default name for argv[0]
    lea 128(a5),a2  ; command tail
    move.b  (a2)+,d2    ; length byte
    ext d2
    moveq   #125,d1     ; validate length
    cmp d1,d2
    bcs.s   valen
    move    d1,d2       ; if invalid length, copy all of tail
valen:  clr.b   0(a2,d2)    ; null tail because desktop inserts <cr>
    moveq   #' ',d1     ; space terminator
get1:   move.b  (a2)+,d2    ; null byte?
    beq.s   argok       ; if so, we're done
    cmp.b   d1,d2       ; strip leading spaces
    beq.s   get1
    subq    #1,a2       ; unstrip start char
    move.l  a2,(a1)+    ; and store that arg
get2:   move.b  (a2)+,d2    ; next char
    beq.s   argok       ; if null, we're done
    cmp.b   d1,d2       ; if not space...
    bne.s   get2        ; keep looking
    clr.b   -1(a2)      ; terminate argv[argc] in the command tail
    bra.s   get1        ; get next arg
argok:  clr.l   (a1)+       ; terminate argv[]
* --- allocate stack
    move.l  a1,_stklimit    ; end of env/arg vectors is stack limit
    add.l   _stksize,a1 ; allocate _stksize bytes of stack
    move.l  a1,sp       ; set initial stack pointer
* --- release unused memory
    sub.l   a5,a1       ; size to keep
    move.l  a1,-(sp)
    move.l  a5,-(sp)    ; base of block to shrink
    pea $4a0000     ; Mshrink fn code + junk word of 0
    trap    #1
    lea 12(sp),sp   ; pop args
*
* Everything beyond here depends on implementation.
* At this point, _environ points to envp[], _argvecs points to argv[],
* and _stklimit points to the end of the argv array.  Thus argc can
* be calculated as ((_stklimit-_argvecs)/4)-1.
* _main could be invoked as follows:
*
    move.l  a5,-(sp)    ; basepage
    move.l  _environ,-(sp)  ; envp[]
    move.l  _argvecs,-(sp)  ; argv[]
    move.l  _stklimit,d0    ; 4 bytes past end of argv[]
    sub.l   (sp),d0     ; (argc+1) * sizeof( char * )
    asr.l   #2,d0       ; argc+1
    subq    #1,d0       ; argc
    move    d0,-(sp)
    jsr _main       ; call mainline
    lea 14(sp),sp   ; pop args


A Final Note

This specification was formulated with careful deliberation, and with
input from several companies and developers who have created
development tools for GEMDOS.  The Mark Williams extended argument
passing scheme was the main influence for this specification, because
it has been in use, and supported by Mark Williams and other companies
for several years.  This specification is very similar to the Mark
Williams scheme, with the following important exceptions:

1) Under the specification, the arguments after the ARGV environment
variable may be validated by checking the command tail length byte. 
The Mark Williams execve() library function uses the command tail
length byte as a telltale, but it is not checked by the crts0 startup
code.  This validation is important for the reasons mentioned in the
Rationale section above.

2) The specification allows the ARGV environment variable to take on any
value.  Mark Williams uses the value of ARGV as an iovector, which is
described in the Mark Williams documentation.  The iovector should no
longer be needed, as its primary purpose was to simplify the MWC
implementation of the C library function isatty().

3) Some versions of the MWC startup code do not require the ARGV= to
have an `='.  Because ARGV is an actual environment variable in the
specification, the equals character is required.


---- END OF FILE ----

