BMOW title
Floppy Emu banner

Kit Biz Profit and Loss


Have you ever wondered what life is like in the “kit biz”, with a part-time business selling electronic gizmos to hobbyists? Maybe you’ve thought about selling one of your own creations, or were just curious if it’s possible to make any money this way. In the spirit of helping the hobbyist community, I’m sharing the 2015 BMOW profit and loss breakdown here. My hope is that others might provide some helpful insights, or learn something that can help their own efforts. Normally I would keep this type of information private, but I decided there’s no harm in sharing, and more knowledge can only help.

BMOW began as a place to document my personal electronics projects and musings, and remains primarily an electronics blog. But along the way, it accidentally grew into a small business too, as some of the projects generated interest from readers wanting to buy hardware for themselves. Chief among these is the Floppy Emu disk emulator for vintage Apple computers, and its related accessories. The Mac ROM-inator replacement ROM for early Macintoshes also has a small but devoted following. Today BMOW is a part-time 1-man business, to which I devote an average of about 10-20 hours per week for R&D, hardware assembly, customer support, and order fulfillment.

Total BMOW gross revenue in 2015 was $55,097. As you can see in the graph, month-to-month revenue varied more than 2x. There was an obvious bump in June and July, when the addition of Apple II emulation features boosted Floppy Emu sales. Sales also jumped in November for no discernible reason, and inexplicably slumped in December during what should have been the year’s strongest period (but recovered in January 2016).

The gross revenue figure includes all the money I collected: that’s money from product sales, California sales taxes collected, and shipping fees. I don’t really consider the latter two as income, because they go to the state or the post office, and not into my pocket, and their inclusion here makes the “revenue” figure look more impressive than it is. Accounting experts might argue whether sales tax and shipping fees should be included as revenue, or dealt with some other way. I’ve chosen to list them as revenue, with an offsetting expense listed later.


Of course that money isn’t all profit. Let’s look at the expenses for the year:


I rang up $31,000 in total expenses for 2015, resulting in a net profit of $24,097. Assuming I worked an average of 15 hours per week, that’s $31/hour before paying income taxes. That’s a lot better than the federal minimum wage, which is one test not every kit biz passes. But it’s a lot less than my typical hourly rate for consulting work, or the rate I could likely earn at a full-time electronics engineering job. One of my big goals for 2016 is to reduce the amount of time spent on things like support and order fulfillment, by searching for efficiency improvements. Much of what I do now is very labor-intensive, and there’s lots of opportunity to make more effective use of time.

I collected $429 on behalf of the state of California, which is an extra hassle that involves a special tax return filed each January. PayPal and eBay took $1982, or about a 3.6% cut of gross revenue. Given how frustrating and awkward PayPal is to work with, I don’t enjoy giving them anything, but it’s about the same rate that I’d pay if I accepted credit card payments directly. I made only a couple of eBay sales in 2015, which is fortunate because they charge 10% commission on top of PayPal’s 3% fee. Ouch.

The post office must really love me: $4172 in postage fees! Sometimes I wonder how eBay sellers in Asia can ship to the USA for a dollar or two, when I can’t even send a package within the USA for less than $6. International postage for small packages to most countries except Canada starts at $13, and (as of rate increases a few weeks ago) is over $20 for the weight of a typical BMOW order. My customers pay the shipping costs, so it doesn’t directly affect me, but I wish I could offer lower shipping rates.

The $378 for equipment represents hardware development tools and machines used for testing. Office supplies like shipping boxes, paper, address labels, ink, and bubble wrap were a $327 expense. The cost for web hosting fees and a few commercial software programs totaled $265, and my city business license was $321.

Hardware is Expensive

The biggest BMOW expense by far was the $23,126 cost of hardware and assembly. Unlike a software publishing business, selling hardware gizmos requires spending a lot of money upfront on hardware parts first. These parts must be purchased in large quantities to get the best prices, so it’s necessary to go into debt temporarily, and make up the debt later from product sales income. In my case I didn’t literally go into debt, but for a while my year-to-date expenses exceeded revenue by several thousand dollars. I have a lingering fear that demand will suddenly evaporate just after I make a big hardware purchase, or something will happen to make my products instantly obsolete, and I’ll be left with thousands of dollars in useless inventory.

$23,126 for hardware and assembly is a big number, so let’s break it down:


Floppy Emu boards are built by Microsystems Development Technologies in San Jose, CA. The cost for parts and assembly of the “core” Emu modules came to a whopping $15,679. This doesn’t include the LCD displays and the ever-elusive DB-19 connectors, which were purchased separately for $1345 and $733, respectively. The clear acrylic case for Floppy Emu is a popular option, and I spent $2058 on materials and laser cutting services for those. A further expense of $1265 was for the SD cards used in the Vintage Software Collection. I buy a lot of SD cards.

$580 went towards making PCBs for hand-built Floppy Emu accessories: the Universal Adapter and the A/B Drive Switch. This amount also included other non-Emu projects like the ROM-inator, Sonic Bow Tie, 68 Katy, and various prototypes and experimental hardware. The chips and other components needed to populate all those PCBs ran to $1460.

Room for Improvement?

This was a good result for 2015, so I’m not complaining. Still, there’s always room for improvement. While I’d love to boost sales volume or drive down costs, the area that’s most ripe for improvement isn’t money but time. There’s a tremendous amount of manual labor involved in most of what I do, and some weeks it cuts into my spare time so much that I deeply resent it. And even during weeks when the labor effort is more manageable, I’d rather spend an extra hour developing a new feature, or researching a new project, than bubble wrapping and boxing. Going forward, I’m going to look for opportunities where I can pay someone else to offload some of the manual work. Even if my costs go up as a result, and my net profit goes down, I’ll still consider it a success if the profit per hour of time spent improves. After all, it’s not my goal to spend every last waking hour of my life devoted to weird electronic gizmos – there are other things.


Here are some of the time-saving ideas I’m looking at for 2016.

Testing – During assembly, Microsystems Development Technologies verifies that each Floppy Emu passes its built-in self-test. Once I get the hardware, I do further testing myself: adjusting each unit’s LCD contrast, assigning a serial number, and actually running an emulated disk on a Mac or Apple II system. That all takes time. Initially it seemed unthinkable to send Microsystems an old Mac Plus and instructions for booting up System 3.2, but now I’m considering doing exactly that. They’re smart guys, they can figure it out.

Low-Volume Assembly – The items with lower sales volumes, like the Universal Adapter and A/B switch, are hand-built one at a time by me. They don’t take more than 10 or 15 minutes at most, but sometimes I just want to ship an order without hauling out the soldering iron first. Even when I build a few at a time to keep a small stock on hand, it turns into a few hours of work here and there that I’d rather spend on something else. Microsystems might not be the right people to build these for me, but there are plenty of other low-volume assembly services like Smart Prototyping. I need to find the time to research them and make an order.

Fulfillment – The most manual of the manual labor I face is order fulfillment. That means printing invoices, picking hardware out of boxes, sorting things into little piles, bubble wrapping, boxing, and taping. I once had a summer job as a shipping clerk, and this is pretty much exactly the same thing. And it still sucks. I could improve on this a little if I had a dedicated shipping area, with big rolls of tape and bubble wrap and boxes neatly stacked and ready to go. At times I’ve paid my daughter to do this work, but she doesn’t like it much either. Maybe a part-time helper from a temp agency? The need for this help is irregular, so I’m not sure how well a temp employee would work anyway.

PayPal and Postage – In an ideal world, I would log into a web site, and click a button to fetch all my new orders. This would automatically update my sales history, print a bunch of invoice slips, calculate the weight of each outgoing package, purchase the necessary postage, and print it. But in reality this process requires a crazy combination of the PayPal site, US Post Office site, and custom software. It’s an orgy of clicking, cutting and pasting, and manual steps. PayPal requires purchasing and printing postage for each order, One. At. A. Time. The post office web site lacks a way to import shipment details, so information must be manually pasted into forms and drop-down boxes stretched across several pages of the site. And don’t get me started again about their abysmal handling of international package addressing, which I’ve discussed here before (1, 2).

For postage there are alternatives like Endicia and, which should allow importing shipment details and combining purchases of all postage for a set of orders. Both services have fairly poor reviews, so I’ve resisted making the switch, but they can hardly be worse than the system I’m using now. On the payments end, unfortunately I don’t see any simple alternative to PayPal. It’s often clumsy and frustrating, but it provides a basic shopping cart system and handles a wide variety of payment types from nearly every country. Square seems more geared towards physical storefronts and swiping a credit card. Amazon Payments may be the most similar to PayPal, though I don’t know much about it.

Did you ever sell a product online? What was it?

What’s your favorite maker-friendly electronic gizmo?

Have a good post office story to share? I once received a coconut mailed from Hawaii. Just the coconut, with my address written on the shell.

Read 11 comments and join the conversation 

SD Card SPI Initialization


What happens when two devices share the same SPI bus? With a good design, each device is enabled one at a time for use of the bus, and they coexist without problems. With a bad design, SPI communication that’s intended for one device is sent to the other, leading to confusion and buggy behavior. In the Floppy Emu disk emulator, the SPI bus is shared between an SD card and an LCD display. As it turns out, it had a bug like this that escaped notice for almost two years, with the occasionally flaky behavior wrongly attributed to bad SD cards, faulty boards, or the phase of the moon. Doh!

The symptom was a “No SD card” message, with error code 10:5, when using a few specific models of SD card. During startup, the Floppy Emu firmware was sending SPI commands to the LCD to draw an image, then sending SPI commands to the SD card to initialize it. In rare circumstances, the initial communication with the LCD was confusing the SD card, leaving it in a state where it refused to respond to any further commands until the power was turned off and on. This caused the Emu to think no card was present. The problem didn’t always happen 100% of the time, and it appeared to depend on the electrical characteristics of each board and anything attached to it. But for certain models of SD card, it happened so consistently that the only remedy was to use a different SD card.

My solution was simple: initialize the SD card before doing any LCD communication. Grab the new firmware with the fix here:

floppy-emu-1.0R-F13Mac Floppy
hd20-0.7E-F14.5Mac Floppy + Hard Disk and Lisa Floppy
apple-II-0.1K-F7Apple II, for Model B
apple-II-0.1K-F6Apple II, for Model A

SPI Mysteries

You might wonder how a problem like this could have gone unnoticed for so long. Looking back over two years of support emails, I only found four problem reports that could be retroactively attributed to this issue. In each case, the person was able to get things working by trying a different SD card, so we chalked up the problem as a damaged or flakey card. It was only recently that I received two reports from people who’d tried multiple cards, all of which failed with the “No SD Card” message and error 10:5. Following up on their hardware, I bought two suspect 16 GB cards (1, 2), and confirmed that they both just plain didn’t work. Ouch. I’ve now verified that the new firmware gets both these SD cards working, and also received confirmation from some other users that the new firmware gets their troublesome cards working too.

So what exactly was the problem? The frustrating answer is that I don’t really know, and my description of the issue intentionally glossed over some important details. It’s true that the LCD communication somehow confused certain SD cards, but I can’t explain why.

Floppy Emu SPI Bus

Here’s a simplified diagram of Floppy Emu’s SPI bus. The LCD and SD card are independently enabled by separate, active low signals LCDE and SDE. Because the AVR microcontroller operates at 5V, all its outputs are passed through a 74LVC244 buffer to step them down to 3.3V for the LCD and SD card (the 3.3V signal MISO is an output from the SD card, and doesn’t need level conversion). SDE also has a 10K ohm pull-up resistor to +5V, to ensure that the SD card is disabled when the AVR isn’t actively driving the signal, during reset and microcontroller startup.

The only way it should be possible for the SD card to be confused by LCD communication traffic is if SDE were asserted at the wrong time. Looking at the schematic and the firmware code, I just don’t see how that’s possible. The pull-up resistor ensures that the SD card will be enabled if the AVR isn’t actively driving it. And once the AVR does begin actively driving it, it drives SDE high (unasserted) until it’s ready to begin communication with the SD card. So the card should be disabled during the initial LCD communication, and should ignore whatever is happening on the SPI bus.

If I weren’t so lazy, I would put a scope on the SPI bus, and verify that SDE is truly unasserted during LCD communication. But I’m lazy, and didn’t do that.

A few hints point to an electrical problem. With some cards, the 10:5 error occurred more often when I had an AVR programmer attached to the SPI bus, even if the programmer wasn’t active. And with those same cards, seemingly trivial firmware changes would cause the error to appear and disappear. Sometimes I’d only get the error on half my attempts, so it wasn’t a deterministic problem.

Maybe poor circuit design causes a momentary noise spike on SDE, during startup and LCD communication. Ringing, ground bounce, or cross-coupling of signals might cause SDE to briefly appear asserted when it shouldn’t be, causing the SD card to try to interpret communications meant for the LCD. But if that were the case, I’d expect to see all kinds of similar communication errors with the SD card during normal operation.

Another possibility is that there’s something fishy going on with AVR pin PB4, which is also the SPI SS (slave select) pin. The datasheet mentions that there’s some special behavior related to this pin. But after reading that section of the datasheet, I don’t think that’s the cause.

My last theory is that the problem is caused by accidentally switching the SD card into 4-bit mode. SD cards can operate in three different modes: SPI, 1-bit SDIO, or 4-bit SDIO. The latter two modes use the card’s pins like a conventional data bus. I believe the details of 1-bit and 4-bit SDIO may be proprietary and require an NDA, and every hobbyist-made microcontroller project I’ve seen has used SPI instead.

The catch is that SD cards initially power on into 1-bit SDIO mode, and part of the SD card initialization process is to switch to SPI mode, which will remain active until power off. With the old firmware, during the Floppy Emu’s initial LCD communication, the SD card was still in 1-bit SDIO mode rather than SPI mode. I don’t know anything about 1-bit SDIO mode, but maybe the chip select input is used differently in that mode, and my LCD communication was accidentally triggering a switch to 4-bit SDIO mode. As I understand it, once switched to another mode, that mode will remain active until power off, which is consistent with the “zombie SD card” behavior I observed with certain cards under the old firmware. Hmmm…

Read 3 comments and join the conversation 

Standby Current of a USB Car Charger


How much current does a typical USB car charger consume, when nothing is charging? Zero? Microamps? Milliamps? Is it enough to be concerned about draining the car’s battery? There’s no better way to find the answer than direct measurement, so let’s go!

My 2016 Mazda CX-5 has two built-in USB ports, which can theoretically recharge my mobile phone while I’m driving around, but the rate of charge is so slow as to be nearly useless. In an hour of driving, it might raise the phone’s charge level by 15%. To get faster charging, I purchased a USB car charger that fits in the 12V jack in the car’s center console: the ubiquitous jack that was once the cigarette lighter in years gone by, but has now been repurposed as a place to plug in dash cams, DVD players, and other car accessories.

The new USB car charger works fine, and can recharge my phone from zero in about an hour, but it leaves me with a lingering worry. The 12V jack in the 2016 Mazda is not switched by the ignition, but is powered all the time regardless of whether the car is on or off. That means when the car is sitting parked, with the engine off, the USB charger is still drawing current. If I were foolish enough to leave some power-hungry appliance connected, it could quickly drain the car’s battery. But even with nothing connected, the USB charger will still draw some standby current. To measure it, I put together a quick test involving a 12V wall supply, the USB charger, a multimeter, and lots of alligator clips.


The answer: the USB charger’s standby current is 14.2 mA. I would have guessed microamps, so I was way off. It doesn’t help that the charger has an LED that’s continuously illuminated whenever it’s powered.

Is a constant 14.2 mA draw enough to worry about discharging the car’s battery? Probably not. From a few quick searches, I learned that a typical car battery has a capacity of around 40 ampere hours. At 14.2 mA, it would take 2817 hours or 117 days to completely discharge the car’s battery. Assuming I drive the car every day, then, it’s not a concern. Even parking the car for a week or two should be fine. But if I ever need to leave the car in storage for an extended period of time, that 14.2 mA could add up. Of course the car itself has its own standby current draw for the anti-theft system and keyless entry, so the USB charger may not even be the largest concern. For typical driving, at least, it appears the USB charger’s standby current draw won’t be a problem.

Read 6 comments and join the conversation 

Clearance Sale: $79 Floppy Emu Model A


While supplies last, the Floppy Emu Model A is on sale at a clearance price of just $79. If you’ve been waiting to add one of these hard disk / floppy disk emulators to your Apple computer collection, now is your chance. The response to the new Model B has been great – maybe a little too great, and I need to close out the remaining inventory of Model A hardware. If you’re a Macintosh or Lisa user, or an Apple IIgs/IIc/IIc+ user looking for a Smartport hard disk, this is a great value! See the compatibility table on the order page and the Model B announcement for more details on Model A vs B differences.

If I were a savvier businessman, I might have waited to introduce the Model B until my inventory of Model A hardware was gone. It’s not quite the Osborne Effect, but introducing a new model that kills demand for the old model may not have been the smartest move. Fortunately for you, my loss is your gain! The good news is that interest in the Model B has been strong. In the past I typically made about one sale per day, but recently it’s been much busier. This was the scene heading to the post office after the 3-day MLK Day weekend:


The Model A is the original Floppy Emu design that’s been featured here at BMOW for over a year. It emulates a classic Macintosh HD20 hard disk or 3.5 inch floppy disk, or a Lisa 3.5 inch floppy disk, or an Apple IIgs/IIc/IIc+ Smartport hard disk, or an Apple IIgs/IIc/IIc+ 5.25 inch floppy disk. Many people have purchased both a Model A and a Model B, to get a dedicated drive for each Apple computer in their collection. Don’t miss this chance to pick up a Model A at a great price!

Read 3 comments and join the conversation 

Introducing Floppy Emu Model B


Today I’m excited to introduce the first significant update to the Floppy Emu disk emulator for Apple II and classic Macintosh computers: Floppy Emu Model B. The new Model B has the same disk emulation functions as the Model A and Universal Adapter, but with several new convenience features:

  • Built-in Apple II Compatibility – Model B is directly compatible with the entire Apple II line, emulating a 5 1/4 inch disk, 3 1/2 inch disk, or Smartport hard disk. While Model A required a separate Universal Adapter for the best Apple II compatibility, Model B has the equivalent functionality built-in. Classic Macintosh and Lisa disk emulation is still supported too.
  • microSD Card Support – The SD card slot is now a push-push microSD type, identical to what’s used in most mobile phones. This will make it easier to find suitable SD card media, since the older full-size SD cards are becoming rare.
  • SD Card Hot-Swap – The SD card can be removed and re-inserted while the Floppy Emu is powered on.
  • Improved Protection Circuitry – Model B features improved protection circuitry on the disk drive interface connector. This circuitry will help protect the Floppy Emu from electrical damage caused by voltage spikes and surges. It also eliminates the risk of potential damage if an Emu board running the Apple II firmware is inadvertently connected to a Mac or Lisa computer.
  • Same Great Emulation Features – All of the time-tested Macintosh, Apple II, and Lisa disk emulation features from Model A are still present. Model B reads and writes emulated 140K, 400K, 800K, or 1.4MB floppy disk images, or hard disk images up to 2GB, if supported by your Apple computer. For full details, see the instruction manual.

If you’re new to Floppy Emu, it’s an external hardware device for vintage Macintosh, Apple II, or Lisa computers. It uses a removable SD memory card to mimic an Apple floppy disk and drive, or an Apple hard drive. The Emu behaves exactly like a real disk drive, requiring no special software or drivers. Floppy Emu is perfect for booting your favorite games, moving files between modern and vintage machines, and troubleshooting a computer without a working OS. Just plug in the Emu board, and you’ll be up and running in seconds.

Floppy Emu Model B is available for sale now. While supplies last, I’m also selling the remaining inventory of Floppy Emu Model A units for a reduced price. It’s disk emulation madness!

Read 31 comments and join the conversation 

The Story of Tetris Max

tetris max 2

It was the summer of 1992. Nirvana smelled like teen spirit, Ross Perot was running for president, and I was a senior at the Massachusetts Institute of Technology who wanted to play tetris. Looking at the options then available for my Macintosh LC computer, none of them were inspiring. My friends were all addicted to a beautifully crafted Mac falling blocks game called Jewelbox, and I wondered if I could make a Macintosh tetris with the same level of polish. And so began the story of Tetris Max, a game that was to play a major role in my life for the next decade.

I had only a shaky understanding of the C language, and a weak grasp of Mac programming fundamentals. This was before the days when any programming question could be answered in seconds at, so knowledge had to be gained the hard way, reading through the five thick printed volumes of Inside Macintosh. Somehow I cobbled together a working game.

Before long, I had dozens of friends camped out in my room day and night, competing for high scores and offering feedback on dropping speed, rotation rules, key repeat behavior, and other fine points that made the difference between a so-so game and a great one. We polished the hell out of that thing, arguing over arcane details until the gameplay was dialed perfectly. Then I agonized over all the little graphics elements and sound effects, for events like dropping a piece, advancing to the next level, or getting a high score. Somehow a mooing cow found its way in there too. I became obsessed with perfecting every aspect of the game until it was buttery smooth.

For music, I chose the instrumental portion of Jesus Jones’ song Blissed. It had that ethereal quality appropriate for trance-like extended play at level 10. Over lunch one day, a few friends and I argued over what meaningless suffix would be best for the game title. Tetris Gold? Tetris Pro? Tetris Plus? How about Tetris Max? Yes, that’s it!

At the time there were dozens of tetris versions available, including the popular xtetris, and Asshole Tetris, which cheated against the player. I was aware that the game concept originated with a Russian man, but it seemed a generic idea like chess or tennis, and it didn’t occur to me that I shouldn’t call it “tetris”. This came back to haunt me later.


In August 1992, I uploaded the first version of Tetris Max to the Info-Mac archive and America Online, which was about as advanced as Mac software distribution got at the time. I prayed that somebody would notice my submission, and… surprise! Somebody did. A lot of somebodies! I started receiving an extraordinary number of emails from all over the world, from people telling me how much they enjoyed playing Tetris Max. It was beyond the best I’d hoped for. The game was a hit!

Everyone wanted to know about their high score. How did it compare to others? What was the highest score ever achieved? People shared their stories of deep states of meditation achieved on level 10, the final level where human reflexes were just barely fast enough to keep up, where marathon length tetris sessions were possible, but where a single mistake was fatal. Others claimed the game helped them get to sleep each night, or reduced their stress levels, like a form of therapy. As for myself, I played the game so much that I began to see falling shapes in my mind whenever I closed my eyes, and would mentally rotate and drop them without any conscious thought.


By that winter Tetris Max had become a major force in the world of Macintosh games, and the excitement level continued to grow. I was invited to appear in a book about Macintosh shareware called Mac Arcade: Don Rittner’s Top Shareware Game Picks. The book included several pages about Tetris Max, including a rather silly biography of me. When I later saw it on sale at a local bookstore, it was one of the most exciting things to yet happen in my young life. And it helped ratchet up the level of Tetris Max mania even further.

After the game had been out for a few months, I was contacted by Peter Wagner, an amateur musician and tetris fan from New Jersey. He loved Tetris Max, and offered to compose some original music for it. The song he sent me was perfect for tetris: beautiful, memorable, and almost meditative without becoming annoying when it was looped 1000 times. When I released an update to Tetris Max, I substituted in Peter’s music, and it became the iconic Tetris Max music that anyone who’s ever played the game probably still remembers today. A funny bit of trivia: Peter sent me his song on a cassette tape, which I digitized using a tape deck whose motor was too slow. So the music in the game is transposed down about a whole step from Peter’s original composition.

Through 1993, the Tetris Max train continued gathering steam. The October 1993 issue of MacUser magazine (feature article: the new Apple Newton) gave it an honorable mention in their annual shareware awards. My name was in print again, and unlike the Mac Arcade book, it was spelled right! Exciting times for a young Macintosh fan.

Making It Pay

By mid 1993 I had graduated from M.I.T. and was living in Cambridge, Massachusetts. This whole time Tetris Max had been a free game, and the only thing I asked people for was a note saying hi. Most other Macintosh games at the time were distributed as shareware, a try-before-you-buy system in which people were asked to send money to the author if they liked the program. With the popularity of Tetris Max, I heard loud arguments from my friends that I was an idiot for not using the shareware idea myself, so I decided to give it a try. In September 1993 I released a new version of the game as a $10 shareware product.

The response was weak at first. Players were under the honor system to send the shareware fee, but there was nothing really motivating them except perhaps a guilty conscience. Later I implemented a nag screen, and an A.I. player feature that was unlocked only for registered customers, both of which helped boost the number of registrations somewhat. But the total remained low.

What really made a difference was the introduction of the “Bonus Disk Set” in 1994. Recognizing that most people needed some incentive to register shareware, I gave them one in the form of a collection of alternate tetris piece graphics, sounds, and music to use with the game. Because only registered users were eligible to purchase the bonus disk set, it spurred lots of new registrations.

In those days there was no PayPal or other easy way to send small amounts of money to a stranger, so the registration system was incredibly low-tech. I rented a box at the Cambridge post office in Central Square, a few blocks from where I lived. Customers wrote paper checks and mailed them to my P.O. box. I used a cheesy XOR algorithm to generate a registration code from their name, then mailed them back a letter with the code. It was tremendously labor-intensive, and I spent hours manually typing people’s names into a database and stuffing envelopes. But low-tech or not, the system worked, and for a while I earned a very nice side income from shareware registration fees. Steve Wozniak even registered the game on behalf of his kids charity. His check was signed just “Woz”.

Receiving payments from people outside the United States was a big problem. My bank would generally not accept checks drawn on non-US banks, or if they did, the service fee was greater than the amount of the check. Other solutions like international money orders didn’t work well either. Eventually I settled on a simple solution: cash. Plain old pound notes, francs, deutschmarks, and reals, plucked from a wallet and stuffed in an envelope. I could convert these to US cash for a small fee at any bank or money changer, but in practice I kept many of them as souvenirs. Sending cash through the mail sounds like it might be a risky idea due to possible mail theft, but I never had even a single cash registration go missing.

Over time, several alternate versions of Tetris Max were developed. In 1994 my friend Yev ported the game to Windows 3.1 and released it as Bricklayer. We split the shareware income between us, but it was never very much, as Bricklayer for Windows never enjoyed anywhere near the popularity of Tetris Max for Macintosh. I also reused much of the same code to develop Columns Max in 1995, and Dr. Max in 1997. Neither game was very successful, and to be honest Columns Max was pretty bad, but I’m proud of Dr. Max. It has a great feel and cute little animations, and is lots of fun to play.


The most important alternate version appeared in the Mac Arcade Pak, published by MacSoft. Beginning in 1994, the game appeared (as Bricklayer) in this collection of five Macintosh games sold across the country at stores like Comp USA and Micro Center. It was low-cost budget software, and I only earned a 25 cent royalty for each one, but MacSoft sold a tremendous number of that Arcade Pak. My relationship with MacSoft’s partner Varcon Systems grew in importance as the Mac Arcade Pak took off. Once when I was buying a new monitor at Comp USA, the woman ahead of me in the checkout line was buying the Mac Arcade Pak. But when I casually mentioned that I’d written one of the games, she didn’t seem impressed. :-)

By 1996 things were going well, and my Cambridge P.O. box was stuffed with envelopes whenever I visited. But I had a problem: I was moving to California. I could release a new version with a new address for registrations, but so many copies of the old version remained in circulation that the Cambridge box was sure to keep receiving letters for a long time to come. My solution was to hire my grad student friend Tom to check the Cambridge box for me, and forward the letters to my new address in California. Problem solved… for a while at least.

Even as the Macintosh platform lost market share, the popularity of the game was undiminished. I continued to get emails and letters from enthusiastic players around the world, and everyone still wanted to know about their high score. I finally got fed up with manual registration processing in 1997. Opening envelopes, database entry, post office runs, bounced checks… it was all too much, so I contracted with Kagi Shareware to process the registrations for me. Letters went directly to Kagi, who handled all the money, registration codes, and customer correspondence. They took a big chunk of the income in exchange for their service, but it was worth it for all the headache that it saved me.

The End of Things

In 1998 I received a letter from New York law firm LeBoeuf, Lamb, Greene & MacRae LLP on behalf of The Tetris Company, an organization with the sole purpose of licensing the tetris brand. The letter claimed that both Tetris Max and Columns Max infringed on the trademark, copyright, and other rights of The Tetris Company, and demanded that I immediately stop all distribution and sales of the games. Though I didn’t know it at the time, this was part of a broad effort by TTC in the late 90’s to remove all freeware and shareware versions of tetris from the market.

Some aspects of these claims seemed dubious to me, as it’s subjective to what extent the “look and feel” of a software program is protected by copyright, and Columns Max was not a tetris game at all. But the “tetris” trademark infringement was more clear, and it seemed I was straight-up wrong in using that as part of the game’s name. After briefly consulting with a lawyer, who wasn’t much help, I decided I didn’t have the resources or the desire to fight. I removed Tetris Max from the internet wherever I could, instructed Kagi to stop accepting shareware registrations, and formally terminated my contract with Varcon.

But stopping Tetris Max proved easier said than done. Because there were so many copies of the game still in circulation, registrations continued to arrive at Kagi and at my old P.O. box. I had to send letters back to all those would-be-registrants, returning their checks. Kagi complained that they were spending hours doing the same thing for the registrations that reached them, yet not getting paid for their efforts, but there was nothing I could do about it. It took about two years for the tide of incoming registrations to finally taper off.

As an interesting post-script, in 2000 I became involved in another legal dispute over Tetris Max, after the game had already been discontinued for more than 18 months. Varcon received a summons to Massachusetts civil court, for a suit related to Tetris Max and the Mac Arcade Pak. It was part of a complex dispute involving derivatives of
Tetris, Missile Command, Pac Man, Dig Dug, and Asteroids. In all there were 4 or 5 companies suing, including Elorg and Hasbro, and 10 different companies being sued. There was no question of trademark infringement this time, and the entire case rested on claims of look and feel copyright violations.

Two months later, I saw a press release saying that Varcon had settled their part of the case, although it mentioned Pac Man and not Tetris. I never heard anything further about the case.

April 19, 2000. BEVERLY, Mass.–Hasbro’s video game unit Hasbro Interactive said today that it has settled a lawsuit with two companies that were accused of violating its copyright on such popular video games as “Pac-Man,” “Centipede” and “Tetris,” for an undisclosed sum.

The two companies, GT Interactive and Varcon Systems, agreed to stop selling look-alike games of titles owned or licensed by Hasbro. GT Interactive and Varcon, for example, sold games like “Mac-Man” and “Munch Man,” which Hasbro said infringed on its copyright of “Pac-Man.”

Hasbro said it would continue to pursue its suit against eGames. and smaller companies Webfoot, MVP Software and Xtreme Games.

Some people may read this story and conclude I’m a bad person for unfairly using somebody else’s idea, and to a large extent I would agree. In hindsight it would certainly have been better if I’d developed a new game concept instead of recycling an existing one. Like many projects gone awry, it seemed like a good idea at the time.

It’s now 2015, and the Macintosh operating system looks radically different than it did in the 90’s. Tetris Max can’t even run on today’s Macs, outside of an emulator for vintage software. Yet two decades later, I still get occasional emails from fans, and they STILL want to know about their high scores. Some things never change!

Read 2 comments and join the conversation 

Older Posts »