There are many old Commodores but I am going to talk about the Amiga.

Hardware

In terms of hardware capabilities that modern computers lack, the first thing that comes to mind is the Amiga’s ability to display different screen resolutions and colour depths on the same screen at the same time.

This is a screenshot of an emulated Amiga 1200. The top half of the screen shows the desktop, Workbench 3.1, running in a 4 colour high res (640×256) screen mode. Below it is DPaint IV, running in a low resolution (320×200) 32 colour screen mode.

Amiga screens are a bit like virtual desktops. You can flip between them and drag them up and down revealing the screens underneath. Here, DPaint IV is running on top, and I have dragged it down halfway to reveal Workbench running underneath.

Notice how the pixels on the Workbench screen are finer than those on the DPaint screen. It is running in a higher resolution.

The later AGA Amigas also had the ability to display high resolution hardware sprites on a low resolution screen, and you could scroll low resolution screens in high resolution pixels, effectively allowing you to scroll in quarter pixels.

This was enabled by the Amiga’s graphics co-processor, known as the “Copper chip” which was synchronised with the beam that draws the display. The Copper chip could change the state of the Amiga hardware as the screen was still being displayed. Not only did this allow multiple screen resolutions at the same time, but it also allowed you to change the colour palette as the display was drawn, giving you more colours onscreen.

Software

There are also several software capabilities provided by the Amiga operating system that are sadly missed today. The first is the Datatype system.

A Datatype is a kind of operating system plugin that knows how to load and save a particular file format. If I install a JPEG Datatype, then all Amiga software that uses Datatypes can now load and save JPEG images, even if they weren’t originally created with that capability. If a new file format was invented today in 2022, I could make a Datatype for it and all my ancient Amiga software would be able to use it.

Here I am using Multiview on an Amiga 1200 to view a PNG image. PNGs did not exist when Multiview was written, however thanks to Datatypes it can load and display them.

Another capability provided by the OS was the ARexx scripting language. Almost all Amiga applications provided ARexx ports that exposed their functionality to remote control and scripting. Modern PCs have many scripting languages, but there are no standards, and few modern applications are as extensively controllable from outside as Amiga apps were. On the Amiga, pretty much the entire community got on board with ARexx, and even the smallest public domain utilities were scriptable.

This is a screenshot of Personal Paint running on an Amiga 1200. The concentric circles were not drawn by hand, but by an ARexx script remotely controlling the software. You can see the script in the bottom part of the screen, inside the MicroEMACS text editor.

Principles

Aside from hardware and software capabilities, the Amiga and its time enabled certain principles to exist in computing, and a certain mindset that has gradually diminished and become lost as other technologies and other principles have come to the forefront.

“Ergonomic access to the full power of your computer”

The Amiga existed at a sweet spot in the history of computing. Like the 8-bit machines which came before it, you could kick out the operating system and program the hardware directly in assembly language. But it also had an innovative multitasking OS, a lightweight GUI that you could program using object oriented methods, and a command line environment that approached Unix, only on a far cheaper machine.

This wide range of capabilities was still at a scale that was accessible to the lone hobbyist programmer. As an Amiga owner you were empowered to make use of the whole power of the machine.

This principle is demonstrated clearly by Blitz Basic 2, the programming language that I grew up with. Blitz let you write hardware hitting games, native GUI apps and command line tools out of the box, with no dependencies and none of the tedious configuration and administrative work that now accompanies supposedly modern high-level languages.

Here is a simple graphical demo I made in Blitz 2. It turns off the operating system and draws some animated bouncing balls using the Blitter hardware. The background gradient is generated by the Copper chip. In modern terms, this could be considered a “GPU” program. 42 lines of code. (The source is available on github)

This is a biorhythms app (remember those?) written in Blitz 2. This one uses native GUI widgets and a custom graph display. 63 lines of code. (Original program by Simon Armstrong. Found on the “Ultimate Blitz CD” available from various online sources)

Both of these programs have no external dependencies and with a few clicks, I can create a binary executable file that others can run on their Amigas with no installation or configuration required.

So this points to another Amiga capability that we seem to have lost, the ability to write simple applications simply, with only a few lines of code and a minimal or non-existent administrative burden.

Compare the experience of learning a high-level language today to that of the Blitz user in 1994. My first Blitz programs were graphical effects. I was drawing shapes, moving sprites around with a game controller and playing sounds on day one.

If today, I want to learn Python, Ruby or my favourite high-level language, Common Lisp, I can only write boring console programs out of the box. If I want to open a window or draw something I need to use a third-party cross-platform toolkit and figure out how to talk to it using C bindings or whatever. Essentially I need to know C or C++ to do it effectively. This is certainly not accessible to beginners, and an awful experience for programmers in general.

In 2022 you’d think that our programming environments would be even more ergonomic and even more effective at giving us access to the power of our machines. You’d think we’d be able to open a window or play a sound in a high-level language with one line of code, out of the box.

Occasionally someone comes along and attempts to solve this problem with some huge package or contrived environment, another layer of abstraction on top of an already tottering stack of previous attempts. But this problem needs to be solved at the system level.

We need to build operating systems that uphold the principle of making computer capabilities readily and ergonomically accessible to high-level language users. Perhaps through some kind of language-independent library system with extensive metadata, or through a OS-wide messaging system.

And we need to start thinking of layers of abstraction as dimensions of usability that are meant to be navigated and used, and not, as we think of them today, as things that “save us” from the folded and shattered strata of unexcavated technical failure underneath.

I’m currently working on a top secret project called SLIDE. It’s an application, and its written in C++ with Qt. I don’t know how much more I want to reveal before its finished.

I use Linux at work, making web applications, and when I wanted to learn more about it, I found some great books, including “Linux Administration Handbook”, and “How Linux Works: What Every Super User Should Know”.

They gave me a good understanding of how Linux was put together, and built a foundation I could use to understand the details from other sources. So after my frustrating weekend with Windows I decided to find the Windows equivalents to these books.
I couldn’t find them.

It seems there are two kinds of books for Windows. Books for total beginners, and expensive volumes for people studying for professional certification. They contain a lot of information but are clearly focused on people working with Windows Server in a corporate environment. They go into great detail about managing the access permissions of hundreds of users, and performing network-wide software installations.

Not much use to a programmer running Windows 10 at home who just wants to know how to control his computer and confidently deal with any problems that arise.

I’d like to see a book, “Windows for Power Users”, which would give me a detailed description of how Windows works, what its major components and ruling principles are.

I’d want a comprehensive discussion of the network stack and Windows Update, how to read and interpret the contents of the Event Viewer, and use the Computer Management tools. I’d like to understand device management and drivers, and I’d like an intro to PowerShell and how to use it to administer and troubleshoot everything previously described.

Maybe all this information is scattered across Microsoft’s website? I certainly can’t find it to my satisfaction, nor can I give the fragments of information I do find the context and big-picture awareness that an expertly written book can provide.

For the past couple of months I’ve been messing about with some retro-programming, working on a little game in Blitz Basic II for the Commodore Amiga (more info coming soon). I just wanted a nice no-stress project to spend a few weeks on before making yet another attempt to change my life through code.

I grew up on Blitz, and it was fun to return to it again after 20 years. On a whim, I decided to write an Emacs major mode for Blitz II so I could edit and read code outside of an Amiga Emulator. It was also a good opportunity to practice my Lisp programming (Emacs plugins are written in Emacs Lisp).

bb2-mode not only provides syntax highlighting and online help for over 2400 Blitz II commands, it can load and save tokenized files. Blitz II saved its source code in a custom file format in order to save disk space. As far as I know, bb2-mode is the only thing outside an Amiga which can load and save these files. So even if the Emacs-using-retro-Blitz-programmer demographic isn’t that large, bb2-mode still has some value.

Anyhow, bb2-mode is on github and is under active development. I’ll have more to say about Blitz II in the future, so stay tuned.

Well, I have been busy:

• Learning 3d modelling
• Improving my art skills
• Improving my maths skills
• Learning Unreal Engine
• Learning Common Lisp

Developing Antigen was a pretty frustrating experience. I had no problems with the programming, but creating the artwork was difficult and took a great deal of time and experimentation. I threw away an enormous amount of crap artwork during the production of the game. So I resolved that once the game was finished, I would spend some time working on art fundamentals before doing another game.

I’ve been working through Drawing on the Right Side of the Brain, which I actually find quite difficult. I’ve never been interested in drawing things in the real world or in representing reality; I only ever wanted to express what was in my imagination. My brain goes crazy when I try to draw a chair or a cup or something – its like it’s not interested in purely sensory phenomena, but constantly tries to seek ideas or “personalities” in things. I’m going to stick with it. There’s a lot of value in doing things that don’t come naturally to you.

I’ve also been working on the exercises on Draw A Box which I’ve found extremely helpful in building basic pencil handling skills (Which I sorely need. I have dyspraxia, and had to have a special pen at school!)

Coffee machine modelled in Maya. One of my first models since starting the Digital Tutors course. One day I’ll do a nice render of it

On top of that, I’ve been learning 3d modelling in preparation for my next game which will use the Unreal game engine. I learned to model years ago, using Imagine on the Amiga, but my skills were pretty out of date. Maybe I’ll post some of my models and renders when I start getting good. I’ve been following tutorials on Digital Tutors. The tutorials are very good, but it is a bit pricey, especially as you’ve gotta sign up as a premium user to access the project files/reference images which you need if you really want to succeed.

Apart from the game development stuff, I’ve also been learning the Common Lisp programming language. I got interested in Lisp a couple of years ago when I first found out about Lisp Machines; high-end workstations from the 70s and 80s that worked in a fundamentally different way from computers today. They offered programmers a positively luxurious environment for building software, and I found them extremely inspiring. I want to do something special with Lisp, but I ain’t gonna talk about that yet

Last week I received my Oculus Rift DK2 headset which I ordered back in August. I had my eye on the Oculus DK1, the first version of their headset, but I was too busy getting Antigen out of the door to let myself be distracted by other projects. Now Antigen is out of the way, I can let myself experiment a little while I figure out what my next big project will be.

It comes in a padded, reusable cardboard box, which is fine for storage but if I was going to take it anywhere I would probably get a Pelican camera case or something similar, and cut some custom foam inserts for it, like this Oculus user has done.

The headset is surprisingly light, and connects to your computer with a sturdy cable that runs over the top of your head along one of the headset’s straps. I imagine this was done for weight distribution and to help keep the cable out of the way when you move around.

The cable connects to your computer via 1 USB and 1 HDMI port. There is a motion tracking IR camera that clips to your monitor like a webcam. This uses 1 USB port. There’s also an optional power supply if you want to use the USB port built into the headset. One device that uses this is the Leap Motion, which I’d like to get my hands on sooner or later…

The Rift also comes with two sets of detachable lenses; a longer lens that is already installed in the headset, and a shorter lens intended for nearsighted users.

Setup was easy. I downloaded the drivers from the Oculus website, installed them and as instructed, updated the headset firmware using a simple and straightforward preferences utility. This tool also lets you create user profiles for the Rift, containing your height and other details.

The Rift appears to your computer as a second monitor. You can view anything you drag on there, but it will look like crap unless it is rendered stereoscopically and positioned correctly. There is a DirectX style “Direct Mode” that lets applications talk directly to the Rift, but it doesn’t work on the Mac yet. (The Mac is a bit of a second-class citizen for the Rift at the moment. Unfortunately, most of the coolest demos are Windows only too.)

At this point I could hardly contain my urge to jack in to the matrix and become the console cowboy I’d always dreamed of being, so I hit “Show Demo” and braced myself.

I found myself sitting at a desk in cyberspace, somewhere on an infinite Tron-esque plain. The first thing that struck me was the stereoscopy, the 3d-ness of the lamp and the tower of playing cards on my desk. I really felt I could reach out and touch them.

The resolution is good at 960×1080 for each eye, but I don’t think it’s high enough for consumer use yet. I suspect that in order to approximate the usability and experience of a desktop monitor, VR displays will require a much higher relative pixel density. There is also a kind of “screen door effect” where you can see the pixel grid. Most of the time this isn’t too bad, but it is noticeable when you try and view details that are further away, such as the faces of game characters.

Text is readable as long as it is large and in the middle of the display. It’s a bit like looking at text on a C64 with a bad TV set. Towards the edges of the display it gets blurry and there is some chromatic aberration. You need to look at text directly in order to read it properly, which will have ramifications for UI design, particularly games where information is usually positioned at the edge of the screen.

All the same, these aren’t really criticisms, they are just statements about where the developers kit is right now. The DK2 is a prototype that a deranged experimenter committed person works with and adapts himself to, rather than a consumer product. I’ve not had a chance to try the new Crescent Bay prototype, but reports suggest that it eliminates the screen door effect and that we can expect the consumer version to be a real advance on what is currently available.

There’s a nice demo included with the SDK where you can walk around an Italian country house and its surrounding grounds. The house is on a cliff over the sea. You really feel like you can fall off when you approach the cliff. One thing I found interesting is how your body is tricked into reacting to things when you accidentally bump into them. It feels suddenly like there is something real there. This demo also shows how high quality shading and lighting can mitigate some of the shortcomings of the headset such as the resolution and screen-door effect. Another demo I tried, 4thFlrStudio by Brendan Coyle demonstrates this clearly, with its remarkable lighting and detail.

After a bit of messing about I got Steam and Half-Life 2 working on the Rift. Within minutes it gave me motion sickness! It clearly showed how VR requires both a rock-solid framerate and well-calibrated motion settings in order to be effective. Anything less than 75fps will likely send the user running to the toilet!

The presence of other characters in the game is startling. This was the first time I had encountered another being in VR, albeit a simulated one. At the beginning of HL2 you go through a police checkpoint and one of them thumps you in the chest. I actually felt it! The enemies were extremely intimidating. I dread to think what it is like on the later levels when you encounter the Hunters and Striders! I really felt I was inside the game, it’s kind of like a fuzzy lucid dream. I will have to experiment with the settings to see how far I can minimise the motion sickness.

The next thing for me to do is get the SDK going and see what I can create with it. I might also need a more powerful computer. Some of the demos I tried only ran at 16fps. My 2012 Macbook Pro is a great for general use and for my iOS development, but its NVidia 650m has about 1/7th the power of a top desktop GPU.