3

According to schematic 320130-1 (from zimmers.net) the user port on the PET brings out from the 6522 PIA all data lines from port A (PA0-PA7), the port A input-only handshaking line (CA1), and the port B bidirectional handshaking line (CB2). The bidirectional handshaking line for port A, CA2, is used as an output to switch between the graphics and business (text) character sets. The overall organisation is as follows:

VIA Port    Pins      User Port       Other Uses
─────────────────────────────────────────────────────────────────
          PA0-PA7     data lines
    A       CA1       handshake
            CA2                       charset switch
─────────────────────────────────────────────────────────────────
          PB0-PB7                     IEEE/CMT interface signals
    B       CB1                       CMT #2 read pin
            CB2       handshake
─────────────────────────────────────────────────────────────────

This seems like an odd arrangement; one would intuitively think that it would be better to assign CA2 to the user port and use CB2 for the character set switch.

Doing so would be particularly useful in high-speed input applications such as this one where the 6822's ability to have a read from data port A automatically generate a handshaking pulse on CA2 could have simplified the design significantly. (That design needed to read and handle each byte in 16 cycles or less. This could be done in 14 cycles without handshaking, but that left no room to add another instruction to do CPU-generated handshaking. In other applications this might simply increase the read speed by around 20%.)

So is there some reason I'm missing here that CA2 was used for the character set switch and CB2 from the "other" port was chosen as the bidirectional control line to bring out to the user port with the other port A lines?

1 Answer 1

3

It's as usualy a combination of needs and possibilities within restricted resources that have to be weighted to generate best usability.

  1. Need for a port-bit to switch graphics
  2. Like of simple port use use by arbitrary user programs
  3. Addition of easy pulse (serial) output

Note that especially the last two contradict each other.

Port A is the only one that offers handshake free access by using register 15 (*1) instead of register 1. Thus port A would be the preferred port to allow user programs handing of data and direction without caring about any other setting, making this as simple as possible.

CB2 is fixed as serial output. To use the serial shift register as output no other port can be used. It' perfect to generate arbitrary wave forms (*2), a quite useful feature in general and in particular used as the default sound output for PET software. This has been already described in one of the first user letters.

Doing port A plus CB2 it's a good combination of offerings. Optimizing for a single and rather extreme scenario would have made the machine less versatile.

At that point it's worth to keep in mind, that the PET was not meant as an embedded system, like the KIM, but a desktop machine. High speed I/O was to be done by communication with appropriate (intelligent) devices via IEEE 488 on a more abstract level than punching ports and waiting in tight loops or interrupts. That part is modelled after HP's example, proven to be quite capable.

In hindsight, having a (mostly) IEEE 488 bus was the most important reasons to buy a PET for a lab environment. Anyone who needed to go past that would need a faster machine than a PET, or at least add own hardware anyway(*3).


*1 - $E84F on the PET

*2 - Within limits of timer and register resolution due the shift register being a ring (i.e. values shifted out from bit 7 get reloaded to bit 0)

*3 - I got at least two PET/CBM in my pile of wonders originating from former labs that had multiple 6522 added for additional I/O. Looks weird, works fine.

2
  • Ah, the point about CB2 being the only access to the serial shift register is a good one. I'm still not entirely clear on the overall design choice, however, perhaps because I'm missing something in the data sheet. What would have been the downside, then, of just using CB1 and PB0-PB7 instead of the port A equivalents? Wouldn't that have given more handshaking capability? Would it have given you everything you could get by using CA1, CA2 and PA0-PA7?
    – cjs
    Jun 25 at 2:31
  • @cjs as mentioned, port A is special as it can be accessed via register 1 or 15. With or without handshake, independent of the ports setting. Quite handy to peak a received value, without issuing a handshake. Or, as mentioned above, more important for an easy to use device like the PET: Port A can be operated by just setting DDRA and writing/reading ORA/IRA (via R15). So yes, Port A is the most versatile thus saved for the user.
    – Raffzahn
    Jun 25 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.