d-29 === Subject: Re: Question about disabling interrupts Hi Mike, MSCHAEF.COM schrieb im Newsbeitrag > ... >>or the 'big hammer': >>GOSBVL =DisableIntr >>and >>GOSBVL =AllowIntr >>However the big hammer is only used inside the system config code, >>in the XModem module, in a certain printing routine, >>and in some matrix manipulation routine. >>It only makes sense if your code is *very* timing critical, > Why is it used in the matrix code? AFAIK because they needed the additional return stack levels. Raymond === Subject: 49g+ Faster Key Assignment Packer KEYPK -- Key Assignment Packer for hp49g+ by Joe Horn HP recommends occasionally doing RCLKEYS 0 DELKEYS STOKEYS as a way of packing the key assignments, that is, removing the space that's wasted when key assignments are deleted. Unfortunately, HP's method is (1) very slow, and (2) incomplete. For example, when I do RCLKEYS 0 DELKEYS STOKEYS on my hp49g+ in its current normal state, it takes 8.5 seconds and leaves 1115 bytes of unrecovered space in the assignment list! Boo, hiss. Over the years, this problem has been addressed by several excellent libraries, such as Simone Rapisarda's SmartKeys and Wolfgang Rautenberg's Keyman. The program below is for those who use key assignments but do not wish to install an entire library for the sole purpose of packing key assignments. It also uses a method entirely different from those libraries. This program recovers ALL the space from the assignment list, and does it super fast: on my machine, with 79 assignments, it takes 0.8 seconds. It also reports how many bytes it recovered. Not bad for a User RPL program. Point of interest: KEYPK uses a programming trick that I *think* is new among User RPL programmers. (If not, correct me). The hp49g+ punishes those who use SYSEVAL with unsupported entry points, because those addresses keep changing. However, unsupported addresses are often at *stable offsets* inside supported routines. Therefore, unsupported routines can be used when their address is calculated from supported addresses. For example, the User RPL command Ck&ClrUKey is unsupported, but it has always been called near the beginning of the supported command xDELKEYS like this: :: CK1&Dispatch real Ck&ClrUKey ... Therefore, even though Ck&ClrUKey is unsupported, it may reliably be called at the address of xDELKEYS plus 15 bytes. On the hp49g+, the address of xDELKEYS is #3EF3B, so the address of Ck&ClrUKey can be calculated thus: #3EF3B 15 + APEEK. Needless to say, this method relies upon the stability of the code itself, which can be ascertained only by examining the code in previous ROM versions. If the code is the same now as it was in HP-48 ROM version A, then it's a good bet that it's never gonna change. INSTRUCTIONS for KEYPK: Before keying in or importing the program, be sure that library 256 is attached: 256 ATTACH. This only needs to be done to create the program, not to run it. INPUT: None. OUTPUT: number of bytes recovered. Unsupported entry points used: StoUserKeys. Allowed ROM versions: ALL. %%HP: T(3); << # 25967h SYSEVAL DUP ->H 47A20B2130 9E550 SREPL DROP # 55E9h SYSEVAL 12 NDUPN ->LIST ->H 9E550 SREPL DROP H-> DUP # 3EF3Bh 15 + APEEK 15 + APEEK 10 + APEEK SYSEVAL BYTES NIP SWAP BYTES NIP SWAP - Reclaimed ->TAG hp49g+ BYTES: 218.0 #2C19h -jkh- === Subject: Re: 49g+ Faster Key Assignment Packer > There is nothing new under the sun -jkh- === Subject: Re: HPGCC 2: sat_decode_real as you described -it looks like the rounding on last reliable digit would fix it or adding very small number like: 0.0000000000001 before truncating would make numbers with repeating 9 look nicer :-) no doubt about it: if you cut away some digits it is standard to round rather than truncate... > I have looked a bit further into this, and have found the following: > - sat_pop_real() pops the HP real 0.8 to full precision (12/15), so as > the comparison afterwards with the C-double constant 0.8 returns true. > This is great and as expected. > - sat_decode_real() does NOT decode the HP real 0.8 to full precision > (12/15), which means the comparison afterwards with the C-double > constant 0.8 returns false. This is contrary to what I'd expect. > - sat_push_real() truncates the double before converting it into a HP > real. That is, sat_push_real(0.7999999999999999) leaves the HP real > 0.799999999999 on the stack. I would have expected sat_push_real() to > round to nearest (12 significant digits) instead of truncating. > Steen === Subject: Re: HPGCC 2: sat_decode_real > as you described > -it looks like the rounding on last reliable digit would fix it > or adding very small number like: > 0.0000000000001 before truncating would make numbers with repeating 9 > look nicer :-) It's not a question of making the result look nicer, it's a question of being able to make comparisons with known limits. As it is, sat_decode_real() and sat_pop_real() returns different answers. This seems to be an error to me (until I'm enlightened by one of the hpgcc guys :-). The truncation in sat_push_real() is also a real problem. I could probably fix it from case to case by adding a small offset or doing something else, but that would add overhead as well as obfuscate the code. Steen === Subject: Re: HPGCC 2: sat_decode_real > It's not a question of making the result look nicer, it's a question of > being able to make comparisons with known limits. As it is, > sat_decode_real() and sat_pop_real() returns different answers. This > seems to be an error to me (until I'm enlightened by one of the hpgcc > guys :-). Well this looks simple to me: if double precision has more than 12 signifficant digits (i'm not shure how much there are -as far as i remeber it's about 13 or 14) that's the obvious source of this problem: -when parsing HP's 12 digit in to double -you get a correct double with 1 or 2 digits missing (compared to full double precision constant) ! Since we have no way of inventing or guessing the 2 last digits, i think the best way to avoid this kind of error is to limit the precision to 12 digits when interacting with saturn stack. a function round could be added for this (if it doesn't exist already) with 2 parametters 1. number to be rounded 2. number of signifficant digits following comma (0 would round up to integer part, 1 would produce 1 decimal etc... ) === Subject: Re: HPGCC 2: sat_decode_real > that's the obvious source of this problem: > -when parsing HP's 12 digit in to double > -you get a correct double with 1 or 2 digits missing (compared to full > double precision constant) ! You don't get a double with a couple of digits missing, you get a double with unknown contents in the last digits. This comes from the BCD to binary conversion. What I'm getting at is that this BCD to binary conversion ought to be the same in sat_decode_real() and sat_pop_real(). It's not. > Since we have no way of inventing or guessing the 2 last digits, i > think the best way to avoid this kind of error is to > limit the precision to 12 digits when interacting with saturn stack. There's really no realiable way to limit a binary double to a number of significant digits. The best one can do is to maintain the best binary representation of the BCD number (HP real) and go from there (this is done by binary division of the exact fraction during the conversion, and continue this division until double precision is met - this might demand higher than double precision inside the conversion routine). I think sat_decode_real() fails in this, while sat_pop_real() does it correctly. Both are let down by truncation in sat_push_real() in the end though. Steen === Subject: Re: HPGCC 2: sat_decode_real > You don't get a double with a couple of digits missing, you get a > double with unknown contents in the last digits. This comes from the > BCD to binary conversion. What I'm getting at is that this BCD to > binary conversion ought to be the same in sat_decode_real() and > sat_pop_real(). It's not. Of course, you're right, these 2 become unreliable digits, -since they don't have the source to be calculated from (HP BCD has 12 -i considered them to be missing :-) > There's really no realiable way to limit a binary double to a number of > significant digits. The best one can do is to maintain the best binary > representation of the BCD number (HP real) and go from there (this is > done by binary division of the exact fraction during the conversion, > and continue this division until double precision is met - this might > demand higher than double precision inside the conversion routine). I > think sat_decode_real() fails in this, while sat_pop_real() does it > correctly. Both are let down by truncation in sat_push_real() in the > end though. I belive there is, i didn't try this but i belive it would work. it would require attention when writing your code, and it wouldn't look pritty: when you pop or decode the BCD from HP stack, truncate the result to reliable number of decimals (you can't round because last digits are unreliable), do the same on your constant or results you got from your C rutines if and when comparing with numbers obtained from stack. In fact it seems like this issue is significant only in cases when you attempt to compare BCDs with doubles but let's put this aside, You belive that rounding (instead of truncating) for sat_push_real would do a better... job right ? (when cutting away significant/reliable digits rounding should be assumed) i belive this is feasible... let's wait and see from HPGCC (it almost rhimes) the simplest case where we can see that is: when you write 0.799999999999 to the stack you get accurate number, but if you type one more decimal the number will get rounded (in case added figure is larger than 4 it will be rounded to 0.8, of course) -last digit is reliable (entered by the user), but has to be cut off due to limitation in HP's BCD real === Subject: Re: Saturn stack and PrRUN in ARMToolBox > Hi. > I just wanted to point out something regarding the stack when running > an ARM program with PrRUN from the ARMToolBox. > If I have a string generated with HPGCC v2.0 on the stack, and do > S->Prg on it, I get a program that can be stored in a variable in HOME > (for instance) and be run from there. The same holds true if I instead > do S->EXE on the string. > But, in the first case Saturn stack level 1 will be the argument to > PrRUN, instead of what previously was in stack level 1. The latter will > have moved to stack level 2 during execution of the ARM program. That's how it used to be in hpgcc 1.1. Now what you see on level 1 is what you left there. > In the second case (with S->EXE) the stack will not be modified during > execution of the ARM program. That's because the new S->EXE was not meant to be used with programs compiled with hpgcc 1.1. But since it's confusing you (and possibly others) I will commit in short (check the repository) a new version that works with both new and old libraries. > The above means any C program (using the Saturn stack) made with HPGCC > should be designed to be either used with PrRUN or used as a standalone > executable - it makes a difference as to where in the stack you have to > look for your data. This is my experience, but is it correct, or do I > do something wrong? It would be simpler if PrRUN popped the C-string > from the Saturn stack before executing the code. It's not exactly how you describe it. Let me try to clarify this: 1) HPGCC versions up to 1.1 had a stack bias, meaning that the launcher code needed to leave an extra argument on the stack. However, this was completely transparent to the user (see the sat_stack_init()... function). 2) HPGCC 2.0 does NOT need an extra argument on the stack, therefore the stack is passed to the C program untouched. This is one of the many little improvements done in the code. But again, this should be transparent to the user. 3) For backwards compatibility, PrRUN detects when you are trying to execute an old hpgcc 1.1 program and in such case it adds an argument to the stack. It passes the stack unchanged if your program is hpgcc 2.0 The only way you would notice the change is if you are NOT using the API correctly AND on top of that you have one of the following: * You are compiling a program with 2.0 but linking with 1.1 libraries (why would you do that?) * You are using 2.0 libraries but the version 1.1 of the utilities (in particular, elf2hp) * You changed some of the default settings in elf2hp and your compiled program appears to be an old 1.1 program. If you are doing one of the first two things, my advice is DON'T!! Use either 1.1 or 2.0 but don't mix. If you are using only 2.0, then check your makefiles, in particular the is adding a stack bias therefore your program seems to be a 1.1 version. I hope this helps, Claudio === Subject: Re: Saturn stack and PrRUN in ARMToolBox > That's how it used to be in hpgcc 1.1. Now what you see on level 1 is > what you left there. Ok, then there's something wrong, because I'm using hpgcc 2.0 only. This simple program checks what is on the Saturn stack: ***source start*** #include int main(void) { SAT_STACK_ELEMENT a; if(sat_stack_depth()!=0) { sat_get_stack_element(1,&a); if(a.prologue==SAT_DOREAL) sat_stack_push_string(real); else sat_stack_push_string(other); } else sat_stack_push_string(empty); return 0; } ***source end*** The above compiles fine and I transfer it to the calc on an SD card. - If I put the string on the stack and execute it with PrRUN, the calc hangs. - If I put the string on the stack, execute S->Prg from the ARMToolBox (v3.10 is installed), save the resulting program to a variable in HOME and run it by pushing the corresponding softkey, the calc hangs. - If I put the string on the stack, execute S->EXE from the ARMToolBox, save the resulting program to a variable in HOME and run it by pushing the corresponding softkey, a string is returned to the stack (either empty, real or other depending on prior stack contents). This is the only case where the program works as expected. There's definetely something wrong with what I do, as I can't make any of my code run with PrRUN. > If you are using only 2.0, then check your makefiles, in particular The makefile contains this (I've removed empty lines): ***makefile start*** INCLUDE_PATH= $(HPGCC)include LIBS_PATH= $(HPGCC)lib export CC= arm-elf-gcc export AR= arm-elf-ar export ELF2HP= elf2hp export C_FLAGS= -mtune=arm920t -mcpu=arm920t -mlittle-endian -fomit-frame-pointer -Wall -Os -I$(INCLUDE_PATH) -L$(LIBS_PATH) #add this for Thumb interwork mode: export C_FLAGS += -mthumb-interwork -mthumb export LD= arm-elf-ld export LD_FLAGS= -L$(LIBS_PATH) -T VCld.script $(LIBS_PATH)/crt0.o export LIBS= -lwin -lggl -lhpg -lhplib -lgcc SRC = $(shell echo *.c) OBJ = $(SRC:%.c=%.o) EXE = $(SRC:%.c=%.exe) HP = $(SRC:%.c=%.hp) all: $(HP) install: all clean: rm -rf *.o *.hp *.exe %.o: %.c $(CC) $(C_FLAGS) -c $< %.exe: %.o $(LD) $(LD_FLAGS) $< $(LIBS) -o $@ %.hp: %.exe $(ELF2HP) $< $@ ***makefile end*** Steen === Subject: Strange files on port 0 with scrambled filename Normally, there are no files onport0 when I check it. Just found that there are 10 more files on my port0 (but HOME) with scrambled file names. I exit FILER6 and run built in Filer. My 49g+ crashed. After reset my 49g+. The strange files on port 0 reduced to 4. The filenames are scrambled. To see the contents, they are XLIB 0 18,XLIB 822 832, XLIB 1857 1971 and External. I don't know what are these. Does these caused my 49g+ crashed occasionally. Do I need to delete them? === Subject: Re: Strange files on port 0 with scrambled filename The 49g+ also showed invalid card data after ON-F3 pressed. Now this calc crashes frequently. === Subject: Re: Strange files on port 0 with scrambled filename > Normally, there are no files onport0 when I check it. Just found > that there are 10 more files on my port0 (but HOME) with > scrambled file names. I exit FILER6 and run built in Filer. My > 49g+ crashed. After reset my 49g+. The strange files on port 0 > reduced to 4. > The filenames are scrambled. To see the contents, they are > XLIB 0 18,XLIB 822 832, XLIB 1857 1971 and External. > I don't know what are these. Does these caused my 49g+ > crashed occasionally. Do I need to delete them? > The 49g+ also showed invalid card data after ON-F3 pressed. > Now this calc crashes frequently. Type PINIT; also delete any files which you didn't put anywhere yourself (except default EQLIBs 226, 227, and any libraries you added). Have you been running any untested SysRPL/ML programs? If user memory is corrupted, problems may return; do you have any backups made before crashes? It is also known that copying the first object from HOME directly to port 2 (flash) may corrupt port 2 (with ROM version C-2.01, build 83 and possibly some earlier), but if you first copy it to port 1 and then from port 1 to port 2 it will be okay; this will surely be fixed in later ROM versions. [r->] [OFF] === Subject: Re: Strange files on port 0 with scrambled filename > Type PINIT; also delete any files which you didn't put anywhere > yourself (except default EQLIBs 226, 227, and any libraries you added). > Have you been running any untested SysRPL/ML programs? There're some program written by Tim Wessman and Wolfgang Rautenberg on port 2. > If user memory is corrupted, problems may return; > do you have any backups made before crashes? Yes, I backup port0 frequently. > It is also known that copying the first object from HOME > directly to port 2 (flash) may corrupt port 2 (with ROM > version C-2.01, build 83 and possibly some earlier), > but if you first copy it to port 1 > and then from port 1 to port 2 it will be okay; > this will surely be fixed in later ROM versions. I always copy programs from port0 to port2. I didn't know this bug before. Will re-install my port2 programs later. But I know the crash issue could be solved by removing Headman. Maybe the actual problem is that I copy programs from port0 to port2. Ted === Subject: What memory is used by flash re-packing? is needed for flash re-packing? Is it the same in 49G+ as in 49G? Is there any possibility that if memory isn't available, the result might be a corrupted flash, instead of just an error message such as Insufficient memory? All that I could find about this was buried in this thread: WH> The trouble is, you'll always need to erase a full bank. WH> When will you want to defragment the flash? WH> when you have no room left for a rather large file. WH> to store all files of the smallest bank. WH> (actually, erasing is done per half-bank - WH> that's where the nightmares come in) Is there any tool for seeing the real memory map (and fragmentation) of flash port 2? Is there any detailed explanation of the flash repacking procedure? Bien Merci === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > It is interesting that knowing all problems about keyboard etc. people > are still buying this calculator. Yes, I am wondering about this, too ... === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > Yes, I am wondering about this, too ... Just so they could run your hp41 emulator :) Jean-Yves === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > Just so they could run your hp41 emulator :) In this case I strongly support it :-) === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory On the 4 Dec 2005 Joe Horn reported in this newsgroup that there was hope and SOON that something would get better. I am not sure what or how soon but after 25+ years of watching it is clear HP issues new calculators around March-April and around September. So if HP has been listening the earliest change would be expected in April. Personally I don't think HP does listen anymore. It has lost the will to fight in the calculator field and is heavily reliant on Chinese suppliers developing something that could be rebadged as an HP machine. Hence the keyboard problem will have to wait until they not HP is ready to move on. > On Wed, 21 Dec 2005 19:39:28 +0100, Heiko Arnemann >> lore. >>Another issue are ramshackle ALPHA and LS-key, >>and movement of the F5 and F4-keys when >>pressing F6. Hey, what a quality :-( >>HP should change the brand name >>when delivering this low cost s... (no smiley here). >>What should the students think when investing >>quite a lot money? > It is interesting that knowing all problems about keyboard etc. people > are still buying this calculator. Maybe this is the same reason why > some woman marry alcoholic husband, get beaten, divorce and then do > the same again?... Psychologists have a theory that explains this > behavior... > A.L. === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory I don't think HP does listen anymore Gene: They don't? 1) Reissued 33S with better decimal point. 2) Reissued 12c platinum with parentheses 3) Released the 49g+ AUR 4) Updated the 49g+ ROM 5) .... If I were HP and I weren't listening, I wouldn't be doing any of these. One can always argue about choices that have already been made, but it does appear HP is listening and making improvements. Are there changes you might still like to see? Probably, but give credit where credit is due. === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory Gene <> schrieb > If I were HP and I weren't listening, I wouldn't be doing any of these. > One can always argue about choices that have already been made, but it > does appear HP is listening and making improvements. Are there changes > you might still like to see? Probably, but give credit where credit is > due. Hi Gene, you are right. The last 6 month a lot seem to have happend and there is quite a lot improvement which has been received by the customers. Especialy ROM and AUR. Honestly, go ahead with your possitive feetback! Personly, it is hard state all nice improvements, while beeing in conflict with obviously shortcomings. I will continue on focussing on insufficiencies. Heiko === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > Personly, it is hard state all nice improvements, while > beeing in conflict with obviously shortcomings. > I will continue on focussing on insufficiencies. A shortcomings that don't allow you a greater accuracy than 1s? How serious of a shortcoming is that ? Seriously, time to see the bright side a little bit instead of the always negative comment JY === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory Always on the defensive? Even though it wasn't your project? The best defense for HP might be to re-establish the ability which always used to be there, if it's at all possible and not too difficult. One company after another tells customers that some recently discovered problem which has alarmed its customers is really insignificant, and shouldn't really matter to them, and every company that does this seems to get really bad PR, just for dismissing the customer's point of view, whereas those who step up and take their own customers' side are generally seen in better light. This is not a question of technicalities or engineering, but one of relationships between organizations and clients, which is why it should not be left entirely to technical people, if they aren't just as well versed in relating to people. [r->] [OFF] === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory >> Personly, it is hard state all nice improvements, while >> beeing in conflict with obviously shortcomings. >> I will continue on focussing on insufficiencies. > A shortcomings that don't allow you a greater accuracy than 1s? How > serious of a shortcoming is that ? > Seriously, time to see the bright side a little bit instead of the always > negative comment Well everything else *IS* the brite side Nobody would by the Beast if it were not the Beauty also There are a few shortcomings, which prevents getting a+ Fix 1) Ccock & Alarm 2) CAS flags & vars interfearing 3) proper mechanism & material for the keyboard and the nagging grows smaller BUT that is HPQ's problem, not yours Merry Xmas to Jean-Yves, Gerald, Cyrille === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > Gene <> schrieb >> If I were HP and I weren't listening, I wouldn't be doing any of > these. >> One can always argue about choices that have already been made, but it >> does appear HP is listening and making improvements. Are there changes >> you might still like to see? Probably, but give credit where credit is >> due. > Hi Gene, > you are right. > The last 6 month a lot seem to have happend and there is > quite a lot improvement which has been received by the customers. > Especialy ROM and AUR. > Honestly, go ahead with your possitive feetback! > Personly, it is hard state all nice improvements, while > beeing in conflict with obviously shortcomings. > I will continue on focussing on insufficiencies. Indeed HPQ has hires outside help (and Cyrlille&Al are working 2) and thus we have AUR, new ROM is coming out perhaps new, improved top models BUT certain problems remain 1) mechanical keyboard durability (change to domes?) 2) clock/alarm system (do it finally right and TEST IT) 3) CAS flags & variable questions (hire Parisse back) ... VPN === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > 3) Released the 49g+ AUR Sorry about my last post, Gene. My memory totally failed me, as I was sure the AUR was released without the aid of HP. It had something to do with the fact that it was you that announced it and took it upon yourself to answer to peoples comments. I must've read the thread way too fast back then (and never got around to looking in the actual document again). Upon re-reading the AUR-announcement thread as well as looking through the AUR itself, it's evident that HP is behind it. I'm sorry for posting such rubbish - I'm glad HP put out the AUR all who participated in the making. I'm also sure HP is still working on the HP49G+ - I'm with you on that one :-) Steen === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > all who participated in the making. I'm also sure HP is still working > on the HP49G+ - I'm with you on that one :-) Hmm. . . are you SURELY SURE?!?!?! ;-) TW === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory >> all who participated in the making. I'm also sure HP is still working >> on the HP49G+ - I'm with you on that one :-) > Hmm. . . are you SURELY SURE?!?!?! ;-) but...but...I haven't even started yet... I'm waiting my inside person to contact me about the new models that HP has prepared - there are several, but nothing really new no 42SII no 15C Platinum some small enhancements to existing models and new small HPs They didn't even buy Qonos... )-`: Well, at least the WinCE PPC models are getting better each year! === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory http://www.educalc.net/181086.page New HP Calculator .... The HP8s Scientific Calculator was launched in South East Asia Market on 1 Jan 2006. The HP8s is a general purpose calculator that is perfect for math and science students. --> The new small HP ... > >> all who participated in the making. I'm also sure HP is still working > >> on the HP49G+ - I'm with you on that one :-) > > Hmm. . . are you SURELY SURE?!?!?! ;-) > but...but...I haven't even started yet... > I'm waiting my inside person to contact me about the new models > that HP has prepared - there are several, but nothing really new > no 42SII > no 15C Platinum > some small enhancements to existing models > and new small HPs > They didn't even buy Qonos... > )-`: > Well, at least the WinCE PPC models are getting better each year! === Subject: Re: HP8S On Fri, 23 Dec 2005 08:57:28 -0600: > http://www.educalc.net/181086.page > New HP Calculator: HP8s Scientific Calculator... Looks very much to me like a re-branded common Casio, much like some I've had in my desk for many years, tho the originals used to sell for more than US $12 fx-6300G comes to mind, in fact http://en.wikipedia.org/wiki/Fx-6300G Speaking of keyboards, that Casio has nice plastic keys, very low force, and mine has never worn out, never failed in any way; perhaps Kinpo should try reverse-engineering some of those. [r->] [OFF] === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > http://www.educalc.net/181086.page > New HP Calculator > .... > The HP8s Scientific Calculator was launched in South East Asia Market > on 1 Jan 2006. The HP8s is a general purpose calculator that is > perfect for math and science students. > --> The new small HP ... >>>>all who participated in the making. I'm also sure HP is still working >>>>on the HP49G+ - I'm with you on that one :-) >>>Hmm. . . are you SURELY SURE?!?!?! ;-) >>but...but...I haven't even started yet... >>I'm waiting my inside person to contact me about the new models >>that HP has prepared - there are several, but nothing really new >>no 42SII >>no 15C Platinum >>some small enhancements to existing models >>and new small HPs >>They didn't even buy Qonos... >>)-`: >>Well, at least the WinCE PPC models are getting better each year! Here is the url: http://www.educalc.net/1766087.page Here is the text: The HP 8s Scientific Calculator is a perfect calculator for Students solving everyday problems in the classroom. HP 8s is also a calculator for everyday living like adding shopping list expenditures, comparing volumes with prices, tracking day-to-day expenditures. HP 8s is perfect for office calculations and calculating quantities for home improvements. The built-in currency conversions in the HP 8s makes it an ideal traveling companion. The HP 8s comes with 240 functions with super visually perfect Algebraic Method for data entry with individual plastic keys, a dot matrix, 2-line display with 10 + 2 digits. HP 8s has a multi-replay function, fraction calculations, Combination and Permutation, Statistics. 9 variable memories, comes with slide-on hard case. HP8s Specifications: * HP 8s has a LCD view area of 61 x 18.8 pixels with 2 display lines. * 10 calculation digits and a maximum length of command line of 79 can be displayed on the HP 8s. * HP 8s can replay function: up, down, left, right. It has error indication and an easy to set Decimal point selection. * Scientific Functions on the HP 8s are trigonometric, inverse, logs, powers and roots of equations, permutations, combinations and factorials. With Scientific display of 10+2. * HP 8s has statistical features that can find mean, standard deviation, variance and regression analysis with STAT-data editor. * The HP 8s needs a power supply of 2 x CR2032 Battery with a life of between 3 to 5 years. Batteries included. * HP 8s physical size (L x W x D) is 15.7 x 7.5 x 1.2cm. * HP 8s weight is 120g. === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory Seen: The HP 8s Scientific Calculator is a perfect calculator for Students solving everyday problems in the classroom. HP 8s is also a calculator for everyday living like adding shopping list expenditures, comparing volumes with prices, tracking day-to-day expenditures. HP 8s is perfect for office calculations and calculating quantities for home improvements. The built-in currency conversions in the HP 8s makes it an ideal traveling companion. The HP 8s comes with 240 functions with super visually perfect Algebraic Method for data entry with individual plastic keys, a dot matrix, 2-line display with 10 + 2 digits. HP 8s has a multi- replay function, fraction calculations, Combination and Permutation, Statistics. 9 variable memories, comes with slide-on hard case. [End of quote] It's much less than fx-6300G, however, since it apparently has not even the tiny graphing window of the latter, no mention of programming, and only 9 memories (6300G has A thru Z, at least 26 right there). [r->] [OFF] === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > http://www.educalc.net/181086.page > New HP Calculator > .... > The HP8s Scientific Calculator was launched in South East Asia Market > on 1 Jan 2006. The HP8s is a general purpose calculator that is > perfect for math and science students. > --> The new small HP ... One for a test ALGebraic-ride, more to come... >> >> all who participated in the making. I'm also sure HP is still working >> >> on the HP49G+ - I'm with you on that one :-) >> > >> > Hmm. . . are you SURELY SURE?!?!?! ;-) >> > >> but...but...I haven't even started yet... >> I'm waiting my inside person to contact me about the new models >> that HP has prepared - there are several, but nothing really new >> no 42SII >> no 15C Platinum >> some small enhancements to existing models >> and new small HPs >> They didn't even buy Qonos... >> )-`: >> Well, at least the WinCE PPC models are getting better each year! === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > http://www.educalc.net/181086.page > New HP Calculator > .... > The HP8s Scientific Calculator was launched in South East Asia Market > on 1 Jan 2006. The HP8s is a general purpose calculator that is > perfect for math and science students. But there is no mention of RPN only algebraic! -- - - - - - - - - - - - - - - - - Bill Graves RKBA! bgraves@ix.netcom.com === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory casati schrieb im Newsbeitrag > http://www.educalc.net/181086.page > New HP Calculator > .... > The HP8s Scientific Calculator was launched in South East Asia Market > on 1 Jan 2006. The HP8s is a general purpose calculator that is > perfect for math and science students. > --> The new small HP ... Interesting thing is that it 'was launched [..] on 1 Jan 2006' . Should that indicate that 'hp' is still beyond the real world time? Aside from that, I think I saw a similar calc recently, from an Asian company... However, it doesn't look that bad, kinda retro design, straight (not droite) rectangular shape and black, like it should be, much nicer than the recent banana shaped and colored calcs IMHO;-) Let's hope it has reasonable keys Raymond === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > 3) Released the 49g+ AUR This was not HP. Steen === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > > 3) Released the 49g+ AUR > This was not HP. How does hiring people (Gene and others) to create something count as not HP? Just curious. . . TW === Subject: Re: hp 49g+, ROM 2.01 build 83, keyboard and try to recover memory > > > 3) Released the 49g+ AUR > > > > This was not HP. > How does hiring people (Gene and others) to create something count as > not HP? Just curious. . . My bad, see my second post to Gene :-/ Steen === Subject: [WANTED] HP48GX screen Hello all, I got an HP48GX with (guess what)... a broken screen. I was wondering if anyone out there would have a non working HP48SX/GX with a working screen to give/sell ? I used to use this calculator a lot everyday when I was a studient, so I'd really like to fix it whatever the price (as long as it is below a brand new HP49). I'm willing to pay for the postal fees, as for the calculator itself. I'm rather interested in a HP48SX/GX with a working screen, than a working screen on its own. Hope someone will feel sympathy for my loneliness without my HP48... Brice === Subject: Re: [WANTED] HP48GX screen I have a dying HP48G (the screen may be identican to the one of the GX) the screen is OK but the keyboard is slowly loosing cap after cap. I would offer it to anyone, but you would have to pay the shipping from France. Interested ? > Hello all, > I got an HP48GX with (guess what)... a broken screen. > I was wondering if anyone out there would have a non working HP48SX/GX > with a working screen to give/sell ? > I used to use this calculator a lot everyday when I was a studient, so > I'd really like to fix it whatever the price (as long as it is below a > brand new HP49). I'm willing to pay for the postal fees, as for the > calculator itself. I'm rather interested in a HP48SX/GX with a working > screen, than a working screen on its own. > Hope someone will feel sympathy for my loneliness without my HP48... > Brice === Subject: Re: [WANTED] HP48GX screen > I have a dying HP48G (the screen may be identican to the one of the GX) > the screen is OK but the keyboard is slowly loosing cap after cap. I > would offer it to anyone, but you would have to pay the shipping from > France. Interested ? A HP48G keyboard going bad?? come on .. I thought this was impossible ?? this kind of stuff can only happened to the 49g+ remember? JY === Subject: Re: [WANTED] HP48GX screen >> I have a dying HP48G (the screen may be identican to the one of the >> GX) the screen is OK but the keyboard is slowly loosing cap after cap. >> I would offer it to anyone, but you would have to pay the shipping >> from France. Interested ? > A HP48G keyboard going bad?? come on .. I thought this was impossible ?? > this kind of stuff can only happened to the 49g+ remember? > JY Then I have a collector !-) === Subject: Re: [WANTED] HP48GX screen > A HP48G keyboard going bad?? come on .. I thought this was impossible ?? > this kind of stuff can only happened to the 49g+ remember? Now, now, it's perfectly acceptable after 10 years of having the daylights beat out of it, but not fresh out of the box! Scott Chapin === Subject: Re: [WANTED] HP48GX screen Seen: > A HP48G keyboard going bad?? come on .. I thought this was impossible ?? > this kind of stuff can only happened to the 49g+ remember? It has even happened to the HP34C (and all of its era); however: o It took a lot of use before keyboard wore out. o Back then, HP stood by its products, not only replacing them, but admitting the fault, and even redesigning them while still in current production. I still admire Casio and Sharp for making so many indestructible keyboards and equipping even their cheapest products with them. I happen to find low-force keys much easier to use, and even suspect that the very need for hard pressing on recent HP products accelerates their demise. [r->] [OFF] === Subject: Re: HP48GX screen <43ab276d$0$29224$8fcfb975@news.wanadoo.fr> <41138dF1c079aU1@individual.net> > A HP48G keyboard going bad?? come on .. I thought this was impossible ?? > this kind of stuff can only happened to the 49g+ remember? > JY very strange, in our surveyor's practice we've got 10+ HP48's 12-10-8-6 years old, used all the time and no failure yet... cheers, reth === Subject: Re: HP48GX screen <43ab276d$0$29224$8fcfb975@news.wanadoo.fr> <41138dF1c079aU1@individual.net> I thought that hp48g series keyboard was unbreakable too... unless you play too much Phoenix game :-)) Nevertheless if you look at hp48 prices on ebay i don't think it's a good idea to repair your calculator. Perhaps you sould buy another one ? === Subject: Re: HP48GX screen <43ab276d$0$29224$8fcfb975@news.wanadoo.fr> <41138dF1c079aU1@individual.net> This only happens with a 49G+ that is brand new!! (What is the MTBF of a 48GX keyboard before it begins to fail?? It is certainly much greater than ZERO.) [MTBF == Mean Time Before Failure] There is NO (did I emphasize NO) excuse to produce ANY product which Yes, I know - we are all frustrated, but I just had to vent! TomCee === Subject: Re: HP48GX screen > This only happens with a 49G+ that is brand new!! (What is the MTBF of > a 48GX keyboard before it begins to fail?? It is certainly much > greater than ZERO.) > [MTBF == Mean Time Before Failure] > There is NO (did I emphasize NO) excuse to produce ANY product which > Yes, I know - we are all frustrated, but I just had to vent! Had a bad day, ate too much chilli ? Did you read the thread before posting this rant? it's about a 48GX === Subject: Re: HP48GX screen <43ab276d$0$29224$8fcfb975@news.wanadoo.fr> <41138dF1c079aU1@individual.net> <411klpF1clnlbU1@individual.net> Yes I did read the thread. I apologize for not being crystal clear, my 'rant' is directed at the (lack of ) quality of current HP products. > > This only happens with a 49G+ that is brand new!! (What is the MTBF of > > a 48GX keyboard before it begins to fail?? It is certainly much > > greater than ZERO.) > > [MTBF == Mean Time Before Failure] > > There is NO (did I emphasize NO) excuse to produce ANY product which > > Yes, I know - we are all frustrated, but I just had to vent! > Had a bad day, ate too much chilli ? > Did you read the thread before posting this rant? it's about a 48GX === Subject: Re: HP48GX screen >> This only happens with a 49G+ that is brand new!! (What is the MTBF of >> a 48GX keyboard before it begins to fail?? It is certainly much >> greater than ZERO.) >> [MTBF == Mean Time Before Failure] >> There is NO (did I emphasize NO) excuse to produce ANY product which >> Yes, I know - we are all frustrated, but I just had to vent! > Had a bad day, ate too much chilli ? > Did you read the thread before posting this rant? it's about a 48GX Now it's also about the comparison between the 48GX & 49g+ I have to admit that 83 solves most of the problems for me but many reports of the broken keyhinges of the 49g+ brings into my memory the power failures of the E-series There must have been other problems too HPQ must go back to domes in order to get a good keyboard Just making the keyhinges 2*thicker & plastic more flexible is simply not enough Did you find a good keyboard for Qonos? === Subject: Re: HP48GX screen <43ab276d$0$29224$8fcfb975@news.wanadoo.fr> <41138dF1c079aU1@individual.net> <411klpF1clnlbU1@individual.net> It's the first time I hear about a keyboard defection on the HP-48 families. I have many HP-48 and after 15 years of intensive use, none of them have keyboard defection (except the a screen defection on one). Same for my other HP-28 machines and HP-19 machines. By the way, one of my oldest HP-48sx has one vertical line on the left which is not displayed. I suppose it is because of plug-ins exchange over the time. As it is the original subject of this topic, I would like to know if it is repairable. Someone in France can repair it for a reasonable price? I'm not familiar with electronics and hardware. === Subject: Re: HP48GX screen Hi Fred, recently there was a thread about this either here in c.s.hp48 or the hpmuseum forum about repairing HP-48 units. One of the posters even gave a detailed explanation with pictures on how to open an HP-48. Should I forward the doc to you via mail? And yes, comparing the HP-48 build quality with the build 'quality' of the 49g/g+ is like comparing apples and oranges IMHO. None of the very many HP-48 units I have or had has a defective keyboard, even my first HP-48SX (Serial #3003A..) still works perfectly, but every 49g (Rubber Duck) unit I had did have keyboard response problems, and my first 49g+ had missing keystrokes, of course (aside from a broken screen) . My 2nd 49g+ is still new in the blister, and waiting to be sold. Of course there's no guarantee that there won't be a failure on an HP-48 ever, but this is *very* different to some current 'hp' products which seem to be made to break 'out-of-the-box' or shortly after, according to the many related threads here in c.s.hp48 . Raymond schrieb im Newsbeitrag > It's the first time I hear about a keyboard defection on the HP-48 > families. I have many HP-48 and after 15 years of intensive use, none > of them have keyboard defection (except the a screen defection on one). > Same for my other HP-28 machines and HP-19 machines. > By the way, one of my oldest HP-48sx has one vertical line on the left > which is not displayed. I suppose it is because of plug-ins exchange > over the time. As it is the original subject of this topic, I would > like to know if it is repairable. Someone in France can repair it for a > reasonable price? I'm not familiar with electronics and hardware. === Subject: Re: HP48GX screen X > And yes, comparing the HP-48 build quality with > the build 'quality' of the 49g/g+ is like comparing apples and oranges > IMHO. 49g keys worked... > None of the very many HP-48 units I have or had has a defective keyboard, > even my first HP-48SX (Serial #3003A..) still works perfectly, > but every 49g (Rubber Duck) unit I had did have keyboard response > problems, > and my first 49g+ had missing keystrokes, of course (aside from a broken > screen) . Mine don't miss keystrokes with build 83 === Subject: Re: HP48GX screen Brother-Peter schrieb im Newsbeitrag >> And yes, comparing the HP-48 build quality with >> the build 'quality' of the 49g/g+ is like comparing apples and oranges >> IMHO. > 49g keys worked... That seems to be a romantic wish;-) Just recall the related c.s.hp48 threads about this topic. I won't quote it all here again, only this: On the first 49g I had in my hands back then, you had to use a hammer for the keys to register. Of course the hammer could also be used to finally turn off the unit;-) On 'newer' units you had to press nearly exactly in the middle of the key face, else it would likely 'click', but not always register. And finally the mess with KEYTIME, which filled many threads. No other calc ever needed s.t. similar... >> [..] >> and my first 49g+ had missing keystrokes, of course (aside from a broken >> screen) . > Mine don't miss keystrokes with build 83 Maybe, but you acknowledged here in c.s.hp48 that your unit still has double key registers here and there. One could ask if it's better to have a key not registered instead of having double (erranous) entries... However, it's near to Xmas, so enjoy;-) Raymond === Subject: Re: HP48GX screen > Brother-Peter schrieb im Newsbeitrag >> 49g keys worked... > That seems to be a romantic wish;-) > Just recall the related c.s.hp48 threads about this topic. > I won't quote it all here again, only this: > On the first 49g I had in my hands back then, > you had to use a hammer for the keys to register. X Naaah! I won several fingerwrestling contests and I'm also known as the Strongest Geek in Finland just one year after the release of the 49G You Windows-Icon-Mouse-Pointer Man just remember that CAT [b]eats the Mouse! Brother-Peter PS: Just teasing, Ray PPS: if ever change your name, I'll call you X-Ray === Subject: Re: HP48GX screen <43ab276d$0$29224$8fcfb975@news.wanadoo.fr> <41138dF1c079aU1@individual.net> <411klpF1clnlbU1@individual.net> Hi Raymond, I have effectivly the document that explain how to open the calculator without damages. But as I know nothing about electronics and hardware, I'm looking for someone who can repair my calcualtor. fred. === Subject: Re: [WANTED] HP48GX screen > I have a dying HP48G (the screen may be identican to the one of the GX) > the screen is OK but the keyboard is slowly loosing cap after cap. I would > offer it to anyone, but you would have to pay the shipping from France. > Interested ? The foam died, replace with new and it works again That is, if it started from [ON] then shift keys and ALPHA >> Hello all, >> I got an HP48GX with (guess what)... a broken screen. >> I was wondering if anyone out there would have a non working HP48SX/GX >> with a working screen to give/sell ? >> I used to use this calculator a lot everyday when I was a studient, so >> I'd really like to fix it whatever the price (as long as it is below a >> brand new HP49). I'm willing to pay for the postal fees, as for the >> calculator itself. I'm rather interested in a HP48SX/GX with a working >> screen, than a working screen on its own. >> Hope someone will feel sympathy for my loneliness without my HP48... >> Brice === Subject: SLOAD: Illegal First Character in Name All right. I was programming last night and everything was running fine. This morning I got up, opened debug4x and this message started showing up. As far as I can tell, nothing has changed since last night. Anyone have any ideas what might be wrong? TW === Subject: Re: SLOAD: Illegal First Character in Name SLOAD is the linker. Illegal first character sounds like something garbled one of the external names. You can select Project Data Tab, :keep intermediate files, recomplile. Then you have the .lr etc files to look through to give you a hint. -- - - - - - - - - - - - - - - - - Bill Graves RKBA! bgraves@ix.netcom.com === Subject: Re: SLOAD: Illegal First Character in Name of my source files had turned into jibberish. It is kind of strange actually, the formatting is correct, just all the characters are replaced with random characters. I have no idea how that could have possible happened. Luckily I had a 2 week old backup and nothing had changed in that file since. . . TW === Subject: Re: SLOAD: Illegal First Character in Name if the garbage chars are all on the same x position, maybe you have a bad sector on your HD? Or do you use that strange editor control that came with the orig. Debug2x....? Raymond schrieb im Newsbeitrag > of my source files had turned into jibberish. It is kind of strange > actually, the formatting is correct, just all the characters are > replaced with random characters. I have no idea how that could have > possible happened. Luckily I had a 2 week old backup and nothing had > changed in that file since. . . > TW === Subject: Re: SLOAD: Illegal First Character in Name i doubt it would be a bad sector. It changed this: :: 100 ZERO_DO (DO) LOOP ; To Something Like This #SW^4 sJH&F4 Wh !*7 DD$#%DF $hg $FS4 D That is just what it was like, not an actualy cut. whitespace wasn't touched, just any other character. No detectabel virii or anything. I use the latest Debgu4x version. It really was a wierd thing. Has anyone got debug4x running in WINE? I haven't been able to get everything functional last time I tried. EMulator doesn't matter as I do my testing on the real calc. That is the last thing keeping me from switching completely. TW === Subject: Re: SLOAD: Illegal First Character in Name Your PC has been demonized by Zeltsar! >i doubt it would be a bad sector. It changed this: > :: > 100 > ZERO_DO (DO) > LOOP > To Something Like This > #SW^4 sJH&F4 > Wh > !*7 > DD$#%DF $hg > $FS4 > That is just what it was like, not an actualy cut. whitespace wasn't > touched, just any other character. No detectabel virii or anything. I > use the latest Debgu4x version. It really was a wierd thing. > Has anyone got debug4x running in WINE? I haven't been able to get > everything functional last time I tried. EMulator doesn't matter as I > do my testing on the real calc. That is the last thing keeping me from > switching completely. > TW === Subject: Re: A new story... > A calculator user (how did that TI guy slip in?) > presses [ 2 ] [ * ] > What the... So a TI user can have a gifted mind? ;-) Bhuvanesh. === Subject: Re: A new story... >> A calculator user (how did that TI guy slip in?) >> presses [ 2 ] [ * ] >> What the... > So a TI user can have a gifted mind? ;-) So it was you, Bhuv! http://www.wolfram.com/ Research SuperStars don't count as (standard) TI users... === Subject: Re: GNU ==> small & probably stupid question GNU is an acronym for GNU's Not Unix. If something is referring to a GNU license they probably mean the GPL, GNU Public License. Much code is released under this license (LINUX for example) because the goals of the License are to maximize user freedom, and inter-user co-operation. Contrast this with most software licenses whose goals are to minimize user freedom and prevent user co-operation. === Subject: invalid card data I rarely use my calculator anymore, but I decided to take it to class with me a few days ago. It worked before I left, but when I got there and turned it on I got the warning: invalid card data error. I have two klotz cards, a 128k one with metakernal, and a larger one. Metakernal is not running, so the problem must be with the 128k card. I am not sure what is wrong or how to fix it. I have completly forgotten how I installed the cards in the first place a few years ago. Could the watch battery have ran out, or is there some other diagnostic test I should do first? === Subject: Re: invalid card data On Thu, 22 Dec 2005 16:54:05 -0600: > I rarely use my calculator anymore, but I decided to take it to class > with me a few days ago. It worked before I left, but when I got there > and turned it on I got the warning: invalid card data error. > I have two klotz cards, a 128k one with metakernal, and a larger one. > Metakernal is not running, so the problem must be with the 128k card. Since cards are checked immediately upon turning calc on, either or both cards could cause the message, if it appears not fully formatted nor with all objects valid. > I am not sure what is wrong or how to fix it. I have completly > forgotten how I installed the cards in the first place a few years ago. > Could the watch battery have ran out, or is there some other diagnostic > test I should do first? o It doesn't interfere with calculating if you don't use any card data (or libraries) o Make sure that cards are inserted snugly; to try to assure clean connections, you could wiggle slightly without pulling out. o When you turn on the HP48GX, low battery warnings should appear if any batteries are detected low (unless you are using cards not properly modified for HP48 voltage levels, but Klotz knows all about that, and should have built the cards accordingly). o If you need to replace any card batteries, leave the cards fully inserted in the calc and the calc turned ON (also with fresh AAA cells in the calc) while you change the card batts. Be careful not to dislodge a card while pulling out its batt. o When you are sure that cards have good batts, you can remove one card at a time (remove only with calc OFF) to see whether the Invalid card data message goes away. o If the message persists with one of the cards, the only way to repair is to insert card (write-enabled), turn on calc and type PINIT command -- if there was corrupt data, some objects might disappear from doing PINIT, so if you needed any vital data not elsewhere backed up, better copy it to HOME and/or backup to a computer first. Good luck! [r->] [OFF] === Subject: OPENFIRE NEWS Since the demo for OPENFIRE was old and outdated, also very few people used openfire to develop their own programs. I finaly cought some time to release a nice small sprite demo. Demo is pure UserRPL to encurage less experienced programers code can easily be read without need for any special tools. Background, Mask and Sprite are in external variables (files) to make them easily accessible. Marry Christmass !!! see you later... http://fly.srk.fer.hr/~/openfire === Subject: Re: OPENFIRE NEWS dofjub$lgp$1@ss405.t-com.hr... > Since the demo for OPENFIRE was old and outdated, > also very few people used openfire to develop their own programs. > I finaly cought some time to release a nice small sprite demo. > Demo is pure UserRPL to encurage less experienced programers code can > easily > be read without need for any special tools. > Background, Mask and Sprite are in external variables (files) to make them > easily accessible. > Marry Christmass !!! > see you later... > > http://fly.srk.fer.hr/~/openfire === Subject: Re: A possible ROM enhancement... <40up4cF1ciqokU2@individual.net> <410lcdF1cs00eU1@individual.net> I understand that enhancing the current debugger is a complex task. When it'll be done it'll be a good evolution :) === Subject: Re: A possible ROM enhancement... > Hello guys, > I noticed that the internal debugger do not fully debug SysRPL programs > (like loops). > What about enhancing the debugger for the next ROM revision? > The debugger could additionnally debug SysRPL and assembler (like user > asm code and SysRPL primitives). Cause Debug4x does it much better ? JY === Subject: Re: EMU48 updates Sorry, wrong address. This is a bug of wine and not of Emu48. Be sure that Emu48 works properly on the supported operating systems and Emu48 definitely use only supported API function calls. Christoph Khanh-Dang schrieb im Newsbeitrag > v.guilbault@free.fr a ̩crit : > > The latest Win9x/NT4/2000 version is now 1.40 for example. > Yes, I've just tried it yesterday, with wine, the win32 API > implementation for x86-UNIX: . Nothing new for me: > the screen keeps beeing not as expected. Indeed, depending on the KML > file used with a 48 ROM, the screen is yellow and white, black and red. > Fortunately, the jemac's KML works flawlessly. > For emu48 and 49 ROMs, I keep getting a black screen. I think it's a KML > issue because the saturn chip seems to be emulated correctly (I just > went to the debugger to verify that). > The KML issue is really the point, because it makes emu48 unusable with > wine, and it's really a shame that people that have no Microsoft Windows > system at home cannot use such a good emulator. Christoph, I should be > really gratefull if you would write a small patch for handling the > screen in a safe-mode way (i.e. that doesn't follow the KML files, and > always draw black or white pixels, with no support of grey effects). I > would really have liked to write the patch myself instead of asking > someone else, but my win32 API is more than limited. === Subject: Re: EMU48 updates <43a7c1a7$0$19711$8fcfb975@news.wanadoo.fr> what i dont understand with emu48 is that 49g+ kml scripts works good for me with rom 1.24 or 2.00 (without arm emulation of course) but only with emu48 1.36. Since that all newer versions (1.37 to 1.40) don't work for 49g+ emulation. Why ? === Subject: Re: EMU48 updates Only Emu48 Plus versions can simulate the 49G+. In the Emu48 v1.36 Plus version the + behind the version number was missing. My classic Emu48 versions don't contain any 49G+ simulation code. To get a newer Emu48 Plus version download the latest Debug4x version. Christoph grokwik schrieb im Newsbeitrag > what i dont understand with emu48 is that 49g+ kml scripts works good > for me with rom 1.24 or 2.00 (without arm emulation of course) but only > with emu48 1.36. > Since that all newer versions (1.37 to 1.40) don't work for 49g+ > emulation. Why ? === Subject: HP-48 and engineering tutorials I found a web site done by James Calvert, associate professor emeritus of engineering at Univ. of Denver: http://www.du.edu/~jcalvert/ This is his home page, if you click on the Engineering I especially enjoyed his survey of vacuum tube electronics in the Review of Electronics (section 29). He must be a wonderful teacher. Ed === Subject: a few HPGCC questions Hats off to all the folks who have been working on HPGCC. You have done an outstanding job to which we are all very grateful. I've noticed a few of things that I wanted to ask about. Perhaps I'm doing something wrong. 1) If I have a simple C program that acts as a function (pops a value off the stack, does some sort of calculation with that value, and returns the result to the stack), there is a noticeable screen flicker when the program is executed. If you graph such a function, the screen flickers considerably like it's out of sync during the graphing process. I did not notice any such flicker with HPGCC 1.1, but when I recompile with 2.0 the flicker is there. Is there something I should be doing to avoid the flicker? Is there any danger in the flicker, like messing up the screen hardware? (I fried a monitor one time using too high of a refresh rate, so I'm a little paranoid.) 2) If I do something like: printf(%dn, sizeof(int) ) I get the following warning: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int' It seems that the result of sizeof is a 'long unsigned int' instead of 'unsigned int'. Even though these two are the same size, they are treated as different types and therefore generates warnings. I see in kos.h, size_t is defined to be 'unsigned int' but the sizeof operator isn't following this. 3) Even though the compiler supports the 'long long integer' and 'long double' keywords, the printf() function does not seem to support the %lld (long long integer) or %Lf (long double) modifiers. It looks like 'long long integer' is using %L which I'm pretty sure is not standard. And a few questions: - Are the hpstack and parser libraries compatible with hpgcc 2.0 if they are recompiled? - Any plans to implement the scanf() family of functions? - Does regular gcc support a 16 byte (or at least > 8 byte) 'long double' for ARM, and if so, could it be implemented into hpgcc? wes