Crawly Crypt Collection 1/crawlyvol1.bin/utility/disk/maxid_22/maxitech.doc

Text File | 1992-06-04 | 14KB | 267 lines

;File name:    MAXITECH.DOC        Revised:    1992.06.05
;Created by:    Ulf Ronald Andersson    Created:    1992.02.07
;
;File purpose:    To document the release of 'Revised MaxiDisk 2.0',
;   - " -    and provide some deeper details than MAXIDISK.DOC does.
;
; Copyright:    Original released as PD FREEWARE by author:  Max Böhm  1987.
;         Revisions as PD FREEWARE by author: Ulf Ronald Andersson  1992.
;
;
; As may be apparent from the general layout of this text, most of it had its
; origin in my source-file comments for MAXIDISK.S, and its support files.
; Some of this information will of course duplicate that in MAXIDISK.DOC,
; but much of it is found in this file only, since I believe that few users
; of MaxiDisk will care very much how it works, as long as it is reliable.
;
;
;    Revision 2.2 updates of May 1992:
;
;    1. The routine that searches for the MPB pointers of TOS has been
;       improved, and now functions on all known TOS versions.
;
;    2. Some sector handling routines have been improved, though this
;       may be masked by the delays caused by packing.
;
;    3. MaxiDisk 2.2 has been tested error-free on several TOS versions
;       ranging from TOS 1.0 through TOS 1.4 to KAOS 1.4.2.
;       Since no TOS-dependent features are used it should always work.
;
;       Note, however, that COPY.TTP may fail on some ancient TOS's,
;       because of the bug in the gemdos function 'Malloc'.
;       Such failure only means that some files will be left uncopied.
;
;       Unfortunately the present release of TOS 2.6 has a bug in the
;       code for 'warm' reset, such that no reset-proof ramdisk seems
;       to be possible under this TOS !!!  (I will investigate this)
;
;
;    Revision 2.1 updates of March 1992:
;
;    Several routines were trimmed for higher efficiency, and one byte
;    in the simulated 'boot' sector was adjusted.
;
;
;    Summary of changes from old MaxiDisk to Revised Version 2.0:
;    ------------------------------------------------------------
;
;
;    1. I have implemented the XBRA protocol for all 3 vectors used.
;       This was one of the two reasons I made this revision.
;       The affected vectors are:
;       1) hdv_bpb        called by OS to identify disk format
;       2) hdv_mediach    called by OS to detect media changes
;       3) hdv_rw        called by OS for all read/write functions
;       During boot MaxiDisk checks if phystop points to the legal
;       identification code for MaxiDisk, which means warm boot.
;       But regardless of whether a warm or cold boot is indicated,
;       all 3 XBRA chains are tested to see if any XBRA named "MAXI"
;       is already in use.  If so, no new vectors are installed, and
;       an error message is given stating this situation.
;
;    2. I have modified the memory protection method, so that MaxiDisk
;       now is compatible with OVERSCAN.PRG and other programs that
;       previously could crash MaxiDisk (especially when nearly full).
;       (OVERSCAN.PRG must be started after MaxiDisk to function well)
;       The need to use it with OverScan etc., was of course my other
;       main reason to make this revision (by now practically rewrite).
;       This modification consists of several parts.
;       1) _memtop is adjusted in addition to phystop
;       2) the RAM block reserving high RAM is shrunk, and then released
;             using normal Mfree, so no garbage MPB's remain.
;       3) All data between _memtop and phystop is moved down into the
;          new corresponding area, without assumptions about screen size.
;       4) _v_bas_ad is adjusted without assuming either any screen size
;          or identity with _memtop, only that it lies somewhere between
;          _memtop & phystop, and the move will be a multiple of 512.
;          The move is not made direct in hardware, nor by calling XBIOS,
;          nor by poking _v_bas_add.  I simply store the new value in the
;          'screenpt' variable and await a VSYNC. Any screen handler which
;          has the physical screen in some other, immovable, area need
;          only ignore 'screenpt', so hopefully most large screens are OK.
;       5) A (hopefully) TOS independent routine searches all of OS RAM
;          to find the MPB root pointers enabling most of the above.
;          Should it fail, an error message will be given.  This does
;          NOT have to mean TOS incompatibility.  It may be due to some
;          earlier boot program messing with MPB's or _memtop, so do try
;          rearranging the auto folder in such cases.
;
;    3. I have patched the BPB handling to ensure better efficiency
;       when using huge ramdisks, which old MaxiDisk hardly packed.
;       BPB is still non_standard, of course, in that it has as many
;       logical clusters as there are physical sectors, but that is
;       how packing was made transparent to the OS.
;       Internally MaxiDisk uses linked packed data blocks of free size,
;       so the loss of space due to cluster size never occurs.
;       The packing itself also makes RAM storage more efficient, so that
;       the extra clusters' FATs originally marked BAD can be released,
;       simply by marking these clusters as FREE in the FAT sectors.
;       But to do so the FAT sectors and internal data block pointers
;       must be dimensioned to handle more data than the physical size.
;
;    4. I have completely rewritten the data block allocation code.
;       The original seemed to be compiler-generated rubbish.
;       It did work, but inefficiently, so I replaced it with a better
;       routine of my own design.  The main task it accomplishes is
;       to reclaim blocked ram by fusing released data block chains
;       into the chain of free blocks.  But the old routine did not
;       always succeed in also fusing all adjacent blocks, so as to make
;       larger contiguous data blocks, and releasing some block links.
;       The new routine always does this, so whenever you clean out all
;       files from MaxiDisk, the data blocks all fuse into one huge block.
;       Thus you can always start over without any remaining fragmentation.
;
;    5. I have completely rewritten the pack/unpack routines, and have
;       changed the packing algorithm a bit. This makes packing a bit
;       tighter and faster, although no packing ramdisk can be FAST.
;       At present the new MaxiDisk seems to run at one eigth the speed
;       of QWIKDISK, as measured by QINDEX, which will do for me.
;       To be specific, each two-byte packing code, can now represent
;       a sequence of up to 64 bytes instead of the original 63 bytes.
;       Nonpacked sequences are limited to 128 bytes instead of 127.
;       A special marker has been implemented to allow completely
;       nonpacked sectors, used whenever packing proves inefficient.
;       So regardless of data complexity, you always have room for at
;       LEAST so much data as is presently indicated by the free FATs.
;
;    6. I have eliminated a lot of compiler-generated garbage-code, and
;       unneeded huge file arrays (that have NEVER been used !!!).
;       Also the insane program startup sequence, which turned the data
;       and BSS sections upside-down.  (Really...!)
;
;    7. I have also patched and streamlined each and every routine that
;       remains in the program to get rid of that silly compiler stuff.
;       eg:    "LEA    (A0),A0"  and such-like ridiculous nonsense.
;
;    8. I have added a simulated "boot" sector, since that area contains
;       the information which OS floppy routines use to boot their BPB's.
;       Programs that circumvent GEMDOS sometimes access this data,
;       instead of using BIOS Getbpb. Such programs will not work with
;       ANY RAM disk which do not initialize this area.  MaxiDisk now
;       sets the "boot" sector according to its current size in RAM, this
;       has been tested with MemFile 3.0 which can now access MaxiDisk
;       through the sector editor, something not possible before.
;
;    9. I have amended the 'hdv_mediach' routine to flag '1' on each call
;       that occurs directly after MaxiDisk has altered the allocation of
;       free FAT's. This flag is returned only on each first such call.
;       Its purpose is to force any programs that try to preallocate FAT's
;       to recognize the need to read the FAT sectors again.  This has not
;       yet been extensively tested, but few programs show the need for it.
;       It may help prevent cache'ing programs from hiding packing.
;
;NB: As of the present version (Feb 20 1992), I am not aware of any problems.
;    Some will probably crop up later on, as more users test it.
;    I can only test it against such software as I have, so users with
;    different interests may have a better chance at finding faults :-(
;    All problems that I have seen with other RAM disks have at least been
;    removed or kept out of this MaxiDisk, and the code is much clearer and
;    easier to work with since I removed the last traces of the compiler.
;    Thus I am confident of being able to fix future problems, if they come.
;
;
;    I will surely improve the program even further, but at present I
;    think I have achieved what I set out to do.  Which was to revive
;    this great idea of a packing ramdisk, in a version acceptable by
;    modern standards and compatible with other modern programs.
;
;
; Below follows an assorted mix of remarks and information:
;
; Original MaxiDisk seems to have been created with a C compiler.
; The startup code extended the BSS area with $2000 bytes stack,
; then moved the contents of the DATA area to the end of the
; original BSS area and zeroed the remainder of both areas.
; A4 was set pointing to the moved data, which were strings,
; so strings were indexed positively, other STATIC's negatively.
; Several Kbyte there were devoted to C IO functions not used !
; A6 was used for allocation of AUTO data.
; All this has been abolished, except for the use of A4 and A6.
; The use of A4 is altered, so all indexes are positive.
; DATA and BSS sections now follow standard.
;
;
;
; MaxiDisk high memory variable offsets, relative to phystop
;
    RSRESET
_maxi_date        rs.l    1    ;long BCD identification date == MAXIDATE
_maxi_drive        rs.w    1    ;word MaxiDisk drive number (0..$1A)
_maxi_size        rs.w    1    ;word MaxiDisk Kbytes data capacity
_maxi_CHAIN_p        rs.l    1    ;-> First free block in data block area
_maxi_dspace        rs.l    1    ;long == free space in data blocks
_maxi_pspace        rs.l    1    ;long == space held by free block pointers
_maxi_reserve_1        rs.l    1    ;RESERVED for future changes (BEWARE)
_maxi_reserve_2        rs.w    3    ;RESERVED for future changes (BEWARE)
_maxi_bpb        rs.w    9    ;9 words BPB data
_maxi_MAP        =    __RS    ;map of data block pointers for logical sectors
_maxi_headend    = _maxi_MAP
;
; twice as many logical sectors may be used, than would be for unpacked data
; so the number available is dependent on how data can be packed.
;
;
; The BPB is non_standard, in that twice the number of physical clusters
; is used for "bpb_data_clusts". Those not available have FATs = $FFF7 .
; As clusters are stored in packed format, these "BAD" clusters can then
; be released, by changing their FATs to $0000 (free).  (INTEL format !)
; Unfortunately, the original allowed packing only on small RAM disks,
; since insufficient extra FATs and map pointers were added to large ones.
; This seems to have caused some confusion amongst the subroutines, as to
; whether "bpb_data_clusts" means sectors or clusters available.
;
; I have fixed it so all sizes use "bpb_data_clusts" at twice the size
; of the physical data area requested, with the same number of map pointers.
; This means all sizes have an extra overhead cost, but this is compensated
; for by the area gained through packing.
; EG:    Size requested        = 1200 Kbyte    = 1 228 800 bytes
;    Data with worst packing    = 1200 Kbyte    = 1 228 800 bytes
;    Total RAM cost        = 1256 Kbyte    = 1 286 144 bytes (excl TPA)
;    Stored test data    = 1586 Kbyte    = 1 624 652 bytes
;    Data with ideal packing = 2400 Kbyte    = 2 457 600 bytes
; This was tested with the files on my program testing diskette, which is quite
; dominated by program files. Text files should pack even tighter.
;
; Some rules of thumb follow:
;
; 1. Data room will always achieve the size you requested in booting,
;    even if no effective packing can be done. (eg: many LZH-files)
;
; 2. RAM cost will be approximately requested size + 5% + MaxiDisk TPA.
;    The TPA is presently appx 12 Kbyte.  No other RAM costs can occur
;    once MaxiDisk is running, it only Malloc's during initialization.
;
; 3. If you expect to have a normal mix of files (not ONLY LZH archives!),
;    you can expect a useful area well over request_size + 25%.
;    Note that this is appx total RAM cost + 20%, so it may even then be
;    possible to have data exceeding total RAM size on your computer !!!
;
; 4. Simpler data gives better packing, so pure text files may well approach
;    the absolute limit of twice the request-size.
;
; 5. The only case when stored data will not achieve the requested size, is
;    when many very small files use up all FAT marks. This will prevent OS
;    from knowing that any area is free, since OS only understands clusters.
;
;
; I can not promise to supply any help or advice on request since, after all,
; this is freeware.  I may have to devote my time to earning som money too.
; Still, if I have the time, and feel in the mood, I might try to help out.
; In case you wish to reach me, my address is as follows:
;
;    Ulf Ronald Andersson
;    Höders Väg 7
;    S-145 70  Norsborg
;    Sweden
;
; (In case you are unsure about nordic characters, use 'Hoders Vag 7'.)
; (This is of course incorrect, but will be understood by post office.)
;
; For cases of dire emergency, my phone number (within sweden) is:
;
; 0753 - 84 105
;
; (I believe foreign callers need to remove the initial zero though.)
;
       -------------------- End of file MAXITECH.DOC --------------------