Assembly 6502 as Intro to Game Design - Using Atari 2600 Games to Strip to the Essence of Design
Or how I decided to write a course on Assembly 6502 for game design students
I turned 46 this year and I find myself teaching introductory game design for the first time in years. I like teaching design because it helps focus new learners toward the melding of humanity and technology rather than learning how to do programming. I am often a weirdo in traditional programs, especially my home disciplines of Sociology and Human-Computer Interaction:
- I don’t fit in in Sociology because I primarily talk about material culture as culture.
- I don’t fit in with HCI because i’m simultaneously too focused on old technology but also too deep into the social strata to be fully technical.
- I work primarily on disaster and emergency management where culture primarily disappears for a time and technology cannot work but games / exercises are how we prepare for those spaces.
As Emergency Management primarily learns through tabletop exercises, uses mostly older tech, and has a technical issue mired in the social strata, being in a games program made sense. I can call some old tech retro or vintage and some things tabletop games interactive media. It’s an island of misfit toys just right for the kind of fun i’m interested in.
Speaking of old tech, the Atari 2600+ was released last year. This means that for the first time since 1991, the Atari 2600 is not only an active system, but it also uses the old hardware so all old Atari games can be reprinted and sold in stores. It also connects to HDMI televisions without the use of adaptors that destroy how the games look.
This also means that we can not only make new, old games, but print them to a board, and sell them on Etsy, Ebay, Kickstarter, or wherever folks can sell things besides or in addition to the amazing Atari Age store.
At the same time, there is a noticeable decline in the creativity of video games in general. Concomitantly, the board game space is slowly declining under its age, lack of quality control, and (personal opinion here) over-focusing on turn 1 rather than end game. This was also paired with a lingering effect of COVID-19 where folks looked backwards to old and retro games resulting in a surge for the cost of those products. That retro phase continues unabated and in a lot of ways is getting far worse in terms of cost though the absolutely unabashed golden era of micro-tabletop rpgs continues to skew this trend somehow.
The result is a perfect moment in time to teach potential video game designers retro-based development. Not only is retro development a game in and of itself, it also highlights the medium’s design potential, growth as an artform, and can help students create a product from development to production to publication.
Simultaneously, teaching vintage or retro design will allow me to develop my programming chops, learn Assembly, and eventually allow me to focus on an Assembly-inspired version of TinyOS as I seek to develop no-nonsense, indestructible, low-energy computing meant for first responders.
But it’s not enough to have a concept, you have to do it. So where do you even begin?
I waffled on this starting point quite a bit. For example, the NES uses Assembly 6502, so does the Commodore computers, and the Tamogatchi line of toys. I could push toward Intellivision I suppose, but it’s so mired in legal limbo that it just isn’t worth it. Same with the NES as taking apart those games and offering source code could get me into some Cease and Desist spaces and i’m not really looking to make Mario angry.
As a result, the most legally untroublesome space is to engage with the 2600+ and go from there. As mentioned, the system is in current active status. However, here is where we get into fun: how do we begin teaching how to write an atari game to students used to compilers and interpreters? How do we essentially reverse the pipeline that Mark Cerny talks about in his post mortem of Marble Madness:
You can’t really start with “Hello World” because…well, it’s kind of insane from the perspective of current coding schema in the obscene shadow that is structured programming. Just getting to the place where letters appear on screen is nuts. To do it, you have to situate things like waiting for the scanline, dealing with how things are reflected or repeated in a playfield, and assigning what the literal binary expression is for each of the Atari’s 160 pixels across by 192 pixels down.
This code skips the weird PF0 space where it has 4 bytes you could use while 4 other bytes are reserved for…stuff. It also skips declaring where to send what, when as you need to sometimes wait for the scanline and in other times, push things quickly to race the beam. In the end, just getting the letters hello world to appear looks a little like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
Phrase:
.BYTE %00000000 ; H
.BYTE %01000010
.BYTE %01111110
.BYTE %01000010
.BYTE %01000010
.BYTE %01000010
.BYTE %00000000
.BYTE %00000000 ; E
.BYTE %01111110
.BYTE %01000000
.BYTE %01111100
.BYTE %01000000
.BYTE %01000000
.BYTE %01111110
.BYTE %00000000
.BYTE %00000000 ; L
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01111110
.BYTE %00000000
.BYTE %00000000 ; L
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01111110
.BYTE %00000000 ; O
.BYTE %00000000
.BYTE %00111100
.BYTE %01000010
.BYTE %01000010
.BYTE %01000010
.BYTE %01000010
.BYTE %00111100
.BYTE %00000000
.BYTE %00000000 ; white space
.BYTE %00000000
.BYTE %00000000
.BYTE %00000000
.BYTE %00000000
.BYTE %00000000
.BYTE %00000000
.BYTE %00000000
.BYTE %00000000 ; W
.BYTE %01000010
.BYTE %01000010
.BYTE %01000010
.BYTE %01000010
.BYTE %01011010
.BYTE %00100100
.BYTE %00000000
.BYTE %00000000 ; O
.BYTE %00111100
.BYTE %01000010
.BYTE %01000010
.BYTE %01000010
.BYTE %01000010
.BYTE %00111100
.BYTE %00000000
.BYTE %00000000 ; R
.BYTE %01111100
.BYTE %01000010
.BYTE %01000010
.BYTE %01111100
.BYTE %01000100
.BYTE %01000010
.BYTE %00000000
.BYTE %00000000 ; L
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01000000
.BYTE %01111110
.BYTE %00000000
.BYTE %00000000 ; D
.BYTE %01111000
.BYTE %01000100
.BYTE %01000010
.BYTE %01000010
.BYTE %01000100
.BYTE %01111000
.BYTE %00000000
Now, there are other ways to do this and over the years, there’s been an effort to make things like a BASIC converter for Assembly. So, you can map to a character map oor use the full power of the 6502 Chip because the Atari actually uses a stripped down version that is missing 13 or so pins that limit memory and other structures. As a result, the Apple 2E or NES can do some mapping with their early graphics chips; however, this course is meant to be raw and show the earliest days in design more directly. It is a harsh proposal with 2 distinct goals:
- How does the code we write manipulate a screen?
- What happens if the game itself is writing the code to make a game?
For 1, you could point to Assembly or the other interpreted languages like Python. These are fine but they are still removed far from machine code. Instead, I want to show a literal moment in time when programming WAS changing the machine directly.
It’s older now and mostly forgotten, but I think a lot about the Degenerator commercials in GTA:VC; though, I believe they actually released these games in GTA5 or GTA:Online.
These games make fun of the simplicity of the concept of games and yet, almost all of these games have stood the test of time in some way shape or form.
At some point, I was running a course devoted to PICO-8 and I still love that course. Strangely, it’s still running and hasn’t changed in ages. Those posts are:
The neat thing for that course was mostly in learning how to engage with folks who had never thought about coding before. I would have them read code, I would have them write and parrot what was on my screen in an effort to make the computer far less scary. As a result, I have gotten comfortable with teaching new bees. I will be distinctly uncomfortable in this first semester especially but I am excited to explore this space more directly.
For this course, i’ll most likely be teaching folks who are far better coders than I am. I can muddle my way through a lot of coding but teaching it will require a level of expertise i’m only now starting to understand. Because of this course, I am able to accelerate my own capacity to code things…though that capacity will be very old, very limited systems.
My hope is that i’ll be able to start making fully formed, original games, by the end of 2025. Unfortunately, this will eventually mean I have to tackle bank switching and that prospect currently scares me.