跳到正文
DEV Community· Naing Oo·· 3 小時前AI 評分42

將 2007 年的 IM-me 復活,改造成 Mac 伴侶裝置

I brought a 2007 IM-me back to life as a Mac companion

AI 導讀

作者把 Mattel 於 2007 年推出的 IM-me 改造成 Mac 伴侶裝置,透過原有 USB dongle 建立 Mac 與手持機之間的雙向訊息傳送。無線連線採用 915 MHz,現行實作使用固定 32-byte 封包;Mac app 亦可傳送時間、電量、鎖定狀態、目前使用的應用程式及通知摘要,並把手持機訊息對應至 macOS Shortcut。

正文

In 2007, Mattel released a small pink device called the IM-me. It had a screen, a full keyboard and a simple purpose: let kids chat with their friends without being glued to the family computer.

It worked with a USB dongle and a Windows application. Mattel's online service later shut down, but the little handset still had a screen, buttons, a radio and a lot of character. I wanted to see if I could give it a new job.

My goal was to turn it into a pocket companion for my Mac. I wanted to send messages both ways, see useful status updates and notifications, run shortcuts, and add a few retro games. I also wanted to keep the original USB dongle in the picture.

What was inside

The handset and the dongle each contain a TI CC1110 microcontroller with a radio. The dongle also contains a Cypress USB controller. That distinction turned out to matter.

I used an ESP32 connected to the debug pins to reprogram the CC1110s. Once the firmware was in place, the ESP32 was no longer needed for normal use. The handset and dongle could run on their own.

The opened pink IM-me handset showing its circuit board, wiring and display connector.

Inside the IM-me handset.

Getting the radios talking

The first milestone was a message travelling from the handset to the dongle and back. The radio link uses 915 MHz, with a fixed 32-byte packet in the current implementation.

One bug took a while to track down. Receiving worked in isolation. Transmitting worked in isolation. But receiving a message and then sending a reply did not.

The cause was a DMA channel that was still armed for the previous receive operation. Aborting the old transfer before configuring the next one fixed the switch from listening to transmitting. After that, the handset could send a message and see the dongle's echo.

The original IM-me USB dongle with its case removed, connected to debug wires and a small breadboard.

The original USB dongle during development.

In radio.c, this is the part of the transmit path that made the difference. It aborts the pending receive transfer, clears the DMA completion flag, configures the channel for transmission, and only then starts the radio:

DMAARM = 0x80 | DMAARM0;
DMAIRQ &= ~DMAIRQ_DMAIF0;
dma_cfg_tx();
DMAARM |= DMAARM0;
RFST = RFST_STX;

The USB breakthrough

I wanted the Mac to communicate through the original dongle, rather than keeping the ESP32 permanently attached as a bridge.

Early SPI probing produced no useful bytes. Some early observations may have been taken on the wrong board, which was a useful reminder to check the hardware assumptions before blaming the code. Later tests also probed the dongle, so that was not the explanation for every failed attempt.

The successful approach was to have the dongle's CC1110 act as SPI master and exchange data with the Cypress controller. A small test produced framed bytes on the Mac through the original USB HID interface. From there, I built the path in both directions: Mac to dongle to handset, and handset back to Mac.

Seeing "MAC SAYS HELLO" appear on the handset was the moment the project clicked for me.

The hardware detail that unlocked this was the wiring inside the dongle: P0.2, P0.3, P0.4 and P0.5 carry the SPI signals, while P1.0 and P1.1 are used for attention. On the Mac, the original Cypress device appears as HID 0e4c:7272.

The bridge wraps a received 32-byte radio payload in a small frame before sending it across SPI. This is the core of usb_forward() from the dongle firmware:

parse(spi(0xfa));
parse(spi(0xfb));
parse(spi(PKT_LEN+2));
parse(spi(1));
parse(spi(1));
for(i=0;i<PKT_LEN;i++) parse(spi(radio_in[i]));

The resulting frame begins FA FB 22 01 01, followed by the radio payload. In the other direction, a small parser assembles a Mac message and the CC1110 transmits it to the handset.

Giving the handset a new job

I built a Mac companion app that sends the time, battery level, lock state, active application and short notification summaries to the handset. The app can also map a message from the handset to a macOS Shortcut.

For example, PING asks the Mac for a fresh status update. I also mapped TERM to a shortcut that opens Terminal. The mappings can be changed in the app, so I do not have to reflash the handset every time I want a different action.

There are limitations. Notification forwarding currently reads an undocumented local macOS database and requires Full Disk Access. The radio link is also unencrypted and unauthenticated, with no delivery acknowledgements or retries yet. It is an experiment, not a secure remote-control system.

Making it feel like a device again

Typing TERM on the IM-me handset to open Terminal on the Mac.

Opening Terminal from the IM-me.

I added a dashboard with icons for the clock, battery and lock state, plus an inbox and a compose area. Messages wrap across two lines. The keyboard was initially bouncing and adding extra characters, so I fixed the debounce while keeping deliberate repeated letters possible.

Then came the fun part: a calculator, Snake, Pairs, Space, Bantumi, a countdown, notes and other small tools. The calculator uses the numbers and symbols already printed above the keys when ALT is enabled. It displays a Python-style prompt, although it is an arithmetic calculator rather than a Python interpreter.

The handset also has a piezo buzzer. I found the output pin, tested three different pitches, and added a simple composer, message sounds and a countdown alert. Hearing the three notes come out of it for the first time was surprisingly satisfying.

Exploring the airwaves

The handset now has a Spectrum app and a separate Signal Explorer. They show sampled radio signal strength across selected ranges supported by the CC1110. You can select a range and monitor a peak.

The display shows approximate signal activity. It does not decode every transmission or record audio, and it can miss signals between samples. The explorer shares the handset's radio with chat, so messages pause while scanning. I tested the explorer's display and confirmed that PING worked again after leaving it.

Standing on earlier work

This build did not start from a blank page. Dave documented the IM-me hardware and LCD interface. Michael Ossmann published IM-me firmware and radio tools. Joby Taffey documented the USB dongle and its connections. Their work, together with the TI CC1110 datasheet, gave me a foundation for the experiments described here.

Dave: https://daveshacks.blogspot.com/2010/01/im-me-hacking.html

Michael Ossmann: https://github.com/mossmann/im-me

Joby Taffey: https://web.archive.org/web/20111008023648/http://blog.hodgepig.org/2010/10/22/im-me-usb-dongle-hacking/

TI CC1110 datasheet: https://www.ti.com/lit/ds/symlink/cc1110-cc1111.pdf

Where it stands

The original dongle can now carry messages between the Mac and the handset, the companion can forward status and notifications, and the handset has a collection of tools that make it useful and fun to pick up.

There is plenty still to improve: secure and authenticated commands, reliable message delivery, better power management and more testing of the radio tools. Notes and melodies are currently kept in memory and are lost when power is removed.

I used AI coding tools as a collaborator throughout the build, alongside datasheets, earlier reverse-engineering work and plenty of hardware testing. The most interesting moments came when something that looked correct in code behaved differently on the bench.

If you have worked on an IM-me or brought an old device back to life, I would love to hear what you built.

#HardwareHacking #EmbeddedSystems #ReverseEngineering #RetroTech #MacOS

來源:DEV Community · dev.to