The Tower of Turmoil Cartridge Space

Does anyone know how much space the Tower of Turmoil actually took on the cartridge?

All NES Maker games build at 512KB.

Here is an image from Shiru's Excellent NES Space Checker from Tower of Turmoil 1.00 (Which is the one I have handy): https://shiru.untergrund.net/software.shtml


White is what it detects as "free space", but that's not necessarily the whole story. The whole story would be hard to get automatically. Usually white that is in between two close together green blocks is not actually free.

So are we talking 50% of the available space?

as far as graphics and such goes.
but as you see, bank 1F is literally full, that's where the game code sits.

Also keep in mind, my game was make with 4.0.11, where there wasn't much free space in Bank 1F as it was. You'll have much more room to work with in 4.1 onwards for custom code and stuff.

Basically anything can go anywhere. DPCM Samples (can't use)/initialization (already setup for you)/Vectors (already setup for you) are the only exceptions that come to mind. (Graphics technically depends. For NES Maker's cartridge, though, the tile data does not need to be somewhere specific.)

You can put code, graphics, music or whatever data in any bank. But for practical purposes within specifically NES Maker, you can't put something else in a bank NES Maker expects say... graphics in unless you want to really rework things. (You're likely to hit assembler errors and have to juggle its exports.)

Here's an old conversation between Joe and Mihoshi20 about which banks are which: http://nesmakers.com/viewtopic.php?f=19&t=248&p=1431&hilit=bank+mihoshi20#p1424 Things have probably changed a bit since then, but it's a good overview.

How room is made in bank $1F is moving the code/data in it to any other bank with free space, and then swapping that bank in when the code/data needs to be accessed. It's a little slower, and a little less convenient is all.

Here are the current Bank Contents. Some things moved, but it's generally similar to how it was before.

• Banks 00 to 0F: Overworld and Underworld Screen Data (each bank accounts for 2 rows of map screens)
• Banks 10 to 12: Background Graphics Banks 1-3
• Banks 13 and 15: Object (monster) Graphics banks 1 and 0. (Yeah, they are numbered backwards)
• Bank 14: Data bank 1 which includes:
  • Input Scripts
  • Extra Input
  • Special Tiles
  • State Changes
  • Camera code
  • ObjectCollisions
  • HUD
  • SpritePreDraw
  • HandleBounds
  • NoPrizeTiles
  • UnderTiles
  • Trigger Checks
  • MonsterLocks
  • PowerUps
  • AI Actions
  • AI Reactions
  • Physics
  • Tile Collisions
  • HUD Tables
• Bank 16: Palettes Bank. It also contains the addresses for graphics and text strings
• Bank 17: String Bank. Also contains code for handling a textbox.
• Bank 18: Data Bank 2. Currently Empty
• Bank 19: No name, but also empty.
• Bank 1A: Reference as BANK_DATA, but also empty.
• Bank 1B: Music Bank. Contains the GGSound engine and is also where your music and sound data ends up.
• Bank 1C: Animations Bank. Contains various object info/data
• Bank 1D: Graphics Bank 0. Contains graphics for HUD, Start Screen, Game Objects, a mysterious box tiles, and the Win Screen.
• Bank 1E. No name, but contains the name tables for the Start and Win Screens.
• Bank 1F. The static bank. Most of what is in MainASM.asm ends up here which includes all the initialization code and the main game loop.

I guess my second question would be:
1. Tower of Turmoil was an amazing piece of work but not an extremely lengthy game, so if it took nearly 50%...how did Nintendo make games that were WAY longer (Mario Brothers for example) and still fit it one cartridge?

by extensively reusing assets (in mario, clouds and bushes are same graphic, and basically all the stages are using the same tiles with different palettes.) also gameplay mechanics.
tower of turmoil is a cool game, but doesnt particularly pose a challenge for the player, as it can be literally ran through. Same can be done to mario i guess, but it's definitely a harder game as far as platforming etc goes.

so...theoretically...the fewer assets (graphics) and limited gameplay mechanics (such as only running and jumping), the game could last MUCH longer?

The original Super Mario Bros consisted of 32 levels that look to be about 16 screens wide for a total of 512 screens. That is the same amount of screens you can make through NES maker. The original Mega Man, best I can estimate, seems to be made of only 180 screens or so. Game length has a lot to do with your game's design, not just the size of levels.

Now if you were to compare this to Super Mario Bros. 3, I wouldn't plan on making anything that size anytime soon. That game had 90 levels plus overworld maps. In addition to that, the size of many of the levels were "bigger" than the ones in SMB1. The SMB3 cartridge did have more space than what were have for our mapper 30 games. We have 512k to fit both graphics and game data, while SMB3 had 512 for just game data and an additional 256k to store just graphics.

I also think that those old games tended to use some trickery to save space. The obvious example would be the 2 water levels in Super Mario Bros used the exact same map, and several castle stages were reused. But I would also bet that in Super Mario Bros 3, even though most levels were 2 screens high, that they didn't waste a bunch of space on several distinct screens of blank sky. Theoretically, some time down the line someone might be able to write a way to compress level data so we could fit more screens in a cartridge, but I wouldn't expect that anytime soon.

I only used about 1/3 of the total screen data NESmaker provides by default. Here's the entire map; I didn't even use the Underworld portion, which adds another 256 screens.



This game was never meant to be an overly lengthy or challenging experience. Keep in mind that this was my first NESmaker game, it's not my masterwork. This was just me getting started with NESmaker. I designed it to be short but highly engaging, adding in as much polish as I could. And really, this game had more content in it than nearly every other NESmaker game at the time I released it.

i didnt by any mean try to mock it, it's far better than the crap im spitting out for what it's worth anyway xD
was just pointing out that it's not particularly challenging from it's gameplay, making it much faster game to run through than, say SMB is, regardless of the amount of screens either has worth in level data.

Mugi said:

i didnt by any mean try to mock it, it's far better than the crap im spitting out for what it's worth anyway xD
was just pointing out that it's not particularly challenging from it's gameplay, making it much faster game to run through than, say SMB is, regardless of the amount of screens either has worth in level data.

Click to expand...

I get what you mean, and I wasn't taking any offense to what you said. And you're right, the design is a factor in how long a game lasts, and so is the skill factor of the player.

CutterCross,
I really hope you don't feel attacked. I was merely using your game as an example. I think Tower of Turmoil is beautiful. I was curious to how much space it took...that's all. And I'm happy to hear it didn't really take as much as I thought it did.

The Lenny said:

CutterCross,
I really hope you don't feel attacked. I was merely using your game as an example. I think Tower of Turmoil is beautiful. I was curious to how much space it took...that's all. And I'm happy to hear it didn't really take as much as I thought it did.

Click to expand...

I don't feel attacked at all, don't worry about it! And thanks for the compliment on the game!

The Lenny said:

I guess my second question would be:
1. Tower of Turmoil was an amazing piece of work but not an extremely lengthy game, so if it took nearly 50%...how did Nintendo make games that were WAY longer (Mario Brothers for example) and still fit it one cartridge?

Click to expand...

Super Mario Bros. used an "object based" format. That's how its levels are so small.

Really basic example:

There's a simple Super Mario Bros. scene. (Edited to keep the explanation simple.) Most NES games break things down into a concept of 16x16 "metatiles" (that are made of four 8x8 tiles, as dictated by the hardware). The screen is 256x240. 256/16=16, so the screen is sixteen 16x16 tiles across. 240/16=15, so the screen is fifteen 16x16 tiles down.

So if you wanted to store the metatile number of each 16x16 metatile in a screen, that's 16*15=240 bytes. (The 16x16 metatile definitions also take up space, but it's negligible relative to screen data, usually.)

240 bytes is not a lot, but if you have a lot of screens, it really adds up. Super Mario Bros. has just 32KB available for all its code/non graphical data. 32*1024=32768 bytes. 32768/240=136.533333333. So using this format, the Super Mario Bros. cartridge could only store 136 unique screens and basically nothing else. (No physics, no music, etc.)

So there's a simple technique that stores the tile number for the metatile, and then how many times the tile appears in a row. Here's how that would shake out for the above scene:


The blue sky takes up most of the screen. It fills 10 entire rows, and 13 metatiles of the next row. So suppose the blue sky's metatile number was 0. To store it for this screen, you'd store 0 (one byte, the metatile number), 10*16+13 (one byte, how many times in a row it appears.).

Then the left side of the pipe interrupts the blue sky. It only appears once in a row. Say 1 is the metatile number for the left side of the pipe. To store it for this screen, you'd store 1 (tile number), 1(how many times).

The left side of the pipe is immediately interrupted by the right side of the pipe. Say the right side of the pipe is 2. It'd be stored as 2, 1.

The right side of the pipe is immediately interrupted by more blue sky. 0, 4.

The blue sky is interrupted after a short run by more pipe. 1, 1. Right side of pipe. 2, 1. Sky. 0, 8. We've hit another left side of a pipe, but it's a different metatile. Say 3. 3, 1. Right side of pipe middle, new metatile. 4, 1. Sky. 0, 4. Left pipe middle. 3, 1. Right pipe middle. 4, 1. Sky. 0, 8. Left Pipe Middle. 3, 1. Right Pipe Middle. 4, 1. Sky. 0, 1. Ground, new metatile. 5, 32.

Basically, this method takes two bytes every time the metatile number needs to change. The above screen would take 34 bytes. A screen that was only sky and ground, would only take 4 bytes. This method (number, then repeats) is called "Run Length Encoding". It is soundly defeated by a checkerboard pattern. Imagine a scene where the metatile change happens almost every tile:



0, 1. 1, 1. 0, 1. 1. 1. It's taking two bytes when the simpler method would only take one. There's a way to avoid this if you use fewer than 129 metatiles, but the point is: No one method will win in all cases. If you use Run Length Encoding, you avoid checkerboard patterns. If you need checkboard patterns, you use a different method than Run Length Encoding.

Still, 34 bytes instead of 240 sounds really good, right? But Super Mario Bros. goes even further. You may notice that after every left side of a pipe (top) is the right side of a pipe (top). 1, 1. 2, 1. And you may notice that after every left side of a pipe (middle) is the right side of a pipe (middle) 3, 1. 4, 1.

You may further notice that under every left side of a pipe (top) is left side of a pipe (middle). So Super Mario Bros. stores how to build a pipe. "A pipe is a thing that has metatile 1 in the top left, metatile 2 in the top right, and metatiles 3 and 4 below for however tall it is." So the pipe is defined as an "object."

And then Super Mario Bros. stores where the pipe is on screen (one byte), and how long it is (one byte). It also assumes the ground is 100% solid and at the same height for each screen.

There are two pipes in the above scene. 173 (metatile position within the screen where the first pipe starts) (one byte), 2 (height of the first pipe) (one byte). 179 (position of the second pipe), 1 (height).

The ground is assumed to be there. (Holes take up space, not the ground.) The sky is also assumed to be there. So the four bytes for those two pipes is the only data that's required.

4 bytes for this scene beats 34. 4 bytes for this scene soundly beats 240.
A screen that is only ground and only sky would take up no space, in theory, since they are assumed to be there and nothing needs to be added to them.

So for those keeping score, Super Mario Bros. had 32768 bytes for code/non graphical data. The average screen has more objects than two pipes. Say the average screen has six objects at two bytes per object. 12 bytes per screen.

32768/12=2730.666666667. It could fit 2730 unique screens. But it doesn't need that many. And that's how it has space for code/music/the other thing it needs.

(To kill the pedants, no, this isn't EXACTLY how Super Mario Bros. does things, but it's a similar concept.) (Edit: Well, an extra byte would need to be stored somewhere per screen. Either a length of how many bytes in the screen's stream, or just an object number that signifies the end of the object based stream. But still, you get the picture.)

So back to Earth. Back to NES Maker. Why doesn't NES Maker use a format like Super Mario Bros.? It'd have to allow the user to teach it how to build all the things. It'd be like everything was a path, that you had to define. It's also harder to write code to draw it.

Super Mario Bros. format makes assumptions based on the type of game it is. (2 metatiles tall ground for every screen unless objects say otherwise.)

NES Maker is trying to cover all types of games. Much like how the checkerboard pattern defeats Run Length Encoding, there are things that defeat the object based format.

Anyway, there ARE definitely ways NES Maker could manage space differently (better?) even if it's not how Super Mario Bros. does things, but I imagine it's not high priority. No one has really even maxed what's there.

Oh my gosh...thank you for that. It makes so much more sense now. Thank you.