From: kegs@provalid.com   
      
   In article ,   
   Mitchell Spector   wrote:   
   >    Question: How *exactly* does an Apple IIGS emulate the 8-bit Apple IIe?   
   >   
   >    For decades the answer has seemingly been the Mega II chip, essentially   
   >an entire 8-bit Apple IIe computer on a single chip (minus the CPU, RAM   
   >and ROM). In fact Apple's marketing and technical documentation always   
   >pointed to the Mega II as how the Apple IIGS was backwards compatible.   
   >   
   >    I've always know the Mega II is what provides classic Apple II video   
   >modes for the IIGS (40/80 ASCII, including Mousetext and international   
   >symbols, LR, HR, DLR, DHR). And while some functions are not used   
   >such as its keyboard control and mouse support, I just assumed the rest   
   >was responsible for the Apple IIGS's 8-bit emulation mode....   
   >   
   >    Then I saw James Lewis' project to build a single chip Apple II, and   
   >read his claim the Mega II's primary (sole?) function is to provides 8-bit   
   >video modes. So, that got me curious. What, exactly, is allowing the   
   >IIGS to emulate the Apple IIe? Such as its sound generation, or replicating   
   >the MMU, IOU and various other components? Is it simply the FPI/CYA   
   >chipset and some other TTL logic recreating the Apple IIe? If none of it   
   >is coming from the Mega II, I'm looking for the real nitty gritty in terms of   
   >technical details on how the Apple IIGS emulates an Apple IIe.   
   >   
   >    On a side note, if the Mega II was NOT responsible for Apple IIe   
   >emulation, and mainly just used as an I/O controller that bottlenecked   
   >the IIGS bus and video draws to 1 MHz, one questions why on earth   
   >Apple didn't scrap the Mega II and design a replacement chip for the   
   >IIGS in all those years? It seems like it was added to the IIGS simply   
   >because it happened to be sitting unused in Apple's development   
   >tool box (the Mega II was originally developed for other purposes).   
   >   
   >Mitchell Spector   
      
   Here's how the IIgs works:   
      
   There's a 65816 CPU, and it talks to the FPI/CYA chip at 2.8MHz, and it   
   connects to the 16MB of RAM/ROM on the motherboard and in the memory   
   expansion slot.  This is all the "fast" side of the system, and it all runs   
   at 2.8MHz.  The FPI generates refresh cycles as needed to the fast RAM.   
      
   There's a "slow" side to the system, where there is a 16-bit address bus   
   and is clocked at 1MHz.  The 16-bit ABUS[15:0] address bus and the   
   DBUS[7:0] data bus that the 65816 and FPI use at 2.8MHz are buffered to   
   a "1MHz" BABUS[15:0] address and MDBUS[7:0] data bus which connects to   
   all 1MHz components.  The FPI determines when a CPU cycle needs to   
   access the slow side of the system, and generates all the control   
   signals needed to do this.  The slow side includes the Mega II, but is   
   also includes the IWM, VGC, SCC, and Ensoniq.   
      
   As for what the Mega II is, it's important to think of what an Apple //e   
   is.  An Apple II+ is a bunch of random 74LS TTL logic that generates the   
   video control signals, decodes the address and selects RAM/ROM/IO, etc.   
   An Apple //e adds the auxiliary memory (the second 64KB bank), and other   
   stuff, and although this could all be done in 74LS TTL chips, it would   
   be a much larger board.  So the //e adds MMU and IOU chips to make the   
   board simpler, just putting the II+ (and some new //e logic) 74LS TTL   
   logic on fewer chips that take less space.  The Mega II is just this   
   process done again, merging the //e MMU, IOU, and video control circuits   
   into one chip.  It's the "same" logic effectively, with some tweaks.  By   
   freeing up board space, the IIgs now has room for IWM, ADB, VGC,   
   Ensoniq, SCC, etc.  The Mega II is not a complete Apple //e--decode   
   logic for the slots is not included and requires the Slotmaker chip.   
      
   It is logically the "same" as the //e logic it is performing, so it's   
   not especially "magic" in what it's doing.  The "magic" is at the FPI/CYA   
   chip, which does the speed conversion.  The fast side of the system runs   
   at 2.8MHz, and when something "slow" is touched, the FPI is the chip which   
   does the conversion to 1MHz.  The FPI is the bridge to the "Apple II" side.   
      
   There is some additional magic where the Mega II and VGC work together to   
   create the SHR graphics mode.  I believe the VGC provides the video   
   addresses, but the Mega II continues to provide the memory control signals   
   (RAS, CAS).   
      
   So, the FPI is the magic that talks to the slow Apple II side.  The Mega II   
   is just one of the things it talks to, which is just most of Apple //e   
   logic rolled into one chip to take less board space.   
      
   The Mega II is MMU, IOU, and non-SHR video generation on a IIgs, but   
   only for banks $E0 and $E1.  So the FPI has to ALSO have the MMU logic   
   in it since it affects fast side memory as well.  One way to think of   
   the Mega II is it controls the memory in banks $E0 and $E1, and that is   
   the Apple //e part, so it's doing the MMU features for that memory.  But   
   the FPI is handling all other banks, so it has replicated the MMU logic,   
   too (aux/main and LC switches are all in the FPI, too, as well as the   
   Mega II).  The FPI just replicates the needed logic to get the Apple //e   
   compatibility right.  The FPI handles shadowing, passing writes to the   
   video memory in banks $00 and $01 to also go to the Mega II to update   
   the bank $E0 and $E1 memory.  So this is likely where some confusion   
   arises--the FPI also has to do lots of things for Apple //e   
   compatibility, and does it in parallel, duplicating some Mega II   
   functionality.   
      
   Kent   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)