SNES, where to start?

[bazz]

I'd like to elaborate why I think my tutorials are awesome -- when I started them, I had no idea about any Electrical Engineering. I had programmed in C, and learned z80 asm to get myself ready -- but still -- the tutorials come from the perspective of someone (me) who is thinking "WTF is all this shit" -- OH! this is what this is and how this works!! *check it out everyone -- this is how this works!! and you do this and THAT'S why it does THAT!!* hehe, and I think that style was well-received by people. A lot of people like me who saw the SNES and were so inspired by it, who wanted to program it, probably also had no prior EE experience - and to explain these things so practically as they were just learned by me I think was delightful.

Before I had written those tutorials -- there were mostly only register reference documents, and eventually a leaked Nintendo manual became more popularly circulated -- and memory map documents were there -- but it was extremely non-obvious how all that connected -- especially to someone with no EE / embedded programming experience. Anyone's best shot was to analyze the "starter kits" that had project files that connected all the dots -- and even THAT was insanely difficult.. My tutorials were a result of being so stubborn that I just kept analyzing those files and assembler documentation and memory map etc. until more things started making sense..

I eventually went on to get into hardware, making stuff like GB Flasher and my own SNES flash cart/programmer -- and let me tell you -- seeing how the hardware works puts EVERYTHING into perspective. (ie. Address bus / Data bus). Getting into SNES catapulted me into a future being able to work with embedded systems running on ARM chips - and now I can reverse engineer even modern systems! But I'm getting into my life story so I'll stop here.

[koitsu]

I more or less agree with bazz's sentiments and story, although I don't do "howtos/walkthroughs" -- I will be egocentric and say that I'm remarkably good about writing technical documentation (and not just for consoles), but I am not a good teacher. So it makes me happy to see someone who took the time to take care of the "teaching" part in a way people can understand.

On the flip side, in comparison to bazz, I have little to no interest in the EE/hardware side of things. While I get general concepts (address lines, data lines, and some other related bits), my eyes gloss over and I want to let out a resounding fart whenever deep/low-level hardware aspects comes into discussion; more specifically, the instant someone busts out a board/trace schematic or starts referencing address/data lines as if those somehow "magically answer the question" is when I get up and leave. In my experience, EE/hardware-focused people tend to give you one-liner answers or links to a schematic and don't really explain anything at the "programming" level.

Again, applying a bit of ego (I've just got out of a work meeting that went so-so, so pardon me for sounding brash): I am living proof that you DO NOT need to understand EE/hardware to work on video game consoles or embedded systems (I've done PIC, worked a bit with MIPS/ARM systems running Linux), or even other things such as storage subsystems (I love working with ATA protocol on MHDDs or SSDs -- and AHCI too -- for example). I am a very strong proponent/advocate of the fact that clear, concise, and well-written documentation for developers/programmers can alleviate 99% of the "need" of understanding EE/hardware. EE/hardware folks have their own docs that make sense to them, and many of them can understand the documentation that's the "next level up" -- but not all of us can understand EE/hardware documentation.

To be clear: I'm not arguing against bazz or saying "you're wrong" (he's not wrong!). I'm not saying understanding EE/hardware isn't helpful -- bazz is proof it's remarkably helpful, and that's totally awesome! -- but there are those of us who do not really care to get into that arena and prefer to work at the layer immediately above hardware (i.e. firmware and upwards). And for us, the solution is well-written documentation that presents information in such a way that both "newbies" and those familiar/skilled with similar tech can actually understand what's going on. So if you're one of those people like me, please don't feel alone or frustrated. :-)

Clear/concise and well-written documentation by someone who understands "how" to write technical documentation at that level goes a long, long way. A lot of the stuff I've seen on the superfamicom wiki (the technical references, not the howtos) makes me cringe (recent example), because it's almost like it was written by a single person who was thinking of/for themselves and not about the readers or their skill sets. And please, whoever reads this, don't respond with "it's a wiki, you have the power to fix it yourself" -- yeah, um, considering I already wrote documentation (not perfect but was way better than what we had at the time) of all this back in the 90s, I think that'd be kind of defeatist.

A short story which I feel proves this fact: from 1996 to 1997, I had absolutely no idea how the NES's graphics worked (specifically the attribute table and how it works "with" the pattern table to define colour of a pixel). I tried for almost a year to wrap my brain around it, and it just never "clicked". It wasn't until I had a roommate -- Mr. Snazz, co-author of our VeNES emulator, who also had no hardware background -- who (after he got graphics working) said "really? It's really easy, it's like this"" and explained it in a way that suddenly clicked (I actually jumped around the room with excitement after). And that is why in nestech.txt I wrote my description of the attribute table how I did (describing it in 3 different ways, alongside ASCII diagrams). Almost 20 years later, I still see people struggling with understanding how it works, and have gotten a lot of "oh my god, thank you, that makes so much sense!" notes privately when people got to that description.

Likewise, one of the best write-ups I've seen of the NES nametables and scrolling is this. While things like this begin to make me cringe (but that's also the nature of the PPU, I guess -- it isn't as simple as was once thought).

I could list several other examples of the same -- such as understanding how some of the design/aspects of the Apple II and Apple IIGS, which I got through both the Technical Reference tomes from Apple as well as through conversations with people who would describe stuff in such a way that it just clicked/made sense -- but that's superfluous I think.

[dougeff]

Might I respectfully suggest trying it out on an actual SNES?

Did anyone ever check this on SNES? I'm curious what is going on.

[koitsu]

Haven't gotten around to it yet. Will try to this weekend. I've added it to my never-ending todo list.

[koitsu]

Tried this out today. Compared results on actual console to that of BizHawk 1.11.6 (2016/03/07) ("BSNES Performance"), SNES9x w/ Debugger 1.51ep10r2, no$sns 1.5, and zsnes 1.51.

The results on emulators are all the same: white "5" near the upper left corner.

On an actual console, the white is more like a high-tone grey (so RGB-wise it looks something like $a0a0a0). Taking a picture of this won't help because it's NTSC and hue/brightness/colour etc. on my TV, plus on the camera, is going to affect the visual results. I can tell it's not white, though, because the SD2SNES boot-up screen uses a pitch white font.

So, odds are you do have a quirk/bug in your code which needs to be worked out. It's probably yellow on higan because of the randomisation of registers and memory contents as byuu describes, and it might be high-tone grey on an actual console (for me) because I'm using SD2SNES which obviously has to pre-initialise the SNES in several ways (including palette).

[Near]

It would be really useful to have a debugger feature that stores a flag to detect when registers/memory is read before being written to after power-on/reset to catch bugs like this. I think people would be stunned by just how often even commercial games do this.

Unfortunately, it seems like that would be a massive amount of work to add "modified" flags to every single register and volatile memory address. And a huge speed penalty to then check these bits every time a memory address is read. Not to mention a cache destroyer.

Memory randomization is the bare minimum I can do, really. The color should change every power cycle if that is indeed what's going on, though.

> In higan-accuracy, however, sometimes the number doesn't show up or shows up with a different color.

EDIT: okay, yeah. I guarantee it's something not being initialized properly. You really need to clear everything: all registers, all WRAM, VRAM, CGRAM, OAM, etc.

[Ramsis]

Hey, nicklausw, nice to hear you've got started on SNES development.

As for what to look for, what's supposed to happen in this: in the top left corner of the screen, the number '5' is drawn and is white.

Tried it on the PowerPak, where the number appears as expected, and on sd2snes. With the latter, the number is barely visible and almost looks like an outline (i.e. pixels seem to be missing).

So yeah, like others have pointed out, it's most likely a problem with inadequate system initialization.

[dougeff]

OK, I f'n solved it.

This fixes the problem...

I added this just before the infinite loop (before screen on)...

Code: Select all

lda #$30
  sta $2130
  stz $2131
  stz $2132
  stz $2133

So, the problem was...I'm an idiot. Higan does NOT reload the rom every time it's run. It keeps a copy of the rom, upon import, but you have to REIMPORT the rom if it is changed. The hour of testing I did the other day was a complete waste of time, because I was testing the exact same original rom over and over, and not the changed rom.

OK. I feel better now. Bright white '5' in Higan Accuracy.

[nicklausw]

Thanks, dougeff. I managed to 'port' over my message printing function from my NES hello world examples and now a message is printed onto the screen.

Now, my one question...

WHY DO THE NEVIKSTI TUTORIALS MAKE THIS LOOK LIKE SUCH A HUGE TASK!?

Seriously, it's having an init routine clear stuff, then some DMA transfers and setting variables and copying text to VRAM. Why did that tutorial have to be filled with so much bloat? Jeez...

In other news, I've been playing around with xkas-plus and bass (byuu's non-linker assemblers, the first of which forked by Revenant) and have decided that I'll just stick with ca65. They're nice and all, but are very hollow in features compared to other assemblers (even WLA) and the way code is parsed is very weird. I kinda liked bass, but it has no idea how to handle spaces, so.

[nicklausw]

There's also bass, xkas, and asar, for those who want to be able to move the direct page around.

How so? I can't seem to find this specific functionality in xkas-plus. Do you mean that it lets you subtract the higher bit?

[Revenant]

xkas(-plus) doesn't have any specific direct page functionality aside from being able to force 8-bit addresses for instructions that support them.

xkas and bass are both intended mainly for patching existing binaries, so I wouldn't really recommend them for writing anything from scratch (although I still sometimes do so myself out of habit).

[nicklausw]

I know xkas and bass are better for patches, I'm just playing with the idea of a SNES assembler with no linker phase. I kinda like it. Probably won't be doing any big switches, though.