Yet another HP50g with Parallax products thread.
LoopyByteloose
Posts: 12,537
Several people have shown an interest in making the HP50g their serial terminal of choice for their Propeller or BS2. But most have come daunted by the documentation and menus seeming to direct them toward Xmodem or Kermit, which are both intended for mainly file transfer...
The BS2 doesn't support file transfer at all as it has only 32 bytes of RAM. It is also half-duplex serial and that adds a bit of challenge.
The Propeller has the ability to transfer files, but nobody has yet to develop an Xmodem protocol. A Kermit protocol is likely to be too large.
++++
I have been working on the third alternative -- simple exchanges of ASCII characters.
So far, I haven't had as much sucess as I had hoped for. I did order and waited about six monthis for a RS232 cable to arrive. Upon arrival I may have damaged it by plugging it in upside down (which would provide reverse polarity power to the internal chip IF that is really possible -- I have yet to convince myself that it is hopelessly damaged.)
I had tried Loopback testing with the HP50g and the serial cable, but no luck. Either it is a damaged cable, or the input buffer opened in OPENIO needs further configuration.
So I have moved on and decided to run down more possiblities.
That means that I have been using the serial cable with a Null Modem to try to get Kermit and Xmodem transfers to my notebook computer via Minicom terminal that supports both.
Results???
Well the serial cable is still acting like it is dead.
BUT, I have found that by using the USB port, I get character-by-character XMIT from the HP50g to reach Minicom and display correcty.
But I have yet to have the SRECV work in the opposite direction. BUFLEN requests always come up with an empty input buffer. The input buffer seems to remain empty.
All this is awkward as I am trying to learn and assess possible damage at the same it.
+++++++
Conclusions.........
If you don't understand how to do character-by-character exchanges on the HP50g, it may be best to use a USB interface with a serial terminal program such as Minicom to build some pragmatic skills about what does what.... this can be done without the RS232 interface.
And it might be best to practise all 3 modes --- character-by-character, Xmodem transfers, and Kermit with a regular computer before moving over to the BS2 or Propeller.
That is what I am doing now. As I may have to order a replacement RS232 cable and wait months for it to arrive.
So it seems best that I learn what the software does with what I have before getting all excited about the use of the HP50g as a tiny serial term.
========
There are some odd loose endz about the RS232 serial cable and its history with the HP50g. The HP documents (see the Advanced Users Guide) often mentions the need to set both Flags 33 and 78 to get the RS232 serial port open and running.
But when I go into my listing of flags, I have only Flag 33. It seems that HP removed flag 78 from the installed ROM and have never offer an explanation of what the implicatons of that are.
There are loose ends here that are buried in time and likely to only become more obsuce. The RS232 cable isn't even made by HP any more and has to be ordered from enthusiastic. I get an uncomfortable feeling that my HP50g might not have complete ROM support for RS232, though the Xmodem and Kermit menus do offer 3 alternatives -- IRda, Serial, and USB.
This has all been a tedious backburner project that was started about January 2014... it is already July. To date I have XMIT sending text to my notebook and Xmodem doing a small file transfer to my notebook. But that is about all.
The BS2 doesn't support file transfer at all as it has only 32 bytes of RAM. It is also half-duplex serial and that adds a bit of challenge.
The Propeller has the ability to transfer files, but nobody has yet to develop an Xmodem protocol. A Kermit protocol is likely to be too large.
++++
I have been working on the third alternative -- simple exchanges of ASCII characters.
So far, I haven't had as much sucess as I had hoped for. I did order and waited about six monthis for a RS232 cable to arrive. Upon arrival I may have damaged it by plugging it in upside down (which would provide reverse polarity power to the internal chip IF that is really possible -- I have yet to convince myself that it is hopelessly damaged.)
I had tried Loopback testing with the HP50g and the serial cable, but no luck. Either it is a damaged cable, or the input buffer opened in OPENIO needs further configuration.
So I have moved on and decided to run down more possiblities.
That means that I have been using the serial cable with a Null Modem to try to get Kermit and Xmodem transfers to my notebook computer via Minicom terminal that supports both.
Results???
Well the serial cable is still acting like it is dead.
BUT, I have found that by using the USB port, I get character-by-character XMIT from the HP50g to reach Minicom and display correcty.
But I have yet to have the SRECV work in the opposite direction. BUFLEN requests always come up with an empty input buffer. The input buffer seems to remain empty.
All this is awkward as I am trying to learn and assess possible damage at the same it.
+++++++
Conclusions.........
If you don't understand how to do character-by-character exchanges on the HP50g, it may be best to use a USB interface with a serial terminal program such as Minicom to build some pragmatic skills about what does what.... this can be done without the RS232 interface.
And it might be best to practise all 3 modes --- character-by-character, Xmodem transfers, and Kermit with a regular computer before moving over to the BS2 or Propeller.
That is what I am doing now. As I may have to order a replacement RS232 cable and wait months for it to arrive.
So it seems best that I learn what the software does with what I have before getting all excited about the use of the HP50g as a tiny serial term.
========
There are some odd loose endz about the RS232 serial cable and its history with the HP50g. The HP documents (see the Advanced Users Guide) often mentions the need to set both Flags 33 and 78 to get the RS232 serial port open and running.
But when I go into my listing of flags, I have only Flag 33. It seems that HP removed flag 78 from the installed ROM and have never offer an explanation of what the implicatons of that are.
There are loose ends here that are buried in time and likely to only become more obsuce. The RS232 cable isn't even made by HP any more and has to be ordered from enthusiastic. I get an uncomfortable feeling that my HP50g might not have complete ROM support for RS232, though the Xmodem and Kermit menus do offer 3 alternatives -- IRda, Serial, and USB.
This has all been a tedious backburner project that was started about January 2014... it is already July. To date I have XMIT sending text to my notebook and Xmodem doing a small file transfer to my notebook. But that is about all.
Comments
Oldbitcollector (Jeff @ Propellerpowered) has XMODEM support in his MicroMite Companion project. It works fine loading and saving files from the uMite to the Propeller. So, it is doable and we're currently doing it when we use the uMites. No reason this code couldn't be used to XMODEM with anybody connected to a Propeller.
+++++
My own desire is to use the HP50g in a character-by-character terminal for Forth on the Propeller and maybe something very simple on BS2. But I am a bit frustrated. The calculator itself works fine, but I wonder both if HP screwed up the RS232 on the HP50g or if I have actually damaged something.
So far, I have only communicated in one direction (to the PC) and only via the USB cable. Maybe tomorrow will offer an 'ah ha' moment that will finally having me communicating in both directions.
After than I will more run tests to determine if the RS232 cable or port is broken.
I do admire the tenacity required to connect to some decades old technology. However in this case I'm not sure why. The calculator does not make a good terminal for Forth or any other language as it does not have a full alpha-numeric keyboard.
It's been a few years, but I used to have a copy of Ward Christiansens source code for xmodem. In 8080 asembly nmemonics. I wrote a little terminal program for an old 8085 based CPM 2.2 computer. That was over 30 years ago.
Anywhoo, I have the older HP48 and it only has 64 flags, but to do ascii transfers over the wire requires seting flag 33 (transfer by wire) and flag 35 (Ascii Mode).. Flag 38 automatically adds a LF after CR when its set. All other parameters were stored in the IOPAR var if that helps.
Oh, come now.
Would a wire-wrap angle stimulate your interest?
because I am building a library just for this. Propeller Os, terminal programs, and interfaces are all in question to
assemble the system. I appreciate your project.
Yes, it does have a full alpha-numeric keyboard if you take the time to learn how it works. The punctuation can be a bit tricky to assert, but it is all there.
Flags 33 and 35 are properly set. I am very annoyed that the Flag 78 seems to have been removed.. apparently made redundant, but never explained.
I will try to get OPENIO, BUFLEN, and SRECV resolved today.... but it does seem that I am doing everything right and getting no different results.
The MicroMite Companion looks very attractive. I have to take some time to get up to speed on what it is offering.
Using VERSION, I have found that my ROM is Revision 2.08.
Apparently, there is a Revision 4.02.
So I guess I will buy some new batteries and update the ROM.
SRECV is definitely not working for me, and BUFLEN outputs an empty buffer with an error message "Too Few Arguments".
I find that odd... because BUFLEN should not require any arguments.
It seems there is also a 'HP50g Connectivity Kit' that I have never installed.
http://www.educalc.net/283486.page
Then I rebooted the notebook
Of course, the Windows7 sternly tells me not to turn off the computer or unplug it.
I finally got Windows7 updated, and I downloaded the binary for the ROM update.
EduCalc website has all the important files and info even though they went out of business many years ago.
I had a lot of difficulty with resetting the calculator into a mode that is supposed to load the ROM binary. The user has to hold down the Plus and Minus buttons while putting a paper clip in the Reset hold and hold for quite awhile... says 3 seconds, seems even more is needed. Try 20 or 30 seconds
I was absolutely delighted to see a screen come up with a choice of 1. Self Test and 2. load ROM binary. Just in case, I ran the Self Test for the USB port before loading the binary.
When it doubt, the binary can be transferred to an SDcard and loaded from that, but nothing but a sub-menu option indicates that (where is the documentation?).
In any event, I stayed with the USB port and successfully loaded a new up-to-date ROM Version 2.15 (was version 2.08) and I now know how to get the Self Test menus for Irda, RS232, and USB ports. For a month or so, I have been imagining a damaged port. Now I can really confirm. Preliminary internal Loopbacks of the Irda, RS232, and USB all say OKAY.
So my problem may have been a stale ROM version. I have to work, but maybe tomorrow I will have a clear idea of my RS232 character-by-character transmission.
These details may be helpful if anyone has had similar frustrations with the HP50g RS232. At least the self tests can be of some help.
Not sure why Minicom was working in only the XMIT direction, but I am delighted to see two way communications.
Now it is time to switch over to the RS232 adapter on the HP50g and see if I can get the same.
Putty also supports Kermit and XModem, so I will get some testing of those as well.
Putty seems to be the gateway to start on the solution. I am curious, though, can you use an xmodem transmission
to the computer via USB? I have acquired a Putty version for windows, plus other recommended terminals, and will
try to access the calculator tonight. (
advanced user manual yet.(lost my last one). I did use a crossover cable, and the calculators did talk. Infrared too.
The IOPAR program has to have the right variables before you can send programs,(stop bits, baud, etc)
OK, check this angle out..........
I checked hpcalc.org out, and thinking in retro; Calculators can "talk" to calculators with no problem, right?
SO, what if there was a program to run on the PC, propeller, or beagleboard to make the real calculator "think" it was
talking to another calculator, but was the emulator on your pc? There is such a program provided, and I am in the process
of ferreting out the usability of that.
Making the calculator 'think it is talking to another calculator' is all a bit vague. If you don't understand RS232, USB, IRda, and the Kermit, Xmodem, and character-by-character protocols that the calculator desires -- the rest is never going to get done.
Sooner or later, you are going to have to get down to the nuts and bolts of this or you won't make any real progress.
Tricorders are fantasy devices on Startreck ... nice to dream about, but all I want is to interface with Forth on a Propeller board with a RS232 interface. And that has been a slow plod so far.
++++++++++++++
My own situation is that I don't want to use IRda ... it is too short distance (inches not feet) and requires a lot of overhead at both ends.
So that leaves me with an USB or RS232 interface.
I have pretty much confirmed that I now get Kermit, Xmodem, and character-by-character serial quite well over USB to USB. But the HP50g is a USB slave that requires a USB host. So that really won't work with a Propeller board or a BS2.
Today my efforts turned toward the RS232 port and special cable on the HP50g. So far, I have managed an attempt to Loopback the serial cable with a Kermit Transfer. The transfer failed for some reason, but the serial input buffer did receive an intact failure message in ASCII that was about 22 characters long.
That indicated that my HP50g and the special RS232 serial cable are all good as the message was transmitted went out through the DB9 connector to a Loopback connector and arrived back at the HP50g's serial input buffer.
But I still have some gap in my knowledge of the the system operations that is causing the serial input buffer to not receive a simple XMIT. There may be something in initialization or software flow control that is not well-documented.
Nonetheless, I did get a BUFLEN that worked correctly to indicate the Kermit transmission error message had arrived, AND SRECV worked as it should to move it to the LCD screen.
+++++++++++++++++++
So I am very close to getting full operation. At that point, I can help others that are stumped.
It certainly seems that it was worthwhile to update the EPROM from version 2.08 to version 2.15. The documents are bit confusing as there is another series of references that read in the 4.xx series. But the numbers I am referring to are the ones displayed if you run VERSION on the calculator.
I am now getting good results with EPROM version 2.15 for the HP50g as provided by the EduCalc website (search "HP50g firmware download" via Google to locate this.)
CLOSEIO <enter>
OPENIO <enter>
"TEST TEXT" <enter>
XMIT <enter>
BUFLEN <enter>
DROP <enter>
SRECV <enter>
I did have to add the DROP between the BUFLEN and SRECV to get the whole message length. That is the only new info.
It seems that the update of the EPROM was necessary. All my hardward is good and now the i/o systems appear to be without bugs.
All is well that ends well.
: I have not updated my eprom.(I guess I will have to do that) Since you have this much success, the only thing left is to write a parser program
for the calc to accomodate any traffic that you may want to pass. to TX and RX from the calculator. Maybe ther could be different "modes" that you
would want the parser to do. to accomplish a task, you may want enough bits to make a byte before passin it further.