https://github.com/Arcadable
November 2019, I quit my job and decided to devote some months to teach myself a new skill. One that I have wanted to learn for a long time. At the time, I worked full time as a web-developer. Before that, I studied Software Engineering. And before that, I have always been playing around with electronics and software as a kid. So, I felt pretty confident with my software development skills.
However, there was always this magical thing called hardware which I use every day, but have no idea how it actually works. As a software developer (and especially web-developer), there is no real need to understand hardware anyway. Since all web development code is so high level, it rarely happens that a problem with your software is hardware related.
As a consequence, I never took the time to understand hardware and general electrical engineering beyond what we are taught in high-school. That is what I wanted to change. I set for myself a ridiculous goal that seemed really far out of my skill-set a the time. Then.. I simply started experimenting. My plan was just to see how far I could get before running out of savings or motivation. I never expected to actually reach my goal, but somehow, I did.
This is the result:
My ridiculous goal was to create a 4 player arcade game console from scratch. Using a micro-controller as the brains, and LED-strips for the display. Using one joystick and four buttons as input per player on each side of the table, the players are able to control a game which is dynamically loaded into the system from a memory chip. Which gives the console a similar user experience to how old-school gaming consoles used to work. Although thus far, I did not have to blow into the card slot to fix any bugs.
To my surprise.. I actually managed to complete the project. It took me about 3 full-time months of cycles of experimenting, failing, reading, giving up and trying again the day after. I wish I would have kept track of my hours so I could tell you how much effort I put into this. I would guess it is probably around 800–900 hours. (Assuming working on this 6/7 days a week for 8–10 hours a day, which is probably pretty close.)
I tried to document the process of my experimenting all the way up to the end result by taking photos and videos. This post is my way of documenting this project and experiences for myself. And for you, if you even made it this far already, hopefully I can inspire you to take on a similarly ridiculous project yourself too.
Getting started
Like I said at the start. At the beginning of this project, I had not much more knowledge of electronics besides an incorrectly memorized Ohm’s law formula. So, first I should learn how electronics really work in practice, before I could even think about attempting to put together a gaming console. I had no idea how I’d even turn on an LED using a micro-controller (MCU). So, that was my first step: order some basic electronics and an MCU to play with. Just to start, I would try to power an LED. I’m pretty sure that my first attempt to power on an LED resulted in a burned out LED. This is not documented on camera, so let’s pretend that did not happen.
This was the first big milestone. Now we know how to get code to run on the MCU. We also learned how we can use transistors as a simple electrical switch to turn on an LED. How exciting!
EEPROM adventure
Part of the project was to be able to write game logic onto memory chips (EEPROM). Which was intended to be read when the game-card is inserted into the system.
Something that hurt me in the long run, was not reading up enough about which kind of EEPROM should be used in this project. In my excitement, I bought some old parallel EEPROM chips (W27C512).
In order to read or write these, we need to be able to set 16 lines high or low. Without using up all my output pins on the MCU, the next logical thing to learn was how to use shift registers.
The gif on the right(Img1) is the result of that shift register adventure.
Using only a couple of pins, we are able to individually control all of the 16 lines.
Now let’s use this new thing we learned with the EEPROM! … yea.. no. I never ended up being able to consistently write data to the EEPROM. This type of chip needs a 12–14 volts input to delete or write bytes. I attempted this using transistors as switches for the higher voltage input. And as far as I know, it SHOULD work. Except it didn’t. I am still not sure what the problem was. Img2 shows the setup I was using to try to read/write bytes to/from the EEPROM.
After finally reading more into this, it turns out that parallel EEPROMs are not used as much anymore. The community generally prefers using I2C serial EEPROMs, for which it consequently is also much easier to find tutorials on. (SO to this amazing tutorial on Sparkfun).
Img3 shows my setup for reading and writing data to the serial EEPROMs… MUCH simpler, way more reliable. What I learned from this is that I should try to not get too excited about ordering parts and trying to push the project forward too quickly. We ended up spending probably 1–2 weeks on the parallel EEPROMs, and in the end, we didn’t use them at all. Although we did learn a lot about the electronics and reading datasheets (which is an entire skill on its own) while doing it. So it was not a complete loss of effort.
So how are we actually going to do this?
We can now read and write to the memory chips. What is the next step? At this point, it might make sense to describe the plan I had for the game console in more detail with the help of some drawings.
This is the general plan. It will be a gaming console with controls for four players. Each player has one joystick and some buttons to play games with.
Circled with red is the game card slot. This slot will have four metal contact points that are used by the console to read the serial EEPROMs in order to load games into memory.
Highlighted in the green area, you see how we plan to build the screen with LED strips. We want a pixel on the screen to be an actual square spot of light, instead of a blob of light mixed together with all the other blobs.
To get the right effect, we use this layout to separate light sources from each other, and also diffuse the light coming out the top of the screen. (The white strips underneath the grid is supposed to represent the LED strips)
I decided to make it a 42x42 LED display. Which ends up being 1764 LEDs. I chose the number 42, since it would make the table about the right size to stand around with four people.
Powering this amount of LEDs is a challenge on its own. At max brightness, an RGB LED takes 60mA of current. (showing white at max brightness). Multiplied by the total amount of LEDs, this results in a max current draw of 105,84A at 5v! In order to come close to this amount of current, we got ourselves a SE-600–5 MEAN WELL power supply. This can supply up to 100A of current. Which is not the 105A that is theoretically possible. But I don’t expect to show pure white screens at max brightness in games anytime soon. Besides that, we will be able to limit the brightness in software. We will also add fuses to make sure we still don’t accidentally exceed this 100A limit.
Building this actual screen is something I will get back to later in this post. First, it was time for some more prototyping. Let’s see if we can actually get a small LED screen working first.
This 3x3 prototype is built using some pieces of cardboard to separate the pixels, and a piece of regular printer paper on top for light diffusion. Works great! We got a nice proof of concept.
To control the LEDs using the MCU, we use the FastLED library. Turns out however, that with a single data line to control the LEDs, we can’t update 1764 LEDs fast enough for games. Given a frequency of 800kHz, it’s possible to achieve a framerate of about 17 frames per second. Not exactly what we are aiming for. Personally, I like having at least 60FPS. Fortunately, this is possible. Simply by using more than one data line. A 42x42 display can be neatly divided into 7 equal display sections. Each of these sections can be controlled separately with its own data line. Using the Parallel Output functionality of the FastLED library on a Teensy 4 MCU. By using 7 data lines, we will be able to achieve a maximum refresh rate of around 120FPS!
I did not plan this, but by pure chance I actually chose that exact MCU at the start of the project. I expected to need the fast processing speed that this MCU offers, in order to run the games smoothly. Img4 on top is already controlled using the parallel output functionality. However, in that prototype, we are using only 2 data lines. Just to testing if it all actually works like they say it does.
How will we execute code from the EEPROM?
Alright, at this point, we are able to read and write to the EEPROM, and we have a working proof of concept for the LED display. What’s next?
There are just 2 big technical challenges remaining: organizing a way to manage all player inputs (buttons and joysticks). And also we need to figure out how to actually execute game-logic instructions from the EEPROM, and show the result of these instructions on the display.
I was still waiting for the orders of the buttons and joysticks to arrive. So first, we can focus on executing the game logic from the EEPROM first.
There are multiple ways we can execute instructions (code) from the EEPROM. However, we should set some requirements first:
- 1) The code should be easy to write.
- 2) The code should be small (file-size).
- 3) The code should be able to interface with existing code libraries such as FastLED, to reduce my workload.
- 4) The code should be able to load into running memory as quickly as possible, to reduce loading times.
- 5) The code should be able to be emulated on a regular PC, to test games.
- 6) The solution should be performant (achieve at least 60FPS).
- 7) The solution should not require a large amount of extra hardware to be purchased.
- 8) The solution should work on the Teensy 4.0 MCU.
- 9) The solution should be easy to implement.
I came up with 4 different ways to run code from the EEPROM:
- Write regular compiled Arduino code to the EEPROM. Then get an external Arduino programmer to read compiled code from the EEPROM and reprogram the Arduino on the fly each time a new game is loaded.
- Load assembly code into RAM and execute it from there.
- Use an existing code interpreter such as ArduinoBASIC or Bitlash.
- Write my own custom code interpreter.
This is a quick summary of how the 4 different solutions compare for this project:
(1) File-size for the solution with the external programmer is terrible. Any code libraries that we are using for this project need to be stored on the EEPROM alongside the game logic. Each EEPROM would have their own copy of the FastLED library in order to display the game state. This is not great. We could probably get around this by somehow adding a base code to the external programmer, which is then joined with the EEPROM code before programming the Arduino. This would be a high risk challenge, since this is not something you can easily find a tutorial for online. We would probably waste too much time on this.
(2) Running Assembly from RAM is a great option. One which I have considered going for. The fact that it is difficult to write could be mitigated by using some higher level language such as C which is then compiled into the correct Assembly code. However, because of the uncertainty if this will easily interface well with other libraries on the Arduino, made me decide against this option.
(3) Using an existing interpreter is a pretty good solution too. However, as far as I know. All of these interpreters run based on strings of characters. These long strings need to be written to the EEPROM. This is not a huge problem. But it is definitely not the best way to keep file-size to a minimum. Besides that, it is not clear if these interpreters could interface with Arduino libraries. For these reasons, I did not think using existing interpreters was the best solution.
(4) Finally we have solution 4: creating our own code interpreter. All of the requirements are met, because it would be completely up to me how I implement the interpreter. It would indeed be performant, if I make sure that the interpreter is performant myself. Yes, the file-size would be small, and it is indeed easy to write… if I make sure it will be myself. In other words; we will have complete control of everything. And it will work out perfectly, if I put in the effort to make it work out. The only huge disadvantage of this solution is that it will take a long time to develop. However, maybe you remember the part where it was mentioned that I dedicated around 800–900 hours to this project. So obviously we decided to go for solution 4; create our own code interpreter. Time is not an issue. I took this opportunity to learn how programming languages are created. I will learn why certain design choices are made in said programming languages.
The birth of ArcadableScript.
The general idea of how this interpreter should work is pretty straight-forward. We won’t go into too much detail of how the interpreter works, as at the time of writing this, I am planning to completely rewrite the interpreter so it is more efficient and easy to write code for. However, the basics remain the same. The interpreter will execute a simple code loop for every game step as such:
A big drawback to this is that the input and game-state are only checked once per frame. Which is fine for games that do not require quick reaction times. However, for other games, it is not possible to react in between frames. This is something I will address in the next version of the interpreter.
This flowchart to the left (Img5) shows how I plan to update the interpreter in the near future. Creating 2 separate loops for the game-state and game-frames. This will allow us to update the game-state hundreds of times a second, while only updating the display 60 times a second.
Unfortunately, it is not possible to run actual hardware multi-threaded code on the Teensy 4.0. So we will not be able to run these 2 loops in parallel. But I’m sure we will figure something out.
Some development later, I managed to write 2 simple programs using our own made up bytecode language. Using actual raw numbers as input for the interpreter, in order to keep the file-size as low as possible. Consequently, I ended up finishing these 2 programs by literally writing down lists of numbers that the interpreter could understand. Just to give you an idea of how readable this bytecode was. These were the actual instructions used to run the example where I move a dot around on the display:
// TODO: Write/read all untyped... data to/from ROM
int untypedGamestate[] = {
0, // Previous time, to keep track of game time/framerate.
0, // Player position x.
0, // Player position y.
0, // Player R color value.
0, // Player G color value.
255, // Player B color value.
};
int untypedValues[][3] = {
// ID, Type, Value
{0, 0, 0}, // Move up button value
{1, 0, 1}, // Move right button value
{2, 0, 2}, // Move down button value
{3, 0, 3}, // Move left button value
{4, 3, 1}, // True/1
{5, 3, 0}, // False/0
{6, 4, 0}, // Current millis since game start
{7, 2, 0}, // Gamestate previous time
{8, 2, 1}, // Gamestate player x
{9, 2, 2}, // Gamestate player y
{10, 2, 3}, // Gamestate player r color
{11, 2, 4}, // Gamestate player g color
{12, 2, 5}, // Gamestate player b color
{13, 3, 1}, // Move player up after button press boundary check
{14, 1, 0}, // System config screen width
{15, 1, 1}, // System config screen height
{16, 3, 3}, // Move player down after button press boundary check
{17, 3, 5}, // Move player left after button press boundary check
{18, 3, 7}, // Move player right after button press boundary check
}
int untypedCalculations[][5] = {
// ID, ending, valueLeftID, calculationRightID, calculationOperator
{0, 0, 9, 1, 1}, // Current player y position - 1
{1, 1, 4, 0, 0}, // True/1
{2, 1, 0, 0, 0}, // Up button
{3, 1, 2, 0, 0}, // Down button
{4, 1, 5, 0, 0}, // False/0
{5, 1, 9, 0, 0}, // Current player y position
{6, 0, 15, 1, 1} // screenheight - 1
{7, 0, 9, 1, 0}, // Current player y position + 1
{8, 1, 3, 0, 0}, // Left button
{9, 1, 1, 0, 0}, // Right button
{10, 1, 8, 0, 0}, // Current player x position
{11, 0, 8, 1, 0}, // Current player x position + 1
{12, 0, 8, 1, 1}, // Current player x position - 1
{13, 0, 14, 1, 1} // screenwidth - 1
}
int untypedInstructions[][10] = {
// ID, rootInstruction, conditionCalculationLeftID, conditionCalculationRightID, conditionOperator, conditionSuccesValueLeftID,
// conditionSuccessCalculationRightID, hasFailedCondition, conditionFailedValueLeftID, conditionFailedCalculationRightID
{0, 1, 2, 1, 0, 13, 0, 0, 0, 0}, // move player up when up button is pressed.
{1, 0, 5, 4, 1, 9, 0, 0, 0, 0}, // move the player up when the boundary is not reached.
{2, 1, 3, 1, 0, 16, 0, 0, 0, 0}, // move player down when down button is pressed.
{3, 0, 5, 6, 1, 9, 7, 0, 0, 0} // move the player down when the boundary is not reached.
{4, 1, 8, 1, 0, 17, 0, 0, 0, 0}, // move player left when left button is pressed.
{5, 0, 10, 4, 1, 8, 12, 0, 0, 0}, // move the player left when the boundary is not reached.
{6, 1, 9, 1, 0, 18, 0, 0, 0, 0}, // move player right when right button is pressed.
{7, 0, 10, 13, 1, 8, 11, 0, 0, 0}, // move the player right when the boundary is not reached.
};If you take the time and look carefully at this code. You will also be able to understand how this early version of the interpreter worked. The general idea of using “values”, “calculations” and “instructions” still stands in the current version. However, much has changed. We don’t have a fixed list of “gamestate” values anymore, they are simply part of the regular list of values now. Besides that, we separated “conditions” from the instructions. This way we are able to re-use conditions in the code. Which reduces the file-size.
Let’s not go into any more detail on how the interpreter actually works. Since much of this will change soon in a rebuilt version.
Now we are at a point where we know how to read/write EEPROMs, and we can run instructions based on arrays of simple numbers. The next logical step is to remove the hard-coded lists of instructions from the code, and write them to the EEPROM. From there on, we can attempt to read and run the instructions that are saved to the EEPROM.
At this point, I have every proof-of-concept that I need to actually start working towards the final result!
Obviously, every single part of the prototype that we created so far needs a lot of work still. In my mind however, the biggest challenges were solved. All I needed to do was to expand on what I already had. Easy!
Building the LED-strip display
Building the display was a lot of work. And I really mean A LOT of work. It started off with having to solder some wires to the 42 individual strips. Each strip needing 3 wires on one side, and 2 on the other. So about 200 wires in total. Having not much soldering experience before this project, you could definitely see my soldering work increase with quality the more time I spent doing the soldering. Of course I ended up re-doing a bunch of the first LED-strips, because I was not happy with how they turned out. All part of the learning process!
Next step. We stick all the LED-strips on a big wooden plate. In hindsight, it would have been a better idea to find a metal plate to stick the strips on for better heat-conductivity, as the display currently does get warm (40–50°C) when doing full-brightness for about an hour. But this doesn’t happen too often anyway. So not a big deal. However, it is something I would change if I attempt this for a second time.
Next up, we attach some larger diameter wires to all the positive and negative wires of the LED strips. Making sure the large wires are rated to be able to supply the max 100A safely. To be extra sure, we also add a 15A fuse for each display section.
At this point, we are able to start making our first attempts at controlling the display. After a lot of failure and tinkering with software settings and wires. I was finally able to display a solid color on the display without any distortion or interference. This took me a long time, and it was still far from perfect. I continued having problems with distorted signals for a while, until I posted a question about it on electronics.stackexchange.com. The very nice people over there helped me diagnose the problem. I still don’t fully understand the problem, but attaching negative leads directly alongside the data-lines from the MCU-ground to the ground terminal next to the data-input on the strips solved the issue. Since then, we never had any distortion problems anymore on the display.
As seen in the illustration from before, we have 2 layers of material that go on top of the LED strips.
For the material on top of the grid, we need something that is strong, transparent but also diffusing. However I did not want to use glass, as it is expensive and easy to break. I decided to go for general purpose clear polystyrene. To make it diffuse the light, I sanded it with fine sandpaper to the point where you can’t see through it anymore. Simple as that.
It took me a lot more effort to build the grid that sits directly on top of the strips. I considered ordering a custom build grid with the right specifications directly, but I was quoted around 500 euro. Which was not worth it in my opinion. So we have to build it ourselves. In order to do this, we need thin (max 2mm thick), strong, opaque, white plastic strips. Quite a lot of requirements. So it took me a while to find the right material. Turns out, old sun-blocking window slats which we had lying around were the perfect kind of material.
First, we made a little jig to make consistent straight cuts on the wide slats. This resulted in just enough smaller strips of plastic. Now, we need to cut notches halfway through each strip at the exact right positions. This is necessary to put the pieces of plastic together to form a grid. This is what I was doing in the third picture. Before you do this, you have to be sure that the width of the saw is the same or a little bit wider than the width of the strip that you are cutting into. Otherwise you will not be able to put the puzzle together later on. In our case, a metal cutting saw turned out to be the perfect width.
On the fourth picture you can see the result after putting all the strips together to form the grid. This was very frustrating tedious work, but the grid turned out very sturdy. The squares generally also look like they are about the same size. No big inconsistencies between square sizes, which would look odd on the display, so that turned out pretty good. Happy with the grid.
Now, we added a wooden ring around the grid which has multiple purposes. First of all, it holds down the clear polystyrene plate on top of the grid. It makes sure the grid does not shift position. And the wooden ring also presses down on the wires so that they are more secure, less likely to accidentally tear off (which did happen a couple times while moving the display).
In this picture, the polystyrene plate on top of the grid is dulled with fine sandpaper. Notice how you can barely see the grid anymore, this is exactly the effect we are looking for.
After spending hours on hours of experimenting with how to properly control the display, we finally got it working. Maintaining signal integrity was a huge problem. But like I said earlier, the community at electronics.stackexchange helped me out!
The display is bright, a lot more bright than I expected. I should have seen it coming though, when ordering a 100A power supply to run the display.
As mentioned multiple times already. We are using the FastLED library to control the LEDs. What I did not mention before is that I also use a modified version of Jürgen Skrotzky’s FastLED-GFX library (which in itself is a port of the Adafruit-GFX-Library) to easily draw shapes and whatnot on the display. The modification to this library is minor, but necessary to make the interpreter talk to the library in a nice way.
Braaaains..
One of the last technical challenges we need to solve before we can finish this project. We need to finish the brains of the console. Get it all in a nice compact package. But before we can do that. We need to figure out how to deal with all the player input signals. As a reminder, we are dealing with 4 buttons and 1 joystick per player. So, that is a total of 16 digital inputs, and 8 analog inputs. The MCU never has enough pins available for this kind of input, besides the 2 data pins that are already in use for reading the EEPROM and the 7 parallel data pins necessary to drive the display.
To solve this, we use a couple of shift registers for the digital inputs. And we use an analog multiplexer for all the analog inputs.
This is starting to get messy. Let me try to explain what is going on in this picture from left to right. On top of the left breadboard we have the 7 data lines that are used to control the display. Underneath that is a section where the EEPROM can be inserted and read.
The top of the middle breadboard has the analog multiplexer. This multiplexer can take up to 16 analog inputs, and depending on the inputs on the multiplexer, wire one of the analog signals through to the MCU. This way, you only need 1 analog input pin, and a couple of digital output pins to handle up to 16 analog inputs. Currently in this picture, I believe no analog input is actually connected to the multiplexer.
Underneath the multiplexer, we have the Teensy MCU.
On the right breadboard we are handling digital input signals. In that picture the 16 digital inputs are simply wired to ground. I was still waiting for the actual buttons to arrive, so this was how I tested all 16 digital inputs. With the help of the shift registers, I believe only 4 pins were needed to manage all digital inputs.
This is just one huge fragile mess. We need to make this more compact, and also less likely to break by breathing on it in the wrong way. So I ordered some prototyping boards and started soldering again!
This was definitely a soldering challenge! Although a great way to learn how to do precise soldering when putting these pieces together.
To come up with this layout, I used the fragile breadboard wire mess as an example. Then tried to come up with a layout that made sense, to keep components that need to talk to each other as closely to each other as possible. That way, I tried to prevent having to cross wires over each other a lot. In hindsight, it might have made sense to use some modeling tools to design this. But it turned out fine anyway. ¯\_(ツ)_/¯
I decided to go for a 2 layer design. On the bottom prototyping board, all the input processing is handled. On each of the 4 input connections, I have 8 input lines (1 ground, 1 positive, 4 digital input, 2 analog input). The MCU communicates with this bottom layer using the 4 connections near the shift registers and the 4 connections near the multiplexer.
On the top layer, we have the power input on top, then on the right we have the 7 data output lines for the display, on the bottom we have the terminals necessary to read EEPROM. And then finally, in the middle we have the MCU of course.
In between the main controlling boards and the player inputs, I created some intermediary boards to reduce the amount of necessary wires on each side from 12 to 8 as it is not necessary to have 5 ground wires going from the main board to the controls. A single ground that is used for all buttons and the joystick works just fine. So 4 of these intermediary boards in total. I love how you can see the gradual improvement in quality for each board that is put together.
After never receiving the initially ordered buttons. I ordered a new set of buttons from a different vendor and promptly received them a couple days later. Allowing me to finally start testing with all buttons.
At this point, I also made the first actual game you could play on the console. Yes, I’m calling it a console now.
I was able to do this, since I had also been making progress with the interpreter while working on the display. In particular, I made progress with the development experience while writing code. This development work was not as visually appealing. So it did not end up getting documented very much.
I made a simple development environment for writing code that could run on the console.
This development environment runs in a web-browser, and it allows you to write code for the console without having to deal with chaotic lists of numbers as you saw before. Besides that, I also created a console emulator that runs in the same web-app.
Being able to emulate games for this console in a web-app was a huge time saver. Since debugging on the PC is a lot more simple than trying to do the same thing on the MCU.
The emulator is not perfect. There are some bugs still where the emulation is not exactly the same as the real version. I will try to fix this in the future when writing a new version of the interpreter. Having to maintain 2 versions of the interpreter (one written in c++ and one in TS) is a bit of a pain in the ass. But worth it.
Putting it all together.
Everything is ready. We are able to display images based on game-logic from EEPROMs, and we can handle player input from buttons and joysticks. Now we need to put it all nicely together in a sturdy table.
I started of by drilling some holes in aluminum plates which will hold the buttons and joysticks. We can then fit these metal plates in routed pieces of wood. This way, the plates will nicely sink into the wood. This will protecting the players from accidentally scratching themselves on the metal.
Building around the display and adding some sturdy foldable legs (for storage). Painting the metal plates black looks really clean. This project is really starting to look like it is getting close to completion.
I was surely wrong, thinking the project was almost done. This is what the console looked like for about an entire month.
Putting it all together, realizing a button is not working. Taking it apart again. Fixing the button. Everything seems to work. Realizing a joystick is not working. Taking it apart again. Then at some point you finally get all the buttons and joysticks working. At which point one of the LEDs will stop working. And in order to fix this, you need to disassemble the entire console and reassemble from the start all over again. This went on for about a month until we finally got everything put together in working order.
The result.
Its finished! At this point I had been working on this project for about 3–4 months. So understandably, my motivation to continue improving on the interpreter, painting the wood and developing more games had kind of run out. It has been about a month since I have worked on this project now at the time of writing. So I finally mustered up the motivation to write this documenting blog post for myself and you, the reader. Although I do not expect anyone in their right mind to actually read all the stuff I wrote down. I hope you enjoyed scrolling through the progress pictures.
If you really read all of this, you might also be interested to take a look at the Github repository for this project. All my code is open source of course! https://github.com/Arcadable
Future work I will do on this project is:
- First of all, I should make a nicer looking game card for the 4-player pong game in that last video. Currently it is just a piece of cardboard with folded up pieces of aluminum foil for the contact points.
- Besides that, I want to give the console a nice looking paint-job. Initially, I planned to do this together with very skilled friends who enjoy painting. However, this is not possible for a while during the pandemic.
- Finally, as I mentioned a couple times already. I am going to rewrite the interpreter in a more efficient way. I will also update the development environment to be more easy to develop games on. Currently, the design of the web-app is hindering productivity.
