Deciphering an odd floppy disk format.

David Barto david at kdbarto.org
Mon Feb 15 13:39:58 CST 2021


Yes, that looks very much like PL/1.

	David

> On Feb 15, 2021, at 11:33 AM, Mattis Lind via cctalk <cctalk at classiccmp.org> wrote:
> 
> 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 cctech mailing list