One thing that me left really annoyed when using Pi1541 was that reading the error channel with Action Replay and others caused the system to run an endless loop after the full data was read. Today, I finally had an idea what could be causing this.
When you read the error channel on a 1541, you'll never get a typical "end of data" notification, but instead the stream starts over again sending "00, OK,00,00", and again, and again... So most (if not all) implementations read the buffer until they read $0d (the return charater) and then stop. When Pi1541 is not sending return, some garbage is read after the channel doesn't have any more data.
Goes half-way for a correct implementation by sending a $0d-byte after the message. It does not implement the "loop-over" of a typical commodore floppy drive, as I'm unsure if it would be worth the effort.
I also changed the sprintf to snprintf so the buffer will never be written out-of-bounds.
pi1541
commented
3 years ago
One thing that me left really annoyed when using Pi1541 was that reading the error channel with Action Replay and others caused the system to run an endless loop after the full data was read. Today, I finally had an idea what could be causing this.
When you read the error channel on a 1541, you'll never get a typical "end of data" notification, but instead the stream starts over again sending "00, OK,00,00", and again, and again... So most (if not all) implementations read the buffer until they read $0d (the return charater) and then stop. When Pi1541 is not sending return, some garbage is read after the channel doesn't have any more data.
Goes half-way for a correct implementation by sending a $0d-byte after the message. It does not implement the "loop-over" of a typical commodore floppy drive, as I'm unsure if it would be worth the effort.
I also changed the sprintf to snprintf so the buffer will never be written out-of-bounds.