home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / hp48 / 5608 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.4 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!modus!gear!cflav!flavio
  2. From: flavio@cflav.sublink.org (Flavio Casetta)
  3. Newsgroups: comp.sys.hp48
  4. Subject: Re: external data objects (library data)
  5. Message-ID: <y6RRTB4w164w@cflav.sublink.org>
  6. Date: 5 Nov 92 12:16:21 GMT
  7. References: <2aed7fc7.2013comp.sys.hp48@hpcvbbs.cv.hp.com>
  8. Organization: Flavio Casetta, Reg'd HP ISV & OEM of handheld computers.
  9. Lines: 44
  10.  
  11. akcs.levenson@hpcvbbs.cv.hp.com (william j. levenson) writes:
  12.  
  13. > I have some questions regarding the object types listed in RPLMAN as
  14. > "external object1", "external object2", "external object3", "external
  15. > object4", and "library data".  It seems that these objects, which are
  16. > declared as data objects in RPLMAN, can be used as definable object types
  17. > for use in applications (definable in that the body of the object is not
  18. > defined as is the case with other data objects (e.g. real objects).  If
  19. > this is so, does anyone know what "rules" must be observed when using
  20. > such objects?  What defines the length of these objects, a length field
  21. > or as SEMI at the end?  I imagine some standard of defining the length of
  22. > these objects must be used to let the garbage collection process know how
  23. > much memory is taken up by a given object.
  24. > 
  25.  
  26. How the new object type should behave is left up to the routine called by
  27. the prolog.
  28.  
  29. The main disvantge I see in using new object types is that the prolog of
  30. this object must reside at a fixed address above 70000 which is almost
  31. impossible to do safely.
  32.  
  33. You could define the new object type on a ROM card which must always reside
  34. at a fixed starting address. But when you remove the card ? you may
  35. loose everything in your HP48.
  36.  
  37. Moreover the decompiler seems to be not designed to pass his task to
  38. an external routine, hence you cannot see what the new object type contains
  39. unless you explicitly look inside it by means of a specific routine called
  40. at will.
  41.  
  42. As a last comment, after two years I still cannot understand why HP 
  43. wrote External1 = 28, External2 = 29 and so on, taking into account that 
  44. the function TYPE cannot return numbers above 27.
  45.  
  46. Bye,
  47.  
  48. Flavio
  49.  
  50. __
  51. * flavio@cflav.sublink.org (Flavio Casetta)
  52.  ---------------------------------------------------------------------
  53. | The usual disclaimer does not apply      |   +59 440404 (Vox populi) |
  54. | ForCALC's opinions are necessarily mine  |   +59 304490 (Fax dei)    |
  55.