My keyboard and key rollover tester

▼ I have a new mechanical keyboard on order, which lets you hot swap the keyboard switches. When you do that, it's a good idea to do a quick test to see if all the keys still work. There are many tools to do this, but I decided to make my own web-based one. I think it came out pretty nicely.

You can see if the keys work by typing them one at a time, or (usually) by running your finger along each row.

In addition to that, you can also see how much key rollover your keyboard supports, i.e., how many keys you can type at the same time. Higher end keyboards usually support "n-key rollover" (NKRO), which means that any combination of keys will be recognized correctly. This is useful for some types of games.

Old keyboards usually don't support any additional rollover, so they can only correctly recognize arbitrary combinations of two keys. (This limitation doesn't apply to shift/control/alt or command/windows.) Additional keys may or may not be recognized. However, it doesn't really matter too much if you can't type Z F6 . For non-gamers, what matters is that when you type quickly, it can happen that one finger hasn't released the previous key yet while another finger is already pressing the next key. Turns out that on many keyboards that don't support real 3-key rollover, you can still type three (or more) keys at the same time, as long as those keys are all on different columns. Which means: you type them with different fingers. After all, how are you going to type E, D and C at the same time, as touch typists type all three of those with their left middle finger?

A common additional limitation (to avoid more complex USB communication) is a 6KRO limitation.

What the rollover tests (for 3 - 7 KRO) do is test combinations of all the regular alphanumeric keys and most punctuation and then tell you if it looks like you have full key rollover, enough for touch typing or no real rollover for that number of keys. You can of course also just press as many keys as you like at the same time and see if they register.

So have a look and let me know what you think.

Permalink - posted 2020-12-24

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