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

[Tony Duell]

> 
> 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=
> e
> > 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 
not essential.

> 
> > 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 
major problem.

> 
> >> 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 
sets.

> 
> > 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 
programs, etc.

> 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. 

-tony