Deciphering an odd floppy disk format.
Mattis Lind
mattislind at gmail.com
Mon Feb 15 13:33:14 CST 2021
Spent some time. Adjusted the MARK sequences to use 55424954 for address
mark and 55424945 for data mark.
That along with a stupid error in the decoder-code that I fixed now result
in some kind of output:
CNT: 003BF ADDRESS MARK: 55424954
CNT: 0040F DATA MARK: 55424945 OKEY CHAR (1),
V
CNT: 006B5 ADDRESS MARK: 55424954
CNT: 00705 DATA MARK: 55424945 P POINTER,
VV V
CNT: 009B7 ADDRESS MARK: 55424954
CNT: 00A07 DATA MARK: 55424945 D CHAR(6) BASED(P),
p V V O
CNT: 00CA1 ADDRESS MARK: 55424954
CNT: 00CF2 DATA MARK: 55424945 DATUM CHAR(6),
' V V
CNT: 00F87 ADDRESS MARK: 55424954
CNT: 00FD9 DATA MARK: 55424945 PP POINTER,
( V
CNT: 01277 ADDRESS MARK: 55424954
CNT: 012C8 DATA MARK: 55424945 1 STR BASED(PP),
a V V
CNT: 01569 ADDRESS MARK: 55424954
CNT: 015BC DATA MARK: 55424945 2 X CHAR(2),
V V$
CNT: 01868 ADDRESS MARK: 55424954
CNT: 018BA DATA MARK: 55424945 2 Y CHAR(2), /* 6
= UKTO, 7 = IKSLAG */ V V V
CNT: 01B46 ADDRESS MARK: 55424954
CNT: 01B99 DATA MARK: 55424945 2 FIRMA CHAR (1),
( V
CNT: 01E34 ADDRESS MARK: 55424954
CNT: 01E86 DATA MARK: 55424945 2 OP_KOD BINARY,
V V
CNT: 02120 ADDRESS MARK: 55424954
CNT: 02172 DATA MARK: 55424945 2 RADANT BINARY,
V
CNT: 02415 ADDRESS MARK: 55424954
CNT: 02466 DATA MARK: 55424945 T4 CHAR(4),
V VH
CNT: 02713 ADDRESS MARK: 55424954
CNT: 02765 DATA MARK: 55424945 ANTAL_KONT BINARY INIT(0),
, V VH
CNT: 029FD ADDRESS MARK: 55424954
CNT: 02A4D DATA MARK: 55424945 TOT_ANTAL_KONT BINARY INIT(0),
V
CNT: 02CD1 ADDRESS MARK: 55424954
CNT: 02D23 DATA MARK: 55424945 VERSION CHAR(47) INIT('
TR10KOLJA Version
1.1 830603'); @ V
What is the programming language? Is it PL/1?
It seems like a record on the disk is a line!
Den mån 15 feb. 2021 kl 18:08 skrev Mattis Lind <mattislind at gmail.com>:
> I did some more research into this and found that a pattern 0x55509255 for
> Address mark and 0x55509251 for Data mark could be used to match against
> the incoming synchronized data stream (pre MFM decoding). These patterns
> contain the longer flux.
>
> I decoded the MFM data after the address mark and both track and sector is
> visible as what it seems to be valid bit patterns. What is interesting
> though is that the number of sectors appear to vary among tracks. Track 0
> had 128 address marks, while quite many had 81 sectors. Still others had 66
> and a few had 121. I studied track 18 more in detail and there were no gaps
> in the sector count so I guess nothing is missing. Address marks are spaced
> over the full number of samples (around 65k per revolution).
>
> My guess is that the data that follows the sector ID is some kind of
> checksum.
>
> I tried to understand the data field but wasn't very successful. Tried
> backwards and forwards and with varying bit offsets for both ASCII and
> EBCDIC. But not a single valid string. Perhaps my decoder had some fault.
> Will do a deeper study on the data field.
>
> I have put some files here if anyone has some insights:
> https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing
>
> Looking a bit further on the *.addressAndData files I see that it seems
> that the marks should probably contain the first bit of the decoded data
> that follows, since when MFM decoded data fields always starts with a 1 and
> address fields always starts with a 0. Including these also makes sense
> because then the Track and sector will end up on proper 8 bit boundaries.
>
>
> /Mattis
>
> Den lör 13 feb. 2021 kl 21:51 skrev Mattis Lind <mattislind at gmail.com>:
>
>>
>>
>> Den lör 13 feb. 2021 kl 21:06 skrev Chuck Guzis <cclist at sydex.com>:
>>
>>> On 2/13/21 11:15 AM, Mattis Lind wrote:
>>>
>>> > As to the 8x/5xH intervals, they appear to be part of the
>>> > preamble to address marks.
>>> >
>>> >
>>> > Can you please elaborate! What do you mean by 8x/5xH intervals?
>>> >
>>> > You think that these fluxes are part of some address mark or data mark,
>>> > right?
>>>
>>> By 8x/5xh I mean the intervals that you noted were 84 clocks. Consider
>>> a part of your sample:
>>>
>>> > 00003f0 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 20 1e 20 1d 20 1e | .........
>>> . . .|
>>> > 00000400 20 1e 20 1e 1f 1d 20 1d 20 1e 1f 1e 1f 1e 1f 1e | . ... .
>>> .......|
>>> > 00000410 1f 1e 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e |..
>>> .............|
>>> > 00000420 22 20 39 30 1f 2e 1f 1d 20 1e 20 1d 1f 1e 20 1d |" 90....
>>> . ... .|
>>> > 00000430 20 1e 20 1e 20 1d 1f 1e 1f 1e 1f 1e 20 1e 1f 1e | . .
>>> ....... ...|
>>> > 00000440 1f 1e 1f 1e 20 1d 20 1e 1f 1e 1f 1d 20 1e 1f 1e |.... .
>>> ..... ...|
>>> > 00000450 20 1d 1f 1c 54 2d 30 2e 1f 1d 1f 2f 1f 1d 1f 1d |
>>> ...T-0..../....|
>>> > 00000460 30 40 2f 2e 1e 1c 43 1b 44 2d 1e 1e 1f 1e 1f 1e |0@
>>> /...C.D-......|
>>> > 00000470 1f 2f 31 1d 1f 1e 1f 1e 1f 1e 1f 1c 21 1e 1f 1f
>>> |./1.........!...|
>>> > 00000480 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1e 1f 1e
>>> |................|
>>> > 00000490 1f 1e 1f 1f 1e 1e 1f 1e 1f 1e 1f 1e 1f 1e 1e 1f
>>> |................|
>>> > 000004a0 1f 1e 1f 1f 1f 1d 1d 53 2d 2f 2d 1d 42 1d 2e 30
>>> |.......S-/-.B..0|
>>> > 000004b0 2f 1e 1e 1f 1e 1e 30 30 1e 1e 1e 1e 1e 30 2f 1e
>>> |/.....00.....0/.|
>>>
>>> Note that the 54 at 0454 appears to be the preamble to an address mark.
>>> Similarly, we can see the same here:
>>>
>>> > 00000740 20 1e 20 1d 20 1e 20 1e 20 1d 20 1e 20 1d 20 1d | . . . .
>>> . . . .|
>>> > 00000750 1f 1e 20 1e 1e 1c 54 2c 30 2e 1f 1d 20 2f 1e 1e |..
>>> ...T,0... /..|
>>> > 00000760 1f 1d 30 40 2f 2e 1f 1d 1f 30 1e 2f 30 1d 1f 1d |..0@
>>> /....0./0...|
>>> > 00000770 31 2e 1e 2f 30 1d 1f 1e 20 1e 1f 1e 1f 1f 27 1e |1../0...
>>> .....'.|
>>> > 00000780 30 2f 1d 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f
>>> |0/..............|
>>> > 00000790 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f 1e 1f
>>> |................|
>>> > 000007a0 1e 1f 1e 1f 1f 1e 1d 53 2d 2f 2e 1d 42 1c 40 42
>>> |.......S-/..B. at B|
>>> > 000007b0 2e 2e 1c 43 2c 2e 41 1c 40 42 2c 2f 2f 1e 30 1e |...C,.A. at B
>>> ,//.0.|
>>> > 000007c0 30 1d 30 30 2e 1d 31 1e 1e 1f 1e 31 1d 1d 43 2e
>>> |0.00..1....1..C.|
>>> > 000007d0 1d 30 30 1e 1e 1f 1e 1e 30 30 1d 1f 1f 1e 1e 31
>>> |.00.....00.....1|
>>>
>>> Note the 54 at 0756 at the start of what appears to be an ID address
>>> mark and the 53 at 07a7 at the start of what appears to be a data
>>> address mark.
>>>
>>
>> That makes sense. I tried to hand decode the section directly after 0756
>> and it decoded fine as mfm. No violations. And I could see something that
>> could possibly be the value 5 which would then correspond to track 5. Now I
>> can try to write a piece of software that handles it and see if this gives
>> something useful. I have a directory listing so somewhere I think I could
>> match up what I get with that printout.
>>
>> /Mattis
>>
>>
>>> --Chuck
>>>
>>>
>>>
>>>
More information about the cctalk
mailing list