NP-41 Emulator (may be)

[everettr]

(01-10-2018 11:36 PM)everettr Wrote:  Have you considered a capacitor across the battery as a low-pass filter?

Quote:On the PCB, I had 4 pads that I can place low-pass filters, currently I only placed one 100nF. I had been experimenting w/ placing all 4 caps, also w/ some higher values. They really don't make a difference in my testing.....

Examining the evidence, it is appearing that the bootloader induced memory corruption problem is the main concern. I had very reliably brick a unit just by jiggling the battery on its housing.

Hi Chris,
Thanks for the reply. I was unclear. I was just thinking more of something to basically "debounce" the battery, like a 10 microFarad capacitor. If the circuit can't see the intermittents from battery jiggle, then maybe you avoid the bootloaderish memory corruption, and life is okay.

[Chris Chung]

(01-11-2018 06:41 PM)everettr Wrote:  Thanks for the reply. I was unclear. I was just thinking more of something to basically "debounce" the battery, like a 10 microFarad capacitor. If the circuit can't see the intermittents from battery jiggle, then maybe you avoid the bootloaderish memory corruption, and life is okay.

That's a good idea, I will look into it.

I had finally found the problem w/ the bootloader corrupting FRAM space. It turned out that I had a few variables and they were allocated via the stack. Although I had setup the stack pointer to RAM area during initialization, accessing these variables sometimes corrupts memory (that is when the "reset" vector got tripped in succession in a short time, i.e. jiggling the battery). I don't understand why except its a timing problem but I am able to fix it by not using the stack for my variables. I had changed and now use absolute RAM locations from my bootloader variables and avoided the memory corruption issue.

In order to fix the shipped units, the bootloader has to be updated. I had created a new firmware image which will facilitate this. The steps are as follows:

• Download np41_180118.bin from here.
• Turn off unit via [ON] key.
• Attach USB-serial dongle. You may connect only Rx,Tx and Gnd as unit is already powered by a CR2032.
• Connect to PC.
• Turn [ON] the unit while holding the [SST] key. You will see "V00x ..." displayed. Before this message vanishes (in 3 seconds), press and hold the [USER] key, this will place unit into bootloader mode. LCD should become blank.
• Start TeraTerm and select correct serial port. Baud rate is 9600N81.
• Press any key and you should be greeted by a '?' character.
• Press '@' key and you should be greeted by an additional '>' character. Unit is ready to received np41_xxxxxx.bin firmware update.
• Select "File" -> "Send File.." from TeraTerm top menu bar.
• I would check the "binary" box 1st (lower left on the dialog pane).
• Select directory ("look in" field) and the correct file (np41_xxxxxx.bin) and hit "OPEN" button
• Transfer will start, wait for it to finish and give it another 1 or 2 seconds and remove unit from PC. Detach USB dongle.
• Now the firmware is updated, pressing [ON]-[ON] combo or [ON]-[<-] combo will bring back the emulation.
• We need to, however, update the bootloader as it causes the memory corruption problem.
• This is done by doing a new key-hold combo. Turn off unit and turn [ON] again while holding the 'B' [1/X] key (B for bootloader), this will copy a new copy of bootloader from the new firmware to the original bootloader location. You can do this a few times if you want to make sure. You can also enter bootloader mode again just to check. The prompt will be changed from "?>" to "BOOT?>".
  

Apart from the bootloader fix, a new key combo (warm start) w/ [ON]-'D' toggles the display mode between "fast" and "true".

If your unit is operating OK for now, you don't need to change the firmware / bootloader. There is not yet major feature updates. And if it fails in the future, you can send it back for fixing.
If you do not have the dongle or means to perform the firmware update, I can do it for you via mailing back the unit free.
If you perform the update and fails it, you can send the unit back and I will fix it for you free.

And when you want to send back your unit for fixing / repairing, I would prefer to wait until my new batch of PCB arrived and I have them tried out 1st. A
nd I want to migrate your units to the new and supposedly better PCB design.

If everything works OK for you, I can still migrate your unit to better PCBs later on for free. It is better for for me to fix all the problems and have a more stable platform before doing this.

[Massimo Gnerucci]

Thanks for the update, I'll try to load it ASAP.
And thank you for your exchange offer: that's true commitment.

[Massimo Gnerucci]

Updated, all went well.
New catalog speed (after ON-D) shows now readable labels.

One thing to note: when I turn off the unit in PRGM mode, and I turn it on again it still is in PRGM mode; if I interrupt a CATALOG by turning the calc off, when I turn it on it picks up cataloging from where it left.

This is different than the real 41: it seems that pressing ON it simply interrupts whatever is doing and turns off display.
Even when running a program, pressing ON the calc goes off, pressing ON again the program continues with the goose running.

[Mark Hardman]

(01-18-2018 04:17 PM)Chris Chung Wrote:  And when you want to send back your unit for fixing / repairing, I would prefer to wait until my new batch of PCB arrived and I have them tried out 1st. And I want to migrate your units to the new and supposedly better PCB design.

If everything works OK for you, I can still migrate your unit to better PCBs later on for free. It is better for for me to fix all the problems and have a more stable platform before doing this.

Chris,

Thank you for the latest update. Just so you know, I would prefer to send my beta version of the board back to be migrated to the better PCB when they become available.

Warmest regards,

Mark Hardman

[Chris Chung]

(01-18-2018 07:08 PM)Massimo Gnerucci Wrote:  Updated, all went well.
New catalog speed (after ON-D) shows now readable labels.

One thing to note: when I turn off the unit in PRGM mode, and I turn it on again it still is in PRGM mode; if I interrupt a CATALOG by turning the calc off, when I turn it on it picks up cataloging from where it left.

This is different than the real 41: it seems that pressing ON it simply interrupts whatever is doing and turns off display.
Even when running a program, pressing ON the calc goes off, pressing ON again the program continues with the goose running.

My implementation is just put everything in sleep, so the unit wakes up where it left off. And all the registers are maintained in FRAM / non-volatile memory, so there is no change in the emulator status.

I will need to know how the real 41 behave in order to emulate it truthfully. Do you think forcing a [CLX] key or clearing some register values (of the 16 status registers) will do? Open to suggestions.

(01-19-2018 03:03 AM)Mark Hardman Wrote:  Chris,

Thank you for the latest update. Just so you know, I would prefer to send my beta version of the board back to be migrated to the better PCB when they become available.

Warmest regards,

Mark Hardman

I am hopeful the new PCB design will resolve the H/W intermittent problems.

[hth]

(01-19-2018 01:20 PM)Chris Chung Wrote:  I will need to know how the real 41 behave in order to emulate it truthfully. Do you think forcing a [CLX] key or clearing some register values (of the 16 status registers) will do? Open to suggestions.

The HP-41 wakes up by executing location 0000. The carry flag status says whether it was on or off (coming from light or deep sleep). Whether the calculator is on or off is decided by the LCD being on or off.

The 10 minute auto-off or stay-on logic (non-programmable "ON" instruction) is determined by whether the LCD is enabled or disabled when the HP-41 is in light sleep (LCD is on in light sleep).

If you emulate the above, the HP-41 mainframe (firmware) will take care of the rest.

Håkan

[Alejandro Paz(Germany)]

I wrote a Fullnut core in VHDL, it seems to be working. It needs around 3000 LUTs on a Cyclone IV (and like 4000 on the MAchXO2) with 128 56 bit registers. Now I'm writing a LCD driver. I think I figured out how the display is connected, here an extract from the source, comment area.

Code:


    -- LCD driver
    -- Target LCD is a 6 common 12 digit 14 segment LCD
    -- Each common is a group of 6 segments, each digit is divided in 3 groups actuated by consecutive commons
    --
    --                          common  0        common  1         common  2
    --     ---------                             ---------                  
    --    |\   |   /|          |\                 0  |   /                  |
    --    | \  |  / |        0 | \ 1                1|  / 2               1 |
    --    |  \ | /  |  o       |  \                  | /                    |  o 0
    --     ---- ----            ---- 2                ---- 3                
    --    |  / | \  |          |  /                  | \                    |
    --    | /  |  \ |        3 | / 4               5 |  \ 4               2 |
    --    |/   |   \|  o       |/   5                |   \                  |  o 3
    --     ---------   ,        ---------                                      , 4
    --                                                             5
    --    Ann0 Ann1 Ann2                                          Ann0           
    --
    -- The segments are biased with 47 k resistors to VCC and GND and the segments
    -- Waveform
    --
    -- Segment 0
    --      --                                  --
    --     |  |__ __ __ __ __ __ __ __ __ __   |  |__ 
    --     |                                |  |   
    --   --                                  --      
    --  +  0  +  1  +  2  +  3  +  4  +  5  +  0  +    
    -- Segment 1
    --            --                                  --
    --   __ __   |  |__ __ __ __ __ __ __ __ __ __   |  |__
    --        |  |                                |  |
    --         --                                  --                     
    --   +    +     +     +     +     +     +     +     +
    -- Common for "on"
    --   --
    --  |  | 
    --  |  |  
    --      -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

[emece67]

(01-25-2018 02:52 PM)Alejandro Paz(Germany) Wrote:  I wrote a Fullnut core in VHDL, it seems to be working. It needs around 3000 LUTs on a Cyclone IV (and like 4000 on the MAchXO2) with 128 56 bit registers. Now I'm writing a LCD driver. I think I figured out how the display is connected, here an extract from the source, comment area.

I'm not the only one reinventing the wheel here ;-)

In any case, it seems that your code is muuuuch more advanced than mine. Incidentally, I'm also using a Lattice MachXO2 device.

Regards.

[Alejandro Paz(Germany)]

Quote:I'm not the only one reinventing the wheel here ;-)

There (seems) to be a japanese proverb that says: "If someone did something, I can do it too", and "If nobody did something, I should be the first one". .

I'll post my code, once the display works on my github page (github.com/raps500). Feel free to ask if you want.

[Chris Chung]

@Alejandro, emece67

Excited to learn about your progress(es).

My bad, the pinout for the LCD is have been posted.

A PDF of the pinout is (HF-3463.pdf) available in the shared drive.

@hth

Thanks for your pointer, I did more digging on available resource and had implemented the warm-start accordingly. The LCD on 10 minute timeout I may not implement as it drains battery, I may fake it though. Will collectively include this in the next firmware release.

I still have not yet receive the redesigned boards. they made them in 4 days and left Hongkong in 5 days but not yet trackable in Canada. I should have use a courier, and I always avoid them because they always add custom clearing surcharges, etc. I will keep you all posted.

[Alejandro Paz(Germany)]

I posted the code. Because the 14 segments display seems to be a bit more difficult to drive than I thought, I knocked out a dot matrix driver for the DOGM132 display. The whole project is more a proof of concept than anything else.There are some missing bits like keyboard scan, the display ignores annunciators and punctuation symbols. I'm sure that there are a couple opcodes that are wrong, I have to do some more debug.
The code and a pair of pictures of the prototype are here:

FullNut on Github

[sc05027]

Hi Chris,

I hope it is not too late. I would like to get a set of NP-41. If it is avaliable, please let me know.

Stephen

[Chris Chung]

(03-05-2018 07:35 AM)sc05027 Wrote:  I hope it is not too late. I would like to get a set of NP-41. If it is avaliable, please let me know.

The sale is closed for now, until I can find a way to ensure reliability.


Time for another update.

I had sent out some replacement units. They are not the latest PCB. They are instead the batch 2 PCBs and a repaired batch 1 PCB (v3). The v4 boards had been running for 6+ weeks and they are the most reliable units I have.

There were setbacks on the newer PCBs. I had received the v5 boards 5 weeks ago and the adjustments I made to the LCD through hole size were wrong, and the boards are of wrong color. I had to abandon them and correct / re-order another set, which took 2 weeks to arrive this time.

These new boards had extensive ground planes and I had assembled 3 boards, of which 2 failed after a few days. I tried to re-work them and they are not reliable. The same issue as previous failed boards and this is an intermittent problem. Everything works fine for a day, put it to sleep and it reboots itself, consumes 10+mA and keys acts up. They are worse than the batch 2 (v4) boards and they are not to be used.

I am starting a new board design w/ a different layout software. Fine and more detail traces will be tried.

Also put up the latest firmware on the share drive

180118:
. new bootloader, no more firmware corruption during battery sway
. [ON] + [D] toggles true and fast LCD display update, do 'CAT' to see the difference
**** perform [ON] + [B] to relocate new bootloader to appropriate memory space

180308:
. fix multiple ROM loading issue, where 2nd ROM onward fails.

* for the ROM loading fix, if you do not want to update firmware, there is also a workaround to load multiple ROMs. That is, you need to load one ROM, reboot the unit, re-connect serial and load the next one. This way multiple ROMs can be loaded w/ pre 180308 firmware.

** if you have the original unit and have never update the firmware, you MUST upgrade 1st to 180118 before upgrading to 180308. This is because we need the new bootloader to subsequent firmware updates.

[rprosperi]

(03-08-2018 12:52 PM)Chris Chung Wrote:  Time for another update....

Also put up the latest firmware on the share drive

Thanks for the update Chris, your perseverance is impressive and I'm sure it will pay off!

It seems the link is bad, maybe there's a typo in the url?

[Massimo Gnerucci]

(03-08-2018 12:52 PM)Chris Chung Wrote:  Also put up the latest firmware on the share drive

180118:
. new bootloader, no more firmware corruption during battery sway
. [ON] + [D] toggles true and fast LCD display update, do 'CAT' to see the difference
**** perform [ON] + [B] to relocate new bootloader to appropriate memory space

180308:
. fix multiple ROM loading issue, where 2nd ROM onward fails.

* for the ROM loading fix, if you do not want to update firmware, there is also a workaround to load multiple ROMs. That is, you need to load one ROM, reboot the unit, re-connect serial and load the next one. This way multiple ROMs can be loaded w/ pre 180308 firmware.

** if you have the original unit and have never update the firmware, you MUST upgrade 1st to 180118 before upgrading to 180308. This is because we need the new bootloader to subsequent firmware updates.

Thanks Chris!

I will try both the 180118 trick and then the new firmware.
The ROM loading issue was what troubled me most.

No free evening these days! Much fun...

[Massimo Gnerucci]

(03-08-2018 01:43 PM)rprosperi Wrote:  

(03-08-2018 12:52 PM)Chris Chung Wrote:  Time for another update....

Also put up the latest firmware on the share drive

Thanks for the update Chris, your perseverance is impressive and I'm sure it will pay off!

It seems the link is bad, maybe there's a typo in the url?

Bob, this is the correct link.

[Chris Chung]

(03-08-2018 02:18 PM)Massimo Gnerucci Wrote:  I will try both the 180118 trick and then the new firmware.
The ROM loading issue was what troubled me most.

No free evening these days! Much fun...

Massimo, I thought you already flash the 180118 firmware, if so, you could just use the workaround (load one ROM at a time) w/o upgrading to 180308. Even as the developer, I always got chills trying to flash firmwares (scare of bricking it).

(03-08-2018 02:21 PM)Massimo Gnerucci Wrote:  

(03-08-2018 01:43 PM)rprosperi Wrote:  Thanks for the update Chris, your perseverance is impressive and I'm sure it will pay off!

It seems the link is bad, maybe there's a typo in the url?

Bob, this is the correct link.

Thanks for the correction.
I hope I will be making progress w/ the PCB.
I wish success and good progress on Alejandro Paz project.

[Massimo Gnerucci]

(03-08-2018 04:34 PM)Chris Chung Wrote:  

(03-08-2018 02:18 PM)Massimo Gnerucci Wrote:  I will try both the 180118 trick and then the new firmware.
The ROM loading issue was what troubled me most.

No free evening these days! Much fun...

Massimo, I thought you already flash the 180118 firmware, if so, you could just use the workaround (load one ROM at a time) w/o upgrading to 180308. Even as the developer, I always got chills trying to flash firmwares (scare of bricking it).

Yes, I did. Alas, no time this evening: had to start setting up the new phone...
But soon I'll have a whole weekend for me! :)

(03-08-2018 04:34 PM)Chris Chung Wrote:  I hope I will be making progress w/ the PCB.

We all wish you luck, Chris. Once you reach a definitive design I will buy another unit.

[Massimo Gnerucci]

Alas Chris, I think I finally bricked it.
This morning I started upgrading a DM42, then a 39GS with newRPL and, finally my NP-41. The first two went well, but not the third.

Well, too many different procedures to follow for an aged brain, it seems...

After connecting the unit to the PC via USB and Teraterm I uploaded the new firmware (or I think I did), now all I have on the display is "NP41 =2432" no matter what key combination I try.

Let me know, please, if there's something I can try, otherwise I'll wait for a new board revision and order it, if/when available.

Keep up the good work!