DKC Atlas Forum

If you know me, I've always been a mega fan of SNES and SNES hacking. I made DKC hacks in the past, which is why I joined the forum when I was 13. After making my last game in GM, I thought "Hey, how cool would it be to make a REAL SNES game?". I recently compiled a personal collection of tools for SNES homebrew development, including graphics importers, ASM compilers, hex editors, etc. I probably won't end up making anything too major, but maybe some very small demos once I get the hang of this ASM and SNES stuff. And heck, I might make another DKC hack if I get good enough.

And since I already set up the compiler, I decided to compile a blue background test ROM. I set the background blue via ASM. Nothing copyrighted is in the ROM.



SNES may be low res, and it may be brutal to work in ASM, but I honestly enjoy the challenge.

Discuss anything SNES homebrew related here.

Huh... care to post the code you wrote for this/resources? This could be a very interesting thing...

I didn't write a whole lot, the public domain SNES_Init and header files were used, which are bare essentials for getting SNES games to work. For practice, I modified the default background color (which was originally green) using ASM. I am new to ASM, but almost everything else related to SNES hacking and homebrew I am not new to at all.

Edit: I now set the background to white, which was my initial goal. By the way, the compiler I'm using is wla-65816. xkas simply didn't work for me.

Challenge:

Read controller input and change the screen to a different colour depending on the button pressed.

I'll try my best! My past hacking skills have really came in handy for this.

Can you link me to where you got those database files from? I would like to check this out too!

Not sure what you mean by database files. Markster was following the wikibooks tutorial or possibly the updated version on superfamicom.org.

I never had much luck with tutorials beyond setting tools up at the very beginning. I've found that they tend to either gloss over important details or simply expect too much foreknowledge from a beginner. A typical path is to first learn how the CPU operates and behaves, then onto how it communicates with other components like the PPU and APU. One option is to grab a few of the debugging emulators and mess around with the features they offer.

Raw documentation is good, but there is an awful lot to take in. Being exposed to terms and skimming through specs can improve your familiarity with the system dramatically. The best documents to have on hand are WDC's comprehensive CPU reference and programming manual, Anomie's docs (particularly the register one) and Fullsnes. Download them and when you have the time pick a page and start reading. Don't worry if you don't understand it all; if your head starts to hurt that just means you're learning.

The next problem is that knowledge doesn't immediately translate into practical skills. It's a good idea to get familiar with the toolchains for development, either oriented towards homebrew or romhacking; assemblers, tile editors, debugging emulators and so on. Prior programming experience can be beneficial but isn't essential. You might find that a lot of tools are good for some situations but don't really work as well for others. In these situations it's useful to have at least some ability in utility programming, so you can write your own tool that does exactly what you need. I don't think it's quite as common now, but it used to be very normal to find tools or documents older than you are that a lot of people swear by despite not being very good. What was best for a specific task twenty years ago might not be what's best today, despite what some people think.

Ultimately this can be a very rewarding journey and writing a halfway good game can be a very attainable goal, but by no means an easy one.

Thanks Kingizor! Always coming to the rescue, lol.