Xref: utzoo rec.arts.sf-lovers:49295 alt.cyberpunk:4941 comp.arch:19107 Path: utzoo!utgpu!cs.utexas.edu!samsung!munnari.oz.au!metro!wolfen!cs.uow.edu.au!david From: david@cs.uow.edu.au (David E A Wilson) Newsgroups: rec.arts.sf-lovers,alt.cyberpunk,comp.arch Subject: Re: 6502 interrupts (was Re: Count Zero Interrupt) Message-ID: <1990Nov9.051840.7481@cs.uow.edu.au> Date: 9 Nov 90 05:18:40 GMT References: <1427@carol.fwi.uva.nl>, <4bC2VW600VIE094FUA@andrew.cmu.edu> Organization: Dept of Computer Science, Wollongong University Lines: 23 esmith@goofy.apple.com (Eric Smith) writes: >The 6502 handles interrupts just fine; it is the Apple II that handles >them badly. I think thats overstating the case a little (and I have 2 6502 machines at home and like the 6502). The major problem with interrupts on the 6502 is that the BRK instruction and IRQ signal both vector through the same location. The only way for the irq handler to tell which it was is to check the B bit in the stacked status register (not the real one). Thus the following code (paraphrased): IRQ: STA $45 PLA AND #BREAK_BIT BEQ IT_WAS_AN_IRQ BREAK: Choosing $45, a location used by the monitor for other things was not, in hindsight, a good idea. At least Apple improved things with the enhanced //e, //c and later machines. -- David Wilson Dept Comp Sci, Uni of Wollongong david@cs.uow.edu.au