Arkain wrote: > I've got yet another idea. How about a new version of ProDOS, under a > different name of course to avoid Apple Copyright problems. I was thinking > about a version that would allow more drives per slot, such as: > > S[1-7], D[1-8], P[1-32] > > where "S"->"Slot" same as before, "D"->"Drive" same as before but with a 8 > max, "P"->"Partition" maxed at 32. This new ProDOS 8 compatible OS should be > able to support all ProDOS 8 applications that used the MLI. Supporting existing applications with such a change would be a problem. ProDOS-8 uses a "unit number" to refer to slots and drives. There are only sixteen unit numbers available: they are encoded with the drive number in bit 7 (0 or 1), the slot number in bits 4-6 (0 to 7), and the bottom four bits are reserved (they are used in some contexts). Slot 0 is not available (S0,D2 is reserved in at least one context, S0,D1 is reserved in several places). All existing ProDOS-8 application which pay any attention to unit numbers would not be able to cope with a change in the definition of the unit number. Several other problems occur to me: 1. ProDOS-8 has a device driver table in its global page. This has an entry for each of the sixteen possible unit numbers, pointing to the driver for that unit number. This table cannot be expanded without changing the structure of the global page, which would break most existing ProDOS-8 applications. 2. ProDOS-8 has a table of valid unit numbers in its global page. This has room for fourteen valid unit numbers, and you couldn't change this without breaking existing applications. 3. The ONLINE call is defined as being able to return a maximum of 256 bytes of data if you ask for all online devices (i.e. potentially 16 devices). You couldn't increase this without breaking existing applications. 4. The device driver interface for ProDOS block drivers (provided by firmware on the interface cards in most cases) only defines two devices per slot. There is a workaround for some cases, which allows four devices per slot (e.g. SmartPort interface in slot 5 on the IIc and IIgs), and ProDOS itself has worked around this by adding support to use the SmartPort firmware driver instead of the ProDOS one, where one is provided by the card. SmartPort allows a maximum of 127 logical units per slot, but ProDOS can only access a few of these (by remapping unused unit number). The RamFast uses a similar technique to allow supporting extra units, but it doesn't have a SmartPort driver. 5. The language card area is completely full. If you wanted to add more code to the ProDOS kernel, you would have to take over some other memory area, which would cause some applications to break. If I kept thinking about it I'm sure I could come up with more problems. In summary, you would have to rewrite existing applications if you wanted to expand the capabilities of ProDOS. I don't think this is going to happen. It would make more sense to port an existing application to run under GS/OS. > Apps that depended on internal addresses would not be supported. There are very few applications which depend on internal undocumented locations within the ProDOS kernel. All applications know about the documented areas of the global page ($BF00-$BFFF), which provides the public interface to the ProDOS kernel. Some parts of the kernel can be located by following pointers from this page (e.g. to replace the clock driver). -- David Empson dempson@actrix.gen.nz Snail mail: P O Box 27-103, Wellington, New Zealand