Threaded Mode | Linear Mode

Massimo Gnerucci · 03-10-2017, 07:14 PM

(03-10-2017 04:34 PM)Hsilop Wrote: BTW: Left is right and right is wrong - ergo left is wrong? Wat?? ;-)

Only if right is right...

That stems from past polls about WP-43 placement of arithmetic keys.
I stand with my POV: they belong to the left side.

signals · (This post was last modified: 03-10-2017 07:59 PM by signals.)

(03-10-2017 06:23 PM)Ángel Martin Wrote: Now, what's the rationale behind the display arrangement having large font XY at the bottom and small font XYZT on top like in the demo??

I'd rather have XYZT in large font and end of the story (perhaps plus small font L).

Hope it's configurable.... anyone knows?

I suspect it's the answer to some questions I've been wondering since I first saw the giant display on it. How is PIXEL going to work with the larger display? Will I be able to have a 3+ line alpha register? Will I be able to call up a virtual printer output as in other versions of Free42? etc.

Looks like the answer is that there's a "virtual" 2 line display at the bottom that works just like you'd expect from an HP 42s, and the lines above are just a dump of the stack contents. I'm guessing this is because Free42 is pretty well tied to the original's 2 line dot-matrix display.

Now, will there be extensions to the calculator's original functionality that allow use of the extra screen real estate? We can hope...

Hsilop · (This post was last modified: 03-10-2017 08:25 PM by Hsilop.)

(03-10-2017 07:14 PM)Massimo Gnerucci Wrote:
(03-10-2017 04:34 PM)Hsilop Wrote: BTW: Left is right and right is wrong - ergo left is wrong? Wat?? ;-)

Only if right is right...

That stems from past polls about WP-43 placement of arithmetic keys.
I stand with my POV: they belong to the left side.

Right!

BTW, I don't disagree. Just having a bit of transitive fun. :-)

Guenter Schink · 03-10-2017, 09:11 PM

(03-10-2017 11:36 AM)grsbanks Wrote: Interesting that there's that image of an owl on screen when the DM-42 is switched off. Is that an eInk display? As far as I know they're the only displays to have zero power requirement to maintain their status. They only require power to refresh.

It's not eInk but low power transflective memory LCD. That is 50 µW consumption for static display.

Günter

Guenter Schink · 03-10-2017, 09:47 PM

(03-10-2017 04:37 PM)emece67 Wrote: Hi all.

AFAIK, the expected wp43 will share the hardware with the dm42l machine. I'm not following in detail the progress in the development of the dm42 (it, simply, is not a product for me, although I do own other Swissmicros machines I love).

Is there any information about the final price of such hardware platform? I have seen some info on the expected price of the dm42, but I'm hoping for the wp43 to be cheaper.

Thanks & regards.

I think it's rather premature to talk about an expected WP43. So far there is only the idea that the DM42P hardware would be suitable to host any possible development of a WP43 software. So, don't hold your breath while waiting for an WP43.

Günter

**rprosperi** · 03-11-2017, 12:46 AM

(03-10-2017 06:23 PM)Ángel Martin Wrote: Now, what's the rationale behind the display arrangement having large font XY at the bottom and small font XYZT on top like in the demo??

2-line display has existed in Free42 for a long time, but the extended display (4- or 5-lines) is part of what's being developed by SM during the port to this new larger LCD, so it's likely it's a debug mode to verify the new 4-line area is correct - but just a guess.

As there is no dev. team yet for the WP-43S, I'd say it's a lonnng way in the future (read years) and also guess that it will actually cost more than the DM42 since it's likely there would be fewer sold. In any case, there's no reason to expect it to be less, it's the same h/w, and both sets of s/w are 'free' (meaning no royalty component cost).

Thomas Okken · 03-11-2017, 12:56 AM

(03-10-2017 11:36 AM)grsbanks Wrote: Interesting that there's that image of an owl on screen when the DM-42 is switched off. Is that an eInk display? As far as I know they're the only displays to have zero power requirement to maintain their status. They only require power to refresh.

I'm not an expert on this, but all the eInk displays that I've seen so far are opaque, not reflective, and they are slow to redraw, and look smudgy when partial redraws take place — all of which probably explains why you only see those screens in eBook readers, and never in smartphones or tablets. (I think there was one smartphone with an eInk screen at one point, a few years ago, but obviously it wasn't a big hit.)

The screen in that video sure looks like an LCD to me.

Thomas Okken · 03-11-2017, 01:09 AM

(03-10-2017 07:56 PM)signals Wrote: \[...\]I'm guessing this is because Free42 is pretty well tied to the original's 2 line dot-matrix display.

Modifying Free42 to take advantage of a bigger screen isn't actually all that difficult... The greater problem is all the programs that expect the screen to be 22x2 characters or 131x16 pixels.

Using the extra space to show the stack instead, or more than two program lines, makes sense. Of course it would be cool if there were a mode where you could use all that space from a program, so you could use PIXEL and AGRAPH to be able to cover all that space, and increasing the size of ALHPA accordingly as well. We'll have to wait and see. :-)

Dave Britten · 03-11-2017, 02:39 AM

(03-11-2017 01:09 AM)Thomas Okken Wrote: Modifying Free42 to take advantage of a bigger screen isn't actually all that difficult... The greater problem is all the programs that expect the screen to be 22x2 characters or 131x16 pixels.

Wouldn't be that difficult to solve, at least from a design standpoint. The 42S has a number of unused "reserved" system flags that could be repurposed for toggling between legacy and enhanced display modes. Of course, a lot of display-related functions and instructions would have to be modified to test that flag and react accordingly. It would be a little bit like running programs compiled for a Psion Organiser II CM or XP on an LZ, where it runs them in a tiny window in the center of its (much higher resolution) screen.

Pekis · (This post was last modified: 03-11-2017 07:12 AM by Pekis.)

Personnaly I prefer a display with the 4 stack registers only (big font) + indicators (rad,... and clock ?)

Ángel Martin · (This post was last modified: 03-12-2017 07:00 AM by Ángel Martin.)

(03-11-2017 07:11 AM)Pekis Wrote: Personnaly I prefer a display with the 4 stack registers only (big font) + indicators (rad,... and clock ?)

Absolutely 1+

That duplication of XY is nothing but confusing and a waste of space in my humble opinion.

Hsilop · 03-12-2017, 08:28 AM

(03-11-2017 07:11 AM)Pekis Wrote: Personnaly I prefer a display with the 4 stack registers only (big font) + indicators (rad,... and clock ?)

Nice, but surely not a dealbreaker. It would be a nice, configurable option in a future software update.

However, there seems to be plenty room for more digits / decimals in the current XYZT. This could provide higher resolution for real numbers, and "normal" resolution for the real and imaginary parts of complex numbers.

Would this be something that is easy to accomodate now or in an early update?

Thomas Okken · (This post was last modified: 03-12-2017 04:16 PM by Thomas Okken.)

(03-12-2017 08:28 AM)Hsilop Wrote: However, there seems to be plenty room for more digits / decimals in the current XYZT. This could provide higher resolution for real numbers, and "normal" resolution for the real and imaginary parts of complex numbers.

Would this be something that is easy to accomodate now or in an early update?

Changing the number-to-text conversion code to show more than the 12 digits it currently shows is trickier than you might expect, but it should be done anyway, even if for no other reason than to allow SHOW to show the full 34-digit mantissa (or 16 digits in Free42 Binary). Once that change is in place, the functionality Hsilop suggests would be quite easy to implement.

UPDATE: For the adventurous, I attached a preliminary patch that makes SHOW display full precision for real numbers.
The obvious next step is to support full precision everywhere: FIX 33, number entry with up to 34 digits, etc. That may take a bit more time. :-)

Thomas Okken · (This post was last modified: 03-19-2017 09:30 PM by Thomas Okken.)

(03-12-2017 01:10 PM)Thomas Okken Wrote: For the adventurous, I attached a preliminary patch that makes SHOW display full precision for real numbers.
The obvious next step is to support full precision everywhere: FIX 33, number entry with up to 34 digits, etc. That may take a bit more time. :-)

I made some more changes to SHOW: it now handles real numbers that don't fit in 44 characters -- this can happen when flag 29 is on and there are a lot of thousands separators, think 1e33 -- and full-precision program lines and complex numbers are also handled better. Also, full-precision number entry works now, in both run and program modes.

It's not ready for release yet; this is my to-do list for 1.5.15:

* Run FPTEST on iOS and Android; check that binary64_to_bid64 and bid64_to_bid128 aren't among the failing functions.
* PRP and LIST should always show numbers at full precision! Even if that means taking up three lines!
* Full-precision copy & paste
* Copy & Paste should handle ALPHA and PRGM.
* Check program import/export w.r.t. long number lines. Are bin->bin and dec->dec lossless? How about edge cases with dec->bin?

Due to popular demand, I put the code on GitHub: https://github.com/thomasokken/free42.

Vtile · 03-27-2017, 11:22 PM

The exponent symbols should have better visibility it seems. When there is no plus involved it gets lost between the numbers. Also complex symbols might have the same problems.
https://youtu.be/0LK7JotR728?t=1m1s

brouhaha · 03-28-2017, 06:11 AM

(03-11-2017 01:09 AM)Thomas Okken Wrote: Modifying Free42 to take advantage of a bigger screen isn't actually all that difficult...

Having already done that for the Free42-based calculator Richard Ottosen and I have demoed many times at the HHC conferences, I would say that while it wasn't difficult to get some basic functionality working with a bigger display, having it "do the right thing" in all of the common cases, e.g., scrolling in a helpful way in program mode, etc., was actually fairly tricky. In fact, my patches still exhibit some corner cases that behave in a suboptimal way.

brouhaha · 03-28-2017, 06:22 AM

(03-10-2017 09:11 PM)Guenter Schink Wrote: It's not eInk but low power transflective memory LCD. That is 50 µW consumption for static display.

50 µW for the display, plus power for a boost regulator to step the battery voltage up to the 5V needed by the display. Even the most efficient available boost regulators for that purpose consume another 50 µW or more. In the calculator prototypes Richard Ottosen and I have shown at the HHC Conferences, which run Free42 w/ display patches using that same LCD, when the calculator is turned off we actually remove power from the display and the boost converter, so that the display power consumption is 0 µW rather than around 100 µW.

We were running from CR2032 coin cells, so an extra 100 uW power dissipation in the off state would have a not completely insignificant effect on the battery life. Usable CR2032 capacity is somewhere around 500 mWh. (Capacity varies considerably by brand; no-name or off-brand batteries are often far lower).

Guenter Schink · 03-28-2017, 09:05 AM

(03-28-2017 06:22 AM)brouhaha Wrote:
(03-10-2017 09:11 PM)Guenter Schink Wrote: It's not eInk but low power transflective memory LCD. That is 50 µW consumption for static display.

50 µW for the display, plus power for a boost regulator to step the battery voltage up to the 5V needed by the display. Even the most efficient available boost regulators for that purpose consume another 50 µW or more. In the calculator prototypes Richard Ottosen and I have shown at the HHC Conferences, which run Free42 w/ display patches using that same LCD, when the calculator is turned off we actually remove power from the display and the boost converter, so that the display power consumption is 0 µW rather than around 100 µW.

We were running from CR2032 coin cells, so an extra 100 uW power dissipation in the off state would have a not completely insignificant effect on the battery life. Usable CR2032 capacity is somewhere around 500 mWh. (Capacity varies considerably by brand; no-name or off-brand batteries are often far lower).

Hi Eric
thanks for the clarification. Let me please emphasize that I'm not involved in the development, but only referring to the information I've been provided with, without really understanding the technical details behind the scene.

Will be interesting to see how SwissMicros are going to handle this.
Günter

PS: I'm glad to see you active again.

grsbanks · (This post was last modified: 03-28-2017 12:23 PM by grsbanks.)

(03-28-2017 06:22 AM)brouhaha Wrote: 50 µW for the display, plus power for a boost regulator to step the battery voltage up to the 5V needed by the display. Even the most efficient available boost regulators for that purpose consume another 50 µW or more. In the calculator prototypes Richard Ottosen and I have shown at the HHC Conferences, which run Free42 w/ display patches using that same LCD, when the calculator is turned off we actually remove power from the display and the boost converter, so that the display power consumption is 0 µW rather than around 100 µW.

I've just been in touch with SwissMicros' Michael Steinmann for something else and raised the point of the 42's display. He has this to say (posted with his permission):

The LCD does need a 5V booster as mentioned by Eric Smith, but our booster has an enable pin which we simply turn off and the consumption goes down close to zero.

Currently we're well below 10µA in OFF mode for the total consumption of the calculator (all of that goes to the CPU), but the goal is less than half of that with adjustments to the software.

ArneStolti · 04-02-2017, 06:32 PM

Hello co-waiters for the DM42.
Is giving a group of beta-testers some first numbers of the expected calculator really Michaels intention (like proposed in this post-group)? And what does is take to become a beta-tester? Only time and willingness to report about the usage or also mathematical skills and screwed problems in the back of the head (I don't know, if I was qualified, but interested in the product).