Subject: OPEN FIRE update to 1.8 OPEN FIRE is now 1.8 -some (minor) organisational changes to the site OPEN FIRE now introduces : 'KSB' simple command which recalls the state of whole keyboard to the stack (one 64 bit user binary -HXS for sys programmers) sample RPL code posted on the site manjo === Subject: Re: OPEN FIRE update to 1.8 X-RFC2646: Format=Flowed; Original >> WARNING: these commands have no error checking, to keep them as fast and as small as possible, be sure to have expected arguments ready on stack. Basically -apply roules of sysRPL HP-159 Please NO !!! do a argument checking !!! And maybe opn your web site on the What's new or keep OpenFire as the 1st TabPage. Lilian. clu619$ldr$1@ls219.htnet.hr... > OPEN FIRE is now 1.8 > -some (minor) organisational changes to the site > OPEN FIRE now introduces : > 'KSB' > simple command which recalls the state of whole keyboard to the stack > (one 64 bit user binary -HXS for sys programmers) > sample RPL code posted on the site > manjo --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). === Subject: Re: OPEN FIRE update to 1.8 How about two versions: one with error checking and one without. When writing the program you can use the one with error checking, but when you're sure everything is ok, replace with the version without error checking? Would this work? This way the final product would still have the smaller size and faster speed. > >> > WARNING: > these commands have no error checking, to keep them > as fast and as small as possible, be sure to have > expected arguments ready on stack. > Basically -apply roules of sysRPL > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > Please NO !!! do a argument checking !!! > And maybe opn your web site on the What's new or keep OpenFire as the > 1st TabPage. > Lilian. > clu619$ldr$1@ls219.htnet.hr... > > OPEN FIRE is now 1.8 > > -some (minor) organisational changes to the site > > OPEN FIRE now introduces : > > 'KSB' > > simple command which recalls the state of whole keyboard to the stack > > (one 64 bit user binary -HXS for sys programmers) > > sample RPL code posted on the site > > manjo > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). === Subject: Re: OPEN FIRE update to 1.8 X-RFC2646: Format=Flowed; Original The problem of error checking is not only for debugging but also for the basic user who will launch the different LIB commands via the menu. The 2 BAD reasons: the smaller size -> just add a few sys-RPL command = 10 octets faster speed -> you DON'T need faster speed for the INIT command. They are called only 1 time at the start. Then, Manjo, please add argument checking !!! Lilian. > How about two versions: one with error checking and one without. When > writing the program you can use the one with error checking, but when > you're sure everything is ok, replace with the version without error > checking? Would this work? This way the final product would still have > the smaller size and faster speed. >> >> >> WARNING: >> these commands have no error checking, to keep them >> as fast and as small as possible, be sure to have >> expected arguments ready on stack. >> Basically -apply roules of sysRPL >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> Please NO !!! do a argument checking !!! >> And maybe opn your web site on the What's new or keep OpenFire as the >> 1st TabPage. >> Lilian. >> manjo a .8ecrit dans le message de >> clu619$ldr$1@ls219.htnet.hr... >> > OPEN FIRE is now 1.8 >> > >> > -some (minor) organisational changes to the site >> > >> > OPEN FIRE now introduces : >> > >> > 'KSB' >> > simple command which recalls the state of whole keyboard to the stack >> > (one 64 bit user binary -HXS for sys programmers) >> > >> > sample RPL code posted on the site >> > >> > manjo >> > >> > >> --- >> Outgoing mail is certified Virus Free. >> Checked by AVG anti-virus system (http://www.grisoft.com). --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). === Subject: Re: OPEN FIRE update to 1.8 have you checked the site recently ? i added argument checking for INITPF and OFVIEW autorepeats (using KSB) i could do more advanced argument checking (by type) but then if arguments are of proper type bad values would also crash the calc. they i would need to check values too ? this could lead me in to the check-doublecheck-dead-end very fast, this is just basic check so basic users wouln't crash their calc. i think it's a fair reminder (for adavanced and basic users) to apply the roules of sysRPL, (since they will use these in sysRPL mostly) manjo === Subject: Re: OPEN FIRE update to 1.8 X-RFC2646: Format=Flowed; Original clvpka$d2o$1@ls219.htnet.hr... > have you checked the site recently ? Yes but I have no HP49G+ yet... I only read the TXT file in the OpenFire Zip package :)) > i added argument checking for > INITPF and OFVIEW >... > i think it's a fair reminder (for adavanced and basic users) to apply the > roules of sysRPL, > (since they will use these in sysRPL mostly) The problem is only for a basic user: he press LIB, OpenFire and then just press the menu Keys (F1, F2, ...) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). === Subject: Re: OPEN FIRE update to 1.8 X-RFC2646: Format=Flowed; Response I agee with the discipline of complete error checking. It's all-to-easy, even for an experience HP user / programmer, to hit the wrong key by accident. And nothing ruins a day quite like a memory loss... By the way, I think that your efforts are fantasitc. I'm certain that it encourages HP engineers and designers to see someone like you working so hard on their product. Chris > manjo a .8ecrit dans le message de >> have you checked the site recently ? > Yes but I have no HP49G+ yet... I only read the TXT file in the OpenFire > Zip package :)) >> i added argument checking for >> INITPF and OFVIEW >>... >> i think it's a fair reminder (for adavanced and basic users) to apply the >> roules of sysRPL, >> (since they will use these in sysRPL mostly) > The problem is only for a basic user: he press LIB, OpenFire and then just > press the menu Keys (F1, F2, ...) > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). === Subject: Re: OPEN FIRE update to 1.8 that's nice of you to say :-) i hope it is true :-) and I hope to see more efforts like this, not only for G+ sake but for sake of learning and understanding the world of Satrun and ARM both. manjo === Subject: Re: OPEN FIRE update to 1.8 > I agee with the discipline of complete error checking. It's all-to-easy, > even for an experience HP user / programmer, to hit the wrong key by > accident. For library commands easily accessed by an ordinary user, definitely. But I don't think that it's needed, or even appropriate, for unnamed library commands, or perhaps even for commands within an unnamed library, intended for use only within SysRPL programs. Note that SysRPL and assembly language commands don't do error checking. > And nothing ruins a day quite like a memory loss... With the 49 series, restoring memory is quick and easy, and if you do SysRPL or assembly language programming, you'll no doubt get some practice at it. -- James === Subject: Re: OPEN FIRE update to 1.8 Public available library commands should have argument checking made so that fair ammount of effort is needed to crash your calc :-) OPEN FIRE 1.8 has basic argument checking so that it doesn't crash your calc if you try to run any of the commands without arguments (if some needed) For my own use i made a small program 'CONFIGURE' which i'm keeping on my SD card, when my memory is whiped out (very rare -but was quite frequent in the early days) I just start this neat thing, it does the following : -restores all flag settings to my preference, -copies my directories and SARTUP file (command) -installs my favorite fonts from SD card -ORDERs (sorts) my HOME directory the way i like it :-) you may consider this as a RESTORE point in XP Windows, i understand Filer6 and similar filing utilities have also nice capabilities like these. which help you restore your calc to normal back in no-time :-) manjo === Subject: Re: OPEN FIRE update to 1.8 > Note that SysRPL and assembly language commands don't do error > checking. Make that argument checking. -- James === Subject: OPEN FIRE update to 1.8 have you checked the site recently ? stay tuned manjo === Subject: Trouble running Emu48 for Pocket PC 2002 I have downloaded the latest Emu48 for Pocket PC 2002 from Christoph Giesselink along with the modified kml and associated bmp files. I duly removed all instances of the older program (which worked fine) and installed it all on my HP iPAQ hx4700. When I run the emulator, I can choose the kml file and the compiler shows that all files are loaded properly. The ROM is loaded, the bitmap is loaded, the buttons, scancodes and annunciators are all defined, but when I click Ok to begin using it, it dies and closes immediately. I have carefully tried reinstalling and running this several times with no joy. Any ideas or suggestions? Simon === Subject: Re: HP-GCC vs TIGCC posting-account=Dzyc9wwAAABCml63_5kidLcMpxekXI5I > The only game I have on my V200 is TI-Chess. It has a very good engine. > http://tict.ticalc.org/projects.html#ref_latest It has been ported to another platform already: http://www.pocketviewer.de/download/nprogram.php?Nr=686&lang=1 -Samuel http://www.stearley.org === Subject: Re: HP-GCC vs TIGCC > We have also a chess game on HP calculators: > http://www.hpcalc.org/details.php?id=795 > But only on HP48 :(( One of the HP-GCC example programs is a Chess game, by Chris Smith. It's included with the download. cheers, Al === Subject: Re: HP-GCC vs TIGCC > One of the HP-GCC example programs is a Chess game, by Chris Smith. It's > included with the download. Please know that lchess, this example, is a proof-of-concept example. It probably can't compete with full-blown chess applications. There is, for example, no opening book and little of the kind of fidgeting that makes minimax search more effective for chess. -- www.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation === Subject: Re: HP-GCC vs TIGCC > Question about HP-GCC, > I have read in the docs that you must : > -engage slow mode and You don't _have_ to use slow mode. However HPG is setup to assume slow mode, and it will have an incorrect refresh rate at 75MHz. This is fairly trivial to fix though, so maybe in a future release... Besides that, if your game can run in slow mode, please use it. It means anyone playing your game will have a longer battery life. > -disable interrupts in order to > use graphics properly in HPGCC > I see disabled interrupts as a major drawback (if that's needed) > Hello World does that right ? Yes. Currently, there is a background process that keeps copying the emulated saturn screen over the real screen. If you don't disable interrupts, anything you write to the screen will be very quickly overidden. If you want to hook your own interrupts, this isn't a problem - just ovveride 0x8000018 / 0x800001c (which are the new vectors for interrupts / fast interrupts respectivly) to point to your code, and setup the registers correctly. Remember to restore the OS defaults when you are done. cheers, Al > manjo === Subject: Re: HP-GCC vs TIGCC > If you want to hook your own interrupts, this isn't a problem - just > ovveride 0x8000018 / 0x800001c (which are the new vectors for interrupts > / fast interrupts respectivly) to point to your code, and setup the > registers correctly. Remember to restore the OS defaults when you are done. while you mentioned restoring the original value i have a sugestion regarding HP-GCC intOff() / intOn() implementation, -by using fixed value when resuming interrupts you may be compliant with current version of ROM, however that could change in the future. Or my programs may alter the interupt mask to my needs, current intOn would not restore my prefered masking -it would override my settings. Basicaly what i'm sugesting is: ------------------------------ intOff() should save the curent interrupt mask, before turning off interrupts intOn() should restore the saved mask rather than loading fixed value to implement this you would need to implement (if not already) global structure -set of constants and variables used to monitor and control the system. -this way it would work regardless of ROM or altered interrupt setting -it would even work on entirely different platform as well :-) manjo === Subject: Re: HP-GCC vs TIGCC > while you mentioned restoring the original value > i have a sugestion regarding HP-GCC intOff() / intOn() implementation, > -by using fixed value when resuming interrupts you may be compliant with > current version of ROM, > however that could change in the future. Or my programs may alter the > interupt mask to my needs, > current intOn would not restore my prefered masking -it would override my > settings. Yep, that should to be changed, just like HPG... cheers, Al === Subject: Re: HP-GCC vs TIGCC > > Hi all, > > > > for the HP-GCC guys: is it possible to compile TIGCC programs to run on > > HP-GCC ?? > > > > Especially 3D games :)) Mmmmm... cross compiling will be very difficult. engine for hpgcc? I don't think it will take so long (I'll do it myself if nobody does!). Porting can be complicated and you know this very well... you are still trying to port your old 49G games to the G+. And we are talking about almost identical machines! I was half-way through a 3D engine in Saturn assembler when this ARM processor became accessible. Then I obviously abandoned the project. In emulated Saturn it rotated a cube at 16 frames per second. This includes object rotation and translation (fixed objects like walls would save you this entire step), camera rotation and translation, and backface culling. All this without using the new division and multiplication opcodes in the Saturn (I was using manual software multiplications with table lookup trigs). With an ARM at 75 MHz we should be able to do raycasting as in Doom with no problems but be patient. It all takes time... and unfortunately we don't have much. Claudio === Subject: Re: HP-GCC vs TIGCC > With an ARM at 75 MHz we should be able to do raycasting as in Doom > with no problems but be patient. It all takes time... and > unfortunately we don't have much. > Claudio I've actually started some raycasting test, some shading but no textures yet, and no movement only rotations. I'll have to stop dev for while since I have exams now. If theres interest, I can post my code. -- Wing Wong. Webpage: http://wing.ucc.asn.au === Subject: Re: HP-GCC vs TIGCC Hello Claudio, what i would love to see is renderer to be in ARM, -controlled from saturn domain, and a standardized structure(or language) for describing the 3D realms from saturn. a variation of VRML or VRML itself would be nice, now as we have C there is realy no limits, (within available memory of course) manjo === Subject: Re: HP-GCC vs TIGCC > > Hi all, > > > > for the HP-GCC guys: is it possible to compile TIGCC programs to run on > > HP-GCC ?? No exactly the same code, since at this moment the keywords are diferent from one and other. but this can be done with a little more of work. :) > > > > Especially 3D games :)) yea maybe, who know? > Hello world maybe? Perhaps in the future, but not right now. Please > remember that TIGCC is about 5 years old - HPGCC is about 3 months old. > So naturally HPGCC only has a tiny fraction of the features of TIGCC. well no really 3 months, since only few day is the firs beta for we the people, maybe 3 months only for the God's > Even if the compiler was ready, alot of TI programs rely on very > hardware specific hacks (sometimes inline asm). Unless you know alot > about both TI and HP hardware it'd be difficult to port. I've already > asked about this on the TI message board. > My personal theory is that as soon as HPGCC is ready for great games, HP > will come out with a newer/better calculator thats totally incompatible :-) yes just like happen with me TI-89 :( > cheers, > Al === Subject: Re: HP-GCC vs TIGCC > We have also a chess game on HP calculators: > http://www.hpcalc.org/details.php?id=795 > But only on HP48 :(( there's a chess game for the 49/49+ its called mlchess and runs quite well on the 49+, but awfully slow on the 49 http://www.hpcalc.org/details.php?id=3067 === Subject: USB News! Hi again, I at last have week of vacation. So I'm ready to work. I have a really good news for you: *The pins for the host and the device ARE the same* Here's what I have: In the samsung sheet: USB Host DN[1:0] IO DATA(ö) from USB host DP[1:0] IO DATA(+) from USB host USB Device PDN0 IO DATA(ö) for USB peripheral PDP0 IO DATA(+) for USB peripheral And a bit earlier: M10 DP1/PDP0 N11 DN1/PDN0 P13 DP0 T12 DN0 So, we are wired to PDP0 and PDN0. But there are TWO pairs of wires for host mode (later on in the sheet Two down stream ports), and one of them is DP1, DN1. Boy, am I happy!!! I read the OHCI specs and part of the USB 1.1 specs. I really REALLY liked the architecture. I think the problem is that not a lot of people now this architecture and that's why they still prefer the old rs232 thing (like sir James M Prange). Just think about it, flash MCU's with usb (PIC18F2455...) cost 4-7$ each. You can easily make a full chain of sensors (127 max) and plug them all in the calc. They would all be independent, hot swappable... All the data would be in nicely formatted files in a huge SD card. Plug it in directly in the computer to analyse. Old rs232 is definitively much easier, but it would be a pain to implement a tiny part of what usb can do. So here's what I'm gonna do, I find myself a cheap and simple usb mouse and try write a driver for it. Of course to do so, I must know all the usb architecture as the palm of my hand, I must also learn to write C progs for the calc, and to understand the one page explanation the samsung datasheet gives about usb host implementation (Refer to Open Host Controller Interface Rev 1.0 specification for detail information. jeje). I really hope I could come up with my mouse cursor in my calc moving on the screen in this week. I don't promise you anything, but trust me... See ya all, great wonderful work, hpgcc group, manjo and all the others. Dimitri === Subject: Re: USB News! > Hi again, > I at last have week of vacation. So I'm ready to work. > I have a really good news for you: > *The pins for the host and the device ARE the same* ??? As far as I know, there's no USB host on the Samsung ARM9 used in the HP49G+, so good luck to write a driver for a USB mouse :) Jean-Yves === Subject: Re: USB News! Hello Jean-Yves > ??? > As far as I know, there's no USB host on the Samsung ARM9 used in the > HP49G+, > so good luck to write a driver for a USB mouse :) Please take another look at the Samsung datasheet :-) http://www.samsung.com/Products/Semiconductor/SystemLSI/MobileSolutions/Mobi leASSP/MobileComputing/S3C2410X/S3C2410X.htm ...IC-BUS interface, IIS-BUS interface, *****USB Host*****, USB Device, SD Host & Multi-Media Card Interface, cheers, Al > Jean-Yves === Subject: Re: USB News! > Please take another look at the Samsung datasheet :-) Sometime soon even JYA will wonder what G+ baby can do :-) right, Al :-) manjo === Subject: Re: USB News! > I read the OHCI specs and part of the USB 1.1 specs. I really REALLY > liked the architecture. > I think the problem is that not a lot of people now this architecture > and that's why they still prefer the old rs232 thing (like sir James M > Prange). Just think about it, flash MCU's with usb (PIC18F2455...) cost > 4-7$ each. You can easily make a full chain of sensors (127 max) and > plug them all in the calc. They would all be independent, hot > swappable... All the data would be in nicely formatted files in a huge > SD card. Plug it in directly in the computer to analyse. > Old rs232 is definitively much easier, but it would be a pain to > implement a tiny part of what usb can do. Just to clarify a few things: First off, I'm not subject to the British crown, and, unless the queen happens to be a fellow RPL aficionado lurking or using a pseudonym on this newsgroup, I think it rather unlikely that she's even aware of my existence, so I'm not sir James. To be sure, there's a lot that I don't know about USB, but that's not the reason for not being more appreciative of the USB *as built-in* on the 49g+, as a USB *device* only. Actually, I think that USB is indeed good for what it was designed for, that is, connecting multiple peripherals (USB devices) to a single host, typically a computer of some kind: PC, Mac, desktop, laptop, maybe even a hand-held. The device drivers (should) know all about the device being connected, so if a user can manage to install the driver, and it works correctly, then the user needn't concern himself with things like connection speed, data bits and stop bits, which control codes and escape sequences the device uses, and so on; just plug the device in and use it. Of course, the operating system may include some common device drivers, which makes things even easier for the user. But there seem to be some device drivers that don't work correctly, and unless the user is skilled at fixing device drivers, he's out of luck in that case. But as far as that goes, device drivers and applications are available for some RS-232 devices too, and could be relatively *easily* written for other devices, so the end user doesn't necessarily have to know much about how they work either. Is the calculator a computer peripheral? Certainly it can be, although I tend to think of my PC as a peripheral for my calculators instead, but in any case, I want to be able to transfer files between the calculators and my PC, so some sort of connectivity is desired. So what's wrong with using the RS-232 compatible port for connecting to a computer? In previous calculators, it was relatively low-speed, but it could be much faster in the 49g+. The big problem is the lack of RS-232 ports on newer computers, especially laptops, and even if the computer has RS-232 ports, there's a good chance that they're already in use, so something else may have to be temporarily disconnected when connecting a calculator. Newer computers come with USB built-in, and with USB, it's pretty easy and low-cost to add a hub if you run low on unused USB ports, so the USB device capability is an advantage. Of course, it's easy enough to add a USB/RS-232 converter to a host, but that's extra expense and trouble. Well, of course RS-232 is relatively old, and there seems to be a perception by some people that anything old must be obsolete. Adding USB device capability was fine, but why take away RS-232 compatibility? What if someone wants to connect the calculator to something other than a USB host? If you have an SD card and a reader for it, that works just fine for transferring files to and from a PC very quickly, but if that were the only way to transfer files, then it mean extra requirements, and even at that, it doesn't make the Xmodem and Kermit servers available. Conn4x makes some very nice use of the Xmodem server, and even MS-DOS Kermit can make use of the Kermit server. I suppose that the SD card could just as well be used to transfer files between the 49g+ and various other devices too, as long as the other device can use the FAT16 file system and the files are small enough for the calculator to fit into memory. If your computer is IrDA equipped, that's another option, although apparently not as fast as USB. An IrDA/RS-232 converter for connection to a PC is fairly low-cost, and I suppose that adding an IrDA card wouldn't be too expensive. The 49g+'s IrDA works okay with Xmodem and Kermit, including the Kermit-based HPComm application and HyperTerminal PE, although not Conn4x. IrDA from the 49g+ is probably reasonably good for peripherals equipped for it, but adding IrDA to a device can be a fairly expensive exercise. But IrDA has the advantage that one IrDA/RS-232 converter, although fairly expensive, would suffice. The 49g+'s IrDA works okay with Xmodem and Kermit, including the Kermit-based HPComm application and HyperTerminal PE, although not Conn4x. The SRECV command on the 49g+ is bugged, at least with IrDA. Sending more than 255 bytes at a time to the 49g+ may well cause a receive buffer overflow. You may well get some more bytes through, but I very much doubt that you'd get 1000 bytes in one chunk through. Of course, with XON/XOFF flow control broken on the 49G, its SRECV command has a very similar bug. But the SRECV problem (with IrDA, at least) on the 49g+ can be source code), I'm reasonably sure that I can get it to do everything that SRECV can, but without the receive buffer overruns. But I'm far from finished getting everything that I want added in to my code. I'm hopeful that the same code would work on the 49G. What about USB? Does the SRECV command work with USB at all? If so, does USB use the same UART addresses in the emulated Saturn system as IrDA does? Anyway, I think that it's a good thing that the 49g+ has a USB device capability. Actually, I think that it would've been good to add USB and IrDA when they developed the 49G, but I realize that there was a need for ACO to get the product on the market quickly. But as a USB device, the 49g+ can't connect to anything except a USB host. The RS-232 compatible port on the 48 series, and to some extent on the 49G, can be used for connecting to many other devices, which is why I wish that it had been retained, along with adding USB device capability. Even if the 49g+ had USB host capability, note that many current devices are already RS-232 compatible, but not USB devices. It seems to me that making them USB devices (adding the hardware and writing the drivers) would be an awful lot of trouble and expense; I expect even more so than adding an IrDA/RS-232 converter. But a USB host/RS-232 converter may be a reasonable work-around. Of course, the serial ports on the 48 series and 49G aren't in compliance with RS-232, but they work well enough for me. RS-232 may be relatively old, but it still works fine for what it's designed for. But if you've found a reasonably low-cost way to convert an RS-232 port to a USB *device* port, then I'd very much like to read about it. Would it be great to have USB host capability in the 49g+? Of course! But there are problems with adding that to the 49g+, and I can well understand why HP didn't do so. First off, to be in compliance with the USB specifications, 500mA at 5V (2.5W) additional power would be required, which doesn't seem feasible from 3 AAA cells. You may be able to get the USB host working without supplying power, if the connected USB devices (or a hub) are self-powered; I don't know. That wouldn't be in compliance, but it may work. Of course, device drivers would also be needed. I suppose that some device drivers in ARM code may be available, and others could be written, if anyone cares to go to the trouble. I understand used for at least some USB device drivers. extra for the underlying ARM operating system. Does anyone actually use port 1 on the 49g+? Does it have advantages over using port 2? hack? Maybe also look into the USB On-The-Go specifications. It seems to me that that might be ideal for a calculator like the 49g+ (or whatever comes out of Project Qonos). Maybe HP's next top of the line model will include it? Conceivably, maybe a USB/RS-232 converter could connect to a USB host port on the 49g+, though it would have to be either self-powered or connected through a self-powered USB hub. So I do hope that you can get the USB host capability working. But what would really make me happy would be RS-232 compatibility on the 49g+, without an additional requirement of going through USB to get it. Good luck with your project! -- James === Subject: Re: USB News! Hello James, Turbiner.... (and other USB, RS232 users) AGREED to you'r writing (James), i have something to add though IF hp wired host and device pins up to the the mini-USB hole :-) THEN -with some work <- this will proove to be a lot simpler than we may be thinking at this moment -once we make a core of USB driver we will be able with much less work to customize for specific devices -using HPGCC we can make a driver for USB->RS232 adapter, which will not take any Saturn memory at all. -USB dongle with a plug-hole for 5V DC power supply (one of these nice small adapters like -cellphone charger would do *OR* if you'd like to stay completely off-main power rechargable battery in the USB->RS232 adapter itself would do the trick -USB device like that would drain much less power than te one *if you belive it should* powered by calculator's battery) We would get RS232 (and some benefits) BENEFITS OVER HP48 type of RS232: -FULL RS232 compliance -in both connector type and signal levels (which is very important for devices which steal power from RS232) OTHER BENEFITS: -part of the hardware (USB dongle -consisting of mini USB male to type A USB feamale with power plug) will be used to connect other type of devices which demand power supply. If power supply is not needed or present in the device -we just unplug the power and we get simple adapter also working just fine :-) Consider this : currently there are much more users who will never connect their HP to anything, some of those not even to a PC those who used to connect their devices mostly did if for transfering files. agreed, THERE ARE (much less in count -that's why i approve not making another hole in the case.) users who did and would love to continue to connect their HP to various stuff. (car diagnostics equipment, some other measuring or data-aquisition equipment, handy-dandy :-) oscilloscope and so on) For compatibility maybe HP could have implement some sort of non-standars null-modem type of RS232 connector like it was on the 48 somwhere under some kind of rubber cork r cover of some sort -while at covers i would appreciate a nice rubber cork for my USB port. Another solution : contacts which would be accessible inside battery compartment, auxilary battery compartment cover with standard 48 connector on it which would use (contact to) internal contacts in battery compartment. The people who would like to use RS232 would have to buy accessory cover, or remove the battery cover and plug the cable to the contacts available underneath. I see endless possibilities here, most of them still open : open for 3rd party development of software, drivers and hardware accessories. G+ contains much goodies currently unused, which may (i hope) be used later FLASHBACK: when i got my SX (that was years after its release) various accessories were available from both HP and other developer/companies ranging from memory cards, printers, ADC/DACs and so on. i imagine it will be the same with G+ in maybe a year or so G+ is still very young and (obviewsly) has some child-sicknesses to get over. I FIGURE: if we wait to see what will happen, while they are waiting to see what we'll do, we ALL end up waiting, BUT if we make something with it, they will see we use it and need it, they will learn how to improove their product and adjust to users needs, and the wheel will start turning. i dont consider this to be naive thinking, rather ACTIVE PARTICIPATION thinking if you don't mind me saying so myself. 48GII and 49G+ are actualy market probes, let me explain : if you study the differences between these two models you could conclude that they are looking what will users go for : is it gonna be bigger screen, or lower cost, is it gonan be USB connectivity or RS232 etc... and as it show's price is not the issue as long as device is under 180$ (halved price of cheap-crap-type PDA) further... i see 48GII canceled over time, but may implement some features from it -like RS232 anyway i realy don't see any other reason (except for RS232) for GII to continue since G+ is afordable and far more powerfull than GII. finaly.... even if they decide to discontinue all models i don't care because i will continue to develop it further for my own needs as i did until now. G+ introduced me with ARM processors and programming the easiest way ever, which makes me feel comfortable when holding any embeded-ARM-processor based device in my hand (read almost everything). manjo :-) understanding ARM is... undertsanding the modern world. === Subject: Re: USB News! X-RFC2646: Format=Flowed; Original > ... > IF hp wired host and device pins up to the the mini-USB hole :-) It isn't that HP wired the host and device pins together... The pins for USB device port 0 are *the exact same pins* as the pins for USB host port 1. Pin M10 is positive I/O terminal for USB device, and at the same time, positive I/O terminal for USB host 1. Pin N11 is negative I/O terminal for USB device, and at the same time, negative I/O terminal for USB host 1. There is a control registrer that controls the functionality of the pins associated with the USB. MISCCR bit 3 is written 0 to configure the chip as a USB device, and written 1 to configure the chip as a USB host. As for the voltage supply, I see nothing wrong with using a hand-crafted USB wire that taps its 5v supply rail from a regulated battery supply. Or perhaps leaving it unconnected, and only using self-powered hubs or devices. If we're paranoid aboput the possible side-effects of attaching the battery, we could protect the calculator's 4.5v circuitry by cutting the 5v line off from the 'upstream' side of the wire, and connecting the battery to the 'downstream' side. However, plugging the calculator into a PC, which is already applying 5v to the line, does not seem to harm the calculator when configured as a device, so I would tend to conclude that there is no harm in allowing the external battery's 5v from reaching the calculator in any event. As for RS232 support: there are 3 UARTs on the chip, of which 1 is used for the IrDA. The 48gii must use another of them for its RS232-compatible (but non-compliant) port. I haven't seen the insides of the 48gii -- does it use the same PCB as the 49g+? (Not too far-fetched... remember the 48g used the same board as the 48gx.) If it does, then it should be possible to hack your own serial port for any devices you may see fit to use, using the 48gii board as a guide. If you need a level shifter to talk with some devices then so be it... if you know what one is, then you won't have any trouble building/acquiring one. Lots of possibilities here, we just have to put them to use! Luke === Subject: Re: USB News! posting-account=mk6bJw0AAAAP43YQhhaqHfe1ZjkzAkHf If we're paranoid aboput the possible side-effects of attaching the battery, we could protect the calculator's 4.5v circuitry by cutting the 5v line off from the 'upstream' side of the wire, and connecting the battery to the 'downstream' side. However, plugging the calculator into a PC, which is already applying 5v to the line, does not seem to harm the calculator when configured as a device, so I would tend to conclude that there is no harm in allowing the external battery's 5v from reaching the calculator in any event. Hey Luke, I don't even think that the 5v line is wired into the calc. I say so because when I had low batt, and tried to connect to the pc it kept on telling me low batt. MISCCR bit 3 is written 0 to configure the chip as a USB device, and written 1 to configure the chip as a USB host. Thaks for that info See you all, Dimitri === Subject: Re: USB News! X-RFC2646: Format=Flowed; Original > I think the problem is that not a lot of people now this architecture > and that's why they still prefer the old rs232 thing (like sir James M > Prange). It's true that not a lot of people know the USB architecture, but a large part of this is due to the fact that it is a LOT more complicated that RS-232 and RS-232 suffices for many applications. > Just think about it, flash MCU's with usb (PIC18F2455...) cost > 4-7$ each. You can easily make a full chain of sensors (127 max) and > plug them all in the calc. They would all be independent, hot > swappable... All the data would be in nicely formatted files in a huge > SD card. Plug it in directly in the computer to analyse. > Old rs232 is definitively much easier, but it would be a pain to > implement a tiny part of what usb can do. Ha ha... what do you think USB gives you 'for free?' Not much! By the time you get done writing software to handle the basic USB transfers, you could have written RS-232 routines that contained comparable functionality instad. I very much like USB, but keep in mind that what USB _really_ gives you is a _standard_ that devices adhere to so that at a high level devices can be classified by class and the _operating system vendor_ can provide a drive that provides basic functionality for _all_ devices of that class. This amount of interoperability is a huge benefit to those making USB peripherals. (Remember serial mice? Even with something as simple as a mouse there were about a half-dozen reasonably common, different standards for the protocol.) > So here's what I'm gonna do, I find myself a cheap and simple usb mouse > and try write a driver for it. A mouse is a human interface device (HID) class piece of hardware, so once you get the mouse working you'll be able to almost immediately get keyboards, joysticks, and various 'miscellaneous' devices going too. By the way, a large amount of code in a USB protocol stack consists of enumerating devices and, in particular, HUB DRIVERS. You can cheat a little and say you're simply not going to support hubs -- this makes life a LOT easier, although you lose the ability to talk to devices with embedded hubs. This includes a small number of keyboards, mice, and even at least one brand (Sony) of memory stick. >Of course to do so, I must know all the > usb architecture as the palm of my hand, I must also learn to write C > progs for the calc, and to understand the one page explanation the > samsung datasheet gives about usb host implementation (Refer to Open > Host Controller Interface Rev 1.0 specification for detail > information. jeje). > I really hope I could come up with my mouse cursor in my calc moving on > the screen in this week. I don't want to rain on your prade here, but a week won't begin to give you enough time. Not a chance. Sorry. You're off by at least an order of magnitude on your time estimate. Still, it's a noble goal, and it'll be great if you can pull it off. I'd suggest starting by downloading a copy of the USB spec from www.usb.org and picking up a copy of Jan Axelson's book, USB Complete.' ---Joel Kolstad === Subject: Re: USB News! posting-account=mk6bJw0AAAAP43YQhhaqHfe1ZjkzAkHf > Hi again, > I at last have week of vacation. So I'm ready to work. > I have a really good news for you: > *The pins for the host and the device ARE the same* > Here's what I have: In the samsung sheet: > USB Host > DN[1:0] IO DATA(ö) from USB host > DP[1:0] IO DATA(+) from USB host > USB Device > PDN0 IO DATA(ö) for USB peripheral > PDP0 IO DATA(+) for USB peripheral > And a bit earlier: > M10 DP1/PDP0 > N11 DN1/PDN0 > P13 DP0 > T12 DN0 > So, we are wired to PDP0 and PDN0. But there are TWO pairs of wires for > host mode (later on in the sheet Two down stream ports), and one of > them is DP1, DN1. > Boy, am I happy!!! > I read the OHCI specs and part of the USB 1.1 specs. I really REALLY > liked the architecture. > I think the problem is that not a lot of people now this architecture > and that's why they still prefer the old rs232 thing (like sir James M > Prange). Just think about it, flash MCU's with usb (PIC18F2455...) cost > 4-7$ each. You can easily make a full chain of sensors (127 max) and > plug them all in the calc. They would all be independent, hot > swappable... All the data would be in nicely formatted files in a huge > SD card. Plug it in directly in the computer to analyse. > Old rs232 is definitively much easier, but it would be a pain to > implement a tiny part of what usb can do. > So here's what I'm gonna do, I find myself a cheap and simple usb mouse > and try write a driver for it. Of course to do so, I must know all the > usb architecture as the palm of my hand, I must also learn to write C > progs for the calc, and to understand the one page explanation the > samsung datasheet gives about usb host implementation (Refer to Open > Host Controller Interface Rev 1.0 specification for detail > information. jeje). > I really hope I could come up with my mouse cursor in my calc moving on > the screen in this week. > I don't promise you anything, but trust me... > See ya all, great wonderful work, hpgcc group, manjo and all the others. > Dimitri === Subject: Re: USB News! Great news Turbiner, of course everything will be confirmed the minute your mouse starts working :-) -i would be interested in a very small usb mouse -available as laptop accessories -writing a driver for it shouldn't be too much of a problem, it is even posible to make it work in the Graphing mode. (as it is now) manjo === Subject: Re: USB News! posting-account=mk6bJw0AAAAP43YQhhaqHfe1ZjkzAkHf Wanted to add, I'll first write a HID driver, which is universal and not to complicated. > Hi again, > I at last have week of vacation. So I'm ready to work. > I have a really good news for you: > *The pins for the host and the device ARE the same* > Here's what I have: In the samsung sheet: > USB Host > DN[1:0] IO DATA(ö) from USB host > DP[1:0] IO DATA(+) from USB host > USB Device > PDN0 IO DATA(ö) for USB peripheral > PDP0 IO DATA(+) for USB peripheral > And a bit earlier: > M10 DP1/PDP0 > N11 DN1/PDN0 > P13 DP0 > T12 DN0 > So, we are wired to PDP0 and PDN0. But there are TWO pairs of wires for > host mode (later on in the sheet Two down stream ports), and one of > them is DP1, DN1. > Boy, am I happy!!! > I read the OHCI specs and part of the USB 1.1 specs. I really REALLY > liked the architecture. > I think the problem is that not a lot of people now this architecture > and that's why they still prefer the old rs232 thing (like sir James M > Prange). Just think about it, flash MCU's with usb (PIC18F2455...) cost > 4-7$ each. You can easily make a full chain of sensors (127 max) and > plug them all in the calc. They would all be independent, hot > swappable... All the data would be in nicely formatted files in a huge > SD card. Plug it in directly in the computer to analyse. > Old rs232 is definitively much easier, but it would be a pain to > implement a tiny part of what usb can do. > So here's what I'm gonna do, I find myself a cheap and simple usb mouse > and try write a driver for it. Of course to do so, I must know all the > usb architecture as the palm of my hand, I must also learn to write C > progs for the calc, and to understand the one page explanation the > samsung datasheet gives about usb host implementation (Refer to Open > Host Controller Interface Rev 1.0 specification for detail > information. jeje). > I really hope I could come up with my mouse cursor in my calc moving on > the screen in this week. > I don't promise you anything, but trust me... > See ya all, great wonderful work, hpgcc group, manjo and all the others. > Dimitri === Subject: MLC -- A multi-platform language is currently working on a new language that would replace BASIC on all the major calcs as the on-calc gaming language. Since BASIC is not intended for game design we feel that a new language is needed to replace it (without loosing its most redeaming quality of being on-calc programmable). We've decided to take it a step further and make it possible to play games on this language on every calc model we can make an interperator for, so far that includes most Ti models (Ti86 currently has a working beta) and the Casio Algebra FX2 (also has a working beta), we hope to extend this to virtually all Ti models and the Casio Classpad as soon as possible. Now, why im telling you all this is because our group is made up of some of only Ti and Casio programmers and we need someone (or someones) to help us make a Hp version (or Hp will not have MLC capabilities). For those doubtfull of the possibilities of MLC i can assure you that so far we have been able to surpass BASIC in every way (every BASIC i know of at least...), we support 4 levels of grayscale, sprites, strings (Casio BASIC lacked string support untill the CP300), functions, buffer switching, and speeds far exceeding BASIC amoung other things. there is currently a PC MLC emulator which mimics the speed we expected MLC to run at (we were wrong, it actually ended up go faster than the highest speed setting...), but it is slightly out of date (variable were originally going to be displayed as numbers, ex: %001 = integer variable, but now we support text variables as well). This program comes with some demo programs and games to demonstrate what MLC can do even in this early beta form. I can provide this emulator apon request to any persons interested in this project and possibly willing to help, just post here or send me an e-mail. I'll also answer any questions that you have regarding the language, sentax, etc... community to be left out. :) CrimsonCasio (admin casiocalc.org, co-founder of Epic Programming Studios) === Subject: Global Variables Hi. Can someone point me to some documentation that would show how to create a global variable with an Hp49+. Using Debug4X would be the best solution, if it's possible. Alan === Subject: HP-49+ Executing a program.. (Newbie!) OK, My HP-49+ is 30 minutes old, I have downloaed a game into a directory (the important stuff first), how do I execute it? Richard === Subject: Re: HP-49+ Executing a program.. (Newbie!) > OK, My HP-49+ is 30 minutes old, I have downloaed a game into a directory > (the important stuff first), how do I execute it? Now. Its great to see that I am not the only one struggeling to run the games I got my self :) Here is my notes from when I learned this a week ago ;) There are two kinds of programs for the 49. There are programs and there are libraries. Many games comes as libraries. I asume you used the windows-tool to transfer the file to your calculator. You must remember where in the catalog structure you put them. I made a folder called games, under home, and put the files in there. Go to the files menu on the calculator, using green - Apps. in there you navigate using the cursors. left for cd .., right for cd. Find the folder containing your files. If the files-program says the files are prog, you can run them by evaluateing them, by pressine eval (that is F5). If it says it is a library, you must move it. Select the file, mark it by pressing enter, press move. A library must be placed in a port. You can see them on the root of the file-tree. ress left a couple of times. Select 2:FLASH, and put them in there. Reboot your calculator, pressing ON+F3 and releasing them at the same time. You should see fancy graphics as the calculator boots. It only takes a second. Now press red - 2 (LIB). Ypu should see your game in the menu. Have fun H.8cvard === Subject: Re: HP-49+ Executing a program.. (Newbie!) You have to know the name of the program that you loaded into the HP49. If you can see the name on the bottom line of the calculator, then just push the F-button under your program name. If you cannot see the name of your program, then you can push the NXT button, which will show you the next 6 programs in the calculator. Keep pushing NXT. Eventually you'll get back to the original 6 programs. If you can't see your program name, then push the VAR key, and use the NXT key to go through all those choices. At some point you should see your program name. Just push the coresponding F1 - F6 key under your program name. Hope this helps. I haven't used the HP49 - I have an HP48 and a HP48GII. They should be similar. Alan PS - the 1st reply is the best approach! But this may get you running a program quickly (and then again, maybe not!). > OK, My HP-49+ is 30 minutes old, I have downloaed a game into a directory > (the important stuff first), how do I execute it? > Richard === Subject: Let me be the first to suggest... was Re: HP-49+ Executing a program.. (Newbie!) This calculator has a pretty steep learning curve to it. It's kind of like DOS 3.2 was, but more disjointed. Take the 5 or 6 hours and spend it reading through the manual, starting from the beginning for at least 5 chapters, then perhaps skip to the programming bit. Then you'll be in a position to get something out of learning to install software onto the calculator.. and there is a lot of great stuff to install. Al... > OK, My HP-49+ is 30 minutes old, I have downloaed a game into a > directory (the important stuff first), how do I execute it? > Richard === Subject: Transfering files via connectivity kit Not to long ago I got a PC running xp for the first time. Although I still intend to install linux on the machine I plan on leaving xp on it for now. While I had xp on the machine I thought I'd give the connectivity kit a try. After a bit of fussing I managed to get xp to see the 49g+ and was able to connect. The question I have now is how do I copy files to and from the calculator. I see there are some options under the file menu for copying files but they're grayed out and I can't use them. Does anyone have any ideas?? -- Keep working millions on welfare depend on you ------------------- fwp@deepthought.com === Subject: Re: Transfering files via connectivity kit dragging and dropping the file on my own. : Not to long ago I got a PC running xp for the first time. Although I still intend : to install linux on the machine I plan on leaving xp on it for now. : While I had xp on the machine I thought I'd give the connectivity kit a try. : After a bit of fussing I managed to get xp to see the 49g+ and was able to : connect. The question I have now is how do I copy files to and from the : calculator. I see there are some options under the file menu for copying files : but they're grayed out and I can't use them. : Does anyone have any ideas?? -- Keep working millions on welfare depend on you ------------------- fwp@deepthought.com === Subject: Re: Transfering files via connectivity kit X-RFC2646: Format=Flowed; Original > Does anyone have any ideas?? drag and drop like any Windows Explorer window. If the small icon on the icon bar shows 0101010 its a binary transfer. If the icon shows ABC is an ASCII (text) transfer. -- - - - - - - - - - - - - - - - - Bill Graves RKBA! bgraves@ix.netcom.com === Subject: Re: Transfering files via connectivity kit >>Does anyone have any ideas?? > drag and drop like any Windows Explorer window. > If the small icon on the icon bar shows 0101010 its a binary transfer. If > the icon shows ABC is an ASCII (text) transfer. Of course copy and paste between the Conn4x window and MS Windows Explorer works too. But HPComm showed the PC files in the same window, and I remember that it took me a little time to figure out that I had to also open another window to transfer files with Conn4x. -- James === Subject: Re: Transfering files via connectivity kit You simply drag and drop your PC files onto the window that shows the directotries that you have in your calculator. This is a very obscurely documented feature! It took me a while to figure it out! You can also drag them the other way as well. Have fun! Alan Ferguson > Not to long ago I got a PC running xp for the first time. Although I still intend > to install linux on the machine I plan on leaving xp on it for now. > While I had xp on the machine I thought I'd give the connectivity kit a try. > After a bit of fussing I managed to get xp to see the 49g+ and was able to > connect. The question I have now is how do I copy files to and from the > calculator. I see there are some options under the file menu for copying files > but they're grayed out and I can't use them. > Does anyone have any ideas?? === Subject: Re: Feature request: PREVAL should support matrices > Hello HP, > Algebraic mode calculate(RPN is same): > PREVAL([[X][X^2]],1,2) > I expect [[1][3]] but HP49G+(ROM 1.23) just say Bad Argument Type, > it seems HP49G+ MATRICES and CALC still need integrate more. > I don't know where to report such feedback, so I post it here. > BTW: Such matrix operation was quite normal operation in Linear System > Theory if you want some more example. Seems unlikely to be implemented. You can easily write it yourself, though. As far as I know, PREVAL is a very simple function (it wouldn't catch singularities or branch cut discontinuities, for example). BTW, does Bernard Parisse still frequent this newsgroup? -- Bhuvanesh === Subject: [49+]Tick marks in Graphing Question Using the 2D/3D inform screen (left-shift hold, F4), in the lower right corner of the screen, one can set the tick marks on the axes to be measured either in pixels (check mark showing) or in actual distances (check mark off). I would like to control that choice within a program, but I can't figure out how to do it. I have checked all the flags, and there does not seem to be any flag controling that option. I did a RCLF from each setting but there was no difference in the flags. Does anyone know how that option can be controlled in a program? === Subject: Re: [49+]Tick marks in Graphing Question X-RFC2646: Format=Flowed; Original If you mean UserRpl, then use ATICK command. On Lev1 Stack put a single value or a list of 2 values. If these values are real numbers then the ticks will be in distances, for example: %5 ATICK sets both axes to 5 units { %5 %3} ATICK sets the x-axis to 5 units and y to 3 units. Using BINTS (binary integers) as the argument gives ticks in pixels: #101b ATICK sets both axes to 5 pixels { #101b #11b } ATICK sets the x-axis to 5 pixelsand y to 3 pixels. To change from a real number to a bint use R->B, ie put '5' on the stack and press R->B gives #101b. Daveh > Using the 2D/3D inform screen (left-shift hold, F4), in the lower right > corner of the screen, one can set the tick marks on the axes to be > measured either in pixels (check mark showing) or in actual distances > (check mark off). > I would like to control that choice within a program, but I can't figure > out how to do it. > I have checked all the flags, and there does not seem to be any flag > controling that option. I did a RCLF from each setting but there was no > difference in the flags. > Does anyone know how that option can be controlled in a program? === Subject: Re: [49+]Tick marks in Graphing Question > If you mean UserRpl, then use ATICK command. > On Lev1 Stack put a single value or a list of 2 values. If these values are > real numbers then the ticks will be in distances, for example: > %5 ATICK sets both axes to 5 units > { %5 %3} ATICK sets the x-axis to 5 units and y to 3 units. > Using BINTS (binary integers) as the argument gives ticks in pixels: > #101b ATICK sets both axes to 5 pixels > { #101b #11b } ATICK sets the x-axis to 5 pixelsand y to 3 pixels. > To change from a real number to a bint use R->B, ie put '5' on the stack and > press R->B gives #101b. > Daveh uses of real versus BINTS in graphics. > > Using the 2D/3D inform screen (left-shift hold, F4), in the lower right > > corner of the screen, one can set the tick marks on the axes to be > > measured either in pixels (check mark showing) or in actual distances > > (check mark off). > > I would like to control that choice within a program, but I can't figure > > out how to do it. > > I have checked all the flags, and there does not seem to be any flag > > controling that option. I did a RCLF from each setting but there was no > > difference in the flags. > > Does anyone know how that option can be controlled in a program? === Subject: Re: HP49G+ ? Great Quality.... !!! Update: GOOD NEWS !!!! manjo schrieb im Newsbeitrag > Hehe > -it's nice to see you still got your good spirit :-) > no don't wait just send it away, > but be sure to attach a message with it > -it is important that they have your words in written, also keep a copy for > you'r files. Thats what I did the four times before..... > Get some names -whom you will give/send your calculator too, so we can > reference these names here. I have the name (unfortunately not nameS). In Germany theres ONE repair center and they know my name und my number. I got the feeling they are tired of talking with me.... It seems to me that - when my call comes - they think Oh my god... Not THIS guy again.... The person I was talking to keeps saying: We tried the calculator and we couldnt find any connection problems. It MUST be your Windows configuration. Maybe I should send my laptop too. So they can test my WHOLE system... > -let me put it this way : > If somone is providing bad service, -which is causing serious damage to > HP -Hp shpuld be able to deal with it > -and belive me there ARe peopkle willing to provide good service, regardless > if the company is called HP or not. > you may find people who are proud to be a HP dealer, AND making good money > out of it. I hope so...... > manjo Christian === Subject: Re: HP49G+ ? Great Quality.... !!! Update: GOOD NEWS !!!! > So you're the developer for the Connectivity Kit, great to see you read this > NG :) (as to current opposed to HP developers). It seems to me that Bill has been reading this newsgroup for quite a long time, and he does respond when he has something relevant to say. Sometimes Cyrille posts too, when he has something to say. I suppose that it may be that he avoids posting because we complain so much. > Can you work with the folks at hptalx.sf.net to try and add missing features > to HPTALX, making it similar to what the Conectivity Kit is right now? That > would be great, real Linux comunication support. And since it's open-source > it could even be made a port for Macintosh. Note that Michael Heinz has written HPConnect for transferring files between the 49g+ and a Mac. Not being a Mac user, how well it works, how it compares to Conn4x, and even whether it's Kermit-based or Xmodem-based, I don't know. See: http://hpconnect.sourceforge.net/ or http://www.hpcalc.org/details.php?id=6106 -- James === Subject: Re: HP49G+ ? Great Quality.... !!! Update: GOOD NEWS !!!! > Yes I Have. In the connectivity kit speed is set to 115200. But if I select > HPx9G+ it turns grey. The HP shows the 115200 in the IOPAR Variable.... > Maybe I could try less speed ??? > Christian The speed selection is only used for communicating with the earlier HP49G and 48G which both use RS232. This setting doesn't effect USB communication. I've had similar problems in the past. A good way to test basic connectivity is to take a screen shot. This always worked even when I couldn't connect properly. Brody === Subject: Re: CN33's from Samsoncables Luis, May I suggest: Within Australia: www.geocalc.net Outside Australia: www.hpcalc.org Noel Causerano (Registered Surveyor) GEOCALC SOFTWARE Registered Reseller HP Invent Cairns, QLD, Australia Email: noel@geocalc.net WEB: www.geocalc.net === Subject: Re: HP49G and BATTERIES:unexpected high consumption >Hello. >I have an hardware problem, I think, with my hp49g. A month ago, I've >changed the batteries (type AAA) of my calculator because it was time >to do it. >But the new batteries bacame flat after only a week. So I've thought: >maybe the batteries were not good. I've tried to put in hp49g a new >set of batteries, but the problem exists still. I've changed 3*3 >batteries (different brands) in 3 weeks: it is not normal. Before this >problem (a month ago and earlier), the calculator worked fine for >20-30 days with a set of 3 batteries, considering my normal usage of >the calc. >Does anyone know what is the problem? >>Did you install the batteries reversed? I've read of that >>partially shorting out a Zener diode and causing a high drain. >>See: >>If that's the problem, then the best thing would be to replace the >>Zener, but I expect that just opening the diode up would work well >>enough. > I think that my calculator has a problem with the zener diode: I've > read a bit about this and I'm quite sure that I' ve put the batteries > with reverse polarity (only for the time necessary to understand the > mistake, ten seconds). Ouch! > So I've damaged the zener diode and also the > calculator because hp49g can't be open using a normal screwdriver Like many devices these days, these calculators aren't designed to be repaired. It's usually cheaper for the manufacturer to replace them than to repair them, so why bother with screws? Also, I suppose that it makes it pretty obvious if the device has been tampered with, voiding the warranty. I suppose that they prefer that the user buy a new device if the current one stops working, instead of it being repaired. > (it > is not a thing that a user can expect from a so expensive calculator, > I mean that hp49g should not be damaged by a simple change of polarity > of batteries, but nevermind). They could've added an ordinary diode in series with the battery for reverse polarity protection, but that would waste a lot of power, probably dropping enough voltage to require one more cell. They could've added a fuse in series with the battery, and maybe, in parallel the Zener diode, an ordinary diode (normally reverse biased), perhaps in series with a resistor. That would give protection against reversed polarity. This would've meant added cost, especially for a user-replaceable fuse. With the 49g+, it looks to me as if the cells wouldn't make contact at one end if inserted reversed, so that seems to be an improvement, and I guess a fairly cheap method of protecting against reversed polarity at that. Of course, the coil springs for the 49g+ cells also make it pretty obvious that the negative ends of the cells are supposed to go there. But there have been reports of some AAA cells with shorter than usual positive buttons not quite touching the flat spiral contact. But with the cost of these calculators, I'd expect the user to exercise reasonable caution about battery polarity. But mistakes do happen. I expect that quite a few devices would be damaged by connecting DC power with reversed polarity. Does anyone care to experiment? > The solution is to change the damaged diode or to remove it without > replacing (I've read that it doesn't influence the correct usage of > calculator). Is it true? If the zener can be removed, which is its > utility? My understanding is that it's there to help meet electrostatic discharge standards. I suppose that the idea is that the high voltage (either polarity) from an electrostatic discharge causes a current through the Zener, limiting the voltage applied to the rest of the circuits. The electrostatic discharges that this is intended to protect against, although high voltage, have low total energy, so the Zener won't be be damaged by them. But under ordinary conditions, it doesn't do anything at all; with the battery inserted correctly, and the applied voltage lower than the Zener threshold voltage, it amounts to practically an open circuit, although I suppose that there may be an extremely small reverse current leakage. > With a calculator without the zener, which caution a user > must consider? I suppose that there's a chance that a user could have a static charge when changing the battery. Maybe touch a good ground first. > If the best solution is to change the zener because this diode is very > recommended, how can I open my calc without to damage other component > and to change it? I've never opened a 49G, but my understanding is that by removing the heads from the half-dozen plastic rivets visible under the batteries, it can be opened fairly easily; much easier than opening a 48 series. I'd use a small drill or maybe a countersink bit, turning it with my fingers, not using a power tool. Maybe search at http://www.hpcalc.org/ > If I can open the calc, can I understand > definitively if the problem is the zener or I can only suppose which > is the problem? I don't know; I'd guess that the damage probably wouldn't be visible, but it might be. > And if I open the calc,how can I see the zener (is a > photo or a picture available to understand which is the zener among a > lot of components)? Again I don't know. Maybe a search at hpcalc.org? Also ask on http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi The Museum is intended mostly for older out of production models, but some of the people there are knowledgeable about newer models as well, and quite a few of them have experience repairing calculators. Maybe check with http://www.fixthatcalc.com/ He should be able to repair it. But I guess that you're located in Europe; maybe someone over there does calculator repairs? Contact HP. They used to have a policy of exchanging out of warranty (including damaged) calculators at considerably below the usual retail price, and I suppose that they still may. Maybe they'll exchange it for a new 49G, or if they don't have any left, maybe a 49g+. -- James === Subject: Re: Hpcalc.org - no updates and 49g+ category > I was quite alarmed because hpcalc.org is the center of my hp world so > no news on hpcalc = no hp news for me. > Any one knows some other worthy websites ? http://m.webring.com/hub?ring=hp48 -- James === Subject: Re: HP-33S tricks & ruminations X-Eric-Conspiracy: There is no conspiracy. > 6502 core if they were planning to use C; seems like there are better > choices out there. If you can find a better choice that costs less than the Sunplus chip (even assuming that a different processor might have better code density), HP might like to hear about it. > Personally, if I were doing a Qonos-like project to provide 'similar to an > HP 33S' functionality, I'd be tempted to use something like an MSP430 > microcontroller with a Xilinx Coolrunner CPLD for the display controller. Sure, that would be a great platform. Also almost ten times as expensive as the Sunplus. > The MSP430 is also a decent target for a C compiler. Definitely.