Recreating NES limits; loading tiles

I've been thinking about a side-project to create an RPG following the limitations of the NES as closely as I can.
To be clear, I'm talking about creating a game using modern architecture but designed to mimic the NES, not creating an actual NES ROM. Even so, I want to follow as many of the hardware restrictions as I am capable of. The more I've studied what most of these limits are, and as I've examined how NES games worked within those limits, the more I want to work within the limits myself. That being said, all the questions I have about these limitations should assume I am talking about the limitations from officially licensed hardware from the era. (Though it is fun to learn what other things were/are possible, so I'm not opposed to learning extra information.)

I've already found and examined a lot of information about how it handles and draws sprites and backgrounds. What I do not understand are things about how it loads and stores tiles.
I do understand that the system had two banks for tiles, each capable of storing 256 tiles, which comes out to the equivalent of two 128x128 images worth of tiles (as each tile is 8x8.) (Edit; fixed the number.)
What I do not understand is what restrictions the system has in regards to how it fills those banks with data. I was on a forum on another site and someone tried to explain a lot of it to me, but I didn't understand much of it, and the fellow never replied to confirm or explain anything.

First of all, I have questions about exactly where a tile is loaded. By which I mean, what order a particular tile may be in the memory. If we think of the banks as literally a 128x128 image, are there restrictions about where on that image a tile could be? Let's say in one part of the game, I load a bunch of forest tiles, and then in another part of the game, I load a bunch of city tiles, and in both areas I have some tiles that are used in both areas. Do those tiles that are used in both areas have to appear in the same location on the 128 image, and be all in the same order? Or would having them be in a different location/order mean that I have to create a whole new set of tiles or a new tileset or such thing? And to what extent do any such restrictions apply? Would this apply to both banks as if they were one? Or to each bank individually as a whole unit? Or perhaps just it just applies to a group of 64 tiles? Or are such restrictions irrelevant, and if I wanted to load a forest area, and then bring in just one single tile from the city area, I could so that without impacting how I have to arrange everything?
Granted, there is something to be said about the ease of always knowing that the tile you want is always in a given location. But knowing how these restrictions are set up will be important for knowing what combinations of enemies I can have in a battle.

Next question, if I say the term "tileset," exactly what am I referring to? It was really hard to write that section about without using it, but I want to make sure it refers to what I think it refers.

Next set of questions, which I suspect impacts the answers to my first set of questions. On the other forum a guy talked about how a game could load tiles into memory from either RAM or ROM. This very much intrigued me, but I was left with far too much that I didn't understand. First of all, is this an option that is set permanently for a cartridge, or something can be changed at a reasonable point in the game? Now, he said that with using ROM for tile data, the entire tileset could be switched out each frame. A lot of games use this to animate backgrounds. But the trade-off is that a game can't mix up what tiles are in a tileset as freely. Whereas if it loads the tiles from RAM, it can mix the tiles more freely, but it has limits about how many tiles it change out per frame. And I assume these limits are dependent on what MMC the cart uses. But even so, I am curious what all of these limitations actually are. It was suggested to use RAM loading for an RPG because it allows me to more freely customize what combination of enemies appears in a battle. But if I can load an entire bank of tiles into the memory for each frame, what's really stopping me from just creating a lot of pre-made tilesets for each possible combination of enemies I could want? What harm does it do me to load a bank of tiles that is only one tile different from another bank? He also made it sound like games that use the RAM loading method were pretty much incapable of animating backgrounds (at least by changing what tiles are loaded; there still is the possibility of using palette animations, and I'm guessing tilemap animating should be a thing.) But if the RAM method simply slows down the speed at which tiles can be loaded, what's wrong with just keeping the number of animated tiles limited to how many can be loaded per frame? Why couldn't I animate just the water tiles? Or load a whole new image for the player each frame?

And finally, although not really related to loading tiles, I would like to know: is there really any disadvantage to using the 8x16 sprite mode?
I can see how it can cause problems with having too many sprites on one scanline, since even if a row is transparent it still counts toward that limit. So if you were building a character that was, say, 24 pixels tall, you could run into the flickering problem a little easier since there are an extra 8 pixels floating above (or below) the part that is actually visible. And if you want to build a character with multiple palettes, you will have to fit those palettes into 8x16 sections instead of 8x8 sections. But those are relatively minor trade-offs compared to being able to effectively double the number of sprites on the screen. Is there some other disadvantage that I am unaware of? Also, can the game switch between the sprite mode at any given time, or is it set permanently in the cartridge, or what?

Those are all of the questions I have at this time. Thank you for your time.

The tiles are divided in 2 banks because one is supposed to be used for the background while the other is supposed to be used for sprites. However, this is configurable, so you can have different settings like both sprites and the background using tiles from the same bank (while the other bank is not used at all), or you can use 8x16 sprites and have them use tiles from both banks, or you can even change these settings while the screen is rendered.


What do you mean 512x512? each tile is 8 x 8 = 64 pixels. Since each bank is 256 tiles, that's 256 x 64 = 16384 pixels per bank. A square image with that many pixels would be 128x128, not 512x512. So what you really have is the equivalent of 2 128x128-pixel images.


That depends on the type of CHR memory the game has. The part of the video memory where the NES fetches tiles from is called pattern tables. It's a window of 8KB of memory (8192 / 16 = 512 tiles) that's filled in different ways depending on what kind of memory the cartridge puts in there.

Games that use CHR-ROM never "load" tiles per se, they just "map" a part of a ROM chip containing tile data to that window. Games with CHR bankswitching can map different parts of the chip to different parts of the pattern tables. Games change which tiles are mapped where for various purposes, like animating the background, rendering a new level, or animating sprites.

Games that use CHR-RAM map a RAM chip to the pattern table area. This means that the pattern tables are just a big blank when the console is first turned on, and the game program is responsible for writing (or loading) tile data to that memory. This is much slower than simply mapping part of a ROM chip, but gives the programmer complete control over the tiles, being able to even generate tiles dynamically.

Most systems (e.g. Game Boy, SNES, Master System, Genesis) only have the equivalent of CHR-RAM, because this RAM is inside the system itself. The NES is a rare exception, because the designers decided to route the tile memory to the cartridge instead of putting it inside the console, giving each game the option to use one type of memory or the other (ROM or RAM).


This all depends on the mapper and type of CHR memory. CHR-RAM imposes no restrictions at all, you can copy any tile from anywhere in the PRG-ROM to anywhere in the pattern tables, so you can combine tiles however you like. The only drawback is that since this is done byte by byte, it takes the CPU a long time to transfer new graphics into the pattern tables.

CHR-ROM makes changing tiles much faster (practically instantaneous, actually), but the ability to mix and match tiles greatly depends on the mapper. The most advanced mappers (e.g. FME-7, MMC5) can break the pattern table area into 8 1KB (i.e. 64 tiles) pieces. The simplest mappers will only allow you to swap the whole 8KB, meaning that to load tiles for a new level you need to replicate common tiles such as the main character and items across all 8KB banks.


With CHR-RAM, yes. You just won't be able to load many new tiles from one frame to the next. Realistically speaking, you can update maybe 8 tiles each frame while still running the game and updating other parts of the video, such as sprites or the tile map. With CHR-ROM you're restricted to the granularity of the mapper you're using (the minimum you can load is 64 tiles), but there are practically no restrictions to how many tiles you can change from one frame to the next, or even in the same frame.


A tileset is just what the name says, a set of tiles. The NES has this somewhat fixed length of 256 tiles per set, but it's not like it forces you to use them all, and with mappers you can access more than that, so the size of the set is somewhat flexible.

On top of that, most games don't address tiles directly, because that would make maps take a lot of memory (1KB per screen). Instead, they use metatiles, which are larger blocks constructed from tiles. The most common metatile sizes are 16x16 and 32x32 pixels, but there are all sorts of variations really. These sets of metatiles can also be called tilesets.


Normally, a cartridge has either CHR-ROM or CHR-RAM, but a couple of games are crazy enough to have both. How these are mapped to the pattern tables will depend on the mapper.


Yes, like I said above.


The total amount of CHR memory you have. The most advanced (non-pirate) mappers can only address 256Kb of CHR memory. Is that enough for all of your combinations?


Backgrounds can certainly be animated with CHR-RAM, as can the player. You just have to design things in a way that a realistic number of tiles are updated each frame. Let's do the math: there are 2273 CPU cycles during VBlank, which is the time when you can access the video memory. Copying a byte from ROM/RAM to VRAM takes 8 cycles, so if you only do this during VBlank, you can write 284 bytes, or 17 tiles. But you're obviously not going to do only this, you also have to change palettes, set the scroll, update the tile maps, update the sprites... all things considered, if you manage all these updates well, you're looking at 8 or so tiles per frame. Design your animations around that and you'll be mostly faithful to the capabilities of CHR-RAM.


The advantage is that you can cover more of the screen with sprites. At 8x8 x 64 you can only have 4096 sprite pixels (out of the 256 x 240 = 61440 pixels that make a full screen), while 8x16 can cover twice that. In most cases you won't actually cover twice the space, because there will be some blank areas, like you said.


The only one I can think of is that since sprites can't scroll smoothly from the top of the screen (there are no negative Y coordinates), 8x16 sprites will appear/disappear more harshly at the top of the screen than 8x8 ones.


It can be changed freely, but you should avoid changing sprite sizes mid-frame or it can mess with the sprite evaluation process.

That's two 128x128 pixel tile sheets. 256 tiles is 16x16 tiles, each 8 pixels, and 16 times 8 is 128.


If you're using CHR RAM, you can replace a tile at any time. You can replace all tiles while the display is blanked, or you can replace up to 8 tiles per vertical blank (10 if you push it) while the display is running. (The vertical blank is the time between frames when the CPU can load new information into video memory, and it happens 60 times per second.)

If you're using CHR ROM, it depends on the capability of the mapper, the circuit that sits between the PPU and the address lines of the ROM. The mapper controls which parts of the CHR ROM the PPU can use at one time. With a later mapper such as FME-7, you can think of the pattern table as consisting of eight windows, each 64 tiles (128x32 pixels) in size: four for background and four for sprites. Each window can be set to display a separate 64-tile bank of the CHR ROM. You can switch entire banks of tiles in and out of the window more or less instantly, and you can even switch different banks in for the playfield and status bar if your game has a status bar.


Only if you're trying to share metatile definitions between the two tile sets.


If you want to mix and match tiles arbitrarily, CHR RAM can do that.


Do you have NES ROM images stored on your computer? If so, you can load one into an emulator and open the PPU viewer window while to see what tiles are switched in and out of the windows.


The vast majority of cartridges have either only CHR ROM or only CHR RAM. Only a handful of games have both: Pin-Bot, High Speed, and a bunch of China-only games. It can't change at runtime, but we do have evidence of a game changing between the two during development.

• Ports of old cartridge games such as Super Mario Bros. to the Famicom Disk System use CHR RAM, loaded at the start of the game with the data that was previously in CHR ROM.
• Super Mario Bros. 2: Mario Madness was originally a Famicom Disk System game. Nintendo was originally going to use the same CHR RAM-based board that other FDS-to-cartridge ports (The Legend of Zelda, Metroid, and Kid Icarus) used, but in the end, it switched to a CHR ROM board.
• The incredibly rare Nintendo World Championships multicart contains Super Mario Bros. and Tetris, modified to use CHR RAM in much the same way as the ports to FDS, alongside the originally CHR RAM-based Rad Racer.

The FME-7 is representative of later mappers, and it lets you switch 64-tile banks.


Memory cost. Kirby's Adventure is the largest licensed NES game using CHR ROM. It has 256 KiB of CHR ROM, where each KiB (kibibyte, 1024 bytes) holds 64 tiles. The only games with larger CHR ROM are the Japan-only Metal Slader Glory and pirate multicarts.


If you duplicate a bank, it will count against the total size of CHR ROM, and most mappers were incapable of switching more than 256 KiB.


Nothing, which is why the CHR RAM-based Battletoads is full of tile animations. It's just somewhat tricky to keep things as interesting by loading only 8 tiles per vertical blank, especially if you have to share those 8 background tiles with loading new sprite tiles.


You could, and you could. In fact, the engine of my current NES platformer project loads a whole new image for the player and each enemy every frame, using double buffering so that it can display one frame of animation while the next frame is being loaded in at 8 tiles per vertical blank.


Yes. The sprite size bit can even be changed partway down the screen, between the status bar and the playfield.

I guess I'll avoid being a killjoy. This topic might also be an interesting read for you: viewtopic.php?f=21&t=10808

Whoops! I meant 128x128, not 512x512. I should have checked my notes; 128x128 is what I already have written down. Thanks for the catch!


Okay, but since sprites and background tiles can come from either bank, are there any restrictions about how they can be divided up? Because I was under the impression that there was technically no actual restriction, and using one for sprites and one for background is just an arbitrary suggestion. I also was under the impression that I could even use a given tile as both a sprite and a background.


OOOOHHH, that makes so much more sense now!

Also, that totally explains why some dirty connections resulted in funky-looking screens, but yet I never saw that happen with other systems. Because the system functions themselves ran back into the cart, so a bad connection will put lines through everything.


Would I be correct in assuming that none were officially licensed for the NES?



Okay, that's 256Kb of CHR memory, so that means memory just for tiles, right? As opposed to memory that needs to also house all of my program code, music, sound effects, and whatever else.
That puts my game's artwork at an upper limit of 16,384 tiles, or 64 separate 128x128 images. And if I use CHR ROM, then any artwork I would need in multiple scenes would get duplicated multiple times, even the tiles I need for text. Yeah, suddenly CHR ROM sounds like a very bad idea for an RPG.


Okay, now that I have a better understanding of that, I am ready to ask about mappers.

First of all, I read something somewhere that suggested to me that while "mapper" and "Memory Management Controller (MMC)" are used interchangeably, the term "mapper" technically refers to how an emulator handles the tile memory, whereas back in the day developers working with actual cartridges would have called them MMC's. Would the be correct, or did they call them mappers back then too?
(I know it's not really important, kind of like how people use "font" and "typeface" interchangeably, even though they are not technically the same thing. But it still is cool to learn this stuff.)

Next I want to find out what MMC I would want to emulate for my game. But when I read through the information on this site, it is completely beyond me. I guess I'd need to know assembly or something. And the information listed on wikipedia doesn't so much to help me know the technical limits.
But since the MMC5 was a more expensive chip, it seems to be more than what I would want to use. (Although its extended graphic abilities are tempting.) So apart from third-party chips, given the point in time at which this style of RPG began to emerge, I'd probably want to presume it would use the MMC3. (Maybe the MMC1, if I decide that the title was "originally made" in Japan.)
Even so, I think it would be best to just get the relevant information and decide what chip to use as the game develops. But as I said, I can't find a page that shows me the relevant information in a manner that I understand. How many tiles can each mapper load in an average frame? What other unique features do they come with?

Also, while the whole cart may have its highest limit for CHR data at 256 KiB, I suspect that wasn't very common, and possibly wasn't even an option until later in the NES's lifetime. Is there a timeframe of when those memory limits were raised?

Consider both banks separate. Consider that to access most of this stuff, you'd be writing a single byte. So the range is only 256. For this reason, you couldn't have say... 400 tiles for the background and 112 for sprites. I feel like that's what you're asking. (Well... that's the simplified answer, because you can access more than 256 tiles with certain mappers...)

Sprites and backgrounds can come from either bank, but it's one or the other, not inbetween. I can use bank 0 or 1 for sprites, I can use bank 0 or 1 for the background. So I could use bank 0 for sprites and bank 0 for the background or bank 1 for sprites and bank 0 for the background etc. Only 4 choices, and only 2 effectively unique choices. (A separate bank for both, or the same bank for both.)

8x16 sprites can access both, but again it just uses a byte. A single bit tells the PPU to use 2 tiles from bank 0 or bank 1. All the other bits say which two tiles. This means you can use tiles 0 and 1, or 2 and 3 in either bank to make a sprite, but you cannot use tiles 1 and 2. Allowing this would require a larger number than a byte provides.

In the case of CHR ROM, that's what the means. In the case of CHR RAM, all your music, code and whatever else is with your graphics in PRG.

Not true. If you plan to use tiles in multiple "sets", you could store them once if you plan well. Some mappers allow you to deal with 64 tile sets instead of 256 tile sets. So you could store a reusable part in 64 tiles, leaving 192 for other stuff. Say you had... four sets. A city, a forest, a swap, a mountain. All of them shared no more than 64 tiles.

So... 64 stored once for the reusuable portion.
Then
192 for the city,
192 for the forest,
192 for the swap,
192 for the mountain
= 832 unique tiles that needs to be stored.

Rather than the 1024 that 256 for all of them would take.

To put this set together in PPU memory, you'd swap in the reusuable portion to say... the first 64 tiles, then swap the remaining three 64 tile segments that correspond to the specific map to the last 192 tiles.

Depending on how you arrange things, your font doesn't even need to impact what's displayed for your map. You could have 256 tiles displayed for a map that doesn't include the font at all, and then ALSO have your font on screen. This is done by swapping out the tile sets after part of the screen has been drawn, and this is ONLY possible with CHR ROM.

Smash TV draws more than 256 tiles in its title screen with this method.

MMC5 is the one that lets you use 16384 tiles at once, instead of just 256. It also allows all kinds of other things that don't feel very NES, since most games didn't have access to them. I won't say it's cheating, but I'll think it loudly.

It's not... "loading", it's swapping. Swapping is instantaneous, so you can draw the screen using quite a few different tiles. See Smash TV. And MMC3 is VERY common, but I don't think maxing out the CHR was, no. It first appeared in 1988.

Edit: At any given time while drawing the screen, the PPU is drawing the background from the set of 256 tiles currently in its memory. The thing about is that this set its using to draw can be swapped out while its drawing. Let's just say... the limit is HIGH for what you can do, but for a practical answer assume you get 256 tiles for some kind of HUD (say... your textbox that displays NPC dialog), and a separate 256 tiles for your map that you can have on screen at any given time.

It's easier for you to describe the type of gameplay you want, and we can tell you what will allow that. What NES can do is very fluid.

Since a picture is worth a thousand words, let's illustrate CHR bankswitching with Megaman 5:



I highlighted the pieces that can be switched in and out in red. Left side has two parts that can be switched, right side has 4 parts that can be switched.
On the left side, this game switches the second page to animate the tiles.
On the right side, it switches the top page when Megaman's animation sequences change, switches the second page when a different weapon is selected, and switches the fourth page for different kinds of enemies in the room. (no enemies are there, so it just selected Megaman's graphics instead)

Nope! High Speed and Pin-Bot are two (the only two?) officially licensed NES games that contain both CHR-ROM and CHR-RAM.


Some mappers (including TQROM, used by High Speed and Pin-Bot) allow you to switch banks of CHR-RAM mid-screen. Of course, you still need to wait for vblank to upload tiles to CHR-RAM.

Out of all the games to use CHR ROM and RAM, they where pinball games. Wow.

The background uses only 256, and 8x8 sprites use only 256. In 8x16 sprites you can use all 512 tiles. But in mappers with an interval timer that counts scanlines using PA12 rises, scroll splits require the background to be in pattern table 0 and the sprites to be in pattern table 1, and one of those mappers is the very common MMC3. No other common mapper has this limit, especially not FME-7. A workaround on MMC3 is to switch the same 64-tile bank into both one of the sprite windows and one of the background windows.


Yes, for the most part. A few games that were just barely over a power of two in PRG ROM size stored music, sound effects, or level maps in the CHR ROM. I can think of at least Super Mario Bros. (title screen map in CHR ROM), Galaxian (music in CHR ROM), Milon's Secret Castle and Dragon Warrior (a bunch of stuff in CHR ROM), and Big Bird's Hide and Speak (shorter voice samples in CHR ROM). Reading CHR ROM is as slow as writing to CHR RAM: only about 128 bytes (8 tiles) can be read out into RAM per vblank.


If you put the text on a separate scanline, such as in the status bar, you can switch a different set of banks in for the status bar.


MMC was the brand name for Nintendo's ASIC (application-specific integrated circuit) mappers, which were the most common ASIC mappers among licensed NES games. Konami's ASIC mappers were called VRC series, Namco/Tengen had one called MIMIC-1, Sunsoft's most famous was called FME-7, etc. Though plenty of Famicom games use non-Nintendo ASIC mappers, only a handful of licensed NES games do so, because it was easier to get Nintendo Co. Ltd. to approve Famicom mappers than to get Nintendo of America or Nintendo of Europe to approve NES mappers. Some simpler mappers, used especially early on in the NES's life, are made out of 7400 series discrete logic chips rather than an ASIC. But the only RPGs I know of on discrete mappers are Japanese: the Japanese version of Dragon Quest and legendary crap game Stargazer.


Most MMC3 games use CHR ROM. The only ones I can think of that use CHR RAM are Mega Man 4, Mega Man 6, Ninja Crusaders, and the Japan-only Final Fantasy III. Pin-Bot and High Speed have both CHR ROM and CHR RAM.


You could try searching NesCartDB for CHR ROM sizes and finding when those games were first published.

Is a "swap" a swamp?

But then how do some games...


...oh that's how.
And actually that makes a lot of mathematical sense. Since 8x16 mode assumes that you are taking a tile and the one right after it, you technically only need to point to half as many tiles. Or more smartly, you can point to 128 tiles in one bank, and 128 tiles in the next bank. Pretty clever.

But this ultimately means that while I can fill my sprite data form either bank (when in 8x16 mode) I still can only fill my backgrounds with tiles only from one bank.

This is unfortunate, because I'd need to build all my text and my enemies as backgrounds, since I can't have more than eight sprites per scanline. So I need to learn more about the tricks to maximize my background data.



Well f*** me; how much space is there in PRG? And on average, how much of that is used up my music and sound and programs and stuff?


Okay, that's good news. What mappers do that?

Hmm... A full set of letters (with upper and lower-case) including the menu borders is already going to take up 96 tiles.
I could fit it into 64 if I have literally only two punctuation marks, if I didn't need a tile for blank space. That still doesn't really work...


Hmm, okay, but if I did that, the text box would have to fill literally the whole screen, would it not? We draw out the normal screen so far, swap tiles, and then draw the text box. That would be fine for the battles (in fact, I could do a lot in the battles if it is possible to swap multiple times) but everywhere else it would look out of place. All the other RPGs have text boxes that just float in the screen, and you can see stuff around them.

What else could I do to get more distance with my backgrounds? (Other than use MMC5, which I have not forgotten about.)


in the simplest terms? Another Dragon Quest clone.

That might explain why the tiles on the original Japanese Dragon Quest were so... limited.
A legendary crap game? Sweet!
*looks up gameplay videos*
...Woooowwwwwww!


Holy crap, how do you guys know all this stuff right off-hand?

There are two major exceptions. One is the MMC2 and MMC4 mappers, which extend the number of tiles for the background to 510... but you have to have horizontal strips from the same bank.

The MMC2 was used in Punch-Out!!, where its primary function was the big portraits of the fighters.
The MMC4 was used for a number of Japanese-only CRPGs, where it's useful (for example) for dialog boxes that are not the full width of the screen.

The other is the aforementioned MMC5.

The practical upper limit is 512 KiB, but there are a small handful of games that exceed that. (There is no theoretical upper limit: one could put a SD card inside an NES cartridge and use all of for a single game.)

Unless you use CHR-ROM and bankswitch mid-screen, right between the gameplay and text areas.

Another option to get more background tiles, if you're willing to sacrifice sprite tiles, is to steal part of the sprite pattern table for text, for example, and swap which pattern table is used for the background mid-frame. That would work even with CHR-RAM.


Most official mappers top at 512KB of PRG, but the MMC5 can go up to 1MB. Music code and data doesn't typically occupy more than 32KB (unless there's a lot of samples), but this can vary a lot from game to game. Storage is hard to estimate because every game uses different formats for the various kinds of data they need. And since you'll not be using 6502 assembly, you definitely shouldn't expect your code to occupy a similar amount of space to 6502 machine code.


Not really a problem for CHR-ROM, since you can change the entire tileset instantaneously mid-screen. But should you decide to simulate CHR-RAM you can steal the necessary tiles from the sprite pattern table like I suggested above.


Maybe you're thinking of SNES RPGs? I don't really like RPGs, so I don't know them as well as I know other games, but text boxes on the NES typically occupy the whole width of the screen. They sometimes scroll in smoothly so they look like they're floating, but there's nothing actually visible around them. Games that do have stuff around their text boxes probably make everything fit in 256 tiles somehow.

Now that I think of it, there's one mapper (MMC2, I think) that can switch patterns automatically when certain tiles are drawn. Something like that could possibly allow you to use a different tileset in the middle portion of the screen, if you used the tiles on the edges of the text box to do the pattern switching. I don't know if any games do that, though.

EDIT: Oh, so it's MMC2 and MMC4 that switch tiles automatically. The problem is that those mappers use 4KB CHR banks, which suck for combining tiles, specially considering that the maximum CHR-ROM they can have is 128KB (32 4KB pages).

Like everything else, it depends on the mapper. You can usually see the max you can use on the mapper's page. MMC3 can have 512KB of PRG. In theory it could support 2048KB of PRG, but I believe you wish to stick to official implementations.

How much space things take up is hard to give a number for. Music size depends on what's supported by the music engine, for instance. Code size depends on how simple your logic is.

And even though using CHR RAM effectively keeps you from using the 256KB of CHR ROM space in MMC3, one of the benefits of CHR RAM is that your graphics data can be compressed.

Well, like I said, you could have 256 characters in your font and still use 256 tiles for your map.

Or with CHR RAM, you could only store the tiles for the text currently being display in the PPU set. Super Bat Puncher (homebrew) does this.

The benefit to this method is that you can have the rest of your map around the textbox. If you want to use a different set of characters for your font than your map using CHR ROM, nothing else can occupy the same horizontal lines as the text.

Here's an example of CHR ROM swapping

Note that none of the map set contains any letters, but as a consequence the text boxes must cover the map entirely.

No, see the above. Again, you can swap out the 256 tiles the PPU uses to draw from while it's drawing the screen.

Edit: Oh wait, reading again you know this. I'll say that RPGs that have floating textboxes like Super Bat Puncher's tend to suffer from simplicity in graphics precisely because they need to dedicate so much space to font, but that's also because most don't do it with CHR RAM like Super Bat Puncher does. But your text boxes must be small, or a Super Bat Puncher style thing will use even more tiles than just storing all the letters.

You can swap out tiles a bunch of times if you want. Here's Smash TV's title screen:

But all those unique tiles are of course using CHR space.

Then MMC3 would be fine for you. Perhaps even overkill. The Dragon Warrior games like "worse" mappers.

It's fairly easy to look up: http://bootgod.dyndns.org:7777/advanced.php

But anyone who's done this has for a while has likely studied and will remember how certain games did things.

Examples:



I mean, I suppose they certainly can be just using up a lot of their tiles for the text; they do use very simple backgrounds with few tiles. But I'm looking into all the possibilities.


Hmm, that's a pretty clever idea. Of course, it would limit the amount of space I could use for text, but I will keep the idea in mind.



What are the limits for swapping out tiles multiple times per frame? How many times can you do this? Can you do it... in the middle of a line? Like draw part of a background, swap tiles, draw more background, swap tiles again?

The largest PRG ROM in a licensed game is 512 KiB. This is the size of Mega Man 4, Mega Man 6, the English version of Dragon Warrior III, and Dragon Warrior IV, which use CHR RAM. It is also the size of Kirby's Adventure and Metal Slader Glory, which use CHR ROM.


It depends. You also need to be able to fit map data in PRG ROM.


MMC3 has 64-tile banks, two large windows (which reflect one even bank and the corresponding odd bank, such as 54 and 55), and four small windows (each of which reflects one bank). You can use the large windows for backgrounds and small windows for sprites or vice versa. FME-7 has 64-tile banks and eight uniform windows, which means you get 8 for backgrounds and 8 for sprites.


If you use CHR RAM and load only the letters used in a particular text box, you can fit four 128-pixel-wide lines of text into 64 tiles. This trick is used by the licensed game Faxanadu and the homebrew game RHDE: Furniture Fight. The text engine in RHDE even uses a proportional font to fit more text and make it look nicer, which is something you can only do with CHR RAM.


Proportional font in Action 53 menu


Monospace vs. proportional


CHR RAM can be swapped too, but this needs more than 8K of CHR RAM, and only a handful of games have that. But in a CHR RAM game, if your sprites use only the first 192 tiles of pattern table 1, you can change the status bar to use the last 64 tiles of pattern table 1.


The licensed game Faxanadu and the homebrew game Super Bat Puncher have floating text boxes. They both reserve CHR RAM tiles 192-255 at all times for a 128x32-pixel text box. RHDE has even bigger floating text boxes, and it in fact reserves tiles 128-255 for proportional text.


Some less popular cartridge board configurations are used by fewer than a dozen games. If you're aware of a configuration, you can memorize which games use it because you know a homebrew using that configuration will need one of those as a donor unless you can use an all-new-parts vendor such as RetroUSB or Infinite NES Lives.

One thing that might dictate a mapper choice is how you plan to save the state of a campaign between play sessions. Do you plan to make a game short enough to play through in one sitting? I seem to remember reading that Dragon Warrior added level grinding specifically to encourage purchase rather than rental. (Compare to the hellish grind of modern micropayment-driven mobile games.) Do you plan to make it so that the state can be represented in 32 bits? Even for an RPG, an 8-character password that represents 32 bits might suffice, as I explained earlier:

• Money (8 bits) nonlinear, possibly quadratic
• Experience (8 bits)
  May be divided into 5 bits for character level and 3 bits for fraction of experience needed for the next level
• Weapon (4 bits)
• Chapter (4 bits)
• Event flags for this chapter (8 bits)

A 4-bit number is 0 to 15. An 8-bit number is 0 to 255. A quadratic 8-bit number can be 0, 1, 4, 9, 16, 25, 36, ..., 65025.

If 32 bits are enough to save your campaign, you can go wild with mappers. But if you need to save more than that, you need battery save. The most common mapper for RPGs using battery save was probably MMC1 with CHR RAM.

Reliable mid-scanline CHR ROM bank switching is pretty much limited to the MMC4, used only for three Japan-only strategy RPGs in the series that the rest of the world knows as Fire Emblem and Advance Wars.

You're right, there are probably quite a few examples. I'm pretty sure that most of them just make everything fit in 256 tiles though, instead of using any tricks.


You can swap CHR as many times as you want per frame, considering the small amount of time it takes to send the switch command to the mapper. The exact timing will depend on the mapper, but the MMC3 for example needs 13~14 CPU cycles to swap each bank. There are 27280 CPU cycles in the visible part of the frame, so you could swap banks over 2000 times in a frame if you were doing only that (which you obviously wont be). So yeah, it's perfectly acceptable for you to switch banks tens of times per frame, and there will still be plenty of CPU time left for the game logic.


You can, but timing that is kinda hard. Mainly because synchronizing the CPU and the PPU down to the pixel is a very hard (if not impossible) thing to do on the NES, so even if you try to do the switch at the exact same point every time, there will always be several pixels of error. You can maybe hide that with thick borders using tiles that don't change with the switch, but this isn't something a typical NES game would do.

Oh flip, my ability to use a battery-baked up save file is dependent on what mapper I choose?

Great, then I'm gonna need to know what battery-save options are available.
I doubt that I would be able to condense all of the needed data into something that small. Not for the kind of project I want to do. (Also, are you suggesting the small amount of save data because it could be reasonably saved with a password, or are you saying the MMC3 and/or most mappers can use a battery save that small?)

Oh and what emulators let me view the tiles like Kasumi was showing? It does not appear to be an option in the one I already have.

FCEUX for Windows. Click Debug -> PPU Viewer to view the pattern tables.

A password is that small. A battery save can be a kilobyte or more.

Wow! This is extremely insightful! This helps a lot to see how these other games are using their space, and I'm impressed at how well many of them are managing their tiles.
This also shows how they are using their palletes, and I am again surprised, because I thought many of these use a green for their background color when on the overworld, but they still use black. Fascinating.

Okay, so let me review what I got before I finish for the evening.

Using CHR ROM with the MMC3 or FME-7 (and possibly others) I could swap out tiles in chunks of 64 (one quarter of the tile bank) at any time, even in the middle of drawing a frame. This would give reasonable-sized chunks of tiles that could be swapped out at any moment, still preserving some semblance of being able to fine-tune exactly what enemies I fight in a given area, PLUS I could even extend those limits by swapping out in mid-frame. In a standard battle, I could draw a background decoration at the top of the screen, change to enemy tiles and draw them, (even changing tiles again after a row to have more enemies,) and then switch out to an extensive array of text tiles, even including special tiles for certain words that I want to draw in a tighter space. And outside of battles, if I'm willing to use the entire width of the screen for my menus, I can greatly expand how many tiles I have for an area. However, I will be limited to no more than 256 different tilesets of 64 tiles for the entire game, so I can't exactly go crazy with how many tiles I use for all of these different things.

Using CHR RAM with (well, most chips will work fine, I guess,) I could fine-tune what tiles I want to load even further, giving me complete control for any combination of enemy tiles I want, but I have to share the tile space with the tiles for the text, and a background decoration if I want it. (And while that sounds limiting, that is actually how most of the RPGs I'm using for examples did it, so it is enough for the game.) Furthermore, I could potentially extend my number of tiles for the whole game even further, since I'd have 512 KiB of shared data, assuming I keep the other data reasonably low. And I could have individual areas (towns and dungeons and such) that have more unique tiles since I could load even just one different tile from another area. And I could have small animations in the backgrounds without using up a lot of my overall data limits.

So I'm basically facing the decision of do more on one screen but do less for the whole game, or do more for the whole game but do less for one screen.

(Or just use the MMC5 and not give any f***s about how my tilesets are arranged because I can use any tile any where.)

I still need to find out how having a battery-based save file will effect my options, but other than that, if everything I understand is correct, I'm ready to start putting together some samples to see what option sounds the most useful to me.

There are always a few exceptions...
The VRC4 and JY Company's mapper support 512 tilesets.
The MMC5 supports 1024 tilesets, if you don't use the arbitrary 16k tile mode.

Wait... I just found something that defies what I understand.

Here's a shot from Final Fantasy 3, with the PPU viewer shown:


The player's party and all the various battle effects are drawn as sprites, and everything else is drawn as background. (This can be confirmed by examining the palettes.)

But yet, we can clearly see that the sprite tiles fill the first six rows of both banks, and the remaining data is used for the background.
That's 192 tiles for the sprites, and 320 tiles for the background.

Now granted, in this particular image, neither the sprites nor the background tiles are using that full amount of space, but even so, we can clearly see that the background is using tiles from both banks at the same time.

How is it doing this?

A "mapper" is...well, it's several things, but here we're talking about what hardware's in the Game Pak. So, strictly speaking, you could do something that people didn't do in terms of combinations.

As for 8-character passwords...I can't think of any that were so short as 8, outside of those that strictly encode "what level am I on": Lolo, Lost Vikings(4c).

Several were longer, such as Simon's Quest (16 chars), Dragon Quest (20 kana!), Metroid (24 characters "JUSTIN BAILEY ------ ------"), Kid Icarus likewise 24, Faxanadu (Variable, can go at least to 24 characters?), Clash at Demonhead (32 characters)...

I feel like I'm forgetting some monstrosities...ah. Dragon Quest 2 (52 kana!), or, outside of the NES era, Golden Sun's Golden Password (256 characters).

Just...just have a save system.

In the top half of the screen, backgrounds use pattern table 0 and sprites use pattern table 1. In the bottom half, backgrounds use pattern table 1. That's what I meant by using a separate set of tiles in the status bar.


Mario Is Missing (Super NES) and Tetris Attack (Super NES) have 8-character passwords.


And Mario's Time Machine (16 chars).


The Lord of the Rings (Super NES) (48 characters), Maniac Mansion (Famicom) (some ungodly amount)

It's not at the same time. FF3 uses a mapper IRQ in order to rewrite to an hardware register in the middle of rendering, so that the left pattern table is used at the top and middle of the screen, and the right pattern table is used at the bottom of the screen for the status bar / menu area. The details are explained in my doccument "How to do raster effects with the NES". Squaresoft are known to use a lot of raster effects in their games (not only FF), on the other hand, Enix hardly ever uses any in their Dragon Quest games. Don't be confused by what appears to look like sprites on the left pattern table, it actually is unused (to be verified)

Like I said before, you can change which pattern table is used for what at any time. This screen starts with the background using the left pattern table, but for the text area it switches to the right pattern table. So yeah, it's not at the same time, it's either one or the other for any given scanline.

This is what I meant a few posts back when I said you could sacrifice sprite tiles in favor of the background. This works for CHR-ROM and CHR-RAM.

In FCEUX's nametable viewer, change the current scanline to 0 or 220 and see what breaks.

Ah, that was the abomination I learned from TCRF I was trying to remember. 125, kana OR [most] roman (64 char options(2^6), 125 chars long...so, 750 bits of data.)

Oh, so you did. Sorry, this thread has had a lot of information to process.


A couple of other questions that have come to my mind while I was examining various games to see how they do what they do...

I was thinking about adding small percentage-bars in the battle sequences, so I looked at how other games have made health bars and the like. Mega Man just has five tiles it uses to draw any amount of pegs it wants to fill in its health bar, which made sense. But when I looked at Zelda II, I could only see graphics for an empty bar-segment and a full bar-segment. Yet in the game you can have any value fill the health bar, even just one pixel more or less, as far as I can tell. How do they manage that?

Next question. If a game were using CHR RAM, how quickly could it load tiles if it wasn't trying to compute anything or draw anything new? I mean like, in the middle of a sequence, but everything can pause for a moment. So the only thing going on is that the system is continuing o display its current image and play music, but nothing is moving on the screen and it isn't computing any new data.
My thinking is that before performing an action, I could maximize my number of tiles by loading the tiles it requires only before the action is performed. Like in a battle, a character is about to cast a spell, the character raises up his hands, and the text screen says the name of the spell. That frame there could be held for several frames, even a whole second, just for dramatic effect. That time could be used to load the graphics needed for the spell. The question is though, how many tiles could be reliably loaded while the system is in such a state?
For the sake of argument, we could assume the mapper is MMC3, but if another mapper has stats worth mentioning, that's fine too.

Third question, possibly related. In Final Fantasy 1, when you press B and select on the overworld, it draws a map of the whole world. When it does this though, it draws it one line at a time, and it takes a couple seconds to do this. I always figured, well, its a big image, and it takes time to draw that. But now today I think that it shouldn't take so long for it to load it into memory. First of all, when you exit the map, it loads the graphics for the overworld in an instant, and that's just as many tiles as the in-game map. And when I view it in the PPU viewer, I see the image load one line at a time across 16 tiles, But I would assume the tiles are loaded one tile at a time, not sixteen at once.
So what is going on here?

Fourth question... Why do some games have the left-most column black the whole time? It's not just something I've seen on some roms on an emulator, I can see the effect happening with the physical games running on my NES as well.

Fifth question... I assume this is impossible only because I've never heard anyone mentioning this as a trick before, but can a palette be changed in the middle of a frame? Perhaps something like the bankswapping; draw so many lines, then change the palette, draw the rest of the image, and thus extend the color capacity of an image by displaying more colors on a single frame?

It looks like sprites are used as well (tiles $6F and $71); the sprites are likely hiding behind the background tiles.

Ohh, I see; so it draws the last box as a completely empty box, and has a sprite behind the bar that moves back and forth. They sacrifice a whole sprite palette to do it, but it seems they use that one for the experience point numbers and other such things.

The vertical blank is 2273 cycles long, and with the fastest possible code copying tiles from PRG-ROM to VRAM it takes 8 cycles to transfer each byte. Each tile is 16 bytes, so in that time you could safely change around 16 (a nice power of 2) tiles if you're not doing any other PPU operations. This means that updating a whole 256-tile bank would take only 16 frames, which is only 26.66% of a second. That's pretty fast, as far as the player is concerned.


Updating CHR-RAM always takes the same amount of time regardless of the mapper. Theoretically, it is possible for a mapper to speed up VRAM transfers, but no such mapper has ever been made.


The PPU has a setting to hide the leftmost 8 pixels of the screen. It can hide the background, sprites, both, or none. The option is there mostly so that games that scroll horizontally while using horizontal or single-screen mirroring can hide the scrolling seam. But even then, 8 pixels are only enough to hide tile updates... attribute updates would need 16 pixels, since palettes are applied to blocks of 16x16 pixels. Look at the left and right edges of the screen in games like Kirby's Adventure or Super Mario Bros. 3 and you'll see some miscolored blocks as the screen scrolls.

On the Master System, any game that scrolls horizontally also hides the leftmost 8 pixels of the screen, because in that console, the tile map is always 256 pixels wide, the same as the screen. It doesn't have the attribute problem though, since palettes are applied to each tile on the Master System.


It is possible (see this recent thread, for example), but it's not nearly as simple as switching patterns. Changing how the patterns are mapped doesn't interfere with the rendering process of the PPU, but changing the palette involves manually writing new data to the PPU memory, which conflicts with the rendering process. So, in order to change the palette, you have to disable rendering (at a proper time that doesn't cause sprite corruption), do the updates (at a proper time that doesn't cause a visible "rainbow" effect), set the scroll so rendering resumes from the correct place, and finally turn rendering on again (at the proper time). As you can see, it's a very timing-sensitive operation that has its limitations (you need a few blank scanlines in order to do it without glitches), but it can be done. It wasn't done often in commercial games though, there are very few examples.

Look at it in a debugger to see what's going on. In a nametable viewer, you can see that the health bar in Zelda II is made mostly of background tiles, but the last segment is left empty. This last segment is filled in by a single sprite with the "background" flag set so it can slide back underneath the nametable health bar.



If you turn off rendering for a frame (i.e. the display will show only a single background colour for the whole screen), you can spend the whole frame uploading new tiles, etc. By doing this you can make very quick transitions, but there will be at least one frame of nothing on screen.

Otherwise you have to do all the graphics updates in vblank, which is about 1/10 of a frame, so really you can do a transition 10x faster if you turn the screen off. The reason Final Fantasy takes so long to draw the overworld? I think Nasir had an idea for that animated effect that he thought would look cool, and uploading one row of CHR tiles per frame probably takes up a whole vblank. (32 non contiguous bytes, so it must change the address for each byte. Basically 32 bytes of data and 64 bytes of addressing? That's more or less a full vblank worth of stuff.) If you're animating something you're at the mercy of vblank bandwidth. (I think it's possible that there are faster ways to accomplish the same visual effect, though. FF1 does it in a very simple way.)



This is a hardware feature to optionally hide the left 8 pixels. I believe the reason they put this in is that you can't specify a negative sprite position, so you can't have sprites sliding off the left of the screen, partially hidden, even though you can do this on the right side. (i.e. you can start a sprite at X=255, and only its left column of pixels is visible, but a sprite at X=0 is fully visible). The NES lets you hide both the background and sprites on the left to hide this defect and act as if the screen cut off there. The top and bottom of the screen should have the same problem, but on NTSC the top and bottom 8 pixels are not drawn by the TV anyway, so they didn't add any hardware feature to address this (though on PAL televisions you can see this problem because they do not hide the top rows).

Also, like tokumaru mentioned above, games like SMB3 that do multidirectional scrolling tend to have an "attribute clash" problem on one edge of the screen. I don't think the NES was really designed to do multidirectional scrolling (only horizontal or vertical) but this hardware feature at least lets you hide 8 pixels worth of the problem, so a lot of games that scroll freely will use it.

Good to know!



Hmm, that sounds like it is actually depending on the interlacing to even be displayed without a blinking monitor, and it would result in an image that more modern TVs wouldn't even display because it is unstable.
Well, I guess that would depend on exactly how the NES outputs its signal; it could be avoided.

Either way, doesn't sound like an effect I would want to try to duplicate then. Might be fun if I was trying to make homebrew, but not for this project.


So it's not actually a technical limitation, it's an artistic choice (presumably.)
I was starting to wonder if the map is actually drawing it by reading the the actual world map and then using that data to create tile data. Don't really know the NES capacity for doing something like that anyway.
As a side note, I recall when I tried playing Final Fantasy on the second model NES (the top-loading one) I could have sworn that the map drew faster than it did on the old NES. Looking back now I suspect I might have just had better patience because I'm older. If I still had a physical cart for that game and a working old NES I would love to test it.


Ohhhhh! That make a LOt of sense! And as I think about it, I think I've seen a bunch NES games that did have sprites suddenly appear on the edge of the screen like that.
Hmmm... It won't be hard to make a sprite disappear if it's left most pixel is past the edge of the screen. Good to know I don't need to worry about that with any other edge.



Oh yes, I have so noticed that in Super Mario Bros 3. I've even seen that happen on the top of the screen in Faria.
So perhaps the bigger question is, why do some game NOT do that? I've never seen that happen in Dragon Warrior, Final Fantasy, or Castlevania II, and all of them scroll both ways.

Not really. There's not much you can do on the NES to mess with the video signal, other than modify the dot crawl pattern (which is harmless) or screw up the sync by using the "blacker than black" colors (which you can easily avoid). The only problems you'll find if you don't time palette changes well is wobbling colors (if the palette is accessed outside of hblank) and a jumpy image below the split (unstable scroll reset).


You're essentially faking things, right? If you just leave a few scanlines blank in the area where the colors are supposedly being changed, that's authentic enough.


The main reason is that the NES only has memory for 2 tile maps which are exactly the same size as the screen (256x240), and these can be arranged horizontally or vertically. This is great for games that scroll in only one axis, because they get an entire screen to perform scroll updates hidden from the player. With multi-directional scrolling though, there will be one axis with no buffer area at all. Some games artificially create this hidden area to avoid visible glitches, but some programmers just didn't care.

Look at Alfred Chicken and Felix the Cat, for example. To avoid the color glitches like those in SMB3 and Kirby, they drew a column of black sprites across the entire right side of the screen, to mask the rightmost 8 pixels, since the PPU can only mask the leftmost 8. This way they can hide a total of 16 pixels, which is enough to hide attribute updates, at the cost of effectively reducing the sprites per scanline limit to 7.

A lot of programmers decided to arrange the tile maps horizontally instead, so that glitches would be at the top and bottom instead of the sides. This worked well in NTSC, because most TVs don't show the topmost and bottommost 8 scanlines, which is enough to completely hide the glitches. On PAL consoles/TVs those glitches were probably visible. Some games did go through the trouble of hiding the glitches in software, like Jurassic Park, that uses CHR bankswitching to map blank tiles at the top and bottom of the screen. Since the patterns are all blank, it doesn't matter what palettes or what tiles are used there, so that area can be used for updates.

Another solution was to put extra memory on the cartridge so that there would be 4 tile maps available instead of just 2, but very few games did that (like, 3 games or so).

I can't say for sure about the games you mentioned, but make sure your emulator isn't hiding scanlines (FCEUX for example defaults to hiding 8 scanlines at the top and bottom, simulating what a TV might do) to make sure that there really aren't any glitches. I don't remember these games doing anything to achieve 100% clean scrolling, but I didn't check.

Probably because the glitches were hidden in the overscan area at the top and bottom of the NTSC picture. Have you tried playing these games through a video capture card or with all lines shown in an emulator (0-239 in FCEUX)?

Oh, I see!

When I turn on the name table viewer, it says the current mirroring is "horizontal," which I gather means the display in the view is being mirrored horizontally, because the game itself is scrolling vertically.
So In the games I mentioned, they are scrolling horizontally, and in SMB3 they are scrolling vertically.
This makes me wonder why SMB3 would opt to use vertical scrolling, knowing it would produce this error. But I suspect the answer is about speed; they need Mario to be able to move fast, and they can re-write the vertical edges of the tile map faster than the horizontal ones (because there are fewer tiles.) But for the RPGs and Castlevania II, they don't need to move as fast, so they can re-write all of the horizontal edges in the time it takes the player to move that far.

For SMB3, I'm pretty sure it has to do with the status bar. If the name tables were arranged vertically, it would be harder to divide the small vertical space (240 pixels) in a scrolling gameplay area and a status bar area. With the name tables arranged vertically, there's a lot of vertical space to move up and down without even touching the status bar.

That's the deal with multi-directional scrolling on the NES with only 1 or 2 name tables: there will be glitches in at least one axis, and you must choose which glitches bother you less so you can live with them or even neutralize them if you're up to the task.

You can nearly eliminate glitches by setting VRAM A10 = PPU A10 XOR A11. This produces diagonal mirroring:

Diagonal mirroring produces glitches only at the corners of the screen. It's possible on MMC5 and a few other mappers, and it could be done in discrete logic with a 74HC86 (quad 2-input XOR gate), but I don't think any existing game uses this.

Yes, diagonal mirroring does reduce the problem a lot, but few mapper configurations allowed it. If you wanted completely clean scrolling you'd still have to do something about the corners though.

Horizontal mirroring produces attribute clash at the sides of the screen. Vertical mirroring produces attribute clash at the top and bottom. On NTSC because the top and bottom 8 pixels are hidden, you can actually completely hide the attribute clash if you're careful. (On PAL this technique is not effective: these games do have attribute clash at the top and bottom in their PAL versions.)

The reason SMB3 doesn't use vertical mirroring is because it has a status bar. A status bar normally has to sit at a fixed location on one of the nametables, which means you can't "wrap" the screen vertically over the status bar. Every room in SMB3 is a maximum of 2 screens high so that it never actually has to do any real vertical scrolling, everything is always vertically fixed in the nametables and the data only really scrolls horizontally. (There are a handful of vertical-only rooms that are an exception, they do a different thing.)

Another one you might take a look at in the debugger is Crystalis. This uses an IRQ timer in the cartridge to simulate vertical wrap by changing the scroll exactly on the seam to skip over the status bar.

Oh, I didn't even think about the status bar. Also, I think you typed something wrong because you described both of those situations as "if the name tables were arranged vertically."




Ah Crystalis. Now there is a game that I have been meaning to play for twenty-five years, but never got around to it.

True. The first time should be " horizontally ".

Just wanted to say that basically, yet it does. If you hack the game and change the overworld, it will automatically be reported on the software-redndered world map ! However, I belive some areas of ocean are hardwired or something like that.

This is not only Final Fantasy, but also many other Square's game uses a similar map rendering technique, such as FF2, FF3, FF4, FF5, Hanjuku Hero, probably Secret of Mana too.