External ADFS for 1MHz Bus Second Winchester Controller

[BeebMaster]

Following on from my "Internal ADFS", I've now made a special build of ADFS 1.50 which maps to a different address on the external 1MHz bus, so it can be used with a different controller. This works on my modified Akhter host adapter mapping to &FC44 instead of &FC40, when I finally learnt how to modify it properly! It also works on Pi1MHzSCSI when the software is compiled to look for the hard drive controller at &44 in FRED (literally a one byte change from &40), although I have had it working at other FRED addresses too. Currently only the original dp11 Pi1MHz adapter with through-hole resistors and diodes works, as Ken's adapter doesn't like sharing the bus with other devices, discussed here.

Here then is "XDFS", an alternative External version of ADFS. Again, the idea is that it can co-exist with ADFS so that finally we can do hard-disc-to-hard-disc transfers with two completely separate Winchester units, or more modern replacements, on the 1MHz bus at the same time. XDFS builds from the ADFS 1.50 source, from a fork I have made with the following changes, all done using conditional assembly options like the various other build options in Hoglet's repository:

- Filing system banner changed to "Acorn XDFS" and help message to "External ADFS".
- All hard disc hardware accesses go to &FC44-&FC47 instead of &FC40-&FC43. This could easily by changed by modifying the XDFS .asm file in the repository to use a different address.
- Selection command changed from ADFS to XDFS, and FADFS changed to YXDFS. (That's possibly a bit ugly so I'm open to ideas on that!)
- Reset selection keys changed from A and F to X and Y.
- Reset selection key right-arrow removed.
- OSWORD disc access calls are renumbered from &70-73 to &60-63 which is the same as IDFS and VFS.
- Filing system number is changed from 8 to 10, same as IDFS and VFS.
- File handle channels changed from &30 - &39 to &50 - &59 as per IDFS and VFS.

As I've reused the existing numbers from VFS and also IDFS, this means that whilst XDFS and ADFS can co-exist, it's unlikely that XDFS will co-exist with either IDFS or VFS being present at the same time, so internal SCSI to external second 1MHz bus controller transfers won't be possible. But XDFS could be built with totally different FS and other important number ranges if necessary, subject to them being checked for clashes with existing firmware.

There was room in the ROM for these minimal changes without losing anything, so the floppy code remains and XDFS will look at floppy drives 4 and 5, or 0 and 1 if no Winchester controller is detected, just the same as ADFS would do. In fact XDFS has 3 bytes spare because it skips one of the reset key checks as above.

Things which haven't changed and are therefore the same as ADFS are:

- XDFS claims and uses the same filing system workspace as ADFS (and IDFS)
- XDFS uses the same configuration commands and CMOS bytes as ADFS (and IDFS)

As I mentioned in the Internal ADFS thread, I'm not certain whether these are a problem; if they are, they will need to be changed. I don't think anyone will need a separate set of configuration options for DIR/NO DIR etc between XDFS and ADFS though. I don't think use of the same workspace as normal ADFS is a problem either as a disc is always re-mounted before any access attempt, so this would have the effect of renewing the data stored in the workspace, though I may be wrong on that.

Other problems are that all current ADFS based utilities using direct sector access don't work because the OSWORD number is changed, so disc formatters, verifiers etc. won't access second Winchester controller. But it's simple enough to make new utilities for use with XDFS - I've made some progress on my ADFS imager which currently works with IDFS OR XDFS (but not as well as, of course), and ADFS.

This is based on ADFS 1.50 so is only for the Master. I'm not sure if the ADFS 1.30 source is available, I haven't been looking for it but if it's around and is as nice as the ADFS 1.50 disassembly then I can look at it.

[hoglet]

I'm not sure if the ADFS 1.30 source is available, I haven't been looking for it but if it's around and is as nice as the ADFS 1.50 disassembly then I can look at it.

https://github.com/hoglet67/ADFS130

[BeebMaster]

Oh yes, thank you. I can see there are a lot more variables in the TOP files here, should make an "XDFS 1.30" much easier!

[BeebMaster]

I've been thinking that the External ADFS should have its own unique set of numbers and not re-use the VFS ones. Though unlikely to be common, there could be a use for External ADFS co-existing with internal hardware as well, which currently wouldn't be possible.

So, I would need a unique filing system number, set of 4 OSWORD numbers, and set of 10 file handles for the External ADFS.

I think the FS number should end in an 8, the only number in the range which is free which ends in 8 both in hex and decimal is &58 and looks to be free:

https://beebwiki.mdfs.net/Filing_system_numbers

OSWORDs &6A to &6D look to be free:

https://beebwiki.mdfs.net/OSWORDs

And file handles &66 to &7F are all free:

https://beebwiki.mdfs.net/Handles

I could start at &6A same as with the OSWORD range, and use &6A to &73 for the file handles.

And if I'm having &6A as a thing, as it happens that's also free for the filing system number.

Anybody have any showstopping reasons why I shouldn't use these numbers?

[Mince]

And file handles &66 to &7F are all free:

https://beebwiki.mdfs.net/Handles

I could start at &6A same as with the OSWORD range, and use &6A to &73 for the file handles.

And if I'm having &6A as a thing, as it happens that's also free for the filing system number.

Anybody have any showstopping reasons why I shouldn't use these numbers?

For MMFS with _DFS_EMUL=FALSE, I change the file handle range to &71-75 instead of &11-15 — https://github.com/hoglet67/MMFS/blob/m ... 0.asm#L154 — this was to avoid clashing with DFS, if you have both installed. I suspect I'm the only person that uses that build, though; maybe I should update the wiki!

[BeebMaster]

Right, still leaves &76 to &7F for the 10 file handles for the external ADFS which I will use, and stick to original FS number idea of &58.

[jgharston]

I think the FS number should end in an 8, the only number in the range which is free which ends in 8 both in hex and decimal is &58 and looks to be free:
https://beebwiki.mdfs.net/Filing_system_numbers

OSWORDs &6A to &6D look to be free:
https://beebwiki.mdfs.net/OSWORDs

To continue the theme of some of the bits being the same across implementations, I'd recommend &68+n, so then you'd have:
OSWORD &60+n : VDFS
OSWORD &68+n : XDFS, fs=&58 - also 88!
OSWORD &70+n : ADFS, fs=&08

And file handles &66 to &7F are all free:
https://beebwiki.mdfs.net/Handles
I could start at &6A same as with the OSWORD range, and use &6A to &73 for the file handles.

And similarly use &68+n to match, or &70+n to match the &30+n and &50+n, giving:
OSWORD %01110nnn : Handles %0011nnnn, ADFS, fs=%00001000
OSWORD %01100nnn : Handles %0101nnnn, VDFS
OSWORD %01101nnn : Handles %0111nnnn, XDFS, fs=%01011000

(Though handles are more opaque than filing system and OSWORD numbers as they are handed *to* your rather than you "sending" them out, so that's probably less of an issue. Programs shouldn't be testing handles for anything other than zero, not specific values.)

(checks for typos.... fingers crossed)

[BeebMaster]

Thank you, I will use those allocations when I update "XDFS" shortly, as long as Mince doesn't mind as there will be overlap with the file handles he is using.

[BeebMaster]

I've made changes to External ADFS now to update all the numbers as above:

https://github.com/beebmaster/ADFS

XDFS filing system number is now &58
XDFS OSWORD base is now &68, so the most common ADFS calls &72 (general read/write) and &73 (read last error) are now &6A and &6B for XDFS
XDFS file handle channel range is now &70 to &79.

Also I added a printout of the Winchester disc hardware address (&FC44 on a standard build, but it can be customised to any valid location) into the help message, as I had done previously with the Internal ADFS, but this made the ROM 5 bytes too long so I have had to abbreviate "External" to "Ext." in the help message to fit in.

XDFS still has the ADFS floppy code included, which could be omitted and save over 1,500 bytes but I am not sure what I would fill it up with. And at least for now, it's useful to keep the floppy code to prove that hard disc selection works correctly and looks for the right hardware.

I just did an image from my Winchester test rig set to &FC44 under XDFS to internal BeebSCSI under IDFS, also whilst I had my Akhter Winchester Disc mounted under ADFS, and floppy drives active (under ADFS or XDFS). The XDFS to IDFS copy worked, and nothing crashed or got confused, so I think it all works.

I have now had to do a bit of "Winchester detect" bodgery in my "ADFS Imager". Previously I used to read &FC40, &FC44, &FC48 and &FC4C and make decisions on what hardware was attached based on the results, but this really doesn't seem to work now: with ADFS hard disc powered on and Akhter Winchester rig at &FC44 attached but powered down, my previous code decided this was a Retroclinic IDE setup!!

My workaround is to read the ADFS status byte (which is in the same location across ADFS/IDFS/XDFS) at zero page location &CD (using OSWORD 5 for compatibility across the Tube) immediately after mounting a drive and using that status byte to decide whether the drive just mounted is hard or floppy. This seems to work.

Next steps are to adapt "UltraForm", my take on SuperForm, to work with IDFS and XDFS and then the Level 3 file server initialiser "WFSInit" to work with IDFS and XDFS, and then look at doing a build of the Level 3 FS for IDFS or XDFS. Somewhere in the middle I will also look at making XDFS 1.30 for BBC B.

When I have done all that, I would like to try XDFS on my Digistore Tape Streamer (which has an Acorn Winchester Host Adapter bodged to &FC44) and see if that works.

[KenLowe]

XDFS still has the ADFS floppy code included, which could be omitted and save over 1,500 bytes but I am not sure what I would fill it up with.

Tube Host Code?

[BeebMaster]

I think the Tube host code is in the Master MOS, which is what this current "1.50" build of XDFS is for, but certainly it's something to think about when I do similar to ADFS 1.30. And I think there would be less of a reason to keep the floppy code in an "XDFS 1.30", as a BBC B might not have a 1770 controller.

One nice side effect of still having the floppy disc code in XDFS is that it's now possible to keep two "ADFS" locations active without having to re-mount and re-dir every time you change drive. One of the many irritants of ADFS is that if you want to load from floppy disc, test the code on hard disc, load the next program from floppy disc, test on hard disc again etc. is that when you change drives using *MOUNT, you are put back to $ and have to navigate to where you need to be from scratch every time.

With XDFS mounting a floppy and ADFS mounting a hard drive (or vice versa), changing between XDFS and ADFS puts you back to where you were.

To be honest, I'm not certain how or why that works: as I said in the first post, XDFS actually has very few changes to the ADFS code, so it uses the same workspace, and I would have expected it to destroy the workspace changing between filing systems, but that doesn't seem to happen.

[KenLowe]

In the following post there is query about the simplest way to backup a file from a real SCSI HDD. The file is too big to fit on a floppy:

viewtopic.php?t=28582

I pointed the OP to this thread, but it got me thinking about an alternative solution to the problem of copying from a real SCSI HDD...

Currently, ADFS can talk to 4 different HDDs (LUNs) via hardware address &FC40..&FC43.
Similarly, the new XDFS can talk to 4 different HDDs (LUNs) via hardware address &FC44..&FC47.

...but to copy between two drives (one real SCSI HDD, the other Pi1MHZ BeebSCSI HDD) you need to switch between the two different file systems, so requires TreeCopy (or similar) to copy between the two.

I wonder how simple it would be patch ADFS so that (for example) ADFS drives 0 & 1 map to LUN 0 & 1 at address &FC40 and ADFS drives 2 & 3 map to LUN 0 & 1 at address &FC44??? This way, everything could be accessed via a single file system allowing the inbuilt *COPY command to work between two drives on different base addresses.

[BeebMaster]

I am sure it would be possible to set the hardware address depending on the drive number being accessed, but ADFS is pretty full so it would mean sacrificing something, like the floppy disc code.

I don't think anything much would be gained though, the two hard drives would still need a way of having separate hardware addresses setting, and ADFS's *COPY isn't recursive, so it could only be used for files in the current directory. Using the temporary filing system on M128 would allow the different variants of ADFS to be used in *COPY command, eg. *COPY -ADFS-:0.$.* -XDFS-:0.$.Backup.*

It would save a ROM slot though.

[KenLowe]

From what I remember, your XDFS uses the same private workspace as ADFS, so PAGE doesn't increase, even if you've got both file systems active at the same time. Is that correct? I'm sure you've done some fairly thorough testing with that but, TBH, that makes me a bit nervous about the potential for corruption.

I was hoping it would be a fairly simple modification, where LDA &FC4x / STA &FC4x would simply become LDA &FC4x,X / STA &FC4x,X, and X would have been previously set to 0 for base address &FC40.. &FC43 or 4 for base address &FC44..&FC47.

I'm thinking that X would be generated from the LUN number 0..3, where LUNs 0 or 1 would set X=0 or LUNs 2 or 3 would set X=4. So X would be set with something like PHA:LDA LUN:AND &02:ASL:TAX:PLA. There might be a more elegant way to do that!

I'll have a poke around when I get some spare time!

[BeebMaster]

XDFS (and IDFS) is currently only for the Master 128, based on ADFS 1.50, so it just claims the same workspace as ADFS uses in the private RAM. I did say in the initial post that I couldn't be sure whether this would cause problems but my own testing shows that it does work. Reselecting ADFS or XDFS etc does cause a re-load of the FS map and root, as far as I can tell, so it doesn't seem to get confused between different filing systems. I have tested XDFS/IDFS/VFS/ADFS in various situations with new and old types of hard drive without seeing any data corruption but more testing by more people would be good.

At this point I can't say whether the same would be true for a BBC B build using ADFS 1.30, which I haven't done yet, but will do eventually, maybe even this year!