IEEE-what? By definiton an IEEE-488 parallel port can emulate GPIB because IEEE-488 _is_ GPIB If you mean the bidirectional printer port that's found in many PCs, I don't think you have enough signal lines. GPIB has 8 data lines and 8 control lines (split up into 3 handshake lines and 5 bus control lins), all bidiriectional. And IIRC there are times when at least the data lines have to be open-collector (repsonding ot a prallel poll being the most common, I think). I don't think a PC printer port can do that, can it? A Victor 9000/Sirius printer port on the other hand... -tony

I thought you had enough outputs to have an ATN line, so you could do addressing. I think you can have multiple devices hooked up to a PC printer port pretending to be GPIB. But I don;t thinkl you can respond to paralell polls on the PC. I seem to remembr you are short of I/O lines, you can't have all of the bus control lines. Missing out EOI and SRQ is not a problem if you just wnat to talk to an HPIB plotter, it is a big problem if you are tryin to emulate an HPIB disk drive. If not, I have one of your GPIB-on-a-printer port programs here. It's the old one that uses an original PC printer port card with the well-knwon cut-and-jumper mod (why this isn't docuemtned in the IBM manuals is beyond me, the board is clearly laid out for it). -tony

I would love to see sometimg similar, but a stand-alone (no PC) device. It should be possible to do it with a microcontroller [1] and some flash memory device (CF card or whatever) and not a lot more. I think you could bit-bang the HPIB protocol with little, if any, external logic. But I don't feel able to write the firmware. [1] Yes, I did say microcontroller. It would be ridiculous to try to do this with a board of random logic :-) It would be a heck of a lot of fun trying to implement the SS/80 protocol using state machines, though <evil grin>. And me. And from what I recall he doesn't release the source code, so you can't port it. There's another problem too. It doesn't (and can't) work with GPIB cards in the PC using the TMS9914 chip. IIRC it's impossible to make an HP-compatible disk unit using a 9914 to talk to the HPIB, one part of the protocol requires you to do something the 9914 can't do (I forget the exact details). You can make a host to talk to HP drives using a 9914, though HP computers that use these drives used to use 9914s (things like the HP120, HP150, HP9000/200, etc). Then they went over to their own Medusa chip (1TL1 IIRC).The drives started out using the Intel 8291 HPIB interface (this one can do whatever it is that the 9914 can't), IIRC some later (for me) ones used the Medusa. -tony

On Mon, 7 Dec 2009, J. David Bryan wrote: I don't really understand that either, but anyways, I'd be happy with a [CS]S/80-only version. Christian

On Tuesday, December 8, 2009 at 19:47, Tony Duell wrote: Yes. There were several different controller cards used in these, including different ones for the same model, depending on the date code. See "HP's 5 1/4-Inch Winchester Disc Drive Service Documentation" (part number 09134-90032, August 1983). Section II, page 1-4 says, in part: "The HP-IB bus controller (9914 HP-IB chip) manages the data transfers across the HP-IB channel." This is from the section entitled, "Winchester Controller PCA Theory of Operation (88134-69910, 09135-69515, and 09135-69501)." The last part number is the one in my 9134A. There's a photograph of the card on page 1-8, and you can see the 9914 chip on the board. The 9133V and XV used controller part number 09133-69508, according to Section III, page 1-2 of the aforementioned manual. Section III, page 1-5 says that controller uses an 8291A. -- Dave

On Wednesday, December 9, 2009 at 19:04, Tony Duell wrote: Early 9134As had third-party OEM controllers, which may explain it. The later units had HP-supplied controllers that use 8291s. Unfortunately, the manual has only block diagrams of the controllers, although it does have schematics of the power supplies. It does have a list of assembly numbers, which is useful, and some adjustment data. Primarily, though, it has a fairly comprehensive description of the Amigo protocol (~60 pages). -- Dave

Tony Duell ????????: The Xebec OEM controller for the 9134A uses a 9914. It speaks Amigo. IIRC, the later HP board used for the 9133A also uses a 9914. The 9121 also uses a 9914. jd

On 10 Dec 2009 at 21:15, Tony Duell wrote: I believe that the original TMS9914 was compliant with the IEEE488 1975 standard. The 8291 used the 1980 standard, or so I recall. Tempus fugit. There was a 9914A part that had updated functionality, but it may have come along too late. --Chuck

I still think it would be a useful project for somebody to make a HP-drive-emulator. Mot using a PC, but using a microntroller, HPIB buffers, the minimal (if any) logic you need to handle HPIB, and a CF card. Make it 'open( and I'll build several... I have never actually seen this Xebec controller in an HP drive unit, but I'll believe it exists. I can;t see why that would be a problem. The HP protocols are all block, not file, baeed (unlike the Commodore drives for the PET). The drive doesn't have any idea what OS is talking to the it, it has no understanding for the directory or the filesystem. I wouldn't bet on it. I am pretty sure the later drives, at least (9144H, etc) check that the hard drive actually matches what is expected (I have been told the cotnroller tries to select non-exixstant heads and makes sure the drive asserts the erorr line, things like that). The 9133V controller (I assume there's a 9134 version, if only becuase you could trivially remoove the floppy drive and controller from a 9133V) can be jumpered to work in 3 ways : With a 5M drive (ST406, and no, that isn't a typo [1]), this is a normal 9133V With a 15Mbyte drive (ST419), that's a 9133XV (I assume you've noticed that in this case the suffx letters are the capacity in roman numerals) With a 5M drive (ST406), but configured as 4 logical volumes. It then appears exaclty like a 9895 8" drive with 3 slaves. IIRC this is the only hard disk unit that works with an HP85. I don't think it will access larger drives if you managed to connect and format one, at least not without firmware mods. Whether it will object to having a larger drive (ewen if you only want to use 15M of it) I don't know [1] In other words I don't mean an ST506. An ST406 is a single-platter (2 head) drive, basically half an ST412 (which is a 2 platter, 4 head thing). The ST419 is the 3 platter ,6 head one. I assume the last 2 digits are the unformatted capacity or something similar. Incidnetally, the HP ISA HPIB card used to link these drives to an IBM compatible (and yes such a thing does exist) uses a 9914 chip. I have one here. I've been inside the 9121, it's certainly a 8291. I can;t think which ones. The 82901 series (5.25" drives) use the 8291 as well. I've never owned a 9895 8" drive, so I can't somment on that one. -tony

On Wed, Dec 16, 2009 at 4:34 PM, Alexandre Souza - Listas <pu1bzz.listas at gmail.com> wrote: Not much, I suppose, except a small board footprint (2-3 small DIPs and maybe some ferrite beads for a complete buffered implementation. Commodore, as cheap as they were, used HPIB buffers (MC3446s, commonly). -ethan

About two years ago, I did some work on such a project. I built a very crude serial -> HPIB "controller" using an AVR microprocessor and a couple of interface chips. I did not use a HPIB 9914 or other controller. All the logic was done in software. I bitbanged everything and it sorta worked. :-) I was able perform simple HPIB operations without too much trouble. One of the things I did was too interface a HPIB multimeter to my PC using the homemade controller as an interface. Sorry but, I have long since lost the work that I had done. It took some searching but, I did find the correct interface (line driver) chips. The device ids escape me but, they might have been something like 75160's. They are just simple line buffers. The biggest issue that I ran into was a timing issue. When a device (talker) sends a stream of data it just pumps out the data. The listener is supposed to use the control lines (DAV, NRFD, etc) to pace the data. Without pacing or some kind of buffer, the talker will send data faster than a bit-banged micro can process it. My microprocessor was not able to keep up with some devices.. For the multimeter this was not a problem. I attached a HPIB bus analyzer in parallel with the controller and meter and used the analyzer in "slow" mode to pace the data. It worked just fine with the meter. I tried it with a tape drive but it didn't work. The data transfer was too slow and it kept timing out. To make this work correctly, I think you would need some hardware "glue" that would detect each data word and then immediately assert a NRFD. A few microseconds later it would release the line and allow the next data word to be transmitted. This hold-off would need to be just long enough to allow the micro to process the data. Something as simple as a one-shot might do the trick. See yas, SteveRob

It's not hard to make a GPIB interface without using a special decoder chip. I uilt a triival HPIB-Centronics interface (to run a parallel printer from a PERQ) usign a couple og 16V8 GALs and a few TTL buffers. And it's been doneby bit-banging many times. IIRC most of the handshakers are 'interlocked' so the software can take arbitrarily long to respond to a change of state of one of the signals. There is oen (I think only one) case where the timing is critical, which may ddd a couple of gates to the design. All the Commodore GPIB disk drives, printers (and indeed PETs) bit-banged the interface. Commodore never used any of the speical controller chips AFAIK. Mind you, the Commoodore GPIB is a little 'odd' when it comes to timing (I've seen 3rd party devices designed to link to PETs that work fine for that but which won't work on amost other GPIB systems). Even HP bit-banged it sometimes. The 82169 HPIL-HPIB translator uses an 8049 and no HPIB interface chip. The other 40 pin package on the PCB is an HP buffer chip with almost no internal logic. THere are several series of thise, I have no idea which, if any, are still current parts (If I was designing something new, I'd want to use a part that was still in full production, of course) Intel made the 8298 (which I know very little about). Motorola made the 3446, 3447 and 3448. Those 3 are quad uffers with different arrangements of transmit-anable lines, etc. TI made the 75160 (octal data line buffer), 75161 (Octal control line buffer for either devices or, IIRC, controllers in a signle-controller system) and 75162 (octal control line buffer in mulitple-controller systems). I've used the Motorola and TI parts, and have data sheets. That may be the case I am thinking of. Maybe looking at a PET scheamtic would help, presumalby it can handle this provlem. The HP59401 analyser is a fun toy, but I don't want it on the bus all the time :-) -tony

'Getting away with it' is something I will do for quick hacks on my own bench, but not for stuff likely to be used by others, or stuff I depend on. Possibly. I said 'easier', not 'cheaper' though. The point being that the buffer chip doesn't have to be programemd, so it can be replaced by somebody who doesn't have a programmer for whatever microcontroller is used. Most modern microcotnrollers (at least ones with enough I/O for this) come in a surface-mount package, the buffers certainly were available in DIPs (and could be socketed). Repair cost != component cost... -tony

We retrieved these yesterday. The seller also has a 5' or so IBM unit he is keeping for his toolchest use. Thanks Mike for the spot. Jim Mike Ford wrote:

Sure. And there were also commands (which I have used) to read/write locations of the interface processor address space (at least on the IEEE-488 units which have 2 processors in them, one to handle the interface, the other to handle the disk data). My point was that on the HP drives, _all_ you have is the block access. The HP drives have no internal filesystem (the commodore ones do, but as you say you don't have to use it). -tony

Tony Duell ????????: Perhaps the 8291 used less code on the microcontrollers? Or perhaps it could do seomthing on it's own, unlike the 9914, such as assert NRDF when it's databuffer was full? Come to think of it, wasn't the 8291 almost "smart", like a hard coded microcontroller? Or even a SATA, PATA, USB storage interface. Such a stand alone emulator would be very useful. There's a fair description of the Amigo protocol floating around as well as the CS80 spec as a PDF on Bitsavers. Since all the HP drive controllers are built around Intel microcontrollers, shouldn't be too hard to use a modern very high speed 8048/52 compatible. One advantage would be the potential ability for one unit to accept more than one address. Xebec published some source and/or pseudocode for their controller board micros, which might help make things easier. I've actually seen just one inside an older HP unit at Halted's. A very poor photo of this board is in the hard disc tech/service manual, on page 1-8 of the service manual and page 32 of the Bitsavers PDF ... (as 9133_9134_9135_9121_9122_ServiceDocumentation_509pages_1985.pdf), as Fig. 1-3, along with a very brief description. If I can find my pictures I'll put them up somewhere. I have two Xebec controllers, one of which, IIRC, is attached to one Seagate 5Mb and one Shugart 5Mb, and the other controller attached to one Shugart 10Mb. One or two more controllers are not being used at the moment. I have several different ROMs for them. It took some experimentation to get them working right without docs or any clues OK, then I was given the wrong info about them. Seems a waste of processing power to use block transfers instead of letting the drive handle all that. Drive capacity also need not be limited by the host's design. It would be an experiment, mostly. It would probably be easier to edit or tweak a disc on a PC, as well. But I would like to have more options for my 20Mb and 40Mb discs. There is/was indeed a 9134V & XV. The other difference from the 9133 was that the front was "blank", as in no opening for the floppy. I may still have the HP catalogs with those, as well. -- jd "Calling J-Man Kink. Calling J-Man Kink. Hash missile sighted, target Los Angeles. Disregard personal feelings about city and intercept."

I still think that nothing beats SD. It **will** be the standard in two or three years.

Dave McGuire wrote: But IDE you can interface to older 8 bit machines. As for classic computers - 12 & 16 bits I suspect that would be a easy hardware project.

And why SD you can't?

It will work in a reduced capacity :o)

On 19 Dec 2009 at 9:10, Dave McGuire wrote: Ten years ago, the same could be said for 8" floppies. Yes, there are private caches of them in existence (I have one) but they're not easy to find by any means. How's your cache of SmartMedia cards doing? Do you expect to see Sony memory sticks being sold 10 years on? It matters if you want to hew to the standards. I've got a camera here that's a lot less than 10 years old that can't format a 4GB CF card (I did manage to format it with Windows XP so the camera could use it, but the camera understands FAT16 and so that's the end of the road--most devices don't have the capability of using only part of a memory card). I'm not trying to be argumentative here. I've got a real problem to address for long-term data storage that will also see very rough (think machine shop) conditions. Do we expect to see SD media out- populate USB flash drives? When do we expect to see SD become cheaper than any other medium? In a comparatively short time, we've gone from PCs having a mandatory floppy drive to having none. You could find blank floppies being sold everywhere; now the local computer recycle/reuse store won't accept donations of new, unopened stock. Compared to floppies, the speed of technological advances in flash media has been nothing short of breathtaking. While this is good for technology overall, it presents problems for planning. Personally, I'd love to use SD media in designs, but I need to have some sort of confidence that SD isn't going to become the next SmartMedia or xD. --Chuck

On 19 Dec 2009 at 15:39, Alexandre Souza - Listas wrote: 10 years ago, maybe one could. SmarMedia is small. In fact, it's difficult to understand why it sunsetted so quickly. But then the same might also be said of MMC. I'm just trying to figure out where to place my bet. --Chuck

On Dec 19, 2009, at 1:02 PM, Chuck Guzis wrote: It never did make it into very widespread use. Lately I've not seen a consumer digital camera that doesn't use SD. One could never say that about SmartMedia. MMC is just a subset of SD. Even the physical specs are compatible. SD looks pretty safe so far, at least to me. -Dave -- Dave McGuire Port Charlotte, FL

On Dec 20, 2009, at 4:49 PM, Fred Cisin wrote: When I need to, I just write on them with a small Sharpie. -Dave -- Dave McGuire Port Charlotte, FL

On Dec 21, 2009, at 4:37 PM, Fred Cisin wrote: I have very small handwriting, enough for an abbreviated label. And black marker on a black surface is usually visible when you tilt it just right. It has been ok. *snicker* -Dave -- Dave McGuire Port Charlotte, FL

On 19 Dec 2009 at 22:18, Cameron Kaiser wrote: Trade you a Fuji SM camera for that Olympus. A whopping 1.5 Mpixel. Nope, that's strictly the domain of wire coat hangers and safety pins. :) --Chuck

Tony Duell ????????: That's probably it. It's been a while since I'v read the data sheets. And I seem to recall something GPIB from other sources, like Fairchild, AMD and NatSemi, as well. I was suggesting a bit more along the lines of "It would be nice if a developer wouldn't focus solely on one type of storage but rather design something where any storage medium could be easily added." There tends to be way too much of a laser focus on favorite storage media, i/o, interfaces, etc. and others end up having to reinvent the wheel, even if the design is open. You're right! And I've seen it elsewhere, as well. There was a couple of detailed notes going around BBS's. Xebec also published their own. No, you're right: They're Motorola in the HP controllers. MSC and Xebec used Intel. I didn't trap the tired memory errors. Sorry. (Wouldn't it be nice to have 8bit processors w/ 500MHz to 1GHz clocks?) It has the separate HP HD and FD controller boards. It appears to work normally except that it is unable to read any floppies. Changing the drive did not change anything about that. Beyond that, no idea, although it may be the data separator board. One Of These Days, I'll dig it up, thaw it and see what else I can find. == jd Fortune's Real-Life Courtroom Quote #52: Q: What is your name? A: Ernestine McDowell. Q: And what is your marital status? A: Fair.

jd wrote: The 8291 appears to have been hardwired logic; the microcontrollers of the time would not have been able to transfer data at anywhere near the speed of the 8291. The 8292, which was used to implement bus controller functionality, appears to have been an 8041 "UPI". That's a mask-programed 8048 derivative which has a slave interface to a processor bus, to act as a smart peripheral. Eric

On Mon, 7 Dec 2009, J. David Bryan wrote: I'd do that the same way (and Windows licences are no problem at all with a MSDN-AA subscription), but I want a headless system running UNIX/Linux with NFS mounted filesystems which would contain the image files. Or even a DOS system (optionally with Netware mounts from a Linux server). The headless system could then be a small mini tower stuffed into some free space of the HP rack or into the raised floor, and which will only be powered up along with the main system. RTE-6/VM and HP-UX would be the systems I'd like to use the emulator for. Christian