Would the HP-15C Limited Edition Firmware Age Away?

[rprosperi]

(03-18-2018 08:55 PM)Greg Wrote:  Sorry Bob. It's not a NY thing. It is an error on the page. I've fixed the page.

If caches give you the earlier version it now says:
http://www.sydneysmith.com/products/hp29u/run/app.html

Thanks Greg, the 2nd link now works, though I guess I expected the UX would be different than the online version. If I can run this offline, how do I invoke it at a later (presumably disconnected) time?

Is it as simple as just saving the app.html file somewhere?

Exploring your site, I see you also have emulators for the HP-21, -25, -29, -65, and -67. Will check them out when time allows.

Thanks again!

[rprosperi]

(03-19-2018 12:42 AM)Mike (Stgt) Wrote:  Both links result in the dispay of a foto showing an HP-29C with three lower case 'r' in the display. There is a blank between the 2nd and 3rd 'r' so it could be 'Error' with 'E' and 'o' missing. Any key or slider blanks the display. I run Firefox 59.0.1 under Win7.
When I hit '/' while the display blank I get also presented the 3 rs. This could be a Div by 0 error.

It looks/works fine on IE11, also on Win-7 Pro x64. Since Win-7 has IE built-in, give that a try; it will at least verify if the issue is Firefox.

[Greg]

The HP-29C comes up with "Error" the first time you run it as the microcode checks for a "magic number" in the RAM. At first power-up, normally in the HP factory for the real thing, you see the "Error". After that the CMOS RAM is initialized and all goes smoothly.

You may see a time lag initially as files download over the net. Each digit, and the "E", "r" and "o" are "digits" from the calculator's perspective, is a small picture. The first time the calculator displays a digit you haven't seen before, it downloads across the net. It shouldn't take long and once it's in your browser cache, it should be instantaneous. There used to be a technique of preloading files like this to get them to you before you ever need them. That's a bit redundant given the "install" link downloads them anyway. The main difference between "use" and "install" is the browser will keep the files with an "install". With "use", normal caching rules apply and the browser may free up space and re-download as it sees fit.

To use the emulators offline, choose the install link and then pin the page to your home screen. There's usually an option like that in phone/tablet browsers. There's an equivalent for desktop browsers (Chrome has "Add to desktop"). You can see it function offline by turning on airplane mode (or pulling out your network cable). If you saw "The application has been installed or updated" all of the files will be local and instantly available. I use the hp67u on my phone and a lot of times I'm in poor coverage areas or disconnected.

I do find it frustrating the first time I run one of the emulators on a new device that digits take a little while to come up. Usually it's something missing from "0.00" (eg "0", "." or "0." depending on whether it's a woodstock in 12 digit mode or a '67 / classic in 15 digit mode) or 2 ENTER 3 + giving " .00" then "5.00". I guess I'm used to it and tune out while it loads. It's normally only the first time but I'll have a think through the options to improve that.

The hp29u emulator is only 368 KB and it is hard to find a desktop or phone app that small. It might be worth clicking the install option, waiting for the message and seeing if that performs better for you. To uninstall, use your browser to clear browsing data for the http://www.sydneysmith.com site. That will free up the downloaded files.

Hope this helps.

[Greg]

I don't have Win 7 but I will try Firefox on Win 8.1 and 10 and see if there's something I've missed about Firefox. Normally it just needs to download the digits.

[Greg]

Hi Mike,
It isn't a download speed issue. I can reproduce the problem. Am looking into it.

[Greg]

Just an update. It looks like, and I could be reading Firefox wrong, that I'm overtaxing it somewhat. It's not its fault. My code could have been written better.

As far as I can tell, it looks like I'm requesting a series of digits ("E", "r", "o") and it is trying to download them but before it gets there, I request them again and it starts over. What we see is the one it did manage to download ("r") and nothing else.

I am running the HP-29C emulator nicely in Firefox 59.0.1 (on Win 10 so far) but with all the tests I'm not sure I can repeat the sequence that got it there. My best guess is it was simply clicking the "install" link and waiting for the "installed" message. What I saw when I did that was each file download in sequence and then the whole thing run. I did try clearing the Firefox cache and retesting but it looks like it retained some stuff as I couldn't get the " rr r" display again.

The Woodstock calculators run at about 200 kHz. That's not as much as it sounds because data gets shipped around serially in 56 bit chunks so it works out to about 3000 microcode instructions per second. Any emulator, even in a browser, has to match that speed. That's 0.3 mS per instruction. I update the display every 80 of those, ie every 24 mS. With a 12 digit display, the browser has somewhere between 2-24 mS to download a (small) picture - depending on whether it does multiple GETs at a time. Every 24 mS I ask again.

I think IE and Chrome are saying, "I already have this one in my list of things to get" and Firefox is saying, "I don't have this yet so I'd better add it to the list".

I could be wrong, but that's what it looks like to me.

There are no javascript exceptions being triggered so it doesn't seem to be a divide by zero error or a case of an unsupported property in this browser.

The workaround is probably to do the "install" as that downloads the files up front. More testing is required.

The longer term fix is to not request pictures I just asked for (eg if the display isn't changing).

[Greg]

Hi Mike,

My HP-65 already has code in it to only update the display if it changes.
That's working fine first time in Firefox for me, even without doing an install first.
Could you please try http://www.sydneysmith.com/products/gss-...index.html for me and let me know if that one works for you?

[teenix]

(03-19-2018 01:59 PM)Mike (Stgt) Wrote:  No -- my no is not related to your emulator as Bernhard's and Tony's do almost the same, it it probably the HP65 itself who does not what I expect. I should compare with a real machine.
What I did:
Start your app, waiting some seconds until '0.00' shown (w/o quotes),
switch to W/PRGM, '00 00' in display,
switch back to RUN,
enter 12345679 ENTER 72 *, '8.888888880 08' in display,
A (for 1/X), '0.00' displayed,
A (for 1/X), '8.888888881 08' shown,
switch to W/PRGM, shows '24' -- WhaThisFor??
f CLEAR PRGM, 2 f LOG, switch to RUN, RTN, R/S loops and in your app I may stop in only by OFF.
Of cause it is my error not to end the "program" with RTN or STOP. Other emulators give me the chance to break the loop with R/S.

/M.

The 24 is displaying correctly in that the current program step is pointing to the RTN step at the end of the [A] button 1/x program. Row 2, 4th key in [RTN].

Press [SST] and you will see 23 displayed which is the first step of the [B] button SQRT program, ie. LBL - row 2, 3rd key in.

cheers

Tony

[Greg]

Hi Mike,

Tony is completely right that that is how the microcode in the calculator makes it behave.

I did find the HP-65 difficult to use initially but that's my background - I'd been spoilt with later programmables that also show the step number. The HP-65 actually starts by loading in a default program that does the A-E keys. If you power on, switch to W/PRGM and SST through you'll see the program. I thought that was neater than the HP-67 which has an internal flag that you can't see and no obvious default program. The downside is I often key a program into a HP-65 and forget to clear the default program first. You end up with, typically, two "LBL A"s in the program and your program only working every second time (and doing 1/x every other).

Now, if you'd done what you did but pressed 4 divide before switching to WPRGM, you would have been even more confused. I was sure I'd done something seriously wrong the first time I tested that on the HP-65 emulator.

You'll see "81" in the WPRGM display and that isn't in the program. The way the (very early) calculator works is what gets displayed is the current calculator operation; not necessarily the current program step. It is confusing and it's one of the first things they improved with later programmables. (The "81" is because the last operation was a - manual - divide). See the HP-65 Owner's Handbook, bottom of page 62.

Bottom line: sounds like I need to fit the same three lines of code to not update an unchanged display, into the HP-29C emulator, and probably my recent ones too (21, 25).

You should get improved speed if you do the "install" option (tap the display digits to get the menu and help to get to my site. There is an "install" link on the hp-65 page. That should result in everything running locally and it shouldn't matter how good or bad your internet speed is. Some countries / ISPs charge for data. Having it all local also cuts any of those sorts of costs.

Thanks for your help with this.

[teenix]

(03-19-2018 07:54 PM)Greg Wrote:  Now, if you'd done what you did but pressed 4 divide before switching to WPRGM, you would have been even more confused. I was sure I'd done something seriously wrong the first time I tested that on the HP-65 emulator.

You'll see "81" in the WPRGM display and that isn't in the program.

The HP-65 puts all key press values into a buffer and when switched to W/PGM this value is added to the program counter with the Buffer -> ROMaddress instruction. This causes a jump to a ROM address determined by the buffer value. Its function is to display a keyboard coordinate, and in this case the last key pressed.

This buffer also gets filled with the current program step when a program is running or by using SST etc, which is why the keyboard position of the current program step appears.

cheers

Tony

[Greg]

Hi Mike,

The looping issues should now be fixed.

[Greg]

Hi Mike,

The calculators loop around from the final step back to step 1 and continue. That's why you can find a LBL that is before you and why, in some cases, they had "rapid reverse branching". It was "rapid" (VERY rapid actually) because it just adjusted the user program counter value rather than looking all the way through memory (here to end, then start to here) for a LBL.

It is interesting to watch the HP-65 as it actually gets to step 00 and executes the "top of memory marker" instruction. It doesn't do anything but the microcode goes through the motions as if it were a real instruction. I haven't noticed how the other models treat the transition. It just was notable when I was investigating what you were seeing.

I think, and I don't have anything immediately to hand to back this up, that Eric and Jacques Laporte were working on the HP-65 for nonpareil. Eric seems to have moved on (site hasn't been updated for a while). The HP-65 seems to have brought more than its fair share of mysteries to untangle and I'm sure that both of them must have felt it, on many occasions, to be more effort that it was worth. The whole card reader, 600 bit circular buffer, and embedded pointers is a real nightmare as I'm sure Tony will agree. It's not at all intuitive today; but it was probably best practice at the time. I suspect Eric got lots of the others going in the meantime. The card reader added a lot of complexity. I do know that Jacques did eventually get it to work in Java as Francois Roulet's one (http://home.citycable.ch/pierrefleur/HP-...assic.html) is based on that. Mine derives from Francois's. There have been a few tweaks and we've both contributed to each other.

[emece67]

Hi all,

I think that the current posts on this thread do have little connection with its title. Perhaps a new thread can be opened with a title that more precisely reflect the current point.

Regards.

[brickviking]

(03-22-2018 06:33 PM)Mike (Stgt) Wrote:  

(03-22-2018 09:15 AM)Greg Wrote:  ... Eric seems to have moved on (site hasn't been updated for a while).

Seems also Rémy Rouvin ended his PockEmul, today the last change was 11 month ago. At first glance it looks like emulating many many Sharp only but it also does a the HP41 and few peripherals with a GUI to 'plug' devices together by aligning their photos. If I only could program C (or C# or C++) I would do an HP41-only fork. Or a NUT-fork.

Ciao.....Mike

Wow, I didn't know about this little treasure-trove. I had a PC-1247 (expandable with extra memory) and it's fun to see some of its brothers emulated. Thanks for this, Mike.

(Post 194)

[emece67]

(03-14-2018 03:17 AM)jjohnson873 Wrote:  Flash memory storage for most embedded microcontrollers is designed for +100 years before the charge on the memory cell will leak enough to flip a bit.

(03-14-2018 06:32 AM)cyrille de brébisson Wrote:  Thrid, I have have not looked at the CPU doc, but I am prety sure that the ATMEL chip has a flash life which is longer than 5 to 10 years. These chips are designed to last decades, not years.

I've checked the Atmel technical documentation about the SAM7L128 and SAM4LC4 microcontrollers that (I think) are used in the HP12/15 Platinum/LE. The minimum guaranteed data retention time for the Flash memory inside these chips is of 10 years in the SAM7L128 and 15 years in the SAM4LC4.

Regards.

[teenix]

(03-26-2018 11:11 PM)emece67 Wrote:  

(03-14-2018 03:17 AM)jjohnson873 Wrote:  Flash memory storage for most embedded microcontrollers is designed for +100 years before the charge on the memory cell will leak enough to flip a bit.

(03-14-2018 06:32 AM)cyrille de brébisson Wrote:  Thrid, I have have not looked at the CPU doc, but I am prety sure that the ATMEL chip has a flash life which is longer than 5 to 10 years. These chips are designed to last decades, not years.

I've checked the Atmel technical documentation about the SAM7L128 and SAM4LC4 microcontrollers that (I think) are used in the HP12/15 Platinum/LE. The minimum guaranteed data retention time for the Flash memory inside these chips is of 10 years in the SAM7L128 and 15 years in the SAM4LC4.

Regards.

Probably useless info, but the PIC that is used in the MultiCalc is specified at 40 years data retention for both EEPROM and ROM (under normal operating conditions).

Seems it's going to outlast me ;-)

cheers

Tony

[emece67]

(03-27-2018 01:19 AM)teenix Wrote:  Probably useless info, but the PIC that is used in the MultiCalc is specified at 40 years data retention for both EEPROM and ROM (under normal operating conditions).

Flash, EEPROM and ROM are different beasts, not comparable about their long term data retention performance.

Regards.

[teenix]

(03-27-2018 02:25 PM)emece67 Wrote:  Flash, EEPROM and ROM are different beasts, not comparable about their long term data retention performance.
Regards.

I suppose I should have clarified that the PIC is a flash type of chip, however, the specified data retention for both EEPROM and ROM memory is still 40 years :-)

cheers

Tony

[Dan Grelinger]

Quote:I've checked the Atmel technical documentation about the SAM7L128 and SAM4LC4 microcontrollers that (I think) are used in the HP12/15 Platinum/LE. The minimum guaranteed data retention time for the Flash memory inside these chips is of 10 years in the SAM7L128 and 15 years in the SAM4LC4.

I wonder if a much longer time could be expected. My HP-15C is already over 6 years old. If it only has an expected lifetime of 4 more years, I will be sad.

[dfsantos]

ups, i just bought a 15c LE