[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ProDOS...
- Subject: Re: ProDOS...
- From: dempson@actrix.gen.nz (David Empson)
- Date: Sat, 23 Sep 2000 18:25:32 +1200
- Newsgroups: comp.sys.apple2
- Organization: Empsoft
- References: <39cba1c2$1@hal.grnco.net>
- User-agent: MacSOUP/2.4.2
- Xref: supernews.google.com comp.sys.apple2:1802
Arkain <rwking@no.usa.spam.net> 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
- References:
- ProDOS...
- From: "Arkain" <rwking@no.usa.spam.net>