Got my PalmIII for a while now with my own USB serial and expansion “port”. Surely made things lot easier. Installed one of my fav Pacman clones called Gobble! which is a freeware. But one big gripe that i had was that the game couldn’t be paused! Looking away from the game could result in losing a life point.
While patching PRCs can be done, and i have studied it before, i have not done it for a long time. But this “lack of pause” in Gobble finally pissed me enough to try to do something about it. So i broke open my decompiler and looked for the right place to patch such that i wouldn’t lose a point in some way.
Did some mapping around in assembly and finally found a good place to patch so that if no button is registered, you wouldn’t lose a life point.
Patch locations are 0x908 and 0x90a. Changing the instructions from 0x5350 and 0x544f to 0x4e71 and 0x4e71 respectively.
Some learnings are – BRA = 6000 – NOOP = 4e71 – BLS = 6304 – BHS = 6216?620c?6228?
Effectively, this acts like a “Pause” function where if you don’t press the buttons for a while, and the ghost doesn’t get you in the meantime, you wouldn’t lose a point. Don’t care about how its done? The PRC file is below. It was freeware but i couldn’t find the source to do a clean fix. So here is the patched version.
It really took me a long while before I wrote the post. Partly coz I was really tired after all the mods done to my Palm, but also that after I completed it… I forgot. 🙂
From Part 2 when I last left off, I was really having issues trying to get the Palm to communicate with my Linux system at the full speed. 19200bps was the fastest I could go but I just couldn’t go 115200bps.
Getting all the connections right
After quite a few tries, I finally realised that I not only had to get the Tx/Rx lines correct, which addresses the basics of serial communications in today’s modern systems, but also the traditional lines which is RTS and CTS. My resulting connection diagram is shown below. Once that is sired up correctly, I was able to get connected via the DB9 serial from the Palm to a TTL UART with no issues!
Once the serial port is setup, there isn’t really much else to do on the hardware front. Once it was possible to get to TTL, converting that to USB or directly connection a TTL to a Raspberry Pi using serial is relatively straight forward. Getting all other pieces of communication to work is simply using older instructions of getting the network connection to the Palm using PPP on linux and/or getting Network Hotsync to work.
In addition, this effectively lays the ground of being able to communicate from the Palm to a Raspberry Pi using simple commands sent over a serial port, and then having a simple serial port daemon listening on the Raspberry to execute the received instructions.
Its been a long while since i last completed this set of hardware “surgery” on my PalmIIIxe. i’m really happy that it works, as i now have the software to get my iCal, Contacts all in this traditional handy device. I also have my own USB sync cable for this and have been able to do things like Network Hotsync etc using pilot-link.
I also learnt about a bunch of things on serial connections, TTL and serial communication. Of course, it also brings me back to Palm programming which was really quite a trip down memory lane. I ams also really happy to have this modification not destroy or disfigure my Palm too much. I now have a 10 pin “expansion port” on the back of my unit, but otherwise, everything still works great. i could still install my old games and utilities into it. It also still functions as my desk calculator. It is a little dated, but i could still install Palm apps like games and utilities to make use of it.
The most disappointing coming out of all this effort was that i couldn’t find the right software to be able to receive email on my palm. Writing an email client is out of my league and applications such as Eudora Internet Suite is severely out of date and i just can’t seem to use that successfully anymore; and i didn’t really want to change the configurations of my email service too much.
In conclusion? Modify your PalmIII if you want to make use of it somewhat. Using AAA batteries is great, and i’m talking about battery life that goes for weeks instead of just a day. Don’t expect it to be transformed into a daily companion now though as you will be challenged to find the software or hardware to be able support all the modern goodies we are now so used to such as Wifi. But having no Internet on the device could also be good…
Its nice to get away from modern tech and connectivity sometimes, and return to simpler times.
Getting a good clean signal over the serial port was really important. After a fair bit of use of the acrylic laser cut connect, it was found that it constituted too much trial and error in manually making the connection. So the idea to actually modify the Palm serial port into a connector started to take root. The key idea is to look for a space on the Palm, solder the connector and have that connected permanently on the Palm, so that when required, an add-on board can be used to expand the capability of the unit, instead of mucking around with the 10-pin port.
Opening the Palm, Soldering the pins
Opening the palm was easy. I followed a post from iFixit to get that done. It was then decided to put the pin connectors on the flat portion at the back of the Palm. The PCB at that area was also empty giving me space to work the wires. I used an isolating tape to mask off the areas where the 10-pin was frequently used by external accessories and soldered “backward” the wires that would extend to the connecting pins.
The wires are then routed internally along the edge gaps of the palm and soldered underneath the cover.
On the PCB, insulating tape was also used on the PCB to prevent short circuits just incase the pins were to touch and scratch the board.
All these are then carefully re-assembled, hiding all the wires within the Palm. The end result is a neat package with no visible modifications to the 10-pin port.
The exposed pins shows up on the back, providing a slight improvement in viewing angle when placed flat on a table top. A cover was made to provide some amount of protection to the pins, but I have found that is usually unnecessary.
Upon re-assembly, a functional check was done to ensure that everything is still working…. and it is.. yeah!
Connecting an Expansion Board
The connector pins lines itself up to a 5x7cm DIY PCB. The connection is fairly straightforward and acts as a breakout board for additional functions like the adding a Hotsync button. Jumper wires are used to extend and connect the various pins to additional circuitry making it a lot neater to deal with. Some pictures below to illustrate what was done. Overall, it wasn’t rocket science, but it surely made the connections a lot easier to deal with.
All the above and previous work finally made sure that I was able to have a good way to achieve a “break-out” of the palm pilot pins unto a PCB which I can then work on. This made it a lot simpler to connect things like resistors and other ICs. As noted in Part 1, this kinda fixed issue 3-6. But now I have to begin working on question (3)…. how do I get the baud rate past 19200? And why can’t I get PPP working? All that experimentation would be detailed in another post.
Serial ports are obsolete. So trying to sync the PalmIII to a modern desktop becomes a pain when you need to convert the serial port to a USB. The use of an adapter is to unwieldy to carry about, so the hunt for a PalmIII serial to USB cable begins…. and it ends rather quickly. It is very hard to find, and very expensive. So comes the consideration to make one yourself. Keep in mind that what I wanted to do was to create a cheap Palm to USB serial connector so that I could have PalmOS talk to a linux… for the purpose of… whatever.
On browsing the internet, there is no lack of information when it comes to documenting the PIN outs of the PalmIII serial port. I have reproduced the one that I found the most simple/useful here.
This is just great, as it also seems to coincide with most of what other people have done with their old PalmIIIs, using it as a serial terminal. A lot of the mods out there seem to simply open up the Palm and solder stuff directly to the TX and RX lines and hooking it up to their Raspberry PI or otherwise. I didn’t want to do that as I didn’t want to “destroy” my Palm. I still wanted to be able to use it for games and to bring it around (thats what I wrote all the sync software for isn’t it?). So the goal was to have a way that my palm can interface with a modern linux system, over USB, get on the internet etc, so that I do fun stuff with it, and get continue to get the same goodness of the original Palm for use as a PDA.
This is where I made my first mistake.
Mistake 1: Not understanding Serial
I have mistakenly thought that it is simply enough to connect the TX/RX lines. But it turns out that TTL levels are very different from RS232 on a DB9 connector. The former ranges from 0-5V and the latter can swing from -9V to +9V or more. Even though both are serial ports. Hooking up directly shows gibberish on PocketTerm (by Plushworks), but it definitely shows something. This means that the first thing I had to do was to try and convert the RS232 signal to TTL. Upon digging a little more, I came across a connector for Serial to TTL. So I ordered one to try.
Problem 1: The Palm Serial Connector
In order to be able to create a direct connection from my PalmIII Hotsync Cable to TTL Serial in a small form, and do away with bulky connectors, I had to desolder the DB9, and directly interface my Palm connector to the serial port. Thats where the connection diagram proved useful. However, I didn’t want to destroy my Palm cable by cutting it. So I had to have a sustainable way to re-create the Hotsync connector so I could build things from it in the future. For that, I designed, with some interactions, an acrylic based connector which I can laser cut, then hook up at low cost. Its not fantastic, but it works.
There are a few issues however, that the height of the pins has to be exact. Otherwise the connection to the palm is flaky. So while doing this helped me get past certain roadblocks, using these connectors wasn’t the way I ultimately ended up with. More on that another time.
Hooking things up
Once I had the connector made, with breakout for all the lines, I followed the diagram below and started connecting it to the RS232 to TTL serial adapter. Putting everything on a breadboard, I decided to go a step further and actually put in some LEDs in order to have some visuals when there is traffic flowing or when the port is open.
The sketch below shows how I hooked up only 4 lines to the TTL and had my first successful sync with pilot-xfer. The connecting system is a Cubietruck which has an onboard TTL serial (UART0) which I connected to. The resulting port on the UART is /dev/ttyS0. The testing software used was, on the Palm side PocketTerm, and on the Linux side, Minicom. The settings used to test are documented in the sketch below.
The photo below shows the hardware build and connectivity on the PalmIII side. Notice that I have a breakout board on the Palm end with some LEDs which I subsequently added to help my visually identify the state of the serial connection. So this allows me to quickly identify connection behaviour and problems across the Palm the TTL conversion. I also added some connector pins so that I can use jumper wires to hook things into the breadboard without having to re-solder all the time. Another video below shows the process of a Hotsync…. just some blinking lights there. But I was happy that this was working.
Further testing with login services on Linux
In general, to be able to offer any kind of service over the serial port, it must not be “taken up” by any other service. So I had to ensure that there are no other boot up service that is using it. As I was using a Cubietruck with the Armbian image, I just had to disable the console from the boot environment.
On Cubietruck, Armbian Distribution delete “console” in armbianEnv.txt or change “console=display”
Just to bring it a step further, once I was able to establish a serial connection at 9600 or 19200 Baud to the Linux system, I tried offering login services on the Serial Port. In may posts, I have noticed that folks are trying all sorts of setup to be able to permanently offer a login prompt over serial. However, this is not something that I wish to do. I wanted to be able to (1) know exactly the service that I want to offer, and (2) have control over when I offer it. The following command provides a login prompt over the specific serial port.
On Cubietruck, Disable Serial Console on Boot cd /etc/systemd/system systemctl mask serial-getty@ttyS0.service sync reboot
Once done, you should be able to get to a login prompt when connecting over the serial line.
Problem 2: Maximum Baud Rate of 115200 is Unavailable
While everything works on 19200 on Minicom and PocketTerm, but when it comes to Hotsync, for some reason, I can’t get it to go above 19200 Baud rate. This holds true for Hotsync, but not the Minicom+PocketTerm combination. All research on the internet doesn’t seem to talk about why. This was a head scratcher for me. Every thing I have read seems to only say “4 lines i.e. Vcc, And, Tx, Rx, and it works”. Poking around the settings on the serial port in linux also didn’t seem to help. So while I was happy that I could now perform a Hotsync at 19200, I wasn’t completely happy as I couldn’t use the max rate of 115200.
Problem 3: Trying to Setup PPP from Palm to Linux does not work
Trying to survive on 19200 Baud rate, I tried to setup PPP on my linux system such that I would be able to get a network connection routed from my Palm to the internet via the linux machine. This was working using my bulky Serial to USB adapter, and I wanted to replicate this with my connection. However, this wasn’t the case. Trying to setup a connection continually fails, with the server side being stuck at the following message.
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x7ba91055> <pcomp> <accomp>]
All this seems to indicate something was wrong. It seems that having just Tx and Rx lines being connected isn’t enough. I started to wonder if the RTS and CTS lines needs to be connected as well. And if DTR needed to be connected.
End of Part 1
At this stage, lets review what was accomplished/learnt/questions:- 1) I have managed to get my Palm connected to a UART TTL Serial Port at limited speed 2) A Max3232 logic convertor is required to convert RS232 signals to TTL 3) The base Palm Baud rate seems to be 19200. 4) Connecting with just TX and RX provides connectivity over serial at the base baud rate, but can’t seem to get to the max speed of 115200 for Networking or Hotsync 5) Do we need all 10 pins to be connected as is in the diagram to be able to replicate the functions of the original HotSync cable? 6) We need to have a clean, stable and extensible way of connecting the Palm Serial port to a breakout board for further development
Points 3-5 seems to be interrelated, and in order to solve it, I had to first have my serial connector be reliable as stated in point 6. As noted earlier, my self made connector seems a little flaky when trying to connect to the serial pins. There was therefore a need to change the way I connected to the serial pins before I tried to tackle this.
I think that, point (6), deserves another post. So till my next installation, where I will highlight what I did to improve the connectivity situation to the 10 pins on my Palm.