jik@picuxa.UUCP (Jonathan Klein) (09/11/86)
Hi, This is my first posting to net.micro.amiga and would like to say that I've gotten a lot out of the discussions here. Now I'd like to contribute something myself. I've been using an ASDG Mini-Rack-B for a week now along with their "2M", a 2 megabyte ram card. I've been really happy with it but they just sent me something I'm REALLY happy about. They sent me a disk containing a thing called vdisk.device. They said it was an alternative to ram: that is completely compatible with DOS whereas ram: is mostly compatible. Also, it's not destroyed by machine reset or system crash. The installation guide gave me a devs/mountlist entry (I'm using 1.2) and said by changing the number of tracks (editing one line) I can set any maximum ram disk size I want (up to 2 mega bytes). They said that later they will come out with an Intuition utility which means I won't have to edit devs/mountlist to change the maximum ram disk size. So I inserted their mountlist entry into devs/mountlist and set it for 1.4 megabytes of ram disk. Next, they say to put: mount vd0: into the s:startup-sequence as the first line. And then reboot. So I did and... Info said I had an 880k df0 and df1. And a 1.4M VD0!!! AND avail said I still had 2 million some odd bytes of fast ram left!!! (from this I can tell that they fool AmigaDos into thinking that there's an N megabyte disk out there but actually allocate the track buffers only when needed. I took there suggestion of creating a script called fill-vd0. They said that should vd0: need recreation I just execute the script and I'm back on the air. They said that the ram disk will need recreation if: 1. I power down. 2. I change the max size of the ram disk. 3. The ram disk is "violated" during a crash. They said they keep checksums of every track and can tell if one's been overwritten. I put a "path vd0: add" into my startup-sequence and for three days and many many reboots I haven't reloaded vd0: ONCE! I got curious how they did it and I wondered if there allocation scheme (allocate on demand) would fragment ram the way the ram: device does. I wrote a program to dump the memory lists and found ZERO fragmentation due to vd0:!!!! NONE! - It seems to grow the disk from the top of memory downwards so it definitely doesn't use AllocMem to get memory. I figure fragmentation due to vd0: will NOT happen unless I completely fill up fast ram and then allocate another track. These guys did a great job on their software. Period. Their hardware is great too. I bought the mini-rack-b (a two slot 100 pin zorro box) for $150. And the 2M ram card for $750. And yes, it has NO wait states. Sincerely, Jonathan Klein ------------------------------- I am not associated with ASDG in anyway except I bought their stuff and love it.
vanam@pttesac.UUCP (Marnix van Ammers) (09/13/86)
Sounds just like what I've been looking for! Will the thing work with my current CardCo 1 MEG addition? If not anyone wanna buy a MEG ? What's their phone number & address? --- Marnix One more review like that and I'm hocking the house and sending them a check ...
cc1@locus.ucla.edu (Michael Gersten) (09/16/86)
Wait a second...it DOESN'T use AllocMem()? Then it CANT be compatible.
Consider what happens if an interrupt routine wants to write to a file,
and writes out to this ram disk. THERE IS NO GUARANTEE THAT AllocMem()'s
DATA WILL BE CONSISTENT. The Ram disk looks at inconsistent data, grabs
memory that may be returned by AllocMem, presto!
This obviously means that the Ram: disk cannot work during interrupts,
but it has no way to tell if its caller was working from an interrupt
routine or not. And there is no problem with writting to disk files
during an interrupt routine.
No flames, please--if I'm missing something here, I think others will
be missing something too. But I don't trust something like that.
Michael Gersten
Views expressed here may not be those of the Computer Club, UCLA, or
anyone in their left OR right mind. And that's the name o' that tune.dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/16/86)
Lets not start a war, the original suggestion that ASDG did not use AllocMem was a guess, not fact. But this brings up a good point on AllocMem... It would be nice if you could specify something like 'MEMF_END' requesting AllocMem to allocate from the end of it's pool rather than the front. Thus, specific applications which allocate and deallocate constant block-sizes all the time AND stick around in memory (e.g. a RAM disk) could use it and many of the amiga's fragmentation problems would go away. -Matt
perry@well.UUCP (Perry S. Kivolowitz) (09/18/86)
In article <1530@curly.ucla-cs.ARPA>, cc1@locus.ucla.edu (Michael Gersten) writes: > Wait a second...it DOESN'T use AllocMem()? Then it CANT be compatible. > > Consider what happens if an interrupt routine wants to write to a file, > and writes out to this ram disk. THERE IS NO GUARANTEE THAT AllocMem()'s > DATA WILL BE CONSISTENT. The Ram disk looks at inconsistent data, grabs > memory that may be returned by AllocMem, presto! > While it is true that no interrupt service routine should perform an AllocMem or FreeMem from within themselves it will never be the case that an interrupt service routine will generate new IO to my RAM disk driver. Hence no problems. In general though, this problem could be avoided (if it really were a problem) by DISABLEing and ENABLEing interrupts around memory list management code (in addtion to forbid and permit). The ASDG Recoverable RAM disk has been banged upon a lot and has not show any incompatibility with 1.2 (except if you call not being able to diskcopy df0: to vd0: an incompatibility). Perry S. Kivolowitz
hamilton@uiucuxc.CSO.UIUC.EDU (09/18/86)
>Wait a second...it DOESN'T use AllocMem()? Then it CANT be compatible. compatible with what? it sounds like it uses Allocate() (which is what AllocMem() uses). >Consider what happens if an interrupt routine wants to write to a file, >and writes out to this ram disk. THERE IS NO GUARANTEE THAT AllocMem()'s >DATA WILL BE CONSISTENT. The Ram disk looks at inconsistent data, grabs >memory that may be returned by AllocMem, presto! hey, that's not unique to ASDG's ramdisk driver. the AmigaDos ram-handler would be just as susceptible. >This obviously means that the Ram: disk cannot work during interrupts, >but it has no way to tell if its caller was working from an interrupt >routine or not. And there is no problem with writting to disk files >during an interrupt routine. have you actually tried doing disk i/o in an interrupt routine?! i wouldn't... even if it were "safe", other interrupts could get fouled up while you're waiting for such a slow process to complete. you're concerned that the memory list may be in an unstable state when the interrupt occurrs; suppose the disk device's message list is likewise unstable at the time you send an i/o request? if i wanted to do i/o from an interrupt, i'd use a second, "soft" interrupt routine, and have the hardware interrupt Cause() the soft one. the soft interrupt would live in normal tasking space. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton