Am Fri, 10 Jan 2025 07:25:48 -0800 schrieb Jeff Liebermann
Post by Jeff LiebermannOn Fri, 10 Jan 2025 05:19:53 -0500, zen cycle
Post by zen cyclePost by Jeff LiebermannOn Sat, 4 Jan 2025 20:51:16 -0500, Frank Krygowski
Post by Frank KrygowskiPost by Jeff LiebermannI'll look in my collection and see if I have an HP11C. Offhand, I
don't think so. There are some on eBay. The one's that offer the
least risk and are likely to work are $75 and up.
No need to check. When that calculator got stolen, the guys running the
company bought me a replacement. By then, the 11C was no longer
marketed, so I ended up with an HP 32S II, one of the few RPN machines
still in their line, IIRC.
The 11C seemed bulletproof, but this 32S is a bit flaky. Its the
calculator I keep in my workshop drawer, so it's not used very often.
But it seems that at least a third of the time I want to use it, it
refuses to turn on. I've slipped a little note in its case with notes on
the recovery procedure.
When it flakes out, I'll usually just pull out my Android phone and run
the HP 48G emulator. My main complaint about that one is that it isn't
really programmable - or at least, it doesn't retain programs when the
app is killed.
I finally remembered to look into my boxes of HP calculators. I don't
have an HP 32SII or something comparable. In the scientific
calculator section, I found an HP 31E and a 32E. Both of these are
low end RPN calculators with LED displays. The 31E had a battery leak
at some time in the past and will require that I do some battery
contact rebuilding. I can provide a complete list of what I have in
stock.
I never could get used to the RPN data entry method
Humans tend to prefer whatever technology they learned first.
Not really. I learned programming by creating punched cards using an IBM
26 Printing Card Punch, editing those programs by using the card
duplicating feature of those machines. Followed by pinnig stretches of
pages printed by large chain printers like to a wall, in order to study
complaints from the Fortran IV compiler, or using a pen to mark logical
errors in the source code, for later correction work on said card punch.
<https://en.wikipedia.org/wiki/IBM_1403>
I prefered almost every new programming technology that I learned later.
Sometimes, technology development takes the wrong path, naturally we
shouldn't and couldn't follow every idea, just because it is new. Simply
because several competing ideas are usually in vogue and are cheered on
by their enthusiastic fans.
Post by Jeff LiebermannMy
first calculator was basically a mechanical "adding machine".
<https://www.google.com/search?num=10&q=marchant+adding+machine&udm=2>
I eventually ended up with an HP-35 RPN calculator and loved it. RPN
is easy, if you think like a computer that stores intermediate results
in a stack.
Of course. If you do. But while I did study the matter (computer
science, that is), I don't think like a computer. I don't use RPN when
writing mathematical formulas, neither on paper, nor while programming.
Before you ask, I do know FORTH, I've even ported and changed an almost
unknown FORTH like language, adding traditional operator precedences to
the implementation, as a side project.
There is nothing wrong with RPN, if it works for you. But there isn't
anything "natural" about it.
Post by Jeff LiebermannAt home, I use an HP-41CX or an emulator on my phone and
PC. There are benefits and detriments to both algebraic and RPN
notation.
Yep.
I rarely used calculators, because writing short program snippets is
more natural for me. Many decades ago I did that using PL/I-80 on my
self-built CP/M computer, nowadays I just fire up a Python REPL, or
start a Jupyter notebook, for so called "back of the envelope"
calculations.
I do have a calculator app on my phone, which doesn't emulate anything.
It is switchable between traditional algebraic and RPN, radix modes
etc., though. The most frequently used feature is the comprehensive
conversion table for units, length, area, mass, speed and such. How
would I be able to convert Fathoms to Furlongs, without such a tool? :-)
Post by Jeff LiebermannIf we can become accustomed to QWERTY keyboards designed to
slow down typing, we can get used to anything. I can switch back and
forth between algebraic and RPN. Algebraic for financial calculations
and RPN for engineering. Evaluating long equations is easier (for me)
using RPN.
I can relate to that, but personally, I just don't calculate that way, I
don't do one shot calculations often enough to earn a benefit from RPN.
My first and only HP calculator is a HP 200LX, still working fine. I
lost one of the tiny case screws, decades ago, replacing the CR2032 now
and then is still awkward. I have no real use for the device anymore,
but I still like it enough for not giving it away. AFAIR, there's still
a copy of the original DeSmet C compiler on the flash card in the PCMCIA
slot. :-)
Getting back to cycling ... :-)
27 years ago, in 1998, the HP 200LX spent a lot of time in my panniers
on my commute (~5000 km/a). While playing with and exploring tiny
Microchip PIC microcontrollers at that time as a hobby, I used a spare
and slightly defective homebrew PCB (size ~1,3 *1,4 inch) as a prototype
board, took a PC16C84 processor, a 4,194,304 Hz quartz, 3 small
capacitors, one resistor, a 9 pin RS232 connector and two sockets, in
order to build an interface between the HPLX200 and a standard reed
contact as used by most bicycle computers sold at that time.
For simplicity, I didn't implement anything fancy on the PIC, by just
measuring and counting revolutions for an adjustable time span and then
sending the data in plain ASCII via the standard null modem cable which
came with the 200LX, leaving collecting the data and perhaps doing the
calculations on the 200LX.
I worked quite well, for some definition of "well". As often, software
and electronics were not the problem. The mechanics were the problem,
more precisely, the proprietary cable from the HP to my circuit board.
So in the end, I just collected data from a single test drive by using
the log feature of the 200LXs terminal program, while carefully holding
the plug with one hand, transfered that to a PC, used Excel to produce a
table - and finally admired my work. :-)
*** from PIC *******
One Revolution s
Current speed km/s
Accum. rev #
Distance km
Time s
800 6 2531 0,62 12,5 6 0,013 50
880 9 1867 0,46 17 15 0,032 55
960 16 1174 0,29 27 31 0,067 60
1040 19 1123 0,27 28,2 50 0,108 65
1120 17 1186 0,29 26,7 67 0,144 70
1200 16 1238 0,3 25,6 83 0,178 75
1280 15 1311 0,32 24,2 98 0,211 80
1360 14 1400 0,34 22,6 112 0,241 85
1440 14 1374 0,34 23,1 126 0,271 90
1520 17 1209 0,3 26,2 143 0,307 95
1600 16 1309 0,32 24,2 159 0,342 100
1680 15 1426 0,35 22,2 174 0,374 105
1760 14 1458 0,36 21,7 188 0,404 110
1840 14 1474 0,36 21,5 202 0,434 115
1920 14 1456 0,36 21,8 216 0,464 120
2000 14 1455 0,36 21,8 230 0,495 125
2080 15 1432 0,35 22,1 245 0,527 130
2160 14 1450 0,35 21,9 259 0,557 135
2240 14 1461 0,36 21,7 273 0,587 140
2320 14 1471 0,36 21,6 287 0,617 145
2400 14 1560 0,38 20,3 301 0,647 150
Anyway, having worked exclusively with mainframes in my job during the
early years, followed by PC sized smaller computers connected to what
they call "cloud" these days, I developed an interest in tiny
microcontrollers that were actually simple and useable for a hobbyist.
This started with the early PIC from Microchip, still expensive, needing
expensive UV-erasable versions, followed by the PIC 18C84 EEPROM
version, which could be reprogrammed without needing an somewhat
expensive UV lamp. Even more joy was using much smaller 8 bit
controllers that were still able to do work that what would have needed
a lot of TTL logic, beforehand. Like for example the PIC10F200
<https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/40001239F.pdf>
Harvard architecture, DIP8, 4 MHz, 256 words program memory, 16 Bytes
RAM, 3 I/O pins, one Input only pin, internal pullups, serial
programmable using an inexpensive programmer. One doesn't need an ARM
CPU with a handfull of cores in order to operate a mid sized toy
railroad, a handfull of these tiny and cheap microcontrollers would do,
at least in principle.
There are cheaper microcontrollers of Chinese origin, Padauk comes to
mind. A quick search tells the there are still cheaper ones in the
pipeline (1.5 cents for a complete computer, wow!)
<https://zeptobars.com/en/read/Nyquest-Technology-NY8A051H-8051-smallest-microcontroller>
but frankly, that's something for the next generation to play with. Is
it possible to implement Tetris with 1k words of OTP memory and 48 bytes
of SRAM? What about a Mastermind solver? I implemented a
Mastermind/Bulls&Cows solver using the PIC16C84, complete with decoding
two buttons, driving/multiplexing a raw four-digit seven-segment
display, using most of its 2 K words of EEPROM and 68 bytes of RAM.
<https://www.mystrobl.de/ws/pic/mm47/>
Parts are still available in 2025, including PIC 16F84A (€6.30 at a
local dealer) and HDSP 5503 (between 4 and 8 $ at ebay), so building
that gadget would still be possible. Rather uninteresting, though,
because microelectronics came a long way between the 16C84 and what we
can use buy and even as hobbyists, today.
This makes me reflect on the criticism of electronics in bicycles. I'm
not talking about replacing muscle power by motor power, that's
replacing bicycles by something else. But what about measuring the
amount of power applied to the pedals, what about telling the cyclist
who balanced he splits the power between left and right, by
instrumenting the pedal or the bottom bracket? What about replacing
those awkward cables and complicated brifters with simple electric
switches and an encrypted wireless channel? Is that bad, because a
blacksmith can't repair it with his tools, like giving a horse a new
pair of horse shoes? What about LED lights, then? Shouldn't we get
back to incandescent bulbs, powered by bottle dynamos?
I think we should not and can not turn back the wheel, at least not like
this. I accept that there are reasons to keep bicycles simple, or to
keep at least some biycles simple enough to long lived and usable even
without much maintenance and without exotic stuff. But the question is,
what makes a component or material exotic? Is a specific bowden cable or
a gear hub or hub generator really less exotic and simpler to
replace/recreate than, say, a LED light or a wireless shifter? I doubt
it.
There is a point when mechanical parts become complicated enough to
create a vendor lock-in, when a second source isn't available. Just like
with electronic parts. Sometimes the relationship gets reversed, when an
over-engineered and complicated mechanical solution is replaced by a
simple construction that combines commercially available electronics
with simple mechanical parts.
In this respect, you have to take a close look at where a dependency
arises, instead of simply linking it to characteristics such as “new”,
“electronic” or “wireless”. We need open standards, either through
industry commitments, or by regulations.
--
Thank you for observing all safety precautions