mass:werk / Blog

(Posts 45 … 37.  Jump to newest. RSS feed: Subscribe.)

A Modernist Christmas

Festive architecture & optimism

Lobby of building 2 at General Dynamics Astronautics, San Diego, CA, Dec. 24, 1958
Lobby of building 2 at General Dynamics Astronautics, San Diego, CA, Dec. 24, 1958.
(SDASM Archives / Convair/General Dynamics Astronautics Atlas Negative Collection)

Season’s Greetings

Better late than never, an old-school e-card…

A festive display hack for the PDP-1 (2020)
A festive display hack for the PDP-1. Click for the live program.

A bit of PDP-1 assembler code running in in-browser emulation:

Visual Story Telling: Revisiting Minard’s Map of Napoléon’s Russian Campaign (1812–1813)

Another view at Minard’s famous flow map, AKA “the greatest infographic of all times”

Minnard’s Russian Campaign revisited
Remapping Minard’s map.

Much has been said about Charles Joseph Minard’s famous flow map titled “Carte Figurative des pertes succesives en hommes de l’Armée Française dans la campagne de Russie 1812-1813” (Paris, 1869) and it is universally praised for its comprehensive depiction of an impressive variety of quantitative data, hence there shouldn’t be much left to add to this. However, as indicated in a previous post, “Observing Minard Observing Napoléon – Observations on textual strategy in infographics by the example of the ‘Greatest Infographic of All Times’.” (2018), Minard’s map may not be what it seems to be at first glance. While we concentrated in this first post mainly on the aesthetic choices and what is actually shown and not shown in the chart and the general context of that sheet, both in presentation and history, we are here going to have a closer look at the very choice of presentation, namely the choice of a flow map and the impli­cations thereof.

Continue reading…

meSpeak.js Update, v. 2.0.7

Text to Speech in JS, and a curious bug. Also, Safari desktop compatibility.

meSpeak Update 2.0.7

A curious bug, believed mitigated long ago, crept up again in meSpeak.js (an open source TTS for the Web in JavaScript maintained by me). On each 80th call, the internal eSpeak engine would crash on a round-off by one error. However, that error message never seemed right, as the abort message indicated a size of more than 1.8 GB for a relatively small and static internal file. Also, this didn’t happen on all browsers. A workaround was eventually found, where we would intercept this error, restart the engine, reload all relevant internal files and start over automatically.

However, this stopped working and the bug rose its head of rare, but questionable beauty once again. It doesn’t happen on all browsers, but, for me, it happens at least in current versions of Firefox. Even more, it seems to be a real Heisenbug, since the script exits on an “out of memory” exception on varying points depending on the specific version of the code. In the minimized production version, the code makes it to several debug messages before the final exit, in the unminimized test version, however, it exits on a different point, which renders intercepting that specific error a somewhat impractical endeavor. Also, the exception dosen’t depend on the length of the utterances spoken (thus suggesting that the “out of memory” exception isn’t caused by memory allocation of the actual code, but the result of cascading failures internal to the JS engine), it just happens on each 80th call of the method “speak()”, which triggers a run of the internal eSpeak engine. Which, on the other hand, provides a suitable point of access to an otherwise somewhat cryptic and inaccessible failure mode, namely, simply keeping track of the number of calls and automatically restarting the engine on every 80th call. (Mind that this may cause a small delay, but it’s still better than the script stalling on an uncatchable exception.)

Shout-out to Trent Murgatroyd for reporting the fault and testing!

This had actually been addressed in version 2.0.6, as of a few days ago (2020-04-17), already. But there was another issue, which had passed my radar, namely, the Safari desktop browser muting Web Audio on default. This is now addressed similar to how mobile devices are handled, by attempting to unlock audio on the first mousedown event occuring in the window. (Unlocking requires a direct user interaction. Hence, meSpeak.js must listen for a global user event. However, it neither blocks or consumes the event in any way, nor does it extract any data.) Additionally to this, meSpeak.js now also attempts to resume the audio-context on every call of the method “speak()” prior to playing any audio, in case it’s found in suspended state. (Again, this will be of any effect only, if the call was issued from code triggered by a user event. On the other hand, it doesn’t hurt trying.)

If you’re using meSpeak.js, please update:

PET 2001 Emulator — V. 1.1

Proudly announcing version 1.1 of the PET 2001 online emulator.

Commodore PET 2001 Emulator V.1.1 Announcement
Yet another PET 2001 related title illustration.

Version 1.1 of the PET 2001 online emulator features a totally revamped mounting and loading mechanism for files. For users this means full access to disk directories and LOADing programs from inside BASIC. For all the nerdy details and some hilarious insights into Commodore IEEE file loading (like, “Where on Earth — uhm, in memory — is the BASIC scondary device address?”) follow the link:

Continue reading…

IBM Punched Card Typography

The surprising mechanical store for exchangable fonts of the IBM card punches

IBM punched card typography explained
Punched card typography explained.

Another recap from the days before the blog, this time about IBM card punch equipment. You may already know that some of the card punches featured a built-in printer to represent the data in human readable characters on the very top of a card. But did you also know that the font and character set used for printing were exchangable? Or how these electro-mechanical wonders stored them?

In this mini-series you may not only learn all about the astounding intrinsics (including interactive animations of the decoding mechanism), but, if you’re the lucky owner of such an amazing device, you may even design your own font or character set for your IBM 026, 029 or 129 card punch.

Stay at Home Edition — Permalink

Five retro computing related long reads to keep you from getting bored at home

Now Go Bang: Stay at home long read edition
Poster: Stay at Home Long Read Edition.


Stay at Home Edition: Refraction for the Atari 2600

RetroChallenge 2018/04: Writing a proper Atari VCS / 2600 game

Refraction for the Atari 2600 (RetroChallenge 2018/04)
Accepting the processor clock challenge…

There’s a noble challenge, every programmer of self-esteem should obliege to at least once in a lifetime: programming a game for the Atari VCS, also known as “racing the beam”. In case you didn’t know, the Atari VCS (Atari 2600) has no video RAM and every line of raster image has to be composed on the fly. More so, you also have to maintain the vertical composition of the TV image, and there is no operating system, no ROM, just the bare metal machine and a trusty video/sound chip (TIA) to talk to. And there are only 128 bytes of RAM in total, already including the processor stack. To do this properly, it’s 6502 assembler once again, but this time every cycle counts.

Particularly, we do a classic two players console game with a twist. A classic game, like it was 1979, no additional hardware enhancements or fancy bank switching allowed. On the way, we learn about the Atari VCS and its hardware, and how to tackle the programming side of things. Moreover, there’s a tiny sprite editor for the VCS and even a synthesizer app to explore its somewhat unique sound generation. Also, it’s our first RetroChallenge project in color!

Start reading: “Refraction for the Atari 2600”…