Hi David, first of all thanks for your detailed and in fact very helpful explanation :-) >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. Very strange, isn't it? Why wouldn't one simply check the RESET signal? Why does the CPU three reads on page 1on RESET? BTW: Would it be possible to emulate that behavior closely enough with a program? >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 Okay, this is what I've expected by now from what you wrote above... >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.) Are you really, really sure about that? I guess we aggree that the normal setup for the LC both on ][ and //e is to be set to write-only (and bank 2). This is i.e. what allows you to simply BLOAD INTBASIC. If this setup were not initialized by the RESET signal itself, it would have to be done by the ROM code and I don't see any ][ ROM code fiddling with LC softswitches at all. Additionally I just used the AppleWin built-in debugger the check for access to the LC softswitches $C081 and $C082 while a //e cold start and DOS 3.3 boot. There was none at all. So if what you write is true my questions would be: 1. How is the LC on the //e set to write-only after it was write-protected by the MMU. 2. How is the LC on the ][ set to write-only generally. >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.) Indeed a quite complicated scenario... >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. Okay, understood. >Other I/O-related switches are not affected. For example, the casette >and speaker outputs and annunciators won't change state. Okay, as far as I know the video softswitches fall into this cathegory as well - don't they? >I/O cards have reset available as an input, and can react as they see >fit. Surely... >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. That's for sure - as I already mentioned above... >The IIgs has a lot more soft switches and I >expect more of them are affected by a hardware reset. Once again thanks for all these informations. However I would be great if you - or somebody else - could follow up on my concerns regarding the LC behaviour - and especially the question from which memory $FFFC/$FFFD are fetched on RESET. Oliver Oliver Schmidt wrote: >Hi David, > >first of all thanks for your detailed and in fact very helpful >explanation :-) > >>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. > >Very strange, isn't it? Why wouldn't one simply check the RESET >signal? A couple of possibilities: /RESET was hard to route to the chip(s) at the stage the capability was added, or it was necessary for compatibility to preserve the possibility of a "software" reset (see below). >Why does the CPU three reads on page 1 on RESET? Sounds like an aborted stack manipulation prior to fetching the reset vector. >BTW: Would it be possible to emulate that behavior closely enough with >a program? If David is correct, a JMP ($FFFC) on page 1 should do the trick. >>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 > >Okay, this is what I've expected by now from what you wrote above... > >>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.) > >Are you really, really sure about that? It depends on the "language card" design. Some used reset to reset their enables, and some did not. Most could be easily modified (by lifting a pin) to not reset. ;-) >I guess we aggree that the normal setup for the LC both on ][ and //e >is to be set to write-only (and bank 2). This is i.e. what allows you >to simply BLOAD INTBASIC. The BASIC loader presets this condition explicitly, and does not depend on the Reset state. >If this setup were not initialized by the RESET signal itself, it >would have to be done by the ROM code and I don't see any ][ ROM code >fiddling with LC softswitches at all. It doesn't because the Language Card postdates the ][ and ][+. It is the BASIC loader program ("APPLESOFT") which contains the Language Card state setting, which it does just prior to the BLOAD. >Additionally I just used the AppleWin built-in debugger the check for >access to the LC softswitches $C081 and $C082 while a //e cold start >and DOS 3.3 boot. There was none at all. > >So if what you write is true my questions would be: > >1. How is the LC on the //e set to write-only after it was >write-protected by the MMU. > >2. How is the LC on the ][ set to write-only generally. It is set by software, not firmware. The only precondition that is required for correct operation is that the ROM bank is enabled for reading. Software takes care of all the bank-switching prior to use. Interrupt handling is the exception ;-), of course. The //c and enhanced //e save and restore the enable state of bank-switched memory on interrupts. >>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.) > >Indeed a quite complicated scenario... > >>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. > >Okay, understood. But on later machines than the ][+, ROM initialization code will disable the I/O expansion ROM space, since the extended main board ROM needs to use it. >>Other I/O-related switches are not affected. For example, the casette >>and speaker outputs and annunciators won't change state. > >Okay, as far as I know the video softswitches fall into this cathegory >as well - don't they? They may or may not, since firmware initializes them in any event. -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ Hi Michael, [...] >>BTW: Would it be possible to emulate that behavior closely enough with >>a program? > >If David is correct, a JMP ($FFFC) on page 1 should do the trick. Thanks for the hint :-) >>>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.) >> >>Are you really, really sure about that? > >It depends on the "language card" design. Some used reset to >reset their enables, and some did not. Most could be easily >modified (by lifting a pin) to not reset. ;-) Wow, "it depends" is the answer that I'd expected least. >>I guess we aggree that the normal setup for the LC both on ][ and //e >>is to be set to write-only (and bank 2). This is i.e. what allows you >>to simply BLOAD INTBASIC. > >The BASIC loader presets this condition explicitly, and does >not depend on the Reset state. Sorry, but now I'm lost. What is the "BASIC loader"? >>If this setup were not initialized by the RESET signal itself, it >>would have to be done by the ROM code and I don't see any ][ ROM code >>fiddling with LC softswitches at all. > >It doesn't because the Language Card postdates the ][ and ][+. Surely, I just wanted to point out my thoughts... >It is the BASIC loader program ("APPLESOFT") which contains >the Language Card state setting, which it does just prior to the >BLOAD. Hm, the most simple scenario, we're talking about seems to be a ][+ with Applesoft in ROM and Apple DOS 3.3 booted. What is the "BASIC loader program" in this scenario? I always thought that the "BLOAD INTBASIC" has no special preparation about it... >>2. How is the LC on the ][ set to write-only generally. > >It is set by software, not firmware. I'm I right that you refer here to the "BASIC loader" you mentioned before? >Interrupt handling is the exception ;-), of course. The //c and enhanced >//e save and restore the enable state of bank-switched memory on interrupts. > I found exactly that out by analyzing the ROM code recently. Thanks for the info anyway. BTW: I still don't understand completely how the code in question gets along without being able to read back the write-protection state from the LC. There are comments in the ROM code listing but I don't really understand them :-( >>>Other I/O-related switches are not affected. For example, the casette >>>and speaker outputs and annunciators won't change state. >> >>Okay, as far as I know the video softswitches fall into this cathegory >>as well - don't they? > >They may or may not, since firmware initializes them in any event. If it is true that on a ][+ with an active LC the RESET fetches the FFFC/FFFD from the LC and if I install a handler there which does not initialize them they will not be initialized - if they aren't already initialized by "hardware". So it's just this difference that is important to understand for me... Oliver Oliver Schmidt wrote: >>>BTW: Would it be possible to emulate that behavior closely enough with >>>a program? >> >>If David is correct, a JMP ($FFFC) on page 1 should do the trick. > >Thanks for the hint :-) > >>>>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.) >>> >>>Are you really, really sure about that? >> >>It depends on the "language card" design. Some used reset to >>reset their enables, and some did not. Most could be easily >>modified (by lifting a pin) to not reset. ;-) > >Wow, "it depends" is the answer that I'd expected least. > >>>I guess we aggree that the normal setup for the LC both on ][ and //e >>>is to be set to write-only (and bank 2). This is i.e. what allows you >>>to simply BLOAD INTBASIC. >> >>The BASIC loader presets this condition explicitly, and does >>not depend on the Reset state. > >Sorry, but now I'm lost. What is the "BASIC loader"? The HELLO program on the DOS Master diskette that loads whichever BASIC is not in the main board ROMs into the Language Card RAM. This program does a test for the presence of a Language Card and then enables it and BLOADs the "other" BASIC. >>>If this setup were not initialized by the RESET signal itself, it >>>would have to be done by the ROM code and I don't see any ][ ROM code >>>fiddling with LC softswitches at all. >> >>It doesn't because the Language Card postdates the ][ and ][+. > >Surely, I just wanted to point out my thoughts... > >>It is the BASIC loader program ("APPLESOFT") which contains >>the Language Card state setting, which it does just prior to the >>BLOAD. > >Hm, the most simple scenario, we're talking about seems to be a ][+ >with Applesoft in ROM and Apple DOS 3.3 booted. What is the "BASIC >loader program" in this scenario? If Applesoft is resident, then the HELLO program, and if Integer BASIC, then the APPLESOFT program, IIRC. >I always thought that the "BLOAD INTBASIC" has no special preparation >about it... No, the loading program must enable the Language Card first. >>>2. How is the LC on the ][ set to write-only generally. >> >>It is set by software, not firmware. > >I'm I right that you refer here to the "BASIC loader" you mentioned >before? > >>Interrupt handling is the exception ;-), of course. The //c and enhanced >>//e save and restore the enable state of bank-switched memory on interrupts. >> > >I found exactly that out by analyzing the ROM code recently. Thanks >for the info anyway. That's exactly what I've been doing recently, too, for other reasons. ;-) >BTW: I still don't understand completely how the code in question gets >along without being able to read back the write-protection state from >the LC. There are comments in the ROM code listing but I don't really >understand them :-( I haven't looked closely at that part, but it could always do a simple EOR experiment to see if it is addressing RAM that is write-enabled. >>>>Other I/O-related switches are not affected. For example, the casette >>>>and speaker outputs and annunciators won't change state. >>> >>>Okay, as far as I know the video softswitches fall into this cathegory >>>as well - don't they? >> >>They may or may not, since firmware initializes them in any event. > >If it is true that on a ][+ with an active LC the RESET fetches the >FFFC/FFFD from the LC and if I install a handler there which does not >initialize them they will not be initialized - if they aren't already >initialized by "hardware". So it's just this difference that is >important to understand for me... And this behavior is exactly what was desired when using a Language Card as part of a strategy to deprotect software. By keeping the card RAM enabled during RESET, it was possible to run a modified monitor that made capturing the executing program's state much easier. I used a Saturn 128KB card clone, and had to lift a pin to prevent RESET from disabling the card. I never encountered any software that detected that I had done this, so I expect that it wouldn't matter much from a compatibility viewpoint. -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ Oliver Schmidt writes: >>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. >Very strange, isn't it? Why wouldn't one simply check the RESET >signal? Very simple. This saved one pin on the MMU that was needed for another function. The MMU already needs the full address bus but dispensed with the need for a RESET pin by this trick. >Why does the CPU three reads on page 1 on RESET? Because RESET is treated in almost the same way as any other hardware interrupt. When an IRQ happens the PC and status registers are pushed on the stack and then the vector is fetched from $FFFE/F. The RESET modifies this to make the three pushes happen with R/W = 1 which means they do not modify the stack contents. >BTW: Would it be possible to emulate that behavior closely enough with >a program? I am sure it could. >>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.) >Are you really, really sure about that? He is correct. I seem to recall that if you run Apple Pascal it sets its own reset vector in the language card to make recovery from pressing the RESET button less traumatic. This does not work on a IIe. >I guess we aggree that the normal setup for the LC both on ][ and //e >is to be set to write-only (and bank 2). This is i.e. what allows you >to simply BLOAD INTBASIC. >If this setup were not initialized by the RESET signal itself, it >would have to be done by the ROM code and I don't see any ][ ROM code >fiddling with LC softswitches at all. There is no code in the II/II+ to deal with the language card as it didn't exist when the ROM was written. The LC will power up in a known state but is unaffected by RESET. The IIe is different. -- David Wilson School of IT & CS, Uni of Wollongong, Australia