Assembler

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Assembler
by on (#159258)
For original homebrews, what assemblers are available? Are there directive pragmas in the assembly language to specify the values normally found in the iNES header?
Re: Assembler
by on (#159259)
NESASM3, ASM6, and ca65 are all popular.

Making a header in each of this is rather trivial.

I'm very partial to ca65, myself.
Re: Assembler
by on (#159260)
zeroone wrote:
For original homebrews, what assemblers are available?

The most common assemblers in use here are:

NESASM - Easy to setup and use. Has commands to easily setup the iNES header. Has a few annoyances, like different syntax from all other 6502 assemblers for a few things, and the code must obligatorily be divided into 8KB banks.

ASM6 - Just as easy to setup and use. More flexible than NESASM since it doesn't force you to structure your ROMs a certain way.

CA65 - Harder to setup (requires a configuration file to organize memory the way you need for each program), needs a lot of getting used to if you want to use the advanced features. Very flexible and powerful.

Quote:
Are there directive pragmas in the assembly language to specify the values normally found in the iNES header?

Only NESASM has built-in header generation, but people have made macros for the other two that greatly simplify the creation of iNES headers. Not that this was complicated to begin with, it's just 16 bytes you setup in 5 minutes and completely forget about them during the rest of the development of the game.
Re: Assembler
by on (#159282)
Is CA65 a C compiler? It's possible to develop NES games in higher level languages?
Re: Assembler
by on (#159283)
cc65 is a C compiler.

ca65 is an assembler that is part of the cc65 toolchain.

You can use ca65 by itself, or in combination with cc65. Yes, there are several efforts to write NES software in higher level languages.
Re: Assembler
by on (#159284)
zeroone wrote:
It's possible to develop NES games in higher level languages?

Yes, but the generated code is generally not as efficient as hand-coded assembly. This means you probably won't be coding something like Super Mario Bros. 3 in C, but games that don't demand as much processing per frame should be possible. Shiru coded the games "Alter Ego" and "Zooming Secretary" in C (and has released the source code), if I'm not mistaken.
Re: Assembler
by on (#159290)
The games that the Mojon Twins have released are also all mostly-C and come with source. They're all licensed under CC-BY-NC-SA (v3).
Re: Assembler
by on (#159303)
Various high level NES stuff:

Shiru's NES C (cc65) guide: https://shiru.untergrund.net/articles/p ... s_in_c.htm

Python on the NES: http://gutomaia.net/pyNES/

Forth on the NES: viewtopic.php?f=2&t=10371

High level assembly for the NES: http://neshla.sourceforge.net/

There's more if you dig deep enough.


Some of my own examples:

my own cc65 C example: http://rainwarrior.ca/music/coltrane_src.zip

my own ca65 example: viewtopic.php?t=11151
Re: Assembler
by on (#160290)
There is also my own version of NESASM (called "Unofficial-MagicKit") which has several improvements (although it is compatible with standard NESASM too); it may be confusing to many people who are not used to it though. Nevertheless, it is my own preference. (One of its new features is support for NES 2.0 headers if you want to use them, although I am sure ca65 can make NES 2.0 headers too)

There are other assemblers than those listed above, although I don't really know what they are; the common ones seem to be NESASM, ASM6, and ca65. (If anyone uses another assembler, let's see)

Please note that if you use NESASM (whether the official version or my version), that it uses the different syntax from other assemblers (it uses square brackets for indirection, and require explicit zero page addressing). I believe this NESASM syntax is better, although it is nonstandard and some people may not want the explicit zero page addressing.

If you like to use advanced macro capabilities, then ca65 or Unofficial-MagicKit will do (they have almost entirely different macro systems, although they are both capable of a lot of things; Unofficial-MagicKit supports custom output routines too, which are separate from (but are capable of using) macros).

A difference between ca65 and others is that ca65 is using modules that must be linked together while other will assemble standalone codes. (Which is better can depend on situations)
Re: Assembler
by on (#161542)
tokumaru wrote:
zeroone wrote:
It's possible to develop NES games in higher level languages?

Yes, but the generated code is generally not as efficient as hand-coded assembly. This means you probably won't be coding something like Super Mario Bros. 3 in C, but games that don't demand as much processing per frame should be possible. Shiru coded the games "Alter Ego" and "Zooming Secretary" in C (and has released the source code), if I'm not mistaken.


Weren't a few commercial games written in C? I seem to recall the Koei games were coded in C, hence their relative slowness
Did Micronics code in C or was it simply bad programming?
Re: Assembler
by on (#161546)
Vectrex2809 wrote:
I seem to recall the Koei games were coded in C

You can find printf style ASCII strings in some of the Koei games. They may have used C, or they may only have borrowed the printf idea from C. (Printf can be implemented in assembly too, of course.)

Personally I would guess that C was used for the initial version of some of their games (e.g. PC-88), but the NES versions could very well have been ported to assembly. It was pretty normal at that time to completely rewrite code for different platforms.