Sorry to be a picky little dweeb here, but NESASM is an assembler. Compilers are usually a lot more complex than assemblers.

  LDA #low(PauseText)
  STA TextPointer
  LDA #high(PauseText)
  STA TextPointer+1


Terminology has never been my strong suit .

Working, thanks everyone!

Final code:

TEXTLENGTH .rs 1
TEXTLOWBYTE .rs 1
TEXTHIGBYTE .rs 1
TextPointer .rs 2

  LDA #$05
  STA TEXTLENGTH
 
  LDA #$0E
  STA TEXTLOWBYTE  
  LDA #$21
  STA TEXTHIGBYTE
 
  LDA #low(PauseText)
  STA TextPointer
  LDA #high(PauseText)
  STA TextPointer+1
 
  JSR LoadText


LoadText:
    LDA $2002             ; read PPU status to reset the high/low latch
    LDA TEXTHIGBYTE                                                                                              ; variable
    STA $2006             ; write the high byte of $2000 address
    LDA TEXTLOWBYTE                                                                                             ; variable
    STA $2006             ; write the low byte of $2000 address
    LDX #$00              ; start out at 0

LoadTextLoop:
    LDA [TextPointer], y     ; load data from address (background + the value in x)                          ;variable
    STA $2007             ; write to PPU
    INY                   ; X = X + 1
    CPY TEXTLENGTH           ; Compare X to hex $80, decimal 128 - copying 128 bytes                         ; variable - Character Length
    BNE LoadTextLoop  ; Branch to LoadBackgroundLoop if compare was Not Equal to zero
    RTS
 
PauseText:
   .db  $19,$0A,$1E,$1C,$0E     ;PAUSE
UnDrawPauseText:
   .db  $24,$24,$24,$24,$24     ;Undraw Pause





Why doing I need:
  LDA #high(PauseText)
  STA TextPointer+1

I never call for TextPointer+1 in the code. Is it because I somehow made something 16-bit?

Watch out dude. If you do this:
STA #$00, X
intending that to be a zero page, X instruction, it won't be. It will still assemble to an absolute, X instruction, wasting 1 byte and 1 cycle.
In NESASM you would have to do it like STA <#$00, X so sometimes < is useful.

You were trying to reach a 16-bit address with the table you had setup with .word. NES uses something called little endian (just Google that), and the +1 is the high byte of the address, whereas the +0 is the low byte. The only 8-bit addresses you'll be messing with are zeropage : ). But yeah, maybe just look up little endian 6502 or something. It should make sense. Ask questions if not!

Thanks. I know what little endian and big endian are. So, it is calling the address of PauseText in the register? If so, that was a huge light bulb!

I always thought it was doing this (but I am guessing I was wrong):

  LDA #low(PauseText)                            = $19 (First number of .db  $19,$0A,$1E,$1C,$0E)
  STA TextPointer
  LDA #high(PauseText)                           = $0E (First number of .db  $19,$0A,$1E,$1C,$0E)                         
  STA TextPointer+1

PauseText:
   .db  $19,$0A,$1E,$1C,$0E     ;PAUSE

If I am right, it is saying PauseText is stored at $WXYZ (just using placeholder numbers) and Low is YZ and High is WX?
So, when you point to it using [TextPointer], it grabs it as $WXYZ.

I hope I am right now, because I used to be so lost with this! Thanks ROTH!
Sorry for all of the questions, this was good for me today...

You are correct with the address assumption.

Right on! Now, to show you why this is so helpful, I'll make a short bit o' code for you to check out. If you already understand what I'm about to post, then cool, maybe it will help someone else hehe Anywho, let's use palettes as an example. And let's say for every level in the game, you have a different full 32 byte palette that you want to use. The typical way for a small game is to just do something like this:

EDIT: Put missing bytes from the palette_table_lo table. Seems like NA's rendering of the code tag isn't all that haha

This is great stuff. Even with the syntax I'm not familiar with (since I code for NESASM), I was able to follow it. I was thinking last week that you should be able to load different palettes for different levels.

I have been getting more used to seeing code written for the ca65 assembler because last week I download the !Clik! source code from your site to see how you handled moving from Title Screen to Game Play. Needless to say, I was pretty confused when I first saw it.

It's really personal preference, but I love asm6 - it's simple, and the syntax just makes sense to me:
http://home.comcast.net/~olimar/NES/

There are some templates over on NesDev that can get you started quickly:
http://forums.nesdev.com/viewtopi...

ca65 is the way to go for huge projects I imagine, but the learning curve/extra setup stuff just isn't worth it to me at the moment.

Edit: Fixed broken asm6 link

Here you have CA65 templates for NROM and SG/SNROM. http://forums.nesdev.com/viewtopi...
I think one of the biggest hurdles when changing from NESASM, ASM6 or something similar to CA65 is the separate linker.

So, I need a way to check if I have exceed a limit.

Is this how I do it?


Subroutine:
   LDA Variable
   CMP #$50
   BMI SubroutineDone   
      CODE TO RUN

SubroutineDone:
  RTS


Basically, when Variable hits 50 or any number above 50, I want to run CODE TO RUN.

The issue is, I am incrementing Variable with different number (1,2,3,4,5), so my program may not always hit 50.

Thanks

Nevermind, I figured it out finally. I was right.

BMI and BPL deal with bit 7, or %10000000.

BCS and BCC deal with greater/less than. In that case, you'd use bcc.

Interesting, BMI working great for me in many locations.

From what I read, the CMP will set the Negative flag (bit 7) if the compare is negative. In my case, I am enabling features in later levels. So, I compare the LevelVariable (set to Level 1) to #$04. The compare sets the negative flag because 1-4= -3. Once the Negative Flag clears in the compare (4-4=0 or 5-4=1), then the new feature is unlocked for the rest of the game.

I will be posting my new ROM in a bit on the private thread. You can check it out there.

EDIT: New ROM was posted last night.

I guess we are both correct. I was talking about LDA. I didn't know you could use those commands for compare! Interesting.

So, I was doing some research of general 6502 programming and it looks like the accepted standard way for 'less than & greater than\equal to' is BCC and BCS. BMI and BPL can do the same thing in a compare situation, however, it may be slow. I think I am seeing this issue when writing text to the sceen using BMI. I am going to replace BMI with BCC and see if it improves it.

So, it may have been a fluke, but bcc seems like a faster command than bmi how I was using it. From 6502.org, here is the bast ways to do all comparisons:

If the Z flag is 0, then A <> NUM and BNE will branch
If the Z flag is 1, then A = NUM and BEQ will branch
If the C flag is 0, then A (unsigned) < NUM (unsigned) and BCC will branch
If the C flag is 1, then A (unsigned) >= NUM (unsigned) and BCS will branch

Link: http://www.6502.org/tutorials/com...

So basically:
BNE to check for not equal <>
BEQ to check for equal =
BCC to check for less than <
BCS to check for greater than equalto >=

They operate the same speed, your code is 99% chance bugged. And using 2 branches is only acceptible when you HAVE to do the math a vertain way, because you can subtract 1 value from one of the numbers and do the compare and always get a 1-branch determination for what you need.

Is there a way to program a game to auto detect if you're using an emulator or hardware?

Get ahold of tepples. I believe he came up with code that does that.

It is possible to detect older or current emulators, but just as you use such detection, emulators will eventually consider your trick and it'll stop to work. Not to mention that all your tricky detection code could be disabled by a romhacker in minutes.

One of ways is to check initial RAM/VRAM contents. Emulators clear it out on start up, but it is never clear on actual hardware, and has semi-random data pattern instead.

I more just want to set it to change control styles on emulator vs hardware.

Not really for hackers. Last time I had a choice on the start screen. It would just be cool to be automatic.

In this case, there is no reliable way to detect emulators in general. The whole idea of emulators is to recreate a system as closely as possible, so in an ideal emulator there are no chances of detection at all, it should be 100% identical to the original. As emulators aren't 100% exact just yet (but close enough), you can detect flaws in certain emulators, or tricky things that aren't emulated properly so far. There are chances of false detections as well.

One way to provide reliable detection is to introduce virtual register in every emulator, which is not exist on the original hardware, and reading it will always provide clear answer is it emulator or not.

Unfortunately ways to tell most emulators need eyeballs, like many get the grayscale flag wrong. At least most people use old emulators so any tricks you do figure out won't be fixed! Theres a few emu specific bugs like flags after BRK but it would take a lot of those checks to cover all the popular ones.