Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!unisoft!bdt!david
From: david@bdt.UUCP (David Beckemeyer)
Newsgroups: comp.sys.atari.st
Subject: Re: nullfilling
Message-ID: <526@bdt.UUCP>
Date: 2 Mar 89 19:48:42 GMT
References: <8903010551.AA25974@ucbvax.Berkeley.EDU>
Reply-To: david@bdt.UUCP (David Beckemeyer)
Organization: Beckemeyer Development Tools, Oakland, CA
Lines: 25

In article <8903010551.AA25974@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET (JOHN ZAFIRIS) writes:
>Here's the proposal:  Atari, write 4 instructions worth of code into
>those new, amazing, almost-as-good-as-sliced bread v.1.4 ROMS that check
>the last 4 bytes of the program that was just loaded (I'm sure that 4
>instructions are able to fit into that 192K or ROM).  If those last 4
>bytes are some magic value, say 628318530 (2*pi, yes, I know, really
>original...) then the memory clearing code is just ignored. ...
[ Rest Deleted ] 
Last four bytes of which part of the program just loaded?  The last bytes
of the Text, Data, BSS, Symbols, or what?   If it's the last bytes of the
file, these are currently undefined, and in fact they're used by MWC
executables.  Who puts the four bytes there?  The linker?  The User?
What's to guarantee that the magic number isn't there now in some
executable file?

Basically I think this is old news.   Forget it.   There's a lot more
important things for Atari to do with the ST; like how about multichannel
DMA and a real MMU and some hardware for that Mega Bus and an expansion
box for it and some ATARI SUPPORTED network hooks built into the OS
and FORWARD SLASHES and virtual file systems and ... :-)
-- 
David Beckemeyer (david@bdt.UUCP)	| "Lester Moore - Four slugs from a .44
Beckemeyer Development Tools		|  no Les, no more."
478 Santa Clara Ave. Oakland, CA 94610	|   - Headstone at Boot Hill
UUCP: {uunet,ucbvax}!unisoft!bdt!david	|     Tombstone, AZ