Is there an equation for getting the 2 bytes from
CHR-ROM (assuming 0x0000 in PPU memory), from the
number of the current scanline?

Right now, my code goes like this:

for(int x=0;x<32;x++) {
int NTableByte = (nes.scanline/8)+x;
int PTablePtr = NTableByte * 16;
int Spec = nes.scanline%8;
byte b1 = nes.PPUMem[0x0000+PTablePtr];
byte b2 = nes.PPUMem[PTablePtr+8];
DrawLine(b1,b2,x);
}
nes.scanline++;

Every time I adjust it, I just get more confused...

Any help would be appreciated.

Thanks,
- Mike

A correction to the code that I hope is actually a correction :).

for(int x=0;x<32;x++) {
int NTableByte = (nes.scanline/8)+x;
int PTablePtr = ((int)nes.PPUMem[0x2000+NTableByte]) * 16;
int Spec = nes.scanline%8;
byte b1 = nes.PPUMem[0x0000+PTablePtr+Spec];
byte b2 = nes.PPUMem[PTablePtr+8+Spec];
DrawTileLine(b1,b2,x);
}
nes.scanline++;

i know this isn't helpful but could you expand on why you want to do this? i think i misunderstand your question

That's the main graphical code for my emulator at the moment.

nm,

My emu can now run a little demo I coded which
makes a simple background (mapper 0 starting at $C000).

mmm seems quite small, I did some code in BBC Basic a year 1/2 ago (colours fixed) to draw the zelda test screen - do you know this language? - if so i could email it to you, it might be helpful with your original post question?

Unfortunately, I don't know that language, but I seem
to have the code working just fine now.

The final code is smaller even:

nes.scanline++;
for(int x=0;x<32;x++) {
int line = (nes.PPUMem[0x2000 + ((nes.scanline/8)*32)+x]) * 16;
DrawTileLine(nes.PPUMem[line+(nes.scanline%8)],nes.PPUMem[line+8+(nes.scanline%8)],x);
}

I haven't implemented $2000 and $2001 yet, so I'm making a few assumptions,
but I was able to confirm that the code works with an overly simple demo.

Either Mario does something wierd to the stack or my RTS has been bewitched,
either way, my CPU is really dumb.

Thanks anyway,
- Mike

I ran your emu and tried a simple prog, but nothing happened - what rom did you use, from what I remember of my code - its along simpilar lines though its not object oriented code, well still what was your code compiled under as i been meaning to look at it

I've uploaded the latest code and build to:
http://k2pts.home.comcast.net/gbaguy/nespp.zip

The emu crashes when Mario is at the end of it's vblank interrupt with an
"Access Violation", but I haven't been able to find where that is happening.
The other ROM is a test (obviously ,(you'll see why if you look)) that just
puts a background on the screen, the text was a joke to friend...

that one is better but you didn't say what compiler the code needs, VC, djgpp, etc? it would make it easier to go through the code

Regarding the 2 ROMs included

1. The SMB ROM included is a hacked pirate version (no titlescreen, Select button doesn't work at titlescreen). If you're going to test your emulator with a commercial game, at least make sure it's a proper dump.

2. The other test ROM is a bit flaky, as it writes to VRAM without disabling rendering (even worse, it ENABLES rendering before writing to VRAM). It only works properly if it starts at VBLANK immediately after reset (which is generally not the case on a real NES). From what I recall, the NESASM tutorial tells you to do this for some strange reason, most likely because the author didn't know any better and/or never tested the code on the real thing.

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

oops, sorry about that.

I compile the code with MS's C++ compiler from the command-line,
so I guess the answer would be VC++.

1) I thought there was something wierd about the fact that the titlescreen was
missing, that means I'll be looking around for a good version today...

2) I wrote that one basically so I could test the graphics decoding routine,
and it did help me remember that == has a greater precedence over &, so I needed
parenthesis around & expressions. About testing code on a real NES, I hope the
Maxi/MegaCart comes out soon...

I think I am going to either entirely rewrite the CPU, or just go through and
individually recode each instruction and test each instruction individually and
disable graphics emulation while I do that.