Getting an Apple Newton MessagePad online in 2026 is surprisingly possible. It is also surprisingly easy to forget just how differently computers were expected to behave in the 1990s.
My test machine is a MessagePad 2100. The goal was initially quite modest: I wanted to make a complete backup, install some software without relying on an original Apple serial cable (which I don’t own), and eventually see if the Newton could still communicate over a modern network.
It turned out that all of those things are possible.
Installing software without the original cable
One of the most useful pieces of hardware I have found for the Newton is Matthias Melcher’s NewtCOM adapter. Apart from providing serial communication over USB, NewtCOM has a microSD card slot. This makes software installation almost ridiculously convenient compared with the original Newton workflow.
I formatted a microSD card as FAT32, copied Newton .pkg files to it and inserted it into NewtCOM. With the adapter connected to the MessagePad, selecting:
Dock → Serial → Connect
makes the packages on the card available for installation.
For simply putting software onto a Newton, this is probably the easiest solution I have found so far. No vintage Macintosh is required, and no original Apple serial cable is required either.
Backing up the Newton
For backup I used Apple’s old Newton Connection Utilities under Windows XP. This part turned out to be more difficult than installing packages. NCU could communicate with NewtCOM, but backups repeatedly failed with communication errors when Windows XP was running in a normal modern virtual machine. The eventual solution was full QEMU emulation rather than KVM acceleration. By emulating an old Pentium-class machine and slowing QEMU’s virtual clock down, NCU became completely reliable. I was then able to make a full backup of the MessagePad and, more importantly, test a selective restore of Notes successfully.
If you intend to experiment with 25-30 year old hardware and software, I strongly recommend doing this before changing anything else.
Ethernet
The Ethernet card I used is a 3Com 3CCE589ET, a 10 Mbps PCMCIA card.
Ten megabits per second sounds almost comical today, but for a Newton it is more than enough.
Before blaming the Newton when I failed to get a link, I tested the card in an old HP Omnibook running Windows 98 SE. After installing the original 3Com driver, the link LED came on and normal network access worked. This was a useful test because it proved that the card, dongle and cable were all good. The Newton needs Apple’s Newton Internet Enabler 2.0 plus the appropriate Ethernet drivers.
For my 3CCE589ET the minimal working installation was:
enetsup.pkginetenbl.pkgnewtdev.pkginetstup.pkgfarallon.pkg3c589.pkg
In Internet Setup the card appears as: Megahertz 589E
I configured it for DHCP.
Why does the Ethernet link go down?
This caused quite a bit of unnecessary troubleshooting.
When the card is inserted, the Newton identifies it and the Ethernet link comes up. A few seconds later the link goes down again. On a normal PC I would immediately suspect a driver or hardware problem. On a Newton this is apparently normal. The Newton does not treat networking as a permanently active system service in the way a modern desktop OS does. Applications ask for a network connection when they actually need one.
Once I installed an application with a Connect button, the card came alive again and stayed alive while the application was using the network. That was the first real proof that the Ethernet installation was working.
A local retro network
I already have a small isolated network for old computers. Its gateway/proxy machine is called retroproxy and has a network address that uses a separate address-space than my normal LAN. This is so that old, vulnerable machines cannot be infected by malware. This Retro-LAN provides DHCP, DNS and various services intended specifically for machines which should not be exposed directly to my normal LAN.
The Newton received an address by DHCP and could reach the proxy without any problems.
My first attempt at an application-level test was an old FTP client called NewtFTP. It successfully opened a TCP connection to the FTP server but, for reasons I have not yet discovered, never proceeded beyond the FTP server’s initial greeting. Rather than spending the rest of the evening debugging a 1998 FTP client, I tried a web browser instead:
NetHopper 3.2
NetHopper 3.2 turned out to be the breakthrough. After installing nethopper.pkg, I pointed it at the local web server.
A packet trace on Retroproxy immediately showed:
GET / HTTP/1.0
User-Agent: NetHopper/3.2 (Newton)and the server replied:
HTTP/1.0 200 OKAt that point there was no longer any doubt:
Ethernet, DHCP, DNS, IP, TCP and HTTP were all working on the Newton.
There was, however, one final piece of 1990s compatibility waiting for me.
Do not tell NetHopper what character set you are using
My web server originally sent:
Content-Type: text/html; charset=UTF-8NetHopper complained that it did not understand UTF-8. Fair enough. UTF-8 was hardly universal in 1998, so I changed the page to ISO-8859-1. NetHopper then complained that it did not have a plugin for ISO-8859-1.
The solution was wonderfully primitive: Do not specify a character set at all.
My small PHP front page now starts with:
<?php
ini_set('default_charset', '');
header('Content-Type: text/html');
readfile('start.html');
?>The resulting HTTP header is simply:
Content-Type: text/htmlNetHopper is perfectly happy with that. And with that, a MessagePad 2100 made in the late 1990s was displaying a page served by a modern Linux machine in 2026.
Getting a web browser to work was nice, but e-mail is probably an even better demonstration of what the Newton was actually designed to do.
For this I used EnRoute i-net 1.4.3, a proper POP/SMTP mail client which integrates itself into the Newton’s own In/Out Box and routing system. This is another example of the Newton doing things differently from a normal computer. EnRoute is not really an application that you launch and then configure in the usual way. Its account information is stored in Owner Info, while its preferences are accessed from the In Box.
For a basic installation I used four packages:
Core.pkgEnRoute.pkgmessig.pkgPoplst.pkg
My retro mail server already provides deliberately old-fashioned services:
- POP3 on port 110
- SMTP on port 25
- no TLS
- plain-text authentication
The Newton could reach both services without problems. The first POP login, however, failed.
A packet capture showed why:
USER test
PASS pass123This was slightly surprising because I had entered:
test@retro.localas the POP username. The EnRoute manual explains the behaviour. It assumes the sort of ISP account that was common in the 1990s and explicitly tells the user not to enter the full domain-qualified username. My modern Dovecot server, on the other hand, expects the complete account name.
Rather than trying to persuade a 1997 Newton mail client to behave like a modern one, I changed the server. I added:
auth_default_realm = retro.localto the Dovecot configuration. This makes:
USER test equivalent to: test@retro.local
That was enough. EnRoute connected, authenticated and downloaded all messages in the mailbox. I then sent a message from the Newton to myself. It arrived.
So a MessagePad 2100 in 2026 can not only browse a local web server over Ethernet. It can also send and receive real POP3/SMTP e-mail, using essentially the same software model it would have used when it was new.
There is something particularly satisfying about seeing a 1990s Newton retrieve mail from a Docker container running on a modern Linux server.