asa.rand at yahoo.com
Mon Sep 7 15:45:35 EDT 2009
I understand that. I believe that I said the GIME allows multiple pages to be available to the CPU, 1 page at a time. DCom was written in the modular fashion you speak of, and was disk-intensive. All of the data produced and used by it was contained in disk files.
What I wanted to do, but couldn't at the time, was figure out how to get different parts running in different pages and communicating between them. It would speed up the program significantly, because I could keep the data in memory instead of having to rely on disk files. The use of files slows the program down significantly.
As it turns out, writing unpack has proven that much of the slowdown was just from the backward way I wrote the original DCom. Unpack already does most of what DCom did, with fewer procedures, and is much smaller, more efficient and faster. But it still relies on disk files, and I know that these files will slow it down on a real CoCo3.
From: Robert Gault <robert.gault at worldnet.att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Monday, September 7, 2009 5:50:44 AM
Subject: Re: [Coco] Emulator
> The 64K limit is imposed by the CPU not the GIME which allocates $2000 byte chunks.
Wayne, there is no reason why a large program must exist only in memory. Write these large programs in modular fashion and load modules from disk as needed to get around the 6809 64K memory limit.
OS-9 is written to make this simple. Even so, this can also be accomplished under the Basic ROMs. It certainly is harder under Basic, but it is even possible to pass variables between program modules.
More information about the Coco