home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6552 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: AddIntServer + VERTB strangeness
  5. Date: 29 Mar 1996 19:29:50 +0100
  6. Organization: dis-
  7. Message-ID: <4jha6u$a7v@serpens.rhein.de>
  8. References: <199603281321.NAA02157@mailhost.unibol.com>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. John Girvin <jgirvin@bfs.unibol.com> writes:
  12.  
  13. >On 20 Mar 1996 19:27:12 +0100, mlelstv@serpens.rhein.de (Michael van Elst):
  14. >:>No, that's not all. You use the functions in a wrong way.
  15.  
  16. >My code does not care how the interrupt mechanism calls the interrupt code, 
  17. >only that my handler gets called at the correct time and that my handler is 
  18. >the only handler that gets called. Both these features are (allegedly) 
  19. >available as OS features, so I use the OS to get them. Tell me what I am 
  20. >doing wrong and Ill change it!
  21.  
  22. The vblank interrupt is a server interrupt. You are just allowed to
  23. add your own code to the chain (at any position but you should be aware
  24. of a graphics.library bug) and you must not abort the chain.
  25.  
  26. >:>>Do you believe that everything must be either 100% or 0% OS with no middle 
  27. >:>>ground? I dont! 
  28. >:>But obviously it has to be so. 
  29.  
  30. >Why obviously? Whats wrong with using the OS to allocate HW resources you 
  31. >need (exitting nicely if not available) then hitting that hardware directly? 
  32.  
  33. Maybe I was misunderstood. Allocating HW resources and then hitting the
  34. hardware is "using the OS".
  35.  
  36. >If you stick to the published OS and HW interfaces (which I do) then surely 
  37. >there is no problem provided these interfaces dont change?
  38.  
  39. The only problem is that of portability. If you poke the hardware then
  40. people must use this hardware. If you use just OS functions then this
  41. adds an abstraction layer that keeps the software happy even when the
  42. hardware changes.
  43.  
  44. >:>Something in between just causes problems because
  45. >:>you have to rely on the particular behaviour of the implementation or
  46. >:>even of a particular machine configuration. 
  47.  
  48. >What specifics of my kickstart/machine am I relying on by using the OS
  49. >interrupts in this way?
  50.  
  51. Using the interrupts in this way is not allowed and it doesn't work
  52. anyway :)
  53.  
  54. But if it would work you would rely on this instead of the specification
  55. which forbids it.
  56.  
  57. >Im relying only on official interfaces and their
  58. >officially described and officially "guaranteed" official behaviour.
  59.  
  60. Sorry, no :-/
  61.  
  62. >:>That's why the only
  63. >:>acceptable solution is to obey to the rules set by the OS specification.
  64.  
  65. >Im trying to.
  66.  
  67. I see this. I'm not flaming you but you simply made a mistake.
  68.  
  69. >The original question was about the OS specification saying 
  70. >one thing ([re?]set Z after interrupt handler code to disable others in 
  71. >chain) and then behaving in another way.
  72.  
  73. The OS specification says that you must not abort the chain with your
  74. handler. This is special for VERTB, it is allowed for PORTS and EXTER.
  75.  
  76. Regards,
  77. -- 
  78.                                 Michael van Elst
  79.  
  80. Internet: mlelstv@serpens.rhein.de
  81.                                 "A potential Snark may lurk in every tree."
  82.