Notifications
Clear all
Electronic Components & Theory
25
Posts
3
Users
0
Reactions
809
Views
2026-08-27 9:53 am
So... I'll be no help on either of these issues.Never mind. I'll check the ESP32 simulators ASAP. Maybe those could be an option to run some C code.
You might do a topic on that... I'd certainly be interested.
But I don't see how it handles peripherals. Any time I ever use a micro, I've got stuff attached... usually sensors and/or actuators. If it takes more time to simulate those than just plugging things into a breadboard, I'm not sure I understand the point.
Thanks.
Inq
Topic starter
2026-08-27 7:37 pm
"Zigbee, Thread, and Matter"-- what ...?
I don't plan to make the keyboard detachable and link it wireless, thus not need of this me think.
2026-08-28 12:42 am
Hi @amphitryonoff,
I wish you well with what I think will be a challenging project. My only previous encounter with an HP calculator, was a very brief loan of an HP35 back in 1973. Very soon afterwards, I bought the CBM near clone, with similar capability, except it had 2-level parenthesis, instead of the infamous Reverse Polish Notation, stack based system. From memory, its appearance was similar to the SR4148 ( https://www.computinghistory.org.uk/det/66009/Commodore-SR-4148R-Calculator/ ), except it did not have the top 8 buttons.
You appear to be attempting to build a considerably smaller machine than the HP35, with rather more capability. Of course the computational complexity should not be a major problem with appropriate software, but the physical construction could be a different matter. I guess you will be making or commisioning custom PCBs etc., The DIY keyboard link you provided shows the keys plus an ATMEGA 328, which has 23 I/O lines, so driving the keyboard should be feasible, but this does not provide a display or radio link such as WiFi or the others you mentioned. LCD displays often also require a considerable number of lines to drive them directly, or one or more driver chips, to provide an interface such as I2C or SPI.
ESP32 family modules often provide WiFi and/or Bluetooth connectivity. Some could provide enough pins to drive the keyboard, and possibly a display function, but these will be much larger than the small modules Google suggested for my query about Xiao.
I don't have any direct experience of using a WiFi from an ESP family board when mounted in a tin, but bearing in mind it will need the keyboard and display in close proximity, mounted over the top of the ESP board, which will also screen the top, even with the lid removed, I would guess the range, using the usual built-in zigzag antenna to be short, possibly effectively zero. Of course, the ATS mini-radio you referred to has an external antenna socket, and that approach could be replicated with suitable choice of WiFi board. The ESP32 family is often discussed on this forum and elsewhere, on the basis of the development boards. These boards include a rectangular module which includes a rectangular screening can, and inside that module is the actual ESP32 family microcontroller device, along with other devices, like memory, etc. In principle, you could consider integrating either the microcontroller, or the rectangular module, onto your own PCB, providing you have the higher level of design expertise implied by these options.
I suggest you start by prototyping with readily available parts, which provide the expected functionality, but may not fit into your desired housing. Whilst this implies some of the design work will be duplicated, the experience gained could prove invaluable. At this stage, I don't think I can provide much more guidance, but if you post further queries, I wil probably see them, and may be tempted to comment, if I feel I can add something useful.
Best wishes and good luck, Dave
Topic starter
2026-08-28 1:13 am
You might do a topic on that... I'd certainly be interested.
Until it's finished have a look at this clip on youtu.be. But if we are lucky in the meantime Bill will present a video about his experience regading simulators in his DroneBot Workshop.
Topic starter
2026-08-28 3:46 am
Hi @davee ,
I wish you well with what I think will be a challenging project.
TY for your good wishes and also TY for your time to look into my high goal. It's feasible me think, step by step, but what's challenging is me, wading through a swamp in terra incognita w/o a compass.
except it had 2-level parenthesis, instead of the infamous Reverse Polish Notation
Awesome RPN in my view 😉
You appear to be attempting to build a considerably smaller machine than the HP35, with rather more capability. Of course the computational complexity should not be a major problem with appropriate software, but the physical construction could be a different matter.
The size of a machine is no idicator of its capability, just wait few years and a smaller device is more capable than the one you kow today. To "emulate" ancient calculators is straightforward, you need a stable simulation of its CPU and a ROM copy of its f/w. Most ROMs leaked out, some of them with much know-why and distinct effort.
Here a photo from a friend:
I've done "emulators" of the HP-41 and the complete HP Voyager series, once in FORTRAN on an IBM mainframe and once more using ooRexx under Windows. Now I will do it once again in C (or C++, IDK). As usual, the challenging or thrilling part is, to attach the major input and output devices -- keyboard and display -- to the host system.
My first intermediate step is to run a virtual Voyager in a ESP32 simulator. When that works I'll rise my head and look forward to take the next hurdle.
The DIY keyboard link you provided shows the keys plus an ATMEGA 328
Here in this second of this clip the presenter mentiones a specialised keyboard chip, alas, I have not found a parts list yet. But I assume (an uneducated guess), since keyboards are a common device there exist plenty keyboard chips, and one or another will fit into my project.
LCD displays often also require a considerable number of lines to drive them directly, or one or more driver chips, to provide an interface such as I2C or SPI.
I'm still far away from choosing an apt display. Thus CYD is still an option.
I suggest you start by prototyping with readily available parts, which provide the expected functionality
I hope I could avoid this approach if possible by using simulators to avoid trial-and-error with real h/w. I'm used to work with virtual systems. That is why building a haptic copy of a calculator is totally terra incognita for me.
At this stage, I don't think I can provide much more guidance
As said before, ty for your time. And please, holler if you see me running into an impasse.
Best,
M.
Topic starter
2026-09-21 7:04 am
Now I found this 'Cyberdeck in a mint tin', what is a nice prove my project is feasible. That's encouraging.
I've still not decided if 'C' or 'MicroPython' (or 'Rust') is the best for my project. All the blinking LED examples, no matter if one or more LEDs, are not of much help in my case. Thus, almost no progress to report.
Topic starter
2026-10-06 11:14 am
A little achievment worth to mention: I've begun to migrate my "Nut CPU f/w interpreter" from REXX to MicroPython under Wokwi. Larded with lots of print() for debugging it currently runs the HP10C and -11C from power on to first stop awaiting a keypress. As of yet there is no display, no key working, it's only a lot of output scrolling in the serial monitor, ending on purpose with
name 'wfnxkp' isn't defined
(= wait for next key press) -- next part of this project.
Thus I made my first steps with Python. Lessons learned: MicroPython is not Python, global does not work in all cases. Then I was forced to pass the variable as argument to the "subroutine", or function definition. Due to this uncertainty about which vars are local and which are global, I feel uncomfortable with MicroPython. In addition, it's pretty time consuming to find the functions that might do what I like.
At least a little success at the moment -- https://discord.com/channels/787627282663211009/1547897510830411819
Note: currently no display output, no keyboard input, f/w interpreter only, still no real h/w involved.
2026-10-06 2:05 pm
I'm glad you have some success. I thought one of the main claims to fame was that Python let you step-by-step debug???
I think you've just driven last nail in the coffin for me using Python.
I've been exposed to two classes at the local University using Python. One says you must use Anaconda, the other says you must not because it will screw up your environment. I have to use different versions of Python for each (by edict). Even the professors run into version changes breaking all their code that they're trying to demo live in class. Rather funny being on the student side.
I've pretty much gotten used to the syntax differences for all the basic coding things between C++ and Python. I still have to reference back and forth for things like lists, dictionaries, tupes, sets, enum... But the staggering amount or relearning of libraries and which does what and what functions are available will always be a problem.
The fact that its runtime is slower unless you're doing something that is in a library (that was written in C++) didn't bother me if the interpreted, step-by-step debugging, modifying, re-running was quicker. However, my personal throughput counting actual coding time, compiling, running, debugging in C++ versus merely removing the compiling time and using Python is almost laughable... I'm night and day faster in C++.
That I can prototype anything but the micro-controller specific code on the PC where the compile time is fractions of seconds and I can step-by-step debug; I can finish tasks in fractions of the time of trying to do it in Python. That you mention the coding is NOT portable and is likely to break the next release of Python or Micro Python has resolutely killed Python for me.
I'm finding University mentality toward Python the most troubling. It's almost a religion to them. As a student, I'll bow to their requirements of course. But as a professor starting next semester, I'll be language agnostic and let students write in Sanskrit if they want.
Inq
Topic starter
2026-10-06 3:43 pm
Hi @inq !
Your description of the Python issues in teaching and practical application says it all. Maybe I'm pampered in some way, at work I programmed on an IBM mainframe, first using FORTRAN and REXX, then REXX and Pipeing. I'm used to, if sometings' wrong, it's my fault, not an error of the system -- well almost not, I reported 2..3 bugs, but that was through the years. In contrast, Python looks to me like a peat swamp. Maybe my view is unfair as I tried MicroPython in a simulator just for three days only, but already I toy with the idea to revise my Go for Python.
Topic starter
2026-10-09 9:01 pm
Next achievment worth to mention: I give up.
More precise: I give up using MicroPhython for this goal. Coming from REXX I was somehow displeased by MicroPython, but a missing translate was too much. W/o it I failed to transform the single segments of the display as lit to the ASCII representation as shown. At least I achieved to rearrange the "lit segments patern" to '007A22003B2222272200', alas not to transliterate it to ' Pr Error ' what is the first msg after power on with new barreries or after a reset.
I'll continue this project, if by using 'Rust' (a speaking name like 'Smalltalk'), or 'C', IDK yet.
Page 2 / 2
Prev