6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 12:03 am

All times are UTC




Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sun Nov 28, 2021 6:46 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
Dr Jefyll wrote:
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.

Was that pun intended? :D

Quote:
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.

Given Commodore Semiconductor Group's past reputation for occasionally producing I/O hardware with problems, there could be a relationship between high serial bit rates and occasional interrupt failures due to closely-space interrupts. Obviously, in a fully interrupt-driven application engaging in high-speed CBAT, the UART's internal timing may become critical. It is possible that a hardware glitch analogous to the 6526 timer-B bug could be involved when, say, the 6551's transmitter interrupts shortly before the receiver and the interrupt handler reads the 6551's interrupt status right before the receiver interrupts.

Considering George's skill in solving the C-64/C-128 unreliable RS-232 performance riddle, I'd be inclined to think his code is clean and there is indeed a strange bug in the 6551.

floobydust wrote:
Personally, I've moved on to the NXP (D)UARTs.

As have I. I haven't used a 6551 in anything for some 30 years.

I am baffled as to why anyone would even consider the 6551 at this point in time. It was a lame UART in the 1970s and is still a lame UART, especially the WDC incarnation with its stuck transmitter bug. Its performance is mediocre, its programming model is inflexible and it lacks FIFOs. Back in the day, many 6502 system builders used the Motorola 6850, despite it not having an on-chip bit rate generator. Almost anything is better than a 6551.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 29, 2021 3:10 am 
Offline

Joined: Sat Nov 27, 2021 3:33 pm
Posts: 8
GeorgeHug wrote:
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.

He did respond:

"For that article in C= Hacking, I was just editing and republishing preexisting documentation from CMD. I don't know if it's true or not."

I assume CMD is Creative Micro Designs. I think they bought SwiftLink from Dr. Evil Labs. Well, I think it's prudent to assume it's at least a possibility. So I think I will change my code accordingly.


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 29, 2021 3:52 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
GeorgeHug wrote:
I assume CMD is Creative Micro Designs.

or probably California Micro Devices which was another second source for 65xx parts. http://6502.org/documents/datasheets/cmd/ Before that, it used to be GTE Microcircuits.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 29, 2021 5:14 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
GeorgeHug wrote:
GeorgeHug wrote:
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.

He did respond:

"For that article in C= Hacking, I was just editing and republishing preexisting documentation from CMD. I don't know if it's true or not."

I assume CMD is Creative Micro Designs. I think they bought SwiftLink from Dr. Evil Labs. Well, I think it's prudent to assume it's at least a possibility. So I think I will change my code accordingly.

CMD is Creative Micro Designs. They were the final producer of the Swiftlink.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 01, 2021 3:23 pm 
Offline

Joined: Sat Nov 27, 2021 3:33 pm
Posts: 8
I believe I have evidence that the bit 7 bug affects the 8551 ACIA found in the Plus/4, and does so at any baud rate. I got BSZ on the plus4world.powweb.com/forum to run a couple test programs on his Plus/4 from my repo on this problem:

https://github.com/gbhug5a/My_CBM_stuff/tree/main/Plus4_IRQ_ACIA_error/IRQ_TEST

I wanted to confirm my belief that every byte transmitted with the Plus/4 would result in two interrupts, and to test a fix for that. So the first program just counted the number of ACIA interrupts (using the bit 7 test) which occurred when transmitting 256 bytes at 2400 baud (i.e. - not 9600 or higher). The second program did the same count, but turned off transmit interrupts before sending each byte, and turned them on again after. The hope was that if the interrupt was disabled when it should have taken place, it wouldn't take place at all. Well, that didn't work, but the actual counts he reported were interesting.

He said the first program always reports 510 interrupts. But the second program varied each time, reporting values such as 447, 456, 457, 452, 454, and 453. The relevant transmit IRQ code from program 2 is:
Code:
transmit:

   lda   $07d4       ;previously stored staus register value
   and   #$10        ;transmit buffer empty?
   beq   backtorom
   bit   $07ce       ;anything to send?
   bpl   backtorom

   ldy   $fd02       ;turn off xmit interrupts
   tya
   eor   #$0c
   sta   $fd02

   ldx   #$00
   jsr   $ea83       ;send the byte

   sty   $fd02       ;turn xmit interrupts back on
   
backtorom:

   jmp   $ce2b       ;acia done, continue rest of irq


I can't explain why the first program says 510 instead of 512, and of course the second program results strongly suggest the bit 7 bug. If I had a Plus/4, and if I could remember how to blank the screen and turn off all the other interrupts, such as raster and timer, I could see if not using the bit 7 test made for consistent results of 512. But I think I would wear out my welcome at Plus/4 world asking for a lot more tests.

The alternative to solve the double interrupts may be to read the status register again after sending the byte. If the second interrupt has been triggered, that should clear it. That's in program 4.

Anyway, it looks like the bit 7 bug may be associated with reading from or writing to the command register close in time to the interrupt taking place. That would be similar to the 6526 bug.


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 19, 2021 7:34 pm 
Offline

Joined: Sat Nov 27, 2021 3:33 pm
Posts: 8
I've rewritten my alternate ACIA servicing code for the CBM Plus/4 and posted it to my Github. In the end, I was not able to get any confirmation of the flaky bit 7 of the Status register. But since testing only involved one computer, I decide to bypass any possible problem by testing the transmit and receive flags individually instead of bit 7.

But I wanted to revisit the second question I had in the original post because others using the 6551 might be affected by what I found. That involves what happens when your IRQ servicing routine writes a byte to the 6551 Transmit Data Register. If nothing is currently being shifted out, the byte written to the Data register will immediately be transferred to the Shift register, and a new interrupt will be generated immediately - because the Data register is empty again. This will bring the IRQ line low again, and since IRQ is level-triggered in the 6502, when the current interrupt service completes, a new one will follow on immediately.

If there is a transmit queue, and if additional bytes remain in the queue, then the second interrupt will let you write a new byte to the Data register, and another interrupt will not be triggered because the first byte is still being shifted out, so the Data register is not empty. This allows for truly continuous transmission if you can keep the queue at least partially full.

But if there is nothing else in the queue, the second interrupt will be pointless, and will just waste time, because nothing will happen in it.

As I said in the original post, the Plus/4 has a one-byte transmit queue. So since the second interrupt follows immediately after the first one, there is no opportunity for the terminal code to fill the queue again. And indeed I found that there were two interrupts generated for every byte transmitted. At high baud rates, that can compromise performance. So my solution was to wait just a bit after writing the byte to the Data register, and then read the Status register again. That clears the second interrupt and lets IRQ go back high. The delay is needed because the new interupt is not actually generated immediately, but after a period of time that is a function of the baud rate. So a longer delay is needed for slow baud rates than for fast ones.

But in reading the Status register again, there is a possibility that a byte has just been received, and if not serviced, that byte will be lost. So what I ended up with was servicing the transmit first, and if I've sent a byte, I wait a while, then OR the Status register with a copy of the original Status read. So if a byte was received on either Status read, that bit will be set, and I service that receive.

I assume everyone but Commodore would use a real multi-byte transmit queue. But even so, it might make sense after writing the byte to transmit Data, to wait a bit, then read Status again, and if Data is empty, write another byte to it if there is such a byte in the queue. Doing that could save an interrupt.

The only reference I found for the delay was in the Rockwell datasheet for their 6551. It said when a byte is written to the Data register, and then transferred to the shift register, the Data-register-empty flag bit is not valid until after 1/16 of a bit period. Apparently this also applies to generating the interrupt. I was not able to measure that accurately, but tested how much of a delay was needed for the double interrupts to transition to single interrupts, and found that the delay increases with the baud rate. My code is complicated enough that no extra delay is needed for 4800 baud and faster. But for slower baud rates I go into a short delay loop. "Slower" means bit 2 of the Control register is cleared. For very slow baud rates (600 and below), I do not delay since the second interrupt might go faster than the needed delay, and in any case at 600 baud a few extra interrupts per second probably don't really matter.

Hope this is useful.

https://github.com/gbhug5a/My_CBM_stuff/tree/main/Plus4_IRQ_ACIA_error


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 19, 2021 8:15 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
The 6551 was a mediocre design when it was first released and as you are discovering, it is a bit like walking through a minefield in trying to use it. I haven't touched one of those things in some 30 years.

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: