Id like to learn about the snes

[magno]

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

In fact, you can take advantage of this for faster and simplier register initialization, changing DP=$2100 and writing to all register space with direct page addressing mode.

As for mode 20 vs mode 21 discussion, everybody would have his own opinion, but I'm currently programming an RPG game for SNES and I prefer Mode 21 (HiROM). Thanks to the bigger size in each bank, I'm been able to code all command-script routines in the same bank, which is really faster and more compact size than splitting 41Kbytes of code into 2 banks: if I would have decided to use mode 20, I would have had to call all routines with JSL (which is slower and longer) and wouldn't have been able to use BRA branching, not to mention I would have had to decide what to do with the spare 23Kbytes in the second bank, which is too small for other game engines (tasking engine is about 30 Kbytes) and too small for graphics. You can see the same problem in Treasure Hunter G, where the code is too dispersed all over the first 20 banks, mixed up with some data.

[infidelity]

Wow so much information!

So does the snes scene have anything close to a debugger like FCEUX has? I'd like to he able to view the snes's ram registers with a hex editor, and edit them via hex, and id like to edit the games rom from within a hex editor. Any info on the most up to date/sophisticated debugger for the snes would be great!

[tepples]

There's bsnes classic and no$sns. I'm looking for one myself, so other suggestions would be appreciated.

[koitsu]

1. bsnes/higan -- no idea what the state of the debugger here is because I have qualms with the whole "file format" crusade thing (please do not discuss this here, it's outside of the topic; I'm just explaining why I have no experience with the debugger).

2. no$sns -- used it a few times alongside Geiger's SNES9x debugger, but I tend to just go with Geiger's.

3. Geiger's SNES9x debugger -- this is what I commonly use, but realise that the SNES9x engine/emulation part is significantly outdated compared to the unofficially maintained SNES9x (source). So just be aware of that.

4. ZSNES when launched with the -d flag -- quite awful, if you ask me, but on very rare occasion (depends on what you're trying to do) can be handy (docs).

Those are the ones I know of, but maybe one of these will be better. Heck if I know.

If you're on OS X, I wish you luck -- you might as well launch a VM with Windows and pray that whatever emulator you run supports GDI+ rendering and just turn audio off.

[ARM9]

1. bsnes/higan -- no idea what the state of the debugger here is because I have qualms with the whole "file format" crusade thing (please do not discuss this here, it's outside of the topic; I'm just explaining why I have no experience with the debugger).

If you're on OS X, I wish you luck -- you might as well launch a VM with Windows and pray that whatever emulator you run supports GDI+ rendering and just turn audio off.

The good thing about bsnes-classic is that it's got none of the higan Emulation folder stuff, so if that was the only thing holding you back then I recommend trying it. I think you should be able to build and run bsnes-classic on OS X as well.

[tepples]

and just turn audio off.

Please help me understand how this doesn't defeat the purpose when trying to debug SPC700.

[koitsu]

and just turn audio off.

Please help me understand how this doesn't defeat the purpose when trying to debug SPC700.

Up until your post, there was no mention of the terms "SPC", "music", or "sound". And given the present subject matter I think SPC700 might be a bit much for the OP to grasp right now. (Audio is always it's own beast...)

To clarify my original point though: audio emulation/translation under a VM, even an HVM hypervisor, has always been crappy in my experience: high latencies, samples that don't play all the way through (e.g. sound layer is clipping playback early), mixer/volume issues (as in clipping), and a multitude of other things. Given how sensitive emulators are to audio playback frequency and latency (see the bajillion of threads discussing all of this), I'm of the strong opinion it's best to do the audio bits natively on something (i.e. use an emulator on your native OS, not under a VM -- or better yet actual NES/FC hardware). OS X people don't have as many choices as Win32 people do.

That's all I was trying to get across.

[infidelity]

Ok I've got a question regarding the ppu.

I know on the nes, the ppu has registers...

$0-$FFF ;sprite tiles
$1000-$1FFF ;BG tiles
$2000-$23FF ;nametable 1 w/16x16 palette attribute
$2400-$27FF ;nametable 2 w/16x16 palette attribute
$2800-$2BFF ;nametable 3 w/16x16 palette attribute
$2C00-$2FFF ;nametable 4 w/16x16 palette attribute
$3F00-$3F0F ; BG palettes
$3F10-$3F1F ;sprite palettes

What is the snes equivalent to what I just described from the nes?

And, is there chr-ram or chr-rom for gfx, or is it an entirely different concept where gfx are stored and loaded within the snes?

[tepples]

Super NES has CHR RAM.

The palette on the Super NES is in a separate address space accessed through a separate set of ports, in much the same way that OAM is separate from video memory on the NES and Super NES.


EDIT: clearer term

[koitsu]

And to be clear: what you listed off aren't registers, they're PPU memory ranges/memory addresses. They aren't accessible natively by the CPU, i.e. you cannot do something like sta $3f10 and write to part of the sprite palette.

You have to access the PPU through memory-mapped I/O registers (on the NES things like $2000/2005/2006/2007, on the SNES $2116/2117/2118/2119 (including if you choose to use its DMA capabilities ($42xx)). Like on the NES, you have to select what PPU address you want to write to using $2006, then use $2007 to write the actual byte/data to it. They're called "memory-mapped" because they are addresses within the CPU addressing space that can let you access addressing spaces outside of the CPU -- "memory-mapped" = "what the CPU can access/read from/write to natively".

And these are different from actual CPU registers. Yes, the word "register" is used differently/contextually and that's often confusing, but know that up front. And if someone uses the term "register" to you, and they don't give you good context? Call them out on it / ask them to clarify.

[tepples]

I've tended to use "port" to refer to NES $200x and $40xx and Super NES $21xx and $43xx because that's what they are: MMIO ports.

[koitsu]

That's a good term to use, tepples. I always forget about the "port" phrase because it makes me think of classic ISA ports (ex. 0x378) on x86 and the in/out opcodes. But yeah, that's a good one.

[Sik]

I never saw the term register being used for address ranges though, it was always a synonym of port to me (well, when it comes to access through memory, registers and ports are different with a control/data port model).

[tomaitheous]

Yeah, I wouldn't label a range of memory 'registers' either, unless they are specifically memory mapped registers, and at that - only in the context of talking about the device. To access register 'x' (of the device), write to port/address 'whatever'. For memory ranges, inside or outside a device, that are specifically for certain types of data or sets of data - I'd never refer to them as registers. Best to correct that now, so you don't get someone confused when trying to talk about such stuffs. But yeah, nametables, memory for holding graphic cells, attributes, etc I don't think could even be considered registers in the traditional sense.

If a memory mapped register is specific to an action (you read it for status, or you write to change functionality - and it directly corresponds to a 'register' on the device), then I usually refer to it as a register. I.e. "Read the PPU status register".

Slightly off topic, but I sometimes refer to ZP/DP area of memory as address registers. They're actually indirect address vectors, but that's what address registers do on other processors. But I usually only do this in the context of the name I've chosen to reserve in that ZP/DP area for indirect addressing (I usually name them something like A0, A1, A2, or R0, R1, R2, etc).

[infidelity]

@koitsu: oh I know all about $2006/7 with the nes, I assumed listing those addresses and their correct usage would suffice in my showing I know how to use/understand them. I'll be more careful in the future, lol. But thank you for clarifying the proper terminology to me.

I've been messing with Geiger's debugger, it has (imo) the best hex viewer for the snes, especially ram, I can watch it in real time. Anyway, I was screwing with the vram in hex during Megaman X, and noticed that the highway intro level uses 2 backgrounds, I started messing with tiles at $A000, the closest to the screen, and $B000, the furthest from the screen. I was randomly overwriting the tiles, and noticed that megaman appeared behind the tiles I was drawing. I noticed that an individual tile has 16bits/2bytes of properties. So does this mean tiles have a BG setting for sprites, making them appear infront/behind tiles?