> On Feb 16, 2021, at 2:38 PM, Mattis Lind via cctalk
> 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
Den tis 16 feb. 2021 kl 19:04 skrev Chuck Guzis via cctalk <
cctalk@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
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
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
Den tis 16 feb. 2021 kl 03:16 skrev Fred Cisin via cctalk <
cctalk@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"
>
>
>
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
Den mån 15 feb. 2021 kl 20:51 skrev Fred Cisin via cctalk <
cctalk@classiccmp.org>:
> 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
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
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)
Yes, that looks very much like PL/1.
David
> On Feb 15, 2021, at 11:33 AM, Mattis Lind via cctalk
> 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
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 DATAMARK: 55424945 OKEY
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
Den lör 13 feb. 2021 kl 21:06 skrev Chuck Guzis :
> 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
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?
Den lör 13 feb. 2021 kl 19:45 skrev Chuck Guzis via cctalk <
cctalk@classiccmp.org>:
> 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?usp=sharing
Den lör 13 feb. 2021 kl 18:40 skrev Jon Elson :
> 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
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?usp=sharing
>
A quick glance shows the typical t 1.5t and 2t MFM pattern, so I'd start
with that. As to
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
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
19 matches
Mail list logo
