[Coco] Emulator

[Aaron Wolfe]

On Sun, Sep 6, 2009 at 11:44 PM, Wayne Campbell<asa.rand at yahoo.com> wrote:
> On Sat, Sep 5, 2009 at 7:55 PM, TP Reitzel<tpreitzel at hotmail.com> wrote:
>> We need an emulator to replace MESS.
>
> I don't think it's that bad. I think MESS is very stable, and I find it enjoyable to use. There are just instances where the behaviour of the memory allocations are larger than the original 64K page method in the CoCo3 allowed for. While it has not been a problem, I do have to wonder if I'm

Can you please give specific examples of this?  Are you sure you
haven't confused MESS with Nitros9?  I can't see how an emulator could
cause this, but I want to understand if this is indeed the case.

exceeding the limit the original CoCo2 or 3 had in terms of available
memory. If my procedures get too large, they will not run in the
original environment. This defeats the purpose of creating the
software to begin with. I want my programs to run on an original CoCo2
or CoCo3, whether it has 64K, 128K or 512K of RAM available. They all
have the same limitation, and while I never possessed a memory board
for the 1M+ sizes, I believe it applies to them as well, and that is
the 64K page size limit imposed by the GIME chip.
>

I am concerned about such things myself.  Again, specific examples
would be very helpful, generalizations are not.

Here is a quote from the Nitros9 documentation that I believe may be relevant:

NitrOS-9 Level 2 Memory Specifics
Because NitrOS-9 Level 2 utilizes the Memory Management Unit (MMU)
component of the Color Computer 3, up to 2MB of memory can be supported.
However, each process is still limited to a maximum of 64K of RAM.
Even with this limitation, there is a significant advantage over
NitrOS-9 Level 1.
Every process has its own 64K “playground.” Even the operating system itself
has its own 64K area. This means that programs do not have to share a single
64K block with each other or the system. Consequently, larger programs are
possible under NitrOS-9 Level 2.
These 64K areas are made up of 8K blocks, the size that is imposed by the MMU
found in the Color Computer 3. NitrOS-9 Level 2 assembles a number of these
8K blocks to provide every process (including the system) its own 64K working
area.

So again I wonder if the memory differences you mention are due to
Nitros9 (and quite normal), or due to MESS as you say?  If you are
simply seeing the additional ram that Nitros9 provides, there is no
problem really, as Nitros9 provides this additional ram on real
hardware as well as in emulators.

-Aaron

> A program written in Basic09 has a memory limit of approximately 40K. Even with separate files, the total of everything loaded into memory must not exceed 40K for both procedure size and for data requirements. I learned this writing DCom. It's bloat is my sandbox. Again, the memory allocations have not proven to be a problem, so I'm not as concerned about them.
>
> The only improvement I could see would be in wimgtool.exe. It doesn't allow for subdirectory copying. Everything gets written to the root directory. Then I have to go into OS-9 and copy the files to the sub-directory, then delete the copies in the root directory. And this because there is no move command in NitrOS-9, though I thought there was in the original OS-9. I also have to write a modbuster procedure since there is no modbuster command in NitrOS-9.
>
> I honestly don't remember if modbuster was an original tool, or whether it was a procedure I wrote. But I can write one. Unpack is pretty much a modbuster on a different level. Time, and testing on other CoCo systems, whether virtual or actual, will tell how well I accomplish my goal.
>
> Wayne
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>