BONUS 🤖 real Bender code

Last week I silently assumed the cultural knowledge that Bender runs on an 8-bit processor called the 6502. We ended with Java code based on byes and I said well you could theoretically port that to to Bender's processor. And today I'm actually going to show you um that I did that. Since I don't have actual Bender hardware available in 2025, we are going to have to wait another thousand years for that. I'm going to show you a different computer based on the 6502. In particular, the Nintendo Entertainment System was based on a 6502 and also the Commodore 64 which I used to program as a kid and teenager. Okay. So, let's go to a Commodore 64 emulator and let me load my program. Here it is. So the program for demonstration purposes is stored in the screen memory. So here you can see an example I band starting at the two and ending here. Before that is 6502 code and after that is the um lookup table containing all the weights for the digits. Okay. And how do we start that? Let me let me show you. So this will start the sub routine at address 1600 which is here and when the program is finished we will print whatever is in the memory location too and that is 68. This is an example from the Wikipedia page and 68 is the correct number. Maybe let's do it for our own example from last week and run the program again. and then we get 87 which is the correct result. Okay, of course you can't really read this code. Um so let's look at the source code that that generated this funny looking code. Okay, so here we have a directive that states the following code should be assembled into address or starting at address 1600. Then we start as last week with a value 62. So first we load the very first digit. Then we clear the carry bit and add to our accumulator or to the a value the uh looked up value for the very first digit just as last week. And we need to clear the carry bit because the add instruction always takes the carry bit into account. There is no add instruction without the carry bit. And then we look at the next digit and add it again. And this time we don't need to clear the carry bit because here it was in an indeterminate state when when we started the program. But this addition cannot possibly set the carry bit. Then the numbers are much too small for the first digits. So we don't need to explicitly clear it. And we save one bite in the program. Okay. Then we load the next digit and add the looked up value up. And now for the first time the values could produce a result bigger than 255. Then the carry bit would be set. So we have to check if the carry bit is still clear. We would jump to here in the program effectively skipping the uh following subtraction. And the subtraction is similar to last week. But this time since we are working with the full range up until 255, we can subtract 2 * 97. So we will only need about half as many subtractions as last time. So let me fast forward to uh the very last digit and then we have a loop that has the let's say target and variant of producing a value between - 97 and minus1. We do that by repeated repeatedly subtracting 97 while we don't cross the zero boundary if you will. And then we build the on's complement by flipping all the bits which mathematically computes -1 minus a. And then we add two to it effectively turning the um negative 1 into a positive one. Okay. And then if you do the math uh pos1 -1 would be 2 and pos1 -97 would be 98. And that's exactly the range that we require as the end result. Okay. And finally we store the result in memory location two. Okay. Then we return from the sub routine. The rest in the program is data. So here's our example number and after that is our um our table. Um yeah. So that's the concrete proof that Bender could indeed perform the IBAN check sum computation even if we will have to wait another thousand years to test it if it actually works.

MOS 6502 assembly language Commodore 64 IBAN checksum 0:00 intro 0:45 demo 2:03 code https://de.wallpapers.com/bild/benderfuturama-bilder-i6hnext7aws27wfo.html