A light day today because I had to work late. With the GSLib example finally running I started looking up how to bring new data in. There’s a UGT tool that does just that. It doesn’t look bad at all. It even has support for the Tiled map editor, which is real nice. I still don’t know what the max limits a map can be, though. The example’s source bitmap is 1024 by 1024 pixels which is pretty impressive (*) but I wonder if it can go bigger.
(*) That’s what SHE said. (**)
(**) sorry
This article is part of a series exploring the reverse engineered inner workings of Downland, a game for the Tandy Color Computer, released in 1983, written by Michael Aichlmayr.
Every room in Downland has five “pickups”, which are treasures that the player can collect for points or to unlock doors. At game start up, the list of pickups per room is generated. The first two items in a room’s list of five are keys that open doors. There’s a data table that determines which key opens which door. When the player completes the game once, the data table is switched to another one with different key-door mappings. I marked it as the “hard mode” version but I don’t know if it’s actually more difficult. The last three items per room are treasures, randomly chosen between the money bag and the diamond.
Fun fact: I only realized last week when looking at a speed run on YouTube that you don’t need to collect all the keys to finish the game. Maybe one day I’ll use that information to become the Downland speed running champion.
Each type of pickup has a base score:
When the player collects them, the game gives the player the base score and an additional random amount between 0 and 127. The random number is taken from a counter that runs through the cartridge rom area from addresses 0xc000 to 0xdf5a. It takes the value at the current address and gets the first seven bits. Other processes advance the counter so it’s reasonably random. Random-ish.
The randomness of the pickups generated and the score added makes it so that getting a high score is partially outside of the player’s control. I’m still unsure if this is was a good idea. A great run could wind up with a bad score, which would be disappointing. I don’t know what I’d replace it with, though!
Since getting the GSLib example running I’ve been trying to set up a project in my own style. I’m fussy and I’ve developed my way of working so whenever I try to adapt a project I always break it down to how I like it. It has the benefit of forcing me to learn how the project actually builds.
It wasn’t entirely smooth sailing because I kept hitting linker errors again. This time, it looked like this:
?ASlink-Warning-Undefined Global 'GSL_TileLookup' referenced by module 'GSLib'
?ASlink-Warning-Undefined Global 'GSL_PositionWindow' referenced by module 'GSLib'
?ASlink-Warning-Undefined Global 'GSL_ActiveDisplayRoutine' referenced by module 'GSLib'
[...]
The linker couldn’t find labels inside the asm blocks of the functions inside GSLib.c. It was essentially complaining about GSLib.c not finding things in GSLib.c.
Turns out I had a --peep-asm flag in the makefile’s CFLAGS for the SDCC compiler and it didn’t gel well with GSLib.c. I couldn’t tell you where the flag came from. It was probably something I wanted to test a million years ago and the flag just hung around everytime I made a copy of the makefile.
As soon as I got that sorted setting up the rest of the project was straightforward. So now I’ve got the GSLib project building and running again, exactly the same as before except different.
Next step is to figure out how to get new assets into the example.
This article is part of a series exploring the reverse engineered inner workings of Downland, a game for the Tandy Color Computer, released in 1983, written by Michael Aichlmayr.
Late last year I started one of those projects I always wanted to do but could never find the time or couldn’t start it successfully. I reverse engineered Downland for the Tandy Color Computer, released in 1983.
Downland was one of those formative games for me. My best friend had a CoCo 2 with a copy of the game and we spent hours trying to beat it. But man, that game is hard.
The player jump physics are game’s best and aggravating aspect. They were the most fluid I had ever seen. But man, no air control whatsoever. When you leaped, you were committed all the way, like in Castlevania for the NES. The jump was floaty enough that there was enough time for a drop to appear ahead and fall on top of you just when you landed. Those drops are the worst.
It was my third or fourth attempt at RE’ing the game. I forget. For these first attempts I had used MAME’s debugger to run through the code and memory variables. I’d try to track memory changes and figure out what they did. And of course I had to learn how to read 6809 assembly code. (hint: I am not an assembly code guy)
At the time I could figure out some of the player state and the section of memory that tracked the drop state. But this method was too slow going for me. The MAME debugger was too cumbersome to use. I’d give up after a week or two. With just the MAME debugger and a text file, reverse engineering this way was like trying to figure out the layout of a blacked out mansion while walking around holding a match.
This time was successful because I decided to learn Ghidra (https://github.com/NationalSecurityAgency/ghidra). It helped a lot with making sense out the code and rom layout, and figuring out the data formats. I also used the trs80gp emulator (http://48k.ca/trs80gp.html) which has great debugging capabilities. The pair of tools really opened everything up and in very little time with these new found powers I managed to eclipse the little knowledge I had gained in the past doing things manually. I soon started learning things about the game that only the original author had ever seen. Finally being able to unlock secrets of this 40 year old game gave me such a wonderful feeling.
I forget the timeline but I think it took me over two months, maybe three, to get the disassembly in a state where I could make sense of how most of everything worked. Enough to be able to start figuring out how to convert it to the C programming language. At the same time I created a tool to convert the Ghidra listing to a buildable assembly file for LWTools (https://www.lwtools.ca/), with which I could build a byte-for-byte reproduction of the original Version 1.1 rom.
After the initial two months I kept updating the disassembly during the year the more I had to get into the details during the conversion to C. Some corners of the disassembly could use a bit more documentation but what’s there I believe is very usable.
The work can be found on GitHub at https://github.com/pw32x/Downland_RE
Maybe in the future if I’m not too lazy I’ll talk about more in detail.
Today was about trying to build and run the GSLIb example. (https://github.com/sverx/GSL)
I kept hitting linker errors due to differences in calling conventions between the pre-built SMSLib and PSGLib libraries from devkitSMS and the GSLib code. A SMSPower forum user suggested building the libraries locally. Turns out that worked. So now I have a building and running GSLib example I can play around with.
I didn’t want to write my own scrolling code as my previous attempt wasn’t performant enough, so I’m looking forward to experimenting with it.
I want to make a thing for the Sega Master System
Looking at GSLib https://github.com/sverx/GSL
Making tests in Graphics Gale https://graphicsgale.com/us/
About Me
Retro game dev, Sega, Downland.
Socials
Projects
Downland_RE, a reverse engineering of the Tandy Color Computer game from 1983, buildable to a byte-for-byte reproduction of the original V1.1 rom.
Downland_C, a translation of the original Downland code to the C Programming language, and ported to many retro consoles.
basicsmsproject, a basic layout of a devkitSMS project using a makefile.
barebones32xproject, a bare bones 32X project using Chilly Willy’s 32X Toolkit based off of Victor Luchits’s Doom 32X Ressurection project.