Code for humans

6502 days of christmas, day 1

Lando Schumpich — Fri, 16 Jan 2026 00:00:00 +0000

Day 1

6502 days of christmas

Lando Schumpich — Wed, 14 Jan 2026 00:00:00 +0000

Introduction

Excel functions as a wee school kid</li>
Html as a teenager to style personal pages in emerging social media (90s/2000s)</li>
10 years of no interest in coding whatsoever</li>
Visual Programming in my studies, which lead to</li>
Custom components written in `python</code>, which lead to</li>`
`Compiled PlugIns written in C#</code>, which lead to</li>`
`Low-ish level libraries written in rust</code></li>`
`Writing a no_std</code> chip-8</code> emulator in rust</code> <- this is the lowest level I have gotten to</li> </ul> where especially the C#</code> experienced helped me then a lot to find my first coding jobs. But still, I never really ventured into even lower level languages like C</code>, or asm</code>.</p>`
`So time to change that: For this (last) years` `advent of code</a> I decided to really</strong> challenge myself and do it in 6502 assembly</code>.</p>`
Advent of code#</span></a> </h2> My relationship with advent of code is so-so: I really like the idea, but I never had the time or interest to follow through with the full calendar. Also the timing kind of sucks, since december is one of the busiest months of the year for me. So looking at the overview</a>, I managed to gather 11</strong> 🌟 stars 🌟 over 2 years I participated in (not counting 2025). So don't expect too much solved days out of this one, especially since I'm going in with exactly zero</strong> prior knowledge of assembly.</p> Why the 6502 assembly flavour?#</span></a> </h2> There are quite a lot different assembly languages one could learn and choosing a first one as an entry point was kind of overwhelming in the beginning. A business-valid</em> choice would have been x86-64</code>, since that is what all the pcs at my job are running. I decided against that, since 1: it's boring to go for the most valuable move and 2: I read multiple times that this flavour of assembly is meant to be compiled to and not</strong> written by hand that much.</p> I looked into old chips that were actually programmed in assembly at their prime-time and the 6502</code> caught my attention. It was used in tons of systems, like f.e. the Acorn Archimedes</em>, or the Commodore 64</em> and learning it's language could open up the skill to write Nintendo Entertainment System (nes)</em> games, which just sounds great. Also the number of opcodes is low, which should translate into a short learning curve.</p> Resources for learning 6502 assembly#</span></a> </h2> There is a lot of very valuable information online if one can find it, as always:</p> 6502.org</a> is a great starting point where I got most of my other ressources of</li> masswerk.at</a> has an amazing overview of the 6502 opcodes, with all their gotchas and modes</li> easy6502</a> was the first ressource that really made it click for me. After going through with it I felt I got the basics down enough to write simple programs myself. Although the difficulty ramps up similarly to the how to draw an owl meme</a></li> 6502.co.uk</a> is on my backlog, if I want to dive deeper</li> </ul> Setting up my dev environment#</span></a> </h2> This was quite annoying. The chip is old and a lot of tech for it was written quite a while ago, so the nice modern toolchains I'm used to were rarely available. Since I did not want to mess around with setting up a toolchain to build 90s/2000s era C projects, I looked at hobbyist tooling developed more recently.</p> One project I found and used for day 1 of advent of code was the rs6502 crate</a>, since that one has an assembler I could use out of the box. Sadly I had some errors running the built-in Cpu</code> emulator, so for emulation I use the mos6502 crate</a>. There probably also are language servers, but since all the assemblers have slightly different flavours of the constructs they support on top of the standard opcodes, I did not bother and just wrote the assembly by hand.</p> During coding the solution for day 1 I quickly realized the need for a debugger, but I could not find one that was easy to install and use, so I postponed it, just printing out register states of the emulator after every instruction. Having a proper debugger from the start would have definitely saved time.</p> The assembler I used initially was very basic, so I ditched it after a while for the customasm crate</a>, which helpfully</em> includes a sample 6502 syntax in it's examples!</p> The stack I ended up with is roughly:</p> mos6502</code> for emulating the 6502 cpu</li> customasm</code> for assembling my handwritten assembly</li> A barebones debugger I begrudgingly coded alongside my assembly attempts, which supports viewing memory, breakpoints and steping back in time.</li> </ul> Here you can see the debugger stopped after calculating the result of day 3 part 1</p> Spoiler ahead</summary> it's 0x4261</code> from memory addresses 0x0000</code> and 0x0001</code></p> </details> The 6502#</span></a> </h2> There are actually multiple versions of the chip, with the first one that saw wide adoption being the initial release of the MOS MCS 6502</code>. Later versions apparently fixed some bugs and also added more opcodes, but I decided to stick to the OC</code>.</p> All variants are 8-bit</em> by default, and through and through. That means all registers are only a single byte wide, with no way to combine them into 16-bit</em> values. This initially was very confusing to me, as all one can do with one byte is address 256 memory locations.</p> Registers#</span></a> </h3> Oh boy, there are almost none and using them has quite the learning curve:</p> ACC</code> the accumulator. Used for arithmetic mostly. Typically I keep the variable I'm currently working on in it</li> X</code> general purpose register</li> Y</code> general purpose register</li> There is also a flags register, which is used for control flow and set automatically inside arithmetic instructions and memory loads</li> </ul> The biggest footguns are instructions that work with one of the registers, but not with another. So f.e. even though most arithmetic only works on the accumulator, there are opcodes for increasing the X</code> and Y</code> registers (INX</code> and INY</code>), but no INA</code>. Another thing that was super annoying is even though X</code> and Y</code> are both kind of general purpose, they are used slightly different when indexing into memory, so f.e. there is LDA (indirect,X)</code> and LDA (indirect),Y</code> which both do something very</strong> different, so one must keep that in mind when deciding on which registers to use for what.</p> Memory Layout#</span></a> </h3> The 6502</code> has a 16-bit</em> adressable memory space, which equates to 65.536 (2^16) bytes of memory. The architecture does not discern between code and RAM</code>, and everything can live everywhere in the whole address space. In practice you need to be careful though to never overlap, as general memory typically does not equate to valid opcodes.</p> There are a few special memory locations reserved for internal functionality of the chip:</p> 0x0000 - 0x00ff -> Zero page. We are free to write whatever there, but it is used for special addressing modes</em> we will need</li> 0x0100 - 0x01ff -> Are reserved for the stack and subroutine stack</li> 0xfffa - 0xffff -> Reserved for reset and interrup signals</li> </ul> In general, the memory is split into 256 pages, which each are 256 bytes wide. Some of the instructions take more cpu cycles when they have to cross a page boundary.</p> Zero Page#</span></a> </h3> The very first memory page from 0x0000 to 0x00ff is special in many ways:</p> A lot of opcodes have a special addressing mode for the 0 page</li> There is indirect</em> memory adressing, where we store a pointer to a memory address at the zero page. Without that there is no way to address the other memory pages</li> Generally all opcodes are fastest (least amount of cycles) when they are executed in ther zero-page-variant</em></li> </ul> </div> rule of thumb</strong> If we can do it in the zero page, we should</p> </div> </section> Opcodes#</span></a> </h3> I'll focus on the opcodes I used most frequently here, for a complete overview, see the amazing resource at masswerk.at</a>.</p> Also in the next post, I'll explain the opcodes that I'm using in details as I go along with the solution to day 1</p> Memory IO#</span></a> </h4> LDA</code>, LDX</code>, LDY</code> -> load a value into a register. Either from memory, or an immediate value</em> f.e. LDA #1</code> loads 1</code> into the accumulator</li> STA</code>, STX</code>, STY</code> -> store the value currently in the register into a given memory address.</li> INC</code> -> increase the value in a given memory location by 1</li> </ul> Register manipulation#</span></a> </h4> TAY</code>, TAX</code> -> Transfer (copy) the value in the accumulator to register X</code> or Y</code></li> TXA</code>, TYA</code> -> Transfer (copy) the value in the register to the accumulator</li> INX</code>, INY</code> -> Increase the value in the register by 1. There is no variant for the accumulator</li> </ul> Control flow#</span></a> </h4> Yeah so control flow is just GOTO</code> with a slight variant of using subroutines</em> via JSR</code> (JumpSubRoutine) and RTS</code>(ReTurnfromSubroutine). Structuring programs and following the flow was very hard for me in the beginning with only this construct.</p> JMP</code> -> Jump to another instruction by literally setting the program counter there</li> BEQ</code>, BNE</code>, BMI</code>, BPL</code> -> Break on a condition and do a jump to the memory address. Conditions are equal, not equal, negative, positive (in order)</li> JSR</code>, RTS</code> -> Jump into and return from subroutines. Somewhat similar to functions in high-level</em> languages</li> BRK</code> -> Kill the whole program (but keeping memory and registers intact). I use that to signal that the program is done</li> </ul> Day 1#</span></a> </h2> I'll go over my solution to day 1 in the next post</a>, to keep this one focused on the general setup and information about the technology itself.</p>

Setting up my blog Lando Schumpich — Tue, 13 Jan 2026 00:00:00 +0000 Introduction#</span></a> </h2> After I killed my personal website somewhere around 2023, since I never really found time to update it anymore, I have been missing a place to give as a home to my loose thoughts. Consider this blog that place and I hope I will keep writing here in the future.</p> Research#</span></a> </h2> I took some time looking for a good solution for my new personal site, focused on blogging</strong> and ease-of-hosting</strong>. My priorities where roughly:</p> Should generate a static site</li> Should be easy to set up</li> Should be maintained, or at least reasonably popular</li> Should have a focus on blogging / personal sites</li> Should have good enough themes out-of-the-box</em> so I don't get distracted theming the site immediately</li> Should have support for atom</em> / rss</em> feed generation from my posts</li> </ul> A very good site I found when searching was Jamstack</a> and after looking through many different generators I finally landed on Zola</a></p> Setting up Zola#</span></a> </h2> Getting started with Zola was both easy and a bit confusing:</p> Installing and getting it running is super easy</li> Theming the size is very confusing, as you don't just apply a theme, but also get new content templates you have to adhere to. At least I found it to not work with the templates from the blog example from the zola documentation</li> </ul> I installed the first minimal theme focused on blogging that I liked terminus</a></p> Installation#</span></a> </h3> I'm sadly still on windows, but at least installing zola there is as easy as it gets using winget</code></p> winget install getzola.zola </span></code></pre> And that's all, now we are ready to create a new site by running zola init</code> inside of an empty folder</p> Choosing a theme#</span></a> </h3> The official docs are a trap</strong>, since they will have you set up your own templates for blogging. This works fine as a first test, but when you then use a theme, it will not work, as those come with their own templates.</p> So rather choose a theme right away, install it depending to it's documentation and look how they have setup their templates.</p> For terminus</code> (and I think most other themes)</em> the best way to install is to clone a git submodule</code> into the themes</code> folder.</p> git submodule add https://github.com/ebkalderon/terminus.git themes/terminus </span></code></pre> Next steps#</span></a> </h2> Other than filling up the site with some posts, I also want to look into other things:</p> Structuring blog posts into long-form projects for themes I'm interested in, or open-source code I'll be writing over long time periods</li> Actually hosting the site, either on Codeberg pages</a>, or some cheap hosting service</li> Venture into self-hosting and write about that</li> </ul>