The Commander X16 (and some more BASICODE)

▼ The Commander X16 is an upcoming new Commodore 64 like 8-bit computer built from currently available parts, as explained in Youtube playlist. After watching some of the more recent videos, I decided to download the emulator... and tried out some BASICODE on it.

Why a new 8-bit computer?

Part of this is of course middle aged nerds wanting to relive their childhoods. Not discounting that aspect, I do think there was something special about the 8-bit home computers from the 1980s. Because those systems were so limited, they dispensed with all overhead and just gave you the minimum needed to write and run programs. So it was easy to write programs like games yourself.

And for some reason, for me at least, none of that translated to more modern systems like the Amiga. Not too long after I got an Amiga, I learned C in college, and ended up writing relatively low level code such as my own traceroute implementation. But I never wrote anything that uses the graphical capabilities of the Amiga, PC or Mac. (Unless you count some more recent web stuff.)

Now obviously those old computers can still be found, but it's getting harder and harder to use them, as compatible displays and I/O options are becoming more scarce. Some kind of emulation such as the THEC64 works well to run the old software more easily, but has nothing to do with the old hardware. Part of the charm of those 8-bit computers is that a single person can understand the whole thing, software and hardware.

Commander X16

So that's where the Commander X16 comes in. The basic idea is to start with a VIC-20, which is an extremely simple design with many parts still available, and then update some parts as necessary.

The biggest issue was finding a good graphics chip with abilities similar to the C64's VIC-II chip. They couldn't find any, so they use an FPGA-based video controller instead, with 128 MB of its own video RAM and also an SD card interface for storage. Audio options were also less than ideal, so it looks like they're also going to use the VERA FPGA video controller for audio.

The VERA will output 640x480 analog VGA, with various text and graphics modes.

The CPU will be an 8 MHz 6502. It's really too bad that they didn't choose the 65816, a backwards compatible 16-bit successor of the 6502. The X16 will have 40 kB of regular RAM (minus a bit for hardware registers) followed by 8 kB of "bankable" RAM. That's 512 kB or 2 MB of additional RAM, but the 6502 can't address that much memory, so at any one time, 8 kB of the extension RAM can be mapped into the 6502's address space. The ROM works in a similar way, with one 16 kB bank out of a total 512 kB available at any time.

The X16 will support a PS/2 keyboard and mouse as well as various extension options. Unfortunately, there is no RS232 port or any other way to communicate with the rest of the world included. So that means either an extension card or swapping out that SD card on a regular basis.

They eventually licensed the C64 BASIC and “KERNAL”, so BASIC programs or even machine code / assembly programs that only uses the system interfaces and don't try to directly use the C64 hardware will run on the X16. On the one hand, that's nice because it's familiar to people who've programmed on the C64 and it will be possible to port over C64 programs relatively easily, but on the other hand, even within the limitations of an 8-bit computer there are a lot of things we could do better these days. For instance, the C64 uses a weird variation of ASCII that makes exchanging text pretty annoying.

BASICODE on the X16

So I wanted to see what it would take to run BASICODE on the X16 using the emulator. I didn't know yet they'd licensed the C64 ROMs so I was surprised to see how compatible the X16 really is with C64 BASIC and C64 system calls. For the most part, the only thing I had to do is change my cursor position code a bit to use the official API call rather than jump directly to the KERNAL code.

But... Cursor positioning once again turned out to be my nemesis. Although the C64 has a 40-column screen, when you move beyond column 39, you continue on to 40, 41 and so on, until 79. That way, you can type lines of BASIC longer than 40 characters. So that creates trouble with BASICODE programs try to figure out the size of the screen. For the C64, I just made sure you couldn't go beyond column 39 and line 24.

The X16's default text mode is 80x60 and it can also run in 40x30. So I had to figure out which mode we're in to tell the difference between the actual column 40 on a 80x60 screen, or the face column 40 on a 40x30 screen. BASICODE programs may also try to figure out the size of the screen by specifying line 100 or so and see on which line they actually end up. But specifying a line outside the actual screen hangs the computer (or emulator). So I had to work around that, too. Eventually I managed to do all of that, and that same code now runs correctly on the C64 and the X16 both in 80x60 and 40x30 mode.

I've updated the my C64 BASICODE subroutines here. Here are some BASICODE programs in English. I like Sea Wars, which is a pretty good version of Battleship, which can run in Dutch, English, French and German. This is the PRG file that will run on the C64 or Commander X16: seawars.prg.

Permalink - posted 2021-05-30

A new life for the 2003 Apple Wireless Keyboard

▼ Back in 2003, Apple released the Apple Wireless Keyboard:

(Not to be confused with later keyboards of the same name that look like laptop keyboards.)

The keyboard still works with an ancient MacBook Pro, but it won't pair with anything from the 2010s. That's too bad, because I think it looks pretty nice. So I decided to see if I could bring its essence into the 2020s by transplanting the keycaps to my Drop CTRL keyboard.

Here on the left is a regular MX style keycap, and to the right one from the AWK2003. Not so different.

Until we turn them over:

However, the AWK2003 keycap will fit on a Cherry MX style switch, especially a Kailh box switch:

But the fit is too loose. However, we can fix that with some teflon tape.

Three layers seems to work well:

And there it is: the Drop CTRL keyboard with 2003 Apple Wireless Keyboard keycaps:

The keycap profile is a bit different, especially on the bottom row, as you can see with the alt key:

It's not possible to replace the entire bottom row with keys from the AWK2003, as only the alt key has a standard size.

So I used the regular keycaps for the bottom row and the cursor keys:

With three layers of teflon tape, the keys mostly stay put, but this is what can happen after a good long typing session...

Permalink - posted 2021-03-05

Update: autobooting a superkickstart Amiga 3000 from the Buddha IDE card

▼ Last week, I wrote about upgrading my Amiga 3000, where I mentioned that the Amiga 3000's boot ROMs don't recognize the Buddha card. Turns out, that can be fixed.

Early Amiga 3000s don't have their regular kickstart in ROM. Instead, they have a kickstart version 36, which will normally try to load an older kickstart 1.3 or newer kickstart 2.0 from a floppy or the harddisk. Also, this needs to be a special kickstart file, which has a "bonus" attached at the end. To make this work, you need to have a harddisk partition with the device name wb_2.x. That partition must be the autoboot partition with the highest boot priority. (If not, the kickstart 36 will try to boot the system itself, and quickly run into software that is incompatible.)

At some point, I noticed that the v36 bootROM only recognized one of the four cards in my Amiga 3000: the ISDN-Master card in the lowest slot. Above that was the CyberVision 64/3D card and above that the X-Surf Ethernet card and the Buddha. So what if the CV64/3D made the AutoConfig™️ process fail, so the remaining cards couldn't be configured? That hunch was correct. After moving the Buddha to the lowest slot and the CV64/3D to the highest one, all three other cards were recognized, so the bootROM would load kickstart 2.0 from the Buddha.

However... that old kickstart 2.0 then in turn wouldn't recognize drives connected to the Buddha, at least not as autoboot targets. Long story short, I made a kickstart 3.1 superkickstart file and put that on a Buddha partition. With that in place, everything finally works reliably without any dependencies on the SCSI HDD.

Making a superkickstart

So how do you get a 3.1 superkickstart? First, you need an Amiga 3000 kickstart file. I wouldn't waste time with a kickstart for a different machine, although that may or may not work. I spent 20 euros on the Amiga Forever 8 plus edition. That's an Amiga emulator package for Windows sold by Cloanto, the current owner of (most of?) the Amiga intellectual property. It comes with all versions of kickstart and workbench. Alternatively, the ROM file that comes with Hyperion Entertainment's AmigaOS 3.1.4 should do the trick. And there's numerous utilities that will write an Amiga's kickstart to a file, so you could use one of those if you have an A3000 with a suitable kickstart version in ROM.

What you also need is an original superkickstart. But if your Amiga 3000 still runs, you should have that. Then use Epsilon's instructions on how to combine the bonus code from an old superkickstart with a new kickstart file to make a superkickstart. When I tried that, it didn't work. Turns out Cloanto scrambles their kickstart files to make illegal copying harder. You can tell you have a scrambled one because it's 524299 rather than 524288 bytes long. However, the romtool copy function will unscramble your kickstart file. (This runs on a Mac or under Linux.)

For good measure, I also used MakeSuperDisk to create a kickstart 3.1 floppy. (Well, Gotek ADF file.) However, when loading the kickstart that way, none of the drives are recognized as bootable...

Making it all work together

To finish the whole ordeal, I created the following setup:

• SCSI HDD in its original setup, with wb_2.x as the device name and a low boot priority.
• The DOM (Disk-On-Module) that comes with the Buddha has about 94 MB of unused space. So I made a new wb_2.x partition there with a slightly higher boot priority and an AmigaOS 3.1 installation on it.
• Last but not least, on a CF card I made a wb_2.x partition with a more extensive AmigaOS 3.1 installation and the highest boot priority.

The idea was that with the Buddha available and the CF card plugged in, I would boot from that. With the Buddha but without the CF card, I would boot from the DOM. And with the Buddha unavailable, I'd still boot from the SCSI drive. However, that last part didn't work: if the SCSI drive device name is wb_2.x, the system will try to boot off of that drive regardless of the Buddha. So I gave the SCSI drive a different device name and made it non-bootable for good measure. This of course easy enough to change with HDToolbox without disrupting the data on the drive. Between the Buddha DOM and the CF card, my trick did work, but remember: the kickstart will only be loaded from wb_2.x if wb_2.x has the highest boot priority.

I use assign dismount <drive> and assign dismount <volume> in my s:user-startup to make the SCSI drive and BuddhaInstall DOM partition invisible and quietscsi11 to make the SCSI drive motor stop spinning so it's quiet. You can also just do assign dismount <volume> to make a volume invisible for the Workbench, but you can then still access files on that drive/volume through the device name.

All in all, I think I'll probably remove the SCSI drive the next time I open up the computer. Also, I originally got transfer speeds of almost 2.3 MB/sec with the CF card, but now only 1.7 MB/sec. Perhaps this has something to do with the presence of the DOM. However, I like being able to swap out CF cards, so I think I'll leave the DOM in place even if that slows down transfers by half a megabyte per second. (But there could be another reason for that, too.)

Permalink - posted 2020-10-31