[15:21:03] NASSP Logging has been started by indy91 [15:21:05] hello hello [16:39:15] hey Niklas [16:39:30] Guenter! [16:40:09] n7275! [16:45:22] discord is busy today [16:53:42] I just made it busier [17:32:26] I have to admit, I like the relative peace of the IRC channel :P [17:35:18] same [17:35:38] my brain isn't great with multi threading [17:40:16] I can not write NASSP code and answer 10 NASSP questions at the same time :D [17:40:55] but speaking of NASSP code, this moon-centered RTE code looks better by the minute. No feature creep and all my test cases work. [17:41:01] hahaha yeah [17:41:02] nice! [17:41:09] gone are the days where it randomly decides to use the other way around the Moon [17:41:16] that's awesome :D [17:42:03] I had a branch for this where I was a lot closer to the RTCC Requirements document already [17:42:08] but I didn't 100% trust it [17:43:08] writing code first (from a source) and understand exactly what it does second is not a good development method [17:43:45] but with this new, more limited attempt I think I know what I am doing [17:44:00] still more stuff I want to implement, but that can come in the next update [17:45:04] hahahaha that's the approach I use for pyul :P [17:45:27] but porting the actual code is a bit more forgiving than the flowcharts or whatever you're dealing with [17:53:19] https://archive.org/details/scans_171.png/page/n119/mode/2up?view=theater [17:53:22] mostly this [17:54:01] clearly a mature document because it accounts for many edge cases. But also full of typos. [18:01:12] these RTCC Requirements documents have not been great in terms of typos, definitely by greatest enemy [18:01:15] my* [18:04:28] yeah typos in this stuff are the worst [18:04:55] at least for me, they make me question my own sanity for quite a while before I start to really question if there are typos [18:08:45] the worst one in these flowcharts is when the typo is in the page number or letter of the code path [18:09:03] some of these are obvious [18:09:06] others not [18:09:38] I've definitely been stuck in a loop before when implementing this stuff in code :D [18:12:38] hahahah oh man [18:12:51] yeah that is very bad :D [20:47:09] night! [17:34:55] hey [17:40:30] 06rn5ng! [17:40:35] nope [17:40:38] morning! [17:40:39] there we go [17:42:20] hey Mike [17:42:41] 0 = m, 6 = o, 5 = i [17:42:46] I am cracking your code [17:44:58] interesting email about LVDC flowcharts [17:45:21] could be quite useful for us. Although I don't have a full grasp yet how detailed they would be. [17:46:53] I asked my 7094 guy about those. [17:47:15] brand new sentence right there... [17:47:20] aren't you your own 7094 guy? [17:47:38] Rich Cornwell [17:48:14] right [17:54:54] hahaha [17:56:22] I have seen some examples of automatically created flowcharts from the time [17:56:53] by IBM even [17:57:03] and I think Rich got a lot of his info from Paul Pierce who donated the 7094 that CHM has [17:57:56] why 7094? Is that what they used for LVDC development? [17:59:48] it's a guess. early LVDC work definitely precedes the existance of the 360. also the AGS cross assembler "LEMAP" ran on the 7094 [18:05:21] plus there's that PDF you found that lists the "compatibility" of the LVDC [19:08:21] which now I can't find [19:18:55] https://ntrs.nasa.gov/api/citations/19660025415/downloads/19660025415.pdf [20:49:13] night! [00:03:36] thewonderidiot, oh that one. [02:25:51] were you thinking of a different one? [03:56:52] nope that's the one, I was just rather surprised that I'd completely forgotten [04:01:19] yeah, and other computers like the 4π mention compatibility with the 360, but the LVDC page does not [14:30:40] hey [15:08:10] morning! [15:09:42] hey Mike [15:10:52] what's up? [15:11:05] finding good scenarios to test the RTE [15:11:35] I have many scenarios [15:11:40] just need to find the useful ones :D [15:11:48] hehehe [15:13:05] and you? [15:14:06] revisiting LVDC booting [15:14:55] the documentation clearly explicitly states that you put a hop constant at location 000 that says where to start execution [15:15:21] but I can't see how that would possibly work given the more detailed descriptions and the schematics [15:15:52] haha oh man [15:16:03] like the very initial thing with the computer [15:16:11] and we still have no LVDC software that actually runs at boot, so no clear answer from that [15:16:13] yup [15:16:14] already running into documentation issues... [15:17:03] most of the documentation is great [15:17:10] it's just this one sentence that I take issue with haha [15:17:48] careful, not that the lawyers are suddenly faster than you [15:17:53] like, in a good way [15:18:05] everything suddenly available... still no booting LVDC :D [15:18:45] lol [15:18:49] so according to the more detailed descriptions [15:18:53] how should it actually work? [15:19:36] what I'm seeing in the simulator is that the address gets set to 000 in module 0 [15:19:56] but then when you let it start executing, it just loads the first instruction from address 000 and begins execution there [15:20:08] instead of performing a literal HOP to some hop constant stored there [15:20:52] and so far everything I've found the simulator to be doing lines up well with the detailed descriptions [15:21:41] exactly how it gets there is weirdly complicated... as are many things in the LVDC [15:22:30] is anything interesting at address 000 in the software? [15:22:50] not in any software we have [15:23:01] presumably the preflight program would have stuff there, but we don't have that [15:24:18] so write your own preflight program. One line of code. Jumping to where you want it to actually start? [15:25:52] yeah, the goal is to write my own preflight program. it's not quite that simple, I think I need to call a couple of things in the flight program before finally jumping to it [15:26:17] but I want to make a preflight program that works in both yaLVDC and my simulator [15:26:30] which isn't going to happen until we figure out how the darn thing boots :P [15:28:34] I remember I had to load the address to start somewhere when I implemented yaAEA in NASSP [15:29:10] managed to figure out how that was done. Very proud of myself, didn't want to deal with that sort of stuff :D [15:29:34] very easy with a working emulator and complete software... [15:31:14] haha nice [15:31:20] yeah right now for the LVDC I have neither :P [15:32:43] ah I am misremembering, it was probably the Block I emulator [15:33:35] Block II: vagc.Erasable[0][05] = 04000; // Z [15:33:44] Block I: vagc->memory[02] = 02030; // Z [15:33:49] ok, not exactly complicated [15:33:55] but I was happy that it worked on the first try :D [15:34:44] nice :D [15:37:06] regarding LVDC flowcharts, with our LVDC it was in many cases not that we couldn't figure out how to make something work. [15:37:34] It was more, if we have to come up with it ourselves (lacking documentation), how do we think it works in the real thing [15:38:15] so even if those flowcharts don't go to an equation by equation level, they could probably tell us the overall flow [15:38:32] like, what would make sense to put in a subfunction etc [15:39:37] just a bit of restructuring things at a higher code level where we came up with our own way previously [15:39:41] right, yeah [15:40:08] as long as the parts in question are actually covered by this flowchart annotation. it's sadly not exhaustive [15:40:15] hmm right [15:41:08] especially the attitude timeline is quite a mystery to me [15:41:26] one thing I implemented with some pretty made up code is TD&E in Earth orbit [15:41:42] I know there was an uplink that could disable TLI in case of a failure and would then enable TD&E for Earth orbit [15:41:51] but which attitude and when does the LVDC maneuver to it [15:42:09] that's maybe something that could be found in a flowchart [15:42:38] not the exact numbers, but the overall logic to it [15:43:50] it's not something I could really ask you to search for, I'd really have to look at it myself. I don't yet know what I am even looking for [15:43:58] not like the presettings [15:44:15] or some highly specific questions I have asked you before [15:44:22] oh weird [16:46:08] I'm working on writing a github issue about LVDC booting... half to justify it to Ron, but half to convince myself haha [16:46:30] and the convincing myself is working. I'm understanding how this all works a lot better as I go :D [16:51:11] the descriptive text in the documentation is pretty hand-wavey [16:51:40] "RUNVN inhibits memory operation during phase A" -- actually only bit times 6 through 12 of phase A [16:52:07] "RUNVN and HOP inhibit memory operation in phases B and C" -- this actually fully inhibits them in all of phase A as well, instead of just part of it [17:03:44] what phases are these? [17:10:59] LVDC instruction cycles are complicated [17:11:08] each instruction has three phases, A, B, and C [17:11:19] each phase has 14 bit times, 1 through 14 [17:11:28] each bit time has for clocks, W through Z [17:11:51] so to specify when something occurs time-wise in the circuitry, you need to give all three. instruction reads begin at A-7-Z [17:13:37] they're essentially progressively faster frequencies of clocks [17:14:10] yeah sounds weird haha [17:16:47] timing in general in the LVDC [17:18:10] * everything in the LVDC [17:18:12] :D [17:38:55] weirdest thing of all, it crashes into the Moon sometimes [18:31:06] hey guys [18:35:03] yo [18:36:03] hey Matt [18:36:05] ah [18:36:06] https://github.com/virtualagc/virtualagc/issues/1082 [18:36:08] oh wow I lied actually [18:36:10] this already exists :D [18:36:16] they also tried to release Colossus 234 [18:36:37] that one didn't even have a chance to be manufactured into rope modules though [18:37:14] 236 gets more complicated [18:37:17] COLOSSUS Memo #81, "COLOSSUS Revisions 233 through 236, COL 236 Revisions 1 and 2", 08/19/1968, by P. Rye. [18:37:37] ???? [18:38:03] really? I had no idea that 236 had revisions! [18:38:11] if they make revisions to revisions they (think they) are close to launch :D [18:38:46] but then they ended up on 237 anyways? [18:38:51] that is super weird [18:38:53] [07:00:35] .tell indy91 I'm trying to figure out what changed between Colossus 236 and 237... no luck so far. GAP apparently didn't do the asterisk thing in mid-68 [18:38:56] [07:03:24] .tell indy91 it's in bank 31, which narrows it down to R34, P23, S30.1, S31.1, or R35 [18:39:09] oh thanks past me :D [18:39:46] hmmmmmmmmmm [18:40:56] do we have Colossus anomaly reports this early? [18:42:16] well [18:42:20] we have COL-1 and COL-2 [18:42:30] COL-1 was for Colossus 224, and COL-2 is already for 237 [18:42:59] and COL-1 was user error apparently [18:43:13] so the real question is, did they even bother filing anomaly reports this early [18:43:39] hmm, I guess not [18:51:00] well, darn. maybe we don't have enough new info for that one yet [18:51:21] no distractions from LVDC for me :D [18:56:23] good :D [18:58:56] I am getting pretty excited to try this repeatable flight simulation mode [19:03:11] if the emulator works right it should do pretty fun things, once it starts up [19:04:02] well I know the emulator does not work right currently for multiply at the very least [19:04:07] almost certainly that means divide too :D [19:05:35] I bet those two instructions are used on the way to orbit [19:06:55] more like, milliseconds after GRR [19:21:07] hahaha yeah [19:21:11] and not even just for math [19:21:21] kind of like the AGC, multiply gets used for shifting and masking [19:21:51] and because it's the LVDC, that shifting is kind of used to construct instructions [19:22:03] so, very bad things happen if multiply is off [14:16:54] hello [14:20:14] hey Matt [14:20:59] trying to come up with a better solution for the texture size multiplier in the VC pull request. It gets used in timesteps, which I don't like [14:21:21] it's a constant integer, no real need to do any calculation there [14:22:22] all I can come up with is adding separate texture size variables for VC vs. the 2D panel though [14:25:25] I know that if it gets merged like this a future NASSP developer having to work on texture blitting is going to be really annoyed :D [14:33:37] multiplying by a constant in a timestep is probably better than checking a conditional in a timestep, but neither are really ideal. [14:34:08] some way we could do those calculations in an init function? [14:36:49] yes, but then it needs to be separate size variables for 2D and VC [14:37:05] so adding more variables vs. unnecessary calculations in timesteps [14:37:42] like for talkbacks. size is set in the Init function as the variables "x" and "y" [14:38:01] This is in the 2D timestep: [14:38:02] oapiBlt(drawSurface, switchSurface, x, y, width * (int) displayState, 0, width, height); [14:38:11] this for the VC right now: [14:38:15] oapiBlt(drawSurface, switchsurfacevc, x*TexMul, y*TexMul, width * (int)displayState*TexMul, 0, width*TexMul, height*TexMul); [14:38:22] separate timestep functions for 2D and VC anyway [14:38:45] and all those multiply by TexMul, for every talkback, every timestep... [14:38:52] and a bunch of other classes with the same thing [14:38:54] not ideal [14:39:07] so like you said, in the Init function it could do [14:39:14] x_vc = x*TexMul [14:39:31] and then in the VC timestep the function would be the same as in 2D, except use x_vc etc. [14:39:39] that's one idea [14:41:01] so for x, y, width and height it would need to have separate VC variables [14:41:32] multiplying by texmul might be less code to undo later actually [14:42:11] at least it's once per timestep, not per substeps like the systems stuff [14:42:57] by later you mean when we get rid of the 2D panels? [14:43:37] yes. when we get rid of them or when move to the 2d mesh method [14:44:14] if we do that TexMul can be removed. Or it could be done with Mike's favourite solution then, the calculation is done during compilation [14:44:32] true [14:44:47] that would be easier to switch from 4k to 8k [14:44:52] make it* [14:45:04] just a define somewhere [14:46:19] yeah. Can't be done right now sadly. [14:46:50] over all it is not such a big deal in the timesteps right now [14:46:55] eventually the VC should use animations for stuff like talkbacks, tape meters, etc [14:47:54] the most problematic case is the IndicatorSwitch class, for talkbacks. We have a bunch of them. All the other cases where TexMul gets used in the timestep right now are a few specialized classes, where we have only 1 object of a class. [14:48:17] so it's really not a huge deal in terms of performance [14:50:27] yeah [15:00:32] so in that branch how does one select between 4 and 8k textures? is there a config file option or is it on the PA configurator page? [15:02:02] I thought it was a separate set of textures actually [15:02:08] in a different branch? [15:02:15] now I am not sure. Would have to ask Jordan [15:02:45] in the branch that there is a pull request for. [15:03:24] Jordan posted a link to the textures on Discord [15:03:31] ooooh [15:03:33] and then you change TexMul in NASSP code to 8 I guess [15:05:28] I thought the pull request added both. that makes more sense [15:06:02] that's one good way for the NASSP install size to skyrocket, supply all sets of possible textures [15:06:15] then it has become a modern video "game" I guess [15:10:07] not that it's huge deal. NASSP just went past 300MB with the added Apollo 12 flight plan [15:10:13] still small [15:10:35] yeah I'm sure we're far from the largest release there [15:10:45] on GitHub [15:11:01] just the number of our releases is high haha [15:11:52] There is really not much need to keep anything but the NASSP 7.0.1 and maybe the past few NASSP 8 releases. But as long as Github doesn't complain... [15:22:43] morning! [15:22:59] if history is any evidence, if we really want to preserve our software long-term, we should print it. [15:23:03] hey Mike [15:24:31] hey Mike [15:24:34] haha oh no [15:25:03] Visual Studio has a print option [15:25:10] I wonder how many pages the whole NASSP code would be [15:25:26] I probably run out of paper with the RTCC code alone [15:25:33] I've never tried haha [15:26:37] at least you didn't say core rope modules as long term preservation [15:30:12] I think you'd need a rather large rope module to fit one of our DLLs [15:34:39] I got to thinking about valve and tank sizes again last night while trying to update systems config things [15:35:54] we save those in the scenerio because there is a few isolated cases where they can be changed by other code [15:37:06] but they're always changed something that has a defined range like a proportional valve or a handle [15:39:05] I think it might be possible to eliminate saving those parameters [15:39:46] yeah that would definitely be good for scenarios not getting outdated [15:44:36] I'm thinking of giving the valves a function to set a pointer to an external device like a handle angular position. size would never change, but it would be multiplied by a 0-1 scaling factor [15:44:46] % open or closed [15:44:58] could also be a voltage [15:45:21] just a double* [15:59:18] I do like the idea of having it as a separate variable [15:59:24] it could be derived class that has that [15:59:32] normal class doesn't save/load valve size [15:59:49] the additional variable gets multiplied with the valve size [16:07:02] in not sure it would even need to be a derived class. handle positions get saved already, and voltages are all saved for eObjects [16:09:29] what might be useful is something like our toggle switch classes, but for pipes. like an expansion of mixingpipe but something that an external "signal" could control. [16:09:59] basically selecting different in and out valves [16:11:21] only if it lets us remove the complicated ECS code for doing what the spool valves do [19:23:59] thewonderidiot, it's legal to have two labels in AGC code with the same name? [19:24:07] VERB69 TC VERB69 # VB69 CAUSE RESTART [19:24:14] I don't understand this in extended verbs... [19:24:41] and where does it even jump [19:24:53] oh [19:25:00] this isn't doing what I think it is doing [19:25:29] this isn't causing an infinite loop on purpose... or does it? :D [19:57:31] yes it is [19:57:36] just jumping to itself [19:57:41] it's the fastest way to crash the computer [19:58:33] that's why V69 is "hardware restart" -- it's triggering the TC Trap hardware alarm which causes the computer to immediately reboot from address 4000 [19:58:47] it's a full GOJAM so most of the internal hardware state gets reset as well [20:00:04] I guess I was expecting something more like V36 :D [20:01:50] no V36 is significantly more invasive [20:02:13] that's a "fresh start" that initializes a ton of software state to 0 [20:02:46] V69, because it causes a crash, is treated like one -- the software picks up from the last phases saved in the restart tables [20:06:06] ah so when doing a V69, it eventually also goes through some code that V36 uses? [20:08:37] they're different types of restarts, and there is a bit of shared code [20:08:59] I see [20:09:02] but V36 is not going to try to restart anything [20:09:21] it's going to clean up memory so you have a fresh, reproducible starting point [20:12:19] "The RESTART routines perform a general reinitialization of the machine rather similar to that done by a Fresh Start (V36E) and in fact using common coding. This includes clearing out the EXECUTIVE's list of currently scheduled Jobs. While a Fresh Start leaves the computer in a basic initial condition requiring loading and operator activity to bring up useful activity such as a Mission Program, the RESTART routines pass off to anoth [20:12:21] tine which works in conjunction with the 'restart protection' of the interrupted program... to automatically put that program back into action at a logical point without loss of significant data such as the state vector and the PIPA's." [20:15:12] right, in the end, very different verbs [20:48:11] night! [22:09:58] thewonderidiot, that PCM decommunicator manual made some sense of a few things [22:10:07] nice! [22:11:01] the specs don't make it seem like it would have enough memory to hold a program complex enough decode the HBR frames and subframes [22:11:14] until you know how it works [22:16:04] I bought that manual because Jimmie has a huge pile of the radiation, inc. modules from what was presumably the JSC 540 Decom [22:16:26] but I'm glad that is is being useful in other ways too :D [14:21:20] hey [14:24:29] hey Niklas [14:29:02] cryo heaters weren't wired to anything? [14:37:59] they were wired directly to the busses [14:41:18] ah [14:53:50] the problem I was trying to solve (without looking as closely as I should've) was actually caused by the direct O2 valve being too big [16:03:31] cool, m,y rebase didn't break anything [16:03:42] my [16:08:54] there are actually a fair number of CBs that aren't hooked up still [16:15:04] the CSM has so many :D [16:17:27] morning! [16:23:25] hey Mike [16:35:38] hey [16:36:03] how goes the multiplication [16:43:36] annoying :D [16:43:50] at least it isn't divide! [16:44:08] I might try to tap into the circulation loops here so I can see the intermediate data [16:44:16] lol don't remind me, that is probably next [16:44:40] how does one even simulate circulation loops [16:45:01] I've struggled a lot in NASSP with any kind of delayed signals [16:46:04] verilog has an unsynthesizable feature that lets you delay any signal by a certain amount of time [16:46:15] so I'm using that in the simulator [16:46:21] for the FPGA I'm using a giant shift register [16:47:21] shift register kind of makes physical sense [16:48:13] just have to use something with regular timing [16:48:28] yeah [16:48:32] which is not that trivial in Orbiter [16:48:37] but can be done [16:48:41] in fact our LVDC does it [16:48:56] its timestep function gets called 100 times per simulated second, not matter what [16:49:22] I forgot why exactly that number, I think that's the finest timing I needed for anything :D [16:51:59] haha oh man [18:06:58] alright I have managed to intercept the multiplicand lol [18:08:30] weirdly: "When the sign of the multiplicand has entered the MD1 latch, the entry gates are disabled and the register loop is closed. Gate A1 is disabled at bit-time 1-Y when TBCV goes to a "0" and gate A4 is disabled by P2VN at bit time 1-Z. The low-order bit of the multiplicand returns to the MD1 latch at bit-time 3-Z. Thus, the previous contents of the register which entered MD1 at bit-times 1-Z and 2-Z are allowed to continue cir [18:08:31] ng. The values of these bits cannot be determined." [18:08:43] I think this means that you can expect the bottom two bits of the multiplicand to be random garbage [18:08:53] which is consistent with what I'm seeing in this intercepted value [18:10:40] oh no, I intercepted it one bit off [18:15:32] what a strange computer [18:17:37] yeah in the AGC I could have just directly looked at this number [18:17:51] instead of having to determine that it was circulated at the same period as the TMV timing signal [18:18:34] and then counting clocks after the TMV rising edge to find the point at which I can sample my shift register to grab the multiplicand value [18:21:10] but I'm almost there I think. hopefully the multiplier and partial product registers have similar enough timing [18:45:56] fun [20:32:37] well, my naive python implementation of the LVDC algorithm is matching the simulator in all cases [20:32:58] no weird off-by-one errors like I'm getting by using native multiplication [20:33:46] obvously will be less performant than a native multiply instruction, but the LVDC is a much slower computer than the AGC and it's only 6 iterations [20:43:09] it needs iterations? [20:44:30] well it's a serial computer, so if they did it the simplest way it would have needed 26 iterations [20:44:41] but they did it four / five bits at a time [20:45:22] oh I see [20:45:51] https://pastebin.com/raw/9Bh6sx9r [20:45:56] this is their algorithm [20:47:03] roughly speaking [20:47:07] looks like fairly efficient code, even if it's just for one instruction [20:47:20] the Virtual AGC does a lot worse on each cycle :D [20:47:23] haha yeah [20:47:45] so the LVDC is really much slower? Kind of impressive then that the managed to run the IGM on a similar time cycle as LGC powered descent guidance [20:48:42] I guess there is no DAP... [20:49:32] they both have the same basic clock frequency. but the LVDC takes ~82 microseconds for every single instruction, compared to the typical 23 microseconds for AGC instructions [20:49:51] LVDC has no DAP, but there is still a lot to do in the minor loop [20:51:23] not having an interpreter equivalent probably saves them a lot of time [20:52:40] hmm, I thought the servicer would be avoiding the interpreter as much as possible [20:52:52] but I guess with some of the vector math it's not really possible [21:08:29] night! [14:37:46] hello hello [14:38:06] n7275, I should do the same with my XRSound branch as you with your drifting IMU one [16:20:28] morning! [16:20:31] hey Niklas [16:20:34] hey Mike [16:20:56] something catastrophic has happened with my server [16:21:19] so I am without my trusty IRC bouncer today [16:21:46] but I have the logs [16:25:56] indy91, rebasing? [16:26:15] just putting it up on Github as a draft PR [16:26:19] hey Mike [16:26:24] ooooh [16:26:27] yes [16:26:31] good idea [16:27:10] GitHub sent me about 20 emails this morning, haven't looked at them in detail yet [16:39:06] speaking of that IMU branch, I recall a brief mention of our CDUs either here or on Discord a few days ago [16:39:56] I'm not super familiar with our CDU code. how much work do you think it would be to make those drive the IMU? [16:42:22] not a lot, more mental work, convincing ourselves that there is no chance that the CDUs are getting desynced from the IMU [16:42:56] if we want to also implement coarse align properly, being able to delete some of that cheaty Virtual AGC code, then our IMU might need to have inertia [16:43:32] I'm quite interested in trying that [16:46:45] hmm [16:46:56] now I am not sure how separate those two things can be [16:47:32] oh? [16:47:52] like, make the IMU use our CDU class without also implementing coarse align properly [16:48:08] ahh okay [16:48:33] although potentially we could first make the CDU drive the FDAI errors only, but during coarse align use the current cheaty code in Virtual AGC and IMU [16:48:49] and use the read counter already as well [16:50:47] that might be better [16:51:45] hmm [16:52:22]