nesdev.com

There is a mechanism used by the crowd that I have started calling the "VRAM Queue" or "VQ" for short. A sequence of bytes, along with an address, can be written into the VQ, and those bytes will picked up later and be written into VRAM at the specified address for the next frame. I discovered the ...

Any idea why they'd expose so few bits of the DRAM and SRAMs to the programmable logic?

I guess if it's a teaching board then this tiny amount is more than enough.

Now that I've had a chance to sleep, I think that this test should capture two different subpixel alignments, because the data bus is driven roughly 100ns after M2 rises. I've since taken my oscilloscope and checked the original test, and I think it's only ever capturing one subpixel alignment. No ...

I've definitely heard of Flash (and RAM-and-something-nonvolatile) that worked that way, but I haven't yet heard of RAMs that had two dice and a demux.

All accesses to zero page wrap within zero page. That instruction (B1 FF) will load the LSB of the pointer from $00FF, but the MSB from $0000, not $0100.

Sprite and background tiles can't be anywhere in VRAM, but you can configure where they're found. Wait really? Perhaps a better way to phrase it is "they can't be everywhere " ? On the Genesis, with its 64KB of VRAM, each tile takes 32 bytes. 65536 bytes of RAM ÷ 32 bytes per tile = 2048 tiles, and...

No, they're independent regions of memory. Try using bsnesplus, NO$SNS, or Mesen-S's debuggers instead. Sprite and background tiles can't be anywhere in VRAM, but you can configure where they're found. Unlike the Genesis (which can address 2K unique background and sprite tiles simultaneously), you o...

The PC's joystick interface would be a super-awkward way to get lightpen data, given that there already was a standard: The CGA, MDA, and Hercules cards (and some EGA cards too) did have a lightpen input, but all appear to have used 1x6 0.1" spacing pin header inside the machine. "Clearly" that mean...

Sadly, your 3198 dumps appear to be completely fine, other than the two LSbits being completely broken. Even if there are more than four pages of instructions inside, the dumps you've recovered can only be six-bit-wide subsets of those 508 instructions.

If you have a standalone NSF file that doesn't use expansion sound or bankswitching, you can convert it into a ROM - look for VegaPlay.

You can probably weave a game around it, but it'll be a challenge to treat the NSF as a black box and not step on its toes.

If you have a multimeter with a diode test functionality, you could see if there's a diode drop measuring pins 1 and 2 to pin 16, or pin 8 to pins 1 and 2.

My suspicion, given that the validation mode can still be entered, is that the bond wire blew up. If so, you won't see any diodes.

I've written a variation on the test that tries to tickle both the "catch the monochrome bit for one pixel" and the "blue emphasis is entirely asynchronous" at the same time. I've tested it with PPU /RESET tied to CPU /RESET, and with PPU /RESET floating. The code uses the CPU to draw this parallelo...

cc65, and the 6502, are actually awful at the "array of structs" model.

For reasonable performance, you really need to stripe your data into separate arrays of bytes. (If you want, this can be a struct of arrays)

Fixon wrote: ↑

Tue Sep 22, 2020 2:28 pm

The Twin Famicom has previously been NESRGB modded (not by me) but that should not be causing the issue, still have the same problem over regular composite.

These symptoms look like something is specifically going wrong with the palette ... so I actually do suspect the NESRGB.

My understanding - we'll be able to confirm once we have a good dump of the 3198 - is that the "lock" 3198 on the mainboard transmits which of the fifteen cartridge CICs it wants to talk to, and only the one where the pins were tied high/low that match is the one that replies. But the "validation" m...