Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!newstop!sun!imagen!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.atari.st Subject: Re: (repost) POOLFIX3.ARC (really fast-load bit) Message-ID: <2017@atari.UUCP> Date: 1 Feb 90 22:16:24 GMT References: <2005@atari.UUCP> Organization: Atari Corp., Sunnyvale CA Lines: 34 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