NP-41 Emulator (may be)

[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.