I’m not one to put stock into New Year’s resolutions, but I do occasionally have ideas for little things-to-do during a given year. One such idea for 2019 is to set my homepage such that I’ll be redirected to the Wikipedia entry for the number of the current day (out of 365, so February 14 will return the page for 45 (Number)). This is easily attained with a small bit of HTML stored locally:
Once you get into the hundreds, there’s less and less interesting information about a given number. In fact, bunches of numbers start to get lumped into a single article. So, we’ll see, I may abandon this by the end of the year. But I think it’ll be an interesting way to learn some weird little numerical tidbits.
Haven’t done a meta post since August, so now seems like as good of a time as any to discuss a few things going on behind the scenes at brhfl dot com. For starters, back in November, I updated my About page. It was something I forced myself to write when I launched this pink blog, and it was… pretty strained writing. I think it reads a bit more naturally and in my voice now, and also better reflects what I’m actually writing about in this space. I also published my (p)review of Americana in November, which was an important thing to write. Unfortunately, it coincided with Font Library, the host of the fonts I use here, being down. This made me realize that I rely on quite a few free and/or open source products, and that I should probably round up ways to support them all. I’ll get to that at the end of this post, it’s a thought process that started in November, though.
Some time in October, I think, Hugo stopped working for me. For whatever absurd reason, the Hugo team has abandoned traditional package managers for Snapcraft. Snapcraft forces updates. I haven’t figured out exactly what is broken yet, but version 0.47.1 is the last version working for me. I have other projects I was hoping to get out this year built on Hugo, but I can’t safely do that until I solve this problem. This has no outside effect (I have safely tucked away a binary of 0.47.1), but it is extremely frustrating. I imagine the next meta post will be figuring out the fix.
I have moved brhfl dot com’s email provider from Google to ProtonMail. If you wish to send comments via the comment links, they’ll go to an encrypted Proton box now. It’s a more secure and private system, and moving this (as well as my personal address) also moves me one step further from Google in general.
During the 2nd iteration of my blog (the white blog, now at archive.brhfl.com), I created a matching Tumblr which just showcased some of the photography from my Flickr. I haven’t done anything with it in years anyway, and given Tumblr’s recent and frightening decision to ban porn, I am planning to delete it. I’m currently questioning whether there’s any value in archiving it; I suspect not.
I think that’s about it as far as recent/upcoming changes, so back to a handful of projects that keep the pink gears turning over here…
Unison is a bidirectional sync tool that runs on pretty much any OS. I use it to keep complete copies of my sites synchronized across several machines, and to sync the generated site with my host. They have a PayPal donation button on their site, which I can’t seem to reliably scrape a link to.
I’m behind on posting about this, but given my potential audience, I wouldn’t be doing so as a warning anyway but rather a curiosity. A couple of weeks ago, malicious code was discovered in an npm package called flatmap-stream placed as a dependency inside event-stream. Publish rights to event-stream were apparently handed off to the bad actor, a user with no history whatsoever, because according to the original author:
he emailed me and said he wanted to maintain the module, so I gave it to him. I don’t get any thing from maintaining this module, and I don’t even use it anymore, and havn’t for years.
The attack was quite targeted – a payload was encrypted using the description of another package, the code would only be executed if this package was present. It appears that the end goal was getting bitcoin wallet access, as this targeted package was directly related to the Copay wallet. I don’t have much experience with npm, but I’ve gathered that its approach to dependencies is decentralized ownership/maintenance with centralized package lists/names/etc. It also seemingly pushes minor updates (as declared by the author) automatically, but not major ones. The vector of attack here was quite fascinating then: find a package that doesn’t appear to have been maintained for a while and that is often used alongside a well-maintained package that you want to infiltrate; ask to maintain the first package; push malicious code as a minor update and remove it immediately in a major update; sit back as it makes its way through projects everywhere.
I’ve been thinking a lot about empathy and emotion in video games lately, and this has really given me the itch to play through Portal again. This weekend, I did just that… sort of. Jamie Fuller1 has released a 2D adaptation of the classic for the Commodore 64 (C64), and it is pure joy. It’s quick – 20 levels with brief introductions from GLaDOS, completable in around a half hour. The C64 had a two-button mouse peripheral (the 13512) but it was uncommon enough that even graphical environments like GEOS supported moving the cursor around with a joystick. Very few games had compatibility with the mouse, and here we are in 2018 adding one more – using WAD to move and the mouse to aim/fire is a perfect translation of Portal’s modern PC controls. If you’re not playing on a real C64 with a real 1351, VICE emulates the mouse, and it works great on archive.org’s browser-based implementation as well.
If there’s one thing that I think really makes it lack the feel of Portal, it’s the absence of physics-based puzzles. Portal, of course, had some straight-forward shoot-here-to-end-up-there style puzzles, some straight-forward avoid-the-Sentry-Turret puzzles, and some straight-forward place-the-Weighted-Storage-Cube-on-the-switch puzzles, but a major aspect of the game was figuring out the physics. You had to have a pretty good grasp on how fast and how far you’d be launched if you placed your portal here instead of there. This is, of course, an unreasonable ask for a C64, but it does dramatically change the feeling of the game.
Regardless, Fuller’s adaptation is a wonderful success. I imagine it’d be fun to play through even without knowing the source material, but as an homage it’s blissful. From GLaDOS’s snark to an ending that I won’t spoil, this tribute was made by and for lovers of Portal. Well worth the quick play, especially given how smoothly it runs in a browser without the need to install your own emulator.
Along with Del Seymour (graphics) and Roy Widding (music).
One might look at the 1351 and think, oh, the Amiga mouse… but of course nothing is ever simple in retrocomputing. The C64 (and C128) had no dedicated provisions for an analog input device, so the 1351 (as well as paddle controllers and the KoalaPad) used the SID audio chip’s ADC. This is a fundamentally different approach than the Amiga’s. Commodore also released another lookalike, the 1350, which was not an analog device, and instead simply sent joystick signals.
The Atari VCS, better known as the 2600, was an important part of my formative years with technology. It remains a system that I enjoy via emulation, and while recently playing through some games for a future set of posts, I started to think about what exactly made so many of the (particularly lesser-quality) games have such a unique aesthetic to them. The first third-party video game company, Activision, was famously started by ex-Atari employees who wanted credit and believed the system was better suited to original titles than hacked-together arcade ports. They were correct on this point, as pretty much any given Activision game looks better than any given Atari game for the VCS. Imagic, too, was made up of ex-Atari employees, and their games were pretty visually impressive as well. Atari had some better titles toward the end of their run, but for the most part their games and those of most third-parties are visually uninspiring. Yet the things that make them uninspiring are all rather unique to the system:
Horizontally stretched sprites
Many copies of the same sprite sharing a horizontal plane
Simple, horizontally symmetric backgrounds
Simple, square ‘balls’ in ball games, ‘missiles’ in shooting games
There’s a recurring theme to this aesthetic: lots of things happening in horizontal space. The VCS is made up of three primary chips: the MOS 6507 processor1, the Television Interface Adaptor (TIA), and the 6532 RAM, I/O, and Timing chip. Of these, we’re primarily concerned with the TIA: it’s the closest thing we have to a video card, and its design is the primary force behind the aesthetic of the console. Before we dive into this, however, we need to know how televisions work. Or, at least how televisions worked in 1977.
Cathode Ray Tubes (CRTs) shoot electrons at a phosphorescent screen, causing it to glow. In a television in 1977, these electrons are focused and moved around the screen via electromagnetism. Well, ‘moved around’ is a sloppy explanation at best, but the signal is created by shooting the focused beams from left to right (that is, horizontally), one line (scan line) at a time, top to bottom. After the bottom line is complete, the beam returns to the upper left and begins again. The analog TV signal contains vertical sync (start up top) information, followed by signals for each line, prefaced by horizontal sync (start to the left) information. This is a gross oversimplification, but it’s accurate enough for the important takeaways: lines are generated horizontally, one at a time, from top to bottom; and synchronization information is built in to the signal. For as antiquated as they seem now, it’s a wonder CRTs ever worked — they are engineering marvels.
The TIA helps a VCS developer manage the above, but it barely helps. The developer needs to keep track of timing and fit their code within the timing requirements of the video signal. Advanced games like some of those lovely Activision titles changed things during the horizontal timing to push the system beyond its intended capabilities — a technique famously known as ‘racing the beam’. But the unique VCS aesthetic of simpler games comes from using that TIA as intended, and the TIA doesn’t know anything beyond what it’s doing to the current horizontal line. This sounds a bit untenable, but it’s worth keeping in mind that the VCS had to find ways to help developers without adding costly RAM beyond the 128 bytes afforded programs.
In the few ways that the TIA does help, it can only help as far as ‘doing stuff horizontally’ is concerned, because it doesn’t know a thing about the previous or next line. It helps by giving the developer a few graphics registers to play with, including a background… or, more accurately, half of a background which is then either repeated or reflected onto the other side of the screen (horizontally symmetric backgrounds). Also included are two player sprites, with the helpful ability to stretch them out to two or four times their width or repeat them two or three times inside that stretched width (horizontally stretched sprites; many copies sharing a horizontal plane). A final convenience exists under the assumption that many games would be of the Pong-like or shooting varieties: single-dot objects (optionally horizontally stretched) that matched the player or background color and offered positioning and collision detection without maintaining a complex graphical object (simple ‘balls’ and ‘missiles’).
Combat, two screenshots of which are simulated above, shows most of these elements, and is very much an archetypal example of the aesthetic I’m referring to. Of the six types of objects (background, two players, two missiles, ball), we see symmetrical, low-resolution backgrounds, player sprites both repeated and stretched, and missiles. Without stretching the limits of the system (racing the beam), this was the sort of thing that you got. With a lot of developers jumping on the home-console bandwagon without trying to live up to the likes of an Activision, this chunky, stretchy, limited-palette2 aesthetic truly defines the system, and all for the sake of giving developers the bare minimum assistance in manipulating a signal for a display technology that operates on horizontal lines.
It’s hard to overstate how important MOS Technology was to home computing. They used cutting edge MOSFET technology and pioneered the art of fixing the production masks, resulting in far higher viable chip yields than competitors. This, combined with a relatively simple chip design, made the 6500 series incredibly affordable for the time.
It’s worth noting that while many systems of yore had a unique aesthetic built around simply not supporting many colors (the Apple II and the typically 4-color CGA of the IBM PC come to mind), the VCS actually had a pretty rich palette! But there were only so many graphical objects, and all of them were 1-bit. Interestingly, this leads us to another pretty typical VCS aesthetic, albeit one that is not so much a deliberate function of the TIA. The fact that developers were constantly working with the knowledge of the system’s timing (down to where it was drawing on the screen) and the fact that all graphical objects had 1-bit color depth meant that quickly cycling the color of an object was an inexpensive effect that added a lot of visual impact. Since this, too, was bound by the line-by-line TIA behavior, it’s common to see a rainbow effect of colorful flashing horizontal strips in VCS games. Among others, Yars’ Revenge, Krull, and Swordquest: Earthworld are all first-party titles that make use of this effect.