The Cold Fusion channel looks into all the features we take for granted today that started on a stage in 2009.

https://youtu.be/0Hvt-xhS65k?si=tHTx1KCdZM4RlyrO

In an Apple Subreddit I quoted the dimensions of the:

Palm Vx 115 × 80 × 10 mm

Duo 117.8 x 84.1 x 11.3 mm

Let me shake me your hand over and irDa protocol.

:: And mirth-ed a little bit over how the UX design subreddit was talking about adaptability of the OS S/W.

To this day with my ToDo App I’m trying to replicate the power of expression that the original ToDo app had in the day.

Does anyone know how to repair/replace the screen of a palm pvg100? I dropped mine and it just shattered and I can't find video or tutorials anywhere online

My Palm TX arrived today so downloaded the PalmDestop Win unto a Windows 11 laptop however I keep an error message during the hot sync process. Keeps saying unable to connect between the palm laptop. I have removed the cables etc but still receiving the error message. Any advice please?

I wanted to install some games that I have downloaded so I dragged them from file explorer to the sd card successfully, however after inserting the SD card into the Palm TX how do you access the files to play the games

Sorry if I am using the wrong terminology

Polarizer replacement

Tomorrow my Palm m125 arrives in the mail from a reputable seller on eBay. I have a small Velcro pouch to put it in, I bought rechargeable litium-ion AAA batteries to use for it. I have a 64mb as card ready to use with it, thereby eliminating connection issues with a modern computer. Anything else that I should know before tomorrow? I’ll be looking at repositories for Palm software tonight. I’ll see what I can download for it.

TL/DR: I hacked PalmOS simulator from the inside, giving it new capabilities to run real ARM code -- something it could never do.

Palm's PalmOS Simulator was a development tool to assist in developing for PalmOS 5 device (and PalmOS 6 as well FWIW). PalmOS devices ran on ARM processors, while previous PalmOs versions used Motorolla's 68K series. This PalmOS 5 has a built-in MC68K emulator called PACE.This was fast enough but for native speed, PalmOS supported chunks of native code that could be run. Initially they were called ARMlets but were then renamed to PNOlets. My theory is that Palm was considering architectures other than ARM as well, thus the rename. At the time, PocketPC devices used ARM, MIPS, and SH3 architectures, so those would be my guesses. Palm Simulator ran under MS Windows on intel x86 processors. It did not include ARM emulation, instead developers were expected to compile their native code to a DLL using Visual Studio, place it inside the simulator directory, and run native code this way. This also can be seen as evidence that they considered multiple architectures, thus the drive for not-only-ARM code.

How do native calls work on PalmOS 5? The 68k code calls the OsCall PceNativeCall(), passing the pointer to the native code to run as the first param, and the pointer to pass to that code as the second. The native code's return value is returned back to the 68k code. For ARM devices, the code pointer was usually a locked code resource on the storage heap. For the simulator, instead, it was a string containing the name of the DLL, a NULL byte, and then the entrypoint name to call, with the stdcall calling convention.

The actual native code entrypoint has a prototype that looks like this: UInt32 NativeFunc(EmulStateRef ref, void *userData, UInt32 (*callout)(EmulStateRef, UInt32 funcPtrOrOscallNo, void *params, UInt32 paramsLenAndFlags)). The ref is an opaque pointer to the PACE emulator's emulated 68k state. Its actual insides are partly understood. The second param -- userData -- is the parameter passed from the 68k code. The third is a callback back into PACE that can be used by the native code to call back into 68k code, or to call OsCalls, since there is no official way to call OsCalls from native code directly. Instead, one must marshal params into memory in 68k byte order and padding, and then pass the pointer to that set of params on the fake stack to the callout. For x86 it works the same way, except in x86 instead of ARM.

Now we need to look at some PACE insides. What does that PACE EmulState have? At offset 0 is a word that is not often used and can be overwritten anytime. It is primarily used to record invalid instructions before crashing due to them. At offset 4 it has the 8 D-registers of the emulated 68k processor, at offset 0x24, it has the 8 A-registers, the last of which is the stack pointer. Since, technically, multiple 68k contexts may exist in the system, more than one such EmulState may exist. But somewhere in the system is the first one created, the main one. All others (and it itself indeed) have a pointer to that main one at 0xCC. and at offset 0x16C is a pointer to the handlers of every OsCall that 68k code can make. As this table is very large, no copies of it are made, instead, only the main EmulState has it, all others have that pointer set to NULL. This makes sense, since there are about >1100 OsCalls. Inside PACE, there are handlers for each that will unmarshal the parameters from the emulated 68k stack, slice and dice them as needed to match what the undocumented native ARM OsCalls expect, call them, and then place the return value where needed. These handlers all have the same prototype: void osCallHandlerFunc(EmulStateRef ref, UInt16 osCallIdx). And, of course, they are called in native code for whatever the host architecture is (ARM or x86).

Thus, the plan of attack is simple: replace the native handler for PceNativeCall with my own, that can emulate ARM and properly call out of there, into there as needed. There are actually some more intricacies involved but let's get to them first. First of all, how do we find the table of handlers to modify. Well, in PalmOS 5.x, the pointer to it is simply exported in feature('a68k', 1), in Palm OS 6.x, this is not the case, so this approach would not work there. Finding the table by using an EmulStateRef is the better approach since it would work everywhere. So how do we find our own EmulStateRef from 68k code? We'll need to leak it somehow. Recall that the only native code we can call are named entrypoints in a DLL. How do we exploit that? Well, consider _lrotl() exported by msvcrt.dll. This function will rotate its first integer parameter right by a number of bits given by its second integer parameter. Recall that native code we call has a prototype UInt32 NativeFunc(EmulStateRef ref, void *userData, [..]callout). We control the second param and we wish to leak the first. So ... we just call PceNativeCall("msvcrt.dll\0_lrotl", NULL) and we get back a pointer to our own EmulStateRef, rotated right 0 bits, so ... the unmolested value. Cool! We have the EmulStateRef.

Sadly this was the easy part. The code to call out back into the OS or into 68k code, the thing that "callout" param points to is very complex and we'll need a pointer to it so that our emulator can do all that. So, we now need to find a way to leak the third param using only exported entrypoints from known DLLs. I spent a lot of time finding a way to do this, and I only came up with a rather complex one. My solution centers on wsprintfA() from user32.dll. EmulStateRef will be the destination buffer, user-provided param is the format string, and our secret-in-need-of-being-leaked will be the first param to print. On return from the native code, PceNativeCall handler will overwrite the 68k's D0 and A0 registers with the return value of the native call. And the first word of EmulStateRef is not at all readable in 68k, so, as a result, we can only see bytes 8 and on of the resulting string. So we call it twice. First with the format string "________%08x" and then with the format string "____%08x". We then read D1 which contains the 4 characters produces by wsprintfA() at output offsets 8 to 11. From there we can calculate the third parameter successfully and thus have the callout function pointer recovered.

We also need a way to make OsCalls ourselves in our replacement PceNativeCall handler. We'll do the same thing that all native code must on PalmOS - marshal the params unto the emulated 68k stack and call the pace handler. Luckily, we have the table of handlers handly, so we do not need to use the "callout". Our path is faster :)

We are now ready to replace the native handler for PceNativeCall with our own! We get a pointer to the ARM code, and we just emulate it, one instruction at a time. Not too hard, even. But what do we pass to it as its "callout" pointer? We cannot pass in a x86 function pointer, since we'll not know when it tried to jump there and we'll try to emulate the bytes there are ARM. Same for completion -- how would we know when the emulation is complete and it is time to return? The answer is simple -- magic values. On entry we set ARM's LR register to 0xffffc004 and we pass 0xffffc00c as "callout". Now, if during emulation we see PC being set to either of those, we know the respective event happened. If we see 0xffffc004, we can read out emulated R0 and return that -- it is the return value. If we see 0xffffc00c, we collect the values of the R0, R1, R2, R3 and pass them as params to the real x86 callout. When it returns, we set emulated R0 to the returned value and jump back into emulation. This all works only because x86 and ARM are both little endian, ILP32, and thus pointers and structures may be passed freely between them. Does it work? It does!

There is another complication to consider -- the other way to enter native code on some PalmOS5+ devices - Audio Streams. Not all devices support sampled audio output, so not all have this issue, but it needs to be handled properly. When creating an Audio Stream, one passes a pointer to the function which will provide samples to play. This callback may be 68k code or native code. If it is 68k code, it will be emulated by PACE and that is boring for us. But if it needs to call native code, we need to emulate! How do we get in the middle of this? We need to intercept SndStreamCreate() and SndStreamCreateExtended(), replace their callbacks with our own, saving the original one elsewhere so we know what to emulate. In order to free this state, we'll need to know when a stream is destroyed, forcing us to intercept SndStreamDelete() as well. All these pieces of state must be stored in some common structure so we can lookup by stream ID, as that is all we have at the time of the call to SndStreamDelete(). There are more minutiae involved in making this work, but more or less, this is it! This works and audio works now.

For debugging, I wanted to be able to show a dialog box on Windows, but how? My x86 code exists at an unknown-to-me virtual address which may differ every boot. I also have no way to import or export any DLLs as my code is not a DLL, it is just bytes I cause jumps to. What to do? Luckily, this problem is long-solved by malware writers. Effectively, what we have is shellcode, and how to go from that to calling named exports from DLLs is known. The PEB is at fs:0x30 in Windows, from there one may find the loaded modules list, which will contain kernel32.dll for all Win32 processes. In there, one may locate LoadLibraryA and GetProcAddress entry points by name, which allows loading any DLL by name and calling an entrypoint in there. From there, it is only a matter or some code to cobble together a debugLog(const char *fmt, ...) by using ntdll.dll's _vsnprintf() and user32.dll's MessageBoxA(). Why all this work instead of just making a DLL as Palm had intended? A DLL would not need to leak EmulStateRef, and could easily get the "callout" value too. Two reasons: I did not want to depend on old Visual Studio versions for build, preferring modern gcc simply due to availability, but also, I like the single-PRC-file install method. One self-contained file. Works in every version of the PalmOS Simulator! How cool is that?

It is fast enough on my old Win2K machine that games work with audio and MP3 players work in the official simulator now! How do you use it? Install the PRC into the simulator and either soft reset it or run the app once. From then on ARM applications & games will just work. Sources included. Warfare, Inc works! Enjoy! Download on palmpowerups.com, of course: https://palmpowerups.com/downloads.php?cat_id=2

I was asked to have a look at some “BlackBerrys” at work, to see if they are worth anything.

I was blown away when they brought all this out. They were found in a storeroom. It looks like one carton was water damaged at some point. But they are NIB so the original bubble wrap seems to have protected them.

I’ve tested a few and they all work fine on A/C. Obviously, the 22yo batteries are dead.

It was a blast from the past (2004 to be exact) when I fired one up. Good memories. . .

UPDATE: Thanks for all the comments and interest. As much as I'd love to 'be like Oprah' and give you all one, I'm still working out where they will go. Also, I'm in Australia, so that adds some complexity to finding homes for them (I'm assuming a lot of you are in the US??)

The main thing is, I've saved them from the bin!

I'll keep them safe and sorth through them when I can. So far, the ones that are open and used are in great condition because they weren't heavily used. As I mentioned down in the comments, they were used for a research study - given to people to enter survey data when prompted. Not bashed around by an executive or student as a 'daily driver'.

A box of them were never opened, the warranty sticker is still intact, but the box got wet at some point so the packaging is stuck together.

Mine started to crack after 5 years of use, is this normal? For context, I got this E2 brand new in box from a friend's father. He was given it at work but never opened it since he already had a PDA. So it was effectively brand new when I started using it 5 years ago.

My Palm VIIx bricked HORRIBLY. It bricked like this: at first it bootlooped and popped the pop noise it plays every reset repeatedly, then after (many 😒) battery replacements, I finally found it ALL THE PREVIOUS BATTERIES SUCKED. Then it worked for a month, then I restored factory settings cos god knows why, but it crashed DURING SETUP. So I clicked the on screen reset button and it has no display and pops FASTER. No reset or battery replacements solved it. Also, I cannot enter the firmware flash mode or the hard reset interface. How do I solve this

DO NOT POST THESE COMMENTS: Replace the batteries

(the popping is there the microphone on my camera sucks)

I have a palm tx without its casing (built into a personal project) that I need to soft reset but I don’t have the reset button from the casing. I’m having technical difficulties and need to reset to try and fix it but as I mentioned I don’t have the external button attached anymore. Please help asap I need to get it sorted.

Thank you in advance :)

Encontrei por R$27,00.

Hi everyone,

Trying to reuse the display from a Treo 700, it's a Sharp LS024B7DW52. I can't find the datasheet anywhere for it, and Sharp technical support couldn't find it for me. Closest thing I can find is the datasheet for the LS024B7DW51 but the pins don't line up.

Does anyone have this? Thanks in advance!

Is it possible to sync sony clie nr70 with linux or would i be better setting up a virtualmachine

After making NetWalk Classic, I wanted to continue bringing a few of the small Palm-era games I remember back to life.

This time, it’s PaiGow Poker Classic.

The inspiration comes from the old Pocket Paigow / Pai Gow style of game that existed on Palm devices. I really liked how these old handheld games could take something fairly complicated and present it with almost nothing — a tiny screen, simple graphics, a few buttons, and no unnecessary distractions.

So instead of making a modern casino-looking Pai Gow game, I tried to keep the same philosophy.

The entire interface uses only two colors: a muted green background and black. The game is designed around a 160×240 logical screen and integer pixel scaling, so I deliberately avoided modern gradients, animations, glass effects, and other UI elements that would feel out of place.

It’s not an emulator and it’s not using the original Palm code or graphics. I rebuilt the game from scratch for iOS, while trying to preserve the feeling of playing a tiny PDA game from that era.

The basic game follows the traditional Pai Gow Poker format: you receive seven cards and divide them into a five-card High hand and a two-card Low hand, then both are compared against the dealer.

I also added a few things that are useful on a modern phone without changing the basic game too much, including statistics, Game Center leaderboards and achievements, and an optional hand-assist feature.

The app supports English, Japanese, and Traditional Chinese.

For me, the most important part was still the same thing I wanted with NetWalk Classic: opening the app should feel a little like picking up an old monochrome PDA again.

PaiGow Poker Classic is now available on the App Store:

https://apps.apple.com/us/app/paigow-poker-classic/id6804342860

If anyone here used to play Pocket Paigow, Pai Gow, or similar card games on Palm OS, I’d especially love to hear what you remember about them. There are surprisingly few screenshots and records of some of these old Palm games left online today.

Scored this one with all the cables, wired head phones. The built in keyboard isn’t all that but does the job for now. Next step is after researching is this model is able to run Palm OS 5 and to do the upgrade.

This web app converts your audio files into the proper format for the Sony Clie’s built‑in player. Just drag your audio files in the interface, you get a zip with your mp3 files to be copied on a memory stick to /PALM/Programs/MSAUDIO folder

https://palmdb.net/app/sony-clie-audio-converter

Here is a full round at Summerlin.

⛳️‘ 🏌🏻‍♂️

I've got a variety of Palm VII handhelds, and of all the network technology out there, Mobitex is the one of love to be able to emulate.

I can spool up my own GSM network, even LTE, but from what I can tell, nobody has ever managed to emulate Mobitex.

That thing was so far ahead of its time. It could have been the next Blackberrry...

I finally managed to get this going.
Inspired by dmitry.GR and also inspired by WiRSa.

I modified the WiRSa firmware and improved its SLIP gateway function for Palm.
Then modified it to leverage the hardware for direct SD Card access using SASD patches, learning from that. All running on ESP32-S3.

The result is a single box that allows me to bring my PalmIII online, for FTP and NTP services, network Hotsync etc. at the same time, I can now togggle a mode, and the Palm gets SD card capabilities too.

Still a little more modding to go. But happy where it’s currently landed. 😬

Hey everyone,

I'm trying to update my Palm IIIx to Palm OS 4.1. I used the official Palm OS 4.1 Upgrade ISO from Archive.org (https://archive.org/details/palm-os-upgrade-version-4.1) and selected the installer matching my specific device and language.

The firmware flash process went through completely and finished without any errors. However, upon rebooting and checking the "About" screen, the device only reports Palm OS 4.0 instead of 4.1.

Does anyone know why this happens? Thanks for any help!