Virtual Boy Architecture

A practical analysis by Rodrigo Copetti

Classic edition - Last updated: March 24, 2023

Languages available: 🇬🇧 - English, 👋 - Add translation

About this edition

The ‘classic’ edition is an alternative version to the ‘modern’ counterpart. It doesn‘t require Javascript, state-of-the-art CSS or convoluted HTML to work, which makes it ideal for readers who use accessibility tools or legacy internet browsers. On the other hand, eBook users can now check the eBook edition.

This edition is identical content-wise. However, interactive widgets have been simplified to work with pure HTML, though these will offer an link to the original article in case the reader wants to try the ‘full version’.

As always, this article is available on Github to enable readers to report mistakes or propose changes. There‘s also a supporting reading list available to help understand the series. The author also accepts donations to help improve the quality of current articles and upcoming ones.

Table of Contents

  1. Supporting imagery
  2. A quick introduction
  3. Display
    1. Projecting an image
      1. Scanner
      2. Mechanics
      3. Display
      4. Active periods
    2. Creating a third-dimensional vision
  4. CPU
    1. Memory access
  5. Graphics
    1. Architecture
    2. Organising the content
    3. Constructing a frame
      1. Tiles
      2. Backgrounds
      3. Sprites
      4. Window
      5. Result
    4. Creative content
  6. Audio
    1. Output
  7. I/O
    1. Available interfaces
    2. The provider
  8. Operating System
    1. House chores
  9. Games
    1. Development ecosystem
    2. Medium
    3. Rules
  10. Anti-Piracy and Homebrew
  11. That’s all folks
  12. Copyright and permissions
  13. Sources / Keep Reading
  14. Contributing
  15. Changelog

Supporting imagery


The Virtual Boy.
Released on 21/07/1995 in Japan and 14/08/1995 in America.
Front view of the console.
Users are meant to look through the eyepieces.


The mainboard.
Not to be confused with the 'Servo board' which the mainboard connects to.
Virtual Sound Unit IC, 128 KB of DRAM and 64 KB of PSRAM are fitted on the back.
Motherboard with important parts labelled


Main architecture diagram
Notice how the two screenshots have its background scenery slightly shifted horizontally.

A quick introduction

A console often summarised by its short lifespan and limited colour space. While technically correct, I believe these attributes tend to overlook other surprising properties.

In this article, I invite readers to learn more about its internal features, many of which became predominant in the market only after the Virtual Boy’s discontinuation.


The whole system is a curious piece of engineering. Externally, it resembles a bulky VR headset on a bipod. The player must place their head close to the eyepiece to see the game in action.

This is as far as I get trying to shoot a photo of the display and the case at the same time. In reality, games look very crisp and in full size!

Internally, it’s a whole different story (and a very complicated one too). For this reason, I thought it would be better to start by explaining how this console displays images and then go through the internal hardware.

Projecting an image

Once you switch the Virtual Boy on, you will start seeing two monochromatic red pictures (one for each eye) through the eyepiece. So far so good? Well, here is the interesting part: This console doesn’t have a screen, so what you see is more of an ‘illusion’ - Let’s dive deeper to know what’s going on.

The topics involved in explaining this (optics, visual phenomenons, etc) may feel difficult at first, but I constructed some interactive animations to make this section little more immersive.


Main diagram of the scanner, showing how light from the LEDs reaches the player’s eyes.
Bird’s-eye view of the console.
First switch is the ‘Focus slider’ and below it is the ‘IPD dial’.

The large volume of this console can be attributed to the Scanner, which fills up a big part of it. The Scanner is the area of the Virtual Boy that displays images. It’s composed of two Display units, each one independently projects a frame (giving a total of two frames, one per eye).

A Display unit is where all the ‘magic’ happens, it’s made of the following components:

Next to the focus slider there is a IPD dial (knob-shaped switch), which adjust the distance between the two Display units. This is done to adapt the displays to the user’s inter-pupil distance.


Image Animation available in the modern edition
Basic representation of the angle of the oscillating mirror over time (at a very slow motion).
The left and right LEDs are operating (active) during the red and blue period, respectively.
During the grey period, no LED is operating (idle).
For sake of simplicity, the angular velocity represented here is constant (but not in the real world).

Now that we have each component identified, let’s take a look how the Virtual Boy manages to show images to our eyes.

If you haven’t noticed before, there isn’t any dot-matrix display to be found, so why are we seeing two-dimensional images from the eyepiece? Similarly to the functioning of a CRT monitor, Display units play with the way we perceive images:

In practice, there are some conditions for all these principles to work:


Image Animation available in the modern edition
Simplified representation of how the first LED unit operates during specific periods of time. Notice how the LEDs will start displaying each column of the frame-buffer during active periods.

Contrary to previous video chips modelled after CRT displays (i.e. PPU and VGP), graphics on the Virtual Boy are not rendered on-the-fly. The graphics chip on this console sends the processed frame to a frame-buffer in memory, each column of the frame is then sent to the LED array for display.

Once the Servo board detects it’s time for display, the graphics chip will start sending columns of pixels from the frame-buffer to those 224 vertically-stacked LEDs, one-by-one in a strategically synchronised matter so the LEDs will have shown 384 columns during the display period. Hence, the ‘screen resolution’ of this console is 384x224 pixels.

Moreover, we need to store two frame-buffers since each one will go to a different display unit. The graphics subsystem also employs double-buffering and other quirks (mentioned later in the ‘Graphics’ section). So, for now, just remember how a digital frame is sent to the LEDs.

Active periods

Image Animation available in the modern edition
Another simplified animation, this time showing how the oscillation of the mirror deviates the LEDs light in a way the user will end up seeing a proper frame.

Consequently of this design, there are going to be periods of:

This cycle is repeated 50 times per second (hence the 50 Hz refresh rate). That means that for every frame, the CPU and GPU would have around 10ms worth of time to update the picture that the user will see. In reality, Nintendo’s engineers implemented something more sophisticated. Again, I’ll try to explain this with more depth in the ‘Graphics’ section. But for now I hoped you got a good understanding of how the Virtual Boy cleverly managed to produce a picture with inexpensive hardware.

This has been a quick explanation of how optics can turn a single vertical line into a picture. If you own or have read about the Virtual Boy before, you may be wondering when the three-dimensional imagery takes place. I just want to make it clear that none of the previous explanation have a connection with that effect. I’m mentioning this because in the past I’ve seen many places arguing that the oscillating mirrors are the cause of the ‘depth perception’, however, with all the information I’ve gathered in this study, I don’t think that claim is accurate.

That being said, I think it’s time we discuss the 3D phenomenon…

Creating a third-dimensional vision

During the marketing of the Virtual Boy, there was a lot of fanfare regarding the fact this console could project a ‘3D world’. I’m not referring to images with 3D polygons stamped (like the other 5th gen. consoles), but the actual perception of depth.

In a nutshell, the Virtual Boy relies on Stereoscopic images to carry out that illusion [1] [2]. So this system wasn’t only capable of toying with our vision to project a full image, but it also did it in a way we would think certain drawings are closer/far away from others!

Left display unit’s screenshot.
Right display unit’s screenshot.
Mario’s Tennis (1995).

The technique is very simple: Each of the two frames displayed (one on each eye) will have some elements slightly shifted horizontally, so when we try to see them with our two eyes, our brain will think they are nearer than others. This depends on the direction the elements are shifted.

Objects shifted towards the centre of your eyes (moved right on the left frame and moved left on the right frame) will appear closer, objects shifted away from the center of your eyes will appear further away. Finally, objects with no shifting will appear between the two other. This approach is called Stereoscopic parallax.

One of the drawbacks of stereoscopy is eyestrain. This was alleviated by the fact games provided an ‘automatic pause’ system which reminded the user to take breaks every 30 min. Nintendo also wrote down various warning messages in their packaging and documentation to prevent serious conditions. In any case, there’s no way to turn 3D off.


Alrighty, we’re back to actual architecture, let’s see now how games construct the frames and music you see and hear.

The system uses a customised version of the NEC V810 which operates at an amazing 20 MHz (if the SNES ran at an average 1.79 MHz and the GameBoy ran at 4.19 MHz, I can’t wait to see what can you do with this one!). Nintendo refers to it as NVC because the processor shipped with the Virtual Boy is a combination of a V810 core with some additional components (more details soon).

The V810 is part of the V800 CPU family that NEC designed for the embedded market [3] [4]. While this CPU is not as popular as the competition (i.e. MIPS, 6502, Z80) it does bring a lot of cutting-edge functionality, specifically:

This is very impressive for a portable console in 1995. But if it wasn’t enough, Nintendo added extra resources:

All of this seems fine and dandy but it does have a big cost: Six AA batteries. This may explain why companies tend to hold on old tech for portable devices, at least in the 90s.

Memory access

32-bit addresses look very tempting on paper, but if the system won’t use anywhere near 4 GB of memory locations, then it’s a huge waste of resources. For instance, even though the upper address lines never change, they will still be decoded for every memory read.

So, with good reasons, Nintendo cut down to 27-bit addresses. This means that up to 128 MB of memory can be accessed instead. 32-bit words are still used as pointers but the upper 5 bits are discarded. As a result, some parts of the memory map will be mirrored.

That being said, the memory map layout allows the CPU to access the majority of the components that make up this system. This includes [5]:

This is as far as the CPU goes, now it’s time to see what can you do with it!


Let’s recap the requirements for the proper display of graphics:

Good news is that all of this is accelerated by the Video Image Processor or ‘VIP’, a dedicated chip made by Nintendo. It has some features inherited from the old PPU but I consider it a clean break from its predecessors.


The VIP may seem like another tile engine at first, but it’s much more advanced than that. For starters, it not only process graphics data but it also controls the Scanner.

Moreover, while classic tile engines rendered graphics per scan-line, the VIP relies on a frame-buffer architecture, where the final frame is stored in memory as a bitmap and then sent for display. This is closer to the modus operandi of modern 3D renderers. In fact, the Virtual Boy took a step further by using some sort of page flipping, where two frame-buffers are stored per Display unit and the scanner picks up one while the VIP is writing over the other. All of this helps to prevent image tearing.

Architecture of the VIP.

Having said that, you can divide the VIP into three main areas:

Overall, the pipeline is very simple:

  1. The CPU sets up the VIP by writing over its internal registers and filling up VRAM and DRAM with the required materials.
  2. The XP will then generate frame-buffers that will be stored in VRAM.
  3. The DP selects the necessary frame-buffer and sends it to the Scanner for display. This is done by copying the frame, four columns at a time, to a small buffer area in VRAM called Serial Access Memory or ‘SAM’, which is automatically broadcast to the Scanner.

Organising the content

Memory layout of the VIP

From the developer side, there are two blocks of memory used by the XP and DP:

Notice that this VRAM is ‘real’ dual-ported DRAM [7], not just a block of RAM reserved for graphics (which Nintendo also calls ‘VRAM’. Dual-ported DRAM enables two devices to read from it at the same time, which explains why the XP can write over VRAM while the Scanner is reading from it concurrently.

Additionally, Nintendo uses a VRAM chip nowhere to be found in the off-the-shelf catalogue. There isn’t a lot of documentation about it, but from the information described in the patent application, SAM may be stored in a separate area inside this chip. This area is presumably made of SRAM instead and contains extra circuitry to allow the Scanner to pull 16-bits at a time [8].

Constructing a frame

Let’s dive deeper and see now how a single frame is drawn on the Pixel Processor. For that, I’ll borrow the assets of ‘Virtual Boy Wario Land’. I strongly recommend reading about a previous tile engine to make explanations easier.


Tiles found in VRAM.
Tiles found in VRAM, separated with a grid.

We have previously seen how traditional tile engines build their layers using 8x8 bitmaps. In the case of the Virtual Boy, tiles (originally called ‘Characters’) are stored in VRAM in an area called Pattern table. Each tile declared occupies 2 bytes, so there is enough space for 2048 of them.

In terms of colours, developers can construct eight colour palettes, four for Background graphics and another four for Sprites.

One may wonder what’s the point of colour palettes if the LEDs are monochrome. Well, this enables developers to use different shades of red. These shades are obtained by altering the brightness of the LEDs. The brightness settings are stored in two registers, which then you reference in the palettes to catalogue the different shades. The resulting palette will contain your two custom reds, plus another red automatically calculated from the sum of both, and finally, the ‘transparent’ colour.


Background Layer 0 (BG0).
Background Layer 1 (BG1).
This one is mostly hidden during gameplay, and then shown completely after hitting pause.
Background Layer 2 (BG2).
Some background layers declared.

The background layer is very simple, pick tiles to form a 512x512 map (64x64 tiles, 4096 tiles in total). Now, it doesn’t end here, because instead of having just a single background layer available… We have 14!

Each individual background layer is called a Segment. A single Segment fits in 8 KB of memory, where each tile reference contains H/V flip attributes and palette index. Each tile reference occupies 2 bytes of memory.

The Pixel Processor also allows to combine different segments to generate a bigger layer, but only a set of combinations are available. The largest mix combines eight segments.


Sprites (or ‘Objects’, as Nintendo call them) are single tiles with independent coordinates, but occupy more memory.

There is a place in DRAM called OAM with 8 KB of memory allocated, here is where sprites are defined. Each sprite definition occupies 8 bytes, so up to 1024 sprites can be declared.

Each sprite have the following properties available:

You’ll also notice there are no screenshots shown for this explanation, the next block explains why.


World 1.
World 2.
This one is rendered on both displays.
World 3.
This one is expanded when you pause the game.
World 4.
This is the ‘sprite layer’ I owe you from before.
Examples of Windows.
Some are meant to be rendered on both displays (using shifting effects), others are exclusive to one.

The layering system may seem simple at first, after all, the VIP provides ‘Background’ layers and a ‘Sprite’ layer. So, what else do we need?

The fact is, to display any of the previous layers mentioned, we have to place them in a ‘bucket’ called Window (also named ‘World’). A Window is the actual plane that will be rendered to the screen, it is filled with layers previously constructed. There are 32 Windows available which will overlap to form the final frame, each Window declaration occupies 32 bytes.

Windows provide different rendering modes. You can grab a Background or Sprite layer and display it as it is. For that, the Window has to be set to Normal mode and Object mode, depending which type of layer you are using. However, you can also take advantage of additional modes which apply extra effects on background layers:



After setting everything up, the Pixel Processor will start rendering the 32 Windows. Once it’s done, the final frame will be placed in the frame-buffer area. This process is repeated for the other Display unit as well.

Since the system employs a double-buffered design, the Display Processor will always fetch the frame-buffer that the Pixel processor is not manipulating, which greatly avoids tearing. On the next active period, the Pixel Processor will overwrite the frame that the DP previously displayed, and so on.

If there isn’t much to render (i.e few Windows are used), there will be long gaps between writing over the frame-buffer and the DP picking it up. This allows the CPU to make extra changes over the frame if it wants. The VIP is also prepared for this: The CPU can set up interrupts to check various states of the VIP, including this case.

On the other side, if there are too many affine Windows to render (for instance) the XP may ‘miss the deadline’ which will cause frame drops. Luckily, there are interrupts available to detect that too. In any case, the official docs provide timings each type of layer can take.

Creative content

As you can see, there is a lot more technology in this console than meets the eye.

Affine mode in action, showing the initial background map.
Rendered map, with perspective projection applied.
Frame seen by the user.
Mario’s Tennis (1995).

At first, I thought the Game Boy Advance was the first portable console that could reconstruct the acclaimed Mode 7 of the Super Nintendo, almost 11 years later. It turns out it was the Virtual Boy all along, five years later. But even so, we’ve seen before that affine transformations in the Virtual Boy could be applied to each of the 32 layers (although with some limitations).

Furthermore, all these new functions worked alongside the Parallax effects, something that the VIP also took care of.

I wonder what kind of games we would’ve seen if this console had lasted a little bit more, just enough so developers could get more comfortable with this hardware.

Another interesting feature was that by allowing the CPU to alter the frame-buffer, it provided developers with the ability to construct their own renderer if the VIP wasn’t enough for them. This is what some games relied on to present their innovative graphics. For instance, ‘Red Alarm’ implemented a scenery constructed with polygons rendered by the CPU.

Red Alarm (1995).
Waterworld (1995).
Both games do minimal drawing from the VIP to let the CPU draw main graphics.

Unfortunately, fundamental issues like visible surface determination weren’t always addressed properly, I’m not sure if that was due to the limitations of the CPU. In any case, this resulted in a scene turned into a messy mesh instead, which made difficult for the player to distinguish which objects were behind others.


Imagine you grab the Game Boy’s Wave channel, multiply it by five and add a noise channel: That’s pretty much the offering of the Virtual Boy’s sound chip. You can also think of it as a sibling of the PC Engine’s.

Mario’s Tennis (1995).

In the motherboard there’s another chip called Virtual Sound Unit or ‘VSU’ that provides the sound capabilities. The PSG relies on internal RAM to store five wave tables and a register file to configure each of the six channels available. Registers are 8-bit wide while the internal RAM is connected to a 6-bit data bus (the CPU will still treat 6-bit words as a single byte, but the upper two bits are discarded).

Each wave is made of 32 PCM samples (encoded in 6-bit values). Channels have a panning control setting (with a volume level from 0 to 15 for each left and right) and a 11-bit frequency control.

There’s also a basic envelope control for each channel that makes the volume grow or decay over time. The fifth channel supports more effects, namely a sweeping function to progressively shift the frequency and a modulator to alter the waveform based on some values stored in the internal RAM.

The sixth/last channel can only output noise.


The mixed result is stereo with a resolution of 10-bit and a sampling rate of 41.7 kHz. It’s also worth pointing out that the console has stereo speakers, so you don’t have to wear headphones to be able to enjoy this!


This is in theory a ‘portable’ console, so don’t expect game-changing accessories (pun intended). There’s still some interesting stuff though.

Available interfaces

Internally, every component is pretty much directly connected to the CPU, except some areas handled by the VIP exclusively.

Underside the case, right side [10]. Showing the Controller (Serial) port and External (Communications) port.

Externally, there are two connectors available for accessories:

The provider

The controller of the Virtual Boy is very peculiar compared to the rest of the console line. Somewhat similar to the Super Nintendo one, without the ‘X’ & ‘Y’ buttons, a larger handler and an extra D-Pad on the right. On top of all this, you can’t look at it while playing.

The Controller [12]. Notice the slider on the centre is the ‘power switch’.
Battery cartridge fitted in the back [13].
You can buy a separate cartridge that does AC to DC conversion instead [14], designed to connect the SNES power brick.

Also, because the controller is also supposed to supply power, it comes with a removable battery magazine on the back. The cartridge is called Tap and fits six AA batteries. If users got fed up with looking for batteries after any of the six wears out, they could also to buy a different tap which connects to an external power supply.

In the case of using the latter accessory, playing with everything interconnected with cables may feel like a house of cards (specially if you can’t look at during gameplay) but I guess that’s the price to pay if you don’t want to worry about batteries 🙂.

Operating System

The V810’s starts execution at address 0xFFFFFFF0H. That means that when the Virtual Boy is switched on, it will look for instructions from that address. That being said, that location is found on the cartridge ROM. This means that the game has the upper hand for the initialisation of the hardware.

Also, there isn’t any BIOS chip to be found on the motherboard, so there won’t be any operating system or any abstraction layer to help simplify operations.

House chores

For this reason, Nintendo instructed developers to perform a number of chores to ensure the proper functioning of this console, these include:


One may think that game development would just inherit the same facilities of the Game Boy (that is, stick with assembly), but it turns out Nintendo and NEC invested a lot of new technology to speed up/modernise this area.

Development ecosystem

Game studios had the option to purchase a development kit from Nintendo which included a fully-equipped debugging station, a toolchain and plenty of documentation.

The hardware kit was called VUE Development System (‘VUE’ was the codename of this console), it was a PC-like tower that contained the Virtual Boy’s internals plus 4 MB of RAM (expandable to 8 MB!). It connected to a headset (with the same shape of the retail Virtual Boy) and a retail controller. To run and debug programs, the dev kit contained an interface board that talked to an IBM PC using SCSI. To use the equipment, you needed an IBM PC/AT (or clone) with an Intel 80386, 2 MB of Memory and MS-DOS installed.

The software kit consisted in a linker, assembler and debugger. At request, Nintendo also offered a C compiler. That means it was no longer needed to write programs directly in assembly! All in all, this setup took 1.5 MB of your precious -and noisy- hard disk.

It’s too bad that this model of development was eventually reverted with the release of the Game Boy Colour. I’m guessing that this was because the Game Boy’s CPU can’t handle ‘unoptimised’ code from a compiler.


Game cartridges are called Game Paks. They have the same name of the Game Boy medium but they are completely different in terms of shape and functionality.

Example of retail game.

Due to the memory address space, the ROM can be up to 16 MB without a mapper. This applies to external RAM too (up to 16 MB). Just like the Game Boy, they can have battery-packed SRAM. The cartridge is accessed using a 16-bit data bus.

Come to think of it, 16 MB of ROM is quite a lot for the mid-90s. After all, the max size of a GB ROM was 128 KB! (without a mapper). On the other side, let’s not forget this console uses 32-bit addresses, so every pointer is 4 bytes long. This is two times the size of Game Boy’s addresses (2 bytes), so it adds up to the space requirements.


Due to safety concerns, Nintendo ordered developers to include a couple of images to mitigate eyestrain and other conditions that may arise from excessive screen time.

Games have to include a ‘read the instructions’ warning, an alignment guide and an automatic pause dialog.

First screen.
Second screen (only showing left one).
Third screen, this one is interactive.

These screens will appear after the console is switched on. The first one ‘orders’ the user to read the instructions manual before continuing.

The second one was some sort of a ‘test card’ that was used to properly adjust the IPD dial and the focus slider.

The third one asked the user if they would like to be remained to take a break every thirty minutes.

The first and third screen were often customised to fit the game’s theme.

I don’t think Nintendo dictated rules like this anymore until the release of the Wii.

Anti-Piracy and Homebrew

The fact that Nintendo created yet-another variation of the Game Pak allowed them to retain control of distribution. Although, since this console never took off, bootleggers probably didn’t even bother.

Apart from that, there are no copy protection or region-locking mechanism implemented in this console. Games imported from America and Japan will work on either console. Also, assuming someone would be willing to manufacture their own Game Paks, Homebrew is also possible.

The last time I checked, Flash carts were theoretically possible but only two reached commercialisation, the ‘FlashBoy Plus’ and the ‘Hyperflash32’ (I’m not on commission! but I thought it’s worth the mention).

That’s all folks

My brother fiddling with the Virtual Boy.
The only remaining member of the user research team 😉.

Throughout this series, we’ve seen all kinds of systems, some with limited CPU but impressive synergies, others with questionable hardware but beautifully packaged. This case however, was an interesting proposal: The CPU wasn’t certainly limited and the graphics were up to the task. The sound wasn’t exceptional, yet remained similar to the rest of the portable consoles in the market.

So, why didn’t many children play with it? I’m afraid a marketing study goes beyond the scope of this article. But from the technical side, I think the message just didn’t get through: At the end of the day, nobody cares for affine transformations or a pipelined CPU if you can only see red dots.

I guess that was my main motivation for writing this article, to prove somehow that innovative technology can be everywhere, even where we least expect.

I’d also like to thank the Planet Virtual Boy community for helping me with the study. They are currently working on many projects that give new life to the Virtual Boy, so I recommend checking out their forum for more info.

Finally, this has been the last article of the ‘retro saga’, the next one will return to (relatively) modern renderers, starting with the PSP!

Until next time!


This article is part of the Architecture of Consoles series. If you found it interesting then please consider donating. Your contribution will be used to fund the purchase of tools and resources that will help me to improve the quality of existing articles and upcoming ones.

Donate with PayPal
Become a Patreon

You can also buy the eBook edition in English. I treat profits as donations.


Big thanks to the following people for their donation:

Alternatively, you can help out by suggesting changes and/or adding translations.

Copyright and permissions

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But you have to respect the license and reference the article properly. Please take a look at the following guidelines and permissions:

Article information and referencing

For any referencing style, you can use the following information:

For instance, to use with BibTeX:

    url = {},
    title = {Virtual Boy Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2021}

or a IEEE style citation:

[1]R. Copetti, "Virtual Boy Architecture - A Practical Analysis",, 2021. [Online]. Available: [Accessed: day- month- year].

Special use in multimedia (Youtube, Twitch, etc)

I only ask that you at least state the author’s name, the title of the article and the URL of the article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you may state either the author’s name or URL of the article at the bottom of the image, and then include the complete reference in the video description. In other words, for any resource used from this website, let your viewers know where it originates from.

This is a very nice example because the channel shows this website directly and their viewers know where to find it. In fact, I was so impressed with their content and commentary that I gave them an interview 🙂.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.

Third-party publishing

If you are interested in publishing this article on a third-party website, please get in touch.

If you have translated an article and wish to publish it on a third-party website, I tend to be open about it, but please contact me first.

Sources / Keep Reading






It's always nice to keep a record of changes.