13 Feb
2021
13 Feb
'21
9:18 a.m.
I have a few 8 inch floppy disks coming from a Q1 Lite computer. I tried
reading them on a PC with a Adaptec 1522A floppy controller but it failed
completely.
Then I tried my Catweasel and dumped the raw flux data. The format differs
from what I have seen before.
I did a quick histogram of the flux lengths and it appears that there are
four groups of sample lengths evenly spaced. Peaks at 30, 48, 66 och 84
samples flux lengths.
The longest flux lengths are interspersed in between more normal flux
lengths in the actual data and I get the same type of result regardless of
reads of the same track and between different tracks. But the relative
frequency is much much lower for the longer flux lengths than the shorter
ones.
An RX02 (MFM ish) had 26, 41, 55 samples as the peaks in the histogram.
As far as I understand cw2dmk software uses 14 MHz setting in the catweasel
so each sample length is around 70ns.
Anyone that has seen this kind of format before? Or is it just a reading
error? I have the same result from several discs though and they look to be
in quite good shape physically.
Link contains histogram files and a raw track flux file.
https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?us…
13 Feb
13 Feb
9:40 a.m.
On 02/13/2021 11:18 AM, Mattis Lind via cctalk wrote:
The longest flux lengths are interspersed in between
more normal flux
lengths in the actual data and I get the same type of result regardless of
reads of the same track and between different tracks. But the relative
frequency is much much lower for the longer flux lengths than the shorter
ones.
The low-frequency of occurrence flux changes may be head
switching when the write and erase current is turned on and
off at the beginning and end of data blocks. So, those
should be ignored.
Jon
11:05 a.m.
Den l?r 13 feb. 2021 kl 18:40 skrev Jon Elson <elson at pico-systems.com>:
On 02/13/2021 11:18 AM, Mattis Lind via cctalk wrote:
Yes. I am aware of write splicing. I would imagine that the number of these
longer fluxes should be somewhere around two times the number of sectors,
right?
I see much more than what I would I would guess is the sector count.
Wouldn't these write splicing fluxes distribute quite evenly in terms of
length, creating a noise of weird fluxes?
In this case there are quite some fluxes centered around 84. If this would
be a result of write splicing I would think the same would happen on the
RX02 disk. I cannot see any of these long type fluxes there. How can that
be explained?
/Mattis
The longest flux lengths are interspersed in
between more normal flux
lengths in the actual data and I get the same type of result regardless
of
reads of the same track and between different
tracks. But the relative
frequency is much much lower for the longer flux lengths than the shorter
ones.
The low-frequency of occurrence flux changes may be head
switching when the write and erase current is turned on and
off at the beginning and end of data blocks. So, those
should be ignored.
Jon
10:44 a.m.
On 2/13/21 9:18 AM, Mattis Lind via cctalk wrote:
Link contains histogram files and a raw track flux
file.
https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?us…
A quick glance shows the typical t 1.5t and 2t MFM pattern, so I'd start
with that. As to the 8x/5xH intervals, they appear to be part of the
preamble to address marks.
--Chuck
11:15 a.m.
Den l?r 13 feb. 2021 kl 19:45 skrev Chuck Guzis via cctalk <
cctalk at classiccmp.org>:
On 2/13/21 9:18 AM, Mattis Lind via cctalk wrote:
A quick glance shows the typical t 1.5t
and 2t MFM pattern, so I'd start
with that.
I'll try that.
Link contains histogram files and a raw track
flux file.
https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?us…
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?
--Chuck
12:06 p.m.
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.
--Chuck
12:51 p.m.
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:
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
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.
--Chuck
15 Feb
15 Feb
9:08 a.m.
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:
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
>
>
>
> 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.
11:33 a.m.
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
>>
>>
>>
>>
11:39 a.m.
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?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
>>>
>>>
>>>
>>>
11:51 a.m.
On Mon, 15 Feb 2021, Mattis Lind via cctalk wrote:
My guess is that the data that follows the sector ID
is some kind of
checksum.
yes. well, sorta. 16 bit CRC
A typical IBM/WD style format has:
a gap
Index Address Mark
a gap (note that WD can use a shorter post index gap than NEC can)
and then, repeated for each sector:
{
a gap
ID Address Mark,
C Cylinder number
H Head number (0,1)
R Sector number
N Sector Length (0:128, 1:256, 2:512, 3:1024)
16 bit CRC of the sector header
a gap
Data Address Mark
Sector data (128, 256, 512, or 1024 bytes. Larger is possible, but unlikely)
16 bit CRC of the data
a gap
}
(This is from memory (error prone?). The WD1791 datasheet should have
more detail, including CRC algorithm?, the specific requirements for the
address marks, and gap contents (write splice, synchronization, etc.))
--
Grumpy Ol' Fred cisin at xenosoft.com
12:13 p.m.
On 2/15/21 11:51 AM, Fred Cisin via cctalk wrote:
(This is from memory (error prone?).? The WD1791
datasheet should have
more detail, including CRC algorithm?, the specific requirements for the
address marks, and gap contents (write splice, synchronization, etc.))
The thing to note is that the mark (data or address) is almost always
included in the CRC calculation.
Also, some early representations could have non-powers of 2 sector
lengths. (the WD1781 for example, encoded the length in multiples of 16
bytes; the Zilog MCZ used 132 byte sectors). But they are the exceptions.
--Chuck
12:36 p.m.
Den m?n 15 feb. 2021 kl 20:51 skrev Fred Cisin via cctalk <
cctalk at classiccmp.org>:
On Mon, 15 Feb 2021, Mattis Lind via cctalk wrote:
Well. Now this is NOT a standard 179x that has written this. As I mentioned
early on in this thread it was not at all possible to read the disks with a
standard controller. The bit rate was off by quite a bit and the general
format is different. So this is not necessarily a CRC at all. The machine
that has written these is the Q1 Lite computer. A very odd mid-seventies
system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf.
Here is an example header:
CNT: 021D5 ADDRESS MARK: 55424954 00000001 01000101 01000110 00010000
000000V00 00000000 00000000 00000000 00000000 00000000 0V0100100 0V00
"V" is for MFM violation, most likely due to write splicing after the
header when enabling writing. This means that the header is at most 4
bytes. First bytes is track, second byte is sector. The third byte appears
to be the sum of the track and sector byte. The fourth byte is unknown. In
all the tracks it seems to have the same value.
/Mattis
My guess is that the data that follows the sector
ID is some kind of
checksum.
yes. well, sorta. 16 bit CRC
A typical IBM/WD style format has:
a gap
Index Address Mark
a gap (note that WD can use a shorter post index gap than NEC can)
and then, repeated for each sector:
{
a gap
ID Address Mark,
C Cylinder number
H Head number (0,1)
R Sector number
N Sector Length (0:128, 1:256, 2:512, 3:1024)
16 bit CRC of the sector header
a gap
Data Address Mark
Sector data (128, 256, 512, or 1024 bytes. Larger is possible, but
unlikely)
16 bit CRC of the data
a gap
}
(This is from memory (error prone?). The WD1791
datasheet should have
more detail, including CRC algorithm?, the specific requirements for the
address marks, and gap contents (write splice, synchronization, etc.))
--
Grumpy Ol' Fred cisin at xenosoft.com
6:16 p.m.
Thanks for the brochure.
That looks like a fascinating project!
Computerworld mentioned it occasionally in 1980.
I love that "Pl/1 will soon emerge as the dominant language of
microcomputers"
If you haven't already exhausted such leads (apologies if you already
have), some trivial GOOGLE'ing turned up the name (and autobiography) of a
guy who designed one of their disk controllers:
https://onedrive.live.com/?authkey=%21AFZhXO9UdDh2wbg&cid=5982EE6D20F4C…
https://www.old-computers.com/museum/forum.asp?c=1286&st=1
https://philosophycentral.org/technology/
Sorry, NO technical details of the controller that he designed.
On Mon, 15 Feb 2021, Mattis Lind wrote:
Well. Now this is NOT a standard 179x that has written
this. As I mentioned
early on in this thread it was not at all possible to read the disks with a
standard controller. The bit rate was off by quite a bit and the general
format is different. So this is not necessarily a CRC at all. The machine
that has written these is the Q1 Lite computer. A very odd mid-seventies
system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf.
16 Feb
16 Feb
2:18 a.m.
Den tis 16 feb. 2021 kl 03:16 skrev Fred Cisin via cctalk <
cctalk at classiccmp.org>:
Thanks for the brochure.
That looks like a fascinating project!
Computerworld mentioned it occasionally in 1980.
I love that "Pl/1 will soon emerge as the dominant language of
microcomputers"
If you haven't already exhausted such leads (apologies if you already
have), some trivial GOOGLE'ing turned up the name (and autobiography) of a
guy who designed one of their disk controllers:
https://onedrive.live.com/?authkey=%21AFZhXO9UdDh2wbg&cid=5982EE6D20F4C…
I have seen them, except for that one. Quite a rambling story. I only
managed to read parts of it. Unfortunately there was little detail of what
he did, except that he did everything. A bit interesting to compare the Q1
Story with the one provided by Daniel Alroy.
The disk controller probably had some intelligence in itself. It seems to
have been connected over sync serial links to the computers. Probably it
provided a quite high level interface to the computer. When I analyzed the
tracks further I found that track 0 had 40 bytes sectors. Then there were
tracks that had 80 character sectors. These were mostly text data on these
tracks. A few tracks had sectors with 256 bytes. They seemed to contain
binary data. I assume track 0 contains the directory that tells what files
go where and the sector size on that track. Supposedly the intelligent
floppy controller (more like a file server) knows of the directory
structure and file structure of the various types of files there are.
In a sense this type of 80 characters record fits very well with classic
punch cards. Perhaps data entry was a big application?
This type of early distributed systems look a bit like the Cogar 4 /
Singer/ICL 1500 systems or Incoterm SPD 10/20. Intelligent terminals with
local storage connected to a central storage (file server).
https://www.old-computers.com/museum/forum.asp?c=1286&st=1
https://philosophycentral.org/technology/
Sorry, NO technical details of the controller that he designed.
On Mon, 15 Feb 2021, Mattis Lind wrote:
Well. Now this is NOT a standard 179x that has
written this. As I
mentioned
early on in this thread it was not at all
possible to read the disks
with a
standard controller. The bit rate was off by
quite a bit and the general
format is different. So this is not necessarily a CRC at all. The machine
that has written these is the Q1 Lite computer. A very odd mid-seventies
system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf.
10:04 a.m.
Building floppy controllers from MSI TTL was not uncommon, even after
the debut of the WDC LSI chips, which were initially very expensive.
Even the bit ordering on some of the early controllers wasn't settled.
You can see LSB-first and MSB-first encoded floppies, GCR, MMFM, hard-
and soft-sector implementations. There wasn't a strong push toward the
IBM implementations (3740/System 3) until the later part of the 70s.
All of which can make deciphering of the early floppy formats "interesting".
I was surprised in the mid-1970s on a remote console project that I
managed to find that the CDC engineers rolled their own UARTs from SSI.
Apparently simpler to use off-the-shelf components for a couple-off
project than try to justify a part not in the parts crib already that
may or may not have a second source.
--Chuck
11:07 a.m.
I think by 75 we at DEC hwe had at least two pin compatible source for
UART, While CHester G Bell gets credit for the design, my memory is
that Vince Bastiani did the design. That set the stage for having the
Synchronus /Isochronous chips built too. Signetics was contracted to
do the 2652 based on my lineunt design used in the DMC11 (similar to
DP8/e and DP11, but ssi chip count reduced and a good bit faster. The
SMC chip was based on Frank Zereksi's DU/DUP 11 design.
bob
On Tue, Feb 16, 2021 at 1:04 PM Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
Building floppy controllers from MSI TTL was not uncommon, even after
the debut of the WDC LSI chips, which were initially very expensive.
Even the bit ordering on some of the early controllers wasn't settled.
You can see LSB-first and MSB-first encoded floppies, GCR, MMFM, hard-
and soft-sector implementations. There wasn't a strong push toward the
IBM implementations (3740/System 3) until the later part of the 70s.
All of which can make deciphering of the early floppy formats "interesting".
I was surprised in the mid-1970s on a remote console project that I
managed to find that the CDC engineers rolled their own UARTs from SSI.
Apparently simpler to use off-the-shelf components for a couple-off
project than try to justify a part not in the parts crib already that
may or may not have a second source.
--Chuck
11:38 a.m.
Den tis 16 feb. 2021 kl 19:04 skrev Chuck Guzis via cctalk <
cctalk at classiccmp.org>:
Building floppy controllers from MSI TTL was not
uncommon, even after
the debut of the WDC LSI chips, which were initially very expensive.
I got information from a person that worked for Q1 reseller in Denmark that
the floppy controller was built entirely out of TTL chips. No CPU
whatsoever. It was interfaced through a parallel bus to the main computer.
What is interesting is that it had variable record length. It was specified
during the format process which tracks had what number of records and their
size. The first track always had 40 bytes record since it was the INDEX
track. File allocation was on a track basis. In the INDEX file each file
then had a start track and stop track as well as information on how many
records there were in the file and what size each record was. Also the
number of records per track were included in the file specification.
I have never ever heard of such a scheme before.
/Mattis
11:43 a.m.
On Feb 16, 2021, at 2:38 PM, Mattis Lind via cctalk
<cctalk at classiccmp.org> wrote:
...
What is interesting is that it had variable record length. It was specified
during the format process which tracks had what number of records and their
size. The first track always had 40 bytes record since it was the INDEX
track. File allocation was on a track basis. In the INDEX file each file
then had a start track and stop track as well as information on how many
records there were in the file and what size each record was. Also the
number of records per track were included in the file specification.
I have never ever heard of such a scheme before.
/Mattis
I haven't, for floppies. But flexibility even more than that is found in IBM/360 disk
drives, where you get to write sectors of variable length, and you don't even have to
pick them ahead of time. Not to mention that those have keyed sectors, allowing you to do
primitive databases directly in hardware.
A similar but more restrictive scheme is the disk drives on the Electrologica X8 (2311
lookalikes, built by CDC I think) where you have a choice of 6 different sector sizes, and
you get to make the choice separately for each track, at format time. You can reformat
any track at any time.
paul
1174
days inactive
1177
days old
18 comments
7 participants
participants (7)
-
bobsmithofd＠gmail.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
david＠kdbarto.org -
elson＠pico-systems.com -
mattislind＠gmail.com -
paulkoning＠comcast.net