home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / apple2 / 19586 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!natinst.com!news.dell.com!math.utexas.edu!ut-emx!ccwf.cc.utexas.edu
  2. From: foegelle@ccwf.cc.utexas.edu (Michael Foegelle)
  3. Newsgroups: comp.sys.apple2
  4. Subject: Re: Mockingboard
  5. Message-ID: <78447@ut-emx.uucp>
  6. Date: 26 Aug 92 19:35:57 GMT
  7. References: <9208240216.aa12190@generic.UUCP>
  8. Sender: news@ut-emx.uucp
  9. Organization: The University of Texas at Austin, Austin TX
  10. Lines: 37
  11.  
  12. In article <9208240216.aa12190@generic.UUCP> 
  13.    taob@terranet.cts.com (Brian Tao) writes:
  14. >
  15. >    I'm still a bit fuzzy about why it can't be done reliably.  This
  16. >is how I understand it:  A game which uses the Mockingboard generates
  17. >some sort of interrupt when it wants to make a sound.  The
  18. >Mockingboard intercepts this and somehow processes it to make noise.
  19. >Can't an INIT which watches for interrupts emulate the Mockingboard?
  20. >Is it a question of speed?  i.e.: the CPU isn't fast enough to run the
  21. >game, process interrupts and simulate Mockingboard sound at the same
  22. >time.  Pardon my lack of comprehension... I've never seen (much less
  23. >used) a Mockingboard, and I've been up until 4 am or so for the past
  24. >few nights working on a news reader for microEmacs GS.
  25.  
  26. You've got it backwards.  The program is told that there's a mockingboard
  27. in the system.  It then knows the locations in the slot in which to write
  28. music data to.  It sets up the control data by setting the interrupt vector
  29. to point to a routine somewhere in the heart of the program which will then
  30. handle all interrupt requests from the mockingboard.  Once the mockingboard
  31. is initialized, every time it needs a new note to play, the BOARD creates
  32. an interrupt, which triggers the subroutine in the program to write the next
  33. music bytes into some locations in the I/O region.  There is no way to 
  34. `intercept' those bytes without actually interpretting the code and changing
  35. the addresses to RAM locations somewhere.  Also, randomly poking bytes into
  36. the I/O locations would play havoc with whatever I/O device might actually
  37. reside there.  Hope that makes more sense...
  38.  
  39. Michael Foegelle
  40.  
  41.  
  42. -- 
  43. -------------------------------------------------------------------------------
  44.    Michael Foegelle  |                    |   foegelle@ccwf.cc.utexas.edu
  45.      ____________    |     You want it    |   foegelle@utaphy.ph.utexas.edu
  46.                      |                    |   GEnie:   M.FOEGELLE2
  47.     University of    |        WHEN?       |   Wunderland BBS  (512) 472-0544
  48.    Texas at Austin   |                    |   14.4kbaud, v.32/bis:  Sysop
  49.