CoCo 3 Upgrades: Hitachi 6309 CPU, 512KB RAM, PS2 keyboard

Installed a bunch of CoCo 3 upgrades from Cloud-9 Tech over the weekend:

• I upgraded the old 68B09 CPU to the powerful Hitachi 63C09. This involved desoldering the old CPU and replacing it with a socket. I also put in a Pro-Tector+ board to protect the CPU from the inevitable torture I have planned for this thing (once I get all of my electronics gear out of storage and back in one place).

• The Cloud-9 512K Triad upgrade board (the blue triangle) was trivial to install by comparison. Following the instructions, I removed the four old (128K) RAM chips, snipped a couple capacitors, and plugged it in:

• Cloud-9 also sells a nice PS2-keyboard upgrade board which was an easy install (no soldering):

I enabled 6309 native mode (15%+ faster vs. 6809 mode) and tested it with my gcc6809 compiled test program. Here it is outputting text to the 40x24 text mode:

I'm currently scrolling the text screen up using a simple C routine. It's so embarrassingly slow right now (even at 1.89MHz 6309 native mode) that you can kinda see the scroll function move the lines up the screen. But this is fine for simple printf()-style debug output. I'm using this BSD-licensed tiny printf() for embedded applications.

I've also compiled in the DriveWire 4 assembly 115kbps/230kbps I/O routines into this test app, so I can do disk I/O without relying on OS/9 or the BASIC ROM routines. My plan going forward is to continue completely "taking over" the machine and just do my own thing (no OS at all). It should be easy to code up a DriveWire compatible I/O disk module (here's the DriveWire protocol specification).

The Color Computer 3's 256 Color (Artifacting) Mode

I've begun playing around with the CoCo3's 256-color artifact color mode (more info here, here, and here, and a Youtube video here). It only works on the composite or RF modulator outputs. You basically set the 640x192x4 mode, fill the 4-color palette with grayscale entries (palette entries 0, 16, 32, 63), and then treat each byte as a separate pixel. (Normally, each byte would contain 4 separate pixels in this mode.)

The various grayscale signal patterns cause different sorts of chroma channel "leakage", leading to the below colors. (The X axis is the least significant nibble in this shot.) This shot was taken on an old LCD monitor (Samsung 150MP), hooked up to the composite input. The actual colors were more vibrant/unique than they appear in this photo.

It's a pretty sweet mode, and what's amazing to me is that all the programmers from the late 80's who worked on this platform mostly ignored it (probably because it didn't work on RGB monitors). Some pretty sweet things could have been done with it because 1 pixel per byte is quite convenient and it didn't need any funky tricks like frame flipping, or mucking with video palette registers in a interrupt handler. I still remember seeing some 256-color images of some photos in the late 80's for the first time (at a Radio Shack store on a Tandy 1000), and being utterly amazed at the detail.

Apparently Tandy engineers were planning on including a real (not artifacted) 256 color mode in the updated CoCo 3, but the execs didn't want their little CoCo line to compete against their big Tandy 1000's. So in a ridiculously shortsighted decision they nixed the idea. However, there were rumors that this mode was actually implemented in the CoCo3's "GIME" graphics chip anyway but just not documented. The fascinating history and technical details can be read about here. Through some sleuthing the author even tracked down and interviewed the hardware engineer who created the CoCo 3's GIME chip, John Prickett.

I've decoded a color JPEG using this mode. These first results are totally crude, but hey it's progress. My palette currently sucks -- I built it from the above image taken on an iPhone just to get things rolling. I didn't use dithering, which would certainly help, but the palette entries are the real problem right now. I've not been able to find an "official" palette or conversion algorithm anywhere yet, so I'm going to somehow either compute one or (maybe better) find a video capture card somewhere and just sample it.

picojpeg: Decoding Lena on a Tandy Color Computer 3

Got a small grayscale version of Lena decoding to the 640x192x4 (HSCREEN 4) graphics mode using my picojpeg.c module. Here it is on an old LCD monitor hooked up to the CoCo's composite output:

In case you didn't know, the Color Computer is a classic 8/16-bit personal home computer from Tandy Corp./Radio Shack. The particular model I'm using (CoCo 3) was released in 1986. (As a kid I always wanted a CoCo 3, but I was stuck with a 16KB CoCo 2 and by the time I could afford to upgrade I had moved on to the PC.)

This is using a 2x2 ordered dither matrix, zoomed by 2x horizontally (displayed as 256x128), using composite out as a sort of inherent low pass filter. The BASIC program currently sets the graphics mode, programs the grayscale palette, and then jumps into the C code's _start function:

10 CLEAR12,9984
20 LOADM"TEST.BIN
30 HSCREEN4
40 PALETTE0,0
50 PALETTE1,16
60 PALETTE2,32
70 PALETTE3,48
80 EXEC9991

The C code (compiled using gcc6809 under Linux) disables interrupts, maps the graphics pages into the ROM area (starting at 0x8000, ending at 0xFEFF or thereabouts) using the MMU0 registers, then decodes the ~4KB JPEG and plots the pixels as each JPEG MCU block is decoded. It currently takes about 45 seconds to decode the 128x128 image, which beats the PIC18F microcontroller I was using a few years ago to originally test this code (that thing would take 10-20 minutes!).

Everything is completely unoptimized - I'm just glad to get it working at all. Using a CoCo to prototype/test this kind of stuff is actually much nicer overall than working on a tiny microcontroller. The CoCo community has compiled a large suite of documentation over the years, and there's a very nice set of tools available. Not to mention I've got built-in (albeit limited) graphics, 128KB of RAM, a 6-bit DAC for sound output, and various forms of input. The 6809 is a surprisingly powerful 8/16-bit CPU to work on - if you push it right.

This poor 1986 CoCo3 has seen better days (the case is an all-yellow wreck). I need to find a machine in better shape:

Zoomed in further, with a 4x4 dither matrix:

picojpeg on a Tandy Color Computer 3 (6809 processor)

I've gotten my picojpeg.c module decoding JPEG images on the (almost) 30 year old CoCo 3. Here's my first 16x16 decoded image on a 6809 CPU. (For all I know, it could be the first JPEG to be decoded on this particular CPU.) The upper nibble of the red component was written to each character of the default low-res 32x16 text screen. It's currently damn ugly, but this is good enough to verify the pixels are being decoded in this test image.

For the compiler, I'm using gcc6809, compiled under Ubuntu 13.10 (with several evil workarounds to get the compiler to build at all), ToolShed to convert the .bin file to a CoCo .dsk image file (running via Wine), and DriveWire 4 (running on another machine with Win7) to transfer the .dsk file to the CoCo. The .dsk image also has a small MS BASIC program to LOADM the .bin file and EXEC it at the right start address.

Unfortunately, I can't run it again without restarting the machine and booting up DriveWire again -- no idea why yet. If I hit reset and EXEC the decoder again it does something but the output image is bogus. This process is terribly slow because after restarting the machine I must CLOADM the DriveWire 4 client over the cassette port (hooked up to my PC's sound output). The DriveWire booting process uses Winamp to play back the cassette sound file!

 The test JPEG, enlarged by 8x and converted to PNG:

The next step is to figure out why I can't restart it without shutting down, and then switch it over to a CoCo 3 16-color graphics mode and add some sort of dithered output. After that comes lots of 6809 specific optimization. It'll still be slow as molasses, even after tuning it, but it's fun anyway.

Figuring out how to build gcc6809 under Ubuntu 13.10, then to get this sucker to output CoCo compatible .bin files was a pain. Figuring out how to enable gcc compiler optimizations without causing aslink to core dump was even more fun. I'll post all the things I had to do soon. It's pretty cool to have a modern C compiler capable of targeting the machine you started with..

Few tips from Mike Sartain on QtCreator Projects, Ninja warning/error parsing

Mike has been improving how we use QtCreator on vogl a lot recently:

QtCreator projects

QtCreator and Ninja warning/error parsing

QtCreator's support for custom builds (in our case, cmake+ninja) is surprisingly flexible.