400h bytes transfer loop?

How to copy 400h bytes of name table and attribute data?

I found this one in a tutorial :



But in that way the code will depend on a fixed address of name table, in the above exmple it will be $E000.

So here is my solution :



But I want to know if there is any better way?
Thanks in advance

I'm not sure what you mean by "fixed address". In your second example, the address is fixed. In the first example, you can put whatever address you want into $00/$01 and use the same code at many addresses. In the second example, it's fixed to the address of "nam_att".

The other disadvantage of the second approach is that the code is longer and takes up more space. It's slightly faster because LDA abs, X is one cycle faster than LDA (indirect), Y, so it's 1000 cycles faster, but I don't see why that minor speed difference would matter.

IMO the "better way" is the first example. Just move the code that sets up the $00/$01 pointer above the code that sets up $2006 and it becomes versatile and reusable.


Two other notes about the second example.

1. CPX #$00 is not necessary, the Z flag is set by INX already, so you can just delete that instruction (saves 2 bytes and 2 cycles).

2. If your assembler supports repeats, you can use them to write shorter code in cases like this (though the generated machine code will be the same length):

In the first code I need to know the address of the name table data :



But for the second code I can use the label "nam_att" and put it anywhere in the code without having to know it's address.

I am using NESASM3 and it seems it doesn't support repeat command.

You can just replace $E000 with nam_att.

What I said before about moving the $00/$01 setup out of the way, you could make this into a function that you can reuse to load many different screens. Something like this:

Awesome!
Thanks a lot!

Similarly, you can also use a named label instead of the direct numbers $00/01. Eg.

Makes it easier if you need to move your RAM values around later, you can just change the number in 1 place rather than everywhere it is used. The only requirement here is that pointers used for indirect addressing need to go on the zero page (so $00-$FE is a valid range for temp_pointer in this example).

It didn't work :

You're using NESASM3. You need to read the documentation that comes with your assembler: http://www.nespowerpak.com/nesasm/usage.txt

<nam_att means "use the low byte of the address of nam_att".
>nam_att means "use the high byte of the address of nam_att".

The NESASM3 equivalents for these are the LOW() and HIGH() functions, e.g. lda #LOW(nam_att).

Get familiar with your assembler. :-)

It works now.
Thanks a lot.

Oh, sorry. That's kinda my fault. I was trying to follow the style of the examples (I don't normally use NESASM3). Because the first example used < but also square brackets I presumed that it was valid NESASM3 code? Or does < work but only on literals?

IIRC, < is for ZP addressing in NESASM.

I just realised I linked to NESASM 2.x documentation, not 3.x. I can't even find public links to the 3.x documentation, which is amusing to me for some reason. usage.txt that comes with NESASM3.ZIP is for NESASM 3.1 and attached here; line endings appear to be LF (i.e. UNIX).

I don't see anything in the documentation (for 2.x or 3.x) that indicates < can be used to force zero-page usage, only that it can be used as the usual less-than comparison operator. But regardless LOW() and HIGH() are definitely what was needed here (no problem rainwarrior, we can't be bothered to remember every community members' assembler-of-choices' syntax :-) ).

Using NESASM myself, I know that < is used to select zero-page addressing (if not specified, it emits a two byte address). (It can also be used to mean less than in compile-time comparisons.) You use LOW and HIGH to retrieve the low or high octet of a 16-bit number.

To copy $0400 bytes from ROM to the PPU address space, one thing I have thought was to store the data in a different order in ROM (for example, at $8000 $8100 $8200 $8300 $8001 $8101 $8201 $8301 etc) and then use a loop of the X or Y register from 0 to 255 and then read all four at each step and write to PPU four times in that loop. (With my "Unofficial-MagicKit", it is possible to make the assembler to automatically rearrange the data at compile time, by defining a custom output routine.)

This is a transformation that optimizes speed at the expense of versatility and code size in this case. I don't think it's really appropriate to do this for loading whole nametables. (The minor speed improvement is not likely to be significant.)

Striped tables are really good for things like looking up a 16 bit value (e.g. pointer tables, jump tables), where the table is in a fixed location. There's little drawback in cases like that, especially if you have a tool that makes them convenient. I wish ca65 had such a feature, and I sometimes use macros to work around this. I think it's cool that you added it to your own assembler.

I can think of how I might make this sort of thing in a preprocessor written in Python. Would that be a good idea to add to my list of things to make for the community once The Curse of Possum Hollow wraps?

That is true, and is what I mainly used striped tables for; it is for 16-bit values and not for nametables. You are correct and it is really much better for such thing as pointer tables and jump tables. (Example of Unofficial-MagicKit macro which does this are available on wiki.)

I suppose it might help those who use ca65. I think this is a good idea, but since I do not use ca65 perhaps see what others say.

(I myself prefer JavaScript as scripting language of choice, but that is just my opinion and you can use Python if you prefer to.)

Yes please. Better tooling helps everyone, and this would be a welcome improvement.

I can make it general enough to cover NESASM, ASM6, and ca65. It needs only whatever operators go in the definition of each table entry.

Our Python vs. JavaScript debate is in another castle.

I wrote a striped table generator in C for my game but it's not very user friendly and instead of being a preprocessor it just generates a file to .include (and automatically creates an enum if you ask it to, because it's meant for metatile information and similar tables rather than small 16-bit value tables).

Would it be useful to make a more general purpose version of this tool? With what syntax and features?

Myself I'm not particularly interested in any external tools to do it (they are trivial to make); I was just musing that it would nice if it were a language feature rather than something you had to set up externally.

After poking around in the ca65 source and documentation a bit, I noticed there does exist a semi-reasonable method for generating striped tables:

Maybe the line continuations with a define isn't the prettiest look, but it does seem to do the job. Labels or other expressions seem just as good as literals, too, and there doesn't seem to be any inherent size limit on the number of entries (the .define is stored as a linked list of tokens).

I find this useful, so I'm going to start a new thread about it instead of trying to discuss it further here:
https://forums.nesdev.com/viewtopic.php?f=2&t=14838