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