Hello, 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 nop .endif .endm 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 Cycle 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 WD1772. 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? Regards, Spiro -- Spiro R. Trikaliotis https://spiro.trikaliotis.net/Received on 2022-03-11 19:03:04
Archive generated by hypermail 2.3.0.