Bringing ROM-Disk Booting to the Macintosh SE: The SE ROM-inator Project!
- Kay Koba
- 22 hours ago
- 8 min read
Updated: 2 hours ago
Why Build an SE ROM-inator?
The Macintosh SE never got the kind of ROM-disk hack that Steve Chamberlin of Big Mess o' Wires created for the Macintosh Plus, 512K, and 128K.
The original ROM-inator was a brilliant piece of work. It gave those early compact Macs a writable flash ROM and, more importantly, the ability to boot directly from a disk image stored inside the ROM.
But there was one obvious gap:
The SE didn't have one...
Later, there were other hacked-ROM projects for the Macintosh SE/30, such as ROM SIMMs and ROM-inator II. However, as far as I could determine, nobody had taken the same basic idea and properly brought it to the Macintosh SE.
So I decided to try it myself.
The goal was fairly simple to describe:
Take the ROM-inator logic from the Macintosh Plus and make it work inside the SE's original ROM architecture.
Following the original spartan design, the hardware uses two SST39SF040 flash ROMs, one for the HI byte lane and one for the LO byte lane, giving a total ROM capacity of 1 MB, a single 74HC02 is used to control the EEPROM's CE and OE signals. I considered TSOP and PLCC packages as well, but decided to go with the DIP package for the initial version.
The software side turned out to be a completely different story.
A little history
Kero's Mac Mods started out as nothing more than my personal hobby. I was repairing and modifying old Macs because, well... I like old Macs.
Eventually, after JDW featured me in a YouTube video about the ROM-inator, I began selling Macintosh and Apple II parts with the cooperation of him and Steve Chamberlin.
In fact, the Macintosh Plus 512K ROM-inator was the very first product I started selling.
I took over production from Steve Chamberlin, so I've always had a soft spot for that particular project. For years, I was simply producing and selling his original design.
The SE ROM-inator was different.
This time I wasn't just making someone else's design. I was diving into the SE's ROM architecture and trying to build something new.
And that's where things got interesting.
First Attempt: "What If I Just Plug It In?"
Before spending months reverse-engineering everything from scratch, I figured there was an obvious experiment worth trying.
I took the actual Macintosh Plus ROM-inator binary published by Rob Braun (bbraun) and put it into an SE.
And...
Bong! It booted.
Well, sort of.
The SE powered up and started running, but it didn't recognize any drives at all.
And of course, it couldn't boot from the ROM disk either.
Considering that the Plus and SE have significantly different internal architectures, this wasn't exactly a shocking result.
Still, it was useful.
It immediately told me that this wasn't going to be a simple matter of taking an existing ROM-inator ROM and dropping it into an SE.
I recorded the experiment, including video, and sent it to Steve Chamberlin. He gave me some useful advice about the ROM contents.
That was about two years ago.
From there, I started digging through bbraun's documentation and his disassembly of the Plus ROM-inator.
Rather than simply copying the finished code, I wanted to understand why it worked.
What was bbraun actually changing?
Where were the hooks?
Which driver was being replaced?
How did the ROM disk get inserted into the Macintosh boot process?
The more I understood about what the original ROM-inator was doing, the clearer the path to an SE version became.
Gathering information on other developments
As I continued my research, I searched Google to see if anyone else had already attempted an SE ROM-inator.
I found several interesting posts and discussions on places like 68kMLA, as well as an one project on GitHub.
There was Frimples/MACSE_ROMINATOR, I looked through it, but I didn't actually build it or test it in depth. The README had two important items listed as TODO / not implemented: Make the Sound driver jump to the ROM-disk driver. Add a jump back from the ROM-disk driver to the Sound driver...In other words, the hooks needed to take over the existing driver and redirect execution to the new ROM-disk driver had not yet been implemented.
I wonder if Frimples will find this interesting if he happens to come across this blog post! And I would like to say to him "I am sorry I couldn't help you when you needed it. At the time, I was working on a completely different project."
Beyond that, I couldn't find much more information that was directly useful to my project.
So I went back to the original work by bbraun and BMOW, and started digging much more deeply into their older articles and technical write-ups.
That became the real starting point for my own reverse-engineering work.
Why .ATP Became the Victim
One of the biggest problems wasn't actually writing the ROM-disk code.
It was figuring out where to put it.
Classic Mac OS doesn't simply scan the ROM looking for random drivers.
The Device Manager relies on structures such as the ROM's core driver list and resource map, which are part of the ROM's original architecture.
Adding a completely new driver and registering it properly turned out to be far more complicated — and risky — than I initially expected.
So I decided to use a trick that is already familiar in the ROM-inator world:
Don't add a new driver.Take over an existing driver slot that you don't really need.
bbraun used a similar technique on his Macintosh Plus adapter, taking the .Print driver and repurposing it under a different name.
So I started looking for a suitable victim.
.Sound
My first choice was .Sound.
I spent a lot of time trying to make this work.
And it kept crashing.
Not just randomly, either.
At the very early stage where .Sound was being opened, the SE would consistently die with an address error, regardless of what code I put there.
Eventually I concluded that the problem was related to when that particular driver slot was accessed, rather than what the replacement code was doing.
So .Sound went into the "maybe someday" pile.
There was another hilarious complication.
For quite a while, I thought I was modifying the .Sound driver header.
I wasn't.
It turned out I was actually looking at .Sony — the floppy driver.
That little naming mistake cost me a lot of time.
Welcome to ROM reverse engineering.
.ATP
The next candidate was .ATP, the AppleTalk Transaction Protocol driver.
This turned out to be the sweet spot.
There were three big reasons.
First: the two drivers in the ROM's core driver list are opened extremely early in the boot process, before the normal System startup sequence.
That's exactly what I needed.
If the ROM disk is going to behave like a real bootable disk, the driver has to become available very early.
Second: .ATP isn't normally useful on an SE unless you're actually using AppleTalk/LocalTalk.
For a typical standalone SE, there is no LocalTalk cable attached and no reason for the driver to be doing anything useful.
So taking over that slot has essentially no practical impact.
Third: it worked.
The exact same replacement approach that crashed in the .Sound slot did not crash when placed in .ATP.
That was a very important discovery.
It demonstrated that the problem wasn't simply "my replacement driver is broken."
The location and timing of the driver slot mattered.
And suddenly the project had a viable path forward.
The Long, Slow Process of Breaking Things
From this point onward, development became a very old-school process:
Change one thing.
Put the ROM in a real SE.
Turn it on.
See what breaks.
Then repeat.
There were plenty of wrong turns.
Sometimes I misunderstood the ROM.
Sometimes Claude misunderstood the ROM.
Sometimes both of us misunderstood the ROM.
And sometimes I simply made a stupid mistake.
But every failure gave me another piece of information.
Along the way, I got several things working:
Startup sound
I ported the startup-sound mechanism using essentially the same technique used by the commercial Plus ROM-inator.
Then I did something a little more fun.
I replaced the startup sound with the sound of an old junk mandolin that I had lying around.
Because if you're going to hack a 37-year-old Macintosh ROM, you might as well make it play a mandolin.
A new Happy Mac
I also reverse-engineered the SE's icon drawing routines and replaced the original Happy Mac with my own design.
The startup icon was modified in the same way.
These were small things compared with getting the ROM disk working, but they were extremely useful as development milestones.
If the icon changed, I knew my modified ROM was actually being executed.
That sounds trivial, but when you're debugging a ROM at this level, having a visible sign that your code is running is incredibly useful.
Bringing .ATP back
I also experimented with making the real AppleTalk .ATP driver coexist with the ROM-disk driver.
I managed to prove that the Unit Table registration mechanism itself worked correctly.
Unfortunately, AppleTalk has much deeper dependencies on its internal initialization sequence than I initially expected.
So for now, that part of the project is on hold.
It's not impossible.
It's just not where I want to spend my time right now.
So, What Actually Works?
The current stable ROM can boot an SE using nothing but the internal ROM.
No SCSI drive required.
No floppy required. No SD card device required.
The current version provides:
ROM-disk booting
Press R during startup to give the ROM disk priority
Normal SCSI/floppy booting when R is not pressed
The original startup sound
The original startup icons
A custom-designed Happy Mac
And then something rather unexpected happened.
This was where I really got to enjoy the full SEFDHD experience.
I added DiskCopy 4.2 to the ROM disk.
That was mainly an experiment.
But the SE has an interesting hardware capability: some configurations support two internal floppy drives, and it is also possible to modify a standard SE to use the same arrangement.
The original SE ROM can recognize up to three floppy drives:
Internal floppy 1
Internal floppy 2
External floppy *The SE Early model is equipped with an IWM chip and supports 800KB drives, while the SE FDHD model features a SWIM chip and supports 1.4MB drives. The SE ROM-inator can provide the necessary ROMs for both versions. In other words, even an Early model can be upgraded to SE FDHD specifications if a SWIM chip is installed!
So I tried it.
And it worked.
This means that, with the ROM disk containing DiskCopy 4.2, an SE can effectively operate as a standalone floppy disk duplicator.
No hard disk required.
No external Macintosh required.
Just the SE itself, a couple of floppy drives, and software living inside the ROM.
That's one of those completely unnecessary but extremely satisfying things you can do with a vintage Macintosh.
And honestly, that's part of why I enjoy these projects.
The work I actually used as my technical starting point was:
Rob Braun (bbraun)'s Hacked Macintosh Plus ROM Driver.
His published ROM analysis and disassembly
Steve Chamberlin's earlier technical explanations and analysis, And his Flash Tool and the ROM-inator ROM.
From there, I continued with my own disassembly, experiments, and "most importantly" testing on actual Macintosh SE hardware.
The final result is the product of a long process of trial and error, reverse engineering, broken ROMs, unexplained crashes, bad assumptions, AI suggestions that sometimes went completely off the rails, and a lot of time spent staring at hexadecimal data.
But that's what makes it fun.
Although about 40 years have passed since the Macintosh SE was released, and we're still finding new ways to make it do things Apple never intended.
And this time, it can boot a disk that lives entirely inside its own ROM. In the past... tinkering with 68000 Mac ROMs was a feat reserved for a select few genius programmers who possessed both deep expertise in 68000 assembly language and the ambition to take on such a challenge... however, thanks to the power of AI and disassembler tools, even someone like me, who isn't a programmer can now create things like this, and I truly feel we are living in an amazing era! It has taken a bit of time, but I'm getting very close to the product launch. I expect will be able to announce the product to everyone around the time summer comes to an end. Stay tuned!
Comments