PC-DOS 1.10 and PCem v12

[Battler]

What's surprising there? Formatting without /1 formats both sides, which obviously won't work with an inserted 180k image...

[mal.sh]

What's surprising there? Formatting without /1 formats both sides, which obviously won't work with an inserted 180k image...

It works fine on real hardware.

[mal.sh]

Thanks. But can you tell what exactly are conditions to raise the error "Track 0 bad - disk unusable"?

This is one of the places where the division between machine-independent and machine-dependent parts of the code shows up quite clearly. The message comes from the machine-independent part:

Man thanks for the analysis.

[vbdasc]

What's surprising there? Formatting without /1 formats both sides, which obviously won't work with an inserted 180k image...

It works fine on real hardware.

Yet no (or at least almost no) real hardware behaves like these 160K/180K/320K floppy images. So the results you got with PCDOS2 were totally expected. For starters, the bug with late handling of the /1 option was obviously fixed, else you wouldn't be able to one-side format the 180K image. Yet now another bug emerges - FORMAT apparently assumes that every track on the diskette can be low-level formatted with 9 sectors per track, an assumption that is actually correct where real hardware is involved, yet totally INCORRECT when we use 160K or 320K images.

Kudos to Battler though, who in his post on 23 Mar, 2017 6:45 pm in this thread predicted this behaviour of PCDOS2 to the last detail.

And as I wrote previously, the best way to use 160K/180K/320K diskette images in PCem seems to be after converting them to 360K.

P.S. Actually you can simulate a 160K/320K image on real hardware - just mod you drive to spin with 340 rpm...

P.P.S. You could also try to format the 160K image with the /8 command line option.

[mal.sh]

What's surprising there? Formatting without /1 formats both sides, which obviously won't work with an inserted 180k image...

It works fine on real hardware.

Yet no (or at least almost no) real hardware behaves like these 160K/180K/320K floppy images. So the results you got with PCDOS2 were totally expected. For starters, the bug with late handling of the /1 option was obviously fixed, else you wouldn't be able to one-side format the 180K image. Yet now another bug emerges - FORMAT apparently assumes that every track on the diskette can be low-level formatted with 9 sectors per track, an assumption that is actually correct where real hardware is involved, yet totally INCORRECT when we use 160K or 320K images.

Kudos to Battler though, who in his post on 23 Mar, 2017 6:45 pm in this thread predicted this behaviour of PCDOS2 to the last detail.

And as I wrote previously, the best way to use 160K/180K/320K diskette images in PCem seems to be after converting them to 360K.

P.S. Actually you can simulate a 160K/320K image on real hardware - just mod you drive to spin with 340 rpm...

P.P.S. You could also try to format the 160K image with the /8 command line option.

Ok. I've got it.