Post Reply 
Check this guy out!
10-28-2024, 09:07 PM (This post was last modified: 10-29-2024 02:12 PM by Commie.)
Post: #1
Check this guy out!
Hi Chaps,

I have been looking to design a rpn calculator using ieee 754 32bit binary floats and I have accumplished this with a compiler and an 8051 mcu. So, although the rpn functions correctly( after alot of work and testing), the problem is found to be ieee 754 32bit floats, as most compilers only support.I do have an AVR compiler which supports ieee 754 64bit binary floats at my disposal.

I wrote my own transcandential math functions using the pade algorithm, this is the same as Taylors series except the pade algorithm yields more accuracy because it is a polynomial divided by another polynomial. I tried Cordics, got it working but there wasn't much advantage in it so I continued with the pade algorithm, supported by Derive 6.2 math pc package.
Anyways, ieee 754 32bit binary floats turn out to be a pile of crap.I did not not know this until I prototyped and then the ugly truth revealed itself regarding ieee 754 floats during protyping.I have since realised that commercial calculators use bcd floating point and have done so for many years and for good reason, which yields much better accuracy results.

Now, Alex Garza has developed a HP15c called the PX15c and is avalable as kit or ready built, however the interesting thing is, he has squeezed it into a $3 atmega328 AVR mcu which is totally amazing and I wish him well with his endevours.I believe his design is one that uses NUT cpu emulation.

Well, there you have it, and then I came across this guy from the czech republic and it appears as though he is a real pro, heres the link:

https://www.breatharian.eu/hw/et58/index_en.html

His calculator is open source and I think I'm going to have a go at building it.

Cheers
Darren
Find all posts by this user
Quote this message in a reply
10-29-2024, 07:17 AM (This post was last modified: 10-29-2024 07:18 AM by HP67.)
Post: #2
RE: Check this guy out!
The project and site were mentioned in another thread which I saw just before this one. Looks very interesting.

It ain't OVER 'till it's 2 PICK
Find all posts by this user
Quote this message in a reply
10-29-2024, 11:37 AM
Post: #3
RE: Check this guy out!
See also

https://www.hpmuseum.org/forum/thread-22596.html

A1

HP-15C (2234A02xxx), HP-16C (2403A02xxx), HP-15C CE (9CJ323-03xxx), HP-20S (2844A16xxx), HP-12C+ (9CJ251)

Find all posts by this user
Quote this message in a reply
10-29-2024, 12:03 PM
Post: #4
RE: Check this guy out!
Or earlier: https://www.hpmuseum.org/forum/thread-20241.html
Find all posts by this user
Quote this message in a reply
10-29-2024, 02:02 PM
Post: #5
RE: Check this guy out!
(10-28-2024 09:07 PM)Commie Wrote:  Hi Chaps,

I have been looking to design a rpn calculator using ieee 754 32bit binary floats and I have accumplished this with a compiler and an 8051 mcu. So, although the rpn functions correctly( after alot of work and testing), the problem is found to be ieee 754 32bit floats, as most compilers only support.I do have an AVR compiler which supports ieee 754 64bit binary floats at my disposal.

I wrote my own transcandential math functions using the pade algorithm, this is the same as Taylors series except the pade algorithm yields more accuracy because it is a polynomial divided by another polynomial. I tried Cordics, got it working but there wasn't much advantage in it so I continued with the pade algorithm, supported by Derive 6.2 math pc package.
Anyways, ieee 754 32bit binary floats turn out to be a pile of crap.I did not not know this until I prototyped and then the ugly truth revealed itself regarding ieee 754 floats during protyping.I have since realised that commercial calculators use bcd floating point and have done so for many years and for good reason, which yields much better accuracy results.

Now, Alex Garza has developed a HP15c called the PX15c and is avalable as kit or ready built, however the interesting thing is, he has squeezed it into a $3 atmega328 AVR mcu which is totally amazing and I wish him well with his endevours.I believe his design is one that uses NUT cpu emulation.

Well, there you have it, and then I came across this guy from the czec republic and it appears as though he is a real pro, heres the link:

https://www.breatharian.eu/hw/et58/index_en.html

His calculator is open source and I think I'm going to have a go at building it.

Cheers
Darren

Check out this post: DIY CALCULATOR

This calculator uses an ATMEGA328 microcontroller with 64-bit (IEEE 754) precision.

It’s not programmable, but it does have a standard TVM (Time Value of Money) and scientific functions.
Find all posts by this user
Quote this message in a reply
10-29-2024, 02:46 PM (This post was last modified: 10-29-2024 03:17 PM by Commie.)
Post: #6
RE: Check this guy out!
(10-29-2024 02:02 PM)agarza Wrote:  Check out this post: DIY CALCULATOR

This calculator uses an ATMEGA328 microcontroller with 64-bit (IEEE 754) precision.

It’s not programmable, but it does have a standard TVM (Time Value of Money) and scientific functions.

Yep, nice design but the ieee 754 64bit floats are utilised and as pointed out already, ieee 754 binary floats are crap, one reason is passing input numbers through strings and back again to the display, when converting from strings to float(and back again) causes a small conversion error which grows as you pass back and move the floats around. The best is bcd floats because they are transparent to i/o or strings and here is the problem, all the compilers, that I have seen or made aware of either use ieee 754 32 or 64 bit binary floats. This is done intentionally to stop would be good calculator design and protects the lower end of the existing scientific calculator market. So the only option open is to go assembler and try and mix the software with a standard high level compiler, avoiding the ieee 754 floats. A big help would be to have access with 64 bit integer data type support but the one compiler (that I have seen) that supports this, costs about $1500.
EDIT:
There is another option, original cpu emulation but this involves becoming an expert with the original cpu at low level, nay, try finding coherent info on the NUT cpu.

Cheers
Darren
Find all posts by this user
Quote this message in a reply
10-29-2024, 03:37 PM
Post: #7
RE: Check this guy out!
(10-29-2024 02:46 PM)Commie Wrote:  
(10-29-2024 02:02 PM)agarza Wrote:  Check out this post: DIY CALCULATOR

This calculator uses an ATMEGA328 microcontroller with 64-bit (IEEE 754) precision.

It’s not programmable, but it does have a standard TVM (Time Value of Money) and scientific functions.

Yep, nice design but the ieee 754 64bit floats are utilised and as pointed out already, ieee 754 binary floats are crap, one reason is passing input numbers through strings and back again to the display, when converting from strings to float(and back again) causes a small conversion error which grows as you pass back and move the floats around. The best is bcd floats because they are transparent to i/o or strings and here is the problem, all the compilers, that I have seen or made aware of either use ieee 754 32 or 64 bit binary floats. This is done intentionally to stop would be good calculator design and protects the lower end of the existing scientific calculator market. So the only option open is to go assembler and try and mix the software with a standard high level compiler, avoiding the ieee 754 floats. A big help would be to have access with 64 bit integer data type support but the one compiler (that I have seen) that supports this, costs about $1500.

Cheers
Darren

Your best bet would be to write your own 64-bit BCD library.
Find all posts by this user
Quote this message in a reply
10-29-2024, 04:47 PM
Post: #8
RE: Check this guy out!
(10-29-2024 02:46 PM)Commie Wrote:  ...
The best is bcd floats because they are transparent to i/o or strings and here is the problem, all the compilers, that I have seen or made aware of either use ieee 754 32 or 64 bit binary floats. This is done intentionally to stop would be good calculator design and protects the lower end of the existing scientific calculator market. So the only option open is to go assembler and try and mix the software with a standard high level compiler, avoiding the ieee 754 floats. A big help would be to have access with 64 bit integer data type support but the one compiler (that I have seen) that supports this, costs about $1500.

One way of doing this is to do what the calculators written for the DM42 hardware do, and that is to use a library that offers decimal arithmetic - decNumbers and the Intel decimal library are the two that I'm familiar with, but I'm sure there are others. (The latter is the faster of the two but takes up much more flash memory, due to use of lookup tables. Free42 uses the Intel decimal library; C43 and C47 use decNumbers; db48x uses a library that c3d wrote himself especially for that calculator!)

For this reason, I'm not sure about the "stopping good calculator design" theory. The WP34S ran on the HP 20/30b hardware (launched in about 2012). This had only a few kilobytes of RAM and 128k of flash memory for the firmware; it used decNumbers to deliver 16 or 34 decimal digits of precision, had a huge number of programming and mathematical functions, and still had about 10k left over for flash storage of user programs. If someone wants to build a calculator which supports decimal floats, they can do it - certainly if they have 128k of flash available.

Also, the GNU cross-compilers that build the pgm files for the DM42 certainly support 64-bit integers (at least for this target), and are of course freely available.

Nigel (UK)
Find all posts by this user
Quote this message in a reply
10-29-2024, 09:29 PM
Post: #9
RE: Check this guy out!
(10-29-2024 04:47 PM)Nigel (UK) Wrote:  For this reason, I'm not sure about the "stopping good calculator design" theory. If someone wants to build a calculator which supports decimal floats, they can do it - certainly if they have 128k of flash available.
Hi Nigel,

I want to design or rather write the code for a clone hp15c, I have read somewhere that the original hp15c rom code is about 6kbyte in length.

I have at my disposal, 8bit PIC's, AVR's and AT89LP51RD2(64Kbyte flash, 2kbyte ram), all are Harvard archtectures and are supported by compilers and are relatively low cost. I think, these mcu's have the required processing power to accumplish my task of developing a hp15c calculator to spec.?

Now, can please tell me how we proceed from here in the utilization and implementation of bcd floating point?

(10-29-2024 04:47 PM)Nigel (UK) Wrote:  Also, the GNU cross-compilers that build the pgm files for the DM42 certainly support 64-bit integers (at least for this target), and are of course freely available.

As far as I am aware, the DM42, from swiss micro's uses an ARM processor? What good is this if I want to design a hp15c using a low cost 8 bit processor.? I should also point out that 9 years ago, I purchased an ARM compiler(which claimed to support 64bit integers) for £220 from Mikroe electronika and has proved completely unusable due to inherent bugs, it's 64 bit integers data types simply do not work. You can still buy this compiler for the now price of $500.

People don't want hp calculators on Apple aps, they want the real thing.
Find all posts by this user
Quote this message in a reply
10-29-2024, 11:58 PM
Post: #10
RE: Check this guy out!
(10-29-2024 09:29 PM)Commie Wrote:  What good is this if I want to design a hp15c using a low cost 8 bit processor.?

The HP-12c Rogue appears to use a 16 digit BCD platform on a 6502 processor. But you'd need to ask HP...!
Find all posts by this user
Quote this message in a reply
10-30-2024, 10:09 AM (This post was last modified: 10-30-2024 10:09 AM by RPNerd.)
Post: #11
RE: Check this guy out!
(10-29-2024 09:29 PM)Commie Wrote:  I have read somewhere that the original hp15c rom code is about 6kbyte in length.

Make that 12 kB. The original 15C had two ROM chips, each filled to 6 kB if memory serves.

Yup... Looking at a dump of the ROM now and content goes from 0000 to 17ff and from 2000 to 37ff. Actually a few bytes less because from 37f3 to 37ff is just zeroes.

Current daily drivers: HP-41CL, HP-15C, HP-16C
Find all posts by this user
Quote this message in a reply
10-30-2024, 11:16 AM
Post: #12
RE: Check this guy out!
(10-30-2024 10:09 AM)RPNerd Wrote:  Make that 12 kB.

I thought 6kb was abit low, thanks for the heads up. 12kbyte rom size is still magic.

Cheers
Darren
Find all posts by this user
Quote this message in a reply
10-30-2024, 11:47 AM
Post: #13
RE: Check this guy out!
(10-29-2024 09:29 PM)Commie Wrote:  I have at my disposal, 8bit PIC's, AVR's and AT89LP51RD2(64Kbyte flash, 2kbyte ram), all are Harvard archtectures and are supported by compilers and are relatively low cost. I think, these mcu's have the required processing power to accumplish my task of developing a hp15c calculator to spec.?

Now, can please tell me how we proceed from here in the utilization and implementation of bcd floating point?

As far as I am aware, the DM42, from swiss micro's uses an ARM processor? What good is this if I want to design a hp15c using a low cost 8 bit processor.? I should also point out that 9 years ago, I purchased an ARM compiler(which claimed to support 64bit integers) for £220 from Mikroe electronika and has proved completely unusable due to inherent bugs, it's 64 bit integers data types simply do not work. You can still buy this compiler for the now price of $500.

You are correct: my suggestions aren't useful for an 8-bit processor with 64k of program space. I hadn't realised that this is what you are working with. So far as I can see, the GNU C compiler doesn't target 8-bit processors at all.

Sorry!

Nigel (UK)
Find all posts by this user
Quote this message in a reply
10-30-2024, 12:01 PM (This post was last modified: 10-30-2024 12:03 PM by HP67.)
Post: #14
RE: Check this guy out!
I seem to remember Keil has some freebies on their site. I think for 8051, not sure if other microcontrollers are supported.

There should also be some freebies from Microchip. I understand the older versions of the IDE are better for assembly coders.

It ain't OVER 'till it's 2 PICK
Find all posts by this user
Quote this message in a reply
10-30-2024, 01:08 PM
Post: #15
RE: Check this guy out!
(10-29-2024 11:58 PM)dm319 Wrote:  But you'd need to ask HP...!

And/or Moravia. Neither is likely to answer IMHO.

A1

HP-15C (2234A02xxx), HP-16C (2403A02xxx), HP-15C CE (9CJ323-03xxx), HP-20S (2844A16xxx), HP-12C+ (9CJ251)

Find all posts by this user
Quote this message in a reply
10-30-2024, 02:03 PM
Post: #16
RE: Check this guy out!
(10-28-2024 09:07 PM)Commie Wrote:  I have been looking to design a rpn calculator

Alex Garza and Miroslav Nemecek have, in my opinion, made gems in terms of programmable calculators but other geniuses have also made interesting feats such as Benoit Maag who used an old TI-1250 to transform it into an RPN-1250 (HP-29C clone).
I also admire the 10LC, 32LC and 42LC which are HP clones in M5 Cardputer (based on EPS32 microcontroller)
(If you are interested you will find information on these creations on my site clones.phweb.me)

http://ti58c.phweb.me
http://clones.phweb.me
http://www.instagram.com/ti58c
"No! Do or Do not. There is no try!" [Master Yoda]
Visit this user's website Find all posts by this user
Quote this message in a reply
10-30-2024, 02:30 PM
Post: #17
RE: Check this guy out!
(10-30-2024 02:03 PM)Pierre Wrote:  Alex Garza and Miroslav Nemecek have, in my opinion, made gems in terms of programmable calculators

Hi Pierre,

Yes, I totally agree with you and appreciate the hard and clever work that they put into their designs. In the near future, I will build the ET58.

They are both very clever guys which have broken through the crystal spheres which have impeded me and others for years.

Cheers for now and I hope you enjoy your new ET58 calculator.
Darren
Find all posts by this user
Quote this message in a reply
11-02-2024, 08:07 AM
Post: #18
RE: Check this guy out!
Have a look at https://github.com/jjj11x/stc_rpncalc which fits a (decimal) floating point library on an 8-bit 8051 microcontroller with 13k of ROM. The transcendental functions are relatively accurate, other than the trigonometric functions based on the Sinclair Scientific algorithms.

If your goal is to write your own decimal floating point library, an 8-bit microcontroller with a little more flash would be sufficient, although honestly if I were starting a design from scratch, I'd just go with a 32-bit ARM microcontroller. The free GCC or clang compilers are very good. There are also open-source decimal floating point libraries available, for instance see https://sourceforge.net/projects/wp34s/ which uses the IBM decNumber library https://sourceforge.net/p/wp34s/code/HEA...decNumber/

The 15C ROM is incredibly space efficient, but was also coded in assembly targeting a 4-bit microcontroller which was specifically designed for a calculator.
Find all posts by this user
Quote this message in a reply
11-05-2024, 08:13 PM
Post: #19
RE: Check this guy out!
Hi Guys,

I've been thinking, ya'know and my crystal ball gazing seems to suggest that there might be quite few more hp, maybe ti aswell, homebrew calculators being developed and appearing in the near future. The reason for this is shear demand for legacy hp calcs?

I bet some are in development right now, so we shall see what the future brings. I'm very surprised at the seamingly high demand.

The other day, I was looking at hp's 9810 desk calculator, it still looks good "today" thats about 54 years on.

Cheers
Darren
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: