6o6 v1.1: Faster 6502-on-6502 virtualization for a C64/Apple II Apple-1 emulator

I'm doing periodic updates on some of my long-term projects, one of them being 6o6, a fully virtualized NMOS 6502 CPU core that runs on a 6502 written in 6502 assembly language. 6o6 implements a completely abstracted memory model and a fully controlled execution environment, but by using the host's ALU and providing a primitive means of instruction fusion it can be faster than a naïve interpreter. This library was something I wrote over two decades earlier for my KIM-1 emulator project for the Commodore 64, and relatively recently I open-sourced and discussed it in detail. It runs on just about any 6502-based system with sufficient memory.

For this update I made some efficiency improvements to addressing modes, trimmed an instruction out of the hot path, provided an option for even more control of the 6502 interrupt flag and implemented a faster lane for direct stores to 6502 zero page (as well as the usual custodial and documentation updates). And, of course, any complex library needs a suite of examples, and of course, any update to a complex library demands new examples to play with too.

So, given that this year is Apple's 50th anniversary (and, as it happens, my own 50th year of existence personally), what better way to show off a 6502-on-6502 virtualization library than with an Apple-1 emulator ... that runs on the Commodore 64 or Apple II? Now yea, verily, this is hardly the first such example and several others have done something of the sort, but I submit that 6o6 makes our take on it here unique, and as a bit of fun we'll discuss the Apple-1's hardware and look at all that prior 8-bit emulator art for comparison (for the C64 and Apple II and even more exotic systems like the SAM Coupé).

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.

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!

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.

The quest for Wolfenstein 3D music on the Apple IIgs

Many people are unaware there is a port of Wolfenstein 3D to the Apple IIgs (my GS is currently still in working order). It's actually a surprisingly good one, derived in part from the Macintosh port with a custom soundtrack, with a strange history of its own. It plays well enough on my 8MHz TransWarp GS accelerator with the viewport about half size, but you really need a ripping soundtrack to mow down Nazis, and while I could revel in their screams the game never once played a note of music.

Naturally, because coronavirus, I decided to spend a weekend rectifying this. And yes, it's the latest 1.1 version, yes, the checkbox for Music was checked in the Wolf3D preferences (Command-P), and yes, other sound effects worked fine.

I like to think I have a modestly tricked out system (hard disk, GS/OS 6.0.1, accelerator, ROM 03 with a Woz Special Edition topcase) but one thing it was a little weak on was RAM. A ROM 03 IIgs has 1.125MB on board (1MB, plus 128K); I had a fully populated 1MB Apple RAM expansion card in, so I had 2.125MB total. Officially the game doesn't play on anything less than 4MB, but it clearly ran, so I figured RAM was the immediate problem.

There are many choices for RAM upgrades for the IIgs but one with a long history (albeit differing opinions) is the GGLabs RAMGS/8. This gave me 8320K (8MB plus 128K on board), the price wasn't exorbitant and I could nab one easily on eBay. Compared to the other cards in my system, it's rather diminutive (and doesn't need the strut prop the long Apple RAM card did).

Its sole installation direction is a silkscreened arrow saying "FRONT." This is a little nerve-wracking because the slot has no keys and the card could go in it either way, and the installation appears backwards. But that's how it's supposed to fit (the controller board for the InnerSpace hard disk is behind it):

With that, I started up GS/OS, admired the nice ample addressing space in Get Info in the Finder, and ran the memory test provided with AppleWorks GS. After many minutes I got a clean bill of health.

However, I still got no music out of Wolfenstein 3D. Trashing the prefs file made no difference. So what else was I doing wrong?

The classic Mac OS divides components up into control panels and extensions primarily but GS/OS deals in control panels and tools. On a ROM 03 system, about half of these tools are built into the ROM and the rest reside on disk. I had a vanilla GS/OS install with all Tools through 034, but music support needs Tool035, which is not installed with standard GS/OS.

After some digging I found the Tool as a standalone file on an unrelated disk image, but this disk image was in the newer-fangled .2mg format, which I can't directly turn into a floppy with DiskCopy or DiskDup on my Power Mac 7300. (Yes, you can use things like ADTPro to write the disk on the IIgs itself, but this Mac has a suitable floppy drive, and it seems like I should be able to use it rather than messing around with serial cables.) CiderPress will convert these, however, and while the GUI is Windows-only you can build some pieces of it on Linux. None of them would directly do what I wanted, which is to turn it into a DiskCopy image, but the source code gets you most of the way there. Edit Convert.cpp and find the line switch(18). This is the destination format. Since I knew this was an 800K image, I changed the 18 to 14, which specifies a DiskCopy 4.2 image, and used the badly-named iconv (not to be confused with libiconv) to generate the image. On the Power Mac 7300 I changed the type and creator codes in ResEdit to dImg and dCpy respectively so that DiskDup would accept it. Bang, a 3.5" floppy with the needed tool.

Triumphantly I returned to the IIgs, inserted the disk, copied the Tool over, restarted GS/OS, started Wolfenstein 3D, and indeed heard some very impressive music out of the wavetable synthesizer. Success! Unfortunately this is where I think I pushed my luck: the 8MHz TransWarp GS just can't keep up with music and the rendering. In fact, while it tries to load the game data you can intermittently hear the music grind to a halt (it even crashed out to the monitor once, presumably because the data didn't arrive quick enough), and you have to have the viewport at postage stamp size to make it playable. I'm glad I have 8MB of RAM and it works very well in everything else, but after all that I decided to turn music back off so I could actually play the game (but I kept the Tool, in case other games require it).

So, with the RAM situation licked, I guess now I'm in the market for a faster IIgs accelerator. In today's world, a man's gotta kill Nazis with a soundtrack, you know.

Not a refurb weekend: Apple IIgs

The most advanced Apple II computer was, of course, the one Apple insisted would be a dead end: the 1986-1992 Apple IIGS. And the reason was simply that the GS was too good a computer, offering Apple II compatibility, 16-bit performance, a 4096-colour palette with up to 640x200 high resolution graphics, and one of the best sound chips since the SID in the Commodore 64 (in fact, Bob Yannes designed the SID, then went on to found Ensoniq who produced the GS'). It was so good, in fact, that it posed a real risk during its development of cannibalizing sales from the Macintosh. Apple thus made sure it couldn't be a threat by deliberately hobbling the 16-bit 65816 CPU to just 2.8MHz when it was capable of up to 14MHz and at minimal additional cost, and intentionally never did more with the system publicly other than token ROM upgrades and pathetic bumps in memory. It takes some truly inspired buttheadery to hold back a fabulous system in that fashion, but that's what Apple was capable of in those days, and arguably still is.

This particular computer in my collection — and yes, that's a Canon Cat next to it, a topic for another day — is a Frankenstein assembled from three partially working units. It has a ROM 03 motherboard (the last revision not counting the 8MHz "Mark Twain" prototype) but with a Woz Limited Edition topcase just 'cuz, a 1MB Apple RAM expansion card (for 2.125MB of memory), an original 7MHz Applied Engineering TransWarp GS CPU accelerator with the 8K cache daughtercard, and a 20MB Applied Ingenuity InnerDrive consisting of a SCSI card plus a unified drive enclosure and replacement power supply. It is connected to an ADB keyboard and mouse, a LocalTalk network box, an AppleColor RGB display, an Apple joystick and 3.5" and 5.25" floppy drives, and boots into GS/OS 6.0.1.

A few months ago after I got LocalTalk up and running and was transferring some other things to it, it started to get flaky, and would invariably crash into the Apple machine language monitor after sitting at the GS/OS Finder for a few minutes. This machine was certainly produced in the "crap caps" era and bad capacitors are in the differential diagnosis, but with so many things installed a more systematic approach would be required. Today it's the Thanksgiving long weekend during a pandemic, and I've got only dayjob work and take-out dinners to look forward to for the next several days. Sounds like an opportunity for another ... Refurb Weekend!

First, let's pop the hood and check for obvious damage. I blew out some dust with an air can, but everything looked pretty shipshape otherwise.

Looking overhead you can see the combination drive cage-power supply for the AI InnerDrive plus its ribbon cable to the controller card. Between the controller card and the enclosure is the TransWarp GS, and the Apple RAM expander card is furthest away.

Closeups of the InnerDrive and TransWarp GS cards.

Closeup of the Apple RAM Expansion card (670-0025-A).

To check for board damage, you also need to remove the power supply, since a couple large capacitors sit under it and, inconveniently with the larger size of the AI combo cage and PSU, the PRAM battery.

Clean as a whistle. I even got out the multimeter and checked the PRAM battery, and it still reads a full 3.65V.

I'm not a fan of prophylactically replacing capacitors that are not obviously bad, especially since you have a non-zero chance of accidentally breaking something in the process of fixing what ain't broke to begin with. At this point I resigned myself to having to test components independently: remove or disconnect something, fire it up and see if it crashes. I was strongly suspecting either the TransWarp card or the RAM expander, since those would certainly cause random failures. For that matter, it might even be heat related. Anyway, to get a baseline, I went ahead and disconnected the LocalTalk network, the joystick and the external drives, rebooted it and waited for it to crash.

After an hour it was still cheerfully sitting at the Finder. I fired up a game of Crystal Quest GS (ported by Becky Heinemann, who also wrote the firmware for the InnerDrive and had very nice things to say about TenFourFox). No crash. I fired up Wolfenstein 3D (ported by Logicware, which Heinemann co-founded). No crash. I played some Tunnels of Armageddon, one of my favourite GS games (no known connection to Heinemann). Still no crash.

I reconnected the joystick and let it sit for a few minutes. The joystick doesn't work too good, but it didn't make anything crash.

I reconnected the disk drives (best done with the power off, just in case) and let it sit some more. The machine had gotten good and warm with all this burning-in, so if heat was a factor, it should have been by then. No crash.

I reconnected the LocalTalk box and let it sit a couple more minutes. Boom, straight into the monitor while it was sitting idle.

I powered it off, disconnected the LocalTalk box, rebooted and let it sit a couple more minutes. No boom, no monitor, normal operation. The LocalTalk network was crashing GS/OS. And, actually, this makes sense, because the last thing I was doing with it before it got "wacky" was copying stuff from the network. It had never been connected to the house LocalTalk segment before because it never needed to be.

So what's crashing it, and why doesn't it do so right away? My guess is that the delay is because something on my household AppleTalk network transmits a packet intermittently that GS/OS's stack doesn't like. The segment itself couldn't be the cause because there were no other LocalTalk hosts up (the 486 and the Colour Classic are both connected to the segment, but neither were on). A Dayna EtherPrint-T bridges the LocalTalk segment to the main Ethernet via EtherTalk; on the other end of the Dayna is the little Macintosh IIci running old Netatalk which services old hosts, this Raptor Talos II running modern Netatalk which doesn't, and the G4 Sawtooth file server running Tiger (not Netatalk). Any one of those could be sending packets that GS/OS 6.0.1 just doesn't know how to cope with, but a cursory Google search and a look through comp.sys.apple2 didn't come up with anything similar. A mystery to be further investigated in a later entry.

In any event, it's good to see it doesn't appear to be caps nor hardware, and there are other ways to get files to the GS, so not having LocalTalk isn't the end of the world. Turns out this wasn't a Refurb Weekend after all, but who's complaining? That said, however, now that it's back in its right mind there are some future upgrades to do. The first is to consider some other means of mass storage since even old battleaxe drives don't last forever, and the InnerDrive firmware is notorious for only being able to work with a very small number of specific drive geometries (forget using a drive much later or larger than the 20MB one it has). A Compact Flash card solution exists and would seem the obvious choice rather than faffing around with a SCSI controller. The second is to put the full 8MB of RAM in it; there are some third party cards still made by homebrewers that will do this. If nothing else, between the two of them I'll be able to shoot a whole lot more Nazis for a whole lot longer, and that's always a(n Apple II) plus.