heckmeck!

Nerd content and
cringe since 1999

Alexander Grupe
Losso/ATW

Sometimes there’s beauty in little errors, or even a genius idea waiting to be unearthed. Take this little typo:

“Emcoding”, heh heh…

But wait! We do have en-dashes and em-dashes in typography, why not introduce en-coding and em-coding? The world of charsets and encodings is daunting and confusing already, adding more technical terms to the mix surely can’t hurt!

En-coding
  • Typographic counterpart: – (en-dash)
  • Narrow: denotes a single-byte encoding
  • ASCII, EBCDIC, PETSCII
Em-coding
  • Typographic counterpart: — (em-dash)
  • Wide: each codepoint encodes to n bytes
  • UCS-2, UTF-32
Swung-coding
  • Typographic counterpart: ⁓ (swung-dash)
  • Byte lengths are swinging back and forth
  • UTF-8, Big5

To be honest, I didn’t know about the swung-dash before. Maybe that’s stretching the pun too far…? The emd. :)

“The algorithms” get a lot of crap these days, but the YouTube video suggestion system dug out a nice oldschool video for me today: Animation 101, an Amiga tutorial by D. L. Richardson of Myriad Visual Adventures. How have I never seen this one? It’s great!

Animation 101 with D. L. Richardson (YouTube)

I love the humor, the effort that went into this, and the fact that the presenter (63 at the time, apparently) obviously had a lot of fun doing it. One hour of pure retro Amiga bliss!

The author also seems to be a real fan of the Amiga speech synthesis. In a recent blog post I briefly mentioned creating little spoken-word dramas in AmigaBasic as a kid. This gentleman does the same thing! (At 54:34 in the video.) He also says “I’m sure you’ve played with it many times”, and I can’t help but imagine him showing off the latest funny dialogue he’s written to his local Amiga user group. :)

PS: On a slightly related note: I have always been really eager to study the inner workings of the narrator device, the speech synthesis implementation by Joseph Katz and Mark Barton of SoftVoice. And not only me! Somehow I never bothered to check if it was contained in the Amiga OS source code leak, which it indeed was.

Let narrator.device read this post scriptum!

Of course™, I don’t have access to those leaked sources and I would never take a peek at it! But if I were to do such a thing, I might conclude that it’s an intricate piece of software with many moving parts! Maybe it even has over 10k lines of code, mostly hand-written 68000 assembly? No wonder it sounds so great. And it’s okay my own crappy speech synth attempts will always pale in comparison…

Cool stuff to stumble upon, new and old.
Before: What’s Cool? · II · III · IV · V · VI

  • EPSON MX-80 Fonts
    Retro fonts are not necessarily made of pixels – here’s some dot-matrix goodness, released as a font pack in all possible formats. I can nearly smell the endless printer paper! Although the letters on the website look a bit squished compared to the specimen in the manual – but what do I know? I had the privilege of starting my home-printing career with a whopping 24 dots… Epson LQ-550 elite, booyah!
  • 64’er Magazin
    (German) A fantastic – and crazy ambitious – art project by pagetable.com, a realtime replay of the German C64 magazine where all the original articles show up as they came out exactly forty years ago. This already started in March 2024, and the current issue has a feature on that new supercomputer from Commodore, the Amiga! :) Of course you get PDFs of the original issues, but all texts (and listings!) have also been converted to (translatable) text form. Truly a labor of love!
  • Presenting Slides / Media Session Sample
    Not a cool article or blog post, but rather a bit of browser tech I wasn’t familiar with. Did you know your website can add a video or canvas element as a floating picture-in-picture gadget onto your user’s desktop? Interesting! Also, the whole MediaSession API might be worth a look (the thing that lets your browser issue those “now playing” overlays). Could you abuse it for interesting content or games? Think Defender of the Favicon, but with prev/next/pause as controls…
  • Deluxe Paint on the Commodore Amiga
    “Let’s crank out DPaint today and see how it holds up!” Hand-pixelling without layers and only one undo level like it’s 1989 – is that as painful as it sounds or is it still fun? A well-written and informative field report – I never knew the perspective mode supported anti-aliasing!
  • The day Return became Enter
    Just as I was struggling with carriage returns and linefeeds the other day, I stumbled upon this piece. Of course, this post rather starts out with the physical carriage mechanisms of early typewriters and word processors, not the ASCII control codes 13 and 10. But it’s all related, of course, and so is the path from the mechanically-rooted naming of the “return” key to the space-age moniker of “enter” to, well, enter stuff.

One more meta-recommendation: If you like this kind of stuff, you should check out Two Stop Bits from time to time, a Hacker News clone for all things retro. It’s a great resource to waste spend your time! :)

Some aftermath of the Amiga preferences extractor: While writing the parsing code, I thought I had either lost my mind or the official file format specification was wrong. One of these possibilities is way more probable than the other, and it wasn’t helping that the output images looked a bit trippy:

When they were supposed to look like this:

But, as many programmers know, it is a good sign to feel like you’re going mad. You will stubbornly try to prove that reality is wrong and you are right, and in the end you’ll learn something either way…

In my case I thought I had found a bug in an official Amiga header file that has been around for forty years. Crazy, right? My own code comments would agree:

// weird: something is off by 1 byte there:
// - devs/system-configuration from Workbench-v2.04.adf
// - expected system colors: aaa 000 fff 68b
// - extracted colors:       d0a aa00 00f ff06 <-- upper bits used?!
// - sprite colors look ok
//
// possible explanation (intuition/preferences.h):
//
//    UWORD color17;      /* Colors for pointer sprite    */
//    UWORD color18;      /*   "     "     "      "       */
//    UWORD color19;      /*   "     "     "      "       */
//    UWORD PointerTicks; /* Sensitivity of the pointer   */
//    UWORD color0;       /* Standard 4 Workbench-Screen colors */
//    UWORD color1;
//    UWORD color2;
//    UWORD color3;
//
// PointerTicks is a byte, not a word!?
// no, wait, there's an *extra* byte after! (still: ?)
//
// with a dummy readByte() inserted:
// - extracted colors aaa 000 fff 68b, sprite colors e44 000 eec
// - looks about right

Assuming an extra byte between PointerTicks and color0 solved the problem! I thought I had really found a bug in the ancient reference code and was getting all excited. Then I noticed something in the hex dump:

0800 0005 0000 0000 0000 c350 0000 0000
0009 27c0 0000 0001 0000 4e20 0000 0000
c000 4000 7000 b000 3c00 4c00 3f00 4300
1fc0 20c0 1fc0 2000 0f00 1100 0d80 1280
04c0 0940 0460 08a0 0020 0040 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 ff00 0e44 0000 0eec 0001 0d0a  green = color17/18/19
aa00 000f ff06 8b00 0000 8100 2c00 0000  red   = color0/1/2/3
...

If you’ve ever worked with text files, you might spot what’s suspicious about the first red color value: The value is 0d0a when it’s supposed to be 0aaa. Is it a coincidence that 0d0a is also the byte encoding of an MS-DOS/Windows linebreak?

Well, it is not. Someone is clearly converting LF linebreaks to CR LF, replacing all 0a bytes with 0d 0a (and treating the binary data as text). But who? At first I assumed my code must be at fault, or the way I invoked “unadf”, a tool from ADFlib to extract files from Amiga disk images. But after some poking it was clear that unadf itself performed the erroneous linebreak translations.

Note: This only affected the Windows build. Under Windows, you need to pass a special flag to open, apparently, otherwise all your bytes will be mangled by default. Now that’s helpful, and totally not insane! :)

So, sadly there was no exciting bug discovery in Commodore’s old code, and sadly, I was not tripping. :) But the bug was still a nice find – it must have been around for years!

Big shoutout to the ADFlib maintainers for fixing the issue in record time, and thanks for all your work!

On the Amiga, you were able to, nah!, you were invited to customize everything on your desktop: the colors, the mouse pointer, the keyboard repeat rate, the screen position.

Amiga preferences editors

While this could get out of hand from time to time, it provided a great way to customize your disks. You only needed to include a 232-byte system file to boot with your colors and mouse cursor. (As long as you were booting into AmigaDOS, and not using a custom trackloader.) This way, you could:

  • design a fancy, futuristic, or goofy mouse cursor,
  • use your logo as the pointer,
  • set all colors to black and use a fully-transparent mouse cursor to hide the fact that you’re using DOS at all.

One day I wondered: Wouldn’t it be fun to automatically gather all the preferences files ever released and collect them into a gallery of system settings?

This weekend I finally got around to write a system-preferences extractor using ADFlib and the docs, and designed a template for the preview images:

Hmm, come to think of it: The enlarged mouse pointer seems kinda redundant the longer I’m staring at it…

Anyway, since I’ve already coded everything, I’m only one full TOSEC download away from building a more-or-less comprehensive gallery. Oh, and a round of pouët scraping, probably…

previous next close