Fixing a hardware bug in software (65C51 UART)
Here's a new video in the 6502 series. It's software for the 6551 UART serial interface. Unfortunately this chip from WDC has a hardware bug that has to be worked around. It's not ideal, but not too terrible. With the conclusion of this video, it's now very easy to read and write data from the serial interface, opening up a lot of interesting possibilities. Up next, I expect to demonstrate Wozmon running on the 6502, so stay tuned for that.
As always, thanks for your support in helping me create these videos, and let me know if you spot any issues in this video.
Thanks!
-Ben
Comments (21)
hello everyone i followed ben eater's uart video down to a T and i am using tera term 5 and also tried putty and i was able to get the hello world to display on the terminal screen but i get a blank screen on my LCD monitor and when i try to type something nothing shows up on either the terminal screen nor the LCD screen like what we see on his videos. does anyone else have this issue and if so what did you do to fix it?
I've fried two MAX232 chips following this video and I cant figure out what is going wrong. When the chip is still intact the program works fine, I get the "Hello World" message to my terminal on the PC and I am able to write back to the 6502 LCD. However after a while the MAX232 gets hot and stops functioning. I've tried two different chips now (the TI from the kit and a knock off Maxim) and on the second chip I tried changing the cap on pin 2 to VCC per the Maxim MAX232CPE datasheet online. Same results. Anyone have any suggestions?
I may have found a solution. I had a rather large 10uF electrolytic decoupling capacitor on the power rail on the breadboard adjacent to where the MAX232 was connected to. I had installed some of these caps because I was having issues with decoupling on some of the circuits in one of the earlier tutorials. It seems that this cap at this location was somehow causing the MAX232 to latch-up and pull >500mA. After removing the capacitor from that power rail, the chip now operates normally and draws only ~12mA and does not latch-up after resets or power cycles.
I have followed through on most of the video's and just completed the project including this one. I wanted to double check with others where they also experience issues not receiving the "Hello world!" string in full. I tried longer delays, replacing the capacitor from 20pF to 30pF from the Chrystal comming of the 65C51 UART. But no joy. Typing text from the RS232 terminal and the echoes from that interaction work well. What more could I do to improve. I am not confident the circuit is good enough to proceed to the next exciting stage. Any help is appreciated. A few resets will produce: `Hello, world!Hello,orld!Hello, world!Heo, world!`
Fixed it, by grounding the CTSB pin (9) on the 65C51 UART. Also decided to firm-up the chrystal + 1M resistor by using the same hole in the breadboard. The resistor otherwise was too loosly connected.
With the Ben Eater 6502+VGA+6551 I've been able to run an actual game! https://www.reddit.com/r/beneater/comments/13a5a21/first_real_game_on_my_be6502_vga_serial/
Does that data sheet at 8:12 have a misprint? 10 and 11 for bits 3-2 both have the same description - I'm guessing 11 should be "RTSB low, transmit interrupt enabled"
The workaround is effective for the bugged chip, but I think adds unnecessary delay for the chip with the working flag. I might would tweak the workaround to delay first and then check the status flag (or remove that entirely if using a hardcoded delay). This is also one of those bugs that is detectable. If immediately after sending the register says it is empty, then we need a fixed delay; otherwise, keep spinning until clear. All of these are good exercises left to the reader most likely. You convey well the reality of a hardware bug and what to do about it.
I'm confused how the load instruction clears the state of the interface chip. I assumed that a load was passively looking at the voltage levels on the bus after the address is transmitted. Does the CPU actively pull the lines low? How does the interface chip know that a load has occurred and it can stop signalling that the buffer is full?
The address lines are set and the rwb (read write) pin is pulled high (to indicate a read).
At 12:50 I'd argue that it's better to do the wait loop _before_ sending the character. This way the CPU can send a character and can do something useful while the controller is sending the character. But if it tries to send a second character too soon it will have to wait. That is of course, if the if wasn't for the hardware bug.
Before would prevent a previously written byte from elsewhere without a delay after. However there's still wasted cpu time unless an external timer is used.
Consider mentioning using a 6522 timer to work around the hardware bug, as an alternative to the delay loop.
Great video, as usual! Although I understand that the economics of fixing the hardware bug would not work out, I am so shocked that the datasheet PDF does not come with a red bold warning about that long-known bug! Is that common?
You mention DCD, was that only on the old chip? how will the 65C51 know the Data Terminal is Ready and that its receive buffer is not full?, delay don't work in those situations
Another great video. Very easy to follow along with.
you may want to de-bounce the reset switch. you could do it quickly and reference the video on debouncing and possibly interest newer viewers to some of your older content.
A DS1813 makes this super easy!
Before watching, I'm going to just guess that it's the "transmit completion indicator doesn't work" issue due to the Tx shift register being loaded immediately when the Tx data register is written. That bug really irks me!
Speaking for myself, it would be interesting to know how you found out about the hardware bug. Did you (un)fortunately beat your head against the wall for us? Was it a known issue in the documentation? Something else? This seems like it might be its own topic, but ultimately, how would one go about finding that out when building their own project, rather than assume they're likely doing something wrong?
It’s actually mentioned in the data sheet. This doesn’t make it any less annoying.