[Coco] Emulator

[Ron Bihler]

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. 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
>
>
>   
Wayne,
With RiBBS it was recommended that one uses the Ram disk for common 
files and procedures that where used often.  The biggest issue ran into 
was the 8k page breaks, it came down to merging several routines 
together to take advantage of the 8K boundaries.  This was one of the 
biggest issues I ran into.  Due to the size of the program it became a 
game on what I could move to a different procedure and what I could 
combine.  Now granted seeing some of the code (thanks to unpack) it sure 
could have been done better.  The age old problem of adding and adding 
and not doing a rewrite it tends to bloat the program.

I am assuming mess handles the ram disk the same way, it looks like a 
Disk to the programs.  I had created a config file for RiBBS that would 
point to all the paths needed, plus a bunch of other options and settings.

I myself have never been able to get Mess to work on my XP machine.  VCC 
works fine, but I am missing something in regards to mess or placement 
?  I get a coco3 screen but no keyboard response, it just sits and looks 
at me :) I am able to test on a real Coco3 when you get that far.

Ron Bihler