|GPIB disk emulator|
NEW: We now have bare boards for sale. See below for details.
Pretty please! read the errata at the bottom of this page before assembling.
Fancy being able to store the data from your old HP163xx analyser? Or your Spectrum Analyzer? Or pretty much any old GPIB-instrument that supports a GPIB-Based disk? Or even that Old Commodore? Sounds Cool? Then this project is for you! Using a PIC 18F4620 an SD-card and a few other components, this project will emulate a HP 9121 disk drive, or other Amigo drives with minor changes in the code. The actual disk data is stored as an image file on the SD and should be readable by the standard Linux LIF utilities or the excellent HPDir utility. (Tested with version 2.03)
The protocol used to control various types of disk drives over GPIB is sometimes called "Amigo" and sometimes "HP-300 Compatible HP-IB". It is fairly elegant and mostly compatible with IEEE-488. When I say mostly is because it implements an "ID" function that is not compatible with 488. The protocol has another weakness: The controller needs to have detailed knowledge of the drive, based on the "ID", ie drive geometry etc. Amigo was later superseeded by the CS/80 (Command Set for the 80's) and it's sister SS/80 (Subset 80) protocol that is more parameterised. Note that some HP units support Amigo, others CS/80, some support both. Check your manuals first! The current firmware supports Amigo and SS/80.
The problems with Amigo soon became evident. Each controller needed to have knowledge of each disk drive, so a new type could npt be used, unless you upgraded the firmware.
To overcome this, HP developed "Command Set for the 80's", later named CS/80 for typographical reasons. With CS/80, a controller needed only to issue a DESCRIBE and the
drive would return all the info the controller needed. Not only geometry, but also stuff like how much time a seek might take and so on. To boot, the protocol used a linear
addressing, instead of cylinder/head/sector. The maximum vector is 6-bytes, allowing a maximum disk size of 2^48 bytes, well beyond what was available in the 80's.
HP Also defined a subset of CS/80, called SS/80 to be used with low-cost drives.
Both SS/80 and CS/80 have "proper" manuals, but Amigo was never formally documented as far as I know. The best Amigo documentation available today is probably the service manuals for old HP diskdrivers such as the HP 9895A and the HP 9123D, available from the HP Museum. Also see the very extensive documentation at The HPDrive Project .
One aspect that is indelibly woven into GPIB is the concept of polling. The controller need to be able to fire off a request to a unit, then go its merry way and return later and check for status. This check is called "polling" and GPIB defines two types: Serial and Parallell. With serial polling the controller addresses each instrument and asks for status. With many instruments, this can be slow. With parallell polling the controller gets the status of up to 8 units in one go. This is how a Parallell Poll takes place: The controller asserts (pulls low) ATN and EOI simultaneously. The units detect this and respond by pulling one dataline low to indicate completion. The actual address can be configured from the host, but the default is that the unit with address 0 pulls DIO8 low, address1 pulls DIO7 low, etc. As you can see, Parallell Polling has very little overhead, hence it is often used for disks.
The current firmware is hardcoded for address zero (0) so the jumper should be in the position marked 0 on the silkscreen. I decided to make it selectable in hardware in case I ever made the address configurable in software,
The design started out as a spinoff of my GPIB Adapter, but I had to change the PIC to a 44-pin part to have enough pins to control everything als also have room for expansion. I did some initial trials with the Microchip SD-library, but found it to be an overkill. I ended up using PetitFATFS. PetitfatFS only supports one file and has some quirks when writing (you need to write a full sector of 512 bytes and you cannot create files), but takes up very little RAM. The current code, implementing a bare minimum of the Amigo protocol, weighs in at 15 250 bytes, leaving more than 50% of the RAM free for further expansion.
Note that the one file limit in PetitFatFs is not a problem. There is only one file on the SD-card and that file is an image of the LIF (HP) disk. All the LIF files you save from your instrument are inside this image file.
The HP 9123D is a dual microfloppy drive with 70 tracks and 16 sectors/track. The protocol is Amigo. That drive is old enough so that it should be recognised by most old HP instruments. Data on the SD card is simply an image of the disk, starting with sector 0.
The HP 9122D is a dual microfloppy drive with 80 tracks and 16 sectors/track. The protocol is SS/80.
The HP 9134D is a Winchester (hard disk) with 303 tracks, 6 heads and 32 sectors/track. The protocol is SS/80.
The circuit is fairly straightforward. The 16 GPIB lines are connected to PIC ports and simply wiggled through the TRIS-bit. Ie the pin is made input to make it high/threestate and output and driven low to simulate the original GPIB open-collector drivers.
The SD-card operates at 3.3V so a separate regulator is needed for that. Using a 3.3V PIC is not an option because of GPIB signal levels. Level shifting between 5V and 3.3V is done with resistive dividers (5V->3.3V) and a mosfet (3.3V->5V). The circuit can be equipped with either a standard SD-holder or a micro one.
The circuit around U1 and Q1 might need some explanation: If we remember our Parallell Poll from above, then ideally, a device should respond within 100ns to a parallell poll (ATN and EOI asserted). To do this in software requires a silly high CPU speed. So this is better done in hardware. The parallel poll response is brought out on RA0, low for asserted and high for unasserted. If RA0 is low and both ATN and EOI happen to be low, then the output of the gate goes high Q1 turns on, pulling the selected dataline (through P8) low. Since the software default of this unit is address 0, you should pull DIO8 low. The purpose of P8 is to make the address selectable if need be in the future. For now, place the jumper in the topmost position, marked "0" on the PCB as the default address of the FW is 0.
I had some problems with the level shifter for the SD card. A good explanation of the problems can be found here, The fix is to change R4 to 1k8. I will also replace the FET with another one with lower Vth, such as BSH 103.
PCB can be equipped with either a standard SD-Card connector or a Micro SD one. Use an angled GPIB connector or a straight GPIB-plug with soldered on wires. Note that I have always used a male connector to allow the PCB to be plugged into an instrument. You need to watch out for the pin orientation. Pin 1 is the top left pin when seen from the component side and pin 24 is bottom right, grounded. A female PCB connector, such as Mouser 636-112-024-213R001 goes on the component side. A male PCB connector, such as 636-112-024-113R001 goes on the reverse side. Same for decoupling caps C7 and C8.
GPIB-connector on reverse side
Alternative, using a GPIB female PCB connector. A male PCB should be mounted on the reverse side of the board. Note position of pin 1
We now have boards for sale. They are of professional quality, plated,soldermasked and silk-screened. The cost per bare board is 25€ plus postage. Postage and packing to Europe is 4€ with priority mail. Please send an email to email@example.com if you are interested.
Bill of materials.
Those familiar with my GPIB Adapter will recognise the code, even if the gpib.* files are cleaned up extensively. All pin assignments are now done through #defines so it should be fairly easy to change around pins or port to another PIC. A word of caution though: You need a 5V capable PIC that has ports that can sink 25mA in case you have more than a handful instruments on the bus.
One difference from the GPIB adapter is that gpib.c calls amigo.c or ss80.c for every received byte, this is because we need to be able to act on a command sequence when it happens. The received byte is pushed into a finite-state-machine where the Amigo or SS/80 protocol is decoded. If a valid command has been detected a status > 0 is returned to GPIB which stops reception and the appropriate command is executed. Adding commands is easy: Just add the decoding to the finite -state-machine, add a return code and a handler for that command.
Will post the latest source once I have it in presentable form
The fall FW now works correctly with the HP85 computer (SS80 only) and adds a new feature: You can have up to 8 disk images and select which one with a suitable BCD Switch.
To activate the disk select feature, you must add DSKSEL 1 to hpdisk.cfg. The FW will then poll the lower three bits on PORTE (pins 6,7,8 on AUX) and select between files lifdata0.bin, through lifdata7.bin. A suitable hardware consists of a binary or BCD switch that pulls up those pins through a 10k resistor. You also need pulldowns, say 100k per pin.
Latest (2016-11-18) Firmware for hardware parallell poll only
A slightly older (2014-02-24) Firmware for both hardware and software parallell poll
You will need a PIC programmer to program updated firmware. I, myself use Microchip's PICKit, but I have had reports of users having good results with the JDM Programmer and PICPgm
Sample lifdata.bin for a HP 9122 729k drive
Sample config file for Amigo
Sample lifdata.bin for a HP 9134L 15Mb Winchester drive
Sample config file for SS/80
Note that the current firmware reads configuration data from a file named hpdisk.cfg on the SD card. The format is very simple: Lines with KEYWORD-VALUE pairs one space between. This way the desired protocol (Amigo or SS/80) can be selected. The config file is read on startup only. The structure of the image file is the same for both Amigo and S/80, ie you can easily read an image created with Amigo, on a SS/80 system.
The source is compiled under MPLAB 8.92
Latest (2014-01-08 v0.6) files. I kindly ask anyone who fixes bugs or makes improvements to send me the files so I can incorporate it in the main project
Download the desired versions of lifdata.bin and hpdisk.cfg and copy to the root of the SD card. Jumper PP to address zero (corresponds to HPDisk being unit zero). Insert card and boot up HPDisk. The firmware will try to mount the card, read hpdisk.cfg and then start polling GPIB. If the mounting or opening of lifdata.bin fails, LED1 will blink an error code. Count the number of short flashes before the long. That is the code (1..7). Codes are straight from PetitFatFs:
If you see a return code of 7, then something is wrong at a lower level. Common causes are not having a BSH103 as Q2 or ripple on the power line.
If the disk ops are OK, both leds will start flashing, indicating GPIB activity.
Note that there are two revisions of the PCB. The original one and the b-revision from April 2016.
The footprint on the Hirose Micro-SD connector is wrong. Use a regular size SD-connector
The silkscreen for the resistor packs is not clear when it comes to orientation, but all three should be oriented the same way as the IC marked U1
The large pads for the large SD connector are not connected to ground. They should be, or card detect and write protect will not work. Solder a wire from the SD Card holder body to ground
Micro SD-card holders do not have a write-protect switch. If you use a Micro-SD, you need to jumper pin 11 on the big SD-card footprint to ground.
Martin Zumr from the Czech Republic has made this video
showing HPDisk in action on his HP-85 computer. Enjoy!
This information and the circuits are provided as is without any express or implied warranties. While every effort has been taken to ensure the accuracy of the information contained in this text, the authors/maintainers/contributors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. I disclaim everything. The contents of the articles below might be totally inaccurate, inappropriate, or misguided. There is no guarantee as to the suitability of said circuits and information for any purpose whatsoever other than as a self-training aid. I.E. If it blows your equipments, trashes your hard disc, wipes your backup, burns your building down or just plain don't work, IT ISN'T MY FAULT. In the event of judicial ruling to the contrary, any liability shall be limited to the sum charged on you by us for the aforementioned document or nothing, whichever is the lower. I will not be held responsible for any damages or costs which might occur as a result of my advice or designs. Nor are you allowed to use any of my designs for commercial purposes without my written authorisation.