Reading from ADFS Floppy with No Map or Root

[BeebMaster]

One of my 3.5" 640K ADFS floppy discs has died, track 0 is inaccessible. I think this happened when I was swapping cables about to try various different floppy drive configurations, and I also discovered that drive 1 of my 3.5" test drive seems to have broken as the head doesn't step any more, so that could have had something to do with it.

Using ADI 2.00 on this disc, it finds sectors from track 1 onwards (although the sectors are listed in the wrong order, probably that's because of the "sector skew" applied on formatting?) so it looks like everything else is there. If I can make an image of track 1 onwards I should be able to reconstruct the disc. I don't think I can make ADI output an image of a whole disc.

It's a new disc I only started a couple of months back, in fact my "RISC Utils" disc for developing (ironically) my RISC OS ADFS imager and verifier and other things. I used an "L" format disc so I could use it in any machine if necessary. As it's "new", I wasn't expecting it to die yet so I have no backup of course (but various programs are stored on my Econet so I haven't lost that much.)

My RISC OS ADFS imager won't work, even skipping all the describe disc part and manually feeding it the right geometry, I just get disc error &9A for every sector, which equates to the "Disc not formatted" error I get if I try to mount it.

My 8-bit ADFS imager won't work either, as in order for OSWORD &72 to work it seems to require a valid map and root, otherwise I just get No directory if I try to use OSWORD &72 from a CTRL-F-BREAK (or with NODIR configured) or if I select a different filing system and then call OSWORD &72, I always get Disc error 50 at :0/0000000.

I tried JGH's DisktoImg but that falls over at the beginning with Disc error 50 as well.

If ADI can "see" it, it must be accessible, but I don't know how - shurely OSWORD &72 can be made to read MFM sectors from anywhere on a floppy disc without it needing to load a map & root directory first? Otherwise we'd never be able to read other disc formats on Beebs like SJ Research floppy discs, or DOS 720K discs would we?

[tom_seddon]

If you've got suitable hardware, Opus DDOS or Challenger will read double-density disks using OSWORD $7f. The Opus double-density format was 18 sectors per track, but if you ask it to read 16 sectors per track starting from sector 0, that might work?

Another option might be Watford DDFS, which has a 16 sector double density format. One of the versions is compatible with the standard Acorn 1770 DFS board. Don't know whether its OSWORD $7f supports double density though.

--Tom

[flaxcottage]

I've met something similar before. ADI would read a disc sector which the DOS (I know I said DOS) said was damaged or unreadable. The disc would also run. In this case I tracked it down to doing a SEEK for the track to read then trying to read the track. That worked.

Is your ADFS-ADI problem the same thing? ADI seeks the track and then reads it?

[BeebMaster]

One of the problems is that I don't fully understand how ADI works, so I will have to go and read the manual. I expect it uses direct access of the disc controller to read sectors to get round the problem that ADFS can't cope if it can't find any ADFS at the beginning.

Anyway...I cheated...mount a working disc, change to the dodgy disc and then I can use OSWORD &72 as it doesn't check for "disc changed"! Possibly I could just overwrite the Master ADFS workspace with a valid FS map and root directory as an alternative.

[BeebMaster]

Getting somewhere now...I copied the Master filing system workspace of a good ADFS disc from &C000 to &C8FF to another location and bodged my ADFS imager to restore that data to the workspace whenever it encountered a disc error on *MOUNT or *ADFS, thus allowing the OSWORD call to proceed:

Then I started getting errors at every sector from &40C onwards, and it was doing 10 or more retries with about 15 head steps with a rewind scrape after each set, for each read attempt.

I I abandoned it and saved the image so far, and it had data up to sector &4FF, so I guessed that the error was being caused at the start of the other side of the disc and that the sector error was "false".
So then I did the image in two halves...

which seems to have worked, although it looks like sectors &500 to &52F have been wiped as well!!

Next I need to work out the minimum number of bytes I need to poke into the ADFS workspace to make it think there's a valid disc mounted, I can't really spare &900 bytes of data to move into position at will.

[BeebMaster]

Looks like I can just clear &C000-&C8FF to zero with a simple FOR...NEXT loop if the disc can't be mounted and then it will allow OSWORD &72 to work.

Problem though is that I am normally using the second processor for a larger data buffer, and you can't reach the host with the ! operator in BASIC!

[BeebMaster]

I've whittled it down to a few bytes, clearing &C300 to &C31F does the trick and allows OSWORD &72 to function. This looks to be where ADFS puts the CSD and CSL names. It will be in a different location on ADFS on a BBC B (possibly variable depending on filing system presence?) and maybe different again on B+. Oh and Elk probably. But it works on the Master and as it's only 32 bytes I need to clear it won't take up much time doing it using OSWORD 6 across the Tube byte-by-byte.

[BeebMaster]

Having now made an image where tracks 0, &50, &51 and &52 are unreadable, I set about trying to reconstruct the map and root directory manually. The root wasn't too difficult, as it only had sub-directories in it, with possibly a couple of other files when I was using the disc for general purpose transfer, but I'm not worried about those, so I didn't have to go searching for miscellaneous files in the root, only directories. By searching through the image in a hex editor for all instances of "Hugo" and taking a note of the directory name and the parent directory start sector, I identified all the directories whose parent was sector 2, ie. the root. Then I added to sectors 2-6 the Hugo identifier at the start and end, the directory name, and then added the 4 sub-directories I had found. I cleared sectors 0 and 1 to zero for the free space map. Then I dropped the modified image onto my BeebSCSI SD card and mounted it, and it worked, but with a bad FS map, so I used my "FixMap" util to re-calculate the checksum and wrote it back to the image.

One thing I did wrong was not setting the top bit of byte 4 of the directory names to identify them as directories, so I got a "not found" error on a *DIR till I fixed that.

Sectors &50-&52 contain a game or a RISC OS module I put on the disc so I'm not worried about losing that, so it only leaves me with sectors 7 to 15 of track 0 "lost". There's a directory at sector 7 and then 4 sectors of one or more programs which I won't be able to reconstruct, but there's a backup of everything on the disc in $.BACKUP, so I can restore the lost directory and its contents from that backup, so I don't think I've lost anything.

I've written the BeebSCSI image back to a floppy disc with my imager, first time I think I've actually used it to backup from one drive to another rather than to an image file, and it worked, so that's good as well. Now I can get all the existing files off the new floppy disc using the RISC OS filer and write it all back to a clean disc.

[BigEd]

Always good to see a successful rescue - well done!

[jgharston]

Looks like I can just clear &C000-&C8FF to zero with a simple FOR...NEXT loop if the disc can't be mounted and then it will allow OSWORD &72 to work.

Problem though is that I am normally using the second processor for a larger data buffer, and you can't reach the host with the ! operator in BASIC!

You can use OSWORD 6 in a similar way to the Context library. Something like:
X%=control block, Y%=X%DIV256
addr%=&1100:!X%=&FFDD:A%=5:CALL&FFF1:IFX%?4=76:addr%=&C300
A%=6:FOR B%=start TO end:!X%=addr%+B%:X%?4=byte_to_poke:CALL&FFF1:NEXT

which will work whatever side of the Tube you are executing on.

[BeebMaster]

I see...I'd already done the OSWORD 6 to clear the bit of workspace in the Master but not done any Model B detect. So...reading the value stored in &FFDD tells us whether we are running on a Master or a B, if it's 76 it's a Master so I clear the filing system workspace around C300 and if it's a B I need to do it around &1100. Very possibly I only need to clear the CSD locations (shown in the Context library) in order to stop ADFS refusing to attempt to read disc sectors, so I will experiment with that as well.

[BeebMaster]

P.S. when using OSWORD 5 & 6 do I not need to set the top two bytes of the address to read or write? ie. &FFFFC300 rather than &C300 to make sure it is using the I/O processor?

[jgharston]

P.S. when using OSWORD 5 & 6 do I not need to set the top two bytes of the address to read or write? ie. &FFFFC300 rather than &C300 to make sure it is using the I/O processor?

No, because the call is explicitly "read from I/O processor" not "read from filing system addressing scheme address".

[regregex]

P.S. when using OSWORD 5 & 6 do I not need to set the top two bytes of the address to read or write? ie. &FFFFC300 rather than &C300 to make sure it is using the I/O processor?

No, because the call is explicitly "read from I/O processor" not "read from filing system addressing scheme address".

You should anyway:

1. Parameter block bytes XY+2 and XY+3 need not be specified if the I/O processor memory is fully accessible using a 16 bit address.
2. For access to memory locations in the computer's sideways RAM, XY+2 = &FE and XY+3 = &FF

– Master Series Reference Manual, p. D.3-10

Clause 1 really means ...if the I/O processor memory location is unambiguously specified in the low 16 bits.

So references to &0000..&2FFF, &E000..&FCFF or &FE00..&FFFF don't have to initialise the high word, but any other access has to arrange to page in the correct device, and if done within OSWORD then the high word must be set up with the paging parameter. OS 2.00 and above provides a convention to specify main or shadow RAM within the OSWORD argument, as described.

With addons like the OS RAM module on the market, arguably programmers should anticipate OSWORD extensions to handle even more address spaces, and treat no address range as safe. It'll be cheaper to define the whole thing always than to decide whether or not to do it.

[BeebMaster]

It's interesting because in my mind I have these calls as "read/write byte across the Tube", (maybe I'm getting mixed up with OSBYTE 157) so: wherever you currently are, access the other processor, but even that logic falls down as it wouldn't work to always read from the I/O processor! I need to re-train my brains to think of them, correctly, as "guarantee read/write of byte to I/O processor".

Which leads to the obvious follow up, are there calls to "guarantee read/write of byte to second processor"?

[BeebMaster]

Putting all this together, this is the routine which clears the bit of ADFS workspace causing the problem. I didn't think use of the variable in a FOR...NEXT loop like this would work, but it does! I thought it would create an infinite loop:

[BeebMaster]

You should anyway:

1. Parameter block bytes XY+2 and XY+3 need not be specified if the I/O processor memory is fully accessible using a 16 bit address.
2. For access to memory locations in the computer's sideways RAM, XY+2 = &FE and XY+3 = &FF

– Master Series Reference Manual, p. D.3-10

That's an error in the book I think (also in New Advanced User Guide p347), "sideways" should be "shadow" surely?