home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / apple2 / 20490 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  5.1 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!wupost!sdd.hp.com!elroy.jpl.nasa.gov!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: Re: Accelerator stuff
  5. Message-ID: <mattd-150992165906@city-lights.apple.com>
  6. Date: 16 Sep 92 00:11:24 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> <mattd-140992122917@city-lights.apple.com> <1992Sep15.093106.13133@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: 81
  12.  
  13. In article <1992Sep15.093106.13133@cco.caltech.edu>, toddpw@cco.caltech.edu
  14. (Todd P. Whitesel) wrote:
  15.  
  16. > Matt, you alone are able to take the engineering principle behind something and
  17. > make it sound like it's the fundamental problem with it. AppleTalk and ProTerm
  18. > (and imitation FTA demos, but they don't count) are the only things that really
  19. > had problems [...]
  20.  
  21. I think it was a fundamental problem -- Zip didn't know how long to slow
  22. down for timing-sensitive code, so rather than do so all the time they
  23. chose two "guess" values -- 5 ms and 50 ms.  This is probablistic rather
  24. than deterministic, as the TWGS approach is.  I like deterministic.
  25.  
  26. > Okay, but there is a lot of code that disables interrupts that really ought
  27. > to be accelerated. Ask the GNO folks how much IRQ processing overhead the IIgs
  28. > has and you'll get retching noises for an answer.
  29.  
  30. Yes, but that's just how Jawaid talks.  :)  [see below for a more concrete
  31. discussion of this]
  32.  
  33. > The LocalTalk code should have been 1-mhz based in the FIRST place. Apple
  34. > warns developers not to write code that is timing dependent at 2.5 mhz;
  35. > the least Apple can do is write code that follows its own guidelines. 
  36.  
  37. Let's not bring out that chestnut.  Compatibility guidelines are so
  38. 3rd-party
  39. developers can stay compatible with the system software -- the system
  40. software
  41. itself can (and often does) have to do skanky things to work.  Being
  42. timing-
  43. dependent at 2.5 MHz is not a problem for Apple as long as Apple would
  44. commit to rewriting it if the processor speed changed; 3rd-party developers
  45. can't reasonably make such commitments (business plans change).
  46.  
  47. This is like saying "QuickDraw breaks the rules because it has hard-coded
  48. knowledge of QuickDraw's direct page."  The system software can do as it
  49. pleases in order to function.  Guidelines keep you compatible with it and
  50. it with you, not it with itself.  That's done at another level.
  51.  
  52. > What LAPRead command? $e1/20 does that. ZipTalk intercepts it (VRN #8) with:
  53. >     LDA $E0C0FC    ;slot 7 is set to Normal speed (it can also use 6)
  54. >     JMP $02AEFD    ;typical value, this passes to the original handler
  55. > This adds 9 cycles (1 slow) to the AppleTalk IRQ manager and disables the Zip
  56. > for 50 milliseconds, more than long enough for an entire LLAP packet.
  57.  
  58. Assuming, of course, that you get to $E10020 within 104 microseconds of
  59. when the first byte of the packet was detected by the SCC.  If interrupts
  60. were already disabled when that happened, you have even less time.
  61.  
  62. And Apple's original timing tests in the late 80s showed that there was
  63. room in the interrupt chain to add one, _maybe_ two instructions in this
  64. code path before AppleTalk might lose data, and therefore reject packets.
  65. You've added extra instructions in this chain, and if the system had
  66. interrupts disabled when the packet started arriving, or if it was already
  67. in 1 MHz mode, now you may miss the packet altogether.  This has much
  68. more effect on a crowded network than on a typical "home" network, but
  69. it doesn't work in 100% of the cases and is not supportable.
  70.  
  71. Your method also requires slowing down one slot, which is kind of icky
  72. but not too much so.
  73.  
  74. All LLAP packets dispatched _except_ the previously-mentioned RTS/CTS pair
  75. go through the LAPRead/LAPWrite AppleTalk command vectors as documented
  76. in the Programmer's Guide.  Patching those vectors to fully disable the
  77. Zip at start and reenable it at end avoids all the problems except the
  78. RTS/CTS problem, and it does so _deterministically._  None of this "All
  79. LLAP
  80. packets should take less than 50 ms" -- it disables on start and enables
  81. on finish, no matter how long the interim is.  Your technique would work OK
  82. for the RTS/CTS packets sent from the IRQ.APTALK interrupt handler, save
  83. the problems previously mentioned about making the dispatching code take
  84. too long.  One could reasonably argue that the odds of this being a problem
  85. are small enough in an accelerated system, but it's still going to cause
  86. problems for people with large networks.
  87.  
  88. \============================================================================
  89. Matt Deatherage, Developer Support Center, Apple Computer, Inc.
  90. Personal mail only -- please POST technical questions, questions about
  91. Apple and its policies, where to find documents and related inquiries.
  92. The opinions I express don't represent Apple, which makes us both happy.
  93. ============================================================================
  94.