chuqui@nsc.UUCP (Chuq Von Rospach) (03/20/85)
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!
sjl@amdahl.UUCP (Steve Langdon) (03/21/85)
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. ]
jcbood@ihlpg.UUCP (Jaap Bood) (03/25/85)
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
jsp@unccvax.UUCP (Joel Patterson) (03/27/85)
Could someone please post a binhex copy of Asteroids for the mac. Sounds like great fun if your an asteroids fan. tia
roy@nlm-vax.ARPA (Roy Standing) (03/29/85)
> 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...