Manual pages for unidsk & mkidsk

These tools are used to manipulate ISIS/iRMX disks in the .IMD and .IMG formats

• unidsk extract files from an .IMD or .IMG file of an ISIS disk, it also supports some  iRMX disks
• mkidsk creates an .IMD or .IMG files for ISIS I / II / III and ISIS PDS disks, using a recipe file.

unidsk

This tool processes a .IMD or a .IMG file that contains an ISIS disk image.

If the image format corresponds to ISIS I / II /III and ISIS PDS disk, It extracts the content and creates a recipe file corresponding to the content. The recipe format is documented in recipe.

Otherwise it assumes the disk is an ISIS IV  or iRMX disk and attempts to extract the content, generating a __log__ file recording what was identified.

usage

unidsk [-v | -V] | [-l] [-d] file

where

the file name should end in .IMD or .IMG and a directory is created with the file name minus the .IMD or .IMG

• -l avoids the use of the repository, but this prevents file version identification

• -d is for ISIS I / II / III and ISIS PDS disk images. It shows the file link structures

For ISIS I / II / III and ISIS PDS disks the tool will additionally attempt to extract any deleted files, prefixing them with a # is they appear to be valid. These appear as comments in recipe file.

If the repository is being used, then each file is looked up in the repository and its location is identified. This allows file versions to be identified. There are some files for which multiple copies are available, if matched, these are also listed.

For ISIS IV and iRMX, the __log__ file records information for each extracted file, this includes some of the underlying system files e.g. __fnodes__ which stores the raw directory data.

mkidsk

This is the logical inverse of unidsk in that it takes a recipe file and recreates a .IMD or .IMG disk image.

Whilst many people prefer to keep prebuilt .IMD or .IMG files, in creating the repository I identified many anomalies in the disk images in circulation. It is apparent that many are copies, sometimes copied between machine. In addition a number have corrupted files. The mkidsk allows pristine versions to be created, even restoring the original interleave and skew if required.

A recent addition to mkidsk is that it will now automatically provide ISIS operating system files based on the os version specified in the recipe. It will also set the file attributes appropriately.

Whilst it is possible to override the os files mkdisk uses, it is not recommended, unless you have a version that is not currently supported; if you have please let me know so that I can add to the collection of supported versions. Be aware I have seen some corrupt versions of the OS.

I currently have over 210 recipe files that can recreate ISIS disks to what I believe is or is close to the original content.

usage

mkidsk -v|-V | [options]* [-]recipe [diskname][.fmt]

where

Note although mkidsk doesn't require it, the convention is to name recipes starting with an @ character. Both unidsk and irepo follow this convention.

The recipe format is documented in recipe and my naming convention is documented in naming

By default the output name is the recipe name minus the leading @ and with a .IMD extension. As the recipe file may have a long file name, you may wish to explicitly specify a shorter output filename.

Unless you are targeting a physical disk, the -i and -t options are unlikely to be used. The -i option adds offsets between sectors on a track and the -t option adds offsets between sectors on a track change. This is needed because ISIS physically interleaves the sectors, unlike CP/M which applies a logical interleave. See Interleave and skew for more information.

Although -i allows the default interleave to be overwritten, unlikely to be needed.

The -f option is only needed to replicate a disk copy to a non ISIS machine. By default ISIS fills unused sectors with 0xc7, unlike CP/M and MSDOS which use 0xe5.

Note: IMD does not support the M2FM encoding used by ISIS DD disks. Generated files use the MFM encoding instead.

Caveats

There are a few cases where mkidsk can not recreate an original image, although physical disks created from these images should work.

• The disk used for the original image had files added and deleted. In this case the residual data from the deleted files will be missing in the image. Disks that have been modified are also likely to lead to some files in different ISIS.DIR slots and with different link block information.
• The default disk images are created without interleave or skew and using 0xc7 as the sector initialisation byte.
  All these can be changed with the -i, -t and -f options.
• The original disk reading software may have incorrectly determined the first sector on a track, hence losing the skew information.
• The original disk reading software may have omitted the boot track where it uses a different encoding.
• If the comment information is changed, the IMD files will be different although disks created will not.

Interleave and skew

When creating physical disks, the Intel standard spaces the layout of where sectors are on the disk physically, using interleave as the spacing within a track and skew as an additional spacing between adjacent tracks. The diagram below illustrates this, note interleave is added before sector 1 is allocated for ISIS I / II / III but not for ISIS PDS. Additionally tracks 0, 1 and 2 and all tracks for ISIS I, ISIS II 2.2 and ISIS PDS reset the initial slot.

The interleave is encoded in the ISIS.LAB file for ISIS I/II/III with a character used for each track. This character is the interleave value added to the character '0'. Since tracks 2 onwards have the same interleave, the first three characters can be used as a shorthand for the interleaves for the whole disk, as used in the table below, which shows the encodings for each OS version. The format columns show the format code that can be used to force this format.

ISIS PDS uses an interleave of 1 for cylinder 0 side 0 and interleave of 4 for all other tracks. Additionally all tracks reset to use initial slot 0.

If the -i option is specified, mkidsk attempts to determine the default interleave and skew as follows:

1. If the format is explicitly specified as SD1, SD2, SD3, SD4 or DD3, DD4 or PDS then the interleave and skew as are specified in the table above. An error is however flagged if an attempt is made to write an ISIS I/II/III OS to a PDS disk and vice versa. Also an error is generated in attempts to write ISIS I or ISIS II 2.2 OS to an double density disk. Other inconsistent formats and OS generate a warning.
2. In other cases, if there is an operating system specified, this is used to determine the format as per the table above. Unless there is a specific reason to force a non-standard ISIS I/II/III format, setting the format to SD and DD with an OS specified will do the right thing.
3. When there is no operating system the following is done
   1. If SD disk and interleave is 1<3, then format is assumed to be ISIS II 2.2 (same format as ISIS I)
   2. if DD disk and interleave is 1H5, then format is assumed to be ISIS II 3.4
   3. if DD disk and interleave is defined, then format is assumed to be ISIS II 4.x
   4. If first character of version is 3, then format is assumed to be ISIS II 3.4 else ISIS II 4.x

In most cases the above rules should identify correctly the format and in the worst case will create an ISIS II 4.x format disk that should work across all ISIS I/II/III, subject to the disk density being supported.

Back to Disk Tools