



                        ATARI TECHNICAL POSTINGS

                                  1990




This volume is a collection of postings to Usenet by Atari's technical
staff from January '90 through to December '90. Postings from November
'88 through to October '89 are available in ATARI_89.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: 16 Jan 90 02:58:17 GMT
From: Ken Badertscher
Subject: dissassembly

V067MAJP@UBVMSC.CC.BUFFALO.EDU (Arion) writes:
| What I don't understand is why don't the excellent development team at Atari
| just go ahead and make the changes and break all the programs that don't follow
| the rules.

Believe me, Arion, it's very very tempting at times.  Especially when
you see some of the really silly things that some developers do to
break the rules.  You want to punish them.  But in fact, the end users
are punished worse if Atari breaks programs which break the rules.  All
a user knows is that his favorite program doesn't work any more.  If
the company that made it is no longer in business, that user is really
up the creek.

Fortunately, we are not constrained to strict compatibility with the
TTOS, so we may be able to fix some of the things we were previously
unable to fix.


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


Date: 16 Jan 90 03:22:43 GMT
From: Ken Badertscher
Subject: STE problem

[ wallace@oldtmr.dec.com (Ray Wallace) writes about solutions to the STE
desktop.inf bug: edit the file or send off for MEDRES.PRG ]

Once again, I have written a patch program which should be available
at the same place you bought your STE.  If it is not available, have
that dealer contact their Atari dealer support representative at
the appropriate subsidiary, and get a copy of STE_FIX.PRG.

Editing the file is not a viable solution, because that will mess up
the desktop.inf file for other STs.  The bug occurs when your STE
_reads_ the desktop.inf file.


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


Date: 19 Jan 90 23:46:05 GMT
From: Allan Pratt
Subject: POOLFIX3.ARC - fix program for TOS 1.4, TOS 1.6

This posting contains a uuencoded archive called POOLFIX3.ARC.  In it
there is a program, POOLFIX3.PRG.  If you have Rainbow TOS (TOS 1.4)
or STe TOS (TOS 1.6), please put this program in your AUTO folder.
It fixes a bug in those TOSes concerning GEMDOS's internal memory
management.

The bug is small and hard to come across.  You have to be fooling with
dozens of folders and lots of Malloc calls to get it to happen.  You
probably haven't seen it; with this program, you never will.

This is an Atari Official patch program.  It is intended for wide
distribution.  Feel free to give this to friends, upload it to BBSes
and other services, and make it available in user group libraries.

Yes, I know you already have fix programs in your AUTO folder. This one
is different.  Why don't we bundle them?  Because you might need some
and not the others, and because it's easier for us: I don't think you
really want to make this kind of thing hard for us to do, do you?

A broken version of this patch, called POOLFIX.PRG (not POOLFIX3.PRG),
was released on 10-Jan-90; if you got that one, throw it away and use
this one instead.  If you happened across POOLFIX2.PRG during the brief
time it was available, throw it away too.  I apologize for the
inconvenience.

If you don't need this patch, the program will tell you so.

Here is an excerpt from POOLFIX3.DOC, also included in the archive:

**********************************************************************

Atari Corp., January 19, 1990

There is a rare bug in Rainbow TOS (1.4) and STe TOS (1.6) involving
the way GEMDOS handles its internal memory.  You probably have never
seen this bug, and if you use this patch program, you never will.

Place POOLFIX3.PRG in your AUTO folder and reboot your machine.  That's
all there is to it.  POOLFIX3.PRG will run every time you boot your
machine, so the bug will never ever bite you.

You might get a message to the effect that it must run first in the
AUTO folder.  If this happens, copy the programs from your AUTO folder
to another place and erase them all from the AUTO folder.  Now copy
POOLFIX3.PRG into your AUTO folder, and then all the other programs
which were there.

(A version of this patch was released January 10; it didn't work, and
shouldn't be used.  Another was released January 18; it didn't work
either. (Look, I'm only human!)  This is Take 3.)

There are more technical details on this bug and the fix
in the file POOLFIX3.DOC, also in the archive.


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


Date: 19 Jan 90 23:52:48 GMT
From: Allan Pratt
Subject: Discussion of poolfix3 -- why 3?

I suppose you're wondering why POOLFIX3.PRG (posted under separate
cover) is number 3.

It's my fault.  It hasn't been my week.

I created the fix and posted it, but it was busted.  I fixed it, and
then busted it again.  After each go-around, I posted the "fix" to
Usenet, GEnie, and CompUServe.  Boy, when I want to make a fool of
myself, I don't do it in a small way.

But hey -- if Lexus can recall all their cars, and AT&T can go off the
air for nine hours, I can mess up once (or twice) in my life, right?  I
know what this must do to my credibility, and I really am sorry it
happened.  I hope that this will not discourage people from actually
USING poolfix now that it's available.  The trouble, in each case, was
in the installation part of the program, not the part which actually
fixes the bug.  The meat of the patch is robust (knock wood!).

So there you have it: my humble apology for the false alarms, and now
the fix itself.  Use it in good health.


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


Date: 19 Jan 90 18:37:06 GMT
From: Derek Mui
Subject: reserving memory

in article <11830071@hpldola.HP.COM>, jg@hpldola.HP.COM (Joe Gilray) says:
> 
> 
> I'm using MWC v3, when I malloc() all of the available memory my program
> recovers.  But now when it calls fsel_input() to allow the user to save
> his or her data an alert box is displayed which says something like
> "system does not have enough memory for directory".  How can I ensure
> that malloc() always leaves the system with "enough memory" to display
> the fsel_input() dialog box?
> 
> Also if there is such a technique, what is a good amount of memory
> to reserve?
> 
> Thank you for any help!
> 
> -Joe Gilray

	The fsel_input() needs a minimum of 3K of memory in order for 
it to come up. The more the files in the directories, the more the 
memory that it needs to allocate. 

	I don't exactly know what MWC v3 does with its malloc(). 


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


Date: 26 Jan 90 23:51:11 GMT
From: Ken Badertscher
Subject: appl_tplay() & appl_trecord()

There was an auto folder program distributed once upon a time which
fixed the specific bugs with appl_tplay() and appl_trecord().  It
was distributed with an ST demo program that went out to many dealers.
It is possible that the Atari customer support people in your country
have a copy of this program.  Check with customer support at your
subsidiary.

Better yet, get Rainbow TOS (1.4)!


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


Date: 25 Jan 90 16:40:56 GMT
From: Ken Badertscher
Subject: VDI commands recording

cs163wed@sdcc10.ucsd.edu ( ) writes:

| Hello.  I wonder if it is possible to add an overhead to the VDI
| such that calls to any VDI functions can be recorded automatically 
| somewhere in memory in some sutiable format.

What you are describing is a GEM metafile.  Using metafiles requires
GDOS and the meta.sys driver.  The metafile format is documented
in the VDI manual in appendix C; the Mark Williams C manual also
has a good description in the "metafile" entry.


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


Date: 30 Jan 90 00:31:02 GMT
From: Ken Badertscher
Subject: ARC 6.02 bugs

klute@heike.informatik.uni-dortmund.de (Rainer Klute) writes:

| Arc 6.02 is the first program I called from Arcgsh
| that supports xArg. (Zoo claims it supports xArg but it does
| not.)

 I believe Zoo supports ARGV, which is the officially supported
extended argument standard.  The README.ST file said it supports
"xARGV" (whatever that means) "as supported by CRAFT/GPshell,
gulam, msh..."  Gulam and msh definitely support ARGV.
You should too!

| (Still missing: Sources for Arc 6.02 to get it to work on the
| UNIX machines.)

 Judging from what I know about the Arc 6.02 port, it wouldn't
help much to have the sources.  The individual who ported it
is a speed freak, and probably hacked up a lot of it in assembler.
If not, I congratulate him for learning the beauty of portability :)


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


Date: 29 Jan 90 19:16:46 GMT
From: Allan Pratt
Subject: TOS io redirection bugs

dal@syntel.mn.org (Dale Schumacher) writes:
>There IS good news, however.  By exploiting a "feature" of the Pexec()
>mechanism relating to the h-blank vector, we seem to have a robust
>work-around for most of the redirection problems.  

>I'd be willing to post the technique to the net, but I would like to get
>confirmation from Allan or Ken that the "Pexec/H-blank trick" will continue
>to work in future TOS versions.

I can't dictate what techniques you use, and I can't repudiate existing
documentation: we've guaranteed that Pexec will always start the new
process at IPL 0, and therefore you are likely to get an Hblank
interrupt between the RTE from GEMDOS and the first instruction of the
new program.

How you use this is up to you, but I warn you: the lure of the Dark
Side is powerful, and once you start down that dark path the forces of
Evil will claim your soul.

Yes, Fdup / Fforce will gag when you get too deep, but Hblank is not
the answer.  If you want to link programs with temporary files, great!
Add command-line options to each program in the chain which say, "Use
this file for input, that one for output."  I had hoped that J.Bammi
could win you over to this point of view.


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


Date: 30 Jan 90 18:11:17 GMT
From: Ken Badertscher
Subject: Words of wisdom on MWC behaviour needed

steve@thelake.mn.org (Steve Yelvington) writes:

| Mark Williams uses a strange method of passing extended arguments that
| encodes redirection in environment variables.

While it is true that the Mark Williams method of encoding redirection
is part of their extended argument scheme, the problem here is not
with the extended argument scheme but rather with their "unusual"
implementation of isatty() and associated funcitons.

The ARGV extended argument specification, a refined version of the MWC
extended argument method, has been documented and is supported by
Atari.  Please use it.  The correct way to do isatty() is also
documented and supported by Atari.  Please use it.

Regarding the Fforce() fix recently mentioned by Dale...
| I'm not going to even try to describe how it works, but since kbad has
| more or less publicly blessed it, perhaps Dale or John will post some
| code.

*cough*  Um, no.  I did not publicly bless the Hblank file redirection 
hack.  I haven't even seen it.  All I said is that processes are
guaranteed to start at IPL 0.  What you do with that information is
your business - but BE CAREFUL.  When you play with fire, or
assumptions about GEMDOS, it's easy to get burned.


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


Date: 31 Jan 90 20:07:25 GMT
From: Ken Badertscher
Subject: ST Format, TOS 1.4 moans directed at Atari UK (was: HAPPY NEW YEAR, ALL!)

grahamt@syma.sussex.ac.uk (Graham Thomas) writes:

| ps. UK mags have been saying that disks formatted with the STE and TOS
| 1.6 are not readable by IBM PCs.  Any comments?

Sounds suspiciously like a case of bad floppy or old DOS.  The desktop
formatting code did not change AT ALL between Rainbow and STE TOS.

Compatibility problems can arise with old MS-DOS versions which use a
magical "media descriptor byte" rather than the proper parameter block
information from the boot sector of a floppy.  The "media descriptor
byte" is not supported by GEMDOS, nor is it supported by Microsoft any
more.  Incompatibilities also exist among certain PC drives - not only
with ST formatted disks, but with PC formatted disks as well.

Am I being paranoid, or has there really been a proclivity on the part
of the press (UK and elsewhere) to slam the STE???  I've heard more
negative rumours and outright lies about the STE than any other recent
Atari development.  I wonder why this is?


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


Date: 1 Feb 90 17:16:55 GMT
From: Ken Badertscher
Subject: Tick-tick-tick-CRASH! is not dead in TOS 1.4

grahamt@syma.sussex.ac.uk (Graham Thomas) writes:

| GST say it's something inside TOS (or GEMDOS or whatever layer
| it might be), so I was rather hoping the problem might go away with TOS
| 1.4. 

Now why doesn't that surprise me?  Not to bash GST, but I have found
that a lot of problems similar to this are a result of bad programming
practices.  Not intentional, but just because the developer wasn't
aware of some restriction or another.  It's all too easy to blame TOS.

I would like to know exactly how the GST products get their keyboard
input, in gory detail.  *IF* I knew that, then I might be able to
figure out what causes the problem.  I strongly suspect that the
problem is caused by  mixing input modes between AES/VDI/GEMDOS/BIOS. 
That has been known to produce results like this.  If it is _not_ that,
then there is a good chance that it _is_ a bug in TOS, and I want to
fix it!!!

| People can go for months without it striking, and then have it
| happen twice in a day.  (Sunspots??? :-) )

Yep, sounds a lot like the ol' cosmic rays.  It is really unfortunate that
this particular bug is not easily reproducible.  Of course, if it were,
it would probably have been fixed long ago... :-/

| I'm waiting for the bug to strike while I'm running Wordplus from within
| NeoDesk, so I can try sending a few wind_update() calls.  Would this do
| any good?

While you're at it, don't forget to sprinkle the chicken's blood on the
keyboard and dance about, chanting at the monitor.


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


Date: 1 Feb 90 17:27:01 GMT
From: Ken Badertscher
Subject: Want pseudo-trap handler examples

saj@chinet.chi.il.us (Stephen Jacobs) asks about critical error and
terminate handlers.

Intercepting the critical error handler is simply a matter of grabbing
logical vector 0x101 using Setexc(), and doing the appropriate thing
with the arguments sent to your error handler by the bios.  This is
documented in the GEMDOS manual in the "extended vectors" section.

Grabbing the terminate vector to "recover" from a ^C is not the way
to avoid having ^C terminate your application.  Use GEMDOS raw
i/o (Crawcin() and/or Crawio()) and roll your own string reading routine.


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


Date: 1 Feb 90 22:16:24 GMT
From: Allan Pratt
Subject: (repost) POOLFIX3.ARC (really fast-load bit)

bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes:
>in the recently posted poolfix3.prg and the older rainbow patch, i
>noticed that the 'dont clear bss' bit is not set in the header. is
>there a reason for this?? any consequences if we set this ourselves.

It's not a "don't clear BSS" bit -- it's a "don't clear HEAP" bit! The
BSS is the uninitialized storage your program declares that it will
need: the C language guarantees that this will be zero, and the ST
compiles by zeroing it when you're loaded.  The REST of the memory you
get allocated, above and beyond your declared BSS, is the heap. For
reasons I do not know, GEMDOS originally cleared all of that, too.
That's real slow on a 68000 with 4MB of memory, so I added that bit to
tell Pexec "You don't have to clear my heap."  Programs with that bit
set load faster.  Not all programs can stand it: MS Write, for one,
expects all that space to be clear.

>apratt: how about sending out a binary diffs (a convenient way is to
>hexdump, and send out context diffs of the hexdumps) from the t1.4
>image, that fixes these problem, so that those of us with eproms can
>fix them. (i really hate auto\patches).

There is zero chance of this.  Atari's policy is, "The only TOS we have
to support is the one in Atari masked ROMs."  If you have EPROMS, you
don't have an Atari-supported OS.  This way Atari gets out from under
the burden of supporting whatever code happens to be in your EPROMs,
with whatever "patches" and "fixes" and "improvements" you or somebody
else put there.

Before you jump all over me, of course, I'm being pedantic.  I know
that real TOSes can be in EPROMs.


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


Date: 5 Feb 90 19:17:11 GMT
From: Allan Pratt
Subject: 16 meg partition limit

brazil@pawl.rpi.edu (Timothy E. Onders) writes:
>In article <20465@watdragon.waterloo.edu> swklassen@tiger.waterloo.edu (Steven W. Klassen) writes:
>>mentioned the 16 meg limit, however, the utilities which came 
>>with it allowed me to make larger partitions.

>Those would be HDX 3.0. HDX 3.0 allows partitions up to 1 GBy (that's
>1024 MB in case you didn't know.), It also allows more partitions per
>physical drive.

Right. Actually it's 3.01; the driver that came with 3.0 had a bug,
though the formatter (HDX) is the same.

>>unreliable for long term use?

Certainly not.

>The only problem, however, is that many disk utility programs ...
>don't know how to handle the larger partitions.

Also right.  Here's the bottom line: when you have a partition larger
than 16MB, the driver creates the partition with 1KB sectors (or more!)
rather than 512-byte sectors, which is the old value.  Cluster size is
still two sectors, whatever size that is.  The disk itself is formatted
with 512-byte sectors, and Rwabs does blocking and deblocking, turning
requests for "one logical sector" into as many physical sectors as
necessary.

The reason for the large-sector implementation is that all GEMDOSes can
handle any (power-of-two) sector size, but not all can handle a cluster
size other than two.

The drawback is that some (most) utilities assume that one sector is
always 512 bytes.  They could have used the Getbpb() call and used the
sector size returned from that, but the original TOS documentation all
but guaranteed 512 bytes forever.  These programs will crash, or worse,
will fail quietly because they read "one sector" into a buffer which is
only 512 bytes long; the Rwabs transfers 1K, clobbering whatever came
after the buffer in memory.  Also, their notion of how big a sector is
(e.g. number of directory entry slots in a directory sector) will be
wrong.

As an additional complication, if you use the "raw mode" (also called
"physical device") bit in the first arg to Rwabs, you get physical
sectors, which are still 512 bytes.  That number is not obtainable as a
variable anywhere, so it'll probably stay at 512.

The hardest-hit class of programs is the "add cache sectors" or  other
disk-caching kind, because it  needs to know how big a buffer to
allocate.  The answer to that question is impossible to compute, so
it's available from the hard-disk driver.  (It's impossible to compute
because it involves a user-preference value which can be patched into
the driver: with removable media you could pop the cartridge and put in
one with larger logical sectors, so the user tells the driver a
minimum for the "maximum sector-size" value to use.)

CACHExxx.PRG from Atari, of course, interrogates the driver and uses
that number correctly.

I'm not publishing the way to interrogate the driver here because I
would not get it right.  The straight scoop is avaiable to developers
in the HDX 3.0 Release Notes document.

The moral is, utilities should always use Getbpb to find out how big
sectors are, how many sectors per cluster, etc., and base all your
other calculations and "constants" on the answers.  If you're adding
GEMDOS buffers or other permanent objects, get the release notes and do
it right.


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


Date: 13 Feb 90 23:39:46 GMT
From: Allan Pratt
Subject: 16 meg partition limit

brazil@pawl.rpi.edu (Timothy E. Onders) writes:

>In article <1990Feb6.223637.15845@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes:
>>
>>What Atari has changed, I believe, is to treat the "recno" parameter
>>as an UNSIGNED int, with a range of 0 to 65535, and consequently a
>>32Mb limit.

Wrong.

>Actually, the logical sector size was also increased [...]

Right.  The logical sector size is now "large enough so the partition
can be represented by 32767 sectors," which is to say 512 bytes
for <16MB, 1024 bytes for <32MB, etc. all the way up to 8K/sector
or more.

This means BIG TROUBLE for any program which does Rwabs() calls and
expects to get 512 bytes per sector: you should use Getbpb() to FIND
OUT how big sectors are, rather than assuming any one value.  It's also
BIG TROUBLE for programs which add buffers to GEMDOS via the "bufl"
system variables: it's hard (not impossible) to tell how large each
buffer must be.  Get the AHDI 3.00 Release Notes from Atari (available
to developers) for the grubby details.

>>the old Dfree()/FAT search bug rears up

There is no such bug; I think you mean "really horribly slow implementation."

>>and file creation takes nearly forever.

That part is true.  So take your own advice and get TOS 1.4!


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


Date: 14 Feb 90 09:53:03 GMT
From: Atari-ST Software
Subject: disk caches  for 1040ST

In article <BAMMI.90Feb12234717@dsrgsun.ces.CWRU.Edu> bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes:

>In article <3561@tahoe.unr.edu> mikew@wheeler (Mike Whitbeck) writes:
>> I also tried dcache (Dijkstra). I believe it only caches read
>> buffers and not write. I would like to cache both read/write
>> operations (floppy and hard disks) and have control over
>> flushing the buffers (e.g. a 'sync' command).

>	Dcache does all of the above. (sync via 'dcache =f' if i remember
>correctly, or via the supplied ACC). It can optionally *not* write
>through.

Correct.

However if you want to use dcache on a floppy
you have to be careful (the manual also warns for this):
- Don't change floppies without 'invalidating' and syncing the cache
  for a floppy.
- Formatting a floppy from the desktop with a cache for the
  floppydrive turned on fails.


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


Date: 14 Feb 90 02:01:28 GMT
From: Allan Pratt
Subject: STE and multisyncs

01659@AECLCR.BITNET (Greg Csullog) writes:

>I ask ONCE AGAIN. If the STE supports large screen monitors, like the
>MONITERMs, can I get the full rez (1024x768) on an OMNIMON Rainbow
>multisync. If so, HOW!!!!!

Taking this tone does not help you get an answer.  This is the first
time I have seen this question come up, and I'm answering you in spite
of your tone mainly as an excuse to ask people to be more considerate
in the future.

No, the STe can not drive a Moniterm or similar monitor directly. The
video signal for that kind of monitor is totally different from the
normal ST/STe video, and requires extra hardware.  There is an add-in
board available for the Mega which has this hardware.  Since the STe is
in a 1040 case, without the room or stakes for this kind of  board,
it's not available for STe.  We do have plans for a future STe with
enough expansion capability to make this possible, but the details 
are not public yet (and I don't know them).

The TT does support Moniterm-style monitors directly.  It has that
extra hardware built in, in addition to other new video modes, plus the
three ST video modes for compatibility.  All the modes except the
1024x768 Moniterm-style mode are usable with the same type of monitor.
That monitor is *like* VGA, but the timing is a little different, so an
off-the-shelf VGA monitor will look funny (i.e. picture too small and
not centered, or something like that).  If you buy the monitor from us,
it will work (of course).  If you buy a multisync monitor, it will come
with enough adjustments that you can make it look good.  Your ST
monitors will not work with a TT.

>Can someone from Atari also post the specs on the SIMMs the STE and STACY
>are supposed to use?

I don't know them.  The SIMMs are there mainly for the cost and space
savings on the PC board, not so you can add memory to your machine.  

In some machines the memory is not even socketed: it's SIPs, not SIMMs.
If the cost of SIPs is lower than SIMMs plus sockets at the time we
buy, we use SIPs.


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


Date: 20 Feb 90 23:40:00 GMT
From: Allan Pratt
Subject: poolfix3

Ritzert@DMZRZU71.BITNET writes:

>[We have a program which dies; poolfix3 improves it a little.]
>Question to Allan or Ken:
>      Shall I install folder100 in addition [to poolfix3]?

You should certainly use foldr100.  Poolfix3 only fixes a bug in
the code which manages GEMDOS's internal memory.  You can still
run OUT of memory there, and FOLDR100.PRG adds more.  A program
which uses Malloc() a lot, or has lots of open files at the same
time, can use up all this memory.

If you see the "panic" message, it's USUALLY because you ran
out of pool memory.  Using poolfix3 will not change this.
Using FOLDR100 will.

Poolfix3 should print a message when it runs; that message either says
it was INSTALLED or says there was some error.  The most common error
is that it can't find GEMDOS: if some program has run earlier in the
AUTO folder and swiped the GEMDOS trap, that'll do it.  (Other messages
include detecting that your GEMDOS doesn't need poolfix at all, and
that your GEMDOS *does* need poolfix, but it can't be installed for
some reason.  That one should "never happen.")


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


Date: 24 Feb 90 02:10:49 GMT
From: Allan Pratt
Subject: poolfix3

jimh@ultra.com (Jim Hurley) writes:
>Actually, although I've heard a lot about this bug, I've never
>read a consistent description of the problem.

The TOS 1.4 release notes describe the problem completely and in loving
detail.  As a rule, YOU DON'T NEED TO KNOW, which is why I don't spend
my days posting long explanations here.

What you DO need to know is this:

	1. If you have Mega TOS or Original TOS (1.2 or 1.0) and a hard
disk, you should use FOLDR100.PRG.  Without it, the system starts
screwing up when you've visited (or even just brushed by) 40 folders or
so.

	2. If you have Rainbow TOS or STe TOS (1.4 or 1.6),
		YOU DEFINITELY NEED POOLFIX3.PRG!

	(2a. STe TOS is just like Rainbow TOS in almost every respect;
it isn't an "enhancement" and you shouldn't wait for it to come out for
the ST.  It's just Rainbow TOS with modifications to make it run the STe.)

	3. If you have Rainbow TOS or STe TOS you MIGHT want to use
FOLDR100.PRG.  The management of the internal memory (which
FOLDR100.PRG adds to) is greatly improved, but you can still run out. 
It's no longer a question of how many folders you've "seen" but rather
of how many  folders and files are ACTIVE, which is to say, in use at
any one time.  Most people don't open a file 40 directories down in
their heirarchy, or two folders each 20 (different) levels down, or
whatever.

	4. If the system ever locks up and tells you to use
FOLDR100.PRG, then you probably should.

In short, POOLFIX3 actually fixes a bug which every Rainbow TOS user is
exposed to; FOLDR100.PRG adds memory to an internal pool.  That internal
pool is really badly managed in pre-Rainbow TOSes, and much much better
managed in Rainbow TOS (after you fix the bug by running POOLFIX3),
but in both cases you benefit by using FOLDR100.


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


Date: 2 Apr 90 20:34:06 GMT
From: Allan Pratt
Subject: Flight Simulator bombs - solution

in article <900401.00441835.016202@SFA.CP6>, Z4648252@SFAUSTIN.BITNET (Z4648252) says:
>     The bomb definitions can be found in most language manuals.  The 
> following comes from GFA Basic 2.0's manual:
> 
> 2 bombs  - BUS ERROR
> 3 bombs  - ADDRESS ERROR
> 4 bombs  - ILLEGAL INSTRUCTION
> 5 bombs  - DIVISION BY ZERO
> 6 bombs  - CHK EXCEPTION
> 7 bombs  - TRAPV EXCEPTION
> 8 bombs  - PRIVILEGE VIOLATION
> 9 bombs  - TRACE EXCEPTION

The number of bombs is the 68000 exception number which happened... 10
bombs is the Line-A exception.  Line-A is used as a back-door to VDI,
but unrecognized line-F opcodes are passed through to the bomb handler.

 10 bombs - Line-A ($Axxx)
 11 bombs - Line-F ($Fxxx) (used by AES/VDI, unrecognized ones go boom)

There aren't any others you're likely to get... All the 68000 exception
vectors are pointed at the bomb handler at boot time; the ones actually
used by the system are re-pointed at the appropriate handler later.


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


Date: 2 Apr 90 20:17:38 GMT
From: Allan Pratt
Subject: Questions about the STE (compatibility)

in article <3068@castle.ed.ac.uk>, eric@castle.ed.ac.uk (E S Fraga) says:
> 	gulam
> 	gcc
> 	GNU emacs
> 	Sozobon C
> 	TeX (any version)
> 	Minix
> and	Uniterm.
> 

All of these programs should be utterly compatible.  They might not be,
but the only reason would be really dumb mistakes by the authors.

I've used Gulam on STe and it's no problem, except for the "mem"
command -- the authors tried to get clever and used secret addresses.

We ran the software library we had here on the STe, and the only
incompatiblities we found were with programs which made illegal
assuptions, like the locations of unpublished variables and the base
address of the ROM.  These were mostly games; the kind of program you
mention had no trouble whatsoever.  That's not surprising: the STe is a
superset of the ST, not a subset or a rearrangement of anything.


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


Date: 10 Apr 90 20:27:20 GMT
From: Allan Pratt
Subject: Bus errors (was re: _memlow / _memtop / phystop)

achowe@tiger.waterloo.edu (anthony howe) writes:
>Is a bus error generated if a memory reference is made to memory
>outside the range specified in system variables [_memlow, _memtop] or 
>on the range [0, phystop]?

You shouldn't rely on getting a bus error (or not getting one) anywhere.
People can muck with the variables you mention, so you really can't
count on them.

This is a good time to publish my universal bus-error code fragment. It
works on any CPU and it doesn't even have to check what CPU it's on. Of
course, it must run in Supervisor mode, because it fools with the bus
error vector.  The key to the code is that it cleans off the bus error
exception from the stack regardless of how much the CPU put there.  It
does this by saving the original SSP and restoring it later, rather
than adding a constant number of bytes to SSP. (If you DON'T get a bus
error, the final "move a1,sp" is a no-op.)

begin:
	move.l	$8,a0
	move.l	sp,a1
	move.l	#berr,$8

* Do something that might cause bus error
	move.l	testaddr,d0

* If you get to the next instruction, you DIDN'T get a bus error.
* Handle that case here (zero a flag), then branch to berrdone.

	sf	berrflag
	bra	berrdone

* If you get to this label, you DID get a bus error.  Handle that
* case (set a flag), then fall through to berrdone.

berr:	st	berrflag

berrdone:
	move.l	a0,$8
	move.l	a1,sp


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


Date: 16 Apr 90 19:32:10 GMT
From: Allan Pratt
Subject: Severe Dcreate() bug in GEMDOS 0.23

alderaan@tubopal.UUCP (Thomas Cervera) writes:
>there seems to be a severe bug in GEMDOS 0.23's Dcreate() Call (TOS 1.{4,6}).
>If you have a file with a given name somewhere on your disk and you create a
>directory with the same name at the same path location, this Dcreate call
>completes SUCCESSFUL!

I can't make this happen.

	#include <osbind.h>
	main()
	{
		int fd;
		long err;

		fd = Fcreate("silly",0);
		Fclose(fd);
		err = Dcreate("silly");
		printf("err is %ld\n",err);
		exit(0);
	}

prints "err is -36" (EACCDN, access denied).  I'm using TOS 1.4's GEMDOS.


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


Date: 17 Apr 90 23:48:39 GMT
From: Allan Pratt
Subject: TOS 1.4 info

jfbruno@rodan.acs.syr.edu (John F. Bruno) writes:
>Don't tell me they screwed up again!!! What if I have a volume with
>10K free and I want to move a 20K file into a folder?!?! 

Moves (via the Gemdos call Frename) are in fact accomplished by
changing directory entries, not by copying files, when the source &
dest are on the same logical drive.

By the way, I *live* for this kind of posting.  Polite, considerate...
just the sort of posting that is sure to result in a speedy,
informative reply. Yup, this is the kind of news that makes me want to
get to work early every day.


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


Date: 18 Apr 90 17:30:41 GMT
From: Allan Pratt
Subject: Severe Dcreate() bug in GEMDOS 0.23

alderaan@tubopal.UUCP (Thomas Cervera) writes:

>apratt@atari.UUCP (Allan Pratt) writes:
>>	#include <osbind.h>
>>	main()
>>	{
>>		int fd;
>>		long err;
>>
>>		fd = Fcreate("silly",0);
>>		Fclose(fd);
>>		err = Dcreate("silly");
>>		printf("err is %ld\n",err);
>>		exit(0);
>>	}
>>prints "err is -36" (EACCDN, access denied).  I'm using TOS 1.4's GEMDOS.

>  Uhm. Maybe your C library does the Fsfirst ?

Uhm.  The capitalized "function calls" are actually direct OS calls,
with no library intervention.  What you see is what GEMDOS saw, with no
interference from anything.

What do you take me for?


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


Date: 18 Apr 90 17:37:03 GMT
From: Allan Pratt
Subject: TOS 1.4 info

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

>I think Atari did it correctly.
>For moves between logical disks, copy && remove is required.
>For the degenerate case of rename, there is still the problem of a failure
>during the operation with the file being lost.  So copy && remove is
>still the safest course.

No, for the degenerate case the Desktop uses the Frename function,
which diddles the directory entries, rather than doing a copy+delete.

As of TOS 1.4, the Frename function is safer than before: there is no
reasonable failure which will lose your original.  The new directory
entry is created before the old one is removed.  This wasn't the case
before.  (Of course, extending a directory involves writing the FAT,
and that can go wrong and clobber your file.  Or you could be renaming
within one directory, and a write error there could clobber your file.
But I said reasonable failures.)

O ye of little faith.  Then again, any of ye who have faith in GEMDOS's
robustness or fault-tolerance are living in a fool's paradise.


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


Date: 20 Apr 90 00:21:32 GMT
From: Allan Pratt
Subject: 6-chip/2-chip TOS 1.4

bills@mcrware.UUCP (Bill Sheppard) writes:
>I recently purchased the six-chip set of TOS 1.4, but need to install this
>in a two-chip machine. I have access to a ROM-burner ...
>...(and what EPROM device is the two-chip set made from)?

There exists no EPROM with the right pinout for 2-chip Megas.  There
may not be any such OTP, either.  That was a problem when we were
building developer releases, etc.  You just can't do it.

If you have six sockets, you're 90% there.  Find the instructions for
cutting & jumping to make your 2-chip Mega a 6-chip Mega. 
Alternatively, you can buy the 2-chip TOS 1.4 set.  It's available, and
has been for many months.


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


Date: 23 Apr 90 19:33:59 GMT
From: Allan Pratt
Subject: Severe Dcreate() bug in GEMDOS 0.23

ski2@milton.acs.washington.edu (Chris Kacoroski) writes:
>In article <1401@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) 
>writes:
>>My RAM TOS 1.0 (GEMDOS V0.21) also clobbers files with Dcreate () !
>>Also the ROM TOS 1.0 in all machines at FU Berlin's physics department.
>I tried the posted program on a 1040st with TOS 1.0 in ROM and it did
>clobber files with the same name as the directory I was trying to
>create while returning successfully.

What is your (collective) point?  I didn't say this didn't happen in
original TOS (1.0), just that it's not in GEMDOS 0.23!  And it's not.

This is even documented: Rainbow TOS Release Notes, August 7, 1989,
page 37:

	"Attempting to Dcreate a directory with the name of an
	existing file will return EACCDN.  Previously, it would
	delete the file, then create the directory."

What threw me was the original subject line, saying this bug was in
GEMDOS 0.23 (Which is Rainbow TOS's GEMDOS).  It's not there, and it's
documented as a change, and the previous, undesired behavior is also
documented.

If your subsidiary doesn't make the Rainbow TOS Release Notes document
available with TOS 1.4, you should take it up with them.  It's part of
the developer's package in the USA.


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


Date: 28 Apr 90 00:21:20 GMT
From: Allan Pratt
Subject: STE TOS / TOS 1.4/1.6 etc.

rjd@cs.brown.edu (Rob Demillo) writes:

> In article <2178@atari.UUCP| apratt@atari.UUCP (Allan Pratt) writes:

>> I don't think it's wise to publish what you learned from the ROMs.
>> [I go on to show "the inherent weakness of this kind of analysis."]

> This is ridiculous. There may be inherent *legalities* about 
> publishing a dismantled ROM, but there is no "inherent weakness"
> in this kind of analysis. It is merely very difficult.

I think you are wrong. You can learn only so much from the ROM. You can
learn what the ROM code does, and how it does it.  But you can't learn
things that the ROM code DOESN'T do.  You won't learn the right way to
interact with the DMA Sound chip (the ROM doesn't use it). You won't
learn about ARGV or the functional limits of the cookie jar (that
accessories can't use it).

You *will* learn things which just happen to be true, but which aren't
guaranteed.  You will learn that calling the BIOS with an invalid
function number returns different things depending on the number.  You
will learn the addresses and uses of variables and data structures. 
It's not a secret, it's just that we need to be free to change those
things in the future.  If your program relies on something stupid and
becomes popular, we could get stuck with a feature we don't like, a
feature YOU don't like and didn't realize was outside the "rules" for
well-behaved programs.

THAT'S why it's dangerous to disassemble the ROMs and take lessons
from what you find.

[Flame on]

This kind of analysis is not that hard, folks.  Please think a little
before posting stuff.  I'm not stupid.  When I say something, I usually
have reasoned it out a little.  If you think about starting a posting
by calling my arguments ridiculous, maybe it's because YOU haven't
thought through the implications of what was said or my response.

[Flame off]


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


From: Ken Badertscher
Subject: Re: Malloc() and desk accessories
Date: 28 Aug 90 19:28:55 GMT

As long as you don't go back into an event wait, you can Malloc all day
long (Mfreeing what you Malloc when you're done with it, of course).

The only time DA's have Malloc headaches if they try to Malloc memory
outside their startup sequence is if they give the parent application a
chance to terminate out from under them.  The problem arises when an
application calls appl_exit().  The AES does not give DA's enough time
to clean up after themselves before the parent application's resources
are released.  It is possible for a DA to not get an AC_CLOSE message
until you're already back at the desktop.

Note that this also causes problems with DA's that open virtual
workstations, since the VDI Mallocs memory for workstation information. 

A sequence of events like the following could cause problems:

  Run an application.
  Open a DA that opens a workstation or Mallocs some memory.
  Quit the application without closing the DA.

At this point, the application calls appl_exit(), which returns before
giving all DA's a chance to clean up.  The application then terminates,
and GEMDOS frees all the memory that was allocated while the program 
was running.  Eventually, the AES will get around to telling the DA,
"Oh, by the way, shut yourself down now."  If the DA then tries to
access any of the memory it had Malloced, it would be messing with
memory that had already been freed.  If this memory had since been
reallocated, the DA would be changing someone else's memory.  If it
happened that the memory had been reallocated to someone else _at the
same starting address_, it would be disastrous for the DA to Mfree that
block.

The solution is simple.  DA's must only Malloc memory in an atomic
(from the AES's point of view) operation, as Steve outlined.  If a DA has
more dynamic memory needs, it can allocate a heap for itself at
startup, BEFORE IT MAKES ANY AES CALLS.  The DA can then use it's own
memory management within this heap.


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


From: Ken Badertscher
Subject: Re: Malloc() and desk accessories
Date: 2 Sep 90 23:27:35 GMT

gt1448b@prism.gatech.EDU (David P. Forrai) asks:

| What is the correct way to call v_opnvwk()?  Should it be done before
| the event loop and v_clsvwk() never called?

The best way for desk accessories to handle opening virtual workstations
is for them to use them in the same way they would use any other dynamically
allocated resources.  Open the workstation, do VDI calls, close the
workstation.  It isn't a good idea to suck up a virtual workstation slot
which may never be used.

You're right, if that's what ACSKEL does, the behaviour in ACSKEL is
incorrect.

The effects of dynamic DA Malloc() and v_opnvwk() calls only recently
became apparent, when the GEMDOS internal memory management was
improved for TT TOS.  A side effect of the change he made was that the
likelihood of a freed block getting reallocated soon after being freed
became much greater.  In previous TOS versions, it takes longer for
freed blocks to be reallocated.  Because of this, you are less likely
to see problems arise when DA's don't get a chance to clean up after
themselves.  It is still and always will be A Bad Idea to mess with
memory you don't own, and that's effectively what DA's do if they
dynamically Malloc memory (either directly or indirectly).

To end on a happy note--the problem of DA's not getting a chance to
free up their resources before having them yanked out from under them
is FIXED in the AES version 3.0.  The AES now actually waits until all
desk accessories are back in an event wait before allowing an appl_exit
caller to terminate.  The new Control Panel (XCONTROL) takes advantage
of this fact, and dynamically allocates memory to load Control Panel
Extensions if it sees that it's on a TT.  This should also be a great
boon to desk accessory text editors and the like.


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


Date: 19 Sep 90 00:21:46 GMT
From: Allan Pratt
Subject: TT RAM

csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes:

>Is the TT's memory mapped by the MMU so that it appears
>contiguous?

No.  There is no address translation going on in the MMU.  If there
were, every program that wrote an address into a chip (video, DMA,
etc.) would have to be able to do the logical-to-physical translation.
This is impractical, and would result in nearly 100% incompatibility
with existing programs.  The MMU is used, however, so don't mess with
it.  It's used to get around a bug in the 68030's design; I may explain
in more detail later.

>I need this info for my hard disk driver which has to
>decide if some transfer is to be made into fast or slow RAM.

Right you are.  That's what the _FRB cookie is for.  But you are
looking at the problem in the wrong terms: rather than deciding what
kind of RAM the transfer is destined for, your program should decide
only what it has to: in this case, decide if it's being made to/from a
place that the ACSI DMA chip can access.  This prevents you from
hard-coding the location or size of different pieces of RAM.  This
saves you from having to re-release your driver  when somebody
complained that he couldn't access VME RAM with it, because you didn't
think of that.

The ACSI DMA chip can access memory only in the low 24 bits of the
address space, so that's your answer: you check the high byte of the
transfer address. If it's zero, you can use ACSI directly.  If it's
not, you must use the FRB.  You never examine any part of the address
other than the high byte, and you only test that against zero. 
Minimizing the information you require in this way leads to maximum
portability and future compatibility.

As an aside to SCSI driver writers, you have less to worry about. As
mentioned above, the definition of accessibility on the ACSI bus is
"the high byte must be zero."  The definition of accessibility on the
SCSI bus is "the bus must be 32 bits wide."  This means that A24/D16
VME memory is not accessible to SCSI, and you should use the buffer
pointed to by the _FRB cookie.

Finally, to defeat nit-pickers before they strike, I *know* that the
ACSI DMA chip can't really talk to everything in the 24-bit ST address
space: it can't see ROM, for example.  But it *can* access any real RAM
in that space, and if you're trying to DMA to something else (like the
palette) you deserve what you get.


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


Date: 19 Sep 90 18:52:43 GMT
From: Allan Pratt
Subject: 68030 cache, write-allocate, and everything.

Okay, for you chipheads out there, here's the scoop:

The 68030 design bug I mentioned is in the cache logic.  I/O space must
be non-cacheable, so there's an INPUT to the 68030 called "CIIN" for
Cache Inhibit INput.  That line is checked on all reads, but it is NOT
checked on writes.

There is a bit in the cache control register called "write allocate:"
when set, some writes to memory create an entry in the cache.

If you write to I/O space with the "write allocate" bit on, the write
can cause a cache entry to be created, even though the memory in
question is non-cacheable.  A subsequent read from the same address
hits the cache before the CIIN is checked, so you get stale data.

This only happens when you do a longword write at a longword boundary
in I/O space, then read back any part of that longword before the cache
line is re-used.  You will read what you wrote, instead of reading what
the device puts in its register.  If it's a read/write register that
the device doesn't change, you won't notice, but if it's the kind of
register that means one thing when written and another when read, or if
the device changes the value in the register, you will get bitten.

To fix this problem, we use the MMU to map all addresses to themselves,
but we set the "cache inhibit" bits for I/O space.  The MMU's "cache
inhibit" bit *does* get checked on writes, not just reads.  This does
not affect performance (much) because the MMU has a cache of its own,
to remember recently-used address translations.  Almost the whole table
used by TOS fits in this cache, so the MMU won't be walking through
memory very much translating addresses.  We've timed it, and it  just
doesn't hurt that much: maybe 1%.

The write-allocate bit is used by TOS so you can access the same memory
in user mode or super mode and it won't confuse the cache. If you don't
set the write-allocate bit, you could write something as supervisor,
write it again as user, then read it as super and get the value of the
first write, not the second one. This is a side-effect of the
write-allocate bit, not its primary purpose.

It's hard to find, but all this stuff is in the 68030 manual: the
section in Chapter 6 (the cache) called "Write Allocate" is on point,
as is the whole MMU chapter.  Don't get clever with the MMU, though,
because we're likely to want to use it in the future.


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


Date: 20 Sep 90 19:00:03 GMT
From: Allan Pratt
Subject: TT RAM

csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes:
>apratt@atari.UUCP (Allan Pratt) writes:
>>VME memory is not accessible to SCSI, and you should use the buffer
>>pointed to by the _FRB cookie.

>Hum, hum, and how do we detect that some RAM is a) VME RAM and b) 16
>bits wide? Did I miss something here?

My comment about VME RAM was not clear.  In the TT030, which is the
full name of the machine that's now available, there are two kinds of
VME address space: A24/D16 and A16/D8.  These are not 32 bits wide, so
the SCSI chip can't access them.  The memory map, telling where in
memory those segments appear, should be part of the TT documentation:
if it's not, it will be.

The VME expansion isn't really for RAM anyway: VME RAM for a TT is
expensive and slow -- slow because it's only 16 bits wide, because it
goes through the VME bus, and because it's not cacheable by the 68030.
You're far more likely to want to put a video display card there, or
extra serial ports or something.  For those, the fact that the
processor can't get at the memory at full speed won't hurt too much.


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


Date: 1 Oct 90 18:15:29 GMT
From: Allan Pratt
Subject: How can I find current DTA address w/o using TRAP #1?

ADAM_TILGHMAN@bdt.UUCP writes:
>I need to trap all FSFIRST/FSNEXT calls (in order to substitute my own
>filenames), as well as FOPEN() calls (to change the filename to suit my
>needs)...
>I can't find the current DTA address;  is there any way that I can
>do this while processing a TRAP #1?

Since you're intercepting trap 1 calls, this should be cake.  Trap 1 is
not inherently non-reentrant, it's GEMDOS that makes it so.  Your code
could make a "real" trap 1 call into GEMDOS for the Fgetdta call.

Making a "real" trap 1 call can be done two ways: either you replace
the old trap 1 vector, make your call, then write yours in again,
or your "fake" the trap 1 by creating a stack frame and jumping to
the old vector.

Any time you catch GEMDOS or BIOS traps, or create a trap or interrupt
stack frame, you should be sure to check the system variable "longframe"
at $59e (word).  If it's nonzero, you are on a machine with "long 
frames" -- an extra word on the stack after the SR and PC.  Only  the
68000 has short frames; every other 680x0 has long frames.

I am answering this in such detail because I want to forestall somebody
else pointing out that you can look in the current process' basepage for
its current DTA pointer.  This is not a published fact, and therefore the
location and meaning of that variable is subject to change.


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


Date: 3 Oct 90 08:40:41 GMT
From: John Townsend
Subject: TOS 2.0 for the ATARI ST

in article <2473@maestro.htsa.aha.nl>, basv@maestro.htsa.aha.nl (bas) says:
> 
> I have seen TOS 2.0 for the ATARI ST. You must boot it from floppy.
> It looks great. I have a question. When is it avaible on rom. 
> -- 
>                     Bas v.d. Vlies
>                     Algemene Hogeschool Amsterdam, The Netherlands
>                     Technische en Maritieme Faculteit
>                     basv@maestro.htsa.aha.nl or ...{backbones}!htsa!basv


Atari has NOT released _any_ TOS 2.0 and especially on disk. If you have
a copy of a disk based TOS it is probably a pirated copy from one of our
subsidiaries.

I would urge you NOT to use this copy and destroy it. It's probably 
dangerous. No telling where it's been and if it's an early version of 
TOS 3.01 like I think it is.. then it is riddled with serious bugs.

There are no plans to release TOS 3.01 ( or TT TOS as it is also known )
for ST machines. It simply won't fit into the ROM space.


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


Date: 5 Oct 90 19:35:07 GMT
From: Allan Pratt
Subject: TT PROGRAM 24BIT.PRG -- USE FOR GFA BASIC PROGRAMS

david@bdt.UUCP (David Beckemeyer) writes:
>I know GFA programs don't run on the TT.

This is not exactly true.  Programs compiled with GFA 2.x will run on
the TT if you use the program 24BIT.PRG (included below) in your AUTO
folder.  What that program does is use the MMU to cause the CPU to
ignore the high byte of all addresses.  GFA BASIC uses the high bytes
of addresses for something, like a type value, and therefore isn't
"32-bit clean." 24BIT.PRG lets you run those programs.  You should also
run with the cache OFF, because the cache uses all 32 bits: $01xxxxxx
doesn't appear to be the same address as $02xxxxxx, even though they
are after they get through the MMU.

24BIT.PRG must run in your AUTO folder.  It has to run before any TSR's
that have their "alternative RAM load/alloc" bits set, so alternative
RAM is empty.  24BIT gobbles up your alternative RAM, so your system
runs as if you don't have any.  (If you *really* don't have any, this
is a no-op.)  You lose access to the VMEbus, too.  This is the price
you pay to run non-32-bit-clean programs.  GFA is working on their
problem.

GFA BASIC itself doesn't run on a TT, even under 24BIT.PRG.  I don't
know about programs compiled with other versions of the compiler, or
whether the compiler itself runs.

In addition to not being 32-bit clean, GFA BASIC uses memory it doesn't
own.  This means they are very sensitive to having other things in
memory (like another process if you're multitasking), and sensitive to
the TOS version (because they rely on certain undefined behavior of
Malloc.)  These practices are Not a Good Thing, and I yelled at them
about this when I was in Dusseldorf.

24BIT will run, but complain, if you're not on a TT, if your TT RAM
isn't empty, or if anything else is funky.


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

Date: 8 Oct 90 19:25:48 GMT
From: Allan Pratt
Subject: How can I find current DTA address w/o using TRAP #1?

gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) writes:

>roeder@robin.cs.uni-sb.de (Edgar &) writes:
>>In article <5429@bdt.UUCP> ADAM_TILGHMAN@bdt.UUCP writes:
>>
>>> I can't find the current DTA address;  is there any way that I can
>>> do this while processing a TRAP #1?
>>
>>The current process' DTA address is recorded in the basepage which can
>>be derived from the act_pd system variable (this in turn is recorded
>>in the sys_base (the first few bytes after the ROM-start) for TOS
>>versions >= 1.2).

>But I thought this is an "unofficial" way of finding the DTA, so it
>may break someday.

No, this is "official" -- contrary to my earlier posting, it's
documented in the original GEMDOS docs, and can't be considered a
mistake.  (Some things that were documented originally are now
considered to have been "mistakenly documented" and are subject to
change, but not many, and nothing important.  Example: the Getmpb BIOS
call should have been documented with "Used internally by GEMDOS" and
nothing else.)

>Watching all SETDTA traps, on the other hand, will always work.

This is not the case.  Each process starts with a default TPA which is
not set via SETDTA.  I'm not sure if that default DTA's location is
documented, but in all existing TOSes it's the process' command line
image, at (basepage+0x80).

No system calls use the DTA except Fsfirst and Fsnext.  It is not
unlikely that a future GEMDOS might have new calls which accomplish the
same thing but don't use the DTA at all, because having system
information in user-supplied buffers doesn't make good sense.  The DTA
and Fsfirst/Fsnext will be maintained for backward compatibility, of
course.  (And the fact that we have to keep them around guarantees so
much cruft in the code that there may not be much point in replacing
them.  But I digress.)


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


Date: 29 Oct 90 21:38:46 GMT
From: Allan Pratt
Subject: gcc ?????

eao@point.mps.ohio-state.edu (Ed Overman) writes:
>fprintf(stdout, "hello, world\n")  it aborts when loading with:
>  hello.o: Undefined symbol _stdout referenced from text

You are missing the line #include <stdio.h> -- this header file is
required when using the standard IO functions and it defines symbols
like stdout.  Technically, it's even required when you use printf, but
your program happens to compile because GCC happens to do the right
thing without the printf declaration.

This is not an accident: GCC was designed in part to be forgiving to C
programmers who don't do things they technically should do.  I have
used an ANSI compiler which did NOT forgive using printf without
including stdio.h!


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


Date: 30 Oct 90 19:57:21 GMT
From: Allan Pratt
Subject: TOS 2.0

The file called TOS 2.0 is an illegal copy of an EARLY test version of
the New Desktop.  IT DOESN'T WORK!  It is an old, buggy internal
version that should never have gotten into the public.  DON'T USE IT.
In the first place, it's illegal, but in the second, it's got BUGS. You
will LOSE FILES.  Things will GO WRONG.  Does this sound like something
you want to be using?


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


Date: 5 Nov 90 19:22:44 GMT
From: Allan Pratt
Subject: ST MicroEmacs Site Needed

ekrimen@ecst.csuchico.edu (Ed Krimen) writes:
>I just sent emacs39.lzh (actually it's 3.925, but who's counting :^) 
>to atari.archive.

Version 3.10 is much better, I think, because it has named procedures
rather than just macro numbers.  You can do something like this:

store-procedure line2top
	1 redraw-display
!endm

macro-to-key line2top M-!
  
This would be line-to-top-of-window, except 3.10 as distributed doesn't
have long-enough buffer names for all that (and doesn't have length
checking on strcpy etc. :-( )

In addition, I think 3.10's search functions are LOTS faster, but that
could have been in 3.9: was searching in big files slow in 3.8 but fast
in 3.9?  If they're the same speed then 3.10 is a BIG improvement.


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


Date: 7 Nov 90 21:19:28 GMT
From: Allan Pratt
Subject: TT graphics modes

micro@imada.dk (Klaus Pedersen) writes:
>Shifter mode called "Sample&Hold".
>(the article said something about HAM and lotsa colors!).

SAH mode has nothing to do with lots of colors.  What it lets you
do is draw filled polygons really fast.  You can draw two dots
on the screen and get a solid line between them, without having
to write the color value to all the pixels in between in memory.
Example below.

>  What happend to the 256 GRAYSCALE mode of the TT ? 

It's there.

>  What is the display reflech rate of the TT (TT-LOW/TT-HIGH) ?

That's "refresh rate" and the color modes are 60Hz no matter what
country you're in. TT HIGH rez is 1280x960 monochrome, and its
frame rate is 67hz, I think.

EXAMPLE OF SAH MODE:

In SAH mode, nonzero pixel values in memory appear as that color, and
zero pixel values in memory mean "continue with previous color."  That's
why it's also called "smear" mode: a colored dot will "smear" to the
right until it reaches another nonzero pixel value.

In the diagrams below, a period (".") is a zero dot and a star ("*") is a
one.  In addition, a zero ("0") represents a pixel value which has the
same color as the background.  Let's say you want a picture like this:

........
..****..
...**...
..****..
........

You can get it by drawing this:

........
..*...0.
...*.0..
..*...0.
........

This means you only had to write six pixels, not thirteen.  Of course,
this is just a sample: the savings is much more dramatic for bigger pictures.

(The trailing "0" in the second picture is what stops the smear from
going all the way to the right edge of the screen.  The left edge starts
out in the background color.)


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


Date: 14 Nov 90 23:33:50 GMT
From: Allan Pratt
Subject: OS in ROM/RAM & viruses (was: Re: TOS 2.0)

A "bootable" floppy is one with an executable boot sector (checksum
$1234).  If you have a "bootable" floppy in the drive, the boot sector
will be executed before the hard disk is hit.  The executable code in
the boot sector can, for example, install a virus, then end with "rts"
to return to the ROMs, at which time the hard disk will boot.  This
is how the Key virus (and all other boot-sector viruses) work.

You are safe from them if you have a disk in the drive which does NOT
have an executable boot sector, or no disk at all. It's best to
write-protect this disk, so nothing can write a virus into the boot
sector.


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


Date: 3 Dec 90 22:10:36 GMT
From: Allan Pratt
Subject: ARC 6.02 doesn't warn when out of space!?

I have ARC 6.02ST and I found out last night that it doesn't tell
you when it runs out of disk space!  Freeware buyer beware!

Here's the banner message from the ARC I have:

ARC-ST - Archive utility, Version 6.02ST, created in November of 1989
Copyright 1985-89 by System Enhancement Associates, Inc.; ALL RIGHTS RESERVED


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


Date: 10 Dec 90 22:44:12 GMT
From: Allan Pratt
Subject: Atari SH204 hostadapter with 'genuine' SCSI drives

heiden@kboeng.enet.dec.com (Matthias Heiden) writes:

[Edited]
>I would like to upgrade my original SH204 with another drive.
>As far as I understand the hostadapter inside the SH204 understands SCSI.
>Does anybody has experience with this solution ? What sort of problems could I
>run into ?

This works for some SH204's.  However, the power supply in the SH204 is
not beefy enough for some drives.  The only way to tell is to see if it
dies. Therefore this is not recommended practice.  In addition, the
host adapter might have the "old" PAL, not the "new" one, which won't
return some errors from the SCSI controller.  This bit me recently: the
"old" PAL didn't return "write protected" from my Syquest drive, and
boy was I confused!  The writes seemed to work, but the cached
directory etc. didn't match what was actually on the disk.

The "old" PAL has the number 60AC on it.  If the little board in your
SH204 has a chip with that number on it, it won't return some errors
from the drive.  I don't know how to get the "new" PAL - maybe dealers
can order it.  Since the SH204 is not in production any more, this
might be hard.


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


Date: 17 Dec 90 22:46:47 GMT
From: Allan Pratt
Subject: saving GCC errors (includes source!)

rcb@netcom.UUCP (Roy Bixler) writes:
>I am using GNU C inside of Gulam 1.04.05 ...
>re-direct the standard error output to a file..

Here's a program that does what you're after.  It compiles under MWC, GCC,
and Alcyon C.  It works best under Gulam because Gulam implements shell_p,
a way for a child of Gulam to say "here, Gulam, please execute this
command line for me."  It may not be the best 'c' you've seen, but it
works.

(Interesting note: the MWC executable is 3622+690+188=4500 bytes
text+data+BSS (almost all text; real small), the Alcyon C executable is
6834+1434+9124=17392 bytes (half is GEM binding BSS), and the GCC
executable is 19592+904+3812=24308 bytes (just big).  The GCC "system"
call from Bammi's library is by far the most complex; I don't know what
else makes it so much larger. I tried to use "minimal.h" for the GCC
version but it didn't work: system() must use something from main.c.)

============================== rd2.c ==============================
/*
 * perform a system() call, but first, redirect handle 2 to a file.
 * See the umsg string for usage.
 * Written by Allan Pratt of Atari Corp., Dec. 17, 1990 and placed 
 * in the public domain without any warranty, expressed or implied.
 * Your mileage may vary.
 */

#include <osbind.h>

void usage();

int
main(argc,argv)
int argc;
char *argv[];
{
	int oh2;
	int nh2;
	long err, akp_system();
	int i;
	char buf[1024];

	if (argc < 3) usage();

	oh2 = Fdup(2);
	nh2 = Fcreate(argv[1],0);
	Fforce(2,nh2);

	strcpy(buf,argv[2]);

	for (i=3; i<argc; i++) {
		strcat(buf," '");
		strcat(buf,argv[i]);
		strcat(buf,"'");
	}

	err = akp_system(buf);

	Fclose(nh2);
	Fforce(2,oh2);
	Pterm(err);
}

/*
 * system() call used below.  It checks for SHELL_P in the environment.
 * If it's there, the pointer at 0x4f6 is assumed to point to a routine
 * which will execute a command string.  If it's not, the library system()
 * is called.  AKP.
 */

long
akp_system(s)
char *s;
{
	char *ptr, *getenv();

	if (getenv("SHELL_P") != 0) {
		long oldssp = Super(0L);
		long (*shell_p)() = *(long (**)())0x4f6;
		Super(oldssp);

		return (*shell_p)(s);
	}
	else return system(s);
}

char *umsg[] = {
  "Usage: rd2 stderr_file cmd args ...",
  "",
  "Where: stderr_file is the file that stderr (handle 2) gets redirected to,",
  "cmd is the command you want to execute, and args are the arguments to that",
  "command.  You can redirect stdout from your shell, and the child's stdout",
  "will go there; don't use the same file as stderr_file, though.",
  "",
  "(This program will use shell_p a la Gulam if you setenv SHELL_P to",
  "anything, otherwise it relies on the \"system()\" call from the library",
  "you compiled with.)",
  (char *)0
};

void
usage()
{
	char **p = umsg;

	while (*p) {
		Fwrite(1,(long)strlen(*p),*p);
		Fwrite(1,2L,"\r\n");
		p++;
	}
	Pterm(-1);
}
========================= end of rd2.c =========================


---- END OF FILE ----

