HP-41 emulation?

[Klaus]

Who is currently building an emulation of the HP-41? (Nelson?)
If noone is, I will do that (or we can do it together).

Hardware:
As there are nice simulations written in C/Cpp, our microcontroller should be supported by a (free) C-Compiler.
LCD: I currently don´t have any experience with LCDs, but those with a built-in controller are easy to use (according to datasheets).

Which LCD and microcontroller can be used? On the PIC, the Interpreter takes about 3000 asm-instructions, plus 1000 asm-instructions for i/o, main loop and i2c communication.

Speed: On the PIC with 4mHz, the emulation of the hp-45 has about the same speed as the original hp-45 (I think it has 380 kHz). But since the LEDs are updated every main-loop cycle, a LCD should speed up things.

Pins: 8 for the keyboard and 8 for display plus a few for RS232/USB

Ram: ?

HP41-firmware in program memory or eeprom?

My plan is to take a simulation of the HP-41** (either nonpareil or the one from "TOS"), move the interpreter part to our microcontroller, add i/o and debug debug debug.

So any suggestions for the microcontroller or LCD?

[Vassilis Prevelakis]

Why not use the LCD display from the original (fullnut) 41.
Try to fit the emulator in the 41 case as well, so that at the
end of the day you have a replacement of the main HP41 PCB.

Since modern microcontrollers have much more extra memory
(and features) you can accommodate the entire memory map
of the 41 (main memory, extended memory, a bunch of ROMs etc) into the on-board memory.

By accommodating the original LCD, you will also be forced to
emulate the original HP-41 I/O bus, which means that your new design will be able to accommodate HP-41 peripherals (e.g the HP-IL interface), although a simple serial interface would be just fine with most HP-41 users.

Best Regards

**vp

[mark murphy]

Klaus,

I've just checked the HP Journal March 1980 P25-26 and cross checked with the Schematic by Reinhard Breuer - the LCD module in the calc sits on the bus and has the drivers bonded to the PCB - so, in effect, it already is an intelligent display and it already sits on the bus. I still suspect that there would be more than enough room to hold two PICs one handling the keyboard, LCD and USB - say the 16C745/765 or another USB driver like the FT2232. This would offload the polling time required for the Kbd/LCD/IO to effectively zero on the other 'mainframe' chip and hopefully deliver the required performance ?

[Vassilis Prevelakis]

mark murphy wrote:

> I've just checked the HP Journal March 1980 P25-26 and cross checked with the Schematic 

> by Reinhard Breuer - the LCD module in the calc sits on the bus and has the drivers bonded to the PCB

Oh, yes, the LCD is just another peripheral. Brilliant design: it reduces the lines that need to connect the main PCB with the front of the calulator (I/O assembly and display). The HP hardware designers of that era knew their shit.

> I still suspect that there would be more than enough room to hold two PICs

I don't understand the fascination with the PIC, why not use an FPGA with an ARM core. That will give you all the processing power you can possibly ask for.

Also somebody (sorry I forget who) did an FPGA implementation of an HP-41 ROM pack. This means thay they have an implementatoion of the 41 I/O bus.

**vp

[mark murphy]

Hi there - It was Meindert Kuipers at http://www.kuipers.to/hp41.htm who was working on the Xilinix project. The only reason for mentioning Pic was that Diego has arleady done the bus interfacing with the Pic based Clonix/NoVram project and Klaus has done the emulation with the IQSIM - seemed to me that some of the components/sw were already effectively in place. Most of us also have reasonable access to $30 Pic progammers etc versus Xilinx systems so it would keep things scalable and 'one off' costs down - perhaps something like the arm lpc2100 series would rock - do we have enough experience - Klaus? As for USB - I'll stick by that as being the most universal interface - as an aside, the camera you mention with Wifi is the Nikon D2H with the WT-1 Wireless Transmitter add-on, this ironically uses a USB2 connection between the main camera body and the WT-1 (see http://www.dpreview.com/reviews/nikond2h/ for more details). All the best Mark

[V-PN]

What batteries would buy daily in case of an FPGA design?

A dozen Lithium camera batteries?

'VPN'

[Meindert Kuipers]

I did an FPGA implementation of the HP41 interfacing (and a lot more!), this is all CPLD based because of power consumption. If you use an FPGA based ARM implementation than your battery life will be very short. This is also a problem with the PIC implementation. As long as it is used as a peripheral (Module emulator) it is OK, because most of the time the module is in a low power mode.

Meindert

[Klaus]

Hello!

I only have experience with PICs, but I am curious to try new things. I also have very little experience with hardware design.
The thing I went for the PICs is that they are widely available (a standard supplier offers nearly all PICs an a few atmels).
Would it help our microcontroller-choice if I wrote the C-code first?

Klaus