[Coco] some results

Mon Nov 9 21:14:59 EST 2009

Instead of merging all of them into RunB, I would try merging just the 
modules you need into your compiled Basic09 module. In other words, unlink 
RunB and the others until they are removed from memory. Then merge just what 
you need into your module; e.g. merge DCom, RunB, Gfx2 into say DCom2 then 
load DCom2 and run DCom. This should result in the minimalist memory 
footprint possible.

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

> I have RunB, SysCall, Inkey, GFX and gfx2 (those are the exact module 
> names) merged together as runb, and it is preloaded when I start NitrOS-9. 
> I added it to the startup file.
>
> Basic09 usually has no problem finding them in small procedures. This only 
> happens when the procedure size exceeds some unknown size. I haven't been 
> able to pin down the exact size, but it's somewhere in the 23K range in 
> source size.
>
> When I wrote DCom, the only time this problem ever occurred was when my 
> workspace size exceeded 32K. Then, I could pack the procedures and run 
> them from the command line with runb.
>
> None of that is working with NitrOS-9, modified Basic09 and original runb. 
> I am going to try running it with the modified runb and see if there's a 
> difference on the command line.
>
> By modified, I mean the version of runb and Basic09 that had the date year 
> modification added. Speaking of that, I don't know if it's important or 
> not, but the modified Basic09 still returns a 14 character string that 
> only includes a 2-digit year. Is it possible that there are other issues 
> that may be affecting Basic09 because of the mods?
>
> Wayne
>
>
>
>
> ________________________________
> From: Lothan <lothan at newsguy.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Mon, November 9, 2009 2:15:09 PM
> Subject: Re: [Coco] some results
>
> 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
>>
>
> --
> 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
> 