#Bad checksum error snes9x manual
#Bad checksum error snes9x full

The 65816 starts up in 65c02 emulation mode (e.g. This is just common practise as well, even on the 6502/65c02,Ĥc) You absolutely need to clear emulation mode on startup.

#Bad checksum error snes9x manual

There are multiple things going on there, so I'll itemise them:Ĥa) You need to make sure the assembler is operating with the knowledge that it's in either bank $c0 (normal speed mode 21 (hirom) - probably what you want), or $80 (fast speed mode 21 but be aware of the memory layout) - see SNES developers manual page 2-21-4 for the memory layout and see the notes at the bottom of that page - and this also relates to (4d) below,Ĥb) Disabling interrupts ASAP is important, you don't want a spurious NMI or hardware IRQ happening at this point. My guess is that (2) and (3) are the cause of your problem. org $xx8000 Or however this is done with WLA DX - see below for why I say $xx, but $xx8000 is important! The very first thing you should be doing (meaning this is the code that should get pointed to by the RESET vector) is this:Ĭode: Select all.

#Bad checksum error snes9x full

You probably aren't initialising the 65816 correctly but since you aren't providing full source code I can't tell. See SNES developers manual Chapter 3 (page 2-3-2 onward) for what you should be doing before turning on the screen in this case.Ĥ. You've probably got $2105 as $00 (mode 0, tile size of 8x8), and $2107 (BG1) is probably pointing to $0000 in VRAM, and $210b (BG1 and BG2) is probably also pointing to $0000 in VRAM, which is probably not what you want (CHR data at the same location as the layout data? Heh -) Well I guess for a 'blank/zero everything' you might!). Likewise/related to 2, you're not doing anything with $2105 (selecting BG mode/size), $2107 through $210a (BG-SC size/base address), nor $210b/210c (name base address for CHR data). If higan/bsnes sticks 'random crap' there on power-on, then good, because there's no guarantee what VRAM contains on power-on or reset on the actual console! It's your responsibility to zero this out (commonly done via DMA) as you see fit.ģ. This would vary from emulator to emulator. You're making a blind (and very bad!) assumption that the content of VRAM is is pre-zeroed/empty. You're not doing anything with $2115 (VRAM access mode/model), $2116/2117 (VRAM address) nor $2118/2119 (VRAM data) - meaning, you aren't writing anything to VRAM. $2121 not being set immediately prior to tinkering with $2122 is probably not wise.Ģ. I'm of the same opinion as bazz at this point, but will expand:ġ.

What Tepples said is correct root cause of your issue is unrelated to the 'failed checksum' message, and fixing that is up to a utility that runs either post-assembly or has to be handled properly by the assembler itself.