19 Mar
2004
19 Mar
'04
10:50 a.m.
On Sat, Mar 20, 2004 at 12:03:32AM +0000, Tony Duell wrote:
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.
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. 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
--
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)
Ethan.Dicks(a)amanda.spole.gov http://penguincentral.com/penguincentral.html