Hi,
I'm completely new to NES programming. I'm able to program with high level languages, but have never done anything Assembler-like.
So, I'd really like to know: Is it actually possible to program an NES game in C and compile it with cc65 without having to use Assembler? Or is the NES support for cc65 of no real practical use? (I'm asking because I searched the internet, but have never seen even an NES demo program written in C.)
If the latter is the case, are there any other compilers for programming NES games in a high level language or do I finally indeed have to resort to Assembler to get it done?
NES programming without Assembler actually possible?
Moderator: Moderators
-
UncleSporky
- Posts: 388
- Joined: Sat Nov 17, 2007 8:44 pm
If you are serious about programming the NES, you are going to have to dive in and learn assembly. I don't know much about what options are available for programming besides assembly; I know some people have tried to use C, and some have used a really cruddy version of BASIC, but it boils down to requiring assembly in one form or another. Higher level languages just can't do things as efficiently, and efficiency is required on the NES outside of very simple games and demos.
NES programs made with a higher level language will invariably require at least some assembly, which means you're going to have to learn some anyway. You may as well do it right from the beginning rather than get really far into a project and realize that you don't have the right instructions, enough CPU time or space on the cartridge to do what you want.
This set of tutorials is very good for getting started in programming the NES, and includes many basic concepts to understand besides just programming:
http://www.nintendoage.com/faq/nerdy_nights_out.html
NES programs made with a higher level language will invariably require at least some assembly, which means you're going to have to learn some anyway. You may as well do it right from the beginning rather than get really far into a project and realize that you don't have the right instructions, enough CPU time or space on the cartridge to do what you want.
This set of tutorials is very good for getting started in programming the NES, and includes many basic concepts to understand besides just programming:
http://www.nintendoage.com/faq/nerdy_nights_out.html
-
neilbaldwin
- Posts: 481
- Joined: Tue Apr 28, 2009 4:12 am
- Contact:
Totally. Sporky is right: you're going to have to get your hands dirty 
I have to say though, 6502 is far from a difficult language to learn. I've learned a few assembly languages over the years (6502, 68000, Z80, SPC700 etc.) and 6502 is a nice one to lose your assembly virginity to.
Plenty of help and support around and plenty of example code even just here on nesdev.
Jump in, the water's lovely!
I have to say though, 6502 is far from a difficult language to learn. I've learned a few assembly languages over the years (6502, 68000, Z80, SPC700 etc.) and 6502 is a nice one to lose your assembly virginity to.
Plenty of help and support around and plenty of example code even just here on nesdev.
Jump in, the water's lovely!
I'm still laughing because of this sentence! But it's true, I agree 100%.neilbaldwin wrote:6502 is a nice one to lose your assembly virginity to.
Instead of repeating myself, I'll ask you to read something I wrote to someone in a situation similar to yours.
IMO, assembly isn't even the hardest thing about programming the NES, mastering the PPU is much harder. If you have the balls to do it, you can learn 6502.
- Be a viking: use an hexa editor to write NES programs. ^_^;; /joking
A buddy of mine on IRC is making an epic MM3 hack. He's pretty much rewritten everything at this point:Celius wrote:Oh my god... That would be such a nightmare to write NES games with a hex editor. Maybe making a simple hello world demo wouldn't be SO hard, but anything beyond that is crazy. Then when you have a bug, good luck fixing it.
- MMX style E tanks
- slopes
- switch to MMC5
- redesign level format to use ExAttributes
- cutscenes, dialog text
- English/Japanese language selection
- MMX style life powerups
- etc, etc, etc
And no matter how many times I (or anyone else) tells him, he refuses to learn how to use an assembler. He's done everything in the hex editor in FCEUXD.
CC65 supports 6502 fully, but doesn't support the NES. So you could sort-of use it, if you don't mind doing the register writes directly in C (or inline asm).
NBASIC programs seem to be pretty much 100% basic, I think the register writes are done with PEEK/POKE but it does some weird hex to decimal conversion when it compiles, making it very strange to read if you want to see the generated asm.
NBASIC programs seem to be pretty much 100% basic, I think the register writes are done with PEEK/POKE but it does some weird hex to decimal conversion when it compiles, making it very strange to read if you want to see the generated asm.
In order to use an assembler that isn't an interactive assembler like debug.exe or the mini-assembler on the Apple II (built into the Integer BASIC ROM and the IIGS and Enhanced Apple IIe ROMs), you need to make the program that you're assembling relocatable. If you have the dedication of doppelganger, who disassembled and documented Super Mario Bros., you can do that. Otherwise, you have to rely on a hex editor or the glorified hex editor that is an interactive assembler.Disch wrote:And no matter how many times I (or anyone else) tells him, he refuses to learn how to use an assembler. He's done everything in the hex editor in FCEUXD.
That sounds awesome. I'll be keeping an eye out for that, should appear on RomHacking.net eventually?Disch wrote:A buddy of mine on IRC is making an epic MM3 hack. He's pretty much rewritten everything at this point:Celius wrote:Oh my god... That would be such a nightmare to write NES games with a hex editor. Maybe making a simple hello world demo wouldn't be SO hard, but anything beyond that is crazy. Then when you have a bug, good luck fixing it.
- MMX style E tanks
- slopes
- switch to MMC5
- redesign level format to use ExAttributes
- cutscenes, dialog text
- English/Japanese language selection
- MMX style life powerups
- etc, etc, etc
And no matter how many times I (or anyone else) tells him, he refuses to learn how to use an assembler. He's done everything in the hex editor in FCEUXD.
I can see doing hacking with just a hex editor though its easier with an assembler to assemble bits of code to insert manually. But coding a whole game that way just seems like a really bad idea.
On the subject of ASM, 6502 ASM is not hard to learn. Really you can learn it in a very short time if you've programmed in C before.
This hack sounds awesome but are you sure the guy is saying the truth ? We've seen were many guys hoaxing stuff in this style just to show off (remember the guy that "ported Sonic to the NES" ?).
For ASM hacks I've done, what I did is write the code in a text editor and write it in hex in the ROM - but all the hacks I did only change one routine or so.
6502 ASM is easy to learn, but hard to master. One is likely to be able to code quickly, but do it very inefficiently at first. Also different people find easier/harder to do different tasks. For example most guys play football better than me, but know less about coding than I.
For ASM hacks I've done, what I did is write the code in a text editor and write it in hex in the ROM - but all the hacks I did only change one routine or so.
6502 ASM is easy to learn, but hard to master. One is likely to be able to code quickly, but do it very inefficiently at first. Also different people find easier/harder to do different tasks. For example most guys play football better than me, but know less about coding than I.
Useless, lumbering half-wits don't scare us.
When you have a disassembly to refer to, editing a program in a plain hex editor is not hard at all. The annoying part would be if you need to move labels around, etc (unless it's all relocatable code, like tepples mentioned).
I can see how someone can stick with a hex editor while hacking something. When you've got a disassembly, the labels won't have real names, there seems to be no real advantage to typing JMP $8043 instead of $4C,$43,$80. You don't really need to know the byte for every opcode, just the main ones (and there are even patterns that make it possible to extrapolate different addressing modes). I've hacked NSFs enough to be able to read the most common opcodes in a hex editor, though I'm probably a little rusty by now.
But on the main topic here, I think it's gonna be hard to understand the NES hardware if you don't know AT LEAST a little bit of assembly. If there were libraries that would hide everything from you, then yeah I can see getting by without it, but as had been said it's a lot harder to come to grips with how the PPU works than it is to learn 6502 (was my first programming language). But there's a lot of info here as well as people who have been through the same learning process.
I can see how someone can stick with a hex editor while hacking something. When you've got a disassembly, the labels won't have real names, there seems to be no real advantage to typing JMP $8043 instead of $4C,$43,$80. You don't really need to know the byte for every opcode, just the main ones (and there are even patterns that make it possible to extrapolate different addressing modes). I've hacked NSFs enough to be able to read the most common opcodes in a hex editor, though I'm probably a little rusty by now.
But on the main topic here, I think it's gonna be hard to understand the NES hardware if you don't know AT LEAST a little bit of assembly. If there were libraries that would hide everything from you, then yeah I can see getting by without it, but as had been said it's a lot harder to come to grips with how the PPU works than it is to learn 6502 (was my first programming language). But there's a lot of info here as well as people who have been through the same learning process.