nesdev.org

not to contribute to the disorder or anything. but wow, this thread really derailed

very interesting. albeit, it brings my system to a crawl.

I'd love to see a similar visualisation of the PPU.

NESICIDE wrote:
You can see here they execute code from $3A0, also:

the problem, in my case, seems to be the undocumented instructions.

NESICIDE wrote:

sahib wrote: if not, this indicates a pretty serious flaw in my CPU implementation...

The singles ROMs test undocumented instructions also, not just official instructions.

okay, I feel like an idiot for not realizing

weee!

comegordas wrote:the problem is that i'm using the .NET framework and my entire emulator is written in common C/C++ language.

I believe there are .NET bindings for SDL.

psycopathicteen wrote:Naw, it's in the Mexican release version also.

somebody should make a mexican-mario hack (!).

What could possibly be more awesome than a fat plumber in a sombrero jumping the flagpole?

hiya, hijacking this thread a bit, since it wouldn't make much sense creating a new one. If I run blarggs' instr_test-v2/official.nes I pass all tests successfully, however, whenever I run the stand-alone ROMs (with a few exceptions) my CPU goes in to an invalid state when the program jumps to 0x03A...

hehe,

there was always a rumor going around the school that some kid managed to jump the flag pole, but I never saw it in real life, so to speak.

ah, sorry to have been wasting your time. I found the error. In my drawing code there was an error when selecting which nametable to draw from, but it was a special state which didn't get triggered very often and it wasn't very obvious to me at first glance. it's weird, sometimes all you need to do ...

I've got a gut feeling that it's somehow related to $2007-writes to fill the nametables. but scrolling works okay in games using other mappers. my MMC1 mirroring code looks like this: void mmc1::Mirroring() { byte mirroring = (rd0 & 0x3); bSingle = bVertical = bHorizontal = 0; switch(mirroring) ...

For some reason, one of the nametables gets filled with the wrong data when I'm scrolling vertically in MMC1 games. I know, the first step is to check whether the mirroring gets updated properly, and as far as I know it does. Mirroring is only set on the fifth write to $8000-9FFF, right? it should b...

There is absolutely no use of this on the MMC1 because you can select which pattern table is used via $2000 anyway... but yet it's just because Nintendo decided to tie A12 on the cart to the MMC1 instead to directly the PPU A12 line. Are there any ROMs you know of that uses MMC1 instead of manipula...

blargg wrote:Using signed char makes your code less portable. Your approach is more portable, though there are simpler ways that are fully portable, like pc += (n^0x80)-0x80

touche! way more elegant!

In two's complement, the high bit of an octet has a weight of -128 (the others have the same as in unsigned). So doing (n-0x100) when the high bit of n is set is just a roundabout way of giving the high bit a weight of -128. seemed like a good idea at the time™. of course you could use a signed cha...

Petruza wrote:But substracting 0x100 to a byte doesn't change it's value.
What does (t-0x100) do?

the code should be read as:

add (t minus 0x100) to the address.

if I was doing t-=0x100, it'd all go ape-shit