Threaded Mode | Linear Mode

rocket.scientist · 04-14-2021, 10:37 PM

So I am afraid I already know the best answer is "get a HP-XX instead". I am looking for a facility, likely using HP-IL to do keyboard entry remotely on a HP-41CL. Doing a bit of searching, I am not finding any good options, so I have come to the Oracles for a vision.

This topic came back to mind as I was going through the update process for my CL. After fat fingering a few entries it became evident that this was going to be interesting, with a couple of restarts along the way.

So here is my question. Is remote scripting / remote keyboard entry possible with a 41C class machine?

Thanks for the wisdom.

-Pat (KG5YPQ)

twdeckard · 04-14-2021, 11:00 PM

The barcode wand provides keypress equivalents, there was a sheet arranged like the face of the calculator with scan codes above each key. I wonder if you could cannibalize the wand and gate across the photodetector or build a loosely coupled LED strobe that would mimic the bar-code timing.

There was an old C64 wand that detected the retrace on the CRT and gave you a stylus. I wonder if you could hold the bar code wand up to a glyph on the LCD and strobe it between light and dark states to provide download to a calculator?

Curious about your application ...

Todd

Martin Hepperle · (This post was last modified: 04-15-2021 11:22 AM by Martin Hepperle.)

(04-14-2021 11:00 PM)twdeckard Wrote: The barcode wand provides keypress equivalents, there was a sheet arranged like the face of the calculator with scan codes above each key. I wonder if you could cannibalize the wand and gate across the photodetector or build a loosely coupled LED strobe that would mimic the bar-code timing.

In fact, there was a semi-commercial product in Germany in the 1980s, which used a wand with the cable cut and interfaced to an external device to control the HP-41C. I don't have the name at hand (PBG or similar), but I believe, it is described in one of the CCD Club Magazines.

Martin

Hans Brueggemann · (This post was last modified: 04-15-2021 05:21 PM by Hans Brueggemann.)

yes, the PBG of the computer club deutschland (CCD) came to my mind as well. the magazine's name was "PRISMA", for the records.
edit: PRISMA May-June 1982 has the first article about it. (PBG = pseudo barcode generator)

rocket.scientist · (This post was last modified: 04-15-2021 10:12 PM by rocket.scientist.)

I will definitely do some research into the products mentioned, though I doubt they are still available today except by lucky find.

I have considered the possibility of two options. First is to reverse engineer the code in the barcode ROM and perhaps adapt it to HP-IL. This is a tall order for me since I am completely unfamiliar with a number of skills necessary here. But then the bigger the challenge, the better satisfaction when it is done. The second and more achievable is to program a micro to emit flashes of light on a LED that mimics the light / dark ratios of the barcode, and optically couple that to a wand. This approach would only provide an "end effector" and still require a PC to coordinate all the pieces.

As an answer to "why", I can only say that I have had an interest over decades on how to use a HMI intensive device like the 41C in a process controlled environment. Using such a device to run the fiddly periodic updates to my CL is a good example. There are many more. Significant here is the HP-41C is end-of-life for all but us devotees. Practicality of use of such a solution is strictly secondary.

Thanks to all for the ideas. Stay healthy.

-Pat (KG5YPQ)

Hans Brueggemann · (This post was last modified: 04-16-2021 06:28 AM by Hans Brueggemann.)

it's always a litlle dangerous to jump into solution space too early, but with a HP-41C wand "at hand" it shouldn't be too difficult to connect a keyboard to an arduino and let it decode the keyboard entries into barcode that flashes an LED into the wand to control the HP-41C.
so that would at least free you from reverse engineering the ROM.

now if you want to go via HPIL, J-F's PIL-IO board comes to mind for generating with some extra HW the barcode flashes from HPIL data. why keeping the wand in this picture? afaik, the HP-41C can be HPIL master only, which might be a limitation when trying to take full control over it with a direct HPIL to HPIL connection, say, a HP-75C connected as "keyboard" to the HP-41C.

PeterP · 04-16-2021, 01:21 PM

Pat, have you considered auto-start modules or magnetic cards?

One can record magnetic cards as autostart and also program modules as autostart on plug-in. If the idea is to create some scripts and then have them executed automatically, this seems to be a viable option potentially.

Sylvain Cote · 04-16-2021, 02:34 PM

(04-16-2021 01:21 PM)PeterP Wrote: Pat, have you considered auto-start modules or magnetic cards?

The Auto-Start/Duplication module always execute the RECOVER program (LBL "RECOVER") at power-on.

There is also the flag 11 that will continue the current program at power on.

Code:

LBL "F11"   // flag 11 demo program entry point

SF 11       // set auto start flag 11 

OFF         // power off the calculator

BEEP        // executed when user press the ON button

END         // flag 11 demo program exit point

cdmackay · 04-17-2021, 05:56 PM

For my education, what is it architecturally that makes it possible to interact with the 71B directly via HP-IL, but not the 41?

rocket.scientist · 04-17-2021, 07:20 PM

(04-16-2021 06:27 AM)Hans Brueggemann Wrote: it's always a litlle dangerous to jump into solution space too early, but with a HP-41C wand "at hand" it shouldn't be too difficult to connect a keyboard to an arduino and let it decode the keyboard entries into barcode that flashes an LED into the wand to control the HP-41C.
so that would at least free you from reverse engineering the ROM.

now if you want to go via HPIL, J-F's PIL-IO board comes to mind for generating with some extra HW the barcode flashes from HPIL data. why keeping the wand in this picture? afaik, the HP-41C can be HPIL master only, which might be a limitation when trying to take full control over it with a direct HPIL to HPIL connection, say, a HP-75C connected as "keyboard" to the HP-41C.

So this is relevant, and part of what is in my mind as a simpler solution than re-writing the HP-IL module to allow control of a 41C. For me, I can barely spell HP-IL, much less rewrite code. :-)

It does strike me as curious why, assuming optical coupling to a wand is so simple, why someone has not already done it. I did find others asking about remotely controlling a 41C keyboard and nobody had a good answer.

I do have J-F's wonderful PIL-Box, and am now curious if the PIL-IO has enough bandwidth to flash a LED with sufficient speed. Not having one to play with I am assuming it would be one command to turn the LED on, and another to turn it off a few milliseconds later. I may need to wait for him to chime in here.

Thanks for the suggestion here.

-Pat (KG5YPQ)

rocket.scientist · 04-17-2021, 07:50 PM

(04-16-2021 02:34 PM)Sylvain Cote Wrote:
(04-16-2021 01:21 PM)PeterP Wrote: Pat, have you considered auto-start modules or magnetic cards?
The Auto-Start/Duplication module always execute the RECOVER program (LBL "RECOVER") at power-on.

There is also the flag 11 that will continue the current program at power on.

Code:

LBL "F11" // flag 11 demo program entry point SF 11 // set auto start flag 11 OFF // power off the calculator BEEP // executed when user press the ON button END // flag 11 demo program exit point

Both SF 11 and mag card would be an excellent option for fully autonomous operation of the 41C. Instead what I am thinking is a way to have the operation of a 41C coordinated with some other asynchronous process.

The updating of a 41CL is a good example, and fairly well known. There is an elaborated dance that needs to happen between a PC and a 41CL to manage the periodic updates, with commands at the PC coordinated with commands on the 41CL. While Sylvain and Monte (and others I am sure) have developed the excellent "clupdate" tool to facilitate, there is still a lot of manual coordination between PC and calc. It would be nice, since the full process is so well known, to have the PC more fully automate the process.

**BIG GOTCHA HERE** This highly automated approach does not accomodate any error conditions that may arise. I am not sure it is possible to permanently brick a 41CL, but I do not want to find out.

-Pat (KG5YPQ)

Sylvain Cote · (This post was last modified: 04-18-2021 04:43 PM by Sylvain Cote.)

(04-17-2021 07:50 PM)rocket.scientist Wrote: While Sylvain and Monte (and others I am sure) have developed the excellent "clupdate" tool to facilitate, there is still a lot of manual coordination between PC and calc. It would be nice, since the full process is so well known, to have the PC more fully automate the process.

Sure, the reason that the 41CL update works the way it is, was that Monte wanted to be able to do 41CL to 41CL update.
In order to do that, the PC had to become a passive file server and the 41CL had to be the active client/controller who request/send data from/to the PC.

For the HP-71 remote keyboard to work, it has to constantly poll the loop (IDY) to detect service request message (SRQ) and then talk to the keyboard device to get the key pressed on the keyboard.
In order to do that, something must be running in the background to do the constant polling and character fetching, either a software background task, a hardware background task in HP-IL module or a specially designed OS polling point that a software can register to.
To my knowledge the HP-41 does not have that level of complexity in the 41OS nor in the HP-IL module.

The two HP-41 peripherals that can do the equivalent of an asynchronous data entry are: the 82153A Optical Wand and the 82104A Card Reader.

Sylvain

edit 1: there is also the Time Module that can trigger an interrupt. (or something similar)

Sylvain Cote · 04-18-2021, 04:43 PM

After a quick research I found that the 82153A Wand Service Manual Chapter 2 explains the process of asynchronous remote data entry quite well.

Monte Dalrymple · 04-19-2021, 07:52 PM

(04-17-2021 07:50 PM)rocket.scientist Wrote: The updating of a 41CL is a good example, and fairly well known. There is an elaborated dance that needs to happen between a PC and a 41CL to manage the periodic updates, with commands at the PC coordinated with commands on the 41CL. While Sylvain and Monte (and others I am sure) have developed the excellent "clupdate" tool to facilitate, there is still a lot of manual coordination between PC and calc. It would be nice, since the full process is so well known, to have the PC more fully automate the process.

**BIG GOTCHA HERE** This highly automated approach does not accomodate any error conditions that may arise. I am not sure it is possible to permanently brick a 41CL, but I do not want to find out.

-Pat (KG5YPQ)

The "elaborated (sic) dance" is actually quite simple compared to what happens behind the scenes when, for example, plugging anything into a USB port on a PC. So are you asking for a "plug it in and it beeps when done" type of operation?

I designed the protocol deliberately to make the user aware of what is going on, and to give the user the opportunity to modify the process if desired:

"CMOPEN" to make sure that the PC is connected properly and aware of the CL.
"*" "FLCHK?" to check the compare the status of the CL Flash with what the PC thinks it should be.
"FLUPD" to actually update the Flash, giving the user the opportunity to verify or modify the updated pages. Perhaps the user doesn't want something updated.
"CMCLOSE" to signal to the program running on the PC that the CL is done.

Of course, there are options along the way. "CPONLY" to simplify the compare process if the user knows that the FLDB on the CL is current. "OSUPDT" protects the user because the OS sector is critical.

The only way to brick the machine is to muck up the update of the OS sector. I made it as foolproof as I can. The downloaded pages in the OS sector are always checked for the proper CRC, even though the comm channel itself is very reliable. The user must specifically enable the OS sector update. The battery status is checked before the sector is erased (this happens with every sector) and the process is aborted if the battery is low. I can't protect against the battery suddenly failing, or being removed, during the OS sector erase or write, but I have tried to account for every other possibility.

Perhaps it's a philosophical thing. As a user, I want control of what happens at each step. I am the first to admit that I may be odd in this regard.

Monte

Andres · 04-19-2021, 09:18 PM

Many years ago Tony Duell and I discussed (at a very high level, without any detailed design) how to couple a pair of CMOS analog multiplexers (CD 4051 or equivalent) in a back-to-back configuration, and connect them to the rows and columns of the keyboard PCB to load programs into a 42S which, of course, has no other input means. An Arduino (or a Raspberry Pi Pico) could easily drive the muxes to simulate keypresses... the muxes could be located inside the calculator with some glue logic to implement SPI, so to reduce the number of data lines entering the calculator from the outside.

The hardware wand was a product from the HP Optoelectronics division. Such HP wand was sold to OEM, and included little hardware on itself. The sensor was not just a phototransistor but a emitter-detector pair mounted with a hyperbolic lens. The HP 41 Wand was an HP Wand plus the circuitry and ROM needed for its specific function.

Some 45 years ago, a solenoids-based "button pusher" was not as weird as it sounds today. HP used them for quality control in calculators production lines (as shown on a HP Digest issue around 1976-77), and "button pushers" were also advertised to adapt IBM Selectric typewriters as desktop printers.

David Hayden · 04-19-2021, 10:15 PM

With today's easy robotic kits, it probably wouldn't be hard to create a Key Pressing Robot (KPRtm).

I envision something like a plotter that moves in the X & Y directions, plus the ability to raise and lower a plunger. Put the calculator in a jig on the KPR and software translates your text listing into key presses based on a configuration file.

Where this really could shine is with calculators that lack I/O. Imagine being able to enter a long program into a 35s or 15C

Heck, it might even be a good project for a high school robotics class.

A few details would make this fairly robust. After placing the calculator into the jig, there might be a calibration step to ensure that the KPR knows exactly where the keys are. Think of the difference between a tall key and short key 41C. The actuator might be two pieces connected by a short spring to avoid over-pressing a key. Ideally, to add a new calculator, you'd just have to write a new config file.

rocket.scientist · 04-19-2021, 10:29 PM

(04-19-2021 07:52 PM)Monte Dalrymple Wrote:
(04-17-2021 07:50 PM)rocket.scientist Wrote: The updating of a 41CL is a good example, and fairly well known. There is an elaborated dance that needs to happen between a PC and a 41CL to manage the periodic updates, with commands at the PC coordinated with commands on the 41CL. While Sylvain and Monte (and others I am sure) have developed the excellent "clupdate" tool to facilitate, there is still a lot of manual coordination between PC and calc. It would be nice, since the full process is so well known, to have the PC more fully automate the process.

**BIG GOTCHA HERE** This highly automated approach does not accomodate any error conditions that may arise. I am not sure it is possible to permanently brick a 41CL, but I do not want to find out.

-Pat (KG5YPQ)

The "elaborated (sic) dance" is actually quite simple compared to what happens behind the scenes when, for example, plugging anything into a USB port on a PC. So are you asking for a "plug it in and it beeps when done" type of operation?

I designed the protocol deliberately to make the user aware of what is going on, and to give the user the opportunity to modify the process if desired:

"CMOPEN" to make sure that the PC is connected properly and aware of the CL.
"*" "FLCHK?" to check the compare the status of the CL Flash with what the PC thinks it should be.
"FLUPD" to actually update the Flash, giving the user the opportunity to verify or modify the updated pages. Perhaps the user doesn't want something updated.
"CMCLOSE" to signal to the program running on the PC that the CL is done.

Of course, there are options along the way. "CPONLY" to simplify the compare process if the user knows that the FLDB on the CL is current. "OSUPDT" protects the user because the OS sector is critical.

The only way to brick the machine is to muck up the update of the OS sector. I made it as foolproof as I can. The downloaded pages in the OS sector are always checked for the proper CRC, even though the comm channel itself is very reliable. The user must specifically enable the OS sector update. The battery status is checked before the sector is erased (this happens with every sector) and the process is aborted if the battery is low. I can't protect against the battery suddenly failing, or being removed, during the OS sector erase or write, but I have tried to account for every other possibility.

Perhaps it's a philosophical thing. As a user, I want control of what happens at each step. I am the first to admit that I may be odd in this regard.

Monte

Ugh. Why did I get a "(sic)" on using the word "elaborated"? According to Google my use was entirely appropriate. :-)

My choice of using the CL update process was only as an example of a well known process where actions on the 41C are coordinated with actions on a PC. I personally enjoy the degree of interaction during the update, and agree your degree of feedback and protective features are remarkable.

Sorry if I struck a cord here, Monte. It was not my intention.

-Pat (KG5YPQ)

rocket.scientist · 04-19-2021, 10:35 PM

(04-19-2021 10:15 PM)David Hayden Wrote: With today's easy robotic kits, it probably wouldn't be hard to create a Key Pressing Robot (KPRtm).

I envision something like a plotter that moves in the X & Y directions, plus the ability to raise and lower a plunger. Put the calculator in a jig on the KPR and software translates your text listing into key presses based on a configuration file.

Where this really could shine is with calculators that lack I/O. Imagine being able to enter a long program into a 35s or 15C

Heck, it might even be a good project for a high school robotics class.

A few details would make this fairly robust. After placing the calculator into the jig, there might be a calibration step to ensure that the KPR knows exactly where the keys are. Think of the difference between a tall key and short key 41C. The actuator might be two pieces connected by a short spring to avoid over-pressing a key. Ideally, to add a new calculator, you'd just have to write a new config file.

Oooh! This is a good approach. I know it can be done much more cleanly, but the image in my mind is that of this "speech to type" typewriter. It is almost SteamPunk. This is definitely going on my to-do list.

-Pat (KG5YPQ)

rocket.scientist · 04-19-2021, 10:40 PM

(04-18-2021 04:43 PM)Sylvain Cote Wrote: After a quick research I found that the 82153A Wand Service Manual Chapter 2 explains the process of asynchronous remote data entry quite well.

Interesting. This appears to make the optical coupling approach feasible. I need to study the barcode structure further, but the simplistic light-dark (bar-space) ratios coupled with low bandwidth should be easily within the scope of a microcontroller.

I like this.

-Pat (KG5YPQ)

cdmackay · 04-19-2021, 10:54 PM

(04-19-2021 10:29 PM)rocket.scientist Wrote: Ugh. Why did I get a "(sic)" on using the word "elaborated"?

It depends on whether you meant the adjective elaborate, or the verb past participle elaborated?

That said, elaborated can be an adjective too, but the OED says that's not in common usage these days. And it could be taken to have a slightly different meaning.

--

and thanks to Sylvain, whose comments answered my question indirectly.