HP Forums
OpenRPN CPU opinions - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: OpenRPN CPU opinions (/thread-55598.html)

OpenRPN CPU opinions - Nelson M. Sicuro (Brazil) - 04-20-2004

Hi to all,

I'm thinking in create a virtual CPU for this project, that can be implemented on any hardware platform and that can run the same OS without modifications on these platforms. This can be easily done as we are used to deal with emulators, the difficult part will be the CPU definition (capabilities, speed, bus width, size of its numeric representation - BCD, IEEE floating point, constructive reals??), memory size, expansion capabilities, I/O capabilities, storage, display.

My idea is a CPU capable of deal with something like the "constructive reals" mentioned elsewhere in the forum, or at least a large BCD precision (>15 digits mantissa, 4 digits exponent) and a very orthogonal instruction set and generic registers (RISC like) with some especialized instructions to deal with keyboard and display and some type of "plug-and-play" for memory,I/O.

Any other ideas or suggestions?

Best regards,


Re: OpenRPN CPU opinions - hugh - 04-20-2004

Everything's sounding good here. One question though, can we get away with emulation without major efficiency losses? Or is it possible to just port the OS directly to other processors? Just curious, I don't know quite as much about this particular area of design, so I'll be listening closely and see if I can't learn a few things myself.

Carry on, it's exciting to see this part of development beginning!

Re: OpenRPN CPU opinions - V-PN - 04-20-2004

Efficion at underclocked speed?


Re: OpenRPN CPU opinions - Nelson M. Sicuro (Brazil) - 04-20-2004

My idea is to create a RISC CPU dedicated to math, easy to implement and emulate. The idea is first emulate it on PC and after the concept has proven good on a protoboard with some microcontroller (I'll start with PICs as I have some here ready to go). With a 20MHz clock PIC I guess I can achieve more than 100.000 emulated instructions per second on it, and with other platform (MSP, AVR) even more. This CPU will need to be projected also keeping in mind the FPGA idea, if someone wants to create a hardware CPU (VERY fast!).

I was thinking at first to use 80 bit or even 128 bit internal registers to store temporary data, but I think that I'll choose some more dedicated to pointers on external RAM to implement any-size numeric operators (RAM is cheap!) and creating instructions to deal with this any-sized operators.

The idea to port the OS directly to the hardware platform is OK too, I just found more fun to create a new CPU! Of course this can be a very good challenge to port the math routines from, say, HP-42S or HP-15C, to the new CPU - but its ROMS are "small" and "easy" to do the reverse engineering. Of course we can also emulate directly the Saturn CPU, but the precision will be stuck on 12/15 digits.

Any ideas from the emulator's Gurus out there?

Best regards,


Re: OpenRPN CPU opinions - Anon - 04-20-2004

I am getting worried that this project will never get off the ground. While I'd love to see this device produced, it seems that the amount of complexity is becoming huge.

For instance, why exactly is a new virtual CPU needed? That is a huge amount of (possibly uneeded) work. why not just use a pre-existing bytecode language, and use a CPU with a bytecode interpreter already made?

As for the physical processor, how about an underclocked TI MSP series CPU? 16 bits at pretty low power.

Re: OpenRPN CPU opinions - Nelson M. Sicuro (Brazil) - 04-20-2004

I opted for the CPU emulation to be more flexible. I have some TI MSP430 here and I'm planning to use them in the next prototype. But I think that mantain an OS in multiple platforms is more complex that maintain an emulator and using the very same OS on all of them. But it is only my idea, it is not the final decision yet.

The MSP430 is very good for this purpose but it can't use external memory directly and it has a small internal SRAM - but it is good for batteries, less than 1uA in standby. The units I have are MSP430F449, 60KB FLASH 2KB SRAM, good enough for an emulator but small for a good calculator. To access external memory with an emulator is easy and transparent to the OS code.

For the MSP430 I need to buy a prototype/development board - I have the bare chips - to start the programming. for the PIC I have it already and can create/debug the I/O code right now (display/keyboard/serial/SD card). I have some "dead" calculators(HP-11C, HP-17B, 41CV) to use their keyboards and bodies.

As I run this project on my spare time this can take some time to get this done (and if I need to spend some $$$ this can take longer...).

Best regards,


Re: OpenRPN CPU opinions - hugh steers - 04-20-2004

hello nelson,

i am currently writing a calculator program for the palm pilot that uses range arithmetic explained here: http://www.voidware.com/range.htm this is a predecessor to constructive reals and i am deliberately trying to keep a lid on complexity.

with regard to the ideas here, i would say that from a software perspective, a general indication of cpu capability is required. my project goes out from the direction, "what can be achieved on a pda" and i have upgraded my notions from 20Mhz to 200Mhz this time round. at 20, i chose fixed length 30 digits but they were too slow for programming. at 200, im not planning more digits, but error tracking and programmability.

there are two paradigms. come in from hardware and fixate the number system and representation, write your custom code. or come in from software, punt on the actual cpu and
port your code as required to the general purpose chip that looks good/cheap/low-power that day.

an emulator looks like a good way to define a chip, at least logically. you also need to know that your design isnt dominated by something general and already out there at low cost etc. that makes the former approach feasible.

Re: OpenRPN CPU opinions - hugh - 04-20-2004

A large amount of work, yes. But in my opinion necessary. It would be easier to just pick a processor and develop around it specifically... but inevitably it will become obsolete. With a virtual CPU we can ensure the project's perpetuation, which is one of my major goals. If it isn't sustainable, then we're just wasting our time. It also allows us to define a standard more readily, which is a big plus!

This direction has my vote.

By the way, OpenRPN may look daunting, but it can be done... and I will see that it comes to life. Allow me to paraphrse: We chose to develop OpenRPN not because it is easy, but because it is hard. It will get off the ground.

Keep up the good work everyone, I can't wait to see this phase going into motion!

Re: OpenRPN CPU opinions - Anon - 04-20-2004

" It would be easier to just pick a processor and develop around it specifically... but inevitably it will become obsolete. "

The HP33s is based on the 6502, which has been around since 1976. The most popular type of microcontroller core today, the 8051, is from 1980. The PIC was first designed in 1976.

My PC is based on the intel *86 design, which was introduced in the late 70's and is still going strong. Code written for an XT will probably still run today.

While I admire your project, I don't think you really have to worry about a CPU core becoming obsolete - as long as you are careful. Chips themselves may become obsolete but the core will be around for ages. And if the particular CPU you use becomes obsolete, you'd need to rewrite the emulator anyway.

I think that as long as the core is not single-sourced, you have nothing to worry about.

I wish you all the best

Re: OpenRPN CPU opinions - Garth Wilson - 04-21-2004

Anon wrote, "The HP33s is based on the 6502, which has been around since 1976. The most popular type of microcontroller core today, the 8051, is from 1980. The PIC was first designed in 1976.

"My PC is based on the intel *86 design, which was introduced in the late 70's and is still going strong.

<end quote> The 6502 family (which has had many improvements since 1976) is still going strong, and the IP holder, WDC (Western Design Center), has no plans to ever discontinue it. Their 65c02's will all do a guaranteed minimum of 14MHz, and most will do 20MHz (which is worth about 40MHz of a PIC16 if the PIC can do the job at all. I have plenty of experience with both). I understand that one of WDC's licensees has a 65c02 core running at 200MHz in a custom IC, meaning about 50 MIPS, with maximum total interrupt latency of 70ns (finishing an instruction and carrying out the interrupt sequence), and minimum of just over 5ns with a special trick. The 65c02 does have SToP and WAIt instructions, and have guaranteed spec.s from 5V down to 1.2V, so it's good for battery-powered operation. The 16-bit version is the 65816. What has always attracted me to the 65 family is the surprisingly high power-to-complexity ratio. WDC has standard microcontrollers based on these processors, but they don't have a lot of versions like you can find with some of the other families. Most people don't realize they own 6502's, because they're embedded in so many products, from camcorders and VCRs to even life-support equipment. In fact, more 6502 cores are going into products today than at any previous time in history-- 200,000,000 per year, according to WDC.

Re: OpenRPN CPU opinions - Renato (Brasil) - 04-21-2004

Have you considered implementing a HP CPU, instead of a RISC CPU ? Motivations, in my opinion, are:
1. It would be FUN. I heard that Stephen Wozniak of Apple was a chip designer at HP, early in his career. I have studied some parts of Apple II design, and it amazed me. Woz has done miracles with the Video, RAM refresh and Floppy circuits. I think Apple II inherited some ideas from HP calcs CPUs (extensive use of state machines, very clever timing techniques).

2. Implementing the HP cpus instruction set would help documenting and preserving the design. Emulators help, but a hardware implementation of the CPU would provide ultimate documentation of the design

3. It would be a better platform for the original HP algorithms. If instructions are the same as HP cpus, word size could be changed without major modifications to algorithms

4. The emulator guys could help you debug the CPU. They understand the instruction set, the registers architeture and the execution flow. I think they would be very happy to interact with you during CPU debugging.

5. You could use original HP ROMS for testing the CPU design, and for using it in a real calculator.

Good luck ad have fun.

Re: OpenRPN CPU opinions - Jonathan Purvis (New Zealand) - 04-21-2004

Dare i suggest basing the OpenRPN calculator on RPL? Rather than emulating an entire CPU, with it's limitations on memory space and word size, why not just implement the few primatives necessary and run the rest of the operating system and programs through the magic of Forth-style code?

Since the stack is entirely pointers to objects, there are no worries about memory limits, just choose the appropriate address word size. The same code can run on CPUs from the 6502 to the PowerPC 970 and beyond!

Decompiling a program to transfer to different hardware is just a matter of looking up the addresses in a table (if you avoid the HP-48's problem of undocumented entry points, easy in an open operating system). Then just recompile for the target machine.

RPL is one of the easiest languages to target a compiler to, so there will be no shortage of higher level languages to write programs in for those who don't like to write their code "backwards".

If you take up this idea, i personally volunteer to write a "keystroke programmable calculator" front end for those that prefer the traditional RPN way of doing things.

Re: OpenRPN CPU opinions - Paul Brogger - 04-21-2004

This topic should definitely be moved to a thread on the OpenRPN board. (Maybe these MoHPC Forum entries could be copied there for starters?)

For my part, I can't understand why, if the goal is a programmable RPN calculator, one would start at the CPU level. There are PLENTY of options available which include documentation, assemblers, compilers and development/debug tools.

One example: using an ARM core (if possible & economical) would confer tremendous spinoff benefits as it would be the same CPU as is employed in the 49G+ line.

It may be fun to do, and it may mesh nicely with someone's skill set, but I don't see how the benefits can possibly outweigh the added cost, delay, and dearth of software support that seem to me inevitable.

But, I'm a rookie in all this . . .