NB: File name: MAXIDISK.DOC Revised: 1992.06.05 NB: Created by: Ulf Ronald Andersson Created: 1992.02.07 NB: NB: File purpose: to document the release of 'Revised MaxiDisk 2.2' NB: NB: Copyright: Original released as PD FREEWARE by author: Max B”hm 1987. NB: Revisions released as PD FREEWARE by author: Ulf Ronald Andersson 1992. NB: NB: NB: This is not the original documentation, which seems lost to mankind. NB: At least I have not yet found any complete archive for this utility. NB: So I have had to take the liberty of creating this DOC file, NB: since I have made some long-needed revisions to MaxiDisk. NB: As follows: NB: NB: Revision 2.0 updates of February 1992: NB: NB: 1. I have implemented the XBRA protocol for all 3 vectors used. NB: This was one of the two reasons I made this revision. NB: NB: 2. I have modified the memory protection method, so that MaxiDisk NB: now is compatible with OVERSCAN.PRG and other programs that NB: previously could crash MaxiDisk (especially when nearly full). NB: (OVERSCAN.PRG must be started after MaxiDisk to function well) NB: The need to use it with OverScan etc., was of course my other NB: main reason to make this revision (by now practically rewrite). NB: NB: 3. I have patched the BPB handling to ensure better efficiency NB: when using huge ramdisks, which old MaxiDisk hardly packed. NB: BPB is still non_standard, of course, in that it has as many NB: logical clusters as there are physical sectors, but that is NB: how packing was made transparent to the OS. NB: NB: 4. I have completely rewritten the data block allocation code. NB: The original seemed to be compiler-generated rubbish. NB: NB: 5. I have completely rewritten the pack/unpack routines, and have NB: changed the packing algorithm a bit. This makes packing a bit NB: tighter and faster, although no packing ramdisk can be FAST. NB: At present the new MaxiDisk seems to run at one eigth the speed NB: of QWIKDISK, as measured by QINDEX, which will do for me. NB: NB: 6. I have eliminated a lot of compiler-generated garbage-code, and NB: unneeded huge file arrays (that have NEVER been used !!!). NB: Also the insane program startup sequence, which turned the data NB: and BSS sections upside-down. (Really...!) NB: NB: 7. I have also patched and streamlined each and every routine that NB: remains in the program to get rid of that silly compiler stuff. NB: eg: "LEA (A0),A0" and such-like ridiculous nonsense. NB: NB: For more technical details, read the file MAXITECH.DOC . NB: NB: NB: Revision 2.1 updates of March 1992: NB: NB: Several routines were trimmed for higher efficiency, and one byte NB: in the simulated 'boot' sector was adjusted. NB: NB: NB: Revision 2.2 updates of May 1992: NB: NB: 1. The routine that searches for the MPB pointers of TOS has been NB: improved, and now functions on all known TOS versions. NB: NB: 2. Some sector handling routines have been improved, though this NB: may be masked by the delays caused by packing. NB: NB: 3. MaxiDisk 2.2 has been tested error-free on several TOS versions NB: ranging from TOS 1.0 through TOS 1.4 to KAOS 1.4.2. NB: Since no TOS-dependent features are used it should always work. NB: Unfortunately the present release of TOS 2.6 has a bug in the NB: code for 'warm' reset, such that no reset-proof ramdisk seems NB: to be possible under this TOS !!! (I will investigate this) NB: NB: NB: I will surely improve the program even further, but at present I NB: think I have achieved what I set out to do. Which was to revive NB: this great idea of a packing ramdisk, in a version acceptable by NB: modern standards and compatible with other modern programs. NB: NB: The remainder of this file is the best near-original DOC's I have. NB: Where I have discovered errors in it, or made important revisions, NB: I have inserted notes like the one immediately below. NB:URA: This line shows how my notes will appear below. ---------------------- Here follows older text ------------------------------- Cologne , West Germany , July 4 , 1988 ---- This file is a translation of the original German README file, written by Max B”hm, the author of this exceptional public domain program. Translated by COLONIUS. Comments made by the translator are within brackets. MAXIDISK.PRG installs a resetproof ramdisk, which compresses the files stored in it. It is usually possible, to store about 750 kB in a 500 kB ramdisk! This version works with all versions of ROM based TOS, including the new Blitter TOS of the MEGA STs. Any memory size, up to 4 megabyte, is supported. (Although it makes little sense to use a ramdisk on a 512 kB system.) MAXIDISK.PRG should reside in the AUTO folder on your boot disk, although you may also install the ramdisk from the desktop after booting your ST. (In this case you should rename the program to MAXIDISK.TOS, since it is not a GEM application and will cause trouble if started as one. It must, however, carry the .PRG extender to autoboot from the AUTO folder.) The first thing MAXIDISK.PRG does, is to check if there is already a MAXIDISK installed. In this case, you are informed about the size and the assigned partition name and the installation terminates. After this, MAXIDISK checks for MAXIDISK.INF on drive A and B (if started from floppy) or on the logical drive (partition) it was started from. {Paul Varn note: If MAXIDISK.INF is not found, you are requested to enter a size and partition letter.} If you would rather abort the installation of the ramdisk after starting MAXIDISK.PRG, simply hit return without entering a numeric value when prompted to enter the desired ramdisk size. A message will inform you that the ramdisk was not installed. Once the MAXIDISK is installed, it is resetproof. This means that the contents of the ramdisk will survive the reset, not the driver program itself. You must start MAXIDISK.PRG after a reset, to be able to access the data in the ramdisk. If you fail to do so, the ramdisk will still remain intact over any number of "warm" resets, but it will seem to be empty (0 bytes in 0 files) until the MAXIDISK driver is reinstalled. {Paul Varn note: Actually, you must use a re-named version of Maxidisk called: MAXIDISK.TOS. When you do this, the screen will just blink and return to the desktop. A symptom of a re-set fault is that when you access the drive, the bytes are ZERO with NO FILES SHOWN. Don't worry. After running MAXIDISK.TTP, everything will return to normal. However, it IS possible to get such a severe system crash, that Maxidisk won't servive. This has been rare for me. If you re-boot from the same disk or drive that Maxidisk was started from, it will take care of itself and all will be normal without the need to re-run Maxidisk.} MAXIDISK.INF is an ASCII file which you may use to install the maxidisk automatically after MAXIDISK.PRG has been invoked. MAXIDISK.INF contains the size of the ramdisk, the drive letter which shall be assigned to the ramdisk (C through P) and the names of programs that should be started after the ramdisk has been installed. (You may edit this file with any text editor or word processor that allows you to save plain ASCII files. If you should use 1st Word (any version), be sure to switch off the word processor mode. You may also delete MAXIDISK.INF entirely, if you prefer to enter size and drive number manually.) The example MAXIDISK.INF file installs a 500 kB ramdisk as drive D, copies the contents of the folder COPY_IT to the ramdisk and finally starts SET_TIME.TOS. (see also COPY.TTP and SET_TIME.TOS) {Paul Varn note: Unfortunately, the person who uploaded to version of this ARC that I found, corrupted the .INF file so that the suggested use of the auto-run feature was not shown. I've tried several ways to do this and have not found it. I prefere to use HEADST by CODEHEAD anyway.} NB:URA: Better instructions are found further on in the text. The following files are not required for the operation of the Maxidisk, but are utilities that are nice to have. COPY.TTP is used to copy files into the ramdisk on a coldstart bootup. The required parameters are the names of the source and destination folders. (Example: A:\COPY_IT D:\ will copy all files within the folder "COPY_IT" on drive A to the main directory of drive B. It is a good idea to include the line COPY.TTP A:\COPY_IT D:\ in MAXIDISK.INF to automate the procedure.) SET_TIME.TOS allows you to set the ST's internal clock. {Paul Varn note: I see no reason to keep this program around. The clock setter that came with my internal battery clock works fine. This is a manual setter. You might do away with it.} NB:URA: Here I agree with Paul. My bbu-clock (patched keyboard) is always NB:URA: initialized by AUTOTIME.PRG, so a manual setter that boots up NB:URA: and won't let me exit without entry (or it resets my clock), NB:URA: can really be a pain in the you-know-where. COPY.C and SET_TIME.C contain the C source code of COPY.TTP and SET_TIME.TOS. These files are contained in a seperate .ARC file which you may download or not. {Paul Varn note: Again the uploader didn't bless us with these files. It's not my fault they are not there.} NB:URA: I have managed to find some copies of these source files, NB:URA: so I have included SET_TIME.C in my MaxiDisk archive. NB:URA: But since I have ported COPY.C to Devpac 2 assembler NB:URA: to create an improved COPY.TTP, COPY.S replaces COPY.C ! NB:URA: Nor do I see any reason to supply the older COPY.TTP. NB:URA: The new one copies identically, is faster, smaller, and NB:URA: has more useful screen displays. {MUST} MAXIDISK.INF, COPY.TTP and SET_TIME.TOS should reside in the root directory of the same drive (either floppy or hard disk) as MAXIDISK.PRG. If you have two disk drives and MAXIDISK.PRG is not started from hard disk, both drives will be checked for the MAXIDISK.INF file. NB:URA: Actually only MAXIDISK.INF must be in the root directory. NB:URA: More on this subject below: Known Problems: none, so far -- at least if you rename MAXIDISK.PRG to MAXIDISK.TOS if you start it from the desktop. If you boot in 40 column mode, the display will be somewhat garbled, but the program works fine nonetheless, so this is not assumed to be a problem. NB:URA: There were indeed some serious problems with the old MaxiDisk. NB:URA: The garbled display mentioned here, was NOT one of them though. NB:URA: In fact I have never seen it. (some other version? German?) NB:URA: But if you are using OverScan (Isn't everyone (why not?)) NB:URA: then you can NOT start MaxiDisk after booting OverScan.PRG. NB:URA: It will seem to work, but probably end in a 'bomb'-raid. NB:URA: The new MaxiDisk (unlike the old) works very well with OverScan, NB:URA: but must precede OverScan.PRG in the boot process. Disclaimer: This software and its documentation are in the public domain. You may copy them freely for non comercial purposes only. No warranty whatsoever is made regarding the performance of this program and the accuracy of its documentation. In other words: use it at your own risk! Problems , Suggestions etc : EMAIL to username COLONIUS on DELPHI. Original Program and all coding by: Max Boehm Im Engelbrauck 5 4670 Luenen West Germany Conversion to the English language by: Stephan Muhs Wilhelmstr. 51 5000 Koeln 60 West Germany (Username Colonius on Delphi) Maxidisk addendum by Paul Varn updated 12/19/90 I found a couple of problems using the auto-copy TTP program while running Maxidisk from the auto folder mainly due to a poor explanation on the part of the translator as concerns the .inf text file syntax. Some experimenting provided the following guideline for very flexable usage: The example above---COPY.TTP A:\COPY_IT D:\ ---will copy the named directory (folder) to the D drive creating the COPY_IT folder there in the process, AND any files contained within the directory to the D drive. When I use the program ALLADIN for the ST to call GEnie, I set up the boot with this MAXIDISK.INF file in the boot directory; 400k C COPY.TTP A:\D C:\ The folder "D" on my boot disk contains all the message and working files Alladin normally expects to see in a folder named DATA. (I've modified the Alladin program to allow this). Now all these files will be in the folder named "D" in the C ram disk. Here are some COPY.TTP command lines that will do some other copying tricks; COPY.TTP A: C: (This will copy ALL the files including INTACT FOLDERS to the ram disk C.) COPY.TTP A:\COPY_IT C: (This will copy all the files in the COPY_IT folder to the ROOT of ramdisk C. with no folder created.) COPY.TTP A:COPY_IT C:\COPYALL (Will create a folder COPYALL in the C ram disk and copy all the files from COPY_IT to there.) I have not found a way to copy individual root files. Easy to solve the problem by putting them in a folder to be copied. Note that the author stated that COPY.TTP SHOULD be in the boot root directory. SHOULD is really a MUST or COPY.TTP will not be found! NB:URA: No, that is incorrect, MaxiDisk has always been able to find the NB:URA: programs in folders, PROVIDED that the full path is specified NB:URA: with each filename in MAXIDISK.INF ! NB:URA: In case of doubt I should also add here that the examples given NB:URA: above are equally valid for the new version of COPY.TTP To figure a rule of thumb for the size ram disk to make, calculate a ram disk about 20% smaller than the total number of files for a rough start. After copying, see how much room you have left and then make adjustments. Some of the size you create is used by the program. NB:URA: Well, the overhead costs of FATs packing maps etc. are a bit hard NB:URA: to figure since they vary with disk size in different ways. NB:URA: But as he says... Try it!, see what happens, then adapt. NB:URA: If you do need specifics you should study MAXITECH.DOC instead. A hint to MAXIMIZE ram disk space. Set your file selector (or desktop) to display files by SIZE so the largest files are sorted to the top. This way, the largest files are copied first down to the smallest files. As the files get smaller, Maxidisk optimizes more. You might get two 250k files into a 400k ram disk. If you had one 250k file, and 8 25k files, you'll get them all in there with room to spare (up to 40% compression). I've seen situations where I've put in a 10k file when there was 20k left in the the ram disk, and saw afterwards that there was 18k left. To get this results during boot-up, copy these files to the folder to be copied with your system set to display size. COPY.TTP will copy the largest first. NB:URA: Sorry, but Paul has confused things! The reason small files SEEM NB:URA: to be packed better is because on disk they eat space in 1Kbyte NB:URA: chunks, even if the file is only a hundred bytes or less. NB:URA: MaxiDisk, however, only pretends to use the normal clusters, so as NB:URA: to be accepted by the OS. Internally MaxiDisk uses custom-built NB:URA: linked chains of packed data-blocks, with the same packing method NB:URA: for all sectors, regardless of whether its file was small or large. NB:URA: Also, OS checks available clusters before starting to write data. NB:URA: There may be plenty of RAM for the packed file, but if the free FATs NB:URA: seem insufficient for the file, OS won't even try to store it. NB:URA: So it is true that storing it earlier might solve problems, NB:URA: but because OS demands this sequence, whereas MaxiDisk doesn't. NB:URA: Another way to solve it is by using a copier with a smaller buffer. NB:URA: Then OS will grant access as long as there are FATs left for one NB:URA: more buffer-load, and this may be enough for the file since each NB:URA: load will consume less FATs than OS can expect. Final note: This wonderful program has been around for a couple of years. Although I've distributed it widely in my area, it hasn't caught on for some mysterious reason. I've seen every PD and commercial ST ram disk, and in my opinion nothing compares to this. NB:URA: Well, the reasons were not all that mysterious, since the protection NB:URA: of RAM ignored "_memtop", and treated "phystop" inappropriately. NB:URA: This made it prone to crash with OverScan.prg, and other programs NB:URA: that need these pointers to be correctly balanced aginst MPB's. NB:URA: Also the lack of XBRA protocol made for poor program cooperation. NB:URA: But all this has now been fixed, so go ahead and use it. NB:URA: One last warning: If you use disk cache, make sure it boots up NB:URA: BEFORE MaxiDisk, so it can not include it in the cache'd drives. NB:URA: Cache could hide the space released by packing, so that the OS NB:URA: could never use it. NB:URA: I always boot CACHEnnn.PRG before MaxiDisk, without any problems. -------------------- End of file MAXIDISK.DOC --------------------