NXC

NXC, short for Not eXactly C, is a C-like programming language for the LEGO MINDSTORMS NXT, the programmable brick LEGO sold from 2006. John Hansen, who already maintained the Bricx Command Center IDE and the later versions of NQC, wrote it on top of his own NXT assembler, Next Byte Codes (NBC). As with NQC on the older RCX, NXC does not replace LEGO’s firmware. It compiles to the bytecode that LEGO’s own NXT virtual machine already runs, so NXC programs sit on the brick next to programs made with LEGO’s graphical NXT-G software. The project’s home page sums up the idea in one line: “NXC is basically NQC for the NXT.” For about five years NXC was one of the main ways to program the NXT in text, and its reference guide grew to more than 2,400 pages of documented API.

History & Origins

From NQC to the NXT

Dave Baum’s NQC had become the standard text language for LEGO’s first MINDSTORMS brick, the RCX (see the NQC page). By the mid-2000s its development had passed to John Hansen, whose Bricx Command Center (BricxCC) project on SourceForge, registered in December 2002, distributed the NQC 3.x releases. When LEGO announced the NXT as the RCX’s replacement, NQC could not follow. The NXT used an ARM-based brick with a completely different firmware and bytecode, so a new compiler was needed.

Hansen started with the low level. The NBC changelog begins with “NXT Bytecode Compiler version 0.1.3.b1”, built on 2 May 2006, before the NXT reached shops. NBC is an assembly-style language that maps closely onto the NXT’s opcodes, and by August 2006 it had reached version 1.0.1. Writing robots in assembly is not much fun, though, so the obvious next step was a higher-level language on top of it.

The first NXC

That language arrived in NBC 1.0.1 beta 12, released on 21 November 2006. The release notes introduced it modestly:

NBC also now supports a very early version of the NXC programming language. This language is a lot like NQC syntax-wise. It is still in its infancy so it is subject to substantial change and improvement. The NBC compiler converts the NXC code to NBC code and then compiles it as it would any other NBC program.

That architecture never changed. NXC was never a separate program. It is a front end inside the NBC compiler, chosen by giving the source file a .nxc extension. NXC emits NBC assembly, and the NBC back end turns it into an .rxe executable for the NXT.

Development was fast. Beta 13 followed three weeks later with do-while and repeat loops “as found in NQC” and asm blocks for inline NBC. The changelog records twenty-two beta versions, b13 to b34, between December 2006 and November 2007; the home page news list dates most of them, at times several in a single week.

Design Philosophy

The NXC Programmer’s Guide opens with almost the same disclaimer as its NQC predecessor:

Although the preprocessor and control structures of NXC are very similar to C, NXC is not a general-purpose programming language - there are many restrictions that stem from limitations of the NXT bytecode interpreter.

The design follows a few clear principles:

• Keep LEGO’s firmware. NXC compiles for the standard NXT virtual machine, so a user can switch between NXC and LEGO’s own software without reflashing the brick. Hansen also maintained an enhanced NBC/NXC firmware that added opcodes, such as native shifts, more maths functions and extra file and high-speed-port system calls, for users who wanted more. The compiler targets it only when asked, with the -EF switch.
• Look like C, feel like NQC. NXC keeps NQC’s task, start, stop, repeat and until, so RCX programmers could move over easily, but on the NXT’s more capable VM it could offer far more of real C: return values, many data types, structs and local variables.
• Separate language and API. As with NQC, the guide defines NXC in two parts: the language (syntax and statements) and an API of functions, constants and macros in a header file that the compiler includes automatically. Much of the API is written as macros and inline functions containing asm blocks of NBC code.
• Stay close to the metal. Because NXC is a layer over NBC, a programmer can drop into assembly at any point with asm { ... }. This gives full access to the bytecode, which the API itself uses heavily.

Key Features

Program structure

An NXC program is made of global variables, tasks and functions. A program must have a task called main, which starts when the program runs. The guide explains that “a task in NXC directly corresponds to an NXT thread”, and tasks are usually scheduled with the Precedes and Follows API calls or with start and stop.

Functions, unlike NQC’s, can take typed arguments, including by reference, and can return values. A function marked inline is expanded at every call site. Other functions become real NXT subroutines, and the guide caps tasks and non-inline functions at 256 combined. Recursion is not allowed: from 2007 the parser rejects recursive calls “since they are not supported by the NXT firmware.”

A taste of NXC

This program drives a two-motor robot forward until a touch sensor on port 1 is pressed, then reverses for one second:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

task main()
{
    SetSensorTouch(IN_1);          // touch sensor on input port 1

    OnFwd(OUT_AC, 75);             // motors A and C forward at 75% power
    until (SENSOR_1 == 1);         // wait for the bumper

    PlayTone(440, 200);            // 440 Hz beep for 200 ms
    OnRev(OUT_AC, 75);
    Wait(1000);                    // time is in milliseconds
    Off(OUT_AC);

    TextOut(0, LCD_LINE1, "Bump!");
    Wait(2000);
}

until is defined in NXC as a macro, #define until(c) while(!(c)), kept “for compatibility with NQC”. TextOut writes to the NXT’s 100×64 LCD, which the RCX did not have.

Data types

NXC has a much richer type system than NQC, which offered only 16-bit integers:

Concurrency made safer

Because tasks run as real threads, two tasks calling the same function at the same time could interfere with each other. NXC’s answer is the safecall keyword, added in 2007:

1
2
3
4
5

safecall void beep(unsigned int frequency)
{
    PlayTone(frequency, SEC_1);
    Wait(SEC_1);
}

The compiler wraps every call to a safecall function in Acquire and Release on a hidden mutex. A -safecall command-line switch applies this to every function in a program.

Sensors and third-party hardware

The NXC API grew to cover far more than LEGO’s own sensors. Beta 35’s notes, for example, list functions for HiTechnic’s iRLink (driving LEGO Power Functions motors and IR trains) and for several Mindsensors devices. Later releases added the HiTechnic IRSeeker 2, Color 2, EOPD and touch multiplexer, and the LEGO Color sensor from NXT 2.0.

Evolution

Dates come from the project’s own news list, release page and SourceForge uploads; these occasionally disagree by a few days (1.2.1 r1 is 10 May 2010 in the news list, 13 May in the changelog and 14 May on the release page). Beta 36 never had a separate release on SourceForge; its changes shipped in 1.2.1 r1. The floating-point work answered a change on LEGO’s side. NXT 2.0, launched in 2009, came with firmware that supported floats, and the NBC changelog for this period says the compiler became “compatible with both 1.0x firmwares and 1.2x firmwares”, with the default target moving to firmware 1.28.

The same compiler also grew languages beyond NXC: NPG, a tiny language for the NXT’s on-brick “NXT Program” (introduced alongside NXC in b12); RICScript, for describing NXT image files; and SuperPro C, for HiTechnic’s SuperPro prototyping board. The compiler was distributed as source and as executables for Windows, Mac OS X (universal binary) and Linux (ia32), under the Mozilla Public License.

Current Relevance

The original project stopped after 1.2.1. The release page still names 1.2.1 r5 (18 October 2011) as current, but the home page’s news list never moved past “TBD, 2011 - NBC 1.2.1 r5 is (not yet) available”, the r5 download links now return errors, and the SourceForge file area ends at r4 (March 2011). Whether r5 was ever publicly distributed is therefore unclear. Hansen’s later test builds of BricxCC, from 2012 and 2013, worked on support for LEGO’s next brick, the EV3, but they target native ARM Linux executables built with a C cross-compiler, not NXC. The NXT itself was replaced by the EV3 in 2013, which is why NXC is listed here as historical.

NXC is still usable. Debian and its derivatives ship the nbc package (1.2.1 r4), which the Debian LEGO Team was still updating in 2026, and the 2011 NXC Programmer’s Guide and API help remain online at the project site. Anyone with a working NXT can still compile and download NXC programs on a modern Linux system.

Why It Matters

NXC carried the NQC tradition, a free, hobbyist-written text language that respected LEGO’s own firmware, from the RCX into the NXT era. It also showed how much the hardware had improved: where NQC was limited to 16-bit integers and functions without return values, NXC could offer floats, strings, structs, typed functions and mutexes, all compiled for the same kind of vendor bytecode VM.

Its layered design, a C-like front end compiling to a readable assembly language, made it a good teaching tool. Students could write in a familiar C syntax and then look at the NBC code it generated, or write asm blocks by hand to see exactly what the NXT executed. Together with Hansen’s book, Benedettelli’s tutorial and the BricxCC IDE, NXC was one of the main routes into concurrent, embedded programming for a generation of MINDSTORMS hobbyists, students and robot builders.