Looking at recent comments on a fast square root routine and on computations of pi(*), I was reminded of this formula

which involves a whole load of square roots and some very easy additions and a final multiplication by a power of two. You get about one extra (decimal) digit of pi for every two square roots - although I'm sure the calculation should be done in binary with a final conversion to decimal.

That is, results for successive values of k in the above formula are:
2.82842712
3.06146746
3.12144515
3.13654849
3.14033116
3.14127725
3.1415138
3.14157294

Just a thought...

(*)

from this thread.

Hello,
BigEd kindly asked for more information about my home-made calculator, here are some for those who may be interested :

As you can see, it looks more like a "duo-digicode" than like a calculator ! I still don't find the hardware I'd like to use for the keyboard. The case is a very basic one from Teko :



It is a 65C02-based machine I finished building 3 months ago : a desktop RPN 4-level stack keystroke-programmable, scientific calculator. I chose to use "old-school" components, hence the alphanumeric display. Some specifications ? They look crude, but I focused on speed -more on that later.

- 6 MHz CPU + 32K RAM + 32K EPROM (2 x 16K switch-selectable, one bank for the calculator firmware, the other one contains Lee Davison's EhBASIC).
- Uses C.R. Bond's floating-point package, which I (partially) debugged and extended.
- 2,000 memory registers (the first 1,000 ones are absolute/indirect addressable, the other 1,000 only indirect-addressable).
- 15,742 user program steps (absolute addressing, no labels).
- The user program can be saved/loaded to/from a PC, using the serial port partially visible at the right side.

Let's take a closer look at the keypads... any comments related to their layout are very welcome !



You can easily guess that I found my inspiration in HP calculators. My machine is some kind of "pot-pourri" of functionalities : I took the number entry method of the hp9100 / hp9810 (scientific notation only), the programming instructions are inspired from the hp41, and so on... and O heresy, there's even a bit of Texas Instruments' TI-57 ! the DSZ instruction operates only on register 000 -simply because it fits my needs, and because it was much simpler to implement ... and faster at run-time.

From a software point of view, around the math package I wrote the user interface, a small program editor and the execution engine. My main goal was speed, so I deliberately chose not to implement fool-proof run-time checks. I'm the only user, it's up to me to know what I can or cannot do : for example, being sure that an indirect register number is actually a positive integer less than 2000... and so on. But of course, if a divide by 0 or an overflow occurs, the program is stopped and an error message a la HP-41 shows up.

Another key to high program execution speed lies in the register and line number processing : when single-stepped, their 3- or 5- digit value is read one digit at a time. But when the R/S key is pressed, all these numbers are first replaced by their equivalent absolute addresses, eliminating the time-consuming conversions from ASCII to binary. A "PACKING" message is displayed during that operation. Then the execution engine starts. Reversely, the ASCII values are put back in memory if single-step mode is entered or if the editor is launched. That simple trick resulted in a 12% speed increase.

Another speed trick is to stop the keyboard scanning interrupt service routine when a program is running. The R/S key columm is left active, and the row is polled each time a user instruction is completed, to check if the user wants to stop the program execution. As a result, the execution rate when using only simple arithmetic operations, averages 2,000 instructions per second. Not that bad, compared to pocket calculators... Complex functions are slower, the longest is nCr, the combinations one : C(3,328 ; 1,664) is computed in approximately 6.5 seconds.

The first photo above shows a running program (computing digits of Pi) ; the VIEW instruction refreshes the X stack display to get a countdown. One big advantage of the 2 x 40 character display is that when a program is single-stepped, the left side dynamically shows the program trace and the right side shows the X and Y stack registers as they are updated :



The 'd' letter besides the number line 00119 tells us that we're in debug mode, single-stepping the program. The instruction pointed at by the 'd' will be executed upon SST press. When in editor mode, the 'd' indicator is replaced with a right arrow.

I have much fun with that toy, writing and debugging the software was also very pleasant. Of course there are many many improvements paths. I'm not a numerical analysis expert and the accuracy, as told by C.R. Bond, is perfectible. (pi is computed in 10,000,000 base -7 digits out of 12)

No doubt I'll go on enhancing this machine ! The next big step will be to find parts for a "real" keyboard, then to have a printed circuit board done... I need some time, as usual.

Hoping some of you found that interesting,
Marc

BTW : I don't know how to hide the "attachments" part which shows up below ; and if I didn't choose the right thread please tell me how to move it. Thanks !

Nice - a serious machine! Lots of room on that 2-line display too.
You might want to check Chris Chung's calculator builds - he uses small push buttons and a legend on the PCB. I think the mechanics of cases and keys are a very difficult area for home made calculators, especially when you include printing of legends.

Thank you for your appreciaton

It seems that we've got the same readings. I noticed Chris Chung's nice work from the beginning. No doubt I'd like to get one of his machines ! I also know of SwissMicros and got 3 of their funny devices... virus, did you say ?

...and you're absolutely right, everything related to the mechanical side of an electronic calculator is by far the most difficult part, unless you have more than serious tooling and skills.

Good point, Swiss Micros are an example of pretty much cracking the problem, although I think some people noted they could scratch off the printed labels if they tried. But they are making things in volume, which will surely help.

Nicely done!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Cool looking contraption, and 65C02 powered. Well done.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thank you very much ; your appreciation has great value to me, really.
...thanks also for the thread renaming

Regards,
Marc

A few more thoughts...
- as this is your own calculator build with your own display and firmware, and loads of available memory, you could presumably implement a double-size or even a quad-size precision for calculation, even without trying to display all the digits, but then your pi program could work more digits at a time.
- you have presumably seen this collection of pi programs for RPN calculators:
http://www.hpmuseum.org/cgi-sys/cgiwrap ... i?read=899
- you have perhaps seen this page on calculating pi using the Chudnovsky method, which relies on a big final square root:
http://www.craig-wood.com/nick/articles/pi-chudnovsky/ (via this page)
(Amazingly, a modern laptop can compute ten million digits of pi in ten seconds or so, even using Python. It's a bit faster in C.)

Yes, I saw the "Pi programs" article on hpmuseum.org (archived it last year) ; very interesting reading indeed. On the other hand, I didn't see the second page and I'll take some time for it !

By the way, maybe do you know of "pifast" ? It is very powerful, written in optimized assembly -and it puts a very heavy load on the processor(s) :
http://numbers.computation.free.fr/Cons ... thome.html

You're right about these double- or quad-precision considerations. That would be quite an undertaking anyway, with some trade-offs between accuracy and speed. I suppose that enhancing the round-off error processing would be another way.

(BTW, it looks like might be using routines from Calc65 as the basis for your calculator? Here's a link to a previous discussion which also points to some fast arithmetic discussions.)

Thanks, I don't think I did see pifast. I'm not sure if it's still true but there was a time when calculation techniques (and CPU speeds) were improving very quickly. Supercomputers were once the natural platform, but eventually PCs took over. I read an amusing note yesterday: sometime before he came to England in 1914, Ramanujan had given 7 new formulas relating to pi, without proof. They were proved in 1995. But in 1985, William Gosper used one of them to calculate a record-breaking 17 million digits. It might seem odd to use an unproved formula. But it had already been proved that the formula was either correct, or would be wrong by the 3 millionth digit - and the new calculation in fact matched the previous record holder up to its 16 million digits. So using the unproved formula ended up demonstrating its correctness!

As that pifast page points to some other pages which have since vanished, here are archives:
- Shigeru Kondo pi pages The home page of the holder of most of the p and e records on a home computer.
- Stu's pi page A best pi programs record site.

BTW that page about Chudnovsky's method is the final one of a series:
Fun with Maths and Python - Introduction
Pi - Gregory's Series
Pi - Archimedes' Method
Pi - Machin's Method
Pi - the the Chudnovsky algorithm

I archived the 4 pages. Sooner or later I'll explore the other methods, especially Chudnovsky's. I need to work out a conversion to a "hand done" multiprecision computation... some fun (?) for some evenings

Thinking about it, presumably your calculator language offers arrays and loops, and so the multiprecision work has to be done in a user-level program which loops over arrays? If you build some multiprecision operations in the firmware, you could get the hard work done inside the calculator's functions without needing a user level program. That would be faster, and offer the possibility of improved firmware doing a better job without any change to a user's program.

I'm thinking of something like the array and matrix handling of the HP15C, where the same operations (addition, subtraction, square roots) can apply to numbers, or to complex numbers, or to arrays and matrices.

True, the multiprecision work is done at the user-level. I already thought about extending C.R. Bond's library with multiprecision, at least for the 4 operations, plus integer and fractional parts. That involves a significant amount of work, since my firmware is rather tightly packed. I didn't envisaged such an evolution from the ground up, and I may have to rewrite significant portions of my code. I built it as modular as possible but some portions are rather convoluted. (for example, some fields of the ST+ / ST- / STx / ST/ opcodes hold their FSM status during their execution -not a so good idea, but I did that to enable me to manually STO / RCL during a debug session, even if another STO... in the user program is pending, reading its 3-digit argument one digit at a time)

Besides that, the floating-point package uses speed tricks in multiplication and division : a pre-processing stage builds a table of multiples, from 1 to 9, of one operand. One can easily imagine the impact it would have on the memory allocation, once "extended" Another point : working with more-than-256-byte F-P registers implies a switch to 16-bit pointers, and even with a smaller format, having the scratchpad F-P registers in zero page will become impossible, negatively impacting the speed.

Eh eh... should I build and program a new, 65C816-based machine ? In such a case I need 2 more years

Edited : incomplete sentence.