Moving the discussion about compatibility problems with the "DOS.GAMES" collection (see previous discussion here) to this separate thread. It's not a DAN][-specific topic, and the other thread is getting incredibly long anyway. Makes sense to spin off sidetrack discussions...
So, as we recently noticed, there is an issue with the "DOS.GAMES" collection - and possibly other collections using the same base. They would run fine when using a CFFA - but not work when using a DAN][ controller, or some other ProDOS interface devices. As discussed earlier, this is caused by a hard-coded address refering to the CFFA device's ROM. This address should normally never be hard-coded anywhere. According to the ProDOS interface standard, it needs to be read from a standardized table inside the device's ROM itself.
In the earlier thread I made a crude hack to change the hard-coded address to match my DAN][ ROM, instead of the CFFA ROM. I assumed the issue was caused by an oversight by the game collection's creator (who is also involved in the CFFA).
Well, my initial assumption wasn't quite right. It has nothing to do with "CFFA guys". Nor is it really anyone's fault. I have investiaged this a bit further. Here's what's going on...
The mentioned game collection is based on the "DOS.MASTER" environment by Glen Bredon. Glen was a math professor and made many Apple II contributions - best known probably his "MERLIN" assembler.
I wasn't even aware of his "DOS.MASTER" utility before. It's a pretty cool environment that he created. It allows to run DOS 3.3 programs from a ProDOS harddrive. Multiple files can be created on a ProDOS drive, where each file is a container for a complete DOS 3.3 floppy disk. It provides a utility to copy DOS files into these containers. DOS 3.3 only supports (small) floppy disks. But DOS.MASTER is able to create a DOS3.3 environment for the programs, so DOS still "sees" floppy drives - without knowing that the data of each floppy actually lives in an image file, which is stored on a ProDOS harddrive... As I said, pretty cool! :)
And Glen knew what he was doing. It works with any ProDOS drive. It's "ProDOS-compliant", doesn't use hard-coded addresses but reads them from the device's ROM. Just as it should be...
So, all should be good, right?
What the issue really is...
The reason why we're still seeing issues is this: DOS.MASTER was made to allow users to copy their (legally purchased...) Apple II DOS software to a ProDOS harddrive - and run it from there. It works great for this purpose. It even supports multiple ProDOS drives - and multiple containers on each of them.
When its installation utility is run, it creates a configuration file. The user selects the drives which should be accessible. The utility stores all of this in the configuration file, including the exact slot of each selected ProDOS drive. And, you guessed it: it also stores the appropriate address of each ProDOS drive's ROM routine...
It just wasn't intended to make portable volume images, suitable for redistribution to other machines.
The concept of generating a fixed configuration file at installation time, with hardware-specific information about the local system's setup - and storing this on the harddrive itself, obviously doesn't make sense when you want to create something portable.
So out of the box, images created with DOS.MASTER are only guaranteed to work on a system matching the setup of the original, which created the image. All ProDOS drives have to be in exactly the same slot. The ROM layout (ROM entry address) of each drive must match the address of the original.
When you create a "DOS Game Collection" made for a system with a CFFA in slot 7, then the image will only work with a CFFA in slot 7. Not with CFFA in slot 6. Nor with a DAN][ in slot 7.
There are multiple ways to "fix" this issue. Though it's more a case of repurposing DOS.MASTER to support a different use case: portable images for redistribution.
Sadly, Glen Bredon already passed away in 2000. But his wife had released all his Apple II projects into the public domain. The collection includes the sources of the Merlin assembler - and those of "DOS.MASTER" (and other stuff). So, it's pretty well documented.
I guess the easiest "fix" is to create a little utility which adapts the configuration file for the current system. It should be easy for "game collections" and similar images, since they only require a single drive to be accessible anyway. No actual selection or mapping is required - which was the initial purpose of the config file. All it needs is a "use the current drive, the one from which we have just booted, and use exactly this as the only available ProDOS drive for the DOS.MASTER environment".
I'll be look into this, as I fall deeper and deeper into this rabbit hole... If anyone has any ideas, or previous experience with DOS.MASTER, let me know...