An Audience With BBC BASIC
The following article was originally written back in 2008 for Archive Magazine, a subscription magazine dedicated to the RISC OS operating system for which I write a monthly column on free software. Although it never made the pages of Archive, a revised version finally appeared in the Wakefield RISC OS Computer Club’s monthly newsletter, The WROCC, in July 2010 and it is this (with some minor corrections) that appears below.
An Audience with BBC BASIC
As a few WROCC members are probably aware, I spend a fair bit of my spare time working backstage with a couple of amateur theatre companies in Leeds. It’s a sufficiently different hobby from RISC OS that, even with the increasing use of technology behind the scenes in the theatre, the two very seldom come into contact.
A rare occasion where they did meet came back in 2008, when Leeds Arts Centre decided to stage a production of Patrick Marber’s Closer in the city’s Carriageworks theatre. Written in 1997, the play is set in the London of the mid-90s and looks at the relationships between four young people living in the capital. Although it won several awards at the time, many people are likely to be more familiar with the film of the same name which came out in 2004; starring Jude Law, Clive Owen, Natalie Portman and Julia Roberts, the screenplay was also written by Marber.
In addition to providing a slightly unusual application for BBC Basic (and very nearly for RISC OS, too), my involvement with the production showed me that it really isn’t that hard to write multi-platform software which can be run on RISC OS, Windows and even Linux. In fact, it isn’t even the preserve of the more predictable languages such as C – BBC Basic is itself more than capable.
Online chat
I first read Closer in 2007, and it immediately caught my interest. As well as having a good script, it contains something slightly unusual: a scene performed in an online chatroom. When the play was written in the late 90s, the internet was a new phenomenon which was starting to catch the imagination of the public, and there was a fair bit of media interest in technologies such as IRC. Even back then, there were already concerns that on the internet, people may not be exactly who they claimed to be.
Closer makes use of this by placing an early scene in a London-based chatroom. Two of the characters sit at their computers, in different locations, and have a long – and somewhat explicit – conversation about sex. The audience get to watch, fully aware that one of them is very definitely not the person that his online identity suggests. The repercussions from this continue throughout the performance.
What makes the scene work is the fact that it is conducted without any spoken dialogue between the two characters. The stage directions require that everything they discuss is typed on their keyboards and read from their computer screens, which makes the fact that they are not directly in contact much more believable. For the benefit of the audience, the text appears on a large screen above the stage so that they can follow the action.
As soon as I read the script, I have to admit that I found myself thinking that making the chatroom scene work could be an interesting challenge. As a result, when I was approached in the summer of 2008 and asked if I would be willing to take on the technical aspects of the production, I immediately said “Yes”. On subsequent reflection – and after discussions with the director – it became apparent that it may not be a simple task.
The requirements
The main requirement for the chatroom scene was that the dialogue between the two characters must appear on a large screen, in something approximating real time. The text needed to appear as if it were being typed by the actors (who would have keyboards with them): one letter at a time, and at a convincing speed but without appearing too regular. Once the screen was full, existing lines would need to scroll up out of the way to make space for what was following.
In most real-world chatroom systems, each person types their text into an area at the bottom of their screen, and it appears to all the other participants of the conversation only when complete. Since we just had a single screen to work with, it was decided that a certain amount of artistic license could be applied and that both characters would type directly into the main window. While not quite true to life, it allowed for better use of the area available and produced a less cluttered result.
It was clear that the text would need to be pre-recorded and played back – trying to type it live during each performance would be too difficult. Since it is never possible to guarantee timings in live theatre – particularly as the scene was likely to receive laughs from the audience which would need to be worked around – some means of keeping the text synchronised with the action on stage was required. The provisional solution was to break the text into short blocks and have the playback pause at the end of each until the person driving the system restarted it again.
By now it had become very apparent that this wasn’t a job for Powerpoint, despite it being the favourite tool for a lot of simple projection work in the theatre. Further investigation failed to turn up any off-the-shelf software to do what we required, and so – slightly reluctantly, given the implications of getting it wrong – I concluded that some custom software would need to be written.
The first implementation
The first step was to get the text from the script into the computer. To achieve this, I wrote a short Basic program on my Iyonix which recorded text typed at the keyboard, logging each keypress and noting the lengths of the time intervals between them. Armed with this, I spent an afternoon typing the chatroom scene in from the script and correcting my mistakes; I now had a lot of data in a text file, and just needed to do something with it.
That initial something was again done using Basic on the Iyonix. With the aid of the RISC OS outline font manager, it was a relatively simple task to print the contents of the text file back on to screen. The information which I had recorded on the delays between keypresses allowed the individual letters to be printed back at my typing speed, and since I was working full-screen, things like scrolling the page could be achieved easily using Basic. It made a pleasant return to the pre-wimp days of programming.
Mindful that the display would eventually need to be ‘dressed up’, I made sure that the scrolling area in which the text appeared could be defined in terms of an invisible rectangle on screen. Although I was at present working with a plain white background, this flexibility would make it possible to overlay everything on to a graphical image at some point in the future. I also made sure that things like fonts, text sizes, line spacings, margins and colours could easily be changed ‘on the fly’.
With the bare bones of the chatroom now working, the basic idea had been proven and it was necessary to start thinking about more practical details. The main question at this point was how the system would work on stage: two actors would have to interact with the computer, and the audience would need to be convinced that it was really them – not me – typing the text.
The set design had the characters sitting near the front of the stage facing the audience, with the projection screen – on which the text would be shown – located behind and above them. Since this would make it impossible for them to see what was happening, two 17" flat-screen monitors were to be placed in front of the actors to relay the text to them. Technically, the easiest way to achieve this would be to show the same image on all three screens; some rough calculations of font sizes, screen dimensions and viewing distances showed that this ought to be viable, so we went with it. The main advantage was that we could use a VGA splitter to feed the output from a laptop to both the monitors and the projector – the software would only have to create one on-screen image.
The final problem was how to keep the cast and the technology synchronised over the course of the scene. At first the plan had been for the actors to watch their monitors and keep in time with the display, but in practice this proved too awkward. What worked turned out to be less complicated: both performers learned their ‘lines’ as normal, and ran the scene at their own pace. Since they typed each line on their dummy keyboards in its entirety (albeit not letter-perfectly), the timings were repeatable and the speed of the recording could be adjusted so that it matched. The problem of keeping the text in step then fell to the stage-crew operating the laptop, using the programmed pauses to start each new section of text as the two actors started to ‘type’ it.
Leaving RISC OS behind
With all of the details decided, I was free to start work on the final software – but one question still needed to be answered first. So far, everything had been created in BBC Basic on an Iyonix, but I had some reservations. Not only did I not have a laptop running RISC OS, but neither did anyone else at the theatre. I could have used a desktop machine, but this would still have left no backup in the event of equipment failure – sadly, RISC OS machines (or even machines running Virtual Acorn) are not so common that they can easily be found at the drop of a hat.
Since the chatroom scene would be so critical to the production as a whole, we needed a viable backup plan. In practice, this more or less dictated that the system would have to run on Windows-based hardware so that a replacement could quickly and easily be found should the worst happen. In the event, we always had two laptops available, and complete copies of the software and data were also left about on CDs to allow a quick and easy install on any other machine if needed.
At first glance, this requirement seemed to demand that the software be re-written from scratch in a language more suited to cross-platform operation. However, there exists a version of BBC Basic that runs on Windows systems from ’95 to Windows 7. BBC Basic for Windows (or BB4W as it’s known to its friends) is a descendent of the version of BBC Basic that was released for the Sinclair Z88. It’s developed by Richard Russell, who was involved with the original specification of the BBC Micro from the BBC’s end back in the early 1980s.
Although the two languages share a common heritage, BB4W was written independently from Acorn’s versions and over the years it has diverged somewhat; in particular, it has gained a number of advanced features such as structures, which will be familiar to C programmers. Despite their differences, BB4W is almost entirely compatible with the most recent versions of Basic V on both RISC OS 5 and RISC OS 6 – and it was the work of a few seconds to copy the code I had written on the Iyonix over to the PC and drop it into BB4W’s window. Despite a nagging feeling that I should be using a ‘proper’ language, I decided to stick with Basic for a while.
Cross-platform compatibility
There was still one difficulty to overcome, however. While the syntax
and keywords used by the two versions of Basic may be compatible, this
certainly isn’t true of the underlying operating systems. Both
versions of Basic allow OS features to be accessed via the SYS command,
and the routines made available this way are often very different. So
whilst everything done in Basic worked without modification (including
any graphics produced via commands like RECTANGLE,
PLOT and so on), other things were more problematic.
The solution, in the end, proved to be easier than I had at first thought. As one might expect, Windows has equivalent facilities for plotting fonts on screen, displaying bitmap images such as JPEGs, and so on; the only problem was converting to these from the RISC OS varieties. Fortunately, the RISC OS calls are often fairly long-winded, so I had already packaged them up into neat functions and procedures to simplify my code. As a result, all I had to do was replace these procedure definitions with ones containing the equivalent Windows calls. An example of the code used is given in the box below.
By separating out all of the OS-specific code into separate files,
which could be fetched appropriately using Basic’s
LIBRARY command, a piece of cross-platform software that was
as happy on Windows XP and Vista as it was on RISC OS quickly became
a reality. While such an approach will be most practical for programs
that can run full-screen outside of the desktop (and hence avoid the
complexities of multitasking on RISC OS), it was still a little
surprising how easy it was to achieve.
Finishing touches
With the basic system now working on both Windows and RISC OS, it was time to start adding the finishing touches to the code. We decided to present the chatroom on screen as a stylised application window using vaguely Windows ‘98-esque borders in keeping with the period that the play was set in; grabbed from a real Windows XP machine with the ‘Windows Classic’ theme applied, the finished article was heavily tweaked in The GIMP (an open-source photo editing package for Windows and Linux, a little like PhotoDesk) before being turned into a JPEG that was used as a backdrop behind the text. By adjusting the screen rectangle in which the text display and scrolling took place to match the window’s work area, it gave the impression that the contents were scrolling normally.
Of course, the chatroom was only one scene out of ten in the production, and as a result, it needed to be integrated into the rest of the performance. The overall set design was best described as ‘minimal’, and it was decided that for the other scenes, a short descriptive title would be projected on to the screen to identify the location: for example, “Hospital”, “Restaurant”, and so on. Before the performance and during the interval, the logo used in the publicity was to be shown instead. To achieve this, a primitive powerpoint-style slideshow system was written to allow simple slides – JPEG images, short lines of text and, of course, the chatroom itself – to be shown in sequence, with timed cross-fades between them.
To make the cross-fades work, two screen banks were used: a technique which will be familiar to RISC OS programmers from the early days. With the current slide already shown on screen, graphics output was switched to a second, hidden screen bank and the next slide created using all the normal methods. Once complete, the new slide was grabbed as a sprite (or the Windows equivalent), graphics output was switched back to the visible screen bank, and the sprite faded in over what was already there using alpha-blending. Although by this stage I was only working on the Windows version, support for alpha-channels on sprites in recent versions of RISC OS should make the same effect easy to achieve on our machines.
The end result
After several months of planning and preparation, the whole system was set up on stage at the Carriageworks in Leeds during the last week of October 2008. The final equipment list consisted of two flatscreen monitors and a video projector, all fed, via a four-way VGA splitter and over 100 meters of monitor cable (several meters of which were kindly loaned to us by WROCC), from a laptop running Windows Vista and the latest version of BBC Basic for Windows.
To my slight surprise, everything worked first time and two rehearsals and four performances passed uneventfully. Having started out (from ignorance) with some reservations, it was pleasing to discover that a system written in BBC Basic could produce such an effective result in a multi-media age. The software could equally well have run on a modern RISC OS machine and, had it not been for the need to be using easily available and quickly replaceable hardware, it probably would have done so.
It would also be fair to say that I was left impressed by my first serious encounter with BB4W. Although I had bought my copy about a year previously, I had not really investigated it prior to using it for Closer. While I would still tend to recommend that anyone familiar with a language such as C should look at other development environments as well, BB4W is easily capable of writing serious applications on Windows (or Linux, if used under Wine). For anyone whose experience is limited to BBC Basic on RISC OS, the language is well worth a look should the need to work on other systems arise.
The feedback we got from our audiences during the week was positive, and it was pleasing to hear many people specifically comment on the chatroom scene – although I doubt anyone realised that the software had been developed using the programming language that originated on the BBC Micro (and that certainly wasn’t a subject I was going to raise in the bar after performances). As this article was written in a week where the BBC was promoting the recovery of colour versions of Dad’s Army from black and white film, which was done using software written in BB4W, it’s interesting for us RISC OS users to ponder where else our favourite programming language may also still be performing a public – if invisible – role.
Cross-platform code
Although BBC Basic itself is the same on RISC OS and Windows, the
underlying operating systems are very different. Code which limits itself
to using just the facilities offered by Basic on RISC OS (that is:
no star-commands or OSCLI, no SYS calls and no
BB4W extensions) will work on either platform, but for other code it is a
good idea to abstract the OS-specific bits out into separate functions in
their own library. This way, writing multi-platform code becomes more
manageable.
As an example, I needed to be able to find the width of a piece of
text in the current font, in terms of Basic’s graphics units.
Instead of directly accessing the OS calls, I used a function that I
called FNget_text_width(text$) – as long as this was
defined correctly for the OS being used, the rest of the code would work
as normal.
On RISC OS, the function accessed the Font Manager, and was defined thus:
DEF FNget_text_width(text$)
LOCAL x%,y%
SYS “Font_ScanString”,font_handle%,text$,&100,&7FFFFFFF,&7FFFFFFF TO ,,,x%,y%
SYS “Font_ConverttoOS”,,x%,y% TO ,x%,y%
=x%Moving to Windows, it had to be re-defined to talk to Windows’ equivalent of the Font Manager, but so long as it still returned its result in terms of Basic’s graphics units, any code that called it could remain unchanged:
DEF FNget_text_width(text$)
LOCAL size{}
DIM size{cx%,cy%}
SYS “GetTextExtentPoint32”,@memhdc%,text$,LEN(text$),size{}
=size.cx%*2As an aside, the Windows version of the function makes use of
BB4W’s structures: size{} is a structure containing
two integer variables, cx% and cy%, which are
accessed as size.cx% and size.cy%. The concept,
and much of the syntax, should be familiar to anyone who uses C. The
other bits of the call, including things like the @memhdc%,
are all explained clearly in the BB4W documentation and online
programmers’ guides – and turn out in practice to be much
more straightforward than they look.
