Changes to the PC side

With more and more things pointing to the PC, I’ve decided to really reduce the amount of work the PC has to do in its receive loop. I looked at Marco’s because his was designed to run (albeit in dos/dos window of 95/98) under much slower machines — and his worked.

I think I’ve optimized the rate the PC can receive reliably down to about half of what it was before.

What I did mainly to optimize it was to remove the PCACK portion of the protocol. This means that the PC no longer ACKs the byte back to the SX. Although the ACK lead was nice to determine what state the PC was in, the overhead associated with wasn’t worth the benefit.

Marco’s didn’t ack it, so maybe I won’t either.

I basically put the byte on the port and raise byteready. Then, after 1/2 byte has been received from the drive, I drop byteready, which gets raised in another 4 bits when the byte is ready.

So I basically have byteready on for 4*2us, and off for 4*2us.

The PC looks for the rising edge by first looking for a low, and then looking for a high. I would think 8us should be plenty for the PC to detect the change in state.

I’m getting the best results so far. I’m getting about 38 correct SYNC’s and sector headers, and partially correct decodes. This puts me at about 20%. Not too bad, but not too good either.

I hope I have the PC issue worked out, and I’m going to further investigate how I sample the data.

About the author

keith

Amateur Electronics Design Engineer and Hacker

One Comment

  • Since you’re reading one track – it is ~12k of data – it may be important how you store incoming data.

    I would get a memory buffer size of a track and a half, and would fill it with zeroes in advance so that it’d be actually allocated by whatever OS you’re running on. Just in case; I can’t say I know the memory management jungle well, but I do remember something about memory not actually allocated until it is read from or written to, which theoretically can introduce some delays.

    Then, after I sample that much of data (a track and then some), I’d stop the program and dump the buffer into some disk file.

    Probably all this is well known to you and actually performed by your software, but I thought I’d better sound it 🙂