Binary to decimal can’t be that hard, right?

I'd love to see a video in which you take this same algorithm and rewrite it into C and the setup necessary to output the right machine code for this chip. Regarding the length of the video, I don't believe you could possibly reduce such a complex subject without skipping over important details.

One piece of feedback on the 6502 kit. You might want to consider including a test socket for the ROM chip. I already broke two pins on my ROM since I have to keep taking it in and out of the breadboard every time I update the code. I try to be careful, but the pins seem to fatigue over time. I'm getting by right now with small pieces of wire soldered on to replace the broken pins. Other than that, I love this kit, have it all working, and am having a blast!

30 minutes seems like an ideal length, but your videos are addictive. I would probably watch a 3 hour video if you posted one on a topic ;)

i didn't watched your video (sorry) because i am on the 8 bit computer still. But to give you my opinion about your 42 min video : no i am more happy to have a long video just 5 min about a topic like this. It is just my opinion and i am maybe a little bit biased because right now it is the main topic i am learning, if i was just someone who was not deeply interested by this, maybe i would prefer a short one, so the question is : who are the people following you ? I presume they are more like me than but i can be wrong about this.

I was confused on how the rotate command was handling pushing the most significant bit into the least significant bit of the next address, but finally realized the rotate command uses the carry flag for carry in/carry out. Part of what threw me was not clearing the carry flag at first (its added in at a later step in the video). But my other confusion was the reversing of the message at the end. I think I could have used some old fashioned drawings on paper to help explain what's happening. There's some slight-of-hand shuffling going on there and it was a bit hard to follow. Love these videos !!!

Another great video, as always I was very excited to see the notification that there was a new video. I enjoyed it and liked the way you broke down the problem. I don't think it was too long. One improvement would be to demonstrate the problem before jumping into the solution. Maybe by first trying to print out a number and see it fail. To drive it home it would be better if the number was calculated instead of a constant in the code. I was watching with my son and it wasn't clear to him the difference between the constant number and a string containing the number. Just looking at the source it is a very subtle difference between a constant string and a number. I paused the video to explain to him what was going on. He is 8 years old so most likely not your target audience but he has enjoyed most of the breadboard and 6502 videos so far. I don't know what kind of math would be useful to do inside of the program since there isn't any input. Thanks again!

Ben, it is not too long, at least not longer than we are used to.

Hi Ben, Thanks for all your videos. This series on the 6502 is bringing back many fond memories of learning the basics of programming on a BBC micro back in the 80s. Funnily enough the last assembly program I ever wrote on that machine was an attempt at a division algorithm; it didn't work. I have some feedback on this video that I hope you'll find constructive. One aspect of your presentation style I find to be particularly helpful is when you work through a whole example run of an algorithm on paper showing all the intermediate states, speeding up the video through the repetitive bits but showing them with commentary nonetheless. This is a massive advantage of this medium over a real-time lecture and you use it to great effect. One case that sticks in my mind was the long sequence of polynomial arithmetic you showed in your series on error-correcting codes. You often refer back to particular states or transitions in subsequent discussion and I find it so much easier to follow this when everything is laid out on paper. In this video you used a tablet to avoid having to write out some of the more repetitive bits and I found this made it harder to follow, especially when you were illustrating the assembly you were writing with particular states of the algorithm that you were finding by repeatedly pressing the button on the tablet. I can understand why you might want to use a tablet for this, it can't be much fun writing out those hundreds of 1s and 0s, but the transparency is immensely helpful to folk like me. A very minor question: why do we have 2 bytes for the [mod10] value? Isn't this always less than 10? Or are you presenting this as a more general 16-bit division algorithm? Finally, I'll echo Richard Wells' suggestion that I feel this could reasonably be two videos, one on the algorithm and a second on its implementation. Many thanks again for all your work, David

Curious if this happens only to my setup: running the code to display the decimal number always works after powering up, without hitting reset. Never happened to the 'hello world' examples before. So I started displaying a longer text right after the calculation and that text also displays correctly when powered (using an USB battery). Maybe a tiny delay is required before writing to the display, just what the this calculation does?

This video is very well done as usual and I learned a lot as always. The division algorithm is clever and well explained. But, this video seems to be getting further away from the hardware and datasheets we know and love and delves deeper into the assembly language rabbit hole. I feel like we have been using assembly language up until now because we have to in order to get the hardware to do anything at all. This video maybe should be called, "Assembly Language is Hard!" At some point, we should possibly start considering higher level languages like some have already one on r/beneater on Reddit. For the Interrupt video could you just have displayed the interrupt count with LEDs or some simple hardware so we could focus on learning about interrupts? I know a lot of people are really enjoying learning assembly language and that is great. Just my 2 cents. Keep up the great work.

This comment probably won’t be very popular. I hope it is taken in the collaborative way it is intended:

At 2:05 or so you type "+ %1000" but say it's four, when four is %0100.

Great video. Worth the 40 minutes of watching to really understand how the algorithm works. I wouldn't worry about the length, people that are interested in binary to decimal would likely sit through it. I know I had no trouble watching the entire thing. As usual a great real world example. Well done!

I think it would be worthwhile to split this into two pieces, one for the algorithm, and one for the implementation. That way, you could go into a little more detail on (1) the ROL instruction and how it uses the carry flag, and (2) the push_char subroutine. I think some diagrams for both of those would be very useful to a lot of people. It would also be very useful in a later video to use this as a basic of a general-purpose division function, rather than this special-purpose subroutine to write out a number in decimal. Of course, that's getting into the software side of things rather than hardware, so perhaps it wouldn't fit in with this series.

I had a very similar problem building a 16bit Breadboard PC. I follow the intcode specs from last years Advent Of Code, and therefore had to do Modulo 100 in hardware. I went with a EEPROM as a lookup table, because I could not figure out a more effective way. This video gave me an idea on how to do fast divisions in intcode though, which would speed up my programs a lot! As always awesome video :D

Great work. If I may be so bold, I think in at least one place, it could stand to be a little longer. At ~36m, when you launch into the stack reversal algorithm, I felt that it was a little rushed. I had to stop and go back to see what was going on. In particular, I think it clashes a bit with your earlier attention to detail in patiently explaining with visual aids how the algorithm works. I understand the char shifting stuff is not the main focus of the video, but I think a few people are likely to get lost here.

I didn't watch it yet, no time today. But a quick question, why not use BCD counting? 6502 has BCD support, right? If I rememeber correctly there is a decimal mode that changes addition to BCD

Love the video, and on the whole there isn't any specific part which could be cut, but i still have some constructive criticism: At 7:50 i have a minor nitpick in that you don't have to do the long division the 3rd and 4th time, the audience understands by now what's happening, can just have filled it out already and say "and we do this until we end up with a result of 0, which is two more times", or alternatively just "and we do this a couple more times...". At 3:23 and 9:09 - saying that binary division isn't much division because all you're doing is subtracting is a /bit/ weird, considering that that's what it _always_ is, whether binary or no. Division is counting subtractions. Some people might not have thought about it too much, and so need a refresher that that's what it is, so saying it once at the beginning and then iterating at the end is all all good. I just think it would be better to get the idea across by saying "You know, when you think about it, division is just subtraction" than by saying "We aren't doing much division here, just subtraction". Maybe leave the first line the same, as it's just giving the gist of things and setting up for later, but then turn out around when you revisit so it's clear that we *are* in fact doing division, it's just that division is always just subtraction. At 24:45 you split a 2-byte subtraction into two single byte subtractions by simply doing the bytes seperately. Correct me if i'm wrong, but that won't work, as it doesn't account for carry. If the right side was too small and the result is negative, the left side won't know that. Any algorithm that actually needs the answer in full, would need to look at the carry in between the single byte subtractions to see if the previous went negative, and if so adding 1 to the number which is subtracted, and re-setting the carry bit high. Don't worry, if the result of the subtraction as a whole should be negative, so will the subtraction of the high byte after the adjusted value, thus the carry flag will be set low again. However, since you don't need the result of those high bits when the result is negative, we don't care here. But then i have to wonder why you even bothered to do it this way, and not just assume 0's, because both numbers only have 1's somewhere in the lowest 4 bits. Whenever we need the result, the high byte will always be 0's, so we could save some computation.

Is there a reason that you used 16-bit for mod10? The highest value that it will hold is 19. It would simplify the code a little bit but I down know if you are willing to redo a great part of the video just for something that isn't wrong.

@1:56, the number should be '0100' as binary representation of 4, instead it's showing '1000'.. just a little error there..

I frequently watch videos over an hour long, so I might not be the normal viewer, but I'd say: Never cut down on time if it decreases the amount of useful information. If you really feel like a video is too long, you could always make it a multi-parter. We all know how you love to keep us in suspense ;). Btw, did you notice that your astable 555 timer was mentioned in one of LTT's videos recently?

Very nice video. I didn't notice having spended 40 minutes to watch. Just one remark on doing the long division with pen and paper: There are some countries where the notation is different (while the technique as such is the same): https://en.wikipedia.org/wiki/Long_division#Notation_in_non-English-speaking_countries . That was kind of surprising for me at the beginning.

Great video! Adding a +1 for a couple of things: A gap in the video about 2-3 seconds at 25:14 as reported by Matt Goldman and also clearer indication that the ROL instruction handles the carry bit as per your explanation like suggested by Jeff Golden. Took me a while also to understand that ROL infact handles the Carry bit the way you explained, instead of needing you to program it on your own and that you didn't need to do anything else with the ROLs. Anyhow, great video yet again, it's amazing how clear your explanations are and how interesting you always manage to make the videos. Didn't feel like 40 minutes at all :D

I got a bit lost in the "push_char" routine. How about building the string backwards in place? Initialize it to 5 spaces and null, then fill it starting at index 4. Printing it would end up right justified, but that's common for numbers anyway. Or tell the print routine to start at the final index after getting the zero dividend.

Like how the video turned out. No problem with length (for me). Loved when the number showed up in reverse and how you fixed it. Though instinctively, I'd populated the number into the string from the right, so it will automatically be right aligned. But I see the beauty of not relying on the string length to begin with.

I agree with your other commenters - I don't see how you could cut this video down or edit it to be shorter and keep the needed parts of the video to help people understand. I have watched the video three times and I have the new program working -- but it took a couple of times though for me to have it really sink in (edit: Understanding how rol was rotating carry bits seemingly both directions was the main part that was hard to grasp for me. It took looking at 6502 assembly reference to realize there was nothing happening automatically here - which is what I assumed because the two words [$0200 value and $0202 mod10] were contiguous. Until I looked up rol I was really confused how the carry bit was getting moved into the low byte of mod10 from the high byte of value which seemed to be to the left of mod10. I may be the only one who was tripped up by this - but if you do end up re-editing this at all and have an opportunity to add a sentence or two to clarify the rol operation and how the carry bits are moving from one byte to the next (based on carry bit state at the time of the rol operation and not automatically based on positions within memory) in the implementation portion I think that would have been helpful to me.) And BTW thank you for producing such quality content -- I have really enjoyed this project and your videos!

Hardly worth redoing, but your example and the actual program deal with binary data except the number you use as the divisor. You hard coded "10" decimal. Perhaps, in keeping with the example, you should have used the binary '1010' instead. A nit, no doubt, but there is the remote chance that someone watching could confuse this 10 as being binary whereby you would be dividing by "2".

From paper and pencil simulation to writing and running the assembly its almost too short but very clear and dense explanation. Easily could have been a 40 mins on the paper and pencil theory and a second 40 on implementation.

Great explanation! Coincidentally, I was just looking into BCD a couple days ago and I had come across a method that involves shifting left and adding three. I can't say I completely understand how that method works because I haven't found an explanation as detailed as yours are. The detail you provide is perfect. But now I'm curious which method is more efficient? I'll have to experiment.

I agree that it seems longer than you would expect for a "simple" division problem. But I don't know what you could cut out to make it shorter without compromising the full Eater level of explanation. Plus this is a building block towards counting and displaying the number of interrupts. I enjoyed the video. Definitely opened my eyes to all that is going on under the hood of a 4 function calculator. I always understood that multiplication was just adding several times, but I never understood how dividing was subtracting several times. Now I know.

I didn't see anything that I thought was unnecessary to the explanation, at least at my level of understanding. Great video.

there's a gap in the video at 25:14

I don't think you should cut anything. Personally I saw and heard exactly what was necessary for me to understand. I think the video is excellent the way it is. Thanks.

I don't know if it's worth fixing, because you don't actually _do_ anything with it, but at 1:54, you've got a binary "8" shown (1000), when discussing a binary "4" (100)

@David yeah, audio seems low to me as well. I tried figuring this out a while back and had a hard time understanding it. This visual explanation is perfect! I finally get it now 😁

I haven't finished watching yet but there's no such thing as a Ben Eater video that's too long in my book.

Is the audio low on this video or is it just my imagination?