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