[Coco] Emulator

[Gene Heskett]

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.
>
>Wayne
>
>
>
>
>________________________________
>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
>http://five.pairlist.net/mailman/listinfo/coco


-- 
Cheers, Gene
"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.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

Windows: The first user interface where you click Start to turn it off.

   -- From a Slashdot.org post