NP-41 Emulator (may be)
01-10-2018, 11:31 PM
Post: #361
 Guenter Schink Member Posts: 282 Joined: Dec 2013
RE: NP-41 Emulator (may be)
(01-10-2018 01:53 PM)Chris Chung Wrote:  +Guenter, +Egan,

The two 2nd batch units are running good and I have confident that they will behave well once the bootloader issue can be resolved. Still I will compare them with new PCBs when they come in.

I will update you w/ our options when I get a solution to the memory corruption issue, which shouldn't take long. (or at least have a good work around on it).

Thanks for the update. As said before, take your time, no need to rush.

Günter
01-10-2018, 11:36 PM
Post: #362
 everettr Junior Member Posts: 48 Joined: Dec 2013
RE: NP-41 Emulator (may be)
Have you considered a capacitor across the battery as a low-pass filter?
01-11-2018, 07:41 AM
Post: #363
 Massimo Gnerucci Senior Member Posts: 1,437 Joined: Dec 2013
RE: NP-41 Emulator (may be)
I seem to have issues only when I load ROMs: I can usually list one ROM's content fine via CATALOG, but functions, if invoked, aren't executed or, if I load more than one ROM, I can see gibberish interspersed in CATALOG listing.

I need experimenting more.

Greetings,
Massimo

-+×÷ ↔ left is right and right is wrong
01-11-2018, 03:38 PM
Post: #364
 Chris Chung Member Posts: 214 Joined: Aug 2014
RE: NP-41 Emulator (may be)
(01-10-2018 11:31 PM)Guenter Schink Wrote:  Thanks for the update. As said before, take your time, no need to rush.
Günter

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

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. After reading / researching on the topic, I am more inclined to think that ground planes are more important as the unit operates on battery only, and I will find out when the new PCBs arrives. I read that w/ increase MCU activity (and speed), the rapid switching on the traces will cause interference, and we do have that happening on key scanning and LCD multiplexing.

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.

The H/W problem is mainly due to workmanship and quality / design of PCB, I think. Both are improving and longer burn-on tests should help.

(01-11-2018 07:41 AM)Massimo Gnerucci Wrote:  I seem to have issues only when I load ROMs: I can usually list one ROM's content fine via CATALOG, but functions, if invoked, aren't executed or, if I load more than one ROM, I can see gibberish interspersed in CATALOG listing.

I need experimenting more.
Yes, this is known to me. And I will spend time to work on it. I don't really quite understand the underlying mechanism other than what I learnt from Eric's code. Will ask the forums help when doing that. The TONE command also does not produce proper frequency, etc. There are many improvements to be made.

Also the next firmware I had added an option to fix the display update logic. Currently I skip some display update calls to save time. There is a lot of segment mapping calculation in the emulator when display need to be updated. I guess in original HP-41C it is partially done in H/W logic so it is fast. The new firmware will allow for full display update and the unit will run slower. But when you do CAT 0,1,2 you will be able to catch the names properly w/o sometimes some names appear on the right.

Please do more experimenting. Just beware of the battery replacing issue. Also let me know what kind of improvements is needed.

In your last few messages, you mentioned some memory problem / finding. I don't understand them but I like to learn (after we fixed the bootloader issue) and work on them. I am really not familiar w/ the HP-41C and only start to write small / simple programs with it.
01-11-2018, 06:41 PM (This post was last modified: 01-11-2018 06:42 PM by everettr.)
Post: #365
 everettr Junior Member Posts: 48 Joined: Dec 2013
RE: NP-41 Emulator (may be)
(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.
01-18-2018, 04:17 PM
Post: #366
 Chris Chung Member Posts: 214 Joined: Aug 2014
RE: NP-41 Emulator (may be)
(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:
• 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.
01-18-2018, 06:44 PM
Post: #367
 Massimo Gnerucci Senior Member Posts: 1,437 Joined: Dec 2013
RE: NP-41 Emulator (may be)
Thanks for the update, I'll try to load it ASAP.
And thank you for your exchange offer: that's true commitment.

Greetings,
Massimo

-+×÷ ↔ left is right and right is wrong
01-18-2018, 07:08 PM
Post: #368
 Massimo Gnerucci Senior Member Posts: 1,437 Joined: Dec 2013
RE: NP-41 Emulator (may be)
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.

Greetings,
Massimo

-+×÷ ↔ left is right and right is wrong
01-19-2018, 03:03 AM
Post: #369
 Mark Hardman Senior Member Posts: 454 Joined: Dec 2013
RE: NP-41 Emulator (may be)
(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

Ceci n'est pas une signature.
01-19-2018, 01:20 PM
Post: #370
 Chris Chung Member Posts: 214 Joined: Aug 2014
RE: NP-41 Emulator (may be)
(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.
01-20-2018, 06:34 AM
Post: #371
 hth Member Posts: 203 Joined: Mar 2014
RE: NP-41 Emulator (may be)
(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
01-25-2018, 02:52 PM
Post: #372
 Alejandro Paz(Germany) Member Posts: 109 Joined: Mar 2016
RE: NP-41 Emulator (may be)
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"     --   --     --  |  |      --  |  |       --      -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
01-25-2018, 03:19 PM (This post was last modified: 01-25-2018 03:25 PM by emece67.)
Post: #373
 emece67 Senior Member Posts: 338 Joined: Feb 2015
RE: NP-41 Emulator (may be)
(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.

César - Information must flow.
01-25-2018, 05:05 PM
Post: #374
 Alejandro Paz(Germany) Member Posts: 109 Joined: Mar 2016
RE: NP-41 Emulator (may be)
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.
01-29-2018, 02:30 PM
Post: #375
 Chris Chung Member Posts: 214 Joined: Aug 2014
RE: NP-41 Emulator (may be)
@Alejandro, emece67

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.

Attached File(s) Thumbnail(s)

02-15-2018, 06:15 AM (This post was last modified: 02-15-2018 11:50 AM by Alejandro Paz(Germany).)
Post: #376
 Alejandro Paz(Germany) Member Posts: 109 Joined: Mar 2016
RE: NP-41 Emulator (may be)
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
 « Next Oldest | Next Newest »

User(s) browsing this thread: 2 Guest(s)