Re: ProDOS...

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

Wow, thanks for the education - do you charge tuition? :-)

Roy

David Empson wrote:

> 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