NESICIDE v? screenshots

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
User avatar
cpow
NESICIDE developer
Posts: 1089
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

NESICIDE v? screenshots

Post by cpow » Fri May 29, 2009 10:15 pm

I've been getting a lot of email lately due to the presence of NESICIDE on RomHacking.NET. Thanks Tater Bear!

Due to that, and partly to give myself a renewed vigor, I'm posting a few snaps of some of the things that are in various stages of 'in-work'ness. I am trying to get to the point where a new release would be a good release.

First, an execution tracer showing 256Ksamples of CPU/PPU bus activities...
Image
Image
...obviously a bit of timing work to be done (cycles is leftmost column not quite visible)

Next, I really like the NerdTracker style, so...
Image

A technicality, but I think something better presentation-wise...the autogen sourcecode for project elements is now viewable via a toolbar button instead of buried in the SOURCECODE tree branch. ALSO, modifications made to the sourcecode are applied back to the graphical view. Right now the graphical view icon in the toolbar is probably not 'cool'. I will change that...
Image

As I mentioned, a project-based wizard, of sorts...
Image

One other thing is that all of the ROM data in the CHR ROM banks or RAM data in the emulator (CPU, PPU, CHRRAM, OAM, Palette, SRAM, [EXRAM--when I get to it] and all of the registers (CPU, PPU, APU, I/O, Mapper) are modifiable via the edit controls. Most take effect when modified. For example, here I modified a few characters in PPU RAM during SMB1 intro (the word WORLD is horked).
Image

Also adding configuration options for lots of junk...
Image
Image

There it be so far.

User avatar
Banshaku
Posts: 2328
Joined: Tue Jun 24, 2008 8:38 pm
Location: Fukuoka, Japan
Contact:

Post by Banshaku » Fri May 29, 2009 10:35 pm

Looking promising. It seems you can use it to debug existing rom, which is always a good thing. If you can add to step in/out/over, label for specific memory addresses and be able to use shortcut keys like visual studio for debugging, not just pressing the button with the mouse, that would be great.

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Sat May 30, 2009 4:12 am

Needs a "Do not use color 0D" warning message.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
cpow
NESICIDE developer
Posts: 1089
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow » Sat May 30, 2009 6:52 am

Banshaku wrote:Looking promising. It seems you can use it to debug existing rom, which is always a good thing. If you can add to step in/out/over, label for specific memory addresses and be able to use shortcut keys like visual studio for debugging, not just pressing the button with the mouse, that would be great.
Yes, shortcuts are becoming more and more obviously necessary. Just before I read this I hit F5 to try to run a ROM. Nothing happened...

'Step in' would seem to me to be equivalent to 'Step' unless you mean 'go until you hit a JSR, exec the JSR, and then stop'?

'Step out' would be 'go until you hit a RTS/RTI' and the address popped off the stack is correct for where you were starting from.

'Step over', would be combined 'step in' and 'step out' and depending on how I interpret 'step in' it could go for a long time until it hits a JSR and then go through to the RTS, or it could do nothing if the current opcode is not a JSR. Thoughts?

Great suggestion!

User avatar
cpow
NESICIDE developer
Posts: 1089
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow » Sat May 30, 2009 6:55 am

Dwedit wrote:Needs a "Do not use color 0D" warning message.
Is it just 0D? That is the 'blacker than black' right? Can it actually physically damage a CRT? [Maybe a stupid question, but just curious if that is the reason you would expect such a warning.]

User avatar
Banshaku
Posts: 2328
Joined: Tue Jun 24, 2008 8:38 pm
Location: Fukuoka, Japan
Contact:

Post by Banshaku » Sat May 30, 2009 7:15 am

NESICIDE wrote:Yes, shortcuts are becoming more and more obviously necessary. Just before I read this I hit F5 to try to run a ROM. Nothing happened...
Yes, they will be quite useful. For now I may have to modify the source code of an existing emulator to have those shortcuts (if I can find the time..). I use VS every day so I kind of miss them when I debug nes code.
NESICIDE wrote:'Step in' would seem to me to be equivalent to 'Step' unless you mean 'go until you hit a JSR, exec the JSR, and then stop'?
Yes, 'step in' is step. It execute instructions one at a time.
NESICIDE wrote:'Step out' would be 'go until you hit a RTS/RTI' and the address popped off the stack is correct for where you were starting from.
Step out is when you just entered a jsr and you do not want to trace the rest of the function. How to implement it is a good question. I guess you need a list of how deep your are to know if you can step out or not. Once your back to the main loop, you cannot step out anymore.
NESICIDE wrote:'Step over', would be combined 'step in' and 'step out' and depending on how I interpret 'step in' it could go for a long time until it hits a JSR and then go through to the RTS, or it could do nothing if the current opcode is not a JSR. Thoughts?
Step over only works if the next instruction is a jsr. You have to execute the code of the function and give back control after the rts. If next instruction is not a jsr, it just become a normal step instruction.

Not all current nes emulator support those method, only one comes to mind. It may be a lot of work to implement but it will be quite useful in the end.

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sat May 30, 2009 8:00 am

NESICIDE wrote:Is it just 0D? That is the 'blacker than black' right? Can it actually physically damage a CRT?
Probably not; otherwise, transmitting no signal at all could hurt the CRT. But if a vertical bar of $0D fools the TV's sync separator circuit, the TV will show an unreadable image. If this image was supposed to be "Don't forget to hold Reset while powering off the NES", it could damage saved data in battery-backed PRG RAM.
Banshaku wrote:Step out is when you just entered a jsr and you do not want to trace the rest of the function. How to implement it is a good question. I guess you need a list of how deep your are to know if you can step out or not. Once your back to the main loop, you cannot step out anymore.
"Step out" is a watchpoint on the stack. It runs until the stack pointer has has increased past its current value.

I can think of two ways to implement "step over":
  1. Save the value of SP, step in, and then keep stepping out until SP is at or above its saved value.
  2. Set a breakpoint after this instruction, then run until next breakpoint.

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Sat May 30, 2009 8:27 am

Color 0D just warps some TVs while the color is on the screen. No damage, just a probably unwanted effect.
Otherwise everyone with a Game Genie would have a broken TV.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
cpow
NESICIDE developer
Posts: 1089
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow » Sat May 30, 2009 8:48 am

tepples wrote: I can think of two ways to implement "step over":
  1. Save the value of SP, step in, and then keep stepping out until SP is at or above its saved value.
  2. Set a breakpoint after this instruction, then run until next breakpoint.
Doing it the second way would be almost equivalent to the 'step' operation. Ie. 'step' just tells the emu to run one instruction. 'step over' would be the same if the instruction were not a JSR, but if it were, then the breakpoint would be set to the return address. I think that's the easiest / most reliable way. Someone could fool the SP approach with buggy code that horks the stack.

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Sat May 30, 2009 9:27 am

Could stack manipulation and other tricks (usually involving the use of JSR and RTS for purposes other than calling and returning from subroutines) break the step out and step over implementations you are discussing?

User avatar
cpow
NESICIDE developer
Posts: 1089
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow » Sat May 30, 2009 9:33 am

tokumaru wrote:Could stack manipulation and other tricks (usually involving the use of JSR and RTS for purposes other than calling and returning from subroutines) break the step out and step over implementations you are discussing?
The first one, yes. I don't think the second one would be affected unless the code never RTSed back to it (ie. the NES goes off into the weeds inside the function you're trying to step over).

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sat May 30, 2009 9:45 am

NESICIDE wrote:
tokumaru wrote:Could stack manipulation and other tricks (usually involving the use of JSR and RTS for purposes other than calling and returning from subroutines) break the step out and step over implementations you are discussing?
The first one, yes.
But if you're "abusing" the call and return instructions, is there really a concept of "in", "out", or "over"?
I don't think the second one would be affected unless the code never RTSed back to it (ie. the NES goes off into the weeds inside the function you're trying to step over).
If the NES goes off into the weeds, that means you should back up to the last saved state and try stepping into the subroutine instead to see why the NES is going off into the weeds.

Post Reply