WACCI 138 Index - Home Page www.wacci.org.uk

Genesis: CPC Coding from First Principles

Richard Fairhurst begins a new series on designing and writing a major CPC program

Part 1: Thinking Aloud

I've got a project, and it's not a very sensible one. You may have read, here and there, about Mark Rison's brainchild, CPC/IP. CPC/IP is a whizzy piece of operating system software that gives your CPC the ability to access the Internet.
  It doesn't actually access the Internet itself, though. You'd need specially-written e-mail, newsreading, or web browsing software before you could do anything useful with it. And useful isn't quite the word, because no-one, frankly, is going to choose the CPC for all their Internet needs.
  But it's great fun. I think CPC/IP is a wonderfully hare-brained, futile, splendid project, and I'd like all Mark's effort to have been worthwhile. There's little point writing an e-mail program ("Ooh look, it's sent an e-mail. Isn't that exciting. I think I'll go and watch the football"), which leaves a newsreader or web browser. I've always enjoyed writing huge, over-ambitious application programs, and did so with RoutePlanner and PowerPage 64. Therefore I've decided to write a browser.

You cannot be series

Over the next few issues of WACCI, I'll be chronicling my attempts to do so. I'm not promising I'll succeed. I'm not promising I won't get frustrated halfway through, and start work on something else (BTL, perhaps). But hopefully the program will feed off the series, and vice versa. Some of it will be a bit techy: some of it won't: but I hope you'll all be able to follow the thrust of things.
  So where do you start? Each programmer has their own approach. Some plunge headlong into the difficult bit of the program, keeping all their plans in their head, just to prove the principle. Some write a 30-page exposition listing objectives, challenges, opportunities and the like. Some sketch the program out on a flowchart.
  I do two things. Firstly, I work out the user interface - how the program will interact with the person using it. I conjure up the screen layout, what keypresses you'll use, whether there'll be a windows-and-pointer system, what the menus will say. This is because software should be designed with the user in mind, rather than doing it the other way round, expecting the user to fit in with the whims of the designer. (It's also because I enjoy this sort of stuff.)
  Secondly, I work out the data structures - how the computer will store all the relevant information in memory. In RoutePlanner, for example, I had to work out how to store details of 2000 placenames, their location in the country, and all their road connections. Typical information would be:

Name:	 	UPPINGHAM
Settlement:	Town
Grid reference: SK301296
Roads:
A6003 to Oakham, 6 miles
A6003 to Corby, 8 miles
A47 to Leicester, 20 miles
A47 to Peterborough, 23 miles

There were going to be 2000 of these. I decided to store them in order from south to north, just to make drawing the map easier. (If you want to see the map of roads around Birmingham, for example, it saves time if the program doesn't have to look through all 2000 records to find out details of nearby places, and can just concentrate on those in a certain range.)
  From then on, it was all fairly straightforward. The challenge was to squeeze the maximum amount of data into the smallest space possible, so that most of Britain could be held in the 6128's extra 64k memory.
  The grid references were converted to simple numeric co-ordinates, measured in eighths of a mile. As a result, each position could be stored in just four bytes.
  The town names would only contain the letters from A to Z, apostrophes, hyphens, and spaces. That makes 29 characters. You can fit that into six bits - representing a number from 0 to 31 - whereas a character is usually stored in one byte, or eight bits. Bingo! A 25% saving.
  I wanted to fit the road number into two bytes, or 16 bits. You can store a number from 0 to 8191 in 13 bits, and by one of those happy coincidences, you don't tend to get many road numbers above 8191 (because 8 and 9 numbers are in Scotland, and there are so few main roads in the Highlands that you rarely need to venture outside three digit numberings). So that left three bits in which I could record the road type: motorway, dual carriageway A-road, single-carriageway A-road, and so on.
  Each place had a record number: 0 was Land's End, right up to 2000 or thereabouts for John O'Groats. So I used this as the destination for each road. And the distance was just stored as a number in miles. Total: five bytes for each road.
  That's how RoutePlanner worked. Let's have a go at applying the same principles to the web browser.

The user experience

This is all about how the user will relate to the program. A big part of this is the name. Our web browser is going to be called Heloise: it has mythical connotations fitting for such a blue-sky project, it has affinity with 'helium' - hence floating through air - hence communications 'through the ether'. It's romantic and totally impractical, because it's a romantic and impractical project. (I'm going to get into Pseuds' Corner at this rate.) And I like the name.
  Much of the user interface comes with the territory. It's a web browser: so the essential component is a page which you can scroll up and down. It could look like Internet Explorer or Netscape, where you have buttons at the top for the essential tools, and a scrollbar on the right to move up and down through the page. But these are designed for computers with mice. Most CPC users don't have one, making using a pointer a bit of a pain in the neck.
  There's also the compelling technical factor that CPCs can scroll the whole screen faster than just part of it. So by not including a button bar at the top, we're making our whole program move faster and feel much more responsive. This is good.
  Instead, all the control will be by the keyboard. Mostly, it will be using the cursor keys: up and down to move up and down the page, left and right to choose the underlined hyperlinks which will take you to another page, and ENTER (or COPY, for 464 and 664 users) to select one of these links.
  ESCape usually gets you out of what you're currently doing, so I'm going to use that when you want to stop looking at the current set of pages and enter a new web address from somewhere else on the Internet. And the main keys will be used, sensibly enough, when you have to type text into a web page - in a search engine, for example.

What will you see?

There is no way, sadly, that we are going to be able to present a full web-browsing experience on a CPC.
  For starters, it'll have to be MODE 2 - which means black and white. MODE 1 text is just too fat for your average web page. And most significantly, there's no chance of graphics.
  This is a real limitation and will severely limit the 'authenticity' of the browser. I wish it wasn't necessary. But just to decode GIFs - the standard file format used for illustrations on the web - takes up huge chunks of memory and processor time, requires some complicated coding, and poses problems of how you show a typically 256-colour image on a 2-colour screen. JPEGs, the file format used for photographs, are even more complex and effectively outside the reach of a CPC.
  Saying that the site will be text-only makes the coding much easier. In particular, our web pages can be just like Protext documents - text starts at the top, flows down the page in one column, and finishes at the bottom. You don't have to worry about flowing it around pictures on the right, inserting little graphics for bullet points, or the like.
  Further to this, all the text will be one size - the standard CPC font. We can have bold and italic text fairly easily. But there won't be any 'tables', the useful but complex web tool typically used for multi-column layouts.
  Plenty of limitations, as you can see. Nonetheless, all the words, and the links, will be reproduced as they should be. It'll still be a web browser, just a rather simple one, more akin to the very first ones produced for PCs.

Structured thinking

That's the user interface. Next, we need to work out the data structure.
  There's only one significant amount of data we need to deal with: the web page text itself. As you may or may not know, web pages are written in a language called HTML (for Hyper-Text Markup Language, but you don't need to know that). This is just like a word-processor document, except that special instructions - like bold and italics - are enclosed in angle brackets. So <B> is bold, <I> is italics, and so on. These instructions are called 'tags'.
  There are two wrinkles to this. One is that paragraph and line breaks are also communicated by using tags. <P> starts a new paragraph; <BR> puts a line break within the current paragraph. If you write:

This is the CPC's
Brand
New
web browser...
And ain't it grand?

in an HTML document, but don't include any <P> or <BR> TAGS, a browser will display it as:

This is the CPC's Brand New web browser... and ain't it grand?

You get the idea.
  The other wrinkle is that you have 'on' and 'off' tags. One turns the effect on; another turns it off. You can tell an 'off' tag by the forward slash ('/') at the start of it. To enclose a word in bold, we'd do something like this:

This is the <B>smashing</B> CPC web browser.

Essentially, HTML is a very simple language. And a CPC can easily work out that, if it encounters <B>, all the text from now on should be displayed in bold. So perhaps we don't need a data structure. Perhaps we can just load the HTML document into memory verbatim - the same way that you load a Protext document into memory, except that we load it from the Internet (via CPC/IP) rather from disc.

Half a block

But we're not going to do that.
  Two reasons. One is that HTML is simple, but it's not always efficient. For example, you can put text in a different font. One way to do this is by writing

<FONT FACE="arial,helvetica,geneva,sans serif">

Fine. But some automated web-page editing programs do this at the start of every paragraph. This is a really good way to make the document stupidly big, and hence fill up the CPC's memory after about two lines. We need to filter these out.
  The second reason is more important. Any web browser allows you to scroll up and down the page at will, rather than just reading it from top to bottom. This is crucial. There might be a hyperlink halfway down the page that takes you to another, related site when you click on it - but you don't want to go there until you've read down to the bottom of the current page. So you need to scroll back up afterwards.
  As we've seen, the start and end of a paragraph are marked by <P> (or, if you like, you can start it with <P> and end it with </P>). If we're scrolling down the page, this doesn't present any problems. When we come to a new paragraph, we start a new line, and print the first 80 characters of the paragraph. Next time the user presses the down cursor key, we print the next 80 characters - and so on until the end. The final line will contain whatever's left, which might not be 80 characters.
  It doesn't work like that if we're scrolling up, because we don't know how many characters are in the last line. (If you don't see what I mean, look at the previous paragraph on this page. All the lines are the same length, except the last one.) If we assume it's 80, that will leave us an odd number of characters when we scroll back up to the top line of the paragraph.

The parser

It would be loads easier if HTML text was organised into 80-character lines, rather than paragraphs. So let's do it like that.
  What we need is a 'parser'. This is a cunning bit of programming that reads in the HTML page from CPC/IP; and stores it in memory how we want it. It'll read <B>, for example, and store it in memory as our special code for 'turn bold on'. It'll read in 80 characters from a paragraph, and then insert our special code to say 'the line finishes here'.
  In effect, this divides our web browser into two distinct sections.

  1. The parser. Reads in the web page from CPC/IP, and records it in memory how we want it. When there's no more page to read, we then move onto:
  2. The page display routine - the real browsing bit. This puts the page on the screen, gets your keypresses, and reacts to them.

There was a time

It makes sense to write part 2 first (no, really, it does). This is partly because the parser's role is to feed the page display routine, not the other way around. So by writing the page display routine first, we get a clear idea of what we want the parser to produce.
  It's also because we can test the page display routine without the parser. We just dummy up a web page in our special format - ready-parsed, if you like - and see what the page display routine makes of it. Testing the parser without the page display routine is a bit more esoteric. You could look in memory to see if it's stored the page correctly, but that would be very boring.
  Next issue, we'll discuss exactly how our data structure is going to function (which I've worked out already), and start writing the page display routine (which I haven't).

WACCI 138 Index - Home Page www.wacci.org.uk