Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!ubvax!vsi1!apple!mattd From: mattd@Apple.COM (Matt Deatherage) Newsgroups: comp.sys.apple Subject: Re: interrupt processing Message-ID: <28271@apple.Apple.COM> Date: 2 Apr 89 20:32:01 GMT References: <8904020431.AA09720@wpi> Organization: Apple Computer Inc, Cupertino, CA Lines: 91 In article <8904020431.AA09720@wpi> GREYELF@WPI.BITNET writes: > >Yes, Matt, you do have a valid point in that a routine that calls another >routine might not expect it to activate interrupts, but if as you say >Prodos 8 doesn't deactivate interrupts, Basic.system must, because by >the time you make it to BASIC, the interrupts ARE disabled. > They aren't in MY version of BASIC.SYSTEM. This can be seen by trying to access the Control Panel from BASIC. If interrupts are disabled, pressing the key sequence doesn't get you in until interrupts are re-enabled. >This is easily tested from the monitor by issuing: >C0C7:0 >and pressing the ctrl-g key, it should sound normal. >Then: >2000: 58 60 N 2000G >and pressing ctrl-g again, it should sound broken up if I'm right. > C0C7 is some softswitch for slot four; setting it to zero causes an effect that is ENTIRELY dependent on whatever is in slot four. I hope no one out in net land tries this out with a hard drive in slot four... >I already tried it on my Laser 128, and that's exactly what happened. > Ah, well now we're getting somewhere. I've been tracing through the IIe ROM (enhanced), and the RESET nor IRQ firmware specifically disables or enables interrupts. The 6502 does disable interrupts when RESET goes low, as it does when IRQ is triggered, but an RTI restores the interrupt flag to whatever it was when the interrupt came through. This leaves the situation where interrupts are disabled (by the processor through RESET) when the system is booted, and the ROM doesn't specifically enable them. I can't say this for certain without checking the source, but I was just playing around with P8 1.7 on my IIe and when the .SYSTEM program got control, interrupts were enabled. I'm almost POSITIVE P8 1.2 and later do this somewhere in the boot process. >The CLI instruction MUST be used to enable the CPU to recognize interrupt >requests being generated (well actually you could create your own processor >mask, PHA and then PLP :^). > There's no argument here. The argument is that you shouldn't have to do a CLI; because if it's safe for interrupts to be enabled, they will BE enabled. >In addition the use of the RESET key disables maskable interrupts, and I would >imagine the use of a BRK instruction would as well. In these cases IT IS >NECESSARY to re-enable cpu recognition of the interrupts being generated. > RESET does disable interrupts as discussed earlier; so does BRK since it is actually a software interrupt. If one of these two things occur, someone would have to reenable interrupts with CLI to get them started again. However, BRK is not something that occurs in most programs (at least not intentionally), and most programs don't have a special handler to keep things going after a BRK instruction. Some programs do have RESET handlers, though. In either case, reenabling interrupts is a tricky business since you don't know what the interrupting hardware was doing when RESET was pressed (or you don't know how the interrupt handler left the hardware when the BRK occurred). This makes leaving them disabled by far the safest choice. Yeah, I know it sounds pud-like, but I don't want to be the one with a BRK handler that enabled interrupts and tried to resume in the middle of disk I/O code, where the interrupts might accidentally trash megabytes of media. It probably could be done safely, but only if you're VERY SURE about what hardware is where, and have a reasonable idea of what was going on when the interruption occurred. I think the latter is pretty close to impossible on systems with slots in them. >Your message noted the proper way to temporarily DISABLE interrupts for >a task requiring timing, but it is NOT the way to enable CPU recognition >of interrupts to begin with, which is what was asked for. > I still say that if using current versions of ProDOS and an enhanced IIe or later, CLI is not necessary and should be avoided. It is obviously necessary for unenhanced IIe's and earlier, which generally disabled interrupts because the firmware interrupt handler and DOS 3.3 collided. It's also necessary for DOS 3.3, but not for the majority of stuff done today. >-- >Michael J Pender Jr Box 1942 c/o W.P.I. I wrote SHELL and Daemon, >greyelf@wpi.bitnet 100 Institute Rd. send bug reports, suggestions, >greyelf@wpi.wpi.com Worcester, Ma 01609 checks to me. > ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that AppleLink PE: Matt DTS GEnie: AIIDTS | Apple Computer, Inc., or any of its CompuServe: 76703,3030 | subsidiaries, in whole or in part, Usenet: mattd@apple.com | have any opinion on any subject." UUCP: (other stuff)!ames!apple!mattd | "So there." -----------------------------------------------------------------------------