clutx.clarkson.edu (AAron nAAs,,,2684025) (04/28/89)
I have been using RamDisks *FOR EVER*, and constantly replacing the one I am using with better one's as they came along. I currently use MaxiDisk which is reset survivable AND compresses everything that you put into it, automatically! MaxiDisk appears to be a normal ramdisk, in use and action to the user, EXCEPT that you can put about 700K in a 500K Maxidisk!! BUT I AM NOT SATISFIED! I heard there are ramdisks for the Amiga and the Mac that ajust their size as you put files into them. Say you install this ultimt:Jimate ramdisk at bootup. It takes up very little memory (maybe about 20K max) until it is used. You pump about 400K in files into this ramdisk of ramdisks, and it uses about 320K of the system (300K for the compressed files (Like in MaxiDisk) and about 20K for the controller). Then you go to run an application that wants *LOTS* of memory, and you can't because you don't have enough avaliable. So, you delete some files in your ramdisk to free up some RAM. Think about it. A ramdisk that you don't have to mess with sizing, a ramdisk that takes up only as much memory as the files you put into it and a ramdisk that takes up less memory than the files you put into it (ala Maxidisk) Of course, unless it is reset survivable, it isn't worth it, so can't forget that! Have I explained suffiently? Have I sparked imaginations? Have any hackers tried this? I "dont think" this exists yet for the ST, yet, does it? I WANT THIS ULTIMATE RAMDISK !!! Oh, I will send MaxiDisk to ssyx soon. AAron nAAs opielask@clutx.clarkson.edu naas17@snypotba
cs163afu@sdcc10.ucsd.EDU (Some call me...Tim) (04/30/89)
In article <2963@sun.soe.clarkson.edu> opielask@sun.soe!clutx.clarkson.edu.UUCP writes: >I heard there are ramdisks for the Amiga and the Mac that ajust their size >as you put files into them. This can't be done on the ST because of one important detail about memory management: When a program is executed, it is allocated ALL available memory. So, though you could use this from the desktop, as soon as you were in a program that didn't give back its memory, the RAMdisk would run out of room. As it turns out, many programs do give back the memory--but there is a further problem that arises: > Of course, unless it is reset survivable, it isn't worth it, so can't forget >that! The way the reset proof ramdisks work on the ST is that (I believe) they tell the operating system that the top of memory is underneath their lowest address, and then reset the system so that all the system variables will be changed to reflect this. i.e. Every time the size of the Ramdisk changes you have to reset the computer. Even the Amiga reset-proof-ramdisk isn't resizeable. There are two kinds of Ramdisks standard on the Amiga under Workbench 1.3: resizeable, and reset-proof. The nice thing is that you can boot from the reset-proof one (without a floppy) under Kickstart 1.3 (a ROM upgrade). That would be a nice feature to add to TOS... Actually, I can imagine ways in which a reset-proof, resizable RAMdisk might be made, but it would either require hardware (cartridge) or TOS-version-dependant code, and the latter method may not even be possible. ---------- Tim Mensch | 4096 colors and 16Mhz on an ST... Internet: tmensch@ucsd.edu | Not bad. Not bad. Claimer: My opinions are much more valuable than any instutions' :->
USQB015@LIVERPOOL.AC.UK (Mark Powell) (04/30/89)
I`m not into GEM enough to know whether a ramdisk that grows and shrinks
in "normal" TPA area is possible, but I know that to create such a ram
disk that survives reset is not possible. This is because reset survivable
ramdisks grab a chunk of ram at the top of memory on boot up. They then
alter a few OS variables, such as top of physical memory, so that the OS
thinks it has less memory than it really has and then re boot so that
the OS will set itself up for this reduced amount of memory. So, this
chunk of memory is left alone at the top of memory. The ramdisk then uses
this memory to store it's data. This method is reset survivable because
this OS variable that was altered by the ramdisk controller is not
affected by a warm start. Thus, every time the ST is reset the OS always
thinks it has this reduced amount of memory and doesn't touch this "protected"
portion of memory that the ram disk is using, using only yhe memory below
the ram disk. Thus, to resize the ram disk this OS variable must be altered
and the system rebooted so that the OS knows the new size of the memory.
This more or less prohibits a re-sizeable, reset survivable ramdisk. Unless,
of course you don't mind the computer resetting every time you add or delete
something from the ram disk.
Mark Powell
ARPANet : Hmm.
JANET : usqb015@uk.ac.liv.ibm
USENET : mcvax!ukc!ibm.liv.ac.uk!usqb015peter@sugar.hackercorp.com (Peter da Silva) (05/01/89)
In article <92@sdcc10.ucsd.EDU>, cs163afu@sdcc10.ucsd.EDU (Some call me...Tim) writes: > Even the Amiga reset-proof-ramdisk isn't resizeable. There are two > kinds of Ramdisks standard on the Amiga under Workbench 1.3: > resizeable, and reset-proof. The new rebootable one that comes with the machine isn't, but the old third party ones, VD0: and VDK:, certainly are. And they work just fine under 1.3. I'm using RAD: and VD0: right now. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
wxh@a.lanl.gov (Billy Harvey) (05/01/89)
Several people have said you can have either a reset-proof _or_ a resizeable ram disk, but not both. Could it work like this: The reset proof ram disk would be by the normal bootup method of telling TOS a new top of memory. The resize ability would not necessarily have to be able to occur within a program, since many allocate all free memory, but why shouldn't it be able to occur at the desktop level? Somehow TOS would have to be forced to recognize a new top of memory without rebooting. Does anyone know if thats a doable thing? It wouln't even necessarily have to be through a legal TOS vector, the program would just have to check which version of TOS it was running under. It would certainly be handy. Billy Harvey wxh@a.lanl.gov
Doug_B_Erdely@cup.portal.com (05/01/89)
*Even the Amiga reset-proof-ramdisk isn't resizeable. There are two
*kinds of Ramdisks standard on the Amiga under Workbench 1.3:
*resizeable, and reset-proof.
*----------
*Tim Mensch | 4096 colors and 16Mhz on an ST...
*Internet: tmensch@ucsd.edu | Not bad. Not bad.
*Claimer: My opinions are much more valuable than any instutions' :->
This is not completly true. Yes, there is a reset-proof ram disk for the Amiga,
it's called VD0:, and there is a resizeable one called RAM:. There is also
one called VDK: which is both sizeable and reset-proof! It expands and contracts
as you put things into it and delete things out of it. And it does survive
a system reset. It's really handy, I use it all the time!
- Doug -
Doug_B_Erdely@Portal.Cup.Comrjung@sal61.usc.edu (Robert allen Jung) (05/01/89)
In article <892@a.lanl.gov> wxh@a.lanl.gov (Billy Harvey) writes: >Several people have said you can have either a reset-proof _or_ a >resizeable ram disk, but not both. Could it work like this: >The reset proof ram disk would be by the normal bootup method of >telling TOS a new top of memory. The resize ability would not >necessarily have to be able to occur within a program, since many >allocate all free memory, but why shouldn't it be able to occur at >the desktop level? Because that limits its uses. Imagine the wonderful benefits you can get if you could run a resizable RAMdisk from within, say, ARC.TTP. You're uncompressing a package, and send all of the bits into the RAMdisk. As the RAMdisk runs out of room, it resizes itself until it reaches the limits of your ST's memory. Unfortunately, from the technical reason cited above, this can't be done. >Somehow TOS would have to be forced to recognize >a new top of memory without rebooting. Does anyone know if thats a >doable thing? It wouln't even necessarily have to be through a >legal TOS vector, the program would just have to check which version >of TOS it was running under. It would certainly be handy. Sounds dangerous to me. The last thing I would want is to write a utility that becomes a menace under a different version of TOS. What lessons did we learn from improperly-written ST programs not running on the Mega ROMs? --R.J. B-) ============================================================================= Disclaimer: This message was written with my authorization # ## # # ## # Mailing address: rjung@nunki.usc.edu ## ## ## (It's easier to just use the reply function, tho) #### ## ####
roeder@sbsvax.UUCP (Edgar Roeder) (05/03/89)
Hello! I know at least one such program: FLEXDISK. This is a reset proof RAM-disk that grows and shrinks when you add or remove files. There are upper and lower limits for this growing/shrinking and the program warns you when the disk gets filled up. You can even boot your accessories from FLEXDISK. It can be used either as PRG or as accessory. You can set the date and time, copy files on the ramdisk at bootup and clear the internal directory-caches of TOS (cf. 40 folder bug). The program is distributed by Application Systems in Heidelberg/W.Germany. The price is somewhat lesser than 100.- DM. This was the good news. * * * The bad news: the version which i've seen seemed not to work with GEMBOOT or GEMSTART. And because those are the last programs which i'll ever remove from my AUTO folder (before i get TOS 1.4) ... :-( Hope this helps. - Edgar
grahamt@syma.sussex.ac.uk (Graham Thomas) (05/03/89)
From article <8904301910.AA07292@ucbvax.Berkeley.EDU>, by USQB015@LIVERPOOL.AC.UK (Mark Powell): > I`m not into GEM enough to know whether a ramdisk that grows and shrinks > in "normal" TPA area is possible, but I know that to create such a ram > disk that survives reset is not possible. Well, it may just be possible with a few tricks (which I, sadly, don't have enough knowledge to describe). I know that Applications Systems Heidelberg prodwce a ramdisk called FLEXDISK which has options for 'reset-resident' and 'grow and shrink to fit the space required by the programs you put in it'. I don't remember if you can choose these options to run concurrently. Flexdisk was 'hardwired' to the German ROMs, but I hear they're thinking of doing an international version. Graham -- Graham Thomas, SPRU, Mantell Building, U of Sussex, Brighton, BN1 9RF, UK JANET: grahamt@uk.ac.sussex.syma EARN/BITNET: grahamt@syma.sussex.ac.uk ARPA: grahamt%syma.sussex.ac.uk@nsfnet-relay.ac.uk UUCP: grahamt@syma.uucp Phone: +44 273 686758
schmidt@fbihh.UUCP (Jens Schmidt) (05/05/89)
In article <733@sbsvax.UUCP>, roeder@sbsvax.UUCP (Edgar Roeder) writes: > I know at least one such program: FLEXDISK (stuff deleted, FLEXDISK is an autosizing ramdisk, bootable and reset resident) > The bad news: > the version which i've seen seemed not to work with GEMBOOT or GEMSTART. And > because those are the last programs which i'll ever remove from my AUTO folder > (before i get TOS 1.4) ... :-( More bad news: FLEXDISK has only been possible with the crumpy old Malloc in TOS versions <1.4. The new TOS is so much cleaned up that the illegal hooks are for ever gone, :-( for this and :-) for the rest of it.
rnss@ihuxy.ATT.COM (Ron Schreiner) (05/06/89)
In article <892@a.lanl.gov> wxh@a.lanl.gov (Billy Harvey) writes: >Several people have said you can have either a reset-proof _or_ a >resizeable ram disk, but not both. If you want a REAL RamDisk that's really reset-proof( i.e. crash proof ) check out STonehenge, the Atari Ram Drive. It's hardware not software. -- Ron Schreiner AT&T Bell Labs ...att!ihuxy!rnss
UNCSPL@UNC.BITNET ("Scott P Leslie") (05/07/89)
Hello,
I know that this has seemingly been discussed to death, but I
would like to share an idea about sizable/rebootable ram-disks.
I'm not completely sure that this will work since I am not all
that experienced with allocating memory in a background TSR.
o Take any re-bootable ramdisk such as Eternal.s
o Have it allocate a reasonable (say 64K) amount of high memory
o Setup the boot sector, FATs, and directories
o Setup a list of pointers to sector groups (in groups of 64).
o When TOS (or anything else) requests a sector, strip off the
lower 6 bits to find out which group the sector is in. Then
look in the pointer list to see if the sector is currently
in the ramdisk.
o If the sector is in the ramdisk, pass it back normally.
o If not, allocate another 32K for the ramdisk (64 sector worth)
and do the read/write from/to it. This is allocated in TOS area.
o If a warm-boot occurs,
o Copy all the sectors from the TOS area to below the current
high ram area. Then set the high -ram pointer to below this.
o Execute the reboot code.
o Thats about it...
My only problem with writing this myself is that I don't know how
to allocate the new 32K while in the background. Sure, I can call
Malloc, but what happens to that memory when the current process
terminates? Won't it be returned to the system heap? If not, won't
it fragment memory?
That's all I have to say, now maybe someone can write an optimized
one for all of us to use. I would do it myself, but I don't know how
to do the memory allocation. Oh well...
--
Thanks for listening,
Scott P. Leslie (UNCSPL@UNC) Jaxjf@laura.UUCP (Jan-Hinrich Fessel) (05/08/89)
In article <92@sdcc10.ucsd.EDU> cs163afu@sdcc10.ucsd.edu.UUCP (Some call me...Tim) writes: >In article <2963@sun.soe.clarkson.edu> opielask@sun.soe!clutx.clarkson.edu.UUCP writes: >>I heard there are ramdisks for the Amiga and the Mac that ajust their size >>as you put files into them. > >This can't be done on the ST because of one important detail about >memory management: When a program is executed, it is allocated ALL >available memory. So, though you could use this from the desktop, >as soon as you were in a program that didn't give back its memory, >the RAMdisk would run out of room. > Also there is a problem with Blitter-TOS, which allocates all availible memory while copying files. This may or may not be true for TOS 1.4, i was not able to test this, because my reset-proof-and-resizable-ram-disk will not work with TOS 1.4 :-(. >i.e. Every time the size of the Ramdisk changes you have to reset >the computer. Not true... >Even the Amiga reset-proof-ramdisk isn't resizeable. There are two Too bad:-). >The nice thing is that you can boot from the reset-proof one (without >a floppy) under Kickstart 1.3 (a ROM upgrade). The nice thing is that you can boot under Blitter-or-older TOS from the reset-proof-and-resizable-ram-disk i am talking about, and select where the auto and acc to load are located. >That would be a nice feature to add to TOS... > >Actually, I can imagine ways in which a reset-proof, resizable >RAMdisk might be made, but it would either require hardware >(cartridge) or TOS-version-dependant code, and the latter method may >not even be possible. The ramdisk is called FLEXDISK, it works with TOS-version-dependant code, and the only thing i am missing is the compression. Sorry if i'm late?? Jan-Hinrich P.S.: FLEXDISK comes with a copy-utility and is not in the public domain. -- Jan-Hinrich Fessel Universitaet Dortmund, IRB jf@unido.uucp || jf@unido.bitnet There's no way to delay that trouble comin' every day... F.Z. =============================================================================