Subject: Re: ProDOS... Newsgroups: comp.sys.apple2 From: dempson@actrix.gen.nz (David Empson) Date: Sun, 1 Oct 2000 22:32:59 +1300 Message-ID: <1ehufbd.1e5miub4f2zxyN%dempson@actrix.gen.nz> References: <39cba1c2$1@hal.grnco.net> <39CD94A4.2555B331@dcnet2000.com> <39CE1FBA.250B83BB@inetnebr.com> <8qmop3$3d6$1@merope.saaf.se> <39D084AB.AD21E514@dcnet2000.com> <39D0AE3F.F631E95B@inetnebr.com> <1ehssze.jy4jskefvttoN%dempson@actrix.gen.nz> <39D630BF.7F550C51@inetnebr.com> Organization: Empsoft User-Agent: MacSOUP/2.4.2 NNTP-Posting-Host: 202.49.157.176 X-Original-NNTP-Posting-Host: 202.49.157.176 X-Trace: 1 Oct 2000 22:43:47 NZST, 202.49.157.176 Lines: 214 Roy and/or Janet Miller 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