Twitch.tv Commodore 64 Live Stream

I first decided to launch a Steam channel for the Commodore 64 in May 2017. I saw that the Commodore 64 was very uncommon there and felt a need to push into this expanding market.
Twitch.tv is one of the most popular stream networks in existence. It has captured the attention of many online gamers that now compete for space. You can find literally, nearly any type of game playing live in the network. Although the C64 is such a small market, my goal was to find a niche where I could insert my two cents and years of devotion to this machine. Although I only entered this segment for a short time, I learned how to use the OBS Studio to stream live, made some friends, and just enjoyed the live interaction with people that dropped in now and then. Maybe one day I will return, but for now this short synopsis into what happened in that time will have to do.

To make this an organized state for the viewers I utilized OBS Studio to setup windows for the Commodore 64 environment. My first window captured the VICE C64 emulator display. The VICE C64 is a tool that “emulates” a Commodore 64/PET/128 environment that can accept commands in Basic, Assembly language, or whatever cartridge is connected to the application. The windows are the Scenes that is seen in the screenshot. Unfortunately this tutorial would be sidetracked if I started showing you how to use OBS Studio, but we could always save that for another day. Be sure to check out other videos on this channel to learn more about the VICE C64 emulator.

The second window I setup was for my physical Commodore 64 unit. I figured this was necessary in order to present screenshots taken in true 8-bit color. The VICE C64 is unable to capture this real time.

The third window utilized by OBS is an overview of my computer desktop screen. This is so that users viewing the stream can focus on all of the applications, browsers, etc. that are up on the screen at any given time.

The fourth window that can be switched between is a tool called Regenerator 1.7. This is used to load in BIN files that were created in the VICE C64 or similar emulators. The purpose is to study assembly language listings in an editor window. There are also many other functions that Regenerator can do, but we’ll come to that shortly.

The fifth window that was being used for the stream broadcast is called Infiltrator. This utility allows you to load in PRG files and VICE C64 snapshots. There are some very powerful controls that are packed with Infiltrator, such as a Bitmap viewer, Character Set viewer, Sprite viewer, and so much more. As this tutorial evolves, we will learn more about this amazing application.

I created a Microsoft Word document that contained the source code for Indiana Jones and the Temple of Doom and Spelunker. The goal behind this was to tweak some code routines in assembly language and learn from them so they could help build parts of the Machine Language Project that had begun then. The project destiny was to recreate a Spelunker clone in 100% assembly language. This eventually was going to involve scrolling and fast action gameplay. The vision was to build a team of Developers (Programmers) that would write various parts of the game program and report on assigned tasks via a Google Hangouts live stream.

The next task involved loading the Spelunker game into the VICE C64 emulator to test the gameplay. The game was written in 1984 by Broderbund Software. Broderbund created some pretty facinating games during the Commodore 64 era, such as Load Runner, Prince of Persia, Choplifter, and many more great titles!

In the first part of the stream, I showed the sprites from the Spelunker game using the Infiltrator application using the Sprite editor. A window can be see here that identifies the sprites contained within the source code as they would be resident in memory if the game were actually loaded.

Infilitrator contains various windows in the Sprite editor mode. The top, left drop down selection is called Background Color and is used to control the background color for the game environment. The next selection contains Colors 1-3 with 3 drop down areas in total. These are used to modify the remaining colors for the sprites. It is important to note that the sprite multicolor mode must be active in order to have more than one color on a sprite. The next drop down selection is called Memory. It displays several banks of memory that allow you to navigate through the sprites loaded into Infilitrator. As you scroll through them the sprite sequences are updated in the main window on the right.

The Spelunker game contains a series of characters ranging from the main player, the ghosts (enemies), and various objects that are manipulated. The Infiltrator tool allows you to easily switch memory to view all the corresponding sprites in the window display seen above.

The sprite characters for the game are located at $e000 = $ee00. Each row contains 8 sprites, which contains the different shapes for the animation. These are then loaded into memory locations $7f8 – $7ff (2040 – 2047), occupying a coverage of 8 sprites in total.

While waiting for the game to load, I opened up a Microsoft Word document showing the code for Indiana Jones and the Temple of Doom. The lines were copied from Infiltrator’s Assembly language editor window. The central idea behind using the Indiana Jones game as an example, was to provide a second synthesis into seeing yet another sprite example loaded from memory. Perhaps this was a little too off the topic, but I wanted to demonstrate how multiple examples would appear within Infiltrator.

Next I went onto to evaluate the code by showing an example for the Sprite Shape data locations. Then I explained how the shape data areas are loaded into memory using an assembly language loop. The Basic programming example looks like this.

POKE 2040, byte – byte – represents the byte placed into that memory location (only values between 0-255). Next I illustrated further by showing how shape data would look to Basic. Another example is below.

POKE 2040, (Indy shape 1)

As the bytes change each time they are poked into memory (or using STA $07fb, X) in assembly language, the sprite achieves an animation overlay each time the values alternate in memory. The main idea here is to place the animation shapes one after the other so they load in order to accomplish an animation display. The X can be thought of as a variable that is cycling through a defined point in memory to prefill that area. In this example since we LDA #$07 we only want to capture 8 shape values. Keep in mind that this loop counts down to zero.

Next I provided an example of how the hex values would look. Looking at the screenshot, you can see that the program begins searching at memory location $59f0 (decimal 23,024) to read in the sprite shape data. This is where the program begins loading the sprite data at. The hex values after that which show 88, 89, 00, C4, C5, C4, C5, 00 are the bytes that are saved into that memory location which contains sprite data for Sprite 0 in the game.

Further evaluation can be done using the Hex editor built into Infiltrator. The can be loaded by clicking on the HEX button when the Infiltrator first loads. You will recognize these buttons in sequence showing HEX, DIS, SPR, BMP, C&S, SINE (Hex editor, Disassembly editor, Sprite editor, Bitmap editor, Character set editor, and the Sine Analysis generation editor.

Infiltrator’s Hex editor is a wonderful tool You can use it to view any game that is loaded into memory. It consists of the memory location registers on the left and the corresponding data found in those locations. It contains 16 rows spanning from the left table to the right. In the far right column in those rows you will see the PET Ascii values identified with those values spanning from left to right.

Because the Hex editor did not spit out the correct values, I investigated further by opening VICE C64 and launching the built in Monitor. The code can then be looked up by typing a d (for disassemble). VICE’s monitor will then show a segment of code within small blocks. This makes it easily then trying to break out of a scrolling listing. Another command you can enter in VICE’s monitor is called mem. In the YouTube example, I typed in mem 0406 as an example to investigate the code found there. The code sample for the Indiana Jones example sprite shapes are found by typing mem 59f0. A screenshot evaluates this to be accurate. The values vary since this code seemed to be modifying the game as it was running.

Toward the end of the video, I demonstrated how to change code in the game. Using Infiltrator’s Disassembler, I searched for the background color by setting the Graphics selection (in a drop down menu) and then examined the assembly language statements to locate where they resided. I eventually found them in $5cd8. Using the VICE monitor I was able to tweak this change and see the result. At the Monitor command prompt I entered a $5cd8 lda #$07. This replaces memory location $5cd8 with the new lines of code. The video cut out before I can complete this however.