New: RPN3.NET (XML-defined universal RPN simulator for .NET software or hardware)

[Nick]

Project Link: https://sourceforge.net/projects/rpn3 (non-commercial; open-source)
* The Description, Features, and Wiki give an overview of the functionality of the design.

I'm proposing to architect a generic core which would allow you (or a designer) the ability to either create or simulate a calculator design and behavior by entering your specifications into an XML (text) file with no-programming required. You could define the keys (including number of keys, layout, number of shift keys), display (single / multi-line, touch...), and I/O (wire up keys to make a physical keyboard, LEDs for indicators...), custom menus and catalogs (41 or 42 style).

Other than the necessary library or module support, the idea is that you could define any of the classic calculators and their behavior in a single XML file (one text file per model) and implement that on either a software or hardware device using inexpensive off-the-shelf components.

The extensible architecture would introduce concepts such as name spacing to allow you to override module conflicts in the definitions as well (and tweak function behavior, such as bug vs bug-free versions, one classic model style vs another, localization -- date format, etc.).

The modules would be plug-ins (DLLs) written in .NET (in your choice of language) that could introduce new functionality and extend existing functions. Data-types could also be added with modules.

Each function would also specify test cases for automated testing (this could save everyone a lot of time). Overall automated testing would also be supported.

You could theoretically rebuild a 9100 or 97C inexpensively and with minimal technical knowledge or test a new design concept such as the WP-43S.

Because of the XML support, even conflicting designs can be implemented. (ex. supporting both a 15C and 41 style complex stack while sharing functionality)

I'd like your feedback on the concept (take a look at the SF & Wiki). Is there a feature you'd like to see? Support for something you might like to implement one day? Any comments / suggestions?

Thanks,
Nick

Edit: Subject

[Claudio L.]

(08-21-2016 09:05 PM)Nick Wrote:  I'd like your feedback on the concept (take a look at the SF & Wiki). Is there a feature you'd like to see? Support for something you might like to implement one day? Any comments / suggestions?

Thanks,
Nick

I think it's a cool concept. It's not clear to me what's going to be defined in the XML file, though.
Is it just the screen display and keyboard layout and behavior? or the actual behavior of every keystroke/command?
If you can define the basic commands without programming, then how would you define let's say "RCL 00" in the XML file? Is there going to be some sort if intermediate language?

[Nick]

(08-22-2016 12:32 AM)Claudio L. Wrote:  I think it's a cool concept. It's not clear to me what's going to be defined in the XML file, though.
Is it just the screen display and keyboard layout and behavior? or the actual behavior of every keystroke/command?
If you can define the basic commands without programming, then how would you define let's say "RCL 00" in the XML file? Is there going to be some sort if intermediate language?

Claudio,

Thank you for your question -- it helps me to think this through and extend the idea. To answer your question: Some of all, yes.

The idea behind the configuration (XML file(s)):

The RPN calculators have a lot of things in common and can share a great deal of simulator code across models. If we build for that, what’s left is the differences that can be defined in the XML files giving multiple types of support from a single core.

By maintaining layers of separation, we could re-use the same function library across multiple configurations in both software or hardware. And these function aren’t limited to math, also consider File I/O, TCP/IP, serial I/O… as the modules will have access to the core object space via a defined plugin interface, other modules functions’, the .NET framework library, and any supported hardware.

For stack, we have 3-level, 4-level, 8-level, n-level with different behavior for X/entry and with or without the constant behavior (commonly T). If you were to describe those settings in an XML file, then a single piece of software could simulate all of those types. Or a function to re-define the stack size could be presented to the user (such as on the WP34S) for any depth (or unlimited) given the size is now arbitrary.

For display, there’s 1 line, 4 line, n-line and that could output to a resizable display if it were of the high-res type, but alternately we could direct the same output to a console or a connected LCD text display. Maybe the annunciators are on the LCD display or maybe they’re an LED wired to a GPIO pin… a configuration file could define that mapping.

RCL is a good example. So let’s say RCL is part of the core library (basic functions, no module required). It has an input… If you made a “RCL” button, then it might prompt for the parameter. If you made a “RCL 00” button, in the config file you might give it a fixed 00 parameter. But in either case, they could both share the same RCL-XX function in the library.

This definition doesn’t have to be a key at all… it could also be 42-style menu or a 41-style catalog with either listing defined in XML as well (or both within the same user-defined layout / XML file). This is how the number of shift keys becomes arbitrary (and why text labeling should be independent of layout as well)... if you want 1 or 3 shift keys… or even chorded (think of the WP34 complex key) it wouldn’t matter as the layout is independent of the other subsystems of the calculator.

The way a function such as CHS could have 3 different behaviors is by writing the functions plugin-style. Consider if an XML stated “15C as the default behavior for all functions” or alternatively “41 as the default behavior with 15C behavior just or the CHS key”. In either case, the function examines the core environment for things such as stack size and configuration factors, then decides how to respond accordingly. And again, because of the separation, a "CHS behavior setting" could be exposed to the user as a function so that they could change this behavior from a menu.

And to extend this idea further, let’s say a module developer created a function and they want to offer 3 different behaviors. There’d be a default (likely) so that you wouldn’t have to do any setup at all to use their function. But if you wanted say alternate or maybe beta behavior, you could add the line they specified to your XML configuration file.

Perhaps the layers of settings / overrides is as follows:
1. The function defaults (whatever the module/function author picked)
2. XML-settings (whatever the 'designer' chose in their implementation to override those defaults given the core or function settings)
3. runtime-settings (the module author could also include functions to adjust the behavior -- giving the user the option to adjust the behavior at runtime (calc on); simply add them to a menu/catalog -- or key)

Intermediate language:

No. The only IL exists in the core and modules -- the “ROM-type” (DLL) code written in .NET (which allows you to compile various languages into the same executable, high performance, not runtime interpreted -- for those not familiar; one user could contribute a VB.NET module and another a C# module and they would both co-exist just fine; the IDE to do this is a free download for non-commercial use)

It was my thought that userspace (keystroke programs) on-device could be treated the same as the core or module function giving a non-programming user the same flexibility in defining custom key/menu layouts of their own on-board code the same as would be a module they added.

Software vs Hardware:

This same core / configuration system applies to both: (example) Making your own custom HP-15C on your smartphone and (example) Making your own custom 97 in hardware with a Raspberry Pi 3 (PC on a board - $35USD) or similar device that can run the .NET framework.

Tradeoffs:

The “ROM” code will be larger, and the memory requirements higher so this isn’t intended to be as efficient as a classic machine. The idea is to make a common codebase more universal and for things like 15C complex behavior or CHS behavior… rather than “vote” on which way to go -- let’s do them both and expose that as a user setting. With the level of abstraction I have in mind, I see this as feasible.

Thanks,
Nick

[Nick]

(08-22-2016 01:42 AM)Nick Wrote:  Perhaps the layers of settings / overrides is as follows:
1. The function defaults (whatever the module/function author picked)
2. XML-settings (whatever the 'designer' chose in their implementation to override those defaults given the core or function settings)
3. runtime-settings (the module author could also include functions to adjust the behavior -- giving the user the option to adjust the behavior at runtime (calc on); simply add them to a menu/catalog -- or key)

...and through that, you get user key assignment (similar but more advanced than the 41, though the 41 behavior is possible). The XML is the startup configuration, which exposes a default number of functions (keys, menus) and behaviors to the user, and the rest depends on what you exposed. If you're doing an XML file for a 15C simulation as close as possible, the user would never know the stack size was re-definable because no option would be on the layout -- they'd always be in 4 or 4+complex mode. But, if you were to give them a different layout and exposed the "Stack Size" functions (say by adding a settings menu in place of ON or pairing a different FLAG), then they could change (and save) this such as on the WP34. (as the rows, columns, etc are arbitrary you could change the number of buttons; it isn't necessary to replace one with another unless you did so to keep the same keyboard size)

Yip,
Nick