nesdev.com

Markfrizb wondered why. I think some of the reasons are

1. Needing to learn two assembly language syntaxes, one for audio and one for everything else. Toward fixing this, byuu developed bass with 6502 syntax for the SPC700, but bass is really more for ROM hacks than for original homebrew. I developed a proof-of-concept reimplementation of 6502 mnemonics in ca65 macro language, which led to blargg's macro packs for SPC700 (both syntaxes) and GBZ80.
2. Needing to find a good set of WAVs to turn into BRRs.
3. It can be harder for your artists to make use of all 15 colors you get in a sprite or tile.
4. It can be harder for your artists to make use of 3 layers.
5. It can be harder for your whole team to make use of 2 Mbit, the smallest size of a well-formed SFC image.
6. It took a lot longer for emulators to get to the point where testing something on an emulator produces some level of confidence that it'll work on a console; Snes9x and ZSNES were even more deceptively permissive than NESticle at times. I'm guessing this is what byuu was referring to.
7. Less known working demo source code, even to the level of hello world. It takes more code to get something visible because of CHR RAM; the program has to DMA in some CHR data.
8. No widely accepted freeware 65816 C compiler; even the Apple IIGS-era compilers are hard to get. This rules out rapidly developed minigames like Alter Ego, Zooming Secretary, and MineShaft.

See also Super NES games slower than NES versions of the same game


EDIT: See also status of solutions as of December 2015.

_________________
Pin Eight | Twitter | GitHub | Patreon

Interestingly, I usually consume a good chunk of memory with music and SFX alone.
- Uwol: Quest for Money (the SNES port) is 2 Mbits, and almost a third of that is the music and SFX.
- MazezaM Challenge is 4 Mbits. Two fifths of that memory is used by the music and SFX. Interestingly, the game is more like a 3 Mbit game, as the last megabit is left unused.
- Tchou, for some odd reason, is a 7 Mbit game, although there is at least one megabit that can be shaved off since it's unused (and if the conditions are right, more than a megabit with some pointer shuffling). My music takes up one and three quarters of a megabit (or almost two megabits)... and a bunch of the music actually ends up unused!

I have a couple of game ideas myself, and I am already developing the soundtrack for both of them (one of them is so large, even larger than Earthbound's soundtrack, that the music alone is already 8 megabits! And the game I have in mind isn't even an RPG!). I've made a couple of test programs (including a graphic test), and I compile on the Mac with WLA DX (compiled using the shell script provided), and test them with SNES9X 1.53. I transfer the data over to another computer to debug if I absolutely have to, because there is no debugger on my end.

I do have a graphic converter that was produced by alekmaul (which I compiled with XCode and then, if I recall correctly, I adjusted the program for endianness issues), and SNESMod by mukunda for the music and SFX (also compiled through XCode).

I've also learned how the music can be banked over time thanks to inventing all sorts of music modifiers over the years, and I'm taking that method for some of these games. The in-game music in Uwol is all in SPC700 RAM at once (exceptions are the Title Screen, Ending and Game Over themes).

For a., I know both SPC700 assembly and 65C816 assembly, although I use 65C816 assembly much more often (I usually don't look up SPC700 opcodes, although I have looked up raw data inside SPC700 files before, especially these days when I do track counts when checking the ranges for the music modifier I produced).

For b, heh... this is where Schism Tracker comes into play, especially given the sound driver I use. I let SNESMod do the conversion, and I simply edit the samples, including loop points, with the tracker. It's basically dynamically changing the size of the sample in the process.
On a related note, I actually have endianness issues with the newest version of BRRTools, while I did not suffer from this problem with the Java version (I don't have the latest Java version..).

For c., I actually have an idea in one of my games to let the main sprites take up four or five colors, with one of those colors being different, and spread them out over the eight patlettes. The best use for this is so that I don't have to make duplicate versions each time. Then the other ten colors for each sprite patlette can be used for other objects. (or, if the right patlette is used, I can recycle some of the colors in one patlette).

For d... I think I have at least one idea that might use 3 layers. However, it might not always apply.

For e... I'm not sure about the graphics, but usually the music I make takes up a good deal of memory.

f. is a major reason why I have multiple debuggers... I have laevatinn (until there's another debugger) just in case I need to really examine what went wrong if the debugger I use, nosns, can't quite pick out the problem due to differences in emulators (I had this problem at least once).

For g... heh, I see what you mean. Especially with custom music. Plus, I think of mid-scanline effects, which I'm tempted to experiment with.

For h... oh yeah, tough call there... I actually can't even think of one that would work on a PowerPC Mac (I'm running an iMac G5 on Mac OS X 10.4.11). Even if I had the source, I'd have to check it and account for endianness issues if they pop up, and that's if the programming language (C or C++ is best for me) and libraries are compatible.

I plan to move to SNES homebrew and even Playstation 1 homebrew once I'll have successfully released several good NES games.

However, that won't be before a good while.
As for tepple's list of problems :
a) isn't a problem when you already know like 6 different assembly languages. Just print the instruction chart in doubt
b) Finding WAVs is not a problem, but making them fit the restricted SPC memory might be a problem. Anyways a low quality/small soundfont should do the work. Or just rip samples out of SNES games
c) Is definitely true ! However you can always come up with cheaper graphics that don't push the system to it's limit. It's the main problem for me, who is a very mediocre artist.
d) Not really. Layer 0 = playfield, Layer 1 = parallax or transparency or large bosses, Layer 2 = status bar and textboxes. Or if that's too much layers, use 2 layers, and use the tile-per-offset in mode 2, an amazing feature that was way too much underused
e) I don't see how it is "hard" to use 2 Megabit. You can always start with an almost blank 2 Megabit ROM. Uncompressed 4BP graphics will take up space quickly, and 64kb of SPC samples will already take 25% of that space.
f) Well the Super Power Pak and other similar devices exists for a reason.
g) I don't know much about SNES hardware but I doubt you have to use DMA, you could always manually copy the CHR assets in forced blanking mode.
h) You can code in assembly, although it's not quite as convenient.

@KungFuKirby : How did you end up having edianness problems with BRRTools ? Did you recompile it under a big endian system ?

I want to program for the snes so bad but I don't know where to start. Which tools should I use , I have windows 7, I have higan emulator, and also snes9x debugger. But as far as the tools to write the code and compile, I don't know where to start. I know a lot about electronic engineering and some various programming language skills.

And open yourself to a lawsuit just as much as if you had ripped the Mario sprites out of Super Mario World.


And open yourself to "Why didn't you just make it for the NES?"


I was referring to effort in drawing a beautiful parallax background.


If you come up with cheaper graphics, they won't take as much space because they'll be stored in Game Boy or 3BPP format and expanded to 4BPP at runtime.


For one thing, the PowerPak, EverDrive, and similar solutions tend to start the program in a state other than the actual power-up state. For another, it takes 30 seconds to get a build to the card, including copying the file, unmounting the CF card, inserting it into the PowerPak, and navigating the menus.


It's still harder than the assets already being there, which is true with either NES CHR ROM or a Super NES "hello world" project template.

_________________
Pin Eight | Twitter | GitHub | Patreon

I've been thinking about the items in tepples' initial post the past couple days. No I am not ready to respond to any of them in full yet; I'm kind of nodding (in agreement) and laughing (in disagreement) with a bunch of them. I really wonder how many of those were around during the snesdev days in the 90s. Am I the only one left? :/

Anyway, the one item I did want to ask tepples about was this, item (g):


You do not have to use DMA, you can do it the "old way" through memory-mapped registers if you wish (in fact that's actually how DMA does it -- yes really!), and in some cases the "old way" is a better choice. But trust me, for large updates, the DMA method is superb in every way and makes a lot more sense when you look at it. Have you actually tried using it? It's simple and logical to use for filling PPU memory.

The way you phrase the item implies that the DMA methodology is a negative -- it really isn't. In fact, overall I find dealing with PPU-related things on the SNES a hell of a lot easier (from a programmer's standpoint) than the NES. Remember: I started with the SNES/SFC and later learned NES/FC, so you could say I'm "spoiled", but it doesn't change the fact that DMA really isn't a negative in any way.

Basically the SNES/SFC is where Nintendo said "let's do this sanely, even if it costs a little more". The joypad registers on the NES, for example, are the one thing that still blow my mind compared to the SNES. NES = have fun screwing around in loops and shifting bits and using spare memory locations; SNES = all button values are stored in a 16-bit memory-mapped register for you to read at any time, where each bit represents a button or direction. wow very speed such smart so design.

Some tools:

• Prebuilt C compiler for Windows hosts
• A tool for optimizing the assembly output from the SNES SDK C compiler (note: Shiru has mentioned that it sometimes performed incorrect optimizations on his code. I have not seen this myself).
• WLA-DX for Windows hosts (includes assemblers for the 65816 and SPC700)
• Sixpack (my graphics conversion tool)

Some example code:

• SPC player (65816 & SPC700 assembly)
• VGM musicdisk with UI (65816 & SPC700 assembly)
• Menu for the Neo SNES Myth flashcart (C, 65816 & SPC700 assembly)
• Decompression routines for the 65816 (for aPLib, LZSS and PackFire)

Sure, but it's simple enough to perform a DMA transfer:

As far I know, fonts are not copyrightable, so logically sound fonts would follow the same rule.
However, if you're smart enough you'll rip each sample from a different game from a different company so nobody will even notice. That'll work better than having every letter from a different font (which will likely be very ugly).

I've seen so many games using Roland SC-55 samples for some of their instruments. Did Roland ever lawsuit game companies ? Or did they pay a licence ? Or is buying Roland hardware considered good enough ?


True, but if you make a nice use of SPC music that'd be the answer ^^ (or would a NES cartridge using an expansion sound like N106 or VRC6/7 considered "more authentic" ?)


Don't use WLA for SPC700 coding. This particular port of WLA is extremely buggy and unstable. It's already hard enough to debug code on a platform with virtually no good debugger, if the assembler doesn't produce the code you had at input it's even much worse. I recommend spcas.

IIRC, bsnes has an S-SMP debugger.
As far as generating correct output is concerned, do you have an example? I've used wla-spc700 in multiple projects and have not seen that kind of behavior.

I wasn't trying to claim it was harder than a CPU-driven copy. But it is harder than the data already being there, which is what you get with NROM on NES. You have to somehow get the data into what is essentially CHR RAM yourself. And unlike on NES, where $2005+$2001+$2000 = display, there are a lot more registers that you have to poke before the PPU will start displaying anything. This is why a hello world template project for your particular toolchain is so important.


Except at the start of vblank, which bites you if your NMI handler didn't have much to copy this frame and you immediately start to run your next frame's game logic. Then you're back to loops to wait for the automatic reading to finish. And if you want to use a mouse or a multitap, you're still back to loops.


The case law for pictorial, graphic, and sculptural works and the case law for sound recordings went in different directions.


It's likely that Nintendo signed a deal with Roland to provide a sample set to licensed developers.


Has, or had? I seem to remember higan gaining and losing the debugger as it goes through different front ends. And is it present for all platforms supported by higan, or do I have to run Wine for debugging the way I have to with FCEUX?

_________________
Pin Eight | Twitter | GitHub | Patreon

Had, in the version I'm using (which isn't the latest one). Windows is the only OS I run at home, so I don't know whether any of the debugger-enabled versions of bsnes are available for other OSs (though IIRC the source code is/was available, allowing you to build it yourself).

There are a lot of homebrew games for classic gameboy, gameboy advance, and nintendo ds. As well as for most 8bit consoles & computers. Many of tepple's possible issues are applying to that systems too, but they didn't stop people. Initializing VRAM with or without DMA isn't that difficult, filling the available ROM space with (useful or wasteful) data is all too easy. Creating a square wave or finding WAVs shouldn't be more difficult as on other systems, finding a WAV to BRR converter may be some small obstacle, the syntax for main cpu and sound cpu are mostly having cosmetic differences, which should be no big deal, except that one may need separate assemblers for each one (finding assemblers & brr-converters shouldn't be impossible, but one needs to get more tools together for getting started).

During their lifetime, SNES and PSX were lacking any kind of good hardware documentation, and there don't seem to have been any good tools for testing things on real hardware. Well, at least from nowadays, floppy disc-based copiers and cdr-based modchips are looking like pre-historic relicts. The snes copiers & psx cheat devices also had parallel ports, which are also a bit pre-historic, but they (should) have reached up to 750kbyte/s transfer rates. I have never tried them, but I doubt that they've been implemented properly (the psx cheat firmwares are doing a lot of handshaking after each byte, so they have more probably reached only poor rates like 100kbyte/s). Though, even if homebrew wasn't that easy during the SNES/PSX lifetime, that doesn't really explain why there's still no homebrew scene yet.

For SNES, my main issue would be the 65C816 cpu. The overall 65xx syntax can be looking quite cryptic (to people who didn't grew up with 6502 computers), myself I don't know (and don't want to know) if TXA transfer from X to A, or from A to X. The 8bit/16bit/24bit memory addressing with lorom/hirom maps is also a bit more scary as on other systems - I could deal with that stuff - but the 8bit/16bit mode switching is just insane. I am still surprised that there are so many companies that have developed SNES games, I've absolutely no clue how they have found programmers that were able to (and willing to) write code on that CPU. The thing might have been quite comfortable when doing everything in 16bit mode, and leaving the 8bit modes unused, but unfortunately many of the I/O ports are only 8bit wide (that's really stupid, looks as if the hardware designers haven't been aware that Nintendo was going to use the PPU/DMA stuff with a 16bit CPU, else they could have at least padded the 8bit ports to 16bit size). Maybe it'd be recommended to stick in 16bit mode, and use 8bit mode(s) only in a few low level functions. Aside from being difficult to program, it's also difficult to disassemble that mode-switching code (which may also be a reason for smaller homebrew/hacking scene).

Anything wrong with no$sns? The debugger for main cpu isn't as powerful as in no$gba/no$gmb/no$psx, but I was hoping that it's at least good enough to be of some use (but yeah, debugging for the sound cpu and for the numerous coprococessors is still lacking some features).
What is an "assembler that doesn't produce the code you had at input"? One that is mis-translating the source code to wrong binary code instead of firing error messages?

The T family instructions all use "from, to" order, just as the 68000 does.


Probably from the 6502 scene. There were plenty of programmers with C64, Atari computer, or Apple computer experience. The Apple IIGS had been out for a few years with the same CPU, and early dev systems were reportedly IIGS-based.


FCEUX's debugger works only in the Windows front end, but at least its bug tracker has been receptive to my Wine bug reports. Do you test in Wine? Or should I be your Linux guinea pig?

_________________
Pin Eight | Twitter | GitHub | Patreon

Unfortunately not, I lost the source code, I only have the binary SPC file left on my PC. But it was something totally random (but deterministic), like it would throw a dozen of 0x00 bytes in the middle of my code for no reason. I don't remember very clearly, but it was extremely annoying. I had to add dummy instructions so that WLA wouldn't trigger its bug. If you didn't encounter it then I'm glad for you. Also pehaps you have a newer version of WLA than the one I had back then ? Although it doesn't seem WLA gets updated much...



The experiment I mentionned was made in 2008. no$snes weren't released at that time, and BSNES had zero debugging features. I was using SNES9x Debug for debugging, it was working, but it was just a bit annoying to make it work, compared to FCEU for example (the absolute reference of debugging, if only Super FCEU was existing it'd be awesome, even at medium accuracy level).


The same could be said of any assembly language, really.