On the APU basics page of the NESDev wiki, there is some code that "plays a 400 Hz square wave (50% duty) at maximum volume: "

Code:

jsr init_apu

lda #<279sta $4002

lda #>279sta $4003

lda #%10111111sta $4000

I know that #% is how you get the literal value for a binary number, and #$ is how you do that for hexadecimal numbers, but I have seen decimal literals represented as e.g. "lda #255". So, my question is, what are the "#>" and "#<" doing here? What are these operators?

Maybe it is an assembler-specific thing, so I am using ca65 if that matters.

# modifies an instruction to take a literal value rather than fetch a value from an address. The characters that follow it don't change this.

% means the number that follows is binary. It doesn't matter if it's supposed to be a literal value or an address, that's determined by the # not the %.

$ is the same just for hexadecimal.

< means to use only the low byte (bits 0-7) of the number, it does not matter if that number was prefixed with % or #. (It is the same as number & 255.)

> means to use only the high byte (bits 8-15) of the number. (It is the same as number >> 8.)

Code:

<$1234 = $34>$1234 = $12symbol = $1234<symbol = $34>symbol = $12

# modifies the instruction.%,$ modifies how a number is written.<,> selects the low or high byte of a 16-bit value.These three things are all independent. You could use all three of them on the same operand, if you wanted. # only works with instructions (and not in a table of bytes, for example).

This is the ca65 meaning, at least. In NESASM < and > only work as instruction modifiers, which is maybe a little strange.

Be warned that "<" and ">" are not standard notation, and some assemblers may have completely different ways of specifying this. Of note, early versions of the CopyNES BIOS contained a rather severe bug (a few broken instructions in the "MicroBug" feature) as a result of trying to use this syntax in an assembler that didn't support it.

_________________Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Good point about the presence of the binary operator not necessarily indicating a literal value, rainwarrior. I haven't considered the possibility of using a binary number for an address, so that's food for thought. Clears things up!

Then of course you probably wouldn't normally type an address in binary or decimal. Binary is useful when you see the number as flags or something like that, and wants it to be clear in your source code what flags you set and clear. Hexadecimal is useful for addresses, but I guess many people use it for about everything. Decimal is only useful when you want a number to be more human readable, like the value in a loop counter.

Personally I mostly use hexadecimal for about everything, including loop counters, (although the $ is annoying to type on Swedish keyboards as it requires the AltGr key) except certain flags that I use binary for. I only use decimal for assembly time math like this:

Code:

lda array+7 ;element 7 (which is the eighth element) in the array lda #NUMBER*2 ;double the number lda #NUMBER/2 ;half of the number ;etc

I only use binary (mostly for bit masks) and hex, never decimal. My main reason for avoiding decimal numbers is because they can easily be confused with hex numbers (even though I have them colored differently using syntax highlighting), and this has caused me some annoying bugs in the past. Better avoid this sort of confusion and always use the base that often makes more sense. Binary is easy to spot, so there's no problem in using that.

As for using binary for addresses, it may not make much sense for CPU addresses, but breaking up PPU addresses into bit fields is a very useful thing to do when manipulating the various tables that exist over there (pattern, name and attribute), so I sometimes do find myself loading partial PPU addresses in binary form.

It always surprises me how adamant some people are using hex for absolutely everything. Frankly, I get quite annoyed when reading code where hex has been used where decimal would have made much more sense (and vice versa). I'm talking about cases like adding 100 to a score counter, but using $64 in the code.

Personally, I try to use the base which makes the code easiest to understand. I can't say that I've run into decimal vs. hex bugs like tokumaru.

At first I also thought it was very annoying to use hexadecimal for everything when the assembler allowed other bases. But I was taught that it was a convention so I'd thought I better get used to it.It's still annoying to type that stupid $ character (AltGr+4) all the time, but I've gotten quicker at it, and I think using $64 instead of 100 have given me a better feel for hexadecimal values (I look them up in the Windows calculator just in case though, haha). I usually keep comments that explains things in decimal if necessary.

Another reason I stick mostly to hexadecimal is simply because Notepad++ refuses to highlight certain combinations of characters. Especially the # plus a number (#$ or #% plus a number works for some reason).

How do you set up the numbers in your highlighting file Tokumaru? I put $ % #$ #% in "Prefix 2" and A B C D E F a b c d e f in "Extras 1", any other combination seems to break hexadecimal highlighting. All other number fields are empty.

And how do you make it do different bases with different highlighting? I guess you don't use the Number style for numbers?

Dwedit wrote:

You can file an issue on the bug tracker for that kind of thing. Scintilla is open source, and so is Notepad++.

I don't know what a bug tracker is though. I will have to do some research first.

Who is online

Users browsing this forum: Google [Bot] and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum