This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NES programming without Assembler actually possible?

NES programming without Assembler actually possible?
by on (#54842)
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?

by on (#54843)
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

by on (#54844)
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! :)

by on (#54848)
neilbaldwin wrote:
6502 is a nice one to lose your assembly virginity to.

I'm still laughing because of this sentence! But it's true, I agree 100%.

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.

by on (#54851)
When I tried writing Gameboy code in C, the compiler didn't offer any advantages over asm (although the library was pretty good). 16-bit math still had to be done in asm. I'm assuming it would be the same with CC65.

by on (#54855)
- Be a viking: use an hexa editor to write NES programs. ^_^;; /joking

by on (#54856)
Then Siudym is a Viking (see NESDev main page).

by on (#54867)
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.

by on (#54882)
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.


A buddy of mine on IRC is making an epic MM3 hack. He's pretty much rewritten everything at this point:

- 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.

by on (#54883)
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.

by on (#54928)
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.

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.

by on (#54932)
There are cross assemblers made specifically for rom hacking purposes.

xkas comes to mind. It doesn't assemble the whole rom, it just assembles your code and inserts it into an existing ROM.

by on (#54933)
Disch wrote:
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.


A buddy of mine on IRC is making an epic MM3 hack. He's pretty much rewritten everything at this point:

- 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.


That sounds awesome. I'll be keeping an eye out for that, should appear on RomHacking.net eventually?

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.

by on (#54942)
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.

by on (#54943)
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.
Re: NES programming without Assembler actually possible?
by on (#54944)
JohnJohn wrote:
(I'm asking because I searched the internet, but have never seen even an NES demo program written in C.)


There actually is one, there is a tetris game written by Groepaz in C. If look for his directory in the CC65 archive you will find it. It uses the conio library, and he also wrote a conio library for the NES - but the problem is that the library won't work on a real NES. Just on the version of FCEU that was available at the time.

by on (#54945)
It seems that most attempts at coding for the NES using languages other than assembly happened at a time when the NES wasn't so well known (technically, I mean) and it wasn't as easy to test programs on hardware, so later it was discovered that these libraries and tools were not compatible with actual consoles, only with the forgiving emulators that existed back then.

I don't want to be a dick, but I strongly believe that if a person can't learn 6502 assembly they will not be able to make games for the NES even if they use another language. Learning assembly is part of the process of understanding how the NES works, and if you can't handle that it's unlikely that you'll do anything significant with the system.

We have a few examples here of people that didn't even know any other languages before 6502 assembly and they turned out to be pretty good NES coders. This shows that it's never too late to learn assembly, and if you already program anything else you are even more likely to grasp assembly if you try hard enough.

by on (#54947)
Listen to tokumaru: he speaks the truth.

:)

by on (#54951)
I guess it all comes down to what motivates you. If your goal is to make a game quickly regardless of what platform you write it for, the NES is probably not a good platform for you. If your goal is specifically to make a game that actually works on a real classic video game system, then it may be worth the extra effort to learn assembly.

I know for me, it really came down to the fact that I loved the NES as a kid, still love it and play it, and thought there would be nothing cooler than making a game for it. Plus, it will be really easy to show what I make to others. Millions of people have a NES and even more people have an NES emulator on their toaster, cellphone, PC, dvd player or what have you.

So if that's the reason you're interested in it, I'd say go for it. Assembly isn't all that hard, especially if you do know C and are familiar with pointers and such. Beyond that, you will need to learn hex and binary number systems, bitwise operations, and 2's complement math is useful as well.

I learned those concepts from "Assembly Language: Step by Step" by Jeff Duntemann. He targets X86, but many of the concepts carry (heh) over so well to 6502 I recommend it to newbies to assembly language in general.

by on (#54963)
Alright, well, then it's Assembly.

Gradualore wrote:
So if that's the reason you're interested in it, I'd say go for it. Assembly isn't all that hard, especially if you do know C and are familiar with pointers and such. Beyond that, you will need to learn hex and binary number systems, bitwise operations, and 2's complement math is useful as well.

Those things are absolutely no problem to me. I never had problems with pointers. And I know binary, hexadecimal, bitwise operations and the two's complement quite well.

Now I have two more questions that I need to know in advance:

1. What's the best tutorial to read? I found a lot tutorials that teach you how to program the NES, but what is the best, the most complete and the most comprehensive one?

2. When I program an NES game, do I have to know how the game shall look like from the beginning? I mean, when I program with C++ or any other high level language, I can start making a game without actually knowing what the game will be like at all.
At first I start with general graphic stuff: Creating an image class, giving it methods to load a bitmap, to write its bitmap or a part of it to the back buffer with or without transparent background, to write the back buffer to the screen etc. (DirectX is not that convenient here, so a bit of selfmade encapsulation is necessary.)
Then I will create a level class on the logic side. (Like, a level internally consists of a two-dimensional array when the game has a top-down perspective.)
Then I will make the graphic part capable of diplaying the level that is represented on the logic part. (I still have no idea what the game will be about.)
Then I program a movable character class and let the graphic part display any characters in the levels too.
Then I can slowly think of what the game shall actually do. I derive classes from the character class so that I have a player class whose objects receive manual input and an opponent class whose objects move according to a certain pattern.
Then I can evaluate the game situation and make the game react to enemy touch (loss of energy or the loss of a life with the reset of the level), reaching the exit (loading of the next level) etc.
So, as you see, I can spend a huge time with programming the basic stuff and I still don't need to worry yet if the game shall become a "Pac-Man" or a "Zelda" or a top-down car race. I can decide that later and don't need to rewrite existing code, just add new stuff accordingly.
Is that also possible with NES programming? Or do I have to know exactly what I want the game to be since later changes would require a huge rewrite of the code?

by on (#54967)
JohnJohn wrote:
So, as you see, I can spend a huge time with programming the basic stuff and I still don't need to worry yet if the game shall become a "Pac-Man" or a "Zelda" or a top-down car race. I can decide that later and don't need to rewrite existing code, just add new stuff accordingly.
Is that also possible with NES programming? Or do I have to know exactly what I want the game to be since later changes would require a huge rewrite of the code?


For me there is some stuff (like the screen updating system, animation system, initialization, and sprite/sprite hit detection) that I wrote once and reuse forever with little modification (other than fixes/optimizations). Sounds pretty much like the stuff you listed, so yeah, programming the NES is just like any other system. The one thing you will want to know before though, is if you'll be scrolling horizontally, vertically, 4 directions, or 8 directions, if you want to allow scrolling backwards, stuff like that.

by on (#54969)
Memblers is right... the type of scrolling does affect the design of your game engine pretty heavily, so that's probably the first thing to get out of the way.

I'd say that although making games on the NES isn't that much different from other systems, it's a bit harder to make serious design changes later on. Good programmers will obviously try to make the different parts of the program independent of each other, but eventually, usually for performance reasons, things end up merging more than we'd like.

So I guess that if you want to avoid multiple recoding cycles, it's better that you start out with a good notion of what kind of game you want.

by on (#54972)
That, and make a prototype for the PC first if you want.

by on (#54976)
tepples wrote:
That, and make a prototype for the PC first if you want.

Sometimes that helps a lot, but other times I feel like it's a waste of time. For my raycaster I felt the need of prototyping, because it used a lot of pre-calculated values and I had to make sure those were correct. Also, the whole technique was experimental, so I wanted to make sure it worked.

But when the overall process is pretty clear in my mind, and the details can be tweaked in assembly without much trouble, I usually code straight for the NES.

by on (#54996)
For me, the absolute best tutorial for NES programming was Michael Martin's NES 101 tutorial. It has a complete program compilable by P65, an assembler written in perl. It demonstrates the basics of sprites, backgrounds, sounds and input. I think if you're already an experienced programmer, that's the best way to go.

by on (#55069)
Screw hex editing, I just thought of the craziest way to enter code.

Ready for it?

Use a tile editor.

by on (#55070)
strat wrote:
Use a tile editor.

Heh! Sometimes I use tile editors with my programs just to get a visual representation of how much space I have used and how much is left. When doing that sometimes I try to identify pieces of code just for fun, and unrolled loops are particularly easy to find! =) I'd never change anything there though...

by on (#55072)
tokumaru wrote:
Sometimes I use tile editors with my programs just to get a visual representation of how much space I have used and how much is left.

So do I. They're also good for finding blank spaces where .align is skipping too far, so that I can re-Tetris the code and put something useful in that hole.

Quote:
When doing that sometimes I try to identify pieces of code just for fun, and unrolled loops are particularly easy to find! =)

Switching among different consoles' tile formats can sometimes be good for finding compression formats. DPCM has a distinctive signature, as does Super NES BRR.
Re: NES programming without Assembler actually possible?
by on (#61156)
JohnJohn wrote:
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?


I guess this thread is a bit old already, the original poster didn't ever reply and the topic got to other issues, but if I may...
Although I agree with what was said here that the best choice to develop for NES is pure assembler, you actually can code in C for the NES.
I made a background+sprite+split scrolling demo and a metronome for the NES, to test a C library for CC65 I made, although it's very basic and I'm not working on it anymore.
But you actually can make demos and games with C.
I actually plan to re-write the library in assembler, so it's faster, but still has function definitions to call from C.
The bottomline is of course you can read and write from and to memory with C, you can compile for NES with cc65, so it's perfectly possible to write games for NES in C.
Will they be as efficient as if written in assembler? nope.
Although you should know that the NES support in cc65 is rather poor. By default it sticks an entire ASCII charset into the CHR-ROM, and implements printf and such functions that make no sense in the NES.
But with a little tweaking of config files, you can clean all that and make a decent NES program.

by on (#61166)
Here's a little platformer demo I wrote completely in C (including the music engine): http://thefox.aspekt.fi/super.nes

So it's definitely possible to write games in C, even something else than puzzle games. :) Although I must admit there's not too much CPU time to spare. I will release the source for the demo and the replacement CC65 NES library once I get the time to polish it up a bit...

Only parts that are written in assembly are:
- boot code
- controller reading (I wanted to include DPCM safe controller reading in my library so I used blargg's code)
- NMI handler (simply increases a variable in memory)

Oh, also note that the music was made with PAL timing in mind.

by on (#61169)
Hey, there's no need to polish it, just share the code, it will useful even unpolished.

by on (#61184)
thefox wrote:
Here's a little platformer demo I wrote completely in C (including the music engine): http://thefox.aspekt.fi/super.nes


That's pretty cool. I need practice C programming, it would be great if I could play around with the source.

by on (#61192)
In response to the NBASIC stuff, We need a new compiler, like a modified Batari Basic, Otherwise, Just ASM/C

By The Way: Two things about the Super.NES engine: Can you release it, and What compiler is it for use in? I am interested in a map editor and a renderer especially.