Path: utzoo!utgpu!watmath!att!dptg!rutgers!cs.utexas.edu!uunet!yale!root From: root@yale.UUCP (Root Of All Evil) Newsgroups: comp.sys.atari.st Subject: Re: ZOO bombs Keywords: ETRNL2, ETERNAL2 Message-ID: <68890@yale-celray.yale.UUCP> Date: 7 Aug 89 16:02:21 GMT References: <8907131551.AA27783@ucbvax.Berkeley.EDU> <2514@water.waterloo.edu> <764@Terra.cc.brunel.ac.uk> <399@laas.laas.fr> <2536@water.waterloo.edu> <777@Terra.cc.brunel.ac.uk> Reply-To: fischer-michael@CS.YALE.EDU (Michael Fischer) Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Lines: 47 Bcc: fischer-michael In article <777@Terra.cc.brunel.ac.uk> ralph@ccs.brunel.ac.uk (Ralph Mitchell) writes: >In article <2536@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: >>>In article <764@Terra.cc.brunel.ac.uk> ralph@ccs.brunel.ac.uk (Ralph Mitchell) writes: >>>| ETERNAL2 doesn't actually work in a Mega 4... Using HiSoft's resident >>>| ... >>>| that the MMU can handle, so it gets a real bus error. Moshe ?? >> >>However, Moshe Braner informs me that, yes, he posted an early warm-boot- >>surviving ramdisk, but ETRNL2 is something that came along later. >>I still suspect Ralph's ramdisk. >> >>The ramdisk program that I use, I have also stored in an ARC file which has >>these characteristics: >> >>Name Length Stowage SF Size now Date Time CRC >>============ ======== ======== ==== ======== ========= ====== ==== >>ETRNL2.PRG 1024 Crunched 24% 784 27 Oct 88 2:15p c37e >> ==== ======== ==== ======== >>Total 1 1024 24% 784 > > >Umm, I've just noticed it called ETERNAL, not ETERNAL2. However, pressing >on... In the doc file it says: > > (c) Robert Fischer and OSS, 1986. > >When running the configuration program, CONFGRAM, it comes out with Robert's >address in Hamden, CT. Eternal itself puts up 2 bombs... > >This version of ETERNAL came on a floppy that was stuck to the front of >a magazine called ST/Amiga Format. Software lives on! As I recall the history, Robert took Braner's original ETERNAL and modified it to make it easier to configure. I believe he also tightened up the code to use slightly less memory. The problem on the Mega 4 is probably due to the ramdisk reading the first location after the top of memory to see if a magic number is stored there, indicating an existing ramdisk. That doesn't work on the Mega 4, so the strategy would have to be changed. Robert might be willing to make the change and release a new version if there is still interest in this program. ================================================== | Michael Fischer | | Arpanet: | | Bitnet: | | UUCP: | ==================================================