Subject: Re: [newbie] .asc file and create dir This is really interesting, with the NO CONNECTION PROBLEM youre not alone... I think you read all the other postings with the usb probs? Tried the new drivers, the new connectivity kit, another usb port, maybe another PC, another cable and nothing worked? then welcome to the club... did you try manually XRECV? (see here: http://home.arcor.de/c.buhmann/) buhmann e schrieb im Newsbeitrag > I have to transfer a file from pc to Hp 49g+. I cannot use usb because > connection fails (I tried last driver and connectivity tool and avery other > possible way, only once with success but, without apparentrly changing > anything, conection returned not to work), so I use an SD card. > The file is .asc but when I transfer it, it doesn't create a dir with all > files inside. > The file stars so: > %%HP: T(3)A(R)F(.); > DIR > PPAR { (0,-1.2) > (5,1.2) T 0 { (0,0) > Can someone help me recreating the dir with all files inside?? === Subject: do HP-calculators die out? Hi I have a HP49 and am not really happy with it, cause his f** slow. My friends have a TI and it's really fast. So I decided to buy a new one, but I read somewhere that HP-calculators may die out some time. What is better to buy a TI and I can be sure to get ROM-Updates, or is the new HP49+ still as good as the TI voyage 200? Actually whats coming after the HP49+ are there some new developments in progress? === Subject: Re: do HP-calculators die out? > Hi > I have a HP49 and am not really happy with it, cause his f** slow. > My friends have a TI and it's really fast. > So I decided to buy a new one, but I read somewhere that > HP-calculators may die out some time. > What is better to buy a TI and I can be sure to get ROM-Updates, or > is the new HP49+ still as good as the TI voyage 200? > Actually whats coming after the HP49+ are there some new developments > in progress? I'm probably not very typical of the guys who live at this group. I have used HP calculators exclusively for 30 years. The last program I I bought a PC. HP used to have this annoying habit of changing the keyboard with every new model, so I bought about a half dozen HP-32Ss and gave one to my everyone in my design team. This was many years ago. I did this so that when I was at their desk or bench, I could pick up a calculator and instantly use it. I moved on to start another company. I kept two for myself, one finally died last spring. I learned that HP was getting out of the calculator business (sort of) when it was too late. I might have bought six HP32SII calculators but they became very expensive on ebay. Both my wife and my daughter have TI calculators. I NEVER USE THEM. I would rather use paper or Excel. They were both purchased because the schools they attended required TI. This situation, multiplied over and over probably lead to the absolute market dominance of TI. Reminds me of a company in Redmond, WA. I don't know anyone with competence in RPN who would ever want to go back to gebraic entry. Unfortunately, the calculator group stayed at HP instead of going to Agilent. Carly and her cronies never understood that the HP Calculator was more than a profit center. I doubt she even knows how to use one. There isn't much demand for a calculator in medieval history. I am disappointed that the new calculators are evidently poorly constructed. Price is less important to the remaining HP cuser or prospect than quality. I am trying to decide from one of the following: 1. Buy 1 or 2 HP48GII or HP49+ calculators. 2. Wait for a Qonos and hope it delivers. 3. Buy a used HP48GX I would probably be content if I could find a few HP32S or HP32SIIs at a reasonably price. So succumb to the dark side if you must (and buy a TI), but I am still an optimist. -- -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com === Subject: Re: do HP-calculators die out? >I am disappointed that the new calculators are evidently poorly >constructed. Price is less important to the remaining HP cuser or >prospect than quality. I am trying to decide from one of the following: >1. Buy 1 or 2 HP48GII or HP49+ calculators. >2. Wait for a Qonos and hope it delivers. >3. Buy a used HP48GX >I would probably be content if I could find a few HP32S or HP32SIIs at a >reasonably price. What is wrong with HP 33S?... I don't remember HP 32S, actually I have never had one. What are the differences between both?... A.L. === Subject: Re: do HP-calculators die out? > What is wrong with HP 33S?... I don't remember HP 32S, actually I have > never had one. What are the differences between both?... Here's what I think is wrong (that is, why I don't buy one): stupid chevron key layout, illegibly small radix mark, and they miss keystrokes too, though perhaps not as bad as the 49g+. Now I better shut up and let someone who knows more about it talk..... === Subject: Re: Old-timers' mini-challenge OFFICIAL ENTRY OFFICIAL ENTRY (revised) Version 2 This is a recursive program, so it must be saved with the name 'R' or have name changed within program to match the name it is saved under. If the 8 character name is still required, it will come in at 72.5 byes but with a 1 character name it comes in at 65.5 bytes. Model hp49+ (uses NDUPN so only works on models with that command) Bytes 65.5 (or 72.5 depending on naming requirements) Checksum # A8CDh (with 'R' as name) %%HP: T(3)A(R)F(.); << OVER SIZE { SWAP OBJ-> 1 - ->LIST UNROT DUP2 TYPE =/ NDUPN ->LIST UNROT R + } :: DROP IFTE > Now we getting on the recursive solution I mentioned earlier > Very beautiful work - more like this I like to see > PS: { DROP } ~ ::DROP (or ::;) And many other posters for other hints, e.g., =/ NDUPN ->LIST === Subject: Re: Old-timers' mini-challenge X-NNTP-Client: ROBOT/LX Hi Veli-Pekka Nousiainen ! in message ID : [...] > Now we getting on the recursive solution I mentioned earlier > Very beautiful work - more like this I like to see > PS: { DROP } ~ ::DROP (or ::;) Very beautiful indeed. And hard to write, as I discovered by trying to make a shorter exit. If only that ::; saved bytes over the ::DROP. Oh, it would in a string. Hey , in view of the beauty maybe you could relax the 8 byte name handicap to 5 . After all we can only see 5 chars on the softkeys. -- === Subject: Re: Old-timers' mini-challenge > OFFICIAL ENTRY > Hi > in message ID : >2. 49G, 49g+ >------------ >70.5 bytes. Checksum is #A9F7h on 49g+. >Takes example_of_type as input. > This one is the same size but takes type as input. > I got the idea from my dog. She just leaped ever so high to > grab my food and I thought of 5 PICK!! So, it's not my idea, > and it is quite ridiculous to keep checking on the size of the > original, but it stops the invisible program from getting > through. Anyway here it is. You'd think we'd be able to go > under 70.5 bytes for the 49G/g+ as we are only 0.5 bytes under > Werner's 48G version. > 49G, 49g+ > --------- > 70.5 bytes. Takes type as input. > Handles example of type with initial TYPE. @ Author: Hutchins @ 48S Checksum: N/A @ 48S Size: N/A @ 48G Checksum: N/A @ 48G Size: N/A @ 49G Checksum: # 608Dh @ 49G Size: 70.5 @ 49g+ Checksum: N/A @ 49g+ Size: N/A @ Download to 49 in exact mode. @ Level 1 argument: Real type number @ Works. > %%HP: T(3)A(R)F(.); > << { } PICK3 1 > << PICK3 OVER TYPE =/ 5 PICK SIZE AND NDUPN ->LIST + > >> DOLIST UNROT DROP2 > > Checksum is #608Dh on 49g+ -- === Subject: Re: Old-timers' mini-challenge X-NNTP-Client: ROBOT/LX Hi , Hope you are feeling better. in message ID <46Kvd.1018$lV.268@fe39.usenetserver.com> : >OFFICIAL ENTRY >Hi >in message ID : [...] It will fail for a blank list as input on the 49G. >49G, 49g+ >--------- >70.5 bytes. Takes type as input. >Handles example of type with initial TYPE. > @ Author: Hutchins > @ 48S Checksum: N/A > @ 48S Size: N/A > @ 48G Checksum: N/A > @ 48G Size: N/A > @ 49G Checksum: # 608Dh > @ 49G Size: 70.5 > @ 49g+ Checksum: N/A > @ 49g+ Size: N/A Needs to be > @ 49G Checksum: N/A > @ 49G Size: N/A > @ 49g+ Checksum: # 608Dh > @ 49g+ Size: 70.5 >%%HP: T(3)A(R)F(.); > << { } PICK3 1 > << PICK3 OVER TYPE =/ 5 PICK SIZE AND NDUPN ->LIST + > >> DOLIST UNROT DROP2 >> -- === Subject: Re: Old-timers' mini-challenge > Hi Virgil ! [...] > %%HP: T(3)A(R)F(.); ><< OVER SIZE { SWAP OBJ-> 1 - ->LIST UNROT DUP2 TYPE =/ NDUPN >->LIST UNROT R + } { DROP } IFTE >> ::DROP instead of {DROP} saves 1.5 bytes. > So, down to 72.5 even with that 8 byte handicap! > Virgil, I don't yet understand how this one works - but it > does! > Oh I think I see, it progressively reducues the size of the > list .. yup OBJ-> 1 - ->LIST is like DUP HEAD SWAP TAIL, but > much shorter in bytes! Just tried a quick DBUG to see it in > action but I'll need a HALT somewhere I think :-) Try putting 41. MENU HALT between the first { and the following SWAP, and then running the program. You can then go step by step from the DEBUG menu soft keys which will already be showing. I find this insertion of 41. MENU HALT very helpful in getting to the heart of a debugging problem. === Subject: Re: Old-timers' mini-challenge X-NNTP-Client: ROBOT/LX Hi Virgil ! [...] >Oh I think I see, it progressively reducues the size of the >list .. yup OBJ-> 1 - ->LIST is like DUP HEAD SWAP TAIL, but >much shorter in bytes! Just tried a quick DBUG to see it in >action but I'll need a HALT somewhere I think :-) > Try putting 41. MENU HALT between the first { and the following > SWAP, and then running the program. You can then go step by step from > the DEBUG menu soft keys which will already be showing. > I find this insertion of 41. MENU HALT very helpful in getting to the > heart of a debugging problem. to how I guessed. I was imagining the output list being built-up as it went along but it puts the separate items in the output list on separate stack levels and then combines them, including a {} on the last pass. Absolutely fascinating! -- === Subject: Re: Old-timers' mini-challenge <10686260ROBOTLX@news.individual.net> X-NNTP-Client: ROBOT/LX Virgil! in message ID <10686260ROBOTLX@news.individual.net> : > Hi Virgil ! %%HP: T(3)A(R)F(.); ><< OVER SIZE { SWAP OBJ-> 1 - ->LIST UNROT DUP2 TYPE =/ NDUPN >->LIST UNROT R + } { DROP } IFTE >> ::DROP instead of {DROP} saves 1.5 bytes. > So, down to 72.5 even with that 8 byte handicap! I just found you 2.5 more bytes I think. This makes you a clear 49G/g+ winner on 70 bytes!! Change this << OVER SIZE { SWAP OBJ-> 1 - ->LIST to this << SWAP OBJ-> DUP {1 - ->LIST I replaced OVER SIZE with DUP and just shifted the IFTE clause a bit further in. It still seems to provide the required exit - so it knows when not to call itself again :-) BTW I don't even know if I'm really right - over to you if you want to submit another official entry. -- === Subject: Re: Old-timers' mini-challenge <10745152ROBOTLX@news.individual.net> X-NNTP-Client: ROBOT/LX Virgil - sorry for misleading - I was wrong below! in message ID <10745152ROBOTLX@news.individual.net> : > I replaced OVER SIZE with DUP and just shifted the IFTE clause > a bit further in. It still seems to provide the required exit > - so it knows when not to call itself again :-) I didn't test the blank list input case. Then I thought I could fix it with an OVER and DROP2 at the end .... no, I6d need two separate DROPs. -- === Subject: Re: Old-timers' mini-challenge > Sorry for the delayed replies. I was suddenly quite sick. Not > life-threatening sick, just the kind of sick where death doesn't > seem like such a terrible alternative. After sleeping for most of > the last 24 hours, I'm trying to absorb a pot of coffee. I > probably should try to eat something, but the idea doesn't appeal > to me just yet. Sorry to hear it. Take care of yourself. Hope you ar better soon. === Subject: Re: MiniChallenge Winners > I can't take credit for the smallest for the 48S . Khanh-Dang beat me > by 1 byte with his recursive program.. No, those programs don't work on the 48S; they require the 48G series' new list-processing commands. -- === Subject: Re: MiniChallenge Winners I stand corrected.. >I can't take credit for the smallest for the 48S . Khanh-Dang beat me >by 1 byte with his recursive program.. > No, those programs don't work on the 48S; they require the 48G > series' new list-processing commands. > -- > === Subject: Re: 49g+ blinking cursor drops keystrokes? X-RFC2646: Format=Flowed; Response > Now the $1 question: why it doesn't happen if the clock is being displayed > in the header. > Earlier in my post i mentioned that the speed change if the calculator > idles for more than 2s ; well if the clock is being displayed: it never > happens. so the CPU speed is *always* 75Mhz, and at 75Mhz the emulation is > always fast enough to catch the key. Well it seems that you are the one wrong here. Because I have always seen people report that the hp49g+ misses a lot MORE keys when the clock display is ON! === Subject: Re: 49g+ blinking cursor drops keystrokes? >This is all good but it's totally either: >1-Inaccurate >2-Plain wrong >There's no such thing as a missing interrupts, collision of interrupt >etc... >I could debate as why it is the case but that would be too long to explain We are always open for a good technical discussion. There are not so many going on in the newsgroup lately. happen instantly, there's a couple of clock cycles going on before it >actually happens. >This mean that at the time the HP49G+ OS (The native ARM OS) sends a key >to the emulator, the CPU is still running at 10Mhz... The emulator >emulates the saturn hardware at 10Mhz.. >So by the time the emulated saturn get to see the key: the user has >released the key, and the ARM OS has sent a message to the emulator: >HOLD A SEC!!! the key has been released. >So by the time the user has pressed the key and released the key, the >emulated HP49 wasn't fast enough to catch it... >And the key is lost. >This has been proven with several user mentioning that when they type: >1 2 3 ENTER >only the 1 is missed. I agree with you, except that when you say that the speed change takes a couple of cycles, they should be a LOT of cycles to make you miss a key. A user can press/release a key in maybe 0.1 seconds or so. Even at 12 MHz that's an eternity... the ARM can do a lot in that time. I always thought that something else (interrupt routine or who knows what) could be wasting additional time, not letting the emulator (or maybe even the ARM OS) catch the key. >Now the $1 question: why it doesn't happen if the clock is being >displayed in the header. >Earlier in my post i mentioned that the speed change if the calculator >idles for more than 2s ; well if the clock is being displayed: it never >happens. so the CPU speed is *always* 75Mhz, and at 75Mhz the emulation >is always fast enough to catch the key. Actually, people reported the opposite. When the clock IS displayed you miss MORE keys. When the clock is NOT displayed it works better. That's why I said in an earlier post that maybe the CONFIGD opcodes were taking enough time outside the emulator to cause the missed key. Your hypothesis could still be close to the answer, though. >So there are two ways HP could fix this issue: >1-Reduce the speed to a higher value so the emulation will always been >fast enough for the emulated code to catch a key. Lots of errors/tries I >reckon here >2-Rewrite the original HP49 keyboard handler in native C/ARM code ; so >even at 10Mhz it's fast enough to detect the key. If the problem is originated only in the clock speed change, then a good solution would be to use an intermediate buffer. Catch all keypresses in ARM and pass the keys slowly to the emulated Saturn. This way you don't need to rewrite any Saturn code or drain more batteries. But I'm sure that if the solution was so trivial it would have been in ROM 1.20. There's something else going on... >Now will HP do it... >Wait and see.. > === Subject: Re: HP49g+ keyboard still crappy X-RFC2646: Format=Flowed; Response > Replace again, please And just how many times should one replace before giving up? So far I have tried 5 different hp49g+ (CN334, CN407, CN334, CN407, CNA436) and all miss keypresses (enough to be unusable to me).