Newsgroups: comp.sys.apple2 Subject: Re: //e, //c, //gs Questions From: dempson@actrix.gen.nz (David Empson) Date: Fri, 6 Nov 1998 04:12:29 +1300 Message-ID: <1di1upw.r8rpk1dvvp44N@dempson.actrix.gen.nz> References: <362CE49D.6386@hotmail.com> <19981023002951.26547.00005083@ng08.aol.com> <28OCT199807125032@vax2.concordia.ca> <19981029024423.15815.00000985@ng03.aol.com> <4NOV199806330693@vax2.concordia.ca> Organization: Empsoft X-Newsreader: MacSOUP 2.3 NNTP-Posting-Host: 202.49.157.176 X-Trace: 6 Nov 1998 04:11:21 -1300, 202.49.157.176 Lines: 148 Path: news1.icaen!news.uiowa.edu!NewsNG.Chicago.Qual.Net!nyd.news.ans.net!newsfeeds.ans.net!news.idt.net!newsfeed.cwix.com!203.97.37.7!newsfeed.clear.net.nz!news.iprolink.co.nz!news.actrix.gen.nz!dempson Xref: news1.icaen comp.sys.apple2:141362 Mitchell Spector 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