Ok, Hello Every Body. I am /new on this NES gaming world. I have seen a couple of assembler programming and it´s really troublesome, since rogramming differs from 8080/80286/80386/80486 micro assembler programming. For me is more useful if I make it on C/C++. So do you know some tutorials about C nes programming I already got the cc65 compiler. But how I start drawing picture, sprites point and Shapes? Know my pourpose is make nes or snes games for emulators for PC or portables, like Dingoo or GP32 << uff I´m a really long-tonged newbie, sorry for the boring chat>>
Unfortunately the NES libraries included with cc65 don't work properly (unless they were fixed when I wasn't looking, I doubt it).
I think it was a guy going by the name Petruza who was working on making some C libraries for NES. It was a little while back, I'm not sure how that progressed.
I don't think there is any example program written in C for NES that actually will work on an NES.. as far as I know. There was a Tetris game written by Groepaz that was cross-platform (he wrote the old NES cc65 libraries), but it's probably not gonna work anymore on most emulators or the real system. Of course the compiler works just fine, if you don't mind writing your own libraries and stuff.
yassergsNESDEV wrote:
For me is more useful if I make it on C/C++. So do you know some tutorials about C nes programming I already got the cc65 compiler. But how I start drawing picture, sprites point and Shapes? Know my pourpose is make nes or snes games for emulators for PC or portables
If you want to code for machines that can run emulators, and you want to code in C, you could always try cutting out the middleman: write your game in C using SDL or Allegro.
I've been working on an couple of examples and a small library (replacement for the built-in CC65 one) for NES development with C.
Based on my experience I think it's definitely possible to write reasonably complex games in C, but there's a lot of low-level stuff one must be aware of, like where variables are allocated and what C code will produce the fastest assembly code (CC65 isn't particularly good with optimizing). Also you still need to know all the nitty gritty NES hardware details.. you won't find any blit() functions here.
The main example is a single direction scrolling SMB-like platformer engine with a simple music engine also written in C (just for fun). I think I'll add some basic enemy support and then it's ready to go.
I looked at cc65's code efficiency and concluded that it would be too much of a limitation for writing a game. You'd have to limit what you did, or write lots in assembly. I don't even think it's reasonable on the SNES. They did it on many of the Game Boy Color games, but the CPU ran significantly faster, and the games all ran at a sucky 30 FPS (Bionic Command, I'm looking at you).
blargg wrote:
You'd have to limit what you did, or write lots in assembly.
I'd think that goes without saying. It's never going to be as fast as assembly. Also the complexity in finding how to make the compiler emit reasonably fast code (and other quirks like that) kinda defeats the purpose of using C in the first case.
But I think a game like Battle Kid would most likely be possible to be written in C (it'd make sense to have completely separate modules like the music engine written in assembly however). Would it be any less work than writing it in assembly... not so sure. But it's fun for sure.
What is a bit annoying is that CC65 hardcore the ($xx),Y adressing mode whenever you acess to any local variable, where Y is the pointer in C variable stack.
A good thing would be to limit the stack length to 256 bytes and use the $xxx,Y adressing instead but there is no option to do this.
Yes the code will be slow, but you will greatly reduce the chances of having variable conflicts, something that happens all the time when you write in assembly and have no "local variables", but numbered Temp and other generic varaibles. Even if you clearly indicate which ones are used/erased on the header of each routine, it's still hard not to mess up.
I think it also depends on the kind of game you code. Usually in a standard game, a good part of CPU time is dedicated to write sprites to OAM. If this routine is written in assembly (it should), along with other routines which are called every frame, it is probably possible to have the core of the game written in C and have it run at fine speed.
Slow code is an issue only if the code is executed regularly.
One thing that writing an NES game in C would lack is an easy way to step through your code as it runs. Unless there's a debugging emulator out there that can read debug output for C programs, you'd have to know 6502 anyway for debugging/stepping. I guess since C would be less error prone to bugs involving shared zp space (as per Bregalad's example) maybe this would be less of an issue, though. I'm so used to being able to step through code from working with C# and C++ professionally though I can't imagine working without it in my hobby.
On the subjective side of things, I know for me I just wouldn't enjoy coding for the NES in pure C. It'd take away the sensation of being 100% in control that makes asm so much fun.
@yassergsNESDEV: When you say troublesome and then mention the x86 processors, do you mean you're familiar with x86 assembly language and find 6502 to be alien by comparison...or? Because I know for me, knowing a little bit of x86 really helped out when I learned 6502. Most of the "hard" things about assembly language are pretty much the same from processor to processor.
NES, no way. SNES, probably not. Targeting the SA-1 @ 10.74MHz could be doable.
C isn't really appropriate for a processor with only a single accumulator. An intermediate between assembler and C should work well. The point would be:
- function arguments
- automatic variable location handling
- less opcode mnemonics, more raw logic (inx; lda #$0100 -> x++; a = 256)
There's an Arkanoid clone written in C that comes with the SNES_SDK (based on TCC). So it's doable for simple games on the SNES, but for more advanced stuff you'd have to write most of it in assembly.
And looking at the code generated by TCC is enough to turn my stomach, even after it's gone though the included optimizer. It's just really, really bad. Can't say anything about CC65's code quality, though thefox mentioned that it's not very good either.
The 65816 includes various stack-relative modes, very obviously for languages like C where you have plenty of local variables. The stack pointer is 16 bits, so you don't have to do the things cc65 does on the 6502.
Bregalad wrote:
What is a bit annoying is that CC65 hardcore the ($xx),Y adressing mode whenever you acess to any local variable, where Y is the pointer in C variable stack.
A good thing would be to limit the stack length to 256 bytes and use the $xxx,Y adressing instead but there is no option to do this.
Yeah it uses a software stack for local variables and function arguments so to get faster code one should use static local variables or global variables. There's a compiler switch (-Cl) that makes all local variables static which speeds up things a bit.
EDIT: Also, it treats all variables as "volatile", so even if a variable already exists in a register it will always read it again from memory. For example:
Code:
byte a = 1, b, c;
b = a;
c = a;
Will read "a" twice from memory always. However, code like "b = c = a;" will read it only once.
That's not so much treating everything as volatile, as not doing any CSE whatsoever.
Memblers wrote:
Unfortunately the NES libraries included with cc65 don't work properly (unless they were fixed when I wasn't looking, I doubt it).
I think it was a guy going by the name Petruza who was working on making some C libraries for NES. It was a little while back, I'm not sure how that progressed.
I don't think there is any example program written in C for NES that actually will work on an NES.. as far as I know. There was a Tetris game written by Groepaz that was cross-platform (he wrote the old NES cc65 libraries), but it's probably not gonna work anymore on most emulators or the real system. Of course the compiler works just fine, if you don't mind writing your own libraries and stuff.
You're right, it didn't progress. Although I'd like to get back to it, I stoppped writing the lib in C, because I realized it would be better if it was coded in Assembler, but exported C functions to be used from C code, which was the original idea.
Actually, there are at least two example programs written in C that work on a NES (Emulator), or did you mean the actual Hardware?
Not sure about that, but it may.
It's a sprite and scrolling demo and a working metronome.
If the original poster is still interested, contact me by PM and I'll send you the sources.
I'm not even gona lie, I think C is evil....especially when people debate what's better, C or assembly, which is too obvious ⌐.⌐
65024U wrote:
I'm not even gona lie, I think C is evil....especially when people debate what's better, C or assembly, which is too obvious ⌐.⌐
There is no perfect language: is all depend of the context of what you are developing. If you say you're doing to develop a new e-commerce website in assembler... I'm going to slap you silly
Banshaku wrote:
65024U wrote:
I'm not even gona lie, I think C is evil....especially when people debate what's better, C or assembly, which is too obvious ⌐.⌐
There is no perfect language: is all depend of the context of what you are developing. If you say you're doing to develop a new e-commerce website in assembler... I'm going to slap you silly
Hahahah, I ment as in the development of a program, not running on another
I bet we could re-program windows to take up 10MB or less of assembly if we programed it :p It's freaking 9GB now!...Thats C for ya it seems :/
65024U wrote:
I'm not even gona lie, I think C is evil....especially when people debate what's better, C or assembly, which is too obvious ⌐.⌐
For the domain of this forum which is NES and 6502 Programming, I would agree Assembler is by far the best choice.
65024U wrote:
Hahahah, I ment as in the development of a program, not running on another
I bet we could re-program windows to take up 10MB or less of assembly if we programed it :p It's freaking 9GB now!...Thats C for ya it seems :/
Are you saying that windows takes up more disk space because it's coded in C?
That's silly. the filezise of the same program coded in assembler and C shouldn't differ on more than a few KB.
If you're talking about memory, it's not that far either.
Windows is cluttered with useless things which take up space and that's not the fault of the language they were programmed with.
Assembler is perfect for little and/or old systems like the NES, plus modern embedded systems, but that's about it.
I dare you develop a modern day operating system in x86 assembler.
C is a great balance between the low level required by operating systems development and the high level required by not spending too much time coding in a language that makes you think more like a machine and less like a human.
Interpreted and Virtual machine languages like Java and .NET, well, that's another story.
Yeah well I think it definently is possible to make a OS, I don't think I could but if you take ONE computer and disassemble the BIOS, you could program a OS around that computer only....A 3.2GHZ PC with a OS in assembly? Fastttttt ^_^
It is true that C is not compiled on the run, but sometimes......I...I'm not sure I just don't like it....
Yeah, the size of an OS has nothing to do with whether it's programmed in C. That's ridiculous.
It's 9 gig because of all the sound effects and fancy graphics and icons and wallpapers and tutorial videos.
Your dislike for C is really irrational.
65024U wrote:
Yeah well I think it definently is possible to make a OS
Well sure, there were some OSes code in assembler, I don't say it's impossible, I say it's highly impractical as developing any big project in assembler.
65024U wrote:
A 3.2GHZ PC with a OS in assembly? Fastttttt ^_^
Linux is coded in C and it's fast, I'm not sure an OS coded in assembler would be much faster, and portability would be lost.
In present days, in the time you would spend coding an OS in assembler rather than C, processors would have doubled their speed at half the price, rendering the speed improvement of assembler useless.
65024U wrote:
It is true that C is not compiled on the run, but sometimes......I...I'm not sure I just don't like it....
Ok, if you just don't like it, that's enough a reason not to use it.
I like both C and assembler as well as other languages and use each where and when I think they fit best.
And I'm ending this conversation here, because the topic is NES development, and we all agree assembler is the best choice for NES development. OS development is not at all what I'm interested in.
Petruza wrote:
For the domain of this forum which is NES and 6502 Programming, I would agree Assembler is by far the best choice.
Until you get to the point where you need to develop editing and conversion tools. At that point you might need C, C++, Python, Java, or C#.
Quote:
I dare you develop a modern day operating system in x86 assembler.
Even if you do name it after Jon Mahon. (Inside joke.)
Sorry I dragged this so far off topic, I just really want to know how big windows really is and stuff that very moment XD
So....Anyone every think of making a NES cart that could be used for developing games?....FROM THE CONSOLE? *GASP*
When you think about it, C is a kind of universal assembly language (notwithstanding the
Universal Machine Language used in MAME. It's a common implementation of memory addressing not found in HLL's. Plus I'm always discovering new and interesting things you can do with pointers.
65024U wrote:
Sorry I dragged this so far off topic, I just really want to know how big windows really is and stuff that very moment XD
So....Anyone every think of making a NES cart that could be used for developing games?....FROM THE CONSOLE? *GASP*
Please don't follow the path of Joe_Cracker
65024U wrote:
So....Anyone every think of making a NES cart that could be used for developing games?....FROM THE CONSOLE? *GASP*
Family Basic. And on the DS there's WarioWare DIY.
But the problems with trying to develop games on a stock NES are input and RAM. Family Basic had a keyboard, and WarioWare DIY has a touch screen. The DS also has a droppingsload more RAM.