• Please review our updated Terms and Rules here

IEEE-488 electrical characteristics?

Twylo

Experienced Member
Joined
Feb 12, 2009
Messages
230
Location
Poulsbo, WA
Hi everyone,

I've been scouring the web and my personal library trying to get up to speed on the IEEE-488 bus as implemented by Commodore. I think I understand it fine from the logic point of view, but I'm not really clear on the electrical characteristics, other than the obvious (active low, +5V drive, etc.)

What is the characteristic impedance of the bus? Is termination required? Is three-state essential? Can CMOS devices be used to drive the bus, or are inverted TTL logic levels required?

It seems like the simplest implementation wouldn't even need bus drivers for a very short run with a single device, but I'm also not so sure about that. I'm pretty sure I'll end up using a 74LS245 and 74LS244 to drive the project I'm working on, but I'm not sure whether they'll be critical during the prototyping phase or not.

And last but not least, are all my questions clear as mud? :)

-Twylo
 
I don't know how Commodore differs from conventional GPIB, but the traditional transceiver is the SN75160B or SN75ALS160. Termination is usually done like this:

Gnd<---6.2K--->Signal<---3K--->+5

I suspect if you're just making a single peripheral for connection with the bus not shared, you can probably get away with totem-pole outputs rather than OC ones.
 
Excellent, thanks! The termination information is super useful.

I'd read up on the SN75160/161 as part of my initial research, and I've ordered some from DigiKey to have around. I was thinking about the '244 and '245 during prototyping because I have a boatload of them on hand.
 
Well! Thanks to that collection of Commodore PDFs I posted about in another thread, I now have a copy of the book "PET and the IEEE 488 Bus" by Eugene Fisher and C.W. Jensen. It seems that every question I have is answered there. Brilliant!

Now, if only I'd found it before cluttering up the forums with an unnecessary thread :)
 
You mean you didn't know about Bombjack? Should be at the top of every Commodore owner's favourite list:
http://www.bombjack.org/commodore/

I didn't, and I'm shocked that I didn't! I can't believe that I never came across it before, because it's exactly the kind of archive site that I'm always actively looking for. Normally my Google-fu is superb, but in this case I've just never hit it.

Frankly, it makes me really worried about what else I'm missing out there. I've been a vintage computer enthusiast since around 1994, I should be on top of this stuff :)

I have the paper version of that book; pretty good as I recall.

I knew about the book, but it was pretty expensive when I went looking for a used copy online, so I kind of put it on the back burner. When I found the PDF I was thrilled.

May I ask what you're planning to build?

Of course! I'm working on an SD-card interface for storage. It will probably present itself as a 4040 or 8050 disk drive. Inspiration comes from the existing Parallel-port-to-IEEE488 devices that I've seen around since the early 90s that allow using a PC as a storage device. I'd like a self-contained device that doesn't rely on having a slave computer around.

The controller I'm using to prototype it is a Teensy controller, since I'm already familiar with AVR development, I had a Teensy on hand, and it has enough IO to handle IEEE-488 with no difficulty.
 
...I'm working on an SD-card interface for storage. It will probably present itself as a 4040 or 8050 disk drive. Inspiration comes from the existing Parallel-port-to-IEEE488 devices that I've seen around since the early 90s that allow using a PC as a storage device. I'd like a self-contained device that doesn't rely on having a slave computer around.

The controller I'm using to prototype it is a Teensy controller, since I'm already familiar with AVR development, I had a Teensy on hand, and it has enough IO to handle IEEE-488 with no difficulty.
Sounds very interesting; cute little board! I think there are a couple of IEEE-488<>SDcard interfaces 'in progress' out there, but I don't think any are ready for prime time; maybe Anders will read this, he's probably most on top of PET developments 'out there'.

Which IEEE-488<>PC interfaces did you look at? Maybe I've missed some...
 
Which IEEE-488<>PC interfaces did you look at? Maybe I've missed some...

The ones I've looked at are Ruud Baltissen's CBM-HD DOS software and PC-IEEE hardware design, and André Fachat's lptiec for Linux.
 
The ones I've looked at are Ruud Baltissen's CBM-HD DOS software and PC-IEEE hardware design, and André Fachat's lptiec for Linux.
They're the two I'm aware of; been meaning to build Ruud's for a year or two ;-)

Maybe I'll get one of those Teensy's and wait for you to finish the software ;-) Good luck!
 
I'm not entirely up to date, but again the ZoomFloppy appears to replace the XS-1541, XU-1541 and whatever the newest Commodore related interfaces and cables are named.

When it comes to the IEEE-488 protocol, I still wonder if the PET and CBM-II lines implement it in different ways. Regular Commodore floppy drives work equally well on all IEEE equipped models, but for example my Corvus hard disk setup is quite picky when used with my CBM 610, i.e. CATALOG stutters character by character instead of flowing line by line. LOAD works fine though. It has been mentioned before and elsewhere, and someone had an idea what it could be due to. I'm just saying when designing a new interface, try to read up on any details about different implementations that to the untrained eye look identical. It would be a duh moment if you need to update or redesign it afterwards due to partial incompatibility with some of the machines you planned to support.
 
That "Teensy" controller looks like an excellent platform for something like this. Assuming I ever actually end up with a working PET sign me up as also interested in a working IEEE drive emulator! (Considering my luck with picking PETs I sort of doubt *any* of the three disk drives I picked up work, or are any better than smoking ruins.) I was vaguely fantasizing myself about trying to implement such a thing using the Propeller (I have a little bit of programming experience with that) but there's a strong emphasis there on the word "fantasizing".

When it comes to the IEEE-488 protocol, I still wonder if the PET and CBM-II lines implement it in different ways...

Could what you're seeing simply be bugs in the CBM-II, either hardware or software? I've always had the impression that those machines were never entirely 100% baked before Commodore shoved them out the door. (And subsequently canned the line.)
 
I'd highly recommend starting with the sd2iec codebase. Replacing the IEC routines with IEEE ones will be your only work effort. It already runs on the AVR, and is well documented. Since it already handles the CBM bus nomenclature and things like disk directories and such, and uses FAT16/32 storage, it would provide a quick way to get to a working implementation.

uIEEE/SD has been in design for a while, but progress has been slow. After receiving numerous complaints about bus loading on the IEC units, I quit development until I could find a contemporary driver IC that can handle a number of IEEE drives on a bus. I think I have found them in the TPIC line, which can sink quite a bit of current. Finding 75XXX ICs can be tough. As well, I was also searching for a reasonable IEEE 488 connector source, which I have now secured (1000 of them sitting in my front room right now).

Jim

Feel free to email if information is needed.
 
I'd highly recommend starting with the sd2iec codebase. Replacing the IEC routines with IEEE ones will be your only work effort. It already runs on the AVR, and is well documented. Since it already handles the CBM bus nomenclature and things like disk directories and such, and uses FAT16/32 storage, it would provide a quick way to get to a working implementation.

Perfect! I hate re-inventing the wheel. It looks like a lot of effort has gone into sd2iec, and I'd be happy to build on it rather than re-implement a bunch of code that wouldn't be nearly as robust without lots of wasted, duplicated effort.

uIEEE/SD has been in design for a while, but progress has been slow. [...]

I'd love to hear what you've done with it so far. I decided to roll my own because I didn't know about uIEEE/SD, and besides, I view it as a great learning opportunity. I haven't taken a hardware project start to finish yet, and I'd like to.

My hardware implementation is progressing well. It's very simple. Prototyping is being done on a breadboard with the aforementioned Teensy++, which is based on an ATmega 90USB162. The US distributor DigiKey has a good supply of 75160s and 75161s in stock, both through-hole and SMT, so I've grabbed some for prototyping. It really boils down to not much more than the AVR, the 75160 and 75161, a 16MHz crystal, some resistors, capacitors, zeners, regulators, and the SD card socket. I have a board mostly laid out in Eagle but I wasn't going to bother completing it until I had some working IEEE routines to test on the breadboard prototype.

I have time this weekend to work on it, so I'm going to conjure up some IEEE code and hopefully at least get a handshake working with one of my PETs.

-Twylo
 
I'd love to hear what you've done with it so far. I decided to roll my own because I didn't know about uIEEE/SD, and besides, I view it as a great learning opportunity. I haven't taken a hardware project start to finish yet, and I'd like to.
I have a design, but I was considering a general purpose set of drivers.

But, I think it's a great learning opportunity.

Jim
 
Back
Top