home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / apple2 / 20404 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  2.9 KB
  1. Path: sparky!uunet!sun-barr!ames!data.nas.nasa.gov!taligent!apple!mumbo.apple.com!gallant.apple.com!city-lights.apple.com!user
  2. From: mattd@apple.com (Matt Deatherage)
  3. Newsgroups: comp.sys.apple2
  4. Subject: Accelerator stuff
  5. Message-ID: <mattd-140992122917@city-lights.apple.com>
  6. Date: 14 Sep 92 19:32:32 GMT
  7. References: <1992Sep10.032455.4825@wl.com> <1992Sep13.085028.20950@pro-palmtree.socal.com> <1992Sep13.210815.27707@news.iastate.edu> <1992Sep14.041304.7483@cco.caltech.edu>
  8. Sender: news@gallant.apple.com
  9. Followup-To: comp.sys.apple2
  10. Organization: Developer Technical Support, Apple Computer, Inc.
  11. Lines: 46
  12.  
  13. In article <1992Sep14.041304.7483@cco.caltech.edu>, toddpw@cco.caltech.edu
  14. (Todd P. Whitesel) wrote:
  15. > 
  16. > there is the AppleTalk/IRQ option but I am not sure exactly what
  17. > all that does, whether it uses a timer or if it just disables the accelerator
  18. > anytime interrupts are being processed (bleck).
  19.  
  20. Blech is the incorrect word.
  21.  
  22. The Zip's "timers-only" system means you can't be sure your
  23. timing-sensitive
  24. code works correctly unless you hit a softswitch that triggers a timer in
  25. the code at the appropriate intervals, or unless you explicitly turn off
  26. the Zip.  Either way requires modifying existing timing-sensitive code, and
  27. this was not a good idea.
  28.  
  29. The TWGS's "AppleTalk/IRQ" option slows down to Control Panel speed (2.5 or
  30. 1 MHz) whenever interrupts are disabled.  This has the advantage of making
  31. _all_ timing sensitive code work as advertised, because anyone writing
  32. timing-sensitive code knew they had to disable interrupts already.
  33.  
  34. It might slow down somewhat, but it's a darn sight better than Zip's
  35. "AppleTalk delay" which slows the accelerator down about 30% of the time
  36. (5 ms for every interrupt, incluing the 60 Hz VBL interrupt, which means
  37. a minimum of 300 ms slowdown every second).  It also wouldn't have forced
  38. Apple to waste time rewriting the internal LocalTalk code to be speed
  39. dependent at 1 MHz instead of 2.5 MHz, requiring more patch memory on ROM
  40. 3 and time that could have been spent on more productive things.
  41.  
  42. (And no, ZipTalk alone or the code I wrote that did the same thing and
  43. sent to Zip a long time ago wouldn't have fixed it -- LocalTalk has to
  44. send a "clear to send" packet as soon as it sees a "ready to send"
  45. packet, and that's all done in the interrupt handler without dispatching
  46. to the LAPRead or LAPWrite commands -- and patching out the interrupt
  47. vector to slow down before doing it is not supportable or feasible due
  48. to extreme AppleTalk timing constraints.)
  49.  
  50. > Todd Whitesel
  51. > toddpw @ cco.caltech.edu
  52.  
  53. ============================================================================
  54. Matt Deatherage, Developer Support Center, Apple Computer, Inc.
  55. Personal mail only -- please POST technical questions, questions about
  56. Apple and its policies, where to find documents and related inquiries.
  57. The opinions I express don't represent Apple, which makes us both happy.
  58. ============================================================================
  59.