SE ROM Flash Tool 1.1, and how it got here!

The SE ROM-inator can now reflash every part of itself on the Macintosh SE itself, including swapping the main ROM between the early SE version and the FDHD one. The flash tool for the original ROM-inator is an excellent program, and I had to get it working on the SE ROM-inator one way or another.

Where it started

Steve Chamberlin started all of this, and his Plus ROM Flash Tool is the reason any of it exists. It runs on the Mac itself, unlocks the two flash chips, and rewrites them in 128K blocks. No chip puller, no programmer.

My first SE copy was his version 1.6 with the dialog redrawn to show SE addresses. The dialog got more radio buttons and a layout that fits the SE ROM. After that I cleaned up the definitions in Flash Tool.c and edited it in THINK C.

Writes that never arrived

Before any of that mattered, there was a bigger problem. Without changes to the hardware, the tool couldn't flash anything on an SE. It stopped with a flash ID error. The ID it read back was just the first bytes of the ROM, which means the unlock writes never reached the chips. The board at that point was Steve's Plus design, moved over to the SE as it was, and the chips at that point were SST39SF040s. Neither had anything wrong with it by design.

So I tacked a few gates onto the board and tested it. On the SE the ROM chip enable comes out of Apple's BBU chip, and it never once gave a flash chip a usable write cycle! I can't tell you exactly why. My guess is that the SE was never designed with writing to its ROM in mind. I doubt there's some other control path in there, but nobody seems to have documented what's inside the BBU, so I couldn't dig any deeper. On Steve's advice, I decided to generate the CE signal on the ROM-inator board itself. OE too, of course. That circuit began as a few 74HC02s and a 74HC74, became a 22V10, then a 20V8, and is now one GAL16V8 gated by /UDS and /LDS.

That's a post of its own. From here on, assume the hardware can write.

Version 1.0: a real SE build

I rebuilt the tool from his source in THINK C 5.0, running in Basilisk II. It got a new name, SE ROM Flash Tool, and every area now follows the SE ROM-inator's own memory map.

Area	Address	Size
ROM Code	400000	exactly 266,240 bytes
ROM Disk Image	441000	exactly 747,520 bytes
Startup Sound	4F7800	up to 28,672 bytes
Entire ROM	400000	exactly 1,048,576 bytes
Happy Mac Icon	40125C	exactly 20 bytes
Custom Address	you type it	up to 1,048,576 bytes

A file of the wrong size is refused and nothing gets written.

Happy Mac is a proper item now. The face is 16x10 pixels on the SE, the same as on the Plus, so in theory the faces Steve drew for the Plus ROM-inator drop straight in.

The startup sound took more thought. The SE ROM-inator always plays 14,760 bytes, a little under 0.7 seconds, no matter what you flash. Steve suggested the tool should take a sound of any length and deal with it. So a short file gets a 30 ms fade and is filled out with silence, and a long one is cut at 14,760 bytes with the same fade so it doesn't click. WAV and AIFF files are turned away, because their header would play as noise. One note: a hijacked startup sound can never be made completely free of noise. It's also fixed at about half of full volume.

THINK C fought me the whole way. I didn't really understand it myself, so when it finally built, I disassembled the app. All six write paths pointed at SE addresses and the Plus ones were gone.

Steve's code has handled two chips from the start, the SST39SF040 and the Am29F040. Those two erase in very different sizes. The SST has 128 sectors of 4K and the Am29F040 has 8 sectors of 64K. His tool keeps that difference inside the erase routine: it erases 4K sixteen times on the SST, or 64K once on the Am29F040, and from there on the writing is the same code for both. That's the kind of thing I admire in his work.

Version 1.1: the bomb

While I kept testing the tool, I tried ROM Code for the first time. Every flash I'd done before had been Entire ROM, and I hadn't noticed.

The progress bar got to the halfway mark and the Mac bombed. With the FDHD ROM file the box said "illegal instruction". With the early SE file it said "coprocessor not installed". I hit Restart both times and the SE booted normally, so I decided nothing had been written.

I was wrong about that. Comparing the two ROM Code files in 128K blocks, the way the tool writes them, showed why.

Block	Starts at	Bytes that differ, early SE vs FDHD
1	$400000	18
2	$420000	22,360
3	$440000	0

The difference starts at the floppy driver and runs to the end of the second block. The tool wrote block 1, which is where the bar hits the halfway mark. It wrote block 2, switched interrupts back on, and the running system jumped into a floppy driver that wasn't the one it had booted with.

So the write had worked. Each crash had quietly swapped my SE between the early ROM and the FDHD ROM, and I never saw it because both of them boot. Entire ROM had never shown the problem, because I always reflashed the version that was already in there.

Version 1.1 changes the order of things for ROM Code and Entire ROM:

1. Read the whole file first.

2. Hold the three blocks below $460000 in RAM. That's the main ROM and the block with the ROM disk driver.

3. Write everything else.

4. Close the file, flush the disk, turn interrupts off, and write those three blocks back to back.

5. Jump to the ROM's restart entry. Don't go back to the Finder.

The bar fills up, sits there for a second, and the Mac reboots. Sound, Happy Mac and ROM Disk updates work the way they always did. The extra buffer costs memory, so the partition went from 384K to 640K. Version 1.1 also adds support for an alternative flash ROM.

Once the real 1.1 was on the SE I ran the list: a sound, a Happy Mac, ROM Code of the same version, a swap to the early ROM, and a swap back to FDHD. No bombs...

One more thing, and it's a big one. To make the ROM disk boot I had to hijack the .ATP driver, and that cost the SE its AppleTalk. That's fixed now. AppleTalk works again with the ROM disk in place. I tested it over LocalTalk on the printer port and copied files from an AppleShare server. With that, this is finally a complete ROM.

We're almost ready to put this on sale. I can say for sure that there are no big bugs left, so once the small things are fixed it can be released. Stay tuned!