Commodore 8050

All questions about how to use KryoFlux go here.
aholme
Posts: 6
Joined: Sat Feb 08, 2014 1:25 pm

Commodore 8050

Post by aholme » Sat Feb 08, 2014 1:51 pm

I created preservation stream files from a Commodore 8050 diskette. These have 77 tracks with between 23 and 29 sectors per track as follows:

tracks 1 - 39 have 29 sectors
tracks 40 - 53 have 27 sectors
tracks 54 - 64 have 25 sectors
tracks 65 - 77 have 23 sectors

A few tracks are clearly damaged; however, most look OK in the histogram and scatter views:

http://www.aholme.co.uk/Misc/8050_histogram.PNG
http://www.aholme.co.uk/Misc/8050_scatter.PNG

But DTC only seems to recognise the 23 and 25 sector tracks:

C:\Projects\PET\kryoflux_2.20_windows\dtc>DTC.exe -l8 -ffoo.img -s0 -i24 -m1 -f8050\track -i0 -e83
KryoFlux DiskTool Console, v2.20, uiv.1, Feb 22 2013, 18:52:16

00.0 : CBM EXT: <unformatted>
01.0 : CBM EXT: <unformatted>
02.0 : CBM EXT: <unformatted>
03.0 : CBM EXT: <unformatted>
04.0 : CBM EXT: <unformatted>
05.0 : CBM EXT: <unformatted>
06.0 : CBM EXT: <unformatted>
07.0 : CBM EXT: <unformatted>
08.0 : CBM EXT: <unformatted>
09.0 : CBM EXT: <unformatted>
10.0 : CBM EXT: <unformatted>
11.0 : CBM EXT: <unformatted>
12.0 : CBM EXT: <unformatted>
13.0 : CBM EXT: <unformatted>
14.0 : CBM EXT: <unformatted>
15.0 : CBM EXT: <unformatted>
16.0 : CBM EXT: <unformatted>
17.0 : CBM EXT: <unformatted>
18.0 : CBM EXT: <unformatted>
19.0 : CBM EXT: <unformatted>
20.0 : CBM EXT: <unformatted>
21.0 : CBM EXT: <unformatted>
22.0 : CBM EXT: <unformatted>
23.0 : CBM EXT: <unformatted>
24.0 : CBM EXT: <unformatted>
25.0 : CBM EXT: <unformatted>
26.0 : CBM EXT: <unformatted>
27.0 : CBM EXT: <unformatted>
28.0 : CBM EXT: <unformatted>
29.0 : CBM EXT: <unformatted>
30.0 : CBM EXT: <unformatted>
31.0 : CBM EXT: <unformatted>
32.0 : CBM EXT: <unformatted>
33.0 : CBM EXT: <unformatted>
34.0 : CBM EXT: <unformatted>
35.0 : CBM EXT: <unformatted>
36.0 : CBM EXT: <unformatted>
37.0 : CBM EXT: <unformatted>
38.0 : CBM EXT: <unformatted>
39.0 : CBM EXT: <unformatted>
40.0 : CBM EXT: <unformatted>
41.0 : CBM EXT: <unformatted>
42.0 : CBM EXT: <unformatted>
43.0 : CBM EXT: <unformatted>
44.0 : CBM EXT: <unformatted>
45.0 : CBM EXT: <unformatted>
46.0 : CBM EXT: <unformatted>
47.0 : CBM EXT: <unformatted>
48.0 : CBM EXT: OK*, trk: 025[054], sec: 25, *T
49.0 : CBM EXT: OK*, trk: 025[055], sec: 25, *T
50.0 : CBM EXT: OK*, trk: 026[056], sec: 25, *T
51.0 : CBM EXT: OK*, trk: 026[057], sec: 25, *T
52.0 : CBM EXT: OK*, trk: 027[058], sec: 25, *T
53.0 : CBM EXT: OK*, trk: 027[059], sec: 25, *T
54.0 : CBM EXT: OK*, trk: 028[060], sec: 25, *T
55.0 : CBM EXT: <unformatted>
56.0 : CBM EXT: OK*, trk: 029[062], sec: 25, *T
57.0 : CBM EXT: OK*, trk: 029[063], sec: 25, *T
58.0 : CBM EXT: OK*, trk: 030[064], sec: 25, *T
59.0 : CBM EXT: OK*, trk: 030[065], sec: 23, *T
60.0 : CBM EXT: OK*, trk: 031[066], sec: 23, *T
61.0 : CBM EXT: OK*, trk: 031[067], sec: 23, *T
62.0 : CBM EXT: OK*, trk: 032[068], sec: 23, *T
63.0 : CBM EXT: OK*, trk: 032[069], sec: 23, *T
64.0 : CBM EXT: OK*, trk: 033[070], sec: 23, *T
65.0 : CBM EXT: <unformatted>
66.0 : CBM EXT: <unformatted>
67.0 : CBM EXT: <unformatted>
68.0 : CBM EXT: OK*, trk: 035[075], sec: 23, *T
69.0 : CBM EXT: OK*, trk: 035[076], sec: 23, *T
70.0 : CBM EXT: OK*, trk: 036[077], sec: 23, *T
71.0 : CBM EXT: <unformatted>
72.0 : CBM EXT: <unformatted>
73.0 : CBM EXT: <unformatted>
74.0 : CBM EXT: <unformatted>
75.0 : CBM EXT: <unformatted>
76.0 : CBM EXT: <unformatted>
77.0 : CBM EXT: <unformatted>
78.0 : CBM EXT: <unformatted>
79.0 : CBM EXT: <unformatted>
80.0 : CBM EXT: <unformatted>
81.0 : CBM EXT: <unformatted>
82.0 : CBM EXT: <unformatted>
83.0 : CBM EXT: <unformatted>

Any idea what might be wrong? It may or may not be significant; but I would say the two histogram peaks are slightly further apart on the higher tracks.

Thanks,
Andrew.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Commodore 8050

Post by IFW » Sat Feb 08, 2014 3:29 pm

Alignment?
Never seen any 8050 dumped...

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Commodore 8050

Post by IFW » Sat Feb 08, 2014 3:29 pm

You could also try switching the density line using -dd0 or -dd1

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Commodore 8050

Post by IFW » Sat Feb 08, 2014 3:37 pm

According to a manual I found via google, it's a 100 TPI drive...
A standard PC drive is 48 or 96 TPI and won't be able to read a 100 TPI disk apart from a few tracks if you are lucky.
You may get better results if you can find a 100 TPI drive or using microstepping to compensate for the alignment difference...

aholme
Posts: 6
Joined: Sat Feb 08, 2014 1:25 pm

Re: Commodore 8050

Post by aholme » Sat Feb 08, 2014 3:54 pm

I already tried -dd to no avail. Are there any undocumented command-line switches?

I was aware that the 8050 is 100 TPI; and I wasn't expecting to read every track; however, as the output shows, a lot of tracks have been read; and, judging from the histograms and scatter graphs, there are a lot more that should/could be decoded.

The linked PNG files show a track that did not decode. I am still suspicious that the second peak is at 6.5us i.e. not 2*4.5us=9us.

Thanks,
Andrew.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Commodore 8050

Post by IFW » Sat Feb 08, 2014 4:00 pm

All command line parameters can be listed using DTC -h.
It is more like reading data bleeding into halftrack on 1541... you may or may not get something legible regardless of how it looks.
As I said there are no 8050 dumps at all, it is perfectly possible that the drive uses different densities for example than a 1541 and of course using those timings wouldn't work. I have no way of guessing...
Can be anything, but first and most important is the different track alignment.

aholme
Posts: 6
Joined: Sat Feb 08, 2014 1:25 pm

Re: Commodore 8050

Post by aholme » Sat Feb 08, 2014 5:07 pm

>It is more like reading data bleeding into halftrack on 1541
If you look closely at the output, you will see Kryoflux is reading distinct data in adjacent tracks e.g.
68.0 : CBM EXT: OK*, trk: 035[075], sec: 23, *T
69.0 : CBM EXT: OK*, trk: 035[076], sec: 23, *T
70.0 : CBM EXT: OK*, trk: 036[077], sec: 23, *T
The numbers in [] are track numbers read from the disk. 77 is the last track. The number of sectors found is correct in all cases BTW.

>you may or may not get something legible regardless of how it looks.
I would expect to see randomness and smearing, not nice regular flux transitions. Surely?

> it is perfectly possible that the drive uses different densities for example than a 1541 and of course using those timings wouldn't work
8050 has 77 tracks and 2083 sectors, so it is much higher density than 1541. I am using image type -i24 as that seems to work best. Is -i24 designed for 1541 density?

>first and most important is the different track alignment.
Agreed. (1/96-1/100)*77 / (1/100) = 3.2, so I would expect the data to go in and out of alignment 3 times between tracks 1 and 77. So it seems odd that I can read tracks 54-60, 62-70 and 75-77 but nothing below 54.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Commodore 8050

Post by IFW » Sat Feb 08, 2014 8:33 pm

-i24 is purely for certain type of custom formats that are derived from the original CBM format and used as a copy-protection, e.g the EU release of Afterburner. It's certainly creative to use it for trying to read a 100 TPI disk :)

I'd expect data to go out of alignment for all of the tracks :)
Possibly none of them are where they really should be exactly. There is some tolerance, but generally speaking little differences do matter, especially for something this dense. Reading legible data, despite misalignment is what I meant that it's like reading halftracks on a 1541 - it is also possible that at some places you read two adjacent tracks at once...
In order to get a correct mapping of the tracks, the exact specifications of the 100 TPI would have be known, e.g. exact track 0 start position and track width as a minimum. Then it would be possible to generate a 1:1 'ideal" track mapping of 96 TPI microstepped to 100 TPI. Microstepping allows a stepper (if it works with the stepper in your drive, that is...) to use a sub-step resolution, which if you are lucky would correlate well with the ideal step mapping calculated as per above.
viewtopic.php?f=7&t=768&p=6766

Tbh I am not quite sure what you are trying to achieve here - a disk where a few tracks are not read is just as good normally as a disk not read at all, especially if all of the data is important.

Anyway, there is no way to tell what's going apart from light to gross misalignment of the tracks - purely depending on which track we talk about. If you'd like, you could post a disk dumped, preferably a known good disk, so it won't become a wild goose chase...
However, the only way to reliably read such a disk is to actually have a 100 TPI drive, or mimic having a 100 TPI drive via microstepping.

aholme
Posts: 6
Joined: Sat Feb 08, 2014 1:25 pm

Re: Commodore 8050

Post by aholme » Sun Feb 09, 2014 2:09 pm

>Tbh I am not quite sure what you are trying to achieve here
I wanted to know what was on the disk, which means reading the directory from logical track 39.

And I've just done it!

Data is readable, despite misalignment, except when the head is exactly half-way between two tracks. This does indeed happen in three places, as predicted. Elsewhere, the head amplifier AGC circuit does a remarkable job of extracting those flux transitions. It doesn't matter that physical and logical track numbers don't match, because Commodore kindly wrote the logical track number into every sector header. But I actually used the scatter plot to find logical track 39. It's the last one with 29 sectors. Track 40 has 27.

I wrote a little C program using the KFStream library, to decoded the stream files. It was a thrill to see my name in the hex dump from 30 years ago.

GCR has 3 characteristic peaks on the histogram, representing bit patterns 1, 01 and 001. Every flux transition has to be one of these three patterns. When the data is noisy, these peaks are not so sharp. As long as the frequency drops to zero between peaks, it is easy to pick threshold points. But the frequency may not always go to zero for noisy data. My method is to eyeball a zoomed in view of the histogram and manually select two troughs. How does DTC do it? Does it find the peaks and bisect?

Code: Select all

#include <stdio.h>

#include "kfstrdec.h"

unsigned char buf[512*1024];

int nibble2gcr[] = {
    0x0A, // 01010 
    0x0B, // 01011 
    0x12, // 10010 
    0x13, // 10011 
    0x0E, // 01110 
    0x0F, // 01111 
    0x16, // 10110 
    0x17, // 10111 
    0x09, // 01001 
    0x19, // 11001 
    0x1A, // 11010 
    0x1B, // 11011 
    0x0D, // 01101 
    0x1D, // 11101 
    0x1E, // 11110 
    0x15, // 10101 
};

int gcr2nibble[32];

int nibble2hex[] = {'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'}; 

#define FN "track34.0.raw" // Logical track 39 = Directory
#define HI 106
#define LO 67

void main() {
	KFStream ks;
	FILE *fp;
	int i;

    for (i=0; i<16; i++) gcr2nibble[nibble2gcr[i]] = i;

	fp = fopen("..\\kryoflux_2.20_windows\\dtc\\c11_8050\\" FN, "rb");
	if (!fp) return;
	int len = fread(buf, 1, sizeof(buf), fp);
	fclose(fp);

	ks.decode(buf, len);
	int n = ks.getFluxCount();
	Flux *f = ks.getFlux();

	unsigned hist[256];
	for (i=0; i<256; i++) hist[i]=0;
	for (i=0; i<n; i++) hist[f[i].fluxValue]++;

	// Review histogram: find 3 peaks and 2 troughs
	fp = fopen("hist.csv", "w");
	fprintf(fp,"flux,freq,clip\n");
	for(i=0; i<256; i++) fprintf(fp, "%d,%d,%d\n", i, hist[i], min(20,hist[i]));
	fclose(fp);
    
	fp = fopen("data.bin", "wb");

    int bits=0, gcr=0, data=1, bytes=0;

	for (i=0; i<n; i++) {
		if (f[i].fluxValue<LO) { // Lower histogram trough
	        bits+=1;
	        gcr<<=1;
	    }
		else if (f[i].fluxValue<HI) { // Upper histogram trough
	        bits+=2;
	        gcr<<=2;
	    }
	    else {
	        bits+=3;
	        gcr<<=3;
	    }
		gcr|=1;

		if ((gcr&0x2FF)==0x2FF) { // Sync mark
			bits=0;
			data=1;
		}

	    if (bits>=5) {
	        bits-=5;
			data<<=4;
			data|=gcr2nibble[(gcr>>bits)&0x1F];
			if (data&0x100) {
				fputc(data&0xFF, fp);
				data=1;
				bytes++;
			}
	    }
	}

	fclose(fp);
}

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Commodore 8050

Post by IFW » Sun Feb 09, 2014 4:00 pm

If that's all you want to do... ;)
Otherwise you should be aware of that remarkable job... the CBM checksum method is extremely weak and the density plus encoding method is prone to peak shifts that are very hard to detect, e.g 11010 vs 10110. Should they happen twice, which is not uncommon, you'd end up with bad data that is "good"...
DTC relies on a fairly complex pipeline; statistical analysis plus cell behavior.

Post Reply