BasiEgaXorz

BasiEgaXorz is a BASIC compiler that targets the Sega Genesis. You write something that looks a great deal like QuickBASIC — % for integers, $ for strings, GOSUB, labels, DATA statements — and it produces a .bin ROM that boots on a real Mega Drive. It also produces Sega CD disc images and 32X ROMs from the same language. For much of the 2000s it was one of the few realistic ways for a hobbyist without 68000 assembly experience to get code running on Sega’s 16-bit hardware, and it is behind a good deal of the era’s Genesis homebrew, including one program that became genuinely internet-famous for all the wrong reasons.

Its name, which nobody pronounces the same way twice, has no documented derivation that survives; the community mostly just calls it BEX.

History and Origins

BasiEgaXorz was written by Joseph Norman, who published it under the handle DevSter, and distributed it free from his personal site alongside a forum for its users. Public releases are archived from around 2004 — version 0.19 was catalogued on Zophar’s Domain with an update date of 23 August 2004 — and CrazyBus, the best-known program built with it, also dates from 2004. The 0.19 version number implies a run of earlier builds, but no reliable date survives for them. The exact first release is not cleanly documented; 2004 is the safe answer.

The context matters. Sega Genesis homebrew in the early 2000s meant 68000 assembly, a scattering of incomplete hardware documentation reverse-engineered by the scene, and an assembler like SNASM68k that had been built for professional development years earlier. There was no SGDK, no supported C toolchain, and no beginner path. A BASIC compiler that hid the VDP register writes behind a Palette statement dropped the entry barrier dramatically — nobody measured by how much, but the difference between learning 68000 assembly and learning a dozen BASIC keywords is the difference between a project and an evening.

Early versions leaned on SNASM68k as an external assembler, which the user had to supply — a persistent source of friction, since the assembler’s behaviour varied across Windows versions. Version 1.23, announced on 20 February 2008, replaced it with ASMX specifically to fix those compatibility problems. The announcement billed it as “the ultimate BasiEgaXorz release,” which turned out to be optimistic: switching assemblers broke a great deal — ASMX did not silently reinterpret certain 68000 addressing syntax the way SNASM68k had — and the following months produced a run of fixes for heap corruption in INPUT and GETS inside functions, broken DATALONG handling, and expressions as basic as a = a * -1. Version 1.28 on 24 November 2008 consolidated those repairs and dropped the last external helper binary.

Version 1.37 shipped on 3 January 2010. Nothing followed it.

Design Philosophy

The compiler’s stated priority is speed, and everything else in the design falls out of that decision. From the documentation onward, the recurring theme is that BasiEgaXorz is aimed at speed, so effectively nothing is dynamic — everything is static.

That is not a hedge, it is the architecture. Variables are allocated at compile time. There is no heap allocator, no garbage collector, no runtime type dispatch, no dynamically sized arrays or strings. A Genesis has 64 KB of work RAM and a 68000 clocked at roughly 7.6 MHz; on a budget that tight, a BASIC runtime doing per-frame bookkeeping is a cost the documentation treats as unaffordable, so the runtime does essentially nothing. The compiler emits 68000 assembly, hands it to an assembler, and the result is a native ROM with no interpreter inside it.

The second commitment is that the language does not pretend the hardware isn’t there. BasiEgaXorz is not a portable BASIC that happens to run on a Genesis; it is a language whose vocabulary is the Genesis. Its statements talk about palettes, tiles, sprites, scroll planes, and joypads, and its numeric limits are the console’s limits. Palette <RGB code>, <palette number>, <color number> is a language statement, and understanding it requires knowing that the VDP has four palettes of sixteen colours each and that tiles are four bits per pixel. You are not insulated from the machine, only from writing the register pokes by hand.

Third, it provides an escape hatch and expects you to use it. The Asm "<instruction>" statement injects a line straight into the compiler’s assembly output. The BASIC layer is a productivity convenience over 68000 assembly, not a replacement for it, and the intended workflow when BASIC isn’t fast enough is to drop through the floor rather than to fight the language.

Key Features

A small, sigil-typed scalar model. Three types, in the classic BASIC style. Integers are 16 bits wide and take a % suffix, with an unsuffixed variable assumed to be an integer. Longs take & for larger values. Strings take $. Sixteen bits as the default width is the 68000’s natural word size and the console’s natural unit of work, and it is the right default for a Genesis game loop.

Static allocation throughout. No dynamic sizing, no runtime allocation. What you declare is what the ROM reserves.

Labels and classic control flow. Line labels, Goto, Gosub/Return, plus user-defined subs and functions. The manual also documents SHLINK, a jump variant described as being for event subroutines. It is old-fashioned BASIC control flow, presented without apology.

Data statements sized to the hardware. DATA stores bytes; DATAINT stores 16-bit values and DATALONG 32-bit ones. Graphics and level data are embedded directly in source this way, which is the approach the manual’s own examples take.

Genesis hardware statements. Palette manipulation, tile and sprite handling, plane scrolling, and joypad reading exist as language-level facilities rather than as libraries you assemble yourself.

Sound as a known rough edge. Community guidance reportedly pointed toward FM music through the YM2612 with samples for effects on a single channel, and treated mixing PSG effects into the picture as something you had to write yourself. The manual shipped PSG frequency tables. Audio was the part of the platform the compiler abstracted least.

Inline assembly. Asm "<instruction> [operand], [operand]" writes a literal line into the assembler output. The argument must be a quoted literal, not a variable — the compiler is pasting text, not generating code.

Three output targets. Per the compiler’s own documentation: plain Genesis ROMs, Sega CD ISO images, and ROMs that can use 32X features, all from the same source language.

A Windows IDE with an emulator. The distribution bundled an editor and an integrated emulator, so writing, compiling, and testing happened without leaving the tool. On a hobbyist’s Windows PC in 2005, that was a complete console development environment in a download of well under a megabyte — the archived 0.19 package is about 443 KB.

Evolution

The 0.x line was a working compiler with an inconvenient dependency: SNASM68k had to be obtained separately and behaved inconsistently across Windows releases. The 1.x line’s defining change was removing that dependency — ASMX in 1.23, and the last of the external helper binaries in 1.28 — so that the download was self-contained.

After that, the changes were consolidation rather than expansion. Between 1.23 and 1.37 the visible work is bug-fixing: heap corruption, expression parsing, whitespace inside parentheses, string entry in INPUT, absolute-address declarations inside functions. Version 1.37 in January 2010 is where the record ends. There was no announced discontinuation, no final release note, no handoff — the releases simply stopped, and by 2011 the homebrew community was describing the project as dead.

What made that terminal rather than temporary was the licensing. The compiler and IDE were distributed as free closed-source binaries, under a licence that by contemporaneous accounts forbade modifying or redistributing the software. The source was never released; the project FAQ’s stated reason was that the compiler and IDE had been written in Visual Basic and the code was too sloppy to publish. A thread on DevSter’s own forum from April 2012 argues the point directly, with users proposing an open-source path precisely because continuing the original was not possible on the terms available. It is a compact illustration of why “free to download” and “open source” are not the same guarantee: the price was never the problem, the source was.

The dialect nonetheless survived. SecondBASIC, developed by Adam Welch under the Second Dimension banner and announced around mid-2016, was built to continue where BasiEgaXorz stopped and uses the same commands. Its credits page thanks Joseph Norman for permission to use the BEX compiler’s assembly library, so this was a sanctioned continuation rather than a hostile fork. The compiler died; the language it defined got a second implementation.

Current Relevance

BasiEgaXorz itself is dormant. There have been no releases since 2010, the original site has been unreliable in recent years — its certificate is currently expired — and the binaries circulate largely through Internet Archive uploads and homebrew mirrors such as Zophar’s Domain. It is a Windows application; how well the 2010 build behaves on current Windows releases is not documented anywhere authoritative, so expect to fall back on compatibility settings or a virtual machine.

The Sega Genesis homebrew scene it served, by contrast, is healthier now than it was when BasiEgaXorz was current. SGDK made C the mainstream option and covers most of what a Genesis developer needs. Developers who specifically want BASIC use SecondBASIC, which keeps the BasiEgaXorz command set and has continued to see releases long after BEX stopped. Anyone starting a Mega Drive project today should choose one of those, not BEX.

Its remaining value is archival and pedagogical. There is a body of BasiEgaXorz source floating around forums and homebrew archives that reads as a snapshot of how amateurs approached 16-bit console hardware before better tools existed, and the manual is still a serviceable, gently written introduction to what the VDP actually does. And CrazyBus — a program whose reputation rests almost entirely on its title-screen audio — keeps the compiler’s name in circulation far beyond anyone who has used it.

Why It Matters

BasiEgaXorz matters as a demonstration that the barrier to console development was never really the hardware. The Genesis was fully understood by the scene long before BEX existed; what was missing was a tool willing to meet beginners where they were. One person shipping a free BASIC compiler with a bundled emulator changed who could make Genesis games, and the surviving forum and archive record suggests the effect showed up quickly in the volume of homebrew.

It is also a clean case study in the economics of abandonment. The compiler did not fail technically — it worked, it was used, and its dialect was good enough that a successor chose to preserve it deliberately. It stopped because one person stopped, and because closed-source distribution under a no-modification licence meant nobody else could start. The community’s response was neither to fork it nor to abandon the idea, but to rebuild it: SecondBASIC exists because BasiEgaXorz was worth reimplementing and impossible to inherit.

And there is a smaller point buried in the design that is easy to miss. BasiEgaXorz did not try to be a good general-purpose BASIC. It was static where BASIC is usually dynamic, hardware-specific where BASIC is usually portable, and it shipped an inline-assembly statement in a beginner’s language because it assumed you would need it. That is an unfashionable set of choices, and it is what let programs written in a beginner’s BASIC stay playable on a machine of that vintage — no benchmark comparison against hand-written assembly was ever published, but eliminating the runtime is the reason the question was even close.