Anders Tornblad

All about the code

Label archive for JavaScript

Emulating ZX Spectrum graphics in JavaScript

TL;DR: I'm using EcmaScript 6 Proxy objects to keep track of dirty blocks in emulated ZX Spectrum video RAM. Try it out at or dive into the code by cloning or forking

Emulating 1982 video RAM in JavaScript

Animated GIF screenshot made using gifcreator.meAnimated GIF screenshot made using gifcreator.meIt's no secret that I have a sweet spot for the Sinclair ZX Spectrum. One of the things I was amazed by as an eight-year-old was the (then) incredible 256×192 pixel colour graphics. Using only 6.75 kilobytes of video RAM, the custom Ferranti ULA chip pieced together the video signal 50 (or 60) times per second.

Software emulation of the Ferranti ULA has been done a lot of times, but reinventing the wheel is a great way of learning new (or old) things, so I decided to make an attempt of my own.

JavaScript, CANVAS and Proxies, oh my!

First of all, I'm using a CANVAS element and the CanvasRenderingContext2D object to draw graphics in the browser's window. I'm also using a Uint8ClampedArray to store the 6912 bytes of raw video RAM. For a more detailed description of the memory layout, scroll down a little. Each byte of the array corresponds exactly to one byte of ZX Spectrum RAM, so changing the contents of a single byte should trigger a redrawing of at least a part of the canvas.

I decided to redraw the canvas in blocks of 8×8 pixels, because this is close to how the ZX Spectrum ULA worked. Changing any one of the 8 bitmap bytes inside a block, or its attribute byte, should mark that block as "dirty" and when the next animation frame comes along, all dirty blocks should be rerendered. Because of this, there is also a Uint8Array of length 728 (32×24) keeping track of dirty blocks, so that I don't have to redraw all blocks every frame.

Using a Proxy object, I'm able to use the array normally, while correctly marking dirty blocks as needed. Without a Proxy, I would have to expose a setter method for changing the RAM contents.

// Without a Proxy object: data.set(address, newValue); // With a Proxy object: data[address] = newValue;

The Uint8ClampedArray and Proxy construction looks like this:

var data = new Uint8ClampedArray(6912); var dataProxy = new Proxy(data, { "set" : function(target, property, value, receiver) { if (property >= 0 && property < 6912) { data[property] = value; var dirtBlockIndex; if (property >= 6144) { // The index is inside the attribute section dirtBlockIndex = property - 6144; } else { // The index is inside the bitmap section dirtBlockIndex = blockIndexFromOffset(property); } dirtyBlocks[dirtBlockIndex] = 1; return true; } // Not a numeric index inside the boundaries return false; } });

This creates a Proxy that, when written to, sets the value of the hidden array, calculates what block is changed, and markes that block as dirty, so that the next call to the renderer only redraws the dirty blocks. This speeds up the rendering process a lot.

The ZX.Spectrum.Bitmap object exposes the following public functions:

  • poke(address, value): Changes one byte of video RAM (valid adresses are within the 16384..23295 range)
  • peek(address): Reads one byte of video RAM
  • ink(value): Sets the current INK colour (0..7)
  • paper(value): Sets the current PAPER colour (0..7)
  • bright(value): Sets the current BRIGHT value (0..1)
  • flash(value): Sets the current FLASH colour (0..1)
  • cls(): Clears the screen using the current settings
  • plot(x, y): Sets one pixel, affecting the colour block
  • unplot(x, y): Clears one pixel, affecting the colour block
  • line(x1, y1, x2, y2): Draws a one pixel line, affecting colour blocks

Try it out

Go to and try it out for yourself. You can also clone or fork the code and play around. Pull requests are more than welcome!

Back to the 1980s

The ZX Spectrum was an amazing computer for its time. An advanced BASIC interpreter fit snugly into 16 kilobytes of ROM, and the 48 kilobytes of RAM included 6.75 kilobytes of graphics memory. Using BASIC commands like PLOT, INK and CIRCLE, you could write algorithms to draw things of beauty on the screen, but you had to look out for attribute clash.

The video RAM consisted of monochrome bitmap data containing one bit per pixel for a total of 256×192=49152 bits, fitting into 49152/8=6144 bytes, starting at address 16384. The order of pixel rows inside this memory area is a little strange, as rows are not placed linearly (each line of 256 pixels is not exactly 256 bits after the one above it). To calculate the screen address of the first pixel of a Y coordinate, you encode the address as follows:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 Y7 Y6 Y2 Y1 Y0 Y5 Y4 Y3 0 0 0 0 0

This effectively divided the screen vertically into three blocks of 256×64 pixels, within which it is easy to get to the next line of characters, and also easy to get to the next line within a character block by simply adding one to the high byte of the address, but calculating the screen position from a pixel coordinate is really convoluted.

Directly after that monochrome bitmap, at address 22528, was one attribute byte per 8×8 block, containing the colour values for the "ones" and "zeros" of the bitmap data. Each attribute byte is encoded like this:

7 6 5 4 3 2 1 0
F B P2 P1 P0 I2 I1 I0
  • F holds a one for FLASH mode, where INK and PAPER alternates every 32 frames
  • B holds a one for BRIGHT mode, where both INK and PAPER are a little brighter
  • P0..P2 holds a value between 0 and 7 for the PAPER colour, which is used for zeroes in the bitmap
  • I0..I2 holds a value between 0 and 7 for the INK colour, which is used for ones in the bitmap

Avoiding the "attribute clash" was tricky, and you had to really plan your artwork or your graphics algorithm to make sure that you only ever needed two distinct colours inside each 8×8 block of pixels. Artist Mark Schofield wrote an article in 2011, describing his process of planning and creating a piece of ZX Spectrum artwork.

If you are looking for more ZX Spectrum art, here are a couple of sites you might have a look at:

Finally got around to fixing Sparky

Back in 2010, the iPad was all the rage. The first really usable tablet device, sporting lightning-fast multitouch capabilities, that were even exposed as (then non-standard) HTML5 Web APIs for JavaScript developers to play with.

It wasn't always easy to keep up with the latest trends, and trying out multitouch experiments then required an iPad. So I wrote a touch event simulation tool, called addTouch. The principle was to use the mouse to add, manipulate and remove multiple touch points, dispatching touch events to the browser.

This made it possible to develop multitouch experiences and test them using an average desktop browser. I supported both Apple's touch events and the (now extinct) Mozilla touch events.

Sparky : just a demo app

Sparky in actionTo demonstrate what addTouch could do, I put together a simple demonstration app called Sparky. Its principle is very simple — put your fingers on the screen to create sparking lines that you can move around. This was in the really early days of HTML5 support, and I hadn't learned Canvas drawing yet, so my implementation uses a few <div> elements and some CSS transform magic.

This has worked fine for almost six years now. I just had to fix a small issue when Apple released the iPhone 4, which had a high-dpi ("Retina") display. There were a few versions of the iOS Safari browser that had bugs when it came to handling device pixels vs logical pixels. I had to do a lot of experimenting with this, and wrote a StackOverflow answer that is currently my third most up-voted one.

What started out as just a demo app for addTouch, now has a life of its own. After my latest complete blog remake, I have been keeping a close look at the IIS logs that I get from Azure. It turns out that Sparky still gets a few hundred visits per week from different incoming, which is nice, but it prompted me to do some much-needed spring cleaning.


The code was actually not too shabby, but some of it was really outdated. It still supported the old Mozilla touch events, and it used screen coordinates instead of local coordinates, which made it look pretty horrible in a non-fullscreen view, especially on the Android Chrome browser. That needed to change.

It was written in a certain style, specifically catered to my own old JavaScript minifier which I no longer use. Also, it polluted the global window object, which I never do anymore, unless I'm writing public APIs. That needed to change, too.

Other than that, it was just the small issue of estimating screen DPI, where I had used hard-coded values directly adapted for various iOS devices. That needed to be replaced with some more general-purpose code, and after a little head-scratching, I just decided to go with the same hard-coded value for all devices. At least for now.

The result is now live and kicking on, and the complete code is available in the lbrtw/sparky GitHub repository.

Next step

I will try to fix some of the issues with addTouch as well, but I'll save that exercise for later. It is not very useful anymore, because the major browsers and development environments have really good touch emulation built in.

Try it out:

"Hello, World!" in JavaScript

How to do "Hello, World!" in JavaScript.

'use strict'; console.log('Hello, World!')

JavaScript has really matured over the last years. Though it started out as a browser-only language, giving grey hairs to web developers everywhere, it is now a competent language in its own right. Combined with initiatives such as node.js, it performs on par with all other system languages. The code above works in your browser (printing to the developer console) as well as in node.js (printing to your terminal output). And yes, you should always go for strict mode.

For more "Hello, World!" examples, go to the Hello World category.

JavaScript countdown using localStorage

New StackOverflow user Pankaj Badera asked how to create a simple JavaScript timer that would survive reboots of the user's computer.

For the specific question, this is not a good idea, because it seems as if the problem needs to deal with some sort of timing rules (school assignment deadlines, maybe?), in which case a server-side solution is a must. However, the technical aspects is pretty intriguing. As it turns out, I have already faced this problem before, when building Tajmkiper, which handles all of its timing client-side.

In principal, you can start any type of countdown, or "countup", allowing the counter to continue between browser and computer restarts, by simply recording the current time for when an event starts, and then continuously checking the difference between that saved value and the current time of a later event.

In Tajmkiper, this is done for many projects at the same time, but the principle is the same. In the case of this StackOverflow question, there is only one timer. Also, Tajmkiper is meant to be a tool for the user, and not for keeping track of (from the browser's perspective) externally checked rules like deadlines, so a solution involving local storage is fine.

My answer looks like this:

(function() { var started = localStorage['started']; if (started) { // This is not the first time the user opens this file // How long has it been? var diff = - started; if (diff >= 1000 * 60 * 60 * 24 * 7) { // At least one week has passed. Do something here. } else { // Less than a week has passed. Do something else here. } } else { // This is the first time the user opens this file localStorage['started'] =; // Do something else here to welcome the user... } })();

For my project time clock, this happens every time you select a different project. I combine this with keeping track of how much time has been clocked total.

Formatting a truncated float in JavaScript

StackOverflow user nips asked how to format a floating point number in JavaScript, truncating the value instead of rounding it.

According to the question, this was the desired result:

  • The value 12.999 must be displayed as 12.99
  • The value 14 must be displayed as 14.00

The page gives a thorough example of how to perform decimal rounding correctly, avoiding any rounding errors in the process. For this question, however, a simple multiplication-division pair is surely good enough:

// Step by step var multiplied = value * 100; var truncated = Math.floor(multiplied); var divided = truncated * 0.01; var output = divided.toFixed(2); // One-liner version var output = (Math.floor(value * 100) * 0.01).toFixed(2);

The above code performs the following steps, in order:

  • Value is multiplied by 100
    12.999 => 1299.9
    14 => 1400
  • Value is truncated using the Math.floor function
    1299.9 => 1299
    1400 => 1400
  • Value is multiplied by 0.01
    1299 => 12.99
    1400 => 14
  • Value is formatted for printing using two decimal places using the Number.prototype.toFixed function
    12.99 => "12.99"
    14 => "14.00"

Most languages do have functions called round, ceil, floor or similar ones, but almost all of them round to the nearest integer, so the multiply-round-divide chain (or divide-round-multiply for rounding to tens, hundreds, thousands...) is a good pattern to know.

In JavaScript there is no float datatype like in a lot of other languages, but the Number object is used for both integers and floating point numbers. Internally, numbers are just 64 bit floating point numbers (source:, conforming to the IEEE 754 standard. So when dealing with numbers in JavaScript, you always need to take floating point precision into consideration!

Revisiting CssFlip

When I first started experimenting with modern Web APIs, 3D transforms was still an experimental feature. Browser support was limited and shaky, and required vendor prefixes. These days support is much better, but there are still a lot of quirks when it comes to browser implementation.

Back in 2011, I wrote a demo called CSS Page Flip, using a combination of CSS and some JavaScript to let a user flip through pages in a book. The transitions are declared in CSS and are triggered by JavaScript. Pages on the left have their transform-origin set to their right edge, which is aligned to the horizontal center of the screen, while pages on the right have their transform-origin set to their left edge. By applying backface-visibility: hidden, I can then rotate pages along the Y axis for a pretty simple effect.

#book { perspective: 2000px; transform-style: preserve-3d; } .page { width: 50%; height: 100%; position: absolute; top: 0px; left: 0px; margin-left: 50%; overflow: hidden; transform-style: flat; backface-visibility: hidden; transition: none; transform: none; } .page:first-child { margin-left: 0px; transform-origin: right center; } .page:last-child { transform-origin: left center; } .currentFold.forward > .page:last-child { transform: rotateY(0deg); } .nextFold.forward > .page:first-child { transform: rotateY(179.9deg); } .currentFold.backward > .page:first-child { transform: rotateY(0deg); } .nextFold.backward > .page:last-child { transform: rotateY(-179.9deg); } .folding .page { transition: all 1s ease-in-out; } .folding > .currentFold.forward > .page:last-child { transform: rotateY(-179.9deg); } .folding > .nextFold.forward > .page:first-child { transform: translateZ(1px) rotateY(0deg); } .folding > .currentFold.backward > .page:first-child { transform: rotateY(179.9deg); } .folding > .nextFold.backward > .page:last-child { transform: translateZ(1px) rotateY(0deg); }

It took a lot of fiddling to find good values for rotateY(). Almost every new version of Webkit broke my experiment, but I eventually settled on a combination of 0deg, -180deg and 180deg.

CSS Flip in EdgeEdge behaving badly A couple of years later, the major browsers started supporting 3D transforms, even without vendor prefixes. Unfortunately all of them have different ideas about how to transition from 180deg or -180deg to 0deg. Finally I thought of forcing the browsers to do what I want by having -179.9deg and 179.9deg. This works fine now, unless for (of course) IE and Edge. IE doesn't even support 3D transforms correctly without prefix, and for some reason Edge treats the transformation matrix differently than the other browsers, completely breaking part of the animation.

Apart from the page flipping, the demo also has an automatic page layout mechanism that reflows the chapters and the text blocks when needed. In the original demo, the contents of the book was actually a detailed description of how the demo was made, but unfortunately the original content was lost at some point. Now it is my personal story instead. Enjoy!

During the next week or two, I will make an effort to bring the solution forward into the 2016 state of mainstream browsers, including the following:

  • Fix scroll wheel flipping in Firefox
  • Handle chapter navigation using history.pushState()
  • Add some interactive stuff on some of the pages
  • Some effort of fixing the weird behavior in Microsoft Edge
  • Minimal effort of making it work in Microsoft IE

When that is done, I will open-source the whole thing on GitHub.

Trying out Visual Studio Code

Yesterday Microsoft held Build 2015 and presented lots of nice things to the developer community. I have always loved Microsoft's developer tools, and started using Visual Studio back in 1997, hacking away with Visual Basic and Visual C++.

Now I still use Visual Studio at work, but for my personal projects, I mostly do web development in PHP and sometimes ASP.NET MVC. For the PHP projects, I have been using Komodo Edit for a while now, and am happy with it.

Visual Studio Code

After a quick download and a smooth installation, Visual Studio Code booted. I opened a folder full of PHP and JavaScript files. Syntax highlighting, bracket matching, syntax errors and warnings work really well for PHP, JavaScript, HTML and CSS, but PHP IntelliSense isn't included in this Preview version, which unfortunately means I won't be switching. Yet. However, JavaScript IntelliSense is amazing! It found a rookie mistake for me...
Don't do bitwise operations on bool

IntelliSense in Visual Studio Code is really good in every language it supports. Code completion and suggestions for JavaScript, HTML, CSS, SASS and C# are instant, but some features are missing from HTML IntelliSense.

A couple of HTML IntelliSense suggestions

  • Allowed attribute values should be suggested, like when typing <link rel=", I would like a popdown list to suggest things like stylesheet and so on.
  • Element suggestion should only include elements that make sense in the context. Directly inside an <ul> element, there is no point in suggesting a <blockquote>. Only <li>, <script> and <template> elements make any sense.

Bad elements in UL

What will make me switch

The editor is really nice to work with, it feels snappy and does things well. Changing personal settings is done in JSON, which is cool, because JSON... Until PHP IntelliSense is added, and some improvements are made in HTML editing, I will stick to Komodo Edit, but I will probably switch to Visual Studio Code eventually.

About to solve an old THREE.js bug and move on with Artsy

I really need to pay more attention. Almomst a year ago, THREE.js released the r67 version, which removed the concept of centroids. This made part 3 of Artsy break. I used centroids and the Mesh.calculateCentroid function, not because I needed to, but because some tutorial told me I should.

When the concept of centroids was removed, in April 2014, my JavaScript demos was very low on my list of priorities, but soon I will make time for fixing and advancing. Who knows, I might even be able to finish Artsy once and for all. I started working on it in October of 2013, so it's really overdue!

For now, I have removed the calls to calculateCentroid and done some small changes to at least get Part 3 to start. Stay posted!

Tajmkiper now public

Today I launch Tajmkiper as a publicly available, free-to-use, utility. You are welcome to use it as much as you want. If you like it, please tell your friends and colleagues about it.

It is designed mobile-first, so it really looks its best on a smaller screen, but works fine in any modern browser.

Try it out:

Read more about it:
Tajmkiper, part 1
Tajmkiper, part 2
Tajmkiper, part 3

Tajmkiper, part 3

Thanks to my earlier efforts (part 1, part 2 and part 3), exporting all projects to a CSV file that is saved locally is really easy. That is also the only part of the utility that I'll blog about. The complete code will be available on Github when the utility is launched for public use, so you are free to check out the complete code.

function exportToCsv() { // Order of properties var propertyOrder = ["name", "time"]; // Create CSV exporter var csv = new Csv(propertyOrder); // Add header line csv.add({ "name" : "Project", "time" : "Total time" }); // Add all projects, using the same (omitted) formatTime function from before allProjects.forEach(function(project) { csv.add({ "name" :, "time" : formatTime(project.getTotalTime()) }); }); // TODO: Create a formatTodaysDate function var filename = "tajmkiper-" + formatTodaysDate() + ".csv"; csv.saveAs(filename); }

Future possibilities

There is actually something that I would like to do on the server-side, that doesn't really take anything away from the beauty (?) of a purely client-side codebase. I would like to be able to transfer my projects from one browser to another. One possibility would be to simple take the JSON representation saved locally, and expose it for copy/paste, but that's not really smooth enough. I want to be able to save my projects to a server, and then load them up on another browser.

One use case for this is when I use the utility on a mobile device, but my company's time report utility uses Excel. Then I would like to open the projects on my desktop computer, export to CSV, which I then import in Excel, and keep working there.

EDIT: Tajmkiper is now publicly available to anyone who wants to use it.
Try it:

Tajmkiper, part 1
Tajmkiper, part 2
Tajmkiper, part 3 (this part)