16bit table indexing problem

[Drew Sebastino]

I know I'm bumping again, (I have had a break from SNES development because WLA has led me a bit frustrated with its bugs like hirom not working correctly and the newer problem) and I decided to try another assembler. I found a download for the bass assembler, (after looking ay a bunch of SNES bass fishing games and bass from mega man ) but I haven't found how to use it, because I don't really know what to do here:

bass command line.png (7.67 KiB) Viewed 9941 times

I typed in bass and then the name of the file, but it seemed to disregard what I wrote. I know I'm also probably going to have to change my code to make it work on bass, but I didn't see any documentation on the assembler so I have no clue what to do.

[tokumaru]

I typed in bass and then the name of the file, but it seemed to disregard what I wrote.

Read the "usage" section: apparently there are a bunch of optional parameters, and then you have to use -o followed by the name of the output file, and finally the input files.

[koitsu]

metaspritetest2, by the way, is not the name of the file. metaspritetest2.asm is the name of the file. The wla.bat file you've been using "hides" use of extensions by (blindly/idiotically) appending .asm to the argument you pass the script.

bass -o metaspritedemo2.bin metaspritedemo2.asm is probably what you're looking for here, but I also don't know for sure because I'd have to read the assembler documentation. There is documentation that comes with it (the UNIX tarball has doc/bass.html).

I'd honestly suggest just asking someone like Tepples to write you a ca65 template and use that instead.

[Drew Sebastino]

By template, I'm guessing you mean something like the walker code in SNES Starter kit? It would probably be easier to start from scratch, seeing that I didn't do too much... Also, does anyone know where to download ca65? I've looked for one, but instead I found a bunch of downloads for something called cc65.

[DoNotWant]

cc65 is the tool-chain with c compiler and all. The assembler comes with it.
Bass is easier to use tho.
http://board.byuu.org/phpbb3/viewforum.php?f=16

[tepples]

I'd honestly suggest just asking someone like Tepples to write you a ca65 template and use that instead.

Did someone say template?

[Drew Sebastino]

What am I supposed to do now? I looked at all the different files, but none of them had the source code. I opened README.md, and it looks like it makes me want to get a bunch of stuff to compile something to make the file. Why doesn't it just come together already? (I remember someone giving me an explanation, I just forgot.)

Building this demo requires that the following software be
installed on your computer first:

* ca65 and ld65, the assembly language tools that ship
with the cc65 C compiler
* Python, a programming language interpreter
* Python Imaging Library, a Python extension to read and write
bitmap images
* GNU Make, a program to calculate which files need to be
rebuilt when other files change
* GNU Coreutils, a set of simple command-line utilities for
file management and text processing

I know that ca65 is an assembler.

By the way, what in the world is a PKCS #7 Certificate?

[nicklausw]

I still don't get why it'd be necessary to install all of that just to have a good SNES environment. A makefile for the SNES is....eh.

[tepples]

What am I supposed to do now? I looked at all the different files, but none of them had the source code.

Did you look in the src folder?

I opened README.md, and it looks like it makes me want to get a bunch of stuff to compile something to make the file. Why doesn't it just come together already?

Because I don't know what operating system people run before they download my template. Nor do I want to have to include copies of image and audio conversion tools for Windows (32-bit), Windows (64-bit), OS X, Linux (32-bit), and Linux (64-bit), 80 percent of which will be useless to each individual user and building 20 percent of which requires a particular brand of computer.

By the way, what in the world is a PKCS #7 Certificate?

The .spc file extension can refer to either SPC700 save states (used for Super NES music) or software publisher certificates. "Public key cryptosystem" refers to the latter.

I still don't get why it'd be necessary to install all of that just to have a good SNES environment. A makefile for the SNES is....eh.

If you've made a sprite sheet, you need tools to convert it to a format that the S-PPU can use. If you've recorded audio, you need tools to convert it to a format that the DSP can use. So you need at least some tools other than an assembler.

And if you're building something with hundreds of source code files, sprite sheets, musical instrument samples, etc., you usually don't want to have to reconvert every single image file and every single audio file and reassemble every single source code file whenever you make one small change. A makefile allows rebuilding only what has changed. Besides, a lot of that stuff already comes standard on Debian-style distributions if you sudo apt-get install build-essential python-imaging.

[koitsu]

I still don't get why it'd be necessary to install all of that just to have a good SNES environment. A makefile for the SNES is....eh.

Simply put: you don't. Tepples' recommendations stem from his own development of tools and other things that tend to "relate" to SNES development (graphics creation/conversion, etc.). Tepples is kind of a interesting fellow because he tends to use large toolsuites (Python, GNU tools on Windows which often require Cygwin or MinGW, etc.) and requires non-bare-bones PLs for development, with a strong Linux/UNIX mindset (the command-line there blows Windows out of the water), yet the platform being developed for is extremely bare-bones. There's nothing wrong with his approach, but it's a method/approach that doesn't work for me.

I happen to be of a different mentality (and from a different era), mainly KISS principle: all you need is the assembler, some documentation, and some general pre-made tools. You don't need tons of disk space for all of this stuff, nor do you need to "install" anything (most KISS/bare-bones tools are self-contained). Most of my SNES coding was done with a single x816.exe binary and only a couple random tools (single .exes) available at the time. That's how it should be, IMO. The way Espozo is already operating is under this mindset (single .rar file contains all his tools, code, etc.), so IMO he should continue with that.

For ca65, you just simply need to download cc65. The only tool you really need from that suite is ca65 (the assembler), and extract it into some place like C:\cc65 and fix your PATH (you can do that from the Windows GUI, although a lot of people do this wrong/put things in the wrong place) to refer to that directory. Or you can just extract ca65.exe (assembler) and ld65.exe (linker) from the archive and use those directly, though if the templates or some other code refer to some special stuff cc65 includes (cfgs, libs, etc.) then you'd need those too. I do love the fact cc65 doesn't have an installer -- I LOVE programs that you just simply unpack somewhere and use them. It also makes clean-up much easier (delete the directory and they're gone).

GNU Make etc. are nice for creating an actual build command that works, e.g. you just type "make" after doing your code changes and everything builds. It's like a Windows .bat file but significantly improved (batch is horrible). On the downside, GNU tools tend to require "special environments" to work on Windows, and the two are either MinGW/MSYS or Cygwin, neither of which I particularly like. There may be purely standalone gmake.exe somewhere but I'd be surprised. You can accomplish the same task in a Windows batch file, but it's just more painful (and batch lacks things like dependency checking).

I think Espozo is learning just how completely awful the tool and development situation is these days, both on classic consoles and even present-day systems, and I feel really sorry for him. :( Something very very bad happened beginning in the early 2000s where morons getting into CS started pushing out awful designs and crappy tools simply because "open source!" and "WHEEEEEE UNICORNS!" and whatever other madness, while older folks from previous eras stuck with extremely minimal sets of tools and environments that they could practically carry around with them on a floppy disk in their pocket. It's almost like the driving force is glitter and "how fast can I push this out + how quickly can I get distracted by the latest new feature or thing rather than actually fix bugs", rather than creating something of actual use. The number of crazies in "development" has grown to a gargantuan size, and it's awfully depressing how few of those people actually understand how a computer (or even the underlying libraries their own PL relies on) actually works. I'm really sure those are the type of people I want developing or designing the tools *I* need, but I'm also the crotchety old man that sticks to what works because I understand how it works.

Don't worry, I'm sure someone will come along and make a SNES assembler written in Ruby and put it on rubygems named something pretentious like chariots_of_fire or super_duper_builder or trampoline_hexify, all very well-thought-out names. *rolls eyes*

[tepples]

My mentality is that once you learn what the tools are doing, they'll scale up to bigger projects. I understand some people prefer minimalism, where the whole thing gets reassembled every time. I used to do that in x816 until I upgraded to an operating system that could no longer run it reliably.

There is a standalone gmake.exe; it's called mingw32-make.exe. It depends only on the MSVC 6 runtime. Sometime in 2005, I ended up making my own distribution of portable cc65 for Windows to use on computers in a college computer lab; I forget whether I used mingw32-make or just batch files. It became less important to me after I got a laptop on which I carry my entire dev environment.

But even then, you still need to turn your graphics, audio, and other assets (components of a game other than code) into a form that your program can use. What's the minimalist way to go about this? Tile editor? Waiting until you get back to your home computer to work on graphics and audio?

[Drew Sebastino]

I happen to be of a different mentality (and from a different era), mainly KISS principle: all you need is the assembler, some documentation, and some general pre-made tools. You don't need tons of disk space for all of this stuff, nor do you need to "install" anything (most KISS/bare-bones tools are self-contained).

It really kind of surprises me how people can have 1TB hard drives and still ask for more room, while my hard drive looks like this:

Disk Space.png (4.15 KiB) Viewed 9841 times

And about downloading an installer, I really don't see the point. To me, it seems like just downloading something twice (the installer and the actual file) for no real reason. Whenever I have the option of a torrent or a direct download, I always just use the direct download.

It's almost like the driving force is glitter and "how fast can I push this out + how quickly can I get distracted by the latest new feature or thing rather than actually fix bugs"

I'm guessing this is referring to wla. (Seriously, the bug that's been causing me problem on XTemp and YTemp present in the version released in 2003 still hasn't been fixed. )

Also, I still don't see how people can "code" in high level languages, because it seems like there is a lot of different instructions and things to keep track of. I've been looking at the GBA, and it looked interesting to try to make something on it when I saw how little, but useful, amount of instructions there are, until I found out that there are a ton of different little things that you can add to the end of each opcode for way more actual different opcodes than it woud seem. For example, I looked at a code and it said subs. What is that supposed to mean? I replaced the subs with sub and it worked perfectly fine, so I don't get it. I find it funny that the GBA is supposed to use a Reduced-Instruction-Set CPU, when it has about a zillion possibilities for you to do. (I don't even want to know what assembly looks like on a CISC CPU.)

I really hope that some day, I won't have to ask a bunch of questions here, but I don't see myself, or anyone for that matter, really learning ASM anymore, especially for the SNES. There is a programming class at my school, but you first have to go though another class that has nothing to do with it, as you just do dumb stuff like create business cards. I'm 99.9999% sure that the "programing" class doesn't even cover any asm, or any non high level languages for that matter. I guaranty that there will be people who finish that class with a 100 average and still not even know what a byte is. (And this is no exaggeration.) Seriously, many peoples lack of any computer knowledge astonishes me, and I sadly think it will only worsen over time. A kid at my school literally thought that I phones (which I despise) became slower over time because the processor started to "rot" or something. Some people at my school didn't even know what a CPU was!

[tepples]

I've been looking at the GBA, and it looked interesting to try to make something on it when I saw how little, but useful, amount of instructions there are, until I found out that there are a ton of different little things that you can add to the end of each opcode for way more actual different opcodes than it woud seem. For example, I looked at a code and it said subs. What is that supposed to mean? I replaced the subs with sub and it worked perfectly fine, so I don't get it.

subs: subtract and set flags
sub: subtract and don't set flags

I find it funny that the GBA is supposed to use a Reduced-Instruction-Set CPU, when it has about a zillion possibilities for you to do.

Reduced instruction set complexity (RISC) largely refers to how "orthogonal" the instruction set is. You can add the same things "to the end of each opcode" no matter what the opcode is. You don't end up with crap like shifting only working with one register and indexing only being allowed with another. (See "Orthogonality" on Wikipedia and Stack Overflow.)

(I don't even want to know what assembly looks like on a CISC CPU.)

Among CISC CPUs, the 68000 in the Genesis, Neo Geo, Amiga, and original Mac is pretty sane. If you want insane, look at recent x86.

A kid at my school literally thought that I phones (which I despise) became slower over time because the processor started to "rot" or something.

It's not the processor that rots; it's the storage. As the internal flash fills up, the memory controller has to work harder to spread out the writes to different flash cells so that one part of the flash doesn't rot prematurely. Also new versions of the OS can be more demanding of RAM, causing the memory manager to have to kick things out more often.

[nicklausw]

http://www.network54.com/Forum/56397/page-9 Looks like for a while Ville was just continuously releasing new versions of WLA blindly. Took some time for the updates to get heavy and for people to notice them (and for him to stop scrambling around compiling it on a bunch of OS's and just make it open source).

And now the source code is a gigantic mess. What a lovely turnout.

[thefox]

There is a standalone gmake.exe; it's called mingw32-make.exe. It depends only on the MSVC 6 runtime.

True, but the problem is that most Makefiles depend on the standard *nix toolset. Many of those tools are natively available with GnuWin32, but that doesn't take care of the many incompatibilities with cmd.exe (e.g. MKDIR is a built-in command in cmd.exe). These differences can be compensated for in the Makefile, but that's not really what you want to be doing when creating a build system.

Personally I prefer using a "Makefile generator" like CMake, because CMake is able to take care of the platform differences. On top of that, CMake has builtin tools for writing and running tests, and packaging the build results.