Inside geoWrite – 1: The Overlay System

First of a series of articles on geoWrite.

geoWrite is a WYSIWYG rich text editor for the Commodore 64 GEOS operating system, which runs with a total of just 64 KB of RAM. In the series about the internals of geoWrite, this article discusses how it manages to fit 52 KB of code into the available 23 KB of application RAM.


I’d be interested to hear of personal experience of programming with overlays - whether using an existing system, or creating one. Perhaps using a very inconvenient system!

I’ve used overlays exactly once, on a test program for the ND-100 minicomputer. The overlay mechanism was part of a framework called TPE (Test Program Environment), or possibly TPM (Test Program Monitor). I think I may have been the first person to actually need the overlay mechanism, but that was mainly because I used memory for largish bitmaps, which was somewhat painful on a 16-bit minicomputer.

1 Like

Do you know if there is documentation for the overlay system used by the ND TPE? I and a couple of other people have been scratching our heads over the format used by the TPE modules.

There certainly was documentation, but it may have been lost. There is a small chance that I have a printout somewhere, about 1200 km away from where I’m sitting.

Have you checked the documentation library at

Yes, I’ve access to most of that documentation, but it may be that I haven’t looked in the right place. I’ll dig further. Thanks!

Some of the BASIC implementations I used had a CHAIN command for doing overlays. It worked reasonably well.

I love this. Especially, as it promises to become a detailed walk through the program and its architecture. Dag Spicer (CHM, senior curator) once coined the term “curated source code” for this.
A few years ago, I had the idea of doing a site “” for the very purpose, but there are obviously not that many projects.

Turbo Pascal has overlays and it worked quite well on CP/M.

RSX-11M also has overlays, and also it was workable.

When you do not have virtual memory you do that swapping part yourself and get things done, with your program in control. With VMS everything was transparant and you could do really inefficient large programs and wonder why it was slow, since small physical memory and paging to a not so fast diks still have to work hard to give you that seemingly endless memory.

UCSD p-System also has overlays, called segments. Memory parts swapped in on demand but under control of the programmer, not the system.

1 Like

Pascal for OS/9 (6809) had a virtual memory option.

Pascal for the C64 had it as well.
(There were two editions by Data Becker, a more “serious” one featuring its own floppy file system and a more basic one, which was probably named “Pascal 64”. At least the former one had it.)

Ah, yes, I used that back in the day, I remember it now. The UCSD p-System itself used overlays as well, the program I wrote took so much space that the editor had to swap parts of the system out just to get room for my code when I used the editor. The Apple II I worked with had four floppy drives just to make the swapping possible. And yes the code I wrote used overlays too.

The segment system in UCSD was pretty advanced in vII, and got even better in vIV. For the time, the vII version was quite advanced. The entire system is based on segments.

vIV made it better because the P-code in UCSD is relocatable, so they added the ability internally to push stuff around to make room for segments, all on the fly.

vIV removed the specialized instructions for stuff (like string handling, I/O, etc.) that was done by the P-machine before, and compiled them to segmented procedures that were loaded as necessary.

If you look at both how the early Mac and IIGS were designed, there’s a lot of similarity to how UCSD was done.