Space Shuttle Ultra 1.25 Revision B development

[n72.75]

I found these, if they're any use.

http://klabs.org/richcontent/software_content/hal_s/hal-s_language_specification.pdf

http://klabs.org/richcontent/software_content/hal_s/programming_in_hal-s.pdf

http://klabs.org/richcontent/software_content/hal_s/hal-s_compiler_system_specification.pdf


Is it overkill to write a compiler? It could be useful.

 

[Urwumpe]

I found these, if they're any use.

http://klabs.org/richcontent/software_content/hal_s/hal-s_language_specification.pdf

http://klabs.org/richcontent/software_content/hal_s/programming_in_hal-s.pdf

http://klabs.org/richcontent/software_content/hal_s/hal-s_compiler_system_specification.pdf


Is it overkill to write a compiler? It could be useful.

I already have the complex HAL/S manual set, including an older manual from bitsavers.

If you want to write a HAL/S-FC compiler that translates HAL/s source into IBM Basic assembler source files, I can help you, I started work on one, but had to stop it for more low level stuff. For this task, I also have a nearly complete set of the FCOS calls, which correspond to language constructs in HAL/S (eg WAIT, SIGNAL or SCHEDULE), including the calling convention for such operating system calls.

Emulating the code would have some advantages since we can then run the software without needing to care for time steps, the next better alternative would be a virtual machine. The "C++ wrapper for HAL/S types" concept is also pretty, but would take much longer in development as a emulation eventually - making C++ behave like FCOS in Orbiters timestep structure is pretty complicated. And the way how new displays are loaded is pretty complex already in HAL/S...and now imagine making a complex C++ function simulating a complex HAL/S function that is based on FCOS functions....

I'll do an assembler then, most stuff except the application software is written in assembler according to statistics. I have already a good start with the MDM PROM assembler, in wise preparation, I already made it use the IBM assembler conventions. :lol:

The next tool set that would then be needed is about producing magnetic tape image files, that could be mounted into SSU. I have seen a number of structures in the description of FCOS, about the file system on the magnetic tape. There would be just the need to mix a master software tape with the I-Loads for each mission...

 

[n72.75]

I can work on an HAL/S-FC to IBM BAL translator.

 

[Urwumpe]

I can work on an HAL/S-FC to IBM BAL translator.

Thank you And please don't forget the macro support, the application interface works by small macros in the HAL/S code.

This one might be interesting for you:

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770075091_1977075091.pdf

 

[DaveS]

We still don't have the real software images, but I have the flow charts of around 95% of the first revision of the FCOS software from the ALT test flights, which would be enough for the start.

Maybe we should start at the ALTs and evolve from there? That way we should get a stable platform going first and the we can worry about orbital functions.

Right now as it is, the RSLS is broken anyway so we're not going anywhere so what we have is Enterprise.

 

[Urwumpe]

Well, we would then need a Ultra-trademark-worthy Boeing 747... :lol:

I think we can get the broken stuff added quickly if a HAL/S compiler is around, RSLS is for example pretty much a simple process residing in the OPS1 memory area, that reacts to LDB messages, or gets events from an process handling LDB messages.

 

[n72.75]

Thank you And please don't forget the macro support, the application interface works by small macros in the HAL/S code.

This one might be interesting for you:

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770075091_1977075091.pdf

I think I'll print it out and read the whole thing...

 

[Urwumpe]

I think I'll print it out and read the whole thing...

I know that feeling. I have now printed around 30% of it, because reading it on the PC is getting annoying after a while. :lol:

 

[DaveS]

Could someone please clean up the scenario file entries? Here's my notes:

• ODS, RMS, STBD_MPM should be deleted as they're managed by the Mission File Manager
• MET* entries should be tied to the MTU subsystem section, possibly replaced by the MTU
• Ascent AP entries should also be deleted as they're managed by the Mission File Manager
• PLBD_CAM lines should be moved into their own subsystem section, like CCTV

This should be sufficient to clean up and make the scenario files better structured. Right now we're mixing old with new and only creating confusion in the process.

 

[Poscik]

I noticed, that typying ITEM 27 EXEC in OPS202 arms TRK CUR in OPS201, so that maneuvering to burn attitude is impossible now.

 

[DaveS]

I noticed, that typying ITEM 27 EXEC in OPS202 arms TRK CUR in OPS201, so that maneuvering to burn attitude is impossible now.

You can also just use DAP in LVLH mode and maneuver manually to the burn attitude.

 

[SiameseCat]

I noticed, that typying ITEM 27 EXEC in OPS202 arms TRK CUR in OPS201, so that maneuvering to burn attitude is impossible now.

What do you mean by this? You shouldn't be seeing the OPS 202 and 201 displays at the same time. ITEM 27 uses the same code that's used for the TRK command in 201, so this might be what's happening. As long as ITEM 27 causes the orbiter to move to the burn attitude, I don't think this is a problem.

 

[DaveS]

What do you mean by this? You shouldn't be seeing the OPS 202 and 201 displays at the same time. ITEM 27 uses the same code that's used for the TRK command in 201, so this might be what's happening. As long as ITEM 27 causes the orbiter to move to the burn attitude, I don't think this is a problem.

I can say that it isn't maneuvering the orbiter to the proper attitude. Instead it is tracking the attitude specified in MM201. And ITEM 27 doesn't have a * next to it in MM202. This is if you check after the burn and go back to MM201.

 

[Poscik]

I just noticed, that when ITEM 27 was active, there was * near it. Now it isn't. Also when doing ITEM 27 EXEC, then setting DAP to AUTO, shuttle isn't maneuvring to burn attitude. Also reqd rates in OPS201 are not correct.

EDIT: Aaaah Dave was first

 

[Urwumpe]

I just noticed that we can maybe fix the docking sequence of SSU now, by using the SetDockMode function...must haved missed this badly needed feature,I hope it works.

 

[DaveS]

I just noticed that we can maybe fix the docking sequence of SSU now, by using the SetDockMode function...must haved missed this badly needed feature,I hope it works.

That would be nice!

 

[Urwumpe]

That would be nice!

yeah, the ODS Ring position would then have a function. :lol:

 

[DaveS]

yeah, the ODS Ring position would then have a function. :lol:

Indeed it would! The DS power lights have stopped functioning so they would need fixing.

 

[Urwumpe]

Indeed it would! The DS power lights have stopped functioning so they would need fixing.

Is in work, would fix this then when unifying the other VC elements, having only a static texture in use there, that can reside in GPU memory.

 

[SiameseCat]

I can say that it isn't maneuvering the orbiter to the proper attitude. Instead it is tracking the attitude specified in MM201. And ITEM 27 doesn't have a * next to it in MM202. This is if you check after the burn and go back to MM201.

I can't reproduce this problem - for me, ITEM 27 works fine. What I've been doing is:
1. In OPS 201, start TRK maneuver.
2. Put DAP in AUTO, so shuttle rotates to TRK attitude.
3. Change to OPS 201 and setup burn.
4. Enter ITEM 27 - shuttle rotates to burn attitude (but * is not displayed).
Can someone post steps to reproduce the ITEM 27 issue?