I0908@DKAFHS1.BITNET (08/31/89)
Date: 30 August 1989, 19:29:29 SET
From: Cornelius Caesar BITNET / EARN: I0908 at DKAFHS1
To: info-atari16 at score.stanford.edu
My small contribution:
I got PACK and CRUNCH from the panarthea archive. While PACK doesn't
work on all executables (sometimes it says 'fout in the header'- why??),
CRUNCH does.
I tested them on my LARN12.TTP:
original: 172 KB
w/ CRUNCH: 141 KB
w/ PACK: 110 KB
w/ PACK & CRUNCH: 87 KB and still working||
(reverse not possible)
ARC still gets some KB out of the 87 KB but then, of course, it's no longer
executable. Note: ARCing the original LARN yields 90 K and ZOO gives 83 K.
Cornelius
NB: MORIA was reduced from 372 K to 320 K with CRUNCH, PACK showed the
'fout' error. CRUNCHing the file had the *unvaluable* side effect that
I am now able to start Moria from my hard disk| Before that the game
immediately returned to the desktop; I could, however, start it when
I booted from floppy. Since I have FOLDR400 and some other things
installed on my MegaFile 60 my 1040 has only about 650 KB free RAM so
I suspect it's a memory problem.
Can anyone explain why the crunched Moria runs when the normal doesn't?
They should have the same need for RAM when they are executed, so the
only possibility coming to my mind is that something happens with
relocating the program or, else, Moria itself does some checking.
Comments?saj@chinet.chi.il.us (Stephen Jacobs) (08/31/89)
In article <8908301805.AA11049@ucbvax.Berkeley.EDU>, I0908@DKAFHS1.BITNET writes: > Date: 30 August 1989, 19:29:29 SET > From: Cornelius Caesar BITNET / EARN: I0908 at DKAFHS1 > To: info-atari16 at score.stanford.edu > > NB: MORIA was reduced from 372 K to 320 K with CRUNCH, PACK showed the > 'fout' error. CRUNCHing the file had the *unvaluable* side effect that > I am now able to start Moria from my hard disk| Before that the game > immediately returned to the desktop; I could, however, start it when > I booted from floppy. Since I have FOLDR400 and some other things > installed on my MegaFile 60 my 1040 has only about 650 KB free RAM so > I suspect it's a memory problem. > Can anyone explain why the crunched Moria runs when the normal doesn't? > They should have the same need for RAM when they are executed, so the > only possibility coming to my mind is that something happens with > relocating the program or, else, Moria itself does some checking. > Comments? ST moria does VERY little checking of anything when it starts. Basically, it looks for the hours file and the highscores file, and that's it. Two possibilities come to mind. First is clock peculiarities. I have no idea of any reason why any of this should affect the system clock, but most of the problems people have with ST moria are cured by setting the system clock to the current date/time, so clock peculiarities are ALWAYS the first guess. Next guess is a Pexec() failure. In my excessive recent experience of Pexec() failures, one important symptom is that afterwards you have no available memory. For reasons that have no obvious rational explanation, this seems to be affected by hard disk driver software. I had trouble with Moria running from the C: drive of my Supra partitioned ST 296N when I used BMS software to drive it. Using Supra software, there's no problem. Moria was the only program that caused trouble, but it's also the only program I run that has about 3x 16^4 of each of text, data and bss. And by the way, you can read those segment sizes from the executable with a hex file editor. One recent version of moria has a total executable region of 565,406 bytes. This brings up my periodic beg: PLEASE!!! Anyone having trouble running moria on an ST with at least a meg of memory: tell me about it. For a limited time only, if I can fix it, I'll surface mail you a disk. Unless something new comes up, moria improvements are my next project (note that moria is the property of Robert Alan Koenecke (sorry about the spelling, I think it's right, but my Alzheimer's disease is acting up), and he doesn't want people making changes that affect the play of the game). Steve J. saj@chinet or saj@chinet.chi.il.us or saj@chinet.clout or saj@chinet.uucp