2 ms·
So they're saying that one memory chip in the FDS has failed, representing 3% of the FDS's memory. The FDS memory seems to be CMOS, which was apparently novel
by denton-scratch 3y ago
So they're saying that one memory chip in the FDS has failed, representing 3% of the FDS's memory.
The FDS memory seems to be CMOS, which was apparently novel at the time of launch[0]. I suppose that means it's static RAM. I have a notion that at least some CMOS SRAM came in 8-bit wide chips, storing 1-4 Kb. So that would imply total RAM of between 20Kb and 80Kb. I haven't managed to track down many definite numbers or facts.
It's programmed in FORTRAN77; it's a very long time since I was adjacent to FORTRAN, but as I recall, all variables were global. I'm sure it's tricky to write code that works even if there's a hole in physical memory; but I guess the absence of heaps and caches must help a lot.
[0] https://www.allaboutcircuits.com/news/voyager-mission-anniversary-computers-command-data-attitude-control/ https://www.allaboutcircuits.com/news/voyager-mission-annive...
- ItCouldBeWorse 3y agoCouldn't you declare a variable that is mapped to the danger zone and canary it.
- AstralStorm 3y agoUnfortunately there's very little code space remaining to code in such a workaround. Easier and safer to rewrite the addresses in a patch.
- denton-scratch 3y agoThat's what I assume the process would be. In those days, a "patch" didn't mean a source-code diff; at least, not in the systems I worked on. We got binary patches. I think they were packaged for use with a program we called "patch", but you could definitely apply them with a hex editor, in a pinch. We got patches for the OS itself this way. But we didn't have access to the OS source, nor the build tools - the OS was written in a proprietary ALGOL derivative, and we didn't have the compiler. I was once shown how to patch the COBOL compiler so that you could produce programs that couldn't be written in COBOL, things like messing with IO ports.