asa.rand at yahoo.com
Tue Sep 8 13:54:01 EDT 2009
Thank you for this explanation of things. There are many aspects of microprocessors and maching programming I do not understand. Everything I read in my earlier days suggested to me that each 64K of RAM was called a PAGE of memory. It shows how much I still have yet to learn.
From: Gene Heskett <gene.heskett at verizon.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Monday, September 7, 2009 8:13:25 PM
Subject: Re: [Coco] Emulator
On Monday 07 September 2009, Wayne Campbell wrote:
>I understand that. I believe that I said the GIME allows multiple pages to
> be available to the CPU, 1 page at a time.
Not quite Wayne, it controls 8 each 8k ($2000 in hex) sized pages at a time,
which totals 64k, and any one of which may be remapped/swapped for another at
any time. Some such operations can of course lead to 'interesting' results
if not handled right. It (the gime) has 16 of these mapping registers, and
which 8 is in use at a time controls the multitasking. The OS normally
claims 8 of them, and allocates the other 8 according to what program is to
be given a slice of time in this time slot. That is a somewhat simplified
view, and programmers are free to manipulate their 1/2 of the map.
It is a technique I used when I wrote myram, a ramdisk for coco3's. I could
actually use 1.5 or 1.7 megabytes of the 2 megs in my machine as a ramdisk by
such paging. Coupled with an automatic initialization (formatting) when
accessed the first time, which took about 100 milliseconds to do, and a full
100% removal when you were done with it, I thought it would be the killer
ramdisk for expanded coco3's, but it hasn't caught on for some reason.
As an aside os9/nitros9 doesn't give a program that only needs 12k a full 64k
to play in. It will get 2 pages, or 16k, and the rest of the map is filled
with repeats, so it does not waste a full 64k ram map per executing program.
> 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.
>Coco mailing list
>Coco at maltedmedia.com
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
Windows: The first user interface where you click Start to turn it off.
-- From a Slashdot.org post
Coco mailing list
Coco at maltedmedia.com
More information about the Coco