nesdev.org

Hi, I'm getting a "Value out of range." error while compiling my .nes file with Loopy's ASM6 compiler.

The error is occuring at line 647 which is where I set the address for the vectors like so: This error only occured after I added a second nametable to my code using the .incbin command. Could this second nametable have put me over the 32K PRG limit? Do you manually need to switch from one bank of PRG to the next?

Zsy wrote:Hi, I'm getting a "Value out of range." error while compiling my .nes file with Loopy's ASM6 compiler.
[...]
This error only occured after I added a second nametable to my code using the .incbin command. Could this second nametable have put me over the 32K PRG limit?

Remove the second nametable, reassemble, open your ROM in a hex editor, and see how much space you have left.

Do you manually need to switch from one bank of PRG to the next?

Yes. You use a mapper to make this switch in the program. Or are you asking how to configure ASM6 to produce ROMs designed for use with a mapper?

Zsy wrote:Could this second nametable have put me over the 32K PRG limit?

Most likely.

Do you manually need to switch from one bank of PRG to the next?

Yes, you can't make programs as long as you want and expect the assembler and the NES to automatically take care of it for you.

You should either compress you name tables (if you are not doing so already) and make it all fit in just 32KB, or pick a mapper and convert your program to use it.

To use PRG bankswitching you have to divide the source in separate pages, each of the size the mapper is configured to handle. When dividing you program you have to take into account things such as fixed banks (a bank that is always visible in a certain memory range), trampoline routines (needed to make calls between switchable banks), and so on.

A good way to divide your program into banks is to put the main engine in the fixed bank (if there is one) and spread the data that's not used so often across the switchable banks. In your case, it would make sense to put the name tables in the switchable banks, because those are accessed one at a time, so you can just switch in the bank with the name table you want and use the data freely.

Yup, I went over the 32kb limit of my PRG ROM, so I removed the rather large .bin file I was using as test music and everything went smoothly on the next compile.

I was originally confused about whether the 32kb of PRG ROM (on an NROM board with no mappers) was in two separate 16kb banks that I have to switch between, but I guess it isn't right?

How does one go about compressing nametables?
I'm using Pin Eight (Thanks for the awesome software tepples!) to generate my .nam files which I then use the .incbin command to load into my game.

I tried opening the .nam files in both a hex editor and my assembly language editor and couldn't really distinguish anything at all.

Likely compression method:
Subtract every element from the last one, then compress that with RLE.

Of course, you need code to encode it (on the PC) and code to decode it (on the NES).

To make sense of most of the data in a .nam (raw nametable) file, try opening it in a hex editor and then setting the width to 32 bytes. Or if you're on Windows XP, try this from a command prompt: 8name has been rewritten in Python as 8name II. It's currently distributed alongside Concentration Room, in the "tools" folder. It's a nametable editor that can create "pkb" (packed nametable) files directly, and it comes with an unpacker in 6502 assembly language.

Zsy wrote:I was originally confused about whether the 32kb of PRG ROM (on an NROM board with no mappers) was in two separate 16kb banks that I have to switch between, but I guess it isn't right?

The NES only sees a contiguous block of 32KB ($8000-$FFFF), the NES itself is not aware of any banking or switching. It's the mappers that break up the addressing space into smaller units (how many units and how large they are is up to the mapper).

How does one go about compressing nametables?

You have to run the nam file through a compressor in your PC that will hopefully output a smaller file that you will use instead of the original. Then in your program, instead of just copying the raw bytes to VRAM you have to use an algorithm that will decompress that kind of data.

If you are coding the compressor/decompressor yourself, RLE is the simplest compression algorithm there is, so you might want to look into it. If you are looking for something ready, you can use my old LZSS "kit". Decompress all files to some folder in your machine and drag-and-drop each file you want to compress over the "compress.wsf" file. Wait a while and a compressed file should appear, use that file in your program. The asm file is the decompression code, you have to use the routine that's inside it in your program.