



                        ATARI TECHNICAL POSTINGS

                                  1991




This volume is a collection of postings to Usenet by Atari's technical
staff from January '91 through to December '91. Postings from November
'88 through to October '89 are available in ATARI_89.TXT and postings
from 1990 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.
1991.


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


From: Allan Pratt
Subject: Re: Setting 2000 year date
Date: 4 Jan 91 19:24:20 GMT

alex@hpgnd.grenoble.hp.com (Alexis MERMET-GRANDFILLES) writes:
>My STE definitively refuses to set its Date to any day
>after the 31 december 1999.

I just tried setting the date to 1/4/2001 on my TT and it works fine.
The code hasn't changed between 1.62 and this version, so I don't know
what to tell you.  Try Tsetdate(0x2a24) -- the return code should be
zero, meaning it succeeded.

If you then try to print the date with a program which is not prepared
to handle the turn of the century, that can cause trouble, but it's not
TOS's fault.


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


From: Allan Pratt
Subject: Re: DMA/FDC Programming
Date: 9 Jan 91 21:11:40 GMT

bcullign@vax1.tcd.ie writes:
>Could someone tell me how to program the DMA and the Floppy Disk Controller
>(FDC) on a 520STFM? Any info would be appreciated.

You might get more help if you described what you're trying to do.

From me, you'll get advice on how to do it without directly programming
the DMA or FDC components of the system.  Unless you're an operating
system, there's no reason that you need to talk to the DMA controller
or the FDC directly.  If you're a developer, check your docs about the
Flop* and Rwabs BIOS calls.  If you aren't, then become one so you can
find out about this stuff.


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


From: Allan Pratt
Subject: Re: Max of 113 files in a subdirectory: fact or fiction?
Date: 10 Jan 91 19:56:06 GMT

GEMDOS imposes no limits to the number of files you can have in a
subdirectory. The only limit is disk space: the directory file itself
needs to grow as more files are added to it.  Under some versions of
TOS, the Desktop will not show more than N files in one folder, but
that's a Desktop limit, not a GEMDOS limit.  Gulam might also gag if it
finds a large number of files in a directory, or if it's asked to copy
a large number of files, but I have not had that problem, and I've used
it to copy large numbers of files (>1000 total, >100 in some
directories).

Root directories do have a limited number of slots for files; this
number is fixed at the time you format the disk.  It's often 128 or so.


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


From: Allan Pratt
Subject: Re: switching res
Date: 10 Jan 91 19:59:10 GMT

sslee@polyslo.CalPoly.EDU (Steven Lee) writes:
>       char *ainit=(char *)a_init;  /* Line A call, $A000 */
>       Setscreen(-1L,-1L,0);
>       *((int *)(aline-692))=319;   /* Mouse X limit */
>       *((int *)(aline-690))=199;   /* Mouse Y limit */
>       *((int *)(aline-666))=16;    /* # of bitplanes */

Setscreen() fills in the line-A variable space with correct values for
the new resolution, so you don't have to do it yourself. This is the
right way to change rez, if you want to do that. Since you already know
you're going "behind AES's back" in doing this, I won't lecture you on
the implications.  As long as you Setscreen() back to the old rez
before you make any AES calls, this works.


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


From: Allan Pratt
Subject: Re: case insensitivity in TOS
Date: 14 Jan 91 21:34:18 GMT

rosenkra@convex.com (William Rosencranz) writes:
>is there any inherent reason why future TOS versions can't be case
>sensitive [...?]

The quick answer is this: GEMDOS was that way originally because MS-DOS
is that way, and GEMDOS is still that way because it was that way
originally.

There is little hope of a case-sensitive GEMDOS in the near future. If
you're desperate, you can look up UNIXMODE from Bammi@cadence.com. I
don't know if he has a stand-alone TSR version yet, or if it's still
just part of libraries you have to link with to get it.


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


From: Allan Pratt
Subject: Re: Setting a 2000 year date *HELP*
Date: 14 Jan 91 21:59:08 GMT

I assure you it has nothing to do with being in France.  The countries
that we do ROMs for get their ROMs from headquarters, and there are no
differences in low-level time handling.

I have just done some research on the clock handling, and I think
you're  right: if you don't have a clock chip in your system (i.e. not
a Mega ST or Mega STe or TT) then the keyboard clock is regarded as the
most correct one, and it uses the "last two digits of the year" method
of keeping time.  This is too bad.  If you have a clock chip, either
the kind in the Mega ST and Mega STe (from Ricoh) or the kind in the TT
(from Motorola), then your IKBD clock is never used, and this problem
does not arise.  Also, of course, if you have some third-party clock
chip and a TSR that intercepts the Xbios Settime/Gettime calls, you
won't have this problem.

Sorry I blew you off earlier: I forgot that there was so much variation
in timekeeping in the Atari computer line.

It is certainly possible to fix this in the BIOS or with a TSR, but
I don't think it'll be a priority for 9 years or so :-)


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


From: Allan Pratt
Subject: Re: TOS Version (was Veriosn)
Date: 18 Jan 91 21:49:50 GMT

bdm@sirius.rice.edu (Brian D Moore) writes:
>     Quick question...how do I know which version I have?  [...]
> Perhaps the default date tells, which is 4/22/87.

That date is the date of the Mega TOS release (TOS 1.2), so that's
probably what you have.

The definite way to tell is to read the OS header.  A pointer to the OS
header is at $4f2, and the TOS version number is found in the second
word of the OS header.  For example, $0102 there means TOS 1.2.


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


From: Allan Pratt
Subject: Re: Hidden folders (was Hidden Files)
Date: 23 Jan 91 18:58:39 GMT

Somebody says "MAC copies to MSDOS (Atari) disks create a hidden folder."

Then ss60wbi@sdcc4.ucsd.edu (G. "Maddog" Knauss) writes:
>You can make ANY file think it's a folder by fiddling with
>GEMDOS(67). [...] I shudder to think of what's going to happen to the disk
>structure if the file isn't actually a folder, though.

TOS versions 1.4 and greater do not allow this.  They return "access
denied" if you try to change the folder bit to make a file into a folder.
You also can't set the volume-label bit or any of the undefined bits.

You can't change ANY of the attribute bits of a folder.  If the folder
bit is set, it has to be the ONLY bit set.  "Hidden folder" is an invalid
combination under GEMDOS.

Obviously, it's possible for something illegal to come in from outside.  I
really didn't think about this when I put those restrictions on Fattrib.
I'll have to think about that one.


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


From: Allan Pratt
Subject: Re: GEMDOS dir/drive changing
Date: 29 Jan 91 21:55:07 GMT

rosenkra@convex.com (William Rosencranz) writes:
>if i Pexec a process, then within that process do a Dsetpath/Dsetdrv,
>when i return from the Pexec, will the parent think it is back in the
>same dir before the Pexec, or will the child's actions be
>propagated back to the parent? in other words, is GEMDOS's concept
>of current/default directory global in scope or is it per process?

Why don't you try it?  The answer is that it's per-process.  The
information is stored partly internally in GEMDOS and partly in the
process' basepage (in the GEMDOS-private part).


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


From: Dave Hanna
Subject: Re: Fast Raster Routines Needed.
Date: 31 Jan 91 18:31:55 GMT

In article <1991Jan23.005852.28904@sbcs.sunysb.edu> mrose@libserv1.ic.sunysb.edu (Michael Rose) writes:
>       Also, does anyone know how the bit planes are set up in the new
>TT specific graphics modes?  In the 320x480x8 mode, does one byte equal
>one pixel?

    NO!  The 320x480x8 mode is merely an extension of the X 2 and X 4
planar modes:  2 bytes hold plane 1 data for the first 16 pixels, followed
by 2 bytes for plane 2 for the first 16 pixels...


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


From: Allan Pratt
Subject: Answer to "what does CACHEnnn do?"
Date: 1 Feb 91 02:29:23 GMT

carter@cat34.cs.wisc.edu (Gregory Carter) writes:
>I don't even know of [a disk accelerator] that does, except Atari's really
>absurd cache program, which doesn't work worth a dam.

You might not understand what CACHEnnn does.  If you think it is supposed
to do something that it doesn't do, you will think it does it badly.

Try this: without running CACHEnnn say "show info" on a disk (floppy or
hard). Now say it again.  Took a while, right?  Had to hit the disk both
times, right?

Now run CACHEnnn (with nnn at least 020) and and do it again. The second
time you "show info," the disk isn't accessed, because the information is
in memory already.  That's an example of what CACHEnnn does.

(This demonstration won't work with a write-protected floppy, because the
second "show info" will actually read the disk to detect media change.)

CACHEnnn doesn't do much good on a machine with TOS older than 1.4 because
those versions used the cache badly: adding more buffers to a badly managed
cache doesn't help.  But STe's have TOS 1.6 or 1.62, so that's not an issue.


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


From: Allan Pratt
Subject: Re: Hidden folders (was Hidden Files)
Date: 6 Feb 91 20:59:38 GMT

neil@cs.hw.ac.uk (Neil Forsyth) writes:
>As it is I can hide a folder by flipping the bit manually
>using a disk editor. (It's OK Allan I reboot afterwards!)

It's not OK.  GEMDOS's behavior in the presence of unexpected flag
combinations is undefined.  For example, some places in the code could
check for (attr & SUBDIR) but some check for (attr == SUBDIR). So you might
find that you can use the thing as a folder, but  you can also Fdelete it,
or if you Fcreate a file with the same name it'll get clobbered!  This
would be disaster for the files contained in the folder.

You're playing with fire.


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


From: Allan Pratt
Subject: Re: Hidden folders (was Hidden Files)
Date: 11 Feb 91 20:10:31 GMT

>apratt@atari.UUCP (Allan Pratt) writes:
>>For example, some places in the code could
>>check for [...] (attr == SUBDIR).

wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes:
>If it is allowed to criticize the Sensei:
>This a a VERY bad programming style.

Tell me about it.  I didn't write GEMDOS, I inherited it.  Besides, I
didn't say this was the case, I said it might be.  I think it is. I haven't
looked.  I choose not to look, so as to keep the possibility open.  It's
like Schroedinger's Cat: if you don't look, you don't know.  In this case,
I want to assume (and I want you all to assume) it's unsafe.


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


From: Allan Pratt
Subject: Re: bombs on an STE
Date: 13 Feb 91 21:20:25 GMT

avgroeni@cs.ruu.nl (Annius Groenink) writes:
>  Has any STE owner ever had the problem of two bombs (bus error) appearing
>on the screen after one of the alert boxes `no disk in drive A' or
>`Disk in drive A has been write-protected'? Can anyone explain this strange
>behaviour of my computer (which already caused me to loose MANY files)?

Try not running any accessories, and see if the problem goes away.

There is a bug in some TOSes: if an alert comes up, and then an accessory's
event_timer call expires, and then the accessory makes a GEMDOS call, you
will get bombs when you click either button of the alert.

The original Control Panel from Atari (the one that lets you set the colors)
did in fact use event_timer and then make GEMDOS calls, so it would cause
this problem to happen.

Most accessories don't have this problem, since (A) they don't use
event_timer much, or (B) they don't do GEMDOS calls as a result of
event_timer.


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


From: Allan Pratt
Subject: Re: catch SLM DMA-calls --- How?
Date: 13 Feb 91 21:23:53 GMT

nico@cs.ruu.nl (Nico Verwer) writes:
>about all [the SLM804] can do is print bitmaps, which are built in memory.

That's right.  But the WAY it prints bitmaps, and the way they are built,
and the way they get sent via DMA to the printer, are all pretty strange.

One thing you can do is have your program (whatever it is) write a page
image to memory, then use the DIAB630 software to send that page to the
printer.  There are escape codes which say, "Hey, printer driver! There's a
page image at location X in memory - print it!"

So if you can get a bitmap to appear in memory someplace, you can point
DIAB630 at it and it'll be printed.


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


From: Allan Pratt
Subject: Re: Apple wins against Microsoft Windows/HP New Wave
Date: 11 Mar 91 19:00:48 GMT

>>In article <4159.27d64355@miavx1.acs.muohio.edu>, 
>>rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins) writes...
>>...is Digital Research and Gem far behind?...

>gilliam@lowlif.dec.com writes:
>Apple did sue DRI in 1985 and won. The Atari license using GEM V1.1 was 
>exempted from the ruling. That's why subsequent versions of GEM are different.

Actually, that's not the case.  I don't know if Apple actually sued DRI,
but I don't think so.  The story as I know it is that they just made
threatening noises, and DRI knuckled under.  DRI agreed to modify GEM to be
less Mac-like (e.g. no overlapping windows), and that got Apple off their
back.  Atari's license pre-dated that agreement, I think.

I'm just blabbering; I don't really know anything.  Have your lawyers talk
to our lawyers if you want facts and legal opinions rather than scuttlebutt.


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


From: Allan Pratt
Subject: Re: TOS 1.4 /auto/ folder stuff
Date: 11 Mar 91 19:08:18 GMT

steve@thelake.mn.org (Steve Yelvington) writes:
>I now have TOS 1.4, and I'm not sure what /auto/ folder programs
>I ought to be using with it. FATSPEED apparently isn't compatible
>or necessary. I have FOLDR200.PRG (probably overkill). I'm running
>DCACHE 1.0f. Is there anything else I really ought to have?

Yes, you should have POOLFIX3.PRG.  This is a program which fixes a serious
bug in GEMDOS.  The bug doesn't bite all the time, but often enough and
seriously enough that "Thou Shalt Run POOLFIX Under TOS 1.4 And 1.6" is a
good commandment to have lying around.

I don't know what DCACHE does, but it is probably different from what
CACHEnnn does.  CACHEnnn installs multiple cache buffers in GEMDOS. The
resulting speedup in original TOS and Mega TOS (1.2) is small, but in TOS
1.4 it's great.  Try this: do a "show info" on a hard disk from the Desktop
once, then do it again on the same disk.  If the second time didn't cause
any hard-disk accesses, then you're in business.  If not, use CACHEnnn
(where nnn is three decimal digits, 080 is a good place to start).


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


From: T R Hall
Subject: Re: ST Pad specs
Date: 25 Mar 91 18:38:20 GMT

ekrimen@ecst.csuchico.edu (Ed Krimen) writes:

>johns@maccs.dcss.mcmaster.ca (Conan the Barbarian) writes:

>- TOS with additional stylus features including mouse emulation and
>- handwriting recognition.
> 
>I don't know, but for some reason 'TOS with...handwriting recognition'
>doesn't seem to jive, if you know what I mean. :^)

>Thanks for posting the information.  May I ask where you found it?  I 
>just like to know the sources of these things. :^)

     You may feel skeptical, but as the designer of the two machines
announced, I can tell you that "TOS ... with handwritting recognition" is
FACT, not conjecture. The HCR code will be in the ROMs (and was, in the Demo
at CeBIT), and tied into the operating system and desktop such that a gesture
in the Menu Bar area will bring up a window (as invisibly to existing
applications as possible) into which Hand-written characters are drawn. As you
write, the characters are converted to ASCII; when you are satisfied, the
characters are sent (via the Keyboard input stream) to the application. This
way, _*existing*_ applications will have HCR capabilitites.

     The "hooks" to call the HCR system will be available to software
developers, so they may call it directly, to recognize ASCII characters,
special character sets, or even gestures. This will be part of the standard
documentation. In case you're curious, the software is a neural-net
simulation.

                                                TRH

[ Incidently, "OCR" is "Optical Character Recognition" and "HCR" is
"Handwritten Character Recognition"; the former uses the Bit-Map image; the
latter uses the "pen-stroke" information directly.]


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


From: Allan Pratt
Subject: Re: The cause of the phantom typist
Date: 4 Apr 91 21:13:42 GMT

micro@imada.dk (Klaus Pedersen) writes:
>> To exorcise one may
>> 1) Replace expressions like ++i; if(i == ANYPOWEROFTWO) i= 0;
>>    by ++i &= (ANYPOWEROFTWO - 1)

>jan@janhh.hanse.de (Jan Willamowius) writes:
> in what language do you want to write that?
>What you are writing is :
>    ++i = ++i & (APO2-1);
> - no matter how you try to hide it...

That's not true. Semantically, "i += 2;" is equivalent to "i = i + 2;"
but "++i += 2;" is not equivalent to "++i = ++i + 2;" because the
people who designed C are smarter than that.  The side-effect is
performed only once.

But regardless of that, you are suggesting that what happens in a C
statement is uninterruptable, so doing something in a single statement
makes it safe when it might be unsafe in multiple statements.  This is
not true.  On the 68000 family, an interrupt can come between any two
instructions.  Individual instructions can't be interrupted, but the
bus can be arbitrated away (for DMA, for example) between the read and
the write of a read-modify-write instruction, except for the TAS
instruction which is explicitly atomic.


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


From: Allan Pratt
Subject: Re: Hardware -vs- Software Scrolling
Date: 4 Apr 91 21:24:01 GMT

>In article <150708@pyramid.pyramid.com> wniren@pyrtech.pyramid.com 
>(Walter "Crash" Nirenberg) writes:
>>My question is what's the difference between scrolling routines written
>>for an older system and a new system with hardware scrolling?  Would I have
>>to completely rewrite them to take advantage of the hardware or would it be
>>a minor modification?

vsnyder@jato.jpl.nasa.gov (Van Snyder) writes:
>I've been using the raster operations in VDI and LineA, in the hope that the
>OS will automatically take advantage of the hardware when it's there.  If
>I'm wrong, will somebody please post?

You're wrong.  The only hardware that can help raster operations is a
blitter, and VDI/LineA automatically takes advantage of that when you
do those operations. But "hardware scrolling" means something else.
It operates on the entire display, not just pieces of memory.

Hardware scrolling means that you have a "virtual display" which is
larger than your physical screen.  Imagine a large piece of paper with
a smaller piece of glass on it. Your screen is a "window" onto the
larger display.  You can move the window around very quickly, in very
fine increments, and this is hardware scrolling.  The point is that you
just bang a few registers rather than moving all 32K of screen memory
to accomplish the move.  (On the TT it can be 150K of screen memory!)

(Of course, the piece of paper doesn't have to be as big as the world
you're scrolling around in; it can be just a little bigger, and you can
write the world in strips as it becomes visible.)

Both the TT and the STe can move the window vertically on single-line 
boundaries, and the STe can move the window horizontally on
single-pixel boundaries, but the TT can only move horizontally on
8-byte boundaries. This is eight pixels in the 256-color mode, but
sixteen pixels in the 16-color modes, and sixty-four pixels in the
monochrome modes.

Hardware scrolling is only good for limited applications like paint
programs where you want a canvas larger than your screen, or games
where you want to scroll the player's view around in a larger world.

Hardware scrolling CAN be used to make whole-screen scrolling faster.
This is something you do in TOS programs when you're on the bottom line
of the screen and you hit return.  But that's another specialized
operation, and it doesn't help such useful programs as Emacs, where
some parts of the screen move and some don't.


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

From: apratt@atari.UUCP (Allan Pratt)
Subject: Re: TOS 2.05 bugfix
Date: 12 Apr 91 00:21:17 GMT

larserio@IFI.UIO.NO (LarsErikOsterud) writes:

>While testing out my new MEGA STE i discovered a nasty bug in one
>of the Xbios routines (I can't understand why no beta-tester has).

Maybe because it's not a bug.

>The XBIOS 5 call  setscreen(logadr,physadr,resolution)
>is used to set screen adresses and change screen resolution.

>The routine does NOT wait for vertical blank as it i supposed to
>but resets the video in the middle of the screen, causing the
>picture to wrap around the left edge of the screen in 50% of
>the cases.  This does not look good (you get the edge of the
>grapic screen in the middle of the monitor screen :-)

Thank you for starting a panic.  I think it is not a bug but a problem with
your Mega STe.  I can not reproduce the "bug" you report.  It might have
occurred to you that your Mega STe is to blame, not TOS.

Your lack of understanding of the reasons for the protection code in the
ROM has led you to a false conclusion.  To nip this in the bud, I'll
explain.  The shifter mode must not be changed during a critical moment
around vertical blanking.  Previously that was avoided by waiting for the
vblank interrupt, which ensures that the critical moment has passed.  The
new code uses another method: it checks to be sure that you are in the
middle of the screen someplace, not in vblank.  The upshot is the same: you
avoid the window of vulnerability.

If you had named the programs that caused trouble this would have been a
more useful bug report.  It is possible that there is an interaction
between those programs and the new code.  Please post or mail me the names
of those programs.

If this turns out to be a real live software bug, I will eat my words.

(Lars-Erik has responded to me in mail about the programs (e.g. Degas
Elite) and I have suggested that he return the machine to his dealer. This
posting is for everybody else, so you don't think we're totally out to
lunch when it comes to testing software.)


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


From: Allan Pratt
Subject: Re: Ptermres()
Date: 11 Apr 91 21:19:08 GMT

>wolfram@tschil.informatik.rwth-aachen.de (Wolfram Roesler) writes:
>... and then terminates via Ptermres(0,0) ...

csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes:
>If I'm wrong here, Allan Pratt
>will certainly correct me in an instant 8-)

Did I hear my name being called?

Ptermres(0,0) is unsafe.  Your TPA is shrunk to zero size (or freed) before
the terminate happens, and therefore you are relying on the contents of
memory that nobody owns: the contents of your basepage to process the
terminate.  This is bad news. Don't do it.  The minimum size argument to
Ptermres should be $80 (the size of your basepage, up to the command line).
This wierd case is not one the authors of GEMDOS (including me)
anticipated, so it's not enforced or anything.  I guess it could be.

Of course, people frequently *do* rely on the contents of memory that
nobody owns, but it's not SAFE.  In particular, that address may have no
meaning any more in a VM system.


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


From: Allan Pratt
Subject: Re: How store extra data at the end of an executable?
Date: 12 Apr 91 21:09:38 GMT

>erik@mcrware.UUCP (Erik Johnson) writes:

>Here is what I would like to do.  I would like to append a picture file to the
>end of my executable file.  In this case, the extra data is a picture file that
>is the menu for my program.  Once a program is loaded into memory, is it closed
>and all file offset information lost, or is there a way I can start reading
>data from the file where the program data left off.

wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes [some stuff
based on wierd and wrong guesses about how things work].

You can't just tack the picture data onto the program file after the
program's data segment, because that would mess up the BSS segment.

I reiterate: you should not try to "append a picture file to the end of
[your] executable file" but rather "arrange for a picture file to
be included in your program file."  This you can do, in the worst case,
by turning the picture file into an assembly (or C!) source file,
assembling (or compiling) it, and linking with the resulting .o file.

Example using my DB (it doesn't matter what compiler you ultimately use):

        :read picture.neo
        :transcript mypic.c
        :dw(+ `rwstart 4)[@32] ; dw(+ `rwstart 80)[@32000]
        :transcript off

Now, in mypic.c, there's a top line you should delete ("dw..."), two lines'
worth of palette data, and 2000 lines' worth of picture data, followed by
another line you should delete ("transcript off"). You have to edit the
file to remove the address and ASCII fields from the dump, and prefix each
number by "0x", and put commas between them, and now you can wrap them in
to C as array initializers, so the result looks like this:

short paldata[] = {
        0x0777,0x0007,0x0070,0x0700, ...,
        ...
};

short picdata[] = {
        0x ...
};

and now you can compile this file, link with it, and use the symbols
paldata and picdata in your program.


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


From: Allan Pratt
Subject: Re: Porting from MWC code
Date: 12 Apr 91 21:15:13 GMT

bill@mwca.UUCP (Bill Sheppard) writes:

>I'm in the process of attempting to recompile MicroEmacs 3.11 to make some
>changes (remove mouse support so I can use within a CLI, for one).  

I will be doing that for Dan (making it truly conditional on the compile-time
symbol "MOUSE") before the true 3.11 release.  I tell you so you know you're
probably duplicating the effort.

>source code appears to expect Mark Williams C, but I'm using Sozobon (also
>have Alcyon).  So far I've seen two compilation (haven't tried linking yet)
>errors: the structure DMABUFFER is expected in stat.h, the Sozobon stat.h
>doesn't reference it, and "aesbind.h" is expected, which also isn't in the
>Sozobon or dlibs distribution.  Any ideas how these can be compensated for
>or where I might find AES bindings (are they in another .h file?)

This Emacs for the ST is GREAT, but the portability stuff is TERRIBLE. If
you're on an ST, the code only works for ST520 and ATARI and MWC. If you
want to do something different, like a different compiler, you're in for
trouble.

Basically, you should leave MWC and ATARI and ST520 defined and then and
remove code as necessary for your compiler.  DMABUFFER is the MWC name for
the DTA structure; it's only used in getffile and getnfile. Substitute the
DTA struct from your compiler (check osbind.h or make your own) and fix the
field names in the defines that have "info" in them.

As for aesbind.h, it might be called gem.h or gembind.h.  It has the
AES structure and constant definitions, the companion to vdibind.h.


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


From: apratt@atari.UUCP (Allan Pratt)
Subject: Re: Problem with my C program [a few general hints about malloc]
Date: 25 Apr 91 20:50:24 GMT

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

>[In article <1991Apr22.014758.3846@wam.umd.edu>,
>     dmb@wam.umd.edu (David M. Baggett) writes ... ]

>> If you want to allocate more memory than can be specified in an unsigned int,
>> use calloc.  It takes two parameters which are multiplied together to get
>> the size of the requested block.  To allocate 128K:
>> 
>>      p = calloc(128, 1024);

In general, this is not a fix.  I have seen allocators which call malloc
from calloc after multiplying the two args together AS INTS, not longs. So
this does you no good at all.  Some compilers work and some don't in this
respect.  You pays your money and you takes your chances.

>You also can use lalloc, which works like the library malloc()
>function except that it requires a long argument. (Be sure to include
>malloc.h when calling any dynamic memory management functions.)

Much better solution, if your library has lalloc. Some have lmalloc, so try
both.  (I forget if the original poster said what compiler/library he was
using.)

>> In general it is VERY WISE to avoid using the bios Malloc and Free and
>> use the malloc, calloc, and free provided with your compiler of
>> choice.

Humph.  TOS 1.4 and upwards have NO PROBLEMS with Malloc that have been
reported to me.


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


From: Allan Pratt
Subject: Re: Weird TT hard disk thingy
Date: 29 Apr 91 17:15:23 GMT

cummins@unx2.ucc.okstate.edu (John Cummins) writes:
>On my Mega ST... I have no SCSI 0 drive.  I use scsi 4 and 5 so I can
>daisy chain a friends scsi 0 drive and still access my own disks.
>But I can still boot... and use my hard disks w/o any SCSI 0 device
>attached.

>The fellow you've been chatting with says the TT won't recognize SCSI devices
>1-7 on the ASCI bus, at least not without an SCSI 0 in place.  Device 0 MUST
>be used for the first device.  Why????

[Am I "the fellow [he's] been chatting with"?]

I can't speak for what SCSI unit numbers ICD or Supra adaptors will or
won't recognize.  From the data presented here, it sounds like ICD will
handle any SCSI unit number on the drive, and Supra will only talk to SCSI
unit zero. The latter is not unreasonable -- if you've got only one drive
on a SCSI-to-ACSI converter, why include the logic to talk to an arbitrary
SCSI device number?  It would mean logic in the adaptor to see what SCSI
drives are out there.

I have even heard of some adaptors which look at the SCSI unit number of
the drive that's connected, and configure themselves as that ACSI unit
number, further confusing the issue.

As for the ST/TT side of the bus, you have to start with zero on each bus
and increment by one for each drive you connect to that bus.  (Remember,
that's unit numbers as the computer sees them, not as the adaptor sees the
disk it's actually talking to.)  The reasons for this are kind of involved,
and I don't want to go into them; just take my word for it and carry on.

I hope this clears up the questions about busses and unit numbers, and we
can get on with our lives.


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


From: Allan Pratt
Subject: Re: *** HELP! Annoying Verticle line screen garbage! ***
Date: 29 Apr 91 17:20:44 GMT

sean@ccwf.cc.utexas.edu (Sean Sterling Foiles) writes:
>Occasionally my ST Color Monitor SC1224 fills up with vericle lines along
>the left side of every other character column.  In lo rez that means 20
>verticle lines, in med rez it's 40. 

That's "vertical," not "verticle."

Take your machine to a dealer.  There's something wrong inside. A dealer
should be able to diagnose, attempt a fix, and ultimately repair or replace
the motherboard.  If the machine is out of warranty he will probably want
to charge you something.  Let him.


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


From: Allan Pratt
Subject: Re: Can't get Setpallete() to work.
Date: 29 Apr 91 17:27:48 GMT

marco@sys6626.bison.mb.ca (Marco) writes:

>Here's the code I've been trying to use to blank (black) my screen:
>----------------------------------------------------------------------
>#include <stdio.h>
>#include <osbind.h>

>main()
>{
>int i, pal;
>for (i=0;i<16;i++)
>        pal = i;
>Setpallete(pal);
>}

This won't work because Setpallete (sic) takes a LONG argument which is a
POINTER to an ARRAY of 16 INT's.  Check those types in the documentation!
If you look at your code again I think you'll realize that it doesn't make
any sense at all.

main()
{
        int i, pal[16];
        for (i=0; i<16; i++)
                pal[i] = 0;
        Setpallete(pal);
}

Setpallete is a misspelling of Setpallete, and is that way because Atari's
original docs and include files spelled it wrong in the first place.
As has been pointed out, this is now retained by most compilers.

A caveat for Setpallete users: the above program is unreliable because
Setpallete copies its argument to a variable, and the palette registers are
loaded from the 16 int's found there AT THE NEXT VBLANK.  Since the above
program has terminated by the time the next VBLANK rolls around, that means
this memory is not owned by anybody, violating the commandment "Thou shalt
not mess with memory thou ownest not."  I know the "program" is just an
example of this poor slob's problem, but it bears repeating that Setpallete
is a delayed-action call.


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

From: Allan Pratt
Subject: Re: TT ROM
Date: 2 May 91 18:02:12 GMT

kimmo@field.fi (Kimmo Lahtinen) writes:
>Here in Finland we are getting TT's with Swedish ROM,
>and there seems to be some problems in them. Also 
>my friend does not like so much for Swedish as language
>for a computer. So I would like to know if it would
>be possible to have an English TOS for TT.

I mailed this guy details on Atari Sweden, but this part is meaningful for
everybody:

The only differences between Swedish TOS and English TOS are the keyboard
mapping and the text in the Desktop.  The underlying code is all the same. 
If the problems have to do with keyboard mapping or text, then a different
country could make a difference, but if the problems are anywhere else, you
should describe them so we can decide if they're TOS bugs.  It may be that
what you've encountered is already fixed.  There have been updates to TT
TOS; the current release is 3.05.


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


From: Allan Pratt
Subject: Re: Weird TT hard disk thingy
Date: 3 May 91 18:09:56 GMT

boyd@nu.cs.fsu.edu (Mickey Boyd) writes:
>The DMA port on the back of the TT 
>is handled differently than that on the various ST's, and this could cause
>an hard drive set up (and working) on an ST to fail (with very little 
>explanation from the Atari HD software).   

A phrase like "The DMA port on the back of the TT" encourages
misunderstanding: there are TWO DMA ports on the back of the TT; one is
ACSI and one is SCSI, and you should make that distinction explicit when
you talk about the TT.

In any case, you are mistaken.  A working setup on an ST will work fine on
a TT.  What part of this conversation makes you think it won't?  The only
oddity will be that SCSI drives (like the internal one), if present, will
have their partitions appear first in the sequence of drive letters.  But
if you have a working chain of drives coming out of your ST, and you unplug
the end of the chain from the ST and plug it into the TT, all those drives
will be accessible and will work just fine.


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


From: Allan Pratt
Subject: Re: TT questions
Date: 3 May 91 18:12:48 GMT

D.C.Halliday@newcastle.ac.uk (Dave Halliday) writes:
>Is it realy true that the TT can only run Unix OR TOS but not both. I do not
>meen that they should run Unix and TOS at the same time but be bootable
>between the two different OS's.

No, it is not true.  Any production TT can be booted in either TOS or UNIX.
UNIX, of course, is not yet a product from Atari, but there is no distinction
between a TOS TT and a UNIX TT; it's all in the software.


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


From: Allan Pratt
Subject: Re: Dfree() void?
Date: 2 May 91 18:03:34 GMT

ONM07@DMSWWU1A.BITNET (Julian F. Reschke) writes:
>The GEMDOS funtion Dfree() is documented to be void ('GEMDOS Reference
>Manual'). In practice, it SEEMS to return useful return codes (like BIOS
>error codes).

The manual is wrong, in more places than one.  Yes, Dfree() is not void.
Never has been.


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


From: Allan Pratt
Subject: Re: Which monitors can use TT high res?
Date: 8 May 91 20:07:07 GMT

>In article <1991May6.010100.9329@noose.ecn.purdue.edu> yegerleh@vivaldi.ecn.purdue.edu (James D Yegerlehner) writes:
>>I know that the TT has a really high-res mode (more than a 1200 by
>>600? pixels), and I know that Atari is (or will be) selling a

rcb@netcom.COM (Roy Bixler) writes:
>I read it was 1200x960.
>Along the same lines, does Atari sell a monitor that can take
>advantage of the 1200x960 monochrome and the 640x400 color mode?  If
>there's no Atari monitor which does this, are there any multi-sync
>alternatives?

Enough of this misinformation.  

TT high rez is 1280x960, an industry standard.  This resolution requires a
monitor along the lines of the Moniterm Viking.  (I don't know if that
particular model actually works, but you need something like it.) Atari
either sells or is planning to sell such a monitor.  I don't have any real
information on our marketing plans in that direction: I just don't know.

This type of monitor can't show any of the other TT or ST resolutions, and
no Atari monitor which can show the other resolutions of the TT can show TT
High.  In that respect this is like the ST:

        ST
                REZ     X,Y,COLORS      MONITOR REQUIRED
                ST LOW  320,200,16      ST color monitor
                ST MED  640,200,4       ST color monitor
                ST HIGH 640,400,bw      ST mono monitor

        TT
                REZ     X,Y,COLORS      MONITOR REQUIRED
                (all ST modes above)    TT color monitor
                TT LOW  320,480,256     TT color monitor
                TT MED  640,480,16      TT color monitor
                TT HIGH 1280,960,bw     high-rez monitor

I am speaking only for monitors that Atari sells and uses.  I guess there
are monitors which you can hook up to ST's and see all the ST modes.  There
may be monitors that can show all six resolutions of the TT.  I suspect
such a monitor would be hellishly expensive -- moreso than the 1280x960
monitor, which is not cheap.

Another note: ST HIGH on the TT is actually a color mode: you can choose
any two colors, not just black and white.


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


From: Allan Pratt
Subject: Re: TOS filing system for MiNT
Date: 15 May 91 16:51:12 GMT

dpg@cs.nott.ac.uk (Dave Gymer) writes:
>I'm about to start work on an MeSsy-DOS filing system for MiNT, and would
>appreciate some advice about the way it should handle filenames.

Before you "start work" please check to see if TOS's and MiNT's own
filesystem isn't what you need.  They *are* MSDOS compatible.  You can
take TOS disks and use them on PC's.

Well, that's not quite true.  They have to be formatted by a program which
does an MS-DOS compatible format.  The difference is a couple of bytes at
the beginning of the boot sector.  Original TOS didn't set that up the way
MSDOS needed.  New TOSes (1.4 and greater) do.  Other people's formatters,
like DoubleClick, let you select this as an option.  There is no difference
at all in the data part of the disk, only a couple of bytes in the first
sector which we ignore and they use.

Sometimes you can format a disk on a PC and use it on an ST.  You can
certainly READ the disk on the ST.  You can't WRITE it unless the disk was
formatted with two FATs.  Some newer MSDOSes think they're doing you a
favor by writing just one FAT.  If you have one of those, use the option to
FORMAT which says, "Put two FATs on the disk."

Aside from these details of formatting (which are not minor), the TOS
and MSDOS filesystems are identical, files, subdirectories, and all.


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


From: Allan Pratt
Subject: Re: GCC compile error
Date: 16 May 91 20:46:26 GMT

wolfram@akela.informatik.rwth-aachen.de (Wolfram Roesler) writes:
>I had that problem too. It seems that gcc had not fully been ported from
>Unix, so some filespecs still use slashes.
>However, the slashes arent really the problem since TOS can deal with 
>filenames containing slashes.

This is not the case.  TOS can't deal with filenames containing slashes.
What CAN deal with them is programs compiled with Bammi's GCC libraries (or
the MiNT libraries, which is almost the same thing).

This guy's problem is that drive D: doesn't contain a directory called tmp
in its root.


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


From: Ken Badertscher
Subject: Re: Weird TT hard disk thingy
Date: 16 May 91 19:51:16 GMT

Roger.Sheppard@bbs.actrix.gen.nz writes:

|I don't think you should be rail roaded in what Atari gives you, I
|believe in freedom of choice, and not this dogmatic attitude that Atari
|gives you.

Precisely.  You are free to use whatever hard disk driver software
you desire.  If you want to use the Supra software, buy a Supra drive
and use it.  If you want to use the ICD software, buy an ICD drive
or host adapter, and enjoy yourself.

Likewise, Atari should be free to choose whether or not to follow
a "standard" created by a third party.  Some such standards are hacks,
some are good ideas, some have a core of good ideas with a lot of
extra nonsense that Atari doesn't need in a standard.

The bottom line for us is that it doesn't matter what standard we
decide on, some people will be unhappy with our decisions.  That's
something we live with.  You can't please all the people all the time.
You can't please all Atari users hardly ever <grin>.


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


From: Ken Badertscher
Subject: Re: Force Desktop Res Change?
Date: 16 May 91 19:41:29 GMT

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

|There seems to be no easy way to do this with an AUTO folder program -
|AES overwrites any changes, and so you have to write a TSR that waits
|for AES to come up and then re-vectors trap #2.

Nope.

I don't know where this rumour came from, but it's been flying around
for some time now, and I've run into it about 3 times in the past month,
so it's time to start spreading facts.

Nobody should be touching trap #2 on a res change.  Think about it for
a minute: if trap #2 got taken every res change how could GDOS possibly
work?

Assemble the following, put it in your auto folder, and change res a
couple dozen times.  You'll see that the trap #2 counter in the upper
left corner of the screen keeps on ticking...

; TAKE2.S - count trap #2's, even after res change.

trap2vec    = $88
_v_bas_ad   = $44e

start:
    pea     take2(pc)
    move    #$26,-(sp)
    trap    #14         ; Supexec(take2)
    addq    #6,sp

    clr.w   -(sp)
    move.l  #($100+fin-start),-(sp)
    move.w  #$31,-(sp)
    trap    #1          ; Ptermres(0,size)

take2:
    lea     save2(pc),a0
    move.l  trap2vec,(a0)+
    move.l  a0,trap2vec
    rts
    
save2:
    dc.l    0
do2:
    move.l  _v_bas_ad,a0
    addq.l  #1,(a0)
    move.l  save2(pc),a0
    jmp     (a0)
fin:
    .end


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


From: Ken Badertscher
Subject: Re: Traps on Resolution Change
Date: 16 May 91 20:01:48 GMT

Desk accessories should not steal trap vectors.

This is not to say that lots of DA's (desk accessories should not steal
trap vectors) that are already out there don't take vectors, but (desk
accessories should not steal trap vectors) it really isn't a recommended
thing.

Desk accessories, as we all know, are (desk accessories should not
steal trap vectors)  accessories, side-liners, assistants, and as such
(desk accessories should not steal trap vectors) they don't warrant
the same considerations (desk accessories should not steal trap vectors)
as main-line applications.

As Julian R. (hi, Julian!) has recently pointed out (desk accessories
should not steal trap vectors), things that take vectors really belong
in the AUTO folder.  TSRs should be the ones (desk accessories should
not steal trap vectors) setting up resources like this, and they should
use the Cookie Jar to communicate with other programs.


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


From: Ken Badertscher
Subject: Re: TRAP #2, Form_doit
Date: 16 May 91 20:06:38 GMT

cmedley@wam.umd.edu (Charles Henry Medley) writes:

|Incidentally, I understand that the new Atari Control Panel has hooks into
|the AES for a modified form_do call that doesn't "lock up" the system.  Does
|anyone know if it is legally patching into TRAP #2 or if it is actually a
|new form_do handler in the ROMs?

No hooks, just a library routine that is also available to CPX's, since
they run as little pieces of XControl.


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


From: Allan Pratt
Subject: Re: TT VME Bus
Date: 20 May 91 17:11:08 GMT

baffoni@aludra.usc.edu (Juxtaposer) writes:
>       Is it possible [to make]  an accelerator card that  uses
>the buslines available on the VME/Atari (TT/mega)bus slots?  Like for instance 
>a 68040 board that takes over the machine and delegates the on
>board cpu as an I/O handler ... ?

No, it's not, because the things that can go on the VME bus in the TT can't
be bus masters.  The TT's VME bus is slave-only, meaning the motherboard
can instigate an access to the VME board, but not the other way around. It
is not unreasonable to suppose that future Atari machines may have
full-blown VME where the VME boards can be bus masters, and then you could
do this.

>Dave Small has already shown that it's possible
>for the ST...:)

No, he shows that it's possible to wire a 68030 into the ST.  I don't know
how he tells the 68000 to go to sleep; maybe you have to cut the whole
thing loose, maybe you just have to cut a few traces (like power and
ground :-) to get it out of the circuit.


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


From: Ken Badertscher
Subject: Re: How can I use the 6x6 ROM font?
Date: 20 May 91 18:06:59 GMT

Use vst_point().

Setting the point size to 8 will get you the 6x6 system font,
9 will give you the 8x8 font, 10 the 8x16 font, and 20 the 16x32 font
(if you're running under TOS 2.0x/3.0x).


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


From: Allan Pratt
Subject: Re: Disabling FAT/Directory cache
Date: 28 May 91 19:04:36 GMT

danny@fiction.ms.sub.org (DanielRoedding) writes:

>7103_2622@uwovax.uwo.ca (Eric Smith) writes:

>> Is there a nice way to tell TOS (version 1.4 and higher) *not* to
>> cache a drive? I want to share a drive over a network; clients
>> will see the drive as read-only, but I'd like the server to be able to
>> write to the drive.

>Since you have to write a little device driver, you also have to take care
>of the media change state. If you return 2 all the time at Mediach() calls,
>TOS should not keep old information it it's caches.

If you return 2 on every call, then you could never do anything: 2 means
HAS CHANGED, and all open handles on the drive are closed. Subsequent
accesses with those handles would return EIHNDL (invalid handle).

Even if you return 1 and find that GEMDOS always re-reads the sectors, this
will be REALLY SLOW, because TOS uses Mediach() to validate its cache
buffers, and it happens A LOT in some cases.  Example: for each
Fsfirst/Fsnext call in a directory search, you'll get at least one
Mediach() call.  If you actually had to read the sector over the net for
each call, it would be unbelievably slow.

I don't know a way to cache a drive from outside.  You're better off using
MetaDOS to catch the calls at the filesystem level rather than the BIOS
level.  If a call is destined for a remote filesystem you make it a remote
procedure call at the top level, not the record level.

Eric, aren't you running MiNT?  You already have the capability: just mount
it like you do a Minix filesystem and make remote procedure calls at that
level.  You could even do local caching and make remote calls like, "Are
my cached buffers still valid?" to reduce your net traffic.


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


From: Allan Pratt
Subject: Re: TT VME Bus, and extending it
Date: 28 May 91 19:10:08 GMT

pegram@kira.UUCP (Robert B. Pegram) writes:
>[T]he TT's VME bus is only D(ata)16(bits), A(ddress)24 (one vme
>connector), which is fine for a Mega STE, but you need D32, A32 to
>really handle an 030.  I'm also not completely clear whether VME
>supports Bus mastering properly ...

The VME in a TT and a Mega STe is indeed A24/D16.  In addition, it is
slave-only: the VME board can't be a bus master.  It is not unreasonable
to suppose that a future machine from Atari might have full-sized VME
with A32/D32 and full bus mastership.

I have seen at least one product where you put the TT in a card-cage and
get larger-sized VME connections (6U; the TT only has 3U) but the bus is
still the same.  The only difference is the physical size and shape of the
VME cards you can plug in.  There is lots available in A24/D16, especially
if you aren't limited to 3U (as the TT and Mega STe are), but as I said,
the VME card(s) can't be bus master(s) in the current machines.


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


From: Allan Pratt
Subject: Re: Atari TT
Date: 3 Jun 91 20:20:26 GMT

baffoni@aludra.usc.edu (Juxtaposer) writes:

>   From the discussion on c.s.a.st a while back with Alan Pratt, I believe he
>said that you can only have 4MB _ST_ ram.  You can have 16 MB TTram like you
>said, but that the other 6MB of ram comes from using the VME bus for ram
>expansion.  In fact, the VME ram is supposed to be faster than STram (no 
>sharing it with video, etc.), even though it is slower than TT ram.

No, no, no...  Your picture of memory in a TT and its limits is a little
off.

On the motherboard there are two megabytes of ST RAM.  Period.  No options,
no extra SIMM or DIP sockets, no nothing.

You can buy a 2MB ST RAM add-on card, for a total of 4MB of ST RAM.  There
may one day be an 8MB ST RAM add-on card, resulting in a total of 10MB
of ST RAM.

You can buy a 4MB TT RAM add-on card.  It may be that, with some work, you
can make this address 16MB of TT RAM.  In future (now?) you can buy 16MB of
TT RAM from Atari -- I'm just not sure.

All of these boards are more than just RAM -- they also have memory
controllers which you can't just get off the shelf.

In the TT030, there is one VME slot, but it is not appropriate to put
system expansion RAM there.  The slot is for peripherals, not RAM.  If you
DO put RAM there, you have to tell the OS about it yourself, and it will be
slow: it's not cacheable, it's only 16 bits wide, it's on the VME bus, and
it's not SCSI-accessible (meaning transfers have to be use SCSI-accessible
RAM; this is taken care of in the drivers, but it slows you down).  I've
put memory there to test things, and it is not fun.  Things run
DRAMATICALLY slower from that kind of RAM.

It is not unreasonable to suppose that Atari may, in future, come out with
a machine in the TT family which has full-featured VME, including the
ability to put 32-bit, cacheable, OS-detectable, SCSI-accessible RAM on the
VME bus.  The TT is designed with this in mind, but the actual VME bus in
the TT030 isn't capable of it.  Such RAM would be slower than TT RAM
(mainly because you can't do burst fills on the VME bus) and about the same
speed as ST RAM: faster because it's not shared with video, but slower
because it's on the VME bus.


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


From: Allan Pratt
Subject: Re: Does TT monitor have sound?
Date: 12 Jun 91 18:36:05 GMT

d90-ngp@sm.luth.se (Niklas Grip) writes:
>Is it usual that multisync monitors don't have loudspeakers and
>whatabout the TT?

Yes, it's true that most monitors don't have speakers.  The TT has a
speaker built in.  It also has stereo output jacks on the back so you can
hook it up to an amplifier and speakers, and you can turn off the internal
speaker if you want.  The idea is that the internal speaker can be used for
normal stuff like beeps and bells, but for high-quality digitized sound
you're likely to want to use the stereo outputs.  The digital sound always
goes to the stereo output jacks; you can control whether the PSG sound
(clicks and beeps) also goes there.


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


From: Allan Pratt
Subject: Re: 1024-byte floppy sectors?
Date: 17 Jun 91 20:12:42 GMT

adamd@rhi.hi.is (Adam David) writes:
>TOS uses a BPB to handle various media specifications. The floppy driver /
>filing system must use 1024-byte cluster buffers for the standard format.
>Why should it not be possible with standard TOS to use 1024-byte clusters
>of one sector each? What modifications do I need to make to TOS in order to
>use the larger sectors with it?

>Any thoughts / suggestions welcome.

You are mistaken in your belief that TOS keeps cluster buffers around. It
doesn't.  It keeps SECTOR buffers around.  The floppy BIOS assumes sectors
are 512 bytes long.  GEMDOS does not, and hard-disk partitions larger than
16MB are implemented using large logical sectors (but not large physical
sectors) with appropriate values in the BPB.  To use 1K sectors on floppies
you would have to replace the floppy BIOS completely, and include in your
TSR a routine which replaces GEMDOS's sector buffers with new buffers large
enough to handle the largest sector size in your system.  This is what the
hard disk driver has to do (except that instead of replacing the floppy
BIOS it's installing the hard-disk BIOS).


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


From: Allan Pratt
Subject: Re: TT beginner questions
Date: 18 Jun 91 20:27:44 GMT

friedric@r2d2.fmi.uni-passau.de (Carsten Friedrich) writes:

>Does anyone have some TT documantation, e.g. new tos-routines and 
>       hardware - registers ? If you only have them on paper, i would give
>       you some money for stamps, if you send them to me. (send e-mail for 
>       adress)

These kinds of documentation are available to developers through the Atari.
Call Gail Johnson at (408) 745-2022 for information on becoming a
developer.

>My version of Mint (0.6) does not seem to work with the TT is there a version
> that does ?

The latest one, 0.8, does.  However, there are some problems in exception
handling.  0.7 worked better, but I don't know if the released version of
0.7 had the TT modifications.

>Is there a switch for gcc (my version is 1.39) to use 68030 code, to use the
>       co-processor and the full TT memory ?

Yes, use -m68020 and -m68881 on the GCC command line, and use PRGFLAGS.PRG
(freely copyable, available on GEnie at least) to set the program-load and
malloc bits so your program can see all TT memory.

>I tried to connect my external 5 1/4'' floppy i used with the st to the tt
>       but failed. any ideas why ? (i just pulled the plug out of the st 
>       and into the tt, but the tt couldn't handle it. :( )

Don't know why.  Should have worked.  Do you use a hack program to change
the seek rate, or a program that makes the Floprate() XBIOS call?  In the
former case the program is probably TOS-version-specific, and in the latter
case it should work.


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


From: Allan Pratt
Subject: Re: Mega STe Questions
Date: 21 Jun 91 16:47:58 GMT

>In article <1991Jun19.114741.11944@informatik.uni-erlangen.de>, 
>csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes:

>> The 68881 is optional. The Mega STE's FPU is programmed just like
>> the FPUs available for the standard Mega, so there should be some
>> development packages supporting it.

This is correct.

stigvi@Lise.Unit.NO (Stig Vidar Hovland) writes:

>How is it programmed on a standard Mega? Will programs written for the 
>TT and 68882 run correctly on a Mega STE and 68881?

No.  The 68030 communicates with the FPU as a coprocessor.  You use
instructions like "FSIN fp0,fp1" and the CPU communicates directly with the
coprocessor, telling it to take the sine of FP0 and put the answer in FP1.
(FP0 and FP1 are floating-point data registers in the FPU.)  The 68000 does
not have this ability.  With a 68000 the FPU is a peripheral, like the
sound chip or floppy-disk controller: it takes many regular 68000
instructions to read and write I/O ports on the chip to get it to do what
you want.  You have to do it "by hand" instead of having the CPU do it for
you.  Thus, it is slower and your program is larger than it would be using
68030 FPU instructions.

What Claus is saying is that there is an FPU peripheral that plugs into the
Mega ST (called the SFP004), and there is an FPU that comes with the Mega
STe, and they interface the same way.  They both interface in the
"peripheral" way, because that's the only way the 68000 can handle.  This
means that a program (or library) that runs on a Mega using the SFP004 will
run on a Mega STe and use its built-in FPU.  In the TT the FPU interfaces
in the "coprocessor" way, so these programs won't work.


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

From: Allan Pratt
Subject: Re: 1024-byte floppy sectors?
Date: 24 Jun 91 18:18:12 GMT

Roger.Sheppard@actrix.gen.nz (Roger Sheppard) writes:
>> ...and hard-disk partitions larger than
>> 16MB are implemented using large logical sectors...
>  ^^^^
>Correct me if I am wrong, but should this not read 32MB ?, I thought
>that this was a typo that caused this problem and was fixed in TOS 1.4

It may or may not have been fixed, but because even people with TOS 1.2 and
(gasp!) TOS 1.0 want to be able to use large partitions, HDX goes to BGM at
16MB for maximum compatibility.  Otherwise you could take a 31MB, non-BGM
partitioned disk to a machine running TOS 1.2 and not be able to get at
the files.


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


From: Allan Pratt
Subject: Re: Writing to read-only files
Date: 8 Jul 91 19:00:16 GMT

danny@fiction.ms.sub.org (Daniel Roedding) writes:

>ue@nathan.ruhr.de (Udo Erdelhoff) writes:

>> In <91186.104812ZVD007@DMSWWU1C.BITNET>, U.Kuehn writes:

>> >Yesterday, I discovered that maccel3, the mouse-accelerator of atari,
>> >which saves the configuration in its program-file, uses Fopen with the
>> >mode readonly to open that file and writes then the data via Fwrite into
>> >it. Is that the correct way???? And why is there no error returned by GemDos?
>> Nope, that's not the correct way. GemDos doesn't care about it and fixes this
>> internally, KAOS won't accept it... 

>Some networks also can be crashed with this. They just check for read/write
>permissions when *opening* the file. If you have read-only access, open the
>file for reading (correct so far) and write something into it, some programs
>(PAMs Net... :-) won't recognize it.

>Even worse: You can manipulate files marked as read-only if you just open
>'em for reading and then write...

>BTW: Are you allowed to change the date/time stamp with Fdatime() when
>you open a file just for reading? GEMDOS allows it, but is it logically
>correct?

>Daniel

Sigh.  As everybody knows by now, GEMDOS does not check the mode you opened
the file in when you try to write to it.  You can read from a file you've
opened for write-only, too.  This is a bug, but it's the kind of bug we
can't really fix.  Perfectly reasonable programs and programmers have made
this mistake, and their programs work because GEMDOS has never checked
this.  Fixing this bug means these working programs will break.  I don't
think the win is bigger than the lose.  Naturally, nobody should rely on
this bug on purpose.

In the case of networking, where you implement access rights more strictly
than GEMDOS does inherently, I think checking the open mode before allowing
a read or write is perfectly reasonable.  I am surprised that KAOS to
"fixes" this bug because it can make an otherwise-OK program "KAOS
incompatible."  I would be interested to know how many programs actually
rely on this bug, and break under KAOS for that reason.

(Of course, KAOS isn't sanctioned by Atari in any way, and my understanding
is that it might be illegal; it certainly is if it's a hacked version of
TOS, as opposed to a complete rewrite without any Atari code or influence.)


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


From: Allan Pratt
Subject: Re: XCONTROL MODEM ACC BUG
Date: 8 Jul 91 19:06:17 GMT

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

>[neil@cs.hw.ac.uk (Neil Forsyth) writes ... ]

> > I was quite surprised. I have since been told of TOS14FX2 (Atari US) and 
> > TOS14FX5 (Germany). Both of which I will try ASAP. 

>Since it's a very short file and *lots* of people will need it, here
>is TOS14FX2 (the official Atari Corp. version). The doc file
>specifically mentions the problem you had with XCONTROL.ACC.

Thank you for posting this, Steve.  I would have done it, but I have been
on vacation.  I approve of (re-)posting small, freely-copyable, important
Atari fixes to the net when there is a demand like this.

If you ever wonder if something is freely copyable, the best place to check
is GEnie: if it was uploaded to the Atari Roundtable (*not* the Atari
Developer's Roundtable) by somebody like Mike Fulton or ATARIDEV (J.
Patton) or Bill Rehbock, you can reliably say that it's official and freely
copyable.  XCONTROL itself falls in this category now, and it's available
on Atari Archive.  

(The A.A. people asked me about another XCONTROL version, ostensibly from
Atari France, and I had to say that it should not be made available: even
if XCONTROL is freely available, and even if it was the genuine article and
not an older rev or something, this other archive was probably just a
collection of stuff and not "the official release archive."  It makes a
difference.)


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


From: Allan Pratt
Subject: Re: Writing to read-only files
Date: 10 Jul 91 20:17:16 GMT

>In article <2978@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>>Fixing this bug means these working programs will break.  I don't
>>think the win is bigger than the lose.  Naturally, nobody should rely on
>>this bug on purpose.
>>

boblu@tekgen.BV.TEK.COM (Robert Luneski) writes:
>This is utter bulsh*t rationalism.

Actually, I think you meant "a rationalization," not "rationalism." I would
say that it is EXCELLENT rationalism: it is rational for you to to be
conservative in what you demand of the machine and OS, and for me to be
liberal in what the machine will allow.

>IMHO any programmer who opens a file Read-Only
>and then writes to it deserves to have the program break.

If it were your program, or a program you use and rely on, you might not
feel that way.  I am reluctant to fix this because I don't know what
programs will break.  It could be just a few little hacks, and it could be
some big title which would cause a huge uproar.  Who can tell?


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


From: Allan Pratt
Subject: Re: TT memory allocation
Date: 9 Jul 91 17:04:46 GMT

martin@minster.york.ac.uk writes:
>OK so far. My problem is that I can't find anywhere a description of
>*which bits* in the program header contain this information! [about
>allowing program load and malloc to come from TT RAM]

I think it's there somewhere, but it's easier to answer this than find
it myself and tell you where to look.

One of the previously-unused longwords in the program header has been
assigned a meaning as of TOS 1.4.  The least significant bit of this
longword is a flag which, when set, says "don't bother to clear the whole
TPA, just my declared BSS."  The next-least significant bit declares that
the program may be loaded into alternative RAM (that is, non-ST RAM) and
the next bit declares that alternative RAM is eligible to satisfy Malloc
calls.  The high byte of the longword has another meaning (too arcane to go
into here) and the other bits are reserved.

This longword is at offset $16 from the start of the program file. Thus,
the program header looks like this:

    struct prg_header {
	short magic;			    /* always $601a */
	long tsize, dsize, bsize, ssize;    /* segment sizes */
	long unused;			    /* unused */
	long prgflags;			    /* described above */
	short absflag;			    /* if nonzero then no fixups */
    }

I think program appeared recently in c.[sb].a.st which lets you set the
bits in prgflags.


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


From: Ken Badertscher
Subject: Re: Writing to read-only files
Date: 14 Jul 91 04:41:44 GMT

Yep, sure enough, MACCEL3 updates its configuration by opening the
file in read-only mode.  Oops.  50 lashes with a wet noodle for me.

I really do need to fix that (and other minor MACCEL glitches),
one of these days when someone sends me a case of round tuits.


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


From: Ken Badertscher
Subject: Re: Determining available font sizes
Date: 14 Jul 91 04:18:30 GMT

tolk@opal.cs.tu-berlin.de (Robert Tolksdorf) writes:

|... the idea
|is that vst_point yields the next available font-size smaller-equal i.
|But this does not work, when scalable fonts will be available.

Checking font sizes still works with FSMGDOS, and it is still important.
The effects buffer used for algorithmic text effects (such as outline,
bolding, etc.) is based on the largest font size in the FSMGDOS configuration
file (EXTEND.SYS).  A program should not use algorithmic special effects
for point sizes larger than the largest returned by vst_point().

The important thing is that it's not necessary to check *all* point sizes
available under FSMGDOS, for obvious reasons.  But it still works, for
compatibility with non-FSM-aware programs, and it's still important to
find out the largest point size you can get from vst_point().


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


From: Allan Pratt
Subject: Re: Writing to read-only files
Date: 15 Jul 91 17:51:01 GMT

>In article <2986@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>> ... I am reluctant to fix this because I don't know what
>>programs will break.  It could be just a few little hacks, and it could be
>>some big title which would cause a huge uproar.  Who can tell?

neil@cs.hw.ac.uk (Neil Forsyth) writes:
>Oh come on Allan! Who in their right mind is gonna create a stink when you
>break a program because you fixed a bug? If you change a documented practice
>you'd deserve some blasting (eg. resvector).

I guess you weren't around on GEnie when I suggested that I fix a bug in
the BIOS trap dispatcher HUGE stink because it would break those programs
that relied on getting a pointer to an internal table in a certain
register.  Apparently this is a favorite trick of the cute-little-hack
crowd, and they were all up in arms that I would take this away.  It's not
documented, and it *is* documented that I am *not* required to return
anything useful or consistent in garbage registers d1-d2/a0-a2.

So people, right mind or no, DO raise hell when seemingly-innocuous changes
are made or suggested.  My logic is not as off-the-wall as you seem to
think: it's based on experience.

Another subject in this thread relates to keeping track of Malloc'ed blocks
using a fixed-sized pool of memory descriptors.  Again, changing this
creates all kinds of hassle -- much more than disallowing writes to
read-only handles.  Having successive Malloc's no longer contiguous is only
part of the problem.  The other, bigger part is that many programs access
memory outside what they own -- a few bytes before or after, or memory
they've just released with Mshrink.  Currently, those places are relatively
safe: if you just used Mshrink to release memory, then it's not used by
anyone.  If you run off the top of a block you've Malloc'ed, it's likely
that either the next few bytes are free, or they're owned by you (via a
different Malloc).  So at in the likely case things will work, or you will
mess up your own data and bomb.  But you won't corrupt the whole memory
architecture of the system. If you write over the OS's memory descriptors,
though, you get in BIG trouble.  Without validation, the result is really
wierd behavior. With validation, the result is a panic ("Memory data
structure corrupted").

Memory protection is a subject of current study for the TT, but not all the
world's a TT (yet).


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


From: Ken Badertscher
Subject: Re: TT compatability...
Date: 16 Jul 91 17:00:26 GMT

ford@tardis.computer-science.edinburgh.ac.uk writes:
(several programs tried out on the TT didn't work, most were games)

As far as TT compatibility is concerned, games are risky at best.
Disk-based copy protected games are almost certain to fail.  The
main reason for this is the use of timing instruction loops.
As you mentioned, some games go too fast.  The same applies
to the tricky timing they try to (wow, alliteration) make copy
protection work.

Something else you could try for non-bootload software is running
24BIT.PRG in your auto folder.  This won't help for software that
relies on CPU instruction timing for timers, or for software that
installs its own exception handlers, but it will let you run programs
that aren't 32-bit clean.  GFA Basic programs compiled using
all but the more recent versions of their compiler have this problem.

|PS.	Should the TTs internal speaker sound as if it's blown?

No, but it does sound quite tinny.  It's quite a low-fidelity speaker.
Try plugging your TT into your home stereo with some RCA jack cables.  Whee!


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


From: Allan Pratt
Subject: Re: TT compatability...
Date: 16 Jul 91 20:31:46 GMT

ford@tardis.computer-science.edinburgh.ac.uk writes:
>Spectre GCR	Well... I've got version 3.0, but I canne get it to work.. it
>			locks up (as does GCRTEST) at the first try at
>			accessing the floppies in GCR mode.

Mine works.  Don't know what the problem might be.

>MiNT 0.8	Works fine (except for the exception handling).

Known bug, I fixed it & sent Eric the fix.

>GNU CC 1.37.1	Everything works except the preprocessor, which doesn't parse
>			#if blocks properly.

Mine works -- are you SURE this is a TT/ST difference?  GCC from Bammi has
always been pretty robust, and certainly has always worked fine on the TT.
It compiles itself, which is a pretty thorough test.


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


From: Ken Badertscher
Subject: Re: XCONTROL & Mouse Accel
Date: 16 Jul 91 17:10:22 GMT

fischer-michael@cs.yale.edu (Michael Fischer) writes:

|I changed my boot sequence so that "maccel3.prg" is the LAST thing
|loaded from the auto folder and now everything seems to work fine.  I
|don't know which program in my boot sequence was causing the problem.
|Does xcontrol locate maccel3 using the cookie jar...?

Yes, the Mouse Accelerator CPX finds MACCEL3 by looking for the cookie
installed by MACCEL3.PRG.  If the CPX is unable to find the TSR, then
something in your boot sequence is probably screwing up the cookie jar --
a *dangerous* thing in STE's & TT's.  MACCEL3 should be able to run
anywhere in the auto folder, in fact you can even run and install it
from the desktop.

Someone mentioned that MACCEL3 had problems with DC Showit?  Hmm...
MACCEL3 is very compatible with a lot of stuff, I'm curious what the
conflict with Showit is...


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


From: Ken Badertscher
Subject: MACCEL3 fea...er, bugs
Date: 16 Jul 91 16:29:41 GMT

Wot, you got something against $AA006E?  Well, it is a REALLY silly
cookie value (and in fact, intentionally non-printing).  It works
much better hex-dumped, you see, if you squint at your monitor like
I do, the AA sort of looks like an M, and the 6E sort of looks like
"SE", which gives you the word "MOOSE" in a hex dump.  Truthfully,
MACCEL3 is a MOOSE accelerator!

  'macc'?  Naah, I should use 'Maus' :)  And I should have used
'Maus' for the CPX, too!


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


From: Allan Pratt
Subject: Re: floppyBIOS FAT handling.
Date: 22 Jul 91 18:51:33 GMT

>In article <rsm426@fiction>, danny@fiction.ms.sub.org (Daniel Roedding) says:
>>Oops ... IT DOESN'T CHECK THE BFLAGS FIELD IN THE BOOT SECTOR???? So what's
>>this flag good for, if even GEMDOS doesn't care about it?
>>
>>Daniel

ONM07@DMSWWU1A.BITNET writes:
>Sorry, there is no such flag in the boot sector. It's only in a BPB.

MSDOS draws the line between 12-bit and 16-bit FATS at the point where a
12-bit FAT cannot work: 4096 clusters.  I think.  GEMDOS' floppy BIOS is
hard-coded to report 12-bit FATs, on the assumption that it won't be called
upon to deal with any 2.88MB floppies with one-sector clusters.

You should be asking, "IT DOESN'T CHECK THE NUMBER-OF-FATS FIELD IN THE
BOOT SECTOR??"  That's a far more serious problem.  You had better not try
writing to a PC-formatted disk that only has one FAT, as some do.  The
number of FATs is in the boot sector but it's not passed to GEMDOS in the
BPB: GEMDOS is hard-coded for two FATs.


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


From: Allan Pratt
Subject: Re: TT printing
Date: 19 Aug 91 17:59:17 GMT

glenn@ludwig.sharebase.com (Glenn Linderman) writes:

>So, I finally got my TT030!  My current programming project gets loaded on,
>and runs slower than on my Mega...until I rework the memory allocation to
>fast RAM, and then it generates a complete screen of graphics before the Mega
>starts (given simultaneous commands) to even update the screen.

Are all the same things running on both machines?  You should run CACHE080
or so, FOLDR100 or so, and you should set the "fast load" bits of your
programs -- there is a TSR that does this for ST's, but starting with TOS
1.4 it's not necessary.  This will all speed things up independent of which
kind of RAM the program loads into.  If you have an ACSI hard disk then you
should NOT set the "load in TT RAM" bit of CACHE080.PRG, because if you do
accesses to the ACSI hard disk will be slightly slower.

>All is wonderful...until I try to print.
>Even from the Desktop, double-clicking on a text file, it says printing that
>file, delays proportionally to the length of the file, and quits.
>Printers are Epson GQ3500, Toshiba 341.
>Desktop printer configuration is to the parallel port.  Any clues?

Are you sure it's configured for the parallel port?  Are you running the
Control Panel and the Printer CPX?  Try NOT running the Printer CPX.  If
the delay is truly proportional to the length of the file then SOMETHING is
happening -- if you have no printer connected it should delay for 60sec and
then say "Your output device is not receiving data."

Parallel printers work fine here.  The parallel port on the ST and TT is
the same, but there is a known problem with some printers: they have
pull-up resistors on the parallel port lines which are either too strong or
too wimpy (I forget which) and cause more current to flow than the Atari
parallel port can manage. The fact that your printer works on an ST argues
that there might be something else wrong; take your TT back to the dealer
and see if he can make it work, repair it, or replace it (it should still
be under warranty, right?).

>and apparently jiggling the power cord caused either a short
>or an open

Well, yes, jiggling ANY power cord which plugs into a device can cause it
to lose contact.

>...and it wouldn't turn on for several minutes after...

I can't explain this part of what you say -- there is no reason for it to
refuse to turn on for a while, then go ahead and turn on.

>Glenn Linderman   glenn@sharebase.com   408-378-7575 x2366

I hope you'll get back to me on this stuff: I won't deny the possibilty of
software or hardware quirks that result in the behavior you're seeing, but
this is the first we've heard of them.


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


From: Ken Badertscher
Subject: Tos 2.0x coming to an STf(m) near you... NOT!
Date: 21 Aug 91 15:08:20 GMT

mike@abekrd.co.uk (Mike Quinn) writes:

|[ST User...]
|said that Tos 2.0 would be made available for owners of old Sts on 512K roms.

 TOS 2.0 won't fit in 192K, so it can't go in ST's or Megas.
 It could be put in an STe, but I don't know about any plans to sell ROM
upgrades for STe's.  That doesn't mean it won't ever happen, just that
_I_ haven't heard any marketing rumbles in that direction.  I prefer to
stay away from marketing rumbles. ;)

 Oh, and TOS 2.0x is the version that comes in the Mega STe.  Never fear,
though, if ROM upgrades are ever made available for the 1040 STe, they'll
probably be made available to Mega STe owners, too.  (Can you say "Atari
fixed some bugs"?  Sure you can.)


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

From: Allan Pratt
Subject: versions that need POOLFIX3 [was Re: Gulam problems]
Date: 27 Aug 91 18:14:11 GMT

>In article <3030@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) says:
>>(and also 2.01 and 3.01), and that bug will EASILY be triggered by the

ONM07@DMSWWU1A.BITNET writes:
>REALLY? I thought this one was fixed in GEMDOS 0.15 (Sversion(): 0x1500)???

My mistake.  The bug is in TOS 1.4 and 1.06 and 1.62 but not in any TT TOS
or Mega STe TOS.  The Sversion() value for the first fixed version is 0x1700,
which is to say Version 0.17.


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

From: Ken Badertscher
Subject: Re: Tos 2.0x coming to an STf(m) near you...
Date: 28 Aug 91 15:26:33 GMT

neil@cs.hw.ac.uk (Neil Forsyth) writes:

|Well the word is that there is some hardware hacking going on too. We'll know
|more next week hopefully when they let the cat out of the bag.

Yep, as soon as I heard about the upgrade board shown in Dusseldorf,
I started choking on that last post... and lemme tell you, regurgitated
Usenet posts are none too tasty. :)

Looks like ST & Mega owners win after all... with this slick little
upgrade, you *will* be able to plug TOS 2.0x ROMs into those machines.
The upgrade is reportedly not for the faint of heart, though... it does
involve running some wires and burning your fingers with a soldering iron.


|What is your opinion of patched versions of TOS 2.0x? I think we already know.

'Nuff said.


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


From: Ken Badertscher
Subject: Re: GEMDOS and AES questions
Date: 29 Aug 91 18:09:37 GMT

avgroeni@cs.ruu.nl (Annius Groenink) writes:

|1. It seems to me that all OTHER text editors load files about
|   twice as fast as my program. I use one straight Fread().

One straight Fread() is the fastest way you can load a file.
It is possible that the slowdown you see is due to buffer
setup you might be doing after you have read the file.

|2. Does the ATARI AES send ANY WM_NEWTOP messages?

No.


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


From: Ken Badertscher
Subject: Re: Official weird thing: wandering menu bar
Date: 28 Aug 91 15:02:20 GMT

bboychuk@sdcc13.ucsd.edu (The Majestic Llama) writes:

|In a program I'm working on, after a re-compile, the menu bar [...]
|is now showing up about three text lines down and half a dozen
|spaces over from the left.

This is probably due to a bug in the Atari RCS.  The things that seem
to trigger this bug are moving menu items around followed by quitting
the RCS and then saving the resource from the exit alert box, rather
than saving first, then quitting.  Another thing that might cause this
is trying to edit a "menu" type tree as a dialog or a panel.

This used to happen to me occasionally when I would edit menus, until
I got into the habit of always explicitly saving the resource before
exiting the RCS.

To make your resource usable again, read it into a binary file editor.
Look at the second word in the resource file; that is the offset to the
object data.  Go to that offset in the file (you'll probably see that
the strings in your resource come before the objects), and find the
root of your menu tree.  If your menu tree is the first tree in the
resource, you'll be patching the first object.  If you found the menu
tree, the bytes at that location will look like:

FF FF 00 01 00 0x 00 19 00 00 00 00 00 00 00 00
^^^^^ ^^^^^ ^^^^^ ^^^^^ ^^^^^ ^^^^^ ^^^^^^^^^^^
next  head  tail  type  flags state    spec

ob_tail will equal the number of titles in your menu, and the ob_type
of a menu ROOT object is always G_IBOX (25, or 0x19).

Following those 16 bytes is the rectangle of the IBOX which is the root
of your menu.  The first four bytes of that rectangle (the ob_x and ob_y)
should be 0.  In your resource they aren't, because the RCS corrupted
them, which is why your menu is showing up in the middle of the screen.
Set those 4 bytes (the ob_x and ob_y) to 0 and save the file back out.

If you have Allan Pratt's DB (Release 3), you can use the following
commands to accomplish the above:

:read foo.rsc
Done, start=<rwstart>, size=<rwsize>
:`t0 = `rwstart + wpeek(`rwstart + 2)
:dw `t0[14]
<addr>: FFFF 0001 000x 0019   0000 0000 0000 0000
<addr>: junk junk
:sl`t0+10 0
:write foo.rsc
Overwrite existing file foo.rsc? y
Wrote foo.rsc, start=<rwstart>, size=<rwsize>

The next time you run your program, the menu bar should show up in the
usual place.  Remember... you shouldn't have this problem if you always
remember to save the resource file out before quitting the RCS, and
never change the type of a MENU tree to dialog or panel.


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


From: Allan Pratt
Subject: Re: Official weird thing: wandering menu bar
Date: 28 Aug 91 18:43:28 GMT

bboychuk@sdcc13.ucsd.edu (The Majestic Llama) writes:
>In a program I'm working on, after a re-compile, the menu bar
>decided that it wanted to stop appearing at the top of the screen
>and is now showing up about three text lines down and half a dozen
>spaces over from the left.

I had this happen to me, and people here said it was a problem in the
resource file, introduced by some versions of RCS (Atari's Resource
Construction Set).  Unfortunately, once this happens to your resource file
you can't un-do it.  I'm told it comes from saving the resource from the
"Abandon / Save / Cancel" box that comes up when you select "Quit" or
"Close" from the top level after you've changed the resource.  It doesn't
happen if you always save using the "Save" menu item, then use "Quit" or
"Close" to get out.

Like I said, once it's happened to your resource file it won't un-happen
unless you actually edit the file on disk.  Since I don't know exactly what
happened or what resource files and menu bars look like, I can't help you
there.  Go back to a backup version of your resource file.  (What?  You
don't keep old versions of important files under development in case stuff
like this happens?  Sorry!)

DISCLAIMER: I have had this happen to me and I've told you what the people
here told me.  I do not know what version(s) of RCS this affects, I don't
know whether or not it's been fixed, and I don't know whether or not it
will be.  Not my department.  I'm trying to be helpful here.


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


From: Allan Pratt
Subject: Re: ST memory allocation
Date: 4 Sep 91 20:43:25 GMT

A variable-size RAMdisk basically Can't Be Done under TOS from outside
GEMDOS, for exactly the reasons you've discovered: you can't go around
allocating and freeing memory from inside a BIOS call or interrupt.

There's another problem: just allocating memory to your RAMdisk when
somebody copies a file there and deleting memory when they remove it won't
do the job, because this will fragment your RAM hopelessly and nothing will
be able to run.  You can ameliorate this by reshuffling memory to compact
your RAMdisk when you can, but that is a lot of work.  And you STILL can't
do Malloc's from inside BIOS, so this complication is academic.

Writing your own Malloc and Mfree is not the answer, because GEMDOS calls
its versions directly, not via trap #1, when it allocates memory for Pexec.
You'd have to replace Pexec, too.  If it sounds like you're going to have
to replace bloody great chunks of OS to do what you want to do, it's time
to think that maybe you should scrap the project and start another one.


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


From: Allan Pratt
Subject: Re: Conclusions: How do I stop Control-C?
Date: 5 Sep 91 21:15:31 GMT

mforget@ersys.edmonton.ab.ca (Michel Forget) writes:
>2.  Use getch() and putch() to do the input and output, and use cfg_ch() 
>to modify the functions to use the BIOS calls mentioned above.  This 
>would be more portable than the above method, ...

I disagree.  It assumes that everybody else who uses your source code has
the same library that you have.  Even if it's popular & widespread (like
MWC or something) it's still not portable.

There's a third alternative: use Crawio(c) for output and Crawcin() for
input.  These are GEMDOS functions, not BIOS functions, and as such are
redirectable and other stuff.  The redirection doesn't actually work before
TOS 1.4 for some of the single-character I/O calls, but that's Yet Another
Good Reason To Upgrade.


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


From: Allan Pratt
Subject: Re: ST memory allocation
Date: 5 Sep 91 21:24:20 GMT

ersmith@ria.ccs.uwo.ca (Eric Smith) writes:
>So perhaps what you should do instead (and it's a *much* cleaner
>solution than fiddling with GEMDOS' allocated memory buffers) is to
>catch the ramdisk calls at a higher level, i.e. at the trap #1 level
>instead of trap #13.

You call that cleaner?!  Eric, I'll assume you had some bad drugs this
morning and forgive you; you don't usually make howlers like this.

It is VERY hard to tell if a GEMDOS call is destined for a given
filesystem.  You have to keep track of all handles to decide which ones are
open on files of yours, including stdin and stdout because of redirection.
This is a COMPLETE non-solution as far as this guy's ramdisk is concerned.

Furthermore and most obviously, DON'T MUCK WITH GEMDOS.  It's almost ALWAYS
a bad idea.  If you have to steal Trap #1 then you've probably got some
serious organizational problems with your program, or else you're just
doing something Evil and Wrong.  The only things that steal trap #1 that I
can approve of are OSes in themselves: MiNT and MetaDOS and the like. And
they HAVE to.


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


From: Allan Pratt
Subject: Poolfix not needed for TOS 1.62 [was Re: Gulam problems]
Date: 9 Sep 91 19:17:58 GMT

Roger W. Sheppard, Roger.Sheppard@bbs.actrix.gen.nz writes:
>> That was the reason that I posted my Arcticle in the First place,
>> Atari will not state if TOS 1.62 needs Poolfix, I would like a clear
>> statement from Atari on this..


ken@isgtec.uucp (Ken Newman) writes:
>I asked Bob Brodie a similar question on Compuserve a while ago, coming
>at it from a different angle, and got a fairly clear reply. I asked what
>the differences were between TOS 1.60 and 1.62, and he stated that there
>were exactly two differences:
>
>	1) fix for the DESKTOP.INF/low-res boot problem (formerly fixed
>       by STEFIX.PRG)
>	2) fix for the memory pool problem (formerly fixed by POOLFIX3.PRG)

This is correct.


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


From: Ken Badertscher
Subject: Re: Mouse click delay hell!
Date: 12 Sep 91 02:25:04 GMT

rossin@hpfctgr.HP.COM (Ted Rossin) writes:

|When I try to detect a mouse button down event in a GEM application,
|event_multi does not return the event to my code until after the double-click
|time out period.

If you ever ask for double click events, you'll wait for single click
events in ROM TOS and Mega TOS.  Unless I misremember, this bug was
fixed in TOS 1.4, certainly by TOS 1.6.  If you have Easy Draw you'll
notice that its response to clicks that bring up the menu are much
quicker.

 YARTU!


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


From: Allan Pratt
Subject: Re: I/O address space
Date: 26 Sep 91 02:08:05 GMT

herzling@rhrk.uni-kl.de (Alexander Herzlinger [Informatik]) writes:
>That's not true, the standard registers are physicaly located at
>0x00FF.... _NOT_ at 0xFFFF.... !!!!!

That's not true.  The standard addresses are physically located at BOTH
0x00FF AND 0xFFFF.  I think you should probably think twice before
correcting somebody who has "atari" in his return address.  It leads to
needless confusion and contradiction.

Yes, the PMMU is used to map addresses, because of a bug in the 68030's
cache-inhibit logic, and yes, the page tables route both $FFxxxxxx and
$00xxxxxx to $00xxxxxx, but that doesn't make you right.  It turns out that
it saves page table space, that's all.


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


From: Allan Pratt
Subject: Re: GEMDOS File Functions and the STe
Date: 8 Oct 91 16:50:08 GMT

mlake@irscscm.UUCP (Marshall Lake) writes:

>Is anyone aware of any undocumented changes with GEMDOS file functions
>on an STe from that on an ST?  I'm thinking specifically of Fopen.

Nothing changed.  TOS 1.4 and TOS 1.62 (STe TOS) have the same GEMDOS, save
for the fix to the bug that POOLFIX fixes -- that bug was in TOS 1.4 and
TOS 1.06 but not TOS 1.62.  Differences in behavior can come from running
or not running FOLDRxxx.PRG; differences in speed from running or not
running CACHExxx.PRG, but a given configuration of these two programs
should run identically whether you're running TOS 1.4 plus POOLFIX or 
TOS 1.62.


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


From: Allan Pratt
Subject: Re: Malloc'ing, what strategy to use?
Date: 8 Oct 91 16:58:11 GMT

r0mill01@ULKYVX.BITNET (Robert Delius Royar) writes:

>It's also safer to Malloc in chunks divisible (no remainder) by 512 bytes.

Where did this come from?  There is NOTHING in ANY piece of code that cares
how much you Malloc, as long as it's more than zero bytes.  Your request gets
rounded up to an even number of bytes (currently; this may become "multiple of
four bytes" in the future), but that's it.

On the subject of Malloc in general: I like what somebody (Steve
Yelvington?) described about Dlibs.  He says Dlibs does a Malloc(-1L) early
on, and uses that number divided by 16 as the "chunk" size for requests
from the OS. I *hope* that it doesn't prevent you from allocating more than
16 chunks of that size: with appropriate fragmentation (or TT RAM!) you can
have many more than 16 times that much memory available in the system.  But
the flexible nature of this chunk size (small on a 1040, large on a 4MB
machine) is A Good Thing.  TOSes 1.4 and newer don't have "number of
Mallocs" restrictions, but this algorithm is still worthwhile.


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


From: Allan Pratt
Subject: Re: TT problem with keyboard interrupt
Date: 8 Oct 91 17:05:37 GMT

vspicer@ccu.umanitoba.ca writes:
>Old_kbd_isr=(long)Setexc(70,kbd_isr);
>asm{
>kbd_isr:
>	move.l		A0,-(A7)
>	
>	(do other stuff)
>	
>	pea		retrn(PC)
>	move.w		SR,-(A7)
>	move.l		Old_kbd_isr,A0
>	jsr		(A0) ; jmp has also been tried and failed
>	
>retrn:
>	move.l		(A7)+,A0
>	rte
>}

>this code works fine on the ST but crashes with two bombs (bus error)
>after the "jsr (A0)" command on our TT. any ideas?

Use JMP not JSR, and you need to test the word at $59e, a system variable
called "longframe."  From the 68010 on there is a longer exception stack
frame, and that's what you're constructing by putting the SR and a return
PC onto the stack and jumping to an exception handler.  If the word at $59e
is nonzero, you need to push a zero before the "pea" instruction.  (On
ST's, $59e is an unused word in system variable space, so it's zero. On
newer TOSes, it gets initialized to a nonzero value if you're on anything
other than a 68000.)

On the other hand, since you're not doing anything useful at retrn, you can
restructure this in a stack-frame-insensitive way:

	move.l	a0,-(a7)
	(do stuff)
	move.l	(a7)+,a0
	move.l	Old_kbd_isr,-(a7)
	rts

The "move an address from memory to the stack, then rts" trick is a way to
do an indirect jump without changing any registers.  Think of it as "jmp to
the address found at Old_kbd_isr" and not really an "rts" and you'll have
the idea.  Since the routine you jmp to ends with RTE, and you haven't
changed the exception stack frame, you don't have to care about longframe.


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


From: Allan Pratt
Subject: Re: Why programs don't work (was Fligth Simulator on STe)
Date: 18 Oct 91 21:03:10 GMT

reeuwijk@dutentb.et.tudelft.nl (C. van Reeuwijk) writes:
>After that, I bought a Mega STe. And I discovered that I could not run
>FSII at all, so I took
>out a disassembler and tried to find the cause. It appears that there is
>a loader program, FS2.PRG, that loads and relocates the code from either
>the color or monochrome version of FSII. However, *IT LOADS THE PROGRAM
>TO A FIXED ADDRESS*, $28000. This may, or may not be an address that is
>already used by other programs, but if you have a harddisk with some ACC's,
>a disk cache, or The FOLDRxxx.PRG program it is very likely that the ram
>at that address *is* in use.  To prove this to myself, I have de-installed
>the auto-boot disk-driver, and started FSII directly from floppy.
>It worked!

Thank you for the opportunity to discuss the question "why doesn't program
X work on machine Y?"

Program X might have been written by real dingbats, that's why.

It might load at an explicit address.  It might use really low memory in an
attempt to foil debuggers, and using that memory might not be as harmless
as it was in the TOS version the author designed it for.  It might assume
that ROM starts at $FC0000. It might demand (inexplicably) that a certain
system buffer appear below address $1000, as Crack'ed does.  It might
clobber a system resource (like Timer C) and then expect BIOS calls to go
on working.

It might run off the end of memory looking for something above phystop,
with a guard against doing that on a 4-meg machine: ST's won't give bombs
when you access non-existent memory under 4MB, but STe and TT will.
The Shadow (background-download) detection code does this.

It might have a bug that wasn't fatal in old TOSes, like I recently found
in Starglider: it has this instruction

	move.b	$df,$fffa0f

instead of this one:

	move.b	#$df,$fffa0f

The second one clears a single bit in the MFP in-service register the first
moves whatever value happens to be in memory at $df into that register. 
Since $df is the low byte of an exception vector that isn't used, you're at
the mercy of the address where the bomb handler landed in ROM.

My point is that we just can't fix these things.  I don't like the fact
that Starglider doesn't work under new TOS, but I can't help it.


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


