home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18620 < prev    next >
Encoding:
Text File  |  1993-01-01  |  1.9 KB  |  46 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!gatech!destroyer!ais.org!empath
  3. From: empath@ais.org (Tim Triemstra)
  4. Subject: Re: 32bit Zortech Pointers
  5. Message-ID: <C06441.8oI@ais.org>
  6. Organization: UMCC
  7. References: <C03usF.8CA@ais.org> <1992Dec31.203531.1158@proto.com>
  8. Date: Fri, 1 Jan 1993 09:09:32 GMT
  9. Lines: 35
  10.  
  11. > I don't understand what INT calls you converted...  One thing to be
  12. > careful of is that if you are trying to pass data to a real mode
  13. > TSR of some sort,  then you need to put the data in a real mode
  14. > buffer... could this be part of your problem?
  15.  
  16. Sorry about the not-so-clear wording on the INT calls, I meant INTeger
  17. calls.  I'm not dealing with any real mode TSRs, or even any external code
  18. to speak of.  The entire program encapsulates only 2 small files that could
  19. easily just be one.
  20.  
  21. The code goes something like this:
  22.  
  23. unsigned char *buffer;
  24. //malloc the buffer I believe
  25. InitVoice(buffer);
  26.  
  27. My pointer logic is real bad at 4am but that is the gist of it.  In the
  28. 32bit mode, I get static - but the proper amount of static which mean that
  29. the interrupt is being called and killed correctly, but not given the proper
  30. data - hence the concept of improper pointer holding in 32bit modes with
  31. interrupts.  I'm going to do alot more combing through the code to make SURE
  32. that there isn't any 4byte integer calls where on 2 bytes are expected, but
  33. I've done days of that and I'm pretty sure that is safe.  I was just curious
  34. if you had to protect pointers that were to be handled by both interrupt
  35. and non-interrupt code.  I have alot of 6510 ASM experience with interrupts
  36. but the knowledge of interrupts ends at a theoretical level with 80xxx 
  37. processors.
  38.  
  39. Thanks again guys.  Joe - I sent this code a while back UUENCODED to
  40. you att proto com, so if this interests you and you would "like" to get
  41. it working go fer it.  It's just gonna be GNU distrubuted when done anyhow.
  42.  
  43. Tim
  44. Empath@Ais.Org
  45.  
  46.