xanthian@well.UUCP (Kent Paul Dolan) (08/10/89)
[So long as I'm wishing...] NoFastRam is pretty good, but I like to play hack [Oh, did I mention that before? ;-)] from RAD: in those dull periods while I build my programming environment into RAM: from .zoo files on floppies. Now, I lose hack games sometimes at a rate faster than one a minute, which means I start the game over (from an icon) pretty often. [Actually, NoFastRam is _great_! Without it I couldn't play hack on this configuration at all. Kudo's to the author(s)!] Hack, however (at least my version), is one of those antiques ported before anybody had more than 512K memory on their Amigas, and it needs to be restricted to chip ram, or all the pictures get lost. Hack played on a continually blank screen is _boring_! Flipping the NoFastRam toggle while I'm loading stuff into RAM: isn't such a hot idea, though; some of my RAM: segment allocations end up in chip ram, and there they stay until I reboot, since the stuff I'm loading while I play is pretty much "read-only". Even if I 1) toggle fast ram off, 2) start my next dungeon crawl, which brings up a 3 bit deep screen for hack, 3) flip screens back to the workbench, and 4) toggle fast ram on, all as fast as possible, I've lost 20K or so per game from chip ram until I reboot. So, what I'd like, is a way to say "no fast ram for programs launched from this CLI invocation/this window", or "TOOL TYPE=NoFastRam" on the launch icon, or "NoFastRam rad:hack", or some other way to restrict _one program_'s access to fast ram, while my zoo sessions [Yes, I typically do two at once, and not a guru yet! More kudos to the authors of the RAM: handler; it's solid as a rock for me. Multi-tasking is _crucial_ to productivity, and the MS-DOS and Mac user communities are still being sold this bill of goods about it being a waste of money. Hah!] still could keep on using fast ram, independent of the fact I'm playing hack when I should be washing dishes or paying bills or some other maintenance mode activity. well!xanthian Kent, the man from xanth, now just another echo from The Well. PS Show me another OS that would survive having two simultaneous sessions writing into a ram disk that expands to meet the need, having access to most of ram toggled on and off ten or more times meanwhile, having big chunks of memory real estate grabbed for screens and then freed, and having a fairly buggy game played intermediately, with screen swapping and so forth going on fairly often, all at once and in real time. The folks at Commodore have given us a really ruggedized OS, within the limitations of no hardware memory protection, and have every reason to be proud of their work. kpd.
jtreworgy@eagle.wesleyan.edu (08/11/89)
In article <13080@well.UUCP>, xanthian@well.UUCP (Kent Paul Dolan) writes: > Hack, however (at least my version), is one of those antiques ported before > anybody had more than 512K memory on their Amigas, and it needs to be > restricted to chip ram, or all the pictures get lost. Hack played on a > continually blank screen is _boring_! > > Flipping the NoFastRam toggle while I'm loading stuff into RAM: isn't such > a hot idea, though; some of my RAM: segment allocations end up in chip ram, > and there they stay until I reboot, since the stuff I'm loading while I play > is pretty much "read-only". > [...] Here's a better idea... use FixHunk or PowerPacker (which I recently posted in comp.sys.amiga) to force your program to load into chip ram. I have done this to every such program, and never had a problem (except of course that I've got all this fast RAM & the stupid things are residing in CHIP ram!). I'm not sure about fixhunk, but with powerpacker you can choose which hunks you want forced into CHIP ram; usually just putting the data hunks there does the trick. -- James A. Treworgy jtreworgy@eagle.wesleyan.edu jtreworgy%eagle@WESLEYAN.BITNET