WLA SNES programming help

[Supernintony]

So I'm trying to work with wla-dx on windows.

it was suggested to use it here http://wiki.superfamicom.org/snes/show/ ... nvironment

anyways, everytime i try to run it. i get the following error.

LOAD_FILE_DATA: Could not open file myfirstsnesprogram.obj
Could Not Find C:\...myfirstsnesprogram.obj

I can't get anything to compile, i even tried compiling some of the example asm files and i still got the same type of error message.

Does anybody know what I'm doing wrong?

[tepples]

If you're willing to try ca65 instead of WLA, you could try this Super NES project template for ca65. Instructions for setting up the development tools are inside.

[Supernintony]

I'm willing to give it a try, are there any cons to using this vs. wla?

[koitsu]

An alternate assembler (to WLA DX and ca65 with 65816 "extensions") is x816, which is what I've used on PCs for over 15 years.

Does the path name you've put all these things in contain spaces? If so, that might be what's responsible for the error, but I'm not sure. Try putting everything in, say, C:\mycode and see if that fixes it. You might also need to name your files shorter (filenames should be 8 characters long). It's been a while since I've dealt with WLA DX.

P.S. -- Nitpicky terminology thing (take with grain of salt), but: assembly code is assembled, not compiled. :)

[tepples]

I'll take the terminology debate to another topic.

Code: Select all

pino@pino-laptop:~$ file Desktop/X816.exe 
Desktop/X816.exe: MS-DOS executable, MZ for MS-DOS

Modern desktop operating systems (64-bit Windows, OS X, and Linux) cannot run MS-DOS executables as native processes. Are you recommending to run x816 inside the DOSBox emulator?

For comparison, a 32-bit Windows executable, which run as a native process under Linux with Wine libraries installed, looks like this:

Code: Select all

pino@pino-laptop:~$ file .wine/drive_c/Program\ Files/nocash/no\$sns.exe 
.wine/drive_c/Program Files/nocash/no$sns.exe: PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed

Supernintony: Are you using 32-bit or 64-bit Windows?

[Augustus Blackheart]

This archive includes everything you need to get started with the exception of make. It uses ca65, binaries are included.

For Windows, you'll also have to rebuild smconv if you want to use multiple soundbanks using the included templates. The only other thing I haven't done yet is automate the selection of the Linux/Windows snes_rules files.

I don't have Windows so if there's anything else that would make the whole process easier let me know.

This is Mukunda's tools (all source code included) with some minor modifications and I've added documentation for SNESGrit (graphics conversion). There are templates for LoROM, HiROM, and ExHiROM. There are also several examples (not all of them are commented as well as I'd like yet). There is the option of using SNESMOD or KungFuFurby's SNESMOD w/ Pitchmod and noise. I'll add the ability to use other sound drivers by modifying the Makefile.

I'd like to collect as many examples as possible and have a lot of useful routines that could be added to any project.

If anybody has any comments on things that could be improved or better documented let me know.

Question for tepples or other ca65 users; is there a way to mirror a specific segment, such as CODE? Right now I have a Unix-y solution using basic command line tools but it would be nice to have something cross platform. I didn't see anything in the docs but maybe I've missed something super obvious.

[tepples]

What do you mean by "mirror"? Do you mean replicate a segment in all ROM banks?

[Augustus Blackheart]

In this case it's for ExHiROM; to replicate the segment located at $C08000 to $408000.

[koitsu]

Code: Select all

pino@pino-laptop:~$ file Desktop/X816.exe 
Desktop/X816.exe: MS-DOS executable, MZ for MS-DOS

Modern desktop operating systems (64-bit Windows, OS X, and Linux) cannot run MS-DOS executables as native processes. Are you recommending to run x816 inside the DOSBox emulator?

Nope -- I don't have this problem because I run XP. :D (Don't bring up XP64 either :D) I suppose DOSBox or a VM of some sort would be the only option for x816. It looks like WLA DX has present-day Win32 binaries for use, so I guess that's that. (Edit: last part of this paragraph means I should migrate my own x816 code over to WLA DX :-) ).

[KungFuFurby]

Thanks for the x816 assembler! Looks like it's a DOS program, meaning I can run this with DOSBox.

I'm interested in this program on the grounds that I'm not sure if I should continue using WLA DX. I attempted to go custom (which partially worked...), and there are certain instructions I wish I could just use names rather than numbers (especially sep and rep, which I have been foiled on).

[tepples]

If you use x816 for 65816, you'll need to use something else for SPC700. WLA can supposedly do both, and ca65 can do both thanks to an SPC macro pack by blargg.

[KungFuFurby]

I already have a SPC700 assembler: I'm using TASM with mukunda's tab files to make the assembly work. I'm also using the DOS version for this one.

[Bregalad]

If you use x816 for 65816, you'll need to use something else for SPC700. WLA can supposedly do both, and ca65 can do both thanks to an SPC macro pack by blargg.

Don't make this mistake ! The SPC700 port of WLA is extremely bugged. You also are forced to create "ROM sections" when the system doesn't have ROM at all (no, the IPL ROM doesn't count since you're not the one programming it), this is ridiculous.

There is no real problem with needing multiple tools to compile a game anyways.

[tepples]

There is no real problem with needing multiple tools to compile a game anyways.

Other than that it makes the instructions to install all build prerequisites longer, as whicker pointed out. If both Windows-only and MS-DOS-only executables are included in a build process, instructions to correctly configure both Wine and DOSBox might get really hairy. So I try not to require too much beyond Python, Pillow, and ca65, if at all feasible.

[Bregalad]

In my personal experience, both Wine and DOSBox has been much easier to install and use than Python, which I never could get properly working.