Yes. Conceptually the program is two threads. One reads from the floppy into a ring buffer and the other reads from the buffer and drives the audio and video.

Yes. Conceptually the program is two threads. One reads from the floppy into a ring buffer and the other reads from the buffer and drives the audio and video. A few tracks are read to prime the buffer before the display thread runs in earnest. The glitches you see are when a byte is dropped when reading a disk track. This causes the display to shift by a column and the interleaved audio data is displayed as graphics. And, conversely, one of the graphics columns is played as audio causing the screeching. Some runs work better than others. The byte drops could be due to slight motor speed variance. Or just down to luck -- a few of the disk operations incur wait states as does writing to video memory. These times vary depending on exactly when they occur so it could just be down to luck. The code works in fixed 128 cycle steps with a few cycles reserved for wait state issues but apparently not enough to ensure correct operation. And what about when the screen completely fills with garbage? I've no idea. Maybe the track didn't write correctly. Or maybe the drive misses a bit. Shifting the graphics and audio data stream by a bit would surely scramble the graphics. The audio should be mostly OK save for getting random noise every 8th bit.