Matt Jenkins wrote: > David Empson wrote: > > > > Matt Jenkins wrote: > > > > > Phoenyx wrote: > > > > > > > > What I have is reference to the Zram 2c card. AFAIK, the info is > > > > the same for all Applied aux memory cards. > > > > > > I hope so - I'd hate to see what I'm working on not work in a //c. > > > On a similar note, does the //GS use the same system in emulation > > > mode ? > > > > Partly. The IIgs does emulate auxiliary memory, but only a single bank. > > Don't try to use $C073 as a bank select register - it is code in the > > IIgs (part of the interrupt handler). > > OK - so the extended memory is only available in native mode on the > //GS. I don't understand this comment. The "extended memory" of the IIgs is available in all modes. In emulation mode, there is one restriction: it is not safe to execute code anywhere outside bank 0. This is because the 65816 doesn't save the program bank when a hardware or software interrupt occurs in emulation mode. All you need to do is hit a BRK or COP instruction (or, more to the point, an IRQ signal), and there is no way to get back to where the code was executing. It is somewhat safer to execute code outside bank 0 if interrupts are locked out, since you then only need to worry about BRK, COP, ABORT and NMI. I don't see much point doing this, however, as a switch to native mode may be as simple as CLC/XCE. In native mode, it is safe to execute code in all banks. You can use other banks for data storage in emulation mode, by using the data bank register or long addressing modes. > > I see you already know about RAMRD/RAMWR, and presumably you know about > > 80STORE. There is one more softswitch of relevance here: > > Yes, turn on 80store and hit the page 2 switch and you bank in $400-7FF > if I remember right. Also, if hires/double-hires is active you also get > $2000-$3FFF. The double hi-res page switch enable is tied to Annunciator 3. If I remember right, it doesn't need HGR displayed on the screen. > > If you are dealing with a multi-bank card, $C073 selects the active RAM > > bank for all of auxiliary memory. > > > > If you switch ZP/stack/language card to auxiliary memory, then you may > > have to deal with the interrupt vectors ($FFFA to $FFFF). A multi-bank > > version extends the problem to other banks as well. > > Yep, I know that $FFFA is the NMI vector - do I ever have to worry about > this? Yes. If someone has an NMI card in a IIe (crack cards, generally) then $FFFA in the current bank will be the vector. You should probably have stub code which handles both NMI and IRQ/BRK by saving the current state, switching to a "normal" memory configuration, then simulating the interrupt again. When the normal interrupt handler does an RTI, your handler resumes control, switches back to the "abnormal" state, and does the real RTI. This is similar to how the interrupt handler operates on the IIc and enhanced IIe (but it doesn't know about multi-bank cards). > Presumable $FFFC will get handled when someone ctrl-resets the box. Reset will enable ROM, so the vector is always fetched from the right place. Note that auxiliary slot cards cannot detect reset, so an arbitrary RAM bank may be selected. This may cause interesting problems with code that tries to access the DHR graphics screen (or any other part of auxiliary memory) without using 80STORE and PAGE1/2, until a driver kicks in and restores the correct bank selection. > > There are also conventions for dealing with the stack pointer in main > > and auxiliary memory. The two stacks are supposed to be independent, > > and the stack pointers and supposed to be saved and loaded in memory > > locations $0100 and $0101 in auxiliary memory (I'd have to dig out a > > manual to confirm which way around they go). > > Is there a ROM routine that handles this ? The IIc and enhanced IIe IRQ firmware knows about these conventions, so if an IRQ occurs while the auxiliary stack is active, the auxiliary SP is saved at $0101, the main SP is loaded from $0100, then the main stack is switched in. The original state is restored when the user IRQ handler does an RTI. The NMI handler usually leaps blindly into never-never land if any nonstandard memory configuration is active. If you are writing code which switches in the auxiliary stack, it is just a matter of following the established conventions, i.e. * Initialization SEI ; No interrupts, please STA AUXZP ; Switch in aux ZP/stack TSX STX $0100 ; Set up the main stack pointer (optional) LDA #$FF STA $0101 ; Set the initial aux stack pointer STA MAINZP ; Switch in main ZP/stack CLI ; Safe to interrupt again * Main to Aux SEI ; No interrupts for a moment STA AUXZP ; Switch in aux ZP/stack TSX STX $0100 ; Save the main stack pointer LDX $0101 ; Load the aux stack pointer TXS CLI ; Safe to interrupt again * Aux to Main SEI ; No interrupts for a moment TSX STX $0101 ; Save the aux stack pointer LDX $0100 ; Load the main stack pointer TXS STA MAINZP ; Switch in main ZP/stack CLI ; Safe to interrupt again This assumes that you don't need to copy anything between the stacks when transferring banks. If you have a multi-bank auxiliary slot card, then I imagine the best procedure would be to replicate this convention in every bank, keeping the stacks separate for all banks. This means that the interrupt firmware will behave correctly when switching in the main bank, and will restore the stack pointer correctly. As long as the user interrupt handler doesn't change the active bank in the auxiliary slot card, everything should work. -- David Empson dempson@actrix.gen.nz Snail mail: P O Box 27-103, Wellington, New Zealand