Just slowly plugging along. I’ve been alternating between trying to understand snippets of code in Ghidra, looking at memory changes at runtime in Mesen, changing them to see what they do, and tracing execution paths in the debugger.
That’s probably the cycle I’ll be doing all the way through.
I can’t debug through Ghidra but it’s got extensive commenting/renaming features. Mesen’s debugger has a few label creation/renaming features but it’s a more limited. I don’t seem to be able to add comments, which would’ve been nice. The debugging features are pretty great, though.
One thing I haven’t seen in Mesen is a feature to track whether certain values went up or down between breaks. It only marks values that have been written to. It would help pinpoint memory values that go down, like health bars or time counters.
So far in memory I’ve identified some various timers, the random number generator, player lives and progression, joystick/oam/ppu register copies. I’ve also found update functions for what I guess are the different “modes”, like the title screen and game play, with each mode having multiple functions, which are maybe sub-modes. Haven’t gone too deeply into it yet. Identified a few simple utility get/set/clear functions for memory and PPU.
I realized I could look at Game Genie codes to help figure out certain values. There aren’t that many codes out there but it did identify a few things.
Moved the project file to the cloud to at least have some semblance of backup and version control. I’ll have to figure out how I want to store this in GitHub or something.
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.
Look at them rainbow colors! I am an artiste!
Downland has a very barren ecosystem. Other than the unrelenting acid drops of death there are two other beings roaming and lurking in the depths of the game’s chambers: the ball and the bird.
The Ball Boulder
In Downland the main active enemy you face other than the drops is what I call the ball, even though it’s probably a boulder. You know, a boulder that squashes and stretches when it bounces across the screen.
In any case, in the reverse engineered assembly code and the C version I call it the ball. It’s the name that came to most naturally to me. I told myself I can name it anything I wanted as long as it’s consistent. I could’ve named it Jennifer.
Every Day The Same Again
The first thing that struck me about the ball behavior is that no matter what room it appears in, it always spawns in the exact same spot. It spawns at X=101 and Y=116 in logical game space, appearing at X=202 in screen space. I never realized this playing the game, even after all these years. Props to Mr. Aichlmayr for making the chambers’ geometry varied enough to mask that fact.
Do The Locomotion
The ball’s position uses 16 bit fixed point values. Eight bits are for the integer part and the other eight bits are the fractional part. The ball moves along the X axis 88 fractional units to the left. In comparison, the player moves 56 fractional units. The player is constantly getting mowed down by the ball. And even if the player manages to dodge it, its repeating nature just means they’ll only have a few seconds before it comes back.
When the ball is falling its speed is increased by 18 fractional units every frame with a maximum speed of 256. When it hits the ground, it sticks to it for 4 frames (showing the squished animation frame), then bounces back up with a speed of -256 and a gravity of 10. When bouncing up, it counts 10 frames and then sets the vertical speed to 0, letting the falling gravity take effect again. This gives the effect of the ball falling faster than going up, squishing hard on the ground.
When part of the ball overlaps a blue pixel on the background, it restarts. Here I changed the rope color to blue.
When it collides with the terrain, the ball resets its XY position, but doesn’t reset its vertical and horizontal speeds. This has the effect of changing the ball’s trajectory as it can be in the middle of jumping up or falling down. This makes it so the player can sometimes find temporary safe spots in certain chambers, like here on the bottom stairs in chamber two:
On every other cycle, the ball bounces clear over the player, providing a brief respite.
Room With a View Ball
In theory the ball can be used in any chamber. The only thing that limits this is a table that specifies which chamber it appears in. The table contains these values:
When the chamber initializes, it goes through the values of the table to find the current chamber number. If the current chamber’s number is found, then the ball is spawned. If it’s not, it reaches 0xff and skips the ball initialization.
Cut Content?
The most fascinating thing about the table above is the set of values 10, 11, 12, 13, 14. As the values are chamber numbers, could this be evidence of cut chambers? Did at one time the game contain five more chambers? Or are these just place holder values? We’ll likely never know. As far as I can tell, this is the only existence of unused data I’ve found in the whole ROM. It’s fun to think about what they could’ve looked like if they had existed.
It’s a Bird, It’s a Bat. It’s Bat Bird.
Drops are random but easily avoidable. The ball is hard to dodge but predictable. When the chamber’s timer hits zero, however, all hell breaks loose. The bouncy zigzagging winged terror of doom is unleashed. Don’t let its simple bird-like appearance fool you. If you see it and you’re not anywhere near a door, consider yourself dead in advance.
Your worst nightmare
Like the ball, no matter which chamber, the bird always spawns at the same spot. It starts at X=35 and Y=26. It has a base X and Y speed of 256 fractional units and then a random speed between 0 and 255 is added on each axis. That means it’ll always spawn going down and to the right but at different angles.
Unlike the ball, the bird doesn’t try to detect the chamber’s terrain. It just flies straight in a direction until it hits an invisible wall and then reflects off. The walls are defined by a bounding box with screen coordinates (14, 16) for the top left and (240, 177) for the bottom right.
It continues to bounce around until you change rooms or die. If you die for any reason, the bird disappears and the timer is reset to 2048, giving you a little more time to escape.
Next Time
With all these hazards going around, I haven’t yet explained how the game detects collisions between them and the player. I hope to cover that in the next installment.
On a whim I decided to look into reverse engineering Kung Fu, a launch title for the NES released in 1985. I was surprised there wasn’t a lot available online already.
Ever since RE’ing Downland I was thinking about my next RE project. I wanted something I could complete in a reasonable amount of time with a reasonable amount of effort. I have huge ambitious dreams of RE’ing all my favorite games, but I have no time or patience for anything big.
The Kung Fu ROM is 40 kilobytes, 8kb of program and 32kb of graphics rom. I think that’s pretty much what I can realistically tackle. (Correction: It’s actually 32kb of program ROM and 8k of graphics ROM. The people responsible have been sacked.)
One thing I’ve already found that surprised me is that the main player character is made out of background tiles, not sprites. If the game already uses sprite 0 to do the split screen, I wonder how it scrolls the middle part of the screen to move the player around.
I got a Ghidra project up and started the preliminary investigation. I’m also using Mesen and its debugging features. I’m not very far in. I’m at the point where it sets up RAM, the PPU, and namespaces and then goes into an infinite loop. After that I guess it handles everything through the vblank handler.
I’ve barely gotten off the ground but I’ll want to post up the work somewhere. I don’t actually know if I can post Ghidra projects on Github. At the very least I’ll post a disassembly listing.
I plan to interleave this work with other projects. I still have maybe a few more Downland Unearthed articles in me, and I’ll want to eventually tackle scrolling of really large areas in SMS Rally. The idea is that instead of intensely concentrating on just one project (and potentially burning out, again) switching between different ones will keep my interest and energy up. We’ll see!
Since the last update, I’ve tried coming up with solutions on how to fix the glitchy sprite tiles when changing direction. The problem stems from me trying to copy too many tiles to VDP memory during vblank. The VDP tries to render the graphics while I’m still trying to copy memory and that causes conflicts. The friendly smspower folks suggested a “double buffered” solution where I’d copy the car’s tiles over two game frames. Copy half-ish of the car’s tiles on the first frame, then the rest on the second frame. When copying, put the tiles into a “back buffer”, i.e. an unused area of VDP memory while the active sprites use a different area. When the copy is done, make the sprite use the newly copied area and then next frame copy the tiles into the “old” area.
Went with an ugly but working solution. In the gif above you can see the two areas in the VDP memory getting updated in alternate steps.
The disadvantage of updating over two frames is that the animation will be updated at 30fps while the rest of the game runs at 60fps. But the physics can still run at 60fps and the new direction even if the sprite doesn’t reflect it exactly for one frame.
Now that I think the prototype is in a decent working shape, I do believe I’ll be taking a break on this project for a bit.
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.
Generating Downland’s backgrounds is easily the most complex part of the game’s code. It doesn’t store its backgrounds as tiles organized on a tile map like on a console, nor does it store the background as an image. In actuality, its backgrounds are built from a string of pre-defined shapes drawn end-to-end by a virtual plotter.
Shapes
Downland uses twenty-two different shapes to achieve its background layouts.
Since the original assembly doesn’t have any names for the shapes, here are the names I gave them in the C version.
Shapes are made up from one or more smaller parts. And each part is made up of one or more segments. Each segment is a line with a direction and length. Most shapes are made up of just one part but the ropes are made out of multiple.
Here is a breakdown of the Stalactite shape.
The Stalactite is made out of one part, and that part is made out of three segments. Segments start from the previous segment’s ending position and so their start and end points overlap.
And here is a break down of the ShortRope shape.
The ShortRope, like all the rope shapes, is made out of three parts (A, B, C). Parts A and C are made up of one segment each while part B is made out of two.
Harry Plotter
The shapes are defined as a series of segments because the backgrounds are drawn using a plotter-like system. From a starting point the plotter goes through the segments of each shape, drawing into a buffer one line at a time. This is similar to how old arcade games like Asteroids and Tempest draw vectors to a CRT display.
Plotter Colors & Hidden Links
The plotter can be configured to draw blue, white, or black lines. Black lines are used to give the illusion of floating platforms or sub-rooms. Below are images of chambers with their hidden lines revealed in white.
Part Data
This is what the data for the Stalactite’s one and only part looks like. Each segment is made up of movements along the X and Y axes plus an orientation. The orientation determines which is the major axis between the two.
Shape Data
There’s no actual data that defines a shape. Each shape has a function that instructs the plotter which parts to draw and how to draw them.
Segment Drawing
Drawing a segment to the screen works similarly to sprite drawing wherein the data assumesa 128×192 resolution but the actual drawing is done in 256×192.
The segment is drawn with white double-wide pixels but a CRT mask is applied on top that makes it appear blue. Ropes are drawn without the CRT mask to appear fully white. No background shapes use orange.
Putting It All Together
Please enjoy this video of all the chambers being drawn one shape at a time.
Worked on importing the sprite graphics into the game prototype. Reused a lot of the animation/drawing code from my old Ninja Girl project.
Once the graphics were imported, started on the actual driving around. It doesn’t feel like 16 directions is smooth enough. Rom space isn’t an issue so I can definitely try 32 directions.
I don’t understand the sprite glitching at certain angles. I’ll have to investigate. Tomorrow, maybe.
I’m easily hitting the map scrolling limits, which is expected. For racing to happen, tracks will have to be pretty long. I still haven’t thought about how I’ll pull that off. I want actual twists and turns, not like Enduro Racer where it just scrolls in one diagonal direction.
Finished drawing the basic sixteen directions for the car. I put them all together in a rotating animation and it… doesn’t look that great.
The car looks inconsistent from frame to frame which is wonderful. The car changes size and height. When I started was drawing the sprites by eyeballing them against the prerendered car but at the end I just started drawing overtop them.
But version 1 is done so now I can start working on code. But I think a version 2 will be in order once I get some gameplay going. Next time I’ll stick much closer to the prerendered version.
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.
In the previous post I talked about how Downland’s 1-bit graphics are setup to take advantage of CRT artifacts to generate colors. In this article I talk about how Downland draws its sprites to the screen.
Sprite Hardware? What Sprite Hardware?
The Tandy Color Computer doesn’t have built-in sprite hardware like the Atari 400 or the Commodore 64, where the programmer can just set a few registers and sprites are conveniently placed on the screen. For the CoCo, drawing sprites requires directly manipulating the memory that is used for the screen.
Screen Memory
What the player sees as graphics is represented by a specific region in the CoCo’s RAM. Turning on bits in that region of memory will activate the corresponding pixels on the screen.
Writer’s Block
One problem with working with Downland’s 1-bit graphics is that you can’t directly address the bit/pixel you want to turn on. 8-bit CPUs like the Tandy Color Computer’s 6809 can only write to memory one byte (eight bits) at a time at the minimum. They can’t write individual bits. So for any changes you want to make to screen memory you have to do it in bytes.
Another limitation is you can’t write that byte anywhere. It has to be written along byte boundaries. This means you can only write a byte at every eight bits (0, 8, 16, etc). You can’t write a byte at bit 3 and expect it to change bits 3 to 10.
Sprite Basics
Because the screen is 1-bit, Downland’s sprites are naturally 1-bit as well, as seen on the player sprite below. Each frame of the player sprite is 16 pixels wide and 16 pixels tall. As the graphics are 1-bit, the 16 pixels for each row of the sprite take two bytes. The first byte of each row contains the front of the player sprite while the second byte contains the back.
8-Bit Drawing Limitations
Because the CPU can only write 8 bits at a time, if you wanted to draw the sprite as-is to the screen you could only do it on byte boundaries. The result is the sprites appear at every 8th pixel on the screen horizontally.
Note that the sprite can be placed anywhere vertically. There’s no limit there.
Still, this is obviously very limiting for a platforming game like Downland which has objects going across the screen.
Shifted Sprites
The trick Downland uses to draw sprites along the horizontal axis is by copying the original sprite and creating new versions that are shifted to the right by a certain number of bits. These are called shifted sprites or bit-shifted sprites.
Things to note:
In the game the sprites are shifted by two bits (aka pixels) instead of one because while the screen resolution is 256 pixels across, the game logic is actually half at 128. So for every X position in the game’s coordinate system, objects are drawn at twice that. Therefore it only needs shifted sprites for even-numbered positions.
It also shifts by two bits to maintain the CRT artifacting effect.
Because we only need shifted sprites for the even positions along the byte, only four shifted sprites are needed for each sprite.
Shifted sprites go past the second byte so they now need take up three bytes for every row.
There’s no version of the sprite for being shifted by 8 bits or more because at that moment you can just use the first shifted sprite again. It wraps around.
Drawing Shifted Sprites
The game uses the sprite’s X position to determine which shifted sprite to draw. The game takes the lower two bits of the object’s X position, which gives a value that goes from 0 to 3. It uses that value to look up which shifted sprite to draw. Zero uses the first shifted sprite, 1 uses the second, 2 uses the third, and 3 uses the fourth.
The image below shows bit shifted sprites being drawn on screen with different X values.
Memory Usage
Shifted sprites are generated when the game is turned on and are stored in memory.
As there are four shifted versions of every sprite of every object, it can take up a fair bit of memory. For example, the player’s ten frames of animation take up:
10 frames x 4 shifted versions x 3 bytes per row x 16 rows: 1920 bytes
With the game taking 6k bytes for the screen, and another 6k for a clean version of the background, it really starts to impact the 16k of the original Tandy Color Computer. But everything fits.
Which Sprites?
Shifted sprites are generated for the player, the ball, and the bird sprites. The ball and bird sprites each have two frames of animation.
Exceptions
The drops, the splat sprite, and the door have their own particularities when it comes to drawing them shifted.
The drops are actually pre-shifted in the ROM, as seen here:
Side thought: I wonder if the drops were the sprites Mr. Aichlmayr made first and then immediately realized that storing shifted versions of all the other game objects was going to take a lot of ROM space and changed strategy. Or the change in strategy came at the end of development trying to reduce the game’s final ROM size.
For the splat sprite, it’s the only one in the game that’s 24 pixels wide.
Unlike the other sprites above, where the shifted versions are pre-drawn, drawing the shifted splat sprite is done on the fly. When the player gets squashed the splat sprite is drawn shifted into a temporary offscreen buffer. The buffer is 32 bits (4 bytes) wide so that the shifted sprite can fit. Then the offscreen buffer containing the shifted splat sprite is drawn to the screen.
Fun fact: the splat has a two frame animation when the player dies but there’s no second frame stored anywhere in rom. To achieve the animation, the splat sprite is first drawn to the screen and some time later the top part is erased directly from the screen’s memory.
The door is also drawn on the fly, using the same technique as the splat sprite.
It’s drawn when a door gets activated and also as part of the background drawing when the player enters a chamber.
Pickups
Finally, the game treasures (key, diamond, money bag) are the simplest drawn objects in the game. They don’t use shifted sprites at all as they’re always drawn at a multiple of 8 pixels.
Wrapping Up
Lacking dedicated hardware support, shifted sprites is a commonly used technique for Tandy Color Computer games to draw objects on the screen. It lets sprites to be placed anywhere on the horizontal axis at the expense of memory. Downland uses the technique in various ways to draw its game objects. In the next article, I’ll talk about how the background graphics are drawn.
Not a big update. Created more graphics in Graphics Gale for the different directions of the main car sprite. Ten down, six to go. It’s slow going because the work is tedious and I’m lazy, but I’m starting to get more confidence in the car sprite making process. Hopefully I’ll have all sixteen directions done this week.
The fun (read: not fun) thing about the Sega Master System is that it doesn’t have sprite mirroring like the NES does. So the game will need graphics for all sixteen directions. It does mean that I can make the graphics unique for all angles, though. So I can keep the #1 on the car door facing the right way.
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.
If you look at the game’s video memory, internally Downland is actually a 1 bit game. The graphics are effectively black and white.
But the game actually has color. How does that work? Notice the spacing between the pixels on the floor and the diamond. The game draws its graphics in such a way to take advantage of CRT artifacting effects. These effects helps the game simulate a limited set of colors. This was a common technique used at the time, as seen on other computers like the Apple II.
Colors
Because of how the NTSC television signal works, different pixel patterns determine which color will be displayed and how it blends with other colors.
On the CoCo’s 256×192 graphics mode, each pixel is represented by a single bit. The artifacting in this mode interprets pairs of bits like so:
00 will be black
01 will appear blue
10 will appear orange
11 will be white
A blue pixel next to an orange pixel (01 10) will also be white
The Tandy Color Computer also has a quirk where the blue and orange colors can be swapped when it powers on.
(To me, the blue version is the canonical version.)
The above is a very horribly simplified explanation of the Coco’s CRT artifacting. A much deeper dive on how all this works can be found in this great Coco Town YouTube video:
But in practical terms, the graphics mode effectively gives a 4 color 128×192 screen.
This “effective” resolution explains what I was saying about drop placement in the previous Downland Unearthed article. The game logic works at 128×192 while the graphics are drawn at twice the horizontal resolution. This counts for both the background and sprite drawing.
Another way of saying it is sprites need to move horizontally every two pixels, to maintain color stability when going across the screen. Otherwise the pixel colors would cycle like a (really limited) rainbow.
Here’s a capture of a hacked version of Downland_C simulating the player and the ball being placed every pixel instead of every two:
One-Bit Shapes
What I find interesting is the way the sprites have been drawn to take advantage of the CRT artifact effect. Here’s are side-by-side comparisons of the 1-bit graphics and the color graphics. The color versions were produced using the XRoar emulator in the the 5-bit LUT Composite rendering mode.
If you stare at the player sprite too long, you start to notice that he’s got blue AND orange hair and you can’t tell what the orange and blue parts of his face are supposed to be. Is that a blue eye at the lower half of his face? He has identically sized mustache and eyebrows? Also, he has ridiculously long arms and his shirt either has a single button or he’s just showing off his nipples. It’s hard to tell as this resolution. And who knows what the white pixel under his hand is supposed to represent!
Without color, Downland’s iconic bouncing enemy of doom is finally revealed to be just a killer walnut.
For a diamond, it’s drawn pretty plain, isn’t it? Still, this orange upside-down triangle gives 400 points! (more or less…)
M is for money, obviously. I like how the stray pixels add a kind of fringe around the top of the money bag.
Dithering makes straight lines? *mind blown*
I never know what the shapes on the doors are supposed to represent. A porthole and a wheel? Are they actually doors from a submarine? Is Downland actually set underwater?
Rom Storage
All the sprites in the game are stored with these patterns, as seen here using a raw pixel viewer to look at the rom’s contents:
(Notice how some of the sprites like standing left and right are perfectly mirrored but some, like the jump, aren’t.)
The one exception to this is the game’s font. It’s stored without effects. I couldn’t get the viewer to align the characters perfectly, but you can see that they’re made up of solid pixels.
Each character is 8 bits wide and 7 rows tall. The character drawing function draws each row while applying (and’ing) a bitmask (01010101) on top to turn off every other bit. This causes the character to appear blue.
I wonder why the mask wasn’t pre-applied. The game could’ve saved a few cycles when updating the timer and score to the screen. Maybe the author wanted to keep the font pristine for easy edits, not minding the performance hit. Or maybe he started with white text and then changed his mind.
Half The Battle
So that’s how Downland takes advantage of CRT artifacts to generate its graphics. One obvious unanswered question is how the graphics are actually drawn on screen. The graphics are 1-bit per pixel but writing to memory is done eight bits at a time as a byte. I hope to explain how Downland draws it sprites in the future.
