Hi,

I designed my own Z280 system, which uses a WD2797 as a floppy disk
controller.
I managed to read and write sectors on the floppy but I had two problems.

1. My WD2797 is very sensitive on the CS# input signal. When I read one
sector there are one or two bytes missing in the read data from the
floppy. I used an scope the measure DRQ CS# and RD# and I saw several
small CS# pulses (CS# going low) without accompanying RD#. In this case
the DRQ goes from high to low again and I assume the DMA, which transfers
the data from the WD2797 does not see the data request which results ina
data loss.
The byte count of the DMA is zero after read date transfer,but I think
this is due
to the problem number two. The CS# depends only on the address signals
and the status
signals of the Z280, the latter are used to determine if this is an IO sequence.
So I think it is not unusual if I see CS# pulses without a RD#.
I changed the logic which creates the CS# signal to the WD2797 so there are
no 'glitches' on the CS# signal anymore and now there are no missing
data bytes.

2. If I read an sector the DMA reads all data bytes but the DRQ signal
of the WD2797 is still activ after the last data byte read by the DMA.
I increased the DMA byte count upto 10 additional data bytes and still
the DRQ signal is activ after the read transfer. I wrote a test program
which setups
the WD2797 and the DMA within the Z280 for reading one sector and then
polls the
interrup signal of the WD2897. When the interrupt signal is set, the
test program
reads the status register of the WD2797 and displays it. The lost data
bit and the
data request bit are set in the status register. Then the test program
reads the
data register and the status register and displays the status register.
This time the
data request bit is reset and also the external DRQ# signal of the WD2797.
The lost data bit is still set. I assume I can live with this work around.

Does anybody know if this is the normal behavior of WD2797, a bug in my
chips
or are am I missing something ?

I have two WD2797 chips, both are very old, both show the same behavior.
Is it possible the chips are damaged internally ?

My command for reading one sector is 80H, so the multible record bit is definitely set to zero.

Sven

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/22/21 6:41 AM, sven wrote:

So I think it is not unusual if I see CS# pulses without a RD#.
I changed the logic which creates the CS# signal to the WD2797 so there are no 'glitches' on the CS# signal anymore and now there are no missing
data bytes.

That seems odd as the data sheet gives a setup time for CS to RD or WR
which certainly implies that CS changing state without a read or write
strobe shouldn't cause any trouble. If CS is changing within the 50ns
setup time, then all bets are off.

I have never used it with DMA but that shouldn't make much difference
since the response to a DMA request is just an I/O cycle. I looked at my
old BIOS code and it didn't help much. The data transfer loop checks DRQ
and INTRQ (those pins are routed to tristate buffers).

It has been a while since I looked at this code...

rloop:
btst #6,(a2)
bne rdone
btst #7,(a2)
beq rloop
move.b ddata(a2),(a1)+
bra rloop
rdone:
bsr rstatus
move.w imsave,sr * re-enable interupts
tst.b d0
bne rerror

rstatus:
move.b dstat(a2),d0 * read status
and.w #$9d,d0 * set condition codes
rts

The transfer loop checks the DRQ and INTRQ pins.

The error check masks out the DRQ bit so I wouldn't have seen that
problem. Perhaps I had a DRQ problem but if so it has been far too many
years ago for me to remember it. :-) But no missed data errors as that
bit is checked. There is a retry on error but transfers were not slowed
down enough to make a problem apparent.

(This was a Peripheral Technologies FD-2 card grafted into my MEK68KECB system.)

http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)