Crawly Crypt Collection 1

home *** CD-ROM | disk | FTP | other *** search

/ Crawly Crypt Collection 1 / crawlyvol1.bin / utility / disk / rde_v5 / rde_v5.doc < prev next >

Wrap

Text File | 1993-08-30 | 38KB | 635 lines

RDE ( Version_5 ) - Upgrade and BugFix on RDE_Version_4. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ( Distribution to the Public Domain by kind permission of Mark Williams Company ) RDE Version 5 improves the GUI on previous RDE versions in that: i/ whenever a filename is to be chosen, it now uses a fileselector rather than the dialogue box. The advantages are obvious. ii/ On creating a ramdisk, the _precise_ desired size in Kbytes can now be typed in via a dialogue box. If 711 or 811 kbytes is requested, then the ramdisk is configured as an exact image of the 2 popular Floppy Formats (720kb and 820kb) - see RDE_V3 documentation below. iii/ When removing a ramdisk in the GUI, you are no longer "forced" to remove one of your installed disks (unless you hit the warmstart button). Of course there should have been a last chance to cancel, and now there is! BUG FIX ~~~~~~~ There has always been an obscure bug in Mark Williams' original RDY and in all subsequent RDE Versions. The symptoms are that if a "nearly full" ramdisk is saved to file and then restored, then its contents near the top end can get corrupted. Luckily this hardly ever happens in normal usage - as most people would leave empty work space in the saved ramdisk and make sure the files are contiguous (i.e. "reorganise" or "defragment") before saving. Those who have used RDE to create ramdisks that are nearly-full ( usually with "read-only" utilities) might have noticed the last few files on the disk are sometimes corrupted after loading. I am indebted to Wojciech Surowka for diagnosing the trouble and, indeed, for suggesting a cure which is now implemented. From my tests, it appears to have done the job. Basically during loading, RDE/RDY copy the contents of the saved file to high memory below PHYSTOP where the screen is. Now if it so happens that screen interrupts ( mouse movement, flashing cursor etc.) are made during the load just AFTER the last few kbytes of contents have overwritten the screen and BEFORE the ensuing warm reset, then it is clearly possible for these contents to get corrupted. The cure is, of course, to set the system byte of the Status Register so that all interrupts are disabled during the load. Ramdisks created with Version_5 retain full compatibility with all earlier RDE versions. I am not aware of any remaining bug in RDE. Documentation(s) that accompanied previous versions are appended at the end. Newcomers to RDE can find useful hints by studying them. Users are reminded that RDE only displays its full flexibility if invoked from a shell with command line arguments. RDSH (available from the archives) is a tiny, quick-loading, shell tailored to RDE's needs. The current executable is about 22 kbytes and is not "packed". If you desire to pack it to about 12 kbytes or so, I recommend either ICE (version 2.4) or PFXPAK, both of which produce MINT compatible executables. It goes without saying that neither I nor Mark Williams Co. will assume any responsiblity for whatever (dire or otherwise) consequences that may arise through the use of this software. Cheers, W. Alan B. Evans. ( August 27th 1993) ****************** PREVIOUS DOCUMENTATION WITH Version_4 ****************** Hot on the heels of my last submission of RDE ( Version_3 ), comes Version_4 with the very significant upgrade that loaded RDE/RDY ramdisks can now be removed (dropped) IN ANY ORDER WHATSOEVER. The restriction of "Last in First Out" that ALL previous versions of RDE/RDY have had is now lifted. Otherwise this has ALL the features of Version_3 and is FULLY compatible with all previous RDE/RDY ramdisks and saved ramdisk files. Unlike Version_3, I've packed RDE Version_4 with the ICE (v_2.4) packer which is MINT-compatible. You can unpack it with Marinos Yannikos' NAUGHTY unpacker if you like. Why did I submit Version_3 a week or so ago if I was working on this? Well, I WASN'T WORKING ON IT! - and the idea only occurred after the latter was submitted. I was also led to believe that this could not be done within TOS - but I persevered out of interest. After finding out by "trial and error" about OEM cruft links and the way TOS boots-up its hard disk partitions I finally could see how this (very desirable) feature could be incorporated. For those who prefer to have as much RAM as possible and work with utilities installed on RDE ramdisks (like me!) this will make life much easier. For example, I could be writing a paper within my SIGNUM2 ramdisk when I find I need to finalise some data analysis with Fortran. So I wish to load my RDE FORTRAN installation but, da*?*n it, I had forgotten to remove that CALAMUS ramdisk installation I was previously working with BEFORE loading the SIGNUM2 one and now there is no room for the FORTRAN one as well on my 4 Mbyte machine. With Version_4 it becomes possible to get rid of that CALAMUS ramdisk I've finished with to make room to load the FORTRAN without disturbing the SIGNUM2 installation at all (Of course - there will be a warm reset - so you must save your document to file on the ramdisk first - come to think of it you'd HAVE TO anyway with SIGNUM2 as it does not allow the execution of external programs from within itself. I'm sure that other RDE users can see similar benefits. This now makes me extremely envious of Falconers and TT'ers with 32 Mbytes or so. (Thanks to Ofir Gal who has verified that Version_3 works OK on a Falcon.) They could install huge applications (given that Version_3 removed the bug that previously had limited RDY ramdisks to no bigger than about 2036 kb) or a huge number of smaller applications simultaneously. I must get one of those Falcons..... but with Maximum RAM as a PREREQUISITE so that I can defragment whole Hardisk Partitions (<= 16 Mbytes) in safety on a huge suitably configured RDE ramdisk in a few seconds (minutes?) only. The only risk is in "sector copying" the defragmented ramdisk (with DFT.TOS) back to the Hardisk Partition. But this should be QUICK (few seconds) and you'd have to be unlucky indeed for the electricity supply to fail during that time!! My apologies to the archivists for bothering them again so soon after Version_3 was downloaded. But I guess they must be used to this phenomenon for I know of few authors who can discipline their minds not to continue thinking about the task that's occupied a hefty % of their "thinking time" for the previous few days - so if further good ideas occur to them....!! I guess this must be a phenomenon well-known to software archivists & justifies an appropriate "delay-time" before submissions are archived that sometimes annoys "over-keen" authors. For the curious, RDE ramdisks install themselves at the top of memory and decrement PHYSTOP to allow space. Removing a previously loaded ramdisk leaves the "stack" fragmented - and it is necessary to pull its tail up to fill the gap. However you must do this in a way that TOS will not complain about and plunge your machine into utter darkness out of which re-birth (i.e. a cold boot) is the only solution. This involves monitoring the values of several "vectors" held within RDE's bootsectors to take into account the ensuing change of addresses of the routines these vectors point to as well as altering in a different way the cruft-link pointers that RDE uses to "find" its disks etc. etc. Anyway now I've got the sums right - the whole operation happens usually within about a second and reliably. There are a few minor quirks. If you remove your "booting" ramdisk then after a warm reset booting defaults to A:\ (all this assumes you do NOT make your Hardisk (if any) boot-itself from C:\ - Rather Harddisks MUST be woken up AFTER the ramdisks have loaded - preferably from a prog. such as AHDI in the AUTO folder of a "booting" RDE ramdisk (see IQ_BOOT the intelligent booting sourcecode for a booting program that I submitted with Version_2 of RDE last year). If subsequently you reload your booting ramdisk off A:\ you will get a normal "loading" warm reset usually followed (at least with ICD Harddisks) by another warmreset after which your booting ramdisk will take over control. There is nothing to worry about in this - it is normal and your data should be intact. HAVING SAID THAT I EMPHASIZE THAT NEITHER I (nor Mark Williams Co. who developed the original RDY) CANNOT BE RESPONSIBLE FOR ANY LOSS OF DATA, ACCIDENTS ETC. THAT MIGHT ENSUE FROM THE USE OF THIS SOFTWARE. THIS SOFTWARE IS NEW! AND, AS SUCH, SHOULD BE TREATED WITH CARE (but it's passed all my tests so far - wabe). Good Luck, W. Alan B. Evans. [wabe@ukc.ac.uk] - May 27th 1993. ****************** PREVIOUS DOCUMENTATION WITH Version_3 ****************** RDE ( Version_3 ) - Some upgrades on RDE_Version_2 + some bug fixes. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ( Distribution to the Public Domain by kind permission of Mark Williams Company ) PREAMBLE: ¯¯¯¯¯¯¯¯¯ Mark Williams Co's RDY always had a few "bugs" that, on the whole, were unimportant until "larger" ST's i.e. the Mega 2 and Mega 4 machines came out. One early bug caused a failure to load on 4-Mbyte machines as the offset was not allowed for in checking whether an address is in RAM or not. This was soon corrected before MWC left the ST-scene. Another (less serious) bug prevented Ramdisks of "total" size greater than 2047kb from loading properly even on 4-Mbyte machines and this has remained in all versions of RDY/RDE to date. Seldom does one wish to have a ramdisk greater than 2 Mbytes even if we have 4-Mbytes of RAM (for we can always load a second one with another volume label) - so this bug did not trouble most users. However there are a few occasions when it is desirable to have ramdisks of size 3 Mbytes and above - and on the Falcon or TT ( I "think" RDE should work OK on these but I have not had the means to test it - and would value hearing from anyone who use it on these machines) it is possible to have so much RAM that I expect that Ramdisks of 8 Mbytes and more may soon become commonplace. Of course this opens up a quick way of reorganising (or defragmenting) hard disk partitions in a completely safe way provided they are not too big to be loaded on to the ramdisk. This is especially favourable with RDE ramdisks for they can be configured to look exactly like your hard disk in structure (excluding BGM [i.e. logical sectors sizes > 512bytes] partitions) e.g. setenv CMD MAKE ; rde SIZE=8000 FATSIZE=16 FATS=24 ROOT=50 would make an embryo ramdisk of size 8000 clusters, with 24 sectors of 16-bit Fats and ROOT directory size of 50 sectors. Then you could transfer your entire harddisk partition to such a ramdisk - using a sector copier like DFT.TOS (included) - then defragment the ramdisk which is VERY quick with Atari's CHKDISK3.PRG or Simon Poole's REORG.PRG - and then "DFT" the defragmented ramdisk back on to the partition. Alternatively, of course, if you have no defragmenting program it is almost as quick to sequentially copy your harddisk files and directories on to the ramdisk, where they will be contiguous and then DFT (or copy again) the ramdisk back to the cleared partition. THE MAIN UPGRADE - ( NO SIZE < 2037kb restriction) ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Anyway, as you'll have gathered by now, I managed to find and cure the assembler "bug" that prevented RDY/RDE's handling of large ramdisks and so RDE Version_3 is currently offered. For the curious the bug ocurred becase the loop instrucuton "dbf" only uses a 16-bit counter - a "common" oversight according to Tim King in his 68000 Assembly Language Book!! The new Version_3 is completely compatible with RDE Version_2 (released in March 92) and with the "All TOS" saved ramdisk files made with this. If you use RDE V_3 from the Desktop using the GUI, you will find that I have revised the selection of Ramdisk button-sizes to reflect the larger sizes now possible (the largest GUI-selectable size is now 3.5 Mbytes). I have included the buttons-sizes marked "720k" and "820k" which, if selected, and all default values then chosen will create your Ramdisk in two favourite "Floppy" Formats - the standard Atari "720k" double-sided format, and the 82-track, 10-clusters per track format that you get (for example if you use DCFORMAT). I have yet to experience an ST or STE for which this larger format does not work perfectly. These are useful if you want to sector copy a floppy onto a Ramdisk (for "defragmenting" perhaps?) using DFT.TOS or similar. Note that your sector copier MUST NOT copy the bootsector. DFT.TOS checks for FSIZE and FATSIZE compatability before it will copy anyway. Of course, you can also create these floppy formats from a shell (e.g. GULAM ) also with (for example) setenv CMD MAKE;rde DISK=F SIZE=711 ROOT=7 FSIZE=5 FATSIZE=12 CLUSTERS=0 setenv CMD MAKE;rde DISK=D SIZE=811 ROOT=7 FSIZE=5 FATSIZE=12 CLUSTERS=0 or, the equivalent command in RDSH would be m F 711 ROOT=7 FSIZE=5 FATSIZE=12 CLUSTERS=0 m D 811 ROOT=7 FSIZE=5 FATSIZE=12 CLUSTERS=0 ( but note that ROOT=7 , FATSIZE=12 are superfluous as these are the default values on RDE Version_3 anyway. To see what the defaults are give the argument CMD=HELP to RDE.TTP (i.e. RDE.PRG renamed to RDE.TTP ). Or, from Gulam you can enter setenv CMD HELP; rde.prg Note, in the above, I have put CLUSTERS=0, so that the ramdisk complies exactly with floppy structures. However TOS (no doubt for some obscure GOOD reason? ) always wastes 2 clusters of disk space at the high end. If you add up the number of useable sectors on a conventional floppy you will find the total is 4 short of the total "formatted" number. Mark Williams Co. incorporated an ingenious scheme into their RDY to reclaim these "lost clusters" from being wasted by TOS. Effectively it involves telling TOS there are 4 sectors more on the ramdisk than you actually have (by upping the cluster number in the boot parameter block) and then marking the last two clusters as "bad" in the FATs. This allows usage of the lost clusters and is what happens if CLUSTERS=1 is specified. By the way this also appears to work on Floppies!! - so if you can be bothered, you can make each formatted disk you have hold 2 kbytes more! - but I digress. I can think of no good reason why CLUSTERS=0 need ever be chosen ( apart from exactly mimicking other media ). So, to have a floppy like ramdisk and 2 kbytes more left-over memory, you could use setenv CMD MAKE;rde DISK=F SIZE=709 ROOT=7 FSIZE=5 FATSIZE=12 CLUSTERS=1 setenv CMD MAKE;rde DISK=D SIZE=809 ROOT=7 FSIZE=5 FATSIZE=12 CLUSTERS=1 (i.e. SIZE decreased by 2 but now with CLUSTERS=1 - the default anyway) Other Minor Mods: ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ i/ One of the useful features of RDSH was its ability to alter the Disk Drive Label of a saved RDE ramdisk file. For example you may wish to load another ramdisk which you've just "happened" to name with the same drivelabel as one you've already got loaded. The solution here would be to alder the drivelabel of the file you wish to load to a new label that's unused. Then it can be loaded and, afterwards, one would normally change the drivelabel back to its original label. Now I've included this feature in RDE_V3.1 as an additional MENU item in GUI mode. You simply select a ramdisk file and after click on the driveable button you wish its label to be changed to. RDE will check that the file is indeed a ramdisk file and report on the change made. This is also possible in the command line mode from a shell with the new command "ALTER". For example to alter the label of a saved ramdisk file SIG_RAM.PRG from I:\ to J:\ (say), just enter setenv CMD ALTER ; rde.prg FILE=SIG_RAM.PRG DISK=J and if all went well you will get a message: RDE_File: SIG_RAM.PRG | | DriveLabel I altered to J if all went well. Needless to add, it will NOT be possible to alter the drivelabels of "packed" saved ramdisk files without unpacking them. ii/ In "CREATING" a ramdisk from the GUI, you can now opt for either 12 or 16 bit fatsize. In the "Get Data on a Ramdisk" and "Save" options the only buttons now active are those that pertain to genuine RDE loaded ramdisks (and NOT ALSO those of any Hard Disk partitions that may be present as in previous Versions). iii/ There was a small format bug in older Versions of RDY\RDE that caused some ridiculous values to be output when it informed you that the set value of FSIZE (no. of FAT sectors) was too small for the SIZE of the Ramdisk and that it was adjusting it upwards to ??*?**!!. This was caused because a "long" was printed using a "%d" (i.e. word) format. This is now corrected. To set FSIZE you must be in command line invocation (i.e. shell) mode. I could not see much point in setting it from the GUI. Apart from making floppy or hard-disk compatible ramdisks, there is no point in setting it to any other value than Mark Williams Co's "least-value needed" which was the "default" value on their original RDY. iv/ I have also altered the ORDER in which the LIST of loaded ramdisks is displayed ( with the command ' setenv CMD LIST ; rde ' ) entered from a shell (like GULAM) or using RDSH.PRG (the mini-shell tailored for RDE that is already in the Public Domain). The order is now according to the order in which they were LOADED - which is useful as it reminds you which one can be removed (Dropped) since dropping must be done on a "Last in, First out" basis. If you use the GUI to remove ("DROP") a ramdisk, you no longer have to select it - the "last-loaded" is the ONLY one offered to be sacrificed. Ancilliaries & Advice: ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ A few tutorial(?) points are in order. If you wish to invoke RDE using its GUI from a shell such as GULAM, don't forget to unsetenv the CMD environment variable first - otherwise it will not load i.e. use 'unsetenv CMD ; pushd $rdedir ; gem rde.prg ; popd' which you could usefully define as a GULAM alias in your GULAM.G file i.e. set rdedir d:\ # wherever RDE.PRG & RDE.RSC reside alias g_rde 'unsetenv CMD ; pushd $rdedir ; gem rde.prg ; popd' The sector copier, DFT.TOS (included) is an upgrade on DFT.PRG that exists as part of RDUTILS in the public domain - for it now uses the largest buffer it can get (with Malloc) to do its sector copying. The previous DFT.PRG assumed you had enough left-over RAM to copy the whole disk in just 1 go. This is hardly likely even on a 4-Mbyte machine if you use the larger RAM sizes now available and they are moderately "full". I would also advise you to get DESKTOP.PRG if you wish to get the DESKTOP.INF loaded to hard disk drive C:\ (if present) from your "BOOTING" RDE ramdisk. This is essential for TOS versions 1.04 upwards. Ideally, for the latest TOS 2.06, the desktop NEWDESK.INF (or DESKTOP.INF) should at boot-time be copied from the booting ramdisk to C:\NEWDESK.INF to over-ride any previous NEWDESK.INF that may have been there. The current DESKTOP.PRG that was bundled with RDSH.PRG does not do this. Da?n!! - I'd better compile an upgrade and include it & at the same time possibly save you some hassle if you use TOS 2.06 (done! - DESKTOP.TOS, an upgrade on DESKTOP.PRG is included. It is still less than 2 clusters in size and, as a bonus, displays your TOS Version at boot-up. You'll probably get tired of this! - so the sourcecode of DESKTOP.TOS is also included so you can compile your own version of it - tailored to do some other tasks also perhaps. With older TOS'es it will work exactly as Version_1 - wabe). The "brief" documentation with the earlier version is included as this was involved no effort on my part and could be useful to first timers using RDY/RDE. See also some new comments in the sourcecode. MINT COMPATIBILITY - Careful how you "pack" it! ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ And, that's about all for now - except that the binary RDE.PRG is now included "unpacked" in contrast to some previous postings which were packed with the POMPEY packer. Unfortunately this made them MINT- incompatible, that led to a few unneccessary hiccups with some users. Incidentally this also applies to a previously posted version of RDSH - so, if yours is MINT Incompatible, unpack it with the Pompey Packer (or possibly with that "Universal Unpacker" of Marios Yannikos, NAUGHTY.PRG). If you wish to pack RDE.PRG, then I'd recommend the ICE (v_2.4) packer or PFXPAK which retains MINT compatibility. If you NEVER use the GUI, then change the name of RDE.PRG to RDE.TTP and discard RDE.RSC. Good Luck, W. Alan B. Evans, [wabe@ukc.ac.uk] - May 19th 1993. Below is listed the documentation that accompanied previous releases of earlier versions of RDE. ***************************************************************************** RDE ( Version_2 ) "ALL-TOS" compatible form with enhanced GUI ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ of Mark Williams Co.'s "RDY" Reset Survivable Ramdisk ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ( Distribution to the Public Domain by kind permission of Mark Williams Company ) This latest version of RDE.PRG is compatible with ALL TOS_versions tested to date - and so, unlike my previous RDE offering, (see documentation below) is a genuine upgrade enabling RDY Fans to painlessly upgrade to the latest TOS machines and continue to use their saved RDY installations. To load "old" saved ramdisk files on TOS 1.4 (and upwards) machines they need to be converted. This is most easily achieved using option "U" of the mini shell RDSH.PRG (see separate offering) - but could also be done by loading the ramdisk on an old TOS ST and then saving it with the new "All-TOS" RDE.PRG. Files saved with the new RDE will load without problems (i.e. bombs) on any ST. I have also slightly enhanced RDE's Graphics User Interface in that now all drive letters C:\ through to P:\ are selectable in this manner. Some parameters (e.g. FSIZE, FATSIZE, ROOT, SIZE, CLUSTERS, HELP etc.) must still be set from a shell - which is why RDSH.PRG is currently also offered (see RDSH.DOC for details) - but beginners will doubtless prefer the GUI. One novel and very useful option in RDSH is option "A" which allows the Drive Label of a saved RDE/RDY File to be altered - very useful if one wishes to simultaneously load two ramdisks saved with the same drive label! - and for changing drive labels to higher alphabetic positions to accommodate that huge new hard-disk you've just bought whose partitions insists on monopolising many of the earlier drive letters. I have also made other minor improvements which only "old hands" who are very familiar with the old RDY/RDE will notice e.g. the new RDE will not ask to Load a newly created Ramdisk if its drive letter is already used etc. Note that for an installation-dependent desktop from "booting" RDE ramdisks when disk C:\ is present on the Newer TOS machines still requires the DESKTOP.PRG utility in the "booting" ramdisk's AUTO folder (see below). I have included a new DESKTOP.PRG version with some enhanced features that is distributed with the RDSH.PRG utility (Read the DESKTOP.DOC file for details). Finally, this version obviates the need for the earlier RDY - for which I had requests from Netters on diverse occasions. Of course, this is still distributed with the Mark Williams "C" software - though they "may" soon be including an "ALL-TOS" RDY that is almost identical to this (save for "default values" that comply with their Manual). The present RDE.PRG is quite small (~11000 bytes) having been packed with the POMPEY Packer (which, though slow, produces good compaction). If the GUI is not desired, it may be renamed RDE.TTP (in the which case the Resource File RDE.RSC will not be needed). I reproduce (below) the original documentation that I wrote for Version 1 of RDE - apart from the novelties mentioned above, it still applies. Good Luck, W. Alan B. Evans, [wabe@ukc.ac.uk] - March 22nd 1992. ***************************************************************************** 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 "msh") 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?