k36853p@saha.hut.fi (Tapani Otala) (10/07/90)
Anybody know the reason why this piece of code does not work properly:
<< PICT RCL @ save current PICT contents to stack
{ #0 #0 } PVIEW @ display PICT
.
.
.
PICT STO @ restore old PICT contents from stack
>>
By 'not properly' I mean the garbage that fills the screen when HP
executes the 'PICT STO' stuff. Looks to me like it (temporarily)
screws up the LCD display controller, i.e. makes it show incorrect area
of memory. BTW, the garbage changes form, or the starting location
of it changes; anyway, sort of like looking at a continuous hex dump
of 0040:0000 of a PC...)
If this method of saving/restoring the PICT contents is incorrect,
better ideas anybody? (sure, PICT { #0 #0 } ROT REPL instead of PICT STO
restores it without the garbled display, but... its not that elegant)
What really bugs me is that the PIE demo program (pages 592-597 of
the Owner's Manual II) seems to use a similar trick, only without
the crap on screen.
-- k36853p@saha.hut.fi ! Clothes make the man. Naked people have little
-- tpo@otax.tky.hut.fi ! or no influence on society. -- Mark Twain
-- Tapani_'TpO'_Otala ! akcs.dnickel@hpcvbbs.UUCP (Derek Scott Nickel) (10/08/90)
The REPL command is the one to choose. My guess is that STO does not
freeze the display when updating. Whatever the case REPL isn't that bad.
Derek S. Nickelrrd@hpfcso.HP.COM (Ray Depew) (10/08/90)
> Anybody know the reason why this piece of code does not work properly: << PICT RCL @ save current PICT contents to stack { #0 #0 } PVIEW @ display PICT . . . PICT STO @ restore old PICT contents from stack >> > By 'not properly' I mean the garbage that fills the screen when HP > executes the 'PICT STO' stuff. Looks to me like it (temporarily) > screws up the LCD display controller, i.e. makes it show incorrect area > of memory. BTW, the garbage changes form, or the starting location > of it changes; anyway, sort of like looking at a continuous hex dump > of 0040:0000 of a PC...) > If this method of saving/restoring the PICT contents is incorrect, > better ideas anybody? (sure, PICT { #0 #0 } ROT REPL instead of PICT STO > restores it without the garbled display, but... its not that elegant) What's happening (according to the person who wrote that section of code) is the following: { #0 #0 } PVIEW sets the display pointer to a certain area in memory. PICT STO resizes PICT to 0 x 0, checks the size of the grob in Level 1, resizes PICT to the dimensions of that grob, then writes the grob contents to the PICT memory location. ... and all the time, the display pointer never moves. So you get to watch the 48 fiddle its bits as it performs all the internal stuff necessary to update the display. There are several workarounds that HP could have used: 1) Blank out the display during operations that currently throw garbage on the screen (PICT STO is only one example). Too slow. 2) Write 0's to the area of memory indicated by the display pointer. Way too slow. 3) Have 2 separate PICT locations. Whenever you change PICT, the 48 changes the "hidden" PICT, then switches PICTs by changing the display pointer. Memory hungry. This is how some PC's get their nice, flicker-free graphics, but the 48 is somewhat constrained by memory. My own workaround is kind of a variation on option (3) above. I know PICT can be made much larger than the actual display, but since the user will only see 64 x 131 pixels at a time, I do all my graphics manipulation in a separate, "hidden" grob, and then do a SUB ... REPL to view the pieces I'm interested in. Looking again at your sample program, though, it appears that you only want to save PICT to protect it from being overwritten while you run another graphics program. Hmm. If PICT is larger than 64 x 131, you're still stuck with the garbage-screen for a split second. > What really bugs me is that the PIE demo program (pages 592-597 of > the Owner's Manual II) seems to use a similar trick, only without > the crap on screen. I know. Don't you hate it when they do that? ---------- Regards Ray Depew HP Colorado IC Division rrd@hpfitst1.hp.com Disclaimer: I don't make 'em, I only use 'em. Same as you.