EclaireXL

Setting up the logic analyser to check the cause of the first few fails on the scanalyzer...

Hmmm, gets a failed checksum on the first sector read and switches to high speed sio. Then takes a while to resync.

Now need to see why I get a bad checksum (tomorrow).

So 3 problems...
i) Sometimes bad checksum, must be a sync issue with pokey clock I guess.
ii) Flip flopping between fast and slow too quickly to make sense.
iii) Seems to be very slow to ready 16 bytes from sd card (atr header), Atari send 3 command packets during this?! Need to work out what is going on here, this makes no sense.

The time spent on iii is in pf_open, the fat file system open. I guess this must do some work.

Perhaps if I ack first then the Atari will give me more time to handle this in piece... This will mean with the current approach that code that accesses drives in turn is slow, though is that common in practice? Probably not.

I guess a disk revolution at 288rpm is 200ms, so it must be ok timing wise to do the ack first.

Added more structure to the command handling (common ack/nak etc) and looking much better. More to do though...

Farb, are you still running into this with the latest builds?

It doesn't seem to be happening as much although I did run into some weirdness a couple of times that might be related so I'll keep an eye on it.

Ok good. That’s as I hoped. I still need to make switching from slow to fast sio and back more reliable, I just fixed something that made it enter that state too often.

I'd added a 2ms delay temporarily to stop some fast/slow flip flopping. That actually breaks USB keyboard when in that state. Decreased it to 100us for now, though really I need to get to the bottom of what is going on.

I have a cartridge (yes, not a disk!) that puts it into this state now, so have something easy to debug...

Implemented using sio clock out as the zpu clock input. Should mean it can listen to whatever speed. Though of course there is still the question of what speed to reply at. Of course I do know what the pokey divisor is but it feels like cheating to use it:-)

On second thoughts, why guess when I know. Pokey is already outputting the serial input anyway (even in input mode, since its oe/in/out which is then connected to the pin). Then I can remove all the divisor guessing logic and code.

Except I need to send start bit from zpu to start that clock. Probably a fairly simple state machine change, but getting too late now!

In the end I chose to use the SIO clock for receiving command packets. I also count the rate. Then I reply using the same rate, creating my own clock.

I also fixed the divisor selection, it was not using the valid from the menu!

Will do another day or so of testing, but think this is now good...