[Coco] Questions for Tim Linder

[Wayne Campbell]

This message is aimed towards Tim Linder, though I do remember that Boisy Pitre also worked for Microware. Of all the names I've seen on this list, and in my memory associated with OS-9, you are the one name that is connected with the original OS-9 development team. I have a few questions, and I think that you *might* be able to answer some of them.

First, were you involved with the development of Basic09?
If so, do you remember anything about the structure of I-Code?

Since I was able to get my original source code to DCom back, I also have the original header file to Basic09 that Boisy Pitre sent me back when I was developing DCom. What he couldn't send me, unfortunately, was the entire source to Basic09. That would have helped me answer my questions back then. I have looked at the source code on SourceForge for the version of Basic09 that was updated to include Y2K mods, but it doesn't have the comments that would explain what is happening at any particular stage of the program. Anyway, I am still trying to understand the parts of I-Code that I didn't understand then. I have almost all of it decoded, as I did back then. But there are a few things in I-Code modules I never did understand completely. They are:

1. Module Header:
   First Execution Statement Offset Address
   I *think* that this is used to establish the point in the module where the first instruction statement occurs. It makes sense to me that, if you put DATA statements at the top of the program, the first instruction would occur immediately after those DATA statements. Since I always put my DATA statements at the bottom of my programs, this field always has the value $0000, which I am interpreting to mean the first byte following the module name. Am I understanding this correctly, or is there another meaning of this integer?

   Procedure Status
   This byte always has the value $80. It occurs immediately before the Module Name Length byte. What is this byte used for? Does it ever have a different value?

2. DSAT (B09 header calls this the Data Area)
   The last 3 bytes of this section are the total number of variables defined in the procedure (the first integer), and a byte that, with one exception, has always contained the value $03. In the one exception, it contained the value $04. I have never understood why it was different in that one instance, or why it is otherwise $03. What is this byte, and what does it mean?

   The DSAT is the shape data for all variables that are not "simple" BYTE, INTEGER, REAL or BOOLEAN variables. Included is the shape data for all record TYPEs. While this data can tell me how many fields there are in that record, the data (as stored) doesn't seem to be connected in any way with the variables DIMed to those records. In addition, the data itself is incomprehensible to me. As an example:

   This is the data for a record as it appears in the DSAT (formatting is mine):

   File     DSAT
   Offset   Offset Size ???  F1  F2   F3   F4   F5   F6  (F=field)
   -------- ------ ---- ---- -- ---- ---- ---- ---- ----
   000004E7 00B0   002A CDCD 58 0160 0167 016F 0177 0181

   This is the data for the variable DIMed to this record type:

                   Data
   File     DSAT   Memory
   Offset   Offset Offset Size 
   -------- ------ ------ ----
   000004F6 00BF   B67C   002A

   The second integer of the variable definition shows that it is the size of the record, but that is all that it shows. If I have two records of the same size, but with different fields and shapes, I cannot directly associate either variable with either record. I am assuming that the shape data for the record may hold a clue as to how RunB (and Basic09) associates them. What I am unable to do is interpret the record shape data:

   002A            represents the size of the user defined type
   CDCD            represents ???      { what does this mean?  }
     58 58-5F =  8 represents aByte    { each of these numbers }
   0160 60-66 =  7 represents aInt     { represents one of the }
   0167 67-6E =  8 represents aReal    { variables defined in  }
   016F 6F-76 =  8 represents aBool    { the type.             }
   0177 77-80 = 10 represents aStrOne  { I don't know how to   }
   0181            represents aStr     { interpret them.       }

   The integer CDCD always has different values, and both it and the byte 58 may not be correctly ordered. For all I know, it could be:

   CD CD58

I need to understand this data if I am to come anywhere near being able to associate variables to the records they are DIMed to. So far, I can only connect field variables that were used with the variable they are associated with. Unused fields produce gaps in the data memory allocation. The record data has been useful for determining how many fields were defined in that record, but it doesn't help me connect the record with its variable.

I hope this all makes sense, and that you can help me. Otherwise, I may have to ask RadiSys if their OS-9 division still has the original source to Basic09 in their archives, and if they would allow me to have a copy of it. (Not likely, but an alternative just the same.)

Thanks for any help you can provide.

Wayne Campbell