[Coco] some results

[Wayne Campbell]

I found that the endless loop error was my own doing. In all of the testing I've done, I always made sure the parameter string contained the correct filename. Because I was testing the parameter before I initialized anything, 'er' was a random number. Also, the file open status booleans were showing up as true when they should have been false. Moving the initializations for those variables before the parameter test corrected that issue.

Now for the bad news. The program still won't run. It reaches the first subroutine call for GFX2 and errors with a 43 error. This means it could not find the procedure in its workspace. This is because there is insufficient memory allocated to run it. Raising the workspace memory size reduces the amount of other ram Basic09 has for loading called subroutines that are pre-loaded or read from a disk file. This means I have to reduce the workspace size. The program loads into 35K of workspace memory. I reduce that to 27000 and I have a little more than the minimum data space requirement for the procedures' variables.

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?"!

And that isn't the only memory specifier it has problems with. It won't let me set memory levels like 26500, or 18512.

Packing the code helps, a little. I can reduce the memory requirement lower, but I can't free up enough to allow GFX2 to load into the workspace. I try running it from the command line. At the same point in execution, RunB reports a 67 error. This means there is an illegal parameter in the run statement. I've double checked the settings, and the run statement is correct. It ran before, but it doesn't now.

I can only assume it has something to do with the way memory is being allocated to the program, whether in the Basic09 environment, or through RunB on the system command line.

I think I neglected to mention that fmato, until now, has been a single procedure. I wanted to try to do everything needed to identify, count and store everything the instruction code has to offer. I have done that. Now I am displaying the data, and performing sorts and renumbers to the data files. The Variables file is the only one not furthur processed, because that step requires matching the references to the VDT, the DSAT, and the data memory. Once that is done, I can recreate the TYPE, DIM and PARAM statements for the procedure being decoded.

I have just installed the code to sort and renumber the Literals file. It was this installation that brought the problem to the forefront. I have now broken it up into more procedures, isolating the search and add reference routines in separate procedures, and then the line reference sort and renumber, followed by the literal reference sort and renumber. The code prior to the installation of the literal sort routine worked without flaw. All of the data is correct, and the overlay windows functioned as expected. The text on the main screen is organized to make it easier to understand what you are seeing.

It all works. The break occurred when I added the literal sort and renumber routine. Because of how far down the program this occurs, there is no valid reason I can think of that would break the rest of the code, other than not enough memory.

Now that I have split it up into different procedures, modifying the searches and sorts will be easier to manage. Currently, they work, but are very slow. The searches are simple linear search until a match is found or the last record is read and compared. The sorts I had to modify from that because the linear sort took way too long. It uses a method that sorts from top-to-bottom, then bottom-to-top for each pass of the main repeat loop. It's definitely faster than the linear method, but it still isn't fast enough. For now, though, it's enough that they work. At least I can rely on the data, even if the display code does get in the way.

I have tried using the memory modifier on the command line, such as:

fmato createmsg - works with my shell
67 - illegal argument

fmato "createmsg" - breaks with my shell
(""createmsg"")
   ^
10 - unrecognized symbol (it doesn't like the extra quotes)

fmato createmsg #32k - results in the error:
43 - procedure not found

runb fmato createmsg #32k
43 - procedure not found

dir -x results show fmato as the 5th file in my commands directory.

It seems it doesn't like the memory modifier either.

I have been working on finding a way to reduce the code size. One thing I tried was using a specific set of variables to act as constants. This way, I can just use a variable to reference a value that is repeated multiple times. On byte literals, it increases the instruction code size, because it takes three bytes to reference a variable, but only two to reference a byte. It can be more useful with integers, as there are more than a few that are referenced multiple times. All hex literals are stored as integers, so there is no loss in size, and no gain in size. String literals are the only real candidates for saving space, but with many of them, it would require creating single word strings of specific length and size for the shared portions, and either the same for the remainders, or they can be left as literal constants. How much space would be saved? I don't know yet.

I will put a copy of fmato's source on sourceforge for anyne who wants to look at it or try to run it.

Wayne