6502.org

Ok, I've learned quite a bit in the short time I've been here. You guys are great with beiginners. I have freqented many electronics forums over the years, and so far you guys are much more patient with dumb questions that you've probably heard a million times. I keep waiting for some version of 'Just Google it, dumb ass', or a not so polite reference to the search function. Folks often forget that for a beginner, googling and searching often just deluges you with info, that with no base knowledge to use as a filter, is not useful.

Short version, Kudos for being so helpful!

OK, to my question. I realize what the 68C22 does. I just don't see why it's needed? As far as I can tell, its main function is to expose the bus to I/O devices. What I don't grasp is why you can't connect I/O to the bus directly? Is it a clock thing? A load thing? Both? Neither?

The bus is active on every single address & data access, including the CPU fetching instructions. If you just put, say, a TTL RS232 output line on the main bus's D0 and an input line on D1, what would happen? D0 would splash 0/1 every single cycle, not just when you try to "write" to it; and anything coming in on D1 would interfere with a low bit of the CPU trying to read instruction bytes from RAM.

For software control of a physical I/O line, you generally want to be able to set that wire to a high or low voltage, and have it stay there until you tell it otherwise. If there's an input, you want to be able to ask something "What's the high/low status of this particular wire?" The VIA does that for you. Plus, it has timers & a serial port that reads/writes pulses for an 8 bits automatically.

I might be stretching a metaphor [edit: analogy?] a bit too far, but running I/O straight from the CPU address and data buses would be akin to connecting a car's engine directly to the wheels with no transmission. There are a few extremely rare [edit: specialized?] cases where this could be useful, but it is in general highly inappropriate.

I/O devices of any type interface the microprocessor's (MPU) buses with the outside world under controlled conditions. Using the VIA as an example, it has two eight bit parallel ports, of which each bit can be programmed to be an input or an output. The VIA's chip selects are wired into the glue logic in such a way that it only responds to read and write requests from the MPU when a specific address is present on the address bus, and only during the correct time in the bus cycle. Furthermore, one of the parallel ports appears at one address and the other parallel port appears at a different address. What this means in practical terms is the external devices or system connected to the parallel ports only communicate with the MPU under program-controlled conditions.

The ability to arbitrarily make some port bits inputs and others outputs masks a characteristic of all microprocessors, in that they can receive input or generate output, but not both at the same time. Obviously, the parallel ports in the VIA don't have such a restriction.

In addition to the I/O facilities of the VIA, it has another important feature. It can be configured to interrupt the MPU when an external device needs attention. Interrupt-driven I/O is a basic computer concept that allows for the fact that the microprocessor normally executes program instructions in a sequential way, whereas external events are random in nature and cannot be planned upon in advance. So the VIA performs an important service in that it doesn't pester the MPU unless something important has happened.

Another function of I/O devices such as the VIA is they insulate the MPU buses from the uncouthness of the outside world. That includes providing different voltages and/or more drive current to the external devices or systems than can be gotten from the MPU itself, as well as protecting the MPU and other devices attached to the buses from unwanted conditions. If the outside world were directly connected to the MPU's buses, instability or outright failure could result.

There are many kinds of I/O devices available, the VIA being but one of them. Others include UARTs, video controllers, SCSI controllers, printer port controllers, digital-to-analog converters, etc., all of which respond to the MPU on one side and interact with external hardware on the other side.

Hope my explanation helps.

I started writing and BDD posted good considerations while I got interrupted; but I'll expand on it.

As I write this, I realize that in past writings, I've always assumed the reader understood what something like the 65(c)22 VIA was for, and only needed his imagination stirred as to the many things that could be done with it, many at the same time. Now I realize I need to add a discussion of it in the primer. I can't take the time to do it justice now, but I'll mention some things that come to mind, without reviewing my "Tip of the Day" column or the circuit potpourri section of the primer.

In addition to the above, you wouldn't want to load the processor's own buses with the I/O's DC or AC loads. You can get output from 8-bit 74HC__ latches that you give addresses to and write to, and input from buffers that put their info on the data bus only when enabled by reading the address you've given them; but that's pretty limiting compared to what a versatile interface adapter can do. To start with, all 8 bits of one of these 74HC__ latches or buffers must go the same direction, unlike the 6522 which has data-direction registers that let you set the direction of each individual bit independently of all the others. Doing your I/O through discrete logic would also take a lot more parts, especially if you want to be able to read output ports to do read-modify-write operations. Maybe not-so-obvious points I'm thinking of are:

• The 65(c)22 also has interrupt-on-change pins (CA1, CA2, CB1, CB2). (Actually, these lines have multiple uses.)
• ability to handshake with another parallel port
• ability to toggle PB7 every time timer 1 (ie, T1) times out, which I've used for things like feeding a piezoelectric beeper without the software babysitting it, or producing a software-settable clock source for something else, like providing the 500kHz for a 65c51 UART to produce 31.25kbps for MIDI (musical instrument digital interface)
• ability to count pulses on T2 on PB6, which you can have the processor read, or have T2 generate an interrupt when you reach the desired number of pulses. This could be used for an event counter, or for a frequency counter (using both timers together).
• Timer time-outs optionally generate interrupts, so you can get an interrupt to do something on regular intervals regardless of what else the computer is doing in the background.
• You can use one of the timers as a watchdog timer by regularly re-writing a value to its registers as long as the program is doing fine, so that if something goes wrong (usually meaning the computer crashes) the timer reaches timeout and its interrupt sends the computer to code that get things back to some orderly operation, without human intervention. (You may want to connect the VIA's IRQ\ output to the processor's NMI\ (non-maskable interrupt-not) input for this one.)
• The VIA can emulate open-drain outputs which it can also read when not actively pulling down.
• The synchronous-serial port has seven modes of operation (the VIA's only bug is in one of those 7 modes, one that won't affect most users). Besides using it to get hundreds of bits of I/O on only three pins, I've also used it to send RS-232, put raster graphics on an analog oscilloscope, and even as a 9-level D/A (digital-to-analog) converter (or DAC) to generate DTMF and other signals.

These things go way beyond just "exposing the bus to I/O devices." In a sense, it's like there's some I/O-specific processing power there that runs alongside the microprocessor, to support it. And of course, you can have several such ICs in one computer.

I think a historical approach might help: in the early days you would connect sets of latches to the data bus with appropriate decoding. It would be more components, more load on the bus, more heat, more soldering, unless your needs were minimal. (See for example the OSI 300 trainer)

The likes of the PIA, then the VIA and then the CIA were increasingly integrated devices which mop up that logic, allow for I/O direction control, support handshaking, have timers and shift registers, and so on.

Looks like the 6820 dates from 1975 or thereabouts. The 6532 RIOT was just a bit earlier, probably more expensive.

(In fact the trend continues, with microcontrollers being an integration of the microprocessor and the peripheral devices.)

You can hook stuff directly to the CPU bus, but then you have to take care of making sure that data is only placed on the CPU bus at appropriate times and that data is read from the CPU at the right time. It requires a number of logic circuits (gates on clocks and address and control lines) and a PIA or VIA encapsulates the requirements and allows multiple ports to be implemented at the same time.

It can turn some hardware requirements for interfacing into programmable software which may be easier to manage.

I have seen that occasionally a switch matrix will be connected more or less to address and data lines for a simple keypad.

It’s worth noting that in an FPGA (or with a CPLD) one doesn’t usually use a PIA or VIA but wires up the desired I/O using a common interface bus like AMBA or WISHBONE. An output port is just a latch connected to a decoder.

Wow, thanks guys! I got my answers and more!