Hex noob question

[1RX]

Hi, I've been trying to understand hexadecimal banking and addressing but every info I find is too basic or too advanced.

I just want to know how to calculate the real physical addresses given the "bank-bank:address-address" notation.

for example:

Bank Address Usage
00-7F 8000-FFFF ROM
70-7F 0000-7FFF RAM
80-FF 8000-FFFF ROM (MIRROR)
F0-FF 0000-7FFF RAM (MIRROR)


It seems that every snes document I find has this notation and I cannot understand it.

another example:

(from a mad-1 doc I was reading...)

addresses that fit this:
($20-$3F):(6000-7FFF)
($20-$3F):(E000-FFFF)
($A0-$BF):(6000-7FFF)
($A0-$BF):(E000-FFFF)

Again, I know this is "from here to here" notation but cannot understand how to get the physical address...

At first I thought it was like this:

40-7D 0000-FFFF
00-3F 8000-FFFF

(my guessing) physical addresses:

400000 -> 7DFFFF
008000 -> 3FFFFF

but then I saw:
(from the same mad-1 doc)

40:0000-7FFF <--- ROM 200000-207FFF
41:0000-7FFF <--- ROM 208000-20FFFF
43:8000-FFFF <--- ROM 218000-21FFFF

so I know it is not like that.

I don't know how noob this might be, but I want to learn this, so any help is much appreciated.

[Bregalad]

From what I understand,

00-7F 8000-FFFF ROM

means that ROM lies at :
$008000 - $00fff, $018000 - $01fff, $028000 - $02fff and so on.

This may seem a bit weird because the ROM is "exploded" into non-contiguous 32kb banks instead of being continuous. I don't really know why they did that, but apparently HiROM fixed that problem.

[koitsu]

What Bregalad said is correct.

It would probably help you to actually look at a visual depiction of the SNES memory map (and it varies depending upon mode (mode 20 vs. mode 21)). I urge you to get this (contains 2 PDFs) and look at pages 2-21-2 to 2-21-5. Pages 1-2-24 to 1-2-35 may also interest you, but I'd recommend sticking with 2-21-2 to 2-21-5 (to a programmer/developer they're more useful).

Also, I do not understand what you mean by "physical address" -- there is no "virtual" memory addressing like on the x86. The memory model of the 65816 is linear and very easy to understand. Just think of the bank + address as a 24-bit value, e.g. "bank $7f, address $1234" is $7f1234. And rollover is linear as well, as I said, e.g. $7ffffe, $7fffff, $800000, $800001, etc...

If the term "mirror" or "shadow" confuses you and you need that explained to you, just ask.

As for Breglad's ponderings over mode 20 and why it "masks (chops) off" the lower $0000-7ffff portion of banks $00-7d and banks $80-ff -- that almost certainly has to do with being "NES compatible", where the console was released with features that allowed developers familiar with the NES (where PRG is generally limited to $8000-ffff) to migrate over to the SNES with a bit more ease. There are other features on the SNES that indicate this as well (e.g. registers $4016 and $4017 -- see page 2-28-9). That's just the reality of the system, no sense in getting OCD about it. :-) There are more important things to worry about. If it bothers you, just use mode 21 and rely on $c00000-$ffffff.

[tepples]

Also, I do not understand what you mean by "physical address" -- there is no "virtual" memory addressing like on the x86.

Physical address in this case appears to mean the address as seen by the PRG ROM, or (in the case of an emulator) the address within the headerless .sfc file.

As for Breglad's ponderings over mode 20 and why it "masks (chops) off" the lower $0000-7ffff portion of banks $00-7d and banks $80-ff -- that almost certainly has to do with being "NES compatible"

There are two kinds of address in the operand of a 6502 instruction.

• Direct: 8-bit offset within $0000-$00FF.
• Absolute: 16-bit offset from $0000.

There are three kinds of address in the operand of a 65816 instruction.

• Direct: 8-bit offset from the frame pointer (D, corresponding to x86 BP) or stack pointer (S, corresponding to x86 SP).
• Absolute: 16-bit offset from the start of the bank (B, corresponding to x86 DS).
• Absolute long: 24-bit "far" address.

The Super NES mirrors the I/O registers ($21xx and $43xx) and the first 8192 bytes of work RAM ($0000-$1FFF) in banks $00-$3F and banks $80-$BF. This brings the registers and the start of RAM within the range of an absolute address no matter what B is set to. Having some of RAM always available can prove useful even without the attempt at partial source compatibility with the NES.

[1RX]

Also, I do not understand what you mean by "physical address" -- there is no "virtual" memory addressing like on the x86.

Hi again, thank you all for the quick replys!!

I'm reading the manual Koitsu provided and it seems I could get to understand this subject after all

I was reading a ppt presentation, and the term "physical address" was supposed to be the address that could be seen in an hexadecimal editor. My noob hexadecimal skills betray me

This whole thing is about something I read some time ago about SNES cartmodding, specifically about building a 96Mbit Star Ocean....

I wanted to understand the mechanism to split the file given the hexadecimal addresses in the format I commented in the first post.

it says:

ROM 3(00-3F/80-BF:8000-FFFF)
ROM 1(C0-FF:0000-FFFF)
ROM 2(40-7D:0000-FFFF)

I've been making some nice snes romhacks and rom translations into real cartridges and this caught my attention, but untill today this is beyond my knowledge.

[koitsu]

While everything you said is correct, Tepples, the argument for keeping $xx0000-xx7fff "reserved" for things like RAM/etc. (so in 65816 you don't have to use long addressing modes, e.g. STA $002100 and can instead just do STA $2100) is questionable once you look at the memory map a bit more closely.

Mode 20 has $0000-1fff available (including mirroring) for RAM/registers through banks $00-3f and $80-8f. However, the ROM (PRG) (despite being in $8000-ffff only) spans across more than just those banks: it spans banks $00-7d. Banks $40-5f don't contain the RAM mapping, and banks $60-6f also don't contain the RAM mapping (for carts with DSPs), and finally banks $70-7d use $0000-7fff for SRAM. It's fairly obvious that this was a design choice on the part of Nintendo, where someone decided that mode 20 games would only go up to 24mbit in size (in other words: that 24mbit "choice" explains why didn't they mirror the RAM/registers in banks $40-5f) -- though to be fair, I only remember seeing mode 20 games reaching up to 16mbit anyway, where anything larger was always mode 21. (I would not be surprised if there were some mode 20 games larger than 16mbit though)

Likewise, with mode 21, I find it interesting that only the upper half ($xx0000-xx7ffff) of the ROM from banks $c0-ff is mirrored into banks $00-7d.

Then there's the fact that the mirroring "cuts off" 128KB early (at bank $7d, rather than $7f) due to someone deciding to place the extra 128KB of RAM in banks $7e-7f. (I never will understand why they did that -- right in the smack dab middle of the addressing range, what the heck).

Then there's the whole high speed vs. normal speed complexity as well.

Just see the screenshots.

And I won't even talk about mode 25 -- and equally disgusting and horrible mess (it makes mode 20 look like a walk in the park).

I would have gone with this memory layout, quite honestly:

Code: Select all

$000000-001fff -- RAM (8KB)
$002000-005000 -- registers
$008000-00ffff -- mirror of $058000-05ffff (needed for IRQ/NMI/RESET/ABORT/COP vectors)
$010000-02ffff -- RAM (128KB)
$030000-04ffff -- DSP
$050000-ffffff -- ROM

It has all the same "gotchas" as the other modes but with a linear memory layout, and would allow for games exceeding that of 64mbit as well (slightly under 128mbit). The only catch would be high speed mode, which I'd have solved by mirroring banks $05-7f to banks $85-ff (for high speed). This would mean the maximum ROM size you'd be able to use for high speed mode is 64mbit, but hey, that's already the maximum limit on the SNES without a mapper, and you'd get a linear memory layout. And I refuse to believe power-of-2-alignment is needed here because the existing memory models stick the 128K work RAM region at bank $7e. :P

(2018/08/29 Edit: attachments removed.)

[koitsu]

Also, I do not understand what you mean by "physical address" -- there is no "virtual" memory addressing like on the x86.

I was reading a ppt presentation, and the term "physical address" was supposed to be the address that could be seen in an hexadecimal editor. My noob hexadecimal skills betray me :mrgreen:

This whole thing is about something I read some time ago about SNES cartmodding, specifically about building a 96Mbit Star Ocean....

I wanted to understand the mechanism to split the file given the hexadecimal addresses in the format I commented in the first post.

it says:

ROM 3(00-3F/80-BF:8000-FFFF)
ROM 1(C0-FF:0000-FFFF)
ROM 2(40-7D:0000-FFFF)

I've been making some nice snes romhacks and rom translations into real cartridges and this caught my attention, but untill today this is beyond my knowledge.

You keep saying "hexadecimal editor", which means you're talking about file offsets. The fact they're shown in decimal or hexadecimal has no bearing.

What Bregalad, Tepples, and myself are talking about is the actual memory map of the SNES/SFC itself, meaning "where in memory" all of the portions of the ROM file "get loaded" before starting the game (for tech readers: I'm intentionally wording this badly/slightly inaccurately so the OP can understand).

Essentially what you're needing is to make a file-offset-to-memory-map chart/table so you know what portion of the file "gets loaded" where.

Before anyone can give you any kind of advice, we need to know what exact game it is you're working on, and if you could provide a link to the ROM image (this would be best, then those of us familiar with the console can look at it and tell you -- please do not upload the ROM to the board, I will delete the attachment if you do this). The "mode" we're talking about (mode 20, 21, etc.) is what ultimately defines the memory model/layout, and that "mode" is both stored in the ROM image (in the cartridge header) as well as often hard-wired on the cartridge itself. It varies per game, so to tell you "file offset abc to xyz maps to memory $xxyyyy" we need this information.

Finally: a 96mbit Star Ocean cart would have to contain a memory mapper, which is a physical chip on the cartridge itself that would allow the SNES to exceed the existing addressing size limitations (meaning no more 32mbit (or 64mbit if using mode 25) limit). You're walking into something that's extremely complex if that's the game you're working on, and I would strongly suggest you take a step back and work on a game that's 16mbit or less to get started/learn the ropes. There are only a couple games that I know of which use mappers on the SNES, while on the NES this is incredibly common (since the memory layout is limited to 32KBytes).

[1RX]

Hello, thanks for the detailed explanation.

The thread about 96 Mbit Star ocean is here:

viewtopic.php?f=12&t=4380&start=15

A normal ROM of Star ocean is compressed to 48Mbit to work with S-DD1.

The user Neviksti created an xdelta patch to expand the rom so it can be played on real hardware using a GF7 backup unit.

Theoretically an uncompressed Star ocean rom file wouldn't need any special hardware to work on a real cartridge and it seems that some people got it to work using 3 x 4MB memory like 29f032 and one 74LS139 decoder in a Hirom PCB with a MAD-1 decoder on it.

[3gengames]

Don't link to ROMS unless they're PD.

[Bregalad]

though to be fair, I only remember seeing mode 20 games reaching up to 16mbit anyway, where anything larger was always mode 21. (I would not be surprised if there were some mode 20 games larger than 16mbit though)

Tactics Ogre is LoRom (mode 20) and 24mbit. The weird thing is that the cartridge actually contains only a single ROM chip, probably it's a 32mbit chip with 8mbit of it being unused. That or the ROM I have on my PC is an overdump.

PS : I hope this is not yet another "please help me to make bootleg Star Ocean carts so I can sell them for very expensive on eBay" thread. For some reason Star Ocean, Earthbound and Final Fantasy 3 are very popular games for this kind of stuff ^^

[1RX]

PS : I hope this is not yet another "please help me to make bootleg Star Ocean carts so I can sell them for very expensive on eBay" thread. For some reason Star Ocean, Earthbound and Final Fantasy 3 are very popular games for this kind of stuff ^^

I know some times it is like that and some people get advantage of the good will of many users of this forum and the free information on the internet. I stated at the first post that I don't understand this and I'm new to romhacking, I asked about hexadecimal stuff because I want to understand something that seems basic but for some reason I cannot find any info that helps me to learn this.

[bazz]

40-7D 0000-FFFF
00-3F 8000-FFFF

(my guessing) physical addresses:

400000 -> 7DFFFF
008000 -> 3FFFFF

That's right actually

but then I saw:
(from the same mad-1 doc)

40:0000-7FFF <--- ROM 200000-207FFF
41:0000-7FFF <--- ROM 208000-20FFFF
43:8000-FFFF <--- ROM 218000-21FFFF

Actually, here's the difference.

The code on the actual black chip called a ROM. if the chip was alone, no SNES, there's memory on there from say $0000-$8000. then the SNES gets its hands on this black chip, and Memory Maps the ROM's $0000-$8000 to, SNES location 00:$8000-ffff | thus, SNES $00:8000-ffff == ROM $0000-8000. still the same $8000 block, just a different location. Continuing, the ROM's memory at $8000-$FFFF is actually mapped to SNES $01:8000-FFFF. That's actually what happens.


when it's memory mapped to SNES, the blocks get broken up, and so if you wanted to read the ROM in a continuous fashion from it being connected to a SNES cart, you would then have to be sure to read only $8000-$FFFF of each bank. since as we already clarified that is how the SNES breaks up ROM in the lower banks. ($00-$3f at the least)