nesdev.org

FinalZero wrote:1) What does the ".segment "INESHDR" do? There's no predefined segment by that name, so I'm confused. What would happen if it was left out?

2) Does "number of 16 KB program segments" mean that one has go through one's source and count how many segments there are?

3) What is a mapper? Why do different games use different ones? I keep finding lists of them, but nothing that actually explains what they are and do.

4) What is a nametable? What's stored in them?

Does that mean it's used for games that scroll horizontally or not?

Also, why doesn't one need ".org $0000" at the beginning of the header? Is it implied?

You wouldn't get a valid iNES header.

Usually your link script template will specify how much PRG ROM it'll create. For example, an NROM-128 template will always make 16400 bytes (16 bytes of header and 16384 bytes of PRG ROM), an NROM-256 or CNROM template will always make 32784 bytes (16 bytes of header and 32768 bytes of PRG ROM), and a template for UNROM, BNROM, or ANROM will probably make 131088 bytes (16 header, 131072 PRG ROM).

They turn the page in the ROM, so to speak. Without them, the NES can't see more than 32 KiB of program and 8 KiB of graphic tiles. Some mappers have smaller "pages", which lets them have more than one active at once, and some have extra timing circuitry to make a few scrolling tricks easier.

In List of background topics, please see Text mode and Text user interface. The nametables are a lot easier to explain if you're familiar with those.

Vertical mirroring is used by some games that scroll horizontally, such as the original Super Mario Bros. and Super Mario Bros. 2.

ca65 delegates placement of code in the binary image to the linker.

FinalZero wrote:As a side note, looking at http://tuxnes.sourceforge.net/nesmapper.txt , it gets Dragon Warrior 1, 3, and 4 wrong.

The mirroring settings in the iNES header are meant for games with hardwired mirroring, and are meaningless in games that have mapper-controlled mirroring. Games that use mappers like MMC1 or MMC3 can change the type of mirroring at any time.

FinalZero wrote:Oh, ok. That still begs to ask why they didn't match the iNES header mirroring value with the one actually used in the game though...

But, am I right in assuming that the part of the header that says how many prg and chr rom sections there are? That is, the mapper specifies only a range, not the specific amount?

I bet most dumpers would just guess the mirroring when filling in iNES headers until the games worked, and no matter what they guessed, games with mapper-controlled mirroring would always work.

But even if anyone cared about this, lots of games change the mirroring type at different times, and it would be very tedious to play through entire games just to make sure they use only one kind of mirroring all the way to the end, for the sole purpose of setting a bit in the header that doesn't really do anything.

Each mapper has a maximum amount of PRG and CHR it can handle, and these limits are usually specified in detailed documents about them. The values in the iNES header count actual "pages", which are 16KB large in the case of PRG and 8KB in the case of CHR. These sizes were used because they were thought to be the smallest in commercial NES games (this assumption was wrong though, as there is at least one game with 8KB of PRG, and this game has to be doubled up in order to be correctly represented in the iNES format).

Since the sizes of memory chips are always powers of 2 (32KB, 64KB, 128KB, 256KB, etc) it's best that your PRG and CHR sections are like that too, so you should never use a weird iNES configuration like 3 PRG pages (48KB).

The MMC3 has 4 pairs of registers at $8000-$9FFF, $A000-$BFFF, $C000-$DFFF, and $E000-$FFFF - even addresses ($8000, $8002, etc.) select the low register and odd addresses ($8001, $8003, etc.) select the high register in each pair.

Mirroring ($A000-$BFFE, even)

FinalZero wrote:What happens if there's more? It's just simply not available? Linker error?

I suppose mappers varied in price too, thus affecting how a development team chose which one to use.

I don't understand what it means by "in each pair".

So, in addition to setting the header correctly, one must set things at the address in the mapper correctly too, in order for a game to run?

Does it reserve all of $A000 to $BFFE to say what the mirroring is? Why can't it just use a couple bits?? I think I'm misunderstanding something...

More than what the mapper supports? I'm sure you can assemble very large ROMs, and some emulators will even run them without problems, but you will not be able to put them on real carts.

I think it's because most operations on the MMC3 are performed with two register writes: the first selects the operation and the second executes it. For example, to bankswitch a page of PRG-ROM you must first tell the mapper where in the addressing space the page will go, and then you tell it which page to put there.

Because the 6502 relies on memory-mapped registers to communicate with different devices, when you write something to the mapper, the mapper has to decode the address in order to know which register you wrote to. The cart receives 15 address bits, and if you wanted a register to be accessible through a single memory location, the mapper would have to decode all 15 bits, increasing its complexity (and cost) unnecessarily. Since the mapper only has a few registers, it's easier to just decode a few bits and ignore the rest. As a side effect, the few registers are mirrored several times across the addressing space (the actual layout depends on which bits are decoded and which are ignored).

So, in the case you mentioned, it's not that the mapper needs a shitload of bytes just to configure the mirroring, it's just that the register that controls the mirroring can be accessed through any address in that range, but it's still just one register.

FinalZero wrote:And finally, do I have the following right?: The ca65 assembler creates an object file from assembly files, and then the ld65 linker creates a NES file from the object file?

-----

http://www.cc65.org/doc/ld65-2.html
Looking at the ld65 documentation, the -t (specifies target system) option and -C (specifies custom config file) option can't be used together. What kind of rom does the linker default to when "-t nes" is used?

djenkins@hera ~/code/nesyar $ find /usr/local -name "nes*"
/usr/local/lib/cc65/lib/nes.lib
/usr/local/lib/cc65/lib/nes.o
/usr/local/lib/cc65/joy/nes-stdjoy.joy
/usr/local/lib/cc65/asminc/nes.inc
/usr/local/lib/cc65/include/nes.h
/usr/local/share/doc/cc65/nes.cfg

djenkins@hera ~/code/nesyar $ cat tools/free-space.pl
#!/usr/bin/perl -w
# NesYar/tools/free_space.pl

# Analyze ld65 linker "map" file, print how much free space I have
# in various segments.

use strict;
use warnings;
use diagnostics;

my $segment_list = 0;
my $zp_end = 0;
my $kernel_end = 0;
my $vectors_start = 0;
my $data_end = 0;

while (<STDIN>) {
        chomp;
        my $line = $_;

        $segment_list = 1 if ($line =~ m/^Segment list:$/);
        next if (! $segment_list);
        $segment_list = 0 if ($line =~ m/^Exports list:$/);

        if ($line =~ m/^ZEROPAGE[\s]+([0-9A-F]+)  ([0-9A-F]+)  ([0-9A-F]+)$/) {
                $zp_end = hex ($2);
        } elsif ($line =~ m/^KERNEL[\s]+([0-9A-F]+)  ([0-9A-F]+)  ([0-9A-F]+)$/) {
                $kernel_end = hex ($2);
        } elsif ($line =~ m/^VECTORS[\s]+([0-9A-F]+)  ([0-9A-F]+)  ([0-9A-F]+)$/) {
                $vectors_start = hex ($1);
        } elsif ($line =~ m/^DATA[\s]+([0-9A-F]+)  ([0-9A-F]+)  ([0-9A-F]+)$/) {
                $data_end = hex ($2);
        }
}

print "\x1b[0;33m" unless ("$^O" eq "MSWin32");
print sprintf ("ZP avail:     %5d bytes\n", 256 - $zp_end);
print sprintf ("DATA avail:   %5d bytes\n", 2048 - $data_end);
print sprintf ("ROM avail:    %5d bytes\n", $vectors_start - $kernel_end);
print "\x1b[0m" unless ("$^O" eq "MSWin32");

./tools/free-space.pl < ./nesyar.map
ZP avail:        16 bytes
DATA avail:     961 bytes
ROM avail:     7190 bytes

FinalZero wrote:What happens if there's more? It's just simply not available? Linker error?

I suppose mappers varied in price too, thus affecting how a development team chose which one to use.

So, in addition to setting the header correctly, one must set things at the address in the mapper correctly too, in order for a game to run?

And finally, do I have the following right?: The ca65 assembler creates an object file from assembly files, and then the ld65 linker creates a NES file from the object file?

http://www.cc65.org/doc/ld65-2.html
Looking at the ld65 documentation, the -t (specifies target system) option and -C (specifies custom config file) option can't be used together. What kind of rom does the linker default to when "-t nes" is used?

ca65 delegates placement of code in the binary image to the linker.

If you try to add more data than what the link script supports, you will get a linker error.

If you want more detail beyond what tokumaru explained, look at one of the few published NES game post-mortems. This one mentions mapper pricing: a scanline counter cost money (because it brought in MMC3), a dedicated switchable bank for DPCM samples cost money (because it also brought in MMC3), PRG RAM cost money (because it brought in a 6264 and at least MMC1), and a battery cost money on top of that.

Yes. The first part of your startup code that sets up the mapper must be located in a fixed bank. For UNROM (mapper 2), this is $C000-$FFFF. For configurations of MMC3 and MMC6 (mappers 4, 118, and 119), this is $E000-$FFFF. For mappers with no fixed bank, such as A*ROM (mapper 7) or S*ROM (mapper 1), the first part of the code must be repeated at the same place in all banks.

Yes, just like a typical C toolchain.

It defaults to whatever the built-in link script for NES uses. I believe this built-in link script corresponds to a board that doesn't actually exist (NROM with 8 KiB PRG RAM), though it could be created with circuitry similar to that used in Family BASIC.

FinalZero wrote:

ca65 delegates placement of code in the binary image to the linker.

So then, does .org do anything at all in ca65 asm?

Yes, just like a typical C toolchain.

Ok. It sounds stupid but I didn't realize it was so.

Thank you to all for answering all my questions so far, especially when the average internet board would eat somebody alive for something like this.

FinalZero wrote:

ca65 delegates placement of code in the binary image to the linker.

So then, does .org do anything at all in ca65 asm?

;; For ease of debugging, we want the "Yar" and "Quotile" at multiples of 16

.align 16
.assert (* = $30), error, "Zero-page layout"
qotile_obj:             .tag    OBJ
qotile_dat:             .tag    QOTILE

.align 16
.assert (* = $40), error, "Zero-page layout"
yar1_obj:               .tag    OBJ
bullet1_obj:            .tag    OBJ

FinalZero wrote:

Yes, just like a typical C toolchain.

Ok. It sounds stupid but I didn't realize it was so. It didn't help that other assemblers simply skip the linker step... With this in mind, my project assembles and links, and then plays in FCEUX without generating an error!, but the screen is blank and nothing happens... I don't have the linker set up correctly yet...

FinalZero wrote: @clueless: Thank you for the script. I don't know Perl (I know some Python, but have never written anything major in it), but I have to get around to learning it sometime...

FinalZero wrote: Also, in your thread on the second page there's a link to http://nesdev.com/bbs/viewtopic.php?t=2997 . Where is the patch at/available for download though?

djenkins@hera ~/code/nesyar $ ca65 --version
ca65 V2.13.2 - (C) Copyright 1998-2005 Ullrich von Bassewitz

FinalZero wrote: Thank you to all for answering all my questions so far, especially when the average internet board would eat somebody alive for something like this.

  lda player_energy
  cmp #MAX_ENERGY
  bcc ok
  .byte $02  ;; 6502 "KILL" opcode.
ok:

tepples wrote: According to the manual, it turns on absolute code mode temporarily. It's one way of making overlay code intended to be copied to RAM before execution; the other (preferred?) way is to specify a segment in the link script whose load and run addresses differ.

outside_label:
.org $0700
inside_label:
  nop
.reloc

 lda outside_label,x
 sta inside_label,x
 jmp inside_label