NP-41 Emulator (may be)

[rprosperi]

(12-17-2015 09:45 PM)Chris Chung Wrote:  Okay, one question for HP-41C owners.

I tried the NQueen problem. It took me 15 minutes on the current NP-41.

The result is 876.0. Can anyone confirm this is correct?

I got the program somewhere in this forum.

I entered the 41 code on that page in a stock 41CX and also got 876. Unfortunately, did not time it (had to answer the door).

[Chris Chung]

(12-17-2015 11:40 PM)rprosperi Wrote:  

(12-17-2015 09:45 PM)Chris Chung Wrote:  Okay, one question for HP-41C owners.

I tried the NQueen problem. It took me 15 minutes on the current NP-41.

The result is 876.0. Can anyone confirm this is correct?

I got the program somewhere in this forum.

I entered the 41 code on that page in a stock 41CX and also got 876. Unfortunately, did not time it (had to answer the door).

Thanks Rob, I was just trying to run a longer program as sanity check to my code. Came across this NQueen benchmark and also want to discover the speed. Looks in par w/ the original, so I am happy.

[Sylvain Cote]

(12-17-2015 09:45 PM)Chris Chung Wrote:  Okay, one question for HP-41C owners.

I tried the NQueen problem. It took me 15 minutes on the current NP-41.

The result is 876.0. Can anyone confirm this is correct?

I got the program somewhere in this forum.

time calculated with the stopwatch

HP-41CX-HN -> result: 876 -> time: 18m 9s
41CL TURBO50 -> result: 876 -> time: 1m 5s

Sylvain

[rprosperi]

(12-18-2015 01:41 AM)Sylvain Cote Wrote:  time calculated with the stopwatch

HP-41CX-HN -> result: 876 -> time: 18m 9s
41CL TURBO50 -> result: 876 -> time: 1m 5s

Sylvain

I just love Turbo mode!

I haven't been able to say that since the 80's!

[Sylvain Cote]

(12-18-2015 04:11 AM)rprosperi Wrote:  I just love Turbo mode!
I haven't been able to say that since the 80's!

LOL

IBM-PC XT or AT -> 4.77 MHz at normal speed and 8MHz at turbo speed.
You normally ran it a 8 MHz except for games that needed the 4.77 MHz to run correctly.

More in context with this thread, I had installed two capacitors selected by a magnetic switch in the 41 toggling between normal and turbo speed.

[Chris Chung]

(12-18-2015 04:44 AM)Sylvain Cote Wrote:  IBM-PC XT or AT -> 4.77 MHz at normal speed and 8MHz at turbo speed.
You normally ran it a 8 MHz except for games that needed the 4.77 MHz to run correctly.

More in context with this thread, I had installed two capacitors selected by a magnetic switch in the 41 toggling between normal and turbo speed.

You mean the 41CL make turbo via hardware? Or the switch just "instruct" the firmware to go turbo.

BTW. Turbo Pascal is my preferred language on PC.

[EdS2]

(12-17-2015 09:38 PM)Chris Chung Wrote:  Using a PI would be very different, as it would run on top a OS. It may not the the instant-on instant-off attribute of a direct MCU build

Just to note for future reference, it's possible to program the Pi at bare metal level. The boot time is of the order of a second, I think - not quite instant.

[Sylvain Cote]

(12-18-2015 12:44 PM)Chris Chung Wrote:  You mean the 41CL make turbo via hardware? Or the switch just "instruct" the firmware to go turbo.

The 41CL board is a complete reimplementation (using CPLD & FPGA) of the original 41 board.
The 41CL run the firmware at the original speed by default, but can also run it at several speed up to 50 times.
All the speed changes are controlled in software by specific 41CL functions in one of its ROMs.
You can read the 41CL user manual HERE
Sylvain

[rprosperi]

(12-18-2015 04:44 AM)Sylvain Cote Wrote:  IBM-PC XT or AT -> 4.77 MHz at normal speed and 8MHz at turbo speed.
You normally ran it a 8 MHz except for games that needed the 4.77 MHz to run correctly.

Exactly what my machine did! I loved that machine, wish I still had it today.

On some clones, one also had to go "down" to non-turbo to use modems, as in some BIOS, the serial com depended on empty code loops, assumed to be at 4.77 MHz (initially, I typed GHz... then realized just how slow these were!).

[Chris Chung]

(12-18-2015 01:40 PM)EdS2 Wrote:  

(12-17-2015 09:38 PM)Chris Chung Wrote:  Using a PI would be very different, as it would run on top a OS. It may not the the instant-on instant-off attribute of a direct MCU build

Just to note for future reference, it's possible to program the Pi at bare metal level. The boot time is of the order of a second, I think - not quite instant.

Yes, I mistaken for the Pi 2, the Pi zero would be ideal for such application. Are they only available in UK? What about the BBC free computer, did that come out yet? That's also a good platform to build things on.

[sa-penguin]

(12-18-2015 02:01 PM)Sylvain Cote Wrote:  The 41CL board is a complete reimplementation (using CPLD & FPGA) of the original 41 board.

You can read the 41CL user manual HERE
Sylvain

I had given up on the 41CL, as it requires a 41 be sacrificed for the keypad and display.
Now you've got me contemplating one with a custom keypad and display, as seen here.

Of course, the code would need to be modified, to handle the new display...

[anetzer]

(12-17-2015 10:36 PM)smp Wrote:  I want one of these now.

Please keep up your effort.

+1!

[Chris Chung]

(12-19-2015 02:39 AM)sa-penguin Wrote:  

(12-18-2015 02:01 PM)Sylvain Cote Wrote:  The 41CL board is a complete reimplementation (using CPLD & FPGA) of the original 41 board.

You can read the 41CL user manual HERE
Sylvain

I had given up on the 41CL, as it requires a 41 be sacrificed for the keypad and display.
Now you've got me contemplating one with a custom keypad and display, as seen here.

Of course, the code would need to be modified, to handle the new display...

After googling up the 41CL and reading briefly on the manuals. I don't think my little project will match up w/ it. But if you are like me, want something basic to play with, this could be a good platform. The Plan B design should be relatively easy to build, firmware will be open sourced, thanks for Eric's original work. The development environment won't cost much either, I used a $15 TI launchpad as a programmer and use gcc compiler.

[Chris Chung]

(12-20-2015 12:59 AM)Geir Isene Wrote:  But... the other way around - take a 41CL board and build your LCD and keyboard and a good metal casing around it - and we may have a killer?

Building a IO / peripheral system that match HP-41C quality in a small scale is no small task. I suspect that's also the reason the 41CL was created as a "brain transplant" project, just to avoid the difficult mechanical component and also the nowhere to be found LCD display.
The only benefit this NP41 project can bring to 41CL would be the 14 segment display. To make it into a donor replacement will take a lot of understanding on the HP-41C? bus and signals. I am less interested in working in this area.
The custom LCD might be of interested to other developers, we can initiate a batch order (300 units) w/ Waon if there are enough interest. As a matter of fact, I am contemplating to use it on other projects.

[hth]

I totally love this display, fantastic!

I am not really looking for a HP41 clone, it takes so much effort in keyboard and connectivity to be useful, and I already have acquired enough HP41s to last me for the rest of my life.

This display would be very useful as an add-on to my BeagleBoneBlacks. I plan to use them in various embedded projects, some HP-41 related. Then just attach some kind of keyboard and I am ready to go!

I am no hardware person, but the MCU on the BBB seems to have various ways to connect displays, so hopefully it will not be a tricky project to interface to it.

To round off, I want to buy about half a dozen of such LCDs.

[Chris Chung]

(12-21-2015 04:34 AM)hth Wrote:  I totally love this display, fantastic!

I am not really looking for a HP41 clone, it takes so much effort in keyboard and connectivity to be useful, and I already have acquired enough HP41s to last me for the rest of my life.

This display would be very useful as an add-on to my BeagleBoneBlacks. I plan to use them in various embedded projects, some HP-41 related. Then just attach some kind of keyboard and I am ready to go!

I am no hardware person, but the MCU on the BBB seems to have various ways to connect displays, so hopefully it will not be a tricky project to interface to it.

To round off, I want to buy about half a dozen of such LCDs.

It will take more than a BBB to drive this display. There are 216 segments and w/ 6Mux you will need 42 pins. You will need a dedicated LCD controller to talk to it, while the BBB can talk to the controller via I2C. But it will definitely make into unique projects.

[quantalume]

(08-17-2015 02:58 PM)Chris Chung Wrote:  I had found the perfect MCU for a nonpareil HP-41C emulation.

The TI MSP430FR6989
. 128K FRAM (non-volatile memory)
. 2K static RAM
. Direct LCD segment driver

Hi Chris, I wonder if you could say a few things in general terms about how you adapted nonpareil to make use of your I/O hardware. The source tarball compiles to a GTK application, but I intend to interface to a physical keyboard and display over GPIO pins. Do I need to rewrite display.c and keyboard.c? Is there a command line interface to nonpareil? Thanks.

[Chris Chung]

(12-27-2015 12:16 AM)quantalume Wrote:  

(08-17-2015 02:58 PM)Chris Chung Wrote:  I had found the perfect MCU for a nonpareil HP-41C emulation.

The TI MSP430FR6989
. 128K FRAM (non-volatile memory)
. 2K static RAM
. Direct LCD segment driver

Hi Chris, I wonder if you could say a few things in general terms about how you adapted nonpareil to make use of your I/O hardware. The source tarball compiles to a GTK application, but I intend to interface to a physical keyboard and display over GPIO pins. Do I need to rewrite display.c and keyboard.c? Is there a command line interface to nonpareil? Thanks.

Sorry for late reply, holiday hours.
Nonpareil source code is arranged very nicely and the IO is isolated clean so adopting physical H/W (to replace GTK as IO) is quite straightforward.

Since I am not trying to physically emulate all processors with the same H/W, I just use a particular core for each project for starting. Say for NP25 I use proc_woodstock.c, for NP41 I use proc_nut.c and coconut_lcd.c

I would have a main program that talks w/ my H/W and as the control loop.
The main loop in this firmware (my project targets at MSP430, you may be targeting AVRs, PICs, ARMs etc) would be just continues scanning of the H/W keyboard and event trigger the processor core. This main program only need to interface w/ the processor core via 3 or 4 functions. An example for what it does.

Initialized H/W, calls nut_new_processor(), nut_set_ext_flag(...). This initialized the processing and emulates certain flags to get the processor ready.

Then the main program enters an indefinite loop, where it alternate between two jobs, (1) provide H/W scanning of the keyboard, and (2) in a timed manner, call nut_execute_instruction().

For (2), nut_execute_intruction() will allow the processor core to execute one instruction, whether there are key pressed or not, it is always executed in a timely basis.

For (1), upon keypress, we call nut_press_key(..) and upon key release, we call nut_release_key(..), in turn the processor core will update it's internal registers to reflect the changes, and upon the next nut_execute_intruction(), the proper processing will be done. It is important for the H/W to register the key press and key release events separately as the calculators has specific functions while key pressed but not released (like showing instruction name).

We do need to intercept the "ON" key separately where we may need set some register flags(?) and go on to do sleep functions w/ the target H/W. Most MCUs has various sleep modes where we can retain RAM memory at very low power.

So the above take cares of input. For the output, I intercepts cocunut_display_update() and inject my code to drive LCD outputs.

These would be the generate approach I am using. And of course there are other little details to take care of, mainly the allocation of memory varies quite a bit between different MCU platforms. So instead of using malloc(), smaller MCU might require you to use point to an address or use static array to reduce overhead.

Also my approach is a "forward migration", where I would replace many parameters w/ fixed values. I.e. nonpareil has this KML configuration system so many parameters are loaded from KML files at startup, I would just use constant values on the NP projects.

* there are also additional things I did to make the firmware compact enough to fit my H/W, which you should not need to do if you are using ARM based MCUs

I had re-organized the ROM content to save bytes (I.e. store instructions as 8+2 bits instead of 16 bits).
I reworked the registers to be 14 nibbles instead of 14 bytes, this saves a lot of program memory. This involves quite a bit of work as I need to modify a number of the instruction operator functions in proc_nut.c

You can study the NP25 source code to understand the structure. The source is quite messy as it can be built into Linux run, MSP430 run via UART and MSP430 run on NP25 hardware.

I am not really to upload the NP41 code yet. This will happen later when it's more stable.

[quantalume]

Chris, thanks for the very detailed reply! I didn't know you had uploaded the NP25 code. It looks like you put everything you needed from nonpareil in np25.h. I might do things a little differently, but having your code to study will make everything much easier. I will be using an ARM11 with 512 MB RAM, so I will have a lot of liberties that you didn't have on the MSP430. Thanks again for taking the time to explain what you did. I'm sure it will be an inspiration for other projects going forward.

[Chris Chung]

Progress Update

This time it is the "slim" version as I call it. The PCB came more than a month ago and I managed break the COG glass. Had to wait for another order of the DOGM equivalent LCD modules. They arrived a week ago and I had assembled one "slim" unit.

       

The front and back of the assembled PCB. I had restricted the length of the PCB to 100mm to reduce cost (at least for the prototypes) I am planning to lengthen it to 120mm so the buttons will spread out a bit and it will be more usable.

   

I also trial fit 3d buttons and a front panel. After several trials the result is quite nice. And I had confidence to make this into an everyday shirt pocket calculator. Next step is to extend the front panel to cover the LCD module (w/ a rectangular cutout, of course) and to print a back panel.

Will also have to workout the overlay / function template, etc.

   

This unit consumes 2.5mA on a CR2032 button cell active. I measure between 2.48 to 2.52mA under constant usage. There is still something wrong w/ the sleep as I envisage it to be sub-uA if not even lower (spec says 0.1 uA on RAM retention sleep). So there is more firmware work to be done.

I also experiment w/ two startup mode where one would show 3 of the stack registers, just to play w/ the possibility w/ having a graphic display.

   

You will see that this unit is head-bulky, as I am using pin sockets for the LCD module. The most expensive part in this build is the LCD so I am saving it for the final design. Just image that the finished unit will be lowered (1/2 thick) and should more or less flushed after applying the 3d printed button panel.

I really want to get rid of the LCD backlight to make it even slimmer. But my supplier only have ones w/ backlight. If I order from North America supplier, it will be $30 bucks instead of $12. So I guess I will settle for backlight for now.

Here is a video that will show the design better. Performance is similar to an original HP-41C/V. It has potential to double the speed by running at 16Mhz vs 8Mhz, but that I need to throw in 2 x 3V coin cell and have a regulator. Not sure If I want to do that.