[11:04:12] Meeting started by thymo [11:04:29] Meeting chairs are: thewonderidiot, indy91 [11:55:49] .ask thewonderidiot I'm playing around with Retread44. Could you tell me why I should assemble them with --early-sbank and --no-checksums. The latter being Retread not having any code to check the banksums if I assume correctly? [12:05:40] Thymo: Ah. [12:07:00] Haha. Hadn't realised you were still awake. :P Where about on this planet are you? [12:07:37] Nebraska. I keep extremely odd hours. [12:11:13] Ah. Got it. Well. Welcome to #nassp if I hadn't already! [12:15:22] :D Thanks. y'all looking for someone to wrangle wiki documentation? (Because the IMU realign checklist page is so-so. It needs better coverage of P52 options and an "oh crap, I zeroed my IMU! Help!" section. [12:27:34] Niklas and I worked on the wiki for a little some time back. But we're not really doing a good job at maintaining it.:P [12:27:50] So yes. Highly appreciated even! [12:32:01] Then I'll sign up on it and start maintaining. [12:34:04] Well that ain't good: "Mailer returned: Failed to connect to prwebmail:25 [SMTP: Failed to connect socket: No route to host (code: -1, response: )] " [12:35:34] Yeah. There were some issues with that [12:35:45] indy91: Hey. What's the status of the wiki registrations? [12:36:24] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2940.0 [12:37:05] hey guys [12:37:19] haha [12:37:21] ok [12:38:09] wiki registration, uhh [12:38:23] I can't really remember, I thought dseagrav managed to fix it all [12:39:47] I got a confirmation email when he fixed it, but maybe there was still a manual step involved [12:39:59] could just be broken again [12:42:46] I got spammed by Guenter, so I didn't see the "Sourceforge no longer sends email from the wiki" [12:43:07] I guess we have to ask dseagrav if he has an idea what to do [12:43:12] Yeah [12:43:31] I'll be back in a little [12:43:43] Cannibal^, so you want to help out with the wiki? [12:44:03] Yep. [12:44:23] that's great [12:45:05] are you registered in the forum? [12:46:00] Nope. [12:46:50] that as well is not an easy process :D [12:48:39] are you fairly new to NASSP or are you a long time user? [12:53:06] I'm fairly experienced. Started back in 6.4. [12:54:00] yeah, I think that was my first version as well [12:54:34] from some chat logs I saw you played around with scenario editing a bit [12:55:05] ran into trouble with the AGC versions NASSP used for the mission or something like that? [12:59:37] Yeah, don't use earlier mission APOLLONO: It used to work, but the recent work on LEMcomputer will load Sunburst 120, and that just isn't fun. :/ [13:00:22] Sunburst120 is great... if you want to see a LM do everything on its own [13:01:01] what we should probably do is add a mission config file, where you can specify mission constant parameter like the CMC and LGC versions used, the DSKY type etc. [13:01:16] right now a lot is handled simply with the APOLLONO parameter [13:01:39] which is bad for creating custom missions/scenarios [13:03:20] A bigger TODO is to make a more configurable vessel. Customizable joystick axes and multiple joysticks, with enumeration of which are plugged in. [13:04:15] yeah, that would be great. I added a few things for joystick handling in the LM, but making it customizable like that is a bit more tricky [13:05:22] that would belong in the NASSP configuration menu, which hasn't been updated in a long time. [13:05:28] Because I have an actual flight sim setup with 3 different components (rudder pedals, a two-axis roll/pitch stick and a throttle quadrant with a bunch of axes. [13:06:48] yeah, it only supports two self contained joysticks right now [13:06:56] no additional devices just for e.g. one axis [13:07:53] Yeah, which doesn't work when R and P are on one, Y on a second and throttle is on a third [13:08:44] yep [13:09:10] it certainly can be done [13:10:00] those advanced controller options just need to be implemented [13:13:06] Were it supporting multiple controllers and axis binding, I could control throttle, hover, R, P and Y. And have buttons and axes (throttle/jets? run/stop? rate of descent switch?) to spare. [13:14:26] ROD switch on the joystick would be very useful [13:15:48] the TTCA handling is always going to be awkward, because nobody has a device like it. There is no separate throttle lever, but you control it with one of the translation axis [13:17:01] Forex, here's my throttle: https://images-na.ssl-images-amazon.com/images/G/01/videogames/detail-page/thrstmstr_b00419zuxs-05.jpg That right-side hat switch would be great for ROD There's another hat switch "aaround the corner". And two more axes. [13:18:05] regarding the ROD switch, you can probably map the switch on your throttle to a specific keyboard key, right? [13:19:44] Probably, but I'd have to install the software for this thing (And I hate that on general principles) [13:20:52] I'm used to DCS and X-Plane: "press button, map what it does" [13:23:39] I have used the config tool of my X52 to map a hat to the numpad for switching the stick between rot/trans modes. [13:23:44] s/hat/button [13:29:49] Right, time for bed. 'night folks. [13:30:56] cya [13:32:15] Night [14:14:05] Hmm. I'm having some issues running a version of Retred44 I modified. [14:14:59] For some reason it starts executing at address 4040 instead of 4000. That causes it to never run GO but does DOWNRUPT. [14:19:42] I'm sure Mike will be able to help [14:21:34] It's like DOWNRUPT wants to trigger before interrupts can even be inhibited. Very strange [14:22:41] I run the sim, check the registers before anything happens. Z is at 4000. Step once. Z is at 4040 and a 1 is in ISR. [14:29:14] Just resized my PC's disk. Got a nice 70G free on C: again. :D [14:32:28] yeah, I should clean up a bit as well [14:33:28] I still had a dual boot with Linux which I never use. I just shrunk that to it's minimum and gave the rest to winblows. [14:41:57] Hey rcflyinghokie [14:42:08] Hey good morning [14:42:11] Happy new year [14:42:18] hey [14:42:22] Happy new year! [14:42:44] Happy NASSP 8.0 release year! Well, maybe [14:43:07] Well *assuming* we can keep this pace [14:43:17] I think it is very promising [14:45:27] what I want to do next is add LVDC presettings for Apollo 9 and 10 TLI [14:45:41] and then I can launch Apollo 9 again and continue the MCC work [14:47:42] And I will start slowly working on fine tuning the ECS [14:48:27] ah wait, I still wanted to rework the LM systems timestep [14:48:37] I've been working on Retread44 for a bit. Trying to get the base work done for when we'll need our own ropes for custom/fictional missions. [14:48:43] I'll do that first [14:49:04] I guess we need heat for the glycol as well [14:49:41] First thing is changing PINBALL so you can use a VERB to swap out all verbs with a new verb table. That way there are a lot of new ones available while still retaining the original. [14:50:18] I think what I have now should work. But the AGC doesn't even get to GOPROG. :p [14:53:06] Slow process :P [14:55:32] Yeah. As soon as I do a single step after GOJAM the AGC goes into ISR #8 [14:56:51] rcflyinghokie, you know the heat loads better than me [14:57:51] give me an easy example and I'll commit the code changes necessary for it [14:59:33] Sure let me pull up some docs [15:00:36] I have been roughly using the circuit breaker load page in the sys handbook [15:00:37] you have to give a pointer to the heat load from the config to each system, with the init function. And then just generate the heat in the systems timestep [15:00:53] yeah, that has heat load numbers [15:00:56] There is a heat load column in there [15:01:03] Thats what I have been using to start [15:01:09] There are a few systems I don't have yet [15:01:32] But here is a simple one [15:01:37] LGC is 110W [15:02:12] not a simple one at all [15:02:19] We will have to look into systems with heaters as they need to behave differently but I can give you the simple ones for now [15:02:24] what about standby mode? [15:02:30] Ah touche [15:02:45] I need to research that [15:02:58] wouldn't make much sense to generate more heat than it draws power :D [15:04:06] Yeah I see that [15:04:14] Load is 80W [15:04:17] Heat is 110W [15:06:03] Unless it's including things like the PSA PTA CDU etc [15:06:07] yeah, it's a special case [15:06:31] a bunch of signals are going into the LGC [15:06:36] The PTA and CDU are powered through the LCG and IMU breakers [15:06:38] not just its own CB [15:07:41] so LGC might be the most complicated case for the heat load even :D [15:07:54] IMU is also not a good start, because we have no heat loads in the CSM yet [15:07:57] Hah yeah [15:08:31] how about the GASTA? [15:08:40] 25.9W [15:09:15] oh, I see how it works [15:09:22] AC and DC power [15:09:49] Ah [15:10:45] Actually GASTA has 2 breakers [15:10:46] so let's just say 25.9W for the GASTA, if it is fully powered [15:11:24] What about the 12.5 on the AC bus A breaker? [15:13:23] good question [15:13:57] that still doesn't add up to 25.9, I guess the incoming voltage from the IMU generates more heat? [15:15:16] I don't know what else would add to it [15:15:49] I'll just use the 25.9 for niw [15:15:50] now [15:16:38] Looks like the 25.9 comes from the DC power and 12.5 from AC power [15:18:03] so should I use 25.9+12.5? [15:18:10] Ouch. Retread44's major mode support goes as far as being able to do a V37 and whatever you enter will you throw you in DSPALARM. [15:18:35] I think so yes [15:18:45] But I got it to run. It didn't like the --hardware from yaYUL [15:19:00] If both breakers are in [15:19:22] it won't generate anything without both circuit breakers in [15:20:16] Yeah then add them for now [15:21:36] Lighting should be another less complex condition (I am refraining from using simple again) [15:22:08] lighting? [15:22:46] Yeah [15:22:49] you chose really short names for the heat loads in the config, I hope you checked that none of them were used for anything else [15:23:32] I did [15:23:41] wouldn't lighting heat load have to be generated based on every individual lamp? [15:23:55] The heat load is from the electroncs package [15:24:06] we don't have a system for that yet I think [15:24:13] Nope [15:24:21] is that the LCA? [15:24:51] They called it the TLE [15:25:13] oh, so something else [15:25:18] The LCA is something elese [15:25:18] else [15:25:37] There is the lighting control assembly and tracking light electronics [15:26:17] ah, so the tracking light [15:26:21] that's indeed simple [15:26:22] But frankly all the LCA parts of this handbook are deleted [15:26:29] But the TLE is just the tracking light [15:26:31] we don't simulate one, so we don't have to simulate the leat load [15:26:33] very simple :D [15:26:36] Haha [15:26:41] heat* [15:26:57] tracking light would be good to have though [15:27:03] so you can see the LM through the sextant [15:27:05] Yeah [15:27:14] Using the vessel marker is kind of annoying [15:27:48] we have a bunch lighting options in the API [15:28:11] someone needs to make themselves familiar with it, it's fairly complex [15:28:16] seems like a job for Alex [15:28:28] As he is not present to defend himself, I concur [15:29:15] Ok I have info on the LCA, it controls all the LM lighting exterior and interior [15:29:33] I can do the coding of course [15:29:42] The TLE contains the strobe equipment for just the tracking light so that is why it makes so much heat [15:29:58] 60 flashes per minute [15:30:13] yeah, I wanted to implement something better for the handling of lamps in the LM, starting with the LCA seems the best way [15:31:15] Oh nice there is even a table with lighting color and brightness [15:32:56] And a diagram of the LCA [15:34:42] where? [15:34:49] The LM 10 AOH [15:35:04] Figure 2. 10-2 [15:35:08] My pdf pg 555 [15:36:44] I didnt know the LM had a docking light on when in the SLA [15:44:01] Hmm for the config, should I just add HEAT to the names to make sure there is no confusion? LGCHEAT versus LGC? [15:45:14] lunar guidance cheat [15:45:25] LGCHEAT [15:45:57] yes, adding heat would be good [15:48:08] Haha [15:48:10] Ok [15:49:27] Just added HEAT to every one [15:57:57] Managed to get my code working. The rope now has twice the amount of verbs available. LD [15:57:57] :D [16:00:16] Haha bigger vocabulary ;) [16:02:50] Retread44 is more limited than I thought though. No major modes, no extended verbs, no program alarms. [16:03:46] It's basically just the Executive, Waitlist, Interpreter and instruction check. Plus a couple of memory peeking poking verbs. [16:04:06] The only supported peripheral is the DSKY. [16:06:16] interpreter at least [16:06:20] that seems advanced already :D [16:07:28] It's still listed as LIST_PROCESSING_INTERPRETER [16:07:36] Not even INTERPRETER as in the later ropes. [16:07:55] does it have the same functions already? [16:08:00] vector math mostly [16:08:20] And Retread44 is from before any actual block 2 AGCs were built. So there's no guarantee it even works. There's no code that uses the Interpreter in here. [16:08:30] Maybe [16:09:05] There's quite a bit. But I have no clueless when it comes to Interpreter stuff. [16:09:22] I know that you can enter interpretive mode my doing TC INTPRET but that's about it. [16:12:37] Now I need to add a verb that allows you switch the two tabs. Now you manually but +0 or >+0 in location 714. :3 [16:12:42] s/but/put [16:14:57] Oh that's nasty. [16:15:11] There is program alarm 'support'. [16:15:27] You do a TC ABORT and put the alarm code after that. [16:15:34] Same as later ropes. [16:15:37] However. [16:15:44] ABORT does a TC ABORT [16:15:56] So you end up with a TC TRAP resulting in a restart. [16:16:25] It's also commented as ****FIX LATER**** [16:17:06] this is early days Block II, there was a lot to be fixed and added later [16:20:43] So there might be one down side to all this. If I remember correctly programs can call verb/nouns themselves through NVSUB. [16:21:06] If that goes through the same routines that I modified bad things will happen. Since that verb is suddenly gone. [16:21:38] Shouldn't be a problem for now since technically programs don't even exist. [16:22:25] I probably should test if NVSUB is being run (DSPALARM should also be doing this) and then force the first verb table. [16:38:24] Done. I got rid of verb 33. That's normally used to proceed without data, you can do that with PRO already. Replaced it with my own routine to complement the selector and make it switch to the other table. [16:46:47] Have you guys seen the video that was posted to the mailing list? [16:50:40] yes [16:50:51] I saw it live actually, partially [16:52:31] rcflyinghokie [16:52:32] https://github.com/dseagrav/NASSP/commit/2715aec3267e6a4da4263557c0ee3cf2aa45c87a [16:52:48] this it all it takes to implement the heat load in code [16:53:08] Very clean [16:53:52] So ideally we need a simulation at least in part for everything that generates heat? [16:55:33] we should have most systems already [16:55:47] the lighting stuff would have been implemented at some point anyway [16:58:12] how do we handle systems that are connected to both glycol loops? [16:58:41] I have been thinking about that [16:58:59] My initial thought is give the heat load to both loops [16:59:01] just split the heat 50/50? [16:59:51] I am not sure if that would work well [17:00:06] It might not give enough heat to the primary loop if that makes sense [17:01:03] so more to the primary loop [17:01:11] surely there is some documentation about that to find [17:02:47] Well one section of the loops have noth primary and secondary passes through the same cold rails [17:02:51] *both [17:03:01] 2 passes for primary, 1 for secondary [17:03:18] So that section 2/3 and 1/3 I think would work [17:04:08] Using the diagram we could estimate how much heat to give to each [17:04:28] The TLE for example has 3 lines from the primary loop and 1 from the secondary [17:05:01] The ASA has 2 and 2 [17:05:06] RGA has 1 and 3 [17:05:18] Could divvy them up like that to start [17:08:08] Quick side question, there is a SECRA and SCERA [17:08:13] Is that a typo? [17:08:28] I couldnt find SECRA [17:09:12] I wondered that as well [17:09:33] SCERA is a device in the SCEA, there are two of them [17:09:55] the SCERAs are what I just implemented [17:10:21] Yeah [17:10:40] I mean other systems have duplicates [17:10:44] there is a good chance it's a typo [17:10:54] And even in the glossary there is SCERA but no SECRA [17:11:02] So I was betting on typo [17:12:50] yeah, could just be the other SCERA [17:21:55] Ok so I think a starting point is divvying the heat load based on number of lines going in [17:44:50] morning! [17:45:00] Good morning [17:45:07] what's up? [17:45:17] Trying to figure out heat loads for the LM [17:45:29] fun [17:45:44] Right now trying to find the loads for the LGC on standby versus operating [17:45:46] hey Mike [17:46:11] Thymo: early versions of YUL had a slightly different algorithm for maintaining SBANK, and Retread was written before bank checksums were a thing [17:46:29] in a big way, Retread has unwired holes in the middle of banks that will cause parity alarms if accessed [17:46:56] they didn't actively fill all holes with CCSHOLE, or constants, or anything until checksumming was a thing [17:49:28] indy91: I can't find any transcriptions of the debrief where they talked about the blanks -- Don says in his book that he took notes during it, so I'm assuming that's what he was referencing [17:50:10] yeah, as you said, probably the GNC specific debriefing [17:52:38] as I said in the email, on the second attempt with 11/2 I got program alarms in P66 as well [17:52:47] so maybe I need slightly less load [17:56:34] yeah [17:57:02] 28/5 is roughly halfway between 11/2 and 17/3 [17:57:27] a bit less than halfway [17:58:01] Hey Mike [17:58:04] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_sys/yaAGC/agc_engine.h#L351 [17:58:13] increase that to :5 or :6 before you try that though [17:58:16] hey Thymo [17:58:17] I had some issues, I set them out in the backlog. [17:58:24] I got the ones you .told me [17:58:25] Somehow I can't use --hardware with Retread44 [17:58:35] yeah, because that is for running on hardware, lol [17:59:00] It causes DOWNRUPT to occur before interrupts can even be inhibited. [17:59:02] it changes the position of the parity bit and reorders the banks to be how they were in the real thing [17:59:13] Ron wouldn't let me change those things by default for backward compatibility reasons [17:59:13] Really, I though yaAGC supported the real bank order. [17:59:15] no [17:59:31] it needs 2 and 3 to come before 0 and 1, while the real AGC had them in order [17:59:46] and it uses bit 0 for parity instead of bit 15 [17:59:56] a --hardware binary looks like total garbage to yaAGC :P [18:00:21] Ah. So just --parity should work? [18:00:25] yep [18:00:48] Cool [18:01:00] I got quite a bit of options going into yaYUL. :P [18:01:00] yaYUL --blk2 --no-checksums --early-sbank --parity --html --unpound-page MAIN.agc [18:01:11] yup [18:01:16] sounds right for Retread [18:01:18] I suppose I don't need unpound-page anymore. I removed all the page entries. [18:01:24] what are you doing with it, anyways? [18:02:02] I suppose starting out with making a rope suited for general use without any mission programming. [18:02:11] hahaha [18:02:19] you've got a long way to go, starting from Retread :P [18:02:28] http://www.ibiblio.org/apollo/DIY.html#Programming_for_the_AGC_Operating [18:02:41] I'd recommend starting from Aurora 12 at least [18:02:46] or Borealis [18:03:00] it's very easy to remove the test DAP stuff from Aurora [18:03:19] and I've "ported" Borealis from BLK2 to AGC for tests, so it has INTERPRETER instead of LIST PROCESSING INTERPRETER [18:03:20] Yeah, they at least have stuff to acknowledge the existence of an IMU. :P [18:03:59] My feature should easily port over to other AGC ropes. I haven't done much. [18:04:03] really what I would like to do at some point is remove all of the mission code from Luminary [18:04:13] you monster [18:04:13] but that would be a bit of a chore, heh [18:04:34] As you might've read I added a new verb that can swap the current verb table with another one. Allowing for more verbs. [18:04:39] what even is Luminary without mission code [18:04:44] It works pretty good so far. :D [18:04:59] the latest version of the Executive/Waitlist/Interpreter/Restart tables operating system :P [18:05:10] Borealis still has an older notion of phase tables and whatnot [18:05:19] Retread has none [18:05:20] although I think that made the hardware alarm tests easier to write... [18:05:23] yes I know [18:05:26] Retread has almost nothing [18:05:27] lol [18:05:39] Program alarms are just TC TRAPS :P [18:05:46] Intentional I might add [18:05:54] And V37 just triggers an OP ERR [18:05:55] yup [18:06:02] haha I know [18:06:24] A lot of "FIX LATER" comments too haha [18:06:44] and as you pointed out, its self-test can't pass due to early simulator bugs [18:07:00] since hardware Block IIs did not exist yet [18:07:24] they ended up manufacturing Retread 50 to correct those [18:07:40] Which we don't have [18:07:48] the computer history museum has Retread 50 modules in their AGC.... I would love to be able to convince them to let me dump them, but I doubt it will happen [18:07:50] they are very stingy [18:08:29] Might need the same plan as Draper Labs [18:08:48] I mean at least these I know exist and can physically touch [18:09:04] Draper is a big mystery [18:09:57] Was yaTape ever done? Or is SuperJob not doing anything currently? [18:10:13] superjob does run and "work" [18:10:27] but yeah, no tape simulator exists [18:10:39] it'd be a bit challenging because it does a lot of fancy stuff with the test connector signals [18:10:56] ok, testing 28/5 next [18:11:01] 11/2 is definitely a bit too much [18:11:28] I love how well-constrained this is. 17.6%, too low. 18.2%, too high. [18:11:47] another thing I was just thinking [18:11:57] wouldn't the throttle castellations make this problem worse, too? [18:12:17] since the throttle would be counting up and down more than anticipated [18:12:25] not by a lot, but at least a bit [18:16:14] we have those castellations about as much as the real mission [18:16:17] slightly more [18:16:39] good, so THRUST will be a higher than anticipated load once it actually DINCs :D [18:21:53] isn't that an output counter? [18:22:09] or do we need to improve both input and output counters? [18:22:19] the output ones are mostly cheaty [18:22:50] I want to do both [18:22:56] great [18:23:51] I've been slowly filling in the table in https://github.com/virtualagc/virtualagc/issues/1055 as I've worked through all of the counter circuitry [18:24:07] one more input counter to go, and then the output counters should all be fairly easy [18:25:39] should be able to start coding the priority chain and output counters in the next couple of days [18:27:27] but I'm thinking I would like to make the boundaries between the AGC and the rest of the spacecraft fairly accurate [18:28:19] so for example for the ACA, you would just write a voltage to some variable in State and yaAGC would internally do the analog-to-digital conversion and generate the right amount of pulses for that voltage at the right rate [18:31:06] speaking of... they must have changed the resistors in the interface modules for the ACA at some point [18:31:42] ND-1021042 and R-700 both say that the ACA deflection can generate anywhere from 0 to 32 counts [18:31:59] but Luminary itself (and maybe the ICD?) expect 42 [18:34:18] we generate 42 [18:34:28] what kind of voltage does it expect? [18:34:32] in the case of the ACA [18:34:56] well, it's 800Hz AC from 0 to 2.8VRMS [18:35:18] with the phase indicating the direction, but we can just use signs for that [18:35:45] so we could either do from 0 to 2.8 or 0 to 3.96 (which is roughly the peak on a 2.8VRMS signal) [18:36:23] Do we have any information on Sundial? It's not listed on either Luminary or Colossus page. [18:36:37] Sundial was the CMC equivalent of Aurora [18:36:42] CSM systems test [18:36:57] I don't know revision numbers but the last release of it was Sundial E [18:37:09] there is a chance that Margaret might have a copy [18:38:31] Might be worth giving it a spot in the table after Corona? Don't know if we have any documents about it. [18:38:39] not really, no [18:38:52] we just know it existed [18:40:16] we might actually have a single page of it [18:40:24] or was that Sundisk... [18:41:14] no, it was sundial [18:41:16] Sundial B [18:41:20] http://www.ibiblio.org/apollo/hrst/archive/1709b.pdf [18:41:27] PDF page 266 [18:43:35] rhc_count[0] = (int)(lem->CDR_ACA.GetACAProp(0)*42.0); [18:43:48] scaling that to 2.8/3.96 instead of 42.0 is easy [18:43:59] awesome [18:44:24] I tried 28/5 [18:44:27] and then I will generate counts [18:44:29] it looked pretty good [18:44:30] how was it? [18:44:37] but I still got program alarms in P66 [18:44:51] oh wow [18:45:20] weird, on my first attempt with 11/2 I didn't get any [18:46:01] I wonder what the difference is [18:46:42] I also imagined P66 as having much less of a load [18:46:45] always* [18:47:50]