[Coco] some results

[Wayne Campbell]

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