[00:51:13] NASSP Logging has been started by thewonderidiot [16:48:12] morning! [17:32:04] hey Mike [17:32:23] .loggingstatus [17:34:59] yeah, had to roll over to a new log last night :P [17:35:31] did banks 36 and 30 in Sundance [17:36:15] new number is 4323 [17:36:30] 2917 of which are coming from banks 31, 32, and 33, the only three banks I don't have lined up [17:37:43] so the detail work begins at close to 1000 left [17:37:54] yep [17:38:15] I think the final number is going to be in the mid-upper 3 digits [17:51:09] I think I am close to do done with this Saturn IB LVDC update [17:51:16] still need to test S-IVB takeover [17:51:18] awesome :D [17:51:31] and then update our few Saturn IB launch scenarios [17:51:47] and test fly if the attitude profile works [17:51:54] orbital attitude* [17:52:13] and after that I'll give the Saturn V the same updates [17:52:34] and then I am ready to launch Apollo 9 with new LM software [17:53:24] excellent, hopefully it will be ready by then [17:54:10] oh, Saturn IB version of the FCC manual is out for delivery today :) [17:54:18] will probably scan that on Friday [18:00:44] great [18:06:32] oh, there is a new mystery in Sundance [18:06:52] I have two addresses for DVTHRUSH, and both look convincing [18:07:11] so I'm not sure if it moved between 292 and 306, or if it used to be two different variables [18:07:41] both addresses are in unswitched erasable and I believe are not shared, so I don't know why it would have moved [18:14:08] looks the same in the GSOP as later on [18:14:31] which routine uses which address? [18:15:19] COPYCYCL in the SERVICER uses 1251 [18:15:37] everything else uses 1201 [18:16:14] 1251 in Luminary [18:16:35] hmm, interesting [18:17:33] I guess for it to work right the correct fixed constant needs to be copied to it [18:17:36] oh, the 1251 address does share with SCAXIS [18:17:48] SCAXIS is weird in Sundance [18:17:56] it's a vector as far as I can tell [18:18:15] but only the first two locations of it are unshared [18:18:31] after that it overlaps with AVEGEXIT, DVTHRUSH, and maybe other things [18:18:37] looks like it's the vector for VECPOINT [18:21:18] so other things about this [18:21:23] 1251 is from Sundance 292 [18:21:33] 1201 is from Sundance 306 [18:21:43] 1251 is only read from, 1201 is only written to [18:21:50] uhoh [18:21:56] haha [18:22:11] Sundance and Luminary have three fixed values for DVTHRUST [18:22:17] which are loaded based on configuration [18:22:23] hep [18:22:28] *yep [18:22:30] I can see that [18:22:49] THRESH1, THRESH2, and THRESH3 are the same as in Luminary [18:23:01] so I'm very confident that Sundance 306 is using 1201 as DVTHRUSH [18:23:03] DPS LM only, DPS docked, APS LM only [18:23:38] there is a PCR in Sundance for that, but only changes the values I think [18:23:47] probably implemented after Apollo 5 [18:24:28] oh, this is interesting [18:24:34] in Luminary [18:24:47] it has THRESH1, THRESH2, THRESH3 but also DPSTHRSH [18:24:55] and DPSTHRSH is only for P63 it seems [18:25:03] THRESH1 + THRESH3 [18:25:52] so in that way having different logic and even different erasable address for servicer (P63) vs. the other thrust programs could make sense [18:26:24] "1201 is only written to" in that part of the code or in all of Sundance? [18:26:38] all of Sundance [18:26:57] THRESH1, THRESH2, THRESH3 are written into 1201 [18:27:13] DVMON in SERVICER reads from 1251 [18:27:24] the noun table points to 1201 [18:27:28] hmm [18:28:34] it's seeming like the most likely scenario is it was moved [18:28:43] otherwise the DVMON couldn't possibly work [18:28:47] ah DVMON is in Servicer [18:28:51] yeah [18:29:18] I'd say let's use 1201 [18:29:24] yeah [18:30:32] Sundance 306 is also writing to 1202 [18:30:37] and nothing ever reads that [18:30:40] so I'm not sure what that's about [18:31:13] 1252 is AVEGEXIT, but that didn't move [18:31:56] where does it write to 1202? I can check if it looks like something I know [18:32:19] both P40LM and P42LM write a 1 into it, in between setting up DVTHRUSH and DVCNTR [18:39:10] hmm [18:39:11] no idea [18:39:57] yeah [18:40:03] I think it is probably unimportant [18:40:14] ...but I guess I should be careful saying such things haha [19:13:43] well I guess anything important we are missing should be noticable in some way [19:20:04] that's one of the nice things of being able to give the AGC software a full workout [19:23:47] yeah [20:05:36] S-IVB takeover works well [20:05:57] not that I changed much for it, the new LVDC attitude control just needed some things being nulled when control is given back to the LVDC [20:14:44] awesome [20:15:21] nice and smooth return back to the orb rate attitude [20:17:31] unfortunately the attitude maneuver after that, controlled by the LVDC, did not work correctly :D [20:19:41] ah, wrong padload [21:23:20] night!