Microsoft makes 6502 BASIC open source

It was probably going to happen sooner or later, but Microsoft has officially released the source code for 6502 BASIC. The specific revision is very Commodore-centric: it's the 1977 "8K" BASIC variant "1.1," which Commodore users know better as BASIC V2.0, the same BASIC used in the early PET and with later spot changes from Commodore (including removing Bill Gates' famous Easter egg) in the VIC-20 and Commodore 64. I put "8K" in quotes because the 40-bit Microsoft Binary Format version, which is most familiar as the native floating point format for most 8-bit BASICs derived from Microsoft's and all Commodore BASICs from the PET on up, actually starts at 9K in size. In the C64, because there is RAM and I/O between the BASIC ROM and the Kernal ROM, there is an extra JMP at the end of the BASIC ROM to continue to the routine in the lowest portions of the Kernal ROM. The jump doesn't exist in the VIC-20 where the ROM is contiguous and as a result everything past that point is shifted by three bytes on the C64, the length of the instruction.

This is, of course, the same BASIC that Gates wanted a percentage of but Jack Tramiel famously refused to budge on the $25,000 one-time fee, claiming "I'm already married." Gates yielded to Tramiel, as most people did then, but I suspect the slight was never forgotten. Not until the 128 did Microsoft officially appear in the credits for Commodore BASIC, and then likely only as a way to push its bona fides as a low-end business computer. Microsoft's source release also includes changes from Commodore's own John Feagans, who rewrote the garbage collection routine, and was the original developer of the Commodore Kernal and later Magic Desk.

The source code is all in one big file (typical for the time) and supports six machine models, the first most likely a vapourware 6502 system never finished by Canadian company Semi-Tech Microelectronics (STM) better known for the CP/M-based Pied Piper, then the Apple II, the Commodore (in this case PET 2001), the Ohio Scientific (OSI) Challenger, the Commodore/MOS KIM-1, and most intriguingly a PDP-10-based simulator written by Paul Allen. The source code, in fact, was cross-assembled on a PDP-10 using MACRO-10, and when assembled for the PDP-10 emulator it actually emits a PDP-10 executable that traps on every instruction into the simulator linked with it — an interesting way of effectively accomplishing threaded code. A similar setup was used for their 8080 emulator. Unfortunately, I don't believe Allen's code has been released anywhere, though I'd love to be proven wrong if people know otherwise. Note that they presently don't even mention the STM port in the Github README, possibly because no one was sure what it did.

While MACRO-10 source for 6502 BASIC has circulated before and been analysed in detail, most notably by Michael Steil, this is nevertheless the first official release where it is truly open-source under the MIT license and Microsoft should be commended for doing so. This also makes it much easier to pull a BASIC up for your own 6502 homebrew system — there's nothing like the original.

Reverse-engineering Roadsearch Plus, or, roadgeeking with an 8-bit CPU

Sorry, Doc Brown: we still needed roads in 1985. That meant paper atlases and misfolded roadmaps and a lot of stereotypical male anxiety asking for directions. Fortunately, in 1985, this problem also had a solution.

Yes, if your car inverter could handle a 45-ish watt load — and your wife doesn't want her seat back right away — you could navigate major routes across America on your home computer like this portable Commodore SX-64. I particularly enjoyed writing this article because my other irredeemably nerdy habit is roadgeeking, exploring and mapping highways both old and new, and it turns out that 8-bit roadgeeking on ordinary home computers was absolutely possible.

For computers of this class, devising an optimal highway route becomes an exercise not only in how to encode sufficient map data to a floppy disk, but also performing efficient graph traversal with limited hardware. Today we'll explore Roadsearch-Plus, one of the (if not the) earliest such software — primarily on the Commodore 64, but originating on the Apple II — and at the end "drive" all the way from southern California to British Columbia along US Highway 395, my first long haul expedition, but as it was in 1985. Buckle up while we crack the program's runtime library, extract its database, and (working code included) dive deeply into the quickest ways to go from A to B using a contemporary home computer.

See Jane 128 by Arktronics run (featuring Magic Desk, 3-Plus-1 and the Thomson MO5)

"Look," says Jane. "I'm a computer program. Run, computer program, run."

I still maintain that the 1986 Commodore 128DCR is the best 8-bit computer Commodore ever made: built-in 1571 disk drive, burst mode serial, detachable keyboard, 2MHz operation, separate 40 and 80 column video, CP/M option, a powerful native mode, full Commodore 64 compatibility and no external power brick. But when the O.G. "flat" 128 was coming to market in 1985 Commodore really wanted it to be the business computer the 64 wasn't (and prior efforts like Magic Desk and Plus/4 3+1 didn't help). Unfortunately for Commodore, it would still be at least a year before the sophisticated GUI of Berkeley Softworks' GEOS arrived on the 64 and another year after that for the native 128 version, so to jump-start the productivity side, the management in West Chester contracted with a small Michigan company to port their Apple II software suite to the new machine — which Commodore then sold under their own name. That company was Arktronics, led by Howard Marks and Bobby Kotick — the very same names later at Activision — and the software package was Jane.

I never used Jane myself back in the day, or for that matter any 128 native word processor, and even when we got a 128 I still wrote my term papers in Pocket Writer 64 or Timeworks Word Writer. However, that faulty but repairable Australian Commodore 128DCR I got last Christmas came with a big box of software and in there was a complete copy of Jane 128 along with the data disk the previous owners' family had used. They were delighted when I said I wanted to take a whack at converting their files as a thank you — and along the way we'll take a look at Jane's oddball history, the original Apple II version, the Commodore 128 version and its all-but-unknown port to the French Thomson MO5, plus those other attempts at productivity applications Commodore tried in the mid-1980s.

The "35-cent" Commodore 64 softmodem

Rockwell famously used 6502-based cores in modems for many years, but that doesn't mean other 6502s couldn't be used. If only there were a way to connect a Commodore 64's audio output directly to an RJ-11 plug ...

Of the many interesting posts from Usenet's more golden days, one of my favourites was John Iannetta's "35-cent modem," where the SID chip provides one-way data modulation to a receiving modem connected via the C64's sound output. While I remember him posting it back in 1998, I never actually tried it at the time.

Wouldn't you know it, but it came to mind the other day when I was looking at a recent haul of Convergent WorkSlate stuff I've got to catalogue. Officially the WorkSlate's only means of telecommunications is its 300 baud internal modem. While we have a 9600bps way of wiring up a Workslate to a modern computer, it's always nice to have a simpler alternative, and I figured this would be a great challenge to see if John's old program could let my Commodore SX-64 talk to my WorkSlate. Spoiler alert: it works!

A mostly merry Southern Hemisphere Commodore Christmas

A merry Christmas and happy holidays from the Southern Hemisphere, where it's our year to be with my wife's family in regional New South Wales, Australia. One of my wife's relatives had an "old Commodore" in their house and asked if I wanted it. Stupid question, yeah?

So they brought over, in their original boxes, a Commodore 128D (PAL) with Commodore 1802 monitor, Commodore MPS-1250 dot matrix printer and a separate box of magazines, circulars and boxed software. Let's fire it up!

One-parting some Commodore 64 utilities for fun and profit

I've got a few retrocomputing bucket list items I'm slowly working down, and a couple of them involve some little Commodore 64 games I've had kicking around on the backburner. However, every game needs media assets, and while there are many great tools for doing art on your present-day workstation and exporting it, sometimes you just want what you used to work with — in as convenient and quick-loading a way as possible that blends with modern emulation workflows. So here's two I tweaked and one-parted — Ultrafont+ and DOODLE! — and some tips for making self-contained tools like these yourself.

The unreleased Commodore HHC-4's secret identity

Once upon a time (and that time was Winter CES 1983), Commodore announced what was to be their one and only handheld computer, the Commodore HHC-4. It was never released and never seen again, at least not in that form. But it turns out that not only did the HHC-4 actually exist, it also wasn't manufactured by Commodore — it was a Toshiba.

Like Superman had Clark Kent, the Commodore HHC-4 had a secret identity too: the Toshiba Pasopia Mini IHC-8000, the very first portable computer Toshiba ever made. And like Clark Kent was Superman with glasses, compare the real device to the Commodore marketing photo and you can see that it's the very same machine modulo a plastic palette swap. Of course there's more to the story than that.

Two tiny 65816 DTV consoles

The 21st century direct-to-TV game console: a dirt-cheap toy dragging poor ports of cherished games to a more downmarket age. If you couldn't afford the real device, your alternative was these inexpensive, inadequate facsimiles faithful only to one's gauzy recollection. As their chipsets are generally grossly underpowered and optimized solely for cost, the vast majority didn't even try to run the original games precisely as they were, and the quality of the resulting rewrites sometimes showed their software to be as rushed as the hardware. (Even today, where true emulators are more plentiful, the SoCs these devices use often still require compromise.) There were certainly standouts that are practical miniatures of the original systems, notably the Commodore 64 Direct-to-TV and Atari Flashback 2, but the remainder during their zenith in the early 2000s were more like this Intellivision and two Atari 2600 imposters, playing uneven resurrections on unrelated silicon.

But it turns out these three (and others) have something in common besides the bargain bin: they're all derived from our favourite chip, the 6502. In fact, the two Atari imposters even embed the 6502's 16-bit descendant, the 65816. How do we know this? Rampant speculation, foggy memory, datasheets and vidcaps — and taking them apart, of course.

Virtualizing the 6502 on a 6502 with 6o6 (and The Incredible KIMplement goes 1.0)

Okay, promises, promises. Here's the first of my bucket list projects I'm completing which I've intermittently worked on for literally two decades. Now that I've finally shaken out more bugs, tuned it up and cleaned it off, it's time to let people play with the source code.

This is the official 1.0 release of the Incredible KIMplement, an emulator of the one kilobyte, 1MHz MOS/Commodore KIM-1 6502-based single board computer. It provides access to the KIM's built-in TTY support (even through your computer's real serial port) and has expanded RAM with 16K of addressing space, all on an unexpanded stock Commodore 64.

It's almost burying the lede to announce that, though, because the real meat in this entry is how the Commodore 64 manages to emulate a very different 6502-based system. That piece is "6o6," for "6502-on-6502," and is a full virtualized software NMOS 6502 CPU that runs on a 6502 CPU — which I've open-sourced too. It has full control of guest code execution, including trapping undocumented and jam opcodes, and completely abstracts all memory access, making it possible to remap addresses, intercept illegal reads or writes, or even run entirely from virtual memory. On top of that, it's complete enough to not only pass a full functional test but also virtualize itself virtualizing itself:

These GIF screencasts are real-time with no tricks. Here a Commodore 64 and Apple IIe are both running a guest "hello world" payload within 6o6 (stage 1), which is nearly instantaneous, then 6o6 running the payload as a payload within another instance of 6o6 (stage 2), which is a little slower, then 6o6 running 6o6 running 6o6 running the payload (stage 3), which is glacial. But all of it works!

xa (xa65) 2.4.1

A quick one: xa (xa65), André Fachat's compatible fast two-pass cross-assembler for 6502, 65C02, R65C02 and 65816 processors that André and I maintain is now at version 2.4.1. This optionally expands the syntax from 2.4.0 and fixes some bugs primarily with relocatable .o65 objects. As usual, there are even more tests in its extensive conformance test-suite, and it is tested on Linux/ppc64le, Mac OS X (PowerPC, Intel and Apple silicon), AIX (its primary development platform, just to be difficult), and NetBSD/macppc and NetBSD/mac68k. You can download it and read documentation in man(1) format (converted to HTML) from the main xa65 home page. xa is free and open-source under the GNU Public License v2.

xa (xa65) 2.4.0 - finally

xa (xa65) 2.4.0 is the newest release of André Fachat's fast and portable two-pass 6502/65816 crossassembler; yours truly is the current maintainer and I just punched "live" on it tonight. It runs on Un*xy things and Windows (with Cygwin or msys2 or similar), and probably other operating systems as well. xa 2.3 has had a good run, but it's served 17 years as the minor release (no joke: 2.3.0 came out in 2006) and time marches on. There are new features to add and old cruft to sweep away. But it's still compatible with all the systems 2.3 was compatible with and adds several new features, including:

• Listing mode, allowing side-by-side byte output with the lines in your source. You can even emit it in HTML.
• A ca65 compatibility mode that allows many of the same pseudo-ops and "cheap local labels" support. Although this obviously doesn't accept every feature in ca65, it can ease translating your assembly source considerably — because once you switch to xa, you won't want to go back. :) This feature is also used for other compatibility options such as MASM and allowing some C-like expressions.
• Assertions at the preprocessor level (#error) and assembly level (.assert), allowing controlled errors when static assertions are violated.
• Linker enhancements for .o65, including deferred linking of undefined symbols.
• You can now get the assembler major and minor version in the preprocessor with XA_MAJOR and XA_MINOR. Other predefined macros may appear in future versions.

Because this is a new minor release, there are incompatibilities. The escape character in quoted strings is now the standard backslash (\) instead of the carat (^), and recursive multi-line /* */ comments are no longer allowed, unless you ask for them with -XXA23. Obviously these features are deprecated, and they will be removed in a future version. Our expanded testsuite is designed to look for regressions and we are very conservative about that, but it's possible we've introduced other changes that may interfere with edge cases or undefined behaviour in your source, and such changes are unlikely to be reversed.

This release also deprecates printcbm(1), since it's not been touched in a long time, was never really a core part of an assembler suite, and VICE petcat does everything it did and more (even I don't use it; I have my own Perl detokenizer). It will be removed in a future version also. Of things that were already deprecated in 2.3.x, the old 16-bit argument syntax for 65816 mvn/mvp is now not accepted and the old -S and -x options are finally removed. If you need those, you must use 2.3.14.

Between 2.4.x and the next version (2.5 or 3.0, depending on my mood and the scope), we will be slowly embarking on cleaning up the source code's readability which has been an admitted issue for years. One big reason for not doing this earlier was because of regression risk and as André and I are xa's most important users, we definitely didn't want cleanup to impair our ability to build our own projects. Now that we have an extensive and growing regression testsuite, this can be done slowly in stages so that we have something more maintainable without introducing new bugs in the process or incompatibilities with the C compilers we already test against (our oldest in the test rotation is egcs-1.1.2 and it probably works on even earlier ones). As these changes are expressly intended not to change code functionality, they will incrementally roll out with future 2.4.x releases.

You can download it and read documentation in man(1) format (converted to HTML) from the main xa65 home page.

What the KIM-1 really needs is an LCD screen

Giving the 1976 1K RAM, 1MHz 6502-based KIM-1 single-board computer bubble memory storage was all well and good, but the basic unit is still just six numeric LEDs for its display. Let's solve that problem.

Here's a sidecar screen for my KIM-1 that's large enough to be useful, small enough to be portable, and efficient enough to be powered by my unit's built-in power supply. Plus, it can be driven by the KIM-1's unallocated I/O lines so that its 20mA current loop terminal interface remains available, with bonus points for being self-lit so you can see it like the LEDs. And the output driver takes up just 64 bytes of RAM.

The spawn of AtariLab and the Universal Lab Interface

We were a Commodore 64/128 household growing up, and Apple IIe systems at school, but that doesn't mean I was unaware of Atari 8-bits. There was a family at church who had an 800XL and later a 130XE — and a stack of COMPUTE!'s I used to read through for hours — and it was interesting to compare the two worlds, especially the relatively luxurious Atari BASIC and DOS against Commodore's spartan accoutrements. On the other hand, there was a lot more software and peripherals for the C64 by then, and you ended up becoming a lot more proficient with the guts of the hardware because you had to. Plus, Jack Tramiel's Atari was a lot like Jack Tramiel's Commodore and not always in a good way. I have an XEGS (functionally a 65XE when you add the keyboard) and a 1050 disk drive I should set up somewhere and mess around with a little.

But that doesn't mean Atari didn't try. Prior to all that, Atari in the Warner Communications days put forth substantial effort to make it competitive in all kinds of settings, notably education. Ataris had some unique hardware in that niche; an Atari was the first non-Control Data microcomputer to access the PLATO network, for example. And then there was the AtariLab.

With a very simple interface box, your Atari 8-bit could read the temperature and sense brightness. You could run experiments on it at school, including polarized and coloured light, or testing how quickly things cool and heat. You could use it at home with your own programs thanks to its comprehensive documentation.

But the surprising part is that even though these were the only such devices released under the AtariLab name, they weren't the end of the line: besides its stealthy revival for other home computers like the Commodore 128 running it here, its creator also turns up in one of the more interesting scientific data acquisition devices I've run across in its price range. We'll test-drive the software, hack on the platforms a little, and try some even more outlandish sensors. Let's go down the rabbit hole with AtariLab — and its full-fledged descendants.

Cracking DesignWare's The Grammar Examiner on the C64

It's been awhile since I've stripped the copy protection off a Commodore 64 software package. This weekend I had a reason to.

I should point out a couple things as preamble. First, my parents insisted I would not rot my brain with games (much), so we had a lot of educational titles for our C64, and second, my wife is a high-school English teacher. I kept a number of packages from back then and one of them was a secondarily acquired copy of DesignWare's The Grammar Examiner from 1984, something like a mashup between a board game and Strunk and White's Elements of Style, where you get to edit a fictional newspaper and fix all the typos and bad punctuation in your quest to become editor-in-chief.

I rather liked it back in the day. Don't judge. My wife — who used Commodores as a girl in the Australian school system but not this particular title — enjoyed it even more than I thought she would, enough so that she occupied VICE on the Talos II playing it all afternoon and prevented me from writing this.

The Grammar Examiner plays well enough on my real Commodore 128DCR, though it's a very slow loader, and I only have an original disk which I'd like to preserve. (My original original copy disappeared a while back, though I've had this particular one at least a couple decades.) A quick sector-by-sector D64 image using a ZoomFloppy yielded a number of apparently intentionally bad sectors typical of early 1980s copy protection, but even with the error information the program's loader just plain hung up in VICE trying to boot the copy. Yes, a nibbled raw copy of the GCR would work and I imagine people have made one of this title, but we'd also like to speed up the process instead of burdening the emulator further (and it would be nicer on the real system too).

So in this post we'll explore the loader routine, decrypt and extract it, figure out how the copy protection is implemented and work around it, and then pull out the payload it reads for a faster start. While we're at it, let's look briefly at the program itself, an interesting example of Forth programming "in the large" on 1980's home computers.

Refurb weekend(s): Commodore/MOS KIM-1

Actually, it was more like a whole stinking Refurb Two Months. The KIM-1 is one of the earliest MOS 6502 computers, a single-board system with 1K of RAM (actually 1152 bytes total) and a one-megahertz CPU developed by Chuck Peddle in 1975 as a way to introduce engineers to the new 8-bit microprocessor. However, its low cost meant it ended up taking on a life of its own as it was one of the cheapest ways to assemble an entire working hobbyist system, and Commodore continued to sell them for several years after they bought MOS. You could hand-key in programs with the hexadecimal keypad and the six LEDs as a display or wire up a TTY. It also supported saving and loading from cassette and paper tape, all built-in to the standard ROMs.

I have a couple KIM-1s and they are the oldest machines in my personal collection, including a Revision A pre-Commodore MOS unit with ceramic processor and RRIOTs, but the one that's the most special to me is the briefcase Revision D system you've seen here in other entries. The Revision D is notable historically as the first Commodore-branded KIM after their 1976 buyout, but it's important to me because this unit was my first KIM, and the one we got in high school from our high school math teacher and learned to program it over the weekend (we'd grown up with the Commodore 64, so we already knew all the machine language opcodes). It conveniently sits in a briefcase with a power supply and has one of Bob Applegate (RIP)'s I/O boards to provide the RS-232 connection.

While working on our most recent KIM-1 project, I noticed that the RAM from $0280 to $02bf wasn't working right. The serial uploads from KIMup would succeed, but the data it stored in that range was wrong, and when I checked with the monitor it would only store values 0-3. I got around the problem by assembling the code to a different address, but on a system with a single kilobyte of memory, you can't ignore a whole 32-byte failure. It was time for a Refurb Weekend.

Making a potato livecam with the Commodore 128 VDC and ComputerEyes

If we're going to make the little old 8-bit MOS 6502 into Skynet — because we already know what the Terminator T-800 CPU is — then it's gonna need to see. How can it exterminate the last remnants of humanity without vision?

And we'll use something period-correct, too. While our favourite Cyberdyne Systems Model 101 was busy stalking Sarah Connor in 1984, the product it might have (slowly) viewed the world with was already on the market: the Digital Vision ComputerEyes. Check out the little beige camera perched on a stack of disk boxes, attentively surveilling the room at just a few, uh, seconds per frame as displayed on the monitor. Plug in a composite video source, connect it up to your Apple II, Commodore 64 or (in 1985) Atari 8-bit, and wait about six or seven seconds to identify targets — or almost fifty for the highest quality. If Skynet had chosen this option we might never have had Judgment Day.

The slow capture speed meant it was never intended as something to view live, and on the Commodore and Atari versions, DMA interference meant you could only capture with the screen off which would seem to make any live-ish feed impossible. But the Commodore 128 has a second video chip that doesn't interfere. Let's turn the Commodore 128 into a really slow potato-quality live camera you can interactively watch and freeze-frame — and then, in exchange for 11% of the screen, make it capture almost 25% faster! Time-lapse video proof at the end!

Refurb weekend: Commodore 128DCR

No question: the Commodore 128D is the finest Commodore 8-bit ever made. On this I tolerate no dissent, and that's not just because I sometimes hang out with Bil Herd. It's a 128, so it's got VDC graphics, 128K and 2MHz operation, but because it's a 128 it's also a 64. It's also an upgraded 128 with the fixed ROMs, (in this North American 128DCR) 8568 VDC and 64K of VDC memory, it's got a built-in 1571 (Commodore's finest 5.25" disk drive), and it doesn't have an external power brick. Plus, even though it has the desktop footprint of a 128, the detachable keyboard means you can just put a monitor on top of it (and the steel-cased North American 128DCR handles that very well) just like you can't with a flat 128, and you either get an actual cooling fan with the plastic 128D or the solder points to put one in a steel 128DCR. My only complaint is that the consolidated DCR motherboard is nearly devoid of socketed ICs, making it a little tough to do component level repair on. I like spares, so I have four DCRs, all of which completely or mostly work (and two spare keyboards, one rather yellow but fully functional and one even more yellow and useful just for parts).

This particular 128DCR has been a constant presence on my desk since the mid-1990s when I first got it as an upgrade from my ailing flat 128. But it has one flaw: it doesn't have a working CIA Time-of-Day clock, which isn't used much by software, so I never bothered to do anything about it. This was tricky when developing TOTP-C64, since the 30 second timer between emitting TOTP codes uses the TOD clock for maximum interval accuracy (the 50/60Hz Timer A interrupt that drives the TI/TI$ jiffy clock can be stalled and lose time, whereas the TOD clock is based on the AC mains frequency and thus is as accurate as your plugged-in wall clock); one of my portable SX-64 systems, my second favourite Commodore 8-bit, handled that portion of testing instead.

Well, now that I've got a new Ultimate II+L cartridge in fire-engine red with its own real-time clock (among other great features), I'd like to update TOTP-C64 to support it and I'd rather do it on the 128DCR. That means we should fix the TOD clock. And that means ... a Refurb Weekend!

The KIM-1 that sounds like Stephen Hawking (or: "jitbanging" DECtalk)

My 1976 briefcase Commodore/MOS KIM-1, a 1 MHz single-board computer with a 6502 CPU and 1K of RAM, has learned to talk — with a familiar-sounding voice.

The KIM-1's serial lines are connected to the last and smallest member of Digital Equipment Corporation's true DECtalk hardware speech synthesizers, the 1994 DECtalk Express. The DECtalk's classic default voice heard in this video is Perfect Paul, which (with adjustments) was the voice of Dr Stephen Hawking as produced with the 1988 Speech Plus CallText 5010.

The 15 keys we can read off the KIM's hexadecimal keypad are polled by a "talker" program that sends the DECtalk Express words and phrases to speak. However, although the KIM-1 has 20mA current loop output you can turn into RS-232 serial, its built-in ROM routines can't reliably communicate at the 9600 baud rate the DECtalk Express demands.

So, in today's entry, we have a veritable smorgasboard of geriatric geekery: using our KIM-1 serial uploader to push a program for execution, let's write a bitbanged 9600 baud serial transmitter routine in 6502 assembly and let the KIM-1 have its say — and crack the DECtalk Express open and look at the insides while we're at it. (Teaser: you'll find its CPU very familiar.)

Printing real headline news on the Commodore 64 with The Newsroom's Wire Service

Besides other things I've written or supervised, so far in my time I've also edited three periodicals, and Springboard Software's The Newsroom is a big reason why. In today's article we'll not only look at the guts of this pioneering 1984 software package, but also solve a childhood mystery I've wondered about since the very first day I touched the program by MITMing an RS-232 connection to snoop on serial data — and then print out a brand new 2023 newspaper with 2023 headlines to prove we cracked the case. (Scroll to the end if you just want to see the finished product.)

xa 2.3.14, the 6502/65816 cross-assembler

xa (xa65) 2.3, the current minor release of this long-lived 6502 and 65816 cross-assembler, gets one more stay of execution to 2.3.14 in order to fix a segfault for recursive macros with smaller arities and a regression from 2.3.13 with nested comments (though André and I may consider whether we will still support this in 2.4). The testsuite is naturally expanded and tuned up a little bit, too, and as always run to completion on the multiple current and geriatric systems here at Floodgap. I know I'm sounding like a broken record but 2.4 is coming and we will be breaking some edge-case compatibility and cutting out some long-deprecated corners of the code, so it was important to ensure 2.3.x was tuned up as much as possible before putting it out to pasture. There is no corresponding new release for dxa, the companion disassembler; work is still being done there.

The new release and archived old versions are updated on xa's home page. Both xa and dxa are available under the GNU Public License v2.