[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: //e, //c, //gs Questions



Mitchell Spector <spec@vax2.concordia.ca> wrote:

> In article supertimer@aol.com (Supertimer) writes...
> 
> >spec@vax2.concordia.ca (Mitchell Spector) wrote:
> >>
> >>    Improved capabilities? :) For the most part, the IIe
> >>*is* an Apple II Plus, only with the equivalent of a 16K
> >>Language Card and lowercase support built-in. [...]
> >
> >Bank-switching and mousetext (I'm thinking of the
> >Apple IIe Professional) were in themselves improved
> >capabilities, not to mention the importance of lower
> >case.
> 
>     The Apple II and II Plus supported bank-switching, using
> a Language Card you could expand to 64K or even more in the
> case of a few specialized slot-0 RAM cards.

This wasn't particularly useful, though.  The IIe auxiliary slot is much
more flexible.

> Technically, I'm not sure how the auxiliary slot's method of
> bank-switching differed from that of the II and II Plus (I do
> have a couple guesses, but I'll let someone else step in rather
> than make speculations.

(Steps up to the podium.)

The language card uses the INHIBIT signal on the slot to override
motherboard memory (ROM) where required, and it monitors the full
address and data bus.  If the language card is read-enabled and a ROM
address is detected, the card hits INHIBIT to disable the ROM, and
outputs its own data instead.  Write accesses don't need to use INHIBIT
(mut might do so anyway).

It has three softswitches that are controlled in the $C080-$C08F area
(assuming slot 0):

- RAM Read enable
- RAM Write enable
- RAM Bank select (for the two 4K banks at $D000-$DFFF)

(They are decoded from address bus bits, so eight locations in the
$C080-$C08F area control all three switches simultaneously.  The
write-enable switch requires a double access to allow writing to the
card.)

The IIe has an emulation of the language card built into the
motherboard, and it appears to be in slot 0 as far as software is
concerned.

For the IIe auxiliary slot, all the bank switching hardware (for
main/auxiliary) is provided on the motherboard.  The card itself only
contains the extra RAM and some logic circuitry to decode signals as
required.

(The RamWorks and similar cards have additional bank switching hardware
on the card itself, to provide multiple 64K auxiliary banks.  I won't go
into that here.)

For software access to auxiliary memory, the motherboard provides three
main softswitches:

- Read bank select (main/aux)
- Write bank select (main/aux)
- Zero page/stack/language card bank select (main/aux)

The first two switches control the memory area from $0200-$BFFF while
the last one controls $0000-$01FF and $D000-$FFFF.  Having separate bank
selects for reading and writing allows data to be copied between the two
banks (this can only be done by code running in the I/O space, e.g. the
80-column firmware, or by code in the language card or ROM).  This isn't
possible with the language card area, except for reading data from the
ROM and writing it to RAM.

These switches all reside in the MMU chip.  They are used to select
which chip select output gets activated during CPU accesses: there are
separate signals going to the auxiliary slot and motherboard RAM.

During the CPU half of each cycle, either auxiliary or main RAM can
output data onto or read data from the data bus.  (The only time neither
bank is enabled is during I/O location and ROM accesses.)

This is complicated somewhat by the 80STORE softswitch, which allows the
auxiliary memory halves of text/lores and hires page 1 to be accessed by
code running in main memory.  If 80STORE is turned on, then the
PAGE1/PAGE2 softswitch is used to determine which RAM bank is accessed
for memory locations $0400-$07FF, overriding the main/aux read and write
bank select switches.

The 80STORE switch also affects hires graphics page 1 at $2000-$3FFF in
the same way.  (I don't recall offhand whether the HIRES switch needs to
be turned on for this to happen.)


The second part of the equation is what happens during the video half of
each cycle.  If the machine is running in a 40-column mode (or standard
hi-res grahpics) then it behaves pretty much the same as the II+.  If
80-column mode is enabled, then video data is fetched simultaneously
from main and auxiliary memory (using independent data busses and
latches), and shifted out through the video circuitry at twice the rate
of 40 column mode (14 MHz instead of 7 MHz).  This description is
simplified somewhat (e.g. lo-res graphics already runs the video
circuitry at 14 MHz.)

> More specifically, I'm not sure why you could mirror 64K on an
> IIe to get 80 columns and DHR, yet not do the same on a II Plus.

The memory management hardware on the II+ doesn't support it, and
neither does the video hardware.  There is no way to do it through a
slot, either, because the INHIBIT signal only works in the ROM area
($D000-$FFFF) in a ][ or ][+.  (It works for $0000-$BFFF area as well
for the IIe, but interacts strangely with the auxiliary memory bank
select.)

> >I remember seeing quite a sizable number of programs
> >that supported cooperative multitasking in SOME way
> >(that is, at least allowed OTHER programs to run in the
> >background).
> 
>     Well I've seen some NDA's do cooperative multitasking,
> GScii+ is one example, you can have it decode files while
> you work on something in the foreground (you can even set
> how much CPU time it uses).

NDAs by definition must use cooperative multitasking.  The only time
they get execution is while an application is checking for events (or in
response to an event associated with the NDA, such as a click in the NDA
window).  The only time that they should be taking over the CPU is while
a modal dialog is displayed, and that should be avoided as much as
possible.

The Manager extends this mechanism so that any other application can get
execution while the previous application is checking for an event.

This is precisely how MultiFinder worked on the Macintosh (and the
mechanism continues to the present day).

The difficulty is that many IIgs applications assume that they own the
machine (except for limited operations by NDAs), and running other
applications tends to confuse things.  Some parts of the toolbox have
global mode settings, which The Manager has to work around somehow.

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