top of page

Video game developed in assembly for the Sega Master System

About The Project

Assembly

Solo

Sega Master System

Research

This project involves the creation of a video game for the 8-bit Sega Master System console. For this, I used the Z80 assembly language which is the programming language that is compatible in the console's processor.

​

One of the goals I tried to accomplish was to create a basic ROM that was fully functional on both emulators and the actual console.​ On the other hand, I described the entire process of developing a video game in this old console, describing the problems I have encountered along the way and their respective solutions, if applicable.

​

Below you can find the document I wrote for the project. It serves as a small manual for anyone looking to create a video game under similar conditions in the future.

What I did

Overview

  • Researched and understood the console’s hardware and architecture.

  • Learned to use makefiles for assembling and linking the project files to generate a valid ".sms" executable that works on a real SMS.

  • Memory optimization to meet the console memory space limitations.​

  • Delivered a fully playable game for the Sega Master System: Enemies, game loop, character movement, sprite and level drawing, animations etc.

  • Documented the entire process to serve as guide for other people that want to develop a game for the same console.

Creating a valid ROM

To create a game that runs on a real Sega Master System, I first needed to build a valid ROM containing essential instructions for initializing VDP registers, configuring memory banks/slots, and managing VRAM.

Banks and slots are used to indicate how big our ROM is going to be. A bank is a segment of memory storing data, while slots are regions where these banks are mapped, allowing the console to access larger memory amounts than it can directly address at once. 

Below is the slot and bank map configuration used in my game
Invasion.

MemoryMap1.png
MemoryMap2.png

Another key aspect is validating the ROM. The BIOS from the SMS checks all the available slots for valid software to boot, typically the first valid game it detects.

​

To make the ROM header functional on both emulators and real hardware, I used the "sdsctag" directive provided by WLA DX. This directive ensures the BIOS recognizes the ROM header as valid. It also allows for the inclusion of additional metadata, like the game's name and version, which can be helpful for version tracking and debugging.​​​

RomValidation.png

​​​​​​​​​​After this more steps need to be done such as initializing the Video Display Processor. All of this is explained in detail in the document you can find in the link above.

Drawing Sprites and Backgrounds

Another key aspect that I had to do was being able to display something, and for this I needed to learn how the VDP (Video Display Processor) works. This involved loading all my resources (color palette, sprite/background tiles and the tilemap) into memory first.

​​

For the color palettes, both the background and sprite, are loaded into the CRAM which is specific for storing this data.

colorPalette.png

On the other hand, tiles for the sprites and backgrounds need to be transferred from the ROM to the VRAM in order to be loaded. The tool BMP2TILE converts images into tile data, generating the tile indexes, tilemap, and color palette needed to display the graphics.

Creating a videogame in the SGM.jpg

The Sprite Attribute Table (SAT) in VRAM is used to position and display sprites on a SMS. Sprite data is first loaded into a buffer in RAM, then transferred to the SAT, which controls the sprite’s position and appearance. With all required data in VRAM, the background and sprite are rendered, completing the process for drawing visuals on the screen.

DrawingExample.jpg

Optimizing Memory Usage

At one point, I realized there wasn't enough ROM space to store all my assets, like sprites and levels. This was partly because the same sprites had to be loaded in both normal and mirrored orientations, while also some backgrounds consumed too much memory. To address this, I initially planned to reduce the space by mirroring sprite tiles, but I found that the SMS doesn't support rotating sprite tiles during runtime, only background tiles.

​

Therefore, my last option was to create symmetrical maps by rotating the tiles of the background. To implement this optimization, I used the Tiled map editor, which allows easy manipulation of tiles. 

SymmetricalBackground.jpg

​​​The image from above shows an example of using symmetrical tiles. Here we can see that the left and right walls are the same tile, but one is rotated. Similarly, columns are created by repeating and rotating these tiles.

​

By using this simple technique, I manged to make a level that previously required a total of 24 tiles to be drawn on the console to now take up only 14. This is a saving of about 320 bytes in total.

Conclusion

In general terms, I am satisfied with the result of the project and the work done over these months. Although the video game that I created is not the best one created for this console, I consider that the result obtained, while it can always be better, is acceptable considering that it was the first time I dealt with this console and I had no previous knowledge about technical aspects of it.

​

The main focus of this project was to create a playable game for the Sega Master System and thats what I managed to do. The game can be played on an emulator or in an actual SMS.

bottom of page