Id like to learn about the snes

[infidelity]

I'm new to snes, but not to 6502 asm. I've had some very good success in new hacking, and I'm starting to get curious in learning all I can about romhacking on the snes.

I'm sorry if all this has been asked before, but certain things I can't find answers on. So if you don't mind, id like to know the following.

1. How do you go about initiating a bank swap within an snes rom? Are there mappers involved, or is the method universal for all snes roms?

2. What are the pros/cons to hi/lo rom? From what I read online, lorom is 1 bank from $0-$8000, while hirom is one bank from $0-$100000(I think thats right)

3. Does the snes act the same with prg-rom as the nes did? Meaning how $8000-FFFF is the. prg-rom

[Bregalad]

1. How do you go about initiating a bank swap within an snes rom? Are there mappers involved, or is the method universal for all snes roms?

No, no, no, you're getting it all wrong. Unlike the NES, the SNES has a 65c815 CPU that has a 24-bit address bus. It can address very large ROMs without needing to do any bank swapping. Actually there is some technique in hardware that could seem analogious to "bank swapping" but everything is done by the CPU itself.

2. What are the pros/cons to hi/lo rom? From what I read online, lorom is 1 bank from $0-$8000, while hirom is one bank from $0-$100000(I think thats right)

I am not knownledgable with the 65c816 to give an exact answer, but adressing data outside of the currently selected bank is complex, can only be done with some opcodes, and requires more bytes. So you want to avoid that as much as possible, just like on the NES you'd avoid doing mapper writes for bankswitching as much as possible. It'd see it as equivalent to the NES' 32k PRG-ROM switching, exept accessing data outside of the bank is *possible*, it's just very limited to simple lda/sta.

With Hi-ROM the banks are enlarged to 64k, so there is only advantages, as you can fit more code and data in the same bank.

3. Does the snes act the same with prg-rom as the nes did? Meaning how $8000-FFFF is the. prg-rom

With Lo Rom : Yes, the memory map was purposely made similar to the NES'. With Hi-Rom this is not true anymore. The similarity with the NES' memory map is probably the only real advantage of Lo ROM.

All I said might be completely false - my knownledge of the 65c816 CPU is almost nonexistant.

[tepples]

The 65816 has different banks for the program counter and everything else. To switch the program counter into a different bank, you use the JSL opcode. A subroutine called this way has to return with RTL instead of RTS. To change the data bank (used by absolute addressing modes), you need to use that push the program bank (PHK) and push and pop the data bank (PHB and PLB respectively). One common sequence is PHK immediately followed by PLB to access program and read-only data in one bank. There are also absolute long addressing modes and a long indirect mode [d],y that temporarily change the data bank just for one instruction. These long modes work not only for LDA and STA but also for other group 1 instructions (ORA AND EOR CMP ADC SBC).

[infidelity]

Thank you for that info, amazing a simple sub routine does the swaps, so used to specific mappers with the nes.

I have another question. Does the snes fade in/out its palettes to achieve blackout, or does the snes CPU have its own specific fade in/out, without altering the current state of the palettes?

[magno]

LoROM has a main advantage: all I/O and registers can de done from the same bank you are executing code. So if you are accessingdata in bank $80, you can access VRAM address register by executing STA $2116; this is true for any bank you are executing code. If you had a HiROM program, then you access the same register by executing STA $002116.

LoROM is good when the code accesses registers intensively, and HiROM is better to optimize in-bank coding.

I have another question. Does the snes fade in/out its palettes to achieve blackout, or does the snes CPU have its own specific fade in/out, without altering the current state of the palettes?

There is a register which allows to increase/decrease screen brightness, so you can fade in/out by simply writing $0 to $F to that register.

[ARM9]

LoROM has a main advantage: all I/O and registers can de done from the same bank you are executing code. So if you are accessingdata in bank $80, you can access VRAM address register by executing STA $2116; this is true for any bank you are executing code. If you had a HiROM program, then you access the same register by executing STA $002116.

LoROM is good when the code accesses registers intensively, and HiROM is better to optimize in-bank coding.

This is a little misleading because what you're talking about is bank mirroring, which can be present on lorom carts as well as hirom.
Some lorom games access code/data in bank $40-$6F for example ($C0-$FF is possible as well), where 0-$7FFF is mapped to the low 32KiB of said rom bank and not the a/b bus registers etc.
Hirom games run code just as well in banks $00-$3F/$80-$BF to gain access to the a/b bus registers etc. mapped to $0000-$7FFF.

[magno]

This is a little misleading because what you're talking about is bank mirroring, which can be present on lorom carts as well as hirom.
Some lorom games access code/data in bank $40-$6F for example ($C0-$FF is possible as well), where 0-$7FFF is mapped to the low 32KiB of said rom bank and not the a/b bus registers etc.
Hirom games run code just as well in banks $00-$3F/$80-$BF to gain access to the a/b bus registers etc. mapped to $0000-$7FFF.

That's not true. Simply check how MAD-1 is connected to SNES address bus and you'd realize that HiROM cartridges would never access A22 = '0', and the other way is also true when checking MAD-1 connection for LoROM games.

Besides, I have RE lots of game code in assembler and never found a HiROM game that accesses $00-$3F/$80-$BF; what's more, $6000-$7FFF in banks $30-$3F (outside HiROM range) is reserved for accessing SRAM in most cartridges, so you are wrong.

Please get my SHVC schematics for several cartridge boards which I shared in the forum some years ago.

[ARM9]

That's not true.

Which parts specifically, if you don't mind elaborating?

Besides, I have RE lots of game code in assembler and never found a HiROM game that accesses $00-$3F/$80-$BF;

dkc2 (probably 1 and 3 as well), hirom in $80-$bf accessing the b bus by absolute 16 bit addressing
killer instinct, hirom $80+
super mario kart hirom $80+
super mario rpg lorom in bank $C0+
winter gold lorom in bank $40+
secret of evermore hirom $80+

what's more, $6000-$7FFF in banks $30-$3F (outside HiROM range) is reserved for accessing SRAM in most cartridges, so you are wrong.

I'm afraid you've lost me here, what part of my post is this supposed to refute?

[magno]

I elaborated what you were wrong in my previous post.
Are you sure you understand what the difference between HiROM and LoROM is?

DKC is HiROM and the code run from bank $C0 up. The same for all HiROM games: Chrono Trigger, Secret of Mana, Seiken Densetsu 3, Final Fantasy 6, Romancing Saga 3, and so on...
I seriously doubt any of the games you listed are HiROM and run code from bank $80...

I'm afraid you've lost me here, what part of my post is this supposed to refute?

This part:

Code: Select all

Hirom games run code just as well in banks $00-$3F/$80-$BF to gain access to the a/b bus registers etc. mapped to $0000-$7FFF.

HiROM games NEVER run code on bank $30-$3F: it they'd do, any accesses to $6000-$7FFF would be redirected to SRAM not ROM. Besides, that WOULDN'T BE A HIROM GAME, BUT A LOROM. You can check this in the developer manual (mode 21, 25, and so on). In fact, this discussion is a nonsense: MAD-1 would never decode the address to ROM properly is the code is not executed in $C0 and upper.

Maybe you are confused with ExtHiROM or LoExtROM modes, or maybe you have misunderstood the point here: of course any HiROM game can access registers from ANY BANK, but using long addressing. If they would use 16bit addressing, then you should change DB to point $00 before accessing registers.

It doesn't make even the slightest sense to think a HiROM CAN'T access registers from any bank, but using long addressing is less efficient than DP or 16bit addressing modes (more bytes and longer instruction execution), or changing DB constantly. That's what I said (no mistakes here): LoROM is more efficient (i.e. better) if the code is register-intensive.

[tepples]

If you take the second half of each 64K bank of a HiROM game, you get a LoROM. Obviously this won't run on its own, but ARM9's claim is that some HiROM games actually have functional code in this LoROM subset on which the rest of the game depends. Case in point: HiROM games have to run code from bank $00 just to boot, as the vectors are in page $00FF00. But I think ARM9 will actually have to point out specific JMLs to $808000-$BFFFFF from specific HiROM games in that list in order to get the point across.

[ARM9]

Are you sure you understand what the difference between HiROM and LoROM is?

There there, no need to be patronizing now. Are you talking about chapter 21 in the book?

I seriously doubt any of the games you listed are HiROM and run code from bank $80...

Just because I'm such a nice guy I've made some screenshots for you:
dkc2 (hirom)
killer instinct (hirom)
smk (hirom)
secret of evermore (hirom)
winter gold (lorom) for the reverse or whatever you were talking about.

HiROM games NEVER run code on bank $30-$3F: it they'd do, any accesses to $6000-$7FFF would be redirected to SRAM not ROM. Besides, that WOULDN'T BE A HIROM GAME, BUT A LOROM. You can check this in the developer manual (mode 21, 25, and so on). In fact, this discussion is a nonsense: MAD-1 would never decode the address to ROM properly is the code is not executed in $C0 and upper.

Of course I know that you can't access rom in $00-$3f:$0000-$7fff, I said no such thing. And I certainly wasn't implying it, I'm sorry for not being more specific in my original post. Regardless, it's really simple to partition your banks so that code is only ever located in $8000-$ffff.

It doesn't make even the slightest sense to think a HiROM CAN'T access registers from any bank, but using long addressing is less efficient than DP or 16bit addressing modes (more bytes and longer instruction execution), or changing DB constantly. That's what I said (no mistakes here): LoROM is more efficient (i.e. better) if the code is register-intensive.

But nothing's stopping you from keeping the dbr in lorom banks in a hirom game, allowing you to reach said registers with 16 bit absolute addressing.

[magno]

There there, no need to be patronizing now. Are you talking about chapter 21 in the book?

I didn't mean to be patronizing: some people mix up "SlowROM" and "LoROM". Mode 21 is "HiROM" as described in page 2-21-4 in the developer's manual book 1.

Just because I'm such a nice guy I've made some screenshots for you:
dkc2 (hirom)
killer instinct (hirom)
smk (hirom)
secret of evermore (hirom)
winter gold (lorom) for the reverse or whatever you were talking about.

Regardless, it's really simple to partition your banks so that code is only ever located in $8000-$ffff.

Man, those chunk of code are running from the mirrored address space... You can't access all your code from that bank: if the code is only ever located at $8000:$FFFF, then you are wasting half the ROM chip size (because in HiROM boards, A15 is routed to Mask-ROM; in LoROM boards, A15 is not routed to Mask-ROM thus using all chip), but if your code is located from $0000 to $FFFF, then you have to jump to the non-mirrored region to execute it... Again, this leads to the same conclusion you said I was wrong: LoROM is better when accessing registers intensively, and HiROM is better in reducing code fragmentation (less long jumps to routines).

But nothing's stopping you from keeping the dbr in lorom banks in a hirom game, allowing you to reach said registers with 16 bit absolute addressing.

Yes, there is one thing stopping me: I can't reach $0000:$7FFF from those banks.

[ARM9]

Man, those chunk of code are running from the mirrored address space... You can't access all your code from that bank: if the code is only ever located at $8000:$FFFF, then you are wasting half the ROM chip size (because in HiROM boards, A15 is routed to Mask-ROM; in LoROM boards, A15 is not routed to Mask-ROM thus using all chip), but if your code is located from $0000 to $FFFF, then you have to jump to the non-mirrored region to execute it... Again, this leads to the same conclusion you said I was wrong: LoROM is better when accessing registers intensively, and HiROM is better in reducing code fragmentation (less long jumps to routines).

Yes, there is one thing stopping me: I can't reach $0000:$7FFF from those banks.

The majority of space is not going to be consumed by 65816 code in a game usually, you can still cram assets and various data in the low 32KiB of banks with code in the high 32KiB. Besides, you'd still be using long pointers to reach across banks in lorom to access data.

[koitsu]

The majority of space is not going to be consumed by 65816 code in a game usually, you can still cram assets and various data in the low 32KiB of banks with code in the high 32KiB. Besides, you'd still be using long pointers to reach across banks in lorom to access data.

Not to mention, nothing stops you from using this trick in either mode, if you're going to do a _lot_ of memory-mapped register I/O:

Code: Select all

rep #$20
lda #$2100
tcd
sep #$20
lda #$0f
sta $00     ; Turn on screen, full brightness

Commercial games (ex. Chrono Trigger) do this. Or just resort to sep #$20 / lda #$00 / pha / plb beforehand. Your choice is either to use 24-bit addressing for your stuff (or for memory-mapped I/O regs), switch b around, or set d=$2100 + use 24-bit addressing for things (or possibly a combo of that and b=$00 + 16-bit reads/writes). There are many options/choices, none are infallible, with pros/cons to all.

I think the mode 20 vs. mode 21 argument with regards to this point is just crying over spilled milk; the console (memory map nor CPU) is going to change at this point in time. Accept the CPU, accept the memory map, move forward.

People crying over this shit would literally cry themselves to sleep if shown Apple II screen holes (also here). The above memory map ""issue"" (LOL) is a walk in the park compared to this.

[psycopathicteen]

Not only could you access the top halves of hirom banks through lorom mapping, but the system boots up that way by default.