My I answer on this old thread? I even registered here in order to add what I have to say.

I stumbled about the WDTEST macro myself some days ago, and I tried to do my own investigations.

I wrote my findings an guesses on the cbm-hackers mailing list (cf. http://www.softwolves.com/arkiv/cbm-hac ... 1585.html; unfortunately, many of the postings on this list were very OT), and I want to give the results here:

My first post was (http://www.softwolves.com/arkiv/cbm-hac ... 31585.html):


---------------------------

Then, Francesco/Frank answered with another wild guess, saying that it might be related to using the "wrong" clock PHI1 instead of PHI2 (http://www.softwolves.com/arkiv/cbm-hac ... 31586.html):



I said it doesn't make sense, because the -CS of the WD177x is wired to PHI2 (cf. http://www.softwolves.com/arkiv/cbm-hac ... 31591.html), and it was confirmed by Gerrit Heitsch (in http://www.softwolves.com/arkiv/cbm-hac ... 31592.html).



Now, I believe I was wrong and I looked into the wrong floppy drive! I believe this is a problem of the 1571 only, not of the 1581! This might explain why the tests made above did not show any result!

I wrote the following (cf. http://www.softwolves.com/arkiv/cbm-hac ... 31638.html):



Now, I think you are more knowledgeable on the 6502 than I am. Does anyone know how long the delay of the PHI1 going high after PHI2 going low? The data sheet only says "0 ns min." for "Delay between PHI1 and PHI2", which does not help much.

Of course, even if it is a problem, it might not be a problem with all 1570/1571 drives.

(Welcome! Thanks for popping over and summarising the findings in that thread... which I was vaguely following. However, I don't think I have any answers for you.)

Well, nice to see an update on this thread. As for the 1571 being affected and the 1581 not being affected, I can easily say that's not the case. The 1581 will fail if you assemble and link the BIOS without the WDTEST macro.

In short, the macro simply ensures that either A0 and/or A1 are active before accessing the base address of the WD1772 FDC. I'm still nor sure why, but that appears to be the case. If you look at the listing file after the code is assembled and linked, you will find that in every instruction that accesses the status register ($6000), either A0 and/or A1 is active (high). In some cases either one will be active and even both active. In short, the macro will trigger based on the lower 2-bits of the address. Perhaps another way to look at this is: every time the status register is accessed, either A0 and/or A1 must be switched from active to inactive. Also note that the PH2 clock is used as part of the chip select for the WD1772.

I'm just guessing at this point, but it would suggest that there is some unusual timing for the based address, which is the status register. Other registers for the FDC don't use the macro preceding the access, so that seems to imply that's it's specific to an odd internal timing of accessing the status register. I would also note that the hardware interrupt from the WD1772 is not used, nor is the DRQ line, so the chip is only operated in polled I/O mode. Interestingly, the Motor drive line is also not used, as that line to the drive is driven from the 8520.

I guess one could track down Fred Bowen (the guy who wrote the 1581 code) and ask him... last I checked, he did have a LinkedIn profile.

_________________
Regards, KM
https://github.com/floobydust

Welcome, strik. Thanks for bringing our attention back to this issue, and for sharing some of the content from the recent cbmhackers thread. Here on 6502.org this intriguing little mystery hasn't received any attention since 2017, and I've just finished reviewed the entire thread in order to refresh my memory.

Although the investigation got set aside before any conclusion was reached, looking back I feel confident I was hot on the trail of the explanation. Although this remains to be proven, I am perhaps supported by some of Francesco's remarks which you quoted, although he's coming at the thing from a different direction. Frank seems cautious about his observation (calling it a "wild guess"), and I too am unsure what to think. If the low phase of Phi1 is larger (ie, wider) than the high phase of Phi2 then it would begin slightly too early and it would also end slightly too late.



I'm not ready to specifically blame the "poor man's inverted phi2" but I will say there's a convincing explanation of why the floppy system will fail if the FDC Chip Select goes inactive too late. What'll happen is, the FDC will remain selected during a fraction of the CPU's next cycle (as it fetches the next opcode). In other words, the FDC will experience a rogue read.

So, why does the macro care so much about the two LS address bits? It's because the location in memory of the LDA wdstat instruction will determine which FDC register experiences the spurious touch.

The LDA wdstat instruction takes four cycles, and then the CPU proceeds to fetch the next opcode. Here are those five cycles:

1. ROM access: read the LDA opcode
2. ROM access: read the LDA LS operand byte
3. ROM access: read the LDA MS operand byte
4. FDC access: read register "rr" <== (rr is the reg we intend to read)
5. ROM access: fetch the next opcode. Early in this cycle is when the rogue read of the FDC occurs.

... and, according to the location in memory of the LDA instruction, here are four possible scenarios for the two LS address bits during the five cycles in question:

1. 00,01,10,rr,11 <== rogue read of the Data Reg
   
2. 01,10,11,rr,00 <== rogue read of the Status Reg
3. 10,11,00,rr,01 <== rogue read of the Track Reg
4. 11,00,01,rr,10 <== rogue read of the Sector Reg

What we see here is, only if the LDA opcode is at binary xxx00 will the rogue read touch the FDC Data Register. And AIUI, the Data Reg is read sensitive, whereas rogue reads of the other three FDC addresses produce no significant side effects and can be tolerated. This explains why they created a macro to prevent the LDA opcode from residing at binary xxx00.


In 2017 I posted some experimental hardware hacks intended to correct the problem and thus verify the theory. The hacks involved adding a transparent latch that'd prevent the FDC from receiving the updated A1 and A0 that appear during the opcode fetch. But Francesco's remarks have inspired me to consider mods to the clock signal instead -- an easier approach.

Said mods could take various forms, and although they're fairly simple I'll make them the subject of a separate post. The goal is to ensure the FDC gets deselected earlier so it doesn't see the A1, A0 values associated with the opcode fetch. Comments and suggestions welcome.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I also spent some time over the past few nights digging into this. I also grabbed some schematics for the Atari ST machines, which also use the WD1772 controller. With the Atari machines, all of the CPU interface lines are connected to their DMA controller, including the data and address lines, R/W, DRQ and CS. Granted, no real knowledge or info on Atari's DMA chip (custom chip), but it does give them absolute control and timing for all registers in the FDC.

I would also reference the WD datasheet, which is not all that great to be honest. It's a bit odd that they don't show any address lines on Read Timings to the FDC, yet they show address lines on Write Timings to the FDC, odd.

Based on everyone's recent input, I would tend to take a different approach for accessing the WD1772. WD did what I would call a half-a** approach to a Motorola 6800 interface (as there's no clock line), so the clock qualification has to happen outside the chip. I would think that isolating the address lines from the address bus and only having them driven when truly selected could in fact be a fix. I'm thinking this is what Atari is doing by having all host interface signals managed by their DMA controller and never being connected to the actual CPU bus. This eliminates any timing anomalies between the various CPU cycles.

To address this (pun intended), either a few gates might be added, or just use a PLD and replace more of the existing circuitry as well... things like all memory and I/O decoding, qualified read and write signals for memory and managing the address lines along with the chip select for the WD1772.

Lastly, I would note that the 1581 drive does not use the PH1 signal from the CPU. PH2 is used for the FDC CS qualification however (and the clock line to the 8520 CIA), and the main CPU clock is used via a 7406 inverter for driving the half of the 74LS139 to generate a qualified write signal for the 8KB SRAM.

Now I need to think if it would be reasonably easy (without hacking the 1581 PCB) to implement such a fix.... hmmm, some more nights ahead on digging.

_________________
Regards, KM
https://github.com/floobydust

All,

Jeff (Dr Jefyll) and I have had some PM going on over the past month or so related to this. Jeff has suggested that the timing is too slow for the /CS line and suggested replacing the 74LS00 with a faster chip (74AHCT00).

A few years back, I took my second 1581 drive and removed all of the chips, capacitors and can oscillator from the PCB. I cleaned out all of the holes, installed new caps and a full set of high quality Mill-Max sockets. I then used new 74HCT logic chips, a new 8KB SRAM and a Rockwell R65C02P4 CPU. The only chips that were kept were the 8520A CIA and the Western Digital WD1772-PH floppy controller. Well, even with the faster HCT logic, there was no difference. The WDTEST Macro was still required! Jeff's suggestion of getting even faster chips was noted (and added to my existing Mouser order).

I opted to do some additional testing... my first 1581 (which is a higher serial number than the first) has a VLSI 1772-02 floppy controller (soldered in). Some years ago, I ordered a few NOS VLSI1772-02 FDCs (which were licensed by WD) and also picked up a few of the Atari made chips, which support the higher data rates for the HD diskettes. I opted to install a VLSI chip, modified the source code and commented out the WDTEST macro. To my surprise, the drive still works... and I've done significant testing over the past few days on this. Note: The Atari controller also works fine in the drive. If replace either the 74HCT139 or 74HCT00 with the original LS parts, the drive eventually fails.

This does highlight that early WD1772-PH controllers have some internal timing problems. It would appear that these were likely corrected when they brought out the WD1772-02 (and even later -02-02) parts, which also have high performance digital data separators. Still, the datasheet is identical to the initial version... so nothing to suggest there is any difference, but there certainly is.

I think Jeff had the right idea... and it seems to be the case. I've added some faster logic chips to my existing shopping list, and at some point, I'll perform additional testing and see if it's possible to have the WD1772-PH controller work without the macro as well... but it will likely be a while... just not sure.

As for my current source code, I've done a fair amount of work on it. It now uses several CMOS opcodes and addressing modes, has sorted out the correct stepping rates for the Chinon drive, integrated the patches implemented in the -02 ROM version, fixed a bug in a routine where the stack wasn't getting pulled properly and I fixed the init code for the ROM checksum so it's working again. The same goes for the Signature 16-bit ROM check. I also changed the ROM version to -03 and the 1581 DOS version to 10C (C for requiring a CMOS CPU).



Hope some others find this useful. At some point (more testing to be done) I'll post the updated source code and -03 ROM image, so others can also update their 1581 if desired.

_________________
Regards, KM
https://github.com/floobydust