Yes, that looks very much like PL/1.
David
> On Feb 15, 2021, at 11:33 AM, Mattis Lind via cctalk <cctalk@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 <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
>>>>
>>>>
>>>>
>>>>
