nesdev.org

Me, misspelling DPCM. Delta Pulse Code Modulation. It is how the NES can play raw sound samples. The APU uses DMA to pull the samples from the high-end of the CPUs address space.

The PPU uses two 4K banks, one for background tiles, one for sprites. The PPU can be configured to pull tiles and sprites from the same 4K bank, or from either bank. Together, the PPU "sees" 8K ($0000 to $1fff in the PPU's address space). This memory lives on a cart as ROM or RAM and is called "CHAR-xxx". Physically, on the bus between the NES and the cart, the PPU controls 13 address lines (2^13 = 8192 = 8K bytes (well, technically, the ISO unit is "KiB", not "KB", but we'll ignore that here)) and reads 8 data bits. There are other control signals (RW, /CE) used to tell the memory circuit if the PPU wants to read or write, and "enable" the chip or not.

I'm sorry. I don't understand your question. What does _what_ do? I suppose that my example won't make any sense to you if you have not played FF1.

Its all semantics. The cc65 compiler suite uses the term "segment", which can be of arbitary length. The NES simply has address ranges and two buses (CPU and PPU). The term "bank switching" means that a memory controller (ie, mapper chip) can swap memory out from underneath the CPU. Banks are typically large, and have sizes that are exact powers of 2, and are aligned on memory address boundaries that are powers of 2.

In a modern computer, the programs "data segment" is copied to ram. "RODATA" and "TEXT" (an archaic term for "code") are marked read-only (if the cpu's mmu supports that). "Data" is loaded just above the end of the "text", and BSS above that. The app's heap starts above BSS and grows up, and the stack starts at the end of the processes address space and grows down. When the heap and stack collide, bad shit happens.

In the NES is bit different. There is no "program loader" that places different segments into memory. Your reset routine _IS_ the loader, so to speak. Typically, a NES program will contain CODE and RODATA in ROM; use all RAM as BSS (but its not called that) and contain no traditional "DATA" segment. However, there is nothing to stop you from emitting a large chunk of "DATA" into your ROM and then copying it into RAM, where it can then be modified and treated as "DATA" like a C program executing on Unix would.

FinalZero wrote:Ok. While we're on the topic of tiles and sprites, is there any way to just grab and display a 4x4 tile/sprite? or is 8x8 the smallest size that can be done?

I'm wondering because if so, then smoother fonts could be created and used, rather than the typical ugly monospaced 8x8 one...

I have played FF1, but not for the NES. I'm trying to ask how they do store the data if they can't store it in one or two char banks. Also, do you mean the monster graphics themselves, or the possible combinations of monster the player's party might meet? If the latter, why is that stored in char rom? It's not graphical.

So, what does one do if one needs data from two separate banks? Load it from one, switch to the other, and then load the rest?

Under normal circumstances, those 256 tiles are not enough to make an entirely unique screen (such screen would need 960 tiles). But if your graphics use only 2 colors (which is usually the case with text), you can use a few tricks. First, NES tiles have 4 colors, so they use 2 bits per pixel. 2-color graphics need only 1 bit per pixel, so you can actually store 2 1-bit images in 1 tile (to display one image or the other you have to use different palettes), which basically doubles the tile count to 512.

Yeah, this can get complicated depending on the number of switchable and fixed banks each mapper has. This is something you have to take into consideration when designing your program.

In my current project for example (UxROM: 2 16KB slots, one fixed, one switchable), the main game engine is in the fixed bank, so that it can read level maps and things like that from all the other banks. Other things that are more or less self contained (i.e. don't need to access other banks) stay in switchable banks too (like the music engine, navigation menus/screens, etc).

Of course there are ways to access anything from anywhere by using trampoline code (i.e. call a routine in the fixed bank which will switch banks, read the data, switch back and finally return the data), but that can be very slow because of all the overhead.

FinalZero wrote:Was/is the SNES simply fast enough that more games than before decided to use proportional fonts?

I understand how that works, but at the same time I'm not sure how that'd work. Wouldn't you have to clear either the upper or lower bits depending or whether your reading the tile or its shadow?

How much does bank switching slow things down?

If nobody minds, I'm going to try posting some code here so we can discuss what exactly I need to program next to work my way toward displaying "Hello World". Perhaps uploading the files somewhere would be a better idea?

Also, is there any way to raise the number of posts that are visible per page on this board?

FinalZero wrote:Ok. While we're on the topic of tiles and sprites, is there any way to just grab and display a 4x4 tile/sprite? or is 8x8 the smallest size that can be done? I'm wondering because if so, then smoother fonts could be created and used, rather than the typical ugly monospaced 8x8 one...

I'm trying to ask how they do store the data if they can't store it in one or two char banks. Also, do you mean the monster graphics themselves, or the possible combinations of monster the player's party might meet?

So, what does one do if one needs data from two separate banks? Load it from one, switch to the other, and then load the rest?

Ok, so "RODATA" is read-only data (in the context of FF) like monster stats (which change), "DATA" is data like character stats (which don't change), "CODE" is like the battle/menu routine, and "BSS" is the ram? And these are only conventions suggested to be followed, not laws that the assembler enforces?

tepples wrote:

Ok, so "RODATA" is read-only data (in the context of FF) like monster stats (which change), "DATA" is data like character stats (which don't change), "CODE" is like the battle/menu routine, and "BSS" is the ram? And these are only conventions suggested to be followed, not laws that the assembler enforces?

DATA is anything copied into RAM at reset time. You shouldn't have much need for this, as things would usually get copied at the start of a game, the start of a level, etc.

Conveniently enough, NES tiles are stored in planes, 8 bytes for the fist plane followed by 8 bytes for the second, so if you open them in a tile editor an set the format to 1-bit, what you'll see is that each NES tile becomes 2 1-bit tiles (without any conversion necessary, the difference is just how the data is interpreted). Pixels can have values ranging from 0 to 3. If a pixel is 0, it's cleared in both planes, if it's 3, it's set in both planes, and if it's 1 or 2 it's set in only one of the planes. That tells you how to configure your palettes so that one image or the other is displayed. Say you want to have black text on white background. Color 0 would always be white, because that's the color that will be picked when both planes have clear pixels. Similarly, color 3 will always be black. As for colors 1 and 2, one will be white and the other will be black, depending on which plane you want to show. Setting one of those colors to white will effectively "hide" one of the planes, so that only the other one is visible.

It depends. You can read a single byte from PRG-ROM in 4 cycles with LDA $8040, for example. If you wanted to load a byte from an arbitrary bank, you'd have to switch that bank in first, which would take at least 8 cycles in an UxROM game, so it would take you a total of 12 cycles, 3 times more, to read a single byte. Depending on the mapper, switching a new bank might take more time, and if you want to do things like remember the previous bank and switch it back after reading the data, the overhead will be huge (of course, the overhead will not be as significant if you are reading 200 bytes, as opposed to only one).

So trust me, reading lots of data from banks all across the ROM is not something you want to do in the middle of your game loop, because there will be a huge impact on the speed. Try to organize your code and data in a way that minimizes bankswitching as much as possible. To give you an idea, it would be acceptable to bankswitch a couple dozen times every frame (i.e. each iteration of your game logic), but if you are doing it hundreds of times per frame, there's probably something wrong.

People often post code in sites like this. If you have a number of source files though, it would probably be better to upload a ZIP file somewhere.

It's possible to render proportional text to CHR RAM. A box for three lines of a character's dialogue might take up 60 of your background tiles (or 30 if you use mid-frame palette hackery), but then those are tiles you don't have to use for 0-9A-Za-z. You'll need it anyway if you plan to produce a version of your game containing Chinese, Arabic, or other complex scripts. Faxanadu, for example, reserves 64 tiles for its text boxes so that the Japanese version can display kanji.

DATA is anything copied into RAM at reset time. You shouldn't have much need for this, as things would usually get copied at the start of a game, the start of a level, etc.

FinalZero wrote:

Color 0 would always be white, because that's the color that will be picked when both planes have clear pixels. Similarly, color 3 will always be black. As for colors 1 and 2, one will be white and the other will be black, depending on which plane you want to show. Setting one of those colors to white will effectively "hide" one of the planes, so that only the other one is visible.

I understand it now. Wouldn't a downside be though that one needs to devote 2 palettes to displaying text if one needs tiles from both sets though?

It's possible to render proportional text to CHR RAM. A box for three lines of a character's dialogue might take up 60 of your background tiles (or 30 if you use mid-frame palette hackery)

What do you mean by """mid-frame palette hackery"""?

DATA is anything copied into RAM at reset time. You shouldn't have much need for this, as things would usually get copied at the start of a game, the start of a level, etc.

What would an example of such a thing be?

How well do you know C? It can sometimes be easier to explain ld65 concepts in terms of C, as that's what ld65 was designed around. Segment DATA contains what C would call the values of initialized statically allocated variables, be they global variables or local variables with 'static' storage. But some coding standards discourage initialized declarations, instead preferring to initialize the variables explicitly from 'const' data at runtime. This 'const' data goes in RODATA.

int f() {
    static int x = 3;
    ...
    x += whatever;
}

intf() {
    static int x;
    x = 3;
    ...
    x += whatever;
}

• Don't use static variables inside functions.
• Initialize global variables at the start of main(), so that if you need to initialize them more than once, you can easily refactor that out. This covers the case of, say, returning to the title screen.

tepples wrote:But if you just want to display subtitle text in a bottom status bar, something simple like loading eight colors' worth of black-and-white palettes can be done in a couple lines' horizontal blanking.

Don't use static variables inside functions.
Initialize global variables at the start of main(), so that if you need to initialize them more than once, you can easily refactor that out. This covers the case of, say, returning to the title screen.

FinalZero wrote:

Don't use static variables inside functions.
Initialize global variables at the start of main(), so that if you need to initialize them more than once, you can easily refactor that out. This covers the case of, say, returning to the title screen.

Ah, that makes sense now.

-----

Here's a couple more questions:
1) I know that sprites can overlap something in the background, but can they underlap it?
2) Were there any mappers that added capabilities for the PPU to use more than just 4 palettes for the background and 4 palettes for sprites? or perhaps add more than 4 colors per palette? Could a mapper even do such a thing?

1) Yes, they can, if you set bit 5 of sprite attribute.