DOS INIT I/O Error

When you do the init, what is the disk image you have selected?  Is it a .dsk image?  How is it generated?  Have you selected a known good .dsk and tried it to see if it will INIT over that?

OK, I just tried that, and I get an I/O ERROR so something weird for sure.

I can see and hear it move to track zero, then it gives the error.

To venture a guess...INIT is different because it is the only place the self-sync-bytes have to be written.  Maybe the self-sync-bytes are written wrong, so as soon as INIT is done formatting track 0, it fails in its verify scan, and you get the error right then.

What I didn't follow is whether in the description of the issue you meant that INIT fails with real media also, and if yes under what conditions.  Failure with real media would mean either some unlikely coincidence or that booting off the emulator results in a corrupted DOS...right?

The formatting process tries to find out how many bytes it can pack on a track, and this depends on the RPMs of the spindle motor. IIRC it starts with writing the track with long gaps and then verifies if the first sector was overwritten, which is expected. It then decreases the gap size and tries again. Until the first sector is still there. And then it accepts that track to be properly formatted.  Alas, I can't remember all the details ... have been a long time I looked into the book "Beneath Apple DOS" by Don Worth et al. (I can't even find it right now ...)

I think that depending on how your Floppy Emu handles the track buffer when a track is being overwritten by too much data, many things could go wrong with this formatting method.

- Uncle Bernie

Your memory is fine...

We can now discuss the particular portions of a track in detail. The three gaps will be covered first. Unlike some other disk formats, the size of the three gap types will vary from drive to drive and even from track to track. During the initialization process, DOS will start with large gaps and keep making them smaller until an entire track can be written without overlapping itself. A minimum of five self-sync bytes must be maintained for each gap type (as discussed earlier). The result is fairly uniform gap sizes within each particular track.