Gravis Ultrasad

« Koala Pad »

Posted on 01 August 2018 20:08 in Hardware
Last updated on 04 August 2018 14:08
koalapad c64 pc msdos retrocomputing art

A week or so ago I was on eBay and stumbled across a thing called a Koala Pad. I had seen and heard of these before - it's basically a graphics tablet from 1983 that came out for damn near every home computer platform. I had seen them for the C64 and Apple II, but this one caught my eye.

See in the lower right?

I had never seen one of these available for the IBM PC. Now, the PCjr is not quite a PC; it's a weird, half-baked entity IBM made to try to compete in the home computer game market. It failed, but left a small legacy of more or less proprietary software behind.

What's strange about this listing though is that the stick itself isn't proprietary. And the PCjr joystick interface absolutely was - it was a horrible little thing: 

The connectors on the back of the PCjr were all completely identical, and the connector itself was terrible - basically just two rows of pins, like a DIP header on a circuit board. One of the cheapest connectors I've ever seen, and the stick in this listing doesn't have it:

See, that's an ordinary IBM PC gameport, the 15-pin that's on everything except the Jr. So it appears this eBay seller has a whole mix of things - a PC Koala Pad, the PCjr-specific disks, and this listing also included the C64 Pad and cartridge. This guy must have cleaned out an estate sale from a collector of these things.


So I ordered it, and they arrived a few days later and I confirmed my suspicions, it really was as described. I started out by trying the C64 software and hardware.

It worked perfectly:

Well, "perfectly" isn't quite the truth. You can see some glitching around the upper edges of the "hole" in the hill; this is where the pad apparently splattered some glitched pixels, a phenomenon another Koala Pad owner told me on Twitter was normal. The pad itself is also rumpled - the plastic top surface is delaminating, a phenomenon I don't know if I can stop or fix. But honestly I doubt people ever got much better out of this thing than you see above, so I call this a win.

Turning my attention to the PCjr model, I had to tackle the software problem. The software, KoalaPainter, came on a 5.25" disk, and my Dell had no 5.25" drive. I'll make a separate post about that so it'll be easy to find later, since I'm sure I'll need it again. Suffice to say it was a tremendous pain in the ass to get my 5.25" drive working on a machine newer than the early 90s.


I popped in the KoalaPainter disk and tried to read it, and just got "Not ready reading drive A." The disk light wasn't even coming on. I tried ejecting the disk and found out it was stuck. I tried a few more times with no success, then popped the drive out of the machine, reached inside and shoved it out from the other end, fortunately with success.

I took a look at the disk and realized someone had set something on it. The edges were curled up, the disk was completely bowed. I tried straightening it, but it's basically impossible to do this with old floppies. I don't know if the plastic was stiff and brittle to begin with or if 30+ years did that to it, but if you try to bend 5.25"s they just stay the way they are, or shatter completely.

The only real option after that was a transplant. I found a blank disk, verified it slotted in and ejected okay, and pulled up the heat seals. It was a gigantic pain in the ass; one of the seals just shattered and gave me a hell of a time getting that side released, the other two were so inelastic I could barely get the sleeve open. I pulled the disk out of the donor sleeve and repeated the process on the KoalaPainter disk, then very, very carefully lifted the disc itself out of one and slipped it into the other.

I put it into the drive and this time it seated okay. I tried to index the disk, and this time I got a listing.

This was promising, but when I started copying the files off I immediately began getting read errors. I retried several times with no success. I popped the disk out and examined it, and the surface showed plenty of worrying signs - splotchy looking white crud all over it that many say is probably mold. I figured I had little to lose however and tried swabbing it off with a q-tip, carefully wiping from center out (does this really make a difference? i doubt anyone has tested in a lab in 30 years).

This time when I put the disk back in I was able to copy off several .PIC files, but when I hit DRAWDATA.DAT it crapped out again. I repeated the process, this time swabbing the disk more thoroughly, and then I was able to copy off everything except KP.EXE - the most important file on the disk, of course. 

At this point I figured, well, this software's online. I remembered stumbling across it when I was looking for the manual for the C64 version, so I knew I could just download an image if it came to it. I did want to get an actual copy of the disk anyway though, so I went for the nuclear option. Since the disk was clearly filthy, I figured I'd try actually washing it.

Some googling came up with a page suggesting that either isopropyl, or water with light soap was safe enough. I wasn't sure if I should trust it, but nothing to lose, right? So I slipped the disk out again, this time onto a T-shirt (I've never encountered anything with less free lint), sprayed some iso on the fabric and wiped it all down. Flipped over and repeated, then put the disc back into the sleeve. 

Nothing changed. I retried several times - 10 or 20 - and then, crestfallen, went to the internet and searched for the software.

After twenty minutes I accepted, to my deep horror, that this disk was not online, and I had just possibly wrecked any chance of ever recovering it. For all I knew, nobody else had this at all, and now it was lost to time. 

Last Hope!!

I got pretty distraught and started trying to copy the files over and over and over, hitting retry again and again and again. I popped the disk out and back in, relisting and recopying repeatedly, dejected. And then, on the fourth or fifth eject and re-insert, I got a "KP.exe copied" message.

I couldn't believe it had worked, and I still didn't until I edited the file, confirmed I saw the DOS EXE header at the top, then scrolled to the bottom and saw the runtime library strings. I tried running it and just got a *** STACK OVERFLOW *** error - but this was a program designed for an 8088 running on an 800mhz P3, so I figured that might be normal.

I made sure I had copies of every file on the disk, then started the machine in Win 98 and copied C:\KOALA to my modern PC. I started up DOSbox in PCjr mode, executed KP.exe, and:


This was a huge success! Unless there's corruption in the middle of the file, it looks like I got a clean copy! I immediately uploaded it to the Internet Archive, in case my hard drives all died at once, and did some tests.

I don't have a gameport on my desktop PC, so I tried a gameport→USB adapter. I didn't expect it to work, and I wasn't surprised when Windows joystick diagnostics showed the X and Y looping rapidly within the test field when I drug a stylus across the Pad. I noticed - unsurprisingly as well - that it looked like it was tracking, but every 1/2" or so the input jumped to zero and began tracking across again. This isn't a joystick, so that's not remarkable.

I tried using KP within DOSbox, but through the USB adapter and Windows joystick interface it was doing the same thing and I couldn't hit any of the UI buttons, though I did manage to knock it into draw mode and get a few dots on the screen. I actually also tried DOSbox on the Windows 98 machine, which has a native gameport, and the same thing happened, so I suspect this is an artifact of the Windows joystick API.

Further Investigation!!

The next day, with a fresh mind, I considered how I would test KoalaPainter itself to see if the EXE really was on the up and up. To do this I needed to be able to interact with it, which didn't necessarily mean having a Koala Pad working. I thought, if I could get a mouse to joystick interface, that might let me try out all the functions of the software. Since a mouse and a joystick are both absolute-input devices (the mouse itself isn't, but the cursor is), I knew this was hypothetically possible.

Software to do this is exceptionally rare and hokey - not at all what I wanted, if it would even work. I quickly turned to a different strategy, seeing if I could modify DOSbox itself. After an hour or so of hacking on the DOSbox source I was able to implement a crude mouse-to-joystick mechanism, enough to reflect the mouse coordinates within the DOSbox window reliably in a DOS JOYTEST.EXE app.

I started KoalaPainter and was overjoyed to see the cursor within the app move in time with the mouse cursor. It was very jittery though, and was tracking at about 50% proportions - with the mouse in the lower right corner, the KP cursor was roughly in the middle of the screen. I adjusted the multiplier for the conversion code and on the next execution I was pleased to see that the positions now matched up almost perfectly, although the jitter was still there.

The mouse buttons won't reliably trigger inputs, and I'm not sure what's up with that. I have not figured this out, and it has basically stopped me from further experimentation. I am able to interact with UI elements after a lot of hammering on the buttons, and one time I got it into drawing mode and got a few speckles on the screen, but I'm not really sure why it's not working better than this.

One thing I did discover, when I changed the CPU cycle count in DOSbox on a whim, is that the gameport read routine is definitely timed based on CPU cycles. When I clock up or down, the "multiplier" of the ratio between the mouse and the KP cursor position changes. So my code probably wasn't wrong to begin with, the program was just running at the wrong speed. This gives me doubt that it can ever be made to run correctly on DOSbox - timing-critical things simply can't be made reliable on that emulator, so I'm not likely to try much further. It was however an extremely entertaining experiment.

More Possibilities!!

From further reading it sounds like the Tandy 1000 is notionally compatible with the PCjr. I have a Tandy 1000, but I suspect I would see the same timing issues with it - my understanding is the Tandy runs at twice-ish the clock speed of the PCjr's 8088, and for some reason I can't change that speed setting like I'm told I'm supposed to be able to - the MODE command just doesn't exist.

Also, the connector is incompatible, so I'd need a PC→Tandy gameport adapter, or to build one. Honestly this isn't a bad idea, since my Tandy sticks broke very quickly (all joysticks made in the 80s, no exceptions, were hot flaming garbage.) But it prevents me from moving forward on testing this for the moment.

Update 1:

I tried the software on the Tandy and was pleased to find it executes with no problem. I haven't built a Pad adapter yet, but I was able to plug in a joystick and I can get about 30% screen coverage with it. I also figured out how the menu works, it's different on each platform and the manuals for KP are lost to time. The PCjr one was confusing to me as well.

To get from the menu to the canvas in the PCjr version, move your cursor to the far upper left and hit a button. To do it from the C64 version hold the stylus in the lower 10% of the pad near the center; you'll hear a beep, and you can now press a button to switch views. Return to the menu by using the same process in reverse.

With the joystick unable to get to the color palette I wasn't able to test much, but I was able to select fill, get to the canvas and fill the screen successfully.

I am not convinced the Tandy is running at the correct speed still. I googled it and found a page that strongly suggests my Tandy has had the OS replaced since the SLOW, FAST and MODE commands aren't present and confirms the machine starts in the fast mode. I tried the linked speed adjustment tools and I don't see any difference in the program performance - maybe these are not truly using the Tandy 1000HX's approach, so I might need to retrieve the original OS disks to resolve this.

I suspect if I fix the speed issue, the joystick would be able to navigate the full screen and I could paint with it. Obviously the goal is to have the Pad working but I would like to be able to use the joystick in a pinch.

I have tried adapting the PCjr joystick to the Tandy port using clip leads but it was very shaky and I'm not convinced I even got the pinout right. More experimentation later.

View/Add comments (Warning: provided by Disqus and may include ads! Hidden for your safety!)