[net.micro.atari] Ram disks and OSS Pascal

mckay@PURDUE-ECN.ARPA (02/20/86)

I've finally gotten both the RAM upgrade and TOS in ROM installed on my ST.

After discoving that the various public domain RAM disks don't work with TOS
in ROM and figuring out how to boot with old TOS, I tried OSS pascal.  (is
there a PD ram disk which works with TOS in ROM?)

The results are staggering:

operation:		All Floppy	ALL Ram disk	Split

Compile and link
"hello, world"		1:20		0:05 (!)	0:23

Compiling 9k
GEM program		2:30		0:21 (!)	didn't try yet.

The most intersting number for me in the Split number.  In this setup I had
my source on floppy and the compiler and libraries on the RAM disk.  The OSS
compiler and linker handle this very well, correctly loading the libraraies
from the disk the compiler is on while placing the source, object and final
program on the floppy.

I have a short analog clock program I posted to USENET's net.micro.atari a
few weeks back.  It is written in OSS Pascal and I'd be happy to post it
here if enough folks are interested.  If not I can mail source and uuencoded
binary to one or two folks.

--Dwight Mckay, ECN Text Processing Software Support
[arpa: mckay@ee.purdue.edu, usenet:...ihnp4!pur-ee!mckay, phone:(317)494-3561]

------- End of Forwarded Message

franco@iuvax.UUCP (02/23/86)

I have found that Mike's RAMDISK works conditionally with 1MEG and TOS in
ROM.  Mike's RAMDISK can be set to any size above 100K.  It has the following
drawbacks:

   1. It seems that if one originates execution of a program from a
      floppy drive some avaiable memory is lost (until the next boot).
      However, this does not seem to happen (except perhaps initially)
      if one originates execution from the RAMDISK.

   2. My version of Mike's RAMDISK does not allow resizing of the RAMDISK.
      But this is a relatively minor drawback.

I have found this RAMDISK very useful - especially for compiling in C
using the developer stuff.  I simply open 'er up to 700K, dump all
the .h, .o, library files, compiler and linker and source into the
RAMDISK and let 'er rip from device D.  I have made up to 15 straight
compiles without a problem this way.  Also, the time for compile has
been as low as 40 seconds (must be a world's record for the DRI C)
on small files (producing 15K executables).  At the moment I can easily
live with this RAMDISK and I recommend it to anyone needing a stopgap
until a real RAMDISK (occupies upper memory, allows resolution change,
can be resized, size at boot can be preset (even to 0), no memory loss
through executions etc.) can be developed.  Frankly, at this point I am
so fed up with PD RAMDISKs that I will go out and buy one once I know
there exists one that meets my specifications.  If anyone can help out here
please do!

franco@iuvax.UUCP (02/23/86)

In the previous response I said i was fed up with PD RAMDISKs.
This was a rather unfortunate statement to make - it shows a lack of
regard for those people who are kind enough to produce useful software
and place it in the Public Domain.  I very much appreciate most of the
PD stuff I have gotten (and Mike's RAMDISK is one of my most important
pieces right now) and I am sorry for being rude.  When I learn enough
about the ST I suppose I will either fix Mike's RAMDISK or originate
another (unless a good RAMDISK shows up first).