nesdev.org

The only mention of it as far as I know is here (edit: and here ). I've tested it (on hardware) and it seems to happen with both 16x32 configurations. It does not happen with 32x64 sprites, and that makes it rather puzzling. Just to clarify what's happening: --- Enabling $2133.1 squashes sprites by ...

0: N4 -> N3 -> N2 -> N1 -> P4 -> P3 -> P2 -> P1 1: N3 -> N2 -> N1 -> P3 -> P2 -> P2 -> P1 -> P1 2: N2 -> N1 -> 03 -> 03 -> P2 -> P2 -> P1 -> P1 3: N2 -> N1 -> P2 -> P2 -> P1 -> P1 -> P1 -> P1 4: N2 -> N1 -> 03 -> P2 -> P1 -> P1 -> P1 -> P1 5: N2 -> N1 -> P2 -> P2 -> P1 -> P1 -> P1 -> P1 6: N2 -> N1...

You have long modes where you the programmer specify the bank: lda $123456 ; Read from $12:3456 Most other addressing modes will use the bank specified by the DBR (data bank register). Access the DBR with the PHB/PLB instructions. lda #$AB pha plb lda $1234 ; Read from $AB:1234 Stack relative and di...

Any decent assembler should be able to handle this case without crazy workarounds. That said, I don't have the experience with WLA-DX to say how to fix this. How would you tackle the same problem with your assembler of choice? How about using ".orga" or the ".base" directives? I...

Those use cases might be a bit more exotic than I had in mind. Certainly for the kind of things I've been doing it's been sufficient. I'd be quite content to pretend coprocessors and other such addons don't exist though. In one of those scenarios however I think it should be enough to use the base a...

Whenever I've executed code into RAM, I've tried to make sure it doesn't depend on location in any way, so it could be copied to any location and work just the same. That way you don't have to worry about where you load it from, and you don't have to pay attention to how you structure your ROM. It s...

Well that's that cleared up. It's certainly not how I imagined it all, but it's much better to learn the correct way and the means of getting there. I'll have to re-evaluate some things. There is one other loosely related thing I might as well ask: There is a bug mentioned in one book (i.e. book1 2-...

This would be difficult to test because... I forgot that your test was using sprites to indicate what had been written. My own tests would prefill OAM with predetermined patterns, perform the reads or writes then display the numeric values to indicate which addresses had been read or written. It's ...

The part about fetching happening in reverse is a massive breakthrough. I've considered that possibility a few times but I wasn't sure if it were possible to test for it. My OAM write test was very primitive, never venturing past rendering or indeed using sprites in any meaningful way, so I never st...

I was half asleep when I wrote that and unbelievably distracted. I don't think I processed more than the first half of the OP. That said, I think most of what I said is correct. The part that's clearly wrong is in regards to Uniracers. There is no prior mention of the write being to the last entry i...

Two dots per sprite is about as close as I've been able to get. The evaluation process needs X and Y, but also the data from the hi table. XY is one word and char/attr is the other, so I've been assuming one word per dot with the hi table bits accessed whenever. As far as I can tell, reads always co...

It seems to run one pass with the running hash, then checks the final result against what it expects. If the two hashes don't match it runs a second pass but logs each interim result along the way. Therefore, one can make it produce that list by damaging the running hash as the first pass is being r...

It keeps a running hash for all the opcodes it tests. If it detects an irregularity, it outputs the hash it has between each opcode loop. 00 - E989B089 04 - 7E8E3E50 0A - 22485002 1C - 318F2A11 20 - 4A09603B 24 - D2D2F487 2A - 97DE6FFA 3C - BF1EDB4D 40 - F599F66C 44 - 2690255D 4A - 75575255 5C - 72D...

I didn't expect the 96:32 theory to fit, but the fact you have two separate consoles that produce similar errors is very encouraging. If a completely different error had cropped up, it still would have been possible for separate SMP+DSP to produce three different states than the 2-in-1 package, but ...

Oh, well that's even better. One thing that was bothering me is the purpose of a "BRR wrapping" test in the first place when it seems like such a basic thing like memory layout couldn't fluctuate at all. The explanation that makes sense to me is that it's not in any way intended as a syste...