News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: snes programming  (Read 20448 times)

fairdenizen

  • Sr. Member
  • ****
  • Posts: 383
  • America's Individuality
    • View Profile
snes programming
« on: October 21, 2013, 10:28:09 pm »
is it possible to program a game for snes, and what is the best language to do so if it is?


thanks in advance

FAST6191

  • Hero Member
  • *****
  • Posts: 2859
    • View Profile
Re: snes programming
« Reply #1 on: October 22, 2013, 05:36:03 am »
Possible. Sure, if you can run custom code on it (and hacking is a great fan/example of that) you can run homebrew of some form.
Best language. Some people have got some things resembling high level languages onto the SNES ( http://www.portabledev.com/wiki/doku.php http://code.google.com/p/snes-sdk/  ) but assembly is still king if you want to make anything resembling a complex game (you could make a wicked version of a pong or tetris with such tools but you are probably not going to be making the next Final Fantasy or Mario Kart). I have no idea how far the inline assembly support will take you with said SDKs I just linked either.

Realistically though even with a higher level language you are going to be learning the SNES hardware. http://en.wikibooks.org/wiki/Super_NES_Programming , http://wiki.superfamicom.org/snes/show/Setting+Up+a+Programming+Environment and http://www.romhacking.net/?page=documents&category=&platform=9&game=&author=&perpage=20&level=&title=&desc=&docsearch=Go and playing to it.

In the end by all means do it and coding for old/embedded/low power machines is an interesting gig that will see you learn a lot but most usually set about this after they know a fair bit of programming, as a means to learning the SNES hardware/assembly or something similar. If you just want to make a game there are far easier and more practical ways to set about it, you can quite happily make it look, play and sound like it was on a SNES too if that is your desire.

ARM9

  • Jr. Member
  • **
  • Posts: 7
    • View Profile
Re: snes programming
« Reply #2 on: October 28, 2013, 11:47:59 am »
FAST6191 is right about having to learn how the hardware works, it is vital if you plan on programming anything for the SNES. The best language if you want performance is assembly, there are no good free C compilers for the 65816. You may want to check out this compiler, I haven't used it so I can't recommend anything but assembly. The C toolchains linked above are both based on the same compiler (tcc-816, a retargeted TCC), which doesn't generate very good assembly at all. I've been working on a C library for the SNES and I'm already planning on abandoning tcc-816 if I continue with the library.

Quote
I have no idea how far the inline assembly support will take you with said SDKs I just linked either.
Both use tcc-816, which doesn't even support inline assembly, neither can it inline functions. Yeah it's pretty crude.

Cyberman

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: snes programming
« Reply #3 on: October 28, 2013, 10:04:52 pm »
is it possible to program a game for snes, and what is the best language to do so if it is?


thanks in advance
Anything is possible
The question is "is it practical"
Have you programmed a game before?

What did you have in mind?

Here are some C compiler links I dug up looking quickly.

SNES sdk
6502.org compilers and languages

I doubt you wish to add a new processor model to the SDCC compilor (for example).

I don't know if thier is a port for the 65816 for GCC (Thier is for the hc12 the msp430 and numerous other little processors but not sure about the 65816).

Cyb

Bisqwit

  • Sr. Member
  • ****
  • Posts: 418
  • Polite, but politically incorrect.
    • View Profile
    • http://iki.fi/bisqwit/
Re: snes programming
« Reply #4 on: October 29, 2013, 11:58:14 am »
One of the best ways to learn a platform is by an example. I suggest you do a lot of studying how emulators and existing games work (by disassembling/tracing them), and that way you will learn a lot. Remember to also have platform documentation handy.

Pennywise

  • Hero Member
  • *****
  • Posts: 2316
  • I'm curious
    • View Profile
    • Yojimbo's Translations
Re: snes programming
« Reply #5 on: October 29, 2013, 08:02:06 pm »
Most SNES games were programmed directly in assembly. None of that high-level language crap folks have today. IIRC, the SNES lacks the power to really handle C etc.

Revenant

  • Full Member
  • ***
  • Posts: 205
    • View Profile
Re: snes programming
« Reply #6 on: October 29, 2013, 08:22:26 pm »
Most (or all) of EA's SNES games were written with the aid of a C compiler, which you can tell particularly by the way function calls are handled (through extensive use of the stack in ways no human programmer would have a reason for, including brilliant things like subtracting zero from the stack pointer in functions with no local variables - smart compiler) and by the fact that it's not hard to find 65816-ized versions of the most common/useful standard library functions like sprintf, etc.

I want to say they weren't the only company that did this, though I can't remember who else's games I've seen obviously compiled code in (Accolade?)

Given that the language's de facto "bible" was originally published in 1978, it's not hard to imagine that a moderately powerful console released more than a decade later could handle it to some degree given a decent compiler. C really is a very low-level language compared to almost everything that followed it.

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: snes programming
« Reply #7 on: October 29, 2013, 10:03:07 pm »
Suffice it to say that the SNES itself is up to C, but the C itself is up to you. Well, you and the good graces of your compiler :P

In the 90s, compilers were not usually particularly good at optimizations. Doom being written mostly in C came as something of a surprise to a lot of people.
we are in a horrible and deadly danger

Bregalad

  • Hero Member
  • *****
  • Posts: 2737
    • View Profile
Re: snes programming
« Reply #8 on: October 30, 2013, 05:56:07 am »
Suffice it to say that the SNES itself is up to C, but the C itself is up to you. Well, you and the good graces of your compiler :P

In the 90s, compilers were not usually particularly good at optimizations. Doom being written mostly in C came as something of a surprise to a lot of people.
C compilers are only good at optimisations where people will do the effort to make them good at optimisations.
Lots of efforts were made for X86 and ARM, but few to none on the 65xxx family of processors.

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: snes programming
« Reply #9 on: October 30, 2013, 11:44:49 am »
I never said you didn’t have to be a wizard to make this work ;)

Quite the opposite, really. You’d have to be That Guy™. You’d have to be Carmack good. You’d have to be Abrash good. You’d have to be Mel Kaye.
we are in a horrible and deadly danger

Bregalad

  • Hero Member
  • *****
  • Posts: 2737
    • View Profile
Re: snes programming
« Reply #10 on: October 30, 2013, 03:35:26 pm »
That's a great tutorial, I know somewhat many of what's being said, but I still learned a lot I didn't know.

And people like this pink girl tend to irritate me to a certain point in real life. A normal programmer should be a mix of the two presented here, he should know what he's doing like the pink girl but he should not remember everything by heart and should not not miss an occasion to show it off.
By experience I know people like this are impossible to work in a group, and I would never hire one of them. Not counting that if they know a lot of stuff by heart, there is very high chances they have accidentally learned WRONG stuff by hear, but because they're so loud mouthed and so sure of themselves, they will insult you for disagreeing with them even though you say the truth, and will do so until you apologize and say you're wrong.

So yeah, even if they are competent at learning stuff by hear, I'd never hire someone like this as they are extremely annoying individuals. It's just the vision of this pink girl made me remember some of my worst souvenirs.

Also, it's not surprising people don't know the "relevant details" of the language. Teachers says, "do never use global variable - they're evil/bad/watehver". You will loose point if you use them in your exercises, period. They don't provide any extra argumentation, and if you are asking for some, *maybe* will post an example where you have a local variable hiding a global one and this will make the code crash, so they think they have proved how evil global variables are.
So it's not surprising people don't know what they are good for, and why they are being initialized.

The C++ part leves me scratching my head. I feel like I've never studied this language, even though I technically did it (twice) I forgot nearly everything. It's definitely the most complex language I've ever encountered. I probably need to go study it again (or to officially claim I don't speak C++).
« Last Edit: October 30, 2013, 03:47:44 pm by Bregalad »

furrykef

  • Full Member
  • ***
  • Posts: 132
    • View Profile
Re: snes programming
« Reply #11 on: November 03, 2013, 07:27:10 pm »
As for C on the SNES... remember the maxim, 90% of the time is spent in 10% of the code. Sometimes this is quoted as 80% and 20%, but the principle is the same.

The thing is, though, back in the SNES's heyday, they probably didn't have profilers available to them. (Heck, I'm fairly sure a certain devkit for a certain more modern console does not include a profiler.) This makes it difficult to identify where the bottlenecks are, and writing everything in ASM in the first place means you don't have to waste a bunch of time rewriting code in ASM trying to find and fix the bottleneck. It's also probable that the SNES devkit didn't have a good debugger available that would have allowed you to make sense of C code. So I can see why programmers back in the day might have decided ASM was just easier to use.

And in fact it still is for those same reasons. You'd need a special emulator to profile and debug code written in C, and right now that's not gonna happen considering we don't even have an emulator that's good for working with code written in ASM. But we have the power to write one, if only anyone could be bothered to.

EDIT:
To somebody beginning programming for the SNES, I would certainly recommend ASM over C. To somebody who is new to programming, I would suggest starting with Python. Python is a great programming language to start with because it's very high-level and easy to understand, and yet it's very powerful and practical. You can write virtually anything in Python. I actually use Python even in programming for ancient systems like the NES, because Python scripts are often useful for generating code and data. For example, if you need to compress some data in your ROM, you can write a Python script that compresses the data. Sadly, though you can't actually program an NES or SNES game in Python because it would be incredibly slow and probably need more RAM than the system offers just to run any code at all.

After learning Python I would recommend learning C. C is also a great language to know because there is oodles of code out there written in it, and if you want to be a good programmer, you need to be able to read it. I would call C a mid-level language. Some call it a high-level language, some call it a low-level language, so mid-level sounds like a good compromise. (It's certainly much lower-level than Python.) C is less expressive than Python, but it is closer to the underlying machine while still being generally familiar, which would help prepare you for the final step: learning 65816 assembly language. If you can get to that point, it should be pretty easy to handle.
« Last Edit: November 03, 2013, 11:02:34 pm by furrykef »

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: snes programming
« Reply #12 on: November 03, 2013, 09:07:25 pm »
As for C on the SNES... remember the maxim, 90% of the time is spent in 10% of the code. Sometimes this is quoted as 80% and 20%, but the principle is the same.
I like this particular phrasing of it. ;D

Assuming you could hook a decent optimizing compiler architecture up to the 65816, you’d probably still have to account for things that standard C doesn’t no matter what you did or how well you code. It’s not unprecedented: these bizarro unportable features were actually tolerated if not loved for at least one architecture’s complicated memory scheme, particularly pre-ANSI.

Another thing is that the 65xx-series had programmer-friendly ISAs in mind. It was pretty much intended to be programmed at the assembly level and to be used in small (for the time) devices. C came from a different world (as a systems language for minicomputers with a more dreadful ISA). It kind of assumes a single stack for everything. Someone who actually made a C compiler for 65816 said it’s not so helpful with that. So, you would have to still program your C around architecture quirks all the time. That doesn’t surprise me; a lot of C is written that way even when it’s completely unnecessary. I never have programmed for systems that old myself, but a lot of DOS code I’ve seen in books contains inline assembly without giving it a second thought!

All that said, there was definitely some C being done on the SNES back in the day. But the real history of that would be a long post where I’d get all the details wrong. Probably more reliable to scour ASSEMblergames or something.
we are in a horrible and deadly danger

Bregalad

  • Hero Member
  • *****
  • Posts: 2737
    • View Profile
Re: snes programming
« Reply #13 on: November 04, 2013, 05:44:58 pm »
Quote
it's very high-level and easy to understand
For me, those are exactly the opposite of the other.

Assembly - low level, very easy to understand
C - mid level, a bit hard to understand but you get used to it quickly
C++/Java - high level - ok, but I begin to scratch my head
Perl - very high level - $"*?*)+?°£

I haven't studied python but I suspect it's even worse than Perl in that matter from what I understand.

Note that easy to understand != easy to program with. Those are two completely different things (usually one is the opposite of the other, but not always). For instance, ASM is extremely easy to understand, but very hard to program with on large scale project.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: snes programming
« Reply #14 on: November 04, 2013, 06:10:44 pm »
So what do you call 'easy to understand' exactly ?

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: snes programming
« Reply #15 on: November 04, 2013, 06:21:27 pm »
Easy is what is familiar.

Easy is rarely elegant or simple, though.
we are in a horrible and deadly danger

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: snes programming
« Reply #16 on: November 04, 2013, 06:23:02 pm »
That's more the word 'understand' that bothers me.

furrykef

  • Full Member
  • ***
  • Posts: 132
    • View Profile
Re: snes programming
« Reply #17 on: November 04, 2013, 08:57:23 pm »
For me, those are exactly the opposite of the other.

Assembly - low level, very easy to understand
C - mid level, a bit hard to understand but you get used to it quickly
C++/Java - high level - ok, but I begin to scratch my head
Perl - very high level - $"*?*)+?°£

I haven't studied python but I suspect it's even worse than Perl in that matter from what I understand.

I fail to see what's easy to understand about ASM in any sense. I came to it from a BASIC, C and C++ background and it was completely alien to me at first, probably even more than the leap from BASIC to C. So I don't think the concepts were easy to understand. And code written in ASM is certainly not easy to understand. You can't tell what it does just by looking at it; you have to mentally break it down step by step. ASM involves a lot of tedious shuffling into and out of registers, which has little to do with actually solving the problem you're trying to solve.

How exactly is this:

Code: [Select]
LDA income
SEC
SBC losses
STA profit

easier to understand, in any sense, than this?

Code: [Select]
profit = income - losses
This is without getting into the complete lack of structured programming in ASM...

STARWIN

  • Sr. Member
  • ****
  • Posts: 450
    • View Profile
Re: snes programming
« Reply #18 on: November 05, 2013, 01:51:46 am »
I fail to see what's easy to understand about ASM in any sense.
Clear order of execution, lack of obfuscating abstractions, no need to worry about portability, language doesn't change, less hidden low-level details..

You can't tell what it does just by looking at it; you have to mentally break it down step by step.
I'll have to say that this is how I treat all programming languages.. high-level OO languages tend to be difficult to understand. It could be that some people are just naturally low-level oriented.. OCDs or whatever.. while the norm is to read everything fast and understand 10% of it, no matter what it is. It probably boils down to the difference between reading and understanding, in some philosophical manner.

ASM involves a lot of tedious shuffling into and out of registers, which has little to do with actually solving the problem you're trying to solve.

How exactly is this:

Code: [Select]
LDA income
SEC
SBC losses
STA profit

easier to understand, in any sense, than this?

Code: [Select]
profit = income - losses
Without knowing the languages in question, they are both impossible to understand. But I agree with you that the latter is easier to read.

As far as 6502 goes, your code example actually reminds me of BASIC. They are not terribly far from each other if you think about it. I barely read 6502 with nice variables like that.. disassemblies and the whole reverse-engineering perspective certainly make ASM look a bit worse than it is.

Assuming 6502, the former example is easy to understand because:
-it executes from up to down unless interrupted
-we know that A stores 8 bits
-all the instructions do a specific, well-defined, simple thing - no single instruction is difficult to understand

Memory references are the difficult part. We hope that they refer to some well-behaving albeit boring piece of memory. We fear that they are related to I/O or other places that the 6502 as a processor really doesn't know anything about.

With the latter example, I hope that there are no bugs, because even if it is "merely" C, which is a really nice language to read if written simply, I just don't know all the ways it can fail. If we assume a lot of things, it can be fairly convenient.. operating with well-defined variables and operators.

If we can forget about portability and undefined behaviour by using a "higher-level" language, we can probably think of variables and their operations in a more lightweight model - something equivalent to ASM. After some thinking the whole "high-level" vs "low-level" concept starts to crumble.

Still, a bigger language often means a larger selection of possible/typical lines/abstractions. Certainly at some point understanding starts to suffer if you cannot remember the language you're using. How much effort should be put to understanding the language vs using the language? If I had to understand one language out of the mentioned ones perfectly, I'd never pick C or C++ or Java, because 6502 is easier.
« Last Edit: November 05, 2013, 02:05:12 am by STARWIN »

Bregalad

  • Hero Member
  • *****
  • Posts: 2737
    • View Profile
Re: snes programming
« Reply #19 on: November 06, 2013, 08:06:41 am »
How exactly is this:

Quote
Code: [Select]
LDA income
SEC
SBC losses
STA profit

easier to understand, in any sense, than this?

Code: [Select]
profit = income - losses
In fact, there is several things that are easier to understand.
First you don't have to worry about the types of income, losses, profit, you know that they they are the size of the accumulator.
Then you don't have to worry about how the - opperator is implemented, and how it will react to overflow/underflow, because this is specified by the SBC instructions which has a completely defined behaviour.

In some of the langages that are, in my opinion, hard to understand, the "-" could call an operator overloading function that would take the objects as arguments, etc... and this like could potentially generate 32kb of code instead of 7 bytes (again, depending on the types).

Object references and copying are something that is especially complex to understand, and I suspect that less than 10% of people who speaks the language actually know what they are doing. Of course, don't include me, since I'm explicitely stating I'm not understanding this, but at least I know that I don't understand it - the most dangerous thing is to think you understand something you don't.

In this regard, high level OOP languages are extremely good at this : They are simpler to work with and make people think programming is easy and that they understand perfectly what they're doing.

The result of this is programs taking 100 times the memory they should take (both code size (hard disk) and data size (run time heap memory)), memory leaks, unpredictable execution speed and very nasty bugs.

This is just my opinion, it's fairly incomplete as I am not so experienced with so many languages, and anyone is free to disagree. But this is why I think low level is easier to understand - but not easier to program with.
« Last Edit: November 06, 2013, 08:13:51 am by Bregalad »