Inspiration
Any engineer finds joy in challenge. Mushing your brain up into a pulp and refining it into a fine, silky liquid only to reform it into some organ-like structure again is often the best way to learn, and what a better way to achieve that than programming in pure assembly for a console 3 decades old.
The SNES was seminal - leading the shift into the '16 bit' era of home consoles. Making a game to run on such a console is an attractively challenging and interesting task.
What it does
A ROM is assembled that can be directly run on any SNES emulator. It starts with a 'splash screen' fading in and out before continuing to gameplay, where you have 4-directional control of a small mushroom guy as you help them 'sprout'.
As you get to the exit of each stage, you get closer and closer to the sun and adventure through several 'screens' of levels (although there's only 1 level so far...)
How we built it
M1TE was used for editing assets, the cc65 suite for assembling and linking, and Vim for editing code.
Silas Hayes-Williams acted as soul 'code monkey', Casper Howard as Art Director, and Mustafa Abd as Game Designer.
Challenges we ran into
The SNES is an old console, and has several quirks. On top of that, assembly is simply just tedious to program in. This console was also one Silas hadn't programmed for before, so we were effectively learning it all from scratch!
A few particular problems arised with:
- Cross-bank addressing of labels.
- a label was defined in one segment and then referenced with 'indexed' addressing in a different segment. The assembler automatically assumed the label to be a 16 bit address despite the full 24 bits being required to correctly address it. This causes several hours of debugging just to find a simple
f:was needed infront of the label to specify it as a 'far' label
- a label was defined in one segment and then referenced with 'indexed' addressing in a different segment. The assembler automatically assumed the label to be a 16 bit address despite the full 24 bits being required to correctly address it. This causes several hours of debugging just to find a simple
- Collision Checks
- collision checking was a continuous hickup. The previous bank address issue effected loading in the collision map, and when copying the collision checking routine to a different part of memory I left out the return statement, leaving the program to hang for no reason, not being solved for at least 1 hour
- Sparse documentation
- The SNES is very under-documented. Tutorials, Wikis and guides are either hard to read, poorly structured, or half-finished
- The 65816's A, X, and Y registers can switch between 8 and 16 bit modes. Changing these modes also effects how much data is written on store instructions. Keeping track of what mode each register in and what mode you need a register in is tedious. There are several duplicated and redundant register mode changing code throughout the whole program that would ideally be removed
Accomplishments that we're proud of
Getting a game that runs on an actual SNES emulator (and likely actual hardware!). That achievement alone is all we need.
What we learned
- DMA transfer on the SNES for filling in VRAM, CGRAM, and OAM
- How tiles, palettes, tilemaps, and sprites work on the SNES
- How to read control input using 'auto read' on the SNES
- 65816 assembly programming
- How to make art using limited colour palettes ## What's next for Team 52: Super MustShroom
We will hopefully continue working on the game to get it working to the point we originally envisioned. We wish to add gravity, platforming, several new levels, and some form of score.
Built With
- 65816
- assembly
- snes
Log in or sign up for Devpost to join the conversation.