1571/1581 Sources: Macro WDTEST inserting NOP before reading WD177x status register / writing command register

From: Spiro Trikaliotis <ml-cbmhackers_at_trikaliotis.net>
Date: Fri, 11 Mar 2022 17:41:27 +0100
Message-ID: <Yit7txwuWMgqfQ97_at_hermes.local.trikaliotis.net>

I am trying to understand the sources of the 1571 and 1581 drives.

In the original drive sources of the 1571 and 1581 (as found on
zimmers.net), there is a macro WDTEST:

WDTEST  .macro
        .ife <*!.$03

I am not completely familiar with the syntax of the assembler used, but
if I understand it correctly, it issues a NOP if bit 0 and bit 1 of the
PC are both 0 - that is, the PC address is divisble by 4.

The (incomplete) listing at
http://www.zimmers.net/anonftp/pub/cbm/src/drives/serlib.zip seems to
confirm my assumption.

This macro is always used before the WD177x status is read (lda, bit) or
stored to the same address (WD177x command register). That is, it is
always similar to this:

        WDTEST          ; chk address
cmd7    lda  wdstat

So, can anyone think of a reason WHY it is done this way? I cannot think
of a reason why this NOP would be needed in some cases, and why it
depends upon the address bits.

I have thought if there might be a problem if the PC is divisible by 4,
because of the sequence of the bus operation of the 6502? That is, could
it be that the WD177x accidiantially recognises a read of the DATA
register, and there would be data loss?

What do I mean?

The 6502 absolute addressing is as follows (looking into the MOS 6502
programming manual, appendix E.3):

Clock    Adress Bus      PC      DAta bus    comments
  1        PC           PC + 1    OP CODE    fetch op code
  2        PC + 1       PC + 2    ADL        fetch ADL
  3        PC + 2       PC + 3    ADH        fetch ADH
  4        ADH,ADL      PC + 3    Data       fetch Data
  5        PC + 3       PC + 4    OP CODE    fetch new op code, execute old op cod

Now, if in cycle 4, there would be a glitch in that the ADH is already
correct, but the ADL is not yet there (but, instead, PC+3 would be
output), this might be a read (or write) to the data register of the

I know, this is a VERY wild guess, and I cannot think that this problem
would only occur in the 157x and 158x drives, but also with other
peripheral devices (like CIA, PIA, VIA, ...). Unfortunately, other than
that, I cannot think of any reason for these NOP.

Does anyone have any insights here?


Spiro R. Trikaliotis
Received on 2022-03-11 19:03:04

Archive generated by hypermail 2.3.0.