nesdev.org

I ported my minimal functional NES program to the Super NES. What bad practices did I use this time? And feel free to point out unclear things in the source code; in a beginners' example like this, I guess I need to err on the side of overcommenting somewhat.

Basic example (LoROM 2 Mbit) (0.05, updated 2015-02-13)
Updates via Git at pinobatch/lorom-template

tepples, I hope this feedback isn't going to be taken the wrong way: I know what you're asking in terms of the help you want, but the package as it stands literally requires such incredibly high technical knowledge of both Linux and Microsoft Windows, as well as build systems and an awareness of what a make file is, and GNU indoctrination, that as it stands anyone that can interpret it would already be able to copy/paste/borrow from documentation and commercial games the necessary ingredients to initialize a system as simple as the SNES.

Please don't throw anything out, your readme just needs a lot more explanation on setting up the build environment you have created, what each external program piece is doing, what is what, where to get the pieces, what to type, and things of that nature.

You're a funny person with some really dry humor. But most code comments I see contain quips that are not actually helpful.
This would actually bring me to tears of frustration on a bad day: "echo Files produced by build tools go here, but caulk goes where?"

"; 16x16 makes it a shitload easier to draw a player sprite" :facepalm:

Who is your intended audience. Maybe even state that in the text file?


Let's run this down as a typical n00b:
**I use Visual Studio in School to make programs, and now I wanna program a Mario game on SNES (or something)**
I downloaded the zip package.
I double click on readme.txt
it tells me in the text to use something other than notepad.
fine now i have to actually extract the zip package to a folder.
I now open readme.txt with notepad++

I reach the sentence "Building this demo requires cc65 for the PRG ROM, and Python and Python Imaging Library for the CHR ROM."
I am slightly puzzled.
I google "cc65 for the PRG ROM" as that is what it requires.
first google result takes me to "https://github.com/cc65/cc65/blob/maste ... nes/crt0.s"
I am confused.
Go back to the readme file.
I read the sentence "You'll probably also need GNU Make and Coreutils, which Windows users can find in MSYS"
in MSYS?
"MSys accepts high-end technology challenges and delivers quality solutions for our clients operating in numerous domains. Our commitment to the clients' success made the clients to get a superior-level of confidence and partner with MSys"

---

Do I think the package you have is a very good start? Yes. Absolutely. A lot of work went into it.

Disclaimer: didn't download the ZIP.

whicker wrote:I double click on readme.txt
it tells me in the text to use something other than notepad.
fine now i have to actually extract the zip package to a folder.
I now open readme.txt with notepad++

I sure can't be the only one who's upset with Notepad being like the only text editor left that doesn't understand non-CRLF newlines, right? I mean, seriously, even freaking edit.com could understand them ._.'

whicker wrote:I reach the sentence "Building this demo requires cc65 for the PRG ROM, and Python and Python Imaging Library for the CHR ROM."
I am slightly puzzled.

I have the feeling this would be worse for somebody with a NES background (since the SNES does not have CHR-ROM, making the sentence actually misleading).

whicker wrote:I read the sentence "You'll probably also need GNU Make and Coreutils, which Windows users can find in MSYS"
in MSYS?
"MSys accepts high-end technology challenges and delivers quality solutions for our clients operating in numerous domains. Our commitment to the clients' success made the clients to get a superior-level of confidence and partner with MSys"

This is worse for a Code::Blocks user: it comes with MinGW but not MSYS, so users get confused as hell (worse, that also tends to make MinGW makefiles completely unusable since they expect you to use MSYS). Doesn't help that even today I still don't know where to get the MSYS prebuilt binaries and no way I'd waste time building them myself (these days I run Ubuntu anyway so I just use the crosscompiler with the native shell).

Oh yeah, also if it uses MinGW, hope it's vanilla and not MinGW-w64, because Code::Blocks includes the former...

whicker wrote:your readme just needs a lot more explanation on setting up the build environment you have created

Then let's get it started.

This would actually bring me to tears of frustration on a bad day: "echo Files produced by build tools go here, but caulk goes where?"

I came up with that years ago when I discovered that some unzip tools could not create an empty folder. So I had to put some one-liner in a text file.

"; 16x16 makes it a shitload easier to draw a player sprite" :facepalm:

Who is your intended audience.

At the second I wrote that, my conception of the target audience was people moving up from the NES to the Super NES. But ideally, it ought to be anyone who can use the command prompt. I've started to build a required reading list before one starts to develop for a retro console.

**I use Visual Studio in School to make programs, and now I wanna program a Mario game on SNES (or something)**

If the audience is people who are used to clicking the Run button in a proprietary IDE and never seeing a terminal, then perhaps my audience is Christopher Pow so he can add support for some Super NES emulator to NESICIDE.

Sik wrote:I have the feeling this would be worse for somebody with a NES background (since the SNES does not have CHR-ROM, making the sentence actually misleading).

Copy and paste problem. I may have to fix this in my SNROM template as well.

The Notepad bit was a reference to a comment by 3gengames.

You can ignore the comment, I'm a full-time Linux user and abuser now so I'm not too worried about Notepad's inept-ness.

installing Fedora dependences. Gotten from web searches, I haven't actually tested it. Does yum require root? Does install imply upgrade?

---

I just now reinstalled cc65 under Linux with standard build tools, and these are the steps I took:
3. unzip ZIP and in the following steps replace [path to cc65] with where you unzipped the folder.
4. In a terminal issue the following commands: 5. Insert the following in your .bash_profile or .bashrc file, to automatically add the local executables to your PATH There is also a bunch of cc65 library files at ~/usr/share/cc65/ but your projects don't use them at all, so I ignored them.

Thanks for the feedback. I've addressed some of the concerns in README and added a .wav to .brr converter that I wrote. Let me know if I've missed something.

I did miss something. I introduced a numpy dependency in wav2brr that I plan to make optional later. But I'd still like a code and comment review of 0.02 in case anything is hard to understand, so that I have a better starting point for a larger (multiple bank) template and a HiROM template.

I eliminated the numpy dependency (by writing my own convolve function for preemphasis), corrected some errors in the link script, and improved the code comments. What else is needed?

Very nice.

Another option for controlling accumulator and index width is to use:

• .a8 .a16 .i8 .i16

edit: I probably should have looked to see where those macros were being used. Question: why wouldn't .a8 at the beginning of spc_begin_upload work?

I was under the impression that .a8, .a16, .i8, and .i16 only changed the assembler's output width for subsequent instructions, not the CPU's mode that lets it interpret the changed width correctly. The .smart directive lets the assembler watch SEP and REP instructions and generate appropriately wide following instructions.

At the start of spc_begin_upload, .a8 by itself wouldn't work because the following lda APU0 expects to already be in 8-bit mode.

tepples wrote:I was under the impression that .a8, .a16, .i8, and .i16 only changed the assembler's output width for subsequent instructions, not the CPU's mode that lets it interpret the changed width correctly. The .smart directive lets the assembler watch SEP and REP instructions and generate appropriately wide following instructions.

Your impression is correct, Tepples.

Has anyone by chance got this to compile on Windows? I got Make, python, pillow etc installed. Also, ca65.exe and ld65.exe are in the root directory of all the unzipped files. However, when I try to run Make, it finds the makefile okay but I only get the following output:

ca65 src/snesheader.s -o obj/snes/snesheader.o
make: ca65: Command not found
make: *** [obj/snes/snesheader.o] Error 127

GNU Make, like the rest of the MSYS distribution, follows the UNIX rule of not including the current working directory in the executable search path unless you explicitly say so for security reasons. You can use one of two workarounds:

1. What I did when I developed on Windows was unzip ca65 and ld65 to some folder and then put that folder on my Path. Path is an environment variable; search the web for windows x.x environment variables (with x.x replaced with the version of Windows running on your PC, such as XP or 7 or 8.1) to learn how to change your environment variables.
2. Or you can modify the makefile to look for ca65 and ld65 in the current working directory. Change ca65 to ./ca65 and ld65 to ./ld65.

Thanks Tepples, that worked! Though now it's complaining that it can't find the bggfx.png file. It's there and all the paths look correct. But still I get one of those "usr/bin/env: python: No such file or directory" errors when it tries to run the pilbmp2nes.py script.