Having just ordered a beebscsi mini, I've been struck by a thought, and I can't be the only person for whom this would be of benefit.

There are now at least three variants of ADFS - 1.x0 for real winchester interfaces (and beebscsi), 1.x3 for IDE (and CF) interfaces, and now 1.57 for HD images on the user port MMC.
This is complicated further by the fact that at least some of the modern, switchable OSs have 1.x3 fitted as standard.

I'm sure I'm not the only person who wants to run several different HD solutions in the same machine, and be able to transfer files between them.

With this in mind, would it be possible to produce custom-labelled variants of adfs, eg WADFS for 1.x0, IADFS for 1.x3, and MADFS for 1.57, so that you can switch between HD solutions as easily as switching between say dfs amd adfs? Even better, would it then be possible (at least on the master) to copy between different adfs's as between other filesystems? Or would it all go horribly wrong due to them all wanting the same workspace?

They would have to have different filing system ID numbers, and different filing system selection commands which, due to the way its coded, has to be exactly four characters. Also, all hard drive interfaces map into the I/O addresses reserved for hard drive interfaces, so you can't plug multiple different flavours of hard drive interface interface in as they are all in the I/O address map reserved for "hard drive interface".

Essentially, the different ADFS versions have been developed for the option of: what hard drive hardware do you want to use? This is the version of ADFS needed for *that* hard drive hardware. Just like: what floppy disk hardware do you want to use? This is the version of DFS needed for *that* floppy disk hardware.

Rather than multiple copies of ADFS, I'd like to be able to have a single copy of ADFS with, e.g. drive 0 being a SCSI hard drive, drive 1 being MMC, drive 4 being from a GoSDC, drive 5 being a real floppy.

(I have an idea for yet another source of emulated floppy and hard discs which, at the hardware level, would be interoperable with all of the above. I'd quite like it to be interoperable at the software level, too!)

Thanks for the explanations. So, in an ideal world, when ide cf drives were added, adfs should have evolved into idfs with a different (unique) filing system id, and mmc drives into mdfs with a third id. They still couldn't have been used simultaneously, and switching between them would have overwritten the previous one's workspace. But at least you could have several hard drive solutions fitted to the same machine and select which one you wanted to use with a simple *xDFS rather than having to unplug the variants you aren't using.

Rather like you can have an MMC DFS and real floppies in the same machine and switch between *disc and *card.

I believe the filing system should ideally cover multple media / interfaces as opposed to having a filing system per media type. ADFS covers both floppies and Winchester drives in a Master 128 (iirc it evolved from winchester only to winchester + floppy to floppy only).

A system where you can mount an interface to a drive sounds nice as suggested by CRJ; a sort of Ultra ADFS, similar to Ultra DFS.

Well, back in the real world, DFS fitted in a 8k byte ROM. It is a filing system for floppy drives only. And at the time, floppy drives and the floppy drive interface cost a fortune.

ADFS was then developed. This came on a 16k byte ROM. Although floppy drives and the interface had fallen in price, they were still rather pricey. Winchester drives cost a fortune. After the bespoke HDD interfaces, SCSI became a common standard.

Then I think (please correct me if I'm wrong) ADFS got hacked to support IDE HDDs.

It's only in relatively recent times that CF, MMC and SD cards have been able to be used. So it's not surprising that it's not possible to use two different HDD or solid state systems in the same machine. Other 8 bit home micros have the same problem.

What it really needs, is the low level hardware 'drivers' to be separated from the higher level filing system functionality. But apparently sorting out and writing such code is not much fun...

1024MAK wrote:
What it really needs, is the low level hardware 'drivers' to be separated from the higher level filing system functionality. But apparently sorting out and writing such code is not much fun...

As I see it the problem is as follows:

1) Shoehorning in driver code for SCSI, IDE, MMC/SD into the same 16k space used by ADFS is not a option.
- Address this by moving the OSWORD &72 calls into a separate sideways ROM which is installed in a lower priority socket than the "main" ADFS.
This means you have two ROMS - one is a filesystem ROM which implements the ADFS file system (and potentially contains the floppy driver code), and a second ROM which implements the hardware drivers.
The "main" ADFS ROM is then modified to issue OSWORD &72 calls rather than directly calling the ROM routines.
2) Differentiating between a SCSI, IDE, MMC drive (when you have more than one installed)
- Address this by (a) hard coding drive numbers: 0 = SCSI, 1=IDE, 2=MMC/SD and (b) requiring that each device sits at a different I/O address.
Code it right (=use conditional assembly) and you could select "0=SCSI, 1=IDE, no MMC support" or "0=IDE, 1=MMC, no SCSI" support which would be transparent to the "main" ROM.
3) Determining device presence - so accessing a non-existent SCSI drive quickly gives a sensible error rather than sitting there for 30 seconds before timing out.

Other issues:
On a BBC B you don't have any non-volatile memory to store settings. (Perhaps a self modifying 16k EEPROM would be the answer.)
I'm certain that there are some ADFS disc accesses which bypass the built in OSWORD &72 code.
Unless there's some cleverness (i.e. the main ADFS ROM knows which ROM the drivers are located in) there's going to be additional overhead whilst the MOS tries to send the OSWORD call to the right ROM.

johnkenyon wrote:1) Shoehorning in driver code for SCSI, IDE, MMC/SD into the same 16k space used by ADFS is not a option.

This is just a hardware issue. Computer Concepts solved this way back when they introduced their Interword range. Much copied by Watford and myself, to name just two. You can probably expand this to have four banks or more, if needed. So I'd say the problem is one of finding someone to write the code - it would need some real dedication . . .

Yes, ADFS is basically full, and couldn't be expected to contain multiple drivers.

However, exposing its drive accesses so that other ROMs can hook in and implement them is rather easier. Indeed, that other thread suggests one can get versions of ADFS and DFS which already makes such calls. The other piece of that jigsaw, however, is support for IDE, MMC, etc. that operates through such an interface.

What I had in mind was that the ROM could provide a command such as *MMC2ADFS 0 Disc23 to map Disc23 to ADFS drive 0. Ideally, there would be a service call when such a mapping was made, so that another claimant could react by relinquishing their previous mapping.

On the one hand, that could take up a lot of ROM slots. On the other, with these modern interfaces loading things into sideways RAM is a lot quicker. I doubt anybody these days would mind, say, unplugging ViewSheet in order to accommodate a filesystem ROM.

Incidentally, while it would be incredibly difficult to support more than 16 existing paged ROMs in a BBC Micro, it would be considerably more straightforward to augment the paged ROM interface to support additional ROMs that were written to cope. For example, are &F8 and &F9 in zero page still free? If so, how about:

New ROMs have numbers outside the 0-15 range.

Every ROM has a private two-byte word.

On entry to a service call or extended vector, &F8 and &F9 contain that ROM's private word.

Two new OSBYTE calls: set &F8,&F9 to private word for ROM n; set private word for ROM n to &F8,&F9. With default of the current ROM

That API means different OS versions can employ different tactics for squirrelling away the private words, depending on how many ROMs they're supporting, what resources they have available, etc. (One obvious candidate: two pages of Hazel on the Master series.)

I can't offer any assistance really except to egg on anyone and everyone with the capability to do this.

One of the major obstacles many of us are finding is being able to archive real SCSI/ST506 Winchester discs. Being able to do a direct sector copy from proper ADFS to IDE/CF/SD etc. ADFS would be very helpful, but as others have already said, having two versions of ADFS live at the same time doesn't currently work, nor does having SCSI/SASI and IDE devices connected to the 1MHz bus at the same time.

I wonder if the FileStore "ADFS" code is any better written than other 8-bit versions of ADFS? It may also be a bit more up-to-date (at least in the FIleStore E01S) which supports SCSI devices connected directly to the FileStore without a host adapter board found in 1980s BBC Winchesters.

While some of the proposed ideas are very cool, for archiving of old hard drives, I think there is a much easier option (he said, without producing any code ).

Extract the code to write to a raw SD/MMC card sector from MMFS and assemble it to run in main RAM. Wrap it in a BASIC procedure which takes a) a 512 byte buffer to write b) an SD/MMC card sector index to write it to as arguments. Write a BASIC program which selects ADFS, mounts the hard drive and uses OSWORD &72 to read 512 bytes at a time and write them to the SD/MMC card using the procedure. Then use dd on Linux or the equivalent on another OS to extract the data and massage it into a suitably formatted image for archiving, reading with ADFS Explorer or writing back out for us with IDE-CF or MMC-ADFS.

BeebMaster wrote:One of the major obstacles many of us are finding is being able to archive real SCSI/ST506 Winchester discs. Being able to do a direct sector copy from proper ADFS to IDE/CF/SD etc. ADFS would be very helpful, but as others have already said, having two versions of ADFS live at the same time doesn't currently work, nor does having SCSI/SASI and IDE devices connected to the 1MHz bus at the same time.

A couple of other ways of solving that problem which might be easier:

- read from the ADFS drive on the 1MHz port and write to an output file on another machine via Econet

- write a little standalone program to read raw sectors from the SCSI disk using direct register access (which is not very complicated and doesn't require any of the high-level parts of ADFS) and write to MMC card or other local filing system

Or of course, if the primary object of the exercise is just to make a copy and the disk is sufficiently compatible with modern SCSI, plug it into another machine and archive it there.

As the creator of BeebSCSI, I've given quite a bit of thought to the issues of multiple storage solutions and BeebSCSI does provide an additional 'option' which I think could be interesting. It's designed to work both on the external 1MHz bus (of the Beeb or Master) and also the internal 1MHz bus on the Master (the required adaptor is included in the github, it's a very simple PCB). I developed it as part of my Domesday86 work, and it not only runs with ADFS, but also VFS.

Now VFS is read-only, but if some clever chap was to modify the Master's ADFS to address the internal bus instead (and correct the inverted data used by VFS and the original AIV SCSI board) - you could have 8 SCSI drives (well, LUNs technically) sitting on the internal bus - BeebSCSI already does this, but they are limited by VFS to be read only (BeebSCSI fully supports reading and writing on the internal bus). Then, on the external bus, you could have normal ADFS or a hacked IDE version, and happily copy between them. It would make backing up a winchester very simple.

I did intend to have a go at this myself, but I've just been too busy with the other parts of the Domesday project. Since BeebSCSI is well documented and open-source; anyone is welcome to give it a go though

Actually I can't remember whether I have had the idea previously of connecting a SCSI drive to the Master AIV SCSI interface and using VFS to read it and use ADFS of whatever flavour to write to whatever is on the 1MHz bus. That would probably work.

Actually I can't remember whether I have had the idea previously of connecting a SCSI drive to the Master AIV SCSI interface and using VFS to read it and use ADFS of whatever flavour to write to whatever is on the 1MHz bus. That would probably work.

It would work, but it would be very slow - VFS is about 3 times slower during DMA transfer than ADFS... A 'fix' for the VP415 laserdisc player (I think we discussed this before, as it's the reason you can't use the VP415 with ADFS).

Another advantage of the 'internal ADFS' idea is that you could have 2 BeebSCSI boards providing 12 LUNs... so 6Gbytes of storage at once. Or even 1.5Tbytes if you use BeebSCSI's jukebox feature (if they make some SD cards big enough!). You could stream the starwars movie from SD card; given the graphical resolution of a Master, there would be enough bandwidth