You can DIY an interface for the Propeller for RS232. Enclosed are two alternative schematics.
One example uses transistors and includes a wired Reset to download SPIN binaries, but it can also be use via just Tx and Rx for Forth communications. I favor this one.
The other example just uses diodes to protect the Propeller and a resistor.
Regarding the calculators....
It seems OPENIO will start up the Genericl character-by-character RS232 on all the HP 48, 49, and 50 serial. Then an XMIT will send whatever you have written to the stack. Reception sits in a buffer until you get it (up to 255 characters). You may have to automate sending it to a display screen.
I have a bit of difficulty with understanding how you are going to send special characters (the Linefeed and Carriage return) that Forth requires.
And my usual 'Cut and Paste' approach for loading Forth programs would require a special HP calculator work around.
If you get a mating DB9 connector (that fits into the DB9 on your cable) and just wire Pin2 to Pin3, you have a loopback device.
You should be able to then use OPENIO to send a test string (say "Hello World") and you should be be able to locate it in the HP receive buffer ... regardless of what the serial settings are at. Just make sure the FLAGs are not set for IR communications.
It helps to turn off XON/XOFF flow control. These have always been known to create problems as the device receiving the XOFF or XON may be too slow to respond properly.. characters get lost.
And this method avoids use of Kermit or Xmodem, which are two more sophisticated serial communications layers that PropForth doesn't support.
++++
Yes, the sound card Oscilloscope is of very limited use. I use mine to decode IR remote control devices.
In hp User RPL, 13 CHR 10 CHR + puts carriage return linefeed on the stack where it can be appended to any string on the stack with "+". This bit of code creates a program ( callable by other programs ) to automate it:
\<< 13 CHR 10 CHR + \>> 'CRLF' STO. The "\<<" and "\>>" symbols stand in for the hp tokens that enclose stored code.
To make it more convenient for calling it could be:
\<< 13 CHR 10 CHR + SWAP + \>>
Then the calling program would place the string to be transmitted on the stack, call CRLF and bingo the string is ready for XMIT. :-)
@Art
Terrific. That pretty much makes the XMIT side of Forth communications done. It looks as though the serial port on the HP50g is full duplex.
Only moving responses from the receive buffer to the screen is left to manage. I still have a long wait for a serial cable, and the vendor could even just return my check and leave the order unfilled. But I am keeping my hopes up.
++++++++++++
If you grow weary of the tangle of 3.3v level shifters, using the resistor and diode solution to protect the Propeller is not a bad alternative. It works... it just may be a bit restricted on the Baud rate.
Well, well, well . . . I have done a lot of experiments and testing and finally found why I was being stumped with connecting to my hp48 via serial communication. I started to break through when I discovered that dlrS_baud in EEpromKernel.spin must be set to 1/4 of the baud rate used in TerraTerm. I didn't discover this by reading GettingStartedPropForth.txt ( although I had read that weeks ago ) but by experimentation. After confirming my discovery by numerous tests I began to wonder if the same was true for the "serial" word in PropForth so I tried it. Gave this command
c" 27 26 2_400 serial" 1 cogx \ set pin 27-tx, pin 26-rx at 9600 baud in cog1
and bingo my test code worked flawlessly - at least for output to the calculator. As I write this I still need to write code to test for input from the calculator but it is indeed time to say YEEEHAW!
Is the GettingStarted text file really the only place this information is available!! What is wrong with this picture? This has cost me a lot of time and some money . . . however, on the plus side it has reawakened my old hardnose troubleshooting side. I'm sure that will be convenient.
However:
"Gratitude is riches and complaint is poverty and the worst I ever had was wonderful". - Brother Dave Gardner
PropForth really needs to revise BOTH there documentation and their code on how to set their Baud rate.
Somewhere along the way, they tweaked the code to run faster baud rates; but made it unclear what the number meant.
I'd forgotten about the oddity. Just the kind of thing a new user will struggle with.
+++++
When using OPENIO, smooth reception seems to require you first to a read of the Buffer length (amount of bytes in the buffer) before you do a SRECV to get it too display.
And the WORDS listing in PropForth will likely crash as the HP50g boffer is only 255 bytes. Display of contiuous serial data from the Propeller to the HP50g requires a loop that is clearing the receive buffer frequently as well.
@Loopy
I do have the new user point of view which helps me see the "haze" more clearly.
I should clarify what my goals are for this conversation. I am not trying to create a full terminal function with the hp48. My project is to make a controller that will read temperature sensors, switch relays based on the readings and stored parameters received from the user, and finally report data and status to the user. The calculator is to be the user interface. It will accept operational parameters from the user and transmit them for storage and action by the Prop. The calculator will also download data and status from the Prop as required by the user. I have done all this before on a much more complicated Forth board by New Micros Inc. but it was years ago and I am having some restart pains but the excitement is taking care of that.
The Propeller is ideal and PropForth is awesome! Thanks to everyone for making and maintaining this for me to discover. I should correct myself on several points. The Prop is actually more complex than the NMI system but in a good way. And I haven't done it all before but the interaction between the hp48 and the Forth system should be basically similar to that between my PC-XT and the earlier board. Also on that system I had to engineer ( using the term loosely ) an analog processing section for the sensors and custom interfaces for relay switching, ADC chip, LCD display, and a ridiculous power supply. It all worked very well for a long time but I destroyed it by redesigning the power supply just before leaving for a 30 day vacation. And it had always needed a better user interface.
Yes, I know I'm building a kludge. It is my dream to do so. Here is the idea. The DMM for reading the sensors will read them directly in microamps. The AD590 sensors operate in the current mode measuring temperature at one degree Kelvin / microamp. They are connected with two wires and are not fussy about supply voltage ( the spec is 3 to 15 volts ) or reasonably long runs. They must be strobed to prevent self heating. Three volts, strobing - sounds like a cog to me. In this arrangement I don't have to do ANY analog engineering. For relay switching I will use the X10 powerline signal system. There are better systems but X10 is ( or was ) cheap and using an XTB powerline modem by JV Digital Engineering ( jvde.us ) is a big improvement over the original and besides I am already using it with irrigation relays for garden watering at night using the calculator to manage the schedule automatically.
This is a kludge but it is also modular. The hp48 is an amazing machine but it is also obsolete - it can easily be replaced by the hp50 ( there are great emulators of both available for Android devices. The X10 system can be easily replaced by something better as can the Protek 506 DMM I am using. It is all off the shelf.
I have always wanted to use a calculator for user interface because it is an extremely low power interface device and that is what my homemade solar heating system is all about. When the hp48 came out in 1990 it got my pulse racing but I couldn't afford to buy one then and "life" didn't favor the effort required to make it work. Besides the Propeller was still in the future. About 5 pawn shop hp48 calculators later I was frustrated because I could not devise a reasonable way to use one to connect all these parts with only one serial port. I eventually built a multi-serial port switcher using a 74HC4052 analog multiplexer but the calculator had no output port pins to switch the channels and none to strobe the sensors. I will skip the other things I tried - a kludge is okay but I have my limits. Then along came the Propeller and best of all PropForth. The only question then is did I have the guts for it.
So that is what I am up to Loopy. Wish me luck and stay tuned. I'm sure I will have more questions. :thumb:
The only thiing that I have doubts about is X10. That communicates over AC mains at the crossing points. It certainly was an attractive idea, but a bit noisy and blocked by transformers while not isolating to one's residence (neighbors could hack in).
I would consider RS422 full duplex in two twisted pairs. It can go for 1000 feet easily and is very low power. The extra wire is reasonably cheap. And your ends don't have to have an AC household plug to have communications.
The BasicStamp2 does support x10. I am not too sure if the Propeller does. You miight take a look at the OBEX listings for it.
What's to criticize? It is your design and if it serves you well, it is just fine. And there is always a chance for improvement later with the additional knowledge gained.
... I discovered that dlrS_baud in EEpromKernel.spin must be set to 1/4 of the baud rate used in TerraTerm. ...didn't.... GettingStartedPropForth.txt .... true for the "serial" word
What is wrong with this picture?
Excellent, you have discovered a problem, and discovered the answer. Will you help us fix this how you'd like it to be?
All documentation and changes are driven by user input (thats YOU). Could you please open an issue on the google code wiki, describe the issue, and describe how you would like it fixed?
For example, where was the FIRST place you looked, where would you have expected it to be? Sal expects everyone to start with propforth.spin (now devkernel.spin etc), since that's where he would start. (and it used to be there in the comments). But he realizes that folks are different, and has given me permission to change stuff according to use input.
If you can suggest a better way to convey this and any other information, I'll do my best to make the change. I'm at work now, and will probably forget this message as soon as I blink, but if it gets captured in an issue Sal will look at it and we will fix it as possible.
Regarding the X10...
The Propeller has a .spin object in the OBEX for a PSC05 X10 interface. While that is NOT Forth code, it may be a way to bench test X10 hardware connected to the Propeller so that you can be sure the hardwire is right before fooling around with generating the right Forth code.
I need to take a look at what is available locally for X10. I know the local B&Q sells some stuff, but I have ignored takes a serious look at what they have.
Bedtime right now but I will work on a submission soon.
I just finished testing 3 serial ports for the calculator, DMM, and PLM. The PLM is 4800 baud and the XTB-PLM is 1200 (!) - I tested using the calculator as a standin for the target gear at those speeds. All worked fine. It was kinda funny sending c" 23 22 300 serial" 1 cogx .
I have been using the X10 stuff for several years with the calculator as the controller so I am pretty confident about that. I am using an XTB modem as a replacement for the crapped out CM-11a which is the usual equipment. The XTB is much better designed by JV Development Engineering. Home page: jvde.us.
I have also wrung out the Protek 506 DMM pretty good using my netbook and then confirming operation with the calculator. More work to do there I am sure. The 506 is kind of old but it uses the serial port with actual numeric data. I also have a Protek 608 which is newer but the serial data is designed to interface easily with a graphic representation of the meter on a PC. Extracting actual numbers is heavily weird. I have figured out how to do it but it is very processing intensive.
Oh yeah, the X10 folks are actually out of business but I have a lot of their relays so I am going ahead with it. Future iterations if any would probably do it another way.
Locally, the B&Q has a big selection of X10 products.. when all your homes are concrete, it becomes a very attractive remodel solution.
If you neighbors are not into X10 as well, you privacy by default. That works.
++++++++++++++++++++++
I am still waiting for my HP50g cable, but you really have opened up quite a few interesting possiblities for the Propeller to accessorize the HP50g.
You already have a graphic calculator with a huge maths library and an SDcard slot. The Propeller can do a lot of odd jobs with interfacing and control, while the calculator does the number crunching and data logging. It is an excellent fit.
I just came across code that allows the Propeller to act as a USB host. And since the HP50c is only a USB client, it could be a useful alternative communication channel. I am just not sure if you can shut out Kermit and use OPENIO on the USB port. And the calculator will also operate without batteries when plugged in as a USB client. I am not sure how handy that is. The Propeller has to provide the power.
Glad 2 hear it! I have always thought this had the potential to create interest. You know there are a number of folks who do some really crazy things with these calculators. Maybe we can suck some of them in on this. I stick mostly to user code with a few calls to User RPL when necessary. There are folks who get heavy with assembly code on the Saturn. Probably one of them wrote the USB host thing you mention.
Speaking of which, that is a cool thing. Almost a year ago I bought a USB to 4 x RS-232 unit from EasySYNC Ltd http://www.easysync-ltd.com/product/534/usb2-h-1004.html. I was hoping to connect my Android tablet to the USB end through an adapter so that I could use the hp48 emulator on the tablet with 4 serial ports. Well, the dang emulator doesn't link its serial commands to the USB port of the tablet. But it sure runs faster than the real thing and the display is to die for. EasySYNC sure has a cool line of stuff for reasonable prices though.
Oh yeah, the X10 folks are actually out of business but I have a lot of their relays so I am going ahead with it. Future iterations if any would probably do it another way.
Wonders never cease. It seems two days ago I came down with chicken pox. So I am not trying to respond to threads in any detail... Slowly getting better, but have these blood red/purplish spots all over.
Wonders never cease. It seems two days ago I came down with chicken pox. So I am not trying to respond to threads in any detail... Slowly getting better, but have these blood red/purplish spots all over.
Wow, George!! Sorry to hear about the chicken pox. I wonder if the Asian strain is different enough from the US version or did you not have them as a kid?
Wow, George!! Sorry to hear about the chicken pox. I wonder if the Asian strain is different enough from the US version or did you not have them as a kid?
Anyway, take it easy and get better!
Hard to say. more than 5 years ago I went to Thailand for three weeks and when i got back here, a small nick turned septic. Had a six day stay in the local hospital.
I had taken all sorts of precautions- anti-malaria, typhus, japanese enecphalitus, dyptheria, and tetnus. But it seems there is something lurking in the mud of the river banks near Laos and Burma.
Travel is just no fun without a bit drama. I could have gone without Thailand declaring marshall law for a week in Chang Mai, or some aggitators taking out ATM with grenade launchers.
That sounds nasty. Hope you're better soon. Are you sure it isn't shingles? They are related and that is for sure something you want good treatment for and fast. Had a couple of brushes with it myself and got it stopped quickly . . . luckily.
Well, I am a bit more stable, but the doctors are not sure what i have specifically.. just a virus. I will know more in a week. Still haven't gottten the HP50g cable.
Today I might go out for decent meal. It doesn't really matter what you have challenging you if you can just enjoy life.
:cool:
Wow. Alot of hard work and success on this thread about adapting hp calculators to parallax products.:blank: I would
like to know how to connection the Hp serial to the stamp , via the hp code, myself.
Wow yourself, robo. You're in Raleigh! I worked night shift at "Dix Hill" when I was in school at the seminary in Wake Forest it '63-65. Later lived with buddies in Lake Wheeler Mobile Estates ;-)
How deep are you into coding on the hp48? So I know to help.
If you are just starting a good thing to do is get another calculator ( I got mine in pawn shops ) and experiment with them via the infrared port. It works the same as wire but without cable. You can play around having one send and the other receive to get the idea. It makes things simple in terms of compatibility and parameter settings.
If you don't want to do that using a terminal program on a computer is just as good if not quite as easy.
I tried to load Tachyon tonight without success. Get garbage in Terraterm after loading the 2.3 kernel in the PropTool. I am kind of excited about it and want to get going but gonna hit the sack now.
Should I start another thread, like "Beginning Tachyon"?
I strongly suspect the garbage is due to TeraTern baud rate not being right. There is a good download file, but display comes up from reset with trash.
I tried to load Tachyon tonight without success. Get garbage in Terraterm after loading the 2.3 kernel in the PropTool. I am kind of excited about it and want to get going but gonna hit the sack now.
Should I start another thread, like "Beginning Tachyon"?
You probably want to make a dofferent thread, Peter J is the author, abd Tachyeon has many design differences from Propforth. Peter uses Tachyeon for different purposes than Sal uses Propforth (and Dave uses pfth for different purposes than both i imagine) so you want to keep these investiagtion separate. Just as you would keep Catalina separate from gcc/simpleIDE.
In any case, Loopy is good source for either, but Peter is the "horse's mouth" for Tachyeon
Comments
One example uses transistors and includes a wired Reset to download SPIN binaries, but it can also be use via just Tx and Rx for Forth communications. I favor this one.
The other example just uses diodes to protect the Propeller and a resistor.
Regarding the calculators....
It seems OPENIO will start up the Genericl character-by-character RS232 on all the HP 48, 49, and 50 serial. Then an XMIT will send whatever you have written to the stack. Reception sits in a buffer until you get it (up to 255 characters). You may have to automate sending it to a display screen.
I have a bit of difficulty with understanding how you are going to send special characters (the Linefeed and Carriage return) that Forth requires.
And my usual 'Cut and Paste' approach for loading Forth programs would require a special HP calculator work around.
If you get a mating DB9 connector (that fits into the DB9 on your cable) and just wire Pin2 to Pin3, you have a loopback device.
You should be able to then use OPENIO to send a test string (say "Hello World") and you should be be able to locate it in the HP receive buffer ... regardless of what the serial settings are at. Just make sure the FLAGs are not set for IR communications.
It helps to turn off XON/XOFF flow control. These have always been known to create problems as the device receiving the XOFF or XON may be too slow to respond properly.. characters get lost.
And this method avoids use of Kermit or Xmodem, which are two more sophisticated serial communications layers that PropForth doesn't support.
++++
Yes, the sound card Oscilloscope is of very limited use. I use mine to decode IR remote control devices.
\<< 13 CHR 10 CHR + \>> 'CRLF' STO. The "\<<" and "\>>" symbols stand in for the hp tokens that enclose stored code.
To make it more convenient for calling it could be:
\<< 13 CHR 10 CHR + SWAP + \>>
Then the calling program would place the string to be transmitted on the stack, call CRLF and bingo the string is ready for XMIT. :-)
Terrific. That pretty much makes the XMIT side of Forth communications done. It looks as though the serial port on the HP50g is full duplex.
Only moving responses from the receive buffer to the screen is left to manage. I still have a long wait for a serial cable, and the vendor could even just return my check and leave the order unfilled. But I am keeping my hopes up.
++++++++++++
If you grow weary of the tangle of 3.3v level shifters, using the resistor and diode solution to protect the Propeller is not a bad alternative. It works... it just may be a bit restricted on the Baud rate.
c" 27 26 2_400 serial" 1 cogx \ set pin 27-tx, pin 26-rx at 9600 baud in cog1
and bingo my test code worked flawlessly - at least for output to the calculator. As I write this I still need to write code to test for input from the calculator but it is indeed time to say YEEEHAW!
Is the GettingStarted text file really the only place this information is available!! What is wrong with this picture? This has cost me a lot of time and some money . . . however, on the plus side it has reawakened my old hardnose troubleshooting side. I'm sure that will be convenient.
However:
"Gratitude is riches and complaint is poverty and the worst I ever had was wonderful". - Brother Dave Gardner
I am happy you got this sorted out.
PropForth really needs to revise BOTH there documentation and their code on how to set their Baud rate.
Somewhere along the way, they tweaked the code to run faster baud rates; but made it unclear what the number meant.
I'd forgotten about the oddity. Just the kind of thing a new user will struggle with.
+++++
When using OPENIO, smooth reception seems to require you first to a read of the Buffer length (amount of bytes in the buffer) before you do a SRECV to get it too display.
And the WORDS listing in PropForth will likely crash as the HP50g boffer is only 255 bytes. Display of contiuous serial data from the Propeller to the HP50g requires a loop that is clearing the receive buffer frequently as well.
IOW, there are some limits.
I do have the new user point of view which helps me see the "haze" more clearly.
I should clarify what my goals are for this conversation. I am not trying to create a full terminal function with the hp48. My project is to make a controller that will read temperature sensors, switch relays based on the readings and stored parameters received from the user, and finally report data and status to the user. The calculator is to be the user interface. It will accept operational parameters from the user and transmit them for storage and action by the Prop. The calculator will also download data and status from the Prop as required by the user. I have done all this before on a much more complicated Forth board by New Micros Inc. but it was years ago and I am having some restart pains but the excitement is taking care of that.
The Propeller is ideal and PropForth is awesome! Thanks to everyone for making and maintaining this for me to discover. I should correct myself on several points. The Prop is actually more complex than the NMI system but in a good way. And I haven't done it all before but the interaction between the hp48 and the Forth system should be basically similar to that between my PC-XT and the earlier board. Also on that system I had to engineer ( using the term loosely ) an analog processing section for the sensors and custom interfaces for relay switching, ADC chip, LCD display, and a ridiculous power supply. It all worked very well for a long time but I destroyed it by redesigning the power supply just before leaving for a 30 day vacation. And it had always needed a better user interface.
Yes, I know I'm building a kludge. It is my dream to do so. Here is the idea. The DMM for reading the sensors will read them directly in microamps. The AD590 sensors operate in the current mode measuring temperature at one degree Kelvin / microamp. They are connected with two wires and are not fussy about supply voltage ( the spec is 3 to 15 volts ) or reasonably long runs. They must be strobed to prevent self heating. Three volts, strobing - sounds like a cog to me. In this arrangement I don't have to do ANY analog engineering. For relay switching I will use the X10 powerline signal system. There are better systems but X10 is ( or was ) cheap and using an XTB powerline modem by JV Digital Engineering ( jvde.us ) is a big improvement over the original and besides I am already using it with irrigation relays for garden watering at night using the calculator to manage the schedule automatically.
This is a kludge but it is also modular. The hp48 is an amazing machine but it is also obsolete - it can easily be replaced by the hp50 ( there are great emulators of both available for Android devices. The X10 system can be easily replaced by something better as can the Protek 506 DMM I am using. It is all off the shelf.
I have always wanted to use a calculator for user interface because it is an extremely low power interface device and that is what my homemade solar heating system is all about. When the hp48 came out in 1990 it got my pulse racing but I couldn't afford to buy one then and "life" didn't favor the effort required to make it work. Besides the Propeller was still in the future. About 5 pawn shop hp48 calculators later I was frustrated because I could not devise a reasonable way to use one to connect all these parts with only one serial port. I eventually built a multi-serial port switcher using a 74HC4052 analog multiplexer but the calculator had no output port pins to switch the channels and none to strobe the sensors. I will skip the other things I tried - a kludge is okay but I have my limits. Then along came the Propeller and best of all PropForth. The only question then is did I have the guts for it.
So that is what I am up to Loopy. Wish me luck and stay tuned. I'm sure I will have more questions. :thumb:
I would consider RS422 full duplex in two twisted pairs. It can go for 1000 feet easily and is very low power. The extra wire is reasonably cheap. And your ends don't have to have an AC household plug to have communications.
The BasicStamp2 does support x10. I am not too sure if the Propeller does. You miight take a look at the OBEX listings for it.
What's to criticize? It is your design and if it serves you well, it is just fine. And there is always a chance for improvement later with the additional knowledge gained.
Excellent, you have discovered a problem, and discovered the answer. Will you help us fix this how you'd like it to be?
All documentation and changes are driven by user input (thats YOU). Could you please open an issue on the google code wiki, describe the issue, and describe how you would like it fixed?
For example, where was the FIRST place you looked, where would you have expected it to be? Sal expects everyone to start with propforth.spin (now devkernel.spin etc), since that's where he would start. (and it used to be there in the comments). But he realizes that folks are different, and has given me permission to change stuff according to use input.
If you can suggest a better way to convey this and any other information, I'll do my best to make the change. I'm at work now, and will probably forget this message as soon as I blink, but if it gets captured in an issue Sal will look at it and we will fix it as possible.
Please open an issue for this.
The Propeller has a .spin object in the OBEX for a PSC05 X10 interface. While that is NOT Forth code, it may be a way to bench test X10 hardware connected to the Propeller so that you can be sure the hardwire is right before fooling around with generating the right Forth code.
I need to take a look at what is available locally for X10. I know the local B&Q sells some stuff, but I have ignored takes a serious look at what they have.
Cheers.
I just finished testing 3 serial ports for the calculator, DMM, and PLM. The PLM is 4800 baud and the XTB-PLM is 1200 (!) - I tested using the calculator as a standin for the target gear at those speeds. All worked fine. It was kinda funny sending c" 23 22 300 serial" 1 cogx .
I have been using the X10 stuff for several years with the calculator as the controller so I am pretty confident about that. I am using an XTB modem as a replacement for the crapped out CM-11a which is the usual equipment. The XTB is much better designed by JV Development Engineering. Home page: jvde.us.
I have also wrung out the Protek 506 DMM pretty good using my netbook and then confirming operation with the calculator. More work to do there I am sure. The 506 is kind of old but it uses the serial port with actual numeric data. I also have a Protek 608 which is newer but the serial data is designed to interface easily with a graphic representation of the meter on a PC. Extracting actual numbers is heavily weird. I have figured out how to do it but it is very processing intensive.
Oh yeah, the X10 folks are actually out of business but I have a lot of their relays so I am going ahead with it. Future iterations if any would probably do it another way.
If you neighbors are not into X10 as well, you privacy by default. That works.
++++++++++++++++++++++
I am still waiting for my HP50g cable, but you really have opened up quite a few interesting possiblities for the Propeller to accessorize the HP50g.
You already have a graphic calculator with a huge maths library and an SDcard slot. The Propeller can do a lot of odd jobs with interfacing and control, while the calculator does the number crunching and data logging. It is an excellent fit.
I just came across code that allows the Propeller to act as a USB host. And since the HP50c is only a USB client, it could be a useful alternative communication channel. I am just not sure if you can shut out Kermit and use OPENIO on the USB port. And the calculator will also operate without batteries when plugged in as a USB client. I am not sure how handy that is. The Propeller has to provide the power.
Speaking of which, that is a cool thing. Almost a year ago I bought a USB to 4 x RS-232 unit from EasySYNC Ltd http://www.easysync-ltd.com/product/534/usb2-h-1004.html. I was hoping to connect my Android tablet to the USB end through an adapter so that I could use the hp48 emulator on the tablet with 4 serial ports. Well, the dang emulator doesn't link its serial commands to the USB port of the tablet. But it sure runs faster than the real thing and the display is to die for. EasySYNC sure has a cool line of stuff for reasonable prices though.
Onward through the fog . . .
Yes BSR went out of business in 1985, but X10 lives on: http://www.x10.com/
http://en.wikipedia.org/wiki/X10_(industry_standard)
Wow, George!! Sorry to hear about the chicken pox. I wonder if the Asian strain is different enough from the US version or did you not have them as a kid?
Anyway, take it easy and get better!
Hard to say. more than 5 years ago I went to Thailand for three weeks and when i got back here, a small nick turned septic. Had a six day stay in the local hospital.
I had taken all sorts of precautions- anti-malaria, typhus, japanese enecphalitus, dyptheria, and tetnus. But it seems there is something lurking in the mud of the river banks near Laos and Burma.
Travel is just no fun without a bit drama. I could have gone without Thailand declaring marshall law for a week in Chang Mai, or some aggitators taking out ATM with grenade launchers.
Today I might go out for decent meal. It doesn't really matter what you have challenging you if you can just enjoy life.
Wow. Alot of hard work and success on this thread about adapting hp calculators to parallax products.:blank: I would
like to know how to connection the Hp serial to the stamp , via the hp code, myself.
How deep are you into coding on the hp48? So I know to help.
If you are just starting a good thing to do is get another calculator ( I got mine in pawn shops ) and experiment with them via the infrared port. It works the same as wire but without cable. You can play around having one send and the other receive to get the idea. It makes things simple in terms of compatibility and parameter settings.
If you don't want to do that using a terminal program on a computer is just as good if not quite as easy.
Let me know where you are so we can start.
Should I start another thread, like "Beginning Tachyon"?
You probably want to make a dofferent thread, Peter J is the author, abd Tachyeon has many design differences from Propforth. Peter uses Tachyeon for different purposes than Sal uses Propforth (and Dave uses pfth for different purposes than both i imagine) so you want to keep these investiagtion separate. Just as you would keep Catalina separate from gcc/simpleIDE.
In any case, Loopy is good source for either, but Peter is the "horse's mouth" for Tachyeon