Posted on

Tucker’s Status Report for 2026-10-10

This week, I found myself busy with midterms and interviews. Nonetheless, I’m ahead of where I expected on emulation (so far) and working on the design report.

I’ve pulled in Martin Hellspong’s `r68k` CPU emulator as an EC000 stand-in for the time being. I’m not sure if this will be viable for the final integration, as we may have tight margins on CPU performance. However, this allows me to work on emulation and package/IO integration simultaneously, because r68k defines an interface for memory/flash/MMIO and interrupt controller that also works for my version. (Memory, being a hot path, will almost certainly need tighter integration on the integrated board, but I don’t have data to prove that yet.) I’ve also completed further work on my version of the emulator, being able to decode the whole instruction set and execute a subset.

The net result is that we can run the test programs I’ve written, outputting to a MMIO-configured UART. We can also run about 25 million instructions of PalmOS before we hit a yet-to-beimplemented device (one of the GPIO controllers). The challenge right now is mimicing the VZ memory bus: in order to get this far in boot, I have 9 virtual devices (lumping the GPIOs into one, which is not quite true, because they all correspond to different external devices!)

We’re not far enough in boot to draw on the screen yet, so… Here’s a smiley face I drew on the LCD controller! My first drawing in 68k assembly. Brings me back to learning to write code in Small Basic.

A smile drawn in m68k assembly

A fun fact: we’re targeting PalmOS 4.X, which does not do memory management in the traditional sense. It can run 4 groups of memory, and system registers (in the VZ package) are mapped into the top of the address space. PalmOS 6.X was supposed to introduce memory protection, but came only towards the end of Palm’s success. (This is a major factor in why we’re running PalmOS, and not just the apps, since they do not have not a modern expectation of isolated memory.) I wonder if they are the last popular general-purpose computers to lack an MMU, but I have not pursued this line of research.

I’m quite happy with the results this week! Now on my end, the goal is to keep squashing discrepancies with the VZ so we can keep booting. Part of that will be setting up a debugging system so I don’t have to keep flipping between the emulator and my disassembler. The major risk at this point is in emulator speed: I intend to update our schedule with time for benchmarking r68k on our dev board.

Posted on

Tucker’s Status Report for 2026-10-03

Tucker’s Status Report for 2026-10-03

This week, we had our design presentation and continued forward with our schedule. In the near future, we need to order our PCB and complete our design report.

I spent quite a bit of time getting comfortable with the 68k instruction set this week, and what the PalmOS binary actually looks like. I spent some more time writing assembly in Easy68k. As an aside: it’s fitting that my version of Easy68k requires x86 emulation to run on my Mac.

I also built familiarity with disassembly and binary analysis of PalmOS. My tool of choice is Ghidra, though its 68k support is not as complete as other architectures. In particular, I found that its analysis tools regularly failed to run unless I manually entered function signatures. I identified utility routines including strcpy, a CRC16 routine, an entry point for a built-in debugger, and a lot of IO/MMIO. In reading the binary, I learned that I’d made an incorrect assumption while learning about the architecture: byte and word operations do not clear (or sign-extend) into the full width of registers, matching x86 byte and word registers, but not the x64 doubleword-to-quadword extension that I’ve programmed against more often.

Work on the case will be useful for informing PCB design, and vice versa. I’ve developed an initial model where the display (with flex cable folded under) can be glued into the top of the case, and the mainboard and battery sit on a sled underneath. It helped develop a few constraints:

– The mainboard must go at the bottom of the device to make the buttons at the bottom work. (I’ve omitted the buttons from the screenshot below, because their placement will be defined by PCB constraints, but they’ll be top-hat style 3D prints that rest on the PCB buttons and can’t fall out of the case.)
– Therefore, the battery must go on top. The battery takes up the majority of the internal volume, as well as weight. The combination of display and battery on top is going to be heavy, and we may want to consider intentionally adding weight to the bottom of the case for balance and comfort, potentially at the cost of overrunning our intended weight limit.
– There is enough room for our LoRa antenna to reach around the battery to the top of the assembly. Despite the lower PCB placement, the antenna can be placed such that it won’t be obstructed by the body or left/right hands.
– The GPS IC will likely end up in a position where it may be obstructed by hands during use, since it must go on the PCB. Modulo EMI, testing with a piece of cardboard suggests that it will likely be least obstructed near the USB port, since there’s little reason for fingers to cover that area for extended intervals. I also considered whether we could place it on the back of the PCB, but that risks a prolonged obstruction by the palm of the hand.
– The USB port placement risks conflicting with button placement. However, we could place it off-center or extend the case out further.

Some factors that will depend on PCB design or upcoming team decisions:

– PCB mounting. I’d prefer to place drill holes on the PCB and add either self-tap screws or fully 3D printed pins into standoffs. I’ll have to experiment with pin and clip style attachments, as they seem preferable, largely due to straightforward reusability. However, screws are the simplest on the modeling side (add a ~4mm standoff with solid fill, and tap into it with a short screw).
– Backplane attachment. I modeled it as a plate that glues onto a recessed edge in the case, but this fails to meet our repairability goals. Screws would be difficult to fit around the battery and require more space above the display. We could implement a hinge, sled, or magnetic attachment. I’m slightly enamored by the idea of a hinge, and may prototype it; however, I think that the choice of mechanism is not a priority here, and a sled is a good backup (if potentially annoying to dial in on a 3D printer).
– Display attachment. I modeled it as gluing into the front of the case; this actually performs quite well for repairability, as it could be removed from behind with a heat gun or exacto knife. This is sufficient for a prototype. For a demo device, I’ll prefer to hide the edges of the display under the bezel, for both durability (protect the touch sensor) and appearance.

I made some progress on the emulator and instruction decoding, but no significant milestones here. That was an early goal, and my work on it will continue in the coming week.

Next week: our team is laying out the PCB, writing our design report, and keeping at software. I’ll be focused on emulator milestones this week. I also need to add a time to revisit the case design and do test fits to the schedule – TBD, but this will likely be a week or two after our PCB arrives.

 

Posted on

Tucker’s Status Report for 2026-09-26

We are on track for work this week. In particular, we’ve narrowed down a lot about our design and component selection, including some fortunate changes towards the end.

We’re aiming roughly for Palm m515 compatibility, as it’s later-generation and fulfills our needs while still being of reasonable scope for a capstone. The m515 has 16MB RAM and 4MB flash, as well as a 33MHz processor. Very few embedded packages have this amount of RAM; for this reason, some prior art upgrades to a Raspberry Pi. This is certainly workable, but it’s overkill for our purposes. However, we don’t want to adopt the complexity of routing our own RAM chip.

I found a ESP32-P4/32 based board in stock with 32MB RAM and 32MB flash, and Sophia found stock of the chip. 400MHz will give us sufficient overhead for emulation, and the MCU has a low-power core appropriate for idle work. I developed a pin map to ensure feasibility, and I’ve started working with the HAL in Espressif’s `esp_hal` crate.

As mentioned last week, I’ve been understanding the 68k landscape. I’ve written a few simple programs using the Easy68k assembler/simulator, written by Brad Krupp and The Great Emerson.

My plan for the following week is:
– Case sketches by Monday night
– Practice using the 68k disassembler by Wednesday night
– Case model; instruction decoding in the hypervisor by Saturday night.

In case of unexpected delays, this schedule has quite a bit of room to flex, as it’s still ahead of our global schedule. I’d like to save that flexibility for future risks, if possible.

Posted on

Team Status Report for 2026-09-19

This week, we’ve been working on our design and starting on the initial implementation: selecting a development board and proof-of-concepting software components.

Our largest risk right now is designing a system incompatible with our goals. Our development board and final platform must have the radios we need and sufficient resources for emulation, and be similar enough to prepare for the final integration. We’re managing this by keeping our high-level goals at top-of-mind and thinking through the stack. In case of an error, we can generally attach further peripherals or expansions through I2C or SPI.

We learned in research that the M68000 does not have the features we’d like for emulation. Instead, we’ll use a more familiar microcontroller (a la STM32) with sufficient performance to make ISA emulation tenable. This is a favorable switch: hardware has improved substantially since the 68k, more than making up for emulation overhead, and a modern platform has better HALs and development tooling available.

Lastly, we had the proposal submission and presentation. We’ve laid out our problem statement, set our design strategy, and created an initial timeline.

Posted on

Tucker’s Status Report for 2026-09-19

I’m writing an update for a week and change, since this is my first update!

At the top of my mind has been the proposal. We received great feedback on our abstract, and this led us to focus our problem statement and update our design. Ultimately, we were able to improve in areas we were given feedback and in areas we personally found weak. I presented, and planned for the points I wanted to hit — especially in making it clear to a student audience, most of whom have not used PDAs, why they’d care — and for the questions I expected to come up.

Slightly ahead of schedule, I’ve been exploring the M68k ISA and laying out the foundation for an emulator. I expect a large part of the challenge in running PalmOS apps will be understanding what assumptions they make: it would be costly to replicate every platform quirk, but insufficient to throw timing and other observable-but-flexible behaviors to the wind. Therefore, I want to understand what we’re looking at early.

As an aside: we’d like to improve upon processor speed if possible, to open the ecosystem to new capabilities. If PalmOS or particular apps depend on timing behavior, we might not be able to do this. We will find out!

This week, I’m working on the device housing design, and looking ahead to the emulator. While the deadlines are relatively lax (as the next critical dependency is ordering our PCB), this will account for software needing more time than expected.