Hi all,

I recently found this old quote from Jim Butterfield in an old comp.sys.cbm post by Jim Brain (http://www.retrocomputing.net/parts/commodore/vic20/docs/6522f.txt):


Was Jim referring to the known 6522 SR bug that can appear when the SR is clocked externally, or is this a different bug? It seems to me like it's a different issue (none of the tricks I know of to get tones out of a 6522 require an external clock driving CA1/CB1), but I thought I'd ask the more experienced members here.

My personal opinion, based on additional years of information, is that Jim was combining two partial stories.

In this PDF:

http://archive.6502.org/datasheets/synertek_sy6522.pdf

Mode 010 sounds like something that might affect CB2 sound. Or, ther might be some IRQ issues (tape routines use the timers in the 6522 for tape timing) in the 6522.

However, I think the issue causing CBM to discard 6522 SR IEC routines was the Mode 011/111 issue noted in the PDF (and Garth Wilson's explanation in this forum under a heading about WDC 6522 still having this issue.) CBM would have attached the IEC_CLK line to the 6522 as an external clock line, and it would have been asynchronous, so the issue would have cropped up.

I think someone later (or at the time) described the issue to JB as being the result of a 6522 SR bug, and Jim connected the earlier CB2 sound issues with the IEC issues incorrectly.

I say that because CBM would not have cared if other things were disrupted while disk access was occurring. At the time of introduction of the VIC, nothing else happened while disk access was occurring, and the VIC was designed primarily as a cartridge unit, not a disk unit, so I doubt CBM was concerned about the slight possibility that video or sound generation would be ill affected by IEC routines during a game load, etc.

In fact, part of me submits the story is a historical rewrite by CBM, passed to Jim to lend some authenticity. We'll never know, though, and I am not suggesting Jim believed it was anything less than the truth. Why? The VIC was designed with cost in mind. Many people agree the VIC-20 contained many of its parts because they were overstocked (the curious amount of RAM, the 6560/61, etc.) and using existing stock would have lowered cost a bit. The choice of serial bus aligns with this. Jack knew the custom IEEE488 cables and connectors were premium priced, while DIN was much cheaper, and easier to low-cost source. In light of this cost consciousness, I think the engineers knew about the SR bug and communicated it, but Jack vetoed the idea of a redesign of the 6522 for cost and stock supply reasons. Jack probably saw no issue with the ~2kBs rate of the bus, as it would keep PET users from screaming about the IEEE price premiums, and it would still load a VIC game in a 2-5 seconds.

Another option is that the bug is hard to eradicate, harder than Jim was led to believe. That the Synertek app note discusses a work around while having noted they fixed the mode 011 bug lends some weight to the idea that the timing issue was hard to address without significant redesign.

It's probably somewhere in the middle. There were probably folks in CBM who wanted to use the 6522 once Jack mandated a move from IEEE488. They wrote some initial 6522 SR code, and it started failing. Once they tracked down the issue, noted the penalty, CBM bean counters decided the lack of demand for disk drives, coupled with the lack of concern over a VIC app loading in 5 seconds versus .5seconds (at fastest rate, 6522 can clock in at 250kbps, or ~31KBps) killed any attempt to fix the issue.
Jim

Thank you, that was a very informative reply (looking at your handle and signature, I can guess why )

Most of your reply comes as no surprise to me (although you did fill in a few gaps), that's what most of us here know as "the 6522 bug". However, I was not aware of the other issues mentioned in the appnote such as the 9 bit bug.

The thing I'm most intrigued about though is the notion that one needed to turn off the SR in order to not interfere with tape recording. I think your theory that it interfered with IRQs makes sense, since tape is a very timing sensitive medium and missed or delayed timer interrupts would wreak havoc with tape routines designed around them. I'm kinda curious why this particular bug doesn't seem to be documented as well as the other ones, especially if the symptoms were well known by PET and VIC owners.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Looking around for more info, I noticed this in the wikipedia entry for the 6522:



Is this behavior what this note in the WDC's datasheet is referring to?

a "in a CBM disk drive bus configuration" was implied in my statement. Since a 1MHz 6522 was in the disk drive, 250kbps was the maximum input speed, and the C128 (and it's 2MHz operation) was years away. Though, even if 500kbps output was possible on the C128, I suspect CBM would have limited it to 250kbs to maintain compatibility with the plethora of IEC devices on the market at that time that might not have been able to handle 500kbps.

Jim

I try


I'm not convinced competition for IRQ time would have been the specifically, as Jim and other PET-heads would have known about that and I think such an issue would not have been termed "interference", but rather "corruption". I seem to recall some personal discussion with Jim that implied it was lost interrupts (there is a bug like that in the 6526, as I recall, where two IRQs happening close to each other causes one to be lost, or something like that). Thus, I think the SR IRQ would cause the timer IRQ for the tape routines to intermittently fire, which would corrupt tape, but not all the time.

Jim

Good recollection. The missed IRQ would occur if the interrupt flag register was read one or two cycles before timer B underflowed and also generated an interrupt. In such a case the timer B interrupt would be lost. This was not found in all 6526s, but enough for it to be a significant problem with CIA #2, since it used the timers to run the fake RS-232 routines. Timer B was used for incoming data and if the interrupt was lost, a bunch of incoming bytes end up in the bucket.

There was also a problem with the Time of Day clock alarm interrupt, which would not occur if the alarm time tenths-of-seconds was set to zero. The solution was to set the tenths to anything other than zero.

This sort of malarkey was fairly typical of MOS Technology product. It seemed hardly anything they produced worked exactly as it should.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I think it's because they tried to hang too much logic off the phi-2 clock, if you ask me. Most other chips on the market are entirely synchronous by design, which means you only have to concern yourself with one, and only one, edge of the clock, and everything happens on that edge.

MOS Tech, on the other hand, tended to not only use both edges of the clock, but as evidenced by the need to qualify read and write signals with phi-2, also the levels too. That simply doesn't leave a whole lot of room for error in fab tolerances.

Honestly, I'm shocked the 65xx architecture works at all!!

Wow, I didn't even know this one! Thanks Jim!

Interestingly it shows a serial communication "network" using the VIA shift registers in Fig. 16 and Fig. 17. Here I assume the implied synchronized Phi2 signals between the systems, to not fall into the SR not detecting the shift pulse, right?

It would have been soooo simple. Why isn't that just simply fixed in the WDC versions....

André

I think it's because of two reasons. One, they're hanging too much logic off the clock signal, as indicated above. Another, I think the 65C22 is drawn from hand-generated layouts, and not synthesized from computer. Fixing the bug would involve changing that layout, and going through a lengthy test/debug cycle, potentially costing a lot. Considering WDC's abject lack of a 32-bit successor to the 65C816, I have to conclude that their sales isn't so large that they can sink that kind of cash, and more specifically, that sales of the 65C22 itself is too small to justify investment.

I don't think it's an unfixable bug -- after all, the 6526 fixed it.

I do wish, however, that the 6522, as versatile as it is, would be augmented by a genuine 6526 successor. I seem to recall that it had a more useful configuration of timers and slightly easier interrupt management. Additionally, it fixes the serial register bug. AND, of course, many an owner of dead-due-to-bad-CIA Amigas or C64/128s would profusely thank them.

But, again, it's all about the sales volume.

That's creepy! Does the VIA really do this? I guess there's one possible problem (I haven't run into it yet) with my 65816 board then. The CPU runs with 8MHz and is slowed down to the 1 MHz the bus runs - but on fast mode, bus select lines are inactive, but the address lines are changing with 8MHz (I'm thinking about switching the bus drivers off here, but not yet done).

On the other hand - this is basically unbelievable. If the chip reacts to address lines even when chip select is inactive it would possibly react to anything all the time, after all it's got only 4 address bits. I'm skeptical.

Actually I know that the VIA latches its address lines when Phi2 goes up - one of the problems when connecting it to the C64. Here the CPU address only goes valid when Phi2 is high, when Phi2 is low, the VIC has the bus. Therefore, for the 6522, the rising edge of Phi2 must actually be delayed until the CPU address got stable enough. This would (somewhat) contradict what is written above.

Anyone knows more?

André

Yet another reason for pining for a 6526.

I miss the CIA.

Although, considering the prices of VIAs now-a-days, you can probably achieve your I/O goals with discrete components a lot cheaper, albeit at the expense of space. (And, if you use an FPGA or CPLD, it'll be amortized cheaper still.)

Yes, I think a small CPLD (e.g. Xilinx 9572 or even 9536) would even suffice for a VIA or CIA replacement. But that's from someone who hasn't done VHDL before :-)

André