This funny-looking device is a DC barrel plug to Apple IIc DIN-7 adapter, inspired by last week’s musings on constructing a battery-powered IIc. The adapter makes it possible to power an Apple IIc with a standard DC supply between 9V and 20V, or a suitable battery pack with a DC plug. The supply or battery should be capable of delivering at least 20 watts, or about 1.67 amps at 12V.

For my experiments, I used a Belkin BU3DC001-12V, which is essentially a fancy 12V 7.2Ah battery with built-in charging circuitry, output regulation circuitry, and fuse. It’s intended to be a backup battery for VOIP systems, but can easily be repurposed for any 12V DC application. Best of all, it’s only about $20 used, which is hardly more than the cost of the battery itself.

The current draw estimates from my earlier post proved to be about right. When running from the 12V battery, the IIc pulls about 1.5 amps for a few seconds while the floppy drive spins. Once the drive stops, the current drops down to about 700 mA. Given the 7.2 amp-hour capacity of the Belkin unit, that ought to be enough for several hours of battery-operated IIc fun.

Building your own DC to IIc adapter is simple, and only requires some wire and a few dollars in parts.

Female DC Jack to Screw Terminal Connector – $1.99
DIN 7 Pin Plug Set – $6.21

 
Video

If you’re wondering why there’s no funny video here of a IIc running in the woods, it’s because I’ve only solved half the problem. A battery-powered IIc is pretty useless without a battery-powered monitor to use with it. Fortunately, 12V DC powered LCDs with a composite video input aren’t difficult to find. Many portable DVD players and car entertainment systems can do that job. To power it, I could build another custom cable to run the monitor and the Apple IIc off the Belkin battery, but I’m going to be lazy and simply buy this splitter:

12V Splitter Cable – $6.59

It remains to be seen how much current the monitor will draw from the battery, but hopefully not much. I’ll report again when I have solid numbers.

While I already have a portable DVD player that will work here, its 5 inch diagonal is a little bit underwhelming. I also have a much nicer 14 inch LCD monitor that runs from 12V DC, but it only has a VGA input and no composite input. I’ll keep my eyes peeled for an LCD that’s 9 inches or larger, running from 12V DC, with a composite video input, to create the ultimate battery-powered Apple IIc system. Then I can… um… OK, I admit there’s no real point to this project. 🙂

Read 3 comments and join the conversation 

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’.

 
Disassembler

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 10 comments and join the conversation 

After 7 years of sitting quietly in storage, my BMOW 1 hand-made computer is ready for a new public appearance! I’ll be exhibiting at the Vintage Computer Festival, August 6-7 in Mountain View, California. Along with BMOW 1, I’ll also be demonstrating Nibbler, 68 Katy, and some other home-made CPU madness. Come join the fun!

If you don’t remember BMOW 1, it was my first adventure into homebrew digital electronics, and it gave birth to this blog. The machine itself is a custom-designed 8-bit CPU, implemented with 7400-series TTL logic and a few PALs. Built around this is peripheral hardware for I/O, sound, and video. The end result is a custom creation that’s vaguely similar to an Apple II in its performance and capabilities.

Remember these photos from 2009? BMOW 1 was built on a large wire wrap board, with about 2500 individual hand-placed wraps connecting all the components. I had a giant spreadsheet to keep track of it all. It took over a year. I think I was insane. There’s no way I’d do that again now. 🙂

In preparation for VCF, I dug BMOW 1 out of storage. It still works! That’s a good thing, because I’ve forgotten most of its details and it’s unlikely I’d be able to repair it now. The Maker Faire 2009 demo was still loaded in ROM, so I spent a little while playing through the demos and listening to some rocking chip tunes. You know what? That thing is pretty fun.

I had a “doh!” moment in connection with the VCF exhibit. After Maker Faire 2009, I saved all the printed materials, posters, schematics, code listings, photos, stickers, and other materials you can see in the booth photo above… until last weekend when I threw them all in the trash. Then just days later, I was invited to exhibit at VCF.

There’s one important mod I need to make before August 6. At Maker Faire there must have been a thousand people who came to see the “big mess of wires”, and went away disappointed when they learned that the wires were hidden out of sight in the final BMOW 1 case. The case has a transparent top to showcase all the chips, but the wire wrap is on the bottom side of the board and is rendered invisible. That’s a shame.

For VCF I’d like to make both sides of the board visible. That means standing the case vertically, and cutting a window into the bottom of the case, both of which worry me. A vertically-mounted case creates a risk it can tip over and get damaged, so it will need some very sturdy feet or anchoring system. And cutting a window in the big steel bottom plate… I stink at anything related to metal working. For the original case design, I cut some much smaller openings in the case with a Dremel tool, and it was incredibly slow. I also destroyed the Dremel in the process.

Read 1 comment and join the conversation 

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 

I’ve got the crazy idea in my head to run an Apple IIc system completely from battery power, so I could take it on the road. I know it’s possible – there’s already one person selling a pre-made kit. That’s a nice solution, but the pictured setup involves an automotive jump-start battery that costs around $150. Would something simpler be possible?

The Belkin Residential Gateway Battery Backup pictured above is designed to keep your VOIP phone or similar device working during a power outage, but it’s found a second life as a popular portable 12V supply for electronics projects. Inside the Belkin unit is a 12V/7.2Ah lead-acid battery. It charges from a standard AC wall outlet, and has a DC barrel plug for connection to the powered device. Hack that off and attach a 12V car cigarette lighter receptacle, or other connector of your choice, and you’ve got a nice little portable power source.

Is 7.2Ah enough to do anything interesting? To answer that question, we need to know how much power an Apple IIc requires. My Apple original AC adapter says it outputs 15V @ 1.2 amps. The IIc can accept any DC voltage between 9V and 20V, so the Belkin’s 12V should be fine here. 15V @ 1.2 amps is 18 watts, and to get the same power at 12V we would need 1.5 amps. That tells us the maximum power the AC adapter can deliver, based on what’s printed on its case.

What about the average power? That’s much more relevant, if we’re trying to estimate the possible run time while connected to a battery. I used a Kill-a-Watt to measure the AC adapter’s power draw from a wall outlet, and it was 12 watts while the IIc was idle doing nothing. So the adapter draws 12 watts from the wall, and delivers something less than 12 watts to the IIc, depending on its efficiency. I don’t know if it’s a switching regulator, or how efficient it is, but I’ll be generous and assume it’s 75% efficient and delivers 9 watts to the IIc. If my reasoning is correct, that means a IIc at idle would draw 0.75 amps from a 12V battery (9 watts).

Back to the Belkin unit: its 7.2Ah battery should theoretically be good for 9.6 hours of runtime, assuming the average power draw of the IIc is close to the idle draw of 0.75 amps. 9.6 hours seems a bit hard to believe, but I’ll go with it for the moment.

Now what about a monitor to use with the computer? Fortunately I’ve got an old portable DVD player with a composite video input that I know works with the IIc. And the DVD player runs off 12V! I haven’t measured its power draw, but I don’t think it can be more than the IIc itself. I’ll assume it’s equal to the IIc’s draw, so the total battery runtime of a IIc with DVD player / monitor would theoretically be 4.8 hours.

If the Apple IIc used any type of standard DC power connector, I’d give this a try right now. Instead, I need to go digging for a female DIN-7 plug. Why must every vintage Apple system include some kind of obscure connector? 🙂

Read 15 comments and join the conversation 

Oh man, this is good! You’re looking at the first DB-19 connector to be made in the 21st century:

This is a happy story about the power of global communication and manufacturing resources in today’s world. If you’ve been reading this blog for any length of time, then you’ve certainly heard me whine and moan about how impossible it is to find the obscure DB-19 disk connector used on vintage Macintosh and Apple II computers (and some NeXT and Atari computers too). Nobody has made these connectors for decades.

I’ve got a disk emulator product called Floppy Emu that attaches to an Apple DB-19 port, so I need a steady supply of these connectors to build my hardware, and that’s a problem. Over the past couple of years, I’ve scrounged what seems like every warehouse and basement on the planet, and bought up nearly the entire world’s remaining supply of new-old-stock DB-19 connectors. My last few product batches included DB-19s from some very obscure international sources. It was clear I’d reached the end of the road.

This wasn’t a surprise. The DB-19 shortage first became obvious to me about a year and a half ago, when a manufacturing error forced me to replace all the DB-19 connectors in a batch of boards, and replacements couldn’t be readily found. Since then I’ve written a dozen times about the impending DB-19 doomsday. I also made several attempts to design a DB-19 substitute using a small PCB and suitably-arranged header pins, but while they more-or-less worked, I wasn’t satisfied with the result.

The specific part in question is a D-SUB DB-19 male solder cup connector, sometimes called DB-19P. It’s very similar to the more familiar DB-9 (old style serial ports) or DB-25, but with a different width to accommodate the different number of pins. “But wait!” says the well-intentioned blog reader, “this web site over here has DB-19P connectors for sale right now!” They may claim to have them, but trust me, they don’t. Electronics parts suppliers seem to make a habit of listing available items that aren’t actually available, whether out of laziness or as an intentional bait-and-switch, I’m not sure. But if you call them or try to actually order the parts, you’ll find they don’t exist.

 
Custom Manufacturing

About 15 months ago, I first started looking into the idea of manufacturing new DB-19 connectors. So here’s the thing – how do you go about having something like this made? I had no clue, and it took me over a year. How do you find factories that might possibly build something like this, and then how do you find a contact person to whom you can explain your needs? Almost all the manufacturers that I talked to blew me off, or wouldn’t even talk to me at all. The US-based manufacturers weren’t interested, or couldn’t do it. In the end, I went through Alibaba listings for companies that make other types of D-SUB connectors, and emailed several dozen of them to ask if they could make a DB-19. Only a few even replied, and only two said they could, both located in China.

The estimated cost was eye-watering – a minimum order size of 10000 pieces and a total cost well into five figures. I had naively assumed that somebody might still have old DB-19 molds they could reuse, or that DB-25 tools could somehow be easily adapted to make DB-19 connectors. Nope. I did a lot of research into possible alternatives like 3D printing or alternate materials, but nothing looked viable. And given the tiny scope of my disk emulator business, I couldn’t justify spending tens of thousands of dollars for making new DB-19s.

So nothing happened. A year passed, and the DB-19 shortage grew more dire still. I made another attempt at designing a DB-19 substitute, but wasn’t satisfied with the results. Out of options, I reluctantly circled back to the manufacturing idea again. I tried to calculate how many years of future sales it would take before I could earn back my investment, and it was a depressingly large number.

But just as I was getting discouraged, good luck arrived in the form of several other people who were also interested in DB-19 connectors! The NeXT and Atari communities were also suffering from a DB-19 shortage, as well as others in the vintage Apple community, and at least one electronics parts supplier too. After more than a year of struggling to make manufacturing work economically, I was able to arrange a “group buy” in less than a week. Now let’s do this thing!

 
Let’s Build It!

Early on, it became clear they’d need more specific directions than simply “make it like a DB-9 but with more pins.” They wanted mechanical drawings and specifications for the part. Umm… They asked for information from my engineering department. Er… I was stumped by this for a short while, but then I found an old mechanical drawing of a DB-25. I photoshopped that sucker, edited some key measurements, and that was what they used for the very expensive mold-making process. I’m still kind of shocked that this actually worked.

Payment required wiring a Very Large Amount to a bank in Hong Kong – no PayPal accepted here. I’m sure the people at my bank thought I’d been duped by some kind of Nigerian 419 scam. Maybe it’s more common elsewhere, but transfers of this type are rare at US retail banks. In my case, it took the branch manager and 30 minutes of paperwork to get the transfer done.

Two months passed, and a round of prototyping. Progress was slow but steady, and I received updates from the manufacturer every few days. I kept waiting, eagerly anticipating this DB-19 bounty. At the end of May the product finally shipped, only to disappear into a US Customs black hole somewhere for a couple of days. Then at long last, after what felt like an infinite wait, I came home to find 10000 of these beauties stacked on my doorstep:

For the moment at least, I have nearly the entire world’s supply of DB-19 connectors, stacked in my living room. I think I’m going to fill the bathtub and swim in them.

Next step: re-ship the majority of these DB-19 connectors to the other people in the group buy. They should start becoming available in small quantities at electronics parts suppliers in a couple of weeks.

Assuming Floppy Emu sales continue apace, I’ll eventually make back my investment in a couple of years. If not, it will at least make for a good story. 🙂 Now, let the retro-hardware celebration begin!

Read 65 comments and join the conversation