News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Small Orientation issues with SNES ROM Maps  (Read 1677 times)

Xardas

  • Jr. Member
  • **
  • Posts: 12
    • View Profile
Small Orientation issues with SNES ROM Maps
« on: January 07, 2017, 02:59:11 am »
Hello boys and girls,

I felt like fooling around with the game I want to edit (FFV for SNES). So I obviously consulted a ROM map of that game. However, the offsets are separated into banks, each with the amount of FFFF offsets apparently. At first I thought "Ok, so the offest 0000 from the second bank must be 10000 from the entire ROM, ... and so on". But that's probably wrong. The map, which is afaik complete, has 32 Banks. But when I divided the amount of offsets in the ROM by FFFF, I got 59 (Dec), so I now think there are 59 banks.

As you might already see, I am lost. Eg. I cannot figure out how to "convert" C1/A3D1 into its corrosponding offest value in the hex editor. I would be thankful if someone explains that to me
Cheers

SunGodPortal

  • Hero Member
  • *****
  • Posts: 2921
  • 2 + 2 = 5
    • View Profile
Re: Small Orientation issues with SNES ROM Maps
« Reply #1 on: January 07, 2017, 03:29:58 am »
Quote
I felt like fooling around with the game I want to edit (FFV for SNES). So I obviously consulted a ROM map of that game. However, the offsets are separated into banks, each with the amount of FFFF offsets apparently. At first I thought "Ok, so the offest 0000 from the second bank must be 10000 from the entire ROM, ... and so on". But that's probably wrong. The map, which is afaik complete, has 32 Banks. But when I divided the amount of offsets in the ROM by FFFF, I got 59 (Dec), so I now think there are 59 banks.

I think a bank is 8000 hex bytes. Also, the ROM map might not be 100% complete. It probably just has whatever the user who uploaded it could identify.

Quote
As you might already see, I am lost. Eg. I cannot figure out how to "convert" C1/A3D1 into its corrosponding offest value in the hex editor. I would be thankful if someone explains that to me

I'm not 100% sure but I think C1 is the bank number. The other part might be in little endian. 6151A3?
War is Peace. Freedom is Slavery. Ignorance is Strength.

Xardas

  • Jr. Member
  • **
  • Posts: 12
    • View Profile
Re: Small Orientation issues with SNES ROM Maps
« Reply #2 on: January 07, 2017, 03:44:05 am »
I think a bank is 8000 hex bytes. Also, the ROM map might not be 100% complete. It probably just has whatever the user who uploaded it could identify.
"Complete" might not have been the correct wording for what I meant. But what I meant is also wrong, so we don't need to discuss that further.  ;)
But I don't think it's 8000. The ROM map always lists a bank from 0000 to FFFF, which is 65536.
Quote
I'm not 100% sure but I think C1 is the bank number. The other part might be in little endian. 6151A3?
C1 is the bank number, I already figured that one out. But here is what I don't get: how did you turn C1/A3D1 into 6151A3?

SunGodPortal

  • Hero Member
  • *****
  • Posts: 2921
  • 2 + 2 = 5
    • View Profile
Re: Small Orientation issues with SNES ROM Maps
« Reply #3 on: January 07, 2017, 03:57:52 am »
But I don't think it's 8000. The ROM map always lists a bank from 0000 to FFFF, which is 65536.C1 is the bank number, I already figured that one out. But here is what I don't get: how did you turn C1/A3D1 into 6151A3?

Well, I'm actually not so sure that I was right now since I'm not used to dealing with this type of address, but I took C1 (which I assumed to be the bank number) and multiplied it by 8000 (with my calculator in hex mode the whole time) which amounted to 608000. Since I think this stuff is usually in little endian I then took the A3D1, switched it around to D1A3 and then added that to 608000 (which assumes there is no header, otherwise you would add 200 unless you are using it in some code, in which case you would ignore the additional bytes for the header).

Sorry, I probably only made things worse. LOL Perhaps someone more knowledgeable will show up.
War is Peace. Freedom is Slavery. Ignorance is Strength.

Disch

  • Hero Member
  • *****
  • Posts: 2730
  • NES Junkie
    • View Profile
Re: Small Orientation issues with SNES ROM Maps
« Reply #4 on: January 07, 2017, 04:13:15 am »
This depends if this is "LoROM" or "HiROM".  Banks are 32K ($8000) on the former, and 64K ($10000) on the latter.

If LoROM:  ((bank_number AND $7F) * $8000) OR (address AND $7FFF)
Code: [Select]
(($C1 AND $7F) * $8000) OR ($A3D1 AND $7FFF)
= (   ($41) * $8000)  OR ($23D1)
= $208000  OR  $23D1
= $20A3D1

If HiROM:  ((bank_number AND $3F) * $10000) OR (address)
Code: [Select]
(($C1 AND $3F) * $10000) OR $A3D1
= ($01 * $10000) OR $A3D1
= $10000 OR $A3D1
$1A3D1

Add $200 if there's a header.

IIRC, the FF games are all HiROM, but double check.  (EDIT:  just checked, and FF5 is definitely HiROM.  $C1/A3D1 corresponds to file offset 0x1A3D1, I'm sure of it)


Endianess probably does not apply to this, but I suppose it depends where he got that "C1/A3D1" address from.  I'm assuming it come from a debugger or document, in which case no byte swapping should be necessary.

Xardas

  • Jr. Member
  • **
  • Posts: 12
    • View Profile
Re: Small Orientation issues with SNES ROM Maps
« Reply #5 on: January 07, 2017, 04:46:54 am »
So C0 really is the first bank. Not that it is important, but I would like to know why they start with C.
I think I got it now. Just for verification, E3/4000 would correspondent to 2x34000, right?
C1/A3D1 was just an example, just like E3/4000.

EDIT:
I tried it, and everything is fine now. Thank you Disch for your explanation. And thanky you SunGodPortal too for trying ^^.
« Last Edit: January 07, 2017, 06:01:16 am by Xardas »

SunGodPortal

  • Hero Member
  • *****
  • Posts: 2921
  • 2 + 2 = 5
    • View Profile
Re: Small Orientation issues with SNES ROM Maps
« Reply #6 on: January 07, 2017, 05:00:01 am »
Quote
This depends if this is "LoROM" or "HiROM".  Banks are 32K ($8000) on the former, and 64K ($10000) on the latter.

Good to know. I assumed they were all 8000 because that's what I was used to seeing in A Link to the Past (LoROM), which is the only SNES game so far that I've delved that far into.

Quote
Endianess probably does not apply to this, but I suppose it depends where he got that "C1/A3D1" address from.  I'm assuming it come from a debugger or document, in which case no byte swapping should be necessary.

Because of the way it was written I assumed it came from a disassembly or something. That's what lead me to byte swapping. I guess I was thinking of it like a pointer or something. Whoops.
War is Peace. Freedom is Slavery. Ignorance is Strength.

Disch

  • Hero Member
  • *****
  • Posts: 2730
  • NES Junkie
    • View Profile
Re: Small Orientation issues with SNES ROM Maps
« Reply #7 on: January 07, 2017, 01:19:11 pm »
So C0 really is the first bank. Not that it is important, but I would like to know why they start with C.

On the cartridge, the A23 pin (the one that controls the $80 bit of the bank) basically goes nowhere, meaning that banks $00-7F effectively mirror $80-FF as far as the cartridge is concerned.  In fact I'm not even sure A23 is connected to the cartridge at all.  It might not be... I'd have to check a pinout.  Regardless, it doesn't really matter.

(EDIT again:  yes it looks like all A pins connect to the cartridge.  Though the doc I found calls the bank lines BA0-BA7 instead of A16-A23:  https://www.caitsith2.com/snes/flashcart/cart-chip-pinouts.html  )

However, on the SNES side, A23 allows for FastROM to be enabled.  So memory accesses to banks $80+ can be performed faster than memory accesses to banks $7F- (assuming the ROM is fast enough, and assuming FastROM is enabled).  So basically, there's little reason to not default to banks $80+ since FastROM can be software controlled.

As for A22 (the $40 bit), that needs to be set for HiROM because memory accesses only go to the cartridge if either A22 or A15 are high.  Meaning $80/0000 doesn't go to the cartridge because both A22 and A15 are low... however $C0/0000 does because A22 is high.

Examples:

banks $00-3F = slow, only upper half of bank goes to cartridge
banks $40-7F = slow, full bank goes to cartridge
banks $80-BF = fast, only upper half of bank goes to cartridge
banks $C0-FF = fast, full bank goes to cartridge.


So yeah -- HiROM games will generally use banks $C0+ because there is little reason not to.

EDIT 2:  Also WRAM hijacks banks $7E/7F, so you have 2 more banks in the $C0-FF range than you would in the $40-7F range.

Code: [Select]
I think I got it now. Just for verification, E3/4000 would correspondent to 2x34000, right?
$E3 & $3F = $23

So 0x234000, yes.

(the '0x' prefix on numbers just means the number is in hexadecimal.  It's the same as the '$' prefix.  I typically use '0x' specifically for file offsets and '$' for addresses to differentiate them, but they mean the exact the same thing)


EDIT:  whoops, A15, not A21.  Sorry just woke up.
« Last Edit: January 07, 2017, 02:08:00 pm by Disch »