Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!lll-crg!lll-lcc!well!ptsfa!ski!dr From: dr@ski.UUCP (David Robins) Newsgroups: net.micro.apple Subject: Re: Apple //e Interrupts Message-ID: <283@ski.UUCP> Date: Tue, 8-Jul-86 18:58:17 EDT Article-I.D.: ski.283 Posted: Tue Jul 8 18:58:17 1986 Date-Received: Thu, 10-Jul-86 05:00:12 EDT Reply-To: dr@ski.UUCP (David Robins) Organization: Smith-Kettlewell Institute, S.F., CA. Lines: 109 >Subject: Apple 2E/enhanced monitor rom >Keywords: interrupt response time > > I just got in an Apple 2E/enhanced computer that is >replacing an older vanilla Apple 2E in an lab application that we >are running. The application uses an ADC driven by interrupts to >look at a process every 100 cpu clocks. > > Everything was fine when we used regular Apple 2s and 2Es. >Now our application bombs, as the monitor ROM (under DOS 3.3) seems >to do something that regularly shuts off interrupts for 250-300 uS. > > For my application, I don't give a hoot about the mouse >support. What I was wondering, does anybody know if I can >de-enhance my computer by putting old ROMs in it? Anybody happen >to know if the EF and CD ROMs can be replaced with 2764s? It would >save us a lot of time to burn our own. The original enhancement kit had an available "About Your Enhanced Apple //e: Programmer's Guide", Apple Product number A2L2072, which was available FREE! The same information is in the new Apple //e Technical Reference Manual, published by Addison-Wesley, and available at some bookstores. (The older //e reference manual covered the old //e.) On pages 24-25 of the Programmer's Guide, and/or pages 154-155 on the new tech manual, the interrupt handler is discussed. "Once the built-in interrupt handler is called, it takes at least 150-200 microseconds for it to call your interrupt handling routine. After your routine returns, it takes 40 to 140 microseconds fto restore memory and return to the interrupted program." "If memory is in the standard state when the interrupt occurs, the total overhead for interrupt processing is about 150 muicroseconds less than if memeory is the worst state. (The sorst state is one that requires the most work to set up for: 80STORE and PAGE2 on; auxiliary memory switched in for reading and writing; bank-switched memory page 2 in the auxiliary bank switched in for reading and writing; and internal $Cn00 ROM switched in)." "Interrupt overhead will be greater if your interrupt handler is installed through an operating system's interrupt dispatcher." ie. the ProDOS MLI interrupt handler. Therefore, if your time requirements need the faster handling as on the old //e, which jumped right to your routine after a few instructions, then you can "unenhance" the new //e by using the older CD and EF ROMs. Yes, they can be copied onto 2764 EPROMs with a copier. (see Jim Sather's book "Understanding the Apple //e"). Don Lancaster, in "Enhancing Your Apple II and //e, Volume 2", recommends the 2764n EPROM, which he says MUST be an INTEL or HITACHI brand with 28 pins and an access time of 250 nanoseconds or less. The old interrupt handling on the old //e was somewhat troublesome, because it sometimes interfered with DOS 3.3. The handler saved the accumulator in $45, which is used by DOS as a scratchpad location during disk accesses and possibly other functions. There was the probability of clobbering DOS with your interrupts. The new handler doesn't do it the same way. If you're going to the trouble to burn your own CD and EF ROMs, why not also add the correction to the handler as advocated by Morgan Caffrey, and published in several places, as well as used inthe old Roger Wagner Double-Time interrupt driven printer routine. From Apple Orchard, March, 1983, Interrupts and the //e: old //e code improved code FA40 STA $45 FA40 JMP ($03FE) FA42 PLA FA43 STA $45 FA43 PHA FA45 PLA FA44 ASL FA46 PHA FA45 ASL FA47 ASL FA46 ASL FA48 ASL FA47 BMI $FA4C FA49 ASL FA49 JMP ($03FE) FA4A BPL $FA5F FA4C PLP You also have to make the DOS interrupt vector at $3FE point to $FA43 rather than $FA40. (DOS patch with sector editor is track 0, sector $0D, bytes $7F and $80, changed from $65,FF to $43,FA.) (In memory, using virgin DOS 3.3, the locations are $9E7F,9E80 changed from $65,FF to $43,FA, and then INIT a blank disk.) I highly recommend the Roger Wagner Publication called the Interrupt Experimenter's Kit. For about $35 (??) or so, you get a manual about interrupts, a disk full of demo programs and assembler subroutines, and a hardware card whic is a 200 interrupts/seconds generator. Finally, the Applied Engineering Timemaster H.O. clock comes with a disk than had a DOS intrrupt patch. This replaces every reference in DOS that uses $45, to some other value so DOS doesn't bomb. -- ==================================================================== David Robins, M.D. Smith-Kettlewell Eye Research Foundation (previously known as: Smith-Kettlewell Institute of Visual Sciences) 2232 Webster St; San Francisco CA 94115 415/561-1705 (voice) {ihnp4,qantel,dual}!ptsfa!ski!dr The opinions expressed herein do not reflect the opinion of the Institute! Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!mcnc!ecsvax!ranger From: ranlil@ecsvax.UUCP (Rick N. Fincher) Newsgroups: net.micro.apple Subject: Re: Apple 2E/enhanced monitor rom Message-ID: <1786@ecsvax.UUCP> Date: Mon, 7-Jul-86 09:21:15 EDT Article-I.D.: ecsvax.1786 Posted: Mon Jul 7 09:21:15 1986 Date-Received: Tue, 8-Jul-86 07:26:48 EDT References: <222@neoucom.UUCP> Organization: UNC Educational Computing Service Lines: 41 > Everything was fine when we used regular Apple 2s and 2Es. > Now our application bombs, as the monitor ROM (under DOS 3.3) seems > to do something that regularly shuts off interrupts for 250-300 uS. > > support. What I was wondering, does anybody know if I can > de-enhance my computer by putting old ROMs in it? Anybody happen > to know if the EF and CD ROMs can be replaced with 2764s? It would > save us a lot of time to burn our own. > This is an odd problem since the manual for the new ROMs claims that the new monitor does not disable interrupts for an extended period. The old ROMs would disable interrupts for extended periods while 80 col screen updating was going on because the old ROMs couldn't tolerate interrupts except in main memory. The new Roms support interrupts in Aux memory by saving the memory state in effect when the interrupt occurred and setting the machine to a known state before going to the interrupt handling routine. This shouldn't take anywhere near 250-300 usecs though. With the new ROMs the accumulator is no longer saved in location $45, it is put on the stack instead. This location is used by DOS 3.3 and the monitor so storing the accumulator here trashed things. Your application probably uses a modified version of DOS to avoid this proble problem. If your application is looking for the contents of the accumulator at $45 it will not work with the new ROMs. You should have gotten the manual "About your enhanced Apple IIe: Programmers Guide" when you upgraded, if not see you dealer for a copy. It will help you modify your code to work with the new interrupt handler. If you are using commercial software call the manufacturer and see if they have a new version. If you really want the old ROMs back, see Don Lancaster's column "Ask the Guru" in Computer Shopper. From about January to May of this year he had a series of articles on installing both sets of ROMs in your IIe and switching between them. He had detailed in- structions on burning ROMs for the Apple. (Sorry I can't be more precise on the dates of those articles, but you can call Don for help, his number is in his column). Rick Fincher Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!husc6!harvard!panda!genrad!decvax!decwrl!pyramid!hplabs!tektronix!uw-beaver!ssc-vax!uvicctr!collinge From: collinge@uvicctr.UUCP Newsgroups: net.micro.apple Subject: Re: Apple //e Interrupts Message-ID: <175@uvicctr.UUCP> Date: Thu, 10-Jul-86 16:07:59 EDT Article-I.D.: uvicctr.175 Posted: Thu Jul 10 16:07:59 1986 Date-Received: Mon, 14-Jul-86 01:41:29 EDT References: <283@ski.UUCP> Reply-To: collinge@uvicctr.UUCP (Doug Collinge) Organization: University of Victoria, Victoria B.C. Canada Lines: 27 >> I just got in an Apple 2E/enhanced computer that is >>replacing an older vanilla Apple 2E in an lab application that we >>are running. The application uses an ADC driven by interrupts to >>look at a process every 100 cpu clocks. >> > "Once the built-in interrupt handler is called, it takes at > least 150-200 microseconds for it to call your interrupt > handling routine. After your routine returns, it takes 40 to > 140 microseconds fto restore memory and return to the > interrupted program." > Yes! 350 us to take an interrupt! Honestly - why bother having them at all? I know people doing MIDI who have been bitten by this. You have to read the code to believe it - it is absolutely unbearable. Of course, there is nothing stopping you from using the language ram and subverting the e2e IRQ handler by jamming in your own hardware vector. -- Doug Collinge School of Music, University of Victoria, PO Box 1700, Victoria, B.C., Canada, V8W 2Y2 decvax!nrl-css!uvicctr!collinge decvax!uw-beaver!uvicctr!collinge ubc-vision!uvicctr!collinge Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: net.micro.apple Subject: Re: Apple //e Interrupts Message-ID: <2245@brl-smoke.ARPA> Date: Tue, 15-Jul-86 09:31:03 EDT Article-I.D.: brl-smok.2245 Posted: Tue Jul 15 09:31:03 1986 Date-Received: Wed, 16-Jul-86 03:23:08 EDT References: <283@ski.UUCP> <175@uvicctr.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 10 I haven't seen mention of this, but interrupts during disk I/O can corrupt your disk. ProDOS supports interrupts but they're inhibited during critical timing loops. If you need interrupts but not disk I/O, nor other timing-critical peripheral-card I/O, then you can certainly plant your own interrupt handler and avoid ProDOS's altogether. I have to agree that the Apple ][ family is really not designed for real-time, multitasking use. There's no reason it shouldn't have been, except they didn't think of it in the first place. Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!neoucom!wtm From: wtm@neoucom.UUCP (Bill Mayhew) Newsgroups: net.micro.apple Subject: Re: Apple //e Interrupts Message-ID: <239@neoucom.UUCP> Date: Fri, 1-Aug-86 20:17:08 EDT Article-I.D.: neoucom.239 Posted: Fri Aug 1 20:17:08 1986 Date-Received: Sat, 2-Aug-86 10:42:20 EDT References: <283@ski.UUCP> <175@uvicctr.UUCP> <2245@brl-smoke.ARPA> <943@rti-sel.UUCP> Organization: Northeastern Ohio Universities College of Medicine Lines: 35 Summary: The disk drive motor True, it would have been very convenient to make the keyboard strobe generate interrupts as an option-- that is something I never understood, as it wouldn't have really cost much to implement. I've always been impressed at how much it is possible to eake out of an Apple II+. The Apple is still one of my favorite machines to work with. As far as interrupts and DOS 3.x go. DOS routines always perform a SEI instruction before entering time-critical sections. The problem crops up because some parts of the ROM code use $45 as a scratch pad, and so does the BRK/IRQ detection code at $FA40, thus an interrupt arriving at just the wrong moment can cause deviant behavior. I got around that by burning a ROM that had a different IRQ vector at $FFFE. I wouldn't recommend changing one's ROM unless absolutely necessary. ProDOS has fixed the problems of sloppy interrupt handling, the only problem is the delay-- oh well. I always wished I could meet Woz and ask him why the Apple II avoids all use of the interrupts internally-- I suppose that he'd remark so as to provide 100% flexibility for peripherals to use them. By the way, a little addenda to the previous article... I don't really think that the apple diskette can be spun backwards, if inserted nomally, in an unmodified Apple drive. The spindle motor is driven directly from the 12 volt supply, and has no means for polarity reversal or speed control-- otherwise, quite correct. Bill NEOUCOM Rootstown, Ohio wtm@neoucom (...!allegra!neoucom!wtm)