All good things must come to an end, and today it’s the end of the Macintosh ROM-inator II SIMM and SIMM programmer. The DIY ROM-inator I kit was discontinued a year ago, and now the ROM-inator II is also being retired. I hate to see it go, but as I’d cautioned more than year ago, this was inevitable.

The ROM-inator II SIMMs (both standard and MEGA sizes) use a set of 16 megabit 5 volt flash memory chips to interface directly with the Macintosh bus. There was only one manufacturer still making this chip, and they moved it to “end of life” status in March 2018. Supplies dwindled, prices went up, and now they’re all gone. The 64-pin SIMM socket needed for the SIMM programmer became similarly hard to get, with only one known remaining supplier with a finite number of new-old-stock parts.

Both technical challenges might be solvable, with enough effort. Perhaps level converters with 3.3 volt flash memory could be integrated on the SIMM. The top edge of the SIMM might be redesigned with a different edge connector to fit a programmer socket that’s still commercially available. But candidly, the ROM-inator was always a somewhat poor value proposition for me, requiring more effort to maintain and support than was reasonable given its sales. I’m not interested in a big new engineering effort to redesign the hardware now.

There are also some issues on the software side that would need attention, if the ROM-inator II were to continue. There’s an unknown bug involving the SIMM programmer’s bootloader, which often causes the programmer to fail to be detected by the software. On MacOS Sierra and later, the software requires an awkward series of quitting and restarting before it will successfully connect. The driver and software application also need to be digitally signed, to shut up the warnings from the latest versions of Windows 10 and MacOS.

Smaller capacity 5V flash memory chips remain available, and I could conceivably design a “ROM-inator II Mini” with 512KB or 1MB of total storage. That would be enough for a modified system ROM with the new startup sound, new icons, HD20 support, and 32-bit clean ROM. But it would leave no space available for a ROM disk, and no way for users to reprogram the SIMM. And there’s already somebody on eBay who’s selling almost exactly that.

Thanks, ROM-inator. It’s been a fun ride!

Read 7 comments and join the conversation 

Happy birthday and merry Christmas, Apple II collectors! I’ve decided to make a gift of my design for an FPGA-based disk controller card, and release it under a Creative Commons – BY-SA license. This means anyone else is welcome to use it, modify it, build it, or sell it. And I hope they will! This mostly-finished design has languished for so long on my workbench, I finally decided it was better to let others take advantage of it than for it to gather dust forever. I know there’s economic value in what I’m giving away here today, but that value is only theoretical while I sit idle. It’s been almost a year since I last worked on the project, and almost two years since I began work on the design, and that’s too long. So here you go!

The only restrictions are on the terms “Yellowstone”, “BMOW”, and “Big Mess o’ Wires”. They’re not covered by this license, and are reserved for my exclusive use. If you build something based on this design, don’t use any of those words. You’ll need to pick a new name like Turbo-Disk Mega Ultra Elite.

You can download the design data here: FPGA disk controller Github repository

 
Ground Rules

Please don’t send me detailed questions and requests for help with this design, or expect me to be your engineering consultant. I’m releasing the design to the community because I don’t have time to pursue it myself. That means I can’t work on it for you, either. The design is released as-is, with no promise of technical support. I may be able to answer general questions, but the rest is up to you.

 
What is This?

Yellowstone is the code name for an Apple II disk controller card that’s based on an FPGA, rather than using discrete logic chips and ROM chips. By reprogramming the FPGA, the card can be made to emulate various other disk controller cards made by Apple in the 1980s and 1990s. The work so far has focused on emulating an Apple Liron disk controller card, but it would also be easy to emulate a Disk II controller card. It’s theoretically also possible to emulate a Disk 3.5 controller card, though this possibility has not been explored in detail.

 
What’s Liron?

The Liron disk controller was introduced by Apple in 1985. More formally known as the Apple II UniDisk 3.5 Controller, it’s designed to work with a new generation of “smart” disk drives more sophisticated than the venerable Disk II 5.25 inch floppy drive. The smart disk port on the Liron is appropriately named the Smartport, and it can communicate with block-based storage devices such as the Unidisk 3.5 (an early 800K drive) and Smartport-based Apple II hard drives.

Why care about the Liron? The Apple IIc and Apple IIgs have integrated disk ports with built-in Smartport functionality, but for the earlier Apple II+ and IIe, the Liron is the only way to get a Smartport. For owners of the BMOW Floppy Emu disk emulator, having a Liron card makes it possible to use the Floppy Emu as an external hard drive for the II+ and IIe. Unfortunately finding a Liron is difficult, and although they occasionally turn up on eBay, they’re quite expensive. That makes cloning the Liron a desirable goal.

 
How it Works

The FPGA disk controller card is little more than an FPGA, a voltage regulator, and a set of level-shifting bus transceivers. The FPGA replaces all of the 7400-series discrete logic chips typically found on a disk controller card. Verilog (hardware description language) replacements for all of the 7400-series parts and other logic were written and programmed into the FPGA. This also includes a full Verilog implmentation of the Apple IWM chip.

The FPGA also replaces the ROM chip containing the boot code for the card. The Apple II executes this code during power-up, and the code knows how to find and load sector 0 from the attached disk drive. The code was obtained from a ROM dump from a real Liron card.

The prototype card also includes a footprint for an 8-pin SPI flash memory chip. It is not used by the current FPGA code, and the chip can be omitted. The idea was that a small number of disk images could be stored in SPI flash memory, so the card could function both as a disk controller and as a disk emulator, but this was never implemented.

The card has a standard 10 x 2 pin disk connector on board. It can be connected directly to a BMOW Floppy Emu disk emulator, using a standard ribbon cable. But for a full Liron clone and connecton to a Unidisk 3.5, a DB-19 female connector is required. A design for a DB-19F adapter PCB is included here, and the adapter can be connected to the disk controller card with a short ribbon cable. The DB-19F is still available from surplus electronics suppliers in small quantities.

 
Project Status

See here for a complete history of work involving the FPGA disk controller.

The FPGA disk controller card was designed by Steve Chamberlin at Big Mess o’ Wires during the summer of 2017, but the first prototype card wasn’t built and tested until January 2018. The version 1.0 card had errors with the wiring for the output enable signal on one of the bus transceiver chips, and it required a few hand-soldered path wires to fix. After further development, the prototype card was demonstrated to work as a Liron clone, in both an Apple IIe enhanced computer and an Apple IIgs. It worked for controlling a real Unidisk 3.5 drive, as well as a BMOW Floppy Emu disk emulator configured for Smartport emulation mode.

Later testing discovered that the FPGA disk controller card worked reliably when it was the only card installed, but other cards were also present, it sometimes malfunctioned. The more other cards present, the worse the rate of errors became. This was diagnosed as a likely termination or contention problem on the Apple II data bus, and various fixes were tried unsuccessfully. After March 2018, I lost interest in researching the problem further, and no more work has occurred since then.

The design provided here is version 1.1, and it fixes the output enable problem from version 1.0.

 
Where to Start

1. Open the FPGA disk controller design (Liron clone) in EAGLE. Export Gerber files and send them to your favorite PCB fabricator. If desired, do the same for the DB19F adapter design.
2. Purchase the chips and other parts listed in the BOM.
3. Assemble the card. I did it by hand, you can do it too. A syringe of solder paste and a hot plate or toaster oven works nicely.
4. Get a Lattice JTAG programmer or appropriate clone. Some clones don’t handle 3.3V logic correctly. Maybe spend the extra money for a genuine Lattice programmer.
5. Install the Lattice Diamond software.
6. Apply 5V power to the card at jumper J4. Do not insert the card into your Apple II yet.
7. Program the FPGA with the bitstream for the Liron clone design – liron_fpgatop.jed
8. Insert the card in your Apple II. Remove any other cards that are present.
9. Connect a Smartport-compatible disk drive, such as a BMOW Floppy Emu disk emulator that’s configured for Smartport emulation mode, or an Apple Unidisk 3.5 drive.
10. Turn on the Apple II. It should boot from the attached drive.

 
Next Steps

The bus termination or bus contention problem must be solved, in order to get a robust card that works smoothly when other cards are also present. See the blog posts from February-March 2018 for more details about what was already tried. A solution will require a person who’s experienced at electronic design, and has appropriate test equipment such as an oscilloscope and logic analyzer.

The current design uses a Lattice MachXO2 1200HC FPGA, and a Lattice JTAG programmer (or compatible) is required for programming it. The XO2-1200HC has more logic resources than are actually necessary for the Liron clone design. The cheaper XO2-640 or XO2-256 could be substituted instead. They are mostly or entirely pin-compatible with the XO2-1200HC.

Programming the FPGA with a JTAG programmer is fine for development use, but end users are unlikely to have one. If reprogramming by the end user is desired (say to switch between Liron and Disk 3.5 emulation behaviors), a different method of FPGA programming will need to be developed.

Read 4 comments and join the conversation 

Good news, Apple II fans – support for .WOZ disk images is now available on the BMOW Floppy Emu disk emulator!

The .WOZ disk image format is an exciting newcomer to the vintage computing world. First released in 2018, it was developed by John K. Morris with the goal of being the most accurate possible representation of data encoded on an Apple II floppy disk. Other disk image formats omit certain “unimportant” data like sector headers, or make other simplifications and assumptions about the disk data. These assumptions are fine for standard software, but they fail for vintage copy-protected software that intentionally violates the standards. Some formats like NIB come closer to capturing all the low-level details of the floppy data, but still fall short. With the WOZ format, it’s possible for the first time to run heavily copy-protected vintage Apple II software directly from a disk emulator, without the need to “crack” the protection. This includes software using copy-protection techniques like cross-track synchronization, intentional invalid or blank regions of the disk, and even the dreaded Spiradisc spiral data tracks.

WOZ format caught my attention when it was first announced last year, and I read through the documentation, but concluded it would be too time-consuming and difficult to add to the Floppy Emu. I was skeptical that some of the timing requirements for cross-track synchronization and other WOZ featues could be met without pre-loading the entire disk image into RAM. The Emu hardware doesn’t have enough RAM to pre-load a full disk image, so the idea looked like a non-starter, and I shelved it. But after a steady trickle of inquiries I finally took a second look at WOZ a couple of weeks ago, and was able to make it work. I was right about the time-consuming part, but wrong about the rest – I eventually found solutions to the technical challenges that worked on the existing hardware. The result is worth it. Many thanks to John for answering my questions and providing sample disk images for testing.

About Floppy Emu: Floppy Emu is an external disk emulator for classic Apple II, Macintosh, and Lisa computers. Using disk images stored on an SD card, it can emulate 5.25 and 3.5 inch floppy disks, Smartport hard disks, Unidisks, and HD20-type hard disks.

 
Apple II Copy Protection Tricks

I discussed Apple II copy protection techniques a couple of years ago here. The WOZ format addresses three major areas:

 

Non-standard data (example: Rescue Raiders) – Normal Apple II floppy disks have 16 sectors per track, 256 bytes per sector, with a standardized sector header beginning with the famous D5 AA 96 byte sequence. Copy-protected disks throw all the standards out the window. To avoid any possible confusion, WOZ stores each track as a single very long bit sequence, without making any assumptions about what the bits mean, or how many bits there are. The track can even have fractional bytes, with a bitsteam size that’s not a multiple of eight.

 

Fake random bits (example: Print Shop Companion) – Normal floppies have data on every track. Even if there’s unused space on the disk, valid sectors will still be present – they’ll just be marked as unused. Copy-protected disks may have tracks that are truly blank, with no magnetic flux transitions. A true blank track is different than an empty/unused track. The drive hardware goes slightly haywire when attempting to read blank tracks, turning up its auto-gain control until it begins to see flux transitions that aren’t really there. The result is that reading a blank track will return a random sequence of bits that’s different each time it’s read. Copy-protected software can check for this. Because there’s no way to write a truly blank track on a standard Apple II floppy drive, this is an effective method of copy-protection.

A related protection technique is to include disk bytes with three or more consecutive zero bits. These can’t be read reliably by Apple II floppy drives, and they appear as random bits, similar to blank tracks. Copy-protected games can read the same bytes multiple times, to verify that random bits appear where they should.

The WOZ format solves both problems by specifically marking tracks and bits that should be treated as random, rather than as standard zero bits. The Floppy Emu firmware can then use a pseudo-random number sequence to generate such bits when needed.

 

Synchronized tracks (examples: Take 1, Archon, Frogger) – On a normal floppy disk, each track is a narrow ring of bits on the magnetic media, and the ring can be rotated at any angle relative to its neighbors without affecting the software. But some copy-protected disks rely on a specific rotational synchronization between neighboring tracks. For example they may require that sector 0 of the first track is physically adjacent to sector 0 of the next track. Because Apple II disk drives ignore the disk’s index hole, this track-to-track rotational synchronization is impossible to achieve when writing disks on a standard drive, and requires special mastering disk hardware. “Take 1” is a good example of software that relies on this type of cross-track synchronization.

WOZ format stores each track’s bitstream relative to the same reference angle. That preserves the cross-track synchronization information. But it’s up to the Floppy Emu to maintain a consistent rotational angular velocity for the emulated spinning floppy disk while stepping between tracks or performing other operations that temporarily interrupt the bitstream. This was the most difficult part of getting WOZ working on the Floppy Emu hardware. It required maintaining microsecond-level timing information about the current state of the bitstream, even while servicing hardware interrupts, reading data from the SD card, or updating the display.

Some copy-protected games take cross-track synchronization even further. They include a double-wide track that spans the width of two normal tracks. The software starts reading from the first track, and then steps to the next track while reading. Reading and stepping at the same time – that’s just evil. “Archon” is one example of this double-wide synced track protection method.

The ultimate in synchronized track copy protection for Apple II is Spiradisc, as found in “Frogger”. The data begins on track 0, but after less than a full disk rotation, the data jumps to track 0.25 and immediately continues. From there it follows the same pattern, with a short data section on each quarter track before jumping to the next track, spiraling all the way through the disk. Once I got Spiradisc working on the Floppy Emu hardware, I knew things were looking good.

 

And more – Other copy-protection tricks that are addressed by the WOZ format include monkeying with the soft switches, resetting the latch midway through a byte, and storing data on quarter and half tracks (The Bilestoad). It’s a jungle out there!

There’s an incredible variety of copy-protection schemes used by vintage Apple II software. Even with the addition of WOZ support to the Floppy Emu, you may still encounter some protected software that doesn’t work correctly. Some games such as Frogger apparently work only when using a real Disk II controller card, and the built-in disk port of an Apple IIc or IIgs won’t work. A few protected titles may work intermittently or not at all, for reasons that aren’t clear. If a game doesn’t boot on the first attempt, give it a second try. Typically the protection check happens only once during booting, and then you’re good to go.

 
What’s Included

• support for WOZ1 and WOZ2 format disk images
• cross-track synchronization capability
• fake random bits support
• disks with more than 35 tracks
• internal upgrade from half-step to quarter-step precision
• related improvements for NIB support

 
TL,DR

“My God, man! Stop talking and just give me the download link!”

Floppy Emu firmware 0.2G contains all the new features described above. This was a major change to some fundamental parts of the emulation code, and there may be unknown bugs, so this firmware is a “beta” release. If you don’t have a specific need to use .WOZ disk images, then stick with the previous firmware version for now. But for those who like to live life on the edge, here it is:

for Floppy Emu Model A – apple-II-0.2G-F22
for Floppy Emu Model B – apple-II-0.2G-F23

You can also download some sample WOZ disk images. All of these have been tested successfully with Floppy Emu using the 0.2G firmware. – WOZ sample disks

Read 11 comments and join the conversation 

The Wombat ADB-USB input converter is now back in stock at the BMOW Store. All pending Wombat back-orders will be shipped during the next few days.

What’s a Wombat? The Wombat is a bidirectional ADB-to-USB and USB-to-ADB converter for keyboards and mice, and was developed by Steve Chamberlin here at Big Mess o’ Wires. For more details, please see the product description page.

Be the first to comment! 

What do you do when a battery-powered appliance won’t turn off? And when it’s a sealed unit, so removing the batteries is impossible? And when its body starts to grow disturbingly warm? That’s the situation I found myself in a few days ago.

 
Riddles in the Dark

I was working at home one night, and gradually became aware of a strange buzzing sound. Initially I thought the sound was outside, but when I went to investigate, I discovered it was coming from the bathroom. My skull shaver, plugged in and recharging, had mysteriously turned itself on and the blades were spinning away. Pressing the on/off button had no effect. Unplugging the charging cable had no effect. The body is a single piece of molded plastic, so there was no non-destructive way of opening it. Nothing could stop the whirrrrrrrrrr of the blades, and the shaver was noticeably warm.

I started to panic that the razor would explode. The internal battery is likely lithium polymer, and from my days with RC cars and aircraft I know that defective or damaged LiPos can fail catastrophically. Like literally go boom and eject flaming molten goo everywhere that burns down your house.

I quickly took the razor outside, and set it on the concrete patio, blades whirring this whole time. A couple of minutes later, I began to fear that it was still too close to the house if it exploded, so I moved it to the street. Thankfully it didn’t explode, and those blades kept whirring for 90 minutes, during which two people stopped to ask what the horrible noise was.

 
A Tale of Two Chargers

So what caused the skull shaver to go crazy? Bad charging. Besides this manly pink skull shaver, I also own a more conventional Norelco cordless shaver. I’d never noticed it before, but the chargers for the two shavers have the same plug at the end of their cords:

A quick check confirmed that yes, I’d accidentally plugged the skull shaver into the Norelco charger. Is that bad? You might think that the plug shape is standardized, and that all charger plugs with this shape are designed for the same voltage. Let’s check. Here’s the skull shaver charger, which is nicely labeled. 5V output, max 1000 mA:

And here’s the Norelco charger. Instead of a label, its specs are molded into the charger body using impossible to read tiny-sized black-on-black lettering. Yuck.

But if it’s tilted at just the right angle to the light, and you get your reading glasses, here’s what emerges:

15 volts! Ouch! I charged a 5 volt device with a 15 volt charger.

I’m suddenly nostalgic for the days when real on/off switches physically disconnected the power. Many of today’s electronic appliances have a soft on/off switch that’s really just an input to some controller circuitry. When soft switches work, they’re great. But when something goes wrong with the control circuit you suddenly have a zombie appliance that can’t be shut off. In the case of this razor, the 15 volts apparently killed the control circuitry before the LiPo battery could be damaged to the point of explosion by over-charging. And the failure mode of the control circuitry was to fail ON.

Have you ever made a similar charging mistake, or exploded a battery through mistreatment? Leave a comment below and tell your story!

Be the first to comment!