Meadville Space Center
Welcome, Guest. Please login or register.
November 24, 2020, 03:36:10 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2267 Members
Latest Member: Apollo Next
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Planning (Moderators: movieman, Swatch, lassombra)
| | | |-+  The great AGC++ purge: A proposal
« previous next »
Pages: [1] 2 Print
Author Topic: The great AGC++ purge: A proposal  (Read 3643 times)
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« on: January 13, 2017, 11:20:50 PM »

So, I'm working on the code to better implement standby, and I just realized something: with all the C++ AGC legacy code floating around in all these classes, I have a hard time telling what's supposed to be vAGC-exclusive, AGC++-exclusive, or a combination of the two. So, I would like to propose that we should flush our codebase of the C++ AGC code, since I don't think we're ever going to return to that code anymore.

Is this a good idea, or am I talking madness?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #1 on: January 14, 2017, 07:28:46 AM »

No objection. I had some similar problems when I worked on the LM code. The old AGC/lunar landing autopilot was still interfering with the DSKY. That's why it used to display P70 sometimes, because of the inverted input channel logic the old AGC thought an abort has been called for. The lunar landing autopilot is actually still in the current version as well, so that can also be removed.

And once the LVDC code is completely moved into the IU and it can hold attitude for TD&E, then the old IU GNC stuff can be removed, too.
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #2 on: January 14, 2017, 10:07:26 AM »

As far as I know nobody is using it. We'll probably break it when we start dumping things for V8, so as far as I am concerned it can go away.

The only notable thing I can think of related to it was there was a bunch of de-Americanization stuff we were supposed to enable later in the project that was going to be done in the AGC++ only because doing it to the actual software would be too much effort. Nobody has complained about the lack of this (or even mentioned it) in several years so unless someone is still offended we can just pretend we forgot about it.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #3 on: January 14, 2017, 10:13:02 AM »

One reason to keep it might be Skylab. We don't have Skylark, the AGC version flown on these missions, and we might never find Skylark. I know a few good documents about the Skylark rendezvous programs, which are more extensive than for the lunar missions, so potentially I would be able to use the AGC++ to implement the rendzvous programs. But we might as well use an earlier AGC version, let the RTCC do some of the ground calculations and start the onboard phase with TPI or NCC2 or so. The ground solutions were the primary anyway, so it's not a terrible loss if we can't do it onboard.
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #4 on: January 14, 2017, 10:16:00 AM »

Which is newer, Skylark or Zerlina?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #5 on: January 14, 2017, 10:19:55 AM »

Zerlina is for the LGC. It was branched off some time before the J-Missions and then developed concurrently: http://www.ibiblio.org/apollo/AGC-versions.jpg
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #6 on: January 14, 2017, 11:05:32 AM »

Well,the idea was if Zerlina was found and was that late in the game, there's still a chance Skylark might turn up if they were developed in the same timeframe.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #7 on: January 14, 2017, 11:15:57 AM »

Potentially. Zerlina is from the private collection of Don Eyles, who was one of the LGC developers. I don't think he has anything about Colossus and derivates.
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #8 on: January 16, 2017, 03:29:14 PM »

OK, sounds like a consensus.

Now the tricky part—the AGC++ code is spread throughout multiple different source code files. The biggest offenders are:

  • CSMcomputer.cpp
  • apolloguidance.cpp
  • DSKY.cpp
  • dskyinterface.cpp

From what I can see, vAGC-related code and AGC++ related code is mixed freely. I originally thought certain source files were strictly AGC++ implementations and the others were interfaces to the vAGC engine, but it's more complicated than that.

Daniel, do you have a good guideline as to what I can excise safely? Unless I'm mistaken, some of the code comments dating back to 2004 are signed by you...
« Last Edit: January 16, 2017, 04:17:10 PM by eddievhfan1984 » Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #9 on: January 16, 2017, 04:11:28 PM »

Personally, I would comment out everything and see what blows up, then uncomment things one at a time. When it builds again check things out, and if it survives you can start eliminating what remains commented out. If we go too far we can always get things back from git history.
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #10 on: January 16, 2017, 05:30:42 PM »

Yeah, trying that. Problem is, there's so many external function calls, I can't figure out where I should kill them all.

I've been setting up a project to model a standalone CM, though, so we can add in systems elements a bit at a time, in a nicely modular fashion. If I can. Tongue
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #11 on: January 16, 2017, 07:10:45 PM »

That's going to need to happen eventually anyway, so make sure you're doing this in the V8 branch.
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #12 on: January 16, 2017, 08:40:59 PM »

I'm doing this in my own fork, Orbiter2015 branch. If anyone can help with the modularization, that'd be great. Tongue
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #13 on: January 17, 2017, 06:02:37 AM »

As far as I know nobody is using it. We'll probably break it when we start dumping things for V8, so as far as I am concerned it can go away.

The only notable thing I can think of related to it was there was a bunch of de-Americanization stuff we were supposed to enable later in the project that was going to be done in the AGC++ only because doing it to the actual software would be too much effort. Nobody has complained about the lack of this (or even mentioned it) in several years so unless someone is still offended we can just pretend we forgot about it.


De-Americanization? Was that just putting everything in metric?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #14 on: January 17, 2017, 07:00:58 AM »

I'm doing this in my own fork, Orbiter2015 branch. If anyone can help with the modularization, that'd be great. Tongue

I'll surely help with that. After NASSP 7.0 is released.

De-Americanization? Was that just putting everything in metric?

Yes. But who uses metric in aerospace anyway, just Russia and China. I can easily live with feet, feet per second and nautical miles.
Logged
Pages: [1] 2 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!