Discontinued parts are bad, “unobtainium” parts are worse. Floppy Emu uses a 19-pin D-SUB male solder cup connector, otherwise known as DB19P, to connect to the computer’s floppy port. DB19 connectors were never common, and were only used in 1980s and 1990s Macintosh, Atari, and some NeXT computers. Today in 2015 they’re very difficult to find. As far as I can tell they’re no longer manufactured, and are only available in small quantities from electronics surplus warehouses.

My hardware sales appear to be drawing down the remaining worldwide stock of these connectors. Working with the vendor who assembles the Floppy Emu boards, we’ve purchased the entire remaining stock from three surplus warehouses, and been advised that they won’t be getting any more. We have enough to finish the current batch of 100 boards, but after that it’s not clear if we can find more DB19s at a reasonable price, or at any price. Worst case, this will be the last batch of Floppy Emus, and I’ll have to stop selling them when the supply runs out. And a couple of DB19-based adapter boards I was planning to release will never see the light of day.

 
Vendors

Searching the web, it seems there are at least half a dozen places that sell DB19 male solder cup connectors. But if you look carefully, several of them are just alternate storefronts for the same company with the same stock. A few places show DB19 but list it as out of stock. At least one other shows it as in stock, but if you call them you’ll learn it’s actually not available.

 
Connectworld
IEC

These are the same vendor. I’ve bought their entire stock. They won’t be getting more.

 
Marvic
PC Accessories

These are the same vendor. Out of stock, not clear if they’ll be getting more.

 
Elliott Electronics Supply
Network Cables

These look like active vendors. I haven’t called yet to confirm availability or quantity in stock.

There’s one more vendor I won’t list here, because I don’t want other people buying up their stock. They’re kind of a pain to work with, but I’ve used their parts for all my boards thus far. Now they’re out of stock, and it’s not clear if they’ll be getting more, or if this is the end. Their web site says they are newly-manufactured parts, so I’m hopeful.

 
Options

A couple of other options, if the supply of DB19 connectors disappears:

• Use DB25 connectors, and cut off 6 pins. This might or might not fit, depending on the mounting screws and case cutout surround the DB19 port on each Macintosh model. It might be necessary to cut away part of the metal housing of the connector, using tin snips or a Dremel. It would be a lot of extra work, look ugly, and require a modification to the Emu’s PCB.

 

• Find an Asian manufacturer to make DB19 connectors. If I commit to buying enough of them, I bet I can find a D-SUB manufacturer in Asia who’d be willing to set up tooling machinery to build DB19s. I’m not sure how many I’d need to buy, though – thousands? And I’m not sure how to find potential Asian partners, and make a proposal to them. My first thought is to use Alibaba to identify existing D-SUB manufacturers of other sizes.

I use PayPal to accept payment for all BMOW products. Customers can create a PayPal account and send money from their account balance, or they can use PayPal with a Visa credit card to send payment directly without creating an account. That’s mostly worked OK, but today I learned that PayPal straight-up denies all credit cards from Pakistan, no exceptions. It’s like a giant middle finger, extended to an entire country of 182 million people. In fact there are 18 countries where PayPal won’t accept payments, some of which would probably never be customers of mine anyway (Papua New Guinea?), but with over 100 million people and English as an official language, the absence of Pakistan is especially galling.

PayPal is popular, at least in the United States, and it’s convenient, but it can also be infuriating. They act like a bank, and hold balances and perform money transfers like a bank, but aren’t subject to the same regulations as a bank. The internet is full of horror stories where PayPal froze accounts containing thousands of dollars due to “suspicious activity”, with no path or process for people to appeal or even discuss it with a human being. And from a seller’s point of view, the PayPal dispute resolution process is as bad as it gets. If you want to scam me, just buy a Floppy Emu, and when it arrives file a PayPal dispute saying that the item was not as described. You will get your money refunded 100% of the time and end up with free hardware, and there’s nothing I can do about it. (Please don’t actually do this.)

Unfortunately there are no realistic alternatives to PayPal that provide similar capabilities. WePay is US-only. Square is only slowly expanding outside the US. Amazon Payments is a mess. Too many companies seem to believe the world consists of the United States and “miscellaneous other”, a group of 6.7 billion people who are somehow not very important.

After some investigation, it looks like the best solution for a one-time payment from Pakistan to the United States is a money transfer service like Western Union or MoneyGram, even though they charge a 10% commission. It’s OK for a one-off, but if I were receiving a lot of orders from Pakistan, it would be a poor long-term solution. If anyone has experience with sending money from Pakistan to the USA and can suggest a better method, I’d be happy to hear about it.

This is what 100 unsaleable Floppy Emus look like. After six weeks of waiting, today I received the new batch of assembled boards, and eagerly opened the box. Excitement gave way to dismay when I discovered that every one of them was assembled incorrectly. Arghh, noooooo! I’ve been unable to fill any orders since mid-December, so I’d been counting down the days until the new hardware was expected to arrive. Now it looks as if there will be a further delay of about a week. Manufacturing is hard.

For whatever it’s worth, my instructions were correct and the error was the fault of the assembly shop. That means I won’t have to pay to fix the mistake, but it doesn’t help me get corrected boards any faster.

The assemblers transposed a part from the extension cable’s IDC20 to DB-19 adapter onto the main Floppy Emu board itself, and also omitted one component. The resulting boards still work, but won’t fit the Floppy Emu cases, and I’m left without any usable extension cables. After some discussion on how to make things right, I agreed to return the whole batch to the assembler, and they’re going to rework the boards to the correct design. I’m not certain how long that will take, but I expect it should be finished by next week.

I could demand that they replace the entire batch with new parts, or give me the batch for free, but I don’t think that would go well. Like me, they’re a small business, and I don’t want to stiff them for thousands of dollars in losses if they can make good on their mistake through rework. And quite frankly I’m lucky they accept my business at all, since my order sizes are so small compared to their typical jobs. If I stomp my foot and demand a pound of flesh, I may get it, but I may also be asked to bring my future business elsewhere. I like working with this shop – they’re reasonably priced and local – and I’d hate to start over from scratch building a relationship with a new assembler in some far-off location. So for now I’ll wait, impatiently.

If you’re crazy enough to want to build your own 68 Katy, I’d like to help you do it. The PCB version is the easiest way to get started. Compared with the breadboard version, it replaces all of the glue logic, timers, and other miscellaneous components with a single CPLD. The number of status LEDs is also reduced from eight to one, and there’s a small change to the serial status address mapping. Otherwise it’s functionally identical to the original breadboard prototype. Get a PCB, solder the components, burn the ROM, and you’ll be in business.

Assembling the PCB requires soldering one surface mount component, the 44 pin CPLD in TQFP package. It can be soldered with a standard iron using the drag soldering method (my preference), with hot air, or with a toaster oven reflow. The rest of the components are easy through-hole parts.

You’ll need an EPROM burner to program the initial flash ROM data, as well as a JTAG programmer for the CPLD. I used a Bus Pirate with the XSVF player firmware to program the CPLD.

Note that the PCB and breadboard versions of 68 Katy are not binary compatible, due to a small difference in their memory maps. If you’re building the PCB version, be sure to use the files linked here, and not the breadboard version files.

 
PCB Version: Parts List

• Motorola 68008 CPU, 8 MHz, 48-pin DIP package
• AM29F040B or SST39SF040 4 megabit Flash ROM
• BS62LV4006PIP55 4 megabit SRAM, or compatible substitute
• Xilinx XC9536 CPLD – not XC9536XL
• Sparkfun FT245RL USB to FIFO breakout board
• 12 MHz metal can oscillator
• bypass capacitors, resistors, LEDs, buttons, switches, sockets, etc. – complete parts list

 
PCB Version: Files

• schematic and board layout – Board definition in KiCad format
• Gerber files – For getting a copy of the PCB made at a fab like Seeed Studio
• CPLD source – Xilinx ISE project and Verilog source code for the CPLD
• 68katy.xsvf – JTAG configuration file for the CPLD
• monitor.asm – My ROM-based monitor/bootloader program. I used Easy 68K to assemble it.
• monitor-plus-linux-pcb.bin – This is the final binary image I programmed into the flash ROM, containing the monitor/bootloader program with the uClinux kernel concatenated to it beginning at address $003000
• virtualboxes.org Ubuntu machine – For Linux cross-development, I used Ubuntu 12.04 32-bit running as a virtual machine under Virtual Box. Don’t use the 64-bit version, or the 68K toolchain won’t work. You can use this pre-configured Ubuntu Virtual Box machine image. Username “ubuntu”, password “reverse”
• uClinux-dist-20040218 – I started from the February 18, 2004 release of uClinux. This is the unmodified version.
  uClinux-20040218-pcb.tar.gz – This is my modified version of uClinux. It includes code for kernels 2.0, 2.4, and 2.6, but I only ported kernel 2.0 for 68 Katy. Search the code for “68KATY” to find my changes.
• m68k-elf-tools-20030314 – You’ll need a 68K cross compiler and other tools in order to build the uClinux source code. I used m68k toolchain 20030314. It’s supposed to be a self-extracting shell script, but that didn’t work for me. I had to extract it manually, like this:

 
Startup

Assemble the PCB. Attach a regulated 5V power supply, and turn on the power switch. Use the Bus Pirate or another JTAG programmer to program 68katy.xsvf to the CPLD – the board must be powered when you do this, but components other than the CPLD don’t necessarily need to be present yet.

Use an EPROM burner to program monitor-plus-linux-pcb.bin to the flash ROM, then place the ROM chip in the board’s socket. Place the CPU and RAM in their sockets as well.

Attach a USB cable to the FT245RL module, and plug it into your computer. The FT245RL module doesn’t need to be connected to the 68 Katy board yet – it’s powered by the USB cable. If necessary, install the FTDI virtual serial port driver software for your computer. When complete, your should see a new virtual serial port like COM4. Now place the FT245RL module in its socket on the 68 Katy board.

Turn on the 68 Katy board. Use terminal software like Tera Term to open the serial port where the FT245RL is connected. The serial port speed and parity settings actually don’t matter, although choosing a faster speed will result in faster file transfer times when sending updates to the board.

Press the RESET button on the 68 Katy board. If everything is working, you should see the monitor prompt zBug(ROM) for 68Katy (press ? for help). Press ? to see a list of available commands. The monitor can load Motorola S-record files, view or disassemble memory, and many other useful things. The uClinux image is stored in the flash ROM beginning at address 003000 hex. To start Linux, from the monitor prompt type j 003000.

Using the provided source code, you can modify the monitor program, the uClinux filesystem contents, or the uClinux kernel. Use a hex editor or other tool to concatenate the uClinux image file 68katy.rom to the monitor program monitor.bin. The combined result must be no larger than 480K. Note that 68katy.rom itself is a concatenation of the uClinux kernel code kernel.text, kernel initialized data kernel.data, and the read-only Linux filesystem image romfs.img. To update the flash ROM with the new monitor or uClinux, from the monitor prompt type u, then use the terminal software’s file transfer option to download the concatenated file. If using Tera Term, make sure to select the option to send the file in binary format, not text.

Have fun!

The 68 Katy PCB version is working! Mostly! I’ve had the parts and PCB on hand for a while, but only recently got around to assembling and testing the thing. Now instead of a breadboard that runs uClinux slowly, I’ve got a 10 x 10 cm PCB that runs uClinux slowly. Ah, the sweet taste of success.

 
Assembly

The assembly process went smoothly, even though I forgot to label some important items on the silkscreen like the JTAG pins. Revision 2 can fix that. The only real soldering challenge was the Xilinx CPLD, a 44-pin SMD chip. The PCB footprint for the CPLD wasn’t the best, as the pads were barely any larger than the pins themselves, making it somewhat difficult to solder with an iron. But thanks to my experience hand-soldering hundreds of similar chips with Floppy Emu, I was able to use a drag soldering technique to get the CPLD down with only minor rework required. The rest of the through-hole components were quick to solder, and I finished the board off with a fancy blue status LED.

Since I don’t own a Xilinx programmer, I used a Bus Pirate to program the CPLD. The process isn’t too bad for occasional or emergency use. Using the Xilinx IDE software, you can create a .xsvf programming file for your design and the target chip type. Then you flash a special XSVF player firmware onto the Bus Pirate, connect the BP’s pins to the JTAG header on your board, and finally run a Windows utility to program the .xsvf file to the chip. I was stuck for a while at the point of flashing the alternate firmware to the Bus Pirate, since I’d forgotten that you must manually invoke the bootloader before updating the BP’s firmware. Once I figured that out, the actual CPLD programming was quick.

 
Boot Up

I pulled the 68008 CPU, RAM, and ROM from the breadboard, stuffed them into the sockets on the new PCB, and confidently flipped the power switch. Oh my eyes, that blue LED was blinding! Who chose that thing?? I tried to take a photo of it, but it’s so overwhelming that it just looks like a white dot on a dim background. Next time I’ll stick with red, but for now I think I’ll need to wear sunglasses when using this thing.

Of course the board didn’t work. When powered on, it appeared to do nothing at all. I poked and prodded for a while with a logic probe, and all the signals seemed to be behaving normally. I don’t know why I always fall back to the logic probe, when I’ve got two logic analyzers and an oscilloscope that would give me much better information, but somehow those tools always feel like too much hassle to get out and set up.

After a few minutes I remembered that I’d made a small change to the address map for the PCB version, so the software for the breadboard version won’t be directly compatible. In order to save CPLD pins and board traces, I changed the way the RDF and TXE status bits are read from the FT245 USB FIFO. In the breadboard version, these status bits appear in different bit positions at a single memory address. But in the PCB version, they appear in bit 0 of two different memory addresses. Both my monitor program and my uClinux FT245 driver needed to be modified to reflect this change.

BREADBOARD 68 KATY               PCB 68 KATY
00000 - 77FFF : ROM              00000 - 77FFF : ROM
78000 - 79FFF : serial in        78000 - 79FFF : serial in
7A000 - 7BFFF : serial out       7A000 - 7BFFF : serial out
7C000 - 7DFFF : serial status    7C000 - 7CFFF : serial status RDF
                                 7D000 - 7DFFF : serial status TXE
7E000 - 7FFFF : LED register     7E000 - 7FFFF : LED register
80000 - FFFFF : RAM              80000 - FFFFF : RAM

Once I made that fix, the board was up and running! I played with the monitor program, booted uClinux, and played Adventure. Everything seemed solid.

 
“Mostly”

The breadboard version of 68 Katy ran at 2 MHz, and didn’t work at higher speeds. I initially tried the PCB version at 2 MHz as well, and everything was great. But when I tried faster speeds like 6 or 8 MHz, it didn’t work at all — it just did nothing, or spewed endless garbage characters. I was disappointed, because I’d hoped the cleaner signals on the PCB vs the breadboard would enable the computer to run at higher speeds.

But wait! After a lot of fiddling around, I discovered that the PCB version of 68 Katy had no trouble running at higher speeds, it just had trouble resetting at higher speeds. If I moved my hand around the CPU while repeatedly pressing the reset button, eventually it would work and the monitor prompt would appear. After that everything was fine, and I could use the monitor program without trouble, or boot into uClinux and play Adventure or run vi. I successfully tested the hardware at 2, 4, 6, and 8 MHz. As long as I could get it to reset cleanly, then it ran flawlessly.

So what’s going on? By touching different CPU pins with my finger, I think I’ve narrowed the problem down to either the /IPL2 interrupt pin, the /RESET and /HALT pins, or the reset button debounce circuit. /IPL2 is the 100 Hz timer interrupt, and it seems like maybe the CPU is immediately hitting an interrupt the instant it comes out of the reset state. Since the interrupt vectors haven’t been initialized yet, it crashes. That does’t fit what I know about the 68008, though – the datasheet says interrupts will be disabled after a CPU reset. Maybe there’s a bug in my monitor program that enables interrupts before the vectors are initialized, but I double-checked and didn’t see anything like that. Anyway, it’s the same monitor program that worked fine on the breadboard.

A more likely explanation is a problem with the reset signal itself. The board has a pushbutton with an RC debounce circuit, with the pushbutton signal connected to a CPLD input. The CPLD uses that to generate the /RESET and /HALT signals for the CPU, which are a little bit strange in the 68000 family. In order to reset the CPU, both /RESET and /HALT should be pulled low. But to exit the reset state, /RESET and /HALT should be allowed to float, and pulled high with an external pull-up resistor. That’s because those signals are actually bidirectional, and are sometimes pulled low by the CPU itself. On the 68 Katy PCB, both signals have independent 10K pull-ups to 5 volts. The CPLD code looks like this:

assign _reset = button ? 1'bZ : 0;
assign _halt = button ? 1'bZ : 0;

Maybe /RESET and /HALT aren’t being deasserted at the same time? Or maybe the rising edge on the pushbutton signal is too slow, and the signal lingers too long in the forbidden voltage zone between logical 0 and 1, causing problems? Indeed, if I monkey with the pushbutton circuit to reduce the RC time constant, it seems to help somewhat, but maybe that’s a red herring.

Maybe the action of the charging/discharging capacitor in the pushbutton circuit is causing some electrical noise that messes up the CPU?

The question is why any of these problems would be worse at higher clock speeds. At 2 MHz, the board runs fine. At 4 MHz, the board fails to reset properly about half the time. At 6 MHz, the board virtually never resets properly, unless I run my finger back and forth across the CPU pins while repeatedly pressing the reset button. 8 MHz behaves even worse than 6 MHz. This must be a clue…