akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) (04/20/91)
HP48SX users, has anyone fiddled with interrupts on the HP48SX? I would be very interested in being able to have interrupt-driven subroutines remaining "memory resident" (such as a sprite animation program). This could facilitate GEM-type interfaces, an entire sprite animation library (unattended graphics animation), picture overlays, etc. I'd be very interested....10Q. Scott.
herman@corpane.uucp (Harry Herman) (04/23/91)
In <28106e62:2851comp.sys.handhelds@hpcvbbs.UUCP> akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) writes: >HP48SX users, has anyone fiddled with interrupts on the HP48SX? >I would be very interested in being able to have interrupt-driven >subroutines remaining "memory resident" (such as a sprite animation >program). This could facilitate GEM-type interfaces, an entire sprite >animation library (unattended graphics animation), picture overlays, etc. >I'd be very interested....10Q. Scott. Are you sure you can do this? I thought all objects in HP48 memory were subject to being shifted to new addresses whenever garbage collection occured. If you wrote something like this, how would you know where your memory resident routine was located when the interrupt came in. Harry Herman herman@ukma!corpane
cloos@acsu.buffalo.edu (James H. Cloos) (04/24/91)
In article <1991Apr23.115645.9250@corpane.uucp> herman@corpane.uucp (Harry Herman) writes: >In <28106e62:2851comp.sys.handhelds@hpcvbbs.UUCP> akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) writes: > >>HP48SX users, has anyone fiddled with interrupts on the HP48SX? >>I would be very interested in being able to have interrupt-driven >>subroutines remaining "memory resident" (such as a sprite animation >>program). This could facilitate GEM-type interfaces, an entire sprite >>animation library (unattended graphics animation), picture overlays, etc. >>I'd be very interested....10Q. Scott. > >Are you sure you can do this? I thought all objects in HP48 memory were >subject to being shifted to new addresses whenever garbage collection >occured. If you wrote something like this, how would you know where your >memory resident routine was located when the interrupt came in. > One way this could be done would be to have the interupt call an XLIB. There must be a ML-level routine that can be used to call an xlib (my symbols files are currently off-loaded so that I can use our quota fressende ada compiler). (Sorry for the foreign word, but 'eating' just doesn't cut it here.) Oh for a SPARC of mine very own..... -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>
bson@rice-chex.ai.mit.edu (Jan Brittenson) (04/24/91)
In a posting of [23 Apr 91 11:56:45 GMT] herman@corpane.uucp (Harry Herman) writes: > In <28106e62:2851comp.sys.handhelds@hpcvbbs.UUCP> akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) writes: >> I would be very interested in being able to have interrupt-driven >> subroutines > Are you sure you can do this? I thought all objects in HP48 memory > were subject to being shifted to new addresses whenever garbage > collection occured. Actually, allocating memory that's not reclaimable by GC is not difficult. A program can allocate such a chunk of memory and copy itself into it, and when it decides it's time to terminate, it can copy itself back to reclaimable space and finish off by deallocating the non-reclaimable space. The stack-menu-PICT GROBs are examples of objects not in the reclaimable space, which can be thought of as an extension of the static system data. It resides between the system variables in low memory and the dynamic memory where commonly allocated object types (numbers, strings, arrays, lists, etc) go. (Other object types, such as programs and directories, which are much less commonly allocated, appear to go at the top of memory, above the stack, with the HOME directory at the absolute top.) The part appearing less trivial is that of intercepting interrupts. They all seem to vector to location #0000F, regardless of origin, which determined in software by the interrupt handler. It doesn't vector via RAM, so unless there is a vector somewhere in the I/O page, I doubt interrupt-driven programs can be written at all on the HP-48. -- Jan Brittenson bson@ai.mit.edu
bson@rice-chex.ai.mit.edu (Jan Brittenson) (04/24/91)
In a posting of [23 Apr 91 20:03:15 GMT] cloos@acsu.buffalo.edu (James H. Cloos) writes: > There must be a ML-level routine that can be used to call an xlib Calling an XLIB is actually quite simple: move pc, a add.a xlib_ref-., a jump @a xlib_ref: data.a #2e92 data.3 700, 1 Will transfer control to XLIB 700 1. -- Jan Brittenson bson@ai.mit.edu
cloos@acsu.buffalo.edu (James H. Cloos) (04/25/91)
In article <15233@life.ai.mit.edu> bson@rice-chex.ai.mit.edu (Jan Brittenson) writes: |In a posting of [23 Apr 91 20:03:15 GMT] | cloos@acsu.buffalo.edu (James H. Cloos) writes: | > There must be a ML-level routine that can be used to call an xlib | |Calling an XLIB is actually quite simple: | | move pc, a | add.a xlib_ref-., a | jump @a |xlib_ref: | data.a #2e92 | data.3 700, 1 | |Will transfer control to XLIB 700 1. | Duh. [SIGH] So, did I epitomise missing the obvious? -JimC