🚀 go-pugleaf

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

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

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

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

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

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt