80-Bus News

We are talking ‘Big’ Programs here!

by Dave Russ

Way back in the twilight of time itself (about 3 – 4 years ago) in a land not too far from here, there could be found a new breed of creature. They were in general a happy band of beings, though they often complained of frequent headaches. You would not see them very often, except maybe first thing in the morning or last thing at night, and if perchance you stumbled upon ore in its lair it would seem as if the poor creature was in a trance.

Every now and again they would congregate in cold halls and back rooms and regale each other with stories until the small hours. These tales were not of high adventure or epic endurance but how to coax an extra 1k of RAM from a small home computer thus doubling its capacity and the suchlike. For hour upon hour they would feverishly tell of how they boldly moved in on video RAM and BASIC workspace and worked wonders on a tiny system, that once it had set itself up, left you with an available workspace that was barely into single figures.

This was the heroic age of the early home computer world. Now lost forever, I’m glad to say, though some of the tales still linger on as classics.

However we still have one legacy from those dark days, and I am sure that it is one of Murphy’s n laws, and that is whatever system you have, a program will always expand to fill it. Way back then all you could do was read routines into available workspace, wherever it may have been, and through the magic of having read the manual, link it all together to give a running program.

Now that we are living in more enlightened times, and have acquired our 8 bit CP/M computer, we now have oodles of memory to play with (We do???), but still we manage to fill it up somehow. We can now afford to program in high level languages with little regard for the target object code size. Fast, tight assembler type code is now not a prerequisite for an efficient program running on a small computer.

So we still manage to fill our memory up, but these days we have better methods of running programs larger than memory than poking routines into obscure little corners. This is the purpose of this awe inspiring (yawn) article.

It may be worth mentioning that I was talking to an academic type not so long ago who is shortly publishing a book on Artificial Intelligence. He said that any machine in design today should be capable of addressing at least 16 Megabytes of RAM. This seems rather extravagant, doesn’t it, but it seems that AI applications are not renowned for their economy with memory.

Getting back to the point, I’m trying to say in my own roundabout way that everyone ought to stop before embarking on a mammoth project and think ahead a little to the time when the program begins to get bigger than the available memory. It may prove difficult to restructure it in six months time, and so we should consider the use of overlaying or chaining even at this early stage.

To give an example, I began a test program for GSX device drivers and at the start I realized that the main menu would have to contain something around 40 options. As it stands this is a prime candidate for overlay techniques, as if I were to add another 20 options along the way I would never have fitted it into memory as a single program. So now I have a single menu/​controller program that reads in and executes options as required. Once complete the called subprogram is discarded and the next read into the same memory area.

This approach is by no means revolutionary and is well established. For example take a look at Wordstar and diskpen, these make use of overlays, DR DRAW and DR GRAPH are into double figures with overlay files in their 8 bit versions.

What to do about it

OK, i hear you shout, so my programs are going to get bigger, what the hell do I do about it??

Well you have a lot of options but they fall into 2 main categories.

1. Program chaining.
2. Program overlays.

Chaining

Program chaining is simple enough in theory but could prove difficult in practice to implement. When a program is complete it runs the next program in the suite. The first program reads the second into memory over its own memory area and then executes it. Usually no trace of the original program remains.

Advantages

1.   Easy to use if the language used supports a chain function. Program creation using a suitable chain function is simpler than overlaying.

2.   Control flow between programs is easy to understand.

3.   With the use of some clever code a program management menu could be written to control a number of applications.