# SSU Development thread (4.0 to 5.0)

#### GLS

The animations do work it's just that they load in the wrong states (open vs closed, cradled vs pre-cradle).
What I want to know is if you have a scenario with the doors closed (like the one you get after you load the original scenario), do they show up open?

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
What I want to know is if you have a scenario with the doors closed (like the one you get after you load the original scenario), do they show up open?
Negative but everything else was in their default positions. Could that be the issue? Since something is off with either saving or loading, everything is set to the default state (closed and latched for the PLBDs, Ku stowed, RMS deployed but cradled etc). This includes the switch positions in the VC.

#### GLS

OK, now things are happening! I didn't use your modules, but by their size I see that they are a Release build (which are much smaller), so I did one and indeed there is something wrong. Let's me have dinner and I'll look at this afterwards.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
OK, now things are happening! I didn't use your modules, but by their size I see that they are a Release build (which are much smaller), so I did one and indeed there is something wrong. Let's me have dinner and I'll look at this afterwards.
Compiling in Debug mode I get the same as you, no issues whatsoever. But switching back to Release mode, the issues are back.

#### GLS

Bug found! Surprise surprise, it was my fault... :facepalm: When I added the _DEBUG preprocessor stuff a few weeks ago, I had one line too many inside it, so when not in debug mode, the @ENDSUBSYSTEM line was never written, and when loading = kaput every single subsystem parameter.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Bug found! Surprise surprise, it was my fault... :facepalm: When I added the _DEBUG preprocessor stuff a few weeks ago, I had one line too many inside it, so when not in debug mode, the @ENDSUBSYSTEM line was never written, and when loading = kaput every single subsystem parameter.
Thanks for tracking the down the bug and fixing it. I was starting to think that something was seriously wrong with my system since it was so strange.

#### GLS

Thanks for tracking the down the bug and fixing it. I was starting to think that something was seriously wrong with my system since it was so strange.
It's my job (and it was my fault...).

#### Urwumpe

##### Not funny anymore
Donator
It's my job (and it was my fault...).
"We don't make mistakes, just happy little accidents."

And if you don't want to believe in the words of Bob Ross, always remember: SSU is a team effort, in the good times and in the bad times.

#### Wolf

##### Donator
Donator
"We don't make mistakes, just happy little accidents."

And if you don't want to believe in the words of Bob Ross, always remember: SSU is a team effort, in the good times and in the bad times.

Guys YOU ROCK :thumbup:

#### GLS

"We don't make mistakes, just happy little accidents."
Well, here's another... :lol:
Although I'm not totally happy with the current SimpleCOMPOOL, I think the current short comings can be overcome with more code, most of it outside Orbiter. Given that we don't have a list of the COMPOOLs and what variables are in them, I currently can't really justify a move to the structure-type construct. So we are left with the current unsigned short array. A way to have both a way to load/save the variables, and to garantee that the addresses don't everlap (not easy by hand) is to have some sort of script/program/whatever that would take a list of variables (i.e. names) and their types and would generate the addresses and a string of names, so new code in the SimpleGPCSystem can take to name variables for the scenarios files.

What I haven't figured out yet is how to plug the I-LOADs into this... some of them must be placed in COMPOOL variables, to be accessable by multiple modules, and maybe there should be a way to define them per mission file. And maybe they don't need to be loaded/saved from the scenario file.

---------- Post added at 11:10 PM ---------- Previous post was at 10:38 PM ----------

Maybe a .csv file for COMPOOL definition like this:
WX_YZ,DW3,,,,

(^^still have to research the types)

...and have the I-LOADs in a separate list that would be used to generate a .h file with all the consts so they can be used by who needs them.

This is already a good detour from the guidance stuff, but I really need to have some I-LOADs in the COMPOOL, and also have them in an matrix so I can access them via index, so something needs to be done.

#### Urwumpe

##### Not funny anymore
Donator

What I haven't figured out yet is how to plug the I-LOADs into this... some of them must be placed in COMPOOL variables, to be accessable by multiple modules, and maybe there should be a way to define them per mission file. And maybe they don't need to be loaded/saved from the scenario file.

Well, should I really make things overly complicated?

A COMPOOL shares the lifetime of its memory overlay. There is no memory management in the FCOS that is more sophisticated. You can say, everything is determined at compile time. A memory configuration (MC) simply consists of the FCOS overlay (OPS 0) and the application software overlay (For example, the majory function GNC memory overlay + OPS 1 overlay + minimal OPS 3 overlay in upper memory). When a memory overlay is changed, the contents of the new memory overlay are loaded from tape.

Thus, the I-LOADS are simple: They are set at compilation. More specific, the compilation of the tape images from compiled object files. You simply load the memory overlay from tape and the I-LOADS are there.

An I-LOAD is roughly the HAL/S equivalent to a "int x = 1;" statement.

Yes, a CSV file would be one option. I would prefer a minimal HAL/S FC parser there, simply because the input would then be exactly the information we have from NASA, and structured data could be kept structured, just like arrayed data, what CSV can't. Another option would be a XML structure. The data types are explained in the HAL/S language manuals. When loading a scenario, we would need something like a "tape linker" creating the data structures for every memory configuration. Also, for modifications/uplinks after creating the tapes, we would need to store the changes in memory or the changes of data on the tape.

Did you already take a look at the examples or parser trees of the COMPOOLs in HAL/S?

Last edited:

#### GLS

A COMPOOL shares the lifetime of its memory overlay. There is no memory management in the FCOS that is more sophisticated. You can say, everything is determined at compile time. A memory configuration (MC) simply consists of the FCOS overlay (OPS 0) and the application software overlay (For example, the majory function GNC memory overlay + OPS 1 overlay + minimal OPS 3 overlay in upper memory). When a memory overlay is changed, the contents of the new memory overlay are loaded from tape.
I suspected that MCs had something to do with it... and ATM I'm not really interested in going down that road.

Thus, the I-LOADS are simple: They are set at compilation. More specific, the compilation of the tape images from compiled object files. You simply load the memory overlay from tape and the I-LOADS are there.

An I-LOAD is roughly the HAL/S equivalent to a "int x = 1;" statement.
That I knew. It's not so much the nature of the I-LOADS but how do we come up with something that works for both modules (our SimpleGPCSoftware classes) and the COMPOOL.
My idea above, of having a I-LOAD list that gets processed into a .h file, and also gets used by the COMPOOL "preprocessor" (that generates the COMPOOL stuff for usage and save/load), doesn't allow for mission specific I-LOADS. Most of the I-LOADs didn't change or they aren't critical enough for "user control" (e.g., the 15s OMS EXEC timer), but user control is needed because SSME max thrust was defined via I-LOAD. Maybe having a I-LOAD list (static) just with the names, and keeping the values in another list (user defined) would work. The values list would be loaded into an array, and then each module, and SimpleGPCSystem for the COMPOOL, would read what they needed for their initializations.

Yes, a CSV file would be one option. I would prefer a minimal HAL/S FC parser there, simply because the input would then be exactly the information we have from NASA, and structured data could be kept structured, just like arrayed data, what CSV can't. Another option would be a XML structure. The data types are explained in the HAL/S language manuals. When loading a scenario, we would need something like a "tape linker" creating the data structures for every memory configuration. Also, for modifications/uplinks after creating the tapes, we would need to store the changes in memory or the changes of data on the tape.

Did you already take a look at the examples or parser trees of the COMPOOLs in HAL/S?
Parser trees of COMPOOLs?! I haven't read everything of the docs I have, but I haven't seen that...
Like I said in the post above, we don't know what variables go in which COMPOOL... or do we? And even if we know some, that won't be all, and as accessing then in C/C++ won't be as easy as in HAL/S, why bother with grouping them in the code? We could "group" the variables (and ID the COMPOOL if we have that info) in comments on the "COMPOOL variable list file".
About specifying things in a way that is closer to "the official way": totally agree. Like I said above, I have yet to do a catalog of the types, so that needs to be done so we know the potatos from the onions. Going back to paragraph above, do we have enough info?

#### Urwumpe

##### Not funny anymore
Donator
Like I said in the post above, we don't know what variables go in which COMPOOL... or do we?

Lets put it that way: We know it pretty good (95%) for FCOS and SM. Also I think for some aspects of GNC, we reach around 50% already.

#### GLS

Lets put it that way: We know it pretty good (95%) for FCOS and SM. Also I think for some aspects of GNC, we reach around 50% already.
Let's say we go with that and make separate COMPOOLs, how would the modules access them? Currently we put it all in an array, and then call something to read/write from there in a +/- controlled way.

So, COMPOOL variables in HAL/S format:
Code:
C	runway declarations
DECLARE X SCALAR DOUBLE;
DECLARE Y SCALAR DOUBLE;
DECLARE Z SCALAR DOUBLE;
DECLARE Z MATRIX(3,3) DOUBLE;

C	other stuff
DECLARE IGI INTEGER SINGLE INITIAL(1);
What I don't see anywhere is "non-hardcoded" initial values... :facepalm:
The expression I-LOAD (or similar) simply doesn't exist in any HAL/S doc I have. I was expecting the I-LOADs to be centralized in a file (or more) and not to be "scattered" throught the code... and according to this they probably were. Anyway, we'll need a centralized system as we will only know the values during loading.

Anyone wants to write the parser, while I write the variables? :shrug:

#### Urwumpe

##### Not funny anymore
Donator
The INITIAL(1) expression is it. As far as I understand the workflow, the classic I-LOAD values are created as INITIALs and compiled into the tape images by the linker for validation and testing.

The program modules refer to the COMPOOL template, which defines the data structure while the memory contents are in the COMPOOL object file.

Last edited:

#### GLS

The INITIAL(1) expression is it. As far as I understand the workflow, the classic I-LOAD values are created as INITIALs and compiled into the tape images by the linker for validation and testing.
Yes, the INITIAL (or CONSTANT) keyword sets the initial variable contents, but that doesn't really work for us, because of the per-mission I-LOAD requirement. So we need a way to load both COMPOOL and modules with values...

Here is a variable definition list, based on the current COMPOOL stuff:
Code:
C	----------------------------------------------------------------
C	SSU COMPOOL definition
C	----------------------------------------------------------------
C	SINGLE => 16b
C	DOUBLE => 32b
C	SCALAR should always be DOUBLE, and implemented in C with a 32b float
C
C
C	outputs to EIUs
DECLARE EIU_1_CMD INTEGER SINGLE;
DECLARE EIU_2_CMD INTEGER SINGLE;
DECLARE EIU_3_CMD INTEGER SINGLE;
C
C	inputs from EIUs
DECLARE EIU_1_PRIDATA ARRAY(32) INTEGER SINGLE;
DECLARE EIU_2_PRIDATA ARRAY(32) INTEGER SINGLE;
DECLARE EIU_3_PRIDATA ARRAY(32) INTEGER SINGLE;
DECLARE EIU_1_SECDATA ARRAY(6) INTEGER SINGLE;
DECLARE EIU_2_SECDATA ARRAY(6) INTEGER SINGLE;
DECLARE EIU_3_SECDATA ARRAY(6) INTEGER SINGLE;
C
C	output to DDU-1
DECLARE DDU1_HSI ARRAY(10) INTEGER SINGLE;
DECLARE DDU1_AVVI ARRAY(6) INTEGER SINGLE;
DECLARE DDU1_AMI ARRAY(6) INTEGER SINGLE;
C
C	output to DDU-2
DECLARE DDU2_HSI ARRAY(10) INTEGER SINGLE;
DECLARE DDU2_AVVI ARRAY(6) INTEGER SINGLE;
DECLARE DDU2_AMI ARRAY(6) INTEGER SINGLE;
C
C	output to HUD-1
DECLARE HUD1_MSG1 ARRAY(31) INTEGER SINGLE;
DECLARE HUD1_MSG2 ARRAY(12) INTEGER SINGLE;
C
C	output to HUD-2
DECLARE HUD2_MSG1 ARRAY(31) INTEGER SINGLE;
DECLARE HUD2_MSG2 ARRAY(12) INTEGER SINGLE;
C
C	TODO MDM FF1
C
C	TODO MDM FF2
C
C	////
DECLARE OVHD INTEGER SINGLE;
DECLARE IGS INTEGER SINGLE;
DECLARE IGI INTEGER SINGLE;
DECLARE RWID INTEGER SINGLE;
DECLARE LSID INTEGER SINGLE;
C
DECLARE SB_SEL INTEGER SINGLE;
C
DECLARE PRI_ID CHARACTER(5);
DECLARE PRI_HDG SCALAR DOUBLE;
DECLARE PRI_POS ARRAY(3) SCALAR DOUBLE;
DECLARE PRI_G2R MATRIX(3,3) SCALAR DOUBLE;
DECLARE SEC_ID CHARACTER(5);
DECLARE SEC_HDG SCALAR DOUBLE;
DECLARE SEC_POS ARRAY(3) SCALAR DOUBLE;
DECLARE SEC_G2R MATRIX(3,3) SCALAR DOUBLE;
C
C	TODO Landing SOP
C
C	Aerojet DAP FCS
DECLARE AEROJETDAP_FCS_PITCH INTEGER SINGLE;
DECLARE AEROJETDAP_FCS_ROLL INTEGER SINGLE;
DECLARE AEROJETDAP_FCS_SB INTEGER SINGLE;
DECLARE AEROJETDAP_FCS_BF INTEGER SINGLE;
C
C	A/L UPP
DECLARE H SCALAR DOUBLE;
DECLARE HDOT SCALAR DOUBLE;
DECLARE V_T SCALAR DOUBLE;
DECLARE VI SCALAR DOUBLE;
DECLARE KEAS SCALAR DOUBLE;
DECLARE VG SCALAR DOUBLE;
DECLARE X SCALAR DOUBLE;
DECLARE Y SCALAR DOUBLE;
DECLARE Z SCALAR DOUBLE;
DECLARE XDOT SCALAR DOUBLE;
DECLARE YDOT SCALAR DOUBLE;
DECLARE PSD SCALAR DOUBLE;
DECLARE HDG SCALAR DOUBLE;
DECLARE GAMMA SCALAR DOUBLE;
DECLARE PHI SCALAR DOUBLE;
DECLARE COSPHI SCALAR DOUBLE;
DECLARE THETA SCALAR DOUBLE;
DECLARE ALPHA SCALAR DOUBLE;
DECLARE BETA SCALAR DOUBLE;
DECLARE QBAR SCALAR DOUBLE;
DECLARE NY SCALAR DOUBLE;
DECLARE NZ SCALAR DOUBLE;
DECLARE WEIGHT SCALAR DOUBLE;
C
C	///
DECLARE TG_END INTEGER SINGLE;
C
C	Autoland
DECLARE PMODE INTEGER SINGLE;
DECLARE FMODE INTEGER SINGLE;
DECLARE NZ_CMD SCALAR DOUBLE;
DECLARE PHIC_AL SCALAR DOUBLE;
DECLARE RC SCALAR DOUBLE;
DECLARE DSBC_AL SCALAR DOUBLE;
DECLARE DBFC SCALAR DOUBLE;
C
C	////
DECLARE SB_POS SCALAR DOUBLE;
C
(I not 100% sure on the SINGLE vs DOUBLE bit size...)

And the parser would create a .h file with something like this (first 6 variables only):
Code:
// addrs
unsigned int SCP_EIU_1_CMD = 0;// outputs to EIUs
unsigned int SCP_EIU_2_CMD = 1;
unsigned int SCP_EIU_3_CMD = 2;

unsigned int SCP_EIU_1_PRIDATA = 3;// inputs from EIUs
unsigned int SCP_EIU_2_PRIDATA = 35;
unsigned int SCP_EIU_3_PRIDATA = 67;

const unsigned int COMPOOL_SIZE = 99;
const unsigned int COMPOOL_VAR_COUNT = 6;

// name array
const char SCP_name[COMPOOL_VAR_COUNT] = {
"EIU_1_CMD",
"EIU_2_CMD",
"EIU_3_CMD",
"EIU_1_PRIDATA",
"EIU_2_PRIDATA",
"EIU_3_PRIDATA"
};

const unsigned int SCP_addr[COMPOOL_VAR_COUNT] = {
SCP_EIU_1_CMD,
SCP_EIU_2_CMD,
SCP_EIU_3_CMD,
SCP_EIU_1_PRIDATA,
SCP_EIU_2_PRIDATA,
SCP_EIU_3_PRIDATA
};

// type array
// TODO define this better
const unsigned int SCP_type[COMPOOL_VAR_COUNT] = {
1,
1,
1,
2,
2,
2
};
It would contain the addresses for general usage, and a list of addresses, names and types for scenario load/save.
The "general usage" would work (as it is now) by calling a type-specific function to read/write, but it could be more controlled (e.g. for arrays) if we take into account the specific variable size. This probably would be a safer bet, but each read/write would need to go to the SCP_type array to get the size info for the checks, and we could maybe use overload functions to avoid calling Read_INTEGER, and sending the address of a SCALAR.

#### Urwumpe

##### Not funny anymore
Donator
Well, remember that there are multiple COMPOOLs to prevent multi-process issues.

Again, I think the process would need something like:

COMPOOL template source --> default COMPOOL + COMPOOL template
COMPOOL mission instance source --> mission COMPOOL + COMPOOL template

Since the template is the same for the COMPOOL we just need it once. Since we use a C++ implementation, the template should better be a C++ header file. The mission COMPOOL is then a matter of taste. a plain binary file would be enough since we can simply address it as object in C++ and just need to deserialize it for the class. Of course, we could then also simply create a XML template for mission COMPOOL instances. But since we also need to get the data into the mission editor, it might make sense to compile the COMPOOL there, create the needed data structures for creating mission data in a format that works best for the mission editor and just let SSU parse and validate a simple line-wise text file: 32 character variable identifier, 16 characters for subscript, 16 for the value, 15 reserved for extensions, one character as checksum. The basic components for describing the COMPOOL as C++ "user model" would then handle the parsing. And with user model, I mean C++ classes that describe HAL/S data types in a COMPOOL in a way that makes it easy to use them in C++ algorithms. Ideally it is just the HAL/S code with C++ syntax.

Also the memory configurations matter a lot, but I can understand why you rather want to have a "one MC for all" solution.

Last edited:

#### GLS

Well, remember that there are multiple COMPOOLs to prevent multi-process issues.

Again, I think the process would need something like:

COMPOOL template source --> default COMPOOL + COMPOOL template
COMPOOL mission instance source --> mission COMPOOL + COMPOOL template

Since the template is the same for the COMPOOL we just need it once. Since we use a C++ implementation, the template should better be a C++ header file. The mission COMPOOL is then a matter of taste. a plain binary file would be enough since we can simply address it as object in C++ and just need to deserialize it for the class. Of course, we could then also simply create a XML template for mission COMPOOL instances. But since we also need to get the data into the mission editor, it might make sense to compile the COMPOOL there, create the needed data structures for creating mission data in a format that works best for the mission editor and just let SSU parse and validate a simple line-wise text file: 32 character variable identifier, 16 characters for subscript, 16 for the value, 15 reserved for extensions, one character as checksum. The basic components for describing the COMPOOL as C++ "user model" would then handle the parsing. And with user model, I mean C++ classes that describe HAL/S data types in a COMPOOL in a way that makes it easy to use them in C++ algorithms. Ideally it is just the HAL/S code with C++ syntax.
Hmmm, why are we talking about "mission COMPOOLs"??? :uhh: As we only have one version of software, the COMPOOL stuff is fixed, and the only thing that changes are the initial values. So IMO we just need a file with the I-LOADs, and that should work both for COMPOOL and internal module variables.
If I understand you correctly, but maybe only partially, you want to have separate COMPOOLs and implement them as classes? I thought of that a few days ago, but somehow "pCOMPOOL_GNC_whatever->varPOS" doesn't look much better than "WriteINTEGER( SCP_POS, 4 )", even though it would provide "direct access" to the variables. ...I ran out of brain power to write more... wned:

Also the memory configurations matter a lot, but I can understand why you rather want to have a "one MC for all" solution.
Everything matters, but I don't want to spend tons of time on this as I still have a big list of TODOs: A/L to finish, some work in the HUD, and then TAEM and Entry, plus CRT displays, and let's hope getting the new things to the IDPs isn't hard because I don't want to work those busses now.
Anyway IMO we should push the DPS architecture as far as it is needed, otherwise we'll spend years just setting up shop, and then we'll still have to code the software to use it. :shrug:

My head hurts.... and I feel like I did nothing today...:facepalm:

#### Urwumpe

##### Not funny anymore
Donator
Well...... you know how a classic linker works, right? I think the one used for the PASS Software was called PILOT (DaveS might correct me)

When I write MISSION COMPOOL, I meant the COMPOOL object file used for creating the tape image for this mission, which is written on the MMU tape.

Thats how it works - especially in GNC, there are no configuration files, no data files. everything is hardcoded into the binary data (memory overlay) that is loaded from tape into the GPC memory. In SM, there are at least configurable tables, that are still hardcoded into the memory overlay, but easier to prepare for the mission.