How to debug a nes crash?

[adam_smasher]

I would rather use Windows than try to write an NES game without a debugger

If it works repeatedly at the beginning of the game

and crashes every time at the end of the level

then something happens during gameplay that causes the crash

(in particular, some global state (either in memory or in the hardware) is changed)

If you know it happens during ppu_on_all(), then you know that the
correct behaviour of ppu_on_all() depends on the the global state that is
changed during gameplay

What does ppu_on_all() look like?

[tepples]

Unless you're using Linux on a non-x86 platform, you can do what I did: sudo apt-get install wine and then use the Windows version.

Pure 64-bit, so Wine is not a possibility.

Then go impure (that is, multi-arch) with i386 and amd64. Or install a VM and run 32-bit Linux and Wine in the VM. Or buy a copy of Windows to use on another computer, compile FCEUX for Windows in 64-bit mode, and run that in 64-bit Wine.

[GradualGames]

Something's gotta be stepping on something. While I was experimenting with C, I could swear I got into a situation once where something was mysteriously stepping on a zp variable of mine. It made me wonder at one point if the linker configuration was set up so that my zp variables actually shared space with cc65's zp space. I never found out what that particular problem was as that bug just hid after a while. With 6502, I've been able to consistently find the root cause of bugs throughout the deveopment of each game (and know for sure it was my own code...the assembler itself only caused trouble in 3 instances I can recall and were minor problems)---something I can't say for any other language I've worked with (sometimes a workaround is the only thing you can find in the face of immense complexity).

[lidnariq]

Then go impure (that is, multi-arch) with i386 and amd64. Or install a VM and run 32-bit Linux and Wine in the VM.

Or debootstrap yourself a 32-bit chroot and use schroot.

[dougeff]

Maybe you could just post the Source Code and/or the ROM, and one of the people here can look at it with a debugger.

(And if cc65 source code, please indicate what version of cc65 you use).

Or perhaps, buy a $20 used windows laptop from ebay.

[Rahsennor]

The Debian version of mednafen has a debugger. It has a really obtuse interface, but it's something.

[tokumaru]

Not having a debugger at your disposal is crazy, solving bugs will take you 10 times longer if you have to keep guessing where the problem is... Come on, just install VirtualBox and a 200MB stripped down version of XP so you can do things properly.

[Rahsennor]

I know I'm being completely unhelpful here, but I find it depressing that the answer to "how to debug a NES game on Linux" is "use Windows".

Seriously though, why is the Linux port of FCEUX so pathetic?

[rainwarrior]

Seriously though, why is the Linux port of FCEUX so pathetic?

You act like this is some sort of professional project. The reason is obvious: nobody is sufficiently interested to do it for free.

If it's something you care about, why not contribute to the project yourself?

[Rahsennor]

I was not intending to act like it was a professional project, and you're right that the answer is obvious. I should have kept my mouth shut.

[rainwarrior]

Sorry, I didn't want to admonish you for speaking about it; what I was trying to do (perhaps with too bitter a tone) was encourage you to join the FCEUX project and help bring it up to snuff.

[tepples]

I find it depressing that the answer to "how to debug a NES game on Linux" is "use Windows".

No, it's "use Wine". That works for NES (FCEUX), and it works for Super NES (NO$SNS).

Seriously though, why is the Linux port of FCEUX so pathetic?

Is it necessarily more pathetic than wanting to adhere to some standard of 64-bit purity?

[calima]

Is it necessarily more pathetic than wanting to adhere to some standard of 64-bit purity?

And waste several gigs? I have better use for that space.

To the people telling me to pirate or pay for Windows, screw you. That is never the solution, it's a problem.

(in particular, some global state (either in memory or in the hardware) is changed)

I know, but there is no such state change in my code. So it must be a compiler bug, which is rather hard to track. If the cc65 stack underflows, it scribbles on the 0x2000 registers, if the hw stack overflows, it scribbles on ZP vars.

What does ppu_on_all() look like?

Code: Select all

;void __fastcall__ ppu_on_all(void);

_ppu_on_all:

        lda <PPU_MASK_VAR
        ora #%00011000

ppu_onoff:

        sta <PPU_MASK_VAR
        jmp _ppu_wait_nmi

While I was experimenting with C, I could swear I got into a situation once where something was mysteriously stepping on a zp variable of mine

They are allocated the same, so that was a bug in the compiler (or the standard library, if you used it).

Maybe you could just post the Source Code and/or the ROM, and one of the people here can look at it with a debugger.

(And if cc65 source code, please indicate what version of cc65 you use).

I use cc65 from git master. Will post the ROM in a bit.

No, it's "use Wine". That works for NES (FCEUX), and it works for Super NES (NO$SNS).

I won't use closed-source software on principle. Yes, fceux Windows would be open source, but that's a huge waste of both time and disk space.

I'm thinking about building fceux with debug symbols, finding where it keeps the RAM, and setting watches by debugging the emulator on the host. Crazy, but far less crazy than installing Windows.

[calima]

ROM link:
https://u.pomf.is/vstins.gz

Wait a second or two and press select.

[cpow]

AFAIK no emulator for Linux supports any debugging, though I've only tried the most popular ones. That's making this quite hard.

NESICIDE does. But it's been *forever* since I built and provided a Linux binary. Not that it won't work. Just will take me a little bit to get my Linux VM back.