SNES Splatoon (How do I shot HiROM?)

[Nicole]

$000000-$007fff is mirrored across every bank in $00-$3f and $80-$bf.

It doesn't even matter if you access them in the slow banks or the fast banks, because they always have the same access speed. (MEMSEL only affects ROM access speed.)

[tokumaru]

Espozo, I don't know much about SNES development, but from what I've been following of your thread(s), it does seem like you're not interested in studying how the SNES works so you can do things properly, you're instead randomly trying out things until you magically achieve the desired result. And it seems that once you get there, you don't even care why.

And it's also true that people have tried to explain the same things over and over, and there's a noticeable lack of interest on your part to make good use of that information.

Maybe you're too eager to get to the interesting part, but where has that gotten you so far? You seem to be stuck on things that prevent your program from even booting properly, am I correct? Don't you think maybe it's time to take a step back and grow a better understanding of the platform you're working on so you can make a program with a good foundation on top of which you can code a proper game?

[Drew Sebastino]

it does seem like you're not interested in studying how the SNES works so you can do things properly, you're instead randomly trying out things until you magically achieve the desired result.

I wasn't aware there was that much to it, until the more I found out. No one ever went to me and said "here, read this." In fact, I remember when I first tried the Nerdy Nights tutorial for the NES (I looked at the NES first) I thought I remember they just kind of threw you right into the middle of the action without really explaining how everything worked.

it seems that once you get there, you don't even care why.

there's a noticeable lack of interest on your part to make good use of that information.

I don't know what you're trying to say.

Maybe you're too eager to get to the interesting part, but where has that gotten you so far?

That makes more sense.

You seem to be stuck on things that prevent your program from even booting properly, am I correct?

Well, It's more like it did boot properly, and then I decided I'd do something else, not knowing the consequences for my actions, and then I screwed it up. The problem was me not knowing fundamental things like K and B, because I never learned about them.

I was new to programming before coming here, which is why I don't know basic stuff like that, but instead more SNES specific stuff(the "exciting" things) like how the video hardware works and how to interact with it. I feel like there should be some sort of guide for people like myself who had no programming experience prior to coming here to work on the SNES.

And no, the book does not count. That'd be a huge turn-off. I feel it's more of a reference than a guide. Maybe you could have a list that says what to learn about in there or something and what order to go. It could be like a school, except instead of a teacher, it's a guide, and it makes you refer to the SNES development manual at specific points. I don't know, I just never understand how anyone else got started here, but save nicklausw, I'm probably the youngest user.

[93143]

In my experience the SNES memory map is the hardest thing to understand about the system. Once you get it, everything else should be relatively easy. (Then again, I had about a decade of C++ and two of Matlab before I started this, so programming wasn't exactly new to me...)

This may not be helpful to you, but it makes sense to me:

I think the key thing to get is the arrangement of ROM areas* and system areas**. Basically, the first and third quarters of the memory map (banks $00-$3F and $80-$BF) are split between system areas in the bottom half and ROM areas in the top half. The system areas are identical in every bank; the ROM areas are not.

The second and fourth quarters of the map ($40-$7F and $C0-$FF) are all ROM, with the exception of $7E and $7F, which are WRAM. The bottom 8 KB of $7E ($0000-$1FFF) is mirrored in all of the system areas, so if your data bank register is anywhere in the first or third quarters of the memory map, you can access that RAM.

LoROM uses 32 KB banks so as to fit in the ROM areas in the first and third quarters (ie: the ROM banks show up in the upper halves of the corresponding SNES banks). HiROM uses 64 KB banks, meaning if a bank is accessed in the first or third quarter of the map, the bottom half is overridden by the system area; you need to access in the second or fourth quarter to be able to see all of the data. (And as you've found, the same is true of the program counter; you can't run code out of ROM below $8000 in the first or third quarter of the map.)

For small programs, it is exceedingly likely that ROM will be mirrored between $00+, $40+, $80+, and $C0+. This means that all four of those locations are identical from $8000-$FFFF in each bank. With LoROM, that corresponds to $0000-$7FFF in your ROM image, which is the whole bank (32 KB). With HiROM, it's $8000-$FFFF, meaning the bottom half of a bank is missing from $00+ and $80+, but it's there at $40+ and $C0+.


*"ROM areas" can also include stuff like SRAM, and can even be open bus. It depends on the cartridge.

**By "system area", I don't mean the cartridge isn't accessed. It certainly can be, and most (all?) special chips use reserved areas in that range. But beginners will generally use it for PPU access, DMA, IRQs, shadow RAM, multiply/divide... internal system stuff.

[Ramsis]

What's with all the passive aggressiveness?

It's not "passive aggressiveness", at least not from my part. Rather, it's active annoyanceness. (Yes, I'm perfectly aware that word doesn't even exist.)

I tried to play along, but you won't take a break.

*Yawn*

You "playing along" is just so entertaining ...

[tepples]

I feel like there should be some sort of guide for people like myself who had no programming experience prior to coming here to work on the SNES.

So some sort of "Easy 65816" counterpart to the Easy 6502 tutorial?

I just never understand how anyone else got started here, but save nicklausw, I'm probably the youngest user.

I was writing 6502 assembly on Apple II at age 14 if it counts.

[nicklausw]

Okay, this doesn't have much to do with the SNES, but on the subject of starting people off...

Maxim's tutorials don't assume much experience from what I remember. http://www.smspower.org/maxim/HowToProgram/Lesson1

I'm not saying we should start people off in the SNES scene with a tutorial for a Sega console with a Z80 processor, but the tutorial really starts from the basics so I think it'd be a nice basis for a set of tutorials designed for the SNES. You could even learn some from it as is, who knows.

[Nicole]

Here's a simplified, high-level look at the SNES's memory map.

Diagram

The top-left diagram shows the memory map as the SNES sees it, basically. The white areas are passed to the cartridge, and the SNES doesn't care about how exactly the cartridge maps ROM to that space.

The second row shows how the mappers for LoROM and HiROM map given addresses to ROM, and the last row shows the complete memory map.

There's ways this can become more complicated (which 93143 delved into), but it's probably best not to get into that right now.

[Drew Sebastino]

You "playing along" is just so entertaining ...

Until this happens: viewtopic.php?f=5&t=14081 I've found it's best to assume everyone on the internet is a complete stranger.

So some sort of "Easy 65816" counterpart to the Easy 6502 tutorial?

Possibly even "easier". I don't like how they go to "our first program" before even learning everything. It first gives you a false sense of confidence learning how to do something as easy as that, and then you find out you don't know squat later and it ends up hurting you more than anything. Maybe this is too basic to some people (he talks about learning hexadecimal at one point though) but I feel like it should start off as simple as learning what bits are. It seems right off the bat, he assumes you know how loading and storing values is really the basis of a computer program, which when I started, I had no clue how it worked. Maybe it should be like "if you understand what this means, skip this lesson." I don't know. I'm not a good teacher though, so I don't have a lot of room to talk.

I was writing 6502 assembly on Apple II at age 14 if it counts.

Wow... I just started looking over stuff when I was about that age. (I think that's when I first looked at "Nerdy Nights" for the NES.)

In my experience the SNES memory map is the hardest thing to understand about the system. Once you get it, everything else should be relatively easy.

And what makes no sense is that it simply doesn't appear to be taught. If I don't know what hexadecimal is, I sure as hell don't understand the concept of a memory map. I always assumed everything on the SNES was kind of somehow able to reach everything, as if something like "FrameCounter" would be the same in every bank, because I sort of though the SNES was running in a type of absolute addressing. The only difference in what I thought of "regular" addressing (I'm not sure what's the name for regular 16bit addressing, if there even is one) and absolute is that absolute addressing wasn't affected by direct page.

Basically, now knowing the SNES memory map (or even memory mapping in general) makes me realize how big of an idiot I was. That's the one thing I like about the prospect of machine code: If you don't know something, you know you don't know it, unlike me in assembly where I've been blissfully unaware of even basic concepts.

I think the key thing to get is the arrangement of ROM areas* and system areas**. Basically, the first and third quarters of the memory map (banks $00-$3F and $80-$BF) are split between system areas in the bottom half and ROM areas in the top half. The system areas are identical in every bank; the ROM areas are not.

Wait, so "sta $2100" is the same in banks $00-$3F as it is in banks $80-$BF? One thing I've noticed though is it looks like in the memory map I found, there's extra random junk near $8000 in banks $00-$0F, $30-$3F, and $80-$8F.

What exactly is open bus? is it just trying to access rom where there isn't any? I always wondered though, what happens if you try and access a hardware register that doesn't even exist, like $3000, for example. Or wait, is this space reserved for special chips, which in that case, it behaves just like if you're trying to load from rom that doesn't exist?

[Nicole]

"Open bus" means a place that isn't mapped to anything. AFAIK, what happens when you read from open bus is that you end up with whatever the last written/read byte anywhere was, even if it was a completely different location.

So, if you read $77 from ROM, then read from open bus, you'd just read $77 again. If you wrote $88 to RAM, then read from open bus, you'd read $88. If you wrote $99 to open bus, then read from open bus, I believe you'd read $99.

[tokumaru]

So, if you read $77 from ROM, then read from open bus, you'd just read $77 again. If you wrote $88 to RAM, then read from open bus, you'd read $88. If you wrote $99 to open bus, then read from open bus, I believe you'd read $99.

Actually, when code and data share the same bus, what you get when you read from open bus is the last byte of the instruction, because that's was the last thing on the bus, afer the instruction was completely fetched.

[Nicole]

Ah, that makes sense. In any case, you don't really need to worry about what exactly you get from reading open bus; just think of it as garbage data.

[tokumaru]

You generally shouldn't rely on open bus, but some games on the NES do. When you read from hardware registers that don't return information on all 8 bits, the unused bits return open bus. A couple of NES games are known to exploit this when reading the controllers, making comparisons that assume specific values in the unimplemented bits. This ended up breaking these games on the PowerPak, which for some electric reason I'm not capable of explaining, changes the open bus behavior. When making your own programs, you should definitely not rely on open bus, unless you wan to use it a type of copy protection (which is also done in at least one NES game), but even then you're risking breaking something on an obscure hardware revision or something.

[thefox]

unless you wan to use it a type of copy protection (which is also done in at least one NES game)

If you're referring to Low G Man, I really don't believe there has ever been any good proof that it was really done for copy protection. All cases of relying on open bus behavior that I've seen have been (I believe) due to bugs in code, or misunderstanding of the hardware.

[rainwarrior]

Low G Man is a bug, for sure.

The only thing I can think of is the modified CNROM, maybe?