rynorris / nes Goto Github PK

Proper debugger features:

• Step one instruction forward.
• Step forward until vblank.
• Breakpoint when PC gets to a certain address.
• Breakpoint when a certain memory address is read/written.

Visual scroll glitches on title screen and crashes when trying to start the game.

Looks like some kind of scroll split issue, maybe sprite 0-hit related.

The top 10 most common mappers according to nescartdb:

• Mapper 1 | 677 (28%)
• Mapper 4 | 587 (24.28%)
• Mapper 2 | 267 (11.04%)
• Mapper 0 | 247 (10.22%)
• Mapper 3 | 155( 6.41%)
• Mapper 7 | 75 (3.1%)
• Mapper 206 | 44 (1.82%)
• Mapper 11 | 31 (1.28%)
• Mapper 5 | 24 (0.99%)
• Mapper 19 | 20 (0.83%)

Implementing all of these would get us to 2127 / 2418 games supported (88%).

Hangs at startup.
This seems to be different to the 0-hit timing issues most people talk about since I'm hanging way before anything even even drawn to the screen!

There's so much wrong with this I'm not sure where to start.
We're failing to swap tile banks half way down the screen, the palettes are messed up, and the music is just a high-pitched squeal.

For the tile banks one my best guess is that we're failing to trigger sprite 0-hit. For the other things, no idea, could be a cascade effect?

Never got round to this before.
Supported:

• Bit 0 - Greyscale
• Bit 1 - Show background in first 8 pixels
• Bit 2 - Show sprites in first 8 pixels
• Bit 3 - Show background
• Bit 4 - Show sprites
• Bit 5 - Emphasize red
• Bit 6 - Emphasize green
• Bit 7 - Emphasize blue

The snare in the background music of stage 1 is not playing. The other DMC samples play fine.
That's a pretty weirdly isolated issue, I haven't noticed any audio problems anywhere else.

The game seems fine up until the second level, and then around halfway through it totally freezes up and stops accepting controller input.
Also if you run into walls it can freeze in the same way. Very weird.

Right now my MMC3 implementation only finds the value of the A12 line whenever the PPU reads from the mapper.
Technically it should just know the actual state of A12 at all times, otherwise the counter won't decrement because of writes to PPUADDR.

I need to refactor slightly so that the MMC3 can have direct access to the value of ppu.v somehow.

Stuff to store

• All CPU registers
• Full contents of PRG RAM
• Full contents of CHR RAM (if present)
• Full contents of SRAM
• All internal state of PPU
• All internal state of APU (could maybe skip this, I have a feeling the APU will probably recover itself)
• State of mapper (will be different per-mapper)

Format

Thinking about going with JSON, with base64 encoded blobs for the memory dumps.
Or perhaps a binary format like msgpack?

I consider this pretty low priority since it's kind of a lot of work, and essentially no games use them.

We should (optionally) properly emulate the NTSC aspect ratio and overscan.
This will hide some artifacts developers intentionally put at the top/bottom of the screen.

https://wiki.nesdev.com/w/index.php/Overscan#For_emulator_developers

I just got to the game over screen on ninja gaiden, and hit reset, but nothing happened and the emulator was stuck on the game over screen forever.
I saw something similar in Contra before.

My reset handling must not be quite right I guess?

Crashes at boot with 'Unknown opcode: 2'.
Guess we must have a CPU bug still hiding somewhere? Probably it's not actually expecting to use the undocumented opcodes.

Probably have to add an NTSC encoder + decoder to make this look authentic. Encode into 8 samples per pixel, and decode using 12.

See: https://wiki.nesdev.com/w/index.php/NTSC_video

Like we have the PPU debug panel, it would be cool to have an APU debug panel to show the current state of the various APU components to help debug sound issues.

Ideas:

• For Pulse and Triangle => Draw an example waveform. Should be a fairly simple calculation from their parameters.
• For Noise => Figure out something that represents the mode/period/volume nicely.
• For DMC => Simple thing would be to just display a bar based on length of current sample remaining. Ultimate thing would be to go fetch the sample from memory and draw the actual waveform.

Would be nice to have a debug mode that displays a page of memory (from the CPU's perspective).
Would need some input scheme to switch between pages.

Self explanatory.