From AtariForumWiki
Jump to: navigation, search
                            ST-to-MSA version 1.0


                         Copyright 1997 Damien Burke 


ST-to-MSA converts the .ST disk images used by PaCifiST, the Atari ST
emulator, into compressed Magic Shadow Archiver (MSA) files.

ST-to-MSA is freeware and unsupported. I take no responsibility for any data
loss you may suffer (e.g. if you type the wrong filename in and overwrite
something important). If you find bugs, mail me and I'll fix them. You may do
what you want with the program provided you include this documentation
unaltered, and do not alter the program itself.


To use ST-to-MSA, type:

STTOMSA <name of ST input file> <name of MSA output file> [/Q] [/O]
/Q - quiet mode - no screen output and no pauses for keyboard input
/O - overwrite - if output file exists, overwrite without prompting
If /Q is used without /O and an output file exists, it will *not* be
overwritten and the program will *not* create the archive at all. Both /Q and
/O, if used, must be *after* the input/output filenames, for example:


...creates the OUTFILE.MSA archive from the disk image INFILE.ST without
any onscreen messages and overwriting the existing OUTFILE.MSA file (if it

While creating, a progress bar is displayed. Each block in the bar indicates
one track converted. Large blocks indicate compressed tracks and smaller
blocks indicate uncompressed tracks.


ST-to-MSA will return status codes of 0 for success or 1 for failure; you can
check for these in a batch file by testing ERRORLEVEL or if you are running
ST-to-MSA from within another program you can check by testing the return code
you get from the execution.


One of ST-to-MSA's uses is to enable ST users to use some of the .ST files on
the net. However, many of these files are images of disks that are quite
large - it can be difficult to get a PC to format a disk to the appropriate
size in order to write the .ST image to it, and if that fails, it can be even
more difficult to try and copy the .ST file over to your ST as it is so large.

So, converting that .ST file to an MSA archive can give you a smaller file to
deal with, which you can then de-MSA on your real ST. However, the compression
routine used by MSA is very basic so many disk images will not get any smaller
when converted to an MSA file. This leaves you back at square one - how do you
get such a big file onto your ST so you can de-MSA it there?

Answer: split it into two MSA files. If you supply ST-to-MSA with a *second*
output filename, it will create two separate MSA files - the first holding
the first half of the disk and the second holding the second half (oddly
enough). For example, if BIGDEMO.ST is an 800Kb disk (80 tracks, 2 sides, 10
sectors per track), then the following:


...will create two MSA files named BIGDEMO1.MSA and BIGDEMO2.MSA. BIGDEMO1.MSA
will store tracks 0 to 39 (or 1 to 40 as MSA likes to term them) and
BIGDEMO2.MSA will store tracks 40 to 79 (or 41 to 80 in MSA-speak). Now it's a
lot easier to get them across to your ST because you can use standard format
ST disks (if you have TOS 1.04+) or standard 720Kb PC disks.


For those interested, an MSA file is made up as follows:


Word	ID marker, should be $0E0F
Word	Sectors per track
Word	Sides (0 or 1; add 1 to this to get correct number of sides)
Word	Starting track (0-based)
Word	Ending track (0-based)

Individual tracks follow the header in alternating side order, e.g. a double
sided disk is stored as:


...and so on. Track blocks are made up as follows:

Word	Data length
Bytes	Data

If the data length is equal to 512 x the sectors per track value, it is an
uncompressed track and you can merely copy the data to the appropriate track
of the disk. However, if the data length value is less than 512 x the sectors
per track value it is a compressed track.

Compressed tracks use simple a Run Length Encoding (RLE) compression method.
You can directly copy any data bytes until you find an $E5 byte. This signals
a compressed run, and is made up as follows:

Byte	Marker - $E5
Byte	Data byte
Word	Run length

So, if MSA found six $AA bytes in a row it would encode it as:


What happens if there's an actual $E5 byte on the disk? Well, logically
enough, it is encoded as:


This is obviously bad news if a disk consists of lots of data like
$E500E500E500E500... but if MSA makes a track bigger when attempting to
compress it, it just stores the uncompressed version instead.

MSA only compresses runs of at least 4 identical bytes (after all, it would be
wasteful to store 4 bytes for a run of only 3 identical bytes!). There is one
exception to this rule: if a run of 2 or 3 $E5 bytes is found, that is stored
appropriately enough as a run. Again, it would be wasteful to store 4 bytes
for every single $E5 byte.

The hacked release of MSA that enables the user to turn off compression
completely simply stops MSA from trying this compression and produces MSA
images that are completely uncompressed. This is okay because it is possible
for MSA to produce such an image anyway, and such images are therefore 100%
compatible with normal MSA versions (and MSA-to-ST of course).

ST-to-MSA always tries to compress tracks - the time taken to try the
compression is so small it wasn't worth putting in an option to turn it off.


The file format of the .ST image files used by PaCifiST is simplicity itself;
they are just straight images of the disk in question, with sectors stored in
the expected logical order. So, on a sector basis the images run from sector
0 (bootsector) to however many sectors are on the disk. On a track basis the
layout is the same as for MSA files but obviously the data is raw, no track
header or compression or anything like that.

.ST files can be written to real disks using DKC's STImage program for the PC,
available from my web site (see top of this document). If you have .ST files
on your real ST you can write them to a disk using ArghBlarg's STTODSK.TTP
program, also available from my web site.

You can also use STtoMSA's companion program, MSAtoST, to convert MSA files to
.ST files. That is also available from my web site.

Damien Burke
31st May 1997

Back to Disk-Imagers