HP41C with Rp Pico attached

[ThomasF]

(09-07-2023 12:11 PM)MeindertKuipers Wrote:  Whenever possible (without cleanup) having the sources of the disassembler part would be great to add that to my HP41 bus tracer.

Hi Meindert,

I just sent you a PM.

Cheers,
Thomas

[blackjetrock]

A bit more progress. I have the RP2040 attached via a module port, which loses the keyboard entry function but retains everything else. It's now powered via the HP41c as well. I have fitted a 16Mbyte flash chip to this PCB instead of the Pico's 2Mbyte so more code and ROM images can be stored. The USB works as well so data could be transferred over that as well. There are spare GPIOs which are taken out to a connector. My code runs fine on this and you can see it in the video emulating a couple of ROMs.

https://youtu.be/e8J7r-Oih8E


Andrew

[Massimo Gnerucci]

(09-09-2023 11:25 AM)blackjetrock Wrote:  A bit more progress. I have the RP2040 attached via a module port, which loses the keyboard entry function but retains everything else. It's now powered via the HP41c as well. I have fitted a 16Mbyte flash chip to this PCB instead of the Pico's 2Mbyte so more code and ROM images can be stored. The USB works as well so data could be transferred over that as well. There are spare GPIOs which are taken out to a connector. My code runs fine on this and you can see it in the video emulating a couple of ROMs.

https://youtu.be/e8J7r-Oih8E


Andrew

This module approach looks very promising.
Well done, keep us updated.

[MeindertKuipers]

Just a brief update on progress with the RP2040 attached to an HP41.
I have been able to emulate Extended Memory on the Pico (connected to my HP41CX), at the same time as emulating QRAM and ROM.
Today I have been able to get HP82143A printer emulation working in a first phase. I can simulate power ON/OFF of the printer and actually print (to a terminal emulator) some text. Next is to implement the printmodes and pressing the PRINT and ADV keys, and check printing into the PC-based HP82143A simulator (including graphics). This now means that I can reliably transfer the DATA register to and from the calculator, set the CPU carry (when asked by the NUT) and switch the calculator on when in deep or light sleep.

[MeindertKuipers]

Another (quite significant) update on this project. I have posted a video on Youtube with a demonstration of the main features.





Things are running pretty stable, some small issues still to be resolved. Now on to the next steps:
- improve the user interface
- flexible plugging/unplugging of ROMs
- HEPAX support
- saving settings and mapping in FRAM
- HP-IL emulation (to USB serial)
- micro SD card support

[Tinue]

Thank you for the video, I found it very interesting. How do you interface electrically with the HP 41? I assume it is a 5V device, while the RP2040 uses 3.3V.

[MeindertKuipers]

(12-02-2023 10:25 AM)Tinue Wrote:  Thank you for the video, I found it very interesting. How do you interface electrically with the HP 41? I assume it is a 5V device, while the RP2040 uses 3.3V.

Just simple level shifters. I have a few interfacing boards left from my MLDL2000 activities. I use a CD4050 for downshifting, and an HCT125 for upshifting to 6V (HP41 is around 6V). For shifting up to 6V a 40109 would be a bit better.

[blackjetrock]

(12-02-2023 10:25 AM)Tinue Wrote:  Thank you for the video, I found it very interesting. How do you interface electrically with the HP 41? I assume it is a 5V device, while the RP2040 uses 3.3V.

The RP2040 is actually sort of 5V tolerant, so it can interface to 5V systems, but only on its inputs.
the HP41C is actually a 6V-ish system, so level shifters are needed. CD40109 shifters are good to use in this situation as they drive at 6V.

Andrew

[Tinue]

Thank you both. I realize that I highjack this thread, so if I am out of line please let me know. I need to interface with the HP C4103A, which is a 5V device. I read about the tolerance to 5V, but as written the RP2040 chip needs to have booted and switched the GPIO to "input", before 5V can be applied. It's a bit risky, when the C4103A is receiving IR on power up: If the C4103A boots up first it can damage the Pico.

I only have a 74AHC125 lying around. These are bus drivers, but can be used as level shifters. They work fine for shifting up, but I never tried them for shifting down. The data sheet hints at this to maybe be allowed, but it's not within spec.

I thought that you were maybe using a simple voltage divider, because I see lots of resistors in the video ;-)

[blackjetrock]

(12-02-2023 11:26 AM)Tinue Wrote:  Thank you both. I realize that I highjack this thread, so if I am out of line please let me know. I need to interface with the HP C4103A, which is a 5V device. I read about the tolerance to 5V, but as written the RP2040 chip needs to have booted and switched the GPIO to "input", before 5V can be applied. It's a bit risky, when the C4103A is receiving IR on power up: If the C4103A boots up first it can damage the Pico.

I only have a 74AHC125 lying around. These are bus drivers, but can be used as level shifters. They work fine for shifting up, but I never tried them for shifting down. The data sheet hints at this to maybe be allowed, but it's not within spec.

I thought that you were maybe using a simple voltage divider, because I see lots of resistors in the video ;-)

The 125 can shift down as it runs off the 3V3 and is tolerant to 5V, I don't think you can shift up from 3V3 with that device? Or are you running off 5V and putting a 3V3 signal in? I've used the 125 for shifting down and it works fine. The problem at 6V is that the Pico GPIO output doesn't quite always make an output high enough to be a 1 for the 125. If you run it at 3V£ (the 125) then that doesn't quite make a 1 sometimes either. The 40109 doesn't have this problem.

the GPIOs on a Pico or RP2040 come up from reset as inputs so there's no problem at startup.

Andrew

[MeindertKuipers]

(12-02-2023 11:26 AM)Tinue Wrote:  I thought that you were maybe using a simple voltage divider, because I see lots of resistors in the video ;-)

For a quick and dirty downshifter you can use a voltage divider, as long as the speed is not too high. The resistors in my video are pullups on the output enables for the HP41 outout signals (towards the HCT125) to ensure that the outputs are not driven while the RP2040 is idle.
Using the '125 works well, its input high is low enough for the RP2040 outputs at 3.3V even when powered at 6V. But the 40109 is a much better solution for levelshifting up. Actually I have a spare 40109 on the breadboard ready for testing.

[Tinue]

(12-02-2023 11:53 AM)blackjetrock Wrote:  The 125 can shift down as it runs off the 3V3 and is tolerant to 5V, I don't think you can shift up from 3V3 with that device? Or are you running off 5V and putting a 3V3 signal in?

I have used the 125 to drive an LED strip, which needs 5V input, from a Raspberry Pi. VCC of the 125 was 5V, and this was then also the output voltage. I later found out that the LED strip is happy with the 3.3V as well, and dropped the 125.

For now, I am using a simple circuit with two resistors and a transistor, which works fine. But it really looks like this is not necessary, and I can simply connect the input of the C4103A directly to the Pico. I already checked the other way round: The C4103A seems to be fine with the 3.3V input from the Pico, and produces a clean signal.

Thanks again, and sorry for misusing this thread. I'll shut up now ;-)

[blackjetrock]

(12-02-2023 01:15 PM)Tinue Wrote:  

(12-02-2023 11:53 AM)blackjetrock Wrote:  The 125 can shift down as it runs off the 3V3 and is tolerant to 5V, I don't think you can shift up from 3V3 with that device? Or are you running off 5V and putting a 3V3 signal in?

I have used the 125 to drive an LED strip, which needs 5V input, from a Raspberry Pi. VCC of the 125 was 5V, and this was then also the output voltage. I later found out that the LED strip is happy with the 3.3V as well, and dropped the 125.

For now, I am using a simple circuit with two resistors and a transistor, which works fine. But it really looks like this is not necessary, and I can simply connect the input of the C4103A directly to the Pico. I already checked the other way round: The C4103A seems to be fine with the 3.3V input from the Pico, and produces a clean signal.

Thanks again, and sorry for misusing this thread. I'll shut up now ;-)

No problem, it's relevant to this project, sort of.

If you haven't then it's worth reading the forum post here:

https://forums.raspberrypi.com/viewtopic...2#p2091977

which has the nasty details of the 5V 'tolerance' of the RP2040.

Andrew

[brouhaha]

(12-02-2023 01:29 PM)blackjetrock Wrote:  f you haven't then it's worth reading the forum post here:

https://forums.raspberrypi.com/viewtopic...2#p2091977

which has the nasty details of the 5V 'tolerance' of the RP2040.

The TL'DR is that in practical terms, the 5V tolerance is like the cake, mostly a lie.

I use 74CBTD3861 voltage clams for all my 3.3V to 5V interfacing, often even for parts that claim 5V tolerance but have significant caveats. The 3861 is an x10 nFET bus switch, with an internal diode from the +5V rail. Due to the diode and the characteristics of the nFETs, it limits voltage through the switch (in either direction) to no more than about 3.5V, which is within tolerance for all 3.3V parts. (Not satisfactory for 3.3V parts running on 3.0V!) Since it does this by the nFET going open, it doesn't present any significant load to either side when it is "clamping" the voltage (unlike e.g. zener or other diode clamps).

[blackjetrock]

(12-02-2023 05:25 PM)brouhaha Wrote:  

(12-02-2023 01:29 PM)blackjetrock Wrote:  f you haven't then it's worth reading the forum post here:

https://forums.raspberrypi.com/viewtopic...2#p2091977

which has the nasty details of the 5V 'tolerance' of the RP2040.

The TL'DR is that in practical terms, the 5V tolerance is like the cake, mostly a lie.

Well, I wouldn't quite go that far. I have used the Rp2040 in circuits where I didn't have room for a level shifter and they have been fine so far. It helps that a lot of old computers seem to have run their 5V rails at just under 5V too.

[ThomasF]

Hi all,

Like Meindert, I have been busy with the Pico attached to the 41 (see Meinderts video some posts above), and for the last weeks I have been trying to emulate the Blinky ROM (HP-82242 IR Printer module).

I started from scratch, with just the ROM-dump of the two banks of the module, but with almost no documentation about the hardware in the module.

But, with the help of Meindert and Mike, I have more or less now a complete emulation of the hardware, emulating all flags and registers in there - enough so that I can use the "module" in a real HP-41 and print.

I have yet to attach an IR-led to the Pico, but I can send and verify the output from the module in the PC, so an IR-led is the next step.

To be able to do this, I have disassembled the ROM and "unwinded" all code to be able to understand how the code works, especially the interaction with the hardware (timers, status registers etc).
Then all hardware is emulated by the Pico in real time, the output buffer, timer clock and signaling on the FI bus, indicating buffer and timer status.

There are some peculiarities that I still don't understand - maybe some hardware and NUT experts here on the forum might help in understanding the inner working ...

One such case is the usage of CXISA. The module uses two banks, and to save from switching, a lot of code is duplicated in both banks.

There is one case in bank 1 (second bank), where a table in mainframe ROM 1 is accessed (at address 0x1400).
But, instead of accessing that table directly, the code calls a subroutine, switches to bank 0, executes CXISA, swaps back to bank 1 and returns.

Code:

 6999 130014 LDI 014        # Main function table (@1400)
 699B 27C    RCR 9          # Rotate in 2 last addr digits
 699C 2951BC GSUBNC 6FA5    # CXISA from bank 0 @ 14xy

# The code jumps the the following code
# Execute CXISA from bank 0
 6FA5 00B GONC +1 6FA6
 6FA6 100 ENROM1            # Jump to bank 0

# Here we switch over to bank 0 and continue execution
 6FA7 330 CXISA
 6FA8 3EB GONC -3 6FA5

# Here we switch back to bank 1 again ...
 6FA5 00B GONC +1 6FA6
 6FA6 180 ENROM2            # Jump to bank 1

# Back in bank 1 we return and continue execution ...
 6FA7 3E0 RTN

So, instead of executing CXISA directly, 7 more instructions including two bank switches and a subroutine call is made.

Is there any logical reason for this? Or just a "why not"?

There is also a case, where an error flag is checked (during the delay between printed lines) where the status flag and keyboard is checked:

Code:

 # Printer done or key pressed ...
 6C4A 16119C GSUBNC 6758    # Get timer-value from reg 5 to A[S]
 6C4C 24C ST=1? 9           # Flag 9 clear?
 6C4D 009182 GOLNC 6002     # Yes, Sub A[X] from C[MSB] -> reg 6 and return
 6C4F 23D3E0 GSUBNC F88F    # ???????

Flag 9 is generally used in the code to indicate a printing problem - so if an error is detected - it jumps to .... "F88F" ... ?
Normally a "PRINT ERROR" is shown, but not in this case ...
My guess it that this is a forgotten "TBD" that never was fixed before launch of the module.

Any ideas or comment?

Best regards,
Thomas

[MeindertKuipers]

Hello all,

After some time of developing and debugging I am now happy to announce that I have HP-IL emulation up and running on my RP2040 Pico setup. I can succesfully do a READP from (simulated) mass storage and use the (simulated) HP-IL printer.

Many thanks to Christoph Giesselink (I have used the HP-IL part of the V41 sources, especially the HP-IL register handling, which I believe also originates in part from Jean Francois) and Jean-Francois Garnier (I had to dive in the PILBox sources and some of his ILPer sources, and his PILBox documentation helped a lot).
In my setup I am emulating the HP-IL module and the PILBox on the RP2040, and there is now a direct USB virtual serial port from the PICO hardware to the PC. PyILPer really thinks that there is a PILBox connected at a speed of 230400 baud.

This is all very much in development and on a breadboard, but I hope to do a hardware design at some time.

[Sylvain Cote]

Wow!

Thank you for creating this new piece of technology.

If I have understood correctly, the final product will do/support the following ...

The current setup:

Quote:HP-41C + 41/IL module + PIL-Box + USB cable + computer running emulated IL peripherals (ILPER, pyILPER, ...)

will be replaced by this one:

Quote:HP-41C + 41/USB Pico module + USB cable + computer running emulated IL peripherals (ILPER, pyILPER, ...)

All existing IL enabled modules will also works → Extended I/O, Plotter, IL-Development, HEPAX, RAMBox, etc.

All physical HP-41 will be compatible → 41C, 41CV, 41CX (in all variants: fullnut, halfnut, talkeys, etc) and 41CL (all versions).

Please correct any misunderstood features.

Sylvain

Note: from my understanding, this was a team effort, so also than you to: Thomas, Andrew, Christoph, Jean-François and the others that I am forgetting or do not know about.

Edit: add physical compatibility

[MeindertKuipers]

Quote:HP-41C + 41/USB module + USB cable + computer running emulated IL peripherals (ILPER, pyILPER, ...)
And all existing IL enabled modules will also works → Extended I/O, Plotter, IL-Development, HEPAX, RAMBox, etc.

This is more or less correct. So far I have only tested some basic HP-IL functions, more are to be tested.
And the module can do much more: IR printing, serial printing, emulating user and extended memory, potentially expanded memory. And of course it is a full fledged MLDL and/or HEPAX configuration (HEPAX is not tested yet). Dont't forget the HP41 bus tracer and HP-IL scope. A TIME module emulation is possible, but not done yet. And Thomas has implemented Blinky and the Wand.

Andrew was the initiator of this project, doing the first RP2040 hardware to interface with the HP41C. Thomas took this project much further and I went into another direction by using the PIO for the low-level HP41 interfacing. Christoph, Mike and Jean-Francois were a great help, partly directly in the project, and partly because of their excellent earlier work. And I had a very generous loan of the real Blinky module from someone else, that was instrumental in dissecting the internal workings of the IR module that Tomas did.

[Don Williams]

Please, please, pretty please. This project needs a "How to for Dummies" document so I can join. I will forever be thankful.

Signed
Dummy