tepples wrote: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).
dougeff wrote: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.