First off, what I know beforehand, is that a stack is something to put values into and read values out of quickly. I presume different types of stacks have different patterns like first or last in, first or last out (FIFO comes to mind). I presume the 6502 will only allow for one such type though.

A stack of dishes

This time I consulted both Easy6502 and this other blog post.

A stack is something you “push” values onto, and “pull” values off of. This is what the Push Accumulator (PHA) and Pull Accumulator (PLA) instructions do, which I previously only knew the name of.

The stack is “last in, first out”. It’s compared to as a stack of dishes, where you are only able to put on a dish or take off a dish from the top of the stack. There is an illustration from Wikipedia for this:

I do not know the exact use for this feature, but considering the limited instructions and cycles we get on the 6502 I can certainly imagine it to be an effective way to handle a list of data. With these types of analogies, I can also think of a way to demonstrate this concept visually with a program. More on this later… 🍔

I analyzed the example program and added comments to make sense of it. In short, we can store values into the stack with PHA and take them off with PLA. The S register (stack pointer) lets us know where in memory the “top” of the stack is currently. TSX and TXS let us read and manipulate this value directly.

A tangent: making interactive code

If we are able to manipulate a stack in my program, then I want to make it user interactive. Luckily, Easy6502 has a simple register $ff that contains the last key the user has pressed while running the program, as an 8-bit ASCII code.

Because we also want to know when a key is pressed, we have to come up with another part of the logic ourselves. For this test program, every time you press a key a new pixel is “typed” to the screen. This is what I made:
(code available here)

In that recording I’m mashing a whole bunch of keys, and as you can you see it’s working as it should! By achieving reliable input polling, we open the doors for all new kinds of programs.

The burger stacking program

My idea is to demonstrate the stack by using a hamburger analogy. Burgers are made of various ingredients stacked together, so this is allows us to visualize what’s in stack memory in a very blatant way! My plan is that you can use the 1 to 7 number keys on your keyboard to place the various pieces such as the buns, lettuce and patties. Then by pressing 0, you remove the topmost ingredient — exactly like how the stack works inside of the 6502.

Starting off, I created the burger sprites.

I had a ton of fun drawing this. I tried to make each piece look as tasty as possible, all while looking at pictures of burgers for reference (making me incredibly hungry). I caught myself talking out loud, tastefully describing how each line of pixels makes the burger look more nice and delicious, resembling some kind of fast food-minded Bob Ross.

I used very specific constraints in order to get the maximum effect out of minimal programming:

• Each piece only uses 1 color.

  • This way, I can use simple run length encoding. As an imagined “pen” moves across the screen, the only thing I need to specify is when it’s down (drawing), and when it’s lifted. This saves memory, lines of code, and speeds up drawing.

• Each piece is 4 pixels high, starting at the red pixels.

  • This means the bigger pieces (the meat and buns) are made up of two slices while looking like one. The program code will need to place both of them at the same time, but that’s about it.

• The 4th row at the pink dots is what I call “overhang”, and is drawn over the piece beneath it.

  • This achieves a more complex looking effect by simply drawing the slices with 1 pixel of overlap. The mockup shows how effective this is, with the dripping cheese overlapping the meat patty.

I think assembling burgers is as much fun as I can provide you with a simple program right now. c:

The structure of the program

I have not finished the program of this day yet, and as such it is merely Part One. For reference, the work in progress code can be found here.

This is the plan I have in mind:

The pieces

Each piece will have its own value, so that the stack in memory plainly lists out the pieces in consecutive bytes.

; Burger pieces:
;  #$00 - nothing
;  #$01 - bottom bread A
;  #$02 - bottom bread B
;  #$03 - sauce
;  #$04 - lettuce
;  #$05 - tomato
;  #$06 - patty A
;  #$07 - patty B
;  #$08 - cheese
;  #$09 - top bread A
;  #$0a - top bread B

Init:

In memory addresses $00 to $08 we will store the colors that the individual pieces should be drawn with. The address numbers match up with the values above.

We should also initialize the stack for the first time here.

StoreGraphics:

Here we will write to memory each of the “pen down” and “pen up” timings for all slice types, using the aforementioned RLE. I’m hoping this is less work and more effective than storing each pixel individually.

FillBG: Starting off with a colored screen

As in my mockup, I think the graphics will look better without a black background this time. I figured out how to draw to the entire screen in a simple way. Here is the code!

FillBG_init:
 LDA #$02          ; ╮ X/$11: Drawing page/high byte
 TAX               ; ╯
 LDA #$00          ; ╮ Y: Drawing position
 TAY               ; ╯
 LDA $00           ; Load background color into A
FillBG_loop:
 STX $11           ; ╮ Draw background color pixel
 STA ($10),Y       ; ╯ to screen using indirect addrs.
 INY               ; Increment screen position
 CPY #$00          ; ╮ Check if Y has overflowed,
 BNE FillBG_loop   ; ╯ otherwise loop.
 INX               ; Increment page
 CPX #$06          ; ╮ Check if X passed enough pages,
 BNE FillBG_loop   ; ╯ otherwise loop.

Because we will have to draw to more than 8 vertical lines this time, we need to be able to address more than 256 pixels. If we can’t do this, then there’s no way we will be able to draw burger pieces all over the screen either!

At the core of this is the indirect addressing mode, as I learned about on the previous day. While we keep the drawing position (Y) in a register like usual, this time we will also keep track of what page in memory we are on (the first byte $XX 00 of an address), and store it in both X and $11. That’s how we store our address of interest for later reference in memory. Indirect addressing will read from $10 to find the 16-bit screen address we want to write to. We simply offset that address with Y like normal. All of this is through: STA ($10),Y — indirect addressing is highly effective!

We use branching to keep two loops going. First we loop until the entire page is filled with our color value. Then we break out of it, increment the page counter, and go back to fill the next page. When that is done 6 times, we break out of the whole program.

Here is what this looks like:

DrawBurger:

Aside from the pen on/pen off technique I use as compression, I have all kinds of approaches in mind here.

When we are stacking the burger, there’s no problem with just drawing each new on top of the the previous one. But because we can take off pieces too, I want a 4 row high rectangle to draw over the discarded piece, (also clearing the “overhang” with it), and then have the top piece redrawn. This way we don’t have to slowly redraw the entire burger stack each time.

PollInput:

This is where a modified version of the input polling code I shared above will run. Nothing needs to happen on screen while the program checks if you hit the 1-7 or 0 keys.

UpdateStack:

Once a key is registered, we break out of the polling loop and add the correct piece or take the last piece off the stack in memory. If a piece is taken off, maybe I will set a flag in memory to trigger DrawBurger to erase the graphic properly.

A short conclusion

From now on, I am unlikely to finish these more complex programs within a single “day”. However, I will still report to you what I’ve learned right after I’ve done it, such is the concept! That means programs will be written over multiple posts, but on the flip side, I won’t be held back by what’s possible within a single session. It should allow me to be as ambitious as I want to be!

Thanks a lot for reading this. I hope you will stick with me until we can both be stacking burgers in the program!

I’ve been memorizing the 6502 processor’s table of opcodes before I even knew what any of it meant, but straight away I noticed the instructions are duplicated many times over. By now, I know that these are the different addressing mode flavors that each of the instructions come in.

An addressing mode is one of the various ways in which you can use an instruction, either by giving it a byte to handle directly, or a memory address, or perhaps a memory address with an offset. It kind of reminds me of how in normal programming a function can have multiple arguments, but here it is within a much more limited structure.

We have many of these modes to learn: implied, absolute (X/Y-indexed), zeropage (X/Y-indexed), immediate, relative, X-indexed indirect and Indirect, Y-indexed. This was a lot to take in for me, and just trying to understand it and taking my notes took up most of the time I had planned for the day. Hence, I’m not writing this on the same day I did these exercises.

Here are the notes I took:

Figuring out what modes do in practice

So because this amount of information is hard to summarize, I will focus on how these various addressing modes may be used in practice.

• Implied mode
  The most simple mode: we do not need to specify anything for this instruction, as it knows what to do by just by calling its name. Say: INX, or “Increment X”, and nothing more is needed.

• Immediate mode
  For when we want to pass a single byte (an 8-bit, 0-255 value) to the instruction. Say: LDA #$01. We’ve loaded the number 1 into the Accumulator. As we’ve learned before, the # indicates the 01 value is a number, not an address.

• Zeropage mode
  We can indicate an address to the instruction using a single byte, as long as it’s on the zeroth page of memory: $0000 to $00ff. Say: LDA $01, shorthand for ‘load the value at address $0001 into the Accumulator’.

  • This makes the first 256 positions in memory kind of special. I’ve heard the zeropaged addresses may be treated as second rank registers in addition to X and Y.

• Zeropage X/Y-indexed modes
  This is how we can finally state: ‘read or write from “this + X” or “that + Y” address’. Following with:

• Absolute, and Absolute X/Y-indexed modes
  We can pass the instruction a full address (say: JMP $1234), or offset it by X or Y. Say: STA $1000,X. If X is 1, this means ‘store the value at $1001 into the Accumulator’.

We now know enough to be able to fill the screen with random colors, which is something we previously couldn’t do!

 LDA #$00    ; Immediate mode: Initialize A
 LDX #$00    ; Immediate mode: Initialize X, the screen position
loop:
 LDA $fe     ; Zeropage mode: Load a value from the randomizer register
 STA $0200,X ; Zeropage X-indexed mode: Write to an offset screen position
 INX         ; Implied mode: Increment the screen position
 JMP loop    ; Absolute mode: the 'loop' label is actually a full address.

• Relative mode
  This is what Branching instructions use to jump a relative amount of bytes through the program. Once again it’s only an 8-bit value, so that’s why it can’t jump too far back or ahead.

And finally, that leaves us with the indirect modes:

• Indirect mode (vanilla)
  We point the instruction to a full address, which at that position should contain the actual address of interest for the instruction to act on.
  Because of how the 6502 reads values of two bytes in reverse (a fact we just have to accept), it reads the second byte as the first part and the first byte as the second part.
  Let’s visualize what “JMP (40f0)” does. The parentheses indicate that it’s indirectly addressed. As you can see below, it starts to read the value starting at $40f0 in memory in reverse, and that’s the address you get to jump to: $cc01.

MEMORY      40f0 40f1 40f2 40f3
VALUE         01   cc   00   00
                \ /
                / \
JMP (40f0) -> $cc  01

• X-indexed indirect mode
  This is the same as before, but it starts reading from the specified address offset by X. Also, we can now only read from zeropaged addresses.

• Indirect mode, Y-indexed

  It starts reading from the zeropaged address we hand the instruction, then finds the register of interest and adds Y to it.

As this is going on for long enough, I will leave writing a program with Indirect mode for a later day.

Rewriting my first program to be smarter!

Not long ago I wrote this simple program only by loading values and storing them back into screen memory by hand. It’s simple, and actually very efficient. But now instead of simply listing out the pixels, our mission is to create these laser gun images again but through logic.

Let’s start by storing the laser gun graphics into memory so we’re able to reuse it, kind of like a sprite. The guns aren’t only drawn four times over, but many parts of it are repeated. Therefore we can use the familiar LDA and STA commands to store the image’s 4 unique rows neatly in memory:

0000: 00 06 0e 03 01 03 0e 06 00 00 06 0e 01 0e 06 00 
0010: 00 00 0b 0b 0c 0c 0f 0f 00 0b 0a 0c 0c 0f 0f 0c  

We then jot down some logic to make these lines appear back on the screen in the most simple fashion. We use X to keep track of the memory position we read the color at, and Y to keep track of the screen position we write our color to. We then repeat through this code using a loop, and read and write at incrementing positions through zeropage memory offsets.

Now I tried to write each 8 pixels of the image on its own line, by adding the screen width of #$20 (32 pixels) to Y after 8 pixels are drawn.

Oops, I didn’t think the addition through… We were already 8 pixels in and trigger the Branch at 9, so we have to add the whole screen’s width minus 9 to Y instead.

There, we successfully wrote the graphics data stored in memory to the screen in its compressed state. We now have to write logic to repeat lines, and elongate the image into its original shape.

Since the X and Y registers are already taken now, we’re going to have to use page zero to store more variables than just those two. When we do some operations, we’ll have to back up our Y register temporarily. I really wanted to prevent this, but I could not think of a way to use less variables than this.

We will have an area in memory starting at $20 that indicates where every line needs to start reading in the sprite data area. By pointing to a position in the sprite data, each line is simple to repeat and define. If we say for line 1 to 16 you start reading at 0, where the blue laser beam is, then we now drawn 4 long laser beam images. In effect, this is kind of like a tile map. This data looks as follows:

0020: 00 60 68 00 00 60 68 68 00 60 68 00 00 60 68 60 
0030: 08 18 70 18 10 10 10 10 10 10 10 10 10 10 10 10 
0040: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

Then, for our new zeropage area variables:

$50 will count at which line we are at.
$52 will count at which line we are at.
$61 will be where we backup Y.

In a loop, we keep reading colors from a zeropaged offset address through LDA $00,X, and keep storing them into screen memory with an absolute offset address through STA $0200,Y, because $0200 is where the screen memory starts.

We branch to the AddLine label when we’ve completed 8 pixels (LDA $52, CMP #$09), and increment the line order and line progress counters. We look back into line order memory ($20+) to see at what position in the graphics memory we should start reading the colors for the next line, which we set X to. If our line order starting position returns $ff, then the program knows to branch to the exit label and BRK.

We have to juggle some variables around, and I had to do a lot of reasoning in my head when the program just didn’t draw anything coherent. Luckily, I found out that the Debugger can jump to any label, so I could step through specific parts without having to step through the whole program.

And things started to take shape:

And there we are back to the original result from Day 1, but this time drawn with more complicated logic!

Actually, it’s missing the differently colored LEDs, but instead of storing unique graphics lines for that, let’s one-up our old result and make the laser beams different colors instead.

We don’t have enough space to fit all the new colored graphics into memory, so we cheat and continue our sprite area from address $60 onwards. I pick some nice colors so we now have red and green laser beams too!

The program can draw each beam differently by simply changing where each line should start in graphics memory.

 LDA #$00   ; Gun 1 Blue Laser Upper Row
 STA $20
 LDA #$60   ; Gun 2 Red Laser Upper Row
 STA $21
 LDA #$68   ; Gun 3 Green Laser Upper Row
 STA $22
 LDA #$00   ; Gun 4 Blue Laser Upper Row
 STA $23

It’s quite easy to do this now: we just change each of the lines we want, and leave the “body” of the guns alone to draw the same lines from graphics memory for all 4 guns.

So finally, for the grand result:

• The code for this program is available here.

And that brings us to the end! There are still some loose ends regarding addressing modes.1 I need to consider how to deal with these topics that want to take up more than a single day. There’s much to learn for me, which is most definitely the point of everything I’m doing here.

Thanks a lot for reading this day’s post, and see you in the next one. ^-^

The following program is given as an example of branching:

  LDX #$08
decrement:
  DEX
  STX $0200
  CPX #$03
  BNE decrement
  STX $0201
  BRK

First off, I notice a label called decrement. Instead of JMPing to an exact address figured out through disassembly, we can instead simply refer to a label. That makes things easier straight off the bat.

I interpreted this program as follows: We store value 8 in the X register. After the decrement label, we then store X’s value at memory address $0200, which I later realize is the start of screen memory ($0200-$05ff). With CPX we compare 3 to X. If it’s not equal, we jump back to the address of the decrement label. Else, we keep running and store X at memory address $0201. The program exits.

Reading the explanation, it is the Compare instructions (CMP, CPX, CPY) that set or clear the Zero flag in the Processor’s status register. This is why BEQ is documented as Branch on EQual zero set, and BNE as Branch Not Equal zero clear. Branch on Carry Clear and Branch on Carry Set incorporate how they react to this flag within their names. It checks for the Z flag to determine whether to branch. In pseudocode, I see it as:

BEQ: if (Z) { branch(); }
BNE: if (!Z) { branch(); }

BCC: if (!C) { branch(); }
BCS: if (C) { branch(); }

The tutorial then offers you two challenges:

Exercise 1: Try writing a program that uses Branch on Equal

I got to work and started experimenting. The logic is clear enough to me, but drawing single pixels to the screen isn’t. I decided to draw a pixel heart with STA commands so we have a nice visual to see what’s happening.

I add the following loop logic to redraw the heart in cycled colors.

 INX
 CPX #$ff
 BEQ skip
 BNE loop
skip:
 BRK

We keep incrementing X to change colors and redraw the heart to reflect the change. Once X hits $ff, we break out of the loop.

With the simulator running quickly, I want to count to $ff before changing colors so that there is a bit of delay. I use X as the timer multiplier that determines how many times Y should wrap back to $00 before continuing:

LDX #$05                ; Set timer multiplier to 5 times
draw:
 {Draw heart}
wait:
 INY
 CPY #$00
 BNE wait               ; Go back to wait: until Y has wrapped around
 DEX
 CPX #$00
 BNE wait               ; Go back to wait: until X has become zero.
 {Change drawing color}
 JMP draw               ; Back to drawing.

This lets me have all the control I want: I can change the colors each loop, and by adding more logic I can even decide how many loops each color should last for. Adding everything I know so far together, I created a pulsating heart animation.

I included the entire code because it fit. ^-^ I was quite happy per usual. In this GIF, we can see how the Y register keeps counting up, triggering the X register to count down to zero where it is then reset to a multiplier value of my choice. One that’s shorter for the dark color, and another that’s longer for the light color, mimicking the rhythm of a heartbeat. As a fancy experiment, I store both the colors and their multipliers in memory at $0000 and $0001. The code is available here.

This code includes the BEQ instruction, so I consider the exercise done!

Exercise 2: Write a program that uses Branch on Carry Clear or Set

Ignoring the mathematical purpose the Carry flag may actually be for, I just focused on what I know it does in effect: set once the Accumulator overflows.

The Accumulator will be the timer counter this time, counting up to $ff letting Y increase every time Carry is set. X will be the drawing color. The looping logic is similar to before.

We define a palette of five fading colors in memory addresses $0001 to $0005 so that we only need to define their values once. Y increments, and we handpick each of the values where Y triggers a branch to a different part of the program. These parts each load different values from memory to set the drawing color X. Once we have cycled through all colors we set Y back to the starting value we stored at address $0010. This is the result:

The code is available here.

I think it achieved the effect I had in mind, and it’s thanks to branching that I can now create something like this at all. I look forward to learn much more effective ways to achieve this same logic.

I challenge you to beat my WRs on Sporcle!

Now something I have been distracting myself with that still relates to this journey is Sporcle. In short it’s a website where you can play memory quizzes and create ones yourself as well. I decided to make my own 6502 themed quizzes:

• Can you name the 6502 Instruction Set? https://www.sporcle.com/games/Cyanne/6502-instructions-easy
  My current best time: all 56 in 00:41.

• Can you name the 6502 Instruction Set (Blind)? https://www.sporcle.com/games/Cyanne/6502-instructions-blind
  My current best time: all 56 in 01:35.

• Can you name the 6502 Opcode Table? (tough!) https://www.sporcle.com/games/Cyanne/6502-opcode-table
  My current best: 71 instructions or 47%.

I’m going to have much more fun with this in my downtime, so maybe you’ll find these quizzes or completely different ones fun as well.

See you next time!

Through my own curiosity and getting new things kindly taught to me, I’ve learned just a bit more about the basics.

How the program is read

I now know that the “PC” value I noticed in the debugger is the Program Counter register, counting up in 16 bits. This is what keeps track of what position the program is at in the machine code.

Going through my program with the Step button, I quickly noticed the counter does not increment one by one, or even consistently. The key that helped me understand this behavior is the Disassemble button. For the first example program it showed me the following:

Address  Hexdump   Disassembly
-------------------------------
$0600    a9 01     LDA #$01
$0602    8d 00 02  STA $0200
$0605    a9 05     LDA #$05
$0607    8d 01 02  STA $0201

I was taught that the first a9 in the “Hexdump” column is there to signal the LDA instruction to the processor. The Program Counter increments, and then reads the value of 01 (the #$01 that the LDA was provided as an ‘argument’). That’s it for that line of assembly code, the PC increments and then there’s the 8d for the next STA instruction, which continues to span over the next two bytes. Now it makes sense that the PC doesn’t increase consistently: in the Debugger we see it stop after every line of assembly code, and that can be one or more bytes in machine language!

I deduced that the processor must know how many bytes should follow after that first number, the opcode. It’s also interesting to note that the opcode will change depending on what the argument tells it to do.

Address  Hexdump   Disassembly
-------------------------------
$0600    a9 10     LDA #$10
$0602    a5 10     LDA $10

Opcode a9 specifies that a literal value $10 should be loaded into A, while opcode a5 tells the processor that register $10’s content is to be loaded into A. It might be the same LDA instruction in assembly language, but it’s not the same opcode in machine language. When you consider that you’re literally telling it to do two different things, it does make sense.

All of these opcodes can be found in a supposedly logical order in a big table. It goes over my head right now, but it’s interesting! Masswerk’s page I found here seemed so useful that I quickly took a few screenshots and constructed a cheat sheet from it:

Brain Training

So I will not deny that all of this is a lot information for me to take in. However, I really want to have as much of this knowledge memorized as possible. Even if I don’t understand what it all means yet, I’d rather know it by heart than having to keep looking it up, especially when trying to fluently read and write code.

While I have struggled with memorization, what has worked best for me is something called a spaced repetition system, a clever way to use flash cards for any data you want to remember. Anki being the most used software for this.

I got to work and created a deck of flash cards with the instruction abbreviation as the question and the full name as the answer.

• I’ve made this “6502 Instruction names” deck available here to import into Anki, if you are interested.

I tested myself on the entire deck of 68 cards (it also quizzes you on some registers and flag abbreviations), and just as I had hoped I already feel more confident. I got a slight feel for how things are called and what things might be possible.

Because we’re dealing with hexadecimal numbers a lot, I decided to memorize the 256 8-bit values in the same way, from hexadecimal to decimal and vice versa. This was a bit more taxing than the instruction names to be quizzed about, and all this calculating gave me flashbacks to DS Brain Training… But similarly here, I’m already more comfortable converting between “hex” and “dec” now.

• My “Hexadecimal and Decimal” deck is available for download here, too.

Applying some new knowledge

I decided to spice up my previous little program a bit. Starting with adding comments, because I know that last day’s long list of instructions drawing the laser guns was not very kind to read. I happened to find out that the semicolon can be used to comment out any text, so let’s do something about this! I used BRK (BReaK) statements for the first time to stop the program from running at certain points of interest. That way I could easily figure out what was happening there and add in a few comments.

Furthermore, thanks to the Disassembly option I now know which program addresses correspond with which lines in assembly code. And I really wanted to see if I could make the JMP (JuMP) instruction work. Loops are important in pretty much any program! And without much trouble I added a JMP $09c0 at the end and it worked exactly as I thought it would. Why’s that you ask? It’s because rabbits know how to JMP. ^-^

In Easy6502, the $fe register returns a random value for each instruction. A random value equals a random color! So I figured out the position of the laser gun LEDs, and decided to make them throw an RGB rave party—

I won’t deny that I’m quite happy with this result! When there’s so little I can do as of now, small achievements count a lot for me.

• The code is available on my GitHub Gists.

The tutorial - Registers, flags, and weird names

It turns out the SR or Status Register is something the processor provides for you to read from, so that you can find out what certain effects an instructions may have had. The register uses 7 flags, each with its own bit. It’s also refered to as NV-BDIZC. This is a jumble of letters representing each of the flag’s meanings.

Negative - oVerflow, Break - Decimal - Interrupt - Zero - Carry.

I tried to make this easier to remember. Hmm, NV-BDIZC? Let’s pronounce it Envee B’dizuk, an odd name, but it actually made me able to recall the Negative oVerflow etc etc. line of bits in order! Mnemonics are powerful enough to be worth the embarrassing nonsense it makes you come up with.

The tutorial shows how the Carry flag is triggered once the Accumulator overflows past $ff after an ADC (AdD with Carry) instruction. For people who like old games as I do, that overflow is pretty famous for causing all kinds of unintended results. I wouldn’t have guessed there is a flag to catch this type of error.

I did memory monitoring for the first time. I could see a value being put into a memory address amidst a sea of 00s. It’s cool to me.

I got to play around with TAX (Transport A to X), TAY (Transport A to Y), TXA (Transport X to A) and TYA (Transport Y to A) instructions (I’ve already got these memorized c: ). I wrote this for the exercise:

LDA #$fa  ; Load the hex value $c0 into the A register
TAX       ; Transfer the value in the A register to X
INX       ; Increment X register
TXA       ; Transfer X register to Accumulator
ADC #$01  ; Add with Carry the Accumulator
TAY       ; Transfer Accumulator to Y register
INY       ; Increment Y register
TYA       ; Transfer Y register to Accumulator
JMP $0602 ; Loop

It was fun to watch the register values and flags jump around in the Debugger, as pointless as the program itself is. It shows you how the Carry flag is only triggered when overflow happens with the ADC instruction, not the increment instructions.

For some reason, doing any SBC (SuBtract with Carry) instruction triggers the Carry flag, and I do not understand why. I made a timer counting a register down to 0, where it then triggers the Zero flag. Next up is learning how to do something with that!

And that concludes this day. Thank you for being along for this journey with me. ^-^

Firstly as a short introduction, I am not a developer by trade. I appreciate the art of writing software a ton, but my only programming experience has been with the nice and easy to use GameMaker. This time however, I’m curious about approaching it from the complete opposite end.

I challenge myself to learn assembly programming

Just for fun! I’ve always wondered about it! It’s like an intimidating puzzle that my brain may or may not be able to grasp. I’m curious if I can do it, and I’d like to take you along for the ride. Even if I don’t get anywhere, I hope my struggles may be interesting to you.

Being fond of the NES and SNES, and also being curious about the PC Engine, deciding on the 6502 family of processors seemed like a sensible enough choice to me.

After expressing my newfound wish, I was soon recommended the Easy 6502 tutorial. It has a built-in miniature 6502 environment, and this is what I’ll be referring to in the next days of getting started. Its rules are described like this:

Memory location $fe contains a new random byte on every instruction. Memory location $ff contains the ASCII code of the last key pressed.

Memory locations $200 to $5ff map to the screen pixels. Different values ($0-$f) will draw different color pixels.

What I learned from the first tutorial section

Going in, I know that computer processors know of values, and registers to put these values into. The way the values and registers are manipulated is through instructions written as short mnemonic names in assembly language. Hardware has registers that will act on whatever you put into them, which is super enticing to me when I think of games hardware.

One of the only things I know about the 6502 is that it has an “Accumulator”, which I understood as that feature calculators have where they keep track of the previous answer, which you are then able to use for your next calculation.1

In the first section of the tutorial, “Our first program”, I can see that two instructions are used: LDA and STA.

LDA #$01
STA $0200
LDA #$05
STA $0201
LDA #$08
STA $0202

Apparently they stand for LoaD Accumulator and STore Accumulator respectively. Putting a value into a specific register seems to take these two instructions. LDA defines the value and stores it into register A (I suppose for Accumulator), and STA defines where it is stored. I feel like I remember seeing this done on a single line when looking at other assembly code, so I wonder about that.

I never knew that values (“literal number values”) were written as #$xx, while $xxxx portrays a register value.

Playing with my first two instructions

The example program draws three differently colored pixels.

Once I started playing around with the values and got the hang of the screen position and color values, I couldn’t help try to draw something on the black screen. The end result is these blue beams shooting out of laser guns, I guess!

My code can be found here.

Finally, I noticed this section includes challenges.

• Try changing the color of the three pixels.

  • Done!

• Add more instructions to draw extra pixels.

  • Done!

• Change one of the pixels to draw at the bottom-right corner (memory location $05ff).

  • Oh, let me do that.

There you go, that’s no trouble for us now! ^-^

And that is all for today. Thank you for reading!