SNES Splatoon (How do I shot HiROM?)

[Revenant]

The latest version of bsnes-plus has the option to use the otherwise-unused WDM instruction as a breakpoint, so it will only affect execution if that option is enabled but is basically a no-op otherwise. It's probably ideal for development compared to "normal" breakpoints since you don't have to know exactly where the code of interest is located in memory.

[Drew Sebastino]

If you want the BRK instruction to actually freeze the game, you should make it lead to an infinite loop rather than an RTI. Or ideally, use an emulator that supports breakpoints (which it looks like you're already doing) and use those instead.

no$sns will automatically open the debugger on STP.

Oh, that's what I wanted to do. I thought "BRK" would just stop the CPU in whatever way, but "STP" is what does that. Yeah, it freezes both times now, like intended. I actually went through the splat drawing code, and somehow, it goes through the entire thing and exits at the right spot (I put STPs at all the exits except the intended one, and I tested to see how far it would go by moving how far I placed the STP) but nothing gets drawn. I'm going to have to look over it carefully. I don't think I've ever made a code work not as intended but without having it crash, so this is new to me.

[Drew Sebastino]

I think I might have found something out. I've actually been busy even during spring break, so I haven't been able to work on this... Anyway, instead of

Code: Select all

  lda InkBuffer,x
  and $0000,y
  ora $0002,y
  sta InkBuffer,x

I wrote

Code: Select all

  lda #$FFFF
  sta InkBuffer,x

and looked at $7E2000 to see if anything showed up, but somehow, the game actually crashed. I looked at the spot in ram, and it appeared to be empty, and I then looked around $0000 and it was filled with FFFF. I'm assuming by some miracle that it worked originally, because I thought that "and #$0000" would make everything there 0, and I was speculating that the "y" value was incorrect and not getting the right data but the weirdest thing is that it's crashing even when I wrote

Code: Select all

  lda #$0000
  sta InkBuffer,x

Anyway though, it really shouldn't be writing anything in that location anyway if long addressing is being used, which I feel it isn't. Is there a way to force it?

Anyway, apparently to add to my confusion, take a look at this:

None of those #$87's should be there, and only two bytes should be filled out at most. I'm assuming another code is looking at the variables in ram that are no incorrect and if freaking out. A couple values actually get updated every frame, surprisingly.

[Drew Sebastino]

I found something. Putting an "stp" at the end of the drawing code (to where no other code gets written) still produces the same garbage in ram, so it must be something self contained. Isn't there a way to make ca65 give you files that say exactly what the assembler is doing, because it makes 0 sense for it to be screwing up for loading a number there. putting an "stp" after the first thing I did in ram doesn't appear to create the weird crazy patterns I showed you guys, but it might be messing up a variable that's triggering a chain reaction. Again, I need the files to tell me if it's the assembler's fault, and I've already had one of those with a different assembler...

Damn it, does anyone else ever get problems like this?

Edit: I thought it would be wise to upload the .bat file I use for assembling everything, so if anyone knows how to fix it to give me .lst files, here it is:

Code: Select all

@echo off
ca65 Main.asm -o Game.o
if errorlevel 1 goto end
ld65 -o Game.sfc Game.o -C SNES.cfg
if errorlevel 1 goto end
ucon64 -q --snes --nhd --chk %1.sfc >nul 2>&1
echo assembly completed.
if exist Game.o del Game.o
if exist Game.sfc start Game.sfc
exit
:end
echo assembly failed.
if exist Game.o del Game.o

I have two .exe files called ca65 and ld65, if that helps. It looks like several people have already downloaded the .zip file I posted though.

[Joe]

Code: Select all

ca65 Main.asm -o Game.o

Code: Select all

ca65 -l Main.asm -o Game.o

[nicklausw]

My guess is that you're pushing a register without popping it, building up values on the stack. Checked for that?

[Drew Sebastino]

My guess is that you're pushing a register without popping it, building up values on the stack. Checked for that?

I just checked for that, and no, there's no pushing or pulling involved. That shouldn't even mess it up anyway, because it's only ran once. The "lda #$0000" definitely shouldn't mess it up.

ca65 -l Main.asm -o Game.o

I tried that but it didn't work. I was actually messing around with it, and I fixed it though by guessing:

Code: Select all

ca65 Main.asm -o Game.o -l Game.lst

Unfortunately, it only makes one file with everything together, but it still works.



I just noticed something. How did I know this would happen...

Code: Select all

0003BFr 2  BD rr rr       lda InkBuffer,x

There's kind of an "rr" missing, because "InkBuffer" is in 7EXXXX... Is there a way to save a cycle or two by only having one "rr" for the top 4 of the 24 bits and having the other bottom 8 bits just be offset by x?

[tepples]

If the data segment register B is equal to $7E, you can access variables in $7E0000-$7EFFFF using 2-byte addresses. That might save a cycle.

[Drew Sebastino]

How would I do this? I just don't want to do long addressing when I don't need to, and the assembler seems to think that InkBuffer fits in a 16 bit address...

[bazz]

Code: Select all

phb
; 8-bit accumulator (EDIT)
lda #$7e
pha
plb
; do stuff with bank $7e
lda $2100 ;wow mom, I loaded $7e2100 !!
plb ; restore old databank

Of course you will be losing cycles unless you can justify the additional stack-processing

[koitsu]

Don't forget the accumulator needs to be in 8-bit mode (sep #$20 minimum) for aforementioned to work properly, otherwise you'll eventually end up with a stack overflow. So be sure to add that to your cycle counting, in addition to any necessary rep #$20 or equivalent thereafter.

[tepples]

One trick I like to do is pea two bytes onto the stack and then plb one at a time.

[Drew Sebastino]

Wait a minute, if the bank register is set to anything other than #$00 and I want to load from something from an area in ram where the top 8 bits are #$00, then won't I have to do "a:" and take up an extra cycle for that?

This is what I'm doing, if it helps. It's taking 8 2bit pixels, masking them, applying a pattern, and then storing them in the original spot. Each step is its own line.

Code: Select all

  lda InkBuffer,x
  and $0000,y
  ora $0002,y
  sta InkBuffer,x

[tepples]

The RAM at $0000-$1FFF is mirrored in both bank $00 and bank $7E.

[93143]

Exhaustively:

The only RAM as such in bank $00 (other than a handful of sometimes-useful bytes in the $43xx range) is what some call shadow RAM, the mirror of the bottom 8K of WRAM. If you're in any bank from $00-$3F or $80-$BF, shadow RAM works normally. If you're accessing bank $7E, shadow RAM still works normally, because $7E:0000-1FFF is what shadow RAM is a mirror of.

If you're in bank $7F or $40-$7D or $C0-$FF, you don't have access to shadow RAM. You can use direct page, because direct page is always in bank $00. But if what you want isn't in direct page, you have to either change the data bank register to access a bank with shadow RAM, change the direct page register so the data you want is in range, or use 24-bit addressing.