More findings regarding the disk controller

Juergen Buchmueller pullmoll at t-online.de
Wed Jun 20 17:36:43 PDT 2007


On Wed, 20 Jun 2007 16:12:03 -0700 (PDT)
"Eric Smith" <eric at brouhaha.com> wrote:

> Juergen wrote:
> > I hope these pieces of info are helpful for Altogether, too.
> 
> Most definitely!  Thank you very much for sharing your findings,
> which obviously have required a lot of hard work.

That was to be expected. The main difference between the display section
and the disk controller, which also share some ideas, is the free running
bit stream and the resulting synchronization problems. The display hardware
was, compared to this, peanuts.

I'm beginning to see the reasons for the one or another signal and when
and why a bit (flip-flop) must be changed or latched.

Currently I'm hunting down the reason why, after successfully booting
sector 0 and loading some page to 01000 to 01377, the microcode switches the
XFEROFF and WFFO to 1, and expects to be awakened after some time - which
it isn't. Then that same page is loaded again, and everything repeats.

I could once more tell what I understood until now:

The raw sector data contains, as it seems, words with the value 0x0001 in
all empty areas - the *ambles. I already described the embedding of fields
containing data, and I was close, except that of course both words of the
header are there. The first field, which i called mfrdl1 after the
microcode constant names, seems to be one word shorter (20), though.

What happens, when the logic is in "free running mode", is that it
synchronizes on the first 1 bit being left shifted to the most significant
bit of the input shift register. The sync data words in the disk image
are 0x0001, so after 16 left shifts the 1 hits the HIORDBIT (MSB), which
triggers an event that sets the WFFO bit and wakes the KWD. From then on
words are latched on every 32 bitclk cylces, i.e. 16 edges of alternating
BITCLK and DATAIN changes.

The microcode skips an amount of data it "knows" to be uninteresting, i.e.
the various pre- and postamble words, and one word before the interesting
data is to be expected it resets the WFFO bit. This is what I called "free
running mode". The very last *amble-word before a field (record) then
synchronizes the bitstream onto a word boundary. The 0x0001 being in the
input latch is ignored and the next word is known to be aligned. The CKSUM
register is initialized to 0521 here.

Then reading continues for the length of the field, and finally the checksum
word. The field words are XORed and the checksum word is subtracted from
the CKSUM register. If the final result is zero, the XFEROFF and WFFO bits
are set, if this was the last record, i.e. data. This is also the point
where I am looking for a bug in my implementation just now.

BTW: the fields, or records, as they are in the *.dsk.Z images, are really
to be read in backwards(!) direction, because the microcode expects it that
way. I guess the transfer program just read and transferred the image on the
fly, without first reading them backwards into some memory location and to
then transfer them in forward direction.


More information about the Altogether-devel mailing list