Back in 2016, I began my first Commodore 64 project on YouTube where I managed a team and worked on a C64 assembly language project known as Spelunker Clone. We were focusing on recreating the game Spelunker, which we dubbed it’s ‘Clone’. After months of studying code that was developed by Siggy and extracted from the Endurion game example, therefore I am proud to announce the launch of the C64 Assembly Language Project 2020!
So in this series, we will be enhancing the code and refine it until we have a game up and running. Currently, the map background has been swapped, and the player can now jump (although it is still quite buggy). When he jumps, he can spring pretty high and often off the screen. Checking for proper deltas in jumping range should solve this issue.
Note: This Game Series will require signing up for our Free Membership service below. Or you can use the Membership Login link here.
Note: This project has been delayed to an error with the email filters. It is my hope this has been corrected, so please still continue to find out the form so I can get a tally of the people on board with this project. It is labeled 2020 for that reason, since gathering a team of people’s experience and availability takes time. You can also contact me on my About page.
I have a list of what I believe are several good steps to proper game design:
Having a good idea (story)
Memory reservation (banking)
Good graphics (sprites – multicolor/backgrounds)
Lots of Options (weapon, pickups)
Challenging bad guys – bosses
Have a good idea (story)
Putting together a game is hard work. It’s like writing a best selling novel that people will enjoy reading. I’ve learned over the years to put a story into place before trying to move forward with designing a game, such as for the Commodore 64 computer.
Commodore 64 Memory Reservation
A good explanation of “Commodore 64 memory reservation” is putting aside memory to make room for graphics, music, and lots of code (such as in assembly language). According to the book Mapping the Commodore 64, the video chip (VIC-II) can only access 16K of memory at a time and all graphics data must be stored in that 16K block in order to be displayed.
Within this area, sprite graphics data may be placed in any of 256 groups of 64 bytes each. Character data can be stored in any of eight 2K blocks. Text screen memory may be in any of 16K sections with bitmap screen memory in either of two 8K sections. Therefore the C64 Assembly Language Project 2020 will contain plenty of room to avoid these conflicts.
When you turn the power to your Commodore 64 computer on, the VIC-II uses the bottom 16K of memory for graphics. This block of memory is also used for other important purposes. In many situations, you will want to change from the default 16K bank at the low end of memory.
The memory registers will be presented soon. Keep in mind that your game program consumes memory quickly, so moving the banks (memory) around is key to allowing a large game project to be designed in memory.
C64 Memory Banks
Bits 0 and 1 select the current 16K bank for video memory from four possible choices using the following bit patterns:
00 (bit value of 0) Bank 3 (49152-65535), $C000-$FFFF)
01 (bit value of 1) Bank 2 (32768-49151), $8000-$BFFF)
10 (bit value of 2) Bank 1 (16384-32767), $4000-$7FFF)
11 (bit value of 3) Bank 0 (0-16383, $0-$3FFF)
Bank 0 (block 0)
This is normally used for system variables and Commodore 64 BASIC program text. Locations 1024-2048 ($400-$800) are reserved for the default position of screen memory.
There is an additional limitation on memory usage for this bank area since the VIC-II chip has the Character ROM generator at 4096-8191 ($1000-$1FFF). This provides little room for graphics data. Other memory locations such as 679-767 ($2A7-$3FF) exist. Then there’s the cassette I/O buffer at 820-1023 ($334-$3FF) could contain graphics memory.
Bank 1 (block 1)
Normally used for BASIC program storage. When using this block, the VIC-II doesn’t have access to the Character generator ROM and limits BASIC program space (about 14K). The ROM can always be switched out and copied to RAM. This block may be a good alternate choice to avoid potential conflicts with other applications that utilize higher memory.
Bank 2 (block 2)
Consists of 8K of Ram, half can be seen by the VIC-II chip as Character ROM, and the 8K BASIC interpreter ROM. The BASIC ROM area ia available for graphics. The VIC-II chip reads only from RAM and sees the RAM underneath the BASIC ROM.
The 6510 writes to RAM even when dealing with memory it reads as ROM. Whatever is written to the RAM under the BASIC ROM is displayed normally by VIC-II. This opens up an extra 8K for sprites and character data under the BASIC ROM. This is a good place for graphics memory.
Bank 3 (block 3)
Contains 4K of RAM unused by the system, 4K of I/O registers, and the 8K Operating System Kernal ROM. This is a good place for both graphics and a BASIC program. The Character ROM is not available, but can be copied to RAM. Avoid use of 52224-53247 for graphics since it’s using DOS support.
Having a game with good graphics will entertain any player at first, but keeping a person interested will involve a lot of repeated playing and less frustration (such as bad joystick movement, impossible enemies, etc.)
Therefore, I intend to make it my mission to ensure a game has not only nice looking graphics, but keeps a player engaged with interesting gameplay. Check out some game examples here that made the Commodore 64 the best selling computer in the 80’s!
Batman the Movie C64 Game
C64 Game Turrican 2
C64 Game Robocop 3
C64 Game Hessian
Fine Scrolling (Moving the screen)
Fine scrolling involves shifting the screen when moving a player past a border boundaries when going either left, right, up, or down. Although there are games that contain single screen gameplay, I am convinced that scrolling a screen beyond the view range (border areas) makes for a more interesting experience. This is why I invested hours studying this and learning and proper timing when scrolling the screen.
The screen is made up of tiny pixels that can be moved in any direction. These tiny dots are known as bits (according to the Commodore 64 memory). Manipulating bits is key to advancing your understanding of fine screen scrolling and will be utilized effectively in the C64 Assembly Language Project 2020.
A raster interrupt occurs when a process is stopped to allow a certain interaction, such as a disk drive reading tracks, a keyboard accepting input, a screen being updated, and so much more.
In our game series, the program utilizes tracing a raster line down the screen to provoke an “interrupt”. During the time that the screen display is scanning lines down the screen (266 lines American NTSC, 312 lines European), each one is updated every 60 times per second. 200 of these are for the visible display screen.
Raster Scan Lines
It is sometimes helpful to know which line is being scanned because changing screen graphics on a certain line while that line is being scanned may cause a slight disruption on the screen. By reading register 53266 ($D012), an assembly language program can wait until the scan is off the bottom of the screen before changing a graphics display.
Our game program for the C64 Assembly Language Project 2020 uses this to copy graphics data to a back buffer, scroll the screen, and much more.
No Commodore 64/VIC 20 game is complete without some type of sprite animations. Sprites are little graphics can pass over a background area without erasing it. Our game will have a lot of sprite animations once it has reached the final stages.
Sprite animations are managed by the VIC register and are placed on the screen as a shape pointed from a memory register. We will explore these more later, but be sure to check out my article on C64 Sprites Defined
Many of the popular games back in the days and more recent have plenty of sprite animations to keep a user engaged all throughout the gaming experience. Here are a few that I have enjoyed.
It is a popular belief that beyond the multicolor graphics of the Commodore line of computers, music (produced by it’s SID chip) has completely revolutionalized games written for this machine. I want to make it a goal to include great music in our project.
Many popular games included some pretty amazing soundtracks. here are a few honorable mentions.
Lots of Options
Before this game is finished, I intend (project) to have a lot of cool options added, such as a selective choice of weapons, various objects to pick up, and so on. Keeping a game filled with options makes for a more memorable playing experience and I look forward to seeing how interesting we can make this for our audience.
Here is a list of some old school “options” that were embedded into some popular games during that era.
Challenging Bad Guys/Bosses
No game is complete without having some type of challenging “Boss” to take on. Nintendo made this famous and stopped players from proceeding to the next level until they eliminated a confrontational bad guy blocking a gate beyond. So our game likely will be including several Bosses to make it more enjoyable.
Several games seen here show how adding a Boss makes the game more challenging and addictive to play!
I hope you have enjoyed this series on seeing what is upcoming for the “C64 Assembly Language Project 2020” I’m glad to know that I can finally get a nice game underway for viewers to enjoy.
Please feel free to contact me if you have some experience with programming in assembly language for the Commodore 64 computer and I’ll see if I can find a spot for you among the team.
Game Name: Parkour
Plot: John’s (player character) friends went to do building parkour one day and suddenly disappeared. John himself is a professional parkour expert, as were his friends, so he thought it strange that they ended up missing. One day he receives an anonymous call from a gang member that requests “payment to free hostages”, which John learns was his friends that done parkour with him.
John trained in parkour at the local gyms for years and one day decided to go exploring with his friends.
They were often getting arrested for pushing the limits, but their strange disappearance baffled John. So he decided to go look for them.
Along the way John will run into people who roam the building (maintenance, gang members, etc.)
At times John will encounter Police that may try to arrest him if he is caught. John can throw them off course by fighting directly or throwing objects at them.
Critters: Rats, stray dogs, and bats can barricade areas at times.
John can collect water bottles to refuel himself along the way and locate cash that was lost by the gang members along the way (for points).
The City: John will travel through various buildings, city streets and make his way eventually to a warehouse where his friends are being held captive.
The gang members are holding his friends for hostage.
I hope you enjoyed learning about this project and can’t wait to hear from and work with you all!
Steve has always had a passion for computers even before he owned one. His first personal computer was an Atari 65xe purchased at Children's Palace around 1986. In later years he attended DeVry University and received a Computer Science degree and worked as a Web Developer for a short season. To this day he currently works for WordPress Live and runs a YouTube channel for the Commodore 64.