The schematics for the 1581 infer a 6526A will work but the two drives I have both use an 8520A. I've read that the 8520A uses a 24-bit binary counter for TOD vs a BCD TOD in the 6526. The 1581 appears to use the TOD clock when a WD1770 chip is installed vs the WD1772 (jumper on the board which connects the phase 2 clock to the TOD input). I haven't looked at the 1571 drive hardware but the 1581 uses the serial port in the 8520A for fast serial transfer mode. As the 65C22 (like the original 6522) still has the serial port problem, you would need to either nix the fast serial mode or use additional hardware and programming to implement it. Still, using the 65C22 is an approach I would eventually take, as you can run a faster CPU clock and would also look at a bidirectional parallel port interface.

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

Hi
I think I understand what it is for.
The WD chip is a small uP. When it is busy it doesn't respond.
In other words, it floats the buss.
Have you ever looked at what is read from the buss when you
read an empty location?
It is the LSB of the address!
It is just code to make up for a slow chip that doesn't always
respond when it is busy.
Dwight

That's an interesting idea.... just not sure about how it would work (need to think about it more). In the code itself, it always reads the status register at the correct address ($6000), so there wouldn't be an empty location read. Then again, once the status register is read, the code masks off the lower two bits, then shifts bit 0 into the carry flag and does a branch if clear (those bits are Busy and DRQ). The Macro itself ensures that the ROM location for the SR read instruction has either bits 0 or 1 set.

I designed a controller using the WD2797 back in the 80's and did use some PHP/PLP sequences to lose some time when accessing the FDC, but never had any odd responses from the chip itself. It does seem a bit strange, but then again, the way the 1581 hardware accesses ROM and RAM it is a bit unusual as well, so your idea does have some foundation

I still need to look into this closer... plus and Jeff and I have kicked around a few other possible ideas for digging deeper into it. I'm hoping to get around to this a bit later this week or next... scope and logic analyzer attached! The good news is that I can write code to loop on some functions and burn it to EPROM and install in the drive.

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

I suspect it isn't allowing access before the register has valid data.
I think there is some other hardware methods but I think the main issue
is that it is really designed to do DMA.
Dwight

Anyway, I'm relatively sure that is it, unless someone else can come up with an
address dependency of the WD chip.
Dwight

An address dependency does seem possible. Moving the lda wdstat instruction around -- which is what the macro does -- apparently has an effect on the outcome.

My attention is on the transitions of address lines A1 and A0 in the cycles during and immediately after the lda wdstat. These cycles are:

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 the Status register
5. ROM access: fetch the opcode of the following instruction

Moving the lda wdstat instruction around results in the following four possibilities. During the cycles of interest, the A1 and A0 values could be...

1. 00,01,10,00,11 <-- problematic
2. 01,10,11,00,00
3. 10,11,00,00,01
4. 11,00,01,00,10

Sequence (a) is the one that the macro prevents from happening, seemingly because it causes a failure. So, looking at the latter part of sequence (a), is there something weird about the 10,00 transition? Better yet, what about the 00,11 afterward? (At the sub-cycle level, it's during phase 2 of the 00 cycle that the data gets moved. Then, on the instantaneously following phase 1, A1 & A0 both change low-to-high.)

Theories, anyone? I tend to suspect a flaw in the 1581 more so than a problem in the FDC chip itself. Meanwhile keep us posted, please, floobydust, and best of luck in your efforts.

-- Jeff

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

xxxxxxxxxxxxxxxxxxI think you have it backwards.
xxxxxxxxxxxIt is the second case that adds a nop.
My bad, I was looking at it wrong.

Dwight

No sweat. The macro isn't especially intelligible, is it!

I'm starting to think I was mistaken to suspect the flaw is in the 1581 drive electronics (not the FDC chip). Looking back over the earlier posts, I see John West said the mysterious macro is used in the 1571 firmware as well.

This business about the 00,11 sequence still seems pertinent, though. As I was saying in a PM to floobydust, 11 is the address of the Data Register, which is "read sensitive." By design, a read of that register can alter the state of the chip -- implying that a rogue read can upset normal operations.

Clearly there's a glitch somewhere, whether it's in the drive electronics or the actual FDC chip. Either way, it seems plausible -- or at least not impossible -- that the (normal, intended) read of address 00 could fail to terminate promptly, causing the read to endure for an extra few dozen nanoseconds. If so, the address during that time will make a difference. The rogue read could hit register 00 01 or 10 and be harmless. But if it hits a read-sensitive register (like 11) then that could explain the trouble.

Just a theory. I need to re-read that FDC datasheet. IIRC, Register 11 is read-sensitive with respect to the "Lost Data" flag.

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

If he put nop in front of all the status reads, it could end up creating
the 00,11 sequence. That would explain why all having nop fails
I think you may be on to it. It just doesn't stop decoding the
address fast enough.
This is most likely a race condition in the address decoder.
Dwight

( last week someone sent me the following tech humor )

Q: Knock knock,
Q: Race condition.
A: Who's there?

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Gentlemen, I've been following this topic and for some strange reason, my memory was jogged concerning a conversation Lloyd Sponenburgh and I had had in the late 1980s about the WD1772 floppy controller's behavior.

Lloyd, who was one of the two architects of the Xetec Lt. Kernal (LK) hard drive subsystem for the Commodore 64 and 128, was working on FASTCOPY, which is an LK utility for rapidly copying files between the hard drive and a 1571 or 1581. He kept running into sporadic errors following an access to one of the WD1772 registers and ended up contacting Commodore for help. What I recall was Lloyd was told by Commodore there was a certain WD1772 register that could only be "touched" once every 8 or 16 clock cycles (I don't recall the exact number), a clock cycle being the clock driving the WD1772. That could explain the macro kludge, since the NOP would throw a couple of microseconds of delay in there.

Dunno if any of this helps.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hi BDD,

The same access timing existed with other earlier WDC FDC chips as well, like the 2797. The clock that drives the WD1772 is 8MHz and the clock rate for the 6502A is 2MHz, both derived from the 16MHz can oscillator via a 74LS93 counter. There are numerous sections in the 1581 code where 20 NOPs are inserted after accessing one of the WD1772 registers, likely to allow the chip to handle a command or respond to an access.

The thing with the macro, it doesn't appear to be a timing related mechanism, but to ensure that the instruction that will read the status register is located in ROM at an address where the lower two address bits are not zero. It almost seems that the address lines (which also are connected to the WD1772) need to toggle some number of times before accessing the status register, otherwise the SR read doesn't come back with the correct results. I'm still puzzled on this one.

Unfortunately, I've managed to tear a miniscus in my left knee and have limited mobility (including standing) for the next few weeks at a minimum. As a result, I've been a bit limited on trying to get back to this as well.

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

Ouch! Sorry to hear that. Were you playing football?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

LOL... no, not at my age, replaced the hot water heater one day, then worked on some of the cars the next day, followed by cycling the day after that. The knee went out 2 days later while playing a game of pool, talk about embarrassing!

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