The IEEE Bus - Standing Room Only?

Jim Butterfield

Before we discuss problems on the IEEE bus, let's take a quick overview and say some good things.

First, the basic bus structure is sound. It can handle many devices, and is capable of transferring data with full handshake at a pretty good speed. It is asynchronous, which means it will adapt to whatever speed the connected devices need.

There's a myth going around that the bus is slow: not true. With a typical operating speed of over 5000 bytes per second, it can transmit a full 64K in about 13 seconds - not bad for full handshaking. There are certain ways that the bus can be used, for example with Basic GET# statements, that will indeed be slow; but you can't blame the IEEE bus for that.

The real problems, as I see them, are in the way that Commodore uses the IEEE bus. There's a lot of potential that is being thrown away.

Lockout

The current Commodore disk units and printers lock out the bus when they are busy. If the disk is doing a NEW/HEADER or a VERIFY/COLLECT it will hold up everything else on the bus. Similarly, if the printer is moving to the next page, or even just printing a line, the bus is out of business.

This is fair enough if you wanted to use the device that is busy. You can't write on the disk until it has finished its last job, and it's reasonable enough to wait for the printer to stop moving before you give it new stuff. But if the disk is busy, you can't use the printer; or if the printer is busy, you can't use the 8010 modem... this kind of thing can hurt.

Item: a software vendor buys four 2040 disk units, strapping the device numbers to allow their simultaneous use. He wants to NEW four blank disks, one on each unit - and discovers to his amazement that he can't start a NEW on unit two until one is finished and releases the bus.

Item: a hobbyist wants to use an 8010 modem together with a printer as a printing communications terminal. He finds that he can't use the modem during the time that the printer is operating, and he loses characters from the transmission line during the time that the bus is locked out.

The bus is not the problem: it's the way that it is being used. Commodore have taken the old-style data processing approach that only one device should be working at a time. This doesn't hurt in many data processing situations, especially if you have only a disk and printer connected. But a more sophisticated system will start to hurt when lockouts start to interfere with real-time sensing or communications applications.

Multiple processors

It should be possible for several PETs to work a single disk unit, or for that matter, a whole set of common peripherals. As small computers find use in larger commercial environments or in schools, there's a need for several operators to read from and write to a common data base.

This is now being done with commercially available interfaces, such as the MUPET, but Commodore didn't make the job easy.

The biggest problem is that ROM systems prior to 4.0 would flash the EOI control line every time the screen scrolled on the PET. This would break up anything else that might be happening on the bus. This problem is now eliminated on 4.0 and (presumably) subsequent ROMs.

Of course, without a commercial interface system, you also have to make sure that two operators don't attempt to use the bus at the same time. The usual practice is to have the operator call to the others, "Everybody hold it for a moment - I want to read disk!" Informal, but workable.

The situation is improving, and commercially available devices make this possible.

Spooling

It's almost possible to tell the printer to LISTEN and the disk to TALK and have information transferred directly between the two devices. Almost, but not quite. Commodore didn't quite get the logic precise enough to do the job.

It would be a tricky job in any case. PET would need to start things up and then stay away from the bus until the transfer was complete, at which time PET would jump back on and close down the devices. Even so, it would be nice to think that the capability was available if needed.

Summary

The IEEE 488 bus is really pretty good as it is. I can't help wishing, though, that a few extra features had been provided to allow development of the real potential that is there.

Maybe when the next round of Commodore devices is announced...?