• Please review our updated Terms and Rules here

I built an Iomega ZIP100 parallel port emulator (PIC32MZ + USB disk images) – LPT100 project

mdanh2002

Experienced Member
Joined
Sep 6, 2011
Messages
274
Location
Singapore
A couple of years ago my old Iomega ZIP100 parallel port drive started randomly ejecting disks. Instead of replacing it, I decided to do something slightly unreasonable: reverse-engineer the protocol and build my own ZIP100 emulator. That hobby project eventually became LPT100, a parallel-port ZIP100 emulator implemented on a microcontroller that reads/writes disk images stored on a USB flash drive.

The project ended up being much deeper than expected because there is almost no public documentation of the ZIP parallel protocol. Most of the work involved reverse-engineering the Linux ppa driver, tracing PALMZIP behavior, and capturing port activity.

The final project, named LPT100, was implemented on a PIC32MZ microcontroller and tested with: MS-DOS/Windows 98/Windows XP/Linux (Super 8086 Box, DOSBox-X, QEMU) and MS-DOS + PALMZIP (Book 8088), with disk images stored on USB flash drive. Parallel port interface was done via GPIO + DMA capture.

I documented everything in two articles:

Part 1 – Protocol reverse engineering + emulator in DOSBox/QEMU
https://www.toughdev.com/content/2026/02/pic3 … x-qemu-testing/

Part 2 – Building the actual hardware
https://www.toughdev.com/content/2026/03/pic3 … ardware-design/

Part 1 Video - Emulator testing (DOSBox + QEMU + multiple OSes):

Part 2 Video - Real hardware LPT100 board running on Book 8088:

On my Book8088 system, write speed is ~7.2 KB/s, read speed is around 6.3 KB/s in nibble mode, which is actually pretty close to real ZIP parallel performance on 8088 systems. When tested in Windows 98 using DOSBox-X, the speed is around 50-60KB/sec in bidirectional mode. The emulator works perfectly on 8088-class systems, although faster machines (386+) can overwhelm the microcontroller timing. I might consider migrating to a faster MCU (e.g. Teensy) in a future revision.

If anyone here still uses parallel ZIP drives, I would love to hear your thoughts.
 

Attachments

  • Screenshot-2026-03-15-120649.webp
    Screenshot-2026-03-15-120649.webp
    758 KB · Views: 10
  • i-built-an-iomega-zip100-parallel-port-emulator-pic32mz-usb-v0-xnfoj684q5pg1.webp
    i-built-an-iomega-zip100-parallel-port-emulator-pic32mz-usb-v0-xnfoj684q5pg1.webp
    37.9 KB · Views: 9
  • i-built-an-iomega-zip100-parallel-port-emulator-pic32mz-usb-v0-dv3stlo3q5pg1.webp
    i-built-an-iomega-zip100-parallel-port-emulator-pic32mz-usb-v0-dv3stlo3q5pg1.webp
    82.2 KB · Views: 10
  • i-built-an-iomega-zip100-parallel-port-emulator-pic32mz-usb-v0-splyc293q5pg1.webp
    i-built-an-iomega-zip100-parallel-port-emulator-pic32mz-usb-v0-splyc293q5pg1.webp
    25.3 KB · Views: 9
Neat work. As far as optimization, I assume you already did the obvious -O3/-Os to see which one is faster (IIRC the MZ series has a code fetch cache but it may not be fast enough to benefit from -Os)
I am starting to see more people using the RP2350 for similar types of endeavors because of its more powerful DMA capability that can be programmed in a more granular way.
 
I played with various optimization switches. No effects at all. The main bottleneck is in iomega_updateState(), which now spans a few thousand lines with just if/else/goto. I do not believe compiler optimization will help much with this. Setting the interrupt priority has some effects (I could get DEBUG sector read to somewhat work on the Pocket 386) but then the USB started to act up.

Adding DMA to copy all data to a buffer before processing really helped. Prior to implementing DMA, I used several interrupt routines (as well as Input Change Notification) to detect pin change. This resulted in a lot of data corruptions due to the MCU frequently missing out on events, even on a 8088 at 8MHz. With DMA added, at least it worked well on my Book 8088 with an NEC v20 installed.
 
Yes, I am working on a few boards that can perhaps be sold on eBay. The next version will use the Teensy microcontroller and supports ECP/EPP. I am also tempted to implemented support for Atari parallel port (with PARCP), Amiga parallel port and maybe Laplink parallel transfer.
 
I find getting files over to my vintage computers to be one of my biggest headaches. Most times I end up using CF card hard drives and rebooting every time just because its the only reliable way. I do have some parallel port zip drives, but this device sounds like an ideal solution.
 
Yes, I am working on a few boards that can perhaps be sold on eBay. The next version will use the Teensy microcontroller and supports ECP/EPP. I am also tempted to implemented support for Atari parallel port (with PARCP), Amiga parallel port and maybe Laplink parallel transfer.
InterLink support would be cool since you could transfer files on a bone stock MS-DOS 6 install.
 
Back
Top