Re: ProDOS...

[dempson@actrix.gen.nz (David Empson)]

Roy and/or Janet Miller <millers@inetnebr.com> wrote:

> David Empson wrote:
> 
> > 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 don't enough about the /// to be able to comment on this with much
authority.

> I know that the /// doesn't have the I/O memory section that the ][ does

It may not be arranged in the same way, but it has to provide memory
mapped I/O somehow (the 6502 doesn't have a separate address space for
accessing I/O).

> I also know that the //e has a memory management chip (I assume ditto on the
> //c).

Yes, both have a chip which is called the MMU (Memory Management Unit),
but this is a rather grandiose name.  There is also the IOU
(Input/Output Unit).  Between them, these chips contain nearly all the
logic circuitry on the Apple ][ and ][+ motherboard, plus some new
features for the IIe (auxiliary memory, 80-column mode).  The "Mega II"
chip in the IIgs is basically a merged MMU and IOU, with yet more
features thrown in.

The IOU is mainly responsible for generating the video displays,
including the "double resolution" modes.

The MMU is mainly responsible for dealing with the bank switching
schemes available to the CPU so that it addresses the appropriate areas
of memory.

The CPU (via the MMU) gets to access memory in one half of each cycle,
and the IOU gets to access memory in the other half of each cycle (for
video generation).

The MMU implements the following bank switching mechanisms:

- Language card area ($D000-$FFFF)
- 48 KB area of main and auxiliary memory ($0200-$BFFF)
- Zero page, stack and language card switching between main and
  auxiliary memory ($0000-$01FF and $D000-$FFFF).
- Text page 1 switching for writing to the odd or even columns of
  the 80-column text screen ($0400-$07FF).
- Double hi-res page 1 switching for writing to the odd or even
  bytes of the double hi-res graphics screen ($2000-$3FFF).

The MMU is also responsible for identifying an I/O access ($C000-$CFFF),
and directs this to the IOU for further decoding.

> What is the difference, and can the // under an extended ProDOS have the
> memory ability of the /// under SOS?

The Apple /// has a much more advanced MMU which can support extended
addressing through the use of pointers (and possibly other techniques).
It defines methods for allocating memory in its full address space.

It would be possible to write an "extended ProDOS" that provided memory
management support for multi-bank auxiliary memory cards, but it would
not be at all convenient for applications to use these areas, because it
is generally an all or nothing situation - 47.5 KB of the address space
must be switched out to access another bank, and the remaining areas
have to be handled very carefully.

(By comparison, the IIgs's 65816 can directly address 16 MB without
requiring bank switching, so it is much easier to handle larger memory
areas.)

> > > 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?

I heard about this once in the mid 80's, so my memory is likely to be
extremely rusty.  As far as I recall, the main technique used is that a
certain range of locations on page zero can be treated as extended
memory pointers via the post-indexed indirect mode, e.g. LDA ($60),Y

There must be some registers in an MMU chip which sets the high order
bits of the address, tied to the corresponding zero page pointer.  When
the MMU recognises the appropriate sequence of memory accesses from the
CPU which includes the use of one of these pointer locations, it
supplies the corresponding "bank address" when the final memory access
occurs.

There is probably also a bank switching scheme that allows the address
space to be switched out in a more reasonable manner than the Apple II
(e.g. something like one or more 4 KB areas that can be switched to
access anywhere in the full address space).  I don't about this for
certain.

> 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).

That suggests a half-and-half address space, with the top and bottom
half of the CPU's 64 KB address space able to be switched to any 32 KB
area in the full 1 MB address space. 

If the bank switching is based on a 32 KB bank, this would require a 5
bit bank number.


> > 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?

Not the existing ProDOS, but in a future extended version, perhaps.

The main problems with using multi-bank auxiliary memory are
restrictions with what you can do while running in other banks.  For
example, the video buffers only exist in main memory and first auxiliary
bank, so a program has to return to a reasonably normal memory
organisation to be able to display anything.  This would prevent running
an arbitrary program in another bank (without the program being modified
to deal with the change in the environment).

The other problem is that accessing data in a different bank is rather
tricky.  You either need code in the language card area of each bank
(which could cause conflicts with ProDOS) or code in the same bank as
the data, and do inter-bank calls (via some shared code) to access it.

> I remember reading that Apple had supplied some support for up to 8
> megs of RAM in a //

The only extended memory support provided by Apple was their standard
slot RAM card.  This design can theoretically support 16 MB (as can the
multi-bank auxiliary memory cards).

Apple's card is only useable for storing data, or as a RAM disk, since
you can't execute code directly from it.   It has a one byte window into
the card's RAM in the I/O space, plus a three byte address register,
which increments automatically for each read or write access to the data
register.

The big advantage of Apple's card (and equivalents like the AE
RamFactor) is that a standard slot card can provide firmware, including
a driver for ProDOS.  This means that you don't need to patch the OS to
use the card (unlike multi-bank auxiliary memory cards), and you can
boot from a RAM disk on the card.  The SmartPort firmware also provides
standard routines for reading and writing arbitrary amounts of data from
the card (avoiding the need for direct hardware access by the
application).

> and I've seen AE's RAMWorks /// in my computer load in all of AppleWorks v3.0
> and Timeout utilities as well.

It can also do this with a standard slot RAM card.  AppleWorks has its
own memory management system, which required loading of an appropriate
driver for whichever extended memory card your machine happens to have.
The Timeout utilities and other modules of AppleWorks are pretty much
independent of the underlying memory architecture - they just use the
memory management code to take care of everything.

I don't know whether AppleWorks allows code to be executed in other
banks of a multi-bank card.  It might just use the card as a big data
store, swapping code and/or data in and out of main memory as required.
For example, you can't call ProDOS or access the video buffers while
running in another bank, so it would either require swapping your code
into bank 0 or providing standard hooks which can be called from any
bank.

It has to use this technique with standard slot RAM cards, and with the
IIgs (you can't execute code outside bank 0 in emulation mode on the
IIgs).

> Can AE's method be accepted as the standard way?

Certainly not, since that would only work with one type of extended
memory card.

The memory management scheme provided by AppleWorks could be used,
however.

> 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?

I think Tom Weishaar suggested that AppleWorks should become the
operating system for the Apple II, even to the extent of putting much of
it into the ROM.

In effect, you can use AppleWorks (and its memory manager) as your
"operating system" by writing your program as a Timeout utility instead
of a standalone ProDOS application.  Your program then requires
AppleWorks to operate, and it gains the extended address range.

I've never looked into this, so I don't know what is available as far as
documentation or licensing issues are concerned.


I jumped straight to the IIgs as soon as I could afford it, and hardly
looked back to the 8-bit environment for subsequent programming.
Certainly not for anything which required more than the basic 48KB
address space.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P O Box 27-103, Wellington, New Zealand