Intel ISIS disk image file tool, adding files

[Frode M]

Just a headsup that I will be adding some long needed features to Eric Smith's file-extractor tool for Intel ISIS disk images. This is namely support for adding and removing files. The work is nearing its completion now, and I expect to be done with it this evening.

The end result will eventually show up on my GitHub when the work is done:
https://github.com/Frodevan/isisutils

I have already added extracting from the double-density Tandberg format, but the add-file support will only be added for the Intel formats for now. This is mainly due to the changed structure of the file-directory entries, in combination with lack of documentation.

-Frode

[mark.p...@btinternet.com]

Frode

Are you aware of my ISIS tools?

1. Unidsk reads a .imd or binary image file and extracts all the ISIS files, creating a recipe file for mkidsk to regenerate the image. It supports ISIS I, II, III and PDS. It will also extract files from some ISIS IV disks.
   Running unidsk on the available TOS disk DISK2.IMD, extracts all the files and indicates some of the residual parts of deleted files
2. Mkidsk this takes a recipe file and generates .img or .imd image files. To add/delete files from just edit the recipe file. Note ISIS I, II, III and PDS but not ISIS IV are supported
   Given that the Tandberg format is largely the same as ISIS II only minor changes may be required. It looks like ISIS.ERR occupies the normal boot track sectors 1-23 with the links saved at sector 24. As it is unlikely this location is enforced the current tool should create a usable disk, however cylinder 0, sector 1 will have Intel “no OS boot message” and ISIS.ERR may be located elsewhere, however ISIS.DIR will reflect this.
   Note the original DISK2.IMD file was single density so I do not know whether ISIS.LAB on TOS DD disks mirrors the ISISI II DD extended format. The TOS ISIS.LAB does not record the interleave
3. Flux2imd this reads Kryoflux files and generates .imd files which can then be processed by unidsk
4. Unirmx, this is a new utility to process iRMX and ISIS IV disks. Currently it only supports image files, but it does handle the format better than unidsk

 

Note unidsk and mkidsk will optionally identify files in my Intel repository and if you have a local copy can install specific file versions from it. There is also a tool irepo to manage your own version of the intel repository.

 

The tools can be found in my github repository https://github.com/ogdenpm/disktools

See also https://mark-ogden.uk/disktools.html

 

If you would like, I am happy to update unidsk and mkidsk to support the Tandberg format for SD disks. I you have samples of the DD format so I can check fixed locations, I would also add these.

 

Mark

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/7cd4e3c9-d327-458a-9076-d246dffbe4ean%40googlegroups.com.

[Frode M]

Your tool is nice for archival of files and recreation of existing images, but having to maintain the recipe files is a bit of an involved operation if you just want to add a file to an existing image. My goal here is to just have a tool where I can just go "command --add filename image_name".

-Frode

[scott baker]

I might as well throw in my hat too and add mine to the pile -- I wrote an isis disk image manipulator a few weeks back: https://github.com/sbelectronics/multibus/tree/master/isistool

It works on raw images only, and it supports operations like adding and removing files. It's written in python. I did it for my own use, so it pretty much has no claim of suitability for any purchases, nor any warranty it won't hopelessly corrupt your images. Like Frode, I wanted something that would let me add a file at a time. I like to assemble on the linux box and inject the compiled binary into live images running on the vintage computer.

Filesystems have always been a hobby of mine.

Scott

[Frode M]

Ok, got everything working now, it's up on the github.

It's a little bit more messy than scott baker's solution, but a lot more parametrized due to the different formats. My approach was also to regenerate some of the datastructures with algorithms when writing files, and there's still some mess left from the old code, so it's by far as elegant and clean as Scott's solution.. But it works.

-Frode

[William Beech]

I also have a tool, makimg-isis, which uses a simple text file to generate a SD or DD disk image.  It will also extract everything from a disk image.  I have been using this tool for the past 10 years.

Here is the config file it uses (SD):

1
y
isis.t0
125229.005
43
isis.bin
isis.cli
a
isis.ov0
attrib
copy
delete
dir
edit
fixmap
format
hexobj
idisk
lib
link
link.ovl
locate
objhex
rename
spindn
submit
vers
system.lib
fpal.lib
plm80.lib
ixref
125229.dir

d
q

It does not get much simpler than this.

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/b640f8ed-4f73-43b2-806a-d11c57a1856fn%40googlegroups.com.

[Frode M]

One thing I also added, which I found quite useful, was the ability to regenerate the mapfile on disk.

TOS itself has a command line tool for this as well, and I consider this as an acknowledgement that they were fully aware that the file-handling in TOS easily got the mapfile out of sync with the actual file directory. Especially in cases where multiple files were written to at the same time, over multiple drives, or cases where files aren't properly closed. Many tools use the very same buffer for the mapfile (there's some OS memory that's reserved for this), and a lock status flag to signal to user programs that write operations were unsafe wasn't added until the very last couple of versions. The end result of this, is that disks in my collection that have been well used, can have quite big discrepancies between their mapfiles and directories, and I even found one case of a file that had a broken sector due to something trying to steal one of its blocks at some point in the past (I found a complete version of the file on another disk, but still). Having a way of getting the proper mapfile is also a nice way to scout for recoverable deleted files in-between the existing files, say if someone deleted a file once and for some reason the update to the mapfile never went through. I have been able to recover at least one unique version of the TOS text editor program by scouting for suspicious holes that showed up in regenerated map files this way.

-Frode

[mark.p...@btinternet.com]

Frode

Scanning the ISIS.DIR file and looking at the link chains, in addition to the normal files on the disk the following are potential extra files that have been deleted

Where duplicate names are shown, they are separate instances of the deleted files in the directory.

GB2033.THH

GB2034.DTR

NO2009.OL3

NO2007.KL1

NO2002.DOR

GB2035.THH

NO2011.KL3

NO2008.DTR

NO2012.RM3

file NO2010.THH could not be recovered

file NO2013.DTR could not be recovered

NO2015.DGP

NO2014.RM3

file FIL could not be recovered

FIOL

SNOPP

FRAPP

FRAPP

AU2572.RM1

file AU2574.TRP could not be recovered

AU2574.TRP

AU2575.T12

AU2601.EL6

AU2602.DE2

AU2603.DOM

AU2604.KT1

AU2597.DOM

AU2594.T19

AU2595.RM1

AU2596.RM2

AU2602.DE2

 

As they are deleted files there is no guarantee that they are not corrupted, but sampling several indicates that most appear to be ok

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/bcfe5013-d54e-4a58-8b6d-17669f43cd97n%40googlegroups.com.