HP-IB, Amigo/cs80 was Re: hp 9153 floppy & disk
ard at p850ug1.demon.co.uk
Sun Feb 14 12:43:34 CST 2010
> Tony Duell wrote:
> > IIRC, the interface to a CF card is essentially IDE, so you could use
> > non-rotating memory if you wanted to.
> Sorry, I would use sd-flash. much easier to deal with, less I/O.
So would I (is that thw oen with an SPI-like interface?). But another
list member mentioned making a device using IDE hard disks, and I was
commenting that if such a device was created, it could also use CF cards
with little, if any, modification.
> > Yes, that's the problem. Most of the traditional HPIB interface chips
> > have long beend discontinued. And ehile you might be able to fet them for
> > repair purposed, I'd rahter not such a device in a new design.
> Here I would put an cpld/fpga on it. Only newer chips available are PCI.
> Bit-Banging the GP-IB is doable, but why ?
Why would you want to use a CPLD/FPGA here? It's another chip, it's
another chip that has to be programmed (and for which you need the
development tools  and a machine to run them on), and it doesn't give
you anyting. Using just about any microcontroller, you can bit-bang the
HPIB handshake plenty fast enough.
 And unlike most microcontroollers, you have to use the proprietary
tools, you can't write your own.
I suspect that with a sensible choice of microcntroller, it could be
built in 4 or 5 chips (microcontroller, a couple of HPIB buffers, the
minimal logic needed to support a banged HPIB handshake and maybe buffers
to the flash memroy device).
Now if I was designing this for myself, I can assure you I'd use a
microprocessor, separate ROM and RAM, some kind of HPIB controller chip
(HP used the Intel 8291 in most of their drive units), and whatever chips
were needed to link up the flash memory device. And of course a pile of
TTL for clocks, reset, address decoding, etc. The reason is that it would
be easier for me to debug the firmware in a setup like that (I could use
an EPROM emulaotr, I could also use a logic analyser to trace the code as
it was running). Problem is, nobody would want to build that, so I feel a
single-chip miocrocontroller + buffers is probably the most senible solution.
> > [75160/xxx]
> Definitely I would use them. No reason to make a real project out of
> this, and suffer, because somebody put 200 devices on it.
> If you do it, do it right (tm)
> > (DIL CPUs, whatever)
> Here I'm disagreeing, Probably even BGA, but who cares ?
> There more interesting chips are BGA, and I'm not thinking about
> replacing the CPU anyway.
The problem with BGAs is that they're alomost impossible to prototype
with, and not many people have the setup to solder them onto a PCB
anyway (I don't). So who is going to be able to actually build the thing?
Oh yes, I'd want to solder the PCBs myself. That way I know they're
soldeed with 'real' solder...
> That would be my approach, to put everything in one chip, but the
> drivers ;-)
My (serious) approach too. One chip + buffers (to HPIB) + the flash
memory device. And since you really need that chip to be a processor (you
try doing the CS/80 protocol in random logic ;-)),, it makes more sense
to use a microcontroller than an FPGA here (yes, I know you _can_ make a
processor in an FPGA, I've done it, but it's not the sensible thing to
More information about the cctech