🚀 go-pugleaf

In article <265@ihlpg.UUCP> jcbood@ihlpg.UUCP (Jaap Bood) writes:
>(btw, I don't agree with the
>review of the ramdisk in the march issue of Mcworld; I have a single disk
>Mac and the Ramdisk solves 80% of the swapping problem, plus has a number of
>other advantages - fast Mcwrite prints; fast launch etc)

I'm using ramdisk used in the Macworld review, and I can't decide if it is
a royal pain or if it is a Godsend. My setup is 512K with 2 drives, so I
don't have a swap problem that someone with a single floppy would. There
are definite tradeoffs.

The main disadvantage I see is that the ramdisk is smaller than a normal 
floppy. This drives me up the wall, since I can't fit everything in a
ramdisk that I would normally fit on a floppy. This is most noticable when
I'm hacking-- Mac C and the MDS stuff unfortunately all want to share a
floppy or the various transfers in EXEC doesn't work, and the preliminary
version of EXEC doesn't seem to work unless it is on the disk with the 
system file-- The result is a 395K disk (with no fonts and minimal DA's)--
I couldn't cram that into a Ramdisk if I wanted to.

On the other hand, when I can put the system stuff and application on the
Ramdisk, its a lot nicer (I do this with MacTerminal and MacProject)
because I only need one floppy to work with the system-- hauling MacDuff
around becomes that much easier. Again this works because neither of these
applications use a lot of fonts-- so the system file is smaller. For
macpaint and macwrite, where I need my fonts and my DA's, my system file is
about 250K, so the applications move back to floppy and all the system
stuff goes to RAMdisk. 

At last look I was maintaining three different variations of the system
file. I'd REALLY like to keep one, but I haven't found a way to do this
considering the 'small' disks (I find it amusing that someone who used to
think an 8K IMSAI was a wonderful machine could complain about half a meg
of memory and 400K floppies...).

>Now to end the good news, I have sometimes the following problem:
>I bring up the system with a startup disk, which creates the ramdisk
>(startup application).
>I execute SWITCH to make my ramdisk the boot-disk, and eject the startup
>disk.

I think the switcher is trying to make use of the same memory that your
ramdisk is-- remember that it partitions off memory into segments to allow
you to pop back and forth between different applications. There is a good
chance that it uses some part of high memory to stores its data and that is
stomping on your ramdisk. I seem to remember reading somewhere that the
switcher and the ramdisks weren't compatible, but I don't know where...

chuq
-- 
Chuq Von Rospach, National Semiconductor
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui   nsc!chuqui@decwrl.ARPA

Be seeing you!

In his posting Chuq says:

> The main disadvantage I see is that the ramdisk is smaller than a normal 
> floppy. This drives me up the wall, since I can't fit everything in a
> ramdisk that I would normally fit on a floppy. This is most noticable when
> I'm hacking-- Mac C and the MDS stuff unfortunately all want to share a
> floppy or the various transfers in EXEC doesn't work, and the preliminary
> version of EXEC doesn't seem to work unless it is on the disk with the 
> system file-- The result is a 395K disk (with no fonts and minimal DA's)--
> I couldn't cram that into a Ramdisk if I wanted to.
> think an 8K IMSAI was a wonderful machine could complain about half a meg
> of memory and 400K floppies...).

His analysis of the situation is the obvious one, but it is not correct.  I will
explain by describing my current C compiling setup. I use the following volumes:

	RAMDisk - System, C compiler, Exec, Edit, and a program called "Finder"
		  that I wrote.  It calls SFGetFile for 'APPL' type files and
		  launches the selected file.  It is much smaller than the real
		  Finder.
	Drive 1 - Linker, RMaker, real Finder, and all the .REL library files.
	Drive 2 - .h files, my source and associated files(ie. .job and .link)

To get all this to work you have to use the Menu or Resource Editor to edit
volume names into the transfer menus of the various parts of the Mac C system.
You also need to put volume names in the .job and .link files to direct the
programs to look in the right places.

The following section of his note seems to me to represent a missunderstanding
of the original posting.  I do not think that the "SWITCH" refered to is the
Switcher.

> >Now to end the good news, I have sometimes the following problem:
> >I bring up the system with a startup disk, which creates the ramdisk
> >(startup application).
> >I execute SWITCH to make my ramdisk the boot-disk, and eject the startup
> >disk.
> 
> I think the switcher is trying to make use of the same memory that your
> ramdisk is-- remember that it partitions off memory into segments to allow
> you to pop back and forth between different applications. There is a good
> chance that it uses some part of high memory to stores its data and that is
> stomping on your ramdisk. I seem to remember reading somewhere that the
> switcher and the ramdisks weren't compatible, but I don't know where...

-- 
Stephen J. Langdon                  ...!{ihnp4,hplabs,sun,nsc}!amdahl!sjl

[ The article above is not an official statement from any organization
  in the known universe. ]

Thanks very much all of you who tried to help me with the eject/insert
problem I had (have). Chuq missed the point about SWITCH. This is just a
simple "do nothing (but do it good)" program, which I use to make the
(system)disk from which it is started, the primary (or whatever the correct
name is) disk.
None of the responses solved the problem, but then neither did I. I've
narrowed it down though! It happens allways directly after I (or actually
after one of my two kids - who love the Mac by the way) have used ASTEROIDS
(a public domain "shoot the rocks" game).
I've checked the program with the Resource Editor (great to see some
European software on the net - should improve the average quality) but I
could not find anything special. If the author is listning ....

				Jaap
-- 
Jaap Bood
IH-3058
2C-434

Could someone please post a binhex copy of Asteroids for the mac.
Sounds like great fun if your an asteroids fan.

tia

> None of the responses solved the problem, but then neither did I. I've
> narrowed it down though! It happens allways directly after I (or actually
> after one of my two kids - who love the Mac by the way) have used ASTEROIDS
> (a public domain "shoot the rocks" game).

I am not the author but I can tell you of a problem with Asteriods, along with
a solution, that a friend of mine worked out.

ASTERIODS turns off ALL interrupts except for 'key down', 'key up',
'mouse down', 'mouse up'.  The problem is that when you quit from
the program it doesn't turn the other interrupts back on.  Since the
Mac is single user, there really isn't anything to worry about --
thus one solution is to NOT turn off all the other interrupts.

Using FEDIT 2.1 or another program of your choice, open the ASTERIODS
application.  In block 1, address 162 (hex) change the contents from
001E to FFFF.  (For anyone who is interested this value is placed in
memory location 144, the system event mask).

While you are mucking about, set the bundle bit.  ASTERIODS has its
own icon, if you hadn't noticed.

Hope this solves the problem Japp Bood was having...