HP71B (r even 75) with RPN calc?

General discussion about calculators, SwissMicros or otherwise
Post Reply
wmwiese
Posts: 2
Joined: Tue Mar 17, 2020 8:04 am

HP71B (r even 75) with RPN calc?

Post by wmwiese »

Folks...

As much as I love 41C style calcs, the wonderful BASICs on HP7Xs are great and handy.

Prob with the 71B is that it really doesn't have a native RPN calc on it. Some modding
to allow this for general XYTZ+L calculation, yet with BASIC programming functionality
would be wonderful.

Rejiggering the KB into a DM4X vertical case would be great. Having the full math etc
libs built in would be super. Card reading etc not necessary - plenty of more modern
ways to get input.

Having the calculator UART be controllable by/thru HP Basic even better. Prob a buncha
other tweaky improvements too.

Ideas/commentary/realization? The full 71 source code is avaiiable and there's plenty
of true emulation code out there, so it can be patched.

BIll W
San Jose CA
J-F Garnier
Posts: 47
Joined: Sun Mar 11, 2018 5:37 pm
Location: France

Re: HP71B (r even 75) with RPN calc?

Post by J-F Garnier »

As a great 71B fan, I would be very happy to have a DM71B, or better a DM72S (see here).
But no chance I guess.

However I don't understand your point: do you want a BASIC handheld with a RPN calculator?
If you have a RPN calc you will have a RPN language à la 41C/42S.
This seems incompatible to me.

J-F
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: HP71B (r even 75) with RPN calc?

Post by rprosperi »

There are several RPN calculator programs for the 71B, I have used one every day since the 80's.

If you have a PIL-Box to easily connect your 71B to a PC to load programs from a LIF disk image, I can send you a copy, but the required overlay is harder to reproduce, even though scanned images are available.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
User avatar
RJvM
Posts: 276
Joined: Wed Jun 02, 2021 9:21 am
Location: Gelderland, Netherlands

Re: HP71B (r even 75) with RPN calc?

Post by RJvM »

For what it's worth, I am in possession of an HP-71B with the HP-41 plastic overlay, still in great shape (apart from some wear at the outer edges).
I wlll gladly share a high quality scan, if requested.
Robbert Jan, MSEE, RPN user since 1976 and a collector for many years I now own all the important ones: HP-35, 45, 55, 65, 97, 19, 21, 25, 34, 10-16, 41, 42, 71, 48, 50, Prime, DM41, DM42, WP43, C47, R47; Project 47 team member https://47calc.com
jwiede
Posts: 44
Joined: Mon Oct 18, 2021 11:17 pm
Location: San Jose, CA USA

Re: HP71B (r even 75) with RPN calc?

Post by jwiede »

I'd gladly shell out for a DM71b or equivalent. RAM/FLASH will be limited by whatever QIP Flash & PSRAM limits apply along with SOC native -- I'd hope for at least 16MB PSRAM & 128MB Flash, but whatever it manages will be miles beyond native HP71b regardless.

I would like to see a few improvements / modifications -- all IMO, ofc...

In terms of what I'd like to see stay the same (or depart as no-longer-needed)...
  1. Must have QWERTY+keypad layout of HP71b (or better), that was sig. part of why 71b was so efficient.
  2. Native flash disk support can replace need for onboard card reader, storage cart slots, etc.
  3. USB-C with OTG support done properly can replace HPIL, provide USB host & host stack capabilities.

In terms of what I'd like to see added above/beyond the expected 71b loadout...
  1. Add a firmware full-featured monitor/debugger, as well as integrate FORTH/ASM cart support native. For advanced users, so okay to hide access to this off the "advanced/system menu", but also provide switch for crash to drop into monitor/debugger instead of normal "crashdump" support.
  2. BASIC file handling retooled to access flash fs, ideally incl. external USB drives/volumes. "Port support" retooled towards USB OTG high-speed serial & HID support. Added bonus pts for having nice FTDI and gpio access to allow using device as host+"serial whatsit"-in-one (a la PC+BusPirate).
  3. Add most popular existing cart extensions to BASIC into native support, incl. MATH cart, etc.
  4. Depending on how screen is handled, provide both char- and pixel-type graphics control from BASIC and via ASM/FORTH.
None of the above should be unduly difficult, only feel strongly about need for I in first list, plus I & II in the second list.
DM42, DM16L, and a menagerie of HPs thanks to CAS (Calc Acq Syndrome)!
jwiede
Posts: 44
Joined: Mon Oct 18, 2021 11:17 pm
Location: San Jose, CA USA

Re: HP71B (r even 75) with RPN calc?

Post by jwiede »

Just to explain my thinking w.r.t. my "big asks" (the firmware monitor/debugger, and incl. ASM/FORTH cart as native):

I strongly believe that one of the strengths of high-end HP calcs in general is their "multi-tiered programming support". They provide quick/easy means of entering equations or quick keystroke programming for simple needs, moving into slightly more complexity and capability with synthetic instructions through RPN/RPL using C/asm-coded libraries, to all-out C/ASM-from-ground-up for those who need extreme programmability and/or performance.

By adding better debugging and support for both "hybrid BASIC" (think usr() jumping to asm) and FORTH/ASM-coded extensions to BASIC, not only does this provide that "middle tier" when developers can extend and supplant their BASIC code with higher-performance FORTH/ASM where it matters, retaining decent debug abilities, but also supports using the device exclusively as a FORTH/ASM programming tool for ultimate performance and flexibility. By providing both (extensible) BASIC as well as FORTH/ASM and a decent mixed-mode monitor/debugger, it provides the proposed "71b-alike" handheld computer with that same multi-tiered programming ability similar to what made the HP calculators so powerful.

Just my $0.02, and I'm not religiously wed to FORTH/ASM, just find that much easier to provide native in a embedded environment SOC (and vastly less resource-hungry), than trying to provide and support a full-on C/C++ toolchain, dynamic linker/loader support, and other required toolchain elements alongside a BASIC programming environment.

A related advantage of FORTH is it would allow reasonably direct integration as a means of implementing BASIC command and function extensions. FORTH's threaded-interpretive nature enables a nice synergy with how the BASIC interpreter handles tokens and args, so it would require little added complexity to enable FORTH words to present as BASIC extension commands/functions.

OTOH, trying to do something similar involving a compiled language such as C would require substantial toolchain and dynamic linking/loading complexity to provide the same ability -- so much so, that it is unclear whether fully-onboard implementation of same is a reasonable ask (IME).

And yes, I've given a bit of thought to the topic. ;D
Last edited by jwiede on Wed Oct 26, 2022 10:49 pm, edited 1 time in total.
DM42, DM16L, and a menagerie of HPs thanks to CAS (Calc Acq Syndrome)!
ben.titmus
Posts: 49
Joined: Wed Feb 24, 2021 7:50 pm
Location: Cambridge, UK

Re: HP71B (r even 75) with RPN calc?

Post by ben.titmus »

jwiede wrote:
Wed Oct 26, 2022 9:40 pm
I'd gladly shell out for a DM71b or equivalent...
None of the above should be unduly difficult...
I think such a device would be great and I would buy one. However, I'm not convinced it wouldn't be difficult. Certainly there would be a large amount of work for SwissMicros even if the firmware existed as it wouldn't be able to use their existing PCB or cases.

If we really wanted such a device I think the only reasonable way of getting it made is to have working software that already covers most of these features and would compile against DMCP (with a simulator as well).
wmwiese wrote:
Sat Sep 17, 2022 12:14 am
The full 71 source code is avaiiable and there's plenty of true emulation code out there, so it can be patched.
Is it available? I couldn't find it (maybe I don't know where to look). I'm not sure emulators are really that helpful when trying to build a new platform - it's a bad idea to try and emulate an old processor to run old code as it makes it hard to make changes (and it runs very inefficiently). As far as I can tell there aren't any existing Open Source projects that cover the features of the HP71B/75. If some properly licensed source code was available it should be possible to build a prototype using the DM42 as a starting point, although obviously without the full keyboard.
jwiede wrote:
Wed Oct 26, 2022 10:31 pm
Just my $0.02, and I'm not religiously wed to FORTH/ASM, just find that much easier to provide native in a embedded environment SOC (and vastly less resource-hungry), than trying to provide and support a full-on C/C++ toolchain, dynamic linker/loader support, and other required toolchain elements alongside a BASIC programming environment.
I'm a fan of FORTH, but isn't RPL close enough? And the keyboard is built around the language (and vice-versa). Maybe the closest to a full working version (and something that would be closer to what SwissMicros already make) would be a newRPL based calculator. That's still quite a bit of work, but would appear to have quite a number of people already asking for it. A DM71B would be a riskier project.
jwiede
Posts: 44
Joined: Mon Oct 18, 2021 11:17 pm
Location: San Jose, CA USA

Re: HP71B (r even 75) with RPN calc?

Post by jwiede »

ben.titmus wrote:
Wed Oct 26, 2022 10:49 pm
jwiede wrote:
Wed Oct 26, 2022 10:31 pm
Just my $0.02, and I'm not religiously wed to FORTH/ASM, just find that much easier to provide native in a embedded environment SOC (and vastly less resource-hungry), than trying to provide and support a full-on C/C++ toolchain, dynamic linker/loader support, and other required toolchain elements alongside a BASIC programming environment.
I'm a fan of FORTH, but isn't RPL close enough? And the keyboard is built around the language (and vice-versa). Maybe the closest to a full working version (and something that would be closer to what SwissMicros already make) would be a newRPL based calculator. That's still quite a bit of work, but would appear to have quite a number of people already asking for it. A DM71B would be a riskier project.
The problem is more one of FORTH integrating better (and more flexibly) with BASIC, as well as serving in a firmware role, IMO. RPL never had quite the same level of "deep native support" for extending its vocabulary as FORTH, at least IMO, esp. in terms of supporting both "FORTH-implemented" and "ASM-implemented" words transparently interchangeable, not to mention providing standard elements for modifying/replacing firmware-/runtime-hosted mechanisms and routines.

Once you start getting into how users would be able to modify or replace firmware-/runtime-environment elements, RPL encounters a great deal more challenges than FORTH, simply because FORTH commonly includes its own firmware-/runtime-environment implemented in FORTH -- it is self-bootstrapped. In contrast, existing RPL instances (by all appearances) were not really implemented that way, or to enable same.

Could RPL be extended in a similar manner to support all those same abilities? Perhaps, but it hasn't been fully to the metal (AFAICT), and so it is speculative to think it can. That has been a common property of most FORTH environments since inception, so for FORTH, it's a mature, well-proven facility of the environment.
DM42, DM16L, and a menagerie of HPs thanks to CAS (Calc Acq Syndrome)!
ben.titmus
Posts: 49
Joined: Wed Feb 24, 2021 7:50 pm
Location: Cambridge, UK

Re: HP71B (r even 75) with RPN calc?

Post by ben.titmus »

jwiede wrote:
Wed Oct 26, 2022 11:07 pm
The problem is more one of FORTH integrating better (and more flexibly) with BASIC, as well as serving in a firmware role, IMO. RPL never had quite the same level of "deep native support" for extending its vocabulary as FORTH, at least IMO, esp. in terms of supporting both "FORTH-implemented" and "ASM-implemented" words transparently interchangeable, not to mention providing standard elements for modifying/replacing firmware-/runtime-hosted mechanisms and routines.
I can see that integration with other languages was probably lacking in RPL. I'm not sure about how much of a change to the language it would be to replace existing routines. (FORTH has the advantage of being able to redefine a term in terms of previously defined terms using its dictionary, which may be lacking in RPL which I don't know well enough.) So I'm willing to concede these points. Although I'm not sure it's a particularly common requirement for a small handheld device.
jwiede wrote:
Wed Oct 26, 2022 11:07 pm
Once you start getting into how users would be able to modify or replace firmware-/runtime-environment elements, RPL encounters a great deal more challenges than FORTH, simply because FORTH commonly includes its own firmware-/runtime-environment implemented in FORTH -- it is self-bootstrapped. In contrast, existing RPL instances (by all appearances) were not really implemented that way, or to enable same.
As far as I understand, the RPL calculators were mostly programmed in RPL (presumably including the runtime environment). FORTH itself requires at least a little bootstrapping in another language (although admittedly very little) and I would agree that RPL is a more complex language so requires more. FORTH allows you to replace parts because of how its dictionary works, not because it includes its own firmware environment implemented in FORTH. (It is possible to write more of the built-ins of FORTH in another language and still allow them to be redefined in FORTH.) So I'm not really sure your reasons are why FORTH has the flexibility it does.
jwiede wrote:
Wed Oct 26, 2022 11:07 pm
Could RPL be extended in a similar manner to support all those same abilities? Perhaps, but it hasn't been fully to the metal (AFAICT), and so it is speculative to think it can. That has been a common property of most FORTH environments since inception, so for FORTH, it's a mature, well-proven facility of the environment.
I'm not really sure this makes sense. It makes very little difference to the user how much is written in RPL/FORTH versus another language, and it appears that RPL calculators had most of the code in RPL. As far as I can see it's the FORTH dictionary that is advantageous here, possibly with better integration with other languages. I'm not sure how much I really care about any of that in a handheld.

The most useful extensibility of FORTH (ease of defining new terms rather than redefining built-ins) is also available in RPL in a similar way, but with better built-in support for types that matter with calculators.

None of this is to say that I wouldn't appreciate a FORTH handheld, because I would. I don't really care about having a BASIC implementation on a handheld as I wouldn't find that very useful. And I really don't want to program assembly on a handheld. (I've programmed enough assembly already in my life.) However, an RPL calculator would give me most of that, and RPL would be much less of a risk for SwissMicros and is much closer to actually being implemented.
Post Reply