I'm wondering if the WDC 65C22 VIA chip still has the serial port bug that the original NMOS 6522s did (the one that prevented the Commodore from offering a fast serial bus interconnect to the 1540/1541 floppy drives)? I don't know much about this bug, to be honest. I've seen references to it on the Internet in various posts, but nowhere have I seen this bug actually characterized.

Does anyone know what this bug really is? How to reproduce it? How to work around it?

I also understand that there are 3 other "timer race condition" bugs with the chip as well. Does anyone have any knowledge of these, beyond the fact that they exist?

Thanks.

Yes, even the WDC part has it. The bug is that when shifting is done under control of an external CB1 clock, if the edge on CB1 falls within a few nanoseconds of the falling edge of phase 2, the CB1 edge will be ignored, so you lose a bit. Worse, you'll get framing errors on subsequent data. I'm not sure how it relates to any speed limitations on Commodore's disc drives because the problem will happen regardless of shift speed. To remedy it, put the external clock signal into the D input of a 74HC74 flip-flop, run the flip-flop's Q output to the 6522's CB1 pin, and clock the flip-flop with phase 0 or phase 2. I have used this to send data from one 6502 computer to another using CA2 for an extra handshake line.

Garth

It relates to Commodore's disk drives because they found themselves without an IEEE-488 cable vendor for these computers. The CEO said, "Get off that bus! Use a bus that anyone can make a cable for," and they did. They decided to go serial, because anyone, anywhere, could make a cable for it.

They were going to use the 6522's internal serial port to do this, because it offered performances that could easily match IEEE-488 in practice. But if the serial port loses a bit, then that solution is clearly not a wise solution. That's why they went with the bit-bang solution instead, and slowed the serial bus down immensely. Although the Commodore 64 *could* have supported it (and there is at least one hardware hack on the 'net you could use to get that capability back), political reasons intervened. It wasn't until the Commodore 128 that the high-speed serial link was implemented.

I know that the 6526/8520 doesn't have this bug. I would have expected WDC to have fixed the serial port bug by now though...



Anyway, that sounds like a good tip. But does this really solve anything?

If the CB1 edge falls a few ns before ph2 falls, then Q will go low IFF CB1 responds before the setup-time for the latch. But if CB1 edge falls a few ns *after* the setup-time window or when ph2 falls, then Q will remain high, and the problem persists. As far as I understand the operation of the serial port, when clocked with an external source, that serial port works independently of ph2.

Being able to use an external clock source is good because it allows me to use any clock speed I want for the VIA's ph2 input. But since the 65816 is likely going to be going faster than the VIA anyway, perhaps I should just hardwire the 6522's clock, and use one of its internal timers to generate the clock signal instead? Would that be an adequate "workaround" for this bug?

> They were going to use the 6522's internal serial port to do this, because
> it offered performances that could easily match IEEE-488 in practice.

IEEE-488 allowed one megabyte (not megabit) per second max, and 250-500 kilobytes per second with a typical setup with quite a few cables connected. You'd have to have a phase-2 rate of over 10MHz to do this with the 6522's serial port. IIRC, 488.2, which came out at about the end of the time I was using IEEE-488, had a way to go much faster.

> Anyway, that sounds like a good tip. But does this really solve anything?

Sure. You're just making sure that CB1's input signal can only transition near phase-2's rising edge, and thus keeping it away from those bad few ns each side of phase-2's falling edge. Delaying the CB1 edge even an entire phase-2 cycle is no problem. You can't work the serial port as fast as one bit every other phase-2 cycle anyway. Without taking a lot of time looking at the details in the timing diagrams, I can say that as long as your phase-2 is at least 6 times the shift clock frequency and the shift clock signal sent from the other device is symmetrical, you'll never lose a bit if you use the flip-flop. I would need to do some closer examination to determine what happens as the shift clock approaches or exceeds 1/4 the phase-2 frequency. The maximum reliable speed will be reduced a little by the use of the flip-flop, but reliability becomes 100% (as long as you don't exceed that maximum safe speed).

> But if CB1 edge falls a few ns *after* the setup-time window or when ph2 falls,
> then Q will remain high, and the problem persists.

It's not a problem. It will get taken care of on the next rising phase-2 edge, which will definitely be well before the serial data line changes state anyway.

> As far as I understand the operation of the serial port, when clocked
> with an external source, that serial port works independently of ph2.

It was supposed to.

> But since the 65816 is likely going to be going faster than the VIA anyway...

How fast? Bill Mensch of WDC told me that although the VIAs aren't tested any faster than 10MHz, he suspects they'll go much faster. And there's more to maximum MHz than just cycle time too; and with careful design and construction, you may be able to meet the timing specifications at frequencies way beyond the conventional rating anyway. My workbench computer works up to 7MHz with 4MHz VIAs, but I still have not exhausted the possiblities for getting a little more speed if I wanted it.

> perhaps I should just hardwire the 6522's clock, and use one of its internal timers to
> generate the clock signal instead? Would that be an adequate "workaround" for this
> bug?

The bug is only with shifting controlled by an external asynchronous clock. If you're going to generate the clock internally via T1, there's no problem for the one controlling the clock. But if you want to send data to a separate device (like the disc drive) also using a VIA, the clock will be external and asynchronous to one or more devices, and you'll have to address the problem at some point.

Actually the flip-flop is not much of a big deal. It becomes a little more significant if you have to add tristate buffers and have the computer control which direction the serial clock is going-- in, or out, of the VIA. You could just decide that one particular unit will always be the one to generate the serial clock. Data can still go both directions even though one end always controls the shift clock. This would be the solution in the Commodore disc drive issue you raised. The computer would always generate the clock signal, and the disc drive would always input the clock through the flip-flop. Maybe Jack Tramiel was too cheap to put the extra flip-flop in. Who knows. Maybe there was already half a 74LS74 sitting unused on the board, so no more parts would have been required anyway.

Not back in the late 70s, it didn't. The timing diagrams I had had signal widths measured in integral microseconds. The fastest practical speeds you could get out of it THEN was around 100KBps -- almost exactly what you'd get from a 1Mbps serial link.



OK, so we're talking about a severe impact on transmission speeds, the factors of which are almost precisely identical to Commodore's software bit-bang solution anyway.



Well, my initial designs call for a 4MHz 65816, which is well within the range of the 6522s. But eventually, in a future design, a 16MHz 65816 isn't outside the realm of possibility.

As far as what people say the 6522 *can* do, I'm not one to take bets. The 6522 is tested up to 10MHz, then that's as fast as it'll go as far as I'm concerned. (Which is news to me, because I'm only aware of it being tested up to 5MHz, but time marches on, I guess). This is why, despite knowing that the 65816 can do 20MHz, I won't drive it faster than what's on my datasheet. When the datasheet gets updated, then I'll feel confident about driving it at those speeds.



Burst mode on the IEC bus is supported using 6526 CIA chips; the serial port bug has been fixed in those chips. They don't have a flip-flop in the circuit. Also, as far as I know, the C64 and C128 both let the slave device control the clock when it was transmitting in burst mode (and, for that matter, in slow-mode too).

> Not back in the late 70s, it didn't. The timing diagrams I had had signal
> widths measured in integral microseconds.

Was that on Commodore documents, or the IEEE document? I verified my numbers from an old HP catalog before writing.

> OK, so we're talking about a severe impact on transmission speeds, the
> factors of which are almost precisely identical to Commodore's software
> bit-bang solution anyway.

Not really. Even at the pitifully slow speed of 1MHz, you'd sitll have 166kbps-- more than 3X as fast as the fastest dial-up modems. The 6502 averages an instructions about every 4 phase-2 cycles (depending on what you're doing). Even if you settled for a bit rate 1/6 of the phase-2 frequency, that's a bit every instruction and a half, a rate which you definitely could not bit-bang.

Maximum speed with the VIA's serial port is achieved by controlling the shifting with phase-2, which will give you a bit every two phase-2 cycles instead of every 4 or 6. Synch problems will keep you from using this mode between computers though. The 6/2 difference will be reduced anyway if there's any dead time between bytes resulting from delays in servicing the port and actually doing something useful with the data (what a novel idea).

From the little I know of your application, I think the VIA's serial port will not disappoint you, other than the flip-flop need.

Neither -- it was an independent source. I don't recall where I got it though, it's been too long. But I remember them making a distinction between theoretical and practical speeds, so I'm inclined to think that I read it in a technical review article.



While this is true for non-storage type devices, I was also looking to connect storage (or other block-mode) devices to this interface as well. For these kinds of devices, you'll want to buffer packets, instead of process data in a streaming fashion.



The idea of the flipflop makes sense, as long as you drive the bus at a sufficiently slow enough speed (even ph2 / 4 should work). I can give the idea some more thought, though I'm still partial to faster speeds.