>>> [is your 300 a 320?]
>> I don't know.  [physical description]  I take it this makes it an
>> HP9000/300 series machine, but I don't know how to get anything more
>> precise than that.
> [...]

I started looking at building an HP-IB pseudo-disk out of a peecee
parallel port and some glue logic.  For preparatory experimentation, I
got out my 7958s, planning to snoop the HP-IB exchange between the host
and them in the system search process.

Then I discovered, to my surprise (and delight), that the (wetware)
memory saying they were dead was partially bitrotted.  One of them
seems dead - the front panel light is red - but the other works, its
bootblocks still intact.  I don't know about its kernel, because,
noticing that the bootblocks reported seeing scsi0 at 14, I put the
SCSI disk on it and told the bootblocks to boot sd6a:netbsd -s, and it
booted.

I then discovered I'd forgotten to populate /dev, but the init I'd put
on that disk went off and did an mfs /dev for me.  I'm now dumping rd0
(the working HP-IB disk) to one of my other machines over NFS, to
preserve the data at least (it's the only known-working bootblock set I
have at present).

*Then* I'll see about synthesizing a pseudo-disk with a parallel port
and some glue logic.  (Why bother?  Because I don't trust the working
disk to stay working, and from this experience I can see that I don't
need more than the bootblocks over HP-IB.)

> Sigh, no one claimed my HP-IB disks, and they were sent to the
> recycler.  They were big MFM drives connected to an HP-IB interface.
> (They were probably too heavy to ship to Montreal anyway).

Yes, that's almost certainly why I didn't snag them myself (I don't
specifically remember seeing them, but probably did and figured they'd
be much too heavy to be worth shipping).  I'll open up the dead 7958
and see if the interface between the HP-IB card and the disk itself
matches any of the old drives I have lying around, just in case it's
willing to work with one.

>> I have an IEEE488 Sbus card, but no information on the interface it
>> [presents] to the host, so that's not much use.
> See if you can determine which chip it uses.

There is a chip of some 150-200 pins, but it's marked "SPARC DMA+" and
is next to the SBus connector, so it's presumably the SBus interface.

The only other "big" chips are a socketed chip with a sticker on it,
which looks like a PROM (presumably containing firmware), and
soldered-in 40-pin through-hole DIP from NEC marked

	NEC JAPAN
	D7210C
	9536XD001

There are also three socketed 20-pin DIPs marked

	GAL18V10
	20LP
	A608C01

which are also marked (in what looks like pencil) 0, 1, and 2.  The
only other chips are: SN74HCT244N, SN74HCT652NT, SN75160BN, SN74LS244N,
SN75162BN, SN74LS273N, and a four-pin thing which looks like a crystal
oscillator (despite being packaged in a plastic DIP): "SG531P C" /
"16.0000M" / "4372A".

> Greg McGarry wrote an ISA driver for the NEC 7210 GPIB chip
> (dev/isa/cec.c).

This is a good enough match to the "D7210C" NEC chip that I think I'll
pop this card in a machine and see if I can do anything based on the
cec driver you refer to.  Maybe I won't have to hack around with
parallel ports.

> Greg also has MI code for HPIB disks and tapes in sys/dev/gpib ...
> the command set used by HP was called "CS/80".  You should be able to
> obtain the knowledge you need from that code base.

Many thanks for the pointers.  I'll go away now and see what I can do
with them. :-)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B