Review: MouSTer: making my favorite wireless mouse work with my Amiga

▼ Original Amiga mice were never that great, and a few decades of use and storage didn't help. So if there's one part of the Amiga I have no problem replacing with something new, it's the mouse. (Don't feel bad, I swore of Apple mice, too.) So a while ago I got a USB-to-DB9 mouse adapter. That one worked fine with wired mice, which was a big improvement.

An Amiga 3000 "tank mouse", an Amiga 1200 mouse and a 2000-era Logitech Mini Wheel Mouse

However, a few years ago I discovered the Logitech Anywhere MX 2 wireless mouse. I liked it so much I got one for at home and one for at work. The MX 2 is a bluetooth mouse that can pair with three computers. You can simply switch to another computer with a small button at the bottom. Now obviously the Amiga doesn't do bluetooth, but the MX 2 comes with a Logitech unifying receiver, which you can plug in any USB port and then the computer thinks it's talking to a wired USB mouse.

Problem solved, right? Not really. The MX 2 didn't work with that adapter, nor with another one. Eventually I went as far as to get a RapidRoad USB adapter for my Amiga 1200. This does work very well most of the time, but the complex USB software is not compatible with most games and is not 100% reliable.

The MouSTer connected to a DB9 extension cable, with the Logitech unifying receiver and the MX Anywhere 2

So when I read about the MouSTer, I thought four times might be a charm. After waiting for the little device to make its way from Poland to Holland over the course of very many days, it arrived today. So I plugged it in and... not much. The mouse pointer did move a pixel or two, but nothing close to working correctly. Then I noticed:

So I plugged a USB thumb drive into the MouSTer, which produced furiously blinking LEDs. Afterwards, there was a new directory on the flash drive, with in it a file named MOUSTER.INI. This is a text file with settings and clear explanations what they do. Out of the box, the MouSTer was set up for the Atari ST (hm, maybe the capitalized ST in the name should have been a clue?). I quickly changed that to "amiga". For good measure, I downloaded the latest firmware and put that next to the MOUSTER.INI file and put the thumb drive back into the MouSTer. After that, different mice worked as expected, with just some tweaks to the DPI divider and LED heartbeat settings needed.

A modern optical mouse like the MX Anywhere 2 sends way more "hey, the mouse has moved" pulses than the Amiga expects. As a result, when you move the mouse quickly, the mouse pointer jumps around because the computer can't keep up. Using a DPI divider ("microstep") value of 2 - 5 on the MouSTer didn't completely solve that for me, but using the Mac Logitech Options program to tell the mouse to use the minimum pointer speed, along with a microstep value of 2 made everything work satisfactorily.

Amiga mice normally have two buttons. The DB9 port has just one unused wire, so the Amiga can recognize a third button, but that's it. No scroll wheels—without using different hardware. However, the MouSTer will helpfully map any additional mouse buttons to the three the Amiga can recognize, with or without autofire. A program like FreeWheel will let you do something useful with the extra mouse button.

You can tell the MouSTer is starting up after turning on the computer because its yellow-orange light flashes furiously. (It'll tell you any error messages in morse code.) This is fast enough that if you press both mouse buttons as you turn on the computer, you're greeted by the boot menu as intended.

Conclusions: after only a few hours of use, I'm already a fan of the MouSTer. The hardware is nice and small, so it doesn't stick out far enough to get in the way. The electronics are visible, but covered with plastic so no chance of accidental shorts. The configuration method is unorthodox, but works well. I tested it with both a wired and a wireless mouse, as well as a couple of joysticks. Everything worked. (It also supports gamepads.) Using the Amiga mouse port is a mixed blessing. On the one hand, it's a limitation: only the one extra middle button and no scroll wheel support. On the other hand, it works with everything. In my case, I simply use two Logitech receivers: one on the MouSTer and one on the RapidRoad. So I just flip the mouse and push a button to switch between features and compatibility. 😎

Permalink - posted 2021-07-24

Iconverter makes your old Amiga icons look right

▼ The way the Amiga handles icons changed a number of times over the history of the platform, with the result that many older icons don't look right on Amigas running later versions of the OS. I made a tool to convert these old icons so they look like they should on later Amigas: Iconverter.

Iconverter is a tool for converting old icons so they look as intended on Amigas running a more recent operating system.

In particular Iconverter will convert OS 1.x and MagicWB icons to NewIcons format using the palette those icons were created for. (Also OS 2.0 - 3.1 icons, but those usually look correct without conversion.)

Note that you need to run the NewIcons extension or the new IconLib_46 on an AmigaOS 3.0 or 3.1 system in order to see the converted version of icons created by Iconverter. AmigaOS 3.1.4 and 3.2 will show them "out of the box".

Iconverter is a shell / command line tool written in standard C. As such, it should compile and run on any system that has a C compiler.

Permalink - posted 2021-07-14

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

Getting the "Music" miniplayer back to actual mini

▼ I just had a moderate-size scare: I typed something into iTunes Music, and the miniplayer now showed playback controls:

That's not what I want. I want it to show the album artwork. That's how I've used iTunes and now Music for many years. If I need to interact with the controls, those will then come up when I place my mouse pointer over the miniplayer window. In the view menu, there is no option to get back to my usual setup.

But it's pretty easy to do this if you know how: just drag the bottom corner of the miniplayer window up until the window is roughly rectangular, and after releasing the mouse button:

This is actually quite a good way to change the layout of the miniplayer. (You can also make the window even smaller or even larger to get different results.) However, it's also extremely un-discoverable.

A free tip, from me to you.

Permalink - posted 2021-04-13