Skip to main content

HP-125 Floppy Drive Emulation

A 'back burner' project I have in mind is to repair an old HP-125 computer I picked up at a thrift shop quite a while ago. This computer has no onboard storage drives, instead coming paired with an HP-82901M floppy drive unit, which communicates over HPIB/GPIB/IEEE-488 (whatever you want to call it). These drives are either pure unobtanium, or are downright bankrupting, so I need to find a way to emulate it.

My requirements are as follows:
  • Standalone operation, not requiring another computer to emulate
  • Low cost parts, or using mostly parts I have on hand
  • (Optional) Multiple uses, I don't want this to be a one-trick pony

While I've learned how the GPIB protocol works, I have no idea what the command set is that either the HP-125 and/or HP-82901M speaks. I've found mention of the HP-82901M using the Amigo command set, as introduced with the HP-300 "Amigo", on this page about emulating an Amigo-compatible drive with a modern PC. That project requires dedicated GPIB cards that regularly run in the hundred+ dollar range, and requires you to have a desktop computer running alongside whatever computer you're trying to boot. This won't do for my requirements.

Unfortunately, they don't list the commands themselves, so my search had to lead elsewhere. One thing I did notice, is that the HP-7970E tape drive was listed as a compatible drive, and I found a listing of commands that it spoke. Unfortunately, most of them only apply to tapes, and not floppy or hard disks, and so I had an incomplete set of commands. The documentation on Bitsavers is sparse for the 82901, and nonexistent for the Amigo command set specifically.

One site I came across, that talks about a microcontroller-based approach, led me on a clue. Turns out this is a rare instance of HP not being the smartest in their documentation. They list the command set in the back of the service manual for the HP-9895A floppy drive unit, rather than its own manual as was done for the successors to the Amigo command set, CS/80 and SS/80.

The previously listed site does provide schematics and firmware, so it could end there. However, it's quite wasteful to use an entire SD card for one disk image. Another issue I have with it is it only provides storage for Amigo-compatible computers. At this point, and after all the effort I went to to find the command-set in the first place, it'd seem like a hollow victory to use someone else's single-use design. I decided to see just what I could do my own way.

So I now have a copy of the command set, and an idea. I've already been planning to make my own GPIB-connected storage modules, and I decided I could merge this into one of them.

My current plan, which is subject to change, is to include a switch on the front, to either start the module in 'Emulated' mode to work as an Amigo-compatible storage device, or 'Standard' mode to work with my own project computers. In 'Emulated' mode, each 'unit' of the drive will use one of eight disk images selected by a thumbwheel. In 'Standard' mode, all but the sectors containing disk images are present to computers running my own command set.

Comments

  1. Well. The way I have it with HPDisk is that I now have a 16-way switch that lets med change "disks". Amigo is a horrid protocol to emulate, SS/80 is so much cleaner. Currently using HPDisk with a HP9816 in SS/80 mode.

    ReplyDelete

Post a Comment

Popular posts from this blog

Disk Selection

So I've started work on the BIOS-ROM for the Z80-based Zephyr computer in preparation for use with BP-DOS, and I needed to decide between SCSI or IDE for a storage disk. The SCSI disk I have would be ideal on the hardware level, since both commands and data are 8-bit (with hardware generated/checked parity), plus it would make for a nice auditory experience being a full-height 5.25" disk. However, an issue arose when reading through the commands section of the SCSI standard, there are several different bus phases, and the flow path can be quite confusing at times. I'm sure given time it could be done, but I'm interested in getting the Zephyr computer running in a reasonable time frame. Instead, I have opted for using one or two IDE disks, for simplicity of the bus and command-set. Data transfers are done on 16-bit words, so a data read/write takes two input/output cycles from the CPU, and the ordering of which byte of the word will vary between reads and writes. On

EEPROM Programmer Pt.2

I have decided to revisit my earlier plan of making an EEPROM programmer with as few I/O pins required as possible. I have decided to abandon that requirement in favor of making something functionally complete with a minimum of software development required. I'm using an Arduino Mega as the programming controller, with the sole reason being the large amount of I/O pins available. Rather than reflashing the controller every time an EEPROM needs to be rewritten to hold a new program, I've implemented a method to send the desired program over a serial connection, and program the EEPROM in 128-byte chunks. This is done via the Xmodem protocol, which allows for a pause between packets to allow time for programming 128 bytes at a time, before requesting the next packet. Due to the variant of EEPROM I have, a 12V level signal needs to be applied to the /OE pin in order to enable a full chip erase. This 12V line will be handled by an opto-coupler, and a momentary pushbutton acting