@@lucasrem Well I doubt your assertion that young people don't understand RS 232. Probably some just learned about it by watching this video. And luckily so, because "nobody needs crap" is just wrong. RS-232 is still widely in use. For example for serial consoles in servers or appliances, or just hobbyists toying with microcontrollers. But if you prefer to not know anything, nobody forced you to watch this video.
Leaving in the bit with the error made this video so much more interesting rather than skipping over it and doing it all correctly, I feel like I learned a lot more about how the system functions than if it had be a straight shot to it functioning properly
Seriously, I've been using RS232 my entire life and I figure I knew more or less how it worked, but your video just raised my understanding of it to a whole new level. Thank you for this.
It's amazing. Even on microcontrollers, we've gotten used to writing UART.init(9600, 8, None, 1) and having the hardware take care of the timing. How does it work? It works just fine, thanks for asking.
I've always known "9600, eight, none, one" as the mantra to make things work without knowing *what* each thing was for so I, too, have enjoyed this video.
@@phyphor these days, 115200 is pretty common, though not absolute 9600 always seemed to run in that happy, Bob Ross range, from really old dayz when the processors couldn't handle it, quite, to the modern times, 96-- doesn't seem to want to die
Same here. I'm a grey beard who started programming in 1976 (more than four decades ago) and one of my first college classes was programming a Motorola 6800 computer in assembly language much like this series of videos. I'm fairly certain I had to write similar code for that course but thank dog those days are long past.
Ben is one of the best teachers i have ever seen on the topics of computer and hardware engineering. He always starts by explaining fundamentals at the perfect pace and builds the complexity step by step. I have both BSc and MSc EE degrees and i still wait for his videos to learn something new every time. Ben, you deserve to lead your own hardware engineering lab in one of the top universities. Keep making more fantastic content, people are waiting for this.
Shaby Barel therapy you need? understand bidirectional serial communication ? Webb, who need to understand it here, or is this just nerdy entertainment ? To lazy to be willing to understand it, eyeballing and wonder.....
@@lucasrem I wonder who needs therapy? Why are you watching and derogatory commenting things yourself are "fully" understanding? It it just to drop BS comments because you got 63 subscribers and Ben got 1 Million? Ben brings an extraordinary educational value to the whole world - Do you?
Agreed. Peoole forget that it was a synchronous motor with a wiper that would engage a clutch to make the wiper rotate around a plate with pads on it. The start bit would engage the clutch and begin the rotor spinning that was in sync with the line voltage. Each bit would land on a pad and either current or no current on a 20ma current loop line (remember those days?) The stop bit would release the clutch and the char. Would be printed. Ever wonder why you HAD to send a carriage return BEFORE the line feed character? Its because the print drum would be traveling back to the beginning of the line WHILE the platen advanced with the LF character which would arrive DURING the CR. I still have a ASR-33 with repair manuals & spare parts. Amazing mechanical device!!
@@michaeldavison9808 back in 1983 I was doing lots of RS232, SLDC, BISYNC. I still have my breakout boxes and protocol analyzers. That came in handy for BISYNC & SDLC
My first job (late 70's) was at a company that sold printers based on the Teletype Model 40. My first experience with RS-232 was with the EIA/current loop interface on the Model 40. Teletype built great hardware.
You're alive! I'm so happy, not only that you're alive, but that you're continuing this series. It's one of the best computer science series on UA-cam, and I come away from each video both more educated and more fascinated than I started. Thank you, Ben, for all you do! Seeing you do all the summation to create a delay makes me glad for higher-level modern functions like usleep() 😁
I think the I/O interface he uses actually has programmable timers, it's just easier for such a small example to make a little loop. In a more real application, you'd probably set up proper interrupts so you can do other stuff while the data is coming in.
seeing the 'funny meme username' from that years-old Computerphile AI generated comments video in the replies here gives me a warm fuzzy feeling .. this little community of tech-y people is a bit smaller than I thought
On a previous spawn of my ethereal soul, I was the sysop of a self-owned amateur BBS. Dial-up, using modems over the PSTN kind of stuff, and the link between the computer and the modem was through an RS-232 connection, so I knew the protocol pretty well for my daily usage. Nonetheless, your description of the RS-232 protocol is by far the clearest and cleanest I've seen. Being a computer programmer, I've always wondered how it could work well without an explicit clock signal, even if both sides agreed on the baud rate, stop bits and parity. I admit, I never actually needed to explore it, but you cleared up that issue for me after nearly 35 years. 😁 Thank you!!!
It's so very satisfying to see all that work translate into actual text transmission and show on the screen! Reminds me why I started to learn programming 15 or so years ago, and really has me wanting to do more work with physical parts like this again. I really love this channel
Nothing changed the last 15 years, we still use the same code here as in 2005, not needing to update the systems. non secure bidirectional communications, the old days was crap! anyone can get in !
@@lucasrem What do you mean "same code as 2005 here"? Ben just wrote his assembly code in 2022 for this educational example, not to deploy a control interface for a nuclear reactor. This has nothing to do with whether people update outdated insecure infrastructure or not. But if you're really concerned about someone hooking up a listening device to your serial cable, you can always send encrypted data. That is a question of whatever "protocol" you make up in software on top of your serial communication, not a question of how old your physical transport layer is. USB, Thunderbold, Ethernet or whatever you think is not "old days crap" is by itself "non secure bidirectional communication" as well.
Great to have you back, Ben. I used to use RS-232 all the time in the 80s and 90s but I never needed to learn it at this level; so this was fascinating for me. Looking forward to the next ep.
The negative voltage requirement of RS-232 is why some ATX power supplies still provide a negative voltage reference on one of the pins. The power supply manufacturers want to provide it in case the end user has a motherboard that uses on board RS-232 (some industrial motherboards still use it). usually the available current for the negative voltage reference is pretty small though (around 1 amp or less).
@@stevedonkers9087 +12v capable of less than 10 amps is pretty common on older power supplies before the 24-pin connector. Even my old P4 system with the 4-pin CPU connector only does 8.5 amps.
@@petevenuti7355 USB to RS232 adapters use a chip like the MAX232. This chip uses a charge pump to create positive and negative from a single 5 volt input. It only generates around +-7 volts instead of the 12 volts RS232 devices are supposed to output but it still works fine with most devices.
Great video as usual Ben. It took me back to my days as a data communications technician. When you talk about the clock pins not being widely used, remember that RS232 supports two different modes of operation. Asynchronous communication works as you described and was commonly used with terminals and printers. Synchronous mode used the clock signal and was more efficient because it didn't need a start and stop bit for every character. Synchronous mode was commonly used on higher speed lines which used multiplexers, data concentrators or protocol converters. For example X.25 packet switched data links or SDLC communications to an IBM mainframe used synchronous mode, and the modem would supply a clock signal.
@@lucasrem Heh, yeah maybe sentimental reasons 😄. I always enjoy Bens explanations of things I'm not too familiar with. I thought it would be interesting to see his take on a topic I was familiar with.
In the Subsea sector, RS 232 and 485 are still relevant on ROVs. They work very well in high noise environments (shielding can only go so far with multiple 3000V AC motors in close proximity). The systems are usually 3 pin...
They're relevant for almost anything industrial. Lots of things like Modbus (used to control basically anything industrial, including probably your buildings AC) run over RS 485.
Who besides me fast forwarded through the clock cycles explanation? Except for that, I loved the video. I learned a lot more about RS-232 than I ever thought I'd know. My first computer was a Commodore-64. The video connector was poor at best (TV) so I bought an RS-232 adapter and connected surplus DEC writer I purchased from work (with free box of fan-fold paper). I wrote a simple BASIC program for my kids. They loved "talking" to the computer and answering its questions. Later, I worked with nothing but RS-232 links to all 66 of our PDP-11 minicomputers at work. I never knew more than the basic pins for the individual signals so this video was a real education.
Had to do a lab in college using a similar architecture to create a musical tuner. So had to precisely measure freq, ex: 440hz. Your clock cycle counting and nop to balance both sides of a branch brought a smile to my face. Someday I'll go back to playing with those types of things again.
Whaaaattt!!! He's alive! Sooo good to see you back! Literally trawled the web occasionally for mention of your name in the hope to hear you were ok. Delighted to see a video! 💪👏👏👏
Holy crap. I thought the rona got him. Glad to know you're still alive man. Thank you for coming back and uploading the content we all love- My kit's been sitting on the shelf gathering dust ; ;
While admittedly less used on consumer grade equipment, the full 25 pin connector was certainly popular for network equipment in the 1990s and 2000s. Routers w synchronous serial connections would come off as DB25, and connect to CSU/DSUs that would then connect to 64K or T1 circuits to go over a WAN. Often to a remote office or ISP. The flow control signals aren't optional or unused, quite the contrary, they were essential to a proper setup. Console ports are much simpler, but the full interface was used regularly for certain applications.
This brings back memories of conference calls with network vendor support while on-site with a telco rep, trying to figure out why the *insert nsfw-language here* circuit wouldn't come up.
And well before the 1990's too. Clock speeds in the 70's were not sufficiently reliable to allow asynchronous transmission at anything above about 300 bits/s (and 75 bits/s reverse). That was enough for a teletype console and keyboard since that was considered faster than the teletype could print or anyone could type, but for serious communication speeds synchronous comms was a requirement. I never saw any equipment that used the secondary channels though.
@@chrishartley1210 fascinating! I've never heard of slower than 300 baud before, but esp if flow control was optional on those devices it would make sense. At 7-10 characters per second were those teletype physical printers?
@@loudej There were a lot of different styles of teleprinter, Teletype was probably the most successful and was a division of AT&T. 10cps was typical so they were slow and quite noisy, but they were a fraction of the cost of the early video terminals. I remember using one of the early graphics terminals (a Tektronix 4010 if I remember correctly) around 1974. The university only had one, it probably cost a small fortune but paper costs for the Teletype 33 terminals would not have been insignificant.
I used these cables for years when I was a kid and all those config options (bauds? parity?) were just magic numbers. It's amazing to finally understand what they mean and how the protocol works. Thank you very much!
This is a gift from god! I've just received my first RS-232 to USB connector that I'll be using in my physics laboratory project with the oscilloscope. Reading data from fiber optics, testing attenuation and error/data loss effects and eventually getting to single photon polarization to experiment with quantum key distribution. I've been mulling over tons of ooollldd documentation for programming to the oscilloscope through the connector and I've been wondering about the specifics of the connector. And here it is!! Imagine my surprise when literally the day I receive the connector, I also receive the best comprehensive overview of the standard I could ask for. As well, I'd never understood what exactly the "clock rate" was for, while you've explained it beautifully Your timing is impeccable and your information, invaluable. Thanks a million mate :)
This is suuuuper cool! Just 7 videos ago, we were all in 1952 in ENIAC era on breadboards... Now, were all at 1992 Basic Instinct era !! Thanks Ben eater, you have inspired my own breadboard project, which is an FPGA programed by an Arduino nano and Dc-4017 made out of 555 timers, the cheapest IC I could get that works on Digikey !! Since my family doesn't have much, As of now it's got 7 555's on a double bread-board in fully functioning gate array mode and building up strong!
You show every step of your Process in detail. I fully understand what you are doing and why you are doing it. It still is magical and impressiv when it just works. You are great!
I use RS232 nearly everyday at work and was very interesting learning more about how it works. For debugging I found a USB-C to RS232 converter so I can use my phone for a terminal rather than using a laptop. Saves so much time.
I have to say again how much I appreciate the way you explain these things. It really works for me. I’ve been using RS232 for years, console access to various networking devices, and now I understand it on a completely different level!
As a service tech, i use RS233 for 20 years and ongoing. It is still very much used in industrial PC’s and PLC’s today. Finally i understand why i always have to set baudrate equal for transmitter/receiver!
Glad to see you back making videos. As someone who works troubleshooting both old and new tech, your videos have helped me gain a huge insight into how things work. We infact still put RS232 on new products we make for backwards compatibility with older equipment.
@@ohasis8331 I don't know what that means, but we used to make up random words for those standards when we were kids. And the sillier the better. My favorite one was RS 232 which I thought stood for robot servicing. I even went to school later for networking, and that never came up.
@@BlackHoleForge Robinson Crusoe from classic literature, lost on a deserted island, means all on your own, by yourself, the only one etc. though from ancient memory, he may have had a manservant at some time. Or maybe I am mixing stories but you should get the drift :)
I started as a tech overhauling Teletype machines over 50 years ago. Back in those days, a lot of companies didn't pay strict attention to the "standard". Also, you will see the clock signals used with synchronous devices. I used to come across it with basic rate ISDN. Even back when I started in telecom, there were synchronous modems that used the clock signal. Also, there were 2 stop bits at 110B and 1 bit at faster speeds. Then there was the Baudot code, where a stop bit was usually 1.42 bits long, though with UARTs 1.5 was used. BTW, many years ago, I designed and built an 8 port serial card (3 ports populated) for my IMSAI 8080 computer. It used the 8250 UART. I wrote all the software for it in 8080 assembler code, including a terminal app for use with amateur radio. I could send & receive in both Baudot and ASCII, as well as printing to my M35 ASR teletype and many other functions with it. Back in those days you knew your computer inside and out!
haven't watched it yet, just got the notification for the new video. so anxious to go home and watch. we're so lucky to have you on youtube ben eater! you're the best teacher!
To echo the sentiments of others, this was a wonderful video. I've used RS-232 my whole life (I wired up my first null modem when I was about 13 or 14), but this video helped me to see it at a deeper level. There is no substitute for visualizing the data on the Scope - the start/stop/parity bits become instantly clear. The mark/space reference finally makes sense too! I'm excited to see how this evolves; that little read/timing loop works just fine, but I bet there is a better way coming. I know they take a ton of work, but please keep making these most excellent vids! Cheers!
I had a lab in community college where we scoped out RS-232 protocol, bit-banging the UART with ASM. We didn't have digital storage oscilloscopes and as such we wrote a simple program to repeatedly send a single character. When the PC was on Windows 98 the timing was all over the place, much more stable when booted to plain DOS.
Man, what a great breakdown of serial.. I honestly always wanted to know what the stop bit/parity etc meant since I was a kid. Seeing it like this makes it seem so simple!
I just dropped out of my classic mechanics course (first step in the 4 levels of physics required for a CS/CE bachelor's) and you've given me a lot of inspiration to keep going... this was so engaging, and I was able to follow all of it - even being someone who never took high school physics and have not gotten past my first level of physics or calc 2. This is lovely. Thank you so much.
Ben you are a genius! Seriously, I love your videos they are very informative and I am learning a lot. I think we are all happy when a new video from you comes online 👍
I recently started using MODbus and RS485 for my job and the first thing I did was check your channel for a video since yours have been the easiest to digest. Great work!
In RS232 there are 10 bits sent 1 START bit followed by 8 data bits and a stop bit so ten bits also there can be one or two parity bits sent before the stop bit. Also there can be seven data bits and one parity bits. So the maximum number of bits sent before resyncing the data is eleven or possibly twelve then when the next start bit is sent the clock is resynched. The start bit is longer than a regular data bit that is why in some devices the receiving device can calculate the baud rate just from timing the start bit and set its own baud rate from that.
Interesting video. Thanks for posting it. For the IBM PC there was a LAN that used the 25-pin RS-232 connectors joined in a ring configuration. The LAN did not require a network card only a 25-pin serial port on each machine. Zero-slot LANs were fairly popular until affordable Ethernet cards became available.
@@Chris-ib8lw Token Ring was IBM's system with real expensive cards connected using heavy coaxial cable we called "frozen yellow garden hose". It used an expansion slot. All I recall was there was a zero slot LAN for up to seven workstations that used a 25-pin RS-232 connector for each machine. For each connector there was one cable connected to one transmit and receive pair of pins and another cable to the other pair. One cable went back to the previous machine and the the other went on to the next machine. A small TSR (Terminate and Stay Resident) program in each station would receive each packet and use it or forward it to the next machine. I do not remember anything else because I never worked on any zero-slot LANs. They were quite slow at 115 Kbaud, or so, and were only used for tiny networks.
@@ivarnordlkken8082 I had began my work on IBM unit record equipment like the 407 using plugboard wiring then the IBM 1401 and then the IBM 360/30 ans on up. I played with the Intel 4004, and found it to be a toy. I built my own processor built around 7400 chips that mimicked the IBM mainframe instruction set. When the 8080 came out, I used it for an S-100 bus microcomputer. Coming from a mainframe environment, I found the instruction set to be VERY limiting. And could not grasp a SP register, as mainframes don't use that. I wrote major applications in assembly lang on mainframes with only 48k of memory. I was always amazed on what i can do with such limited memory. I would watch a tape sort on a mainframe (which was way faster than using disk) and was in awe. After it read alp the input data, it would print out how many passes of the data it would have to make before final output. You could even tell it which tape drive you wanted the output on even though it used that drive as a work drive! The instruction set was VERY powerful in mainframes and I missed that when I wrote for the Intel platform. For example I could clear 16meg of memory with just ONE instruction. Also the absence of 16 general purpose registers boggled my mind! Who would design such a limited processor! To me, the processors in a PC will always be a toy. They never matured. I now code on TI processors like the MSP430 and PIC type decixes8
This reminds me of my days doing assembly programming on a PIC16F84. I had implemented a bit-bang UART driver that drives an rs232 interface. Also a 232 interface using a simplified ttl level voltages is prevalent in embedded programming for debug purposes
I also used the PIC16F84. The program memory was so small that I had to write a single bit bang routine to handle rs232, i2c and rs485 for an amusement arcade machine monitoring system, I remember using an interrupt pin for the rx line, causing the start bit to trigger an ISR . Now we have atmega328 its a different world. LOL.
Its amazing that engineers could design a 25 pin interface to carry serial data between DTE and DCE. Even when they reduced it to a 9 pin connector, only 4 pins were actually used. I loved the programming example in the video. It was great to go from the example that printed an "X" when something arrived to actually printing the ASCII characters. Great video.
It was nice to see you address the rising edge/falling edge timing. It's wonderful when you don't have enough ICs to be concerned with fan-out and de-bounce. Would love to see a follow up on flow control or half vs full duplex.
I love the fact that he took the time to put on a Patreon t-shirt for the outo, you can barely see it in the reflection of the terminal! Fantastic video as always!
Nice tight loop, gone are the days (at least in PCs) that you have a known fixed clock rate and execution time, but so awesome to see that in action! Have you ever thought about getting a ZIF socket adapter for that EEPROM on the breadboard? I always get so nervous watching you pry out and insert the chip with all those wires around it! :) Fantastic video as always!
@@WolfePaws PIC and AVR have ICSP (In-circuit serial programming) where you just leave a pin header attached to the programming lines on the chip. A cable connects from your programmer to the header and you can program whenever you want without having to move the chip.
@@richardbanks2669 Very good point. The ZIF sockets I have do have very stubby leads too and I don't recall ever trying to put them on a breadboard. Though I think the reason he doesn't is just because of the way he explains things so clearly and non-distracting way, like only using what you actually need to do this. Just like he shows the assembly and EEPROM writing steps each time, so it's absolutely clear what is happening.
RS-232 signals are defined as referred to the DTE. When you mentioned this simple fact, often missed by even experienced people, you earned a thumbs up.
Excellent tutorial, I don't think many people programming today would get, or appreciate counting CPU cycles... but that is how we had to do it back in the day! Even at UBICOM in the year 2000 their microcontroller would read the ethernet traffic in the ISR it did cycle counting... It was a Hard real time requirement, and the branching through had to balance in time regardless of the data received. Next when you get to the UART part of your tutorial, when I wrote my Master's thesis in Computer Science I did a study on Real-Time communications and used RS-232 and did the deep dive into that protocol and the whole architecture of the IBM's UART, PIC Controller, and learned just how flawed that was... I figured out the hardware bugs, I think 5 to 7 gotchas that did things like: prevent Full-Duplex ISR driven TX/RX, what the source of those mysterious callbacks when the line was enabled or disabled, instruction overlap in the x386 and the I/O instructions, etc. Back in the early 90's I researched this deeply, and I never saw printed in a book!
Great video! Few improvements that could be possible: 1. Use a conditional jump subroutine to get a 3 cycle delay instead of 2 NOPs for 4 cycle delay, to allow getting the more exact 104us delay 2. Half bit time routine wasn't exactly half a bit time. Would be closer to 69-70us when half bit time is 52us. But not super important here. 3. Could be cool to parameterize your delay subroutine so you have the same sub routine for 1 cycle and half cycle, but that's just for overachieving:)
He is just doing bitwise ttl receive for this video ? I think it will fail when he has a longer cable .. more capacitance... he will show you then show how a UART handles it still.
Great tutorial on RS232 ! Btw you could simplify a couple of things in your code. Use Y index register for delay countdown instead of X to avoid the phx plx. Also reuse same delay routine by setting Y to either #13 or #6 before calling the wait routine depending if you want to wait a full bit or a half bit. Btw, an interesting thing about the Commodore 64 was that they never did a real RS232 implementation as part of the hardware but delegated that to the CPU so the machine actually had to this identical bit fiddling to transfer or receive a byte. However they did make use of a timer triggering a NMI (non maskable interrupt) so that the read bit was done quickly and a return from interrupt passed control back to the program running. However, the max speed you could use was 2400 baud with this method, and even then they messed up the timing table for PAL computers so it is in fact broken on all machines made! However, one could code this yourself and get as high as 9600 baud like you do here on your 6502, but then have no time to do other stuff while you were sending or receiving. A hack was done to enable this though by simulating a clock signal to trigger an interrupt as all transfers always started with a 1 but required a hardware hack for the receive signal.
I took several classes that covered serial protocols in college, and I'm ashamed by how much I didn't understand until watching this video. Awesome resource, thank you for making this
The clock pins were commonly used and are required for synchronous modem connections, typically used on private wire circuits. In the days before the internet this was how you interconnected branch sites, originally with a copper circuit patched through the local exchanges between sites.
But as it turned out, switching to asynchrous meant it worked on longer cables , noisier environments.. noise on the clock signal would send it haywire... the async UART works with about 5 samples of the received bit.. See, sometimes the circuit would be a bit assymetric (eg for mark vs space) and so the timing of the signal coming through would be a bit skewed.. as the main problem with a long cable is capacitance, the charging of it takes a bit of time.. if the circuits are not perfectly symmetrical, the timing of the pulse is not symmetrical (between mark and space.)
Hey! If you are curious what the clock pins are used for, in some applications (I work in optical sensors) you need to have very precise timing associated with each data packet. The Clock and Ref_clock pins can be used to connect a very precise oscillator (at 1 kHz for example) to the device you are getting data from. This is helpful if you need to integrate the results you get (and thus need exactly defined dt.) This is an alternative to a synchronous serial interface, which comes with it's own problems. It is very nice to be able to use an asynchronous interface with precise intervals defined for specific data packets. to get a little weedier, what matters more than the time a packet is sent/recieved is the time a packet was GENERATED. this often involves numerical calculations (in an FPGA for instance) where you need to know exactly when the communication RTL logic is "sampling" a normalizer or shift register for instance.
i used to be so patient and diligent in doing stuff like these. now, my attention got diluted by so much stuff. I'm glad to see videos like this. I could at least feel the excitement without needing to commit to another project 🤣
I was only looking at my 6502 build a couple of weeks ago and thinking that I needed to figure out how to get it hooked up to a terminal, so the return of your series is very timely!!!!
"A while ago I built this breadboard computer..." This is like your father who went out to get milk, but he is back after 23 years with a carton of milk in his hand, asking why the breakfast isn't ready yet.
Once again a great video. On something I have been using for 25+ years and thought I knew a fair bit about. You have provided more useful information. Thanks.
This video made this day so much better! You're a great teacher, and I enjoy your videos, and learn so much even though I know I would likely never be this capable, but brings a smile to know that at least I understand how things work. I always had those questions as a kid and it feels good to finally 'get it'. All the support :)
On the level converter: many transistors have a base-emitter breakdown voltage smaller than the rs232 mark voltage. If you don't exceed the reverse breakdown power for this junction the circuit will continue to work fine for awhile, but the transistor's beta will gradually degrade and the circuit will eventually fail. A series diode on the base (cathode to base) or a shunt diode from base to ground (cathode to base) would fix this. BTW the reverse breakdown base-emitter maximum power is never specified, because the manufacturer doesn't want you to run the transistor in that mode. They specify the b-e reverse breakdown voltage so you know what not to do. One other point: half of 13 isn't 6. I won't tell anyone if you don't :-) Finally: I love your coding and explanations, they're crystal clear! Your whole approach is a pleasure to watch. Thanks!!
I have worked with synchronous RS-232, in which the clock pins were in use. The assumption is that the clocks gate the signal from a buffer where the bit is held until the clock releases it. Interesting thing is that normally the clocks, both send and receive, always originate from the data communications equipment. This is because the communications networks way back when were multiplexing multiple signals from a centralized clock (old-style Time-Division Multiplexing [TDM]). That means your bits better be ready to go when the clock says go. The much more common asynchronous signalling is left to adjust timing through a network by allowing for buffering to satisfy the strict timing requirement of the network.
It has bee. A while since i wrote assembler and it was mostly Z80 and 8051 code. But i have done 6502 a very long time ago on the VIC 20 and the C64...lol it was a joy watching someone else coding in assemler! Great Video.
Okay, I have to let it out. I missed your videos so much that I started looking for another places where you might have had been doing... anything 😂 Also made sure that there is no rumours anywhere saying that something bad happened. I was thrilled to discover the Ben Ben and Blue podcast, oh, that was a great listen! The 'origins of Ben Eater' are so inspiring. I love your story and keep learning so much from your videos. I'm glad they're back 😀 Actually I'm using a lot of industrial RS-232 speaking devices (barcode scanners, measuring equipment) at work and still learned new things from this video 😀
Great Ben thanks to have you are back after this "pandemic" period. Wish I could have learned all this from you in my early days. Best Regards from Hans in the Netherlands.
I'm so glad the Bob Ross of Computer Engineering is back.
Perfect description
Second that
It’s taken this long because he’s been uploading the video with a serial port, one byte at a time
Same. :D
"there's nothing wrong with having a port as a friend"
...officer.
I just wrote a bunch of 6502 serial code for our "C64 Spectrum Analyzer" video and I still learned stuff from this :-)
Dave, your videos are great. Really nice to see you watching and appreciating Ben’s videos.
Thank you for coming back sir, it really means a lot for us your viewers. 🙏
RS 232, nobody needs crap, old people understand it, noobs need it too ?????
@@lucasrem
Rest assured, people like you don't need RS232.
Go back to Minecraft.
@@lucasrem Well I doubt your assertion that young people don't understand RS 232. Probably some just learned about it by watching this video. And luckily so, because "nobody needs crap" is just wrong. RS-232 is still widely in use. For example for serial consoles in servers or appliances, or just hobbyists toying with microcontrollers. But if you prefer to not know anything, nobody forced you to watch this video.
Leaving in the bit with the error made this video so much more interesting rather than skipping over it and doing it all correctly, I feel like I learned a lot more about how the system functions than if it had be a straight shot to it functioning properly
Seriously, I've been using RS232 my entire life and I figure I knew more or less how it worked, but your video just raised my understanding of it to a whole new level. Thank you for this.
It's amazing. Even on microcontrollers, we've gotten used to writing UART.init(9600, 8, None, 1) and having the hardware take care of the timing.
How does it work? It works just fine, thanks for asking.
Can't think of a good reply, something about protogens?
I've always known "9600, eight, none, one" as the mantra to make things work without knowing *what* each thing was for so I, too, have enjoyed this video.
@@phyphor these days, 115200 is pretty common, though not absolute
9600 always seemed to run in that happy, Bob Ross range, from really old dayz when the processors couldn't handle it, quite, to the modern times, 96-- doesn't seem to want to die
Same here. I'm a grey beard who started programming in 1976 (more than four decades ago) and one of my first college classes was programming a Motorola 6800 computer in assembly language much like this series of videos. I'm fairly certain I had to write similar code for that course but thank dog those days are long past.
Ben is one of the best teachers i have ever seen on the topics of computer and hardware engineering. He always starts by explaining fundamentals at the perfect pace and builds the complexity step by step. I have both BSc and MSc EE degrees and i still wait for his videos to learn something new every time. Ben, you deserve to lead your own hardware engineering lab in one of the top universities. Keep making more fantastic content, people are waiting for this.
Shaby Barel
therapy you need?
understand bidirectional serial communication ?
Webb, who need to understand it here, or is this just nerdy entertainment ? To lazy to be willing to understand it, eyeballing and wonder.....
I agree.
@@lucasrem I wonder who needs therapy? Why are you watching and derogatory commenting things yourself are "fully" understanding? It it just to drop BS comments because you got 63 subscribers and Ben got 1 Million?
Ben brings an extraordinary educational value to the whole world - Do you?
As a former employee of Teletype Corporation, the description of the signal (mark, space, start, stop, bits, etc.) brought a smile.
Agreed. Peoole forget that it was a synchronous motor with a wiper that would engage a clutch to make the wiper rotate around a plate with pads on it. The start bit would engage the clutch and begin the rotor spinning that was in sync with the line voltage. Each bit would land on a pad and either current or no current on a 20ma current loop line (remember those days?) The stop bit would release the clutch and the char. Would be printed. Ever wonder why you HAD to send a carriage return BEFORE the line feed character? Its because the print drum would be traveling back to the beginning of the line WHILE the platen advanced with the LF character which would arrive DURING the CR.
I still have a ASR-33 with repair manuals & spare parts.
Amazing mechanical device!!
I also recognize them, because I use RTTY a lot(RadioTeleTypE)
Mark, space, start and stop, parity ..... the days when my 1983 Computer Science degree meant more than just 'software engineering'.
@@michaeldavison9808 back in 1983 I was doing lots of RS232, SLDC, BISYNC. I still have my breakout boxes and protocol analyzers. That came in handy for BISYNC & SDLC
My first job (late 70's) was at a company that sold printers based on the Teletype Model 40. My first experience with RS-232 was with the EIA/current loop interface on the Model 40. Teletype built great hardware.
You're alive! I'm so happy, not only that you're alive, but that you're continuing this series. It's one of the best computer science series on UA-cam, and I come away from each video both more educated and more fascinated than I started. Thank you, Ben, for all you do!
Seeing you do all the summation to create a delay makes me glad for higher-level modern functions like usleep() 😁
I think the I/O interface he uses actually has programmable timers, it's just easier for such a small example to make a little loop. In a more real application, you'd probably set up proper interrupts so you can do other stuff while the data is coming in.
im also glad hes alive
seeing the 'funny meme username' from that years-old Computerphile AI generated comments video in the replies here gives me a warm fuzzy feeling .. this little community of tech-y people is a bit smaller than I thought
@@TS6815 The world is a small place when we can all share ideas with each other :)
The serial port/parallel port was used for cars obd 2 for programming/complex Dtc record check for cars
Thank goodness you're back!! We've missed you and your incredible computer engineering videos. :)
On a previous spawn of my ethereal soul, I was the sysop of a self-owned amateur BBS. Dial-up, using modems over the PSTN kind of stuff, and the link between the computer and the modem was through an RS-232 connection, so I knew the protocol pretty well for my daily usage. Nonetheless, your description of the RS-232 protocol is by far the clearest and cleanest I've seen. Being a computer programmer, I've always wondered how it could work well without an explicit clock signal, even if both sides agreed on the baud rate, stop bits and parity. I admit, I never actually needed to explore it, but you cleared up that issue for me after nearly 35 years. 😁 Thank you!!!
Welcome back!
Wait, this video was uploaded 5 minutes back. How did you comment on it 2 hours prior??
@@briankimathi5033 prob patreon
It's so very satisfying to see all that work translate into actual text transmission and show on the screen! Reminds me why I started to learn programming 15 or so years ago, and really has me wanting to do more work with physical parts like this again. I really love this channel
Nothing changed the last 15 years, we still use the same code here as in 2005, not needing to update the systems.
non secure bidirectional communications, the old days was crap! anyone can get in !
@@lucasrem What do you mean "same code as 2005 here"? Ben just wrote his assembly code in 2022 for this educational example, not to deploy a control interface for a nuclear reactor. This has nothing to do with whether people update outdated insecure infrastructure or not.
But if you're really concerned about someone hooking up a listening device to your serial cable, you can always send encrypted data. That is a question of whatever "protocol" you make up in software on top of your serial communication, not a question of how old your physical transport layer is. USB, Thunderbold, Ethernet or whatever you think is not "old days crap" is by itself "non secure bidirectional communication" as well.
We've missed you Ben! Glad to have you back!
The Spambots are also back. 😅
@@marcel151 Of course - it wouldn't be UA-cam without SpamBots!
@@marcel151 Just keep reporting them, yt gets something done when they get flooded with reports.
Great to have you back, Ben. I used to use RS-232 all the time in the 80s and 90s but I never needed to learn it at this level; so this was fascinating for me. Looking forward to the next ep.
The negative voltage requirement of RS-232 is why some ATX power supplies still provide a negative voltage reference on one of the pins. The power supply manufacturers want to provide it in case the end user has a motherboard that uses on board RS-232 (some industrial motherboards still use it). usually the available current for the negative voltage reference is pretty small though (around 1 amp or less).
Yes, most of the power supplies I have seen have -12v at around 300 milliamps. For a comparison I don't think I've seen a +12v rail lower than 10amps.
@@stevedonkers9087 +12v capable of less than 10 amps is pretty common on older power supplies before the 24-pin connector. Even my old P4 system with the 4-pin CPU connector only does 8.5 amps.
Is this why USB to rs232 adapters don't work?
@@petevenuti7355 USB to RS232 adapters use a chip like the MAX232. This chip uses a charge pump to create positive and negative from a single 5 volt input. It only generates around +-7 volts instead of the 12 volts RS232 devices are supposed to output but it still works fine with most devices.
Some old sound cards used it too, for proper op-amp IO without DC offset. Old BIOS EPROMS also used the -5V IIRC
Great video as usual Ben. It took me back to my days as a data communications technician. When you talk about the clock pins not being widely used, remember that RS232 supports two different modes of operation. Asynchronous communication works as you described and was commonly used with terminals and printers. Synchronous mode used the clock signal and was more efficient because it didn't need a start and stop bit for every character. Synchronous mode was commonly used on higher speed lines which used multiplexers, data concentrators or protocol converters. For example X.25 packet switched data links or SDLC communications to an IBM mainframe used synchronous mode, and the modem would supply a clock signal.
What did you do in the market ?
sentimental reasons, why you watched it ?
@@lucasrem Heh, yeah maybe sentimental reasons 😄. I always enjoy Bens explanations of things I'm not too familiar with. I thought it would be interesting to see his take on a topic I was familiar with.
In the Subsea sector, RS 232 and 485 are still relevant on ROVs. They work very well in high noise environments (shielding can only go so far with multiple 3000V AC motors in close proximity). The systems are usually 3 pin...
They're relevant for almost anything industrial. Lots of things like Modbus (used to control basically anything industrial, including probably your buildings AC) run over RS 485.
Card access controllers talk to subpanels via 485.
Aircraft too!
With the NMEA standard? Because we use NMEA 0183 a lot with glider avionics.
@@johannesgaida3137 it depends on the simulation
Who besides me fast forwarded through the clock cycles explanation? Except for that, I loved the video. I learned a lot more about RS-232 than I ever thought I'd know. My first computer was a Commodore-64. The video connector was poor at best (TV) so I bought an RS-232 adapter and connected surplus DEC writer I purchased from work (with free box of fan-fold paper). I wrote a simple BASIC program for my kids. They loved "talking" to the computer and answering its questions. Later, I worked with nothing but RS-232 links to all 66 of our PDP-11 minicomputers at work. I never knew more than the basic pins for the individual signals so this video was a real education.
Thank god you're alive, I was worried. Great to see you back!
Very satisfying to watch.
i’ve beeen waiting for a new Ben Eater video😭😭❤️🔥 keep up the hard work Ben 💪🏽💪🏽
Had to do a lab in college using a similar architecture to create a musical tuner. So had to precisely measure freq, ex: 440hz. Your clock cycle counting and nop to balance both sides of a branch brought a smile to my face. Someday I'll go back to playing with those types of things again.
Great to see you again Ben 😍
Ever since I encountered my first DB25 RS-232 serial port back in the '80s, I have wondered about this... Just brilliant! ❤
Whaaaattt!!! He's alive! Sooo good to see you back! Literally trawled the web occasionally for mention of your name in the hope to hear you were ok. Delighted to see a video! 💪👏👏👏
Assembly programming interacting with hardware. Love it! More, please! Very well explained!
Holy crap. I thought the rona got him. Glad to know you're still alive man.
Thank you for coming back and uploading the content we all love- My kit's been sitting on the shelf gathering dust ; ;
The production quality of these vids is amazing, glad that you're back
just a home job, web cam, final cut skills !
your channel ? play games ...? need quality channel, stop playing !!!!
@@lucasrem huh?
While admittedly less used on consumer grade equipment, the full 25 pin connector was certainly popular for network equipment in the 1990s and 2000s. Routers w synchronous serial connections would come off as DB25, and connect to CSU/DSUs that would then connect to 64K or T1 circuits to go over a WAN. Often to a remote office or ISP. The flow control signals aren't optional or unused, quite the contrary, they were essential to a proper setup. Console ports are much simpler, but the full interface was used regularly for certain applications.
This brings back memories of conference calls with network vendor support while on-site with a telco rep, trying to figure out why the *insert nsfw-language here* circuit wouldn't come up.
And well before the 1990's too. Clock speeds in the 70's were not sufficiently reliable to allow asynchronous transmission at anything above about 300 bits/s (and 75 bits/s reverse). That was enough for a teletype console and keyboard since that was considered faster than the teletype could print or anyone could type, but for serious communication speeds synchronous comms was a requirement. I never saw any equipment that used the secondary channels though.
All my 80's retro gear uses 25 pin connectors too. I never really saw 9 pin connectors on anything except joysticks before the 90's!
@@chrishartley1210 fascinating! I've never heard of slower than 300 baud before, but esp if flow control was optional on those devices it would make sense.
At 7-10 characters per second were those teletype physical printers?
@@loudej There were a lot of different styles of teleprinter, Teletype was probably the most successful and was a division of AT&T.
10cps was typical so they were slow and quite noisy, but they were a fraction of the cost of the early video terminals.
I remember using one of the early graphics terminals (a Tektronix 4010 if I remember correctly) around 1974. The university only had one, it probably cost a small fortune but paper costs for the Teletype 33 terminals would not have been insignificant.
I used these cables for years when I was a kid and all those config options (bauds? parity?) were just magic numbers. It's amazing to finally understand what they mean and how the protocol works. Thank you very much!
Never knew RS stood for recommended standard. Those little knowledge nuggets just add value to these videos. Thanks!
This is a gift from god! I've just received my first RS-232 to USB connector that I'll be using in my physics laboratory project with the oscilloscope. Reading data from fiber optics, testing attenuation and error/data loss effects and eventually getting to single photon polarization to experiment with quantum key distribution. I've been mulling over tons of ooollldd documentation for programming to the oscilloscope through the connector and I've been wondering about the specifics of the connector. And here it is!! Imagine my surprise when literally the day I receive the connector, I also receive the best comprehensive overview of the standard I could ask for. As well, I'd never understood what exactly the "clock rate" was for, while you've explained it beautifully
Your timing is impeccable and your information, invaluable. Thanks a million mate :)
Thanks Ben. These videos have immense value to the world.
This is suuuuper cool! Just 7 videos ago, we were all in 1952 in ENIAC era on breadboards... Now, were all at 1992 Basic Instinct era !!
Thanks Ben eater, you have inspired my own breadboard project, which is an FPGA programed by an Arduino nano and Dc-4017 made out of 555 timers, the cheapest IC I could get that works on Digikey !! Since my family doesn't have much, As of now it's got 7 555's on a double bread-board in fully functioning gate array mode and building up strong!
I was just thinking how it had been a long time since is seen anything from you! Thank you for all your amazing content!
You show every step of your Process in detail. I fully understand what you are doing and why you are doing it. It still is magical and impressiv when it just works. You are great!
Bro you got to keep regular updates on the community tab because I was genuinely concerned for a while.
I use RS232 nearly everyday at work and was very interesting learning more about how it works. For debugging I found a USB-C to RS232 converter so I can use my phone for a terminal rather than using a laptop. Saves so much time.
the legend has returned
Didn't think I would find a serial port video so interesting. I always learn something from these wise guys on the tube.
Been waiting for this!
I have to say again how much I appreciate the way you explain these things. It really works for me.
I’ve been using RS232 for years, console access to various networking devices, and now I understand it on a completely different level!
So glad you're back as your videos are fantastic. I still think your series on building your own 8 bit computer Is one of the best on UA-cam.
As a service tech, i use RS233 for 20 years and ongoing. It is still very much used in industrial PC’s and PLC’s today. Finally i understand why i always have to set baudrate equal for transmitter/receiver!
You always do such a good job of explaining these concepts in a clear and understandable way. I feel like I understand this in a way I haven't before.
Glad to see you back making videos. As someone who works troubleshooting both old and new tech, your videos have helped me gain a huge insight into how things work. We infact still put RS232 on new products we make for backwards compatibility with older equipment.
I can't believe I went my whole life without realizing that RS stood for recommended standard.
You're not Robinson Crusoe.
@@ohasis8331 I don't know what that means, but we used to make up random words for those standards when we were kids. And the sillier the better. My favorite one was RS 232 which I thought stood for robot servicing. I even went to school later for networking, and that never came up.
@@BlackHoleForge Robinson Crusoe from classic literature, lost on a deserted island, means all on your own, by yourself, the only one etc. though from ancient memory, he may have had a manservant at some time. Or maybe I am mixing stories but you should get the drift :)
"The best time to learn something was 10 years ago, the next best time is now."
I remember hearing this somewhere, but can't remember where.
We have RS Components in the UK, and initially thought is must have been something related to them.
I started as a tech overhauling Teletype machines over 50 years ago. Back in those days, a lot of companies didn't pay strict attention to the "standard". Also, you will see the clock signals used with synchronous devices. I used to come across it with basic rate ISDN. Even back when I started in telecom, there were synchronous modems that used the clock signal. Also, there were 2 stop bits at 110B and 1 bit at faster speeds. Then there was the Baudot code, where a stop bit was usually 1.42 bits long, though with UARTs 1.5 was used.
BTW, many years ago, I designed and built an 8 port serial card (3 ports populated) for my IMSAI 8080 computer. It used the 8250 UART. I wrote all the software for it in 8080 assembler code, including a terminal app for use with amateur radio. I could send & receive in both Baudot and ASCII, as well as printing to my M35 ASR teletype and many other functions with it. Back in those days you knew your computer inside and out!
Fantastic to see a new video posted from you, sir! Thank you, as always, for educating me a bit more. It's always something interesting :)
So happy to see you're alive and well. We've missed you greatly.
haven't watched it yet, just got the notification for the new video. so anxious to go home and watch. we're so lucky to have you on youtube ben eater! you're the best teacher!
as always, it is a great pleasure to watch your tutorials. It is good to have you back in business
Incredible video quality and technical explanation! So glad you're back!
To echo the sentiments of others, this was a wonderful video. I've used RS-232 my whole life (I wired up my first null modem when I was about 13 or 14), but this video helped me to see it at a deeper level. There is no substitute for visualizing the data on the Scope - the start/stop/parity bits become instantly clear. The mark/space reference finally makes sense too! I'm excited to see how this evolves; that little read/timing loop works just fine, but I bet there is a better way coming. I know they take a ton of work, but please keep making these most excellent vids! Cheers!
I had a lab in community college where we scoped out RS-232 protocol, bit-banging the UART with ASM.
We didn't have digital storage oscilloscopes and as such we wrote a simple program to repeatedly send a single character. When the PC was on Windows 98 the timing was all over the place, much more stable when booted to plain DOS.
Man, what a great breakdown of serial.. I honestly always wanted to know what the stop bit/parity etc meant since I was a kid. Seeing it like this makes it seem so simple!
It’s been too long! Glad you’re back. Please don’t make us wait so long again
I just dropped out of my classic mechanics course (first step in the 4 levels of physics required for a CS/CE bachelor's) and you've given me a lot of inspiration to keep going... this was so engaging, and I was able to follow all of it - even being someone who never took high school physics and have not gotten past my first level of physics or calc 2. This is lovely. Thank you so much.
Welcome back Ben, great to see you making videos again.
Fanstastic !!! I am very glad that there is channel which is doing fundamentals so eloquently.
Ben you are a genius! Seriously, I love your videos they are very informative and I am learning a lot. I think we are all happy when a new video from you comes online 👍
One of the few channels I have the bell turned on for and stop whatever I’m doing when a new video comes out.
Thank you Ben 💞
This is so interesting. Out of my depth and you lost me at times but still fascinating. I've never seen bits on an oscilloscope like that!
If this interests you enough you can go back and watch his older videos and learn exactly what all of it means. This channel is amazing.
Just watch for RTS and CTS ... and cross over (DTE to DTE , or DCE to DCE ) connections.
@@chicken_punk_pie And it is well worth doing, you can do it at leisure rather than force it. I took months but got the whole lot.
I recently started using MODbus and RS485 for my job and the first thing I did was check your channel for a video since yours have been the easiest to digest. Great work!
In RS232 there are 10 bits sent 1 START bit followed by 8 data bits and a stop bit so ten bits also there can be one or two parity bits sent before the stop bit. Also there can be seven data bits and one parity bits. So the maximum number of bits sent before resyncing the data is eleven or possibly twelve then when the next start bit is sent the clock is resynched. The start bit is longer than a regular data bit that is why in some devices the receiving device can calculate the baud rate just from timing the start bit and set its own baud rate from that.
I use RS 232 on a daily basis at work communicating serially with various plc based systems that are 20 odd years old..
Great video as always
Hey glad to see you back man! Hope everything is alright with you. Great content as always.
I just love how at the end it was et voilá and it all worked as intended.
Interesting video. Thanks for posting it. For the IBM PC there was a LAN that used the 25-pin RS-232 connectors joined in a ring configuration. The LAN did not require a network card only a 25-pin serial port on each machine. Zero-slot LANs were fairly popular until affordable Ethernet cards became available.
These were the original token-ring protocol networks correct? I remember reading about this many, many years ago in a MCSE class I took.
@@Chris-ib8lw Token Ring was IBM's system with real expensive cards connected using heavy coaxial cable we called "frozen yellow garden hose". It used an expansion slot. All I recall was there was a zero slot LAN for up to seven workstations that used a 25-pin RS-232 connector for each machine. For each connector there was one cable connected to one transmit and receive pair of pins and another cable to the other pair. One cable went back to the previous machine and the the other went on to the next machine. A small TSR (Terminate and Stay Resident) program in each station would receive each packet and use it or forward it to the next machine. I do not remember anything else because I never worked on any zero-slot LANs. They were quite slow at 115 Kbaud, or so, and were only used for tiny networks.
What a teacher. I'm a 44 yo mechanic/welder and you have explained this perfectly. I fix stuff on the side or I should say "I try to fix ". Thank
Great video. Also great to see someone programming in assembly so fluidly!
Ive been programming in assembly for over 50 yrs
Best Language ever
@@rty1955 Me too. Both 6800 and Z80.
@@ivarnordlkken8082 I had began my work on IBM unit record equipment like the 407 using plugboard wiring then the IBM 1401 and then the IBM 360/30 ans on up. I played with the Intel 4004, and found it to be a toy. I built my own processor built around 7400 chips that mimicked the IBM mainframe instruction set. When the 8080 came out, I used it for an S-100 bus microcomputer. Coming from a mainframe environment, I found the instruction set to be VERY limiting. And could not grasp a SP register, as mainframes don't use that. I wrote major applications in assembly lang on mainframes with only 48k of memory. I was always amazed on what i can do with such limited memory. I would watch a tape sort on a mainframe (which was way faster than using disk) and was in awe. After it read alp the input data, it would print out how many passes of the data it would have to make before final output. You could even tell it which tape drive you wanted the output on even though it used that drive as a work drive! The instruction set was VERY powerful in mainframes and I missed that when I wrote for the Intel platform. For example I could clear 16meg of memory with just ONE instruction. Also the absence of 16 general purpose registers boggled my mind! Who would design such a limited processor! To me, the processors in a PC will always be a toy. They never matured. I now code on TI processors like the MSP430 and PIC type decixes8
25:42 "that's awesome". Indeed it is. As always an excellent video. Happy you are back.
This reminds me of my days doing assembly programming on a PIC16F84. I had implemented a bit-bang UART driver that drives an rs232 interface.
Also a 232 interface using a simplified ttl level voltages is prevalent in embedded programming for debug purposes
git ?
I also used the PIC16F84. The program memory was so small that I had to write a single bit bang routine to handle rs232, i2c and rs485 for an amusement arcade machine monitoring system, I remember using an interrupt pin for the rx line, causing the start bit to trigger an ISR . Now we have atmega328 its a different world. LOL.
Its amazing that engineers could design a 25 pin interface to carry serial data between DTE and DCE. Even when they reduced it to a 9 pin connector, only 4 pins were actually used. I loved the programming example in the video. It was great to go from the example that printed an "X" when something arrived to actually printing the ASCII characters. Great video.
It was nice to see you address the rising edge/falling edge timing. It's wonderful when you don't have enough ICs to be concerned with fan-out and de-bounce.
Would love to see a follow up on flow control or half vs full duplex.
I love the fact that he took the time to put on a Patreon t-shirt for the outo, you can barely see it in the reflection of the terminal! Fantastic video as always!
Nice tight loop, gone are the days (at least in PCs) that you have a known fixed clock rate and execution time, but so awesome to see that in action!
Have you ever thought about getting a ZIF socket adapter for that EEPROM on the breadboard? I always get so nervous watching you pry out and insert the chip with all those wires around it! :)
Fantastic video as always!
I thought the same thing about the ZIF socket. So many bent DIP pins doing this over the years...
Hah, yes, absolutely - I've been thinking this since the start of the project. Alternatively there has to be a way to program it in place.
@@WolfePaws PIC and AVR have ICSP (In-circuit serial programming) where you just leave a pin header attached to the programming lines on the chip. A cable connects from your programmer to the header and you can program whenever you want without having to move the chip.
I tried this once, but typically ZIF sockets themselves have legs which are too fat to fit into standard solderless breadboard :(
@@richardbanks2669 Very good point. The ZIF sockets I have do have very stubby leads too and I don't recall ever trying to put them on a breadboard.
Though I think the reason he doesn't is just because of the way he explains things so clearly and non-distracting way, like only using what you actually need to do this. Just like he shows the assembly and EEPROM writing steps each time, so it's absolutely clear what is happening.
RS-232 signals are defined as referred to the DTE. When you mentioned this simple fact, often missed by even experienced people, you earned a thumbs up.
Excellent tutorial, I don't think many people programming today would get, or appreciate counting CPU cycles... but that is how we had to do it back in the day! Even at UBICOM in the year 2000 their microcontroller would read the ethernet traffic in the ISR it did cycle counting... It was a Hard real time requirement, and the branching through had to balance in time regardless of the data received. Next when you get to the UART part of your tutorial, when I wrote my Master's thesis in Computer Science I did a study on Real-Time communications and used RS-232 and did the deep dive into that protocol and the whole architecture of the IBM's UART, PIC Controller, and learned just how flawed that was... I figured out the hardware bugs, I think 5 to 7 gotchas that did things like: prevent Full-Duplex ISR driven TX/RX, what the source of those mysterious callbacks when the line was enabled or disabled, instruction overlap in the x386 and the I/O instructions, etc. Back in the early 90's I researched this deeply, and I never saw printed in a book!
Great video! Few improvements that could be possible:
1. Use a conditional jump subroutine to get a 3 cycle delay instead of 2 NOPs for 4 cycle delay, to allow getting the more exact 104us delay
2. Half bit time routine wasn't exactly half a bit time. Would be closer to 69-70us when half bit time is 52us. But not super important here.
3. Could be cool to parameterize your delay subroutine so you have the same sub routine for 1 cycle and half cycle, but that's just for overachieving:)
He is just doing bitwise ttl receive for this video ? I think it will fail when he has a longer cable .. more capacitance... he will show you then show how a UART handles it still.
I was also concerned about half bit timer :)
Hi Ben, glad to find a new video from you! Very clear and inspiring as usual. Thank you!
Great tutorial on RS232 ! Btw you could simplify a couple of things in your code. Use Y index register for delay countdown instead of X to avoid the phx plx. Also reuse same delay routine by setting Y to either #13 or #6 before calling the wait routine depending if you want to wait a full bit or a half bit. Btw, an interesting thing about the Commodore 64 was that they never did a real RS232 implementation as part of the hardware but delegated that to the CPU so the machine actually had to this identical bit fiddling to transfer or receive a byte. However they did make use of a timer triggering a NMI (non maskable interrupt) so that the read bit was done quickly and a return from interrupt passed control back to the program running. However, the max speed you could use was 2400 baud with this method, and even then they messed up the timing table for PAL computers so it is in fact broken on all machines made! However, one could code this yourself and get as high as 9600 baud like you do here on your 6502, but then have no time to do other stuff while you were sending or receiving. A hack was done to enable this though by simulating a clock signal to trigger an interrupt as all transfers always started with a 1 but required a hardware hack for the receive signal.
I took several classes that covered serial protocols in college, and I'm ashamed by how much I didn't understand until watching this video. Awesome resource, thank you for making this
The clock pins were commonly used and are required for synchronous modem connections, typically used on private wire circuits. In the days before the internet this was how you interconnected branch sites, originally with a copper circuit patched through the local exchanges between sites.
But as it turned out, switching to asynchrous meant it worked on longer cables , noisier environments.. noise on the clock signal would send it haywire... the async UART works with about 5 samples of the received bit.. See, sometimes the circuit would be a bit assymetric (eg for mark vs space) and so the timing of the signal coming through would be a bit skewed.. as the main problem with a long cable is capacitance, the charging of it takes a bit of time.. if the circuits are not perfectly symmetrical, the timing of the pulse is not symmetrical (between mark and space.)
Hey! If you are curious what the clock pins are used for, in some applications (I work in optical sensors) you need to have very precise timing associated with each data packet. The Clock and Ref_clock pins can be used to connect a very precise oscillator (at 1 kHz for example) to the device you are getting data from. This is helpful if you need to integrate the results you get (and thus need exactly defined dt.) This is an alternative to a synchronous serial interface, which comes with it's own problems. It is very nice to be able to use an asynchronous interface with precise intervals defined for specific data packets.
to get a little weedier, what matters more than the time a packet is sent/recieved is the time a packet was GENERATED. this often involves numerical calculations (in an FPGA for instance) where you need to know exactly when the communication RTL logic is "sampling" a normalizer or shift register for instance.
i used to be so patient and diligent in doing stuff like these. now, my attention got diluted by so much stuff. I'm glad to see videos like this. I could at least feel the excitement without needing to commit to another project 🤣
I was only looking at my 6502 build a couple of weeks ago and thinking that I needed to figure out how to get it hooked up to a terminal, so the return of your series is very timely!!!!
"A while ago I built this breadboard computer..." This is like your father who went out to get milk, but he is back after 23 years with a carton of milk in his hand, asking why the breakfast isn't ready yet.
How is it like that in any way, even remotely?
Once again a great video. On something I have been using for 25+ years and thought I knew a fair bit about. You have provided more useful information. Thanks.
This video made this day so much better! You're a great teacher, and I enjoy your videos, and learn so much even though I know I would likely never be this capable, but brings a smile to know that at least I understand how things work. I always had those questions as a kid and it feels good to finally 'get it'. All the support :)
On the level converter: many transistors have a base-emitter breakdown voltage smaller than the rs232 mark voltage. If you don't exceed the reverse breakdown power for this junction the circuit will continue to work fine for awhile, but the transistor's beta will gradually degrade and the circuit will eventually fail. A series diode on the base (cathode to base) or a shunt diode from base to ground (cathode to base) would fix this. BTW the reverse breakdown base-emitter maximum power is never specified, because the manufacturer doesn't want you to run the transistor in that mode. They specify the b-e reverse breakdown voltage so you know what not to do.
One other point: half of 13 isn't 6. I won't tell anyone if you don't :-)
Finally: I love your coding and explanations, they're crystal clear! Your whole approach is a pleasure to watch. Thanks!!
I have worked with synchronous RS-232, in which the clock pins were in use. The assumption is that the clocks gate the signal from a buffer where the bit is held until the clock releases it. Interesting thing is that normally the clocks, both send and receive, always originate from the data communications equipment. This is because the communications networks way back when were multiplexing multiple signals from a centralized clock (old-style Time-Division Multiplexing [TDM]). That means your bits better be ready to go when the clock says go. The much more common asynchronous signalling is left to adjust timing through a network by allowing for buffering to satisfy the strict timing requirement of the network.
It has bee. A while since i wrote assembler and it was mostly Z80 and 8051 code. But i have done 6502 a very long time ago on the VIC 20 and the C64...lol it was a joy watching someone else coding in assemler! Great Video.
Welcome back Ben. So happy to see you back in action.
Okay, I have to let it out.
I missed your videos so much that I started looking for another places where you might have had been doing... anything 😂 Also made sure that there is no rumours anywhere saying that something bad happened. I was thrilled to discover the Ben Ben and Blue podcast, oh, that was a great listen! The 'origins of Ben Eater' are so inspiring. I love your story and keep learning so much from your videos. I'm glad they're back 😀
Actually I'm using a lot of industrial RS-232 speaking devices (barcode scanners, measuring equipment) at work and still learned new things from this video 😀
Always impressed at the quality and information density of your videos.
Great Ben thanks to have you are back after this "pandemic" period. Wish I could have learned all this from you in my early days. Best Regards from Hans in the Netherlands.
New Ben Eater video?! Just what I needed after a brutal week! Haven’t even watched it yet and already know it’s gonna be fantastic!
I learned more from him in a day than my entirety of schooling years.
That ignited my neurons. Thank you for your wonderful presentation.