HP-IB, Amigo/cs80 was Re: hp 9153 floppy & disk

Tony Duell 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 [1] 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. 

[1] 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)

Indeed...

> 
> > (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 
use hree).

-tony




More information about the cctech mailing list