Earlier quoted context omitted.
The joke has been going on for quite some time now - Lisp and related languages use Polish Notation everywhere. (The main benefit is that (R)PN is parenthesis-free, so it makes it easier for a calculator to process expressions with multiple operators. The use in programming languages is nonexistent but to make clear that +, *, .. are just like any other function call, where you would naturally use polish notation.)
Not nonexistent-- there are many stack-oriented programming languages[1], of which Forth is the most famous. There's even a "Reverse Polish Lisp" on HP calculators! [1] http://en.wikipedia.org/wiki/List_of_programming_languages_b...
Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
21–30 of 103 posts
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#22Unfortunately, as calculator prices collapsed, so did Sinclair Radionics' profits, and the company was broken up in 1979 after heavy losses. He fought Moore's law, and the law won. But this whole thing reminds me of Woz's work in the first Apples. Why wasn't his genius work similarly wiped out? Soon after the Apple, there were dozens - hundreds - of new personal computer manufacturers. I think it's software. The valu…
Apple fell to the PC because the hardware was a fraction of the price since clones were allowed to exist in the PC world.
Apple sued their clones out of existence. Might all be using Apple today if they had not.
Then they eventually switched to pc hardware themselves.
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#23The bit that is probably most striking to modern eyes is the data representation. With 320 instructions there's simply no room for the "obvious" code to translate to and from a display representation. So everything was stored in BCD and operated on one (decimal!) digit at a time using a 4-bit ALU.
I was under the impression that BCD was commonly used in calculators. I know that my HP 48 used BCD and was able to address 4 bit nibbles.
You're right that BCD is very common for calculators. BCD was also commonly used in microcomputers, since you save all the binary-to-ASCII code for I/O. This is why x86 has a bunch of BCD instructions like AAA (ASCII adjust after addition), which was important enough to be a single-byte opcode.
The 6502 is notable for its highly-efficient and patented (https://www.google.com/patents/US3991307) decimal arithmetic mode. I'll write up its interesting circuits sometime. One consequence of the patent is the processor in the NES video game is a 6502 clone that lacks decimal mode.
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#24Earlier quoted context omitted.
Not nonexistent-- there are many stack-oriented programming languages[1], of which Forth is the most famous. There's even a "Reverse Polish Lisp" on HP calculators! [1] http://en.wikipedia.org/wiki/List_of_programming_languages_b...
Sorry, I meant there is no benefit to using it in programming languages.
Forth is arguably the best language in terms of expressive power/language complexity, though that's largely due to the denominator.
It's a great choice for tightly constrained devices, though far fewer devices have such constraints now. The mental overhead of having to track stack-effects for each function makes it difficult to scale to large systems and maintain productivity, but if you're trying to eke every iota of power out of a chip with a tiny amount of ROM, it's hard to beat a direct-threaded (or token-threaded...) Forth.
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#25Unfortunately, as calculator prices collapsed, so did Sinclair Radionics' profits, and the company was broken up in 1979 after heavy losses. He fought Moore's law, and the law won. But this whole thing reminds me of Woz's work in the first Apples. Why wasn't his genius work similarly wiped out? Soon after the Apple, there were dozens - hundreds - of new personal computer manufacturers. I think it's software. The valu…
VisiCalc on the Apple had a huge contribution to its success. It was the proverbial "killer app" that drove Apple II sales.
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#26Earlier quoted context omitted.
I was under the impression that BCD was commonly used in calculators. I know that my HP 48 used BCD and was able to address 4 bit nibbles.
You're right that BCD is very common for calculators. BCD was also commonly used in microcomputers, since you save all the binary-to-ASCII code for I/O. This is why x86 has a bunch of BCD instructions like AAA (ASCII adjust after addition), which was important enough to be a single-byte opcode. The 6502 is notable for its highly-efficient and patented ( https://www.google.com/patents/US3991307 ) decimal arithmetic mo…
I had thought the 2A03 didn't have BCD to save silicon-- but apparently they just crudely disabled it by removing 5 transistors[1]! Would Ricoh's second-source 6502 license have been more expensive if they included BCD?
[1] http://www.visual6502.org/wiki/index.php?title=6502DecimalMo...
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#27Unfortunately, as calculator prices collapsed, so did Sinclair Radionics' profits, and the company was broken up in 1979 after heavy losses. He fought Moore's law, and the law won. But this whole thing reminds me of Woz's work in the first Apples. Why wasn't his genius work similarly wiped out? Soon after the Apple, there were dozens - hundreds - of new personal computer manufacturers. I think it's software. The valu…
VisiCalc on the Apple had a huge contribution to its success. It was the proverbial "killer app" that drove Apple II sales.
Yes, that and Apple Writer. Full disclosure: I wrote Apple Writer.
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#28Unfortunately, as calculator prices collapsed, so did Sinclair Radionics' profits, and the company was broken up in 1979 after heavy losses. He fought Moore's law, and the law won. But this whole thing reminds me of Woz's work in the first Apples. Why wasn't his genius work similarly wiped out? Soon after the Apple, there were dozens - hundreds - of new personal computer manufacturers. I think it's software. The valu…
Sinclair's branding was huge in the UK, but you can only sell so many calculators and the leapfrog in sophistication in those days was breathtaking. Technologies plummeted in price within months.
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#29So is 'reversing' a common lazy shorthand for 'reverse engineering'? The title confused me until I realized what it was about. Feeling like an old fart...
Simple explanation - there wasn't room to fit "reverse engineering" into an 80-character title.
Very apt, considering the topic.
Tho in 1974 Sinclair could've fit it in a 37-char title.
Re: Reversing Sinclair's amazing 1974 calculator hack - half the ROM of the HP-35
#30Nicely done, especially compared to the fits that HP went through trying to figure out how they could prove or disprove that all 11 digits of their calculation were correct.
I wouldn't call them "fits", really. 40 years ago these calculators were looked upon with a bit of skepticism. Engineers that were used to seeing the log tables with their own eyes and hand-manipulating slide rules were being asked to trust the results coming out of these calculators. And lives depended on it, really. If you were a civil engineer designing a bridge and you needed to be absolutely sure the numbers you…
Trusting the numbers coming out of a calculator was ALWAYS a bad idea, especially if lives depended on it. It wasn't just the calculator making a mistake - you could have made a mistake keying in the numbers.
This is dealt with by:
1. running the results through the inverse equations to verify that you get the inputs back again
2. calculating the results using an independent method to verify them
3. having a different group of people independently check your numbers
4. have your results pass a "reasonableness" test, i.e. do they make sense
5. put the resulting design on a test rig and verify the numbers experimentally
How do I know this? I worked on critical flight control systems for Boeing.
Any engineer who just punches numbers into a calculator and bets lives on the results ought to be fired.