HP-IB, Amigo/cs80 was Re: hp 9153 floppy & disk
ard at p850ug1.demon.co.uk
Fri Feb 12 16:09:09 CST 2010
> On Fri, Feb 12, 2010 at 3:19 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote=
> >> How about an AVR-based box (open, no BGAs, etc) perhaps with an SD
> >> socket or CF socket, with an HPIB interface that will work with a)
> > That would seem to be a good idea.
> > I would suggest that the HPIB interface be buffered (using either the
> > 75160/1/2 series of chips, which would use 2 devices, or 4 off 3448 or
> > similar.). =A0As I mentiond a few weeks back it is a lot easier to replac=
> > a buffer chip than a microcontorller iff something goes wrong).
> I'm all in favor of buffered devices - especially since CBM machines
> quickly grow to 1-2 disk devices and a printer, at least, if you are
> using real hardware (vs just imaging old floppies).
And HP set-ups might have even more devices (HP made a lot of nice HPIB
peripehrals, the 5930x series, for example).
> Is there really a significant advantage, cost or availability, between
> 75160/1/2s and 3448s? I've seen both used in 1970s and 1980s IEEE-488
> devices and have no personal preferences either way.
I can't comment on the cont, I've not bought these chips for many years.
I remember seeing the 75160 listed by, IIRC, Digikey recently, so I guess
it's still easily avaialble.
The difference is hat the 7516x devices contain 8 buffers. The 75160 has
a common dirextion line, and is usd for the 8 data lines. The 75161 has
direction control set up so the buffer can be used in a device, or, IIRC
as the system controller, but not as a 'second' controller. The 75162 can
operate in all 3 ways, A 75161 should eb enough for the disk emulator,
but the 75162 might be easier to find.
The 3448, etc, contain 4 buffers. 4 of them can be used as a device,
controller, or system controller interface. You may need a little
external logic 9or exra port pins) so as to get DAV and NRFD/NDAC going
in oposite directions.
> > There should be no broblem with 'banging' the handshake on
> > microcontroller port lines. HP haev been known to do this. IIRC you need
> > a very small maount of external logic (let me check) to ensure one signal
> > changes fast enough. It's only a couple of TTL chips, though (and common
> > ones, like 74x00), not really worth putting in a PLD.
> I do recall seeing something like that in discussions on the CBM
> Hackers' list - a gate or two to flip a signal faster than a 1MHz
> processor can do in software.
Exactly. If /when we get to this stage in the design I will see what HP
did in soem of their software-implemented HPIB units.
> > HPIB would take 16 port lines of the microcontroller + 2 or 3 to control
> > the buffer driection. And then you need however many port lines it takes
> > to talk to the flash memroy device.
> If it's quick enough, you _could_ use an 8-bit shift register for
> input and/or output, reducing the MCU pincount substantially, but that
> would probably only be important if you were trying to keep the MCU
> below the size of the 40/44-pin varieties.
40 pin microcontorllers may have 32 port lines (4 8 bit ports) IIRC. That
should eb easily enough -- 8 data lines for HPIB, 8 control lines for
HPIB and 3 driection cotnrol ines would still leave 11 lines free. IIRC
some of the flash memory card things have an SPI-like serial
interfacewhich needs 3 or 4 lines.
I would prefer a microcontroller that could be socketed (DIP or PLCC,
possibly) since it's easier to hand-wire the prototype board. But it's
> > As regards code size, IIEC, the HP9133H (SS/80 protocol) has 16K of 6809
> > conde in it. That should give you some idea as to the complexity.
> That does. Even a $4 AVR has 16K of code space these days.
I suspect that 6809 code is a bit more efficient than many
microcontroller codes. But these days memory space is probably not a
> >> Once you have a platform that is electrically and timing-compatible
> >> with HPs and PETs, it shouldn't matter if you choose to implement
> >> Amiga/CS80 or CBM "DOS" at the firmware level...
> > The Commodore and HP command sets are very different. The major
> > difference is that Commodore drives are file-oriented devices (you open a
> > file by name, you can get a directory, etc), while HP devices are block
> > oriented.
> Yes. In terms of complexity, the CBM command set encompasses the
> functionality of the HP command set. If you coded for the PET, I
HP have all sorts of indentification, status, etc, commands. It's not a
totally trivial command set to implement.
> don't think it would be hard to have it also do Amiga/CS80, but I'd
> have to examine the HP technique since I've never worked with it.
You need to hunt through some of the manuals on hpmuseum.net. If I have
time I'll see if I can identify manuals that document the 3 main command
> > Yes, I know the Commodore drives let you read disks at hte block level, b=
> ut most
> > of the time you didn't do that. H
> It depends on what you are doing. I've written many disk utilities
Oh sure. I was thinking of rthe average user, loading and saving BASIC
> that "understand" the block-level format to do things like undelete
> files, etc. 95%+ of what CBM users do though is, as you point out, at
> the file level. You have to implement memory read and write commands
> (M-R, M-W) to do things like change unit numbers, so I would consider
> a strict files-only implementation to be incomplete.
I would agree.
More information about the cctalk