[04:01:10] NASSP Logging has been started by thewonderidiot [04:01:12] indy91: okay so I'm not super happy with this [04:01:51] but if I shift stuff around in LDPLANET a bit, from this: [04:01:53] TC INTPRET [04:01:53] VLOAD [04:01:54] STARSAV3 [04:01:54] VXSC UNIT [04:01:55] 1/SQR3 [04:01:55] STORE STARSAV2 [04:01:56] GOTO [04:01:57] P23.31 [04:01:58] to this: [04:02:05] TC INTPRET [04:02:06] VLOAD VXSC [04:02:06] STAR [04:02:07] 1/SQR3 [04:02:07] UNIT [04:02:08] STORE STARSAV2 [04:02:09] GOTO [04:02:09] P23.31 [04:02:36] that completely fixes the bank 16 checksum and I get an assembly with all checksums matching for Comanche 44 [14:02:58] hello [14:15:40] good morning :) [14:16:31] hey Ryan. [14:16:54] welcome back [14:18:40] Thanks! [14:18:48] Life gets in the way sometimes [14:19:45] I am excited to see where things are [14:22:12] it does. not a bad thing though. I took a couple months off in end of summer to get married this year [14:22:57] if done a bunch of work on RF systems [14:23:07] *I've [14:28:23] all antennas now use Friis equation model of signal strength [14:29:08] and the RR and vhf ranging now use connectors rather than calling each others functions [14:29:47] Congrats! I got engaged myself this summer :) [14:30:00] And I am excited to play with things as they are now and get back into the systems [14:30:00] that's just what I've added. currently breaking the fuel cell code [14:30:05] lol [14:30:13] congrats! [14:30:16] Well I will be breaking the substances again [14:30:30] I still have all the corrected values but they require breaking the game to implement [14:42:27] hey guys [14:47:37] hey [14:58:46] morning [15:06:40] I still cannot seem to get NASSP to launch [15:08:34] it was build correctly? [15:08:45] what error are you getting? [15:09:50] yep built just fine [15:10:12] Exception thrown at 0x07099A8B (D3D9Client.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0x00000000. [15:10:35] same as yesterday [15:11:20] maybe something with the video settings [15:11:27] does the DX9 Client log say something? [15:12:23] where is that [15:12:40] I have the orbiter logs but no dx9 client log [15:13:05] Modules\D3D9Client [15:13:57] the hdml file? [15:14:06] yep [15:14:14] wont open [15:14:39] browser window says site cant be reached and notepad++ wont open it [15:15:24] hmm [15:15:49] In orbiter log: [15:15:50] 000000.000: >>> WARNING: Obsolete API function used: oapiBlt [15:15:51] 000000.000: Colour key argument not supported by graphics client [15:15:55] normal [15:15:59] Thought so [15:16:14] this is a fresh install of everything too [15:16:19] so I am quite confused [15:16:25] you are using Orbiter_ng.exe? [15:16:28] yep [15:16:35] unless I got a bad download of the dx9 client [15:16:36] and activated the DX9 client module and did the video settings [15:16:45] any particular video settings? [15:16:48] what version of the DX9 client did you download? [15:16:53] latest [15:16:54] just that it has any resolution [15:17:02] what version exactly [15:17:03] D3D9ClientR4.11-forOrbiter2016(r1355) [15:17:07] sorry was grabbign it [15:17:09] that's wrong [15:17:15] oh [15:17:20] there is a separate version for the Orbiter Beta [15:17:50] derp [15:18:17] maybe I need to RTFM [15:20:16] that was it [15:20:50] ah great [15:21:44] Think I might jump into an apollo 9 just to reacclimate myself before jumping back into things [15:24:37] New computer build so maybe I will crank the graphics :) [15:28:26] morning! [15:28:59] hey Mike [15:29:11] early for you haha [15:29:30] banksum working out is a good argument [15:29:40] but explain to me the thought process of changing that routine again :D [15:30:08] both versions of LDPLANET seem to do the same thing, same number of words [15:30:17] any reason why one version would be inferior? [15:30:59] no, they're exactly the same [15:31:24] I was just trying out random things, and was messing around in LDPLANET because I don't trust it [15:31:31] right [15:31:46] I don't really like it because I don't know why they would have bothered to make such a change [15:31:58] but it does perfectly explain the checksum difference... [15:32:14] yeah, that would be a weird thing to change again [15:33:40] Artemis has things grouped like that, strangely [15:33:51] although it has the UNIT and GOTO on the same line [15:35:50] yeah that is strange [15:36:37] could Comanche 45 help us with this? [15:36:53] if the banksums work out, does that say anything about LDPLANET? [15:37:01] possibly [15:37:26] but then we are messing around with bank 16 a bunch anyway [15:37:27] although I'm not quite sure what to do with 45 lol [15:38:03] I guess we have to retrace the steps they took to fix it without moving addresses [15:38:19] although judging by LDPLANET, following their "logic" might be difficult lol [15:40:15] heh yeah [15:40:21] so just for confirmation [15:40:34] this is what happens if I just stick the fix as seen in Comanche 51 directly into S40.1: [15:40:36] Bugger word mismatch in bank 01; actual 50110 != expected 50116 (diff = 00006) [15:40:37] Bugger word mismatch in bank 05; actual 74460 != expected 74466 (diff = 00006) [15:40:37] Bugger word mismatch in bank 11; actual 44656 != expected 44661 (diff = 00003) [15:40:38] Bugger word mismatch in bank 14; actual 47774 != expected 47777 (diff = 00003) [15:40:38] Bugger word mismatch in bank 15; actual 70257 != expected 70265 (diff = 00006) [15:40:39] Bugger word mismatch in bank 16; actual 46116 != expected 57374 (diff = 11256) [15:40:39] Bugger word mismatch in bank 17; actual 50460 != expected 73163 (diff = 22503) [15:40:40] Bugger word mismatch in bank 24; actual 55765 != expected 56001 (diff = 00014) [15:40:41] Bugger word mismatch in bank 32; actual 65506 != expected 65511 (diff = 00003) [15:40:42] make: *** [Makefile:21: diffComanche045sums] Error 9 [15:40:48] lots of banks get mad [15:41:24] because of references [15:41:26] mostly [15:41:29] yep [15:43:13] bank 24 will be the S40.9 reference [15:44:55] the likely place for the jump is at 16,2030 [15:45:25] jump somewhere else, do calculations, jump back and have the same number of words [15:46:04] I wonder if they moved that whole UT calculation with it [15:46:10] if they had enough space somewhere [15:47:22] hmm [15:47:35] so you think they changed it 16,2030 to "SETPD GOTO" or something? [15:48:17] just a goto [15:48:31] and then do the DELVSAB calculation somewhere else [15:48:33] and jump back [15:48:57] just GOTO doesn't work, because both SETPD and VLOAD take an argument [15:49:00] and because that changes the number of words, maybe they did some parts of the following code in the other location as well [15:49:02] changing to just GOTO there would drop a word [15:49:12] hmm [15:49:50] a single goto probably adds one word [15:50:06] so in the other location they maybe did SETPD 0 [15:50:20] and then have a reference to the VLOAD VTIG [15:50:22] would that work out? [15:50:41] I'm not following [15:50:58] can you type out the code you're thinking of? [15:51:12] uhh, I can try [15:51:41] in 16,2030: GOTO ELSEWHERE [15:52:00] and in elsewhere it does the DELVSAB calculation [15:52:05] and also SETPD 0 at the end of it [15:52:10] and then it goes back to 16,2031 [15:52:16] VLOAD [15:52:17] VTIG [15:52:27] and STORE VINIT is then still at 16,2033... maybe? [15:52:54] GOTO and its target don't go on the same line [15:52:58] so it would be [15:53:04] ah right [15:53:07] 16,2030: GOTO [15:53:07] 16,2031: ELSEWHERE [15:53:20] and then there's an awkward extra word that we have to fill in [15:53:36] GOTO VLOAD [15:53:39] ELSEWHERE [15:53:40] VTIG [15:53:58] nope, it's illegal to have anything on the same line following a goto [15:54:12] right, that wouldn't work haha [15:54:58] but I am fairly convinced that the jump should be at 2030, that's the best place really [15:55:14] yeah [15:55:17] what's that large difference to bank 17? [15:55:32] in* [15:55:35] I'm pretty sure that's where we're GOTOing to [15:55:41] right [15:55:53] jump to bank 17 to set DELVSAB, jump back [15:56:25] hmm [15:56:31] so where in bank 17 could it go [15:58:18] 3740? [15:58:51] if possible, better not to move around bank 17 references [15:59:40] yeah [16:00:02] should be enough memory there [16:00:43] SETPD GOTO makes the banksum very close [16:00:45] maybe we can figure it out how much the elsehwere routine does by looking at bank 17 banksum [16:00:53] for 16 [16:01:06] hmm yeah maybe [16:04:06] maybe they also "fixed" LDPLANET in 45 [16:05:28] I doubt it [16:06:10] probably would have been done when changing STAR to STARSAV3 [16:11:02] you know what's weird? [16:11:34] http://www.ibiblio.org/apollo/ScansForConversion/Comanche055/0710.jpg [16:11:38] look at the punch card numbers [16:12:19] the patch has the main sequence, while the code that was originally there in Colossus has inserted numbers [16:12:28] except for the STORE VINIT [16:14:09] so maybe they put the patch directly into bank 16 and moved the SETPD VLOAD into bank 17 [16:16:21] SETPD, VLOAD and a bunch of other stuff [16:19:23] so you think it's like in C55 until 16,2032 [16:19:32] then the GOTO [16:21:57] something like that? [16:26:21] 16,2033 GOTO [16:26:22] 16,2034 ELSEWHERE [16:26:27] 16,2035 UNIT [16:26:32] and elsewhere does [16:26:39] ELSEWHERE [16:26:39] SETPD VLOAD [16:26:40] 0 [16:26:40] VTIG [16:26:41] STORE VINIT [16:26:41] VXV [16:26:42] RTIG [16:26:43] GOTO 16,2035 [16:27:00] and 16,2036 is unchanged [16:27:01] 16,2036 27713 STOVL UT [16:27:06] does that work? [16:28:39] hmm, bank 16 doesn't really like that [16:34:07] so with orbitersound 5 is there a way to stop that popup from continuously showing up? [16:34:35] https://www.dropbox.com/s/84w8xvz881agmny/Screenshot%202020-11-25%20113420.jpg?dl=0 [16:34:53] if you find a way please tell me lol [16:35:22] haha [16:45:17] these patches are much harder to figure out in interpretive code :P [16:53:29] oh btw, the main document I use for this LVDC update, flight program language requirements, was written by M&S Computing, Inc. [16:53:45] which was founded by people working at IBM Federal Systems Division [16:53:52] working on Saturn and Skylab software [16:53:55] oh nice [16:54:00] so they should know what they are talking about :D [16:58:11] there is some special logic to get S-IVB cutoff exactly on time. But that logic only seems to work for the first S-IVB burn, so earlier today I did a TLI that didn't cut off until S-IVB ran out of gas [16:58:35] today would be a good day to find a Saturn V EDD :D [17:09:38] hahaha I feel like you could say that about most days :D [17:11:31] haha [17:11:41] I do say that on most days [17:33:23] I suppose its better than saying "bad" when someone makes a boo boo :) [20:20:19] the alternative way to cut off the S-IVB engine is about 0.02 seconds slower, how terrible [20:22:04] oof yeah that seems borderline unacceptable :P [20:24:19] it's interesting how software has to deal with hardware limitations of the switch selector [20:25:06] switch selector routine writes stage and channel to the switch selector and then schedules itself again with a delay, so that the relays can energize [20:25:59] and then after it checks the relays are set, it issues the read command which actually causes the command to be sent to the stage [20:26:15] and then it schedules itself again to reset the relays. and then again for a hung stage check [20:26:40] and all this combined means it can't issue commands at a rate greater than every 0.1 seconds [20:28:12] huh, interesting [20:32:35] Hey [20:35:45] rcflyinghokie: Congrats on getting engaged! [20:35:52] Hey! [20:35:54] And thanks! [20:36:04] I figured after 8 years it was time ;) [20:36:50] and yes congratulations! [20:37:25] oh yes* [20:40:10] congratulations indeed! :D [20:40:29] Haha [20:40:29] oh and we were so looking forward to you returning that we left all the checklist work as it was, so that you have it to yourself [20:40:45] Why that is so sweet of you all [20:41:01] Actually i dont mind as I had my own little flow to it :) [20:41:15] I made it worse actually. The CSM high gain antenna rotary switches now have 2x as many positions [20:41:23] I think it had 8 before, now they have 16 positions [20:41:33] but that screwed up the positions in the checklist [20:42:16] I think I added that when n7275 implemented auto tracking [20:43:25] noticed that recently [20:43:53] I am making new scenarios btw as my LVDC update will break old scenarios [20:44:14] so I'll at least replace all Apollo 8-11 scenarios through TLI [20:49:57] Ok I can take a look [20:50:04] Any other major changes? [20:54:07] hmm, don't think so [20:54:35] one side effect of the VCs is that large mesh and texture files have to be loaded [20:54:41] and the LM gets created at CSM separation [20:54:59] so for me there is a multiple second long freeze right now when you do CSM sep [20:55:03] loading the LM [20:55:13] that's pretty bad, we have to improve that [21:07:58] Hmm [21:08:18] Is there any way to like "preload" that? [21:09:06] maybe it can be loaded globally. The LM mesh is already present before CSM sep of course, in the SLA [21:09:29] long term solution is to have stages docked together on the launch pad, including the LM [21:10:06] oh that might another major change [21:10:15] Apollo 5 now already works with docked stages together [21:12:19] https://i.imgur.com/LBa6uOt.png [21:13:47] <3 Apollo 5 [21:14:01] by the way I'm getting very close to the end of turning Aurora into punchcards, so I'll be starting up Sunburst here soon [21:14:12] ah fun [21:14:15] nice [21:14:40] I'm done with all of the "normal" aurora stuff and just have all of the weird DAP things at the end left, haha [21:15:18] but hopefully tonight you can solve Comanche 45 first :P [21:15:26] lol I'll mess around with it more [21:15:27] provided we actually solved 44... [21:15:44] I don't think our 44 solution will have any bearing on whatever 45 thing we come up with [21:16:20] because the words we're changing out are not really ambiguous, since they're definitely the same as C249 [21:16:48] so the contribution to the banksum from the little section that we're changing would be the same regardless [21:16:54] if that makes sense lol [21:17:10] yeah, I think so [21:17:22] the more I think about it though, the more confused I am about the bank 17 change [21:17:42] because if they were jumping to the end of bank 17, why not just jump to the end of bank 16 instead? [21:17:55] is there enough room there? [21:18:02] yeah, bank 16 has even more room than 17 [21:18:11] hmm, that is weird [21:18:30] is there definitely a big jump in the banksum of bank 17 from C44 to C45? [21:18:45] or is that a reference that shifted [21:18:52] in your C45 version [21:20:36] yeah bank 17 banksum changed from 50463 to 73163 between C44 and C45 [21:21:14] bank 16 changed from 70262 to 57374 [21:21:20] and those are the only two banks with different checksums [21:21:25] right [21:21:50] I wonder if both bank 17 checksums ending with 63 is a coincidence [21:23:36] is there anything in bank 17 that has to do with this issue? [21:23:44] even vaguely related... [21:26:01] some constants [21:26:16] for P40 at least [21:27:00] maybe they moved THETACON or something to make room... [21:27:25] although just straight moving that to bank 17 will make other banks in other modules that reference bank 17 mad [21:28:47] could they have fixed any of the other issues that got originally postponed to Colossus 2A? [21:29:15] TVCINIT is in bank 17, of course haha [21:29:27] hmm, like what? [21:29:52] I feel like Norton would have made note of most of those things [21:30:11] true [21:31:32] like half of bank 17 is jetselect, definitely no change there [21:32:25] oh more than half [21:33:43] in any case, I think it's still the best guess to put our "elsewhere" routine in there and see what happens to it [21:34:29] my current approach is to try adding GOTOs or CALLs or STCALLs in various ways to S40.1 [21:34:46] and then based on the resulting checksum, looking at where that jump address would have to be for it to be correct [21:39:07] makes sense, given the little information we have [21:43:40] oh, and the lack of a bar by this in the Norton document means that the jump (assuming there is one) does have to go where we think it does [21:44:11] i.e. the calculation is definitely the same, and definitely done before the Vinit = Vtig [21:45:10] how can there not be a jump? [21:46:44] could* [21:52:53] well, if THETACON moved that buys two words [21:53:09] ah right, and we don't need much [21:53:12] that could make sense [21:54:30] but that's only two and we need three lol [21:55:30] just negotiate it down to 2 with Comanche, that should work [21:55:48] haha [21:57:29] and moving one of the other constants in bank 16 probably doesn't help [21:58:28] yeah, because the real problem is the references to S40.1 and S40.9 from bank 24 [21:58:46] *S40.8 [21:58:54] THETACON is the only constant between those two labels [22:03:25] yeah [22:04:32] well good luck with that [22:04:36] night! [22:04:38] night! [04:16:50] oh good. I've broken all the mission scenarios with a CSM/Saturn in them.. [05:59:16] sounds like you just barely beat Niklas to it :D [14:12:54] All the -30 second scenerios now make good abort practice [15:26:07] hey [15:43:40] hey Alex [16:30:21] hmm, this new way of doing orbital attitude maneuvers doesn't really work with Apollo 9 [16:30:31] it's tricky to find a system that works with all missions... [16:38:28] but I think I'll have to do an update to the orbital guidance, hopefully the last new feature [16:42:05] ah, right [17:03:58] morning! [18:00:35] hey Mike [18:53:58] what's up? [19:02:19] broke Apollo 9 attitude timeine, need a better system for dealing with attitude maneuver for all missions in the LVDC [19:02:24] timeline* [19:02:48] I guess the lack of early morning chat message means you haven't found Comanche 45 yet [19:02:58] yeah not yet [19:03:12] it's annoying because there really are only a few ways they could have done this lol [19:03:25] yeah [19:03:28] I'm confident that we'll get there eventually [19:03:49] if I don't get it in the next week or so I'll send out a message to the mailing list to see if other people are interested in trying [19:03:54] I'll not use Comanche 44 in NASSP at least haha [19:03:59] hehehe [19:05:05] in the mean time, I found another EBANK= bug in pyul [19:05:17] it's permamently accepting one-shots instead of forgetting them [19:05:27] I probably have another inequality backwards somewhere or something [19:07:34] annoying [19:07:49] yeah the mailing list might be able to help, as it's probably a fairly contained problem [19:18:06] I think I failed De Morgan's law again [20:01:04] haha [20:01:14] I failed even simpler logic [20:01:19] XOR is not the same as "NOT AND" [20:01:54] not and is used in the translated LVDC code to set a flag back to 0 [20:02:16] for some reason I thought X ^ Y would work (Y being a mask) [20:02:27] X & (~Y) was the right solution [20:11:27] hahaha [20:11:47] I think I did have a logic problem there but it wasn't my only issue [20:12:01] I am falling very far down this ebank rabbit hole [20:38:34] this attitude timeline issue is one of those where I have to just think about it for a day or two and not do bad coding attempts [20:39:47] hahaha [20:47:30] or reading the AS-206RAM orbital guidance code, that would also help :D [20:47:42] but I'll not ask you about anything with the name guidance in it lol [20:51:34] haha thanks [20:51:35] also FINALLY [20:51:38] I found my problem [20:51:43] aha! [20:51:46] I had misread a MAX AD SET +1 as a MAX AD SET -1 [20:51:56] I see a difference there [20:52:05] so it was taking a complex path that ended up with the ebank register being updated when it should not have been [20:52:54] ouch, sounds difficult to find [20:53:30] I had like a dozen things being printed out to the listing for every line [20:53:32] the printout was a disaster lol [20:54:30] haha [20:54:55] I was chasing a bug that didn't exist yesterday because of bad luck [20:55:11] remember the TB5 start condition for AS-206RAM? [20:55:14] acqusition of signal [20:55:25] LVDC does a calculation for AOS every 8 seconds [20:55:41] once it has detected that it sends a short sequence of 4 switch selector commands to S-IVB and IU [20:55:52] and I was testing a different switch selector sequence [20:56:08] and by chance the AOS sequence happened shortly after starting a scenario I had saved [20:56:13] hahahaha oh man [20:56:26] so I was expecting one sequence in the LV log [20:56:29] but saw the other one [20:56:35] terrible bug [20:56:38] or just bad luck... [20:57:43] I have another bad one [20:57:48] LVDC major loop [20:58:07] I have the code run that the right interval [20:58:11] DT_N is the interval [20:58:32] I have a variable sinceLastCycle which accumulates time. Once it's greater than DT_N it does a major loop [20:58:40] that is how I am timing the major loop [20:58:58] DT_N depends on the current phase. A major loop takes about 1.7 seconds during IGM [20:59:10] less than that in other phases [20:59:23] oh interesting [20:59:23] so what happens if sinceLastCycle is at about 1.6 seconds [20:59:31] and then it switches to another phase [20:59:37] where DT_N is shorter [20:59:42] major loop is run immediately [21:00:22] so I had a major loop run at exactly a time base start, when the IGM wasn't running anymore [21:00:40] and I couldn't figure out for a while why it did a major loop at exactly TB7+0.0000000 seconds :D [21:00:47] hahaha [21:00:55] am I resetting sinceLastCylce to 0 somewhere???? [21:01:10] or worse to a large number [21:01:12] or DT_N is 0 [21:01:15] so how are you fixing it? forcing it to count all the way up to the previous DT_N before switching in the new one? [21:01:18] so many possible bugs [21:01:28] or does it not matter? [21:01:40] well it does somewhat matter [21:01:53] I just had to move a bit of code to the time base 5 and 7 start functions [21:01:59] or else it runs another IGM cycle [21:02:20] after the first S-IVB cutoff it had already reset the flag salad for TLI [21:02:28] and then running another IGM cycle is bad [21:02:33] as it thinks it's starting TLI [21:03:44] in reality the timing constraint of turning the IGM off is probably not as strict [21:04:12] but because I can have a major loop running at that exact moment I have to turn it off when I set DT_N to a shorter time [21:04:27] and not e.g. 0.01 seconds later [21:18:25] yeah that makes sense [21:23:07] one thing I need to improve about timing there is for the high-speed loop [21:23:34] in the last few seconds before cutoff, most functions of the IGM and some others are disabled and a reduced major loop is running [21:23:57] which I don't have the precise timing for, but I think it's about 0.7 seconds instead of 1.7 [21:25:12] maybe when that is started I can set sinceLastCycle to something realistic for the next loop [21:27:45] "...and the high [21:27:46] speed cutoff loop was entered at TB4+134.106 seconds. Ten passes [21:27:47] through the high speed loop were made before S-IVB cutoff." from the Apollo 14 flight evaluation report [21:28:06] and I know when cutoff happened, so that's how I came up with the 0.7 seconds lol [21:47:22] night!