• Please review our updated Terms and Rules here

CP/M Disk image parser?

P

per

Veteran Member
Joined
Jan 21, 2008
Messages
3,052
Location
Western Norway
Does anyone know of a program that can parse a CP/M 2.2 disk images for file entries on a recent PC? The program I wish to exist should be able to handle disks of various different Heads per disk/Tracks per side/Sectors per Track/Bytes per secror values.

Writing such a program shouldn't be too hard, as the CP/M disk structure is fairly well known. Generally the two first tracks consist of boot data, while the file directory starts at the third track, immediately followed by data.

Each entry in the table consists of 32 bytes, as explained here:
http://www.cpm8680.com/cpmtools/cpm.htm

In my case the disk has 1 side, 40 tracks, 10 sectors per track, and 512 bytes per sector. It follows the standard with the filetable and data starting at the third track, and the table consist of 40 entries.

I know I can just use 22Disk, but that's quite too much a hassle when dealing with emulators.
 
tezza said:
I haven't looked into it but would Omniflop be a possible contender?

Tez
Click to expand...

Omniflop seems to base itself uppon an existing actual floppy drive (or a replacement of one). What I need is much simpler, just an utility to scan and edit the file as appropriate.

Reading out a file should be easy as long as one know how the extent and block pointer system works (should be trival). Writing requires some calculation, to make sure nothing gets overwritten and that every new block pointer for the added file turns out correct.
 
Per -

Some years ago I wrote a program in QBasic just for this purpose. My CP/M system was defunct and I needed access to some old files. I used a DOS utility like Anadisk or Diskdump, I forget which, to read a full data image of each disk into a single DOS file. These were plain data images (including any bad sectors), not structured images like ImageDisk or TeleDisk.

The Qbasic routine interactively parses that dump file to locate the directory area, shows the directory, and extracts any selected file from the image into a DOS file.

This was for my own purposes and coded for the specific skew factor used on my disks. But it could be adapted for any CP/M diskette format so long as you know the skew factor or can calculate it by looking at the placement of data in the dump file. The Qbasic program reconstructs file data by following the CP/M directory block information in the dump file. It does not care about physical disk geometry.

Being Qbasic it is easy to read, test and modify.

If you are interested, send me a PM and I'll send you the code.

Rick
 
The Qbasic program reconstructs file data by following the CP/M directory block information in the dump file. It does not care about physical disk geometry.
Click to expand...

Rick, how does your program work when there's a side-to-side incremental skew or when the directory occurs in the middle of the disk? (Yes, there are some who did that). Or where there's only one sector with directory information in it and the layout is otherwise unknown?
 
Chuck - the intelligence of this program is limited (like that of its author).
The assumption is that the imaging program has taken each track 0 (side 1+ side 2) to track XX, and dumped the raw data in a sequential file, ignoring sector layout.

The user has to know, or work out by looking at the dumped data, what kind of sector layout and skew have been used, and how the file blocks listed in the directory block against each filename have been distributed through the dump file. Same would apply to addressing an unusual directory location. I assumed standard CP/M location, but one could change it around.

So like many things in the CP/M world, it needs to be customised by a user for any particular CP/M disk layout. But being interpreted Qbasic, and working on images not precious old disks, it's not too hard to play around with in real time until it works.

I used it to reconstruct the data from some tens of diskettes. But is is more of a kludge than a polished utility. If anyone wants to look at the code, I'll check it again and make sure comments are as clear as possible.

In theory, it could be developed to locate a non-standard directory area by some sort of signature. But it would not be hard to just scroll through a screen dump of the image file till you see the file names appearing..

On a system that was working but undocumented, you could save a test file made up of ASCII bytes that incremented after every 128bytes, then check an image to see where these byte blocks had been placed, and correlate that to the directory block information.

But there are other programs like ImageDisk that do disk format discovery fairly reliably.

Rick
 
That's all assuming, of course, that you can write the diskette yourself with known data.

But the physical format is the smallest part of the puzzle in my mind.

Take, for example, the National Semi BLC 86/20--the (8") directory is on Cylinder 39, Side 1. Track allocation goes backward toward cylinder 0, then upward toward cylinder 76 after that.

If you think that discovering the ASCII string you wrote is straightforaward, you've never had to work on a Sharp MZ80B--it stores data complemented--and then side 1 before side 0.

There are also a few formats that "spare" a sector on each track.

My point is that there are probably more than a 1,000 different CP/M formats, of which 800 or so are unique. The ingenuity of programmers and engineers must not be under-estimated.
 
Since the OP is talking about parsing images, not disks, I'd think it'd also be useful to know what kind of images he wants to read? Teledisk? IMD? ??

And why is using an emulator such a big problem?
 
MikeS said:
Since the OP is talking about parsing images, not disks, I'd think it'd also be useful to know what kind of images he wants to read? Teledisk? IMD? ??

And why is using an emulator such a big problem?
Click to expand...

It's generally raw images, uaully with a scew factor of zero. cpmtools works, but it's quite inconvenient to use and sort of slightly buggy. However, it works for most of the work I want to do.

If I only could write in C++/# or someting like that, I could have made a windows app where you typed in all the info the program needed in the correct textboxes, and then just use a simple interface to move files to/from the images.

It would also be nice to know how the disks included in the AltairZ80 emulator is encoded. After what I have seen, it's one of those formats that first use all sectors of head 0 followed by all sectors of head 1, instead of one sector from each head throughout a track, plus that it includes unused data (~9 bytes typically) between each actual sector of the image.
 
You must log in or register to reply here.
Back
Top