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...
DOS.MASTER
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.
Proper fix
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...
Now that you mention it, I seem to remember DOS.MASTER being on the Sider 20 hard drive I have around here somewhere.
I will have to download that source code and take a look. Anyone know where it can be found? The name Charles T. Turley sounds familiar, but I don't think I know him. Sadly googling that name I mostly find obituaries and no real clue if any of them is the one mentioned by Glen's widow.
A little more googling I came up with some Usenet threads from back in the day. Unfortunately it appears that Charles "Tom" Turley passed away in 2014. And worse it mentions that Glen had told him he wasn't able to provide source for one of his other programs Pro-Sel, So as far as yet no clue where to find DOS.MASTER source.
All the usual places: https://mirrors.apple2.org.za/ftp.apple.asimov.net/images/disk_utils/dos.master/
The dos_master_1.8.zip contains an image with the latest version - and it includes binaries and matching sources.
But since the tool's configuration utilities are written in BASIC, we probably don't even need to be messing with any of the binaries. I'm checking if just some PEEKs and POKEs can be added to the ProDOS STARTUP (basic) program, to patch the configuration file with the slot and ROM routine address of the primary ProDOS drive - before executing it.
Ok, I think I have a solution. The attached ZIP file contains an image which should now work with any ProDOS drive. CFFA, DAN][, BOOTI, ... whatever. And it should work with the device in any slot. If you have a ProDOS drive, please see if the image boots with your device and shows the following menu:
DANII_DOS_GAMES.jpg
There's a total of 102 games, and it's a quite enjoyable collection:
I wanted a simple approach, which could also be applied to other DOS.MASTER-images easily.
Initial approach was just to BLOAD, PEEK&POKE and BSAVE the configuration, adapting it to the current ProDOS device whenever the image was booted. That worked, however, I remebered there are also read-only ProDOS drives (or drives where you can enable a write-protection). So it wasn't perfect yet. It took a few more tweaks to make it work without ever writing the configuration back to disk.
The only change is in the image's initial STARTUP program. The original startup contained nothing else but a single launch command:
10 PRINT CHR$(4);"-DOS.3.3"The new STARTUP is a little longer now... :)
But it's still all written in basic and could be copied to other DOS.MASTER images, to make them independent of the ProDOS drive and slot. The only limitation is that it will only work for configurations based on a single ProDOS volume. But software collections meant for distribution are usually individual images anyway. So the support for multiple ProDOS drives isn't really an issue.
If anyone was aware of other "distributions" based on Glen Bredon's DOS.MASTER, let me know.
Nice! it is a pretty neat system.
Of course to any one else playing with it, you can exit the menu with "0". This drops you into a DOS 3.3 System Master disk that has been patched to be able to access all the "volumes" so the commands are extended.
Example, to list the files in volume 5, you would enter CATALOG,V5
To run one of the programs, just BRUN programname,V5.
I tried this archive on my BOOTi and it doesn't work.
When booting the volume ProDOS gives me a relocation error.
When launching BASIC.SYSTEM separately it starts to load DOSMASTER then crashes with an I/O ERROR.
Any ideas ?
I think I prefer 8-bit games with the Dos3.3 launcher as the files are not hidden. The disk images are saved as F1 files on a Prodos volume. Is there any way to add games to the hidden partition on this volume?
Yes, this happens on the Apple II+ when you have a problem with the upper 16K memory due to a bad socket connection on the language card or on the motherboard. Try flexing the motherboard, reinsert the language card and its ribbon cable and see if it goes away.
Or there is no 16K RAM card to begin with.
On an Apple II+ if you only have 48K, ProDOS doesn't give you this error. Instead it says that you need 64K to run ProDOS. If we are talking about an Apple IIe, I would suspect a memory problem.
Come to think of it, you're right.
RELOCATION ERROR is returned by ProDOS when it fails to install in the upper 16K but thinks that there is a 16K card in place.
So I concur. Some memory issue in the upper 16K.
A memory test using the copy utility Locksmith 6.0 will tell you.
It has a very good memory test and will sniff out almost any memory card in any slot and test it.
I should point out that I'm running my BOOTi on a Platinum //e with 128KB RAM.
Run the DOS 3.3 version of the Apple II RAM test utility on all memory: http://www.ivanhogan.com/kfest/MemUtil/
Hello,
It might be a dumb question,
but how do I create a dos partition within Prodos disk image with dsk file in it.
Reading the dos.master doc, it can be done using Apple II fud. Is there tools to be used more in Mac/Linux/ Win32 env ?
Thanks
Vincent
Originally the tool required you to run the "MAKE.DOS" utility, which creates the DOS partitions on the ProDOS drives and also creates the startup for the "virtualized" environment (a file called "DOS.3.3" to be run from ProDOS, which would then allow DOS 3.3 programs to be run). And to copy files (or maybe entire disks) into the empty DOS partitions, you would use the "FUD" utility. This allows you to copy files from a real DOS disk to those partitions.
Not sure if there was any support to create partitions with the modern Linux/Windows utilities like Ciderpress or AppleCommander. At least I'm not aware that any of these tools had special support for these DOS.MASTER partitions on a ProDOS drive. So you probably have to copy files on a real machine (or on an emulator).