Threaded Mode | Linear Mode

Vtile · (This post was last modified: 02-12-2016 01:13 PM by Vtile.)

Like title says. Question is the "busy bug" troubling every single machine (ROM215) or do I have a monday piece what comes to hardware? Would be nice to know, before I file a Quarantee claim of vanishing serial number.

toml_12953 · 02-12-2016, 01:21 PM

(02-12-2016 12:50 PM)Vtile Wrote: Like title says. Question is the "busy bug" troubling every single machine (ROM215) or do I have a monday piece what comes to hardware? Would be nice to know, before I file a Quarantee claim of vanishing serial number.

I searched for "busy bug" but didn't find anything. What is this bug?

Tom L

Vtile · 02-12-2016, 01:29 PM

(02-12-2016 01:21 PM)toml_12953 Wrote:
(02-12-2016 12:50 PM)Vtile Wrote: Like title says. Question is the "busy bug" troubling every single machine (ROM215) or do I have a monday piece what comes to hardware? Would be nice to know, before I file a Quarantee claim of vanishing serial number.

I searched for "busy bug" but didn't find anything. What is this bug?

Tom L

Somesort of keypress registering lag error causing random double inputs through whole calculator and random long lags in simple mathematics like division etc. much annoying.

damaltor · 02-12-2016, 02:02 PM

neber had that problem, and never heard of that problem. Is there a way to reproduce? if not, i would recommend to RMA the units...

Vtile · (This post was last modified: 02-12-2016 02:41 PM by Vtile.)

(02-12-2016 02:02 PM)damaltor Wrote: neber had that problem, and never heard of that problem. Is there a way to reproduce? if not, i would recommend to RMA the units...

Maybe I'm just too fast for calculator, with my two finger technique. :-P That rubberbanding, hanging drives me nuts, and its random even worse. Atleast I know it is not a failing HW .. hopefully. I think I kind of start to get what is going on here, two or three things mixing together that looks like a one biiiiiig bug, interesting. Unfortunately my function generator is so long away and this piece is hard to open. It seems that with the "Busy Bug" there is also a keyboard oscillation problem, which together looks like the "Busy Bug" would be making double presses also in the stack view, interesting. One input for keydown and one "key up" if pressed certain lazy way. Need more work.

Simone Cerica · 02-12-2016, 02:45 PM

in this discussion is explained the "busy bug":

50G "speed bumps" again
https://groups.google.com/d/topic/comp.s...discussion

John H Meyers

Quote:If the delayed keystroke registers when the *next* key is pressed,
then it's the "busy bug," as may previously have been mentioned;
I've seen no fix ever reported for that bug, which is highly likely
to reside in manufacturer Kinpo's ARM OS (the emulator and
hardware layer), rather than in the HP OS (which runs
on the emulator that hides within).

Joe Horn

Quote:You're experiencing the Busy Bug, which happens whenever a key is
pressed at exactly the same moment that the busy annunciator turns off.
The next system interrupt causes the delayed key to get executed.
Your observation of a 1-second delay reveals that you have the "Ticking
Clock Mode" turned on (flag -40 is set). Ticking Clock Mode causes a
system interrupt every second (even when HEADER < 2 which makes the
clock invisible), and THAT interrupt is what's causing your delayed
keystroke to get executed. If you turn the ticking clock off (-40 CF),
the delayed key will remain in the key buffer until the next keystroke.
Leaving the clock on is probably less annoying.

it's also instructive to read this topic:

50G - sporadic pauses - garbage collection ?
https://groups.google.com/forum/#!msg/co...KTrgY4zXIJ

You have to use FMEM by John H Meyers:

Code:

@ HP49/50 series only

\<< 5000. MAX :0:JUNK DUP PURGE MEM ROT -

IF DUP 0. > THEN MAKESTR SWAP STO

ELSE DROP2 END 0. DROP MEM \>> 'FMEM' STO

ex. 10000000 FMEM

Vtile · 02-12-2016, 02:52 PM

Quote:You have to use FMEM by John H Meyers:

Code:

@ HP49/50 series only \<< 5000. MAX :0:JUNK DUP PURGE MEM ROT - IF DUP 0. > THEN MAKESTR SWAP STO ELSE DROP2 END 0. DROP MEM \>> 'FMEM' STO

ex. 10000000 FMEM

Thx, what does that do, I'm not following since it seems to be a mix of SysRPL and UserRPL, I'm only familiar with the userRPL

Simone Cerica · (This post was last modified: 02-12-2016 03:02 PM by Simone Cerica.)

It reduces the occurrences of the garbage collector

Vtile · 02-12-2016, 03:09 PM

(02-12-2016 02:58 PM)Simone Cerica Wrote: It reduces the occurrences of the garbage collector

..But, but do I need to run it once or twice and does it introduce some other effects by it self I should be aware of and how I turn it off if it is cousing troubles with something else?

Simone Cerica · 02-12-2016, 03:14 PM

if you notice sporadic pauses then use FMEM, make a backup before using it

Han · (This post was last modified: 02-12-2016 04:08 PM by Han.)

If you type fast, using the (rightarrow)KEYTIME command might be useful. I would place the program << 0. ->KEYTIME >> into a variable named 'STARTUP' to ensure that there are no missed or double keypresses.

DavidM · (This post was last modified: 02-12-2016 05:35 PM by DavidM.)

(02-12-2016 03:09 PM)Vtile Wrote: ..But, but do I need to run it once or twice and does it introduce some other effects by it self I should be aware of and how I turn it off if it is cousing troubles with something else?

You can find a description of the use of the FMEM program from its author here: FMEM description.

The main side effect to be aware of is that running this program will leave a rather large string object named "JUNK" in port 0. You can purge it quite easily simply by executing:

Code:

:0:JUNK PURGE

[Edit: additional info] Note that purging this object cancels the benefit of the program. So the basic concept is leave the object in place so long as you don't need the memory, but delete it if you need the memory for something else. You can always run it again after you've taken care of whatever needed the additional memory.

The "busy bug" doesn't inherently cause double keypresses, but many users understandably think that their initial keypress wasn't registered and as such will press the key again... which then causes both to be processed.