GPIB (was Re: OT: Windows profanity)

From: Ethan Dicks <>
Date: Fri Mar 19 18:50:12 2004

On Sat, Mar 20, 2004 at 12:03:32AM +0000, Tony Duell wrote:
> > I do, however, have a few Texas Instruments GPIB interface ICs (SN75160BN and
> > SN75161BN) in my junkbox. The GPIB connectors are standard anyway - 24-way
> If you're just talking to 1 or 2 peripherals (say you want to hook up a
> GPIB plotter, or you want to get the data off an HP disk drive) you can
> get away without the special buffers. You can use open-collector TTL
> gates to drive the bus, and TTL schmitt triggers ('14s, for example) as
> receivers. Like many things I'd not do this on a 'production' board, but
> it works as a hack.

Interesting... I had not thought of substitute line drivers, but it makes
sense... unless you are trying to build a gargantuan PET system (the kind
nobody could afford "back in the day"), most people had one disk drive box
(2040/4040/2031/8050...) and _maybe_ a printer. These days, though, the
most common thing for Commodore owners would be to hook up a disk drive
to a modernish machine to extract floppies... using O.C. drivers and
Schmitt trigger receivers would work just fine for that.
> You don't need a GPIB talker/listener/controller IC. The whole bus is
> designed so that the handshakes are 'interlocked' That is, something
> happening in one device causes some other device to do something, then
> the first device might do something else, etc. You can do the whole
> handshake in software (Commodore always did, in the PET and all the
> peripherals), and there's no chance of missing a signal transition.
> Alternatively you can make some state machines from TTL or PALs (I did
> this years ago, it's not hard) if you like hardware.

Hmm... I had not thought of a state machine, but my experience with GPIB
is 100% Commodore, so I'm perfectly comfortable with software-driven
handshaking. Since all of C='s peripherals were 6502-family-based, it's
not like you'd get the data any faster with a hardware solution.
I have a couple of add-on IEEE-488 carts for the VIC-20 and C-64 - same
basic design - a ROM (for the low-level protocol code), some form of
PIA or VIA, and SN75160BN/SN75161BN line drivers wired up to the output
ports of the VLSI I/O chip. The PET used different drivers that
seperated the signals so that the host sees unidirectional lines, but
that's just a minor implementation detail.

> I have plenty of GPIB-capable machines from handheld calculators up to
> workstations (e.g. HP41 + HPIL + HP82169 translator in the first case,
> PERQ in the second). I even have the Acorn interface for the Beeb.
> Nothing spare, though

With one exception, all of my GPIB hardware is C= or third-party for
C= CPUs... I do have one HP 9-track tape drive with a GPIB interface,
but I've never even powered it up. I should Google for some information
on it when I get home... I have no idea how much buffer space it has
onboard, or if you could drive it at the incredibly slow software-driven
C= data rates, but it'd be cool to put a 9-track on a PET! I'm sure
you could talk to it, but whether or not you could transfer real data
to/from it would be another question entirely.

Whenever I contemplate my own modular 6502 homebrew system, I always
include a GPIB interface since I know I can roll one with a few chips
and a couple of K of machine code, and then have access to a raft of
existing peripherals, but then I remember that I could just go back and
hack some PETs, and the urge to build from scratch subsides. :-)


Ethan Dicks, A-130-S      Current South Pole Weather at 20-Mar-2004 13:28 Z
South Pole Station
PSC 468 Box 400       Temp -61.9 F (-52.2 C)    Windchill     -106 F (-76.7 C)
APO AP 96598          Wind  10.5 kts Grid 030   Barometer 683.1 mb (10508. ft)
Received on Fri Mar 19 2004 - 18:50:12 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:05 BST