[Coco] Emulator

[Gene Heskett]

On Sunday 06 September 2009, Wayne Campbell 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 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.
>
>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

Modbuster was not an original tool, and there are several other substitutes 
for it, my 'vfy' for one.

Launch it with the -s (and -k too if its track 34 you are splitting) name-of-
file to be split.  I also wrote a track 34 to directory entry tool, so that 
track 34 is then just another file and can be accessed by vfy.  IIRC its 
called kernel2dir or something similar.  Either way it will generate a set of 
files in the directory you are cd'd to that are the individual modules of an 
os9boot file for instance.  The -k switch makes it also save the pre-amble 
and post-amble bytes sequences on each end of a track 34 image as separate 
files.

I don't recall if I built a c library split function into vfy or not, it 
would be relatively easy to do since all clib modules start with $62CD, where 
an os9 module starts with $87CD.  Just change the trigger integer.

-- 
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>

I've enjoyed just about as much of this as I can stand.