This is a replacement NES library for CC65, somewhat alike to rNES. I have removed bunch of “useless” stuff from the default nes.lib and replaced crt0.s with a new version. There's also a platformer demo with source.
Get it from http://kkfos.aspekt.fi/projects/nes/kne ... -for-cc65/
Any comments and suggestions are welcome.
KNES library for CC65 (aka Programming the NES in C)
Moderator: Moderators
-
GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Hey, that's really neat. Hopefully someone will use it for something cool. At the very least perhaps it could help make learning the NES a little easier for some people. They could start with C and then gradually migrate to replacing their C code with asm, perhaps. I know for me I'm so used to asm I don't think I'll need to use C...but it is still neat that it is now proven it is possible to write a decent game for the NES in C. Good work. I'm assuming the demo is similar to the C platformer demo you posted a while ago?
Yeah, that was one of the goals. Hopefully it brings more people to the homebrew scene. Nerdy Nights style programming tutorial for C could work really well.Gradualore wrote:Hey, that's really neat. Hopefully someone will use it for something cool. At the very least perhaps it could help make learning the NES a little easier for some people. They could start with C and then gradually migrate to replacing their C code with asm, perhaps.
It's funny to think that the bulk of the currently released homebrew games could have been written in C... (well, it's mostly puzzle games anyways).
Yeah, the demo is almost exactly the same. I simply added a few more features and fixed a couple of things. It's not still a full game but there's plenty of CPU time to add features (especially if the music engine is replaced with one written in assembly).Gradualore wrote:I know for me I'm so used to asm I don't think I'll need to use C...but it is still neat that it is now proven it is possible to write a decent game for the NES in C. Good work. I'm assuming the demo is similar to the C platformer demo you posted a while ago?
I actually quite like writing NES stuff in C. I'm probably going to write some of the less speed critical parts of my WIP game in C, like menus and cut scenes.
Also I think it can be useful for prototyping algorithms. Of course it's possible to use something like SDL for the same purpose (and I have done so in the past) but at least I have another option now.
It's much less error prone than writing the same stuff in asm, IMO.I've always wanted to program the NES in basic....even through an interpreter. Maybe there is some way to use BASIC compiled into assembly for the NES? -pokes all the 1980's Basics-
And seeing the performance hit for C on a NES.....I think it's just too insane. 6K cycles for only a few commands? Ickkk.....and anyone who knows C should be able to pick up assembly IMO. I think if we were to make a programming language people who can't program could make stuff with, I don't think C would be the answer..... :/
And seeing the performance hit for C on a NES.....I think it's just too insane. 6K cycles for only a few commands? Ickkk.....and anyone who knows C should be able to pick up assembly IMO. I think if we were to make a programming language people who can't program could make stuff with, I don't think C would be the answer..... :/
Family BASIC exists. It was never ported to NES because the keyboard wasn't brought over. In fact, as I understand it, there is still no standard keyboard for the 72-pin NES, nor an adapter for PS/2 or USB keyboards. If there were one, I'd probably have made something years ago.65024U wrote:I've always wanted to program the NES in basic
Now I don't want to come out too defensive, you're entitled to your opinion, but I don't agree with you.65024U wrote:And seeing the performance hit for C on a NES.....I think it's just too insane. 6K cycles for only a few commands? Ickkk.....and anyone who knows C should be able to pick up assembly IMO.
1) You're refering to the figures I posted at NintendoAGE? I don't know where you get "only a few commands" from... The code checks controller state, updates sprites, physics and checks collisions in update_frame(), hardly "only a few commands". Also there is room for (algorithmic) optimization.
2) Even if there IS a performance hit (of course there is compared to assembly, unless the assembly is programmed really poorly), it doesn't matter UNLESS it matters. What I'm trying to say, it doesn't matter how much CPU time it uses if it does the job in time. Premature optimization is the root of all evil.
3) "and anyone who knows C should be able to pick up assembly".. but assembly isn't C. C code is more maintainable, more readable, faster to code etc etc. To put it short, I think you're missing the point.
It's great to see a C library released for the NES.
I didn't look into it, but it sounds all good to me. Saying the performance hit isn't worth the trouble coding in C before even trying is now a good engineering approach. You'd want to at least try to code a game in C, and if it's too slow, port it to assembly, if still too slow port it to a faster system
What you guys seems to be forgetting is that it's perfectly possible to mix assembly and C in the same project. So in a typical case, you'd do tight loops that are executed often in assembly, and complex code that isn't executed often in C. Typically :
- Interrupts
- Sprites mazing
- Scroll updates
- Controller reading
- Music engine
Must be done in assembly. For game logic, it's probably not much of a performance hit if you write it in C. I might be wrong, but without trying you can't know.
Oh and of course you have to reserve an argument stack which is a bit annoying and will eat RAM... but maybe this will kill some bugs. I've had so many bugs in assembly because of variable conflicts, especially with TempX or whatever general purpose variables.
PS : A major problem though is that th most you use "tricks" to make C more optimized, like using static variables instead of parameters, the most it will end up complex to read and understand as ASM, so in the end you'd as well use ASM.
I didn't look into it, but it sounds all good to me. Saying the performance hit isn't worth the trouble coding in C before even trying is now a good engineering approach. You'd want to at least try to code a game in C, and if it's too slow, port it to assembly, if still too slow port it to a faster system
What you guys seems to be forgetting is that it's perfectly possible to mix assembly and C in the same project. So in a typical case, you'd do tight loops that are executed often in assembly, and complex code that isn't executed often in C. Typically :
- Interrupts
- Sprites mazing
- Scroll updates
- Controller reading
- Music engine
Must be done in assembly. For game logic, it's probably not much of a performance hit if you write it in C. I might be wrong, but without trying you can't know.
Oh and of course you have to reserve an argument stack which is a bit annoying and will eat RAM... but maybe this will kill some bugs. I've had so many bugs in assembly because of variable conflicts, especially with TempX or whatever general purpose variables.
PS : A major problem though is that th most you use "tricks" to make C more optimized, like using static variables instead of parameters, the most it will end up complex to read and understand as ASM, so in the end you'd as well use ASM.
Useless, lumbering half-wits don't scare us.
This is definitely true (I assume you meant global variables). Also looking at the C generated assembly listing for hours trying to figure out ways to make the C code more optimized can end up taking more time than writing the same thing in ASM, and can defeat the purpose of using C. But oh well.Bregalad wrote:PS : A major problem though is that th most you use "tricks" to make C more optimized, like using static variables instead of parameters, the most it will end up complex to read and understand as ASM, so in the end you'd as well use ASM.
I think this is a great thing! To me great thing about it is it provides and easier starting point for those just new to NES development. Naturally when they reach the limitations of C code they will be forced to move on the ASM, and by that point they should understand enough that it won't be seemingly impossible. I know I just about gave up when I fist looked at it.
If you provide a library that contains useful reusable routines that do significant work, the C code can do the light-duty stuff and thus not need to be as efficient. For example, you might have an asm routine that does sprite DMA, and copies tens of bytes to VRAM quickly in VBL, and make it usable from C.
As someone with many years of experience in both C and asm, I have to agree 99% with thefox's three points. Being able to program in pure asm has a certain "coolness factor" to it. However, pure asm is not always the right answer. There are different tools and different jobs. Sometimes several tools are equally valid choices, and sometimes only one tool will do (and sometimes no tools work).thefox wrote:Now I don't want to come out too defensive, you're entitled to your opinion, but I don't agree with you.65024U wrote:And seeing the performance hit for C on a NES.....I think it's just too insane. 6K cycles for only a few commands? Ickkk.....and anyone who knows C should be able to pick up assembly IMO.
1) You're refering to the figures I posted at NintendoAGE? I don't know where you get "only a few commands" from... The code checks controller state, updates sprites, physics and checks collisions in update_frame(), hardly "only a few commands". Also there is room for (algorithmic) optimization.
2) Even if there IS a performance hit (of course there is compared to assembly, unless the assembly is programmed really poorly), it doesn't matter UNLESS it matters. What I'm trying to say, it doesn't matter how much CPU time it uses if it does the job in time. Premature optimization is the root of all evil.
3) "and anyone who knows C should be able to pick up assembly".. but assembly isn't C. C code is more maintainable, more readable, faster to code etc etc. To put it short, I think you're missing the point.
My only issue is with "pre-mature optimization". Some people (ok, my former boss) are militant about deferring optimization until really late. The problem is that by then the project becomes too difficult to optimize (sometimes). Choosing proper data structures at the beginning will go a long way to ensuring that your project will be optimal enough later. For my personal projects I tend to profile, optimize and refactor my code many times as I develop it. If nothing else, I'll make it crunch a large data set while running inside a profiler so that at least I know where it is spending its time.
That being said, I still have not experimented with using C (or any other high-level language) in a NES project. I liked the idea of NESHLA, but I did not like its implementation or syntax. I write all of my asm in ca65, so throwing in cc65 should not be too difficult.
Haha sorry, I didn't want to make it explode. I think this is really cool, but shouldn't it be more for newbies? This is very cool and worth looking into, but still.....wouldn't a BASIC-type OS that also could translate to 6502 ASM on the same system work a bit better then C?
I am just thinking....If you could make a BASIC interpreter that at the end of development, be assembled to assembly? Or atleast include C functions that are smaller and do less so you don't have to call whole functions, because the less you can do per instruction, the more you can add and customize.
And wasn't there a C compiler from some game company? We need to contact them!
I'll probably mess with this later....If the weekend ever gets here.
I am just thinking....If you could make a BASIC interpreter that at the end of development, be assembled to assembly? Or atleast include C functions that are smaller and do less so you don't have to call whole functions, because the less you can do per instruction, the more you can add and customize.
And wasn't there a C compiler from some game company? We need to contact them!
I'll probably mess with this later....If the weekend ever gets here.
Great demo. Pretty cool to see the source for an NES program, coded in C. I think I will use C for some things on NES, and having a base to start with helps. I've been doing asm for years, but C is new to me.
65024U: There is one BASIC compiler I'm aware of - nbasic. But you're sure to need inline assembly with this. A BASIC interpreter would be cool, Family BASIC seems good enough to use though.
65024U: There is one BASIC compiler I'm aware of - nbasic. But you're sure to need inline assembly with this. A BASIC interpreter would be cool, Family BASIC seems good enough to use though.
Work better in what sense?65024U wrote:wouldn't a BASIC-type OS that also could translate to 6502 ASM on the same system work a bit better then C?
I think it's bit of an apples and oranges situation...Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi