BMOW title
Floppy Emu banner

Archive for the 'ROM-inator' Category

ROM Hacking Tutorial with ROM-inator II

The ROM-inator II replacement flash ROM for the Mac II series and SE/30 comes pre-programmed with nifty new features for your vintage Macintosh. With the optional ROM SIMM Programmer, you can edit the ROM’s contents, altering the ROM disk or writing a different stock ROM image. But why stop there? For the truly adventurous, this tutorial will demonstrate how to patch the ROM code to alter the machine’s low-level behaviors. This is an advanced tutorial for major gear-heads, so hang on to your hat!

We’ll begin with the Macintosh IIsi ROM. It’s a universal ROM, meaning that even though it was designed for the IIsi, it also works in many other Mac models. The original IIsi ROM is just a 512K chunk of raw data, which you can find here. The ROM-inator II’s contents are also based on the IIsi ROM, with many modifications and additions. The latest ROM-inator II contents are available on the product’s web page, and at the time of writing it’s this file. Only the first 512K of the file is ROM code, and the rest is data for the ROM disk.

Hex Editor

To modify or patch the file, we’ll need a tool called a hex editor. I’ll be using a Windows hex editor called xvi32, but there are many other options for Windows, Mac, and Linux. Check out Synalyze It and Hex Fiend for some other examples. If we open the ROM-inator II file in xvi32, we’ll see this:


What’s all this? Running down the left side are the file offsets in hex. These are the same as the addresses within the ROM code. In the center panel, we see the actual bytes from the file, displayed in hex, 16 bytes per line. In the right panel we see those same 16 bytes again, but displayed as printable characters instead of as hex values. That’s not especially useful in this example, but it’s handy when examining ROM code that contains embedded string constants.

In the example above, the value at offset 32 is 6E, which is equivalent to the ASCII character ‘n’.


To do anything useful with this, we’ll need to understand how these bytes are structured and what they mean, so that we’ll have some idea how to modify them. In this case, we know that the bytes are 68000 machine code, so we can feed them through a 68000 disassembler to create a more human-readable version. As with the hex editor, there are many options for 68K disassemblers, including this slick web-based disassembler. Using the web disassembler to examine the first few bytes of the file, we’ll get output like this:


Once again, the left column shows the file offsets (ROM addresses), and the center column displays the actual bytes in hex. The column on the right displays those same bytes reinterpreted as 68000 machine code. The number of bytes per row is no longer fixed at 16, but instead varies with the size of the encoded 68000 instructions. Notice that the code is displayed using syntax normally employed for x86 disassembly, so it looks a bit odd for those people accustomed to 68K syntax. But even if we ignore the syntax, something about this code just looks wrong. It begins with a couple of strange move instructions, a negation, and OR-ing random-seeming registers with strange constants. It just looks wrong, and that’s because it is wrong. One of the limitations of disassemblers is that they struggle to distinguish code from data, and in this example the bytes beginning at address zero are mostly data. By attempting to interpret them as 68K code, we get garbage.

By employing some knowledge about the 68K CPU, we can make better sense of this. At reset time, the 68K initializes its stack pointer from address 0, and its program counter from address 4, then it begins executing code. So the first instruction to be executed will be the one whose address appears at offset 4 in ROM, which we can see from the hex dump is 4080002A hex. That may seem like a strange address, since it’s a 32-bit address far outside the range of the 512K ROM code. Once again, we need to employ some knowledge of Macintosh internals to know that the ROM is initially mapped into the CPU’s address space at 40800000. So 4080002A simply means offset 2A in the ROM. As it turns out, the instruction at 2A was disassembled correctly in the listing above, and it’s just a PC-relative jump to address 8C. If we try the disassembler again, this time feeding in the bytes beginning at 8C and adjusting the base address accordingly in the disassembler settings, we get something that looks more reasonable:


It begins by loading a value into the status register, which the 68000 manual tells us will disable interrupts. It then loads a value into D0 and stores it into the cache control register. More processor initialization follows. Whew! We can make sense of this, but it’s slow and tedious work.

A Mac-Specific Disassembler

For this work, a better disassembler is FDisasm, a 68K disassmbler with some Mac-specific intelligence. FDisasm is itself a vintage Macintosh program running under System 6 or 7, rather than a modern Windows or OSX application, so it’s normally run under emulation with the cross-platform Mini vMac emulator. In addition to simply disassembling the 68K code, FDisasm also replaces address and data constant values with their symbolic names, where those names are known from Apple reference sources or previous disassembly work. It even inserts some helpful comments into the disassembled code. To do all this, FDisasm needs to have formatting information with advance knowledge of the Mac ROM being disassembled. Unfortunately, the IIsi isn’t one of the ROMs for which FDisasm contains pre-supplied formatting information. But happily for us, Rob Braun has already done some work in this area, and created partial formatting information for FDisasm with the IIsi ROM. Using that formatting information, FDisasm generates this disassembly beginning at address 8C:


That looks much better! We see that address 8C has the label StartBoot, and other addresses and constants also now have meaningful names. It looks like the MOVEC instruction was disassembled incorrectly (a FDisasm bug?), but that’s a small matter. With disassembly at this level, we can finally begin to search for interesting sections of code to study, and eventually to modify.

Double Chime

As an example, we’ll walk through the construction of a ROM patch to make the Mac play the startup chime twice. Maybe it’s such a great chime that it deserves to be played twice? Poking through the disassembly, we eventually find some relevant code at address 45C0A:


While it’s not obvious, I can tell you from super-secret sleuthing that this code is called from a computed jump instruction at 4651A:


This code requires some explanation. At the point the boot chime is played, the Mac’s RAM hasn’t yet been configured, and there is no stack. That means the code can’t use the normal JSR/RTS mechanism to call and return from subroutines. If we examine the code at OrigBootBeep6, we’ll learn that it uses the A6 register as a return address, once it’s done playing the chime. So the line above that loads DT140 into A6 is setting the return address, which happens to be the address of the instruction immediately following the jump. To play two chimes, we’ll need to duplicate this block of code two times.

Patching code becomes problematic when the new code requires more bytes than the old code. The code contains many address cross-references, so we can’t simply shift the bytes down to make room for new code, the way we’d insert an extra word into a sentence in a text editor. Instead we need to find some unused area of the ROM, put the new, larger code into that area, and then modify the original code to jump to the new code. Finding a suitable unused area is as much art as science, but while skimming through the ROM disassembly, this jumps out at address 3CBE:


I’m going to hazard a guess that somebody named “Gary” worked on the IIsi ROM.

Gary appears to have filled up padding space with many copies of his name, which we can replace with new code. If we’re wrong and all those “Gary” bytes are actually necessary, the computer will crash horribly. Such is the excitement of ROM hacking. We want to insert some new code that plays the chime twice, then jumps back to the instruction just after the old code. Using the original code as a template, our new code should look something like this:

        MoveQ.L   $28, D0
        Lea.L     NEXT1, A6
HERE1:  Lea.L     ($XXXX), A0
        Jmp       HERE1(A0.L)
NEXT1:  MoveQ.L   $28, D0
        Lea.L     NEXT2, A6
HERE2:  Lea.L     ($YYYY), A0
        Jmp       HERE2(A0.L)
NEXT2:  Lea.L     ($ZZZZ), A0
        Jmp       NEXT2(A0.L)

where $XXXX and $YYYY are the offsets from HERE1 and HERE2 to OrigBootBeep6, and $ZZZZ is the offset from NEXT2 to DT140, the continuation point of the original code. We can compute those offsets by doing some hexadecimal math, subtracting the addresses where those instructions lie in the “Gary” area from the addresses we need to jump to. We’ll use the hex editor to do the actual patching work. Using xvi32 to view Gary’s ROM padding beginning at address 3CBE:


We can type directly into the center area of byte values to modify them. But what bytes should we type, to implement the new code that we want? Converting from assembly code to byte values is the job of an assembler, so we could use a 68K assembler like EASy68K to do the work. But in this case, almost all of the instructions already exist in the original code, so we can simply copy the assembled byte values from there, modifying the bytes that represent addresses as needed. For example, we can see from the original code that MoveQ.L $28, D0 assembles as the two bytes 70 28. Beginning with the first “Gary” at 3CC4, we’ll crib bytes from the original code, not yet worrying about the address offsets. The result looks like this:


The offsets require more careful study. First, we consider the instructions like Lea.L NEXT1, A6. While this looks like an absolute address, it’s actually a PC-relative address. Another FDisasm bug? An alternative 68K disassembler represents these same instructions as LEA ($C, PC), A6. This loads A6 with the address 10 bytes ($C hex) beyond the current program counter value. 10 is still the correct adjustment in our new code, so that doesn’t need to change. Next we consider the computed jump instructions like JMP HERE1(A0.L). While this looks like an absolute offset, it’s actually a PC-relative offset that the alternative disassembler shows as JMP (-$8, PC, A0.L). Once again, -$8 is also the correct adjustment in our new code, so that doesn’t need to change either.

The XXXX, YYYY, and ZZZZ offsets are the only values that need to change. In the original code, the instruction was:

46514  41F9 FFFF F6F6 DT139:   LEA.L (-$90A), A0

46514 was the address, 41F9 was the instruction opcode, and FFFFF6F6 was the (negative) offset. So we need to find the three instances of the bytes FFFFF6F6 in the new code, and modify them to the correct offsets for OrigBootBeep6 (twice, from HERE1 and HERE2) and DT140. After applying some math, these offsets turn out to be 00003388, 00003378, and 0004283A, respectively.


Finally, we need to patch the original code, so that it jumps to the new code. To do this, we’ll perform a similar hex calculation to subtract the original code’s address from the “Gary” address at 3CC4. We only need to modify the offset in the instruction at address 46514 to point to our new code instead of directly to OrigBootBeep6. This is a little bit sloppy, as D0 and A6 will end up getting set redundantly, but it’s simpler than modifying that whole block of code at 4650E.

Beep! Beep!

That’s it! The modified ROM file is here.

This should give you a sense of the kinds of ROM modifications that are possible with the ROM-inator II and the ROM SIMM programmer. Patching the ROM can be challenging work, but with a little imagination and patience almost anything is possible.

Read 9 comments and join the conversation 

SIMM Programmer for ROM-inator II


SIMM programmers are now available for the Mac ROM-inator II customizable Macintosh ROM SIMM. If you’ve been waiting for your opportunity to go nuts with ROM hacking, here it is! With a ROM-inator II and this SIMM programmer, you can tweak the Mac’s lowest-level firmware to your heart’s content. Get one now at the BMOW Store.

  • Tired of the pre-programmed ROM disk image in the ROM-inator II? Replace it with a new one!
  • Want to know what happens if you put a Mac LC ROM in a Mac IIci? Download the archive of stock ROM images and try it.
  • Ready to make your own ROM hacks? Use 68K disassembly tools and your favorite hex editor to patch a “universal” ROM like the Mac IIsi, and see what crazy things you can accomplish. With the right tools and plenty of patience, you can change the system icons and fonts, change the startup behavior, modify system sounds, and much more.

The programmer is a USB peripheral, and connects to your PC with a standard USB B Mini cable (not included). The programmer utility software provides an easy GUI for updating the contents of the ROM SIMM’s flash memory. The utility program is compatible with Windows 7 or later, but you can make it work on OSX or Linux if you compile the software for yourself. It’s based on Qt and should be easily portable.


The programmer board has an integrated on/off switch for convenience. Please connect the USB cable and insert the SIMM into the socket before switching the power on. Hot-plugging the ROM SIMM or the programmer itself may cause damage. Yes, I am paranoid.


You may be wondering why the programmer PCB is a 6-sided flying saucer shape. In order to fit within the standard 10 x 10 cm area used by many PCB manufacturers, I had to rotate the SIMM socket 45 degrees and place it on the diagonal. The microcontroller and other components all fit within the space on one side of the socket, so I deleted the region of the PCB on the other side of the socket rather than leaving it empty. But that left a rather awkward-looking truncated triangular thing, and it offended my design sense. After some thought, I decided to redefine which way was “up”. I turned the diagonal into a new bottom, and clipped the third corner to match the other two, resulting in a completely unique board shape.

Read 2 comments and join the conversation 

Introducing the Mac ROM-inator II

Mac ROM-inator II rominatorii-front-and-back

Say hello to a new retro-computing gizmo – the Mac ROM-inator II! It will supercharge your vintage Macintosh II series or SE/30 computer, by replacing the stock ROM with a programmable flash memory module. Add a bootable ROM disk, change the startup sound, hack the icons, gain HD20 support and a 32-bit clean ROM. Go nuts! The Mac ROM-inator II is available now in the BMOW Store.

The flash ROM comes pre-programmed with a custom ROM image with the following changes as defaults:

  • Customized startup chime – major 9th arpeggio
  • ROM disk image provides a diskless booting option
  • New startup menu screen displays installed RAM, addressing mode, and ROM disk details
  • Built-in HD20 disk support
  • 32-bit clean
  • Memory test is disabled for faster booting
  • Happy Mac icon is replaced by a color smiling “pirate” Mac

The ROM-inator II is derived from Doug Brown’s original Mac ROM SIMM design, used with permission. A portion of sales goes back to Doug.

ROM Hacking Magic

All the early Macintosh computers have some low-level functions stored in ROM. It’s the Mac equivalent of a PC’s BIOS. These ROM routines are responsible for initializing the computer when the power is first turned on, checking to see what hardware is installed, finding an attached disk with OS software on it, and booting that OS. Even after the OS has booted, the ROM routines still handle many low-level functions like interrupt handling, keyboard support, and floppy I/O, as well as some higher level functions like drawing windows and icons. If you can control the ROM, you can control virtually everything in the computer.

Nearly every member of the Macintosh II, Quadra, and LC families has a 64-pin ROM SIMM socket on the logic board. In some cases, the stock ROM is in this socket. In others, the stock ROM is soldered directly to the logic board, but it can be overridden by a ROM SIMM in the socket. All that’s necessary is to figure how to build a ROM SIMM that’s physically compatible, and then program it with appropriate software. A few years ago, the important details were reverse-engineered by Doug Brown and others at in an epic forum thread that stretched to over 1000 posts.

The ROM-inator II is a standard PCB, shaped and sized to fit the ROM SIMM socket. It comes pre-programmed with a base ROM image that’s modeled off the Mac IIsi ROM. This is a universal ROM that’s also capable of working in many other members of the Mac II family, including the SE/30, Mac IIx, IIcx, IIci, and IIfx. By patching key ROM functions, it’s possible to alter the Mac’s behavior in fundamental ways – a new startup chime, support for additional disk types, and a modified Happy Mac being a few examples. All it takes is a 68K disassembler and a lot of patience.


The stock ROM in most Macs of this period was around 512K in size, but the Mac’s address map devotes a full 8MB to ROM. In a normal Mac, the rest of this address space is unused. The ROM-inator II uses larger flash memory chips to take better advantage of the available address space. The first 512K of flash memory is used for the actual ROM code, and the rest is available for interesting goodies like a ROM disk image. Rob Braun’s original romdrv paved the way for ROM booting, and I’ve made several enhancements, including a startup menu and support for compressed disk images.


The pre-programmed ROM image is compatible with the Macintosh IIx, IIcx, IIci, IIfx, IIsi, and SE/30. The Mac ROM-inator II module is physically compatible with any Macintosh having a 64-pin ROM SIMM socket, except the Quadra 660AV and 880AV. This includes the previously mentioned models as well as many other Quadra, LC, and Performa models. For these other models, the flash memory will need to be reprogrammed with an appropriate ROM image.

For a similar ROM upgrade for the Macintosh Plus, 512Ke, 512K, and 128K, see the original Mac ROM-inator Kit.

HD20 Support and 32-Bit Clean ROM

A nice benefit of the pre-programmed ROM image is to add built-in support for HD20-type hard disks, such as the HD20 hard disk emulation mode of the BMOW Floppy Emu. The Macintosh IIx, IIcx, IIfx, and SE/30 lack HD20 support in their stock ROMs, so this replacement ROM enables those machines to use HD20 disks.

The pre-programmed ROM image also makes the Mac 32-bit clean, enabling it to use more than 8MB of RAM natively without the need for special system enablers or extensions. Some older Macintosh models like the IIx, IIcx, and SE/30 have stock ROMs that are “dirty”, meaning they can’t support 32-bit addressing without ROM patches. Using the Mac ROM-inator II and the pre-programmed ROM image, the Mac SE/30 can support up to 128MB of RAM!

ROM Disk

ROM Disk

The built-in ROM disk is a 5.5MB bootable disk image containing System 7.1 and a collection of classic games. Using the ROM disk, it’s possible to create a diskless workstation without any physical disks attached. Once booted from the ROM disk, Appletalk file servers can also be mounted over a local network.

The ROM disk image is stored compressed in the module’s flash memory, and is decompressed on the fly as needed, in order to squeeze the largest possible disk image into the available space. This requires 1MB of RAM for caching of decompressed disk sectors, so a minimum of 2MB total system RAM is required. The ROM disk can be mounted as read-only, or as a read-write RAM disk.


When first powered on, the Macintosh will play a customized startup sound, and display diagnostic info about the amount of installed RAM, the current addressing mode, and the detected ROM disk type. After a moment, a startup menu will be displayed. To boot from the ROM disk as a read-only disk, press the R key on the keyboard. Or to convert the ROM disk into a writable RAM disk, press the A key. If no keys are pressed after five seconds, the Macintosh will boot normally from an attached SCSI disk, or wait for a floppy disk to be inserted.

romdrv-splash romdrv-splash2


The Mac ROM-inator II’s flash memory can be reprogrammed using an external SIMM programmer, providing the ultimate in customization. There’s 4MB of flash memory available for any purpose, like a custom ROM disk image, alternate ROM code, digitized sounds, user interface tweaks, or other crazy experiments. Using compression, this is enough for the base 512K ROM image plus a roughly 5.5MB uncompressed disk image. Or fill the whole space with a collection of different base ROMs, selected from a startup menu. Go crazy!

Programmer software

The SIMM programmer is currently a DIY project you can build yourself. See the schematics and PCB files, firmware, and host software on GitHub.

A second-generation SIMM programmer will be ready at the BMOW Store in summer 2016.

Happy ROM hacking!

Read 12 comments and join the conversation 

Changing the Macintosh Start-Up Sound

Beep! Wouldn’t it be fun to customize the cheery little square wave greeting of your Mac 512K or Plus? With a Macintosh ROM-inator kit installed, now you can. This isn’t a control panel like SoundMaster, that plays while the OS is loaded from disk – it’s the sound that you hear the moment you flip on the power switch. On a normal vintage Macintosh, this sound is generated on the fly by code in ROM, but with ROM-inator you can alter this behavior and create any kind of sound you’d like. Let’s get started!

This tutorial assumes you already have a ROM-inator kit installed in your Mac 512K, 512Ke, or Plus. If not, follow the link to learn more or buy a kit. The ROM-inator is capable of many customizations beyond just startup sound hacks, including making a bootable disk contained entirely in ROM.

The steps below may look long and complex, but that’s because I want to be thorough and avoid skipping any details. In a nutshell, all that’s necessary is to convert a sound to the proper format, optionally patch a byte in ROM to reflect the sound’s duration, and then use Flash Tool to store the new sound in ROM.

Making the Start-Up Sound

First, you’ll need a sound sample to replace the default beep. This can be something you recorded yourself, or a sound downloaded from a source like The ideal sound will be 0.66 seconds in duration, matching the length of the standard beep sound, but durations from 0 to 1.3 seconds are possible if you’re willing to do a small amount of extra hacking as explained below. For this exercise, I’m going to use the MOOF! sound of Clarus, the DogCow, which I found here. The DogCow was the mascot of Apple Developer Technical Support for many years during the vintage Macintosh era.

Next, you’ll need to convert your sound to mono 22 kHz 8-bit unsigned raw format. The free audio tool Audacity can do this, converting from other formats like WAV or MP3 if necessary. The “moof” sound is a WAV file, so let’s open it with Audacity and take a look:


The moof sound is just under 1.5 seconds in duration – longer than the 1.3 second limit. Fortunately everything from about 1.2 seconds onward is just silence, and can be deleted. In the Audacity window, click the mouse in the timeline at 1.2 seconds, then drag it to the right to select the range from 1.2 seconds onward. Then hit the delete key on your keyboard, and everything from the 1.2 second mark to the end will be removed. In my case, I ended up with a sound that Audacity said was 1.203 seconds in duration.

The screenshot shows that the moof sound is mono 8 kHz 32-bit float format, so it needs to be converted. First, change the “project rate” selection in the lower-left corner to 22050. Then go to the File menu, and select “Export…”. In the dialog box that appears, press the Options button, and select RAW (header-less), Unsigned 8 bit PCM. The “Save As Type” should be set to “other uncompressed files”. Then save the converted file. If a box appears asking for metadata, ignore it and save. See screenshots:



Adjusting for Sound Duration

If your sound is 0.66 seconds long, then you’re done – you can move on to the next step below, storing your new sound in ROM. But if the sound is longer or shorter than 0.66 seconds, you’ll need to make a one-byte change to the Mac ROM startup sound routine. If you don’t make this change, your sound will either be cut off too early, or will keep playing past its end while interpreting random memory as sound data. It won’t hurt anything, but it won’t be very pleasant for your ears.

Download the file code-patched.bin, which contains the default ROM code for ROM-inator. (By the time you read this, the version linked here may be out of date – see the ROM-inator main page for the latest version.) You’ll need a binary editing tool such as xvi32 to make a one-byte change to this file. Open the file, and examine the byte at offset 0xEF hex, which is offset 239 in decimal. The value at that offset should be 0x28 hex, or 40 decimal. This is the duration of the startup sound, in sixtieths of a second.


Multiply the duration of your sound by 60, truncate the result to a whole number, and write it at offset 0xEF, replacing the 0x28 value that was there previously. My sound is 1.203 seconds, times 60 is 72.18, so I’ll write the value 72 decimal, which is 0x48 hex. Then save the modified file as code-patched-for-sound.bin.

Storing the New Sound

The last step is to copy the files you created onto your vintage Mac. You’ll need to copy the new sound file, the duration-adjusted ROM code (if any), and the utility program Flash Tool (found on the ROM-inator page). My preferred way to copy the files from a modern PC to a Mac Plus is with Floppy Emu, but it can also be done via a Localtalk network, or by using another Macintosh as a bridge machine for copying to an 800K floppy disk. With Floppy Emu, I put a blank 800K disk image file on my SD card, use a tool like HFVExplorer (Windows) or Fuse HFS (Mac OS X) to copy the files into the blank disk image, then put the SD card in the Floppy Emu and connect it to the vintage Mac.


Run Flash Tool on the Mac, and click the radio button to indicate you want to update ROM with a new startup sound. Select the sound file you made, and hit the “Update ROM” button to perform the update. The process only takes a few seconds. If your sound’s duration was not 0.66 seconds and you made a duration-adjusted ROM code file, you’ll need to store that in ROM too. Click the radio button to indicate you’re performing a ROM code update, select your code-patched-for-sound.bin file, and apply the update.

Happy sound hacking!

Read 1 comment and join the conversation 

ROM-inator Back in Stock

rominator-board-350-2 rominator-installed-372

The Mac ROM-inator kit is back in stock! The ROM-inator replaces the stock ROM with 1MB of re-writable flash ROM in a Macintosh Plus, 512Ke, 512K, or 128K – making it possible to do all sorts of crazy customizations! The new kit has an updated default ROM image, with a new boot chime, modified Happy Mac icon, and System 6 ROM disk with a small collection of built-in apps and games. All these defaults can be changed by updating the flash memory. Personalize that old compact Mac, and make it fun again!

Be the first to comment! 

ROM-inator Disk Setup Tutorial


The Mac ROM-inator kit adds 1 MB of rewritable flash memory to your vintage compact Macintosh. A bootable ROM disk is one of many interesting possibilities this creates. The kit comes with a preprogrammed System 6.0.8 boot disk image, but how can you edit the disk image or replace it with a different one? My previous description skipped over some steps that may not have been clear to everyone, so read on for a detailed tutorial on creating and transferring the disk image.

Creating the Disk Image

The first step is to download or create a new disk image file, to be used for the ROM disk. These files normally end with a .dsk filename extension, and are commonly used with Macintosh emulation tools and disk copy programs. The Floppy Emu disk emulator also uses .dsk files, so if you’ve already got an Emu, you can probably use one of your existing disk image files as a ROM disk. You can also download .dsk files for many old system versions, utilities, and games at As long as the file isn’t larger than 864K, and contains bootable system software, it should work.

But using an existing disk image is boring. What if you want to create a custom disk image, with your own personal collection of games? There are many ways to do it, including the tools HFVExplorer (Windows) or Fuse HFS (OS X). The method I’ll describe here uses a popular software-based Macintosh emulator called Mini vMac. We’ll use this software to set up a new .dsk file, and fill it with goodies.

  1. Download Mini vMac here. It supports OS X, Windows, Linux.
  2. Before you can run Mini vMac, you’ll need a Macintosh ROM file (vMac.ROM) and system disk. You can find both in this tutorial file archive.
  3. Move vMac.ROM into the same folder as the Mini vMac application you just downloaded, and follow the setup instructions. When the instructions ask you to drag your bootable disk image, use the file HD20.dsk from the previous step’s file archive.


You’re now running an emulated Mac Plus! You can attach additional disks by simply dragging the .dsk files into the Mini vMac window. Unlike a real Plus, you can have many disks attached all at the same time. Let’s create a bootable disk image for use with the ROM-inator, containing a few classic Mac games.

  1. The archive contains an empty 864K disk image file called rominator-disk.dsk. Drag this file into the Mini vMac window.
  2. Download .dsk files for Klondike, Brickles, MacMan. Drag these into the Mini vMac window too.

You should now have five different disks mounted in Mini vMac:


  1. In Mini vMac, drag the System Folder from the System Startup Disk to ROM-inator Disk. This copies the system software, and makes ROM-inator Disk a bootable disk.
  2. Copy the games from the other disks onto the ROM-inator Disk. Some of the game disks also contain System Folders. Don’t copy these – only copy the games themselves.

You should now have a finished ROM-inator Disk:


Drag the ROM-inator Disk icon to the trash can to unmount it. Your finished ROM disk image is now stored in the file rominator-disk.dsk.

Transferring the Disk Image

Now that you have a disk image file, how do you get it onto your Macintosh so you can write it to the ROM-inator? Once again there are several ways to do it, including connecting your compact Mac over Localtalk to a slightly less ancient Mac that also has Ethernet, or using an external SCSI drive to sneakernet the file from another computer. But the simplest method is to use a Floppy Emu configured as a hard disk emulator in HD20 mode.

Normally you would copy a .dsk file to the Floppy Emu’s SD card, so you could use it on the Macintosh as if it were a real disk. But in this case, we actually want the .dsk file itself transferred to the Mac, which means we need to put the file rominator-disk.dsk inside another disk image. We’ll use Mini vMac again.

  1. Start Mini vMac.
  2. When you see the blinking question mark, drag HD20.dsk into the Mini vMac window.
  3. In Mini vMac, on the System Startup Disk, you’ll find a program called ImportFl. Double-click the icon to run it.

ImportFl will now wait for a file to import from the host operating system:


  1. From your OS X, Windows, or Linux desktop, drag the file rominator-disk.dsk into the Mini vMac window.
  2. When prompted, choose a destination on System Startup Disk to save the file. Any location is fine – just remember where you put it, so you can find it later.
  3. Quit ImportFl.

rominator-disk.dsk is now stored as a data file, inside HD20.dsk.


  1. Exit Mini vMac.
  2. Copy HD20.dsk to Floppy Emu’s SD card.
  3. If you haven’t already, update your Floppy Emu with the latest HD20-aware firmware. You can download the firmware from the Floppy Emu product page.
  4. Connect the Emu to your Mac, and turn it on. If necessary, press SELECT while the Emu is displaying version info on the LCD, in order to switch into hard disk emulation mode.
  5. Reset the Mac. It will boot from the HD20.dsk image on the SD card.

rominator-disk.dsk is now visible as a regular file, on the System Startup Disk mounted by your Mac.

Writing the Disk Image

The final step is the easiest – writing the new disk image to the ROM-inator. The utility program Flash Tool makes this easy, and to make it even easier, Flash Tool is already included in the HD20.dsk image.

  1. On your Mac, on the System Startup Disk, you’ll find a program called Flash Tool. Double-click the icon to run it.
  2. Under the heading “ROM Area to Update”, select ROM Disk Image.
  3. Press the Select File… button, and browse to the location where you previously stored rominator-disk.dsk. Select this file.

The Flash Tool setup should now look like this:


  1. Press the Update ROM button. You’ll see a progress bar while it’s working. The update takes about 60 seconds.
  2. When the update is finished, reset your Mac.

You’re done! It looks like a lot of steps, but the whole process only takes a few minutes. Your new disk image is now stored in flash memory by the ROM-inator. Whenever you turn on your Mac, you’ll see the “press and hold R now” message. To boot from the ROM disk, press and hold the R key on the keyboard for a few seconds. If R is not pressed, the Macintosh will boot normally from an attached SCSI disk, or wait for a floppy disk to be inserted.

Have fun!


Read 6 comments and join the conversation 

« Newer PostsOlder Posts »