Fixing a hardware bug in software (65C51 UART)
Added 2023-05-01 00:32:25 +0000 UTCHere'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
I encountered the latch up issue again during one of the later videos. This time I used a current limiting resistor (120 Ohm) on the VCC connection to the MAX232. This seemed to do the trick.
Morgan
2024-04-21 23:18:28 +0000 UTCI 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.
Morgan
2024-04-13 03:49:30 +0000 UTCI'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?
Morgan
2024-04-09 01:22:47 +0000 UTCFixed 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.
Toon Leijtens
2023-06-23 17:45:07 +0000 UTCI 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!`
Toon Leijtens
2023-06-23 08:53:45 +0000 UTCWith 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/
NormalLuser
2023-05-07 06:15:04 +0000 UTCI don't have mine in front of me, but I think I used a resistor to slow down the reset line rise/fall as a simple debounce.
TheWebMachine
2023-05-06 09:51:41 +0000 UTCDoes 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"
Kris Kennaway
2023-05-03 22:00:45 +0000 UTCI'm not sure if I understand you correctly. What I meant was to: 1. wait until the chip indicates that the previous byte (if any) was sent 2. send the new byte to the chip. The waiting part happens only if there was a previous byte sent quite recently. The benefit of this scheme would be that the CPU is free to do useful things while the chip is sending the byte. That is, these happen in parallel. But again, this only makes sense if the indicator bit is reporting the correct state.
Ivan Toshkov
2023-05-03 10:46:57 +0000 UTCCool. I was thinking about how to auto reset my 8-bit computer at power on. That DS1813 looks quite handy.
bencodestx
2023-05-03 03:56:24 +0000 UTCI also had this question. Showing the datasheet acknowledgement would be valuable. As many times as Ben has pointed to the value of actually reading the datasheets I still find myself just looking at the pinouts and scratching my head.
bencodestx
2023-05-03 03:52:24 +0000 UTCThe 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.
bencodestx
2023-05-03 03:49:57 +0000 UTCBefore 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.
Anne & Jim K
2023-05-03 03:43:00 +0000 UTCThe address lines are set and the rwb (read write) pin is pulled high (to indicate a read).
Anne & Jim K
2023-05-03 03:40:55 +0000 UTCI'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?
rhc
2023-05-03 02:18:38 +0000 UTCAt 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.
Ivan Toshkov
2023-05-02 12:09:46 +0000 UTCConsider mentioning using a 6522 timer to work around the hardware bug, as an alternative to the delay loop.
Phil Dennis
2023-05-01 19:32:25 +0000 UTCA DS1813 makes this super easy!
Jason Thorpe
2023-05-01 18:42:07 +0000 UTCIt’s actually mentioned in the data sheet. This doesn’t make it any less annoying.
Jason Thorpe
2023-05-01 18:41:27 +0000 UTCGreat 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?
Xavier
2023-05-01 14:55:46 +0000 UTCThis bug has been difficult at times. It's been around for a while. Bob Corsham chose the 6850 on the KIM-1 I/O expansion board because of this bug. I too find it much easier to use, but hard to find sometimes. (I LOVE Bob's KIM-1 Clone) The delay method becomes especially painful when you want to take it down to 2400bps to interact with vintage 8 bit machines. Looking forward to the next video in the series.
Michael Doornbos
2023-05-01 13:14:58 +0000 UTCYou 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
Thomas Eriksen
2023-05-01 07:19:52 +0000 UTCAnother great video. Very easy to follow along with.
Jim Kelly
2023-05-01 04:51:49 +0000 UTCyou 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.
Michael McDonnell
2023-05-01 04:29:03 +0000 UTCBefore 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!
Jason Thorpe
2023-05-01 04:10:41 +0000 UTCSpeaking 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?
Hugo Dahl
2023-05-01 03:30:33 +0000 UTC
