cw@vaxwaller.UUCP (Carl Weidling) (10/09/87)
I don't have a developer's kit. I do have Mark Williams C. I presume that a RAM disk works by intercepting calls for file services in the OS, but I haven't uncovered documentation to explain where or how. Could somebody explain how it's done, and maybe include source for a RAM disk. The famous eternal ram disk is not supposed to work with the new ROMS, also, I've heard there are limits to the size of a lot of RAM disks (somebody at a show muttered something about them using 12 bit FATs instead of 16 bit FATs or something) so that you cannot have a 2 meg RAM disk for instance. Any info would be appreciated. Regards, Carl Weidling
med@druhi.ATT.COM (DrapalME) (10/11/87)
In article <1177@vaxwaller.UUCP>, cw@vaxwaller.UUCP (Carl Weidling) writes: > > I don't have a developer's kit. I do have Mark Williams C. > I presume that a RAM disk works by intercepting calls for file services > in the OS, but I haven't uncovered documentation to explain where or > how. > ... > Regards, > Carl Weidling If you have MWC version 2.0, you already have what you are looking for! On the third disk (maybe the second one, I don't have them handy right now), there is an archive file (MWC ar format) that has the source for a configurable ramdisk that is reset-resistant. It's every bit at good as the eternal ramdisk, and you have the sources so that you can change it anyway you want. The only complaint I had with it was that it really couldn't be used in your AUTO folder, but having the sources, I simply fixed that :-). If you are interested in these changes, I could send you the DIFF's. Myron Drapal ..!ihnp4!druhi!med
braner@batcomputer.tn.cornell.edu (braner) (10/11/87)
[] The "eternal" ramdisk (and probably most others) work by plugging their own routine's address into the system vector holding the "hard disk Rwabs() vector". That vector is used by the BIOS trap code when the call is Rwabs(). The parameters passed to it are as described in the calling specs for Rwabs(), plus/minus some shift in the stack pointer (can't remember now). The RAMdisk code checks the drive number, and if it's not the RAMdisk it jumps to the original Rwabs() address. If the eternal ramdisk does not work with the new ROM it is probably due to the way it installs: it assumes that upon a warm reset the ST leaves the memory-size system variable alone, and the physical RAM above that point intact. Does the new ROM do otherwise? About 12-bit FATs (the standard in GEMDOS floppies): With 5 sectors allocated for the FAT (as opposed to 2 in MS-DOS) we have 5*512*8/12=1706 FAT elements. Each refers to one CLUSTER, which in GEMDOS is 2 sectors, or 1K. Thus the FAT can handle a 1706K RAMdisk. This is, of course, not enough for HARD disks so they must use larger clusters --- or FATs. - Moshe Braner
c9c-eh@dorothy.Berkeley.EDU (Warner Young (WHY)) (10/11/87)
In article <2291@druhi.ATT.COM> med@druhi.ATT.COM (DrapalME) writes: >In article <1177@vaxwaller.UUCP>, cw@vaxwaller.UUCP (Carl Weidling) writes: >> >> I don't have a developer's kit. I do have Mark Williams C. >> ... >> Regards, >> Carl Weidling > >If you have MWC version 2.0, you already have what you are looking for! > > Myron Drapal > ..!ihnp4!druhi!med I, unfortunately, DONT't have MWC at all! I happen to have Alcyone C, so I would be most grateful if someone could post sources for a RAMdisk. Please not in assembly, except for absolutely vital sections. Thank you all in advance. "Warp 10: it's not just a good idea; it's the LAW!" \ / \ / Warner \ /\ / \__ / Young \/ \/ | \___|
frans@philmds.UUCP (Frans Meulenbroeks) (10/12/87)
In article <2622@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (braner) writes: >If the eternal ramdisk does not work with the new ROM it is probably due >to the way it installs: it assumes that upon a warm reset the ST leaves >the memory-size system variable alone, and the physical RAM above that >point intact. Does the new ROM do otherwise? eternal2 does work with the new (UK) roms (personal experience). However, sometimes I do have problems with the recognition of the alt and caps-lock keys. There are no problems with the reset-proof ness of eternal2 (at least if your program doesn't scribble all over memory, like mine did once). -- Frans Meulenbroeks Until 15-oct-87: Philips Distributed Realtime Multiprocessor System