d-17 === Subject: Re: Mig for HP39/40 >> I've tested the 39/40G version and the 38G version. Both seem to work >> with no problems. >> I assume that you created it using JYA's aplet framework and this has >> a bug that means that the normal download using the Disk drive >> (Kermit) option always fails. It always gets to the end of the >> download and then > This has been fixed years ago ... > It isn't a problem in the skeleton itself, only that there should always > be a library within the package that is most of the time missing. > JY Yes but this one does have a library (MIGLIB00.38 or MIGLIB00.39). I can't comment on whether it is or is not written correctly - only that it exhibits the classic behavior of reaching the end of the download, pausing for a moment and then reporting File not found. Could it be that the name it is expecting is not the same as the default library name that comes with the aplet framework? I did notice that Khanh-Dang's library had a different name to the one that accompanies many of the other sRPL aplets. However I'm not an sRPL programmer so I couldn't check the code. >>On the 38G the alternative (Wire) option doesn't exist >> so you have to download the Xmodem aplet first and then use that to >> transfer the library and the aplet. Once I did that it worked correctly >> on the 38G too. > Are you sure the Xmodem aplet is needed? When using an emulator, I > managed to send both the aplet and the library by using a xmodem > transfer software. Not sure what you mean by this. The original 38G only had a Kermit option - the one that it uses when you choose Disk drive from the SEND/RECV menu. If you wanted to use Xmodem you had to download a special aplet. On later models the Wire option was added to the SEND/RECV menu and that option uses the Xmodem protocol. If you're using the emulator that may be different. === Subject: Re: Mig for HP39/40 I just tried again, with the new version of Mig 39 and with a freshly reset 40G. The Disk drive option still gets to 100%, pauses and then fails with File not found. >>> I've tested the 39/40G version and the 38G version. Both seem to >>> work with no problems. >>> I assume that you created it using JYA's aplet framework and this has >>> a bug that means that the normal download using the Disk drive >>> (Kermit) option always fails. It always gets to the end of the >>> download and then >> This has been fixed years ago ... >> It isn't a problem in the skeleton itself, only that there should >> always be a library within the package that is most of the time missing. >> JY > Yes but this one does have a library (MIGLIB00.38 or MIGLIB00.39). I > can't comment on whether it is or is not written correctly - only that > it exhibits the classic behavior of reaching the end of the download, > pausing for a moment and then reporting File not found. Could it be > that the name it is expecting is not the same as the default library > name that comes with the aplet framework? I did notice that Khanh-Dang's > library had a different name to the one that accompanies many of the > other sRPL aplets. However I'm not an sRPL programmer so I couldn't > check the code. >>> On the 38G the alternative (Wire) option doesn't exist so you have >>> to download the Xmodem aplet first and then use that to transfer the >>> library and the aplet. Once I did that it worked correctly on the 38G >>> too. >> Are you sure the Xmodem aplet is needed? When using an emulator, I >> managed to send both the aplet and the library by using a xmodem >> transfer software. > Not sure what you mean by this. The original 38G only had a Kermit > option - the one that it uses when you choose Disk drive from the > SEND/RECV menu. If you wanted to use Xmodem you had to download a > special aplet. On later models the Wire option was added to the > SEND/RECV menu and that option uses the Xmodem protocol. > If you're using the emulator that may be different. === Subject: Re: Mig for HP39/40 > I just tried again, with the new version of Mig 39 and with a freshly > reset 40G. The Disk drive option still gets to 100%, pauses and then > fails with File not found. Then it means that in the aplet structure, there's no reference to the library and it's not named properly either. Default name is Lnumber.xxx nothing to do with the skeleton, just not used properly JY === Subject: Re: Mig for HP39/40 I tried it on a 39g+. Although it loads and seems to run normally there is simply no sound. > I just tried again, with the new version of Mig 39 and with a freshly > reset 40G. The Disk drive option still gets to 100%, pauses and then > fails with File not found. >>>> I've tested the 39/40G version and the 38G version. Both seem to >>>> work with no problems. >>>> >>>> I assume that you created it using JYA's aplet framework and this >>>> has a bug that means that the normal download using the Disk drive >>>> (Kermit) option always fails. It always gets to the end of the >>>> download and then >>> This has been fixed years ago ... >>> It isn't a problem in the skeleton itself, only that there should >>> always be a library within the package that is most of the time missing. >>> JY >> Yes but this one does have a library (MIGLIB00.38 or MIGLIB00.39). I >> can't comment on whether it is or is not written correctly - only that >> it exhibits the classic behavior of reaching the end of the download, >> pausing for a moment and then reporting File not found. Could it be >> that the name it is expecting is not the same as the default library >> name that comes with the aplet framework? I did notice that >> Khanh-Dang's library had a different name to the one that accompanies >> many of the other sRPL aplets. However I'm not an sRPL programmer so I >> couldn't check the code. >>>> On the 38G the alternative (Wire) option doesn't exist so you have >>>> to download the Xmodem aplet first and then use that to transfer the >>>> library and the aplet. Once I did that it worked correctly on the >>>> 38G too. >>> Are you sure the Xmodem aplet is needed? When using an emulator, I >>> managed to send both the aplet and the library by using a xmodem >>> transfer software. >> Not sure what you mean by this. The original 38G only had a Kermit >> option - the one that it uses when you choose Disk drive from the >> SEND/RECV menu. If you wanted to use Xmodem you had to download a >> special aplet. On later models the Wire option was added to the >> SEND/RECV menu and that option uses the Xmodem protocol. >> If you're using the emulator that may be different. === Subject: Re: Mig for HP39/40 > I tried it on a 39g+. Although it loads and seems to run normally there > is simply no sound. that's perfectly normal... the way to do sound is entirely different that the previous series. JY === Subject: adapter for connectivity kit(HP48G) Is there an adapter seriell-usb for the con.kit from the HP48 === Subject: Re: adapter for connectivity kit(HP48G) You can use a generic serial<->usb translator. They aren't just a simple adapter, but contain active electronics, since USB is a smart protocol. There's no advantage in speed, since that is still limited by the serial port of the 48. But you can at least use one to connect to a PC that has no serial interface, but has USB. Howard === Subject: Re: adapter for connectivity kit(HP48G) On Wed, 01 Feb 2006 12:15:21 -0600: [presumably about a computer having USB but no built in wired serial ports] > You can use a generic serial<->usb translator. Do you also need a driver, to create a virtual COM port? I have a USB device (IR at the other end, in this case) which theoretically could communicate using serial IR (the very hardware/software level which HP48 understands), yet it is useless because its driver fails to create a virtual COM port, and none of my Windows software for HP48 will talk to anything but a COM port for communicating with an HP48. Presumably you do get a better driver (or perhaps find one built into Windows) with better USB<->serial adapters. What about any built-in motherboard IR? If it exists and is already capable of acting as virtual COM port, then it might already be able to communicate with HP48, albeit much more slowly than over a wired connection. I seem to recall some software for speeding up HP48 IR, however, so perhaps something can even be done about the speed. [r->] [OFF] === Subject: Re: Is it possible to use the emulator linked to dotnet or excel? Raymond Del Tondo: > PF_Fan schrieb im Newsbeitrag >> Raymond Del Tondo: >>> PF_Fan schrieb im Newsbeitrag >>>> Is it possible to use the emulator linked to dotnet or excel? >>>> >>> If Emu48 (and your version of Excel) still support DDE, >>> you could at least load or save stack items. >>> Just check the Emu48 docs. >> It would be nice if emu48 could publish a DLL (OLE or not) so we can use >> HP49 functionalities in dotnet, excel, etc.. > AFAIK the Emu48 version shipped with Debug4x is a DLL. Does it have any API reference? === Subject: Re: BMP 2 GROB thank you it worked:) escreveu: > May i sugest: > http://fly.cc.fer.hr/~/openfire > in the PC software section you will see image converter > OR (even more flexible) > http://www.xnview.com/ > if you use a windows machine this will be perfect for you -you can convert > GIF, JPG, WMF, BMP in to: > -monochrome or various formats of grayscale for HP48's and 49(+)'s > when you have your image on the stack just edit it -arrow key down or type > PICT STO and then edit with arrow key left or > run some alternative GROB or grayscale viewer. > === Subject: Re: BMP 2 GROB thank you it worked:) escreveu: > May i sugest: > http://fly.cc.fer.hr/~/openfire > in the PC software section you will see image converter > OR (even more flexible) > http://www.xnview.com/ > if you use a windows machine this will be perfect for you -you can convert > GIF, JPG, WMF, BMP in to: > -monochrome or various formats of grayscale for HP48's and 49(+)'s > when you have your image on the stack just edit it -arrow key down or type > PICT STO and then edit with arrow key left or > run some alternative GROB or grayscale viewer. > === Subject: Easydrill Has anyone seen any other program compared to easydrill. for the HPg49+. It is a drilling and surveying program developed by directional drillers. === Subject: Re: Easydrill I use financial software for the purpose, to complement my directional drilling into the bank vault next door :) === Subject: Re: Easydrill >..to complement my directional drilling >into the bank vault next door :) I'll bet he gets a lot of that sort of humor. 6) === Subject: The Next HP Calculator Hello The last calculator HP has released is the HP49G+. It is an emulator, emulating the 49G with a modern, different and far powerful hardware. Assuming today's hardware power level, it seems to me that this emulation method is completely extensible. The 49G+ has power to emulate almost all HP Saturn-based calculators. It would be great to hear HP announcing a calculator with a modern and robust(robust like the 48GX) hardware and ability to emulate all the calculators HP released. An obvious problem that has to be overcomed is the keyboard layout. Designer should find a consensus between models. User once get the calculator, and selects the ROM he/she wishes to use. As an old and ceased HP-enthusiast, I think this would be a great good-bye gift from HP to us. Alper === Subject: Re: The Next HP Calculator You are familiar, I assume, with HrastProgrammer's emulators? (http://hrastprogrammer.tripod.com/). Many of them run on the 49g+, though often with fewer features than on the 48gx. === Subject: Re: The Next HP Calculator > You are familiar, I assume, with HrastProgrammer's > emulators? (http://hrastprogrammer.tripod.com/). Many of them run on > the 49g+, though often with fewer features than on the 48gx. I) The 49g+ is not the calculator mentioned since it lacks robustness, primarily because of poorly built keyboard. II) They have two emulation layers, these emulators are themselves emulated seriously reducing performance for a 48-series calculator. Alper === Subject: Re: The Next HP Calculator Actually, for HP-42X and HP-71X the CPU isn't emulated at all, since both of those machines used a Saturn. For the others, HP-41X, and the Voyagers, the emulated CPU is a Nut processor that ran at 680 MHz in the fastest machine the HP-41. On a 4MHz Saturn, they all run at several times the speed of the originals. Also, the Nut architecture is similar to Saturn, so I imagine the one layer of emulation is relatively straightforward. And on the 49g+, Hrast claims his emulators run even faster, even if he did have difficulties implementing all the features of the originals. So even in the case where it is emulation on top of emulation, the speed is even more times that of the originals. That's not to say that a machine specifically designed to emulate old HP machines wouldn't do better, of course. But I have two points about that. First, Hrast's emulators are here now, and HP is unlikely to release a machine whose sole purpose would be to emulate older ones. And second, general-purpose handheld devices such as the Zaurus can run HP emulation, (Nonpareil, for example,) at many times the original speed. I think there are ports of Emu48 and Emu42 to wince too, if that's what floats your boat. 8) (Granted, the keyboard issue remains.) Howard === Subject: Re: The Next HP Calculator > Voyagers, the emulated CPU is a Nut processor that ran at 680 MHz in > the fastest machine the HP-41. 680Mhz is a *very* fast processor ... will be hard to emulate this one at a reasonable speed ! === Subject: Re: The Next HP Calculator >Actually, for HP-42X and HP-71X the CPU isn't emulated at all, since >both of those machines used a Saturn. I should clarify that the first paragraph above refers to Hrast's emulators running on a 48gx or HP49g, not a 49g+. === Subject: Re: The Next HP Calculator Oh, for a bit of patience before I post! 8) The Keyboard issue that remains is ambigious. There's the problem of the 49g+ keyboard, the saga of which has been thouroughly thrashed hear and elsewhere. On that point, I'll just say that my recent model 49g+ does OK with ROM 2.05 and KEYTIME set to 1200. The other keyboard issue is the one I was referring to, That's the problem of general putpose computing devices not having the specialized keyboard a calculator has. This issue is what makes me rate Hrast's HP-41X emulator as the most successful HP-41 simulation going. Several others do as great a job at simulating the 41 to the point f being able to run HEPAX, for example. But Hrast's offering is implemented on a calculator, with a calculator's keyboard. Even with the lack of a template to help you learn the mappings of the keys, that results in a very comfortable experience operating the program. No PC or handheld keyboard can beat the convenience of lots of specialized keys laid out in a logical order for doing numeric manipulation. I'd argue that the PC starts to win when you want to do mathematical symbols, since you can choose from so many different input methods, but for one or two variable functions, a dedicated key is just better. Howard === Subject: Re: The Next HP Calculator hello, Just one question, why would you like to emulate a 41 on a HP48 series? I mean, as far as I know, there is no function of the emulated HP41 that is not available on the HP48 series, natively, and much faster... I understand if it is just to say: we can do it, but if you prefer to use a HP41 (for familiarity I guess), why not just use a HP41 directly? > Oh, for a bit of patience before I post! 8) > The Keyboard issue that remains is ambigious. There's the problem of > the 49g+ keyboard, the saga of which has been thouroughly thrashed hear > and elsewhere. On that point, I'll just say that my recent model 49g+ > does OK with ROM 2.05 and KEYTIME set to 1200. The other keyboard issue > is the one I was referring to, That's the problem of general putpose > computing devices not having the specialized keyboard a calculator has. > This issue is what makes me rate Hrast's HP-41X emulator as the most > successful HP-41 simulation going. Several others do as great a job at > simulating the 41 to the point f being able to run HEPAX, for example. > But Hrast's offering is implemented on a calculator, with a > calculator's keyboard. Even with the lack of a template to help you > learn the mappings of the keys, that results in a very comfortable > experience operating the program. No PC or handheld keyboard can beat > the convenience of lots of specialized keys laid out in a logical order > for doing numeric manipulation. I'd argue that the PC starts to win > when you want to do mathematical symbols, since you can choose from so > many different input methods, but for one or two variable functions, a > dedicated key is just better. > Howard === Subject: Re: The Next HP Calculator please allow me to cut in here :-) I guess what Alper realized is that 49G+ is manny times as powerfull as any preceding model of HP calculator. -as such it is capable to emulate any older model Belive me when i say 49G+ can emulate 41. on the second emulation layer and still get faster than original speed Like Cyrille i dont see the point in of emulating older model, only if you're NOT familiar with new models. On the other hand if you emulate 41's on 49G+ it is obviews that you're missing few more power-and-new-features-packed generations of calculators. -my message for this people is simple: LEARN (you simply have to, or you will be left behind) It is possible to create different ROM for each of the past models which would all run on the same 49G+ hardware, however, you would be missing the old feel, the blurry+faded+slow LCD :-) and some hardware features of the older models. -like setial port, HP-IR or old 40pin extension port So there is no point in this either :-) > hello, > Just one question, why would you like to emulate a 41 on a HP48 series? > I mean, as far as I know, there is no function of the emulated HP41 that is > not available on the HP48 series, natively, and much faster... > I understand if it is just to say: we can do it, but if you prefer to use a > HP41 (for familiarity I guess), why not just use a HP41 directly? > Oh, for a bit of patience before I post! 8) > The Keyboard issue that remains is ambigious. There's the problem of > the 49g+ keyboard, the saga of which has been thouroughly thrashed hear > and elsewhere. On that point, I'll just say that my recent model 49g+ > does OK with ROM 2.05 and KEYTIME set to 1200. The other keyboard issue > is the one I was referring to, That's the problem of general putpose > computing devices not having the specialized keyboard a calculator has. > This issue is what makes me rate Hrast's HP-41X emulator as the most > successful HP-41 simulation going. Several others do as great a job at > simulating the 41 to the point f being able to run HEPAX, for example. > But Hrast's offering is implemented on a calculator, with a > calculator's keyboard. Even with the lack of a template to help you > learn the mappings of the keys, that results in a very comfortable > experience operating the program. No PC or handheld keyboard can beat > the convenience of lots of specialized keys laid out in a logical order > for doing numeric manipulation. I'd argue that the PC starts to win > when you want to do mathematical symbols, since you can choose from so > many different input methods, but for one or two variable functions, a > dedicated key is just better. > Howard === Subject: Re: The Next HP Calculator A principal reason for emulating an older model is to be able to plug in, without modification, anything from the existing body of software (translating even to unrealized ongoing sales potential) already developed for that model, which often represents a huge investment that hasn't yet fully depreciated, and can still supply substantial value. I believe it's quite the same for the 49G+; after all, why wasn't an all new calculator designed from scratch, based on the new processor? Why only emulate that aging HP48 series, instead of proceeding at least along one of those lines which ACO was developing before it pulled its own plug? (or higher management pulled it) Why is there still an HP12C (did it ever make it into the Guinness Book of Records?) Another old model, still being emulated after two millennia: http://www.guinnessworldrecords.com/content_pages/record.asp?recordid=56104 [r->] [OFF] === Subject: Re: The Next HP Calculator > (Practical reasons for emulating older machines.) Those are good reasons. They mostly don't apply to me, however. I'm a handheld computing device collector and enthusiast. Old hardware and software are fun for me. Emulation strikes me as cool, also. Just for fun, I'd like to get the following emulation chain running sometime: Linux->VMWare->Windows->EMU48->HP71X->HP41 Emulator ROM->Some program. Nothing practical about that! 8) But there's another reason, which I discussed earlier. Those emulators run and several times the speed (680*K*hz. Sorry for slipping three decimals, there 8) of the original machines. Not only can you continue to use software that you may have become used to over a period of many years, but you can run it between three and four times faster. Another reason related to John's first point, but not identical with it, is the fact that you can often run add-ons for the emulated machine that are no longer available or prohibitively expensive. This is true for HP-71X, which emulates an HP-71B, and the Math ROM and FORTH/Assembler ROM among many others. These are rare and quite expensive nowadays. But for the price of an HP-48 (already payed in my case) and HP-71X (100 euro, currently) I can run an emulated 71B with the ROMs that have bits available on the Internet. That happens to be nearly all of them. The same thing holds true for the HP-41C, but since that machine was hugely popular, and stayed on HP's price list for 10 years, there is an enormous library of software and interesting plug in modules. I can play with all of them under HP-41X. So for an enthusiast, the appeal of emulation strikes me as obvious. But there's overlap with the practical reasons John mentioned. Those vast software libraries are available to working engineers, too. Lastly, there's a rather delicate matter. Some of us old farts dislike RPL, and wish HP had continued to develop the old keystroke model of programming at the high end. I've actually come to like User RPL in the course of writing YatZ49, but I still see merit in the older, simpler model of programming. HP-41X let's me use that model, let's call it RPN, on an HP-48 if I want. But what I'd really like is to have RPN in a peer-to-peer relationship with RPL. That is, one style of program could call the other, within the limits of the old RPN style, such as the four level stack. The old style is natural for me when confronted with relatively simple problems. RPL is more expressive, but also more complicated. I'd like to be able to revert to RPN when it struck me as appropriate, or switch to RPL when I needed extra power. Howard === Subject: Re: The Next HP Calculator Here are some claims about that 2000 year old model: Today, you may also see an abacus with the counters strung on wires. They are still used in Japanese schools. Each year in Hong Kong a race is held to work out the same sum on a calculator and on an abacus ? and each year the abacus wins! http://www.guinnessworldrecords.com/content_pages/record.asp?recordid=56104 [r->] [OFF] === Subject: Re: JHM's CHOOSE Replacement > but [HP48GX] ROMPTR B3 64 doesn't even exist [on 49G] On HP48GX, the user CHOOSE command itself first checks arguments and then invokes ROMPTR B3 63 (which is entirely different from the FPTR calls used in the 49G series, so of course you can not make any direct correspondence). As 48GX internal CHOOSE continues, it puts ROMPTR B3 65 on the stack before starting the main engine ROMPTR B3 0 As far as I can see, ROMPTR B3 64 and ROMPTR B3 65 are the same thing, and seem to be what picks the item to display from each list element: :: DUPTYPELIST? IT :: DUPNULLCOMP? ?SEMI ROMPTR B0 98 (48GX only) ; DUPTYPECSTR? ?SEMI FOUR ROMPTR B0 74 (48GX only) ; It's all well and good to say that the GX browser is in the 49G, but that previously cited post documents all about the message handler in the standard CHOOSE type interface, and how to use it to adjust the menu part, for example, but in this case we are interested in seeing about a different, full-screen display, rather than about a different menu, so we haven't yet found out what we need. Maybe more research will uncover it, but I'm late for a date :) [r->] [OFF] === Subject: Re: JHM's CHOOSE Replacement > but [HP48GX] ROMPTR B3 64 doesn't even exist [on 49G] Well, curiously enough, when I replaced that with DO>STR (which isn't correct, but is just for experiment), and assembled on 49G, the result was a working full-screen CHOOSE on 49G -- this sort of looks promising :) [r->] [OFF] === Subject: Re: JHM's CHOOSE Replacement The whole old browser of the 48GX (which is in the ROM of the 49G as pointed out) is documented in gxbrowsr.zip available at hpcalc.org. Information about the new browser can be found here (Using HP49 CHOOSE for more than just selection) and it is also described in Programming in System RPL 2nd Edition. Andreas http://www.software49g.gmxhome.de/ === Subject: Re: JHM's CHOOSE Replacement BTW: There's another description of the full screen browser (originally called BRBrowse) . See SpeedB.txt (the doc for SpeedBrowser) , also on hpcalc.org (http://www.hpcalc.org/details.php?id=1860) Raymond > The whole old browser of the 48GX (which is in the ROM of the 49G as > pointed out) is documented in gxbrowsr.zip available at hpcalc.org. > Information about the new browser can be found here > (Using HP49 CHOOSE for more than just selection) > and it is also described in Programming in System RPL 2nd Edition. > Andreas > http://www.software49g.gmxhome.de/ === Subject: Re: Busted Key? One fix from home. How do you take the top of calculator apart ? What do you attach the bandaid to ? I am new to this site, and new to shoddy workmanship of HP products. My 42s has been problem free in 3 continents and decade and half, but the 49g+ has two wobbly keys, in less than 8 weeks. I bought it to take the Praxis exams. Maybe i should sell all my HP, and go to the TI89. In any event, any help would be appreciated. cheers, jack