I'm new here. Hello everyone.

I recently decided to post all my Commodore stuff on Github, and ran across something from 30 years ago involving the Commodore Plus/4, which you may recall has a real 6551 ACIA (called the 8551 in the Plus/4). This computer's rom has an error in the IRQ servicing routine which makes it impossible to receive a null byte, which in turn makes file transfers impossible. I brought this up a long time ago, but never wrote replacement code which bypassed the error, and have now done that.

This process has raised two questions about the 8551. The first is that I found a mention online that some programmers had found that the original MOS 6551 interrupt flag, bit 7 of the status register, is not always set when an interrupt is generated if the baud rate is 9600 or higher. The interrupt takes place properly, but bit 7 just isn't always set. So the question is whether anybody knows if this defect affects the 8551. Most software I've seen, including the Plus/4's IRQ code, bypasses ACIA servicing altogether if bit 7 is cleared since it assumes the ACIA wasn't the source of the interrupt. If a receive interrupt is not processed because of this, an incoming byte may be lost.

The second question I believe involves all 6551s. If there has been no outgoing traffic for a while, when you write a byte to the transmit register, that byte is immediately transferred to the outgoing shift register, and an interrupt is immediately generated with the transmit register empty flag set. This makes it possible to transmit continuously because the transmit register can be filled before the previous byte transmission has been completed. But for the Plus/4, the problem is that it uses a single byte transmit queue - just a single outgoing byte and a flag indicating there is now something to send. This means that the interrupt that takes place immediately after that byte is written to the ACIA is completely pointless. There will never be another byte available that could be loaded in. So assuming transmit interrupts are enabled, every byte transmitted will result in an extra interrupt, immediately after the current one, that does nothing but waste time and accomplishes nothing.

What I thought might work is, within the IRQ routine, disable the transmit interrupt just before writing the byte to the ACIA, and then enabling the interrupt again a few instructions later. The hope would be that when the interrupt is re-enabled a new interrupt would NOT be generated because the time for doing that has passed - barely. Does anyone know if that would work? How would you go about testing to see if it works?

Of course the ultimate solution is to upgrade the transmit buffer situation, but I'm trying to come up with just a new front end to the IRQ servicing routine, not modify anything else in the Plus/4 firmware. And I should say that I no longer have any CBM gear, so I have no way to test anything.

Well, if anyone has any ideas about these questions, I would appreciate any comments. Here's the Github link in case anyone is interested.

https://github.com/gbhug5a/My_CBM_stuff

George

Many years ago (the 80's) I added a R6551 to a Vic-20 on a plug-in expansion board, which also had additional memory, a couple expansion slots and a RTC. I wrote a buffered BIOS for it and was able to run at 19.2K baud rate with a wrap plug on the RS-232 connector. The code was interrupt-driven for both receive and transmit. The receive/transmit buffers are 128-bytes each. There are no known issues with the code, albeit recent W65C51 ACIAs have a defect with Xmit. In more recent years, I integrated this BIOS (with updates) into a tiny monitor with an expandable BIOS.

If you're interested, you can grab the source on my GitHub page:

https://github.com/floobydust/Micromon-V1.2

_________________
Regards, KM
https://github.com/floobydust

Thanks very much. Your IRQ code branches past all the ACIA stuff if bit 7 of the status register is cleared. If this worked at 19.2K, then at least the 6551 you tested it on did not have the bit 7 bug. And you have a real buffer for transmit, so the issue I have with the Plus/4's single-byte buffer didn't come up. I may just go ahead and provide for the bit 7 bug. Instead of testing bit 7, I think I can just test the Rx and Tx flags individually. It would just be a few more clock cycles on each interrupt, so maybe pretty cheap insurance.

Oddly, I never recall hearing about the bit7 bug in the status register. I have early NMOS Rockwell 6551 parts plus an very old Synertek 6551 and numerous other CMOS versions. I've not encountered any problems, so perhaps it was only with some early MOS parts?

_________________
Regards, KM
https://github.com/floobydust

I found it here:

http://csbruce.com/cbm/ftp/reference/swiftlink.txt

"Some programmers have reported problems with using bit #7 to verify ACIA
interrupts. At 9600 bps and higher, the ACIA generates interrupts properly,
and bits #3--#6 (described below) are set to reflect the cause of the
interrupt, as they should. But, bit #7 is not consistently set. At speeds
under 9600 bps, bit #7 seems to work as designed. To avoid any difficulties,
the sample code below ignores bit #7 and tests the four interrupt source bits
directly."

That's all I know. But I haven't seen it mentioned anywhere else.

Welcome, George

You asked for comments, and I will try to be helpful. Unfortunately I can't point you to a solution because I suspect you're dealing with faulty information. The "9600 bps and higher" problem makes no sense to me in terms of a hardware issue. IMO there must be a misunderstanding somewhere.

I'm by no means a Commodore expert but I am a hardware guy, and here's my take. The ACIA internal circuitry for flags needs to respond to events (such as a read or write) that last just one CPU cycle. And I expect the resulting flags update also takes just a single CPU clock cycle, plus a slight latency perhaps -- another cycle or two at the most.

So, imagine Scenario A. The ACIA is working properly, at low speed (below 9600). Because of the low speed, dozens or hundreds of CPU cycles will go by between events. Then a read or write occurs, or maybe a transfer from a holding register to a shift register. The flags need to respond properly to this very brief event (which occupies just one CPU cycle), and they are successful in doing so.

In Scenario B, above 9600 baud, less time elapses between events. But the timing of the event itself doesn't change. So, why would the flags (bit 7, specifically) fail to update? Is it because it needs lots of time -- dozens or hundreds of CPU cycles! -- to recover from the previous event? Maybe, but I don't think so.

Meaning no offense, but I suspect your source is unreliable on some level. For example, if indeed multiple persons have experienced the problem, perhaps your source has misunderstood what the others told him. It's possible I'm overlooking something. But you asked for comment, and, as described, the "9600 bps and higher" thing sounds to me much more like a problem pertaining to software -- which very plausibly COULD take dozens or hundreds of CPU cycles to finish dealing with a previous event.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

Oh, thanks for the link to that article, BDD - and thanks, George, for writing it!

ACIA and 6502 have different clock sources, right? If so this intermittent-at-higher-baud bug suggests a metastable issue due to status generated with one clock being sampled by processor running on different clock. Metastability occurs at a low but constant rate so higher sampling rate has better chance of revealing metastability issue. If the intermittent problem is fixed by running ACIA and 6502 with the same clock, then metastability is likely cause of the issue.
Bill

Thanks for the added info, BDD -- it does seem as if it might be peripherally pertinent. And yet I remain alert to the possibility that some sort of misunderstanding exists.

BTW I'm not questioning George's reliability, just that of the report he's seeking to verify -- so far, unsuccessfully.

The report mentions an issue that occurs at high baud rates but not low baud rates, and I've explained why baud speed sensitivity seems to me likely to indicate a software bug, not a hardware issue with the ACIA.

Perhaps Commodore-produced I/O devices do have a checkered reputation for reliability, but what remains unverified (in this thread, at least) is the existence of a baud-speed related problem. If the problem were sensitive to bus speed, or not sensitive to speed at all, that to me would seem a lot more plausible.

Oops, I see plasmo has just posted, and he makes an excellent point. And IMO it reveals, as I suspected, a degree of misunderstanding. If sampling and metastability were to cause a problem (and this seems plausible) then the problem will NOT (as reported) disappear at low baud rates; it will merely become less prevalent. (And if the problem is fixed by running ACIA and 6502 with the same clock, this supports the conclusion that metastability is the cause.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Is the XMIT status bug of W65C51 intermittent or stuck-at? WDC literature seems to suggest it is stuck-at-0, but that seems unlikely because a quick test will reveal it and such obvious flaw will never make to production. If it is intermittent, I wonder whether it is also due to metastability? Which can be prove/solved by running CPU and W65C51 at the same clock.
Bill

You'd think not. And yet... !

Right. Sadly, as a small company, they seemingly lack the resources to prevent or correct the problem. So they altered the documentation instead.

Kudos for not trying to deny it, I guess. And workarounds do exist. (Nothing I've read indicates that it's a metastability issue.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks for everyone's comments. Jeff, I agree that if the problem exists at all, it probably isn't dependent on baud rate. But of course I've been down this road before with the 6526, so I'm open to the possibility that the problem is real. And BigDumbDinosaur's report supports that. The remaining question is whether the "8551" used in the Plus/4 also has this problem.

Testing the individual interrupt source flags should finesse this issue, but there would be some timing cost. But unless I can somehow confirm that the 8551 is immune to this issue, I think it makes sense to do that. I think I can combine that with an idea for turning off the transmit interrupts when there's nothing to send. The Plus/4 makes no provision for that.

Well, I've sent email to Craig Bruce asking if he remembers anything more about this issue. I'll report back if I get a response.

Well, having first found the W65C51 Xmit bug, the bit is permanently stuck on, hence it always shows that the chip is ready for another character to be transmitted. Problem is, if you write to the chip before the Xmit shift register is empty, it simply reloads the SR with the new character and what bits haven't been sent are gone. It also causes endless interrupts to occur when Xmit IRQ enable is set on.

Oddly, the WDC datasheet has been changed several times since I alerted them to the problem, but it never seems quite correct in describing the problem. Granted, one can use it in a system, but it requires a software workaround, so there's simply no existing code ever written that will work correctly for transmit... receive on the other hand has no issues, interrupt-driven or polled I/O.

Personally, I've moved on to the NXP (D)UARTs. They are more programmable, higher data rates, more function and a 16-bit timer that doesn't sync against the CPU clock (provided you use either the specified crystal or a can oscillator). I use the timer for a jiffy clock, i.e., 10ms interrupt which results in a realtime clock function, accurate delays and a benchmark timer for testing.

_________________
Regards, KM
https://github.com/floobydust

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