With the Game of Life working at the end of the last session, I thought we’d do something a little different this time, converting a famous one-line BASIC program into assembly. In the process, we had to write code to scroll the screen as new lines appear at the bottom. Enjoy several minutes in the middle of me rubbing my furrowed brow as I struggle to figure out why it’s broken at one point.
In this session we added a “press a key to continue” feature to the program, and then worked out the bug that was keeping certain cells from updating properly. Then I talked a bit about the possibility of refactoring the algorithm for walking through the cells and determining their neighbors to make it faster, and whether to do that next time or move on to another project. Comments and suggestions are welcome.
I realized after recording the last video that my method of converting the work area into the game board was overly complicated, so the first order of business this time was to simplify that. That also got rid of the buggy behavior we ended with last time. Then we do some self-modifying code to save bytes, which is cool but also shows how easily that can result in bugs. Got that working, but there still seem to be a few cells that don’t work right.
Continuing with our Game of Life, we work out the code to calculate the number of neighbors for each cell and then rebuild the cell grid for each turn. Also improved the randomness of the initial grid layout. There’s a bug somewhere that’s throwing off the rebuild, so debugging that will be the first task for next time.
I started coding Conway’s Game of Life in 6502 assembly. This video covers the initial setup, laying out the game grid, filling in random (“random”?) cells, and thinking about how to process neighboring cells. I expect the full game to take a few more videos, as I have some ideas to add after getting the basic game working.
I finally finished the next entry in my 6502 Assembly Language series yesterday, and it took overnight to process and publish. In this one I debug the print-a-number code from #6, and then talk a bit about what to do next. I think I’m going to write a version of Conway’s Game of Life, as a way to develop an operating system kernel along the way. A game will need basic functions like “print a character at coordinates x,y”, so I think that’ll be an interesting way to do it.
Continuing on from the last video, we start working on code to print a number on the screen, one digit at a time. Debugging to come in the next installment.
Continuing with the code we wrote in #4, we compare the code the assembler understands, with comments and labels, to the machine code it produces, using the machine language monitor in the Commodore 128 to disassemble it. We also convert the binary division routine from #4 to handle 16-bit dividends, and then 32-bit. Also discussed the issue of where to store working values in memory. A side note: I was puzzled during the video why my perl command was printing a 1 after the expected value of “b27”.
We walk through an assembly language routine to divide one 8-bit value by another on the 6502. It was a little darker in there than I realized, so I hope it’s watchable, since I don’t want to do it all over. As usual, questions and comments are welcome. The next chapter will incorporate this routine into a larger bit of code.
This video introduces the 56 op-codes in the 6502 assembly language instruction set, and gives examples of the commonly used ones, using a Commodore 128 monitor. Here’s the list of op-codes divided up by function. This is the third video in my ongoing 6502 assembly language series. If you’re not familiar with the 6502 hardware, or with binary math and bitwise operations, check out the two previous videos in the series for info on those.
I’ll be doing videos to demonstrate the 6502 instructions soon, and you can’t understand several of them without a basic understanding of binary math. It’s not hard, but it’s something that isn’t taught in math classes anymore, or is touched on as a concept but not really absorbed. This video demonstrates how to write binary numbers and translate them to decimal, how to add them, and how to convert to hexadecimal (base 16).
I plan to do some demonstrations of assembly language programming, so I thought I’d do a short intro. This is about the 6502 family of microprocessors, which were used in many computers of the 1980s, and are still produced by the millions for embedded hardware and hobby projects. The 6502 is a pretty easy CPU to program, because it has a fairly small set of instructions, and yet it’s powerful enough to do interesting things.
The fourth and final video in the series. I add the ability to ask for a number of games on the command line, do some final cleanup of the code and testing, and push it all to my gitlab repository. I intend to do more programming videos, so if you have suggestions or questions, please send them to firstname.lastname@example.org. I may try some live streaming so it would be possible to interact in more of a classroom manner, if these generate any interest in that.
This is the one where I spend an embarrassing amount of time figuring out how exactly to avoid losing a game of tic-tac-toe. Got it figured out, though. Now the players are smart enough to force a tie every time. In Part 4 I’ll clean up the code somewhat, add a few more features, and maybe talk about what comes next in the series. Part 1 Part 2 Part 4 tttbot repository
Here in part 2 I write most of the code, getting the program to where it can simulate one game. The AI is very dumb at this point, on purpose, so I could make sure the win and block conditions worked correctly. Part 3 will make it smart enough to produce all tie games, clean up the code, and do any debugging. This isn’t a tutorial, so I’m not trying to teach C in it, though that’s something I may tackle at another time.
This the first part in a series of videos on C programming, which will walk the viewer through programming a tic-tac-toe simulator (a program which has the computer play against itself, a la War Games). I will be making it up as I go along, so you’ll get to see how the sausage is made, from designing to debugging. I hope that doesn’t result in too many long pauses as I think about things, or too many times of backing up and starting over, but we’ll see.
As I say in the video, I get asked now and then what programming language a person should learn. I thought I’d put together a simple demonstration of several, to show some of the similarities and differences, and why it’s a good idea to be proficient in more than one. I’m also trying something new in using my phone as a webcam. Works okay, though it does add a short delay.
I’ve been playing some Stardew Valley lately. I got it from gog.com for $15, which is the most I’ve spent on a game in a long time. It’s a very well-made game, and even more impressive when you find out it was done by one man. Not many people can code well enough to make a complete game work, and do good graphics, and do good music, etc. Most games are made by teams of people with different skills, and when one skill is missing, it shows.