[Coco] MAME FDC Issue that can cause corruption

[William Astle]

On 2017-08-02 02:31 AM, Ciaran Anscomb wrote:
> Run out of time looking into this this morning, but the difference
> between this and XRoar seems to be:
> 
> When MAME switches drives (motor still on), the new disk is not "ready".
> RSDOS doesn't check for this before submitting the read sector command,
> so when it does so an NMI is triggered (in XRoar, the new drive is
> immediately reflected as "ready" if it is indeed ready).
> 
> The NMI is, I guess, taken as successful completion of command, so
> as no new bytes were read, the old contents of the buffer remain: ie,
> the granule map (which I believe is read to a specific address), and
> the first sector of the directory (which is probably going to be read
> to the same buffer).
> 
> So what's the behaviour of real drives?  Is there really a delay before
> the ready signal is updated on switching drives?

Clearly the real hardware works fine with whatever DECB does or the COPY 
command would fail hard on multiple drive copies. In fact, DSKCON in 
DECB is fairly conservative in what it does.

Looking at DSKCON, it *does* wait for a "ready" signal before even 
deciding which operation has been requested, even if the drive is 
already spun up. In fact, it does that before even checking if the drive 
is on the right track. The only thing it doesn't do when the motor 
should still be running is run two "count X from 0 to 0" delays.

It further waits for the FDC chip to acknowledge ready for READ/WRITE 
before going in to the read/write loop. So, if things are exiting 
"clean", it means the FDC has said "I'm ready for you to send/read a byte".

So that must mean that MAME is doing something hinky.