nesdev.org

I've been trying to get into the SNES dev scene, and have found:

Neviksti's starter kit, which uses WLA and isn't very organized. People don't seem to like it. I converted it to CA65, but am still not a fan.

Tepples' tutorial, which is very over complicated.

And uh. That's it. So what am I missing here, if anything? This doesn't seem like a very nice introduction to the 16-bit dev scene, and I'd like to stick around but there's no tutorials or anything that I can really follow.

Starting is as bad as you'd think... I started with Walker, did stuff to it, caused some bug that made it flip out so Koitsu converted what I did up to that point to ca65 and then I did more stuff to it. I guess if you want, I can give you what I've done so far and you can go backwards with it? (Or, you know, I can take features away instead of you doing so.)

The tutorials I used were bazz's tutorials (which unfortunately use WLA) and I also asked 101 questions here to get me where I am now. I'm sure you already know about this website, but here it is: http://wiki.superfamicom.org/snes/show/HomePage

I'm just saying, I hope you have better patience than I do...

nicklausw wrote:Tepples' tutorial, which is very over complicated.

I'm willing to fix any too-steep gradient. What's the first thing you had trouble understanding?

The first problem I had was kind of my own problem: the makefile. It assumed a lot of programs that I don't have, and this might just be because I'm on Windows, but I needed to actually type in "python" before all the .py files to get them to run. Make knew to use python to open them, but kept trying with "env python" which uh...didn't work. It's fine now, but felt like some sort of rude awakening.

I've gotten the thing to build and taken out all APU stuff (don't care just yet,) so we'll see where this goes.

Looking through main...

line 17. X? What? I get the size bit thing, but have no idea what X is.

line 60. What's the deal with the shift 13 bytes or whatever that is?


What exactly is pseudo hi-res, and why is it optional? Same with interlace. Is this explained somewhere else?

The rest of that file kinda makes sense. I should probably just PM questions and suggestions for the rest of them.

Someone posted this link recently...
https://github.com/undisbeliever?tab=repositories

I haven't looked closely at everything, but they appear to be a dozen small games written for SNES.

nicklausw wrote:The first problem I had was kind of my own problem: the makefile. It assumed a lot of programs that I don't have

What did it assume beyond MSYS and Python? Are you using Cygwin Make, MSYS Make, or mingw32-make? Fixing the instructions to install dependencies still counts as fixing the tutorial. I guess I'm just spoiled on Debian derivatives, where sudo apt-get install python-imaging build-essential and then building the cc65 toolchain from source gives everything you need.

Make knew to use python to open them, but kept trying with "env python" which uh...didn't work.

What env does, as explained in answers to TheGeeko61's question, is let the shebang line (#!/path/to/program) processor search the PATH for the Python interpreter rather than hardcoding an install location. I was sure env came with MSYS. (Does it?)

X? What? I get the size bit thing, but have no idea what X is.

I'm sorry; I just assumed that anybody who has studied computer graphics would have known what an X coordinate was.

What's the deal with the shift 13 bytes or whatever that is?

The sprite pattern table starts $4000 words from the start of video memory. But the OBSEL register needs the address of the sprite pattern table to be given in $2000-word units, and the right shift by 13 bits divides the address by $2000.

What exactly is pseudo hi-res, and why is it optional? Same with interlace. Is this explained somewhere else?

Features that the demo doesn't really use, but you can turn on when building the demo to see what they do. Both are explained in the list of MMIO ports on wiki.superfamicom.org.

tepples wrote:What did it assume beyond MSYS and Python? Are you using Cygwin Make, MSYS Make, or mingw32-make?

I'm using mingw32-make. The programs assumed were sed (had to copy from cygwin to C:\Windows,) pwd (had to make a batch file under C:\Windows,) and bsnes and something else. Should I be using something other than the command line? Cygwin broke in half when trying to use the makefile, so.

tepples wrote:What env does, as explained in answers to TheGeeko61's question, is let the shebang line (#!/path/to/program) processor search the PATH for the Python interpreter rather than hardcoding an install location. I was sure env came with MSYS. (Does it?)

The MSYS shell...uh...maybe I shoulda thought of that. Don't seem to have it, though...

tepples wrote:I'm sorry; I just assumed that anybody who has studied computer graphics would have known what an X coordinate was.

The sarcasm, man, it hurts. I see what you mean now though.

tepples wrote:The sprite pattern table starts $4000 words from the start of video memory. But the OBSEL register needs the address of the sprite pattern table to be given in $2000-word units, and the right shift by 13 bits divides the address by $2000.

So this could be done with lda #$4000/$2000?

tepples wrote:Features that the demo doesn't really use, but you can turn on when building the demo to see what they do. Both are explained in the list of MMIO ports on wiki.superfamicom.org.

Fair enough.

Update: the MSYS shell (which I do in fact have apparently) handles all the Unix problems.

nicklausw wrote:

tepples wrote:What did it assume beyond MSYS and Python? Are you using Cygwin Make, MSYS Make, or mingw32-make?

I'm using mingw32-make. The programs assumed were sed, pwd, and bsnes and something else.

The sed and pwd are needed for use of NO$SNS in Wine. Most Windows programs accept paths with either forward slashes or backslashes, and most Windows programs accept paths relative to the current directory. This means I can easily run them in Wine from a UNIX makefile. But the command line parsing in Martin Korth's NO$SNS emulator is quirky in that it requires an absolute path to the ROM, not a path relative to the current working directory. So it needs to use pwd to retrieve the name of the directory where the makefile resides and sed to convert it from a UNIX path, with forward slashes and no drive letter, to a Windows path, with backslashes and a drive letter, suitable to pass to NO$SNS filenames to be passed on the command line. They shouldn't be needed for an emulator that has more sane command line processing, such as bsnes. That's why I made EMU a variable, so that the user of the makefile could customize the choice of emulator. The big reason I use NO$SNS at all is that it's the only debugging emulator I know of that runs full-speed on my Dell Inspiron mini 1012 laptop's Atom CPU.

Should I be using something other than the command line? Cygwin broke in half when trying to use the makefile, so.

As you ended up discovering while ninjaing this very post, MSYS is lighter weight than Cygwin but still provides enough of GNU Coreutils to run typical makefiles. From README.md:

1. Visit devkitPro Getting Started.
2. Follow the instructions there to download and run the devkitPro Automated Installer.
3. In the installer, check only MSYS.

Is there a way I could have made it even clearer that yes, Windows users should be using MSYS?

tepples wrote:The sprite pattern table starts $4000 words from the start of video memory. But the OBSEL register needs the address of the sprite pattern table to be given in $2000-word units, and the right shift by 13 bits divides the address by $2000.

So this could be done with lda #$4000/$2000?

Yes it could. But at the time, I thought it might confuse people who aren't accustomed to seeing division in assembly language. They might think it's some sort of other separator, much as the Apple IIGS Monitor (aka CALL -151) separates the bank (A23-A16) from the rest of the address (A15-A0) with a slash. The >> 13 emphasizes that bits 14 and 13 of the address are going into bits 1 and 0 of OBSEL. Or I could add a comment near every bit shift in a similar context that "Alternatively, this could be interpreted as a division by whatever"; would that make things clearer?

Ya got me, I didn't look very well through the readme. Sorry about that.

Yes it could. But a lot of people aren't accustomed to seeing division in assembly language; they might think it's some sort of other separator. The >> 13 emphasizes that bits 14 and 13 of the address are going into bits 1 and 0 of OBSEL. Or I could add a comment near every bit shift in a similar context that "Alternatively, this could be interpreted as a division by whatever"; would that make things clearer?

That's a very odd thing to assume that people would know. A comment would certainly help, as without it, I doubt many people would know what's going on.

Thanks for the feedback. I've added comments to those places in the tree that will become 0.06.

Out of curiosity, why don't you have the template up on GitHub or some other git client? Feels like changes would be a lot easier to manage that way, and feedback would be less tedious to give. (imo, that is).

Because then I'd have to set aside a few hours to learn how to Git.

tepples wrote:Because then I'd have to set aside a few hours to learn how to Git.

Ah, I see. Git wasn't drastic to figure out for me, just the weird terminology had me caught up for a while. Yeah, though, if you lack time then maybe stick to what you're doing.