home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / atari / st / tech / 5674 < prev    next >
Encoding:
Text File  |  1992-11-17  |  1.4 KB  |  40 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!mcsun!sun4nl!sci.kun.nl!sanders
  3. From: sanders@sci.kun.nl (Sander Stoks)
  4. Subject: Re: getmpb
  5. Message-ID: <BxuynL.81K@sci.kun.nl>
  6. Sender: news@sci.kun.nl (NUnet News Owner)
  7. Organization: University of Nijmegen, The Netherlands
  8. References: <b010d0aa@Kralizec.fido.zeta.org.au>
  9. Date: Tue, 17 Nov 1992 11:30:56 GMT
  10. Lines: 28
  11.  
  12.  
  13. In a message of <02 Nov 92 18:12:40>, pcxkrm@unicorn.nott.ac.uk (3:713/602)
  14. writes:
  15.  
  16. p> Hi,
  17.  
  18. p> As a person who has spent the last ten years programming almost solely
  19. p> in BASIC, the ins and outs of memory management are fairly new to me.
  20. p> I'm currently trying to write a program which needs to know where it is
  21. p> in memory. My GEMDOS information tells me that the 'C' call getmpb
  22. p> should do this - but it seems to return only the top of system memory or
  23. p> something - it gives the same thing every time with no pointer to a
  24.    second
  25. p> block.
  26. p> Am I being very thick or is there some other way to find out my
  27. p> program's basepage? I'm running an STe with 2Mb of memory and TOS 1.62.
  28.  
  29. p> Keith.
  30.  
  31. What language are you programming in? BASIC? (Guess not, since I can't
  32. imagine a BASIC program which needs to know its memory location) If
  33. yes, which version? I know there is a variable BASEPAGE in GfA, which
  34. points to the basepage of the currently running program (only useful
  35. for compiled programs of course, otherwise it would point to the
  36. interpreter.)
  37.  
  38. Sander SToks
  39. sanders@sci.kun.nl
  40.