[Coco] Interesting developments, and a real issue

[Wayne Campbell]

My work on DCom/unpack has progressed in a new direction. While hand-decoding ribbsmain and rconfig, two modules from Ron Bihler's RiBBS program, I began to see the way the code flows. I now understand much more of how the content of the I-Code is arranged.

I had written a utility to give me an organized dump of the I-Code. I call it fmato (ForMATtedOutput). By organization, I mean:

* The header is displayed in its parts, and is separated from the instruction section by a blank line.

* The instruction code is displayed with both module and relative addresses and the code for one instruction per line. lines are terminated by a \ token ($3E) or a <eol> token ($3F). This is actually inaccurate in application, because it does not detect a difference between the token being a token, or being part of a variable, line or literal reference.

* The DSAT and VDT sections are also separated from the instruction
code, and each other, by a blank line. Each displays the module and
relative offset to the first byte value displayed on that line. Each
line is 20 bytes in length.

I decided to use fmato as a testbed. I wanted to know exactly what I could identify in the instructions, and how many of what were found. I started from the beginning, and worked my way through the header, then the instruction code. When I reached the end of the instruction code, I had identified every variable reference, every line or branch reference, and every literal reference in the instructions.

Variable references are wrapped in braces: {}
Line references are wrapped in parentheses: ()
Literal references are wrapped in brackets: []

Then I took the DATA statements in unpack and added them to fmato. Now, every token has a name. It can be a keyword or Basic09 function name, or an internal reference that has no bearing on the reproduction of the source code. There is one special wrapper I use. It is: <* *>. I use it to wrap the integer value that occurs in FOR and NEXT statements that is identical in value per FOR/NEXT pair, and each pair has a unique value.

I then added files. Three were necessary:

1. Variable reference
2. Line reference
3. Literal reference

While the literal reference file may serve a purpose later, it really is not necessary to the reconstruction of the source code, since they are Basic09 constants. Because they occur in the instructions, they are easily identified, so a reference file isn't required.

At this point, I began to realize that I had to organize the output in order to make the program execute faster, and to make it digestable to us humans. I added display code, using GFX2, and created a screen layout that accomodates the data I want to see, and overlay windows to display the various lists in. It works great! Until now.

The plan has been to add every function needed to decode the I-Code as much as possible in one pass of the module. The first pass identifies everything in the instructions, then the fmato deals with the reference files. It sorts, renumbers and assigns line number strings to the line references, then sorts and renumbers the literals reference. That is the final step the first pass can do without referencing the VDT and DSAT sections for variable identification.

When fmato reached 24k in source size, I ran into a problem with Basic09. The program would run, display the date, and then get hung in a loop, displaying the same number repeatedly. The value of the number proved to be different in each run, sometimes positive, sometimes negative, and I had to quit MESS to get out of it.

The cure was to pack the procedure, then reduce the memory in Basic09's data space to 23000. fmato would then run correctly.

As I said before, I added display code. Once I was caught up with adding the display code, I then added the literal reference sort and renumber code. This boosted the source size significantly. It now loads into Basic09 with a size of 30089, and the data size is 834. Opening Basic09 with a 32k memory size leaves me 1398 free. This should be enough to run it, but I've tried using 33k, 34k, 35k all the way up to 40k. It does the same thing, gets stuck in that loop.

I pack, and the size is 24438. With 32k, the free space increases from 1398 to 7049. Plenty, right? Wrong. Still gets stuck in that loop. Reduce memory to 26000. Not enough free for the data requirements. Basic09 always says What? if I specify anything other than a whole thousand on the memory spec, so trying 26500 or 26750 is not working.

I try running it from the command line. The same error. Gets stuck in that loop.

The Basic09 I'm using is v01.01.01 for 6809, modified to include a 4-digit year. The RunB I'm using is the original that, if it uses the date at all, only looks for a 2-digit year. There's something going on that isn't specific to one version. I don't know how to resolve the issue, or even what may be causing it.

Can anyone even venture a guess as to what is happening? I'm running the 6809 version of NitrOS-9 using the MESS emulator.

Wayne