Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!killer!osu-cis!tut.cis.ohio-state.edu!mandrill!gatech!udel!rochester!cornell!batcomputer!itsgw!steinmetz!uunet!portal!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.atari.st Subject: Re: null fill eliminated Message-ID: <1067@atari.UUCP> Date: 1 Jun 88 22:56:05 GMT References: <490@philmds.UUCP> Organization: Atari Corp., Sunnyvale CA Lines: 26 From article <490@philmds.UUCP>, by leo@philmds.UUCP (Leo de Wit): > null fill (there could be a 1/(vbls/sec) delay %-) and is guaranteed NOT to > work on all ROM versions 8-). > The main problem will be the addresses (start, end) of the fill-routine > in ROM. This is appalling! Please get over the idea that you can fool with stuff in ROM. For starters, some programs EXPECT that the whole heap (not just the declared BSS) is zeroed at startup... Microsoft Write is one. Maybe the disk cache you use, or the hard disk compaction utility, or something equally deadly expects this -- and you'll learn the hard way not to fool with this kind of thing. I know the clearing takes a long time on 11/20 ROMs. It's much faster in Mega and future ROMs. But it's still there, because it is a "settled expectation" among developers. ("Settled expectations" are things that people count on despite the fact that nobody promised they'd stay true.) I urge people not to use this trick or any other which changes the environment that programs execute in, or depends so heavily on actual addresses in ROM. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt