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?us…
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
>>
>>
>>
>>