Re: ProDOS...

[Roy and/or Janet Miller <millers@inetnebr.com>]

David Empson wrote:

> Roy and/or Janet Miller <millers@inetnebr.com> wrote:
>
> > Phoenyx wrote:
> > >
> > > My comment about the P8 compatibility is still valid, just as David's is.
> > > Any new or upgraded OS would loose 80 to 90 percent compatibility with
> > > system applications due to the way the ProDos/Apple II system is designed.
> >
> > But would a full implementation of SOS do that?
>
> SOS would be no better than any other non-ProDOS operating system.
>
> ProDOS implements a subset of the calls available on a full SOS system.
> I've never seen any programming documentation for SOS, but my
> understanding is that ProDOS allows for nearly all the SOS support for
> file I/O on block devices.  SOS also has full support for character
> devices (such as serial and parallel ports), unlike ProDOS.

The ProDOS workbench phrases it like this:
SOS communicates with all devices - the console, printers, disk drives, and so on
- by making open, read, write, and close calls to the appropriate device; writing
to one device is essentially the same as writing to another. ProDOS can perform
these operations on files only.
The workbench then explains the hardware reasons why.

>
>
> I believe that ProDOS uses the same call numbers and similar parameters
> to the corresponding SOS calls, which makes it relatively easy for the
> author of an application to support both operating systems (///
> EZ-Pieces and AppleWorks being the best example of this).
>
> > Since P8 is only a cut down version of SOS?
>
> ProDOS is a functional subset of SOS, but as far as I know, the memory
> organisation and application protocol interfaces are different.

"SOS has a fairly sophisticated memory manager:  a system program requests memory
from SOS, either by location or by amount needed. If the request can be satisfied,
SOS grants it. That portion of memory is then the sole responsibility of the
requester until it is released."

"A ProDOS system program is responsible for its own memory management. It must
find free memory, and then allocate it by marking it off in a memory bit map. If a
page of memory is marked in the bit map, ProDOS will not read date into that page.
ProDOS can thus prevent users from destroying protected areas of memory
(presumably all date is brought into memory using the ProDOS READ call)."

>
>
> SOS was designed around the architecture of the Apple III, including its
> special extended memory architecture.  ProDOS was designed to squeeze
> into the limitations of the Apple II.

That was a question I had asked earlier. How does the /// and SOS handle memory? I
know that the /// doesn't have the I/O memory section that the ][ does, and I know
that SOS is a RAM based OS. I also know that the //e has a memory management chip
(I assume ditto on the //c). What is the difference, and can the // under an
extended ProDOS have the memory ability of the /// under SOS?

>
>
> > One thing that SOS does that I would like to see in P8 is the
> > ability to utilize more than 128K as user memory.
>
> This is due to the extended memory architecture provided by the Apple
> /// hardware.  In effect, it can directly address more than 64 KB
> without requiring bank switching techniques.

David, how does it do that? Do you know?

>
>
> The Apple II has no such specialised hardware, and uses complex bank
> switching techniques to access more than 64 KB.

The /// uses bank switching too, somehow. What I have read is that memory is
handled in 32K blocks, and, in theory, the /// could have a full meg of RAM
(though I think even under the ///+ the limit was 512K).

> The 16 KB language card
> area (hidden behind the 12 KB of ROM) was the first such method,
> followed by the 64 KB auxiliary memory of the Apple IIe.
>
> Third-party memory expansion cards extended the auxiliary memory concept
> by providing a multi-bank version of it.  Unfortunately, this is rather
> difficult to manage.

And this was what I was wondering - can such a scheme be done as part of ProDOS,
so there is an accepted, standard way for using the expansion memory, other than
as a RAM disk? I remember reading that Apple had supplied some support for up to 8
megs of RAM in a //, and I've seen AE's RAMWorks /// in my computer load in all of
AppleWorks v3.0 and Timeout utilities as well. Can AE's method be accepted as the
standard way? How can anyone who wishes to write a new program for the 8 bit ][
use such additional memory in a way that will work with most expansion memory
cards and with the //gs?

BTW - I really appreciate your answers here. You have filled in some gaps in my
knowledge, I merely want more gaps closed  :-)


>
>
> > Wouldn't it be nice to see all P8 programs have that kind of data without
> > having to use RAM disks?
>
> The multi-bank memory architecture doesn't allow for this sort of thing
> without each application being written specially to use it.

But that can be done now? In a recognized standard way?

Roy