Meadville Space Center
Welcome, Guest. Please login or register.
September 24, 2020, 01:55:52 PM

Login with username, password and session length
Search:     Advanced search
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
  Show Posts
Pages: [1] 2 3 4
1  Project Apollo - NASSP / Project Apollo - NASSP News & Discussion / Re: NASSP moving to Orbiter Forum? on: April 24, 2018, 01:47:20 PM
I'm totally on board with moving to the Orbiter forum. It took me 6 tries to view this thread, 2 to vote in the poll, and 4 to get to the "post a reply" screen. It would be really nice to have an existing, maintained forum that handles technical issues, user registration, and all that for us. I also think that it might potentially help with attracting new developers. Thumbs Up
2  Project Apollo - NASSP / Support & Bugs / Re: LM G&C checklists anywhere? on: January 17, 2018, 08:03:34 PM
That was due to a misunderstanding of the cause of the program alarms, right?
3  Project Apollo - NASSP / Support & Bugs / Re: CMC/LGC Restart on: December 25, 2017, 03:52:00 PM
Yeah, sounds like something is broken -- hardware restarts generally wouldn't be accompanied by program alarm lights, especially without anything in FAILREG,+1,+2. But assuming things aren't fundamentally broken, for a RESTART light, though, the most useful information exists in channel 77, which as Thymo says can be read with V01N10E 77E. The erasable locations RSBBQ,+1 are also useful; those registers hold the BBANK and Q registers as they were at the time of the restart, so you can figure out exactly what code was running when the restart happened. You can display those with V04N01E 1432E in both Luminary 99 and Comanche 55.
4  Project Apollo - NASSP / Project Apollo - NASSP News & Discussion / Re: Merry Christmas and Happy Holidays! on: December 25, 2017, 03:43:03 PM
Merry Christmas everyone! This has been a fantastic year for NASSP. Here's to 2018 being just as good!  Very Happy
5  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGS Development on: October 22, 2017, 12:30:41 AM
So all it has to do is listen to the special data word that says "AGS update" and respond to the interrupt generated by that data word, right?

Yeah, pretty much. The AGS has an 18-bit input register that captures the first 18 bits of a 40-bit AGC downlink word. There's an additional discrete input for the Downlink End signal from the PCM, which sets a flip-flop. When the program detects that this input bit is set, it reads in the captured 18 bits. This read automatically clears the "end" flip-flop.

So in theory, all we need to do is read the downlink data out of the AGC, assemble the 18-bit word that the AGS is expecting and jam it into its input register, and then set a bit for it to know that it has data. I haven't looked, but aea_engine.c might need to be updated on the VirtualAGC side to automatically reset the end bit on input register read.
6  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGS Development on: October 19, 2017, 04:15:19 PM
It's serial -- it's an identical copy of the downlink data line to the PCM. The PCM also sends the downlink start, downlink end, and downlink clock signals that drive the AGC's downlink circuitry to the AGS. The AEA is effectively a passive listener on the AGC's downlink channel; it detects when the AGC has special downlist selected and initializes itself based off of that telemetry.
7  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: March 25, 2017, 07:47:45 PM
Yeah, there's a bit of known weirdness around that stuff. One of the things I'm working on now is making all of the static things in agc_engine.c non-static and part of the state structure, which should solve all of those issues.
8  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: March 25, 2017, 06:56:45 PM
Alright, to answer your question more specifically:

PROG: This light is entirely under software control, so without knowing which alarms might occur, it's impossible to say what might be wrong.
RESTART: The RESTART light is forcibly prevented from turning on when leaving STANDBY until timepulse 10 of GOJ1. At this point, the signal that sets the RESTART light (GOJAM) has been comfortably off for a while. If the RESTART light were to come on, that means the AGC was powered back up long enough to execute at least a full instruction, and then for some other reason (power transients etc.) took another reboot. VirtualAGC isn't simulating anything to that level of detail, so the normal case of no RESTART is expected.
CMC: This light isn't currently simulated at all by VirtualAGC itself, partly because our standalone AGC/DSKY doesn't a window for that light, and partly because we don't yet have any copies of the schematics for AGC module B8, which housed the warning filter that drove this light (though we hope this situation will change in the near future). Anyways, standby also doesn't directly affect this light, and any instances of it turning on would be related to the aforementioned possible restarts caused by power transients or other things of that nature.
9  Project Apollo - NASSP / Planning / Re: Documentation on: February 04, 2017, 03:29:13 PM
The NTRS has had a major upload. It's going to take a while for the 'data mole' to fully sort out what has been added but here is one sample document:

Apollo guidance computer program block 1 /100/ and block 2 Final report, 25 Jul. - 31 Dec. 1969 (110 pg 66mb)

I have also seen one document with Apollo 19 in the abstract...

Did anybody, by any chance, happen to download this document? I can't find any copies online anymore.
10  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: V8 Release Work Thread on: January 29, 2017, 08:41:59 PM
Your standby light is probably controlled by output channel 13 bit 11, which is set at entry to P06. This bit is what enables standby to be started via PRO depression. The VirtualAGC agc_engine.c and yaDSKY2 use the new fake output channel 163 to simulate these hardware (rather than software)-controlled lights. The STANDBY light is bit 9 (00400) of that channel. Indy mentioned that he used channel 163 for something else, though, so there might need to be some renumbering somewhere.

As far as lights going off -- that happens because the DSKY receives the AGC's switched 14V rail for use in its EL power supply. When +14VSW stops providing power, the EL segments all go off. yaDSKY2 doesn't do this yet... it's on my TODO list. But basically you'll just want to manually switch them off whenever State->Standby is 1, and restore their previous state when it goes back to 0. EDIT: Actually, you could just dual-purpose the STANDBY light bit in channel 163 for this.  Happy

As far as your edit -- I'm not sure if I'm reading it correctly, but it is possible to go straight through standby and back out into the V37 program selection if you just keep holding PRO down.
11  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: V8 Release Work Thread on: January 20, 2017, 02:19:48 PM
SbyPressed currently needs to be reset by whatever DSKY you have as soon as PRO is released. If it's left high the computer will come right back out of standby after one period of F17B (0.78 seconds).
12  Project Apollo - NASSP / Support & Bugs / Re: CSM hibernation? on: January 15, 2017, 12:13:31 AM
I hope you don't mean standalone yaAGC/yaDSKY2 by "upstream"! It works locally for me, so hopefully it would for you too. The light doesn't come on until standby is actually entered. The standby circuitry is timed identically to the night watchman, so once P06 is selected, standby will be entered and the STBY light will be lit anywhere from 0.64 to to 1.92 seconds after PRO is depressed and held (depending on the phasing of the scaler when the button is pushed). If it comes on any sooner, it probably means it thinks PRO was being held down even though it wasn't. (And as an aside, it would be possible to do exactly that on a real AGC for an accelerated standby -- holding PRO down while starting P06.  Happy )
13  Project Apollo - NASSP / Support & Bugs / Re: CSM hibernation? on: January 13, 2017, 05:41:07 PM
Also, for the most part, you don't need to worry about the destructiveness of reads on erasable memory. The vast majority of resets are caused by the signal STRT1 (which is more-or-less an OR of the various hardware alarms and standby). STRT1 gracefully lets the current MCT run to completion before triggering a GOJAM. And as far as I know every MCT of every instruction sequence in the AGC takes care of writing read values back out to memory -- so in standard resets there isn't any danger to erasable values.

There are a couple of things, on the other hand, that can trigger a STRT2 signal. While I don't know exactly what they are (we're missing the schematics to module B8), I believe it to be something like an OR of a scaler failure and a bus voltage failure. Anyways, STRT2 is treated much more urgently, and GOJAM occurs right away instead of waiting for the MCT to finish. If that happens at the right point you can end up with memory that has been destroyed -- and the next time the AGC is turned on, it will take a STRT1 restart from a parity failure the first time it access that address. That will only ever be a single corrupted address.

As far as I know, once the erasable memory has been loaded at the factory, the above is the only way to actually destroy values in it.

As for what's powered in standby -- it's all of the scaler module (so every clock frequency), all of the timer module except for the 12-step timepulse counter (so timing leading leading into and including the first scaler stage, as well as the start/stop logic), half of the Alarms module (mostly B8 interfacing stuff like STRT2 -- STRT1-relating things are off), and a handful of things in the In-Out modules related to keeping clocks to peripherals going. And, of course, the gates that can get you back out of standby.  Happy
14  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: January 07, 2017, 12:39:11 AM
Okay, super! Ron's marked the sim as sponsored by the "NASSP Group" on the website (we can change that to your real names if you want). In this case, it's probably easier (for me at least) if one of you be the primary sponsor and handles the money. archive.org at least doesn't have any problems with billing people who live outside of the US. So whoever the primary sponsor is going to be, shoot an email to Ron (info@sandroid.org) and he'll get with you on the paperwork.  Very Happy
15  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: January 05, 2017, 10:40:23 PM
@indy91, @kneecaps, and @jalexb88 --

We've just found a sponsor that is willing to cover the total cost of Zerlina. I wanted to run it by you guys, though, to see what you thought, since there was discussion of putting your money towards that. If you're still really keen on that, we can see if this person would be open to sort of filling in for me to cover the remainder. Otherwise, we could fall back on the sim idea. Outside of the Zerlina sim, the only two listings that don't have sponsors are the Luminary 131 and Luminary 99 rescans, so all of the new things will be covered.  Happy

Let me know what you guys think.
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!