Einstein:      Network   ·   «ROM Card»   ·   ROM Reader   ·   Screen   ·   Serial Port

About the Newton MessagePad ROM card

Feb 19 2017


Download Eagle Board and Schematics files here:

  • V0006 - first rough version
  • V0008 - cleaned up schematics
  • V0010 - ROM pin names

The Story

The Apple engineers were smart when they were building their MessagePads. The MessagePad required an immense 8MB of storage for the Newton operating system. In the 90's, flash memory was extremely expensive, so they had to use ROM chips that were mass-produced and could never be updated. But they knew that they would have changes to their firmware until release day, and they would need to able to fix bugs even after the machine was sold.

They came up with three solutions.

First of all, every jump to an important function in the ROM goes through a jump vector. With a little bit of effort, those vectors can be modified, changing the call that is actually being made. This allows the system software to make change to how the OS works after it has booted and is running.

Quite interwoven is a second grand idea. The NewtonOS uses the CPU's Memory Managemen Unit to replace chunks of ROM with chunks of RAM. These patches are applied pretty early in the boot process. They are loaded from flash memory, so that switching the unit off, or losing power, will still keep the patch around for the next boot.

If all else fails, MessagePads have their ROM chips sitting on a daughter board, a small additional cicuit board that is fitted into a common (at that time) connector and can be changed without tools after opening the case.

But the ROM board has some additional features. It can carry not only the 8MB required for the OS, but it can contain another 8MB of ROM. Apple calls this a ROM Extension and it has an entire protocol that allows software in the ROM Extension to override software in the core ROM.

Apple was hoping to license the ROM to other parties. The ROM Extension would allow Apple to ship the same ROMs to any licensee, and the licensee would then override pretty much anything from hardware drivers to OS patches to their own included software package, and, probably most importantly in our visual world, logos and graphics.

Image taken form pda-soft.de from Frank Gründels amazing Newton page IIRC. Check it out!

There is yet another samart option for the ROM card. Instead of adding 8MB of ROM, NewtonOS will also recognize an additional 4MB or 8MB of flash memory, raising the internal Flash from 4 to 12MB, and leaving both PCMCIA slots available.

Todays Flash prices are laughable for the amounts required in the MessagePad. A 64MB chip can be had for 6$US in singles. Imagine how little they must be with the buying power of Apple.

Anyway, wouldn't it be fantastic to create a souped-up ROM board? 8MB Flash and 8MB NewtonOS, also in Flash, being able to patch it, fix it, extend it, have fun. Maybe have even more that 16MB if that is possible. Is it possible? How can we find out?

An early draft of the licensee information for this ROM card exists, but it is not detailed enough to build such a card. Before starting a patch wire solution, I wanted to know how the original board worked, and then fill in the missing information in that draft.

Well, I went all the way and reverse engineered the entire ROM board. Here are my findings.


The ROM board plugs into the Newton main board using an SO DIMM edge connector, just like RAM modules did and still do. The pinout is completely different, and the PCB is longer, but the connector is standard and was easily available in the 90's. It is really hard to find in 2017 though. SO DIMM sockets are still made, but start at a pin count of 144 and go up from there. I'll keep looking around.

Two ROMs

The only IC's on the board are two mask-programmed custom ROMs. The ARM CPU has a 32 bit bus, so each ROM has a 16 bit data bus. Since there is no selection logic, the edge connector provides select pins for ROM bank 0 (the lower 8MB) and another select for ROM bank 1. Both ROM chips listen to ROM_CS_0. Flash RAM would listen to another chip slect signal.

Four ROMs

On the back side of the ROM board, we find pads for another four chips. I was hoping that these can be populated with flash chips, but unfortunatley that is not the case. These positions are alternative positions for ROMs in 8 bit mode. They have the same footprint as the front side ROMs, so I assume that this is simply for another configuration.

Apple made boards with footprints for eight flash RAMs which were used during development. Check out Frank Gründel's page on this rare ROM card.

Jelly Beans

Besides the ROMs, there is only one resistor and a possible capacitor close to each ROM between GMC and VCC.

Reverse Engineering the Board

It is always smart to grab as much information as possible before actually touching the board. I dumped the ROM content, searched for documentation of the chips (none online), and for documentation on the board, which I eventually found, named the "ROM Board Designer's Guide". It gives us the pinout of the edge connector and the type of flash chips that are supposedly supported as internal flash. They are unsurprisingly the same 28F016SA flash RAM by Intel that are used on the main board.

Stripping the PCB

After taking a lot of pictures of the board (I have multiple ROM boards, no worries), I desoldered all parts with a heat gun. Then, the PCB is scanned at high resolution on a flat bed scanner, so we can later recreate the markings.

Next, I removed the solder mask and scanned the bare copper on boath sides. Probing the connections revealed a four layer board. Since I could not be sure if there may be exrtra wires besides the usual ground plane and another VCC plane, decided to grind the pcb material down to the next copper layer on both sides. Again, I made highres scans of those as well.

Image Material

I had seven scans now:

  • top view with chips
  • top without chips, but with text
  • top layer, bare copper
  • second layer, visible copper
  • third layer, visible copper
  • bottom layer, bare copper
  • bottom layer with text, no components on that one anyway

Next, I used an image processing program, (Photoshop, Gimp, whatever), to align all scans perfectly in seven layers and crop them down quite a bit. Every layer was stored in a separate, yet aligned, highres jpeg.

Manual Labor

I wanted to recreate the PCB and the schematic in Eagle. I know, it's the wrong tool for the job, but that's what I got, so I had to work around it. I wanted to use the images as an overlay and then trace the vector data on top, but Eagle does not like raster data at all. Another attempt at vectorizing the images in Inkscape failed miserable, even after tweaking contrast to nearly black and white. The vector data generated is just not good enough.

Human brain power to the rescue. I loaded the images into my CAD software (QCAD, great tool!), and traced every wire on the board for every layer. It took about three hours, but the result is very usable and imports easily into Eagle.

Let the Eagle land!

Now, the vectro data from QCAD is just a helper. In a second step, I have to trace everything again in much more precission and with PCB routing in mind. In the Schematic view, I loaded the SO IMM edge connector and created and loaded the two ROM chips without any pin marking - yet.

Again, Eagle is a horrible tool for reverse engineering. The Schematics view does forward data to the PCB view, but changes in the PCB view never get sent to the Schematics view. If they ever get out of sync, you basically have to go back until they sync again. At least the PCB warns you before you do something silly.

So how is it done if I want to transfer from PCB to Schematics then? Well, I started with a random pin and connected that to a temporary part. Then I changed into PCB view and traced along the vector - not to the temporary part, but wherever my vector would take me. Before drawing the final wire that would connect two pins (but not back-annotate), I noted the new pin, went back to schematics, connected the pins there, and then finished the last bit in the PCB view. It takes a while, but it is pretty safe to do and creates the schematics in the progress.

Place Video here

If there is any interest in how I did this, I will make a screen cast an post it here. For now, this space intetionally left blank...

Any Results


The Eagle PCB, packed in a zip file, can be dowloaded at the top of this page.

The ROM board connectors offers address lines up to A24, giving it access to 32MB blocks of memory. Two different chip select signals, ROM_CS_0 and ROM_CS_1, make two of those blocks available. ROM 0 supports only read functionality, wheras ROM 1 allows for read and write, and even includes a delay line to insert CPU wait cycles if needed.

The populated ROMs are organized at 2*4Mb*16bit, adding up to 8MBytes, which are mirrored into the area covered by ROM_CS_0. The unpopulates pads can alternatively hold 4 of the same type of ROMs at 4*2Mb*8bit for 16MB of ROM space. Interestingly, the 4 ROMs are used in 8 bit mode, requiring the NewtonOS and possible licensee ROM Extensions present in the same ROM. I would have expected two sets of ROMs in 16 bit mode, with two slots taking the original ROM, and two ROMs holding the licensee extension.

Well, and I had hoped in my wildest dreams, that the empty pads were there to simply have additional Flash RAM soldered onto them, which should be supported by the OS for the ROM_CS_1. But they are not. Adding Flash to the ROM board would require a redesign.

Further Plans

I will add a chapter that oultines my findings based on the PCB that I recreated. In a second step, I may try to create a new ROM board with additional functionality, for example (in descending order of likelyhood):

  • multiple ROMs on a single board that can be reprogrammed and switched
  • ROM Extensions that can be reprogrammed and switched
  • additional internal Flash as it may or may not be supported by the native OS
  • much more Flash as it could be supported by ROM patches
  • possibly adding SD card support