The Maynooth University Micro Mapping System (MUMMS) was my most ambitious (and, in retrospect, foolhardy) programming project, as it ended up being not far short of a fully fledged vector-mode Geographical Information System written for a BBC Micro using a mixture of Basic and Assembly language. The program was started in 1983 and it was revised and expanded throughout most of the 1980s.
MUMMS was designed to be as user friendly as possible. WIMP technology (Windows Icons Menus and Pointers) had not yet made an impact, so the approach adopted in writing MUMMS was to engage the user in a question and answer dialogue. Many of the questions took the form of a menu with several choices. The user's response would determine which questions would be asked next. When MUMMS had sufficient information to carry out a particular operation it would do the requested task and then resume the question and answer dialogue. Answers were checked wherever possible. If detected, errors were flagged and the user was invited to answer the question again. The error checking procedures were one of the strengths of the program, making it virtually impossible to do anything stupid. However, on the odd occasion, a student would come up with a totally unanticipated error which might make the program crash. This produced a rather intimidating 'Catastrophic Collapse' screen, containing details of the problem (which could be used to trap future occurrences), but in most instances no permanent damage was done and the user could often resume provided they were more careful about how they answered that particular question the next time.
When users completed one set of questions they would be passed on to a new screen with different questions. These screens were organised as a hierarchical branching tree. Each screen contained a prominent title which was colour coded to help users keep track of where there were. The program had three major branches (plus one or two minor branches containing ancillary utility options) each of which was reflected by a different colour surround to the title (red, green or yellow). The text in the title was also colour coded to reflect the 'level' of the screen in the hierarchy. Each screen was also numbered (e.g. '1.3.2' to indicate the second option in the third option of the first branch).
The three main branches were for processing locational data, processing attribute data, and combining the locational and attribute data to draw a thematic map.
The data structures used for the locational data were extremely crude. MUMMS provided reasonably extensive editing tools, but it did not provide any topological checks. The onus was on the user to ensure that there were no gaps in the borders of polygons. This was basically done by visual inspection, although there was an option which allowed users to flood fill each polygon with colour to see if it overflowed into an adjoining polygon. The boundaries were input and edited in vector mode, but the completed polygons were saved as a raster image to allow maps to be redrawn as speedily as possible.
The attribute data options were actually better than in many modern GIS programs. Users were able to enter their attribute data into a data matrix in which the rows were automatically linked to polygons in the locational data. Options were provided to test the data for extreme values (indicating possible errors) and the values in selected cells could be easily changed. Options were also provided for manipulating the data - e.g. to divide one set of counts by another to create a rate. MUMMS provided quite a few options for creating new variables, including one to calculate regression residuals. There was also an option for counting the number of cases in each area using the data in a file containing information about individuals. The type of data in each column in the data matrix was identified as counts, rates, densities, means, etc. MUMMS would not allow choropleth maps to be drawn using inappropriate data types (e.g. counts) unless the user specifically insisted that they knew what they were doing.
The third major branch provided options to combine the locational and attribute data to draw thematic maps. MUMMS was largely limited to choropleth maps and did not facilitate the overlay of different layers. However, it provided a comprehensive set of options for determining the class intervals. The frequency distribution of the attribute data could be displayed as a histogram - a very useful feature which is strangely missing from many more sophisticated GIS programs. The maps were drawn by flood filling the polygons representing each area with an appropriate tone - generally on a red-orange-yellow scale. MUMMS was primarily intended as an interactive analytical tool rather than a cartographic package, so the quality of the hard copy output left a lot to be desired. This took the form of a black and white screen dump on a dot matrix printer.
The coloured screen display was nothing to write home about either. The BBC Micro had very limited graphics capabilities compared with a modern PC. The maximum screen resolution (Mode 0) was 640 x 256 and that was with only two colours (normally black and white). If you wanted four colours - the minimum with which you could create six or so distinguishable coloured tones on a map by interleaving different coloured pixels - the maximum screen resolution (Mode 1) was reduced to 320 x 256. Another problem was that Mode 0 and Mode 1 each used up most of the available memory, leaving only 5.5 Kilobytes free for the program code plus the data. If you consider that a standard 3.5 inch floppy disc normally contains almost 1,425 kilobytes, and that some Windows-based GIS programs nowadays occupy more than a Gigabyte of space on disc (i.e. 1,000,000 Kilobytes), you will begin to appreciate how little space there was to work in. Fortunately the entire program did not need to be in memory at any one time as the Basic programming language allows one program to 'chain' (i.e. run) another. It was therefore possible to break the program up into a large number of modules, each of which could do a particular function before calling up another one to continue with the next step. The only problem was that all the data currently in memory was wiped out each time a new module was loaded. To retain parameters from one module to the next, it was therefore necessary to 'poke' the data values into parts of the memory which were reserved for the operating system. This was a hazardous business, but by consulting a very detailed memory map it was possible to identify little tiny clumps of two or three bytes which you could be fairly certain would not be required by the operating system before the next module could retrieve the data values saved there (and which would not cause the whole system to crash). By appropriating these spaces it was possible to pass sufficient parameters from one module to the next, and thereby at least identify which channels the program could use to locate the main data filed on a floppy disc.
The other option for saving space, and also speeding up some of the slower operations, was to write routines in Assembly language, assemble them into machine code, and then burn them onto an EPROM. Most of the slower sections (e.g. the flood filling algorithm) were translated into machine code which could be accessed by system calls from within a Basic module.
I am immensely proud of the fact that I got something as comprehensive as MUMMS to run in something as small as a BBC Micro. I am also proud of the fact that MUMMS did some things better than many modern commercial application programs. However, my beloved BBCs (and MUMMS) were eventually superseded by 'Wintel' PCs in the early 1990s - after which nothing quite worked the way it should. Perhaps I should have written a PC version of MUMMS. However, time did not permit. This is probably just as well as I was bound to lose out to ESRI and the big boys sooner or later.
Return to the Programs page
Return to the Computer Courses page
Return to the main Computer Applications / GIS page