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.

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.txtit 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/master/libsrc/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.

I double click on readme.txtit 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...

1. Visit http://devkitpro.org/wiki/Getting_Started2. Follow the instructions there to download and run the devkitPro Automated Installer3. In the installer, check only MSYS. Don't check devkitARM, devkitPPC, devkitPSP, or any of the libraries for newer platforms unless you want to start on one of those sometime soon.

To install Python under Windows:

1. Visit https://www.python.org/2. Under Downloads, under Download for Windows, click Python 2.7.8 (This step may change if the maintainers of the Python web site reorganize the Python web site.)3. In your web browser's downloads folder, run python-2.7.8.msi4. Follow the prompts through the installer wizard

1. Visit http://cc65.github.io/cc65/2. Scroll to the bottom3. Click "Windows Snapshot" to download the zip file.4. Open the zip file.5. Inside the zip file, open the bin folder.6. Drag "ca65.exe" and "ld65.exe" into a new folder.7. Add this folder to your "Path" environment variable. Can someone finish this?

Open the makefile in a text editor and change EMU to whateverSuper NES emulator you have installed.

Quote:

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.

Quote:

"; 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.

Quote:

**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.

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:

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 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.

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.

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:

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:

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.

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.

Who is online

Users browsing this forum: Majestic-12 [Bot] and 7 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum