Author Archives: Marcel

Of mice and men (but mostly mice)

Mice for the QL always have been kind of a problem. In the age that predated USB by two decades there was simply not the one mouse standard to rule them all. Every system did pretty much its own thing and getting a mouse that actually worked wasn’t that easy to begin with. In fact I have never even owned a mouse for the QL that worked right out of the box, every mouse had its electronics ripped out and replaced by something else to work with my trusty SuperQBoard clone. This posed a problem for me as I have recently resurrected my trusty QL but apparently the mice were thrown away at some point or other. Jochen Hassler kindly gifted me one of his old mice, but it was brown with age, the ergonomics is questionable and I really didn’t remember what a pain the ball-based mice were to use compared to their optical brethren.

This lead to the idea of implementing a converter, like taking a cheap Arduino Pro Mini to interface a modern USB mouse to the old SuperQBoard port. Fortunately before starting such a project I had a look at what’s already there and found the “New MKIV Amiga/Atari USB mouse adapter” for about 16€ plus postage. Atari mice are generally the type used for the QL, too, so I just bought it. The first tests a few days later weren’t that encouraging, nothing worked at all. So I had a look at the schematics of the SuperQBoard and found out that although electronically it’s Atari/QIMI compatible, it used a completely different pin layout!

Long story short, this is the pin mapping I came up with

SuperQBoard QIMI/Atari Signal
1 9 Right button
2 6 Left button
3 1 XB
4 3 YA
5 7 +5V
6 4 YB
7 2 XA
8 5 n/c or middle button
9 8 GND

After building a suitable adapter cable the optical mouse began to light up, indicating the power is there, and the buttons worked, too, indicating a working mouse protocol on the USB side (or rather PS/2 side really, the adapter only works with mice that can speak the PS/2 protocol over the USB connector) but the pointer only moved very erratically. So after some hair pulling (as if I still had any) I went back to the schematics and saw that apparently unlike QIMI my SuperQBoard clone only had pull-up resistors on the mouse button lines and not on the lines responsible for X/Y movement! So I decided to integrate them quick&dirty style into the adapter cable:

Quick&dirty integration of pull-up resistors…

… but in the end, who can tell

And what can I say, it worked so smoothly it was a pure joy to use.

So, lessons learned:

  • The adapter might be used together with a QIMI interface right out of the box
  • SuperQBoards used a pinout different from QIMI
  • SuperQBoards might be lacking the necessary pull-up resistors
  • Hardware tinkering is still fun

New QPC2, DISA and more

Every year I take the birthday of my daughter as an incentive to get stuff out of the door.

So this year I present to you:

QPC2 v4.05

This is mostly a bugfix release. It includes the latest SMSQ/E 3.28. One option was added that instead of a fixed resolution it can use the maximum resolution of the current monitor. Select “Max” as a resolution to do this.

Get it from the Downloads page.

… but there is more

The disclaimer for the following software: you may not sell the software and they come with no support whatsoever.


My old friend Jochen Hassler was over for dinner a few days ago and I asked him if I may release his software. He said yes, so here I present to you DISA, a pretty revolutionary disassembler at its time. V3.04 was the last official release done by Jochen in 1999. I adapted the source code for high colour in 2003, but this release 3.05 has never left my hard drive until today. So here they are:

DISA 3.04
DISA 3.05
DISA examples

As I got most of my software directly from the authors I usually lack the original manuals, as it is in this case. If somebody could provide that to me I can add it to the distribution.

Update: Thanks to Albin Hessler (who provided the Word document for v2) and David Westbury (who provided a scan of v3) I can now provide the latest manual here: DISA3E.pdf

ATR device

I didn’t have the time to sort through the source and binaries I have of the ATR device, but I know for example that Dilwyn has a few ROMs or binaries and those can now be used freely, too.


And finally I had a chat with another old friend of mine, Jochen Merz, and he agreed to officially release QMenu for everybody to use. So here is my latest menu_rext file:

Menu_rext 7.66

Update: apparently I’m not up to date in regards to QMenu, but 7.66 is the latest version I had the source code to. I will do a follow up when I know more about the later versions.

Was this a great birthday or what? 🙂

Have fun, Marcel

HomeMatic: Gehäuse/Verstärker für HM-OU-CM-PCB

English: HomeMatic home automation articles will be in German as this system is mainly used there.

Den Anfang meiner (zumindest geplanten) HomeMatic Serie macht ein bereits älterer Aufschrieb über den Bau eines Gehäuses für den HM-OU-CM-PCB. Als Ausgangs-Basis dient ein bei Pollin erhältliche “Tragbarer Aktiv-Lautsprecher PULSE”. Anders als bei Pollin üblich ist das Ding auch ein Jahr nach meinem Bastel-Projekt noch erhältlich, mittlerweile sogar schon für wahnsinnige 3,95€!

Der eingebaute Verstärker liefert mit 3 Watt viel Bumms, läuft allerdings mit 5V während der HM-OU-CM-PCB mindestens 8V fordert. Der “richtige” Weg wäre es wohl 8V außen anzuschließen und dann intern auf 5V zu senken, wie es der HM ohnehin macht. Bedeutet aber größere Arbeiten an der Verstärker-Platine wenn man die vorhanden Buchsen des Verstärkers weiter benutzen will und Wegfall der USB Versorgung. Ich hab mich dafür entschieden den Step-Down Wandler auf dem HM zu umgehen und die Platine direkt mit 5V an Pin MP11 zu speisen. Auf eigene Gefahr, man verliert damit den Verpolschutz! Dies stellt dann auch erhöhte Anforderungen an das verwendete Netzteil, die 5V müssen sehr sauber reinkommen sonst gibt’s jede Menge Stör-Geräusche! Ein altes iPhone Netzteil bzw mittlerweile sogar ein billiger 5€ ALDI Zwischenstecker mit USB-Ladeausgängen verrichten hier bei mir aber sehr gute Dienste.

Den internen Verstärker des HM sollte man wie in der Anleitung beschrieben abklemmen und den Ausgang dann mit der Klinken-Buchse am Verstärker verlöten. Dann noch Masse und die 5V rüber und fertig ist die Kiste. Für den physischen Halt habe ich den Batterie-Halter etwas aufgedremelt so dass man die Platine hineinschieben kann. Hält ganz gut und man kommt nach dem Öffnen des Deckels bequem an die SD-Karte.

Den Rest erklären hoffentlich die Bilder.

QMovie v2.00

In my last post I lied that regarding the QMovie player “I’m done here”. OK, to my defense, even I didn’t know that I’m not done yet. So today I present to you QMovie v2.0:

The details and downloads are on a dedicated QMovie page.

QMovie SMSQ/E movie player

This has been superseded by QMovie v2

QMovie is a quick&dirty full colour movie player including sound for QPC. I really didn’t have the time to write this, but sometimes an idea latches itself into my head and I can’t let go until I have done something about it. So the target for this was “be done quickly” and not “be done perfectly”.

You can download it here (135MB). Just start the QPC2.exe and it should run. The movie frames are time synchronised to the audio. No double buffering (neither for the screen nor for the play buffer) nor any other fancy stuff is performed as the performance was already good enough.

Clip: The Iron Maidens recorded at the LKA Stuttgart by me. 10 fps, 20kHz mono

Creation of this video:

ffmpeg -i “IMG_7696.MOV” -r 10 -s 480×270 Frame_%04d.png
ffmpeg -i “IMG_7696.MOV” -f u8 -ar 20k -ac 1 sound.raw

Convert all Frame_%04d.png into _spr files using PNGConv. Settings: “binary”, “.” separator, “solid mask”, “no compression”.

The resulting Frame_xxx.spr and sound.raw files are combined using a quick Perl script called

The QMV Format is an interleaved data format with one second of audio, followed by one second (10 frames) of video in Sprite format (fixed size, must not be RLE compressed). No meta data is saved (remember, “quick” was the motto here), all things like resolution and frame rate are hard coded into the qmovie_exe file.

Feel free to improve it, I’m done here 😉

Wrapping stdcall functions in Node FFI

A colleague of mine needed help wrapping some C DLLs for NodeJS. He’s using the Node FFI API for the wrapping, which unfortunately is a little light on documentation. The problem was that by default Node FFI wraps cdecl functions and there is no mention of stdcall anywhere. In fact the consensus on the net seems to be that it’s not possible at all. Reading the sources proved more fruitful and so I document the way here for future generations to find:

The standard way of initializing a FFI wrapper using the array in the constructor

actually takes an additional parameter with the calling convention, but in stdcall the function names are often decorated with an additional “@x” which denotes the bytes the function parameters need on the stack. Problem is, blah@x is not a valid identifier and in the array the Javascript function pointer always has the same name as the function in the DLL. The solution is to manually wrap the functions, which I actually prefer anyway as the function pointer doesn’t end in a struct but can be used directly afterwards:

The resulting wrapper is called using “AdsPortOpen()” and it accesses the function with the decorated name “_AdsPortOpen@0”. The easiest way to get the decorated name is using the dumpbin utility from Visual Studio with the “/exports” parameter:

C:\Windows\System32>dumpbin /exports gdi32.dll
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file gdi32.dll

File Type: DLL

  Section contains the following exports for GDI32.dll

    00000000 characteristics
    573C8294 time date stamp Wed May 18 16:56:20 2016
        0.00 version
        1000 ordinal base
         727 number of functions
         715 number of names

    ordinal hint RVA      name

       1012    0 00043F40 AbortDoc = _AbortDoc@4
       1013    1 00045806 AbortPath = _AbortPath@4
       1014    2 0003BA5C AddFontMemResourceEx = _AddFontMemResourceEx@16

HTTPS everywhere

Out of the blue my hosting provider finally offers one SSL certificate for free to use with my site. I’ve been using StartSSL certificates for my home servers for a long time now, but on the shared hosting servers I couldn’t just install my certificates and I felt the prices for regular ones are a pure rip-off.

In any case, finally got HTTPS support and I have adapted the site accordingly. I had to change all download links for this to work, so if I have missed a broken link or in case of any other problems, give me a shout.

QPC2 for Mac OS X

Sometimes things happen out of the blue. I haven’t heard from my fellow QL friend Peta Jaeger for years and yesterday he mailed me a complete ready-to-run distribution of QPC2 for MacOS X. Under the hood it employs the WINE Windows emulation layer, so QPC2 is of course still not a native Mac application, but it almost feels like one. I only have a headless Mac at home (meaning without a monitor or keyboard) and I’m currently 5km away from that, but even through the remote VNC connection it felt absolutely usable, which I find pretty amazing. Peta also included the Black Phoenix QL software distribution so you can start clicking through various applications right away. It is installed like pretty much any other Mac application, but if you have questions feel free to contact Peta about it.

Interested? Check it out on the Downloads page.

QPC2 running on Mac OS X

QPC2 running on Mac OS X

Analyzing the HomeMatic CBC authentication algorithm

This is my first post about my new hobby, smart homes in general and specifically HomeMatic, and it’s already quite a technical  one: solving the AES authentication problem with the new HM-SEC-SD-2 smoke detectors. The detectors use cryptographic authentication between them so that not every grumpy neighbour can activate the alarm. This is good, but also a problem when you want to activate the alarm yourself, as part of a burglary system for example.

The main tip came from Michael Gernoth, who mentioned that the CCU2 software used to contain a function called performCBCAuthentification, which sounded like it could fit the given scenario. Fortunately reverse engineering is something I’m usually pretty good at, so I set out to have a look. Reverse engineering binary code is somewhat akin to assembling ground coffee back into beans. Challenging but also satisfying when it works. The tool of choice is a somewhat expensive tool called IDA which my employer fortunately bought for me to do my job. Unfortunately not the very expensive version that can actually output C-like code, just the disassembler one, but we can work with that 😉

From ground coffee…

On the high level overview the function in question looks like this:

High level IDA function view

Which is actually not too bad. Somewhat regular and not too much code overall. Zooming into one part looks like this:

Inside the function

This may look wild to the untrained eye but is actually great news: one one hand, it’s ARM assembler, which I have never read before and also, it’s C++, which is a pain to read in assembler, but on the other hand we see that IDA found many symbols and that most function calls actually have names. This is like winning the lottery! One function call in particular shows what it means to have C++ code at hand:

BL _ZNSt8_Rb_treeIiSt4pairIKiSsESt10_Select1stIS2_ESt4lessIiESaIS2_EE17_M_insert_unique_ESt23_Rb_tree_const_iteratorIS2_ERKS2_ ; std::_Rb_tree<int,std::pair<int const,std::string>,std::_Select1st<std::pair<int const,std::string>>,std::less<int>,std::allocator<std::pair<int const,std::string>>>::_M_insert_unique_(std::_Rb_tree_const_iterator<std::pair<int const,std::string>>,std::pair<int const,std::string> const&)

Everything clear now? Thought so. Unfortunately our newly found fortune doesn’t cover variables and object properties, so parts like the following look a lot easier visually but without any clue what the data is, is a lot harder to analyze:

More ground coffee

It looks like it’s traversing a doubly linked list in search of the encryption key, but I haven’t analyzed this part of the code 100% and probably don’t need to.

… to the beans…

In the first step I tediously transcribed the code I’ve seen back into something somewhat resembling source code. By hand…

This is not supposed to compile and there might be transcription errors or bugs in it. It’s just to get your notes in order and is certainly a lot more readable than the code we’ve started with, so we can finally deduct the algorithm from it!

… to the algorithm …

Given the example frame of:

00 01 02 030405 060708 09 0A 0B 0C 0D 0E 0F101112
01 14 41 44E347 44E347 01 01 96 00 00 03 0A802A78
 | Flg | Sender Recvr   |  |  |    IV1 |  
Cnt  Type             Chn No State    IV2
  1. Build an initialization vector containing:
    1. One byte with the value 49
    2. The sender address (3 bytes)
    3. The receiver address (3 bytes)
    4. The byte marked “IV1”
    5. The byte marked “IV2”
    6. The Cnt byte
    7. 5 bytes of zero
    8. One byte with the value 5

    In our example frame this adds up to “4944e34744e347000301000000000005”.

  2. Encrypt this using the AES key, which results in “d064bd7e0161592f1175f1c9e822f87b”.
  3. Build a second frame using:
    1. The Cnt byte
    2. The Flg byte
    3. The Chn byte
    4. All bytes from field “No” up to FrameSize – 6 (just leaving out the signature and the IV bytes)
    5. Fill the rest up with zero so that we have 16 bytes again

    This gives us “01140101960000000000000000000000”.

  4. XOR the result of the AES encryption with our second frame. This gives us “d170bc7f9761592f1175f1c9e822f87b”
  5. AES encode the result again. This gives us “d051f2c911e8cb716057a89d0a802a78
  6. Lo and behold, the last 4 bytes match the signature in our example frame! Perfect

… to the end

The CCU2 code only contains the routine to check a signature, not to generate one. So at this stage it’s unknown to me why the two IV bytes have the value they have, as I don’t own the hardware yet nor was I given any more example frames to work with. Maybe they can be chosen freely, maybe they are counted up. In any case, the remaining work should be fairly easy to do in comparison. Hope I could help!

New QPC v4.04 plus SMSQ/E v3.26! With stipples!

A little over two years ago QPC2 v4 was made available for free to celebrate the birth of my little girl Marla. I wanted to release 4.03 for her first birthday but missed the date and then forgot about it (the changes weren’t that important anyway). So I planned to release what I have for her second birthday and missed that, too… then I noticed the 18th birthday of my web presence came up last week, so I was going to release it then for sure! Spoiler-alert: I didn’t make it. But this time for a good reason at least: Wolfgang wanted to include a few last-minute changes to SMSQ/E that would allow it to draw alpha blended blocks. I liked the idea in general, but just supporting blocks seemed a bit halve-baked to me, so I foolishly offered to extend the alpha blending support to the whole graphics sub-system!

Okay, this is a job that is, in principle, actually not that difficult, but in practice and when you want to achieve at least some level of performance it can be a bit of a pain to develop. Especially if you’re crazy enough to also aim for supporting the old-timey stipples, and I’m no man for halve-finished jobs, so stipples there will be! So, after the girls go to bed I usually have one or two hours to myself and I made some good use of them. Today I can finally show you the result:

Alpha blending (for all plattforms!)

The alpha blending support is, like INK, PAPER or OVER, a part of the settings of a window. The setting can be changed using the aptly named ALPHA_BLEND SBASIC command. It takes two parameters, a channel and an alpha weight from 0 to 255 with 0 being transparent and 255 being opaque. So, after executing for example ALPHA_BLEND #1,128 all future graphics commands on channel 1 including BLOCK, CIRCLE, LINE and PRINT will draw their contents halve-transparent over the existing background until alpha blending is disabled again (by setting the weight to the default of 255: ALPHA_BLEND #1,255). Here’s a little example:


The trap to control the mode from other languages is defined as thus:

|                                                                             |
|  Trap #3    D0=$62                                               IOW.SALP   |
|                                                                             |
|       Set the alpha blending weight for a window                            |
|                                                                             |
|  Call parameters                      Return parameters                     |
|                                                                             |
|  D1.B alpha weight (0..255)           D1   preserved                        |
|  D2                                   D2   preserved                        |
|  D3.W timeout                         D3   preserved                        |
|                                       D4+  all preserved                    |
|                                                                             |
|  A0   channel ID                      A0   preserved                        |
|  A1                                   A1   preserved                        |
|  A2                                   A2   preserved                        |
|  A3                                   A3   preserved                        |
|                                       A4+  all preserved                    |
|                                                                             |
|  Error returns:                                                             |
|        ICHN  channel not open                                               |

I don’t actually have any use for this feature myself, I just wrote it because, well, I could. I certainly hope somebody else finds it useful, though 🙂 And after all these years of developing SMSQ/E this is actually the first trap that I have defined myself (all other functions I introduced were vectored routines)!

DOS device rewrite (QPC only, obviously)

I’ve written many hundred thousand lines of assembler in my life and 20 years ago when hacking on an 8Mhz 68008 or even a 66 Mhz 486 this still made a lot of sense. But the times have changed a lot, not only are CPUs so fast that speed doesn’t really matter that much anymore, compiler became so good that you will have some real trouble beating them with your average assembler code! Also, CPUs have been optimized to execute compiled code and if you do some clever trick in assembler that a compiler wouldn’t do you could actually end up with much slower code on a new CPU generation (this has happened with QPC before).

To cut a long story short, every time I had to touch a sub-system of QPC in the last few years I rewrote it in C first in order to not go insane for writing any more lines of x86 assembler. This time it was the DOS device that got the C treatment. Functionality wise not much has changed, except one thing:


It always bothered me that the DOS device could not rename files and if I had known 15 years ago what I know today I could have implemented it back then, too, but alas I didn’t. The feature as it is now implemented needs Windows Vista+ to work, so XP and lower still cannot rename files (boo hooo!). But if you’re still using XP I strongly urge you to update anyway.

And the rest

The rest is mostly minor bug-fixes, you can check out the details in the version history. Perhaps one interesting change is Respect “Keep aspect ratio” when going into fullscreen mode. The story behind this is that QPC2 v4 does not alter the physical screen resolution to go full screen anymore, it just stretches the content of the QL screen to the extent of the monitor. This is a bit of a problem when the screen resolution is for example 1366×768, because in order to stay compatible to the QL colour mode QPC enforces the screen x-resolution to be divisible by 8, and 1366 is not. So QPC will round down and try to stretch a 1362×768 QL screen to a 1366×768 monitor, which can only be done by doubling a few pixel columns. If you are in this situation then enabling the “Keep aspect ratio” option will now make sure that the screen will not be stretched, instead there will be four black columns on the right hand side of the screen instead, as it was with QPC2 v3.

So this is it, the first new release in two years. I hope you’ll like it, enjoy!