Development Languages

What languages have been used to develop games for consoles over the years? I know that people worked directly with assembly for the NES, and probably for the SNES too, but what about the N64? Were things fast enough yet that they could use C (and maybe C++?). What about the GBA? (I assume that for the GB and GBC, people used assembly directly.)

Assembly code (mostly) and C for all mentioned consoles. C++ - maybe for N64.

There were rare cases of more exotic languages, mostly among hobbyist devs, like Lisp for NES.

GBA can run C or any other subset of C++ where exceptions and dynamic casting are turned off at the compiler. Audio mixers, software 3D engines, and other time-critical code were written in ARM assembly language and loaded into a limited amount of fast RAM. PS2 can run Lisp, like in Jak and Daxter. Several games for modern platforms are written in Lua on top of a C++ engine. All Xbox 360 games from small developers are written in C# due to the .NET CF platform's lack of P/Invoke and Emit.

Lisp? That seems like an odd choice for such an old machine...


So, the C++ compiler for GBA supports/supported inheritance (and virtual methods, etc)?


By modern platforms, you mean XBox360, PS3, and Wii?

What did the generation before (XBox, PS2, Gamecube) commonly have used? What about the PS?


What are "invoke" and "emit", and why does their lack prevent using another language?

* * *

Is it only concern about speed that prevented people from using higher-level languages? or the lack of tools, perhaps? I remember seeing some game for the NES here was made with cc65's C compiler, and it didn't (seem) to have speed issues.

Are you kidding ? I tried to make a program that basically writes text on the screen, and even that was too much to handle, it lagged.

Well, here's what I was talking about: viewtopic.php?f=22&t=7999

Maybe it hides its lag behind the text that flashes multiple times before loading the next level.

You must have been doing something wrong. Shiru's games don't have any lag. Also in KNES I have included a basic platformer demo which is entirely written in C (Shiru's games use an assembly library), so if you have trouble with showing text on screen, I don't know what to say.

Lisp was just a cool enthusiast's experiment. Learn more.

It is quite abstract question if C on the NES has performance issues. Compiled code is of course slower than hand written assembly code, few times slower - so 'yes' in this regard. However, a game may not require 100% of CPU time and work full speed, smooth, etc, even with not very effective code (it won't help anything if there will be 60% of free CPU time in a game) - so 'no' in this regard.

Yes, mostly assembly for a long time for games on all systems. C came in to use a lot earlier for home computer games, but a few developers were still writing in mostly assembly well into the 90s.

There are a few rare examples on the NES that it has been suggested were using some C (e.g. Koei's Romancing Saga II).

I think most PC game developers were moving into C maybe around 1990. For consoles, more like 1994. Many were using C for PSX.

Nowadays C++ is pretty dominant, I think it took hold in the late 90s, not sure when.

(This is all based on personal anecdotal experience with old game source, and developers I've talked to. I don't know anything about N64 or GBA stuff, so I won't comment there.)

This is not true. The XNA platform requires C#, as I understand, but outside of XNA C# is not typically used for 360 development. C++ is the standard language for 360.

The vast majority of games commercially released for 360 are written in C++. Perhaps you could limit your definition of "small developer" to someone who is using XNA. Probably anyone who can't get access to a 360 devkit is going to use XNA, but we should be clear about how "small" the small developer has to be.

Of course I know that compiled code is slower than hand-written assembly code. I was (and am) asking about whether real games were written in asm or not, and if they were, would the speed loss gained by using compiled code be as big as feared and that the game would be reduced in quality?. Of course, I realize that this answer will vary from game to game.

Thanks for the all the responses so far.

The C++ compiler for GBA was either GCC, Green Hills, or any other C++ compiler supporting ARMv4 and Thumb.


In programs that mix native code and managed (CLR) code, P/Invoke is the way that a module compiled to CLR bytecode calls a module compiled to native code. The trouble is that standard C and standard C++ cannot be compiled to CLR bytecode; it must be compiled to native code. This rules out using standard C or standard C++ in the Xbox Live Indie Games or Windows Phone 7 environment, neither of which allows the use of native code.

Emit is the way to create CLR bytecode at runtime. Languages that use the Dynamic Language Runtime, such as IronPython, use Emit for something, and I'm not sure what. The trouble is that the .NET Compact Framework, used by the Xbox Live Indie Games and Windows Phone 7 environments, does not implement Emit. This rules out using IronPython and other DLR languages in those environments.


Speed and tools are part of it, but memory use is another. In a lot of cases, the available C compiler generates substantially larger code, which hurts if you're trying to squeeze a lot into one PRG ROM bank.


Not always. Some platforms, especially x86 and ARM, have enough engineers working on the optimizers that they approach native code, but the 8-bit microprocessors aren't among them.


This is true of NES, not of Game Boy or anything else battery-powered that lets the CPU enter a low-power state during free CPU time.


The exact moment when it changed was sometime during the Jaguar's life. When porting Doom, someone figured out how to make a C compiler work around the broken instruction cache of the Tom CPU.


That's exactly what I meant by a small developer. Remember that my audience ended up including someone who had never heard of basic .NET Framework concepts such as P/Invoke or Emit and was thus unlikely to have heard of XNA. As I understand it, the console makers' developer qualifications are designed to poach developers from other platforms, not to nurture startups. To get the devkit for Nintendo platforms, for example, a company has to have a dedicated secure office and a previous commercial title on someone else's platform, and I don't imagine that PlayStation and Xbox are any different.

I was ninja'd four times in a row while writing this comment.

The qualifications for getting developer hardware from Nintendo, Sony, or Microsoft are arbitrary. The real qualification is not really having an office or something like that (even though that has been used historically as one of Nintendo's arbitrary reasons); the bottom line is whether they think you have a viable business strategy.

Anyhow I just wanted to be clear that most XBLA games by developers that you might consider "small", like Super Meat Boy, or Braid, are written in C++ and do not use the XNA platform. However, the XBox Live Indie Games service is entirely XNA/C#, so far as I know.

On the subject of rom banks, when did rom banks stop being used? N64/PS era (They had 32-bit physical addressing, iirc.), I assume? Then again, I suppose that CDs and DVDs are like rom banks somewhat...


When you say this, what does it mean exactly? C++ has many features that are obscure and difficult to use. Do they just restrict themselves to a subset of the language? (But one that's a superset of C.)

Sega Genesis doesn't use banks (expect for 1-2 games), it has a huge chunk of linear memory.

C++ isn't strictly a superset of C, but the differences are subtle enough that it's not really wrong to say it is.

C++ is much more complicated than C, and yes it has a lot of obscure features, but the primary feature of C++ over C is classes, and specifically the inheritance of virtual functions in derived classes. This feature is used heavily in modern code. You can write C++ without classes, and there are several other useful features of C++ (templates, const, operator overloading, etc.), but really its reason for being is classes.

In general, people who choose to use C instead of C++ do so for a specific purpose. Sometimes it's because they are working on a specific processor that doesn't yet have an effective C++ compiler. Sometimes it's because they specifically want to avoid the complexity of C++ (e.g. the Linux Kernel).

Alternatively, there's Java, which is more focused on classes and that kind of high level feature set that C++ has, but with a lot less complexity than C++ because it's not built on top of a low-level language like C.

The last systems to have ROM banks would be GameBoy/GameBoy Color and SNES. SNES doesn't need a banking controller, though they did exist. But you still have banks in the 65816. GameBoy Color lasted a bit longer than the SNES though. N64 didn't have them as it had a multiplexed bus and didn't actually execute from ROM as far as I've heard. The Cartridge was used more like an attached Disk. And CDs and DVDs are not like rom banks at all. They are just discs. ROM banking responds instantly. Look at Castlevania on NES. Data is accessed as fast as the 6502 can call for it. Then look at Castlevania on Famicom Disk System. It takes time to load and only so much can be loaded at once. Not very alike other than being a method to access more information.

I've heard people say that PS1 games can sort of function like Cartridge games in the way they load memory and then run, but this is more like the old Famicom Disk setup again. Only not as limited obviously.

One last note, I do not know when the NeoGeo Pocket existed but it may have used ROM banks, I don't know though. Also there was the Wonderswan but again I have no idea. As previously stated, cartridge systems that did not use ROM banking or did not do so very much would include Sega Genesis and N64 but probably some other less known ones.

In volume, CD ROMs are much cheaper to manufacture than cartridges, which was the biggest reason for switching to optical media like that. The other is they have huge storage capacity, but that was secondary. The other thing you need to support this is enough RAM to store all the code and data you need to access quickly at any given time. So, once CD-ROM and RAM technology had gotten cheap enough, there was little reason to manufacture cartridges anymore. (Handhelds kept using them for durability, i.e. lack of moving parts.)

I don't understand the statement that PS1 used the CD "like a cartridge" either. Though, many early PS1 games would load most of the game into RAM, and then just use the CD for audio. You could take out the CD after starting your game, and put in your own audio CD to change the soundtrack in some games (until it needs to load a new level).

I think that the comparison was in the sense that with CDs and DVDs you have to copy sections of data to RAM before you can use them, so that block of RAM is somewhat analogous to a ROM bank that's currently selected (i.e. in both cases you don't have immediate access to the complete data). Obviously, selecting a new bank in is much faster than loading data from a CD or DVD.

The Super NES in mode 21 had a big 4 MB linear ROM from $C00000 to $FFFFFF.
The Genesis had a big 4 MB linear ROM from $000000 to $3FFFFF.
The GBA had a big 32 MB linear ROM from $08000000 to $09FFFFFF, but like the N64, it had an interleaved bus so consecutive access were faster.
The DS is like a PS1: the Game Card is read like a disk, well maybe a really fast disk like an SD card, and data must be copied into the 4 MB RAM before it can be used. The PSP Go and PS Vita work the same way. One DS game (Nintendo DS Browser) required an accessory that added an additional 8 MB RAM in the GBA slot.

SNES memory is not truly linear, at least from 65816 and assemblers standpoint, unlike Genesis. It has either 32K or 64K banks. You can easily put, say, 200K of linear data in a Genesis program without any effort, but you'll have to split it into pieces for a SNES program.

As I understand it, Mode 20 data has to be split into 32K banks: $808000-$80FFFF, $818000-$81FFFF, ... Mode 21 data, on the other hand can be accessed linearly. True, the program counter won't cross 64K boundaries, and there's a penalty for 64K boundary crossing in indexed addressing modes analogous to the penalty for 256 byte boundary crossing on the 6502. But what am I not seeing? If it's a problem with the assembler and linker not supporting what used to be called "huge" arrays back in the days of 8086 real mode, that was a problem with some 8086 tools too, and tools can be fixed.

32K or 64K, banks are still banks. Not much difference, actually. I'm not interested in digging into technical details, I'm just telling as a programmer that worked with Genesis and SNES: handling large amounts of data is way easier on the Genesis, just like on modern PC, and on the SNES it is quite similar to the NES.

Using CD-DA instead of ADPCM (either VAG or XA) would be a pretty bad design choice (even if several games did it) :
- You can't loop a song without having it stop then restart
- Takes 4 times more space on the CD

The only pro is that you can listen to the music with a regular CD player.


I just wanted to add that this is totally true. It's in fact the opposite of ROM banks : Instead of switching the data in several clock cycles or so, you need to load it off the disc which is much, MUCH slower, and can't be done many times a frame like bank switching does.


Some opcodes allows you to use 24-bit addressing, removing the overhead of bankswitching.


Yes, this should be especially interesting for homebrew. Distributing burned CDs is like 100 times easier (and cheper, which is important if you don't make profit, as the end product will also be cheaper) than manufacturing cartridges.

The TurboGrafix-16 / PC-Engine indeed looks like an interesting platform for homebrew as it can support CDs. Unfortunatly it wasn't released in Europe, so almost nobody has this console except collectors.

Yeah, I didn't say it was a good idea. It was done in many games though (and that list isn't complete by any means).

Many games on that list (and not on that list) just contains 1 single "trivia" track which is not actually used in the game.

They're quite easy to find though. Consolegoods are selling unused/boxed PAL versions of the TurboGrafx for around 80 EUR.
If you want a TurboDuo (HuCard and CD-support all in one unit) the price will probably double, and you'll most likely have to settle for a used NTSC unit (not that NTSC/PAL matters that much unless you plan on using it with a very old CRT TV).

It should be noted that some TurboGrafx 16/PC-Engine CD systems do not like CD-Rs. Some will end up getting the laser sled *stuck* at the outter end of the track. I had a PC-Engine DUO that would have that happen with particular burned games. However atleast one homebrew game has been Factory Pressed. And a second one they are trying to get pressed.

The second game is already pressed and done, but they are doing the bonus material on CDR IIRC. It should be noted that Nero has been found to do some weird things when the game is in ISO/WAV/CUE format. On some setups, it seems to ignore the 'MODE' assigned to the data track and instead burns it using a newer mode and really gives problems for some TGCD systems. The trick is to analyze the CDR and make sure it's not burned as MODE 2 data (I forget which form off hand), but as MODE 1. If you give Nero a BIN/CUE, the sector format is preformed and Nero will burn it as MODE 1. None of my versions of Nero have done this, but others have confirmed this problem. The current solution was to mount the IUSE/WAV/CUE in a virtual drive then rip it as a BIN/CUE, then burn it. It's amazing the Duo units can even read MODE 2 form 1 (or form 2, I forgot).

It's not recommended to use a PAL Turbografx with a CD unit. For one, I know of no one that has one so your base will be null and two - PAL TGs have different timings and some CD games will be effected by this (possibly a few hucards as well). The PAL units are a collector/novelty thing; stick with NTSC/J machines. Turbo Duo or PC-Engine Duo units (all in one CD unit) are the best option. There are plenty of info on the system about caps and repairs and plenty of experienced people that offer services for repair. The laser modules are replaceable too.

If you buy a US TG16 and then later decide you want a CD unit, then the original US CD addon will run you quite a bit of money. You can use a japanese cd addon but you'll have to make your own cable for as the connector shape is slightly different and it'll look terrible as combo. A white PC-Engine or grey Core Grafx unit would be a good choice for a first initial Hucard only investment, then a SuperCDROM^2 unit can be purchased later (it already has the system card built into it and is able to use the Arcade Card Duo which is cheaper of the arcade cards). I personally think the SuperCDROM unit has a better laser unit than the Duo's. I've never heard of or seen one get the 'parked laser' issue like some original Duo units (the Duo R and Duo RX are white model Duo units and are the last revision hardware to be made, thus supposedly the best laser units too) that haven't had a replacement laser module. Stay away from the 'breifcase' japanese CD addon; it's the original CD addon unit and probably well worn/has issues reading CDRs.

This is true for most consoles/add-ons actually, they hate CD-Rs by general rule as the laser barely has enough power to read pressed discs and more often than not will have trouble reading CD-Rs as the laser needs to be stronger (and CD-RWs outright aren't recognized). This is true even for the Dreamcast, which should be relatively new for CD technology.

Never had that problem with my japanese Saturn though. But maybe that varies between different units and/or brand of CDs.
Would be cool to have a CD-ROM emulator that reads data from an SD card as a replacement for the drives in these systems when they eventually fail (because the CD-ROM drive is probably one of the first things that will fail).

I have dozens of Dreamcast games and only 2 of them are original. Never had any problems. With CDs at least, the controller port on the other hand has been dead for a while.

Yeah I had the same idea when I was cursing the CD-ROM drive of my PSX. I briefly thought about attempting to make an emulator like that, but didn't start on it because the connector is probably proprietary and I don't have the skills needed to do reverse engineer the hardware.

Indeed, Java's more focused on classes and avoids all the baggage that C++ has to carry for backwards-compatibility. But even Java's still stuck in some strange middle-ground by insisting on having static variables and methods. Scala did it right by replacing them with singleton objects (and introducing functional programming concepts). It may sound silly, but many times I've wished to inherit a static method, and singleton objects effectively do just that. Of course there's work-around ways to do these things in Java, but there's work-around ways for having classes in C too, it's what they're compiled down to after all!


For some reason, I was thinking that the SNES had a 65C02.


24 bits lets you address 2 MB of memory. Didn't most games fit in those 2 MB? What is a banking controller? Is that like the memory-mapped inputs that the NES had that you write to to change banks?

2^24 Bytes = 16 Megabyte.

For some reason I thought bits instead of bytes. Yes, you're right, 16 MB.

While they certainly read a pressed disc better, many CD consoles will read good quality CD-Rs just fine. The PS1 has some interesting issues that some attributed to playing CD-Rs. Early versions had the CD lens assembly close to the power supply where most of the heat was generated. The heat over time would warp the plastic and could cause alignment issues that would cause reading problems. Newer models use different material less vulnerable to this and other later models move the position of the lens further away from the power supply.

I've tried CD-Rs on every system I've had access to and they all worked to some degree. Sometimes they are picky about the type of media you use and your burner matters too. GameCube was pretty picky. PS1 as well wouldn't let you use bargin crap CD-Rs. DreamCast did though. I remember using Office Depot crappy CD-Rs just fine. The Sega Saturn seemed to read anything I threw at it too. PS2 I think was a bit more picky. Sega CD seemed to eat up whatever you threw at it. PC-Engine like PS1 wouldn't let you be cheap. But these are just my observations, I never did any scientific test. So I'm not sure what you mean by hate CD-Rs. The machine can't hate, it's a machine. It may have trouble reading low quality CD-Rs though. But most systems will if you have the right media and burner.

Xbox1 will almost never read a CD-R and about half of xbox1 DVD-ROM drives will not read DVD+R. (All will read DVD-R.)

The fun thing is, my PS-One read music CD-R perfectly fine without any skipping problems, but game CD-Rs have some problems. They work, it's just there is occasional read errors, which causes some skipping in music and FMVs.

My only guess is that those occasional read errors only happen when reading the CD at 2x speed, because that's the only technical difference between a CD being used for a game and for a music.

Well it's also a different format. Mode 2/XA I think.

Yes - but I meant the laser reads the bits the same way no matter what the format actually is - so the format should make no difference, why would games causes problem when a musical CD causes none ?

Reading speed is the only thing that could causes the problem. Perhaps someone could point me to a game which uses 1x CD-ROM speed for streaming it's videos (which is probably very rare - as the quality would suffer) and I could enforce this supposition.

Isn't audio CD players ignore any errors during read, which is may be acceptable for audio, but certainly not for data?

Both audio (CD-DA) and XA sectors uses whole sectors of 44100 * 2 * 2 / 70 = 2520 bytes, without correction data. Read errors can be detected, but not corrected, causing some skipping.

However I still have occasional problems with the streamed music in Suikoden, which is not XA, so it is probably stored in sectors with correction errors. Perhaps the Playstation still can't correct the read errors even with the correction data, if there is too much errors in one reading. The game should then retry to read the sector, but when the data can finally be read successfully, it's too late and it caused a glitch in the music.
Just an assumption.

I also have the game crashing sometimes which is very annoying.


EDIT : You are right there is not even a CRC or anything in the audio CDs, so read errors can't even be detected. I wonder how it comes CDs skips when there is read errors instead of playing some kind of white noise... does't make much sense

Of course, on CDs the physical pits themselves are encoded, 8 bits -> 14 bits or something like that, so that parity errors can be detected and the misread sample skipped over... that's why there's no white noise coming out of the CD when there's a scratch.

The EFM (eight to fourteen modulation) is for clock recovery and speed control, as it guarantees a transition from pit to land or vice versa no faster than every three units and no slower than every fourteen, not for error correction. There are two layers of error correction on a CD. Both audio CDs and CD-ROM have CIRC, or cross-interleaved Reed-Solomon coding. CD-ROM has a second Reed-Solomon ECC layer at the 2K sector level, and audio CD players trigger some sort of DSP waveform interpolation if a burst of errors is so long that CIRC fails to correct it.

The 6502's architecture does not seem to lend itself well to C. Fortunately, the same traits that cause this also make the '02 easy to envision solutions in assembly language. Here's an example of compiled C code, an empty count-to-100 loop, the line

with i defined as a char (1 byte). The equivalent BASIC line would be

The popular CC65 C compiler, which admittedly is not optimizing, produces the following 6502 code from it. The comments were added by hand, not by the compiler.

all for what can be done in assembly language with only:

which, besides being less than one-seventh as many bytes, has no subroutine calls to eat up even more time like the compiled C version did.

Since the index value is not used inside the loop, we could further shorten the code by starting at 100 and counting down, to zero, to get the same number of loop iterations. We'll use DEX, which like many other instructions, has an automatic, implied, compare-to-zero instruction built in, so we can omit the CPX #0:

Clearly the assembly-language version will absolutely fly compared to the compiled C-language version.

I'm sure a much better C compiler could be written for the '02. Perhaps there is one and I'm just not aware of it. The above is from the middle of my web page, "Assembly Language: Still Relevant Today." An experienced programmer came across it last week and emailed me saying he was working on a 68020 around 1990 and they were looking for the C compiler for it that put out the fastest-performing code. One thing they tried was an empty count-to-10,000 loop, and timed it. Zero. What? So they tried 10,000,000 instead. Still zero. It turned out that the compiler was smart enough to see that the loop did nothing, so it compiled no code for it. Unless the desired delay is super short, a loop is usually a very poor way to get it; but if a programmer knew what the compiler should put out, he might have a very good reason for the empty "for" loop, and wouldn't want the compiler to delete it.

I remember reading, back then, about compilers trying to optimize things to make their compiler look better than the competition's. They watched for various things you might want to do, particularly well known benchmarks and tests, and replaced them with the hand-optimized version strenuously written by the few programmers who knew the processor a lot better than the customer would. My reader commented that that was "a bit naughty."

If you add -O to the command line it will do a bit better job than that.

You can to still better with a few very minor changes to your code:

• use an unsigned char instead of an int (always a good idea to use 8-bit unsigned when you can)
• use a static variable instead of a stack based variable (cc65's simulated stack is slow)
• use ++i instead of i++ (i++ has a delayed side effect that carries a slight penalty)
• use -O flag in command line (yes it actually has an optimization flag, and it helps)

The result:


So, yes your naive C code compiled to something pretty horrible, but with a few hints to the compiler it gets a lot better. It's never going to get as good as assembly, but it's usually not that hard to get it to behave a lot better than what you were looking at.

Garth, you necro 5-year old topics regularly...

What I keep wondering is why does cc65 produce such inefficient code without the O flag. Is there any reason whatsoever that somebody might want to compile without that flag with cc65?

(It's not like some compilers where optimizing produces weird hard to understand assembly... It seems the opposite here, the unoptimized is weird and hard to make sense of, and the optimized produces normal looking code)

Nothing wrong with that IMO, so long as he's adding useful things to the discussion. Anyway, we necro 30+ year old consoles


From the perspective of the compiler writer, I imagine the transformation without "-O" is more straightforward and thus less likely to be buggy. If there's an issue with some generated code, it's helpful to know whether the problem is in your optimizer or somewhere earlier in the compilation chain.

Yeah, I think that's it. With CC65 there's no reason not to use -O, really, unless you're trying to debug the compiler.