dr@ski.UUCP (David Robins) (07/09/86)
>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!
collinge@uvicctr.UUCP (07/10/86)
>> 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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/15/86)
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.
medin@noscvax.UUCP (07/17/86)
Well so the enhanced //e doesnt save the a reg in $45 for the interupt routine. That may be why the 80 col display has been driving kermit (and me) wild. So how do you determine that you are using the enhanced //e ????? Thanks in advance Ted milnet address "medin@nosc"
greg@utcsri.UUCP (Gregory Smith) (07/28/86)
In article <2245@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >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 > >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. Oh yeah? Any idea how much cost was saved ( way back when ) by making the CPU work its tail off in disk I/O, rather than using an LSI disk controller chip ? ( Not to mention trimming everything from the drive, e.g door switch, index hole sensor, track zero sensor. TUKATUKATUKATUKATUKATUKA!!) -- "You'll need more than a Tylenol if you don't tell me where my father is!" - The Ice Pirates ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
jb@rti-sel.UUCP (Jeff Bartlett) (07/30/86)
> In article <2245@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >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 > > > >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. > > Oh yeah? Any idea how much cost was saved ( way back when ) by making the > CPU work its tail off in disk I/O, rather than using an LSI disk controller > chip ? ( Not to mention trimming everything from the drive, e.g door switch, > index hole sensor, track zero sensor. TUKATUKATUKATUKATUKATUKA!!) > > Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg An Apple ][ with software disk control will beat a Radio Shack model II (w/controller) hands down in disk performance. * Faster track to track seek time. * Higher density. * Fast transfer times. Also you can operate the disk spinning backward, or lay down spiral sectors. Maybe they should include a 2nd CPU on-board to process IO. (My grip is: "why didn't they tie the parallel keyboard input into the interupts", 'Can you say "POLL" boys and girls?, I thought you could.' ) Jeff Bartlett mcnc!rti-sel!jb Center for Digital Systems Research Research Triangle Institute
wtm@neoucom.UUCP (Bill Mayhew) (08/02/86)
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)
greg@utcsri.UUCP (Gregory Smith) (08/04/86)
In article <943@rti-sel.UUCP> jb@rti-sel.UUCP (Jeff Bartlett) writes: >> >I haven't seen mention of this, but interrupts during disk I/O >> >can corrupt your disk. >> > >> >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. > >> Oh yeah? Any idea how much cost was saved ( way back when ) by making the >> CPU work its tail off in disk I/O, rather than using an LSI disk controller >> chip ? ( Not to mention trimming everything from the drive, e.g door switch, >> index hole sensor, track zero sensor. TUKATUKATUKATUKATUKATUKA!!) >> >> Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg > >An Apple ][ with software disk control will beat a > Radio Shack model II (w/controller) hands down in disk performance. My brother recently purchased a //c ( which is why I am reading this grp ) and I am impressed at the speed of the disk. But I imagine your comparison is more of a reflection on the Radio Shack... I have an EPSON QX-10 ( "A WHAT??" I hear you say...) with controller and DMA. With one of the operating systems, a BIOS call to write the disk will return immediately and perform the write in the background, even if the drive needs spinning up first. The point is that the Apple implementation makes it impossible to handle interrupts ( or anything else ) during disk i/o. > > * Faster track to track seek time. > * Higher density. > * Fast transfer times. Yes, and the latter two are impressive, given the software support required. > >Also you can operate the disk spinning backward, or lay down spiral sectors. Can you operate the disk spinning backwards? Do Tell. As for spiral sectors, the inability of hardware to do such nasties protects users from horrible copy-protection schemes. This applies to half-tracking, as well. > >Maybe they should include a 2nd CPU on-board to process IO. > >(My grip is: > "why didn't they tie the parallel keyboard input into the interupts", >'Can you say "POLL" boys and girls?, I thought you could.' ) Yes. Can you say "No typeahead without the software doing handstands?" Even a keyboard interrupt would not allow typeahead during disk i/o without a 'real' disk controller. The problem with all this, is that any mods to the Apple II line must be compatible with all previous software. 90% of the value of an Apple is due to this software base. If this were not the case, the //e would have been VERY different. They would have used a CRT controller chip to straighten out the screen addressing, e.g., and they might even have switched to a decent processer. Don't get me wrong, the original design of the Apple ][ gave excellent performance for the price at the time ( sure beat the PET ). But the momentum of compatibility has caused much grief as the machine has outlived its design. Of course 96% of users will never know or care about this, but dyed-in-the-wool bit-hackers like me will... What bothers me is that even the Apple //c goes 'TUKATUKATUKATUKA' when aligning its head. If the processor sent 'step in' and 'step out' pulses to the hardware, it would be a simple matter to add a track-0 sensor and disable the step-out signal when it sensed track-0. It seems (?) that the CPU directly controls the stepper-motor coil signals though, so this annoying noise cannot be easily eliminated without modifying the CPU's view of the controller, which would break software that bypasses DOS and would thus be Impossible. I believe Apple would have loved to eliminate this if it were possible to do it at reasonable cost. -- "You'll need more than a Tylenol if you don't tell me where my father is!" - The Ice Pirates ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
wtm@neoucom.UUCP (Bill Mayhew) (08/10/86)
[Watt's my line...] Hi, The Brrrrraaattt! that apple disk drives make has to be one of the worst sounds on earth! Of course, other than at start up, that noise is usually indicitive that major loss of data eith just has or is about to happen. About 6 mo. ago, I bought some cheep-o 1/2 height disk drives from JDR. I think they're called "BAL 500". The drives are built around a Teac mechanism that that has track zero sensors and various other goodies. One neat feature is that when the drive reaches track zero, the internal LED sensor cuts off any further stepping. No more Brrrrraaattt! The other neat feature these drives have is the write-protect LED sends its pulse to a differentiator and one-shot that turns the spindle motor on for a few seconds. When disks are inserted, they turn on the motor briefly to assist in alignment of the diskette-- very nice touch! I really appreciate this, since media positioning is easy to botch on the newer "duodisk"; I really miss the old Shugarts! Another nifty device is the "BAL" drive controller. At boot time the controller examines for either DOS 3.3 format or 3.2 format and switches in the appropriate control and decoder ROMs. It uses a latch that can not be accessed from the CPU to do the setting of the ROM, thus the controller functions well even with copy-proof software. We like this, as we still have a lot of old software floating around, and this eliminates the need for the "boot13" diskette. Bill Mayhew Division of Basic Medical Sciences Northeastern Ohio Universities' College of Medicine Rootstown, OH 44272 USA (216) 325-2511 (wtm@neoucom.UUCP)
hsu@eneevax.UUCP (Dave Hsu) (08/14/86)
In article <250@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > The Brrrrraaattt! that apple disk drives make has to be one of >the worst sounds on earth! Of course, other than at start up, that >noise is usually indicitive that major loss of data eith just has >or is about to happen. Better than the Pbbbbbbbt! sound that (what was it, Locksmith 5.0?) makes when you hit reset and it magically locks your head into some unfriendly position :-) >I really appreciate this, since media positioning is easy to botch >on the newer "duodisk"; I really miss the old Shugarts! I have other grips about the duodisk units, largely because of their unfriendliness towards half- and quarter- stepping, but also because upside-down disks (like Wizardry, for instance) tend to get stuck on the inside of the drive. I never did trust spring-eject mechanisms anyway. See what happens when you take a design cue from the Commodore 64? >Another nifty device is the "BAL" drive controller. At boot time Good idea! >Bill Mayhew -dave -- David Hsu (301) 454-1433 || -8798 || -8715 "I know no-thing!" -eneevax Communications & Signal Processing Laboratory / EE Systems Staff Systems Research Center, Bldg 093 / Engineering Computer Facility The University of Maryland -~- College Park, MD 20742 ARPA: hsu@eneevax.umd.edu UUCP: [seismo,allegra,rlgvax]!umcp-cs!eneevax!hsu "Evil...pure and simple!"