Steven Goodwin

For most people, an emulator is a way of running old software (usually games) on new hardware. But using an emulator to step through the original ROM code of an old computer can provide insights on how the machine worked, teaching us tricks that were usually the preserve of hardware hackers.

In this talk, we cover seven different machines (including perennial home computers like the ZX Spectrum and Commodore 64, along with the Dragon 32, and consoles like the Gameboy) to deep dive on a single element of their implementation. We explain how data can be transfered without a data bus, why it's quicker to check for multiple results instead of one, or what is the legally optimal series of bytes for copy protection.

Beginning with a brief overview of the era in question, 1980-1985, we begin by looking at each of the 7 machines, showing an open source emulator, and how it works in a normal scenario. We then highlight a portion of the code to examine, and break down the reasons for it being written in the way it was. For each machine, we focus on the way the code makes the machine work showing a practical use to emulators that is often overlooked.

We end with a number of "honorary mentions" of ROM code that exists for non-essential purposes, such as Easter eggs.

p.s. no knowledge of antiquated assembly languages is required or expected!

In an ongoing search for new programming metaphors I have devised a tiny language called Zarkov. Its proof-of-concept has been implemented in Javascript and allows for basic maths to be performed in either direction, i.e. forward and reverse. So, should you get a error, you can simply invoke the .back() method on the program object and the steps revert allowing you to see how/why it reached that state.

The PoC is essential a way of handling UNDO and REDO in terms that represent a programming language, rather than an application.

But is it useful? Has it been done? How does LISP already do this? (Because LISP can do anything, right!? :)

After a (mercifully!) short presentation, the floor is opened to see if the idea has merit or prior art, and whether it's worth pursuing.

In 1982, David Horne wrote a version of chess which managed to fit inside the memory of a 1K ZX81. Although it wasn't a complete implementation, it was impressive enough to be remembered now, almost 40 years later. But running it in 2022 requires at least an emulator, ROM file, and the .P file, which limits the appeal to retro enthusiasts and excludes the intended audience - chess players!

So, I modified the EMF emulator (and the game) to run as an emulator-as-a-service, so that it can be played via the lichess servers with a modern web-friendly interface.

In this talk I'll cover a brief history of the program, how the emulator was modified, how the program was reverse engineered and understood, how this code connects to the lichess server and, most crucially, why someone would do it!

Along the way we'll look at the chess notation, FEN, Z80 assembler, NDJSON, and a few other pieces to show you the complete puzzle fits together.

We all know that Ada Lovelace is credited as the first computer programmer. But what did she write? What did it do? And how does it work? We look at the program, its function, and break it down line-by-line so you can understand the origins of our entire industry. After all, it doesn't get any more retro than this!

In this talk, developer, geek, and digital archaeologist, Steven Goodwin, breaks down the very first program ever written to explain what it does and how it works. He goes on to simulate it within a JavaScript version of Babbage's analytical engine, rewriting it piece-by-piece until it looks like modern code, and thereby demonstrate what features of current languages we now all take for granted.

He finishes up with a discussion on the controversy surrounding her involvement in computing, aiming to answer the question once and for all - "Was she really the first programmer?"

Back in May 2015, I spent an evening watching retro game documentaries and was inspired to develop a game for the ZX Spectrum... a computer released back in 1982. After all, with everyone talking about making retro games (but actually making modern games with retro visuals) I decided to make a real retro game. In machine code. This talk covers the methods by which a modern computer is able to help developers write, debug, and test new software that runs on old systems. It uses the game "ZX Adventure" as a real-world example.

Old machines had so little power you were forced into writing highly-optimised assembler if you wanted anything to fit into that tiny memory, or execute reasonably fast on those slow processors. Luckily, modern machines make the process of writing software so easy you can spend all your development time on the fun parts - and it's this part we'll focus upon. Starting with the game design, we begin by creating "Hello world" on the obsolete machine, understand the truly minimal requirements, and building up the game piece by piece.

We also touch on the issues of emulation, licenses, and publishing, given that the original Spectrum game has now been ported to the ZX81 for a commercial (and yet still open) release.

The closing keynote of 2020 covered the history of FOSDEM. Now it's your turn to share your memories. This session is an open forum for people to share 2-3 minute stories and anecdotes from their time at FOSDEM, including favourite sessions, parties, speaking experiences, and so on.

Ideas for stories might include:

• problematic journeys to the venue
• projects you saw before anyone else
• successes of projects
• people you met (or fell out with!)
• what it's like to get into the Ada dev room :)

Ever wanted to write an emulator? Or understand how they work? In this talk you learn how to start writing your own emulator from the ground up. You'll see the basic methods used to emulate CPUs, memory, and graphics cards. For the keen, we'll also cover advanced emulation techniques, licensing issues, and history.

There are a lot of old machines in the world, many are literally falling apart, and out of the consciousness of the programmers who once built them. But all deserved to be remembered. That's why we need more emulators developed in the open, so the knowledge isn't lost to history. By showing how easy it is, we hope to encourage others to do the same, regardless of their language of choice or which old computer they want to resurrect.

With worked examples, live demos, and new games, there is a lot of easily accessible code to see, and advice on how (and where) to start writing emulators.

The speaker is prolific developer Steven Goodwin who created the EMF emulator framework, and wrote 9 emulators during 2020. He is also a computer historian and part of the Centre for Computing History in Cambridge, England.

Since 2001, FOSDEM has been a ritualistic retreat for thousands of free and open source-minded developers.

Incorporating contributions gathered from across the FOSDEM community, this talk reflects on those past events and makes comment on the changes in technology, community, and the conference itself.

For those new to FOSDEM this talk provides a lively and interesting discussion on how FOSDEM began and has changed over the years, told through the eyes of one of its most loyal supporters, Steven Goodwin, who has attended them all and, since 2003, has been documenting his (mis-)adventures in "The FOSDEM Diaries."

And for those veterans, it provides a trip down memory lane and a solid reminder that we were all young once, and that we should help the current generation in the way we were helped all those years ago!

This talk gives real insight on how communities change over time, and how those new to the fold can break into an arena that can often appear as one clique of kranky old developers! Steve will also explain the origin of the FOSDEM drinking game ‘beermat buckeroo!’

In 1996 I read about György Ligeti’s mechanical music (notably Poème Symphonique) and started to explore the possibility of precisely timed music. Knowing that computers now allowed more programmatic control over sound than they did in 1962, when Ligeti's wrote his piece, I set about writing algorithms to generate MIDI files which ultimately became Symphony 1 in C# minor.

This talk covers the methods of generating MIDI files algorithmically in JavaScript, using the ones from the Symphony 1 as examples, showing how you can turn an abstract idea into music. It also discusses the additional processes and work necessary to turn a core idea into a full album. Along the way Steven touches on copyright, music trivia, geeky tech stuff, and the philosophy of music that can never be performed by humans.

The connection between Web and MIDI seems as likely as the joining of Garlic with Bread! Yet, we now have the power to create music from the web browser! Either by generating MIDI files for later manipulation, or as live instruments, WebMIDI provides us with the power to build some amazing online music applications.

In this short form talk, Steven will cover the internal details of the MIDI protocol, and its related file format, to show how music is represented by computers. This details both the recording and playback of music within the browser, and external application. It comes complete with live demos, synthesized sounds, and occasional music jokes!

Modern software needs inter-process communication. Often through DBus. But the state of the existing libraries are more perfunctory, than active. Consequently, the limits of these libraries become apparent when you go beyond a single thread, are limited to standard libraries, or use anything other than a classical event loop. In this talk we cover the journey, from the realisation of the problem, the guiding development tenets, to the implementation of a library that covers everything from the low-level protocol and high-level C++ interface.

We start with a breakdown on the whys and wherefores of the choices made, be it C++11 or C++14, to fork or not to fork existing code, or whether boost::asio should be used.

We continue with a discussion on the implementation details, such as the pitfalls in serial protocols, zero-length strings, non-aligned data, and the problems in C++ over C.

We end up with production-quality code, the politics of naming, and a question: will this be the final DBus library we need to write?

Background: D-Bus is an inter-process mechanism that allows communication between multiple programs running on the same machine. Asio is a cross-platform C++ library for network and low-level I/O programming. This talk covers how and why the former was implemented using the latter.

Home automation, like most fields in IoT, appears simple. A few lines of code, a couple of data points, and the job appears done. However, integrating computer code into a human life is not so simple. This talk highlights the personal issues involved in this area of IoT software development, and why the code you develop in the lab is often unsuitable for the home. "Simple" functionality like picking a random song, decreasing the volume, and playing a movie take on hidden complexities, that will be uncovered.

Steven Goodwin has lived in the automated home he's been building for the last 15 years. The Minerva project contains much of that code, but that's only the start. On one hand it needs some very specific configurations (e.g. which train stations do you use, so it can guestimate your arrival time, and therefore know when to control the heating or put the kettle on), and on the other it needs custom code to reflect your lifestyle. This latter point extends into the conversation of self-awareness of your own living patterns, and how they can be quantified.

He'll also comment on AI and service platforms (like Nest) which contain lessons for all IoT products.

In this session, Steven Goodwin will practically demonstrate the various "moving parts" necessary to build a WebRTC application, by creating one live on stage. It will provide a better understand of how WebRTC applications work under the hood, what the API provides, and serve as a guide as to what is (and what is not) possible for developers to deliver using WebRTC, and what other technologies are needed for a full-blown solution.

The talk covers:

• History and scope of WebRTC
• The connection flow
• API functionality (e.g. stats)
• Creating signalling
• Server-side work
• The browser problem

It also details the business logic cases of how to take a basic WebRTC app and then to build a purely online VoIP product, such as a call centre, thereby demonstrating the extra work required to work with WebRTC, beyond the promotional blurb.

In a few years time, it will be impossible to study the history of retro-computers since its software was either proprietary, closed-source, written in a now-obsolete language, or encumbered by software “protection” to prevent copying. Furthermore, the hardware upon which it ran is dying, and the cassette tapes holding the software are physically disintegrating.

This talk covers a ten-point plan outlining the primary issues in digital archaeology. It covers the methods necessary to preserve our computing legacy, the use of emulation, and how open source can help with this endeavour. We end with an overview of some projects that will inspire you, and help you preserve your own slice of history!

Many people learn to code because they want to write a computer game. More often than not, they want to re-write their favourite game, but making it a little easier! Unfortunately the gap between a personal project, open source game, and professional offering is substantial, with the lack of polish obvious at every turn. In this talk, Steven Goodwin, a game developer of 20 years standing (and 3 books on the subject), dissects each discipline (art, music, writing, and code) to explain where polish should be added and why it’s so rare to see open source games as effective as their commercial counterparts.

In theory, an open source game should be much better than a commercial version. After all, as a group, we have more resources at our disposal, over more time, in order to build more assets, write more code, and fix more bugs. But that’s rarely true. Our efforts look rushed and amateur in comparison. After a brief discussion on the meta-problems of open source game development we look at each discipline and demonstrate what needs to be written to improve the game, details of simple, but effective, visual improvements that can be done with very little effort, and how certain functionality can be implemented in order to make a game shine. The talk also includes a checklist of features implemented in Space Bounce that, while you might not have noticed them, you would certainly realize if they weren’t there.

The session will look at the issues developers run into when developing their own WebRTC applications. It looks at the problematic elements in the API, the compatibility problems between browsers, missing infrastructure, and even the human element. All in all, it's a demonstration that a true WebRTC application can't be built in a snap.

Last year, I presented a talk explaining how easy it is to build a WebRTC application.

This year, I'll tell you the truth!

It will cover both the ideas and code necessary to move your basic application into something that resembles production-ready.

In this session, Steven Goodwin will practically demonstrate the various "moving parts" necessary to build a WebRTC application, by creating one live on stage.

Although the marketing hype suggests you can build a 'Skype in a browser' in an afternoon, it doesn't really tell you how. Or where the problems will occur. This talk will cover both the client and server-side code necessary. Targeted at developers of all levels who are unfamiliar with webRTC, it will provide a better understand of how WebRTC applications work under the hood, what the API provides, and serve as a guide as to what is (and what is not) possible for the developers to deliver.

Digital cameras provide almost every feature you could want. But if they don't, you are forced to upgrade or go without. CHDK is a project which allows you to program new functionality to the majority of Canon cameras, in either C, Lua, or Basic. The talk features background on the project, code, tools, and the methods of compiling and introducing a new firmware into the camera.

Over the course of 1 hour, Steven Goodwin will guide the audience through the entire process of taking a normal (proprietary) camera and converting it into an open source version by installing custom firmware on it. He will then cover some of the features available (such as the on-device scripting language) and continue by explaining how to build and debug your own functionality. Starting with simple grids, continuing with games, and time-lapse code. And ending with a fully recompiled firmware running on the device.

This talk introduces a brand new web server - Ultra. With a binary at just 51K it's small, fast, and encompasses an all-in-memory web server with an in-built NoSQL datastore, a data processing language, SSI, multiple configurations, and logging. If you want to learn basic networking programming, its source is small enough for you to learn from. The talk covers the basic architecture and approach in keeping a small footprint, and breaks down the source into easily understandable blocks.

The talk covers the history and development of a unique project - one that tells a classic open source story about a developer scratching an itch, and solving a problem he didn't have! It covers the code from 47 lines of C, to 1500 of C++. It also details how the processing language was governed by code re-use, and how the data store uses convention over configuration to work efficiently. It's one of the few projects that is small enough to do serious work, but small enough to be explained line-by-line in a talk! (Although it won't be that direct!)

Generating music from an Arduino usually needs a shield. And shields cost money. This talk introduces a project that makes it free and easy to play sound without a shield, nor a knowledge of musical theory.

We shall introduce a number of projects that make the Arduino make noises, other than the squeaks of the example code. This includes the new library, Armstrong, which supports various methods of playing music, along with MIDI functionality, all from a vanilla Arduino.