[Coco] some results

[Wayne Campbell]

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