Don Bruder wrote: > In article , Oliver Schmidt > wrote: > > > Is there information available on which //e softswitches are modified > > by the reset itself and which softswitches the software has to care > > about. My question is especially about the switches related to memory > > banking (LC as well as AUX). > > I've forgotten anything useful I ever knew in this department due to > disuse. > > > And one question on the reset itself: Is it blocked by an SEI > > instruction? > > Nope. Reset is (unless I've gotten terminally fogged) a hardware signal, > not an interrupt. RESET, NMI and IRQ are all hardware signals - they are inputs to the microprocessor. SEI only affects whether the 65xxx reacts to the IRQ input. It has no effect on NMI or RESET. > It's an actual "pull this line of the processor low (or is it high? > Again, too long since I used the knowledge) for a moment" thing. In the case of the 65xxx, it is low, if anyone cares. (As are IRQ and NMI.) > Once the reset signal is cleared, the processor does the equivalent of a > JMP ($FFFE). Actually JMP ($FFFC), for some bizarre reason (in most other CPU families, the reset vector is the first or last one in the vector table, not the middle one). Why do I bother to remember these details? :-) > If you want to try to block out resets, or alter the behavior, you're > going to have to play with patching the reset vector. Agreed. According to Inside the Apple IIe, the MMU chip recognises the bus sequence generated by the CPU for a hardware reset (three reads on page 1 followed by a fetch at $FFFC) and reacts by resetting all of its softswitches. This means that most of the "IIe and later" softswitches in $C000-$C00F will be reset (equivalent of writes to even addresses in this range): - Disable 80-column store - Select main memory for read (disable aux memory) - Select main memory for write (disable aux memory) - Select slot CX ROM - Select main memory zero page and stack (disable aux memory) - Select internal C3 ROM The MMU is also responsible for the language card softswitches, all of which are cleared, so ROM is selected and RAM writing is disabled, resulting in the reset vector always being fetched from ROM. (This differs from the ][ and ][+ with a language card, which will fetch the $FFFC vector from the currently active bank.) The MMU's copies of the PAGE2 and HIRES softswitches are cleared. (The IOU's copy might be unaffected, so if PAGE2 happened to be active, the IOU might be trying to display video page 2 while the MMU will access main memory if 80STORE is enabled again. I'd have to dig further to confirm this.) The MMU's INTC8ROM switch is also cleared (this is related to the internal C3 ROM space) so motherboard ROM won't appear in $C800-$CFFF, but other cards might still be active in this area. Other I/O-related switches are not affected. For example, the casette and speaker outputs and annunciators won't change state. I/O cards have reset available as an input, and can react as they see fit. The IIgs uses different hardware (Mega II and Fast Processor Interface chips) but it has the same behaviour at reset. I expect the implementation is more straightforward, with the RESET pin going to the Mega II and FPI/CYA, rather than doing a slightly risky decode of a memory access sequence. The IIgs has a lot more soft switches and I expect more of them are affected by a hardware reset. -- David Empson dempson@actrix.gen.nz