disk-utilities icon indicating copy to clipboard operation
disk-utilities copied to clipboard

disk-analyse: Display duplicator info when found

Open M-a-r-k opened this issue 7 years ago • 4 comments

I'm not sure how common this is, but some disks duplicated on Trace Mountain equipment contain log/diagnostic info on track 80.

Here's an example .scp dump taken from a new 720KB-PC-formatted Maxell MF2DD disk. Track 80 (both sides) contains one 2048-byte sector. https://www.mediafire.com/?qz72xnbi6n3wg9h

The log/diag info contains a unique number/serial number. For disks which have previously been used (written to) by someone, the data on track 80 is likely to persist since normal disk formats only use tracks 0-79.

With --format=ibm_pc_dd there are clues that something is on track 80:

$ disk-analyse -v --format=ibm_pc_dd 2nd_Maxell_MF2DD.scp blah.img
Found format "ibm_pc_dd"
PLL Parameters: period_adj=5% phase_adj=60%
*** T80.0: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=00 secsz=2048 wanted=512
*** T80.0: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=00 secsz=2048 wanted=512
*** T80.0: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=00 secsz=2048 wanted=512
*** T80.0: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=00 secsz=2048 wanted=512
*** T80.0: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=00 secsz=2048 wanted=512
*** T80.0: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=00 secsz=2048 wanted=512
*** T80.1: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=01 secsz=2048 wanted=512
*** T80.1: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=01 secsz=2048 wanted=512
*** T80.1: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=01 secsz=2048 wanted=512
*** T80.1: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=01 secsz=2048 wanted=512
*** T80.1: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=01 secsz=2048 wanted=512
*** T80.1: IBM-PC DD (720kB): Unexpected IDAM sector size sec=01 cyl=50 hd=01 secsz=2048 wanted=512
T0.0-79.1: IBM-PC DD (720kB)
T80.0-83.1: Unformatted

Note that "T80.0-83.1: Unformatted" isn't strictly true. If instead you use --format=ibm:

$ disk-analyse -v --format=ibm 2nd_Maxell_MF2DD.scp blah.img
Found format "ibm"
PLL Parameters: period_adj=5% phase_adj=60%
T0.0-79.1: IBM-MFM DD (9 512-byte sectors, 4608 bytes)
T80.0-80.1: IBM-MFM DD (1 2048-byte sectors, 2048 bytes)
T81.0-83.1: Unformatted

Then the log/diag data is written to the end of the output file so you can easily inspect it. [Which may not be what the user wanted, since the output file is then 724KB long.]

Would it be a good idea to output the log/diag sector data to a separate file, or at least report its existence? It could be present regardless the format of tracks 0-79. So if the input file contains data for track 80, check to see if diag/log info is present, even if you're only processing tracks 0-79 as Amiga trackdisk format, for example.

It might be interesting to see what proportion of commercially-duplicated disks have similar data on track 80. In the past I noticed that some Amiga disks (dumped using MFMWarp or similar on my Amiga) had data on track 80 despite being unprotected. But I never looked into that any further at the time.

Here are the contents of the log sector (taken from a different disk to the image I uploaded, so date/time etc. differ):

$TRACEBACK (tm) 
$OPER = Administrator
$NETWORK = TGI ENABLED
$STATION = Loader 9
$GROUP = Line 6
$WORKCELL = TRACE
$HOST = TRACE
$WORKORDER = B.TAYLOR B.SHIFT
$SYSTEM = V 4.4.0
$PRODUCT = 025302
$PTIME = Tue Oct 15 13:16:10 1996
$DESCRIP = IBM PC 3.5LD (720K)
$MEDIA TYPE = <default>
$WINDOW = C,60%, C,65%
$THRESHOLD = C,40%, C,35%
$RETRIES = 2, 3
$PRE/WRC = 
$DRIVESN = 11184
$LOADERSN = 049616947
$BPSN = 731805-195
$CPUSN = 731806-261
$FCSN = 731817-250
$DRVBDSN = 551354-14
$USTRING = 
$TSTRING = TraceBack (tm) Copyright (c) 1992 Trace Mountain Products Inc., ALL RIGHTS RESERVED
$DUP TIME = Thu Aug 21 17:59:30 1997
$SN = NOT SERIALIZED
$DISK#/JOB# = 813/3000
$DRVLIFE = 132511
$ICD = 26uS,176uS
$REINSERT = OFF
$ISV = 1.5%
$MTA = 0.50V
$TURBO = ON
$WRITEPROTECT = IGNORE
$MAGINDEX = NOT PRESENT
$$

Then space characters to 0x7FE bytes then two bytes 0x54 0x9E (checksum?)

M-a-r-k avatar Nov 15 '16 21:11 M-a-r-k

I've heard of this before I'm sure. I wonder if the Amiga disks had IBM-format data on cylinder 80 too. Maybe this is worth adding to disk-analyse as a command-line option, --mastering-data=output.img; no image name specified means just log presence of mastering data to the terminal; cmdline option not specified means no mastering data detection (current behaviour).

keirf avatar Nov 15 '16 22:11 keirf

Based on the log text in the example, perhaps that was a standard feature of the default Trace duplication scripts? So some Amiga/Mac/whatever disks could possibly contain similar info. [Maybe in some cases by accident if, for example, the duplication house used pre-formatted "blank" disks like these Maxell ones with data on track 80.]

I'll check some of the Amiga CT raw dumps I made several years ago. (By the way, I have many dumps made with the Amiga program MFMWarp which I could also look at. Support for MFMWarp images in disk-analyse would make that a lot easier, but that's another issue/enhancement request I think...)

M-a-r-k avatar Nov 15 '16 22:11 M-a-r-k

If MFMWarp format was documented I would add support, but I don't think it is.

keirf avatar Nov 15 '16 22:11 keirf

I don't think it's documented as such, though the (assembly-language) source is available: http://www.whdload.de/whdload/Tools/MFMWarp_src.lha

M-a-r-k avatar Nov 22 '16 21:11 M-a-r-k