|★ AMSTRAD CPC ★ SOFTOGRAPHIE ★ CHRIS HALL (LOCOMOTIVE SOFTWARE) ★|
|Chris Hall (Locomotive Software)||Games - Auteurs||Locomotive Software: Full Stream Ahead||Locomotive Software|
David Kelly talks to Chris Hall from Locomotive Software
The Amstrad CPC464 is the first home computer Chris Hall has had a hand in designing.
Amstrad began work on their machine almost two years ago. Unfortunately, by August last year it became apparent that there were difficulties with both original system software and the hardware.
So. Amstrad had a keyboard and a case together with a partly finished hardware design based around the 6502 processor. And not much else.
MEJ Electronics was brought in by Amstrad to sort out the hardware design. They, in turn, get in touch with Chris Hall's software house Locomotive (both companies are composed of former Data Recall employees) and both decided to start again from scratch.
The original design was ditched entirely and a new one was created, based around the Z80 processor. This was code named 'Arnold' and became the Amstrad CPC64.
The Z80 suited Amstrad because it gave the machine the possibility of running business software using the CP/M disc system. And it helped Locomotive, which already had experience of the Z80 chip.
Locomotive is a new company set up to develop system software. "We don't do applications or games and we are very interested in speed — our Basic is fast!
"We literally first heard of the Arnold last August and the three of us — Richard Clayton, Bruce Godden and myself — had a hectic few months." Locomotive actually started writing in September last year and had to work blind for six weeks.
Locomotive and MEJ worked closely on the design. "We had an idea of what price the machine was going to be sold for — which set the parameters for the hardware. We couldn't knock out something 'noddy'. On the other hand, we didn't have time to produce a QL from scratch.
"Before we started we looked at the BBC machine, because at that time we saw it as a market leader, and we also had a look at the Commodore 64.
"We already had our own Basic interpreter for a CP/M80/CP/M86 MSDOS system and the decision to use the Z80 in the Amstrad was driven by the fact that we couldn't possibly have written both the firmware and the Basic in three months.
"There were a number of constraints which came from Amstrad's original thinking — the casing and keyboard and the inclusion of a cassette recorder and monitor. That was all settled and had to be taken on.
"The monitor is a pixel VDU — the simplest sort. When you do the sums you find the Amstrad has to be the way it is. It is a straightforward 16K of memory for the display — two colours at 640 x 200. four colours at 320 x 200 or 16 colours at 160 x 200. You can 'suck' 16K from Ram just fast enough to refresh the screen.
"The sound uses the Gl chip — AY-3-8912. If you look at the number of sound chips there aren't very many and the Gl has three channels.
"A Centronics port seemed appropriate, for a printer. Having the built-in cassette player made life easier because its electronics are a bit special.
"Add in a custom gate array and there you have the machine."
The main thrust behind the firmware was to make it as open as possible for other languages and software. "We tried to keep a firm distinction between the firmware and the Basic. The Basic simply takes the commands keyed in, packs them up and passes them to the firmware. The HiSoft Pascal written for the machine, for example. has all the graphics and sound facilities that the Basic does."
Nearly all the features of the machine are implemented in the firmware and Basic. "We wanted to avoid 'magic numbers' in the Basic. The Commodore machine has some very good hardware features but, without Simons' Basic, you have to spend your time 'poking' away with magic numbers. Similarly, we knew we wanted to avoid confusing VDU19-type commands that the BBC suffers from.
"The Arnold is intended to be as easy to program as possible. After all, even an experienced programmer, faced with a series of Pokes to various machine-code addresses written some time ago, may have trouble working out what is going on."
The firmware is written as a series of sub-routines. There are no variable interfaces — no system variables to Poke around with. Everything is written to use routines. For example, the Sound command in Basic picks up the key commands, organises the parameters and picks up the machine-code command Sound Cue in the firmware. All of the machine code subroutines in the firmware are documented. Amsoft — Amstrad's computer division — will be publishing in full the firmware documentation.
"Anybody writing software for the Amstrad should never need to go near the hardware. The only possible point would be if you want particularly fast and flashy screen routines. In this case we decided that it wasn't appropriate to provide generalised routines."
Software houses writing for the machine have been asked by Amsoft to write using the firmware provided, rather than reinventing the wheel.
One interesting feature of the CPC464 is its use of 'windows'. "We wanted the machine to have separate text and graphics windows." The way it works is to define an area of the screen as, say, a graphics window and then anything plotted outside the area of the window is 'clipped' and not displayed.
"We thought that one text window was a bit mean so we have got eight. The text windows are tied up with the eight text streams. Each stream has its own window, its own cursor, and its own Pen and Paper commands. "You select a stream which you can then write to — and it will then plonk it out in that stream."
Another feature of the machine is its real-time controls. At a machine code level the firmware incorporates a number of hardware interrupts which, linked to an internal timer, can be used to trigger a sub-routine. Frame fly-backs from the screen can also be used to 'kick' a routine.
At the level of Basic two commands are provided: After (After n Gosub) which jumps to the subroutine after n where n is a time in 1 /50sec; and Every (Every n Gosub) which jumps to the subroutine every n — and gives a periodic effect.
Similar mechanisms are also provided for the sound commands. Sound management is all done from the interrupt path so, unlike the Dragon, the processor can carry on processing when a sound is being generated.
With something around 12 weeks to complete the software on the Amstrad, the Locomotive team had to work flat out. The majority of the Basic was already written, but it was rearranged and some new features were added. The firmware was written piecemeal in modules. Each of the five modules (1 sound, 3 screen, 1 keyboard) were fully tested before going on to the next. "We wrote them in a sensible order so that if the fundamental routines took longer to write than we expected then at least we had written them by the time we had to deliver the software to Amstrad!
"We handed, over our finished software 14 weeks ago and the machines at the launch had finished Roms in them."
POPULAR COMPUTING WEEKLY (05-1984)