GREYELF@WPI.BITNET (04/02/89)
>>Yes, Prodos 8 sets up its own interrupt vector to its interrupt handling >>routines on booting. As for special precautions, first allocate an >>interrupt routine, activate the hardware, then CLI to enable CPU >>recognition of the interrupts. >> >>Interrupts are only enabled after setting the hardware to generate them, >>and issuing a CLI instruction to enable CPU recognition of interrupts. >ACK! ACK! ACKI >We officially frown on people who do that. CLI, that is. If someone needs >interrupts *disabled*, that's just fine. That's reasonable. But most folks >(*especially* low-level routines) should not be directly clearing the flag >with a CLI instruction? >Why? Because the person who called you might need interrupts disabled, and >it's not reasonable to expect everyone calling a low-level routine to have >to re-set the interrupt flag after any call to an external routine. >What we recommend is that those who need to *disable* interrupts do so with >the sequence PHP/SEI. When you no longer need interrupts disabled, use PLP. >This disables interrupts when necessary, and returns the processor *to the >previous interrupt state* when done. >GS/OS and ProDOS 8 both keep interrupts enabled at system start time, and >don't leave them disabled (since they generally use PHP/SEI/PLP) when >unnecessary. So unless using DOS 3.3 (which is old enough not to deal with >this problem), try not to specifically turn on interrupts, but rather just >restore what was there before you disabled them. If you haven't disabled >interrupts, assume they are enabled. >----------------------------------------------------------------------------- >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." >----------------------------------------------------------------------------- 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. 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. I already tried it on my Laser 128, and that's exactly what happened. 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 :^). 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. 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. -- 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. People keep asking me if Shell or Daemon are compatible with the IIc, IIe. YES, I wrote them on my Laser 128. I mean, what would be the challenge to multitasking on a IIgs? I'll start writing dedicated gs programs when somebody sends me one in the mail.
mattd@Apple.COM (Matt Deatherage) (04/03/89)
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." -----------------------------------------------------------------------------