[Coco] some results

[Lothan]

Have you tried merging runb, gfx2, and your code module into a single file? 
If you load them separately, each separate module takes up full pages of RAM 
(4K, 8K?) even if the module is say 100 bytes. Merging them can 
significantly reduce the memory footprint required.

--------------------------------------------------
From: "Wayne Campbell" <asa.rand at yahoo.com>
Sent: Monday, November 09, 2009 4:28 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] some results

> I don't know what is going on with the mem command. I can specify some 
> values between even 000s, but not always, and some values are not accepted 
> at all. I decided to work around the memory problem and try to make the 
> procedure smaller.
>
> First, I replaced all of the GFX2 statements with GOSUBs, and put one of 
> each GFX2 statement in subroutines. This reduced the code size for fmato 
> to <24000 (unpacked). It still wouldn't run, so I removed the sort and 
> renumber routines from fmato and placed them in separate procedures. 
> Having them all in the workspace at the same time just made the overall 
> size of the procedures greater than fmato was by itself. I packed the sort 
> and renum routines into separate module files and deleted them from the 
> workspace.
>
> Then I added SHELL statements to load each when it was time to use it. 
> fmato still wouldn't run, even though the memory size was reduced to 24k 
> (or so). I packed fmato, and found I could reduce the workspace size to 
> 23000. It worked! I ran fmato and it ran. It went through the instruction 
> section, displayed the decode in overlays, and when it got to the first 
> sort, it quit with a 43 error. Running mdir showed that the sort module 
> was indeed loaded, but Basic09 couldn't "find" it.
>
> I unlinked it from memory and quit Basic09. I ran it from the command 
> line, and 67 error. Apparently the original RunB still has a problem with 
> it. There were still 3 routines to separate, the ones for creating a 
> record when a new var ref, line ref or lit ref occurs. I did that. While 
> they were all merged with fmato it ran (only in Basic09, and only after 
> packing). It still errored when it got to the first sort routine.
>
> I packed the record routines separately and removed them from fmato's 
> workspace and tried again. Now it errors when it tries to run the first 
> record procedure. Again, mdir shows that the module was found and loaded 
> into memory. I don't get it.
>
> I am going to try separating the instruction decode section. It is the 
> single largest routine in the program. I have a multitude of counter 
> variables, as I wanted to know exact data concerning the I-Code. Perhaps 
> making it a separate procedure will fix the problem.
>
> Wayne
>
> Also, I'll be putting the newest version of fmato on sourceforge, since 
> the one I put there yesterday is already obsolete.
>
>
>
>
> ________________________________
> From: Robert Gault <robert.gault at worldnet.att.net>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Sun, November 8, 2009 8:35:52 PM
> Subject: Re: [Coco] some results
>
> Wayne Campbell wrote:
>>
>> Trying to go down to 26000 reduces the memory to less than
>> the needs of the procedures. I am finding that Basic09's memory
>> command is broken. For example, I can type mem 32000 and it will
>> increase or decrease to that amount. Likewise, I can do the same
>> with 34000. But if I specify 33000, I get "What?"!
>
> There is a good chance you have some code mismatches between your Basic09 
> and the OS-9 versions. On my system, I can smoothly ask for memory within 
> Basic09 up to mem 32760 giving 32767. I get What? trying for 32770, or any 
> number higher including 34000.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>