Voyager Status, What is it? Options

[tuvas]

Anyone know the latest Voyager status? I've hear rumors, but I'm wondering if anyone has anything more concrete (I won't share the rumors, as I really don't know much about it, so...)

[mcaplinger]

The Voyager FDS was designed several years before the first microprocessors. It has some unusual architectural features, including 128 general-purpose registers (mapped from the main RAM and not as separate logic entities) and a six-clock basic instruction cycle operating on 4-bit values per clock.

I'm not sure how the Voyager team is proceeding. If I were faced with this problem, I would try to build the smallest possible software load that would send useful telemetry to the transmitter. And to support that, I would build a software simulator of the system and make sure the behavior of existing loads was understood. The FDS memory (8K, I think) is loaded through the CCS, so it should be possible to experiment a bit with new FDS loads without the possibility of bricking everything, assuming of course that the CCS keeps working.

[stevesliva]

What I gathered from Ars was simply that they're going to try to command it into "encounter mode" or some such other modes. Which make sense, try that before software reload, see what happens.

Floyd -- the very long PDF linked by mcaplinger above has lots of details, including that tidbit about the massive amount of registers. The images basically look like the "8K" memory is probably something like 256 discrete CMOS ICs -- making each 32 bits, so if each register is 4bits, maybe there are 16 chips for the "registers" and 240 for the rest of the memory. All that to say -- the reason the registers are mapped from "main" memory is because the MPU itself is a collection of discrete ICs on a huge board with probably hundreds of SRAM ICs... the memory bottlenecks aren't analogous to CPUs.

In any event, if there really were 128 x 4 = 512 bits of registers over 16 separate chips, simple programs probably don't need to use all 128. So I was thinking a bad register would be hypothetically easy to work around, esp since there's not image processing happening. There is some text on page 187 of the PDF about how DMA instructions take the same time that all other instructions take... or I don't quite follow. Probably the biggest distinction between the regs and the other memory words was that the regs were addressable with 7 bits of a 16-bit instruction, while the memory addresses were 4k/16=8bits? So separate instructions were needed to access the "lower 4k" instruction memory vs. upper 4k scratch vs. upper 4k scratch in other unit? Also not clear to me how a 16-bit memory word would load into 4-bit registers, but this is a special ISA, so perhaps 4 registers load at a time. The other thing indicated is that arithmetic would be slow... a several cycle operation because it was doing 4-bits a cycle. Perhaps a more common operation was to simply forward along specific ranges of data, or MSBs, etc.

All that to say, a bit flip in one of the registers shouldn't be more fatal than a bit flip in instruction memory... just even harder to work around at this stage, because you have to change and reload the firmware. And sure, if a 16-bit word has to load into 4 registers, maybe there are effectively 32 and not 128 registers, when it comes to programs loading from memory. But 32 --> 31 should still be manageable.

[mcaplinger]

if each register is 4bits

I don't think the registers are 4 bits, I think the ALU does arithmetic 4 bits at a time on presumably 16-bit registers. This is called bit-slicing and was a fairly common design technique at the time: https://en.wikipedia.org/wiki/Bit_slicing