RDE - STE-Compatible form of Mark Williams Co.'s "RDY" Ramdisk. ( Distribution to the Public Domain authorised by MWC [Doug Peterson] Jan 91) Let it be clearly herein stated and understood that I can assume no responsibility whatsoever from the use of this modified software - and, as MWC have authorised its PUBLIC DOMAIN distribution WITHOUT benchtesting my modifications, neither can they be held responsible for any unforeseen adverse effects consequential to its use. Alan Evans (Email: wabe@ukc.ac.uk) Mark Williams C's "RDY" configurable, saveable-with-contents-to-file, self-loading, eternal ramdisk utility has, from its inception, reigned supreme amongst sophisticated reset-survivable ramdisks. As fans of "RDY" will know, you can have as many RDY-ramdisks simultaneously loaded as volume letters allow and further one can be made a "booting ramdisk" so that the ST (on warm reset) will boot from the auto-folder present on the "booting" ramdisk. In fact, since I purchased Mark Williams C (version 2.1.7 on disk label) in 1987 and thereby found how convenient an installation of that software that "RDY" afforded, I naturally used it to install ALL my various ST packages (Wordplus, Signum, Prospero Fortran, Degas Elite etc. etc.) on "booting" RDY disks stored as rather large executable (.PRG) files (which nevertheless load very quickly) on floppies. Since those days the advent of "executable" packers such as PACK and now the Lharc based PFXPAK has not only meant that the executables one puts on the ramdisk can be shrunk in size but the saved (.PRG) ramdisk files can themselves be packed ( reasonably quickly with PFXPAK - but don't try it with PACK-ICE!!) - which made large installations possible on a single floppy (I normally format to 82 tracks and 10 sectors giving 820 kbytes using Double Click's DCFORMAT - and have experienced next to no failures). In this way (with PFXPAK) I have installed the ENTIRE Mark Williams C (v_3.0) plus their C-Source Debugger and Resource Editor on a Single Floppy! (except I used the smaller (and better?) Gulam shell rather than "me") which loads in about a minute onto my Mega ST-4. Who needs expensive, troublesome hardisks? Recently I decided to "upgrade" and buy myself an STE (with 4 Mbytes) for home use. Imagine my dissappointment when I then discovered that none of my numerous "RDY" installations worked - "bombs" appeared each time they tried to load. I FAXED Mark Williams Co. to ask if there was an upgrade that worked on the Rainbow TOS 1.6 - only to be told in one brief sentence that, as I have the sourcecode, I should HACK out a solution to the problem myself! True I had the sourcecode (but only that which came with version 2.1.7 - which would not work satisfactorily on Mega-4 machines - when I upgraded to version 3.0, MWC supplied a new "rdy.prg" binary that had cured this Mega-4 bug but supplied no sourcecode for the new version. So much for so-called "Software-Support" - despite my MWC manual boasting of "SOFTLINE - Telephone Support" to registered users (such as I!). Neither did I understand the differences between the new TOS and previous TOSses(?) - and I really thought it unreasonable that MWC appeared not to care at all for its dedicated clientele - as this just was not a trivial problem in C but caused by Operating System changes that are kept secret from "amateurs" like myself and only revealed to "Sofware Developers" who pay a substantial sum for the priviledge (How else would they keep abreast of amateurs?). Despite my annoyance at MWC's response to my plight, I hated more the prospect of not being able to use my "RDY" installations on my (otherwise very satisfactory) new STE - and so I began to HACK. As you can see I have been successful - the trouble being traced to RDY's "non-standard" RESET procedure. Atari UK, despite their willingness to help - simply could not advise me of the proper RESET procedure - but at a Computer Show in London early this New Year, I mentioned this to Mike Vedermann (of Double-Click Software) and, immediately he informed me that, by definition, the required RESET Vector can ALWAYS be found by *((char **)0x4) - which is required by the 68000 assembly code - which turned out to be the vital info I needed. Since Mark Williams Co's Doug Peterson had informed me that "RDY" is now "PUBLIC DOMAIN" - I asked MWC (via Doug Peterson) for permission - which swiftly forthcame - to release this STE-compatible version of "RDY" to the PUBLIC DOMAIN Networks in order to save other "RDY"-Fans the hassle of similarly spending a lot of time "hacking about" to get their installations to work - possibly without eventual success. It is rather important to avoid confusion with "RDY", as the STE-version will NOT work satisfactorily on the older TOSses (to version 1.2) - which is why I have called the STE-compatible version "RDE" (I never could fathom what the "Y" in "RDY" stood for anyway!). If you try "RDE" with the older TOSses "bombs" will result. So herin please find "RDE.PRG" and its resource file "RDE.RSC" - but see below. "RDE.PRG" is PFXPAKed as this reduces it to about 11,798 bytes rather than 17865 or so - you can recover the unpacked binary using the latest "lharc" or by "pfxpak -u rde.prg bare_rde.prg" . There is another small problem. It appears that the new RAINBOW TOS will insist on taking its DESKTOP.INF from the "C"-drive if there be one despite booting from the auto folder of the booting "RDE" ramdisk. So how do you get an installation-dependent desktop? My solution is to save your tailored "DESKTOP.INF" file on your "booting" RDE installation (as with previous TOSses) - but, now be sure to include the little utility "DESKTOP.PRG" in the auto folder. On boot-up this checks to find if DRIVE C:\ exists, in the which case it copies the DESKTOP.INF file on the ramdisk to "C:\DESKTOP.INF" - else it does nothing. This will OVERWRITE any DESKTOP.INF there may be on C:\ however - so the next time you boot-up your system from a floppy disk A:\ (with AHDI.PRG in its AUTO folder) you may get a strange desktop. If you care about this, copy your preferred boot-up DESKTOP.INF to your "boot-up" (A:\)floppy disk - and put DESKTOP.PRG in its AUTO folder also - but after "AHDI.PRG" naturally. Oh, and FINALLY, I should mention that I have altered some of the "defaults" of "RDE" - as compared with the original "RDY". As fans will be aware, "RDY" recognises several "Environment VARIABLES" and, because of this, it is optimal to invoke it from a shell like Gulam - in the which case you might as well rename it "rde.ttp" and discard "rde.rsc". As you can discover with the shell command (entered from "me" or Gulam): setenv CMD HELP;rde the new default settings and list of all Environment VARIABLES is as follows: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ rde - rebootable ram disk Copyright 1987, Mark Williams Company, Chicago commands passed in the environmental variable 'CMD' LIST - provides a list of installed RAM disks. MAKE - constructs a new RAM disk executable binary. LOAD - loads a saved RAM disk 'FILE' into memory. SAVE - saves active RAM disk 'DISK' with its contents to 'FILE'. DROP - removes an active RAM disk from memory HELP - presents information. parameters passed in other environmental variables DISK - drive identifier for RAM disk (default = G). SIZE - size in kilobytes of the RAM disk data area (default = 200). ROOT - size in sectors of the root directory (default = 7). FILE - file name for RAM disk image (default = rdedisk.prg). BOOT - should the disk install itself as the boot device (default = 0). FATSIZE - should the disk use 12- or 16-bit tables (default = 12) CLUSTERS - should the disk recover two lost clusters (default = 1) FSIZE - specify the number of FAT sectors (default = least needed) ______________________________________________________________________________ Note I have changed the default drive identifier to G:\ (from C:\ - after all many ST'ers now DO have Hard Diskdrives) for when a new ramdisk is made (setenv CMD MAKE). The default FATSIZE is now 12 bits (rather than 16) so that "RDE"'s fats and disk-sectors correspond to nearly all floppy formats. Usually on most floppies each FAT table occupies 5 sectors so, if you want to configure your "RDE" like a floppy (apart, of course, from "RDE"'s rather special bootsector - ensure that you setenv FSIZE 5 before MAKEing the ramdisk - otherwise "RDE" will choose its own FSIZE - which depends on the SIZE of the ramdisk that is made. For some reason - the maximum size of ramdisk possible appears to be 2 Mbytes (even on Mega-4's or STE-4Mbyte). Let me hasten to add that this is the case with the original "RDY" as well as "RDE" also. If this is a "bug" it is to do, at least partially, with the FSIZE value that is chosen. Here are a few useful "RDE" or "RDY" commands to help the uninitiated to get used to this most sophisticated piece of software that is now "PUBLIC DOMAIN" 1/ setenv CMD MAKE;setenv DISK H;setenv BOOT 1;setenv SIZE 900;rde OR rde CMD=MAKE DISK=H SIZE=900 BOOT=1 (makes an embryo "booting" ramdisk H:\ of size 900k as the "default" filename "rdedisk.prg". Simply executing this loads the ramdisk). Note the second command is shorter and "should" achieve the same end (but in my experience it is, on the whole, better to setenv the environment variables before calling "RDY"). 2/ setenv CMD DROP;rde DISK=H (removes ramdisk H:\ - which is followed by a warm reset) 3/ setenv CMD SAVE;setenv DISK H;setenv FILE c:\mwcram.prg;rde OR rde CMD=SAVE DISK=H FILE=c:\mwcram.prg Saves the ramdisk H:\ with all its contents to the file "c:\mwcram.prg" onto a hard disk C:\ presumably - but C:\ "could" be another RDE ramdisk, for example!) etc. etc. Good Luck, Alan Evans, University of Kent, Canterbury, Kent, CT2 7NR, UK. ( Email: wabe@ukc.ac.uk ) PS: My factual account above, which underlines the farcical MWC's "software support" for the ST that now seems to exist, probably arise (as knowledgeable 3rd parties "reliably" inform me) because MWC have now "given- up" developing software for the ST and have alledgedly moved on to financially-lusher pastures - I hope these rumours prove to be without substance ( not that I wish any financial hardship on MWC you understand!! - but, rather, simply bemoan the lack of any future prospects of more elegant and masterly software contributions to the ST-scene as this gifted Software House have come up with in the past). MWC's generosity in making "rdy" PUBLIC DOMAIN - and permitting this modified "rdy" to be distributed deserves the HIGHEST COMMENDATION - even though this generosity - if the rumours be true - "might" have stemmed from a guilty conscience re. ST support? Who cares? - facts are facts - and things are seldom ENTIRELY good or bad, are they.