Writing a lunar lander game for an actual lunar lander(cowlark.com)
cowlark.com
Writing a lunar lander game for an actual lunar lander
http://cowlark.com/2019-07-20-cowgol-agc/
17 コメント
Complete guess, but I would say they weren't just optimizing for ease of creating software, they were also optimizing for ease of creating the hardware.
If you're creating hardware that's only going to be used a few times, it's probably not worth it to spend a lot of effort into giving it every feature that programmers want.
If you're creating hardware that's only going to be used a few times, it's probably not worth it to spend a lot of effort into giving it every feature that programmers want.
I think you're on the right track but the motivation would be more for a smaller, lighter mass computer and not so much the one off nature as they made many hardware changes as requirements changed.
Still I feel the 1s compliment was perhaps more of a choice based around the familiarity of the designer, Eldon Hall. It was a style of the times and 2s compliment had not yet become the dominant standard.
They did add instructions when the programmers asked for them --- such as the famous EDRUPT instruction (whose use is still a bit of a mystery).
> it’s strictly limited to only being able to compute x/y when |x|>|y|. Anything else, you get garbage, including in the y=x
I think it's literally just to keep the math circuit logic very simple, it'll be identical to MOD (just need to look at the remainder register) and |x| <= |y| will either require some hackery to convert it (with an appropriate test) or the machine having some idea of non-integer numbers.
For implementation of division, you could have the circuit equivalence of:
Of course there would be no checking, hence the garbage out when you misuse it. Your checking would be done manually.
[1] https://en.wikipedia.org/wiki/Ones%27_complement
I think it's literally just to keep the math circuit logic very simple, it'll be identical to MOD (just need to look at the remainder register) and |x| <= |y| will either require some hackery to convert it (with an appropriate test) or the machine having some idea of non-integer numbers.
For implementation of division, you could have the circuit equivalence of:
uint div(x, y){
uint t = x; //temporary (don't want to touch x)
uint c = 0; //counter
while(t >= y){
t = t - y;
c = c + 1;
}
return c; //remainder is in t
}
Of course there would be no checking, hence the garbage out when you misuse it. Your checking would be done manually.
[1] https://en.wikipedia.org/wiki/Ones%27_complement
I have the same question. My first guess would be it was due to the reality of using the limited space and design process. Note the mention in the article about asynchronous logic and hand-wired gates. It probably seemed a better trade-off to keep the circuit as simple as possible if it would work fine and out of the box for a majority of the cases.
Hello, author here.
It's a surprisingly modern-ish system, in many ways, and surprisingly weird in lots of other ways. One thing which really surprised me was a complete lack of pointer support: I managed to bodge the look-up-table instruction (which evaluates its argument and adds the result to the next instruction to be executed) to do pointer dereferences instead (INDEX ptr; TC 0). And, luckily, I found a way to make the assembler emit an address as a literal value, which it really didn't want to do.
It's a shame the address space is so small (only 12 bits!) or you could totally port real software to this...
It's a surprisingly modern-ish system, in many ways, and surprisingly weird in lots of other ways. One thing which really surprised me was a complete lack of pointer support: I managed to bodge the look-up-table instruction (which evaluates its argument and adds the result to the next instruction to be executed) to do pointer dereferences instead (INDEX ptr; TC 0). And, luckily, I found a way to make the assembler emit an address as a literal value, which it really didn't want to do.
It's a shame the address space is so small (only 12 bits!) or you could totally port real software to this...
I've updated the post on cowlark.com which a decent writeup on the machine's more interesting quirks.
Hm - I keep getting a 1202 program alert when hovering near the surface.
1201 and 1202 errors are non-disruptive overflow notices, see [1]
[1] https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html
[1] https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html
I think that's the longest non-loop Youtube video I've ever seen.
My writing-a-vi video is longer (by about ten minutes).
I thought about this myself and it's really cool to see someone follow through on such a whimsical project. One consideration is that the is already a great lunar lander game for this system!
[deleted]
Does anyone know of any FPGA implementation?
https://github.com/virtualagc/agc_simulation
And write up of Mike Stewart's approach to handling the async logic and propagation delays.
http://mikestewart.hcoop.net/2016/03/06/fpga-support/
And write up of Mike Stewart's approach to handling the async logic and propagation delays.
http://mikestewart.hcoop.net/2016/03/06/fpga-support/
>"Division. Arrgh. The AGC does have hardware division (and multiplication), but it’s strictly limited to only being able to compute x/y when |x|>|y|. Anything else, you get garbage, including in the y=x case. This hit me several times and trying to deal with all the sign issues, combined with the 1s-complement sign issues above, was really painful."
Not being expert in slightly outdated processor architectures (1s compliment!), might someone more expert than I be able to tell me _why_ this is the case and was a good design decision? It seems like a potential way for unexpected sensor data to bite you in the arse...