Unable to format ADFS disc

[ZornsLemma]

I don't seem to be able to format an ADFS disc in b-em. I create a blank ADFS L disc using Disc->New disc. I then try to format it and I get a "disc error 50 at :0/000000". Here's a screenshot (emulating a Compact, but it's the same with a Master running MOS 3.50):

Sorry if I'm doing something silly here, but I thought I'd mention this in case it is a bug...

This is with current master (4a1792ff143755edb99f18713b71bfcb7edbfa4f).

(I admit this is a little pointless, but I wanted to create a "known good" ADFS disc by having it formatted with official Acorn software.)

[SteveFosdick]

It is a bug, in the sense that the emulation of the 1770 is supposed to accept write track commands in such a way that no error is generated but in the case of a simple sector dump format like SSD, i.e. .adf/.adl files, it won't actually do anything as there is nowhere to store the ID fields or gaps that would be generated. I may have implemented something a bit moire clever for IMD but I can't remember.

If it got that far it would, of course, store the sector data for the free space map and root directory.

I don't promise to fix this quite so quickly but just for reference which version of ADFS are you using, assuming the format command is built in?

[ZornsLemma]

Thanks! I don't think this is particularly important but it would be nice (no more) if it worked.

It's happening with ADFS 2.10 (Master Compact) and ADFS 2.03 (MOS 3.50); I didn't try any others, but based on what you're saying it would probably fail with any ADFS formatter. I just used the ones where it was built into ROM because it was easier than finding a copy of AFORM. :-)

[SteveFosdick]

I have pushed a fix to this to a new branch for the time being: https://github.com/stardot/b-em/tree/sf/issue170

An interesting observation on the Acorn formatter - it seems to set the head ID in the sector headers to zero even on the 2nd side of the disc. Fortunately, nothing seems to check this.

[ZornsLemma]

Thanks, I've built that and it seems to work. That said - and I can't reproduce this after a quick try - the very first time I tried it the formatter just hung and I couldn't even reset the machine with CTRL-BREAK, I ended up killing b-em. I believe I had a .dsd image in the drive I was trying to format, which is perhaps weird - even ignoring this possible hang, the correct thing to do there isn't all that obvious to me. I just thought I ought to mention this for completeness; as I say, I am now able to format an ADFS disc when I wasn't before.

It is a bit odd about the head ID. I guess if it's always been wrong no one could ever have written code relying on it being correct. :-) And I'm guessing it saves a few bytes of code in the formatter.

[SteveFosdick]

I attempted to write the code that processes write track so it wouldn't get stuck or do anything crazy but as you mentioned the failure possibly being with a DSD (single-density) as the mounted disc I have added a further check. Now if the density of the mounted disc doesn't match that with which you are trying to format it, it returns a write protected error via the FDC and a warning is issued (to stderr, the user or the log depending on options) giving the actual reason.

This doesn't fully match how a real floppy should behave as these aren't specifically single or double density - it is a case of how you have formatted it, but it is not useful to try to format a disc in a way that the image file does not support and it is better to check that at the start then once data has been overwritten.

The same does not apply to IMD files as these are self-describing and the number of sectors/track can be changed.

On the head ID I checked the 8271 data sheet too and it seems to me that neither controller is interested in the head ID in the sector header, only the cylinder number and sector number.

I think the background to this is that the disc format, i.e. the concept of address/data/deleted data marks, gaps etc. was defined by IBM and is intended to be very general. The two FDCs we are familiar with just use the bits of the format they find useful. Maybe whoever designed the format had previously worked on old hard discs where the head could be withdrawn from the stack of platters, moved up/down and then re-inserted between a different pair. In that case having the head ID (or rather surface ID) would be useful to confirm the head in the right place just like the cylinder ID is useful to check that there hasn't been an error stepping the head to the correct place.

[ZornsLemma]

Write protecting the disc if the density doesn't match seems sensible; the emulated hardware (with the older .dsd-style formats) just doesn't have the same flexibility as the real hardware where changing density is completely logical. I had forgotten b-em actually supports IMD files, I should remember that in future as just occasionally it may be handy.

I like the idea that the disc format includes stuff to detect physical rearrangement of platters!