MaxiDisk

Search
Votes / Statistics
Rating 
N/A
Hits: 314
Downloads: 196
Votes: 0
My Atarimania
Comments (0)

Screenshots - MaxiDisk

MaxiDisk atari screenshot

Information - MaxiDisk

GenreTape / Disk / Cartridge UtilityYear1996
Language[unknown]PublisherST Format
Developer[n/a]Distributor-
ControlsMouseCountryUnited Kingdom
Box / InstructionsEnglish, GermanSoftwareEnglish
Programmer(s)

Anderson, Ulf / Böhm, Max

LicensePD / Freeware / Shareware
SerialST TypeST, STe / 0.5MB
ResolutionMedium / HighNumber of Disks1 / Double-Sided
Dumpdownload atari MaxiDisk Download / MSAMIDI
Protection

Instructions - MaxiDisk

 File name:	MAXIDISK.DOC		Revised:	1992.06.05
 Created by:	Ulf Ronald Andersson	Created:	1992.02.07

 File purpose: to document the release of 'Revised MaxiDisk 2.2'

 Copyright:	Original released as PD FREEWARE by author:  Max Böhm  1987.
 Revisions released as PD FREEWARE by author: Ulf Ronald Andersson  1992.
		

	This is not the original documentation, which seems lost to mankind.
	At least I have not yet found any complete archive for this utility.
	So I have had to take the liberty of creating this DOC file,
	since I have made some long-needed revisions to MaxiDisk.
	As follows:

	Revision 2.0 updates of February 1992:

	1. I have implemented the XBRA protocol for all 3 vectors used.
	   This was one of the two reasons I made this revision.

	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).

	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.

	4. I have completely rewritten the data block allocation code.
	   The original seemed to be compiler-generated rubbish.

	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.

	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.

	For more technical details, read the file MAXITECH.DOC .


	Revision 2.1 updates of March 1992:

	Several routines were trimmed for higher efficiency, and one byte
	in the simulated 'boot' sector was adjusted.


	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.
	   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)


	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.

	The remainder of this file is the best near-original DOC's I have.
	Where I have discovered errors in it, or made important revisions,
	I have inserted notes like the one immediately below.
  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.}

  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.}

 Here I agree with Paul.  My bbu-clock (patched keyboard) is always
 initialized by AUTOTIME.PRG, so a manual setter that boots up
 and won't let me exit without entry (or it resets my clock),
 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.}

  I have managed to find some copies of these source files,
  so I have included SET_TIME.C in my MaxiDisk archive.
  But since I have ported COPY.C to Devpac 2 assembler
  to create an improved COPY.TTP, COPY.S replaces COPY.C !
  Nor do I see any reason to supply the older COPY.TTP.
  The new one copies identically, is faster, smaller, and
  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.

  Actually only MAXIDISK.INF must be in the root directory.
  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.

  There were indeed some serious problems with the old MaxiDisk.
  The garbled display mentioned here, was NOT one of them though.
  In fact I have never seen it. (some other version? German?)
  But if you are using OverScan (Isn't everyone (why not?))
  then you can NOT start MaxiDisk after booting OverScan.PRG.
  It will seem to work, but probably end in a 'bomb'-raid.
  The new MaxiDisk (unlike the old) works very well with OverScan,
  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!

  No, that is incorrect, MaxiDisk has always been able to find the
  programs in folders, PROVIDED that the full path is specified
  with each filename in MAXIDISK.INF !
  In case of doubt I should also add here that the examples given
  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.

  Well, the overhead costs of FATs packing maps etc. are a bit hard
  to figure since they vary with disk size in different ways.
  But as he says... Try it!, see what happens, then adapt.
  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.

  Sorry, but Paul has confused things!  The reason small files SEEM
  to be packed better is because on disk they eat space in 1Kbyte
  chunks, even if the file is only a hundred bytes or less.
  MaxiDisk, however, only pretends to use the normal clusters, so as
  to be accepted by the OS.  Internally MaxiDisk uses custom-built
  linked chains of packed data-blocks, with the same packing method
  for all sectors, regardless of whether its file was small or large.
  Also, OS checks available clusters before starting to write data.
  There may be plenty of RAM for the packed file, but if the free FATs
  seem insufficient for the file, OS won't even try to store it.
  So it is true that storing it earlier might solve problems,
  but because OS demands this sequence, whereas MaxiDisk doesn't.
  Another way to solve it is by using a copier with a smaller buffer.
  Then OS will grant access as long as there are FATs left for one
  more buffer-load, and this may be enough for the file since each
  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.

  Well, the reasons were not all that mysterious, since the protection
  of RAM ignored "_memtop", and treated "phystop" inappropriately.
  This made it prone to crash with OverScan.prg, and other programs
  that need these pointers to be correctly balanced aginst MPB's.
  Also the lack of XBRA protocol made for poor program cooperation.
  But all this has now been fixed, so go ahead and use it.

  One last warning: If you use disk cache, make sure it boots up
  BEFORE MaxiDisk, so it can not include it in the cache'd drives.
  Cache could hide the space released by packing, so that the OS
  could never use it.
  I always boot CACHEnnn.PRG before MaxiDisk, without any problems.

       -------------------- End of file MAXIDISK.DOC --------------------

Article - MaxiDisk


MaxiDisk Article MaxiDisk Article MaxiDisk Article
About Us - Contact - Credits - Powered with Webdev - © Atarimania 2003-2024