818 === Subject: Re: HPGCC for 48gII? > Does HPGCC support the HP 48gii? I'm having trouble getting a program > to run on it when I know the program runs on the 50g. The HPGCC home > page says it supports the ARM based calculators, but a wikipedia I just got the 48gii and it appears to be an older version with the > serial cable and no USB support. VERSION returns: > Version HP49-C > Revision #1.23 You would need version 1.1 to use it with the 48GII and 39G. Check www.hpgcc.org to download the proper version. Claudio === Subject: 48S - ROM version How do I know the ROM version of a 48S? I already tried the command version, but it did not work. Valfisio. === Subject: Re: 48S - ROM version > How do I know the ROM version of a 48S? Only on HP48S[X]: #30794h SYSEVAL (Result: HPHP48-?) Another way for HP48S[X]: FAQ: 3.4 How can I tell what ROM revision I have? http://www.hpcalc.org/hp48/docs/faq/48faq-3.html#ss3.4 [r->] [OFF] === Subject: How to Raise to the Power of on HP-16C (no Y to the X key) Any suggestions? There is probably an easy way but I have yet to find it. === Subject: Re: How to Raise to the Power of on HP-16C (no Y to the X key) Importance: Normal > Any suggestions? There is probably an easy way but I have yet to find > it. The 16C isn't a scientific calculator so it has no logarithm functions needed to calculate non-integral powers. To raise a number to an integer power, n, write a program that multiplies the number by itself n times. Tom Lake === Subject: Re: HP 50g keyboard layout >> This is the first I've heard of KEYTIME. Can you explain more about >> this fix? > HP50 missed keystrokes > The factory default settings for key hysteresis is so long that if entering > numbers quickly, keystrokes may be missed. The fix is simple--just type 500?KEYTIMEor > 500->KEYTIME(in case the first right arrow didn't come through on your web > browser) where the right arrow is the one entered by pressing Right Shift + > zero. Be sure to delete the space the calculator puts in to the right and left > of that arrow. Viola! You can now type as fast as humanly possible, while > still being protected from key 'jitter' entering doubled keystrokes. This, then, is unrelated to the problem where if a key is pressed just as the CPU goes to sleep, it isn't processed until after the CPU wakes up again (on the following keystroke). It's the latter that I find more annoying and was hoping that this would address (though this is useful too). Does anyone know if it can be fixed by a future ROM update, or if it is a hardware problem that can't be worked around? === Subject: Re: HP 50g keyboard layout > This, then, is unrelated to the problem where if a key is pressed just > as the CPU goes to sleep, it isn't processed until after the CPU wakes > up again (on the following keystroke). It's the latter that I find more > annoying and was hoping that this would address (though this is useful > too). Does anyone know if it can be fixed by a future ROM update, or if > it is a hardware problem that can't be worked around? Seems to be an unrelated software problem. Considering that HP has not released a new ROM since 2.09C in 2006, it seems like HP is not interested in releasing new ROM updates. (JYA said a while ago that there exists a ROM 2.10C, but for some reason, HP simply is not releasing it.) S.C. === Subject: Re: HP 50g keyboard layout Eric Rechlin <> schrieb im Newsbeitrag >> HP50 missed keystrokes >> The factory default settings for key hysteresis is so long that if >> entering numbers quickly, keystrokes may be missed. >> The fix is simple--just type >> 500 ->KEYTIME > [..] > If I set it to 500, it's still possible to lose keystrokes if I press the > same key twice in a row too fast. Intuitively, I would think that 500 > (61ms) would still be fast enough, since that's still an awfully short > time period, but apparently not. > I never had to adjust KEYTIME on my HP-48GX. Still no bouncing keys... SCNR;-) Raymond === Subject: Re: HP 50g keyboard layout > Even better, try a lower threshold, like 160 ->KEYTIME. I think the minimum > level that the OS handles is 20ms, which is around 160/8192 of a second, so > I don't believe it would have any effect if you go any lower. On my 50g, it > handles a setting of 160 just fine with no bounce, while never missing a > keystroke. > My KEYTIME is at 512. I once changed it down to 256, but at 256 ticks, my 50g (CNA 644) would ddouble keystrokes. I guess there is variation across different samples of hardware, but I don't really have a problem with it because I rarely type that fast anyway. S.C. === Subject: Re: HP 50g keyboard layout > If I set it to 500, it's still possible to lose keystrokes if I press the > same key twice in a row too fast. Intuitively, I would think that 500 > (61ms) would still be fast enough, since that's still an awfully short time > period, but apparently not. It's easy to grossly underestimate how quickly experienced users can press buttons -- a useful exercise is to just take a wristwatch and time how quickly one can start and then immediately stop it: Most anyone can repeatedly get under 25ms, and some can repeatedly get under 10ms. While clearly the *average* keypress internal is much longer than that (since you have to move your fingers around to the next button), someone entering 666 or enter enter can do it quite rapidly. For comparison, with a regular keyboard (with a lot more real estate to cover than a calculator keypad), really good typists can easily exceed 100WPM (10 characters per second or 100ms per press and release cycle) on average and in bursts can be at least 50% faster. Particularly good stenographers (smaller keyboard) can reach 300WPM! === Subject: Re: HP 50g keyboard layout >> If I set it to 500, it's still possible to lose keystrokes if I press the >> same key twice in a row too fast. Intuitively, I would think that 500 >> (61ms) would still be fast enough, since that's still an awfully short >> time period, but apparently not. It's easy to grossly underestimate how quickly experienced users can press > buttons -- a useful exercise is to just take a wristwatch and time how > quickly one can start and then immediately stop it: Most anyone can > repeatedly get under 25ms, and some can repeatedly get under 10ms. While > clearly the *average* keypress internal is much longer than that (since > you have to move your fingers around to the next button), someone entering 666 or better that or... === Subject: Re: HP 50g keyboard layout For comparison, with a regular keyboard (with a lot more real estate to cover > than a calculator keypad), really good typists can easily exceed 100WPM (10 characters per second or 100ms per press and release cycle) on average and > in bursts can be at least 50% faster. Particularly good stenographers > (smaller keyboard) can reach 300WPM! Stenographers also do not use regular QWERTY (or even Dvorak) keyboards: http://en.wikipedia.org/wiki/Stenotype It is by using a special phonetic keyboard that they are able to keep up with the speed of speech. S.C. === Subject: Re: HP 50g keyboard layout Off-topic a bit here, but... Speaking of chording keyboards (like stenographers use)... does anyone remember a little handheld computer from the late '80s that had a bazillion little buttons (like they all did), but then five *big* buttons placed roughly in the shape of where your fingertips come down? I seem to recall it had a 4-line LCD, all of 32kB of memory, and few -- if any -- applications besides taking notes using chording with your one hand, but I remember being quite intrigued at the time. Not that I had the money to actually *buy* one, though... === Subject: Re: HP 50g keyboard layout On Feb 11, 4:29 pm, Joel Koltner Particularly good stenographers >> (smaller keyboard) can reach 300WPM! > Stenographers also do not use regular QWERTY (or even Dvorak) > keyboards: Yeah, by smaller keyboard I meant fewer number of keys, but that wasn't very clear. It is by using a special phonetic keyboard that they are able to keep up with the speed of speech. AFAICT it's because there's very little hand motion -- fingers generally only ever move between two rows, never between columns. (Although the thumbs go between two columns...) They also omit spaces, tend to abbreviate, etc. Still, a stenographer is pressing and releasing one (or multiple) keys at a rate of better than 20Hz -- over 30Hz for the very best! === Subject: Question About HP50g Keys? Do the paints on the keys come off over time under normal to heavy useage? I learned that my old 48SX (Singapore) and 32SII (USA) keys were molded, not painted like the new generation of HP calculators. It appears that starting or not long after production in Indonesia, the quality of HP calcs are not what they used to be. When I bought my 32SII (still in excellent condition) years ago, I was afraid that the paints on the keys would rub off, not knowing they were molded, so I covered the key tops with a thin layer of clear nail polish, hoping to make it last as long as possible. I haven't used it much but the clear coat is still there! I wonder if anyone who has problem with the paint on the 50g rubbing off? Also, are the keys on the 50g the same for all production? I saw comments saying they are a little hard to press and can be tiresome after a while. My own experience with less-than-a-week old used 50g (CNA733xxxx) is that they are OK, but some keys are smaller than the others. Not like the 48SX where only the ENTER key is twice as wide. I wish they had the alphabet letters printed to the side of the key like they did in the 48SX, instead of on top, making the key tops appear clustering. I do think about putting a clear coat of nail polish on the key tops so they outlast the calculator useful life. === Subject: Re: Question About HP50g Keys? I'd be worried more about plastic key hinges breaking, rather than key paint wearing off. I don't have any problems with 50g but I didn't use it too frequently or heavily. I wouldn't put anything above the keys, not worth the hassle IMO. === Subject: Re: Question About HP50g Keys? > I'd be worried more about plastic key hinges breaking, rather than key > paint wearing off. I recall seeing comments about that but it doesn't look like something happens frequently enough? > I wouldn't put anything above the keys, not worth the hassle IMO. No hassle at all. I doubt it would take long, especially I have my nieces who I believe are experts at handling nail polish. :) === Subject: HP48 ROM source code Hi ! I recently worked on Stacker4x project with Yann, what awaked my passion about HP48 :) I therefore went through this newsgroup in which I did not have access during my years secondary schools, and of discovery in discovery, I came across this post : Obviously ROM source are in circulation :) So my question is: Somebody would have the HP48 ROM source code (S and G), and could provide them me please ? Graal quest would be over ? lol I hope ... === Subject: Re: Question About HP50g Keys? > Do the paints on the keys come off over time > under normal to heavy useage? I've pounded quite heavily for a long time on my 50g, and its keytops are still perfect. No broken hinges either. Nor does the paint wear off the case. Since I was one of the loudest and most obnoxious bellyachers about these problems on earlier models, I feel obliged to point out these improvements by HP. === Subject: Re: HP 50g keyboard layout > This, then, is unrelated to the problem where if a key is > pressed just as the CPU goes to sleep, it isn't processed > until after the CPU wakes up again (on the following > keystroke). It's the latter that I find more annoying... A very useful workaround to this so-called Busy Bug is to turn the clock display on (MODE DISP Clock, or -40 SF) and leave it on permanently. Any keystroke caught in the evil clutches of this bug will be released and executed by the next clock display update (every second) or by the next keystroke, whichever comes first. The extra battery drain is negligible, and no keystrokes are completely lost. -Joe- === Subject: Re: HP 50g keyboard layout > ... does anyone remember a little handheld computer from the > late '80s that had a bazillion little buttons (like they all > did), but then five *big* buttons placed roughly in the shape > of where your fingertips come down?I seem to recall it had > a 4-line LCD, all of 32kB of memory, and few -- if any -- > applications besides taking notes using chording with your > one hand, but I remember being quite intrigued at the time. That was the Agenda (aka Mini-BAT) by Microwriter Systems: http://www.xaphoon.com/dataegg/History.html That writeup is by Gary Friedman, whose talk about the Data Egg won him the Best Speaker Award at an HHC conference in Corvallis, OR. He is also an amateur poet and humorist: http://holyjoe.net/poetry/friedman.htm === Subject: Re: HPGCC and keys Plenty of them. > If you want to wait for a key and you don't need to keep control of > your program, use keyb_getkeyM(1); which has debouncing and will work > properly. It will also wait for the key to be released, so no need for > the second loop. > If you don't want to lock your program while waiting, you can do the > following: keymatrix a; do { > keyb_getmatrix(&a); > if(a.full==0) { > // IDLE TIME, DO SOMETHING USEFUL HERE } > } > while(a.full==0); once you know a key was pressed, you can either use keyb_getkeyM(0) to > find out what key was pressed or investigate the keymatrix you already > have. > Using keyb_getkeyM() has the advantage that if the key pressed was a > shift, it will wait for other key to be pressed and will properly > detect shifted keys. > If you are writing a game and you only care about a few keys, and they > may be pressed simultaneously, it is better to proceed directly from > the keymatrix: > In fact my program works in 2 ways: - Sometimes you can press 3 keys in the same time: a shift key + one ore two arrow keys in the same times... - Sometimes I just need a key.. > // (assuming 'a' has the keymatrix with the pressed keys) int key=keyb_getnextkey(&a,-1); while(key!=0) { > // HERE key CONTAINS THE ID OF A KEY, ONE OF THE KB_XXX CONSTANTS // PROCESS YOUR KEY key=keyb_getnextkey(&a,key); // OBTAIN THE NEXT SIMULTANEOUS KEYPRESS } // NOW EITHER WAIT FOR ALL KEYS TO BE RELEASED OR CONTINUE YOUR MAIN > LOOP, READING THE keymatrix AGAIN If you want to wait for all keys to be released, the following will > do: do { > keyb_getmatrix(&a); > if(a.full) { > // KEYS ARE STILL PRESSED, BUT YOU CAN USE THIS TIME TO DO SOMETHING > USEFUL } > } > while(a.full); This helps me. Know I have to understand your text... I did not have time now... Tanguy === Subject: Re: HPGCC and keys >> Tanguy Briancon I have had similar problems, this is one way I found that works for > interactive applications that pause for input: for(;;) { > sys_slowOn(); //conserve battery while user thinks > while(!keyb_isAnyKeyPressed()) //key down > ; > sys_slowOff(); //ok, got key, burn battery //process key while(keyb_isAnyKeyPressed()); //key up > sys_waitRTCTicks(2); //fix key bounce > Tnank you: it could be a good a idea... > For game like applications that do not pause for input and that > require that each action have a keystroke I have been using this: for(;;) { > keyb_getmatrix(&a); //process keys > //e.g.: if(a.full & KB_MASK64(KB_ADD)) { } while(keyb_isAnyKeyPressed()); //key up > } > I don't know much about keyb_getmatrix(&a): sorry I will RTFM... === Subject: Re: HP50 and triglyphs > Also, see these posts: === > Subject: Re: Ascii xx symbols and %%HP headers === > Subject: Ascii Import/Export for SD card and Emulator === Subject: HP 50g keyboard layout This was probably discussed back in 2006 when the 50g was released, but tell me... was the impetus for having Enter in the lower right-hand corner presumably to make the keyboard familiar to TI-83 (etc.) users that have their keyboards laid out that way? I find that I make a lot of errors switching between the 50g and the 35s, which has + in the LRHC. :-( === Subject: Re: HP 50g keyboard layout > ... was the impetus for having Enter in the lower right-hand corner > presumably to make the keyboard familiar to TI-83 (etc.) users that > have their keyboards laid out that way? Probably, but there actually is a good reason to put it there: It's the key that is pressed more than any other key, and that location is the easiest for a right-handed user to reach when the calc is held in both hands with both thumbs pressing the keys. For example, putting two numbers on the stack feels like a single smooth motion, with the right thumb only needing to rock slightly downwards to press ENTER. That is *slightly* more efficient than the traditional double-wide ENTER key placed midway up the keyboard, which requires a *slightly* farther travel of the thumb to press. Proof that ENTER is the most-pressed key? Look at any well-used HP 49G. The paint on the keys wears off fastest from the ENTER key. See http://holyjoe.net/hp/crummykeys.htm for photos. === Subject: Re: HP 50g keyboard layout > Proof that ENTER is the most-pressed key? Look at any well-used > HP 49G. The paint on the keys wears off fastest from the ENTER > key. Seehttp://holyjoe.net/hp/crummykeys.htmfor photos. That's true. When I first got my HP49G+, the ENTER label rubbed off in one day, and the rest of the keys took three days. :-) Here's a key layout idea. It's not original - I have an old Fujitsu handheld PDA that uses it. Put a pushbutton or rocker switch on the each side, level with the display. Both right-handed and left-handed folks will find a thumb on one button or the other (assuming they aren't using both thumbs for typing). It could be programmed as ENTER or whatever; better would be a center-off rocker with two programmable positions. Bill Off My Rocker Markwick === Subject: Re: HP 50g keyboard layout > This was probably discussed back in 2006 when the 50g was released, but tell > me... was the impetus for having Enter in the lower right-hand corner > presumably to make the keyboard familiar to TI-83 (etc.) users that have their > keyboards laid out that way? I find that I make a lot of errors switching between the 50g and the 35s, > which has + in the LRHC. :-( ---Joel This was discussed years before 2006: when the original hp49g was released... I don't know the hp35s. But the hp49 (and 49g+,50) have one more key than the hp48 series: in alpha mode that was a big progress! Tanguy === Subject: Re: startup 49g+/50g An obvious user owned resource that I forgot: the stack! MANY User RPL programmers (including me sometimes) wrongly assume that the program always starts with only its inputs on the stack. I've even see some programs that use CLEAR at the beginning because the programmer doesn't *care* what's on the stack. Even worse, I've seen some programs that use CLEAR at the *end* of the program because the programmer doesn't *know* what's on the stack and wants to clean up the mess he's left there. Ugh! Whatever user-data that was floating on the stack before a program runs should be left on the stack after it finishes (other than its inputs, of course). In User RPL, use DEPTH ->LST to save the stack, and OBJ-> DROP to restore it. === Subject: Re: HP chip model planes > Why on earth does a calculator need to run at 30MHz? The > original HP15c ran at 220KHz[*] in 1983. Has Bill Gates Well, it doesn't *need* to run at 30MHz but it might have no choice but to run at 30MHz. I don't suppose many chip manufacturers validate their products to run at 220KHz. More pertinently, a fast clock speed means that each calculation is over and done with quickly, allowing the calc to drop into its low power state sooner. If it ran more slowly, it would simply consume less power over a longer period of time. The net result being little different. -- Bruce Horrocks Surrey England (bruce at scorecrow dot com) === Subject: Re: HP chip model planes >> Why on earth does a calculator need to run at 30MHz? The >> original HP15c ran at 220KHz[*] in 1983. Doesn't an emulated calculator need to have its emulator based on a much faster CPU than the original product, even if only to run no slower than the original? Quite a few of those originals were also rather slow, compared to today's faster-paced products and expectations, so doesn't that require yet another bit of souping up? Should HPGCC, when running C programs, slow down the ARM CPU, to match the speed of the Saturn that it no longer emulates? It is possible for some things to be too fast, however. I had an early Casio scientific that became too fast, to the extent that the display never even blinked during calculations, and this led to lack of positive feedback that it had responded to the operator at all. A number of HP calculators incorporate deliberate operator fedback, such as the appearance of the word Calculating in a display, which is made to appear for a minimum number of milliseconds, even if the calculation could have been completed a hundred times over, by the time this condescension to human slowness was completed. === Subject: Re: My HP49g+ has died. posting-account=QSfVcQoAAADkgn5Et4hWcvOa13b-lJy1 Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) Hi ! My HP49g+ has died several times, same as yours, and came back after an air drying aplication of 20 minutes. It seems that the machine don«t like fast change of temperature (specially down) that makes some condensation inside it. When you air dry it, just put the batteries back, and it goes again. Daniel p.d. look at === Subject: Re: Change to command line humor. Hopefully the documentations were better but I think it is made up for by this friendly and helpful community. > The -> refers to the single arrow character that you get by > right-shift 0. It's not a dash and a greater-than. For typing command names like ->KEYTIME, ->LIST, STR-> etc. > alpha shift will also be found useful; > otherwise spaces will be inserted around the arrow character > (you can also of course just backspace to remove spaces). The alphabetical CATalog is also useful: Commands beginning with - are all together, near the end of the list. You can locate commands ending with - via their beginning letter(s), as usual. When you select commands from the CATalog, > you need only locate them in the list and press ENTER; > you need never spell them out or type special characters. By the way, right-shift ENTRY (right-shift Alpha) > prevents any evaluation of a command line until ENTER is pressed, > by turning on program entry mode (PRG indicator), > just as do {} and <<>> and :: > the misleadingly named Text editor (under APPS) > also merely starts a new command line in PRG mode. Ain't it wicked? http://www.youtube.com/watch?v=a0m6sclZkH0http://www.youtube.com/watch?v=Fi-p 7anJCmM === Subject: My HP50g hacked??? i try some programs on my hp. one programs name diary bible... its about bible. how i install it i dont understand but after that program my hp when opening interesting things write on screen then my normal screen comes. this take 1sec max. but my hp now waste more more battery. i can use new batteries only 4-5 days. i try hard format but it didnt changes anything. what can i do. can somebody answer it... === Subject: Re: My HP50g hacked??? posting-account=QSfVcQoAAADkgn5Et4hWcvOa13b-lJy1 Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) > hi everyone, i try some programs on my hp. one programs name diary bible... its > about bible. how i install it i dont understand but after that program > my hp when opening interesting things write on screen then my normal > screen comes. this take 1sec max. but my hp now waste more more > battery. i can use new batteries only 4-5 days. i try hard format but > it didnt changes anything. what can i do. can somebody answer it... > What HP are you using and what version of the S.O. are you using ? (Write version on the keyboard to know) Daniel === Subject: Non Freed Memory I've got a pretty difficult but interesting problem currently with a program being developed for automatic compression. However the problem is generic to all programs which may face a not enough memory error. Here is the description : I start the program with an object in Stack1. Let's say the object is very large, for example 30K. Now i want to compress it. I need another time 30K + 5K for the compressor, so 35K. Therefore, i must have at least 65K available at the beginning to succeed. Let's say that if there is not enough memory, it is correctly trapped by the system. So now this condition is fullfilled. I have at least 65K available. The program is compressed to 20K for example. So now i'm using 30K + 20K on the stack. So i've got at least 65K-50K=15K Free. Now i need to integrate the compressed object into a composite (2Ob>Seco). This will copy the compressed object. So i need another time 20K at least. That means 50K+20K=70K minimum. However, 70K is more than 65K, so maybe i don't have enough memory. *** This is where it becomes interesting. *** At this stage, i don't need the initial object anymore, so i drop it. This should free up 30K memory, right ? Wrong, when doing a MEM check, it shows that memory is still in use, even after the DROP. Now, that could be because the 30K object is in LASTARG ? That's right, so i'm doing anything silly to make sure this it is no longer in LASTARG, for example ZERO DROP. Check again : no way, memory is still not freed. I can repeat the process tens of times, memory is never freed. As a consequence, the 2Ob>Seco command will fail if there is not enough memory left. Now, when the program ends, whatever the outcome, if i check again with MEM, now the 30K object is no longer in memory. Weird ? It is as if something was keeping the initial object into memory while the program runs, even after being dropped from the stack. It only disappears after the program ends. And no, it is not saved into memory. Or is it ? I was wondering : Is this a known effect ? could it be because the object is the first on the stack when the program starts ? === Subject: Re: Non Freed Memory > Hello Here is the description : *** This is where it becomes interesting. *** At this stage, i don't need the initial object anymore, so i drop it. > This should free up 30K memory, right ? > No! Useless objects remains in memory. When memory is full (and when a program asks for more memory...) the hp does a garbage collector and useless objects are remain from the memory. And you get new memory avaible for your program... This garbage collector can be force by a GARBAGE in sys-rpl and GARBAGECOL in ASM. This takes some time (that is why an HP seems to be frozen sometimes...). Any error in rpl made a garbage collector by the way Tanguy === Subject: Re: Non Freed Memory >> Here is the description : > *** This is where it becomes interesting. *** >> At this stage, i don't need the initial object anymore, so i drop it. >> This should free up 30K memory, right ? >> No! Useless objects remains in memory. When memory is full > (and when a program asks for more memory...) the > hp does a garbage collector and useless objects are > remain from the memory. And you get new memory avaible > for your program... This garbage collector can be force by a > GARBAGE in sys-rpl and GARBAGECOL in ASM. > This takes some time (that is why an HP seems > to be frozen sometimes...). Any error in rpl made a garbage collector by the way Tanguy And the MEM does not do a garbage collector so the result can be not true (because of useless objects in memory...). Like in your program... === Subject: Re: Non Freed Memory > And the MEM does not do a garbage collector so the > result can be not true (because of useless objects > in memory...). Like in your program... I guess Yann is aware of how the garbage collector actually works. He must have meant the UserRPL xMEM instead of the SysRPL MEM. xMEM does a garbage collector, whereas MEM doesn't. === Subject: Re: Non Freed Memory > He must have meant the UserRPL xMEM instead of the SysRPL MEM. > xMEM does a garbage collector, whereas MEM doesn't. === Subject: Re: Non Freed Memory >> He must have meant the UserRPL xMEM instead of the SysRPL MEM. >> xMEM does a garbage collector, whereas MEM doesn't. > Sorry... But what about my argument about lastarg? If you start a program with somethings on stack you can have this object back with undo (red-shift HIST). === Subject: Re: Non Freed Memory > He must have meant the UserRPL xMEM instead of the SysRPL MEM. > xMEM does a garbage collector, whereas MEM doesn't. > But what about my argument about lastarg? If you start > a program with somethings on stack you can have this object back > with undo (red-shift HIST). Maybe you can look at #80775 there is 5 space for addresses for the LAST stack. If the object have this adress in #80775 (+5...) then the GC will not delete it... (This was for hp49 but is it still the same for hp49g+/hp50?) === Subject: Re: Non Freed Memory > when doing a MEM check, it shows that memory is still in use, Which MEM? SysRPL MEM does not perform GC, and does not recover any space. User MEM performs GARBAGE before MEM === Subject: Re: Non Freed Memory Le mercredi 28 janvier 2009, Yann a .8ecrit : > I've got a pretty difficult but interesting problem currently > with a program being developed for automatic compression. How did you create the object to be compressed by your program? Could you write a small piece of code that could reproduce your issue? === Subject: Re: Non Freed Memory posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) How did you create the object to be compressed by your program? > The initial object, in my test, is DuneGX (37KB). This is not specific, stfox has the same issue with a 50KB object. The idea is that you need a large object to start experiencing such issues. I've used FastLZD for compression, but i don't think the problem to be compression specific. I believe it could happen with any program which creates an object 2 of roughly the size of object 1. For example, a DUP xNEWOB could do the trick. (Although, to be in a perfectly equivalent situation, Object 2 must be a bit smaller than Object 1 ). The problem happens when creating a 3rd object from the 2nd one. In order to free some memory, i'm dropping object 1. Then i'm discovering that object 1 is still in memory, even after being dropped. As a consequence, the program may fail with a not enough memory error. The point is : Object 1 must be removed from memory, to leave enough room to create Object 3. > Could you write a small piece of code that could reproduce your issue? Well, i currently believe that something i'm doing in the code is retaining Object 1 in memory. This is probably something that i'm not describing in the scenario. So better provide you with the problematic source code itself. :: ( 1:Ob ) XEQTYPE %25 %= ( 1:Code? 2:Ob ) OVER TYPECOL? OR ( 1:Exe? 2:Ob ) SWAPDUP ( 1:Ob 2:Ob 3:Exe? ) Compression_Here ( 1:T/F 2:Ob 3:Ob 4:Exe?) NOTcasedrop :: ( 1:Ob 2:Exe? ) SWAPDROP ZERO Need more mem to compress Display_Line2 ; ( 1:C.Ob 2:Ob 3:Exe? ) DUP OSIZE TWENTYONE #+ ( 1:CSize 2:C.Ob 3:Ob 4:Exe? ) 3PICK OSIZE ( 1:Size 2:CSize 3:C.Ob 4:Ob 5:Exe? ) 2DUP #> How did you create the object to be compressed by your program? >> The initial object, in my test, is DuneGX (37KB). > This is not specific, stfox has the same issue with a 50KB object. > The idea is that you need a large object to start experiencing such > issues. I've used FastLZD for compression, but i don't think the problem to be > compression specific. > I believe it could happen with any program which creates an object 2 > of roughly the size of object 1. > For example, a DUP xNEWOB could do the trick. > (Although, to be in a perfectly equivalent situation, Object 2 must be > a bit smaller than Object 1 ). The problem happens when creating a 3rd object from the 2nd one. > In order to free some memory, i'm dropping object 1. > Then i'm discovering that object 1 is still in memory, even after > being dropped. > As a consequence, the program may fail with a not enough memory > error. The point is : Object 1 must be removed from memory, to leave enough > room to create Object 3. >> Could you write a small piece of code that could reproduce your issue? Well, i currently believe that something i'm doing in the code is > retaining Object 1 in memory. > This is probably something that i'm not describing in the scenario. > So better provide you with the problematic source code itself. > :: ( 1:Ob ) > XEQTYPE %25 %= ( 1:Code? 2:Ob ) > OVER TYPECOL? OR ( 1:Exe? 2:Ob ) > SWAPDUP ( 1:Ob 2:Ob 3:Exe? ) > Compression_Here ( 1:T/F 2:Ob 3:Ob 4:Exe?) > NOTcasedrop :: ( 1:Ob 2:Exe? ) SWAPDROP ZERO Need more mem to > compress Display_Line2 ; > ( 1:C.Ob 2:Ob 3:Exe? ) > DUP OSIZE TWENTYONE #+ ( 1:CSize 2:C.Ob 3:Ob 4:Exe? ) > 3PICK OSIZE ( 1:Size 2:CSize > 3:C.Ob 4:Ob 5:Exe? ) > 2DUP # SWAP#- ( 1:Gain 2:C.Ob 3:Ob 4:Exe? ) > ROTDROPSWAP ( 1:C.Ob 2:Gain 3:Exe? ) ( Object1 is > dropped here ) > ************************************************** > xMEM xHALT DROP ( Object1 is dropped, but memory not freed) > ************************************************** > ************************************************** > ZERO xDROP > xMEM xHALT DROP ( memory still not freed !) > ************************************************** > ROT ( 1:Exe? 2:C.Ob 3:Gain ) > ITE :: ' ExeDecode ; :: ' Decode ; > the program fails if there is not enough memory ) > SWAP ( 1:Gain 2:C.Prog ) > ; > ( 1:Size 2:CSize 3:C.Ob 4:Ob 5:Exe? ) > 3DROP SWAPDROP ZERO The first object may be marked as lastarg so will not be frozen by GC. The hp allows you to do 'undo'... === Subject: Re: Non Freed Memory Another way to avoid saving a reference to any input in LASTARGs is not to start your command with any function which saves args, i.e. do not start with any CKn or CKn&Dispatch, but instead begin with CK0NOLASTWD or AtUserStack then do your own arg checking via other functions. The last prior command's args are still left over, however. By the way, if you use ZERO xDROP and then abort, what will LASTARG return to the stack? Oops, hey, this command left a bint on my stack :) Okay, yet another method for dereferencing LASTARGs (here expressed in UserRPL): -55 DUP SF CF LASTARG now returns nothing. I suppose there could be an internal function (or bit of ML code) just for cleanly wiping out saved arg references, but I don't know it. Or do I? Try exploring the ROM function for UserRPL command SF If a system (negative) flag is set by SF, the very last thing, following SetSysFlag tests whether flag -55 is now set, and if so, it goes into the ML which wipes out those references. This very thing is what makes -55 DUP SF CF work, which was very thoughtful of Wickes & company, I would say! The HP48[S/G] location (112EC) of the code for clearing last args appears as if it may be unsupported but stable per these lines from Entries.all: 53842 :: NS:?ClrLastArgs 53842 @ If LASTARG flag is clear [no, set :] ClrLastArgs 112EC P NS:ClrLastArgs 112EC @ Clear Last Arguments The (different) HP49/50 location (263E6 in mine) might be as well, but better do your own more thorough research. At any rate, the ML is brief and can also be copied. Clearing LASTARGs doesn't affect your original stack mark (depth), which seems also of benefit. === Subject: Re: Non Freed Memory posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) Feedback : I've tried to remove the CK2 in the caller program, and i also tried to start my test using directly the compression program, bypassing the caller. In both circumstances, the memory is not freed, even after a ZERO xDROP. I'm not sure if LastArg is a problem here, because the big object is no longer in LastArg. Looking further : The compression program starts by a XEQTYPE call. That's because i couldn't find a better way than XEQTYPE %25 %= to test if the object is a CODE type. XEQTYPE is a SysRPL program, but is nearly the same as xTYPE, its UserRPL equivalent. Maybe this is where a CK1 is hiding ? In this case, i would need a better way to test if the object is a CODE. === Subject: Re: Non Freed Memory > I've tried to remove the CK2 in the caller program, This brings to mind that any reference, or within any still referenced composite, or perhaps in a saved stack would still tie up the release of object memory. There seem to be commands for testing whether an object remains referenced, e.g. REFERENCED?, NOTREF?, PTRREF?, INTEMNOTREF? If the object was on the stack before pressing a key to start a program, for example, Last Stack would keep the original object referenced, despite anything else you might do. === Subject: Re: Non Freed Memory posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) If the object was on the stack before pressing a key > to start a program, for example, Last Stack > would keep the original object referenced, > despite anything else you might do. > This seems to be the right explanation. i found UNDO_OFF, UNDO_ON and UNDO_ON? (supported entries). If i trigger UNDO_OFF before starting the program, then the problem is solved => object 1 is cleared from memory after being dropped from stack. Good !! Problem is : Unfortunately, if i trigger UNDO_OFF from within the program, it is too late. And i don't want to force the user to keep its calculator with a permanent UNDO_OFF. So the better solution would be to clear Last Stack. Alas, i could not find any command for this... === Subject: Re: Non Freed Memory > So the better solution would be to clear Last Stack. > Alas, i could not find any command for this... There was never intended to be any, since it could pull the rug out from under the user. If you keep nesting HALTs, you can turn Last Stack on and off at every level, each of which can have its own saved (cached) stack, which was utilized to make an unlimited undo program via HALTing at every step: I don't know what you can or can't do about the current situation, but you'd better be careful about doing it, taking into account any possible current user settings (e.g. Last Stack currently on or off), since any mistake or assumption here might potentially be harmful. The wildest idea I can think of could be to transfer any reference for the original object to some new object (commands seem to exist for transferring references), which is still interfering with what the user expects, but is not unprecedented (e.g. the editor ED from Jazz alters any original string directly, which you can not UNDO). Good luck! === Subject: Re: Non Freed Memory > an unlimited UNDO program via HALTing at every step: It turns out that the above needed a subsequent revision: Complete thread: Final program version: === Subject: Re: Non Freed Memory Just replaced the central part of my previous source code with the following : ************************************************** %0 xDROP ( Clears from LastArg ) CacheStack ( Clears from LastStack ) xMEM xHALT DROP ( Checking : At last ! Ob1 is cleared ! ) ************************************************** CacheStack did the trick, by replacing the previous LastStack with the current Stack, from which Ob1 is cleared. towards the right direction. === Subject: Re: Non Freed Memory > CacheStack did the trick, by replacing the previous LastStack with the > current Stack, from which Ob1 is cleared. Important follow-up from experience : we discovered that using CacheStack command That's a pretty violent restriction for a supported entry. CacheStack.... === Subject: Re: Non Freed Memory You could also consider taking a look at the SysRPL words: CACHE / DUMP and SAVESTACK / UNDO Yann schrieb im Newsbeitrag >> CacheStack did the trick, by replacing the previous LastStack with the >> current Stack, from which Ob1 is cleared. Important follow-up from experience : we discovered that using CacheStack command > That's a pretty violent restriction for a supported entry. CacheStack.... > === Subject: Re: Non Freed Memory > Just replaced the central part of my previous source code > with the following : ************************************************** > %0 xDROP ( Clears from LastArg ) > CacheStack ( Clears from LastStack ) > xMEM xHALT DROP ( Checking : At last ! Ob1 is cleared ! ) > ************************************************** CacheStack did the trick, by replacing the previous LastStack > with the current Stack, from which Ob1 is cleared. Pretty good! Note that InitSysUI (the same function which clears flag -62 during startup, thus turning off User keys mode) also calls ClrLastArgs in all HP48/49/50. ClrLastArgs appears stable at 112EC in HP48[S/G]. Is there anyone who doesn't find PTR 263E6 (ClrLastArgs) within InitSysUI in any HP49/50 series ROM? -- that location appears to be in a branch table, such as is used for other fixed entry points, even though it has no associated supported symbol (it's exactly the same in ROMs 1.19-6, 1.24, and 2.09, for example, so that looks mighty stable!) Nosy doesn't understand a branch table if invoked with input #263E6h or PTR 263E6, but does understand correctly when encountering PTR 263E6 within an actual program, e.g. InitSysUI as above, or :: PTR 263E6 ; (assemble, then input to Nosy) If one can use ClrLastArgs instead of %0 xDROP, then all intermediate calls to user functions are eliminated. === Subject: Re: Non Freed Memory ClrLastArgs appears stable at 112EC in HP48[S/G]. Is there anyone who doesn't find PTR 263E6 (ClrLastArgs) > within InitSysUI in any HP49/50 series ROM? -- t If one can use ClrLastArgs instead of %0 xDROP, > then all intermediate calls to user functions are eliminated. > Yes, this address appears in several lists, but not all of them especially not in Carsten's entry list. So i was worried about using the unsupported ClrLastArgs. As a consequence, i opted for a now familiar strategy : using CK1LASTNOWD at a place in the code where i know there is nothing important, this similarly replaces LastArg with current Stack1 object, clearing the big Ob1 from there. === Subject: Re: Non Freed Memory > I opted for a now familiar strategy: using CK1NOLASTWD > at a place in the code where i know there is nothing important, > this similarly replaces LastArg with current Stack1 object, > clearing the big Ob1 from there. Any subsequent error will then return the (possibly irrelevant) last object, and may drop a different amount of the stack, back to the new point, rather than the original point, if any different. Anyone using IFERR to trap errors ought to be informed that something unexpected (non-return of original args) will happen if an error occurs. If there are originally two input args, then it might actually be useful to return, if anything at all, the exact same number of args as were input to the original command, thus satisfying one normal expectation, allowing any user's assumption to write IFFERR TwoArgCommand THEN DROP2 ... END to remain valid (except when they forgot to clear flag -55 beforehand :) Maybe I just like to argue about arguments :) http://kids.niehs.nih.gov/lyrics/cindfall.htm http://www.youtube.com/watch?v=muXyYpDstr0 (No one doesn't love Bernadette :) === Subject: Re: Non Freed Memory If there are originally two input args, then it might actually be useful > to return, if anything at all, the exact same number of args > as were input to the original command, thus satisfying > one normal expectation, allowing any user's assumption > to write IFFERR TwoArgCommand THEN DROP2 ... END to remain valid > (except when they forgot to clear flag -55 beforehand :) > Good point. > But what about my argument about lastarg? If you start > a program with somethings on stack you can have this object back > with undo (red-shift HIST). This is a choice here, like Bang type. The problem is about memory limitation, an issue which occurs only with large-size object as argument. This is a design choice to solve this issue by intentionnally deleting the initial object after successfull tests, because, anyway, this is an automated tool, doing lots of compressions in a row,. The alternative is to stop the operation with a Not enough memory message, but i'd prefer not to stop it in the middle. > Maybe you can look at #80775 there is 5 space for > addresses for the LAST stack address #80775 for HP49. LASTARG never really was a problem, because it can easily be overwritten by a simple ' %0 xDROP ' for example LASTSTACK, on the other hand, has been much more difficult to deal with. And still is, because CacheStack remains pretty dangerous to handle. === Subject: Re: Non Freed Memory > You can't dereference the original argument via a SysRPL DROP, > but you could via a UserRPL xDROP (which simply replaces > any older saved references with a single newer one, > for a smaller object). This was tried but does not work either. For sure, the initial large object is no longer in Lastarg, but it is still occupying its memory, up to the end of the program. > Another way to avoid saving a reference to any input in LASTARGs > is not to start your command with any function which saves args, > i.e. do not start with any CKn or CKn&Dispatch, > but instead begin with CK0NOLASTWD or AtUserStack > then do your own arg checking via other functions. The program above the one where i described the problem (the caller) starts with a CK2. The big object is Stack2 in this case. So this could be the root of the problem. I will try your suggestion to not use it. Maybe a Depth test could be enough to start with. === Subject: Re: Non Freed Memory > At this stage, i don't need the initial object anymore, so i drop it. > This should free up 30K memory, right ? Wrong, when doing a MEM check, it shows that memory is still in use, > even after the DROP. Now, that could be because the 30K object is in LASTARG ? > That's right, so i'm doing anything silly to make sure this it is no > longer in LASTARG, for example ZERO DROP. Only UserRPL commands save LASTARG references, via the CKn&Dispatch with which the ROM code for UserRPL commands most commonly begins. You can't dereference the original argument via a SysRPL DROP, but you could via a UserRPL xDROP (which simply replaces any older saved references with a single newer one, for a smaller object). At the same time, that would change the effect of any subsequent abort (as to both arg restoration and excess stack depth removal), and of course would also interfere with the original idea that the original args to a command would normally be preserved (but it wouldn't be the first such command to have this non-typical behavior). === Subject: Re: User Keyboard > stfox and i are preparing a program which > will be remapping quite many user-keys onto library functions. > We currently have 14 user-key assignments. > The initial setup costs a bit of time, something in the range of a > full second on a standard HP48G. > This is not very long, but i would like this process to be a bit > more instantaneous, if that is possible. > We are using some pretty standard RPL call, > xASN with %lc.p assignment, and StoUserKeyPatch with #kc.p. > I wondered if it exists a speedier way to do such a job. > 14 is not massive, but maybe there is a way to store many user-key > assignments faster than 14 times single-key assignments. User xSTOKEYS accepts a list (multiple assignments). If key assignment is only to be in effect during a program, and not remain after the program exits, perhaps a POL ? (don't ask me anything more about POLs, which I have never written :) === Subject: Re: User Keyboard User xSTOKEYS accepts a list (multiple assignments). > However, it did not seemed any faster when we tried it. Maybe we should try again and benchmark it more thoroughly. > If key assignment is only to be in effect during a program, > and not remain after the program exits, perhaps a POL ? > (don't ask me anything more about POLs, which I have never written :) Wow, POL, i've never understood anything about it, in spite of reading numerous Yann === Subject: Re: User Keyboard > i've never understood anything about it, in spite of reading numerous Basically, a POL is just... a loop. You need to write handlers to run a POL. A handler is just a program which is started by the POL when some events occur. For example, a key handler is a SysRPL secondary object which, when evaluated, takes a key code and its plane as arguments and returns either FALSE if the key is not handled or a secondary and TRUE if the key is. The secondary is then executed by the POL. Inform boxes and browsers are like POLs in spirit. For inform boxes, you have to provide a message handler for the whole thing, and one for each field. Lots of events are generated by the inform box: each time you press a key, each time a field gets focussed or losses focus, etc. Programming them is like programming graphical interfaces on modern computers, you have to create the interface and hook callbacks for each event you are interested in. Well, POLs are powerful but slow. Inform boxes on the HP48G series are astonishly slow. (A new inform box motor was programmed in the HP49 and is faster.) Whatever, I really prefer using menu-based applications (like on HP48S/SX) rather than their graphical counterpart. It's much more like you are doing multitasking. === Subject: Re: User Keyboard Khanh-Dang schrieb im Newsbeitrag > Le mercredi 28 janvier 2009, Yann a .8ecrit : >> Wow, POL, >> i've never understood anything about it, in spite of reading numerous Basically, a POL is just... a loop. You need to write handlers to run a > POL. A handler is just a program which is started by the POL when some > events occur. For example, a key handler is a SysRPL secondary object > which, when evaluated, takes a key code and its plane as arguments and > returns either FALSE if the key is not handled or a secondary and TRUE > if the key is. The secondary is then executed by the POL. Inform boxes and browsers are like POLs in spirit. [..] Well, POLs are powerful but slow. Inform boxes on the HP48G series are > astonishly slow. (A new inform box motor was programmed in the HP49 and > is faster.) Whatever, I really prefer using menu-based applications > (like on HP48S/SX) rather than their graphical counterpart. It's much > more like you are doing multitasking. The basic POLs aren't that slow, taken in account that even the most basic ones handle the most important system events for the POL application programmer. No alarms to take care for, no timeouts to handle, and the basic errors are caught easily using a POL. And a POL allows the app programmer having total control of his application user interface. Actually a POL is the standard application frame for nearly every interactive thing on the HP-48. Even the cmd line editor is a POL, at least on the real HP-48. An application programmer could make his app do all the basic checks in a discrete way, and very likely forget to handle the one or other exception -- or simply let the POL mechanics do that for him. Inform boxes and choose boxes _are_ POLs, not only in spirit;-) They're (programmable) POL applications themselves. For the HP-48 G series, you can also have very fast user interface elements using SpeedUI, which accelerates the whole UI, including inform boxes, choose boxes and much more. The next version (the 2009 edition) will add support for a QuickStartMenu, similar to APPS on the doorstops, but invented here (tm:-) Also UFL support for choose boxes and message boxes will be included, as well as many UI refinements, like the global multiple clipboard, and the global online function/cmd catalog including parameter help. The overall performance has been increased once more, and the new and optional UFL support helps to gain some further speed regarding displaying text. HTH Raymond === Subject: About POLs (was Re: User Keyboard) > The basic POLs aren't that slow, taken in account that even the most basic > ones > handle the most important system events for the POL application programmer. No alarms to take care for, no timeouts to handle, and the basic errors > are caught easily using a POL. And a POL allows the app programmer > having total control of his application user interface. What do you exactly mean when you talk about system events? What are timeouts? POLs don't let the user do other tasks once he is in the POL. A POL is a loop, and a loop can't be easily broken. The user can halt the POL (with HALT), but only *temporarily*. It is not as powerful as the aplet system on HP38/39/40. In an aplet application, when the user switches to the main stack, the application's status is saved. The user exited the aplet's interface *permanently*, but the status is restored when the user switches back to the aplet's interface. It's like menus-driven on the HP48S because the user has the ability to do multitasking. It's different because aplets are graphical interfaces, whereas menus-driven are... menus. Graphical UI are more intuitive but less ergonomic (less fast, less parametrisable, ...) than menus. For my everyday use, I prefer more ergonomic applications, but I'd rather use graphical UI for applications I don't use every day. === Subject: Re: About POLs (was Re: User Keyboard) >> The basic POLs aren't that slow, taken in account that even the most >> basic >> ones >> handle the most important system events for the POL application >> programmer. >> No alarms to take care for, no timeouts to handle, and the basic errors >> are caught easily using a POL. And a POL allows the app programmer >> having total control of his application user interface. What do you exactly mean when you talk about system events? What are > timeouts? > Examples for system events caught in a POL are key presses, alarms, UART events, ATTN, module pulled, timer count downs, sleep,... where the latter can also be seen as timeout. When the ten-minute period before the calc switches itself off has been reached, the sleep exception will be issued. > POLs don't let the user do other tasks once he is in the POL. > That's not correct. You can tell the POL to allow other tasks, and if you take a look at the HP-48 built-in edit line, you'll see that the user can do nearly everything while inside the editline POL. And every input field of a form which allows data entry actually starts a new POL (a specialized edit line)... > A POL is a loop, and a loop can't be easily broken. > The idea behind a POL is to have an environment, which is fully controllable by the application developer. So if the app developer doesn't want to have his app exited using the one or other way, this is what the POL is for. On the other hand, if the developer wants to enable every possible thing while in his POL, this can also be achieved, see the input line POL. Nearly every POL also includes an exit condition. If this condition is met, the POL will be quit, or in other words the loop will be finished. Not broken, because an application developer should always ensure a clean exit, even in an error event situation. > It is not as powerful as the aplet system on HP38/39/40. > However even the Topic Outer Loop is a POL basically, expanded by a generalized mechanism to save and restore task environments;-) The central function is the GetKeyOb - DoKeyOb sequence in both cases. BTW (and slightly OT): Neither POL or TOL _need_ to have visible UI elements, but the key handling and other event checking are always done, or at least enabled. The extreme case would be a POL or TOL with no visible feedback, but only waiting for and handling a specific event or exception. > In an aplet > application, when the user switches to the main stack, the application's > status is saved. The user exited the aplet's interface *permanently*, > but the status is restored when the user switches back to the aplet's > interface. It's like menus-driven on the HP48S because the user has the > ability to do multitasking. It's different because aplets are graphical > interfaces, whereas menus-driven are... menus. > Ahem, that's not multitasking. The background task will always be in a suspended state, not running while in the background. My PC is capable of multitasking, because it allows multiple programs to virtually _run_ at the same time, not just taking up memory. And about restoring an applications UI: This could also be done by Library Data objects, as it propably was intended. However, as written above, the TOL provides a more generalized mechanism. But then, I never missed that ability on my HP-48... > Graphical UI are more intuitive but less ergonomic (less fast, less > parametrisable, ...) than menus. For my everyday use, I prefer more > ergonomic applications, but I'd rather use graphical UI for applications > I don't use every day. > Did you take a briefer look at the internal mechanics of the HP-48 menu system? It's very powerful and flexible, but there are some drawbacks regarding performance of the menu system because there are different levels of generalized prerequisite actions which significantly slow down menu key action. One can see this when starting the library menu, which is very slow by default (not too ergonomic;-). Simplified speaking, this is because the built-in menu display update mechanics eat that much performance. Raymond === Subject: Re: About POLs (was Re: User Keyboard) > Examples for system events caught in a POL are key presses, alarms, > UART events, ATTN, module pulled, timer count downs, sleep,... > where the latter can also be seen as timeout. OK, I never thought about UART events or module pulled events. Programs that don't explicitly use a POL also have a loop with a %0 xWAIT somewhere (let's omit programs that use 100% CPU, usually written in assembly language). And, after all, %0 xWAIT is just a minimal POL, so these programs actually use a POL too. >> In an aplet >> application, when the user switches to the main stack, the application's >> status is saved. The user exited the aplet's interface *permanently*, >> but the status is restored when the user switches back to the aplet's >> interface. It's like menus-driven on the HP48S because the user has the >> ability to do multitasking. It's different because aplets are graphical >> interfaces, whereas menus-driven are... menus. > Ahem, that's not multitasking. Oh, I meant multitasking from the user point of view, not the technical term for the programmer point of view. (Sorry if I am sometime not that clear, english is not my mother tongue.) Some internal applications save their state, like the plotting application (leftshif + F1 to F6). But the inform box doesn't retain where the cursor previously was when you last exited the screen. (Not really an issue, though :-) So yes, you can do multitasking with a POL, but programmers have to implement explicitly state saving. Even if a programmer implemented state saving, he wouldn't do it the same way another would. With Topic Outer Loops, state saving is done in a standard way. > One can see this when starting the library menu, > which is very slow by default (not too ergonomic;-). > Simplified speaking, this is because the built-in menu > display update mechanics eat that much performance. I thought the library menu was slow because it has to build itself (kind of running the xLIBS command) before beeing displayed. Once the menu is displayed, it is as fast as any other menu. When I press the NXT key, I cannot feel the slow update mechanics you are mentionning. === Subject: Re: About POLs (was Re: User Keyboard) Khanh-Dang schrieb im Newsbeitrag > Le jeudi 29 janvier 2009, Raymond Del Tondo a .8ecrit : >> Examples for system events caught in a POL are key presses, alarms, >> UART events, ATTN, module pulled, timer count downs, sleep,... >> where the latter can also be seen as timeout. OK, I never thought about UART events or module pulled events. Programs that don't explicitly use a POL also have a loop with a %0 > xWAIT somewhere (let's omit programs that use 100% CPU, usually written > in assembly language). And, after all, %0 xWAIT is just a minimal POL, > so these programs actually use a POL too. > The central point of %0 xWAIT is WaitForKey, which in fact is a specialized POL to wait for a so-called fully-specified key press, that is every key except the modifier keys. While waiting, the standard system event/exception handling is active, but once the user pressed a key (fully-specified, see above) the specialized POL will be exited, and therefore the system events are not covered by that POL anymore. As another example, the UserRPL INPUT command effectively opens an edit line POL, but when the user presses ENTER or ATTN, that POL will also be exited So a UserRPL program using WAIT and/or INPUT or alike should not be confused with a real POL application. UserRPL programs can be hardened against certain exceptions using other methods, like IFERR..END clauses. And for ML programs using 100 percent CPU: Most of them are simply designed badly, at least from the energy wasting point of view. A possible exception of the words above could be real-time games, which continuously update the display. Nearly every other task can be realized using an event-activated system, that is waiting for action in a low-power state. It's relatively easy to mimic the central key waiting and exception dispatching functionality in ML, as there are some related ML entries in ROM. And most things which are not covered by ROM entries can be achieved with relatively small discrete code. I'm sure there are some examples available, however my SpeedUI main loop is programmed using a central wait and event handling code in ML, which has all the functionality of the SysRPL version. Another example is my SpeedMiner, which also waits for a key press in low-power mode, and all from within ML code. As gimmicks, the SpeedMiner also features key repeating and key nullifying (like on the HP-41;-) Ok, maybe too far OT... So yes, you can do multitasking with a POL, > but programmers have to implement explicitly state saving. > [..] > Even if a programmer implemented state saving, > he wouldn't do it the same way another would. > With Topic Outer Loops, state saving is done in a standard way. > And that's one of the main advantages of using the TOL mechanics. > One can see this when starting the library menu, >> which is very slow by default (not too ergonomic;-). >> Simplified speaking, this is because the built-in menu >> display update mechanics eat that much performance. I thought the library menu was slow because it has to build itself (kind > of running the xLIBS command) before beeing displayed. Once the menu is > displayed, it is as fast as any other menu. When I press the NXT key, I > cannot feel the slow update mechanics you are mentionning. > I was talking of the effect when using an HP-48, of course;-) The doorstops have rewritten ad optimized code for this. Amongst other things, the library menu (RightShift+2) on the HP-48G series uses a flag to indicate dynamic rebuilding, which is evaluated in the SysOuterLoop, and that's one of the parts which make it that slow. There were some attempts from different people to accelerate the library menu, and I also made my version, which builds the initial library menu slightly faster than the built-in version, but if you press the NXT key, my version will show the next library menu pages almost instantly, where the built-in version has a noticable and annoying delay. Raymond === Subject: Re: About POLs (was Re: User Keyboard) > The central point of %0 xWAIT is WaitForKey, > which in fact is a specialized POL to wait for a so-called > fully-specified key press, that is every key except the modifier keys. While waiting, the standard system event/exception handling is active, > but once the user pressed a key (fully-specified, see above) > the specialized POL will be exited, and therefore > the system events are not covered by that POL anymore. What is puzzling me is what POLs do with system events. I believed the system events are handled by the interrupt handler. For example, say a RPL program (either UserRPL or SysRPL) is doing number crunching, using full CPU. If data is incoming on the serial port, an interrupt is generated by the UART. Then, the interrupt handler is started and does what it has to do. Here, the interrupt The interrupt handler also does some system maintenance, such as #80000h) are still correct; if not, the memory is supposed to be corrupted and a warmstart is triggered (just try - at your own risk - to poke 5 random nibbles at #80000h). === Subject: Re: About POLs (was Re: User Keyboard) > And for ML programs using 100 percent CPU: > Most of them are simply designed badly, > at least from the energy wasting point of view. > Nearly every other task can be realized using > an event-activated system, that is waiting for > action in a low-power state. > One of my very very first ML program was a (badly programmed) Greyscale picture displayer for SATURN-based systems, which i still use sometimes these days. I always thought that having a loop reading the linecounter millions was a pretty bad design energy wise. Complexity is very low for such a program : just change the displayed screen according to weight rules. This must happen at every display-redraw, which means 64 times per second. That may sound a lot, but well, even for a saturn processor, this is very little job. Well, i wish i could find a way to put the calculator in low-power mode, and then wait for a timer-event to wake-up the CPU approximately just before the screen-swapping is necessary. That sounds like a pretty simple exercice to start handling events in ML. Unfortunately, i don't even know where to start.... === Subject: Re: About POLs (was Re: User Keyboard) > Well, i wish i could find a way to put the calculator in low-power > mode, > and then wait for a timer-event to wake-up the CPU approximately just > before the screen-swapping is necessary. You might want to learn about the interrupt handler, how to replace it. The ML instruction SHUTDN might be useful, too. Briefly, your program can set its own interrupt handler, replacing the system's one. You can force your own interrupt handler to be triggered by a timer timeout (see TIMERCTRL.1 and TIMERCTRL.2). But it's easy to badly design such a program because your interrupt handler should do what you want (changing the screen's adress every 1/64s or so) but, it *also have to* what the system interrupt handler used to do. Actually, it doesn't really matter if games don't handle properly incoming data on the serial port. What I've been wondering is how the system keeps tracking the system time. I read somewhere it use TIMER1 to trigger an interrupt every 8192 ticks, that is, every second. If so, using TIMER1 for your own use may change the system time. Anyone has some details about system time? === Subject: Sintaxe in sysrpl to call a program of a library I am making a lib and some programs are in sysrpl. How do I to call a program1 from a program2? The program2 will be sysrpl? Both programs are in the same lib. program2 ??? program1 === Subject: Re: Sintaxe in sysrpl to call a program of a library > I am making a lib and some programs are in sysrpl. > How do I to call a program1 from a program2? This is closely dependant to the development tool you are using. If you are building your library with CRLIB, you don't need to do anything special. ID program1 will be translated by CRLIB at compilation. first, but if you don't know that, then you have to read the documentation urgently, or your code will not even compile. === Subject: Re: Sintaxe in sysrpl to call a program of a library === Subject: Adjust the speed of the processor Someone already used programs to modify the speed of processing of 50G? They really work? What are the real risks of the use of these programs? === Subject: Re: Adjust the speed of the processor > 50G? They really work? What are the real risks of the use of these > programs? You will destroy the world by throwing away more disposable batteries. Just think about that when all the glaciers melt and the world's population is displaced. It will all be your fault. . . (nothing really, you'll just go through batteries quicker) === Subject: Soft Menu problem I was given a problem that could easily be solved by using linear algebra. I set flag 117 (Soft Menu); then per the manual, I pressed Right arrow NUM.SLV . I did not get the input form as shown on page 11-18 in the manual ?? However , I did get 'Root' 'Diffe' 'Poly' etc that I think I should get if flag 117 was cleared. In fact, if I clear flag 117, it does appear to affect Right Arrow NUM.SLV ?? Do you think there is an error in the book or do I have an outdated software? === Subject: Re: Soft Menu problem > I was given a problem that could easily be solved by using linear > algebra. I set flag 117 (Soft Menu); then per the manual, I pressed > Right arrow NUM.SLV . I did not get the input form as shown on page > 11-18 in the manual ?? However , I did get 'Root' 'Diffe' 'Poly' etc > that I think I should get if flag 117 was cleared. In fact, if I clear > flag 117, it does appear to affect Right Arrow NUM.SLV ?? Do you think > there is an error in the book or do I have an outdated software? You held down the shift key while you were pressing the next key; release the shift key before the next keypress to get what you wanted. A certain set of keys is pre-programmed to distinguish shift[hold] from shift[release] for different actions. User key assignments can also make this distinction. You will probably come across more of these built-in special key assignments in the manual. In RPN mode, the top-row shifted graphing functions, for example, can only be invoked by holding the shift key before pressing A-F. === Subject: Re: Soft Menu problem > A certain set of keys is pre-programmed to distinguish > shift[hold] from shift[release] for different actions. > As a public service, not to mention some free advertising, :-) here's the shifthold list from the Shortcut keys entry in my HLP49 help file, which is a free download from http://www.hpcalc.org/details.php?id=5973 Hold shift while pressing other key. LS+MODE Mode softkeys LS+TOOL Real/Complex toggle LS+NXT Last menu LS+VAR Home dir RS+ENTER Exact/Approx toggle RS+9 Time softkeys RS+right Kermit server RS+SPC Semicolon RS+CAT (49G) CHARS softkeys RS+EVAL (49G+) CHARS softkeys RS+' Left quotes (`` chr 96) Holding LS while pressing keys A-F gives six plotting functions; these have their own entries. Bill Pluggin' away Markwick === Subject: Re: Soft Menu problem > As a public service, not to mention some free advertising, :-) > here's the shifthold list from the Shortcut keys entry in my > HLP49 help file, which is a free download from > http://www.hpcalc.org/details.php?id=5973 Here are some shifthold key combos missing from your list: LS+downarrow VISITB for variables and EDITB for everything else. * ALPHA RS+['] Omega ALPHA RS+6 degree symbol ALPHA RS+2 upside-down exclamation mark ALPHA RS+3 upside-down question mark ALPHA RS+[.] ; or . depending on flag -51. * LS+downarrow is different from LS downarrow; the latter is like the HP 48's EDIT key, performing VISIT for variables and EDIT for everything else. I *think* that completes the list, but I make no promises. ;-) === Subject: Re: Soft Menu problem InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648),gzip(gfe),gzip(gfe) the visits are so infrequent! === Subject: Re: Soft Menu problem the visits are so infrequent! I second that. :-) -- Bruce Horrocks Surrey England (bruce at scorecrow dot com) === Subject: Re: Soft Menu problem > Here are some shifthold key combos missing from your list... > I *think* that completes the list, but I make no promises. ;-) How about your original KEYHUNT program? [Feb 23 2000], which finds them all: Split into separate programs: [Oct 22 2002] (also an alpha[hold] assigner to make safer top-row graphing keys) Note that the result lists in the posts were for older ROMS (and for 49G, prior to 49G+/50G, which has slightly different arrangement of functions on three central keys), but a fresh running of the program should find all current key assignments, on any 49/50 series model and ROM. === Subject: Re: Soft Menu problem posting-account=c-Jc4woAAAA18oLSdtiQO88Zf36AsP2t .NET CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > A certain set of keys is pre-programmed to distinguish > shift[hold] from shift[release] for different actions. As a public service, not to mention some free advertising, :-) > here's the shifthold list from the Shortcut keys entry in my > HLP49 help file, which is a free download fromhttp://www.hpcalc.org/details.php?id=5973 Hold shift while pressing other > key. LS+MODE Mode softkeys > LS+TOOL Real/Complex toggle > LS+NXT Last menu > LS+VAR Home dir > RS+ENTER Exact/Approx toggle > RS+9 Time softkeys > RS+right Kermit server > RS+SPC Semicolon > RS+CAT (49G) CHARS softkeys > RS+EVAL (49G+) CHARS softkeys > RS+' Left quotes (`` chr 96) Holding LS while pressing keys > A-F gives six plotting functions; > these have their own entries. Bill Pluggin' away Markwick manual.. this completely clears everything up ! Part of the beauty of the 50g is its complexity... I did note that RS Cat will open the catalogue whether the RS key is held or not... I think this group is again. === Subject: startup 49g+/50g This is simply a request/reminder for all the programmers out there that feel compelled to either replace or remove someone's 'startup' file to please have your routines check to see if 'startup' exists, and if so ask if it is ok to modify/delete it. Please forgive me if I sound a little cranky or terse, but this is an issue that needs addressing. === Subject: Re: startup 49g+/50g > This is simply a request/reminder for all the programmers out there > that feel compelled to either replace or remove someone's 'startup' > file to please have your routines check to see if 'startup' exists, > and if so ask if it is ok to modify/delete it. Whodunnit? TW === Subject: Re: startup 49g+/50g > file to please have your routines check to see if 'startup' exists, > and if so ask if it is ok to modify/delete it. I agree completely. All programs should run (or not :-) and exit without any changes whatsoever to the user's calculator. I've had programs overwrite my CST var and similar rudenesses. Another real annoyance is libraries that have a $config var that runs some fancy graphics just to show you how clever the programmer is. Of course, this junk runs on every warmstart. And flags - put all the flags back the way you found them. PUSH and POP are easy to use. Use an IFERR loop to be sure that POP runs if there's an unexpected exit. I'm sure there are more... === Subject: Re: startup 49g+/50g > I've had programs overwrite my CST var and similar rudenesses. Protection for 'CST' overwrite: { my custom menu } 'CST1' STO 'CST1' MENU just repeat the second line to restore it. You can also, in this way, save various alternate custom menus, and can choose any one of them by just storing its name into 'CST' Program to choose among lists in current directory, by name: << Choose CST 5 TVARS 1 CHOOSE { MENU } IFT >> 'CST?' STO === Subject: Re: startup 49g+/50g posting-account=HLB0wQoAAADFCl1K6ZIYOA1tkfCtYfW9 Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) > I've had programs overwrite my CST var and similar rudenesses. Protection for 'CST' overwrite: { my custom menu } 'CST1' STO > 'CST1' MENU just repeat the second line to restore it. You can also, in this way, save various alternate custom menus, > and can choose any one of them by just storing its name into 'CST' Program to choose among lists in current directory, by name: << Choose CST 5 TVARS 1 CHOOSE { MENU } IFT >> 'CST?' STO I do keep spares of STARTUP, CST, KEYASN, etc... on the SD card, but it's the general lack of consideration that one wouldn't normally expect from this particular community. === Subject: Re: startup 49g+/50g posting-account=tK2cUgkAAABPl7vxXuLS8-X63eEhN1C3 .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648),gzip(gfe),gzip(gfe) > I've had programs overwrite my CST var and similar rudenesses. Another thing that programs rudely stomp to death is the current GRAPH screen. HP says that it should be respected as a user owned resource: Most user RPL graphics commands are directed to the graphics screen, which is the graphics object visible in the plot environment. However, the text screen, the grob visible in the standard stack environment, has the same properties as the graph screen, and should be used by application programs for graphics displays whenever possible, to leave the graph screen as a user owned resource. The EquationWriter does this, for example, as does the HP82211A HP Solve Equation Library card. -- RPLMAN.DOC, section 20, page 94. Hey, howzabout we compile a complete list of user owned resources which should be returned to the user without modification except when necessary and well-documented? So far, this thread has mentioned the following user owned resources: 'STARTUP' 'CST' flag settings (mode settings) Port contents 'STARTOFF' 'TOFF' User key assignments What else should be respected as a user owned resource? I suspect that there are many more. === Subject: Re: startup 49g+/50g > Hey, howzabout we compile a complete list of user owned resources > which should be returned to the user without modification except when > necessary and well-documented? So far, this thread has mentioned the > following user owned resources: Excellent idea! As a previous poster put it, we need a code of programming chivalry. I'll give it some thought. Bill === Subject: Re: startup 49g+/50g > I agree completely. All programs should run (or not :-) and exit > without any changes whatsoever to the user's calculator. I've had > programs overwrite my CST var and similar rudenesses. Another real > annoyance is libraries that have a $config var that runs some fancy > graphics just to show you how clever the programmer is. Of course, > this junk runs on every warmstart. And flags - put all the flags back the way you found them. PUSH and > POP are easy to use. Use an IFERR loop to be sure that POP runs if > there's an unexpected exit. I'm sure there are more... I've always been pretty careful about this with one exception. I would hate to see you rant about the surveying software I did. :-) The installation program goes like this. . . Delete everything in port 0, 1 and 2 Check that HOME has at least 128kb, if not wipe it Pack Bank 8 Pack Bank 9 Pack Bank 10 Install two C libraries that are about ~108 kb each (had to be sure they were aligned properly) Install the rest of the libraries (everything with the two C libs is about 470kb) Reboot and write in a STARTUP, STARTOFF and TOFF Display a graphic while. . . creating folders on the SD if needed checking to make sure the user key assignments include the program specific assignments, if not, install them restoring the hidden directory contents from a saved profile restore instrument configuration, job file configuration and projection settings for GPS startups and launches the main icon screen after checking authentication info of the various modules STARTOFF saves the current job file, backs up some info when you power back on it checks if the communication ports are required to be on and turns them on if needed I hate having to do all of that. Installation is about a 1 min thing if it has to do everything. Startup takes about 7 seconds if it has to do everything, and about .5 seconds normally once it has been done before. Looking at it though, it was either force drastic installation procedures, or deal with people who can't get it to install because they have one little thing wrong. Since most people weren't using the calculator for anything else, I decided it was definitely worth it to do all of that. I agree though that in most cases it isn't necessary. Programs that are 7 kb and have a 4kb animation that wastes 10 seconds every time you run them are the worst. TW === Subject: Re: startup 49g+/50g omgosh wow! I'm lucky I never had to do anything like that, nor would I. I would have demanded my money back and do things by hand, but you did remind me, programs that change key assignments or don't turn off the clock lol. I guess there needs to be some sort of a programming code of chivalry. === Subject: Re: startup 49g+/50g > omgosh wow! I'm lucky I never had to do anything like that, nor would > I. I would have demanded my money back and do things by hand, but you > did remind me, programs that change key assignments or don't turn off the clock lol. Well that is the major difference between what essentially amounts to a re-purposed device for a specific professional task, and just a regular program anyone would be installing. I forgot to mention that a sticker is also stuck onto the keyboard surface so all the regular R/L shift functions are covered. A few are on there, but everything is pretty much covered. Never had anyone complain about not seeing the regular keyboard, but I had many complain at the start when the key assignments were wrong, it wouldn't update the installation, hangups when the C libraries were mis-aligned, and so on. I guess when you pay 1500+ for a device dedicated to a task, you don't really care if your startup variable has been reassigned. . . :-) TW === Subject: HPGCC and keys My program in hpgcc (V2) is something like: while(!keyb_isAnyKeyPressed()); //Wait for a key touche=keyb_getkeyM(0); // get the key (touche means key in french...) while(keyb_isAnyKeyPressed()); // Wait the key is released Then I deal with the key and go back to on other while(!keyb_isAnyKeyPressed()); touche=keyb_getkeyM(0); while(keyb_isAnyKeyPressed()); The problem is that (sometimes, I think it is when I press it quickly..) when I press a key my program acts like if I press the key twice. For me while(keyb_isAnyKeyPressed()); stops but I have still the finger on the key. Anyone have the same problem? Maybe it is not the good way to deals with keys in hpgcc. Other ideas? I am using an hp49g+ with rom version 2.06 (They were problems with first hp49g+ ROM but I don't have this problem in RPL.) Tanguy Briancon === Subject: Re: HPGCC and keys <... The problem is that (sometimes, I think it is when I press it > quickly..) when I press a key my program acts like if I press the key > twice. For me > while(keyb isAnyKeyPressed()); > stops but I have still the finger on the key. The function keyb isAnyKeyPressed() does not have keyboard debouncing, therefore if your keyboard bounces back this function may exit the loop. The keyb getmatrix() function does have a primitive debouncing technique, therefore you are better off using getmatrix and all the M functions, which use keyb getmatrix. Anyone have the same problem? Maybe it is not the good way to deals with > keys in hpgcc. Other ideas? Plenty of them. If you want to wait for a key and you don't need to keep control of your program, use keyb getkeyM(1); which has debouncing and will work properly. It will also wait for the key to be released, so no need for the second loop. If you don't want to lock your program while waiting, you can do the following: keymatrix a; do { keyb getmatrix(&a); if(a.full==0) { // IDLE TIME, DO SOMETHING USEFUL HERE } } while(a.full==0); once you know a key was pressed, you can either use keyb getkeyM(0) to find out what key was pressed or investigate the keymatrix you already have. Using keyb getkeyM() has the advantage that if the key pressed was a shift, it will wait for other key to be pressed and will properly detect shifted keys. If you are writing a game and you only care about a few keys, and they may be pressed simultaneously, it is better to proceed directly from the keymatrix: // (assuming 'a' has the keymatrix with the pressed keys) int key=keyb getnextkey(&a,-1); while(key!=0) { // HERE key CONTAINS THE ID OF A KEY, ONE OF THE KB XXX CONSTANTS // PROCESS YOUR KEY key=keyb getnextkey(&a,key); // OBTAIN THE NEXT SIMULTANEOUS KEYPRESS } // NOW EITHER WAIT FOR ALL KEYS TO BE RELEASED OR CONTINUE YOUR MAIN LOOP, READING THE keymatrix AGAIN If you want to wait for all keys to be released, the following will do: do { keyb getmatrix(&a); if(a.full) { // KEYS ARE STILL PRESSED, BUT YOU CAN USE THIS TIME TO DO SOMETHING USEFUL } } while(a.full); === Subject: Re: HPGCC and keys My program in hpgcc (V2) is something like: while(!keyb isAnyKeyPressed()); > //Wait for a key > touche=keyb getkeyM(0); > // get the key (touche means key in french...) > while(keyb isAnyKeyPressed()); > // Wait the key is released Then I deal with the key and go back to on other while(!keyb isAnyKeyPressed()); > touche=keyb getkeyM(0); > while(keyb isAnyKeyPressed()); The problem is that (sometimes, I think it is when I press it > quickly..) when I press a key my program acts like if I press the key > twice. For me > while(keyb isAnyKeyPressed()); > stops but I have still the finger on the key. Anyone have the same problem? Maybe it is not the good way to deals with > keys in hpgcc. Other ideas? I am using an hp49g+ with rom version 2.06 (They were problems with > first hp49g+ ROM but I don't have this problem in RPL.) Tanguy Briancon I have had similar problems, this is one way I found that works for interactive applications that pause for input: for(;;) { sys slowOn(); //conserve battery while user thinks while(!keyb isAnyKeyPressed()) //key down ; sys slowOff(); //ok, got key, burn battery //process key while(keyb isAnyKeyPressed()); //key up sys waitRTCTicks(2); //fix key bounce } For game like applications that do not pause for input and that require that each action have a keystroke I have been using this: for(;;) { keyb getmatrix(&a); //process keys //e.g.: if(a.full & KB MASK64(KB ADD)) { } while(keyb isAnyKeyPressed()); //key up } === Subject: Re: HPGCC and keys > The problem is that (sometimes, I think it is when I press it > quickly..) when I press a key my program acts like if I press the key > twice. For me > while(keyb isAnyKeyPressed()); > stops but I have still the finger on the key. It sounds to me like you're dealing with key bounce. When you press a key on the calculator (or any keyboard for that mattter), the contacts actually bounce briefly, causing the electrical circuit to open and close very rapidly. This has to be handled in hardware of software - a process called debouncing. I notice that there's a comment in sources/hplib/keyboard/ keyb getkey.c that says HP says the keyboard is debounced in hardware - yeah, right so that function probably handles debouncing the keyboard. You may need to modify the keyb getkeyM.c to do similar logic, or you could try to rework your code to use keyb +getkey() instead. Dave === Subject: Chess clock for the HP48g & HP49g Here is a complete chess clock for our favorite calc: http://hp-ti-calc.zouig.org/HP48-49/ChessClock/cclock.html It can do all the different chess clocks : blitz, Fischer, Bronstein, std. A time handicap can also be set. === Subject: NEOPOLYS 8.1 my HP 50g, both in exact mode and in approx mode: cos(a*t+b) -> L Error: Bad Argument Value cos(2*t+3) -> L Error: Bad Argument Value cos (2.*t+3.) -> (1. 0.)/(1. 0. 9.), i.e. x/(x^2+9), is incorrect. With LAP command of HP 50g CAS: LAP(cos(a*x+b))=(-a*sin(b)+cos(b)*x)/(x^2+a^2) LAP(cos(2*x+3))=(cos(3)*x-2*sin(3))/(x^2+4). Simone. === Subject: Re: Eneloops : . For some reason, : > though, it won't work with them. It doesn't even turn on. If I replace : > one Eneloop with a normal NiMH, it works. : I had the same thing happen twice. The first time was with regular : alkalines, and the problem was that one cell was completely open (it : was ohmless!). The second time was with regular NiMH cells and the : problem was the battery contacts in the calculator - although the : cells seemed to fit perfectly, the calc's positive contact wasn't : quite long enough for certain brands of batteries (it worked fine with : most alkalines). The cure was to pry out the positive contact a : little bit with a tiny screwdriver - I've had no trouble since. : It's pretty silly when a high-tech company can't even manage to make a : reliable batteryholder. But that's how it goes these days - I bought : a box of nails and half of them had the heads on the wrong end. :-) That's ok just save the nails with the head on the wrong end for when you need to nail something the other way!! -- ------------------- Keep working millions on welfare depend on you === Subject: Error Message posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) Hello We are currently trying to fiddle with error messages in a compression program which handle massive number of files. We learned a lot these last few days on how to play with them. We know how to trigger an error, how to trap it, get it displayed, we understand how to mark the stack, get it regenerated to its initial format (if LastArg is enabled), we also know how to make sure the CMD name written on the first line is either a selected UserRPL command or the name of a Library entry. Now i'm looking, at something more difficult, how to modify the CMD field on the first line with a custom string. The idea is that, if during a mass decompression sequence, one of the file cannot be decoded due to lack of memory, the user might interested to know exactly what's the file name, rather than just being informed that decompression failed due to lack of memory. The CMD field is also called LASTCKCMD in many documentations, but there is very little explanation on how it works. It is just said to be automatically updated by CKn and derivatives, there is also a very specific SysRPL entry named ÕRSAVEWORD which seems to be able to affect it, but i couldn't find how. Another possibility would be to use DO$EXIT with ERRTRAP, but this loses the error number and therefore the error message itself (the second line, for example, Insufficient Memory). I guess my exact need is to modify just the first line (the Last CMD), keeping both Error number and message as they are. Any idea ? === Subject: Re: Error Message > Another possibility would be to use DO$EXIT with ERRTRAP, but this > loses the error number and therefore the error message itself (the > second line, for example, Insufficient Memory). If you want to use DO$EXIT you could fetch the string with JstGETTHEMSG from your error/message number. Or use DO#EXIT which directly uses the message number for the error message. > I guess my exact need is to modify just the first line (the Last CMD), > keeping both Error number and message as they are. The Last CMD is saved in =HISTORY1 80798 HISTORY1 -> $ with the most recent CMD history entry 8079D HISTORY2 ->2nd entry HISTORY1 807A2 HISTORY3 ->3rd entry HISTORY1 807A7 HISTORY4 ->4th (oldest) entry HISTORY1 You can easily modify this values with a ML program and store another string into it. HTH, Andreas http://www.software49g.gmxhome.de === Subject: Re: Error Message > If you want to use DO$EXIT you could fetch the string with > JstGETTHEMSG from your error/message number. It seems the following line would work with your suggestion : ERRTRAP :: ERROR@ JstGETTHEMSG Msg Test NEWLINE$&$ !insert$ DO $EXIT ; > Or use DO#EXIT which directly uses the message number for the error message. DO#EXIT seems to not use any input at all for the first line 1, and just displays the standard Line 2. Storing the first line beforehand using EXITMSGSTO did not worked. It seems error message has to be #70000 for the user defined error message to be displayed. > 80798 HISTORY1 -> $ with the most recent CMD history entry > I expect those (in series-dependent locations?) > refer to the last four command _lines_ (that text > which the editor submits when ENTER is pressed) I agree, they can be modified using CMDSTO, but are not used by Error Message === Subject: Re: Error Message > The Last CMD is saved in =HISTORY1 80798 HISTORY1 -> $ with the most recent CMD history entry > 8079D HISTORY2 ->2nd entry HISTORY1 > 807A2 HISTORY3 ->3rd entry HISTORY1 > 807A7 HISTORY4 ->4th (oldest) entry HISTORY1 I expect those (in series-dependent locations?) refer to the last four command lines (that text which the editor submits when ENTER is pressed) unrelated to the last [user] command name which appears in built-in error messages. They are also left unpopulated when Last Cmds is turned off. === Subject: Re: HPGCC on Visual Studio 6.0 posting-account=csTZXgoAAAAbLFyIpZhF6lUYhcG2k6N4 MathPlayer 2.10b; GTB5; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648),gzip(gfe),gzip(gfe) > Is it possible? === Subject: Re: HPGCC on Visual Studio 6.0 > Is it possible? Haven't used visual studio much, but I do know you can define external tools to do compiling. You won't have debugging or anything though. === Subject: Re: MI HP > hey fellas > i just bought i used hp 49g+ > and when i first put on the batteries the hp made a beep and the > screen shows do you want to recover the memory? > click yes or no > Amaury PAdilla -- All normal. Answer NO and start to use your calculator. Roberto === Subject: Re: HPGCC and keys <498a1aa1$0$15121$426a34cc@news.free.fr> posting-account=y6ooGwkAAACoZd171Nq6oGIjQC5mB4Q9 .NET CLR 2.0.50727; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618),gzip(gfe),gzip(gfe) I don't know much about keyb getmatrix(&a): sorry I will RTFM... Basically the keymatrix type is a 64-bit integer, where each bit represents a key. A bit set means the key is currently pressed. The bit number of each key is given by the constants KB xxx. If the whole keymatrix==0, then there are no keys pressed. The function keyb getmatrix() simply reads the state of the keyboard and stores the state of all keys in a keymatrix integer. Nothing complicated, really. === Subject: Re: HPGCC and keys > I don't know much about keyb_getmatrix(&a): sorry I will RTFM... Basically the keymatrix type is a 64-bit integer, where each bit > represents a key. A bit set means the key is currently pressed. The > bit number of each key is given by the constants KB_xxx. If the whole > keymatrix==0, then there are no keys pressed. > The function keyb_getmatrix() simply reads the state of the keyboard > and stores the state of all keys in a keymatrix integer. Nothing complicated, really. > In fact I still have key bounce problems using keyb_getkeyM(1): is it normal? My code looks like while(1) {key=keyb_getkeyM(1) switch (key){ case KB_A ... case KB_ENT goto end } end: Is there anything wrong in this? (the goto is not pretty but it is an another problem...) Tanguy === Subject: HP50 and triglyphs Where should I look for a list of all the triglyphs? You know, where program delimiters are entered as << and >> ? Sometimes I upload and get Xemacs to show 215 217 style special characters, and sometimes the triglyphs (ex: ->) but am not sure what is controlling this behaviour. Have tried setting TRANSIO to 0,1,2,3... So I had in mind an Xemacs macro to convert both ways and make a special font that displays them in Xemacs. But had the feeling that this has all been done before? I am not finding anything about HP50 and triglyphs on the web--So I'm asking here: Anybody point me the right direction? === Subject: Re: HP50 and triglyphs > Where should I look for a list of all the triglyphs? You know, where program delimiters are entered as << and >> ? > Sometimes I upload and get Xemacs to show 215 217 style special characters, and sometimes the triglyphs (ex: ->) > but am not sure what is controlling this behaviour. Have tried setting TRANSIO to 0,1,2,3... So I had in mind an Xemacs macro to convert both ways and make a special font that displays them in Xemacs. > But had the feeling that this has all been done before? I am not finding anything about HP50 and triglyphs on the web--So I'm asking here: Anybody point me the right direction? Also, see these posts: === Subject: Re: HP50 and triglyphs > Where should I look for a list of all the triglyphs? You know, where program delimiters are entered as << and >> ? > Sometimes I upload and get Xemacs to show 215 217 style special characters, and sometimes the triglyphs (ex: ->) > but am not sure what is controlling this behaviour. Have tried setting TRANSIO to 0,1,2,3... So I had in mind an Xemacs macro to convert both ways and make a special font that displays them in Xemacs. > But had the feeling that this has all been done before? I am not finding anything about HP50 and triglyphs on the web--So I'm asking here: Anybody point me the right direction? > Num Sym Description --- --- ----------- 128 <) angle symbol 131 v/ square root 132 .S integral symbol 133 GS Greek Sigma (GSLIST) 135 pi pi 136 .d derivative symbol 137 <= less or equal 138 >= greater or equal 139 =/ unequal 141 -> right arrow (->LIST, -> a b c) 142 <- left arrow (<-local) 143 |v down arrow (|vMATCH) 144 |^ up arrow (|^MATCH) 156 PI capital pi (PILIST) 159 oo infinity 171 << program delimiters 187 >> 092 backslash Hope this helps! Mark === Subject: Stacker4x compression driver posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) Hello Bruno and I are pleased to propose to HPcalc user community the first public version of a compression driver for HP48, 49 & 50, named Stacker4x, in honor to Stack electronics 90's product, Stacker. Stacker, and is successor NTFS compressed format, allow users to keep their data on hard disk in compressed format, while still accessing them transparently as if they were normal. Stacker4x allows the same for the HP4x user. To provide an agreeable user interactivity experience, Stacker4x compress and decompress very fast. A specific derivative of LZD, based on FastLZD v0.4a, is used in this version. Features available : - Can compress & store any object - Objects are automatically decompressed & run - Can recover object in original format - Can save & extract from/to extension ports (Note : SD Card port :3: intentionnally filtered out) - Automatic recursive compression/decompression on directories - Can stop compression/decompression anytime by pressing a key - Display memory savings - Default to STO when not enough memory to compress - Mass compression/decompression utilities provided You can download the software at this website : http://HPUtils.Webhop.org or http://phantasie.tonempire.net/utilitaires-f7/ or http://phantasie.tonempire.net/utilitaires-f7/stacker4x-compression-driver-t 75.htm#83 Direct Download : http://img24.xooimage.com/files/5/a/4/stacker4x-v1-ad93e9.zip As always, user feedback are always welcomed, you can used this Newsgroup post or website to provide your comments. Yann === Subject: Re: SAT not recognised by mobo after been on USB BANG! Maailmankaikkeuden historia./Neutriino. Neutriinot ovat pieni.8a ja hyvin kevyit.8a hiukkasia. Niit.8a syntyy ydinfuusiossa, jotka toimivat t.8ahtien (esimerkiksi Auringon, perusydinvoimalan) energian l.8ahtein.8a. Useiden vuosien ajan neutriinojen oletettiin olevan massattomia, mutta nyky.8a.8an tiedet.8a.8an ett.8a niill.8a on pienen pieni massa, tosin liian pieni pime.8an materian ongelman selitt.8amiseen. Massan olemassaolo ratkaisi pitk.8a.8an mieli.8a askarruttaneen neutriino-ongelman, jonka mukaan havaitsimme v.8ahemm.8an neutriinoja Auringosta kuin teorian mukaan olisi pit.8anyt. Pieni massa antaa neutriinon vaihtua kolmen olomuodon- elektronin, myonin ja tau-neutriinon- v.8alill.8a sen tullessa Auringosta maahan. *T.8ass.8a on siis keskeist.8a tajuta, ett.8a kvanttiydinfyysikkojen neutraaliksi aiemmin v.8a.8arin ilmoittama ydinvoimalatehokadon 17% neutriinos.8ateily ymp.8arist.9abiotooppin on my.9as potentiaaliltaan siis yll.8a mainitusti elektronis.8ateily.8a. Ja kuten on syyt.8a tiet.8a.8a elektronis.8ateily tunnetaan paremmin ns. beettas.8ateilyn elektronituotoksena! J.8alleen huomaamme miten h.8arskisti ydinala valehtelee aiheesta. Ydinvoimalassa mittareissa n.8akym.8at.9an neutriinos.8ateily l.8ap.8aisee kaikki s.8ateilysuojat se sen j.8alkeen muuttujana synytt.8a.8a .8a.8arimm.8aisen tuhoisaa beettas.8ateily.8a. Toki sen lis.8aksi, ett.8a neutriinon osuessa protoniin syntyy 1 000 000eV gammaterssi my.9as. Aiemmat havaintolaitteet pystyiv.8at havaitsemaan vain kaikkein kevyint.8a tyyppi.8a. Neutriinojen ilmenemismuotojen lukum.8a.8ar.8a voidaan ennustaa alkur.8aj.8ahdysteoriasta. Samalla haastetaan tiukasti teoria, jonka mukaan maailmanmkaikeus alkoi kuumassa tihe.8ass.8a tilassa. Neutroni. Atomiytimet koostuvat kahden tyyppisist.8a hiukkasista, neutroneista ja protoneista, ja n.8am.8a molemmat hiukkastyypit taas koostuvat kolmesta kvarkista. Neutronit painavat melkein yht.8a paljon kuin protonit, mutta ovat varauksettomia. Supernovar.8aj.8ahdyksen .8a.8arimm.8aisiss.8a olosuhteissa protonit ja elektronit voivat yhdisty.8a ja muodostaa neutroneja, jolloin kuolevan t.8ahden ytimest.8a syntyy tihe.8a neutronit.8ahti. Neutronit.8ahden maksimimassan oletetaan olevan noin kahdeksan Auringon massaa: t.8at.8a suuremmat luhistuisivat mustiksi aukoiksi. === Subject: Re: startup 49g+/50g By the way, Stacker4x falls in this category. It remaps a few user-key, so that the casual user does not need to think about it : his data is getting compressed/decoded on the fly without the need to do anything special. This is not a side-effect, user-key definition is the goal of the program. So i guess this must be clearly documented, and a way to cleanly uninstall these settings must be provided. This is what's documented in the readme on this issue : **************************************************************************** ************************* Modified Calculator settings : ------------------------------ Stacker4x triggers the User Keyabord on reset (ON+C), using an alarm interrupt. (Note : STARTUP file is not modified.) A one second delay is intentionnally left, which can be used to prevent Stacker4x from starting. A simple manual method would be to trigger UserKeyboard (LeftShift +Alpha). A more complex one would to be to erase or disable alarm events. When Stacker4x is enabled, using zMODE, a few users keys are defined. They are : STO, RCL, and all Shift-Menu keys. A Message warns the user (Stacker Mode is enabled) When zMODE is used to stop Stacker4x, all associated user keys are deleted. A Message informs the user (Stacker4s is disabled) You can also manually switch user keyboard on & off, using the normal shoft+alpha combination. In this case, Stacker4x user key definitions remain in memory. **************************************************************************** ************************* === Subject: Re: startup 49g+/50g > In User RPL, use DEPTH ->LST to save the stack, > and OBJ-> DROP to restore it. ->LST is a Development Library command on 49/50 series only, compilable only if library 256 is attached. ->LIST is a UserRPL command common to all HP48/49/50, so one might use the latter for greatest generality, and assurance that the program will always compile properly. === Subject: Re: He was not immediately the wiser Aika huvittavaa, ett.8a tiedotusv.8alineet ovatr kiinnostuneet vain Kallin taustamaksajista, miksi? Miksi ihmeess.8a ei oteta esille esim. Anne Holmlundin ja vaikka nyt Paavo Lipposen kaltaisten kiistatta tiedettyj.8a ydinalan madonlukukytk.9aksi.8a SDP:n vaalien alla ja noin? Niist.8a voisimme saada enemm.8an kuin mukaansatempaavaa viitett.8a siihen mist.8a esim. Vapaavuori helsinkikeskeisen ydinintonsa ja Suomen maakuntien sy.9antiins.8a potkun ottaa? Nimitt.8ain n.8aiden kaikien taustasponsorit kun ymm.8art.8a.8akseni on JO valmiiksi lehdist.9alle tiedotettuna! Mit.8a hy.9aty.8a edes olisi lain kirjaimella, jossei asiasta kaikkein kiinnostuneimmille , eli .8a.8anest.8ajille asti sponsseista reality.8a tulisi? Ai niin pahus tosiaan, ei ne tulekkaan!.. ..( Kallia moitti muutamia viikoja sitten mm. TVO:n johtajana tunnettu P. Simola. H.8an oli kovin k.8a.8armeistynyt siit.8a, ett.8a heid.8an lukuisat lanserauksensa seutukuntien politikoille olivat k.8apyis.8asti kuivuneet kasaan. Pertti prutisi pahasti siit.8a, ett.8a OL-3 hanke meni kuin kiulu sikalaan, mutta t.8am.8a OL-4, niin sille l.9aytyi TVO:n suunnattomaksi kauhuksi tykitt.8av.8a.8a kaatajaa massoittain. Oi voi ja j.8ai sen verran ydinalala hampaankoloon, ett.8a p.8a.8attiv.8at silt.8a seisomalta silkaksi kostoksi erottaa Kallin my.9as , .. .oi ja niin tosiaan Forttumin isopalkkavirasta.. ..Uups, jaa niin ei meill.8a n.8aist.8a mahdolisista sponssi Posivoista ja Fennovoimista saa miss.8a.8an virallisesti haastella. Voi kauhistus sent.8a.8an juu.. .! === Subject: MI HP i just bought i used hp 49g+ and when i first put on the batteries the hp made a beep and the screen shows do you want to recover the memory? click yes or no doesnt matter what i clicked, still turning it off... i dont know if i should return it or throw it away or what? please help me i'll really appreciate it... === Subject: HPGCC for 48gII? Does HPGCC support the HP 48gii? I'm having trouble getting a program to run on it when I know the program runs on the 50g. The HPGCC home page says it supports the ARM based calculators, but a wikipedia I just got the 48gii and it appears to be an older version with the serial cable and no USB support. VERSION returns: Version HP49-C Revision #1.23 Dave === Subject: Re: MI HP > screen shows do you want to recover the memory? > click yes or no > doesnt matter what i clicked, still turning it off... You might be experiencing one of RPL's dumbest bugs. Some ROM versions don't do anything if you press NO directly. You have to press any other key first (other than YES or NO) and *then* press NO. It's worth a try. === Subject: Re: HP 50g keyboard layout Bill Markwick suggests a key on the side for easy thumb access. Methinks that's a good idea. Many computer mice also have side- mounted buttons for the same reason. Buttons mounted on the side (or back?) of an HP handheld should be user-definable, like side-mounted mouse buttons are. That'd be cool. === Subject: Re: HLP49 > How to copy examples from HLP49 to stack? Put the cursor at the beginning of the example and press BEGIN (RS- APPS). Move the cursor to the end of the example and press END (RS- Mode). Press COPY (RS-VAR). Exit HLP49 and press PASTE (RS-NXT). The example will be on the command line. Press ENTER to put it on the stack. Now you can store it with any name you want, or if it doesn't need any arguments, you can press EVAL to run it. (Use PASTE to get it back again.) === Subject: Re: HLP49 >> How to copy examples from HLP49 to stack? Put the cursor at the beginning of the example and press BEGIN (RS- >APPS). Move the cursor to the end of the example and press END (RS- >Mode). Press COPY (RS-VAR). Exit HLP49 and press PASTE (RS-NXT). The example will be on the >command line. Press ENTER to put it on the stack. Now you can store >it with any name you want, or if it doesn't need any arguments, you >can press EVAL to run it. >(Use PASTE to get it back again.) === Subject: Re: HP50g wireless starts on by itself What is wireless, and what indicates that wireless is on ? === Subject: Re: HP50g wireless starts on by itself Replacing the low batteries will cure everything. http://www.youtube.com/watch?v=IRSylpEusQE === Subject: Re: HP50g wireless starts on by itself to elaborate a bit more on this: I, too, have been bitten by this hm nonstandard icon. It does not mean wireless, it stands for alert, which is, batteries low. They could've just put in a low battery sign m. > Replacing the low batteries will cure everything. http://www.youtube.com/watch?v=IRSylpEusQE === Subject: Re: HP50g wireless starts on by itself to elaborate a bit more on this: I, too, have been bitten by this hm > nonstandard icon. It does not mean wireless, it stands for alert, > which is, batteries low. They could've just put in a low battery > sign > > Replacing the low batteries will cure everything. >http://www.youtube.com/watch?v=IRSylpEusQE > === Subject: Re: debug4x garbled screen and can't load 50g on emu48 1.47 >> I just downloaded and installed debug4x, and noticed that pressing on-d >> on emu-50g that comes with it shows the bottom screen garbled, I did 0n-D here with no problem. Whay do you mean by bottom screen ? > What are you trying to do? Just to make sure i uninstalled both emu48 and debug4x. Step-by-step: downloaded http://www.debug4x.com/Debug4x_b136.exe standard install chose not to run the demo-project, and not to view the text file press finish start menu->HP 50,49,48 Development Kit->Emu-50g right-click on the ON-key, left-click the D-key result-> ftp://ftp.ua.pt/incoming/steve/screen.GIF as you can see the bottom shows the file-browser also, this is not the screen i get on my real 50g the behaviour is diferent if i press ON-F too. I wanted to see the boot-sector version but i can't because it just won't go into the update-mode following reset. Steve Sousa === Subject: Needs some helps Hi I made a dynamical geometry program (like geogebra or geoplan) in C for the hp49g+. Of course it is far away of geogebra... But you can do some interesting things: -draw a curve imediately then zoom in/out or change the windows very fast... - Draw a geometrical figure like: let be (AB) be line (droite en francais ) then C' the middle of [AB]. Draw the line perpendicular to (AB) by C' and so one... And then you move A (with the arrows keys) and then all the figure just goes right! (the perpendicular to (AB) moves and so on...). (if you don't understant you can try geogebra: it is free software...). [FRENCH] On peut tracer une triangle ABC puis tracer les, m.8edianes, m.8ediatrices, hauteurs (tout cela en niveaux de gris) puis ensuite bouger un point du triangle (ABC) et on a les dessins qui se refont parfaitement. So the questions are: -is there anyone interesting in this project? -le programme est pour le moment en francais (that's french stuff guys!!) so come on! - This program is in french. What is the best way to have a program in two languges: I have a lot of sprintf(s, en francais,...) or hpg_draw_text(coucou,ici, la). ? Some include? Tanguy (see ggrobedit and cgrobetid and wwww.hpcalc.org) === Subject: User Keyboard I'm looking for a way to activate the user keyboard during restart sequence (ON+C). When the calculator is running, i just need to do : SIXTYTWO SetSysFlag When the restart sequence is triggered, all libraries get a chance to start a config program. So i tried to activate User Keyboard during this sequence. I'm sure the program was started, but for some reason, the user keyboard was not activated by the end of restart sequence. I guess there must be something which either prevent the user keyboard from being activated, or more probably, that system flags are being initialised at a later stage of the restart sequence, thus erasing my -62 flag. Is there a way to get around this limitation ? === Subject: Re: User Keyboard I'm looking for a way to activate the user keyboard during restart > sequence (ON+C). When the calculator is running, i just need to do : > SIXTYTWO SetSysFlag When the restart sequence is triggered, all libraries get a chance to > start a config program. > So i tried to activate User Keyboard during this sequence. I'm sure the program was started, but for some reason, the user > keyboard was not activated by the end of restart sequence. I guess > there must be something which either prevent the user keyboard from > being activated, or more probably, that system flags are being > initialised at a later stage of the restart sequence, thus erasing my > -62 flag. Is there a way to get around this limitation ? > Store the following program in a variable named STARTUP in your home directory: << -62 SF>> === Subject: Re: User Keyboard > Store the following program in a variable named STARTUP in your home > directory: << -62 SF>> This unfortunately does not seem to work on HP48, although it works ok on newer HP50G. If possible, I'm looking for a method which would stay valid for all 4x calculators models === Subject: Re: User Keyboard > [STARTUP variable] unfortunately does not seem to work on HP48, > although it works ok on [HP49G and all subsequent 49/50 series] Nothing like this was built in, but see (besides Raymond's, which are always the best :) http://www.hpcalc.org/details.php?id=5345 [OT48, W. Rautenberg] http://www.hpcalc.org/details.php?id=6689 [Autoexec, maybe not on warmstart] Does MetaKernel for HP48 have 'STARTUP' variable? (after all, shouldn't MK turn any HP48 into a virtual HP49/50, except no HPGCC? :) http://www.hpcalc.org/details.php?id=213 the 49 it's good, the 48 with mk is the best, says one reviewer :) === Subject: Re: User Keyboard > Store the following program in a variable named STARTUP in your home > directory: << -62 SF>> This unfortunately does not seem to work on HP48, > although it works ok on newer HP50G. If possible, I'm looking for a method which would stay valid for all > 4x calculators models Maybe with :: SIXTYTWO SetSysFlag ; from a library. The libraries contains one variable called $CONFIG and is called after the system is restarted. Seq: Restart -> $CONFIG1 ->$CONFIG2 -> $CONFIG3 -> ... (1, 2, 3, ... are the libraries) Another advanced programs are available, Raymoond Hellstern? - Gaak - === Subject: Re: User Keyboard Gaak <..> schrieb im Newsbeitrag > Store the following program in a variable named STARTUP in your home > directory: << -62 SF>> This unfortunately does not seem to work on HP48, > although it works ok on newer HP50G. If possible, I'm looking for a method which would stay valid for all > 4x calculators models Maybe with :: SIXTYTWO SetSysFlag ; from a library. The libraries contains one variable called $CONFIG and is called after the system is restarted. Seq: Restart -> $CONFIG1 ->$CONFIG2 -> $CONFIG3 -> ... (1, 2, 3, ... are the libraries) > Another advanced programs are available, Raymoond [..]? > Yep, my SpeedUI configurator, which contains STARTUP prog support;-) However my CF.LIB may be kinda overkill for this task, since there are many other things included. For things like setting flags at warmstart it will absolutely be sufficient to add the discrete SysRPL code to the config code of your lib. Like ASSEMBLE =XXcfg RPL :: [#] XXROMID TOSRRP ( *Autoattach* ) FIVE SetUserFlag ; Which will simply set user flag 5 after each cold- or warmstart. The TOSRRP line is not mandatory, if you don't want the lib beeing referenced in ROMPTAB... HTH Raymond Del Tondo (formerly known as R. Hellstern;-) === Subject: Re: User Keyboard This is indeed exactly what i tried to do. I'm sure that the $CONFIG program is run, because other parts of it have intended effects. However, specifically regarding UserKeyboard system Flag, it does not work, the keyboard start in normal mode. I don't know if the problem is specifically limited to 62 SysFlag. My current assumption is that something, at a later stage of the warmstart process, is intentionnally disabling User Keyboard system flag, maybe for safety, maybe as a side-effect of a higher-number library. But of course, i may be wrong. === Subject: Re: User Keyboard > Store the following program in a variable named STARTUP in your home > directory: << -62 SF>> This unfortunately does not seem to work on HP48, > although it works ok on newer HP50G. If possible, I'm looking for a method which would stay valid for all > 4x calculators models Oh, sorry. I assumed you were using a 49g(+) or 50g. I don't know how to do it on a 48g(x). === Subject: Re: WHIRL Program > Nice looking, and very fluid on HP48SX, quite a great achievement > Gustavo ! Documentation says: Original author unknown Exists one comment from Mika to Joe that says: I liked one of the effects in the French demos so much that I added rotation in the opposite direction and straight out movement. Does Anyone know the original author of this demo? - Gaak - === Subject: I cant find FBoxW I«m writing an small drawing program and the compiler cant find the FBoxW command. I'm using Emacs 2.11a on Emu48 1.42+ emulating a hp 50g rom 2.09. === Subject: Re: I cant find FBoxW FBoxW GETADR says: Non existing entry. Try FBoxB. FBoxG1 and FBoxG2 are grayscale commands. - Gaak - > I«m writing an small drawing program and the compiler cant find the > FBoxW command. I'm using Emacs 2.11a on Emu48 1.42+ emulating a hp 50g rom 2.09. === Subject: Re: I cant find FBoxW > I«m writing an small drawing program and the compiler > can't find the FBoxW command. The standard extable library contains these symbols, (including aFBoxW) about which I don't know nothin' more: FBoxB FBoxG1 FBoxG2 ------ FBoxXor LBoxB LBoxG1 LBoxG2 LBoxW LBoxXor aFBoxB aFBoxG1 aFBoxG2 aFBoxW aFBoxXor aLBoxB aLBoxG1 aLBoxG2 aLBoxW aLBoxXor It seems interesting that the one missing is the one you are looking for; perhaps Dmitri Ivanovich Mendeleev could explain this gap in the otherwise periodic table of these ROM elements? Good luck! http://www.aip.org/history/curie/periodic.htm http://www.rsc.org/education/teachers/learnnet/periodictable/pre16/develop/m endeleev.htm == Subject: Re: I cant find FBoxW > FBoxW : Make a white filled rectangle. > HP49/50 Entry : #255D3h According to XREF49.txt, FWIW, that's a/k/a FBoxG1, but what's in a name, anyway? ----- 255D3 FBoxG1 ----- 255D8 FBoxG2 ----- 255DD FBoxB ----- 255E2 FBoxXor ----- 255E7 LBoxW ----- 255EC LBoxG1 ----- 255F1 LBoxG2 ----- 255F6 LBoxB ----- 255FB LBoxXor ----- 26B34 aFBoxB ML ----- 26B3B aFBoxW ML ----- 26B42 aFBoxG1 ML ----- 26B49 aFBoxG2 ML ----- 26B50 aFBoxXor ML ----- 26B57 aLBoxB ML ----- 26B5E aLBoxW ML ----- 26B65 aLBoxG1 ML ----- 26B6C aLBoxG2 ML ----- 26B73 aLBoxXor ML 'Tis but thy name that is my enemy; -- Thou art thyself though, not a Montague. What's Montague? It is nor hand, nor foot, Nor arm, nor face, nor any other part Belonging to a man. O, be some other name! What's in a name? That which we call a rose, By any other word would smell as sweet; So Romeo would, were he not Romeo call'd, Retain that dear perfection which he owes Without that title: -- Romeo, doff thy name; And for thy name, which is no part of thee, Take all myself. Juliet, act ii, scene ii http://en.wikiquote.org/wiki/Romeo_and_Juliet === Subject: Re: I cant find FBoxW perhaps Dmitri Ivanovich Mendeleev could explain this gap in the otherwise periodic table of these ROM elements? hehehe ver funny > but what's in a name, anyway? You are right Mr. Meyers === Subject: Re: I cant find FBoxW > FBoxW : Make a white filled rectangle. HP49/50 Entry : #255D3h Well, when I compile :: PTR 255D3 ; the result is FBoxG1. I got surprised when i saw this, but then I notice that FBoxW and FBoxG1 have the same address. === Subject: Re: HP50g wireless starts on by itself > to elaborate a bit more on this: I, too, have been bitten by this hm > nonstandard icon. It does not mean wireless, it stands for alert The ((o)) annunciator is used both for due timer reminder alarms (any alarms having a message string as their object), and for low battery The alternative message about low battery occurs only upon wake up (or warmstart?), and in HP48 series it also reports low battery levels (nor for a removed coin cell). Otherwise a main battery test occurs, perhaps once per minute, and the ((0)) indicator comes on when battery is low. There is also an actual wireless annunciator -- a kind of arrow-like thing, which turns on when infrared transfer is taking place (perhaps other I/O also). The association of an unidentified icon with an observed low battery message, plus recovery after being off for a while, suggests that low battery was the actual culprit in this case, although there really also exists a genuine wireless situation, of an entirely different nature than expected by those who have lived with wireless computers and phones as constant close companions, and aren't on quite as familiar terms with the calculator usage guides, or even its list of basic capabilities and features :) Are there any bluetooth calculators yet? Yep: http://www.engadget.com/2005/09/14/casios-wireless-usb-calculator-keypad/ http://www.ciao.com/Interlink Electronics Bluetooth Calculator Keypad VP6270 15545330 http://www.eurotech.com/EN/innovation.aspx?pg=wearable Wi-Fi, Bluetooth and GPS technologies -- bases loaded :) And passing mention of the almost unheard of HP wireless (IR), after long discussion between people who doubt they even exist: http://www.physicsforums.com/archive/index.php/t-167531.html === Subject: Re: HP50g wireless starts on by itself > to elaborate a bit more on this: I, too, have been bitten by this_ hm_ >> nonstandard icon. It does not mean wireless, it stands for alert The ((o)) annunciator is used both for due timer reminder alarms > (any alarms having a message string as their object), > and for low battery The alternative _message_ about low battery occurs only upon wake up > (or warmstart?), and in HP48 series it also reports low battery levels > (nor for a removed coin cell). Otherwise a main battery test occurs, perhaps once per minute, > and the ((0)) indicator comes on when battery is low. I think it's much more frequent than that. I recall, when a battery was marginal, that the annunciator would come on when I pressed a key (causing the CPU to draw more current as it handled the keystroke) and go off again when the calculator was done executing the command. Presumably the internal resistance of the batteries was such that under load, the voltage dropped below whatever threshold was used for the annunciator. > There is also an actual wireless annunciator -- > a kind of arrow-like thing, which turns on > when _infrared_ transfer is taking place > (perhaps other I/O also). Yes, I believe it comes on for all I/O. So not really a wireless annunciator per se, but rather communications. === Subject: Re: debug4x garbled screen and can't load 50g on emu48 1.47 > Just to make sure i uninstalled both emu48 and debug4x. > Step-by-step: > downloaded http://www.debug4x.com/Debug4x_b136.exe > standard install > chose not to run the demo-project, and not to view the text file > press finish > start menu->HP 50,49,48 Development Kit->Emu-50g > right-click on the ON-key, left-click the D-key > result-> ftp://ftp.ua.pt/incoming/steve/screen.GIF > as you can see the bottom shows the file-browser > also, this is not the screen i get on my real 50g > the behaviour is diferent if i press ON-F too. > I wanted to see the boot-sector version but i can't > because it just won't go into the update-mode following > reset. Interesting that it does not occur with some of my other EMU files. I will investigate and report back soon. === Subject: Re: debug4x garbled screen and can't load 50g on emu48 1.47 >> Just to make sure i uninstalled both emu48 and debug4x. >> Step-by-step: >> downloaded http://www.debug4x.com/Debug4x_b136.exe >> standard install >> chose not to run the demo-project, and not to view the text file >> press finish >> start menu->HP 50,49,48 Development Kit->Emu-50g >> right-click on the ON-key, left-click the D-key >> result-> ftp://ftp.ua.pt/incoming/steve/screen.GIF >> as you can see the bottom shows the file-browser >> also, this is not the screen i get on my real 50g >> the behaviour is diferent if i press ON-F too. >> I wanted to see the boot-sector version but i can't >> because it just won't go into the update-mode following >> reset. > Interesting that it does not occur with some of my other EMU files. > I will investigate and report back soon. Well I looked through all my 50g+ roms for the EMU and they all show the same problem with ON-D. What I had never noticed before is that ON-A-F does not clear the calc either - it runs some diagnostic. ON-D varies in what shows on the screen depending on what is in the Flash. As you mentioned it is part of a Filer screen. My guess is that the ON combination screens are invoking some code which uses op-codes or ARM code that has not been changed for the emulator. Most things do emulate quite nicely but this EMU does not do the ARM stuff and here is a good example. So, Steve, I do not think there is a solution for you. -- - - - - - - - - - - - - - - - - Bill Graves RKBA! bgraves@ix.netcom.com === Subject: Re: debug4x garbled screen and can't load 50g on emu48 1.47 <3t6dna21PtLzdejUnZ2dnUVZ_sHinZ2d@earthlink.com> <4977b0b6$0$57670$892e0abb@auth.newsreader.octanews.com> posting-account=HQcyKwkAAAAfyVM-3k2cuaNBENqZAwPy Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) > I just downloaded and installed debug4x, and noticed that pressing on-d >> on emu-50g that comes with it shows the bottom screen garbled, > I did 0n-D here with no problem. Whay do you mean by bottom screen ? > What are you trying to do? Just to make sure i uninstalled both emu48 and debug4x. > Step-by-step: > downloadedhttp://www.debug4x.com/Debug4x b136.exe > standard install > chose not to run the demo-project, and not to view the text file > press finish > start menu->HP 50,49,48 Development Kit->Emu-50g > right-click on the ON-key, left-click the D-key > result->ftp://ftp.ua.pt/incoming/steve/screen.GIF > as you can see the bottom shows the file-browser > also, this is not the screen i get on my real 50g > the behaviour is diferent if i press ON-F too. > I wanted to see the boot-sector version but i can't > because it just won't go into the update-mode following > reset. > Steve Sousa Emu48 works fine for 48G and 49G calculators (Saturn) Emu48+ is a Emu48 extended that supports 131x80 pixels but some parts is not correctly displayed. The ROM is made to simulate real behavior, but it isn't the real ROM. The new machines (ARM) contains Saturnator. So, some problems are available at Emu48+ with big screen. Remember that Debug4x contains the ROM for 50g (Emulator version). - Gaak - === Subject: Missing Addresses for HP Calculator Calendar Recipients - Can You Help? posting-account=K31tcwgAAABVnT_oG3A7BQonvJCmOPn4 Well, all the free HP Calculator Calendars for year 2009 have been mailed to those HHC2007 conference attendees for which we have mailing addresses. That still leaves some for whom addresses are missing. We'd like to send the calendars out if only we knew where to send them. The people for whom we need addresses are: Martin Cohen Joel Kolstad Ricardo Lazzari Gary Cain Jean-Yves Avenard Karl Moerder Carl Morris Hey guys - can you please contact me at jakes pahhc org and send me your mailing address? Jake Schwartz P.S. - Info on the calendar may be obtained at http://www.pahhc.org/2009/Calendar.htm and info on obtaining DVDs of any of the HP Calculator conferences from the past 23 years is available at http://www.pahhc.org/video.htm . === Subject: Looking for a programming project I'm toying around with my 50g and looking for a programming project. Does anyone have any suggestions or need anything simple? Having a blast programming a calculator after being away from them for 25 years, Dave === Subject: Re: Looking for a programming project > I'm toying around with my 50g and looking for a programming project. > Does anyone have any suggestions or need anything simple? Having a blast programming a calculator after being away from them for > 25 years, > Dave I propose the c.s.hp48 roms project. -What is it? It's a community effor to create a de-BUG-able source for the 49/50 calculators. -But how? Create a source file of the form: SupEntry NIBHEX 0123456789ABCDEF . . NIBHEX 0123456789ABCDEF nextSupEntry NIBHEX 0123456789ABCDEF . . NIBHEX 0123456789ABCDEF etc... Were the nibhex strings contains a dump of the rom being worked on. -I still don't see how that helps? Well, such rom *has* to compile equal to the original using current tools. Then, as most of the regulars here disassemble the rom while working on projects or just for fun, instead of saving their work on a file on their pc, they would replace the nibhex strings with their dissasembly, if it is reasonable, test if the file compiles as the original, and if it does submit it to the project. That helps, because many times, when people have found a bug they poke around the rom trying to find it, when that happens, such person could submit a patch, and after peer review and aproval it gets compiled as the next c.s.hp48-rom-unofficial. There is no need for the whole original sources to do this, and it doesn't have the inconsistencies of simply trying to assemble the (dumb) dump from a disassembler. Yes it does have the drawback of not seeing the whole-picture but it might give good results for lots of small stuff. What do you think? Steve Sousa === Subject: Re: Looking for a programming project > I propose the c.s.hp48 roms project. -What is it? It's a community effor to create a de-BUG-able source for the 49/50 > calculators. Steve, That's funny because I had a very similar idea. Many years ago I worked on a binary translator that took programs like the ROM, disassembled them, translated to another instruction set, optimized the result and poof! Now you had a program that ran on another architecture. So when looking at the HP50g, I wondered how much of the ROMs are RPL and how much are still Saturn assembly and could you convert the Saturn Assembly to ARM and really make it fly.... If anyone from HP is reading this, consider that you could probably tap a lot of volunteer talent on the net for projects like this. Actually, I think an even better project would be an RPL optimizer. As many people have pointed out, User RPL is slow because each instruction has to check for the number of arguments, their types etc. etc. But it wouldn't be too hard to track the number and type objects on the stack and, when they are well known, convert the User RPL into equivalent SysRPL that assumes the correct type/number of objects on the stack. I'm quite surprised that no one has done this yet. Or maybe I just haven't found it. === Subject: Re: Looking for a programming project you are always welcome to create an additional dataset for my TreeBrowser. Creating a dataset is quite simple and can be done either with debug4x or on the calculator. More inforation is available on my website http://www.software49g.gmxhome.de Andreas === Subject: Re: Looking for a programming project posting-account=KxEIGwoAAAALMxy6hykxLK1wPdiyuNkK Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) > you are always welcome to create an additional dataset for my > TreeBrowser [...] quite interesting. I'll see if I can find some field of study that isn't already covered - if such a thing exists!!! :) :) :) Dave === Subject: Counting objects with an HP48g + Arduino + Cheap laser pointer http://www.youtube.com/watch?v=n6edRkNRSOk :) very nice to see my old 48g in action 50g will work the same way with the new custom serial port? anyone knows? === Subject: Re: hp 35s > eradicate for the last hp 35s No, they're still there. See: HP has never publicly acknowledged or addressed any of these bugs, unfortunately -- this is not your father's HP calculator division. > Post on this cal are rare > nobody seem to program with it > or may be it's to easy !! Since it doesn't have any I/O besides the screen and the keys (or the ability to be programmed in assembly language), I think that most people are just writing their own small programs. I believe HP does have a (freely downloadable) solutions manual that provides many useful programming examples, and at one time I believe there was at least one commercial book of programs marketed. ---Joel === Subject: Re: hp 35s | > eradicate for the last hp 35s | | No, they're still there. See: | | HP has never publicly acknowledged or addressed any of these bugs, | unfortunately -- this is not your father's HP calculator division. | | > Post on this cal are rare | > nobody seem to program with it | > or may be it's to easy !! | | Since it doesn't have any I/O besides the screen and the keys (or the ability | to be programmed in assembly language), I think that most people are just | writing their own small programs. I believe HP does have a (freely | downloadable) solutions manual that provides many useful programming | examples, and at one time I believe there was at least one commercial book of | programs marketed. | | ---Joel | | very interesting === Subject: Re: hp 35s you could try on the hpmuseum forum (www.hpmuseum.org), and check the forum archves for related threads. There are (or were) people spending time on the 35s. HTH Raymond Denis schrieb im Newsbeitrag > eradicate for the last hp 35s > Post on this cal are rare > nobody seem to program with it > or may be it's to easy !! > Denis === Subject: Re: hp 35s Merci Denis | | you could try on the hpmuseum forum (www.hpmuseum.org), | and check the forum archves for related threads. | | There are (or were) people spending time on the 35s. | | HTH | | Raymond | | Denis schrieb im Newsbeitrag | > eradicate for the last hp 35s | > Post on this cal are rare | > nobody seem to program with it | > or may be it's to easy !! === Subject: Re: HP chip model planes >> Thought I'd share this I came across on another group: >>http://www.elcafevirtual.com/julio/ > Model planes made entirely from old HP calculator chips and parts. > Dave. > I wonder how many collector's item HP machines were destroyed to make >> these works of art. None. The Lockheed F-104 Starfighter was the second of four I made more > than 30 years ago with defective and scrap HPchips. This aircraft > model I made with IC,s of the Clasic and Woodstock pocked calculator > series. This model has a modified HP-67 card reader mechanism built-in > that moves up and down the landing gear, pilots' cabin and the engine > light and four intermitent tricolor leds, powered by 6 V. Dave. What a relief... (cross-posted to c.s.hp48) === Subject: Re: HP chip model planes Thought I'd share this I came across on another group: >http://www.elcafevirtual.com/julio/ Model planes made entirely from old HP calculator chips and parts. Dave. I wonder how many collector's item HP machines were destroyed to make > these works of art. > None. > The Lockheed F-104 Starfighter was the second of four I made more >> than 30 years ago with defective and scrap HPchips. This aircraft >> model I made with IC,s of the Clasic and Woodstock pocked calculator >> series. This model has a modified HP-67 card reader mechanism built-in >> that moves up and down the landing gear, pilots' cabin and the engine >> light and four intermitent tricolor leds, powered by 6 V. > Dave. What a relief... > (cross-posted to c.s.hp48) of those models. That gave me quite a scare. I had to go pull out my HP 9825T, 35, 67, 97, 34C, 38C, 42S, 12C, 16C, 32SII, 17BII+, 48SX, 48GX, 50G, 33S, 35S, and 20B === Subject: Re: HP chip model planes > Thought I'd share this I came across on another group: > http://www.elcafevirtual.com/julio/ > Model planes made entirely from old HP calculator chips and parts. > Dave. >> I wonder how many collector's item HP machines were destroyed to make >> these works of art. > None. The Lockheed F-104 Starfighter was the second of four I made more > than 30 years ago with defective and scrap HPchips. This aircraft > model I made with IC,s of the Clasic and Woodstock pocked calculator > series. This model has a modified HP-67 card reader mechanism built-in > that moves up and down the landing gear, pilots' cabin and the engine > light and four intermitent tricolor leds, powered by 6 V. Dave. >> What a relief... >> (cross-posted to c.s.hp48) of those models. That gave me quite a scare. I had to go pull out my HP 9825T, 35, 67, 97, > 34C, 38C, 42S, 12C, 16C, 32SII, 17BII+, 48SX, 48GX, 50G, 33S, 35S, and 20B > and give them all a hug. Phew! > What? No HP11C? Still in (heavy) use here. The 12C is for finance guys AFAIK. Probably a lot of those will show up on the 2nd hand markets soon, along with their owners ... -- http://www.analogconsultants.com/ Use another domain or send PM. === Subject: Re: HP chip model planes >> Thought I'd share this I came across on another group: >> http://www.elcafevirtual.com/julio/ >> Model planes made entirely from old HP calculator chips and parts. >> Dave. > I wonder how many collector's item HP machines were destroyed to make > these works of art. >> None. > The Lockheed F-104 Starfighter was the second of four I made more >> than 30 years ago with defective and scrap HPchips. This aircraft >> model I made with IC,s of the Clasic and Woodstock pocked calculator >> series. This model has a modified HP-67 card reader mechanism built-in >> that moves up and down the landing gear, pilots' cabin and the engine >> light and four intermitent tricolor leds, powered by 6 V. > Dave. > What a relief... > (cross-posted to c.s.hp48) >> of those models. >> That gave me quite a scare. I had to go pull out my HP 9825T, 35, 67, 97, >> 34C, 38C, 42S, 12C, 16C, 32SII, 17BII+, 48SX, 48GX, 50G, 33S, 35S, and 20B >> and give them all a hug. >> Phew! What? No HP11C? Still in (heavy) use here. The 12C is for finance guys >AFAIK. Probably a lot of those will show up on the 2nd hand markets >soon, along with their owners ... HP12Cs are still being made, $70 retail, so I doubt they'd bring much more than $100 on eBay... ;-) An HP11C, OTOH, I might buy. I bought a 35S a year ago. Don't like it as much as either my long stolen HP11C or weak in the keys 35 year-old HP45. === Subject: Re: I cant find FBoxW > FBoxW GETADR says: Non existing entry. > Try FBoxB. > FBoxG1 and FBoxG2 are grayscale commands. Why is there an aFBoxW (and what is that), if there exists no corresponding FBoxW? The single missing entry in an otherwise complete grid pattern of 20 FBoxB FBoxG1 FBoxG2 ------ FBoxXor LBoxB LBoxG1 LBoxG2 LBoxW LBoxXor aFBoxB aFBoxG1 aFBoxG2 aFBoxW aFBoxXor aLBoxB aLBoxG1 aLBoxG2 aLBoxW aLBoxXor Is it hiding in one of the address ranges previously posted, from JKH's compilation XREF4849? http://www.hpcalc.org/search.php?query=xref4849 === Subject: Re: I cant find FBoxW > FBoxW GETADR says: Non existing entry. > Try FBoxB. > FBoxG1 and FBoxG2 are grayscale commands. Why is there an aFBoxW (and what is that), > if there exists no corresponding FBoxW? The single missing entry in an otherwise complete grid pattern of 20 FBoxB FBoxG1 FBoxG2 ------ FBoxXor > LBoxB LBoxG1 LBoxG2 LBoxW LBoxXor > aFBoxB aFBoxG1 aFBoxG2 aFBoxW aFBoxXor > aLBoxB aLBoxG1 aLBoxG2 aLBoxW aLBoxXor Is it hiding in one of the address ranges previously posted, > from JKH's compilation XREF4849?http://www.hpcalc.org/search.php?query=xref4849 ROM entries (49 series) ----------------------- #26080 =FBoxW #255D3 =FBoxG1 #255D8 =FBoxG2 #255DD =FBoxB Note: =FBoxW aka =GROB!ZERO === Subject: A small zelda style game for hp 50g Hi friends, i'm writing a small game for hp 50g. It is a zelda style game but more simple. The player have to find things to advance in the game. The game is not finish yet, but i have been working on it for about three weeks. This is my first game in System RPL. but i made develope other programas, like: - CAD 49: A graphic editor for hp 49g+, inspided in MS Visio. - Anova48pro: For statistical Inference. I also made: - Horizontal 50g: Horizontal KML script for emulation of hp 50g on emu48 4x zoom. - Fundamentos de User Rpl: A book about user rpl, in spanish. And a i think than developing games is the most dificult and interesting thing. The programmer have a a challenge on each step. Well, if you like games, please test a prealfa version of mine from: http://mnavarro.fortunecity.es/BMprealfaen.htm === Subject: Re: User Keyboard > My current assumption is that something, at a later stage of the > warmstart process, is intentionally disabling User Keyboard flag It does, because otherwise one could lock oneself out by disabling the entire USER mode keyboard (0 DELKEYS 'S' DELKEYS), for which the only recovery is a warmstart (ON+C is a special interrupt, and isn't disabled). Deliberately turning USER mode off at warmstart, only after all configs have been run, also prevents configs from leaving USER mode on, which, if the above were in effect, would make breaking back in increasingly difficult (or impossible on HP48S/G, without resetting all memory via ON+A+F, escape on 49/50 series possible only by remembering that you can hold down Backspace after ON+C to abort configs, unless you have an old 49G ROM where that might not even have been implemented). Thus Raymond's schedule a control [program] alarm to turn on USER mode a bit later, to defeat the thoughtfully planned emergency escape hatch. Note, however, that doing the above leaves the door open, as above, for getting locked out, with breaking back in becoming increasingly difficult, unless you inform users that they had better BOTH warmstart and then pretty fast either disable configs (on 49/50) or the next 'control' alarm (on 48). I think it's ON+4 [ON+TIME] which was thoughtfully also provided (on 48G, at least), for escaping from an infinite loop of control alarms, and which might still protect users of the 48 series from your good intentions :) === Subject: Re: User Keyboard and for the code showing how to proceed to get around this pretty complex situation. This is very helpfull and highlighting. === Subject: Re: User Keyboard Hi Yann, here's a formal config program, which will set USER mode. The trick is to decouple the action from the current config process. ASSEMBLE =XXcfg RPL :: [#] XXROMID TOSRRP ( *Autoattach* ) DATE TOD % .00005 %HMS+ ' :: PURGALARM% ERRSET :: SIXTYTWO SetSysFlag ; ERRTRAP NOP ; THREE{}N STOALM{} DROP ; For interested people, the thing works as follows: 1. Do the normal list entry in ROMPTAB (optional) 2. Set up a control alarm an eyeglimpse in the future 3. Warmstart has finished. The alarm will be activated, and perform the wanted action, in this case setting USER mode. The ERRSET .. ERRTRAP are formal and optional here. If you intend to include somewhat more complicated things there, the error trap may help avoiding trash on the stack. HTH Raymond Yann schrieb im Newsbeitrag This is indeed exactly what i tried to do. > I'm sure that the $CONFIG program is run, because other parts of it > have intended effects. > However, specifically regarding UserKeyboard system Flag, it does not > work, the keyboard start in normal mode. I don't know if the problem is specifically limited to 62 SysFlag. > My current assumption is that something, at a later stage of the > warmstart process, is intentionnally disabling User Keyboard system > flag, maybe for safety, maybe as a side-effect of a higher-number > library. But of course, i may be wrong. === Subject: Re: User Keyboard here's a formal config program, which will set USER mode. > The trick is to decouple the action from the current config process. ASSEMBLE > =XXcfg > RPL > :: [#] XXROMID TOSRRP ( *Autoattach* ) DATE TOD > % .00005 %HMS+ > ' > :: PURGALARM% ERRSET > :: SIXTYTWO SetSysFlag > ; > ERRTRAP > NOP ; THREE{}N STOALM{} DROP > ; For interested people, the thing works as follows: > 1. Do the normal list entry in ROMPTAB (optional) > 2. Set up a control alarm an eyeglimpse in the future > 3. Warmstart has finished. The alarm will be activated, > and perform the wanted action, > in this case setting USER mode. The ERRSET .. ERRTRAP are formal and optional here. > If you intend to include somewhat more complicated things > there, the error trap may help avoiding trash on the stack. HTH Raymond > This is indeed exactly what i tried to do. > I'm sure that the $CONFIG program is run, because other parts of it > have intended effects. > However, specifically regarding UserKeyboard system Flag, it does not > work, the keyboard start in normal mode. > I don't know if the problem is specifically limited to 62 SysFlag. > My current assumption is that something, at a later stage of the > warmstart process, is intentionnally disabling User Keyboard system > flag, maybe for safety, maybe as a side-effect of a higher-number > library. But of course, i may be wrong. Nice. Some entries are unavailable to me :-( [Jazz] Here full code: ASSEMBLE =PURGALARM% EQU #E724 =STOALM{} EQU #E54D =CONFIG RPL :: ( AutoAttach ) DATE TOD % .00005 %HMS+ ' :: PURGALARM% SIXTYTWO SetSysFlag ; THREE{}N STOALM{} DROP ; - Gaak - === Subject: Re: HP chip model planes >> Thought I'd share this I came across on another group: > http://www.elcafevirtual.com/julio/ > Model planes made entirely from old HP calculator chips and parts. > Dave. >> I wonder how many collector's item HP machines were destroyed to make >> these works of art. > None. The Lockheed F-104 Starfighter was the second of four I made more > than 30 years ago with defective and scrap HPchips. This aircraft > model I made with IC,s of the Clasic and Woodstock pocked calculator > series. This model has a modified HP-67 card reader mechanism built-in > that moves up and down the landing gear, pilots' cabin and the engine > light and four intermitent tricolor leds, powered by 6 V. Dave. >> What a relief... >> (cross-posted to c.s.hp48) > of those models. That gave me quite a scare. I had to go pull out my HP 9825T, 35, 67, 97, > 34C, 38C, 42S, 12C, 16C, 32SII, 17BII+, 48SX, 48GX, 50G, 33S, 35S, and 20B > and give them all a hug. Phew! > What? No HP11C? Still in (heavy) use here. The 12C is for finance guys >> AFAIK. Probably a lot of those will show up on the 2nd hand markets >> soon, along with their owners ... HP12Cs are still being made, $70 retail, so I doubt they'd bring much > more than $100 on eBay... ;-) An HP11C, OTOH, I might buy. I bought a 35S a year ago. Don't like > it as much as either my long stolen HP11C or weak in the keys 35 > year-old HP45. Yes, Costco even had them a while ago. Anniversary edition. Not exactly the same electronically but it sure was a nice touch. I wish they'd also do that with the HP11C. And yeah, when my wife absolutely wants me to trudge along to a yard sale I always keep looking for those calculators. None so far in years :-( -- http://www.analogconsultants.com/ Use another domain or send PM. === Subject: Re: HP chip model planes > Thought I'd share this I came across on another group: >http://www.elcafevirtual.com/julio/ > Model planes made entirely from old HP calculator chips and parts. > Dave. >> I wonder how many collector's item HP machines were destroyed to make >> these works of art. > None. > The Lockheed F-104 Starfighter was the second of four I made more > than 30 years ago with defective and scrap HPchips. This aircraft > model I made with IC,s of the Clasic and Woodstock pocked calculator > series. This model has a modified HP-67 card reader mechanism built-in > that moves up and down the landing gear, pilots' cabin and the engine > light and four intermitent tricolor leds, powered by 6 V. > Dave. >> What a relief... >> (cross-posted to c.s.hp48) > of those models. > That gave me quite a scare. I had to go pull out my HP 9825T, 35, 67, 97, > 34C, 38C, 42S, 12C, 16C, 32SII, 17BII+, 48SX, 48GX, 50G, 33S, 35S, and 20B > and give them all a hug. > Phew! >> What? No HP11C? Still in (heavy) use here. The 12C is for finance guys >> AFAIK. Probably a lot of those will show up on the 2nd hand markets >> soon, along with their owners ... > HP12Cs are still being made, $70 retail, so I doubt they'd bring much > more than $100 on eBay... ;-) > An HP11C, OTOH, I might buy. I bought a 35S a year ago. Don't like > it as much as either my long stolen HP11C or weak in the keys 35 > year-old HP45. Yes, Costco even had them a while ago. Anniversary edition. Not exactly > the same electronically but it sure was a nice touch. The latest 12C actually uses an Atmel ARM processor (as in the new 20B) running the original 12C ROM using the Nonpareil emulator: http://nonpareil.brouhaha.com/ Rumor has it further Voyager models (11C, 15C etc) will be re-released with this method. Dave. === Subject: Re: HP chip model planes > The latest 12C actually uses an Atmel ARM processor (as in the new > 20B) running the original 12C ROM using the Nonpareil emulator: > http://nonpareil.brouhaha.com/ Rumor has it further Voyager models (11C, 15C etc) > will be re-released with this method. Since it's been observed that some previous product updates are actually complete internal re-designs, complete with bad bugs and less accuracy, an emulation of the original would seem very attractive, to those who know about the quality of those originals; perhaps, should they dare to tinker with them, the few remaining bugs of the originals might even be fixed. However, the originals were designed with limited memory, so can an exact clone provide any more program and data storage, or even additional functions, as did some of the subsequent updates? I suppose I'd better rush out and sell my old originals, before the market is flooded with clones, satisfying the demand that currently exceeds the supply :) Never-cloned originals whose value keeps increasing: http://www.glassinesurfer.com/stamp_collecting/gsinvertedjenny.shtml http://en.wikipedia.org/wiki/Inverted_Jenny Once rare, until cloned: http://en.wikipedia.org/wiki/Dag_Hammarskj.9ald_invert http://stamps.about.com/od/historyofphilately/p/DagHammar.htm How about those HP49Gs with inverted keys? Are they fetching huge prices, like stamps? See http://holyjoe.net/hp/HP49.htm#upsidedown === Subject: Re: HP chip model planes The latest 12C actually uses an Atmel ARM processor (as in the new > 20B) running the original 12C ROM using the Nonpareil emulator: > http://nonpareil.brouhaha.com/ Rumor has it further Voyager models (11C, 15C etc) will be re-released > with this method. How does the ARM.based version compare with the old version, in terms of speed and battery life? I would not be surpised to hear of an 11C that was still on its original set of batteries :-) === Subject: Re: HP chip model planes > The latest 12C actually uses an Atmel ARM processor (as in the new > 20B) running the original 12C ROM using the Nonpareil emulator: >http://nonpareil.brouhaha.com/ > Rumor has it further Voyager models (11C, 15C etc) will be re-released > with this method. How does the ARM.based version compare with the old version, > in terms of speed and battery life? I would not be surpised to hear of > an 11C that was still on its original set of batteries :-) I haven't head about the new 12C as apparently it's quite hard to find and identify them on the shelves, and only sold in Europe or somewhere so far? If the new 20B is anything to go by (and it should be because it's the same processor) then battery life it will be a shocker. Rated 9 months from two CR2032 batteries. IMO HP goofed big in the design of the 20B. It works at 30MHz for all calculations (then goes to sleep), but that means 15mA or so from the two CR2032 batteries. This means big losses in the battery internal resistance when doing calcs. When I queried one of the HP designers about this on another forum, I got the response that the CR2032 batteries have an IR of 5 ohms (IIRC) and everything was fine and dandy. Well, they must be real special batteries they are using because normal CR2032's start at 20ohms IR and go up. I can dig out the actual figures I came up with from the other forum if needed, but it was I think something like 30% at least of the computational power wasted in the battery IR. Crazy design. Also, there was some concern about the low battery detection logic not working properly. Dave. === Subject: Re: HP chip model planes > The latest 12C actually uses an Atmel ARM processor (as in the new > 20B) running the original 12C ROM using the Nonpareil emulator: > http://nonpareil.brouhaha.com/ > Rumor has it further Voyager models (11C, 15C etc) will be re-released > with this method. > How does the ARM.based version compare with the old version, >> in terms of speed and battery life? I would not be surpised to hear of >> an 11C that was still on its original set of batteries :-) I haven't head about the new 12C as apparently it's quite hard to find > and identify them on the shelves, and only sold in Europe or somewhere > so far? If the new 20B is anything to go by (and it should be because it's the > same processor) then battery life it will be a shocker. > Rated 9 months from two CR2032 batteries. > IMO HP goofed big in the design of the 20B. It works at 30MHz for all > calculations (then goes to sleep), but that means 15mA or so from the > two CR2032 batteries. This means big losses in the battery internal > resistance when doing calcs. Why on earth does a calculator need to run at 30MHz? The original HP15c ran at 220KHz[*] in 1983. Has Bill Gates really made us 136x dumber / less efficient in the past 26 years? Well, maybe he has at that. * Unless hotrodded ... http://www.brouhaha.com/~eric/hpcalc/voyager/speedup.html Run the new version at 2MHz, port it natively to the ARM, and blaze on. James Arthur === Subject: Re: HP chip model planes > The latest 12C actually uses an Atmel ARM processor (as in the new >> 20B) running the original 12C ROM using the Nonpareil emulator: >> http://nonpareil.brouhaha.com/ >> Rumor has it further Voyager models (11C, 15C etc) will be re-released >> with this method. How does the ARM.based version compare with the old version, > in terms of speed and battery life? I would not be surpised to hear of > an 11C that was still on its original set of batteries :-) >> I haven't head about the new 12C as apparently it's quite hard to find >> and identify them on the shelves, and only sold in Europe or somewhere >> so far? >> If the new 20B is anything to go by (and it should be because it's the >> same processor) then battery life it will be a shocker. >> Rated 9 months from two CR2032 batteries. >> IMO HP goofed big in the design of the 20B. It works at 30MHz for all >> calculations (then goes to sleep), but that means 15mA or so from the >> two CR2032 batteries. This means big losses in the battery internal >> resistance when doing calcs. >Why on earth does a calculator need to run at 30MHz? The >original HP15c ran at 220KHz[*] in 1983. So there is no lag in 59!? Do you happen to know that the HP35's clock was? > Has Bill Gates >really made us 136x dumber / less efficient in the past >26 years? At least. Windoze is a lot prettier though. OTOH, I'd like an HP11C (or name your fav HP calculator) in each cell in Excel. >Well, maybe he has at that. === Subject: Re: HP chip model planes The latest 12C actually uses an Atmel ARM processor (as in the new > 20B) running the original 12C ROM using the Nonpareil emulator: > http://nonpareil.brouhaha.com/ > Rumor has it further Voyager models (11C, 15C etc) will be re-released > with this method. >> How does the ARM.based version compare with the old version, >> in terms of speed and battery life? I would not be surpised to hear of >> an 11C that was still on its original set of batteries :-) > I haven't head about the new 12C as apparently it's quite hard to find > and identify them on the shelves, and only sold in Europe or somewhere > so far? If the new 20B is anything to go by (and it should be because it's the > same processor) then battery life it will be a shocker. > Rated 9 months from two CR2032 batteries. > IMO HP goofed big in the design of the 20B. It works at 30MHz for all > calculations (then goes to sleep), but that means 15mA or so from the > two CR2032 batteries. This means big losses in the battery internal > resistance when doing calcs. > Why on earth does a calculator need to run at 30MHz? The >> original HP15c ran at 220KHz[*] in 1983. So there is no lag in 59!? I just tried it. Less than 1 second, AFAICT. > Do you happen to know that the HP35's > clock was? > Two-phase quadrature 200KHz clock, divided down from 800KHz main osc. Details here: http://www.jacques-laporte.org/HP35%20Hardware%20basic%20design.htm === Subject: Re: I cant find FBoxW > ROM entries (49 series) > ----------------------- > #26080 =FBoxW > #255D3 =FBoxG1 > #255D8 =FBoxG2 > #255DD =FBoxB Note: =FBoxW aka =GROB!ZERO === Subject: Re: I cant find FBoxW > ROM entries (49 series) > ----------------------- > #26080 =FBoxW > #255D3 =FBoxG1 > #255D8 =FBoxG2 > #255DD =FBoxB > Note: =FBoxW aka =GROB!ZERO Ah, now that's the first answer that has a solid ringing sound to it :) The course our city runs is the same towards men and money. She has true and worthy sons. She has fine new gold and ancient silver, coins untouched with alloys, each well minted, tested each and ringing clear. Yet we never use them! Others pass from hand to hand, sorry brass just struck last week and branded with a wretched brand. So with men we know for upright, blameless lives and noble names. These we spurn for men of brass. [Aristophanes, The Frogs 405 B.C.] . === Subject: Banner Program Gustavo Portales presents: The new Banner program (v1.2) available for 48&49 series. http://www.gaak.org/hp/banner/ === Subject: Re: Looking for a programming project > I'm toying around with my 50g and looking for a programming project. > Does anyone have any suggestions or need anything simple? Having a blast programming a calculator after being away from them for 25 years, Implement an integrated help system, visible to appropiate degrees of complexity, in the stack display(i.e. expanded RS+DownArrow or header area), in the choose boxes (an added two-line text area at the end for help text, similar to the dialog box), on the edit line and while bulding an user rpl program. === Subject: Re: Looking for a programming project well, currently there are two data sets available. A general technical one which covers everything (and even more) of the original EQNLIB released back in 1991 and an economic one which covers the most common formulas in economics. It would be beneficial IMHO to have specialized data sets for different professional categories, say for example - mechanical engineering - civil engineering - chemistry - etc... Surely there is some overlapping in the disciplines, but it would allow to arrange the formulas the way they are used in the specific discipline. Hope I gave some thoughts. Andreas http://www.software49g.gmxhome.de === Subject: Re: Looking for a programming project Shouldn't volunteers for one of the suggestions know that they would be working on a commercial product (Euro 49.95 for each package on SD card)? I'm sure they must be offered compensation for any work, which might attract more interested people. === Subject: Re: Looking for a programming project > Actually, I think an even better project would be an RPL optimizer. > it wouldn't be too hard to track the number and type objects > on the stack and, when they are well known, convert the User RPL into > equivalent SysRPL > I'm quite surprised that no one has done this yet. Or maybe I just > haven't found it. Well, from my experience, just moving from UserRPL to SysRPL with only the intention translate, say, xDUP by DUP, results in gains which can be considered minor. No 10x here, just a few percent. You really start to get some gains when using new features from SysRPL not available from UserRPL, But these requires more than just command translation. === Subject: COERCEFLAG in UserRPL The program below is not executed properly. Implementation stop after # 2602Bh SYSEVAL. What's wrong? Ç CLLCD Clear Directory? # 2F1A5h SYSEVAL @ AskQuestion # 2602Bh SYSEVAL @ COERCEFLAG IF THEN 15 TVARS DUP SIZE 0 > { PGDIR } { DROP } IFTE CLVAR END È === Subject: Re: COERCEFLAG in UserRPL [COERCEFLAG replaces SysRPL TRUE/FALSE with a numeric real 1/0] > # 2602Bh SYSEVAL @ COERCEFLAG [49/50 series only] > IF ... As TW said, COERCEFLAG includes a pop from the return stack (SEMI), which terminates that program level (returning to the next higher level), which was done because it's the very last action in the performance of all UserRPL commands which return real 1/0 as true/false, and thus saves one SysRPL command in all those places in ROM. Donnelly's HP48 Handbook therefore suggested surrounding the COERCEFLAG itself with << >> What COERCEFLAG exits from is then just that program (which is finished anyway), thus continuing with whatever follows. The briefest way of all may be to replace your COERCEFLAG with Which is only 2.5 bytes longer than just the COERCEFLAG syseval itself. posted UserRPL programs, to test results of SysRPL commands: === Subject: Re: COERCEFLAG in UserRPL > The program below is not executed properly. > Implementation stop after # 2602Bh SYSEVAL. > What's wrong? Ç > CLLCD > Clear Directory? # 2F1A5h SYSEVAL @ AskQuestion > # 2602Bh SYSEVAL @ COERCEFLAG IF > THEN > 15 TVARS DUP SIZE 0 { PGDIR } { DROP } IFTE > CLVAR > END > È If I remember right, COERCEFLAG drops the rest of the runstream, so your program essentially ends up being this: << CLLCD Clear Directory? # 2F1A5h SYSEVAL @ AskQuestion # 2602Bh SYSEVAL @ COERCEFLAG >> You can use the sysrpl command ITE #XXXXX SYSEVAL 1. 0. TW === Subject: Re: COERCEFLAG in UserRPL posting-account=T6_JoAoAAAD5X1NpIb7ZcQrmFCd8Otqa Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) The program worked very well ! This is the new version. Ç Ç 15 TVARS DUP SIZE 0 > { PGDIR } { DROP } IFTE CLVAR È Ù y Ç CLLCD Clear Directory? # 2F1A5h SYSEVAL @ AskQuestion # 34B3Eh SYSEVAL @ IT y È È === Subject: SDfiler 1.3 So I somehow managed to delete the folder with my old calc files off the web server. The only thing I can't find a backup of is the latest revisions I made to the SDfiler program. If anyone has that saved TW === Subject: Change to command line posting-account=eqvyQQoAAAAlRCnhJ6qb0BalXT52YC-g Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe) Hello. I have looked in the HP50g manuals and have not found a way to switch to the command line. I actually wish to change the key response time with the ->KEYTIME command. How can I enter the command line interface? Is the any other way to execute a command? I thank you! === Subject: Re: Change to command line Ahem, if you were able to key in numbers so far, you may have found the CLI;-) When you turn on the calc and see the stack, you're at the CLI. To open a new CL just press a numeric key, or turn on ALPHA mode, and then press an alpha key. Actually, the CLI (Command Line Interface) should be covered somewhere within the first pages of the manual. HTH schrieb im Newsbeitrag > Hello. I have looked in the HP50g manuals and have not found a way to > switch to the command line. I actually wish to change the key response > time with the ->KEYTIME command. How can I enter the command line interface? Is the any other way to > execute a command? I thank you! === Subject: Re: Change to command line It does help conceptually. However I can't type the command in stack because the calculator interprets the dash as a minus sign. In the line editor, when I try to type 300 ->KEYTIME and push enter, I have >KEYTIME highlighted and message Invalid Syntax. I found the command in 20 Essential Things to Know About the HP-49G http://www.hpcalc.org/details.php?id=4910. > Ahem, if you were able to key in numbers so far, > you may have found the CLI;-) When you turn on the calc and see the stack, > you're at the CLI. > To open a new CL just press a numeric key, > or turn on ALPHA mode, and then press an alpha key. Actually, the CLI (Command Line Interface) should be covered > somewhere within the first pages of the manual. === Subject: Re: Change to command line > It does help conceptually. However I can't type the command in stack > because the calculator interprets the dash as a minus sign. In the > line editor, when I try to type 300 ->KEYTIME and push enter, I have >>KEYTIME highlighted and message Invalid Syntax. I found the command in 20 Essential Things to Know About the HP-49G > http://www.hpcalc.org/details.php?id=4910. The -> refers to the single arrow character that you get by right-shift 0. It's not a dash and a greater-than. === Subject: Re: Change to command line > The -> refers to the single arrow character that you get by > right-shift 0. It's not a dash and a greater-than. For typing command names like ->KEYTIME, ->LIST, STR-> etc. alpha shift will also be found useful; otherwise spaces will be inserted around the arrow character (you can also of course just backspace to remove spaces). The alphabetical CATalog is also useful: Commands beginning with -> are all together, near the end of the list. You can locate commands ending with -> via their beginning letter(s), as usual. When you select commands from the CATalog, you need only locate them in the list and press ENTER; you need never spell them out or type special characters. By the way, right-shift ENTRY (right-shift Alpha) prevents any evaluation of a command line until ENTER is pressed, by turning on program entry mode (PRG indicator), just as do {} and <<>> and :: the misleadingly named Text editor (under APPS) also merely starts a new command line in PRG mode. Ain't it wicked? http://www.youtube.com/watch?v=a0m6sclZkH0 http://www.youtube.com/watch?v=Fi-p7anJCmM === Subject: Re: HP chip model planes > The latest 12C actually uses an Atmel ARM processor (as in the new > 20B) running the original 12C ROM using the Nonpareil emulator: >http://nonpareil.brouhaha.com/ > Rumor has it further Voyager models (11C, 15C etc) > will be re-released with this method. Since it's been observed that some previous product updates > are actually complete internal re-designs, complete with > bad bugs and less accuracy, an emulation of the original > would seem very attractive, to those who know about > the quality of those originals; perhaps, should they > dare to tinker with them, the few remaining bugs > of the originals might even be fixed. The ASIC used in the previous 12C was becoming obsolete, so HP either had to either re-design from scratch (software wise), or go with Eric's ROM emulator. They wisely went with the later given that almost the entire finance industry relies on the 12C, and any numerical bugs would have unacceptable to say the least. > However, the originals were designed with limited memory, > so can an exact clone provide any more program and data storage, > or even additional functions, > as did some of the subsequent updates? I suppose I'd better rush out and sell my old originals, > before the market is flooded with clones, > satisfying the demand that currently exceeds the supply :) Yup, if a new 11C or 15C ROM emulated machine comes out, the Ebay market will drop like a rock. Once rare, until cloned:http://en.wikipedia.org/wiki/Dag Hammarskj.9ald inverthttp://stamps.about.com/od/historyofphilately/p/DagHammar.htm How about those HP49Gs with inverted keys? > Are they fetching huge prices, like stamps? > Seehttp://holyjoe.net/hp/HP49.htm#upsidedown If Casio ever brong back the CFX-400, interest in my uWatch will no doubt dry up! http://www.calcwatch.com/ Dave. === Subject: Re: HP chip model planes > The latest 12C actually uses an Atmel ARM processor (as in the new >> 20B) running the original 12C ROM using the Nonpareil emulator: >> http://nonpareil.brouhaha.com/ >> Rumor has it further Voyager models (11C, 15C etc) will be re-released >> with this method. > How does the ARM.based version compare with the old version, > in terms of speed and battery life? I would not be surpised to hear of > an 11C that was still on its original set of batteries :-) >> I haven't head about the new 12C as apparently it's quite hard to find >> and identify them on the shelves, and only sold in Europe or somewhere >> so far? > If the new 20B is anything to go by (and it should be because it's the >> same processor) then battery life it will be a shocker. >> Rated 9 months from two CR2032 batteries. >> IMO HP goofed big in the design of the 20B. It works at 30MHz for all >> calculations (then goes to sleep), but that means 15mA or so from the >> two CR2032 batteries. This means big losses in the battery internal >> resistance when doing calcs. Why on earth does a calculator need to run at 30MHz? The > original HP15c ran at 220KHz[*] in 1983. >> So there is no lag in 59!? I just tried it. Less than 1 second, AFAICT. > Do you happen to know that the HP35's >> clock was? Two-phase quadrature 200KHz clock, divided down from 800KHz main osc. Only 10% in 11 years. G. Moore obviously didn't work at HP. ;-) >Details here: >http://www.jacques-laporte.org/HP35%20Hardware%20basic%20design.htm === Subject: Re: HP chip model planes > The latest 12C actually uses an Atmel ARM processor (as in the new > 20B) running the original 12C ROM using the Nonpareil emulator: > http://nonpareil.brouhaha.com/ > Rumor has it further Voyager models (11C, 15C etc) will be re-released > with this method. >> How does the ARM.based version compare with the old version, >> in terms of speed and battery life? I would not be surpised to hear of >> an 11C that was still on its original set of batteries :-) > I haven't head about the new 12C as apparently it's quite hard to find > and identify them on the shelves, and only sold in Europe or somewhere > so far? If the new 20B is anything to go by (and it should be because it's the > same processor) then battery life it will be a shocker. > Rated 9 months from two CR2032 batteries. > IMO HP goofed big in the design of the 20B. It works at 30MHz for all > calculations (then goes to sleep), but that means 15mA or so from the > two CR2032 batteries. This means big losses in the battery internal > resistance when doing calcs. >> Why on earth does a calculator need to run at 30MHz? The >> original HP15c ran at 220KHz[*] in 1983. > So there is no lag in 59!? >> I just tried it. Less than 1 second, AFAICT. > Do you happen to know that the HP35's > clock was? > Two-phase quadrature 200KHz clock, divided down from 800KHz main osc. Only 10% in 11 years. G. Moore obviously didn't work at HP. ;-) > Bill Gates didn't either. Else the 15C would have probably needed 512MB -- SCNR, Joerg http://www.analogconsultants.com/ Use another domain or send PM. === Subject: Re: Looking for a programming project > Shouldn't volunteers for one of the suggestions > know that they would be working on a commercial product > (Euro 49.95 for each package on SD card)? Yes, that is the reason why it is on my website. I am not charging anything for the data sets, I am charging for the engine. But of course you need the engine to display the data set. There are ready to use EMU49 Document (*.E49) available for download on the entry page so that you get an overview of what the software does. > I'm sure they must be offered compensation for any work, > which might attract more interested people. This is, of course, negotiable but probably not in a publich newsgroup. Andreas http://www.software49g.gmxhome.de === Subject: Re: Looking for a programming project > There are ready to use EMU49 Document (*.E49) available for download > on the entry page so that you get an overview of what the software > does. http://www.software49g.gmxhome.de/ENGLISCH.zip is corrupt. === Subject: Re: Looking for a programming project > http://www.software49g.gmxhome.de/ENGLISCH.zipis corrupt. I have fixed the archive. Andreas === Subject: Re: Looking for a programming project I have uploaded a new version of ENGLISCH.zip which should be o.k. (I tested it for me and it worked o.k.) http://www.software49g.gmxhome.de/ENGLISCH.zip Andreas http://www.software49g.gmxhome.de === Subject: Re: User Keyboard As it seems you know quite a lot regarding advanced user keyboard configuration. i'm willing to ask you a few more questions on this subject if you don't mind. Maybe some of them have no simple answer, or no answer at all. As background information, stfox and i are preparing a program which will be remapping quite many user-keys onto library functions. Description of the program can be found here : http://phantasie.tonempire.net/utilitaires-f7/stacker4x-compression-driver-t 75.htm#83 We are near the end of development phase, and therefore trying to polish the last details. 1) Many functions are mostly equivalent, with just a single parameter change. This parameter is therefore provided by the userkey. For example, Right-shift+A is mapped with : :: ONE XLIBcall ; Many others look the same. As a consequence, there are many small secondaries into the user keyboard list. This is apparently not so good, because secondaries size cannot be simply evaluated (you have to go through each and every element within the secondary); as a consequence, user keyboard speed could slow down. Now, to be fair, i've not felt any slowdown during my testings. So maybe this is not a problem with very small secondaries. Anyway, just in case, i've wondered if it would possible to retrieve the last key pressed. If that was possible, only the XLIBcall would remain, making the user- keyboard list a bit more compact. Unfortunately, i could not find anyway to do it. So maybe that's not possible. 2) We currently have 14 user-key assignments. The initial setup costs a bit of time, something in the range of a full second on a standard HP48G. This is not very long, but i would like this process to be a bit more instantaneous, if that is possible. We are using some pretty standard RPL call, xASN with %lc.p assignment, and StoUserKeyPatch with #kc.p. I wondered if it exists a speedier way to do such a job. 14 is not massive, but maybe there is a way to store many user-key assignments faster than 14 times single-key assignments. === Subject: My HP49g+ has died. ) but yesterday it switched off and it I can't turn it on, I have changed both the AAA batteries and the memory one, but nothing; when I take out one of the batteries and put it again it appears a line on the screen and then nothing else. What can I do??? Do u know any === Subject: Re: My HP49g+ has died. > but yesterday it switched off and it I can't turn it on, I have > changed both the AAA batteries and the memory one, but nothing; when I > take out one of the batteries and put it again it appears a line on > the screen and then nothing else. What can I do??? Do u know any Try taking all the batteries out (even the coin cell) and leave them out for a couple of hours (also disconnect from USB). I had a similar crash (all I could see was a line) on my 50g a year or so ago and this did the trick. My first 50g did the same thing after a reset (poking the hole in the back with a paperclip) and it stayed in permanent reset resulting in a replacement by HP. Best of luck, Mike Bryant