48G Re-creation Project (fantasy)

[Druzyek]

I know the HP-48G ROM can be copied but could you ever sell this device if it contained anything from the original ROM?

[Claudio L.]

(10-27-2019 03:15 AM)sunhp Wrote:  

(10-27-2019 02:09 AM)Claudio L. Wrote:  My point exactly... OLED HD to emulate 128 pixels wide black and white screen? It is confusing.

131.. ok 136 pixels wide ;-)

You got me! I didn't pay attention who I was replying to, I should've been more precise knowing it was you

[Claudio L.]

(10-28-2019 07:22 PM)Druzyek Wrote:  I know the HP-48G ROM can be copied but could you ever sell this device if it contained anything from the original ROM?

Selling the hardware would be fine, but the user would have to manually download the ROM from hpcalc.org and load it (which if there's a nice interface to do it, shouldn't be a problem for a person that thinks in RPL).

We went through something like that many years ago with hpgcc3. We provided a "patching" program that would modify the 50g ROM provided by the user to install hpgcc3, this was required to properly execute "ARMCode" objects. We could not distribute an already modified ROM (and we aren't even talking of selling anything, that was simply redistribution), and this became an obstacle for adoption.

This new 48 recreation project would have to do something similar to "expand" the 48 with special opcodes or ROM patches. From the emulation layer you can provide virtual Saturn opcodes, but if the ROM doesn't use them there's no advantage, so the original ROM would definitely need modifications.
If you wanted more RAM, I wouldn't even know where to begin to expand the Saturn memory addressing system, that would be a very difficult thing to do.

[lemontea]

In recent days, I've come to the conclusion that we probably don't need to talk about all the underlying technology yet, UNTIL we have figured out recreating a SATISFYING keypad hardware solution :-)

I mean, for many of us, that's really the key (no pun intended, or maybe intended) factor right?

If we didn't care about the physical form factor, tactile user experience, then many of the smartphone emulators would already suffice.

The DM42 is a superb device, but some of us, myself included, STILL are not happy with the tactile key feel.

The old HP hardware was great, and if we can replicate or even improve upon the keypress, that would be awesome.

If cost is not an issue (I think this calculator is not really meant to be a low budget project), perhaps we can use tactile pushbuttons for every key? I think of those because probably the bubble type contact switch board is not something one of us can produce at home. But we can buy several dozen momentary switches, and 3D print the plastic framework.

However, the momentary pushbuttons that I have as parts don't seem to have the CLICK-CLICK tactile feel of the bubble switches.

I have some computer keyboard mechanical switches but those are way too large for this implementation.

Any suggestions?

[EugeneNine]

Someone thats worked with 3d printers see if you can print a keypad similar to the 48 series.

[Eric Rechlin]

(10-28-2019 08:32 PM)Claudio L. Wrote:  but the user would have to manually download the ROM from hpcalc.org and load it

One of the popular iPhone emulators for the 48 does exactly that. They charge users for the emulator and then use my bandwidth to download the ROM. Seems kind of crummy that they are trying to profit off of HP's work and my bandwidth, but it is what it is. If the emulator were free I'd have no problem with it.

[EdS2]

(10-26-2019 07:45 PM)Claudio L. Wrote:  As far as hardware, a Raspberry Pi is a bad choice for baremetal coding. Its Broadcom CPU has a weird way to boot, and needs proprietary drivers, which means you are stuck with Linux, can't go baremetal. It's a great board for people that code on top of Linux, though.

Hmm, the Raspberry Pi may be a poor choice for other reasons, but it's certainly not limited to Linux - there's at least one other OS and there are several bare-metal projects.

[Claudio L.]

(10-30-2019 09:24 AM)EdS2 Wrote:  

(10-26-2019 07:45 PM)Claudio L. Wrote:  As far as hardware, a Raspberry Pi is a bad choice for baremetal coding. Its Broadcom CPU has a weird way to boot, and needs proprietary drivers, which means you are stuck with Linux, can't go baremetal. It's a great board for people that code on top of Linux, though.

Hmm, the Raspberry Pi may be a poor choice for other reasons, but it's certainly not limited to Linux - there's at least one other OS and there are several bare-metal projects.

I just learnt of Ultibo, and I stand corrected. Looks like you aren't stuck with Linux anymore, as much of the hardware is being supported. However, you are limited to GPL license.
Also, I'm not sure the term "baremetal" even applies when you have a full RTOS running on the GPU and providing services, but let's say for simplicity that an application built with Ultibo would count as baremetal.

[lemontea]

(10-30-2019 08:49 PM)Claudio L. Wrote:  

(10-30-2019 09:24 AM)EdS2 Wrote:  Hmm, the Raspberry Pi may be a poor choice for other reasons, but it's certainly not limited to Linux - there's at least one other OS and there are several bare-metal projects.

I just learnt of Ultibo, and I stand corrected. Looks like you aren't stuck with Linux anymore, as much of the hardware is being supported. However, you are limited to GPL license.
Also, I'm not sure the term "baremetal" even applies when you have a full RTOS running on the GPU and providing services, but let's say for simplicity that an application built with Ultibo would count as baremetal.

Thanks for pointing out Ultibo. I took a quick look at the website.

Looks like it wants you to program in Pascal!

I have totally forgotten my Pascal! Never thought I'd ever have to relearn it. Probably won't, to be honest (lol).

[lemontea]

Anyway, I have been brainstorming this keypad thing for days. Still nothing substantial.

I even tried to look for mechanical keyboard switches that are small enough for our purposes. Nope. Doesn't even look like we can just take the switch component out of the whole chassis, at least not with ALPS or Cherry switches.

[maxrk]

(10-30-2019 10:48 PM)lemontea Wrote:  Anyway, I have been brainstorming this keypad thing for days. Still nothing substantial.

I even tried to look for mechanical keyboard switches that are small enough for our purposes. Nope. Doesn't even look like we can just take the switch component out of the whole chassis, at least not with ALPS or Cherry switches.

The following is based upon my hands-on controls development which includes sourcing keypads.

There are companies out there that make tactile keypads. As an example Nelson-Miller, CSI Keyboards, GM Nameplate, Almax, and others. The keypad usually falls under the generic name of membrane keypad. Most of these are manufactured in Taiwan or China however final assembly for the above suppliers may be done in the US - especially in the case of Nelson-Miller. These places are one-stop shops for final product.

The PCBs are not rocket science and can be made using 1 or 2-layer styles. These PCBs can be made for cheap at JLCPCB - hard substrate using

The PCBs can also be the flexible kind (FPC) which can have a built in pigtail that uses a low profile ZIF socket for connection to. This is seen on many laptop internals.

The keypad domes, which are the switch making and spring portions of the keypad, are stamped in different diameters and shapes with round being common and either gold or carbon plated or a combo of the two with gold being favored in low current applications like this.

The layers of the keypad with domes are literally taped together with double-sided tape including the overlay which is the portion with the print on it.

Plastic keys can be made as with the DM42 of which require additional hardware to attach and seal or one can make an overlay out of silicone rubber, painted with undercoating of white, as an example, and then painted with black and then laser etched with the names of the keys. The rubber overlay is more cost effective than using hard keys as in the 48 however one will get the HP 49 rubber keypad feel.

Overlays can also be made of polyester and can be printed on, preformed with key shapes, and then taped down. I think this is the case with some of the Swissmicro calcs. Polyester keypads can be sealed from the environment very well and can be spill-proof and UV resistant.

Quality wise, one may get better mileage / cycles out of dome switch designs versus very small mechanical switches, but dome switches can have growing pains until the manufacture works out the assembly process.

Oh, and there are also piezo-electric keypads which make electrical impact based upon impact and not mechanical contact. Also, the Microchip CPUs will work with either mechanical or piezo inputs through programming.

Anyway, see if membrane keypad technology answers some of your questions about keypad switches.

[lemontea]

Thanks! That's excellent input. Will look into all those areas.

I also just came across the below, which is a basic example showing how a person can 3D print the framework of a device, and wire up electronics inside it, for a final product. Note that only the supporting framework is 3D printed. The keycaps are purchased and therefore look professional. Something like this can form part of the recreated 48, with other parts professionally sourced.

Mechanical keyboard:

https://www.thingiverse.com/thing:1889210

Battery holders:

https://www.thingiverse.com/thing:456900

[lemontea]

(Totally unrelated but perhaps also interesting for some of us here)

https://www.thingiverse.com/thing:1467855

[lemontea]

Not what we want but "good effort" haha

https://www.thingiverse.com/thing:2049445

[lemontea]

Another one (work in progress, non-RPN)

https://circuitmaker.com/Projects/Detail...ntReleases

[lemontea]

I found the switch they use.

Dome shaped. SMT.

$10 for 50 of them.

https://www.digikey.com/product-detail/e...G4621CT-ND

Datasheet

https://media.digikey.com/pdf/Data%20She...TL3315.pdf

[Claudio L.]

(10-30-2019 10:45 PM)lemontea Wrote:  Thanks for pointing out Ultibo. I took a quick look at the website.

Looks like it wants you to program in Pascal!

I have totally forgotten my Pascal! Never thought I'd ever have to relearn it. Probably won't, to be honest (lol).

Yes, you are tied to a license, tied to a language and tied to an API that won't be portable to other platforms.
However, you could in theory make your calculator in layers carefully planned. You should come up with a HAL layer, connecting your application with abstracted hardware, then provide ports of this HAL layer with drivers for your different platforms, so that if you decide to get out of R-Pi you could simply write a new HAL layer.
Ultibo could be (I didn't look deep enough, but in theory) compiled as a library, and you could code in C, as long as you declare the external functions as pascal calling convention, your HAL should link without any issues. Storage of strings and data structure differences might still arise, but your HAL layer could abstract all that.
Your other choice would be go with a simpler platform, where you can write your own drivers and go truly baremetal (still, coding with a HAL layer would allow you to port to other hardware in the future, so it should be done anyway). This choice would be my first, rather than using a Raspberry Pi, but the R-Pi would get you started a lot faster, so it's a trade off.

[EugeneNine]

You were never "stuck" with Linux anyway. There is always bare metal. But a Pt is still overkill, I'd use a small ARM mcu.

[lemontea]

(10-31-2019 07:52 PM)EugeneNine Wrote:  You were never "stuck" with Linux anyway. There is always bare metal. But a Pt is still overkill, I'd use a small ARM mcu.

I was thinking of something from Microchip.

I think this device ought to be powered by 3 x AA or 4 x AA, last for years on a set of batteries, and doesn't have to be blazing fast (for that you'd just use a CAS app on your computer or smartphone).

No rechargeable lithium packs. It should stay in the desk drawer to be used many times per day, or once every 3 years, and still works when you pick it up to do a calculation. NiMH won't last 3 years in a drawer. So, only primary batteries. You can put in alkaline AA or Energizer Lithium for even more mileage.

LED or EL backlight e-ink is a bonus, depending on power drain.

No wireless anything except maybe IR (backward compatible so it can communicate with the IR printer, 48/49/50). But no need to bother with RF. Ultimately I envision this to be a solid, durable metal case, sealed for basic dust/water resistance (or at least the keyboard component can be taken out and rinsed in clean water, with the main PCB protected against spills, rain or dust).

[EugeneNine]

Newer low self discharge NiMH like Eneloops will last years in a drawer.

And one of the Microchip PIC or Atmel (which microchip now owns) like the one I was testing with https://www.microchip.com/wwwproducts/en/ATSAMC21E18A