Glad you liked in Ajinkya! I'm trying to decide at the moment what functionality to add before interfacing it. Probable baud rate would be interesting but doesn't really add anything to the cpu, a but of buffering would be handy but it's a lof of circuitry to add.
It just shows when people tell you something is hard or even impossible you can come up with not only a simple but elegant solution too. It must be very rewarding. Well done. I've been re-watching your old videos lately and they are a joy to watch. Keep up the good work.
Thanks Mathias! The combination of the SR latch to detect the start bit and it's inverted output holding the 193 in reset is really the core of this circuit.
Thank you for making this video. I have just enjoyed making the transmit and receive circuits myself, and I'm looking forward to learning more from your next videos in this series!
Clock alignment was my biggest concern but you addressed that perfectly. I had issues back in the day with 9600bps devices being just a little too slow or fast so the clock would periodically fall out of alignment. This isn't a huge deal for typing and displays as it manifests as a "rare" 1 bit error, but for sending several KB of binary data, it could be a nightmare.
Thanks Michael! In theory the receive circuit shout tolerate a drift of upto half a bit per transmission frame as it essentially resets itself with each start bit, something else would probably go wrong before then though. We are a bit spoiled now with the accuracy of all the components we get comparatively cheaply.
I've only saw that on badly implemented "bit banging" UARTs made via software that didn't use interrupts to detect the lowering edge trigger. You have to edge trigger the circuit on lower signal, its easier done with discrete components, ironically than on software (because people are bad with interrupt code).
Congratulations for what you do and many thanks for sharing this with us, James! I'm not sure if I'm saying it wrong or not, but isn't an majority circuit used in receiving the start bit? Have you thought of doing an implementation in this way as well? Also, do you think to implement an SPI interface?
Thanks! SPI is mostly a simple architecture but there are some complexities to it (the different modes). In some ways the SNES controller interface I built is closer to SPI.
Very nice! It would be great to see the schematic for what's on the breadboard. I guess, once the CPU interfacing is figured out, you will make up a UART a pcb? I think that will be your first input device, as the LCD was all output? And I still think you should write a machine code monitor. It's a fabulous way to learn an ISA, or in this case, to confirm that an ISA is useful for writing practical software.
Lawrence, it's not that I don't see value in a monitor, it's that it doesn't win out when compared against other things I could spend my time on. A half baked one could be done quite quickly but to do the job well is a significant time investment. I have a different method of loading code without an eeprom planned that could be completed alongside a couple of games in the time it would take me to write a decent monitor.
Thanks for your great videos, James! It is really appreciated. Very well put together - this time in more of a tutorial style. I've just stumbled upon your channel and realized that we pretty much share a similar passion... but with a different spin :-) Have a look at my 'Minimal 8-Bit CPU' build if you find the time. Cheers!
Good stuff Slu4! I've watched a the first of your vids, will get thru the rest over time. Hopefully you've watched enough to get an idea of how overly ambitious i've been.
@@weirdboyjim I found your UART miniseries so fascinating that I immediately started to build a 'UART edition' of my Minimal 8-Bit CPU, which won't be using any Arduinos - just the UART for I/O... my design is getting simpler every day :-) Again thanks for sharing the concept. Cheers!
Nice, now you've just got to add a baud rate generator, auto detect and a buffer :) in the past we used to add a preamble to the the message to give the receiver a chance to sync and get the mid point more accurate. I thought you were going to send "The quick brown fox jumped over the lazy dogs" or some thing of that ilk.
Thanks Teh, Baud rate generator is a maybe. Buffering I'm interested in, but a multi-byte buffer might be a lot of circuit to add. Auto detecting the baud rate is an interesting challenge, not sure I'd want to do it in hardware on a breadboard though.
My idea to enable/disable the osc directly doesn't work, of the three I oscillators I`ve tested one ignored the enable signal completely, two started whenever they wanted and because controlling the counter gives the same result there's really no point. Another question was how to make the baud rate variable... Still don't get why someone would want to slow the whole thing down but a mux should solve that problem. Since it's very probable that the only thing getting connected to the board is goint to be some kind of converter I woul'd ignore "standard" baud rates and go for the absolute maximum possible.
Shame that didn't work, I've noticed how the enable like on the crystal oscillators can be hit and miss. I held of for a day before replying to your message for what may now be an obvious reason, to implement a programmatic baud rate control what you need is to add a clock divider into the circuit, just like the one in my latest cpu video (ruclips.net/video/jlCBTwww4QI/видео.html). Only instead of dip switches you would take the preset value from a latch chip that you can load with the require denominator.
Thanks. I’ve thought about it some more and realized a couple of things. First, that using the clock signal of the crystal gives a 16x finer resolution than does the 1st 193, and that this enables starting the counter on the 2nd 193 very quickly after the start bit, as a clock edge is available sooner. Second, that in the setup without the 2nd 193, there is a phase shift of the start bit wrt the 1st 193 clock due to propagation delays. What I still don’t understand is why that delay varies from key press to key press.
Great video - really enjoyed watching!! What would happen if you started receiving just as Tx was toggling between data bits, and confused this as the start bit? Is there a way around this or are you just assuming you always start Rx with a "clean" start bit?
Thanks Richard. Not 100% sure I understand what you are asking, I'm wondering if you think the tx/rx pair at each end are connected together? The TX on the remote end connect to the local RX and vise-versa. There shouldn't be any cross talk between them.
@@weirdboyjim Thanks for the reply. Say you are constantly transmitting data and then start receiving at a random point in time. There's no guarantee that the first falling edge the receiver "sees" is the start bit (could be the falling edge of a data bit, say). So I suppose i'm wondering how synchronisation to the start bit is always guaranteed. If that makes sense?
@@stencilgraffitiapp the first character would be garbled, but as soon as there was a "gap" in the incoming data, longer than a true character, it would automatically resynchronize. True UART hardware would notice an incorrect stop bit polarity and generate a framing error.
Nice! I imagine hardware flow control would be useful for the receive side at least, 115200 is not slow for this type of tech :) That seems fairly simple though
Thanks Frank! There are a few options for flow control, but I'm worried I might be digging myself a hole with the amount of circuit to build on top of what I have.
Just finished binge watching almost 100 videos about your cpu🤪 But here is my first question: could you use the original 1.8MHz clock to "oversample" for the start bit and use that to reset the divide by 16 counter for alignment?
That's pretty much what the circuit does, I hold the counter (one running at the 1.8mhz) in reset until until the start bit comes in. Sorry if it wasn't clear.
The test code here was throwaway. stdafx.h is a header file created by the automatic project creation code in visual studio. There wouldn't have been much in it though, so post on discord and we'll get you working.
Thanks Dennis. In the Harry Potter books wizards can't use technology "Because magic interferes with technology", now you've told me I'm a wizard do I get to use that as an excuse when my stuff doesn't work?
@@weirdboyjim whatever works for you James! I'm sure you don't often need that excuse tough! PS thanks for all the great content. You're on top of a dozen channels I look out for new videos and I'm never disappointed. If only you knew how much I've learned from you! ✌️🤯
I think you have misunderstood what my circuit is doing, the transmit and receive circuits share a clock source but there is no clock connection from the remote transmitter to the local receive, or the local transmitter to the remote receive circuit. The transmit and receive circuits shown here are not talking to each other, they form the two halves of a UART and share some circuitry.
@@weirdboyjim I see. First I didn't notice you've added separate clock divider for the receiver. I recommend using 74HC595 instead of 164 and separate register.
@@FilipMilerX Other people have suggested the 595 but I explicitly wanted to separate the functionality in this version. Hopefully it's clear to the viewer that the latch functionality is necessary. You could get an entire UART on one Chip fairly early, the point of this series is to look at the internal workings, not the easiest way to do it.
Hello. I've always had a doubt about serial lines. Lets say we are receiving a long stream of bytes. Our circuit gets the first low, takes it as start than counts to 10. What happens if i conect the line at the middle of some random byte? The first 0 bit in that byte would be mistaken by a start and that count would never be synched. How can i avoid this?
Uart my favorite new channel.
Uart much appreciated.
God Bless. Uart.
I see what you did there! Thanks! Glad you are enjoying!
Never actually worked with chips on a bread board, but this is empowering to watch. This vlog is a delight!
Glad you are enjoying it!
Perfect implementation.
I can't wait to see it interfaced with your computer ✨
Thanks as always ✌
Glad you liked in Ajinkya! I'm trying to decide at the moment what functionality to add before interfacing it. Probable baud rate would be interesting but doesn't really add anything to the cpu, a but of buffering would be handy but it's a lof of circuitry to add.
It just shows when people tell you something is hard or even impossible you can come up with not only a simple but elegant solution too. It must be very rewarding. Well done. I've been re-watching your old videos lately and they are a joy to watch. Keep up the good work.
Thanks David! I appreciate the support as always.
very nice, especially the second 193 to sync the start bit.
Thanks Mathias! The combination of the SR latch to detect the start bit and it's inverted output holding the 193 in reset is really the core of this circuit.
Thanks James, this is awesome. I have to rewatch these two videos again. Very interesting. Take Care.
Thanks as always Jerril! This series is probably only going to be 4-5 videos long, so maybe hold of on a re-watch until it's all there.
Thank you for making this video.
I have just enjoyed making the transmit and receive circuits myself, and I'm looking forward to learning more from your next videos in this series!
That's great to Hear Jim! Glad you found it interesting / useful.
James, another amazing video. Thank you to bring us your projects through this channel.
Glad to hear you liked it, thanks for your support as always Leonardo.
Found this UART series really useful and informative, Thank You!
Good to hear Daniel, thanks!
Clock alignment was my biggest concern but you addressed that perfectly. I had issues back in the day with 9600bps devices being just a little too slow or fast so the clock would periodically fall out of alignment. This isn't a huge deal for typing and displays as it manifests as a "rare" 1 bit error, but for sending several KB of binary data, it could be a nightmare.
Thanks Michael! In theory the receive circuit shout tolerate a drift of upto half a bit per transmission frame as it essentially resets itself with each start bit, something else would probably go wrong before then though. We are a bit spoiled now with the accuracy of all the components we get comparatively cheaply.
I've only saw that on badly implemented "bit banging" UARTs made via software that didn't use interrupts to detect the lowering edge trigger.
You have to edge trigger the circuit on lower signal, its easier done with discrete components, ironically than on software (because people are bad with interrupt code).
Great work James!
Thanks Aaron,
Congratulations for what you do and many thanks for sharing this with us, James! I'm not sure if I'm saying it wrong or not, but isn't an majority circuit used in receiving the start bit? Have you thought of doing an implementation in this way as well? Also, do you think to implement an SPI interface?
Thanks! SPI is mostly a simple architecture but there are some complexities to it (the different modes). In some ways the SNES controller interface I built is closer to SPI.
Very nice! It would be great to see the schematic for what's on the breadboard.
I guess, once the CPU interfacing is figured out, you will make up a UART a pcb? I think that will be your first input device, as the LCD was all output?
And I still think you should write a machine code monitor. It's a fabulous way to learn an ISA, or in this case, to confirm that an ISA is useful for writing practical software.
Yeah, I'll probably do a pcb for it at some point although I've not 100% decided if it will form a final part of the cpu build or not.
@@weirdboyjim it would make debugging your games easier? Also you could use it as a way to load code without plucking out the EEPROMs.
Lawrence, it's not that I don't see value in a monitor, it's that it doesn't win out when compared against other things I could spend my time on. A half baked one could be done quite quickly but to do the job well is a significant time investment. I have a different method of loading code without an eeprom planned that could be completed alongside a couple of games in the time it would take me to write a decent monitor.
Nice work and nice way to end it with the Knightrider scanner.
Thanks Adam. The Larson scanner was obvious once I stopped and thought about it, nice obvious pattern to test with.
Thanks for your great videos, James! It is really appreciated. Very well put together - this time in more of a tutorial style. I've just stumbled upon your channel and realized that we pretty much share a similar passion... but with a different spin :-) Have a look at my 'Minimal 8-Bit CPU' build if you find the time. Cheers!
Good stuff Slu4! I've watched a the first of your vids, will get thru the rest over time. Hopefully you've watched enough to get an idea of how overly ambitious i've been.
@@weirdboyjim I found your UART miniseries so fascinating that I immediately started to build a 'UART edition' of my Minimal 8-Bit CPU, which won't be using any Arduinos - just the UART for I/O... my design is getting simpler every day :-) Again thanks for sharing the concept. Cheers!
@@slu467 That's great news! Let me know how it goes.
Excellent video as usual.
Thanks as always Jonny!
Nice, now you've just got to add a baud rate generator, auto detect and a buffer :) in the past we used to add a preamble to the the message to give the receiver a chance to sync and get the mid point more accurate. I thought you were going to send "The quick brown fox jumped over the lazy dogs" or some thing of that ilk.
Thanks Teh, Baud rate generator is a maybe. Buffering I'm interested in, but a multi-byte buffer might be a lot of circuit to add. Auto detecting the baud rate is an interesting challenge, not sure I'd want to do it in hardware on a breadboard though.
I really like your videos, thank you and keep them coming! :)
Thanks Benjamin! It's good to get feedback!
My idea to enable/disable the osc directly doesn't work, of the three I oscillators I`ve tested one ignored the enable signal completely, two started whenever they wanted and because controlling the counter gives the same result there's really no point.
Another question was how to make the baud rate variable... Still don't get why someone would want to slow the whole thing down but a mux should solve that problem.
Since it's very probable that the only thing getting connected to the board is goint to be some kind of converter I woul'd ignore "standard" baud rates and go for the absolute maximum possible.
Shame that didn't work, I've noticed how the enable like on the crystal oscillators can be hit and miss. I held of for a day before replying to your message for what may now be an obvious reason, to implement a programmatic baud rate control what you need is to add a clock divider into the circuit, just like the one in my latest cpu video (ruclips.net/video/jlCBTwww4QI/видео.html). Only instead of dip switches you would take the preset value from a latch chip that you can load with the require denominator.
I don’t understand the issue whose solution requires the additional 193 that is held in reset until the start bit arrives.
Holding the counter in reset until the falling edge of the start bit gives us a clock synchronised with the senders clock.
Thanks. I’ve thought about it some more and realized a couple of things.
First, that using the clock signal of the crystal gives a 16x finer resolution than does the 1st 193, and that this enables starting the counter on the 2nd 193 very quickly after the start bit, as a clock edge is available sooner. Second, that in the setup without the 2nd 193, there is a phase shift of the start bit wrt the 1st 193 clock due to propagation delays. What I still don’t understand is why that delay varies from key press to key press.
Great video - really enjoyed watching!!
What would happen if you started receiving just as Tx was toggling between data bits, and confused this as the start bit? Is there a way around this or are you just assuming you always start Rx with a "clean" start bit?
Thanks Richard. Not 100% sure I understand what you are asking, I'm wondering if you think the tx/rx pair at each end are connected together? The TX on the remote end connect to the local RX and vise-versa. There shouldn't be any cross talk between them.
@@weirdboyjim Thanks for the reply. Say you are constantly transmitting data and then start receiving at a random point in time. There's no guarantee that the first falling edge the receiver "sees" is the start bit (could be the falling edge of a data bit, say). So I suppose i'm wondering how synchronisation to the start bit is always guaranteed. If that makes sense?
@@stencilgraffitiapp the first character would be garbled, but as soon as there was a "gap" in the incoming data, longer than a true character, it would automatically resynchronize. True UART hardware would notice an incorrect stop bit polarity and generate a framing error.
ahhhh 74LS00 and a 74L73? Dual JK Flip flop were my first two chips as a child... Good times. nice tricks on this
Thanks!
@@weirdboyjim not a worry, gonna order one of these. Too much fun to not have one hanging around
Nice solution! 👌
Thank you! Cheers!
Nice! I imagine hardware flow control would be useful for the receive side at least, 115200 is not slow for this type of tech :) That seems fairly simple though
Thanks Frank! There are a few options for flow control, but I'm worried I might be digging myself a hole with the amount of circuit to build on top of what I have.
Fifo UART maybe nice to add as well if it wasn't suggested .
@@Clearwater420 it would be great. How complex do you want it to get? ;)
Just finished binge watching almost 100 videos about your cpu🤪
But here is my first question: could you use the original 1.8MHz clock to "oversample" for the start bit and use that to reset the divide by 16 counter for alignment?
That's pretty much what the circuit does, I hold the counter (one running at the 1.8mhz) in reset until until the start bit comes in. Sorry if it wasn't clear.
Do you have that stdafx.h file header somewhere?
The test code here was throwaway. stdafx.h is a header file created by the automatic project creation code in visual studio. There wouldn't have been much in it though, so post on discord and we'll get you working.
Nice work. ;)
Thanks Ash! I appreciate the support!
You're a wizard!
Thanks Dennis. In the Harry Potter books wizards can't use technology "Because magic interferes with technology", now you've told me I'm a wizard do I get to use that as an excuse when my stuff doesn't work?
@@weirdboyjim whatever works for you James! I'm sure you don't often need that excuse tough! PS thanks for all the great content. You're on top of a dozen channels I look out for new videos and I'm never disappointed. If only you knew how much I've learned from you! ✌️🤯
do you have circuit
You can find design files for the completed modules on my Easyeda profile: oshwlab.com/weirdboyjim?tab=project&page=1
In real world situation the receiver has its own clock. There is no clock line specified in UART.
I think you have misunderstood what my circuit is doing, the transmit and receive circuits share a clock source but there is no clock connection from the remote transmitter to the local receive, or the local transmitter to the remote receive circuit. The transmit and receive circuits shown here are not talking to each other, they form the two halves of a UART and share some circuitry.
@@weirdboyjim I see. First I didn't notice you've added separate clock divider for the receiver. I recommend using 74HC595 instead of 164 and separate register.
@@FilipMilerX Other people have suggested the 595 but I explicitly wanted to separate the functionality in this version. Hopefully it's clear to the viewer that the latch functionality is necessary. You could get an entire UART on one Chip fairly early, the point of this series is to look at the internal workings, not the easiest way to do it.
Hello. I've always had a doubt about serial lines.
Lets say we are receiving a long stream of bytes. Our circuit gets the first low, takes it as start than counts to 10.
What happens if i conect the line at the middle of some random byte?
The first 0 bit in that byte would be mistaken by a start and that count would never be synched.
How can i avoid this?