That is indeed an excellent illustration of why ”perfect rectangles” is not a desirable representation of pixels when simulating computer graphics originally intended for display on a 15 kHz CRT TV or video monitor.

In some comments to this article, though, there is maybe some confusion over what you'd actually want to see in a CRT simulation. Granted, there were many different types and generations of CRT displays. They varied in terms of their accepted horizontal and vertical timings, the dot pitch of their shadow mask or the density of their aperture grille, their dynamic range, their effective resolution, the persistence of their phosphors, and the details of their electron gun/beam control. There were also many different signal types and color encoding standards implemented for driving the display — some of which generated their unique artifacts.

But if you do not fetishize about the artifacts as such (such as RF noise, or hum bars slowly traveling across the screen, or adjacent colors affecting each other in unintended ways) but just want the nicest-looking, most authentic and crisp picture you could have hoped to achieve back in the day, it is very easy to specify the gold standard that the emulation/simulation should strive to target:

It is something akin to a Commodore Amiga (any model) driving a TV-compatible 15kHz computer/video monitor — such as the Philips CM8833 or the Commodore 1084S — using RGB signaling. No more, no less. Make it look the same and you’re golden.

What this means in practice is:

1. Forget about EGA, VGA, and SVGA. They’re not relevant to the types of signal sources we’re talking about. (8-bit and 16/32 bit home computers and game consoles of the 1980s and early 1990s) The monitor whose display characteristics you want to simulate should be a CGA computer/video monitor; suitable for both computer and video work (that is, also capable of being used as a CCTV monitor, or for video editing using VCRs).

The monitor needs to be compatible with the standard-definition 625/50 and 525/59.94 interlaced video rasters, and their half-the-vertical-resolution, non-interlaced (progressive) variants, with a 15kHz horizontal scan rate. These are the signal types that were conventionally produced by the hobbyist/home computer systems and video game consoles of the era.

Such monitors are generally close to TVs in their design (e.g. they feature a PAL or NTSC color decoder for decoding CVBS and Y/C signal types) but lack an RF tuner. They have more user-accessible picture controls and support more (professional) input signal types (RGB or Y'PbPr), along with consumer video signals, and are capable of displaying higher effective resolution (discernible ”TV lines” — that is, horizontal resolution on a scanline) than your typical (portable) CRT TV of similar size.

2. Make sure that you attempt to simulate scanlines, and align the input video raster (scanline raster) to the pixel matrix of the target display. This immediately leads to a specific technical restriction on the output side: the vertical resolution of the simulated CRT image must not be allowed to scale freely on an LCD or OLED display, but only in discrete steps that are multiples of the number of active scanlines in the original input signal. (e.g. 288, 576, 1152, or 1728 for a 625-line signal and 240, 480, 960, and 1440 for a 525-line signal.) Otherwise you will run into aliasing artifacts.

For instance, your starting point would be the original vertical (active) resolution as is. Or, more accurately, half the nominal vertical resolution of a standard, interlaced video signal since the home computers and game consoles of the 1980s commonly outputted a slightly non-standard, non-interlaced signal where the TV will draw the consecutive fields effectively as progressive frames, with no half-line displacement between the ”even” or ”odd” fields. At this stage, there can be no scanline emulation as there is no room for it. Each scanline will occupy a single pixel row on the target display.

A step up from this is doubling the original vertical resolution and adding a dimmer, interpolated line in-between any original scanlines. (Just leaving every other line blank is too drastic, and not really how the image looked liked on a CRT. Typically, the scanlines are thicker than the inter-scanline gap.)

Another step up would be reserving two horizonal pixel rows per original scanline, and a dimmer line (row) in-between them, to mark the inter-scanline gap. Now we’re at three times the original vertical resolution.

Thereafter — as the resolution allotted for each scanline will increase in discrete steps — you may start simulating the actual beam shape with increasing accuracy. This would involve simulating the rounded/dimmed/tapering edges and blooming at points where the beam switches on or off or increases or decreases in brightness. Such things help recreate the smooth edges of text and pixel art and the overall, scanline-based ”video raster look” of CRT graphics.

3. Once your scanlines are in order, make sure that you maintain the correct aspect ratio by interpolating the horizontal resolution in lock-step with the vertical resolution. Note that the correct aspect ratio of a video raster (as seen on a properly-adjusted TV, or a TV signals-compatible video monitor), is dictated solely by the EBU and SMTPE video / TV signal timing standards. That is, the shape of the image and its pixels is fully determined from the pixel clock producing the signal, and how it relates to the standard TV timings.

The nominal picture shape of the era was 4:3 but the shape of the actual picture you see on the screen depends on the device generating the signal, and how it paints the pixels relative to the so-called ”active picture” area and sync pulses defined by the TV standards. Often, the image produced by a computer or video game console of the era does not fully cover the entire ”active picture” of the video signal (as specified by standards), and therefore does not necessarily represent an exact 4:3 shape, but may have some other rectangular shape centered within the 4:3-shaped ”active picture”.

4. Also note that standard-definition TVs and video monitors are assumed to overscan the active picture. Some of the picture will go over the edges of the CRT screen and be cut off.

This was originally because the early CRTs were rather roundish in their shape, so the corners of the signal got cut off ”by design” so you could fill all of the surface area of the tube with image. Also, early CRT electronics could not hold the image all that stable and its size often fluctuated based on the overall image brightness and also drifted over time due to the components aging unless you readjusted the geometry potentiometers. This made it impossible to keep the edges of the active picture accurately aligned to the edges of the CRT.

Yet another reason for overscan was that analog production technology (analog TV/video cameras, analog VCRs/VTRs, etc.) could not guarantee a clean signal to the very edges of the nominal active picture. There was video head switching noise and other artifacts hidden behind the edges, so it was desirable to let the CRT ”cut” the edges and shape the visible image in a clean way.

Early TV-connectable home computer and video gaming systems countered overscan by generating rather big borders around the picture, to keep the action centered within an area that is actually visible on the tube. The later systems (such as the original Xbox, and optionally the Amiga) embraced overscan, instead: they could fill the active picture area of the signal to the very edges — with no borders. But while doing so, they also had to follow the same safe area guidelines that broadcasters adhered to when positioning text or graphics or important action.

A proper simulation should both simulate overscan and include an option to switch it off (switch into an ”underscan mode”), with the overscanned mode being the default, as it was on a normal TV or on a properly adjusted video monitor.

5. There are some more interesting and esoteric things one could attempt at doing when simulating the display of interlaced signals (in a truly interlaced fashion), or the persistence of phosphors on a CRT — especially given a high enough framerate (preferably an even multiple of the original vertical refresh rate). Doing things accurately would likely require profiling an actual 15kHz CRT monitor with a special high-speed camera.

6. Given a very high-resolution display, it might become possible to simulate an aperture grille or shadow mask patterning at last to some artificial extent where you align the simulated mask exactly to the pixels of the output device so a not to introduce interference patterns but do not align it exactly to the simulated electron beam.

7. Gamma and other characteristics of the CRT color primaries/phosphors could also be modeled and simulated to the degree possible. Some emulators, for instance, used to have rather bad palettes which in no way matched what you would have seen on a CRT.

8. There are likely to be analog overshoots and ringing in the driving video signal and its interaction with the electron beam control, as well as some filtering and electromagnetic effects that produce some subtler characteristics of a CRT image. Modeling these would require a good understanding of the inner workings of a CRT-based display and the signals driving the circuitry.

All of this should lead to an image that makes e.g. the text of a command-line shell look as smooth as it was on a CRT, instead of being a jaggy collection of lego blocks. But the look of a video raster is a very different thing from just simply blurring or interpolating the original pixel data — so if one thinks mere blurring should do the trick, that is a very mistaken assumption.

Then again — and to get back to where we started — I do not think simulating artifacts such as RF noise or interference, or shadowy ghost images, or PAL or NTSC color artifacting gains much — except as a gimmick that you will try out once, then switch off forever. Such artifacts were undesirable back then and they are also (mostly) undesirable now.

What you want is rather a simulation of a clean signal driving the CRT. Back in the day, everyone would have wanted to get as clean a signal on their CRT as possible, with no extra artifacting caused by the inherent limitations of some signal paths, but of course displayed in the technical manner video raster was supposed to be displayed on a CRT. RGB signal, where natively produced by the computer or game console, and where available as a supported input option on your monitor, was the holy grail of picture quality, also for TV-signals-compatible devices. Some cheaper systems just were not designed to output their video as RGB signal since they primarily targeted users who were assumed to use domestic TVs as their displays instead of the more professional and more expensive CGA computer/video monitors. And, in many markets, domestic TVs also did not feature an RGB input.

Europe was lucky in this regard, though, since the French insisted on getting their SCART connector on the TVs sold here, and the SCART connector specified analog RGB input pins along with composite video. So if your signal source supported RGB in the way e.g. the Amiga and many fourth or later generation home video game consoles did, you could get a very clean picture even on a domestic CRT TV.

(Later on, the ubiquitous RGB support on European TVs also helped with DVD players and digital set-top boxes, which in their European versions commonly included a SCART connector and outputted RGB signal, producing as crisp an image as the CRT was technically capable of displaying.)

(OK, NTSC color artifacting was used in some early systems as an indirect, cheap way of creating a color signal without including ”actual” color support, so it is desirable to optionally simulate it in some cases — but its usefulness is limited to the specific systems and software titles that made use of this approach. For any other titles, you'd rather switch off such color processing and treat the input as if it were monochrome or RGB signal, getting a clean image that is free of accidental color artifacts.)

Yet another thing is, of course, the physical size of the image. In the 1980s and early 1990s, the CRTs of RGB video monitors and portable TV sets were around 14 inches in size. Domestic CRT TVs maybe weighed in at 25 to 32 inches. Factor in the typical viewing distances and you'll see the viewing angle was quite narrow-ish compared to the modern, gigantic screens filling your entire field of vision.

There are some reasonable practical limits to how thicc a scanline could be (or should be in its simulated reproduction), and what is its proper relation to the size of the entire video raster, and how big a part of your field of vision the original images would have covered. If you go much beyond those limits — blow up the image to cover a too large part of your field of vision just because your screen is so big — the pixel art, with its now fist-sized pixels, will no longer appear the way it was originally assumed to be displayed.

Not where I live, and that sounds quite limiting! Thank ${DEITY}, ISPs here in Finland assign their customers genuine public IPv4 addresses, usually via DHCP. Typically, you can even get several of them – the maximum on a consumer connection could be something like 5. (I’m using 2 right now.) Only something like the port 25 (SMTP) is blocked for inbound connections so you’re free to run a personal web server, SSH box, VPN to your home network, etc.

Finnish cellular carriers – as opposed to the actual fiber/copper/cable ISPs – have a different practice, though: they will usually NAT the 3G/4G customers by default, which is quite understandable, as you generally do not want inbound connections to a cellphone. Still, at least my carrier (Saunalahti) lets advanced customers choose a different APN which will give a public IPv4 address even for a 3G modem or a cellphone, which is quite nice and handy as well for some situations.

Manuals for old, unique (non-PC) hardware platforms, peripherals, and programming environments may still have relevance to them, though.

There’s always the retrocomputing/historical angle where you’d want to preserve books such as a register-level hardware reference explaining the capabilities of an old 8-bit home computer model for an aspiring programmer, or a system administration guide for an old minicomputer, or programming manuals (entry-level or not) for such systems. Or user manuals for the seminal applications which were driving the sales of such systems.

Also: some people are very interested in preserving old product catalogs with pictures and technical information of what was available for such systems back in the day.

That is correct. Single-user designs were the norm with personal computers of the era. There are some ways around this (, for example) but they're sort of limited.

The lack of memory protection is due to the first models being designed around the plain Motorola 68000 CPU, which lacks a memory-management unit (MMU). Later models were available with beefier and more feature-rich processors from the 680x0 series, some of the including an MMU. You could also buy add-on “turbo cards” (processor cards taking over the functions of the main CPU, effectively replacing it with a faster one.) But by then it was too late. The OS relies heavily on shared libraries and message passing in flat, shared, unprotected memory space.

Otherwise, the Amiga hardware platform and AmigaOS – the first model/version having been released in 1985 – included concepts such as preemptive multitasking, windowed GUI toolkit in the system ROM (no “text mode” at all), overlapping “screens” in different resolutions and bit depths, hardware blitter and DMA-based I/O (including multichannel sampled stereo sound), drivers for devices and filesystems, the “AutoConfig” system for add-on devices (fulfilling the same role as PnP did later in the Wintel world), 8-bit ISO Latin-1 character encoding as standard, windowed command-line shells, shell scripting, inter-process scripting (ARexx), an OS-provided framework of multimedia “datatypes” (handlers/decoders/players for common file types), scalable fonts, clipboard, speech synthesizer as a standard OS feature, etc.

Ignoring Linux and OS/2 for a moment, in some ways it felt the Wintel camp only caught up ten years later when Windows 95 was released to the masses, and at that point, both the OS and the “IBM-compatible” PC hardware platform were still missing some key features and novel ideas that made the AmigaOS so great and elegant in its day.

Quantum BigFoots (some early models) had a known data corruption problem which could be prevented (altogether, or from getting worse) by applying a firmware uprage from the revision A01.02 to A01.03, or later. Alas, a later version of the firmware cannot fix a drive which already has corrupted areas on its platter: it can only prevent further damage.

I wouldn't pay much extra specifically for getting a touch screen on an ordinary laptop, but if it's there, I don't mind. (I recently bought an Asus laptop with one but it wasn't a factor in that purchase at all.)

There are two use cases where I've found the laptop touch screen kind of useful:

1) Developing and testing touch screen apps, or ideas for those, for touch-screen based devices which are not laptops. Pretty much a no-brainer. It's kind of neat to be able to do that on a your ordinary, "serious" machine even if you're never actually going to use the app that way, outside testing.

2) One-handed browsing sessions. (Yeah, but no - not necessarily only those. More like browsing something while eating or enjoying a hot cuppa with your other hand holding a sandwich, or the cup.) Actual tablets do this use case better, but if all you've got in front of you is an ordinary laptop and you simply want a new screenful to read, would like to follow a link or zoom in a bit or pan around, poking the screen with your non-occupied fingers is sometimes the most straightforward and effortless thing. Especially if it is also your non-dominant hand which you don't normally use for controlling the mouse pointer.

At least Saunalahti in Finland offers publicly routable IPv4 addresses to their mobile customers. You have to activate the feature in the self-service portal and use the correct APN so generally only those who know what they're doing would do it, but it is all documented on their website. The feature is free of charge.

Similar community-driven projects have been carried out in other EU countries, such as Finland.

Here’s one such example from the region that geographically centers around Töysä – a small rural community of 3,000 people – and its neighboring towns/municipalities, some of which are a bit larger, but not much:

Verkko-osuuskunta Kuuskaista (The Network Co-operative Kuuskaista)

6net+ core network (a PowerPoint presentation)

There’s a GreaseMonkey “user script” called YousableTubeFix. If installed, it helps getting rid of many YouTube annoyances – including the completely needless autoplay feature.

Under-appreciated, you say?

On CP/M:

• WordStar, one of the most influental word processors of its time. Even today, several character-mode text editors make use some of the shortcuts which originated on WordStar.
• The CP/M operating system itself, which was quite popular back in the day and gave inspiration to PC-DOS/MS-DOS.

On the Commodore 64:

• GEOS by Berkeley Softworks. Who would have thought the venerable C64 could host a GUI system almost making it comparable to the first Macintosh models (not quite, but suprisingly close, given the 8-bit processor, memory limits etc.) There was a host of serious productivity applications for this environment.
• PageFox: a desktop publishing system for the C64.
• Microrhythm: a digital drum machine based on the undocumented sample playback features of the SID chip.
• The SID audio chip, which was way more feature-rich than its competitors of the time, and in some ways comparable to a “real” synthesizer, giving actual character and resonance to computer music, instead of just beeps and blips. Its creator, Bob Yannes, later went on to found Ensoniq, a company which designed and manufactured actual musical instruments (keyboards, samplers, etc.) The SID was a unique piece of audio hardware which enabled the musical software of the C64 to do its magic – and its legacy still lives on in the form of numerous emulators, vast sound archives and libraries (such as HVSC), custom-built musical instruments based on the chip (such as the SIDStation), etc. This is one of those cases where a piece of hardware has been inspirational and influental and enabled a number of software applications which would have been pointless if it weren’t for the hardware.

On the Amiga platform:

• (The Ultimate) SoundTracker by Karsten Obarski, later followed by the even more popular, more advanced clones or derivatives: NoiseTracker and ProTracker. These started the whole computer music “tracker” genre as we know it today – with four sound channels in a stereo arrangement and digital instrument samples, no less.
• Audio Master, one of the first digital audio sample editors for an affordable personal computer. Supported stereo sound as well. (Often accompanied by inexpensive audio digitizers attached to the printer port.)
• Deluxe Paint by Dan Silva of Electronic Arts – the first paint program for the Amiga. Taking a different approach from its predecessors on other platforms (which were mostly toys), the Deluxe Paint was a very powerful bitmap graphics art package, featuring advanced multi-color blitter-enhanced free-form brush handling features and color cycling effects, and used for creating graphics for innumerable games and demos – also when developing for other platforms than the Amiga. Later gained animation features as well. Still a great paint package for creating graphics for any old computer with paletted graphics modes. Also introduced the EA IFF format, which was then adopted to the Amiga platform wholesale as the standard structured format for many types of files. It was later also adopted to Windows in a bit modified form (RIFF – for example, the so-called “wav files” are in RIFF format), but not as widely.
• Photon Paint: A paint program making use of the photorealistic 4096-color “HAM” mode.
• Real 3D. One of the first CSG solid modeling ray-tracing packages for personal computers. Supported smooth-curved quadric surfaces (instead of the jaggy polygons of its contemporary competition), calculated reflections and transparency in materials in a physically accurate, realistic way (a lens would actually function as a lens), and made good use of the Amiga’s 4096-color “HAM” graphics mode.
• NewTek’s Video Toaster: the first studio-quality genlock, video titling / paint box / CGI / visual effects / animation toolkit, and video mixing system, implemented on top of an inexpensive, generic-purpose multimedia computer platform with the aid of the supplied video mixing hardware. (Also gave birth to the LightWave 3D modeler/renderer.)
• Scala Multimedia – the versatile video titling and info TV application, tightly synchronized with the vertical refresh of the TV-compatible video modes, so you could get absolutely silky-smooth, professional-looking scrolling and wipes. (Unlike in PowerPoint etc. where they will always stutter.)
• The AmigaOS itself: the first widely available, mouse-driven, windowed, pre-emptively multitasking GUI operating system, which came standard with an affordable personal computer. One of the unique features of the AmigaOS and its supporting hardware was the ability to run applications in multiple different graphics modes (pixel clocks, bit depths) yet display them at same time on the screen.
• The Amiga platform itself: the first true “multimedia” computer which was released before the term “multimedia” was coined. (Pre-emptive multitasking, multi-channel stereo sound based on digital sound sampling and DMA playback, speedy hardware blitter and a simple co-processor, photorealistic-at-its-best graphics and animation capabilities, compatibility with TV standards, built-in support for synchronizing its video raster to an external video source with the help of a genlock, etc.) On other platforms of the same era, these features would not have been available to the software applications.

Probably forgot to list all too many interesting things, but there you have it. For some applications, I find it difficult to separate the hardware from the actual application. Ground-breaking computer applications often needed never-before-seen groundbreaking computer hardware to support them, which was mostly the case with the Amiga, for example.

I can't get over how fast that client is... after sitting through broadcast Teletext and waiting for pages to cycle round, it's interesting to see how much more usable the system becomes when it's responsive.

Many modern TV sets (from mid-to-late 1990s and onwards) and DVB set-top boxes can cache all Teletext magazines – including subpages – which makes browsing the content a breeze.

The DVB standard ETSI ETS 300 743 defines a method for transmitting Teletext data over a DVB (MPEG-TS) stream. This method is used in the DVB countries which maintain the old Teletext service alongside with the digital broadcasts. DVB set-top boxes and TV sets with an integrated DVB receiver/decoder commonly include a Teletext browser.

UK has chosen to abolish Teletext in favor of an MHEG-5 based information service – known as the “red button” service by the viewers. However, this does not mean it wouldn't have been technically possible to carry the full Ceefax Teletext service over DVB broadcasts in the UK as well: the local broadcasting companies just chose not to do it.

Broadcasters in some countries – such as Finland and Italy – have experimented with providing a similar information service through the more ambitious, Java-based MHP, instead of MHEG-5. But in Finland, at least, these experiments have failed due to unenthusiastic response from the STB makers and the general public. (The MHP services were probably introduced at a too early stage, and it was partially a PR failure as well.) Instead, regular Teletext service is still being broadcast on many local DVB channels using the method defined in ETSI ETS 300 743.

Nearly all foreign TV shows and movies which are shown on Finnish TV channels are subtitled in Finnish – that’s the norm here. (Dubbing is normally never used here except for the content intended for kids under reading age. Also, the narrated sequences in some documentaries are sometimes re-narrated in Finnish whereas their on-screen dialogue remains subtitled. But those are pretty much the only exceptions.)

The same practices go for actual movies seen in a movie theater, and the shows and movies released on DVDs or Blu-Rays.

DivX Finland is mostly providing subtitles for the purposes of watching shows and movies which are not (yet) made available in Finland through official channels, or – as it might be the case with some more obscure foreign TV shows, for example – never will.

Some individuals who are fluent in some particular foreign language – usually English in the Finnish context – take pride in watching shows or movies of that language without subtitling. Yet, the norm here – which is also reflected in the default settings of the set-top boxes and TV sets – is that subtitles for translation are always on and visible. (The local TV channels show a lot of foreign content which specifically calls for translation. It just wouldn’t fly if they tried to provide it to the Finnish-speaking audience “as is”, with no effort to translate. People expect the translations to be there.)

Some Finnish-language shows may also have subtitles in Finnish for the benefit of the hard of hearing. But these subtitles, which are not about translation but transcription, are never seen by the normal folks as you need to fiddle with the settings of the TV to receive them. And only those who have the need will want to see them on their screen anyway. (There is also no legal requirement to provide such Finnish-on-Finnish transcription service, so the availability of such special-needs subtitles is pretty much limited to some select shows produced by YLE, the local public broadcaster.)

I was born in 1976 so I got to experience the rise and fall of inexpensive mainstream 8-bit and 16/32-bit microcomputers during my school years. Perhaps more significantly, I also got to experience “home computing” as a hobby, rather than as daily necessity. Also, I belong to one of the generations which were – already before entering school – significantly more knowledgeable about computers than their parents. I suspect this is a condition which may no longer necessarily hold true with the more recent generations...

I entered the first grade of elementary school in September 1983. I also got my first computer, the Commodore 64, for the Christmas of that same year. It was not my first experience of personal computers, however: during the previous year, I had already got my feet wet on my friend’s VIC-20. (My friend was an enthusiastic home computer hobbyist and he had taught me some BASIC programming, so I knew a little bit about that, too – even before entering the school.)

As far as my school was concerned, computers didn’t really exist. They where nowhere to be seen in the lower grades (1–6). They just didn’t belong to the curriculum for the smaller kids. Most adults – including school teachers – were only trying to come to terms with the rather frightening prospect they will yet need to learn about these devil’s machines before retiring... The kids of my generation, though, were eager to get a home computer for themselves during those years, which was in no small part because they filled roughly the same spot as game consoles today. But home computers were also favored by hobbyists and tinkerers, of course, and I had the hobbyist/tinkerer mindset about it. Games were only of secondary interest.

After a few years, my C64 setup had grown to include the Commodore 1541 diskette drive (I started out with the Datasette), the MPS-801 dot matrix printer, and a copy of the GEOS graphical desktop environment – even a Commodore 1351 mouse, which was a rather rarely seen peripheral for the C64. Beginning from the 3rd grade, I was actually using geoWrite (the standard word processor which came with GEOS) for some of my school work. The teachers were a bit baffled at receiving dot-matrix printouts on fan-fold paper from a 3rd grader but generally their response was pretty good. On occasion, though, I was not allowed to use the computer because the teacher insisted typing would not serve the secondary purpose of the writing assignments: honing ones skills in cursive handwriting. This was somewhat irritating considering I was rather more inclined to write in block letters, anyway (and continue to do so to this date...)

Our class was assigned a class magazine project both during the 5th and the 6th grade. I brought my entire Commodore 64 setup in school to make it possible to design the layout of the pages (partially) on a computer. My Finnish teacher – who has now sadly passed away – was so excited about getting this primitive form of computer-based desktop publishing in her class she called the local paper and they made a story about it, with a picture and all. The second year I did this I also brought in an Osborne I and another dot matrix printer which my dad had salvaged from getting binned at his workplace. I let another kid type in articles using WordStar on this other computer.

By the time I entered the 7th grade (1989), I found out the upper level elementary school had two computer labs for teaching “automatic data processing”. These were the only classrooms with computers in them in the whole of school. (Later on, the music class and the art class received a computer each as well.) The older one of the two computer labs was already considered obsolete as it was only equipped with Apple IIs. The current focus of the computer classes was on MS-DOS and IBM-compatible PCs. The typing class, however, used the Apples for typing exercises. Otherwise they just sat there unused. (The problem was, how do you gracefully get rid of a couple of dozen of old computers which were bought with taxpayers’ money? It was a bit delicate question – even politically loaded – so the Apples remained there for the time being.)

The primary computer lab was equipped with Amstrad PC1640s. There was even a LAN built on LANtastic and Artisoft’s custom network adapters. It was all moderately OK for a basic MS-DOS teaching environment but these PC/XT clones were also quickly becoming obsolete, and they were nothing to write home about. Especially as by that time I had purchased an Amiga 500 which run rings around the computers in school in just about all respects (it had a better OS, better graphics, actual sound instead of beeps, multitasking, 3.5" microfloppies instead of 5¼" floppies, etc.)

Continuing the trend set in the lower grades I brought the Amiga to the school for a few weeks to display its graphics and sound capabilities. The teacher was impressed – especially about the sound and music.

So what was taught to us in these elementary school computer classes? The course started out with the teacher explaining the basic theory pertaining to the operation of the computer. This was basically done in a fairly traditional way, utilizing a block diagram and arrows which explained the roles of the processor, memory, instructions, input, output, storage, etc. After this introduction, we moved on to practical use of computers, which was... MS-DOS commands. There was a bit of programming, too (I guess it was in QBASIC), but only a bit – it was already deemed quite unnecessary for an ordinary computer user. Quite a lot of time was assigned to learning the basics of the spreadsheet and the word processing components of Microsoft Works (this was the text-mode MS-DOS version.)

The MS-DOS versions of Deluxe Paint and Deluxe Paint Animation (originally an Amiga paint program) were also available and used in these classes. Because me and my friend already knew pretty much everything taught in the course and could easily figure out the parts we didn’t, we actually spent most of our time designing animations in Deluxe Paint. So those classes were sort of useless for us. But it was fun times anyway since otherwise we would have had to sit in some other class... and of course there were some new things I picked up about IBM-compatible PCs in general, as I was an Amiga user at that time and didn’t have much hands-on experience on them.

The teacher also run weekly computer club nights for those interested in computers. Many attended, yours truly included. One of the highlights of these club meetings was when the teacher made us carry one of the PCs to the school library. We were then instructed to make a phone call from one of the computers in the lab to the computer in the library, using modems and terminal emulators. This was the first time I was chatting away in real time using mere text, with another person typing on a different computer at the other end. That other person happened to be someone who owned a modem himself. After a quick text-based chat we discussed some more face to face, and he introduced me to the world of BBSes. I was soon a modem-owner myself, which was perhaps the most useful thing which came out of those club nights and the computer classes in general.

The primary computer lab had a separate walled office for the teacher. There was a curious thing sitting in that small room, taking up lots of space. It was a large machine the size of a refrigerator. And there was this larger machine behind it which resembled an overly tall chest freezer. And to top it all, there were these strange displays and keyboards scattered around the tables the back of the class room, gathering dust in there. They were definitely not PCs but we were never told to switch them on during the classes. So what was that all about?

Turned out it was an IBM System/34, with a refrigerator-sized line printer and half a dozen IBM 5251 display terminals. The teacher explained to me the school had received this setup as a donation from the local asphalt company. This was some time in the beginning of the 1980s. Then he pointed at the wall. There was this picture hanging on there – a yellowed cutout from a local paper documenting the happy event. In the picture, the manager of the said company was shaking hands with the school officials, smiling. So... the local company got good PR and a place where they could dump their obsolete hardware (for free). The school got a truckload of (old, obsolete, difficult to manage) computer equipment. What could be a better deal? ;)

Needless to say, the System/34 was a rather demanding environment to operate for an elementary school teacher. Even booting it up (from an 8" floppy, no less) took some 15 minutes. And the skills ordinary school kids could learn on those terminals, using with the left-over software originally used by the asphalt company, probably weren’t easily transferable to the modern PCs. So, rather unfortunately (but understandably), there was not too much love for it in the school... it was just sitting there, taking up space.

Which raises the question... why was it still there? The same reason why there was that other computer lab full of Apple IIs! Back in those days it was not politically easy to get rid of once-expensive, still impressive looking computer equipment without rubbing some people the wrong way. Especially as the system was originally given to the school as a generous donation. (The teacher finally managed to make the system disappear some years into the 1990s... a bit of a shame really. I only saw it running once – during one of those computer club nights when I specifically asked the teacher to boot it up, just to see how it works. But once we got to see some life on the terminals, the teacher couldn’t find the folder where he had written down the login password... so we never got to see anything more than the login prompt. For the better or worse, that was my one and only experience of the System/34...)

Once I graduated from the elementary school, I started the upper secondary school (grades 10 to 12, which prepare students for university.) This school shared some of the resources and facilities with the local elementary school and used the same computer lab and even the same teacher – despite being located in another building a couple of kilometers away.

The computer labs were now upgraded a bit – the old Amstrad PC1640s were being replaced with generic 386 PCs with SVGA cards and the Apples were gone, being replaced by the PC1640s. During this time I was an active user of dial-up BBS systems. One thing led to another, and soon I was also one of these three guys running the school’s semi-official dial-up BBS... which we founded once we got a permission and some funds from the principal.

We based the system on an advanced messaging board software called BBBS. It was also accessible from the school-wide LAN (the school now had computers in the lobby and in the library). It soon attained a handful of active users – among them also girls who were a couple of years younger than my age. This was a somewhat surprising development for the time. Or then again, not so surprising – it was the discussions and the social side of it all, not so much technology and tinkering, as it was for the guys. These were the first generations of girls naturally drawn to online discussion boards right at the school age.

The computer lab classes were not compulsory in the upper secondary school, either but I took them to fill the schedule. This time, we were actually made to program in the class – even using a “proper” compiled language: Borland Turbo Pascal. But with some negotiation I managed to change this to C for my part and did my project in that language, instead, just because I thought it was a more interesting and capable language. Another one of our assignments was simply about figuring out a project which would somehow involve using the computer and writing a detailed report about it – which had to be done on the computer as well, of course.

During my last couple of years in the school (1993–1995), the younger school kids had been granted access to the Internet during their computer classes using a dial-up modem connection. As it turned out, this was the beginning of the end for the dial-up BBS online world and the hobbyist computing which were both to be replaced by the Internet and a generic mainstream interest in computers as communication tools.