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 <mattisl...@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 <mattisl...@gmail.com>: > >> >> >> Den lör 13 feb. 2021 kl 21:06 skrev Chuck Guzis <ccl...@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.@B| >>> > 000007b0 2e 2e 1c 43 2c 2e 41 1c 40 42 2c 2f 2f 1e 30 1e |...C,.A.@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 >>> >>> >>> >>>