Specualtion on 49G+ amd 48GII
Harold A. Climer
Having read all the comments about the new HP calculators, I ask the
following questions.
1. Is HP going even more proprietary than it has in the past i.e
during the days of the HP41 series? HP-IL etc.
The kulge with the cable for the 48gII. One now can not just build
their own ant longer. Are they going to come out with an expensive HP
only accessory to accomplish what is missing?
2. The fact that the 49G+ can only be a USB client and not a
USB server that according to some knowledgeable people who contribute
to the discussions on this group, the hardware is available to have
two USB ports on the calculator. Again is an expensive HP only
accessory in the wings that allows two way USB communications for the
49G+?.
Harold A. Climer
Dept.Of Physics,Geology,and Astronomy
University of Tennessee at Chattanooga
Chattanooga TN USA 37403
D Herring
I see things in a slightly less pessimistic light. Instead of these
being malicious defects, I think they were engineering/marketing tradeoffs.
Here are my speculations.
48GII:
For some reason HP felt it was better to put the CMOS/TTL/whatever <->
RS232 conversion circuitry in the cable instead of the calculator.
Since RS232 operates at a higher voltage than the calculator, battery
savings can be achieved by powering this circuitry from the host. For
99% of the population (e.g. those who use the supplied cable), the
location of the conversion circuitry has absolutely no effect on the end
user.
Calculator to calculator connections may be able to bypass the RS232
voltage levels entirely. I also suspect that the conversion circuitry
is at a moderately high risk of damage due to incorrect voltages; it is
easier to replace a fried cable than a fried calculator.
49G+:
Another USB port would probably have increased the cost with negligible
benefit to the end user. In fact, 2 USB connectors (or 1 multiplexed
connector) would probably confuse the user. Anyway, why would people on
the field want to connect two calculators with a USB cable instead of
IR? A major complaint about the 49G was the requirement for the (TI
style) cable connection. If you're only using USB when connecting to a
host computer, then you don't need host capabilities on the calculator.
In short, engineering explanations provide the same results as paranoia,
but also provide reasons of "why this way".
A mostly satisfied (and still happy) 49G+ user,
Daniel Herring
Rich
D Herring replied:
> Hi Harold,
>
> I see things in a slightly less pessimistic light. Instead of these
> being malicious defects, I think they were engineering/marketing tradeoffs.
>
> Here are my speculations.
>
> 48GII:
> For some reason HP felt it was better to put the CMOS/TTL/whatever
> <-> RS232 conversion circuitry in the cable instead of the calculator.
> Since RS232 operates at a higher voltage than the calculator, battery
> savings can be achieved by powering this circuitry from the host. For
> 99% of the population (e.g. those who use the supplied cable), the
> location of the conversion circuitry has absolutely no effect on the end
> user.
Interestingly, there have been several post *by* end users who could not
get the RS232 to work. Typically the complaints you see are just the tip
of the iceberg.
> Calculator to calculator connections may be able to bypass the RS232
> voltage levels entirely.
I do not recall that they are supported for the 49G+, I suspect the same
is true for the 48GII. You could upgrade the calc OS from another calculator
on the 48 series, a very handy feature IMHO. Several have posted of missing
this feature as well.
> I also suspect that the conversion circuitry
> is at a moderately high risk of damage due to incorrect voltages; it is
> easier to replace a fried cable than a fried calculator.
I really doubt you're going to get enough voltage from one HP49G+ to
fry another, methinks your risk assessment is out of the ballpark.
> 49G+:
> Another USB port would probably have increased the cost with
> negligible benefit to the end user. In fact, 2 USB connectors (or 1
> multiplexed connector) would probably confuse the user.
Yes, the engineering community is hopelessly confused by such things,
it a damn shame they cannot be more like the women on TV who can do
anything.
> Anyway, why
> would people on the field want to connect two calculators with a USB
> cable instead of IR?
Since the 49G+ does not support IR connections, it would seem the only
option. The 49G also lacks IR, but it includes a cable to connect two
49G's or a 49G and 48X.
> A major complaint about the 49G was the
> requirement for the (TI style) cable connection.
Interestingly, I've not heard this. A quick deja search of this group
failed to find a single complaint. Where does this come from?
> If you're only using
> USB when connecting to a host computer, then you don't need host
> capabilities on the calculator.
And that is the complaint, users don't "only" connect to a host computer,
and this connection does not work reliably or on all computers, which is
another complaint.
> In short, engineering explanations provide the same results as paranoia,
> but also provide reasons of "why this way".
When it was explained why the 49G had no IR, that was an engineering
explanation, the Saturn has only one hi-power pin and that was needed for
writing to the flash ram. What you posted does not seem to be an
engineering explanation as far as I can tell.
> A mostly satisfied (and still happy) 49G+ user,
Me, I'm gonna wait a bit.
Rich
> Daniel Herring
motz
Data acquisition systems
HMI equipment
Telemetry systems
Remote control systems
PLC's
Radio equipment
Telescopes
Scada systems
and on and on ...
Why would they want to do that? Because many of us would like to use
I/O data as process parameters for calculated decision making. You
might think that a laptop or desktop computer would do the job, but
the foot print for those type of devices is impractical for field
useage. The calculator makes life much better when, say, it's -10
degrees with a cold blowing 20 mph wind and your natual gas flow
computers indicate field maintenance is required to shut in a high
volume pipeline's electrically operated valves when the pressure
changes to some determined value. (Just as an example).
So, I would like to have some means to move data through the USB port
to an RS 232 interface of any design and I bet there are plenty of
other existing and potential customers who would also.
On Sat, 01 Nov 2003 19:14:51 GMT, D Herring
Joseph K. Horn
> 1. Is HP going even more proprietary than it
> has in the past i.e during the days of the
> HP41 series? HP-IL etc.
In my personal opinion, no, and in fact quite the opposite. Back
then, almost everything was proprietary; now we have lots of industry
standard and off-the-shelf partsm e.g. the ARM9 CPU, a USB port, SD
memory cards, and more-easily obtained batteries. Nothing to sneeze
at!
> The kulge with the cable for the 48gII. One
> now can not just build their own ant longer.
Why not?
> Are they going to come out with an expensive HP
> only accessory to accomplish what is missing?
Are you referring to the overhead-projector LCD panel, which requires
the same 10-pin serial port that is in the 38G, 39G, 40G and 49G?
> 2. The fact that the 49G+ can only be a USB
> client and not a USB server ...
Same as your digital camera, MP3 player, and most other USB devices,
right? The reason that USB was included was to let the user upload
and download to/from a computer. All you need for that is Xmodem
Server mode. Making the 49g+ a USB controller would have taken more
hardware & software than could fit into the projected price point.
How much extra would you be willing to pay for the 49g+ to be capable
of being a USB controller? Even more importantly, can you guarantee
that all other hp49g+ buyers would be happy to pay the same higher
price that you're eager to pay?
Anyhow, it won't be long before somebody develops a cable that plugs
into the SD card slot and connects to external devices. That's also
industry standard, and capable of robust I/O.
> is an expensive HP only accessory in the wings
> that allows two way USB communications for the
> 49G+?.
It's already capable of that. Being "only" a USB client makes it
already capable of 2-way communication... also knows as I/O.
-Joe-
Disclaimer: The above was my opinion when I wrote it, but might no
longer be my opinion by time you read it, so don't let it get your
panties in a bunch.
James M. Prange
> Hi Harold,
>
> I see things in a slightly less pessimistic light. Instead of these
> being malicious defects, I think they were engineering/marketing tradeoffs.
Instead of malicious defects, I see them as engineering/marketing
mistakes.
But I do applaud using the widely available SD card. Remember what the
expansion cards for the previous 48 series calculators cost? And even
though I don't like the USB on the 49g+, at least the cable is industry
standard.
> Here are my speculations.
>
> 48GII:
> For some reason HP felt it was better to put the CMOS/TTL/whatever
> <-> RS232 conversion circuitry in the cable instead of the calculator.
> Since RS232 operates at a higher voltage than the calculator, battery
> savings can be achieved by powering this circuitry from the host.
Actually, on the previous calculators, outgoing RS-232 signals are at a
low voltage level. Only the incoming signals are level-converted, and I
don't see that it would have to put any extra load on the battery. The
outgoing signal levels may be questionable, but they seem to work quite
well. Why change something that works so well?
> For
> 99% of the population (e.g. those who use the supplied cable), the
> location of the conversion circuitry has absolutely no effect on the end
> user.
As long as the device that they're connecting to can supply the power.
That's ok if you're connecting to a PC, but for many other devices....
But the 48gII doesn't have all that much memory, and isn't expandable,
so might not be very suitable for some applications anyway.
> Calculator to calculator connections may be able to bypass the RS232
> voltage levels entirely. I also suspect that the conversion circuitry
> is at a moderately high risk of damage due to incorrect voltages; it is
> easier to replace a fried cable than a fried calculator.
Maybe so, but for the user, buying an HP proprietary cable may be more
expensive than you expect.
> 49G+:
> Another USB port would probably have increased the cost with
> negligible benefit to the end user.
Probably true, as the end user would no doubt need to install a special
driver on the 49g+ host to go with whichever device he wanted to
connect. Who wants to write a driver, specifically to be installed on a
49g+ host, for whichever devices he wants to connect to?
> In fact, 2 USB connectors (or 1
> multiplexed connector) would probably confuse the user.
Remember that the users of these advanced calculators may be a bit more
technically competent than those who have a problem figuring out how to
connect their VCR to their TV. I expect that even the GameBoy crowd
could cope with two different connectors.
> Anyway, why
> would people on the field want to connect two calculators with a USB
> cable instead of IR?
For connecting two calculators, IR may be ok. *If* it actually works. I
notice that the signal to the 82240 printers is much weaker than it is
in the previous calculators, and I haven't figured out a way to
communicate with a 48SX or 48GX in Serial IR mode. Does anyone know
whether the IrDA on the 49g+ actually works?
But I think that what people in the field really want a cable for is
connecting to other devices, which may not have any sort of IR
capability at all. An RS-232 cable, that is, *not* a USB cable!
> A major complaint about the 49G was the
> requirement for the (TI style) cable connection.
Needing a different cable than I use for the 48 series might be a minor
nuisance, but "major complaint"? Where did you see that? If I simply use
the supplied adapter, the 49G cables work perfectly well with the 48
series.
> If you're only using
> USB when connecting to a host computer, then you don't need host
> capabilities on the calculator.
Absolutely true, but what if you want to connect to anything else?
RS-232 works quite well on the older 48 series calculators, but it's
missing on the 49g+ (and crippled on the 49G and 48gII).
> In short, engineering explanations provide the same results as paranoia,
> but also provide reasons of "why this way".
>
> A mostly satisfied (and still happy) 49G+ user,
Well, I didn't seriously expect the 49g+ to be what I'd use for real
work, it was easy enough to guess what the documentation would be like,
and I knew that it couldn't communicate with the 49G. My major
complaints are the keyboard that misses keypresses even worse that the
49G does, the weak IR to the printer, and not being able to communicate
directly with the 48 series calculators. I expect that most of my other
complaints with the 49g+ could be corrected by a ROM upgrade, if HP
cares enough to continue supporting it.
--
Regards,
James
Al Borowski
> For connecting two calculators, IR may be ok. *If* it actually works. I
> notice that the signal to the 82240 printers is much weaker than it is
> in the previous calculators, and I haven't figured out a way to
> communicate with a 48SX or 48GX in Serial IR mode. Does anyone know
> whether the IrDA on the 49g+ actually works?
USB does not work on my PC running win98, so I regulary use IrDA for
transfers - it appears as a virtual COM port under '98, and works fine
with the old software.
cheers,
Al
Ed Look
Al Borowski
> Strange, USB basically works well in my Win 98 (NOT SE)...
I meant that the HP49G+'s USB does not work under my system. I have an
SD card reader/writer that works fine though.
Al
Ed Look
I installed a PCI USB 2.0 card, giving me 2 more ports. The original
two included with my system are 1.0. The 49G+ DOES have a little
problem with the two USB 2.0 ports on the PCI card. But since I shifted
the 49G+'s cable to the old port, it works like a charm every time... so
far; after reading everyone's kvetches, a little prayer is in order...
Harold A. Climer
wrote:
Unfortunately for small engineering and surveying firms the GX was a
perfect solution for collecting,analysing, and storing data and then
downloading it to a PC in the office. The new data loggers now
available are much as 40 times as expensive as a GX. Now HP has given
these small companies no upgrade route for the discontinued GX,
Companies ( like the one my brother works for) work on very small
margins, and can not afford lots of new wis-bang equipment every year
and still remain competitive with larger rivals.
HP has forgotten who their core customers really are IMHO.
At least the HP I have know for the last 30 years.
It is really a shame that marketers have taken over the
world.
James M. Prange
Thanks Al. So there is hope. If I add IrDA to my PC, I should be able to
use the same software that I use with the other calculators then? Does
the Kermit protocol (especially ASCII mode) still work on the 49g+? What
about the serial I/O commands such as XMIT and SRECV? About what range
does the IrDA have?
Maybe an IrDA to RS-232 converter will also work for other devices,
provided that they can supply the power or it's battery powered. I know
that they're available; does anyone have any experience with them?
Still, I'm curious as to why my 49g+ has such a short range to the 82240
printers. Do I have a defective unit (external serial CN331..., internal
serial CN337...), or are they all like this?
What about printing to IrDA printers? Seeing that the 49g+ does print to
the 82240 printers, I surmise that it's using the "Red Eye" format for
printing via IR; is there a way to make it use the IrDA format?
And what about communicating with the "old" 48 series via serial IR? Is
there a way to make the 49g+ use Serial IR?
I notice that APPS "I/o functions.." shows me "Send to HP 49/48GII" and
"Get from HP 49/48GII". I wonder what the deal is with those? Maybe
whoever wrote that expected the 49g+ to have an RS-232 port? Or maybe
they plan on making a special accessory for communicating with RS-232
devices? On the other hand maybe the "49" part refers to the 49g+, and
it means via IrDA.
--
Regards,
James
motz
work for my setup. Two inches is it. Beyond that no workee.
Al Borowski
> Thanks Al. So there is hope. If I add IrDA to my PC, I should be able to
> use the same software that I use with the other calculators then?
Well, if you are running win98, then yes. WinXP does not have support
for a 'virtual COM port' using IR! There may be third party drivers, but
I haven't found any.
>Does
> the Kermit protocol (especially ASCII mode) still work on the 49g+?
Yes
>What
> about the serial I/O commands such as XMIT and SRECV?
Yes, it acts just lioke it was attached via a serial port
About what range
> does the IrDA have?
The range is quite short - maybe less then a foot. Keep in mind I am
usung a dodgey home made IrDA adaptor, so that may be the reason.
>
> Maybe an IrDA to RS-232 converter will also work for other devices,
> provided that they can supply the power or it's battery powered. I know
> that they're available; does anyone have any experience with them?
No, but I'd imagine they would work fine.
>
> Still, I'm curious as to why my 49g+ has such a short range to the 82240
> printers. Do I have a defective unit (external serial CN331..., internal
> serial CN337...), or are they all like this?
I have an ext serial number CN331... as well, so I can't answer that.
>
> What about printing to IrDA printers? Seeing that the 49g+ does print to
> the 82240 printers, I surmise that it's using the "Red Eye" format for
> printing via IR; is there a way to make it use the IrDA format?
No idea.
>
> And what about communicating with the "old" 48 series via serial IR? Is
> there a way to make the 49g+ use Serial IR?
I remember hearing somewhere that this isn't possible, for both software
and hardware reasons.
later,
Al
James M. Prange
> Harold A. Climer wrote:
>
>
>>1. Is HP going even more proprietary than it
>>has in the past i.e during the days of the
>>HP41 series? HP-IL etc.
>
>
> In my personal opinion, no, and in fact quite the opposite. Back
> then, almost everything was proprietary; now we have lots of industry
> standard and off-the-shelf partsm e.g. the ARM9 CPU, a USB port, SD
> memory cards, and more-easily obtained batteries. Nothing to sneeze
> at!
All good points, and apparently they do bring the cost down
considerably.
I'd almost forgotten the problems with finding fresh N cells for the 28
series, and of course many earlier calculators required calculator model
specific battery packs. I suppose that almost everyone has AAA cells "on
the shelf" at home, and the CR2032 cell is commonly used and easy to
find. I hope that the calculators manage the power so that they draw
from the CR2032 only when they're off and the AAA cells are missing or
too low to supply sufficient power to retain memory.
The relatively cheap and widely available SD cards for expansion are
especially welcome.
Of course, when the earlier calculators were developed, perhaps suitable
"industry standard" and "off-the-shelf" components and accessories
simply weren't available. HP calculators really did invent new things
back then.
But why not keep the "industry standard" RS-232? Was there any real need
to invent some new incarnation of RS-232 specific to the 48gII? Or to
eliminate RS-232 from the 49g+?
>>The kulge with the cable for the 48gII. One
>>now can not just build their own ant longer.
>
>
> Why not?
I'm sure that, given sufficient information, one could. But perhaps not
as easily and cheaply as with previous 48 series calculators.
>>Are they going to come out with an expensive HP
>>only accessory to accomplish what is missing?
>
>
> Are you referring to the overhead-projector LCD panel, which requires
> the same 10-pin serial port that is in the 38G, 39G, 40G and 49G?
I'm glad that you mentioned that. How do we use one of those with the
49g+ or 48gII? Of course, besides the connection issue, with the 49g+,
there's also the difference in pixel rows. Although the display panels
are impressive and no doubt could be very useful, I wonder how many were
ever made or used. I have a "3rd party" display magnifier from Firmware
Corp. that I noticed cheap on eBay. It uses a 48SX display and a big
lens and plugs into an expansion slot on the 48SX or 48GX. Pretty nice,
although for me, it's more of a "nifty gadget" than something that I
actually have much practical use for. I still haven't gotten around to
making the cable to connect it to the 49G. I wonder whether HP will
market something similar for the new calculators.
>>2. The fact that the 49G+ can only be a USB
>>client and not a USB server ...
>
>
> Same as your digital camera, MP3 player, and most other USB devices,
> right? The reason that USB was included was to let the user upload
> and download to/from a computer. All you need for that is Xmodem
> Server mode. Making the 49g+ a USB controller would have taken more
> hardware & software than could fit into the projected price point.
I applaud adding the USB client port (although I do wish that the USB
driver and Conn4x combination worked with my PC), but I think that not
also keeping the RS-232 port was a mistake. Uploading to and downloading
from a computer isn't the only thing that RS-232 on the "old" 48 series
is used for. USB is great for connecting to a suitably equipped PC, but
not for connecting to other devices.
I know very little about how USB actually works; it's much like magic to
me. But I suppose that it should be possible to build an accessory
that's a USB host with the hardware and firmware/software for
communicating with the 49g+ on one port, and has an RS-232 port for
communicating with other devices. I don't know how big such a device
would be, but I'd expect that handheld-sized should be feasible. Heck,
with the miniaturization now-a-days, maybe it could fit into a cable
connector.
Taking that a bit farther, it could also have additional USB ports for
communicating with other USB devices. Perhaps sort of a highly
specialized miniature computer for communicating between a variety of
USB devices. For that, we'd have to also have a way to add additional
drivers, but with solid state flash memory, it should be feasible.
Why not an IrDA port while we're at it? One that supports serial IR for
communicating with the 48 series and other legacy devices.
> How much extra would you be willing to pay for the 49g+ to be capable
> of being a USB controller? Even more importantly, can you guarantee
> that all other hp49g+ buyers would be happy to pay the same higher
> price that you're eager to pay?
Personally, I wouldn't pay much, if any, extra for a USB host port on a
calculator, simply because I don't have any USB devices that I'd want to
control from a calculator. But I certainly wouldn't rule out the
possibility that others may have USB devices that they'd like to control
from a calculator, or that I may have one in the future.
> Anyhow, it won't be long before somebody develops a cable that plugs
> into the SD card slot and connects to external devices. That's also
> industry standard, and capable of robust I/O.
An interesting idea, and yet another area that I'm ignorant in (there
seem to be more such areas every day). Certainly it should be possible
to build something that looks to the 49g+ just like an SD card. Maybe a
sort of shared memory area that the 49g+ and some other device can each
read from and write to. But I wonder about negotiating which device is
writing. Certainly you wouldn't want the 49g+ to be writing to (or even
reading from) this shared memory area while the other device is writing
(or reading), and vice versa, and there may be a need to signal that the
contents have changed, so it's necessary to read them again.
>>is an expensive HP only accessory in the wings
>>that allows two way USB communications for the
>>49G+?.
>
>
> It's already capable of that. Being "only" a USB client makes it
> already capable of 2-way communication... also knows as I/O.
Yes, certainly it's capable of 2-way communication, but perhaps not
quite as simply as RS-232. Maybe I have some misconceptions about USB,
but doesn't the host have to initiate any "conversations"? So, if the
host wants to send something to a device, it says, "Hey, pay attention
and get ready for this!" or asks "Are you ready for this?". But if the
device wants to say something to the host, it has to wait for the host
to get around to asking "Do you have anything to say?". So, if I have it
straight, any 2-way communication is dependent on the device being
connected to a host that understands how to communicate with that
particular device.
So for two USB devices to communicate with each other, they'd both have
to be connected to the same USB host which knows how to communicate with
each of them, if I understand correctly. No direct communication between
devices, only via a host acting as an intermediary.
Of course RS-232 also depends on the devices "knowing" how to
communicate with each other. Whether to use other hardware signals
besides the transmit and receive data signals, and if so, how. The
speed, number of start bits, data bits, and stop bits, the parity (or
pseudo-parity), if any. Whether to send and pay attention to XON/XOFF or
other control codes. Whether flow control is even possible and if so,
which method to use. Whether to use full duplex or half duplex. When to
"talk" and when to "listen". Whether a file transfer protocol such as
Kermit or Xmodem is expected. Any special conventions for encoding and
decoding control codes or non-ASCII characters embedded within the data.
And no doubt a few other "minor details" that could frustrate me at
times. But to me, it seems so much simpler, and, in my opinion, a lot
closer to being "industry standard" than USB.
--
Regards,
James
James M. Prange
>> Thanks Al. So there is hope. If I add IrDA to my PC, I should be able to
>> use the same software that I use with the other calculators then?
>
>
> Well, if you are running win98, then yes. WinXP does not have support
> for a 'virtual COM port' using IR! There may be third party drivers, but
> I haven't found any.
Well, that's real encouraging. If I were to upgrade from 98SE to XP, I
might be able to use Conn4x, but would eliminate a chance to add an IR
device that I can treat as a COM port. I wonder whether I'd lose my USB
to RS-232 converter, and just what other "improvements" XP makes. Maybe
with JP Software's 4NT....
>> Does
>> the Kermit protocol (especially ASCII mode) still work on the 49g+?
>
>
> Yes
>
>> What
>> about the serial I/O commands such as XMIT and SRECV?
>
>
> Yes, it acts just lioke it was attached via a serial port
Definitely good news there.
> About what range
>
>> does the IrDA have?
>
>
> The range is quite short - maybe less then a foot. Keep in mind I am
> usung a dodgey home made IrDA adaptor, so that may be the reason.
Well, a bit disappointing, but better than nothing. Maybe someone else
can contribute information on this?
>> Maybe an IrDA to RS-232 converter will also work for other devices,
>> provided that they can supply the power or it's battery powered. I know
>> that they're available; does anyone have any experience with them?
>
>
> No, but I'd imagine they would work fine.
That's what I'd expect too. What I particularly wonder about is whether
they can draw whatever power they need from the transmit and receive
data lines, or do they need some other power source? I suppose that the
information is available online, but I was hoping that someone in the
newsgroup would have experience with one and share his experience.
>> Still, I'm curious as to why my 49g+ has such a short range to the 82240
>> printers. Do I have a defective unit (external serial CN331..., internal
>> serial CN337...), or are they all like this?
>
>
> I have an ext serial number CN331... as well, so I can't answer that.
>
>>
>> What about printing to IrDA printers? Seeing that the 49g+ does print to
>> the 82240 printers, I surmise that it's using the "Red Eye" format for
>> printing via IR; is there a way to make it use the IrDA format?
>
>
> No idea.
Anyone else?
>> And what about communicating with the "old" 48 series via serial IR? Is
>> there a way to make the 49g+ use Serial IR?
>
>
> I remember hearing somewhere that this isn't possible, for both software
> and hardware reasons.
That could be, although the fact that it can send (albeit very weakly)
in the format needed for the 82240 printers leads me to expect that it
should also be capable of using a serial IR format. I was under the
impression that IrDA was capable of a serial IR mode for communicating
with "legacy" devices such as the 48 series calculators. But the fact
that the I/O input forms don't offer a choice of speeds may be a clue.
Perhaps sending to the printers involves some trickery such as sending
bits widely spaced within the IrDA data stream or something like that,
which may also explain the very short range.
--
Regards,
James
Al Borowski
> Al Borowski wrote:
> >> Thanks Al. So there is hope. If I add IrDA to my PC, I should be
> able to
> >> use the same software that I use with the other calculators then?
> >
> >
> > Well, if you are running win98, then yes. WinXP does not have support
> > for a 'virtual COM port' using IR! There may be third party drivers, but
> > I haven't found any.
>
> Well, that's real encouraging. If I were to upgrade from 98SE to XP, I
> might be able to use Conn4x, but would eliminate a chance to add an IR
> device that I can treat as a COM port. I wonder whether I'd lose my USB
> to RS-232 converter, and just what other "improvements" XP makes. Maybe
> with JP Software's 4NT....
Keep in mind that the old version of the PC connectivity Kit works
perfectly well using win98 and IrDA. WinXP works fine with USB. So I
guess it depends on whether you'd prefer paying for an IR adaptor
instead of upgrading to XP.
Al
James M. Prange
> I measured the distance from the 82240B and hp49g+ at which it will
> work for my setup. Two inches is it. Beyond that no workee.
And I've seen other posts that mention a very short range for this. I'd
be particularly interested in hearing from anyone who finds that their
49g+ can print to an 82240A or 82240B from a more or less normal
distance, like about the 3 to 6 feet that I get from the 48SX and 48GX
(I suppose that this depends on battery condition and perhaps model), or
even the 18 inches specified in the printer manuals.
> On Sun, 02 Nov 2003 18:30:00 -0500, "James M. Prange"
> <jmpr...@i-is.com> wrote:
>
>
>>Still, I'm curious as to why my 49g+ has such a short range to the 82240
>>printers. Do I have a defective unit (external serial CN331..., internal
>>serial CN337...), or are they all like this?
--
Regards,
James
James M. Prange
> James M. Prange wrote:
>
>> Al Borowski wrote:
>> >> Thanks Al. So there is hope. If I add IrDA to my PC, I should be
>> able to
>> >> use the same software that I use with the other calculators then?
>> >
>> >
>> > Well, if you are running win98, then yes. WinXP does not have support
>> > for a 'virtual COM port' using IR! There may be third party
>> drivers, but
>> > I haven't found any.
>>
>> Well, that's real encouraging. If I were to upgrade from 98SE to XP, I
>> might be able to use Conn4x, but would eliminate a chance to add an IR
>> device that I can treat as a COM port. I wonder whether I'd lose my USB
>> to RS-232 converter, and just what other "improvements" XP makes. Maybe
>> with JP Software's 4NT....
>
>
> Keep in mind that the old version of the PC connectivity Kit works
> perfectly well using win98 and IrDA.
Yes, so I gathered.
> WinXP works fine with USB.
So far, with the sole exception of the combination of the USB driver and
Conn4x for the 49g+, 98SE also works fine with USB.
> So I
> guess it depends on whether you'd prefer paying for an IR adaptor
> instead of upgrading to XP.
Well, for now, using the SD card and reader works well enough for
transferring files, and I don't have anything other than the calculators
to use IR with. Maybe HP will find a way to get the 49g+'s connection
kit to work even with the PCs that it fails with now.
If I were to upgrade the operating system, I'd be far more inclined to
add a Linux partition than to purchase yet another disappointing kludge
from Microsoft.
--
Regards,
James
Gene Wright
> Unfortunately for small engineering and surveying firms the GX was a
> perfect solution for collecting,analysing, and storing data and then
> downloading it to a PC in the office. The new data loggers now
> available are much as 40 times as expensive as a GX. Now HP has given
> these small companies no upgrade route for the discontinued GX,
GENE: You can't always upgrade from an old model. HP25 programs
wouldn't run unless translated to HP67 programming language, for
example. Surveying software will make its way to the 49G+...give it at
least a few months! I know of one vendor who plans surveying software
for $100 for the 49G+. Since the HP48GX is/has been discontinued
because of CPU shortages (if the rumors are true), then the surveyors
would have to change machines anyway.
> Companies ( like the one my brother works for) work on very small
> margins, and can not afford lots of new wis-bang equipment every year
> and still remain competitive with larger rivals.
> HP has forgotten who their core customers really are IMHO.
> At least the HP I have know for the last 30 years.
> It is really a shame that marketers have taken over the
> world.
> Harold A. Climer
GENE: I don't believe HP's "Core customers" make up enough of a market
by themselves to warrant building a calculator just for it. How many
surveyors use HP calculators? 10,000? 50,000? I don't believe it
would make business sense to make a model for a group that small.
If it DID make sense, another company would jump in and take those
profits for themselves.
The 49G+ will have surveying software - give it a chance to be on the
market long enough!
The 49G+ has the ability to capture and store data for retrieval back
on a PC through the SD card.
These models are only the beginning too. Keep that in mind.
Gene
P.S. And, 48GX's are still to be found for people that really want
them.
motz
Connectivity kit and my hp48sx, via RS-232. I use it almost daily.
I messed around with the IR mode unsuccessfully, trying to make the
hp49g+ communicate with the hp48sx via IR. Now the hp49g+ has assumed
a mode that won't work with the new connectivity kit. I've toggled
things around (back to wire mode, of course, and reset all parameters)
but something must not have "stuck." The hp49g+ worked before, so I
think I can get it back to that point again. The hp48sx has a better
I/O interface, though.
-Dale-
Cyrille de Brébisson
> 1. Is HP going even more proprietary than it has in the past i.e
> during the days of the HP41 series? HP-IL etc.
> The kulge with the cable for the 48gII. One now can not just build
> their own ant longer. Are they going to come out with an expensive HP
> only accessory to accomplish what is missing?
Actually, this is a pretty common practice (the 2 PDA I have with RS232
cable do that)
All CPU and similar that you can see around and that claim to 'support'
RS232 in fact support the protocol, but not the signal strenght (they work
in 0/3.3 v only, which is not a normal RS232 level, but much easier to
acheive on a 3.3V powered IC.
Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable
and powering it from the PC is common practice (this is BTW the way your
mouse gets powered) and saves a lot of power from the device.
Also, doing so allows to reduce risks of destruction of the final device
(cable is cheaper than the calc).
BTW, you should be able to connect 2 calcs with the RS232 using a hand made
cable without any electronics in it. You might even discover that you can
connect with a lot of devices without the "adaptor" circuitry... However,
this is not the RS232 standard.
> 2. The fact that the 49G+ can only be a USB client and not a
> USB server that according to some knowledgeable people who contribute
> to the discussions on this group, the hardware is available to have
> two USB ports on the calculator. Again is an expensive HP only
> accessory in the wings that allows two way USB communications for the
> 49G+?.
Ok, let us speculate that there is a USB host on the HP49G+:
- Where does the power come from? remember, USB is suposed to provide up to
500mA for the periferials. at 800mAH of power on a standard AAA, how long
will the calcualtor battery last?
- Where does the drivers come from? USB clients need drivers to be installed
on the calcaultor in order to work. I imagine that HP will have NO problems
whatsoever to get EVERY USB device manufacturer to create the drivers for
the HP49G+ calcualtor! After all, aren't they all already doing Windows, Mac
and Linux drivers, how much more work would it be to also make HP claculator
drivers?
regards, cyrille
Veli-Pekka Nousiainen
news:3fa67a58$1...@usenet01.boi.hp.com...
You're right about the different drivers for all the different devices
No USB host then.
How about a cable to connect the 49g+ to an RS-232C port then?
Working with BOTH USB 1.1 and 0..3.3V serial would be great!!
VPN
PS: The batteries will last 1_h ?
Harold A. Climer
That is why I am thinking a UBS port on the 49G+ my not be all it is
cracked up to be. I am getting a sinking feeling that maybe it was not
such if a good idea ta abandon wire RS-232 transfer capability.
We use both Vernier ULI boxes(for our in lab PCs), and LabPros for
portable applications.
I hate to have to tell my students that only a TI calculator will work
with them.( LabPro) I really leaves a bad taste in my mouth not to be
able to say HP's will work too.
Bob Roberts
regarding the serial port of the 48GII. When we talk about a custom
48GII HP cable we are talking about a cable with active electrical
elements integrated beneath the connector hood. We are not talking
about a simple proprietary connector scheme that some of the PDA use
on their serial ports. Nor are we talking about a cable that could be
easily built in your average home office. Although it would be
possible to build one yourself, it would not be practical since there
are 18 components required for the voltage level conversion circuitry.
The HP-48GII (and all previous models 48G, 48G+, 48GX) DOES conform
to the proper voltage levels of the RS-232 specification on both the
drivers as well as the receivers. The cable connector is
non-(de-facto)-standard but there are commercially available cables
which have a 9-pin D-sub connector for the previous models (the 48GII
comes with this a custom cable for this purpose).
CPUs do not conform to the RS-232 standard since they lack the proper
voltage levels to drive the cable. Most CPU contains a UART that
handles the RS-232 protocol. The voltage level conversion is left to
the system designer to handle outside of the CPU. Nowadays, this is
almost always done using a charge pump IC that doubles the system
voltage. This allows the proper RS-232 voltage levels to be generated
from any 5 volt or 3.3 volt system without the additional cost of
custom power supply circuitry. The voltage level used by the host
system has nothing to do with RS-232 compatibility.
HP has (for whatever reason) chosen to put this circuitry in the cable
they supply with the unit. All would be well and fine (at least with
me) if they had chosen to power the circuitry. Instead they use the
RS-232 signals DTR or RTS (either will work) of the "terminal" device
to power the cable circuitry. These signals are on pins 4 and 7 of
the D-sub connector. All should work fine as long as you are
connecting your HP to a PC (using proper driver software to toggle
these modem control signals to the proper level). Try using almost
any other 232 device and you are almost certainly out of luck. We
used to use the HPs as portable instrument controllers and have used
the RS-232 ports to control and communicate with any number of RS-232
devices. This will probably no longer be possible with the 48GII.
I have heard some speculate that this was done for power reasons.
Highly unlikely since the 48GII cable circuitry uses the Sipex SP3220E
(similar to the Maxium 3221E). This IC draws only 1 uA of current
when not in use (and this is with the receivers active – which could
support a wakeup feature). I have also seen it noted that it might
have been done for some sort of protection. Why would it matter where
the transceiver were located if this was the case? The pins to the
printed circuit card are still present on the back of the unit. The
unit is much more likely to be damaged by ESD by not including the
transceiver in the unit itself since there is a much more direct shot
at the processor without the protection circuitry the transceiver
provide. By the way, the SP3220E's ESD tolerance is over +- 15kV for
both Human Body Model and IEC1000-4-2 Air discharge test methods.
RS-232 devices do not typically destroy each other. The RS-232
specifications require that the transceivers are practically
bullet-proof.
You should be able to power the cable yourself by supplying 5V DC to
either pin 4 or 7. I can't read the part number on the voltage
regulator so I am not sure how low (or how high) you can go on this
voltage.
Bob Roberts
> Hello,
>
>
> > 1. Is HP going even more proprietary than it has in the past i.e
> > during the days of the HP41 series? HP-IL etc.
> > The kulge with the cable for the 48gII. One now can not just build
> > their own ant longer. Are they going to come out with an expensive HP
> > only accessory to accomplish what is missing?
>
> Actually, this is a pretty common practice (the 2 PDA I have with RS232
> cable do that)
Actually, this is not a common practice at all. Could it be that two
RS-232 devices do it - sure but keep in mind that there are literally
thousands that don't do it. By the way I checked the 5 different
serial PDAs we use - none of them do it. It violates the RS-232
standard and makes the device non-compatible with many different
devices (of course if all you want to do is to connect to a PC - it
should be fine)
> All CPU and similar that you can see around and that claim to 'support'
> RS232 in fact support the protocol, but not the signal strenght (they work
> in 0/3.3 v only, which is not a normal RS232 level, but much easier to
> acheive on a 3.3V powered IC.
We are not talking about a CPU, we are talking about an assembly that
claims support for the standard (at least they used to - I'm not sure
what their official stance is now). Not sure what devices do this.
Any device that used a 3.3 V "RS-232" would be quickly fried when
connected to a true RS-232 device (which would include a standard PC).
> Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable
> and powering it from the PC is common practice (this is BTW the way your
> mouse gets powered) and saves a lot of power from the device.
> Also, doing so allows to reduce risks of destruction of the final device
> (cable is cheaper than the calc).
The RS-232 adapter uses almost no power (only 1 uA) when not
operating. Check the quiescent current draw of the static RAM. Of
course the mouse gets its power from the PC but it is not a RS-232
device (nor does it claim to be). This is why you have a special
mouse port on your PC (or why you use the USB which does supply power
to it's devices). What risks of destruction? (see my follow-up post).
>
> BTW, you should be able to connect 2 calcs with the RS232 using a hand made
> cable without any electronics in it. You might even discover that you can
> connect with a lot of devices without the "adaptor" circuitry... However,
> this is not the RS232 standard.
I would not suggest this unless you are ready to replace your 48GII.
RS-232 voltages can (and do) swing +/-15 VDC. This would quickly fry
your unit without the RS-232 protection circuitry the cable provides.
> > 2. The fact that the 49G+ can only be a USB client and not a
> > USB server that according to some knowledgeable people who contribute
> > to the discussions on this group, the hardware is available to have
> > two USB ports on the calculator. Again is an expensive HP only
> > accessory in the wings that allows two way USB communications for the
> > 49G+?.
Two way USB communication is already possible. The issue is who
initiates the transfer?
> Ok, let us speculate that there is a USB host on the HP49G+:
> - Where does the power come from? remember, USB is suposed to provide up to
> 500mA for the periferials. at 800mAH of power on a standard AAA, how long
> will the calcualtor battery last?
About an hour and a half. USB devices are also allowed to power
themselves. I would imagine that if you choose to connect a USB
device that draws 500mA you would probably want it to be powered via
an external source.
> - Where does the drivers come from? USB clients need drivers to be installed
> on the calcaultor in order to work. I imagine that HP will have NO problems
> whatsoever to get EVERY USB device manufacturer to create the drivers for
> the HP49G+ calcualtor! After all, aren't they all already doing Windows, Mac
> and Linux drivers, how much more work would it be to also make HP claculator
> drivers?
I guess it would be up to them but why prevent them if they wanted to?
>
> regards, cyrille
Pete M. Wilson
>
>But why not keep the "industry standard" RS-232? Was there any real need
>to invent some new incarnation of RS-232 specific to the 48gII? Or to
>eliminate RS-232 from the 49g+?
I can't believe you wrote industry standard and RS-232 in one
sentence.
The PC of the future doesn't have serial ports and a far bigger group
of users will connect 49g+ to PCs than anything else.
No one has mentioned using a PDA as a serial collection device - they
are cheap, programmable in high-level languages, and have lots of
memory, etc. compared to HP calculators - why not use a PDA?
Pete M. Wilson
Gamewood, Inc.
wils...@gamewood.net
James M. Prange
> Hello,
>
>
>
>>1. Is HP going even more proprietary than it has in the past i.e
>>during the days of the HP41 series? HP-IL etc.
>>The kulge with the cable for the 48gII. One now can not just build
>>their own ant longer. Are they going to come out with an expensive HP
>>only accessory to accomplish what is missing?
>
>
> Actually, this is a pretty common practice (the 2 PDA I have with RS232
> cable do that)
>
> All CPU and similar that you can see around and that claim to 'support'
> RS232 in fact support the protocol, but not the signal strenght (they work
> in 0/3.3 v only, which is not a normal RS232 level, but much easier to
> acheive on a 3.3V powered IC.
If I recall correctly, this is just about the signal level from the
48SX, 48GX, and 49G. I'm well aware that it's below the minimum that
RS-232 specifies, but it seems to have worked quite well for a lot of
users for well over a decade. Have there been many complaints about the
low signal level?
> Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable
> and powering it from the PC is common practice (this is BTW the way your
> mouse gets powered)
The mouse that I'm using now isn't RS-232 to start with, and what else
besides a PC would I want to connect my mouse to anyway?
> and saves a lot of power from the device.
I hadn't noticed that the life of the batteries in the other calculators
was particularly short, and I do use the serial port fairly often.
Of course, the power has to come from somewhere, and if not the
calculator, then from the other device. Ok if you're connecting to a PC,
but what if the other device also runs on batteries, or worse yet, like
the calculator, doesn't supply power where you expect to find it?
> Also, doing so allows to reduce risks of destruction of the final device
Have there been many cases of the calculators (with the possible
exception of the defective early 49Gs) being destroyed by power coming
into them through the RS-232 port?
> (cable is cheaper than the calc).
How much cheaper? For the end user who needs to purchase one, that is.
Is it the same cable used on some other devices, or is it HP only?
> BTW, you should be able to connect 2 calcs with the RS232 using a hand made
> cable without any electronics in it. You might even discover that you can
> connect with a lot of devices without the "adaptor" circuitry... However,
> this is not the RS232 standard.
That's good news. Without the cable, can it still stand up to a maximum
strength standard RS-232 signal coming in? How about overvoltages? But I
admit that I don't know just how much the previous calculators could
take; I never attempted to test one to destruction.
>>2. The fact that the 49G+ can only be a USB client and not a
>>USB server that according to some knowledgeable people who contribute
>>to the discussions on this group, the hardware is available to have
>>two USB ports on the calculator. Again is an expensive HP only
>>accessory in the wings that allows two way USB communications for the
>>49G+?.
>
>
> Ok, let us speculate that there is a USB host on the HP49G+:
> - Where does the power come from? remember, USB is suposed to provide up to
> 500mA for the periferials. at 800mAH of power on a standard AAA, how long
> will the calcualtor battery last?
I'd pretty much ruled a USB host on the calculator based on the
requirement for drivers, and hadn't even thought of this issue, although
I had been thinking that the 500mA that my card reader supposedly
requires seems like a lot of current.
So just on the power requirement, a USB host on the calculator is ruled
out short of going to an external power source. But an external power
source opens up a whole can of worms with some people using the wrong
power source, problems with keeping the external power from feeding into
the batteries without requiring disconnecting them and wasting battery
power in the protection circuits....
> - Where does the drivers come from? USB clients need drivers to be installed
> on the calcaultor in order to work. I imagine that HP will have NO problems
> whatsoever to get EVERY USB device manufacturer to create the drivers for
> the HP49G+ calcualtor! After all, aren't they all already doing Windows, Mac
> and Linux drivers, how much more work would it be to also make HP claculator
> drivers?
Well, I suppose that whoever wrote the MS-Windows USB driver for the
49g+ might have an opinion on how much fun it is.
Doesn't the Linux community pretty much develop their own drivers?
And the Mac users... well I guess sometimes they're just plain S.O.L.
unless they can make do with something designed for a Microsoft O.S.
Of course, S.O.L. often describes us MS-Windows users quite well.
And with a calculator as a USB host, I expect that it's users would be
very much S.O.L. for drivers.
I wish it were feasible, but if wishes were horses, guess what we'd be
up to our necks in.
The USB client on the calculator is wonderful for connecting it to
suitably equipped PCs, but not good for much, if anything, else.
Would it have been all that hard to keep an RS-232 port on the 49g+ for
all those other uses?
--
Regards,
James
Eric Smith
> Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable
> and powering it from the PC is common practice
Not in my experience. I have perhaps twenty different handheld devices
with serial ports, and only some of the ones from HP, such as the HP-94 and
HP 48GII have done this.
> (this is BTW the way your mouse gets powered)
My mice are powered by either USB and PS/2 ports. You are, of course,
correct in that serial mice (fortunately a dying breed) were powered
from the serial port. However, this is substantially different from
a communications application, in that the baud rate was very low, 1200
or 2400 bps, IIRC. And even then, it sometimes caused problems if
the mice were used on a long serial extension cable.
> and saves a lot of power from the device.
Irrelevant. If an external transceiver can be wired to steal power from
the EIA-232 signals, an internal transceiver can be wired in exactly the
same way. There's not any special magic in this that only allows it
to be done when built into a cable.
> Also, doing so allows to reduce risks of destruction of the final device
> (cable is cheaper than the calc).
It doesn't do that either. EIA-232 transceiver chips (such as the Maxim
MAX23x and MAX32xx) are designed with a great deal of built-in ESD
protection. CMOS logic-level I/O in processor chips have some ESD
protection, but nowhere near as much as the EIA-232 transceivers,
because it is not expected that they will be directly exposed to the
outside world. If you just bring out the CMOS logic level UART I/O pins
to a connector, even with some discrete transorbs (or equivalent), the
port is likely to be much more susceptible to damage than if the
transceiver was built in.
Maybe there were good reasons for putting the transceiver in the cable,
but you haven't stated any.
Eric
James M. Prange
> "James M. Prange" <jmpr...@i-is.com> wrote:
>
>
>>But why not keep the "industry standard" RS-232? Was there any real need
>>to invent some new incarnation of RS-232 specific to the 48gII? Or to
>>eliminate RS-232 from the 49g+?
>
>
> I can't believe you wrote industry standard and RS-232 in one
> sentence.
>
> The PC of the future doesn't have serial ports and a far bigger group
> of users will connect 49g+ to PCs than anything else.
First off, I guess you missed this paragraph:
I applaud adding the USB client port (although I do wish that the USB
driver and Conn4x combination worked with my PC), but I think that not
also keeping the RS-232 port was a mistake. Uploading to and downloading
from a computer isn't the only thing that RS-232 on the "old" 48 series
is used for. USB is great for connecting to a suitably equipped PC, but
not for connecting to other devices.
Second, I guess that by "industry", you mean just the PC and common PC
peripherals industry. Yes, they are indeed rapidly going to USB, which
is very well suited for them. But I wish that they'd keep an RS-232 port
or two. But even if the PC doesn't come equipped with RS-232, it should
be cheap and easy enough to add a serial I/O card. If you have a
computer such as a laptop that you can't add a card to, USB to RS-232
converters are available at a low cost. So connecting any RS-232 device
to just about any computer shouldn't be any real problem.
USB is very unsuitable for devices that are intended for connection to
anything other than a computer. RS-232 is clearly very superior to USB
for these devices. To be sure, the calculator may be connected to the
computer at times, but most often it's not connected to anything at all,
and in the older 48 series, it's often connected to other devices. But
the USB on the 49g+ is useful only for connecting to a USB host.
In my opinion, RS-232 is alive and well and likely to be in use for a
very long time. Just what advantage other than speed does USB offer over
RS-232 for connecting two devices to each other?
Oh well, maybe if I buy an IrDA to RS-232 converter, I might be able to
connect the 49g+ to RS-232 devices.
> No one has mentioned using a PDA as a serial collection device - they
> are cheap, programmable in high-level languages, and have lots of
> memory, etc. compared to HP calculators - why not use a PDA?
Data collectors are hardly the only reason for connecting a calculator
to something other than a computer. I don't know much about PDAs, but
they generally seem to lack a decent keyboard, I very much doubt that
they're programmable in RPL, I doubt that they have the mathematical
functions I'd like, and with the SD card, I doubt that I'll run out of
memory real soon.
But on the other hand, with a good emulator with a 48G ROM on it, a PDA
type device does have some advantage over a real calculator.
--
Regards,
James
Edward Sanford Sutton, III
> sentence.
> The PC of the future doesn't have serial ports and a far bigger group
> of users will connect 49g+ to PCs than anything else.
ROM update out of the box?
> No one has mentioned using a PDA as a serial collection device - they
> are cheap, programmable in high-level languages, and have lots of
> memory, etc. compared to HP calculators - why not use a PDA?
> Pete M. Wilson
> Gamewood, Inc.
> wils...@gamewood.net
are the only PDAs, but it is one example of many. He needs it for
phonebook, memos, appointments, etc. and all in a light pocket device
with a backlit screen. As it stands, I've set him up with HP emulators
on it since his main complaint is that it doesn't come with a very
powerful calculator, and that at least filled the power gap. For me,
graphing calcs fill my need much better than any PDA I've seen,
including my dad's old PocketPC, which he gave to me (64mb ram compaq
ipaq 3765), and spending a 'little' extra $$$ on a mem card would push
the usable memory of my calculator far beyond what PDA owners I know
have in their units.
So anyone found figured out any fun things that having a calc and
PDA talking can do. IR data transfer, a sort of a hub to have both
connected to a PC all through one link, or using one or another as an
IR repeater are what I've thought could be fun to try to do in the
future.
Ed Sutton
Pete M. Wilson
>Pete M. Wilson wrote:
> >
> > I can't believe you wrote industry standard and RS-232 in one
> > sentence.
> >
>
>Second, I guess that by "industry", you mean just the PC and common PC
>peripherals industry.
Actually, I had the problem with the word "standard". After dealing
with serial devices for over 20 years, that is one word I never use
when it comes to RS-232.
James M. Prange
> "James M. Prange" <jmpr...@i-is.com> wrote:
>
>
>>Pete M. Wilson wrote:
>>
>>>I can't believe you wrote industry standard and RS-232 in one
>>>sentence.
>>>
>>
>>Second, I guess that by "industry", you mean just the PC and common PC
>>peripherals industry.
>
>
> Actually, I had the problem with the word "standard". After dealing
> with serial devices for over 20 years, that is one word I never use
> when it comes to RS-232.
Ok, yes, there are indeed many different options to be aware of when
using RS-232. It's very "flexible", and that flexibility can be a
disadvantage. You have to make sure that the two devices "talking" to
each other agree on a variety of options, and furthermore, if it's not a
direct connection, you have to be careful that anything relaying data
can handle whatever goes through without mangling it. I'm sure that
we've all had some very frustrating experiences using RS-232. But,
especially for direct connections, it's not overwhelming; there are a
limited number of things that could be going wrong. If one or both
devices are capable of being configured to use different options, a
successful connection is usually possible.
But just how standard is USB? It looks to me as if each client device
needs its own driver on each host that it connects to. That's not my
idea of "standard".
--
Regards,
James
Dave Baum
"James M. Prange" <jmpr...@i-is.com> wrote:
> Pete M. Wilson wrote:
> > "James M. Prange" <jmpr...@i-is.com> wrote:
> >
> > Actually, I had the problem with the word "standard". After dealing
> > with serial devices for over 20 years, that is one word I never use
> > when it comes to RS-232.
>
> Ok, yes, there are indeed many different options to be aware of when
> using RS-232. It's very "flexible", and that flexibility can be a
> disadvantage. You have to make sure that the two devices "talking" to
> each other agree on a variety of options, and furthermore, if it's not a
> direct connection, you have to be careful that anything relaying data
> can handle whatever goes through without mangling it. I'm sure that
> we've all had some very frustrating experiences using RS-232. But,
> especially for direct connections, it's not overwhelming; there are a
> limited number of things that could be going wrong. If one or both
> devices are capable of being configured to use different options, a
> successful connection is usually possible.
It sounds like you are talking about things like baud rate, stop bits,
parity, control flow, etc. Getting the settings right is only half of
the battle, though.
When I read James' post, I was thinking more along the lines of
compatability at the electrical level. Lots of devices cut some corners
in their "RS-232" drivers/receivers. Usually it is done to save a
little cost, sometimes because the designer didn't really understand
RS-232 well enough. Either way, the devices typically work with *most*
other devices, but then you'll run into a combination where both sides
took shortcuts that conflict with one another. I believe a previous HP
calculator (49G?) had problems like this with older Macintoshes.
I saw one very odd case where two devices couldn't communicate, but then
if the cable was made 3' longer everything worked fine.
None of this is a problem with the RS-232 specification itself, but
rather with the large collections of devices which are assumed to be
RS-232, but don't really meet the full spec.
Dave
Pete M. Wilson
I don't think that is a fair criticism of USB. If I plug in any RS-232
device to a host, how well will it work without software? It is true
that many USB devices have special drivers, but that is because of the
nature of the device, or sometimes the poor implementation of their
USB service. New digital cameras that use direct USB connection are an
example of USB done right - they act just like a USB hard drive, and
that makes sense considering the typical use of the connection. If the
only purpose of the 49g+ interface was to send and receive files,
there is no reason hp couldn't have implemented it as a USB disk drive
and not required any driver.
Cyrille de Brébisson
> >But just how standard is USB? It looks to me as if each client device
> >needs its own driver on each host that it connects to. That's not my
> >idea of "standard".
>
> I don't think that is a fair criticism of USB. If I plug in any RS-232
> device to a host, how well will it work without software? It is true
> that many USB devices have special drivers, but that is because of the
> nature of the device, or sometimes the poor implementation of their
> USB service. New digital cameras that use direct USB connection are an
> example of USB done right - they act just like a USB hard drive, and
> that makes sense considering the typical use of the connection. If the
> only purpose of the 49g+ interface was to send and receive files,
> there is no reason hp couldn't have implemented it as a USB disk drive
> and not required any driver.
This would be a good idea, if it was (easely) feaseable...
Let me explain USB drive use a sector type of interface. ie: the pc asked
for sector n of the "hard drive" and the sector is transfered to it, exactly
as on an IDE drive.
The PC then handles the files as a file system
now, for a digital camera, no problem, they have a SD card, or similar in
them and they send the sector requested by the PC from the SD card.
on a hp calcualtor, there is a file system, yes, but it is COMPLETLY
different from the PC file system. what would the calcualtor do when the pc
request sector 0 (partition table)? well, it could, on the fly create a fony
sector and send it to the pc... what does the calcualtor do when the pc
require the FAT? well, same thing...
up to here, all is good....
now, what happen when the PC read files? no problem again (I mean appart
from the implementation that is starting to get tricky), it can generate
something that looks like a hard drive from the internal file system...
now, the PC starts to send writing orders on sectors for the calculator...
what does the calculator do with them? well, this starts to get dificult,
because these sectors are not linked with any file, and the calc does not
know about sectors, only of files... well, let us save them (how many will
we save? who knows)....
anyway, at one point in time, the PC sends modifications to the FAT and the
root directory, the calc can now go back on all the data received, make
sense of it and transform everything back in calc files! ouf... (this
include for example a file open for read/write and modified in the middle,
files moved from A to B, directory changed (remember, on the calc, a
directory is also a file... how does the PC deal with that)....)
mind you, in this scenaro, how does the calc manage memory? oups... because
as it need memory to work, but also needs memory that is the "free memory"
on the hard drive... but as a hard drive can not resize itself, this will
not work...
again, what happends when the PC starts a defrag? that can not possibly make
sense for the calcualtor...
what I mean is that the idea is excelent, but unfortunately, not
implementable due to the legacy of the HP48G file system...
regards, cyrille
James M. Prange
> In article <bo972l$tqk$1...@newsreader.mailgate.org>,
> "James M. Prange" <jmpr...@i-is.com> wrote:
>
>
>>Pete M. Wilson wrote:
>> > "James M. Prange" <jmpr...@i-is.com> wrote:
>> >
>> > Actually, I had the problem with the word "standard". After dealing
>> > with serial devices for over 20 years, that is one word I never use
>> > when it comes to RS-232.
>>
>>Ok, yes, there are indeed many different options to be aware of when
>>using RS-232. It's very "flexible", and that flexibility can be a
>>disadvantage. You have to make sure that the two devices "talking" to
>>each other agree on a variety of options, and furthermore, if it's not a
>>direct connection, you have to be careful that anything relaying data
>>can handle whatever goes through without mangling it. I'm sure that
>>we've all had some very frustrating experiences using RS-232. But,
>>especially for direct connections, it's not overwhelming; there are a
>>limited number of things that could be going wrong. If one or both
>>devices are capable of being configured to use different options, a
>>successful connection is usually possible.
> It sounds like you are talking about things like baud rate, stop bits,
> parity, control flow, etc.
Those and signaling on other lines besides transmit and receive data.
Lines which may or may not be present on either device, and may or may
not be required on either.
Of course the various connectors can also be a problem; which pin is
which signal? It helps if you have a manual for the device.
> Getting the settings right is only half of
> the battle, though.
>
> When I read James' post, I was thinking more along the lines of
> compatability at the electrical level. Lots of devices cut some corners
> in their "RS-232" drivers/receivers. Usually it is done to save a
> little cost, sometimes because the designer didn't really understand
> RS-232 well enough. Either way, the devices typically work with *most*
> other devices, but then you'll run into a combination where both sides
> took shortcuts that conflict with one another. I believe a previous HP
> calculator (49G?) had problems like this with older Macintoshes.
I'm aware that it can be a problem, but I've personally only had it
happen to me when trying to use a fairly long cable with a defective
device putting out a very weak (well below RS-232 specifications)
signal.
Well, I have run across some that didn't go negative for the mark
signal, just to 0V, but I was aware that they weren't really RS-232 (the
manuals made that clear) before actually trying to make the connections,
and I knew that level shifters would be needed.
According to the "HP 48 I/O Technical Interfacing Guide", the 48 series'
transmit signal is +/-3.0V minimum, 3.5V typical. And for the received
signal the operating ranges are -15.0V to .03V for a mark, and 1.0V to
15.0V for a space. The absolute maximum allowable voltage for both is
+/-25V.
I believe that the 49G (except for some early defective units) is the
same. Quite possibly those early 49Gs with the "serial port hardware
bug" having trouble with some Macintoshes and perhaps some other devices
are what you heard about.
From what Cyrille posted, I'd guess that the 48gII without the special
cable might be the same, but I wouldn't want to count on it being able
to take +/-25V, or even +/-15V, without anything getting fried; any
volunteers? The special cable, I'd guess, is there to boost the signal
into the recommended range, but could also limit the received voltage.
I don't have copies of the RS-232 standards (they aren't free) but as
far as I can tell, the RS-232 standards specify, for transmitting, -15.0V
to -5.0V for a mark and +5.0V to +15.0V for a space. But for receiving,
-15.0V to -3.0V for a mark, and +3.0V to +15.0V for a space. And
everything should be able to withstand at least +/- 25V.
So those calculators don't meet the recommended standard for transmitted
signal levels, but with any luck (the other device meets or exceeds the
standard for received signals and not much signal loss) it ought to
work, and usually it does.
My Sharp EL-5520 manual says that the output is 4-6V, and warns that it
uses CMOS components, and voltages exceeding the allowable range may
damage it, so I've never tried connecting it directly to a PC. From the
manual for the Sharp CE-137T level converter, it seems that what it
"expects" from the handheld is 0 to +0.5V for a mark and +3.3V to +5.5V
for a space, so I guess that straight from the EL-5520 it's even worse
than the HP calculators; the signal doesn't swing negative for a mark.
For the output from the level converter, it claims -10 to -3V for a mark
and +3 to +5.5V for a space; still not necessarily up to the standard,
but it works for me.
I really don't know which (if any) standard the Macintoshes claim to
support, or whether they meet it.
> I saw one very odd case where two devices couldn't communicate, but then
> if the cable was made 3' longer everything worked fine.
That is strange. My guess is that it wasn't entirely the peak voltage
levels, but perhaps more the pulse shape. Maybe the extra length changed
the cable capacitance just enough to allow it to work. Or if it was a
different cable entirely instead of a matter of adding an extension,
maybe the longer cable actually had less signal loss or distortion.
> None of this is a problem with the RS-232 specification itself, but
> rather with the large collections of devices which are assumed to be
> RS-232, but don't really meet the full spec.
I agree. If the device has a "serial port", then they should say which
(if any) standard it meets. Best if the device actually meets some
standard, but if it doesn't, then they should say so very clearly up
front.
At least the 48SX engineers were well aware of the problem, and did find
a way to make it close enough to work with most RS-232 devices. But I
don't think that the full story ever made it into the Owner's Manual; I
think that it never actually mentions RS-232, but uses the term "serial"
instead. So they didn't actually lie about it, they just let the buyers
assume that "serial" means "RS-232".
As far as I can tell, the special cable for the 48gII is intended to be
a way to get the transmitted data signal into the recommended range.
Certainly that's a worthy goal, but in my opinion a misguided method of
meeting it, even if some PDAs do it that way. Surely electronic devices
have advanced a bit since the 48SX was designed; it would've been better
to put it all into the calculator and draw any power needed from its own
batteries, rather than relying on being able to get power from the other
device. I guess that it's too late now; the 48gII is already in
consumers' hands. Maybe on the next calculator....
--
Regards,
James
Joseph K. Horn
> a TI calculator will work with them.( LabPro)
> I really leaves a bad taste in my mouth not
> to be able to say HP's will work too.
Doesn't the HP48GII offer exactly what you need? If I'm not mistaken,
it has the same RS232 port as the original HP48SX/GX.
-Joe-
Harold A. Climer
wrote:
It might be OK when they get all the bugs worked out.
Unfortunately the GII has no FLASH upgrade capability and also has a
smaller user RAM left after the OS overhead than the GX,,which will
work.( albeit much more slowly than the GII) Of course that might not
make a difference.
You would have to write your own software for the GII to
talk to the interface box, but I do not see that as being too much of
a problem considering all the great 48 programmers that prowl these
regions
Some simple programs have already been written for the Vernier
ULI box which also has an RS-232 port
A Programmer's Reference Manual is available for both the
ULI box and LabPro on Vernier's web site.
Some energetic young lad might even be able to sell them to
Vernier and I would not have that bad taste in my mouth any longer,
Harold A. Climer
Physics/Geology/Astronomy Lab Instructor
U. Tennessee At Chattanooga
Bob Roberts
Unfortunately, they have significantly changed the serial port on the
GII. It no longer works with many (possibly a majority of) RS-232
devices.
Bob
Bob Roberts
Unfortunately, they have significantly changed the serial port on the
James M. Prange
> "James M. Prange" <jmpr...@i-is.com> wrote:
>
>
>>But just how standard is USB? It looks to me as if each client device
>>needs its own driver on each host that it connects to. That's not my
>>idea of "standard".
>
>
> I don't think that is a fair criticism of USB. If I plug in any RS-232
> device to a host, how well will it work without software?
I think that as a general rule, the firmware/software to configure the
serial (RS-232 or similar) port and send or receive data is built into
the device or its operating system. Sort of like a driver, except that I
don't have to add separate firmware/software to connect to a different
device. A terminal emulator works fine for sending and receiving from
the 48 series. Heck, even the DOS COPY command will work. For something
more than transferring a simple short data stream, like a file transfer,
I'll probably want more appropriate software. Sort of like Conn4x,
except that Conn4x seems to be specialized for a few calculators. With
Kermit or Xmodem, for example, I can transfer to and from quite a
variety of devices, as long as they have the matching software
installed.
> It is true
> that many USB devices have special drivers, but that is because of the
> nature of the device, or sometimes the poor implementation of their
> USB service. New digital cameras that use direct USB connection are an
> example of USB done right - they act just like a USB hard drive, and
> that makes sense considering the typical use of the connection. If the
> only purpose of the 49g+ interface was to send and receive files,
> there is no reason hp couldn't have implemented it as a USB disk drive
> and not required any driver.
Well, maybe. I see that Cyrille has already responded to this part. I'm
not sure of all that the USB port is supposed to be able to do. The
documentation leaves a lot to be desired. The Conn4x and USB driver
combination doesn't work on my PC yet, except for updating the flash
ROM. For example, are we supposed to be able to "print" (to a terminal
emulator) via USB? Or use the XMIT and SRECV commands via USB?
--
Regards,
James
James M. Prange
Ok, I'm well aware that the file system inherited from previous
calculators is very different from the file system used on a hard drive
(and the SD card). And the file system inherited from previous
calculators is too well suited to a calculator to discard. I guess
replacing it would mean scrapping RPL too, and I certainly don't want to
ever see that. And I'm aware the the 49g+'s handling of the file system
on the card is, so far, not up to what we'd like,; the inability to
create subdirectories, for a start. But surely the 49g+ isn't totally
ignorant of the SD card's file system either. I mean, it apparently can
and does read to and write from directory entries, the FATs, and the
appropriate clusters, and it can format the card. Obviously it gets
information about the card's format from the boot record, and even
writes to the boot record when it formats a card. I wonder how much
information about the card is kept in the 49g+'s operating system when
it's not actually accessing the card.
Maybe the 49g+ could totally hand control of the card to the PC when
it's accessing the card via USB? Of course, if the 48g+'s operating
system is keeping information about the card in memory, it would have to
be refreshed when control were handed back, but I suppose that this has
to be done any time that a card is inserted anyway.
By the way, I've been turning the 49g+ off when removing or inserting
the card, but wonder whether that's necessary. Is the card supposed to
be "hot-pluggable"?
Just a few stray thoughts, and I'm glad that you guys know more about it
than I do.
--
Regards,
James
Francesc Aguil'o Gost
I read your mail in "comp.sysy.hp48" entitled "Re:HP49G+:strings to
programs". Thank you for that mail. With the "KINVIS" translator I can
write now an hp49g+ program in the PC-Linux, grab it to the SD card,
read it with the hp49g+ and convert it to a RPL program.
Is it possible to get the others translators, I mean "KVISLF", "KVIS",
etc. I would like to do the inverse process: from a RPL program in the
hp49g+ ---> translation ---> SD card --> PC and read the "text" program.
Thank you in advance for your time.
F. Aguilo
James M. Prange
Ok, but note that the programs are based on SYSEVAL sequences to
accomplish the results that the SysRPL commands would give you. SYSEVAL
simply goes to that address and executes whatever is there. If you goof
on the address, or don't have valid arguments on the stack, the
calculator may very well crash and lose memory.
Note that the 49G and 49g+ use a different address from the (old) 48
series.
I don't know about the 48gII. Does anyone know which calculator the
entry points for it match? Or what the VERSION command returns? Or what
a binary transfer header from a 48gII looks like?
I've added code in these programs to do the argument checking, but make
sure that you enter the hex values exactly as shown, and use the BYTES
command to verify that the checksum and size match my results.
These first four are for the 49G or 49g+.
EDITDECOMP$49
%%HP: T(3)A(R)F(.);
@ Argument: Level 1: Any object.
@ Returns: Level 1: Object decompiled to command line editor character
@ string form.
@ Notes: 1: For a character string argument, the result is the string
@ embedded within another string.
@ 2: "Real" numbers are as in STD display format.
@ 3: "Binary" integers use wordsize 64.
@ Checksum: # 7771h
@ Size: 30.5
@ For 49G and 49g+
@ NOT for 48S/SX/G/GX/G+!
\<<
DUP DROP @ Verify that an argument exists.
# 25ECEh SYSEVAL @ EDITDECOMP$ for 49G and 49g+.
\>>
KVIS49
%%HP: T(3)A(R)F(.);
@ Argument: Level 1: A character string.
@ Returns: Level 1: A character string translated as in Kermit ASCII
@ SEND transfers, except that NewLines (LineFeeds) are
@ left as is.
@ Notes: 1: Respects translation mode in IOPAR.
@ 2: If IOPAR doesn't exist in the HOME directory, then creates
@ it with default values.
@ 3: If IOPAR exists but is invalid, then errors out.
@ Checksum: # 8B49h
@ Size: 28.
@ For 49G and 49g+ only
@ NOT for 48S/SX/G/GX/G+!
\<<
\->STR @ Verify that an argument exists and
@ force it to be a string.
# 2F34Eh SYSEVAL @ KVIS for 49G and 49g+.
\>>
KVISLF49
%%HP: T(3)A(R)F(.);
@ Argument: Level 1: A character string.
@ Returns: Level 1: A character string translated as in Kermit ASCII
@ SEND transfers.
@ Notes: 1: Respects translation mode in IOPAR.
@ 2: If IOPAR doesn't exist in the HOME directory, then creates
@ it with default values.
@ 3: If IOPAR exists but is invalid, then errors out.
@ 4: Translates a "bare" NewLine (LineFeed or LF) to a
@ CarriageReturn LineFeed pair, but a CRLF pair is left as is.
@ Checksum: # 2AC1h
@ Size: 28.
@ For 49G and 49g+
@ NOT for 48S/SX/G/GX/G+!
\<<
\->STR @ Verify that an argument exists and
@ force it to be a string.
# 2F34Fh SYSEVAL @ KVISLF for 49G and 49g+.
\>>
KINVIS49
%%HP: T(3)A(R)F(.);
@ Argument: Level 1: A character string.
@ Returns: Level 1: A character string translated as in Kermit ASCII
@ RECV transfers.
@ Notes: 1: Respects translation mode in IOPAR.
@ 2: If IOPAR doesn't exist in the HOME directory, then creates
@ it with default values.
@ 3: If IOPAR exists but is invalid, then errors out.
@ Checksum: # CED2h
@ Size: 30.5
@ For 49G and 49g+
@ NOT for 48S/SX/G/GX/G+!
\<<
\->STR @ Verify that an argument exists and
@ force it to be a string.
# 2F34Dh SYSEVAL @ KINVIS for 49G and 49g+.
+ @ Append any partial code.
\>>
These four are for the (old) 48 series.
EDITDECOMP$48
%%HP: T(3)A(R)F(.);
@ Argument: Level 1: Any object.
@ Returns: Level 1: Object decompiled to command line editor character
@ string form.
@ Notes: 1: For a character string argument, the result is the string
@ embedded within another string.
@ 2: "Real" numbers are as in STD display format.
@ 3: "Binary"integers use wordsize 64.
@ For 48S/SX/G/GX/G+
@ NOT for 49G and 49g+!
@ Checksum: # 4A5Ch
@ Size: 30.5
\<<
DUP DROP @ Verify that an argument exists.
# 15A0Eh SYSEVAL @ EDITDECOMP$ for 48 series.
\>>
KVIS48
%%HP: T(3)A(R)F(.);
@ Argument: Level 1: A character string.
@ Returns: Level 1: A character string translated as in Kermit ASCII
@ SEND transfers, except that NewLines (LineFeeds) are
@ left as is.
@ Notes: 1: Respects translation mode in IOPAR.
@ 2: If IOPAR doesn't exist in the HOME directory, then creates
@ it with default values.
@ 3: If IOPAR exists but is invalid, then errors out.
@ Checksum: # F12h
@ Size: 28
@ For 48S/SX/G/GX/G+
@ NOT for 49G and 49g+!
\<<
\->STR @ Verify that an argument exists and
@ force it to be a string.
# 2FEDDh SYSEVAL @ KVIS for 48 series.
\>>
KVISLF
%%HP: T(3)A(R)F(.);
@ Argument: Level 1: A character string.
@ Returns: Level 1: A character string translated as in Kermit ASCII
@ SEND transfers.
@ Notes: 1: Respects translation mode in IOPAR.
@ 2: If IOPAR doesn't exist in the HOME directory, then creates
@ it with default values.
@ 3: If IOPAR exists but is invalid, then errors out.
@ 4: Translates a "bare" NewLine (LineFeed or LF) to a
@ CarriageReturn LineFeed pair, but a CRLF pair is left as is.
@ Checksum: # D13Ah
@ Size: 28
@ For 48S/SX/G/GX/G+
@ NOT for 49G and 49g+!
\<<
\->STR @ Verify that an argument exists and
@ force it to be a string.
# 2FEC9h SYSEVAL @ KVISLF for 48 series.
\>>
KINVIS48
%%HP: T(3)A(R)F(.);
@ Argument: Level 1: A character string.
@ Returns: Level 1: A character string translated as in Kermit ASCII
@ RECV transfers.
@ Notes: 1: Respects translation mode in IOPAR.
@ 2: If IOPAR doesn't exist in the HOME directory, then creates
@ it with default values.
@ 3: If IOPAR exists but is invalid, then errors out.
@ Checksum: # 5866h
@ Size: 30.5
@ For 48S/SX/G/GX/G+
@ NOT for 49G and 49g+!
\<<
\->STR @ Verify that an argument exists and
@ force it to be a string.
# 3016Bh SYSEVAL @ KINVIS for 48 series.
+ @ Append any partial code.
\>>
> Thank you in advance for your time.
You're welcome.
--
Regards,
James
PoppaCork
stuff?
I wanted to transfer my 49G programs from my PC to my new 49G+ but
encountered the strings issue.
Happily, using your code as listed below these problems are pretty
easily overcome.
> # 25ECEh SYSEVAL @ EDITDECOMP$ for 49G and 49g+.
> # 2F34Eh SYSEVAL @ KVIS for 49G and 49g+.
> # 2F34Fh SYSEVAL @ KVISLF for 49G and 49g+.
> # 2F34Dh SYSEVAL @ KINVIS for 49G and 49g+.
After transfer from PC to 49G+ I edit the string to remove the header
info and the repeated lines (that always appear at the end of the
string??) then return the string to the stack.
To speed things up I then run this conversion program, that uses your
code, but with no checks, though always ensuring the string in on
'level 1' of the stack
<<
# 25ECEh SYSEVAL
# 2F34Eh SYSEVAL
# 2F34Fh SYSEVAL
# 2F34Dh SYSEVAL
DROP STR-> STR->
>>
I then store the code as a program/variable. (The DROP gets rid of an
extra set of quotation marks that appear on the stack.)
As you can see I have no idea what I am doing!!!
Is this dodgey and am I using the SYSEVAL commands correctly?
Certainly they seem to do the trick.
Thanks again for the excellent advice.
Chris McCorkindale
Austrukinfalia... mate
James M. Prange
> Mr James Prange, your a blimmin genius!
Well, thank you, although such praise may put me in danger of getting a
"swelled head". Actually, my head feels swollen enough already due to
recurring sinus problems.
> How do you know all that
> stuff?
Much of this knowledge was gained from (or at least pointed out by) John
H Meyers, who hasn't been active on the newsgroup lately. But various
sources of information on SysRPL programming also show these useful
functions. The SYSEVAL sequences may be considered to be a "quick and
dirty" way of invoking SysRPL commands, which don't have UserRPL names,
within an otherwise UserRPL program. Look around for SysRPL information
at http://www.hpcalc.org/ and http://membres.lycos.fr/ekalin/index.php,
and also search the Google archive of this newsgroup at
http://groups.google.com/advanced_group_search?group=comp.sys.hp48.
> I wanted to transfer my 49G programs from my PC to my new 49G+ but
> encountered the strings issue.
You've left out a lot of information. How were the programs transferred
from the 49G to the PC? Xmodem? Kermit binary mode? Kermit ASCII mode?
And how are you transferring them from the PC to the 49g+? Conn4x? SD
card? IrDA? If IrDA, using Xmodem or Kermit? If Kermit, binary mode or
ASCII mode? Did you do any editing of the programs on the PC?
I'd think that a binary mode transfer from the 49G to the PC, and then
another binary mode transfer from the PC to the 49g+, should work.
> Happily, using your code as listed below these problems are pretty
> easily overcome.
>
>
>> # 25ECEh SYSEVAL @ EDITDECOMP$ for 49G and 49g+.
>> # 2F34Eh SYSEVAL @ KVIS for 49G and 49g+.
>> # 2F34Fh SYSEVAL @ KVISLF for 49G and 49g+.
>> # 2F34Dh SYSEVAL @ KINVIS for 49G and 49g+.
>
>
> After transfer from PC to 49G+ I edit the string to remove the header
> info
An ASCII transfer header that starts with "%%HP: "and ends with ";"? Or
a binary transfer header that starts with "HPHP49-x" (where x is "C",
"B" or "X")? If a binary header, did you also edit out anything
following those first 8 characters?
> and the repeated lines (that always appear at the end of the
> string??) then return the string to the stack.
Perhaps an artefact of Xmodem transfers? Or of Xmodem transfers that
didn't work quite as intended? I usually just use Kermit, so I don't
have much experience with Xmodem.
> To speed things up I then run this conversion program, that uses your
> code, but with no checks, though always ensuring the string in on
> 'level 1' of the stack
Well, if you're certain that you'll never make a mistake, ok. I'd be
more comfortable starting with something that ensures that the first
SYSEVAL sequence gets a proper argument. Of course, once you've done the
initial argument checking, the structure of the program should usually
ensure that the next step gets a proper argument, so you usually won't
have to check arguments again.
> <<
> # 25ECEh SYSEVAL
Okay, you've applied EDITDECOMP$. If it was already a string, then
you've made it a string within a string, and any NULs, quotation marks,
and backslashes within it were decompiled to \00, \", and \\. I really
don't understand the reasoning behind this step.
> # 2F34Eh SYSEVAL
And now you've applied KVIS. Why? What effect this has depends on the
translation mode (from IOPAR); If the translation mode is the default 1,
then it ends up returning whatever it started with.
> # 2F34Fh SYSEVAL
And now KVISLF. Again why?
> # 2F34Dh SYSEVAL
And now KINVIS. Ok, that "undoes" anything that KVISLF may have done,
but if KVIS did anything at all, then that still remains to be undone.
> DROP STR-> STR->
>
> I then store the code as a program/variable. (The DROP gets rid of an
> extra set of quotation marks that appear on the stack.)
There's nothing mysterious about the "extra" set of quotation marks;
KINVIS returns two strings, the second usually, but not necessarily,
empty. The level 1 string contains anything from the end of the argument
string that could be an incomplete translation sequence, such as a CR or
a "\" followed by up to 2 more characters. I'd use + instead of DROP.
The first STR\-> compiles the string made by EDITDECOMP$. The second
STR\-> compiles the string that I guess you started out with.
> As you can see I have no idea what I am doing!!!
It looks to me as if a simple STR\-> (or OBJ\->) in place of that
program would have sufficed.
Assuming that the objects were transferred from the 49G in binary mode,
and the to the 49g+ in binary mode, it could be that Xmodem added some
padding at the end of the last packet which somehow didn't get removed.
Conn4x doesn't work on my PC, and I don't have IrDA on anything except
the 49g+, so I don't have any way to experiment with Xmodem transfers to
the 49g+. Maybe better to use one of the "object fixer" programs written
specifically for this kind of problem. Search on hpcalc.org for "obj
fix" (without the quotes). I guess that one that's written for the 49G
should also work on the 49g+.
> Is this dodgey and am I using the SYSEVAL commands correctly?
Well, the trouble with SYSEVAL is that other than checking that the
level 1 object is indeed a user "binary" integer object, it doesn't do
any argument checking. It just executes whatever is at the address
specified by the level 1 object. If you goof on the address, or have too
few arguments, or the wrong type of arguments, or even the wrong values
for arguments, a SYSEVAL may well cause a crash, quite possibly
corrupting memory beyond recovery. In one way SYSEVAL is more dangerous
than writing SysRPL code; at least with SysRPL, if you're using the
correct entry points table for the calculator, then you'll get the
address compiled correctly. So be careful with them. What happens if you
apply KVISLF, KINVIS, or KVIS without a string argument? Or EDITDECOMP$
without any argument? I don't know, and would as lief not experiment
with such questions.
> Certainly they seem to do the trick.
Well, it looks to me as if you're "spinning your wheels" a bit. Maybe I
don't quite understand your situation, or maybe you've just been lucky,
so far.
If the objects were transferred from the 49G in ASCII mode and then to
the 49g+ in binary mode, I'd suggest the following plan of action.
First use the information in the ASCII transfer header (which begins
with "HP%%: " and ends with ";") to determine how to set up the 49g+.
The T(0|1|2|3), if present, tells you the translation mode; use the
numeric value as the argument to TRANSIO.
The A(D|R|G), if present, tells you the angular mode to be used for
compiling any objects with angular components. Use the letter to
determine whether to use DEG, RAD, or GRAD.
The F(.|,), if present, tells you which of "." or "," is the
fraction mark in the file; be sure that the calculator is set to use
the same fraction mark.
As the file is from a 49G, set the 49g+ to Exact mode to avoid having
any exact integers compiled to real numbers. (If the file were from a
48, it would be best to set the 49g+ to Approximate mode to avoid
compiling reals to exact integers.)
Now edit out the header; get rid of everything from the "HP%%: "
through the first ";". If you care to automate this on the calculator,
\<< DUP ";" POS 1. + OVER SIZE SUB \>> should do the trick.
Now apply KINVIS to undo any Kermit ASCII translations.
Now do either STR\-> or OBJ\-> to compile the source code string
to an object.
Finally, store the object.
> Thanks again for the excellent advice.
You're welcome, but if you're going to rely on my advice at all, then
please do read carefully what I've written, and consider carefully
whether it applies to your situation, and if so, just how it applies.
Yes, I know that I tend to be wordy and often get sidetracked onto a
related subject, but I do try to make everything accurate, albeit
perhaps my writing is often a bit tedious. And of course sometimes I'm
just plain wrong or have neglected some important "detail"; maybe I just
forgot or maybe it's just something that "everybody knows".
--
Regards,
James
James M. Prange
> Hello,
>
>
>
>>during the days of the HP41 series? HP-IL etc.
>>The kulge with the cable for the 48gII. One now can not just build
>>their own ant longer. Are they going to come out with an expensive HP
>>only accessory to accomplish what is missing?
>
>
> Actually, this is a pretty common practice (the 2 PDA I have with RS232
> cable do that)
>
> All CPU and similar that you can see around and that claim to 'support'
> RS232 in fact support the protocol, but not the signal strenght (they work
> in 0/3.3 v only, which is not a normal RS232 level, but much easier to
> acheive on a 3.3V powered IC.
Back when I first read this, I thought it meant about +3.3V for a
"space" and -3.3V for a "mark", similar to the "RS-232 compatible"
transmit levels in the "old" 48 series. But perhaps it really means
about +3.3V for a space and 0V for a mark (or vice versa)? For
example, with my Sharp, it seems that +3.3 to +5.5V is a space, and 0
to +0.5V is a mark, unless I use a level shifter.
And what about the signals going into the 48gII? Are they restricted
to about 0V to +3.3V? Or can it take the maximum -25V to +25V from an
RS-232 device like the 48 series can?
> Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable
> and powering it from the PC is common practice (this is BTW the way your
> mouse gets powered) and saves a lot of power from the device.
> Also, doing so allows to reduce risks of destruction of the final device
> (cable is cheaper than the calc).
>
> BTW, you should be able to connect 2 calcs with the RS232 using a hand made
> cable without any electronics in it. You might even discover that you can
> connect with a lot of devices without the "adaptor" circuitry... However,
> this is not the RS232 standard.
Does that include connecting a 48gII to the "old" 48 series? Or just
between two 48gII calculators?
<snip>
--
Regards,
James