SNES Splatoon (How do I shot HiROM?)

[Drew Sebastino]

load from something from an area in ram

Wait a minute, I'm an idiot, because I meant I want to load something from an area in rom. That's what the

Code: Select all

  and $0000,y
  ora $0002,y

are for. If it were offset by #$7E, it would mess it up. Actually, looking at it, I just noticed I have to have all the splat graphics in one memory bank. I guess that shouldn't be too bad. I'm going to have to go through all this code at some point anyway for if there's extra ram in the cartridge.

Man, now looking at it, the SNES memory map is awfully complicated...

[tepples]

If you want to access both ROM and RAM without using any sort of 24-bit addressing, then you'll need to ensure that the ROM data is in the top half of bank $80-$BF and the RAM data is in the shadow RAM area ($7E0000-$7E1FFF). If you cannot arrange this, then you must use 24-bit addressing for either the source or the destination.

Are you using LoROM ($20/$30) or HiROM ($21/$31)? Or do you want the details explained for both?

[Drew Sebastino]

I want the details explained for both... Isn't HiROM bigger?

[tokumaru]

I wonder if I'm ever going to understand SNES memory mapping... Every time you guys talk about it, it sounds completely alien to me! It looks like everything is so broken up, it's insane! So yeah, I'm kinda interested in an explanation too!

[lidnariq]

The SNES's two different memory maps were approximately the two ways that N thought that people might want to use the SNES:

Mode 20 ("LoROM") assumed that people wanted to pretend that the SNES acted approximately like the NES's BNROM: shared resources (RAM from $0000-$1FFF, PPU, sound, DMA, on-cartridge save RAM) were always available in the lowest 64 banks. (Or, if the person paid the then-premium for faster memory, banks $80-$BF).

Mode 21 ("HiROM") was a forward-looking way of thinking about it, assuming that people were actually going to take advantage of the 65816's larger address space, with 24-bit pointers and remapping the direct page.

Of course, since the 65816 has both the PBR and DBR, this division is a little artificial. And the small handful of Mode 20 games that are larger than 2 MiB don't even get the advantages of LoROM in those upper banks (where $40 ≤ DBR ≤ $7D )

[tepples]

In LoROM (mode $20 or $30), PRG ROM runs from $808000 through $80FFFF, $818000 through $81FFFF, $828000 through $82FFFF, ..., $FF8000 through $FFFFFF, for a total of up to 32 megabits 4 MiB. A23 and A15 are ignored. Banks $80-$FD are mirrored into $00-$7D. If the data bank register is set to bank $00-$3F or $80-$BF, the program can access shadow RAM and a ROM bank from the first 16 megabits (2 MiB) at once without using 24-bit addresses.

In HiROM (mode $21 or $31), PRG ROM runs from $C00000 through $FFFFFF, for a total of up to 32 megabits (4 MiB). A23 and A22 are ignored. Banks $C0-$FD are mirrored into $40-$7D, and the second half of each bank is mirrored into $00-$3F and $80-$BF. If the data bank register is set to one of these banks, the program can access shadow RAM and the second half of a ROM bank at once without using 24-bit addresses.

In ExHiROM (mode $25 or $35), PRG ROM runs from $C00000 through $FFFFFF, $400000 through $7DFFFF, $3E8000 through $3EFFFF, and $3F8000 through $3FFFFF, for a total of up to 63.5 megabits (just under 8 MiB). A22 is ignored. The second half of each bank $C0-$FF is mirrored into $80-$BF, and the second half of each bank $40-$7D is mirrored into $00-$3D. If the data bank register is set to one of these banks, the program can access shadow RAM and the second half of a ROM bank at once without using 24-bit addresses.

The difference between $20 and $30, $21 and $31, and $25 and $35 is that $30, $31, and $35 can take advantage of faster 120 ns ROM, which was more expensive at the time than the common 200 ns ROM. The S-CPU runs at 3.6 MHz when accessing fast ROM or 2.7 MHz when accessing RAM or slow ROM. In ExHiROM, only the area from $C00000-$FFFFFF (including its mirrors in $80-$BF) is fast. DMA is always slow (2.7 MHz), so if a game DMAs from ROM, it can put the data used as a DMA source in the slow part and gain the benefit of fast ROM for the rest of the ROM.

I made a diagram several months ago.

[tokumaru]

That's confusing as fuck. If I was ever gonna jump into 16-bit development, I'd probably choose the Genesis/MD, which appears to have a much more consistent architecture, without a shit-ton of possible configurations, from memory mappings to video modes. Is there at least a consensus on what's better to do on the SNES these days, when cost isn't such a big factor?

[psycopathicteen]

-Banks $00-$3f and $80-bf contain both ROM and RAM.
-Banks $40-$7d and $c0-$ff are ROM only.
-Banks $7e and $7f are RAM only.

[Drew Sebastino]

That's confusing as fuck. If I was ever gonna jump into 16-bit development, I'd probably choose the Genesis/MD, which appears to have a much more consistent architecture, without a shit-ton of possible configurations, from memory mappings to video modes.

I'm beating a dead horse here, but the color count kills it for me. Honestly, I think the onscreen color count on the SNES is kind of mediocre, especially when you see an arcade system from 1985-1986 or so that's inferior to the SNES in every way except it has over twice the number of colors. Hell, no need to look further than the PCE, and it was a home console. Anyway, if I were to go for a "balanced" 16 bit system, I would have started out with the M92. (Unfortunately though, it has piss poor documentation...)

Is there at least a consensus on what's better to do on the SNES these days, when cost isn't such a big factor?

Definitely FastROM. (You'd be a sucker not to use it.) I don't know about LoROM vs. HiROM, but I'd probably use HiROM because it's easy to switch over to ExHiROM if you find yourself running out of memory with graphics or whatever. (Although I can't imagine myself ever filling up over 4MB worth of graphics at the rate I draw... Better be safe than sorry?)

You know tepples, I was always under the impression that you made this (SNES.cfg) and although I think it's meant for LoROM, will it work for HiROM?

Code: Select all

# ca65 linker config for 256 KiB (2 Mbit) sfc file

# Physical areas of memory
MEMORY {
  ZEROPAGE:   start =  $000000, size =  $0100;   # $0000-00ff -- zero page
                                                 # $0100-01ff -- stack
  BSS:        start =  $000200, size =  $1e00;   # $0200-1fff -- RAM
  BSS7E:      start =  $7e2000, size =  $e000;   # SNES work RAM, $7e2000-7effff
  BSS7F:      start =  $7f0000, size = $10000;   # SNES work RAM, $7f0000-$7ffff
  ROM0:       start =  $008000, size =  $8000, fill = yes;
  ROM1:       start =  $018000, size =  $8000, fill = yes;
  ROM2:       start =  $028000, size =  $8000, fill = yes;
  ROM3:       start =  $038000, size =  $8000, fill = yes;
  ROM4:       start =  $048000, size =  $8000, fill = yes;
  ROM5:       start =  $058000, size =  $8000, fill = yes;
  ROM6:       start =  $068000, size =  $8000, fill = yes;
  ROM7:       start =  $078000, size =  $8000, fill = yes;
}

# Logical areas code/data can be put into.
SEGMENTS {
  CODE:       load = ROM0, align =  $100;
  RODATA:     load = ROM0, align =  $100;
  SNESHEADER: load = ROM0, start = $ffc0;
  CODE1:      load = ROM1, align =  $100, optional = yes;
  RODATA1:    load = ROM1, align =  $100, optional = yes;
  CODE2:      load = ROM2, align =  $100, optional = yes;
  RODATA2:    load = ROM2, align =  $100, optional = yes;
  CODE3:      load = ROM3, align =  $100, optional = yes;
  RODATA3:    load = ROM3, align =  $100, optional = yes;
  CODE4:      load = ROM4, align =  $100, optional = yes;
  RODATA4:    load = ROM4, align =  $100, optional = yes;
  CODE5:      load = ROM5, align =  $100, optional = yes;
  RODATA5:    load = ROM5, align =  $100, optional = yes;
  CODE6:      load = ROM6, align =  $100, optional = yes;
  RODATA6:    load = ROM6, align =  $100, optional = yes;
  CODE7:      load = ROM7, align =  $100, optional = yes;
  RODATA7:    load = ROM7, align =  $100, optional = yes;

  ZEROPAGE:   load = ZEROPAGE, type = zp;
  BSS:        load = BSS,   type = bss, align = $100, optional = yes;
  BSS7E:      load = BSS7E, type = bss, align = $100, optional = yes;
  BSS7F:      load = BSS7F, type = bss, align = $100, optional = yes;
  }

[tepples]

It would need to be modified. But right now, I'm running a bit of a low grade fever, which means I'm not in the mental state to make and test a HiROM.

If you want to try yourself, change the memory area sizes to $10000, the memory area starts to $C00000, $C10000, ..., and the SNESHEADER start to $C0FFC0.

[Drew Sebastino]

Dang, I switched it, but I forgot how it would give me a bunch of range errors... Why do all the starter demo stuff use LoROM? I guess they assume that everyone who works on the SNES has started with the NES, but I'm not under the impression that any of the people working on the SNES have worked on the NES.

Anyway, this is my first (and hopefully only) problem it's given me. It's code for jumping to appropriate object code. Direct page is being moved here, which is why "Identity" isn't being offset by anything. It loads "identity", first checks to see if it's 0 (no object), if not, gets the value and offsets the table by it, and loads that value in the table it landed on which is the address of where the code starts. I'm still not entirely sure how "()" works, but I guess "jsr Whatever" and "jsr (Whatever)" are different instructions, because one is jumping to the posted address and the other is jumping somewhere based on the value at that address?

Code: Select all

object_identifier_loop:
  lda Identity
  beq next_object
  tax
  jsr (ObjectIdentificationJumpTable-2,x)

Further down...

;========================================================================
.segment "RODATA"
;========================================================================

ObjectIdentificationJumpTable:
  .word object1_code

Could I just get the Identity, have it be 24 bit, and somehow transfer the value to the program counter directly? Actually, how would I even do this in one go? You can't transfer 24 bits at once, and that's kind of important here. Yeah, it was a dumb idea anyway...

[tepples]

Dang, I switched it, but I forgot how it would give me a bunch of range errors... Why do all the starter demo stuff use LoROM?

Because I flipped a coin.

I'm still not entirely sure how "()" works, but I guess "jsr Whatever" and "jsr (Whatever)" are different instructions, because one is jumping to the posted address and the other is jumping somewhere based on the value at that address?

Yes. If $FFFC-$FFFD have values $5E $A0, then JMP $A05E and JMP ($FFFC) do the same thing.

[Jump table stuff]
Could I just get the Identity, have it be 24 bit, and somehow transfer the value to the program counter directly? Actually, how would I even do this in one go? You can't transfer 24 bits at once, and that's kind of important here. Yeah, it was a dumb idea anyway...

You could try pushing the 24-bit address minus 1 on the stack and using the RTS trick, like the Apple IIGS Toolbox does. (Caution: The minus 1 part has to be done modulo 65536, as execution wraps within a program bank.)

[Sik]

Why do all the starter demo stuff use LoROM?

I imagine Super Mario World is LoROM? Because I imagine a lot of people would be in it to hack SMW instead of making games from scratch.

[Drew Sebastino]

Because I flipped a coin.

Really?

You could try pushing the 24-bit address minus 1 on the stack and using the RTS trick, like the Apple IIGS Toolbox does.

That's actually pretty ingenious...

(Caution: The minus 1 part has to be done modulo 65536, as execution wraps within a program bank.)

I don't have a clue as to what that means, but I'm guessing that this can just be static? I mean, for the "Identity" of "Object1", it would just be "#object1_code-1". (or something like that. I don't know how it'll tell if the -1 is part of the name or not.)

I imagine a lot of people would be in it to hack SMW instead of making games from scratch.

But, I mean, we're talking about things like the SNES Starter Kit. Has anyone ever made a sort of reassembly of a game to where they've made assembly code that completely recreates the game just how it was made? I guess different assemblers have different preferences as to where they want to map everything and memory and stuff like that though.

[bazz]

(Caution: The minus 1 part has to be done modulo 65536, as execution wraps within a program bank.)

I don't have a clue as to what that means, but I'm guessing that this can just be static? I mean, for the "Identity" of "Object1", it would just be "#object1_code-1". (or something like that. I don't know how it'll tell if the -1 is part of the name or not.)

he means if your symbol is at $040000 then the math must say 04FFFF instead of 03FFFF. most programs use % for modulus, but you don't really need to actually use it. just do the subtraction on the lower 16 bits and leave the bank byte unmodified.

I'm all for sharing neat tips and tricks but I feel like Espozo is in over his head.