nesdev.org

You can use a two byte address on the zeropage ($00-$FF) to access memory by that address.

The indirect indexed addressing mode works for LDA and STA.

LDA ($00), Y < This instruction loads a byte from the address stored at: ($01 << 8) + $00 + Y

It's definitely good to know how to do this on one's own with indirect indexed (as described by rainwarrior), but I figure I should add NES Screen Tool actually just includes code to load a full (compressed) nametable.

In NES Screen Tool: Nametable, Save Nametable and Attributes, select RLE packed binary from the dropdown menu.
Include "rle.asm" in your project, write the address of where the data should start in the PPU to $2006 then jsr to unrle with the address of the data itself in X and Y.

Be aware that the file is in NESASM syntax. To change this, change lda [RLE_LOW],y to lda (RLE_LOW),y. You may also need to update the labels for your assembler, and you may also want to relocate which RAM it uses at the top. You may also need to change references to PPU_DATA to $2007 if you are not using that standard.
I'm told this only works if you are using < 256 unique tiles in the nametable, but haven't verified this.

Probably because not everyone uses exactly the same names for things, particularly for the bit constants that get stored in the register. It's not like Game Boy where the official register names leaked fairly early on and essentially the entire homebrew community started using the same header file.

Ah, but the wiki calls it PPUCTRL without the underscore! There's not really a standard. I've always wondered about the source of the names, myself. Early homebrew developer decided to name them, or do they come from official Nintendo stuff? Either way, if I give you sta $2007 instead of those names, it will assemble in anything regardless of how the assembler deals with defines/equs/.dsbs.

I know I can branch on minus after this: and I don't after this: Not to say that you shouldn't use PPUDATA/PPU_DATA if you're comfortable with them, but those are some reasons why people don't. Yes, I realize in the above you could comment either with the info the other doesn't have.

I don't use them because not using them is what I'm used to. The two that I have to look up ($2000/$2001), I'd have to look up if they were named too.

(Another case of ninja'd but posting anyway.)

I have a confession to make: I think I was the one who came up with the "PPUCTRL" set of names for PPU registers $2000-$2007 that the community has since more-or-less adopted. But that was back in the 2000s decade. Because I didn't put serious work into an audio driver until 2009, I didn't get a chance to make analogous names for the audio regs that caught on.

If you got "ninja'd", that means someone else submitted a reply to a topic while you were composing your reply.

I've always preferred "$2007" to "PPU_DATA", and I find the latter to be obfuscating rather than the former, but opinions differ. I would say that the NES only has 8 PPU registers. So relative to other systems, the numbers are less difficult to keep in memory.

tepples wrote:I didn't get a chance to make analogous names for the audio regs that caught on.

The PPU registers at least mostly have a single function per register. This is not really true for half the audio registers. Naming them effectively is not so easy a problem.

I think it was feos_tas that added these names to FCEUX. I disabled them immediately.

The other thing about the audio registers is most programs hardly ever write an audio register in more than one place in the code. There's a lot less need to have a name for a thing that appears exactly once.
TBH, I find the former obfuscating in its verbosity. $80 as a hex number is very easily remembered as a byte with only the high bit set, and I do easily remember that the high bit of $2000 controls the NMI, as from using that register I find it's the most important bit.

The rest of the bits of $2000 I don't remember. I look them up when I need to use them, and it's really not any kind of problem to do so. I have to interact with them so few times in the code that I see no reason to build verbose constants to help me construct these bitfields. BTW, I very often like to use binary notation like %10000000 instead of $80 for things that are bitfields, but depends on the situation.

Actually, the most likely thing I'd do would probably be to annotate it with a comment, rather than creating bitfield constants: I do, on the other hand have bitfield construction constants for controller reading stuff. PAD_L, PAD_A, PAD_SELECT. Those I find quite useful, as controller bitfield parsing tends to have many cases in a typical program, each with very specialized needs. Very different situation than with $2000 which gets used maybe 3 places in the code. Also, the order of controller bits as left to right or right to left is arbitrary, depending on how you stored the bits as they were read; there's much more need to use defined constants when something is arbitrary or could change. $2000 on the other hand is always $2000.

$2006 and $2007 get used in a lot of places in the code, but for the same reason they're very memorable. Both of them also have very simple function, no bit packing, just a whole byte with one purpose.

$2004 doesn't need a name because you're not going to use it anyway. ;P

Et cetera.


Anyhow, you should use the style that feels effective to you. Lots of people like the defined names for these registers, and they seem to be included by default by Mesen and FCEUX at this point. Some people, like me, feel the opposite. I don't think it's a no brainer that this is the better way to go.

Kasumi wrote: In NES Screen Tool: Nametable, Save Nametable and Attributes, select RLE packed binary from the dropdown menu.
Include "rle.asm" in your project, write the address of where the data should start in the PPU to $2006 then jsr to unrle with the address of the data itself in X and Y.

I just tried this and it doesn't seem to work for me. It doesn't actually create the file I choose. I added an empty dummy file to see if it's content changed and for some reason it just doesn't seem to save.

Any idea what I'm doing wrong?

Thanks

Also, for NES Screen Tool / nesst.zip:

The rle.asm file in the .zip may need to be adjusted for whatever assembler you're using. It appears to have been written for NESASM 2.x or 3.x (it often matters, and the source doesn't specify which version). But the code is very short and fairly easy to understand. If/when converting it to the assembler you use, be aware that NESASM uses brackets to specify indirect addressing (ex. lda [RLE_LOW],y), rather than the more common parenthesis (ex. lda (RLE_LOW),y). This has caused many problems for people in the past.

If the export-to-file feature doesn't work, you can alternately try using "Put to the clipboard -> ASM data" to put a ton of .db statements into the clipboard, which you can paste directly into your source code (if you wish to do it that way). There is no point in discussing which method is better or worse; use whatever you prefer, or whatever works. I'll note that I've never used this tool before, I'm going completely off of the readme.

koitsu wrote:If the export-to-file feature doesn't work, you can alternately try using "Put to the clipboard -> ASM data" to put a ton of .db statements into the clipboard, which you can paste directly into your source code (if you wish to do it that way). There is no point in discussing which method is better or worse; use whatever you prefer, or whatever works. I'll note that I've never used this tool before, I'm going completely off of the readme.

The only issue I have with that is it doesn't seem to do the RLE thing. It looks like all the data is uncompressed.


Another related question. What segment should I drop the nametable into?

Thanks for your help

battagline wrote:The only issue I have with that is it doesn't seem to do the RLE thing. It looks like all the data is uncompressed.

Hmm... well that sucks! The readme is a bit vague here, but yeah, it looks like it might only export the non-RLE'd version. I'm keeping my response terse to try and avoid someone saying "but NES Screen Tool is open-source so you can fix it yourself!" (No end-user wants to hear that answer.)

battagline wrote:Another related question. What segment should I drop the nametable into?

Assembler-specific question. You need to get in the habit of specifying what assembler you're using when dealing with things of this nature. :-) The question likely implies cc65/ca65/ld65. Someone else will have to answer that (odds are it'll amount to "it depends on how you set up your .cfg file", which then gets off-topic vs. the thread subject, so maybe discussion of cc65/ca65/ld65 bits would be better-suited for its own thread? Unsure.)

In the save dialog, at the bottom just below the filename is a "save as type" field. Click that and select an RLE format.

rainwarrior wrote:In the save dialog, at the bottom just below the filename is a "save as type" field. Click that and select an RLE format.

It will save as the binary .rle, but when I save as the .asm RLE, nothing happens. The file won't show up and if I try and save over an existing file it doesn't change it.

Thanks

battagline wrote:It will save as the binary .rle, but when I save as the .asm RLE, nothing happens. The file won't show up and if I try and save over an existing file it doesn't change it.

Ah, I see. That's a bug. I guess I'd suggest to report that to shiru...

For the mean time, why not just save as the binary and then .incbin it in your assembly? Is there something you need the .asm export specifically for? You can see the exact same data with a hex editor on the binary version.

There is a few bugs in nes screen tools but in general it works well. One that I do not know the exact order to reproduce it is if you ask to save 1k chr at cursor location, sometime it will save something else ^^;;; I was sure that I selected the wrong banks in my code until I found the data was wrong. "Must have put cursor wrong place then. Will be careful next time". Then it happened again I may try to check where the bug is someday in the code but for now, I will just be careful.