Meadville Space Center
Welcome, Guest. Please login or register.
October 25, 2020, 07:00:11 AM

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
  Show Posts
Pages: 1 2 [3] 4
31  Project Apollo - NASSP / Programming / Re: LM status... on: September 12, 2016, 12:07:46 PM
Cool! I can see where the rupt is generated (top right of A17-1) but there's a lot of gates and latches separating it from the count pulses that I don't understand yet. I'll dig into them when I get home tonight.
32  Project Apollo - NASSP / Programming / Re: LM status... on: September 12, 2016, 11:34:53 AM
I don't think the CM uses that interrupt at all. In the LM, it's just used for the redesignator, and it's ISR exits right away if P64 isn't running.
33  Project Apollo - NASSP / Programming / Re: LM status... on: September 12, 2016, 11:07:32 AM
I never commited a L-Register overflow commit to Virtual AGC from a few weeks ago. Now during LPD it at least seems to do the countdown, but I still haven't had success with actual landing point redesignation. maybe it's looking for a specific count from the ACA counter, so I'll try with a joystick. It's possible that it doesn't like full deflection, which commands RCS hardover.

Awesome! I really wasn't expecting that one to have any pragmatic effect. For the LPD, are you currently generating RUPT10? I can't find the code for it.
34  Project Apollo - NASSP / Programming / Re: LM status... on: September 10, 2016, 05:43:01 PM
I tried to implement an artificial delay between setting the RadarActivity bit and the LR response (filling the register, RadarActivity bit zero and RADARUPT), but that didn't help. Maybe I should set it higher than 0.1s? Also, if I put the code that zeros the RadarActivity bit in the "LR unpowered" section of the code, then the 1210 alarms don't happen anymore with a pulled circuit breaker. Resetting the RadarActivity bit shouldn't really be in the in the LR code at all, I guess. Maybe the 1210 and the 1201/1202 alarms are both caused by this? If the bit isn't reset at all, then the 1210 alarms happen. If the bit is reset too fast or too often then the executive overflow occurs.
And the RR isn't generating any RADARUPTs either right now? That 10Hz limit applies to both of them combined. Yeah, ideally the bit would be reset 100-110ms after the radar activity bit is set, regardless of which radar is being addressed, and regardless of whether or not they're on. You could possibly try increasing the delay to 0.11s, which appears to be close to the worst case, but I wouldn't push it any further than that.

I'm going to start looking at that old VirtualAGC issue that claims most instructions take an MCT longer than they should. It's an easy change if it's right, and I'd be curious to hear if the 1201s and 1202s go away entirely if you make the change suggested on the issue. That would account for a LOT of incorrectly wasted CPU time.

e: Actually on further thought, you're just sticking the radar readings directly into RNRAD, right? In reality, there will be CPU time stolen from SHINCing and SHANCing bits into that counter. So assuming we've got the RADARUPT load approximately correct, we should be dedicating slightly less CPU time to the radars than the real thing would have.
35  Project Apollo - NASSP / Programming / Re: LM status... on: September 09, 2016, 02:25:20 PM
Yeah, get the alarm data and try to measure RADARUPT frequency, if you wouldn't mind. Thanks!

Though I fear the alarm data will just point us to the alarm call in EXECUTIVE.
36  Project Apollo - NASSP / Programming / Re: LM status... on: September 09, 2016, 02:17:21 PM
Oh, of course, that's not what I was trying to get at. I was just saying we could try that to observe the behavior change if we wanted to.

Also, I wonder whether the AGC is getting ahead of itself if the radar data comes in faster than the ~100ms it took in the real thing. It might see an instantaneous RADARUPT and then immediately try to schedule another reading.
37  Project Apollo - NASSP / Programming / Re: LM status... on: September 09, 2016, 01:48:54 PM
Unfortunately we don't have a LGC version where it is fixed as comparison. That was only done after Apollo 13.

As far as I know, this was just a constant change. The constant is THROTLAG in CONTROLLED_CONSTANTS.agc. For our two versions of Luminary, it has Don Eyles's setting of 0.2. Don's site doesn't say what the value was changed to, but we'll probably get pretty close just by changing that constant to 0.075, until we get a real Apollo 14+ Luminary listing.  Happy
38  Project Apollo - NASSP / Programming / Re: LM status... on: September 09, 2016, 01:39:29 PM
Yeah, these are probably happening for the same reason as Apollo 11, even if it's not the same root cause... input from some device(s) coming in too quickly. How fast is radar data being fed in? The sum total of all radar requests shouldn't exceed 9 Hz or so.
39  Project Apollo - NASSP / Programming / Re: LM status... on: September 08, 2016, 08:32:22 PM
Fantastic! Congrats on the landing!! Very Happy I'll get on the 401s. I got a build of NASSP going last night, and am currently struggling my way through learning all the controls.  Happy
40  Project Apollo - NASSP / Programming / Re: LM status... on: September 08, 2016, 12:45:00 PM
Yeah, the bit reset should definitely be in agc_engine.c. If CH13b4 has anything to do with the 1210s, then yeah -- the RADARUPTs are needed to clear it. Can the code be changed such that RADARUPTs are generated regardless of the breaker state? I.e., is there any bit of radar code that gets called if the breaker is out, or is it cut off entirely?

Also. Is it possible that the "fast" alarms have a different V05N08 display than the slow ones?
41  Project Apollo - NASSP / Programming / Re: LM status... on: September 08, 2016, 11:33:57 AM
Yeah, RADARUPT happens without anything attached to the radar input or output pins whatsoever.

It's slower than I expected too -- it takes a whole 10 milliseconds for it to start counting (the first ADVCNT pulse), and the rupt itself doesn't happen until nearly 110ms after I wrote to CH13 bit 4 (which is ACTV/ in the trace). The timing could of course be off if I have a wiring error somewhere, but yeah -- pulling breakers on the radars shouldn't interrupt the flow of RADARUPTs, just the validity of their data.
42  Project Apollo - NASSP / Programming / Re: LM status... on: September 08, 2016, 10:30:43 AM
Awesome! Yeah the bit is reset when the request for a RADARUPT is generated by any source, before the computer actually services it.

Also, starting to understand the radar interface circuitry more, it looks like RADARUPTs are generated internally after a sequence of a bunch of pulses is sent to the target radar, rather than on any action from the radars themselves. So they definitely shouldn't be happening if the AGC isn't actively trying to use the radars. But it might still expect the interrupt even if the radars are off. I'll have to see if I can get the rupt to fire in my hardware sim -- I had been thinking I'd need to spoof a radar interface for that to happen but now I'm not so sure.

Of course, take that with a grain of salt until I actually get it to work.  Wink
43  Project Apollo - NASSP / Programming / Re: LM status... on: September 07, 2016, 10:12:47 PM
Another thing to try -- it looks like the hardware resets bit 4 of channel 13 (the radar activity bit) as soon as RADARUPT is triggered. The GenerateRADARUPT function isn't currently doing that. It looks like Luminary might be reading that back in, although I can't see where things would go wrong if it unexpectedly stays set.
44  Project Apollo - NASSP / Programming / Re: LM status... on: September 06, 2016, 08:43:16 PM
Do either of those timers have direct control over LR and/or RR pulses?

And a formal welcome to the project, thewonderidiot. Thanks for helping out with the DINC and the 1103 issues.

Thanks!  Happy

I'm not sure, honestly... it does look like TIME4 at least checks some things about the RR. I'm going to go ahead and make the changes to VirtualAGC anyways, since the incorrect TIME3/TIME4 phasing will make us fail the RUPTCHK test when we get the chance to run the real self-test code. It's probably worth pulling those changes over into NASSP just to see what happens as a result, since the relative timings of a lot of things will change.

e: Pull request for the timer phasing is open:
I still lack the means to test this stuff myself -- my next task is to get Orbiter installed and a clone of NASSP going.  Very Happy
45  Project Apollo - NASSP / Programming / Re: LM status... on: September 05, 2016, 09:06:24 PM
So, I took a closer look at timer timing. VirtualAGC currently increments TIME1, TIME3, and TIME5 all at the same time, however my hardware sim has TIME5 offset by 5ms. Think that might have something to do with it?
(TIME3 and TIME4 are supposed to be phased by 5ms too, but I'm only showing a 2.5ms offset right now. Must have something wired incorrectly somewhere, since the documentation suggests this should be 5ms too. It shouldn't impact what I see for the TIME3/TIME5 offset).

e: Does anybody know of any original source other than E-2052 that specifies phase offsets between the various timers? I'm starting to convince myself, looking at the schematics, that T4 should be offset from T3 by 7.5ms instead of 5ms...

e2: E-2065 lays out a RUPTCHK routine in the self-test code:

"The only non - programmable instruction that  is  checked  is  PINC, which  is
checked in the RUPTCHK subroutine. The fact that TIME3 interrupts  2  1/2  mil -
liseconds after TIME4 assures the proper functioning of all the pulses in this  in -

So that means E-2052, VirtualAGC, and "The Apollo Guidance Computer: Architecture and Operation" are all wrong about the relative phasing of TIME3 and TIME4 -- lovely! That makes two timers that are being incremented with the wrong relative phasing -- TIME4 and TIME5. Possibly the cause of contention issues?
Pages: 1 2 [3] 4
Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!