Gauging interest in a DM48 or DM50?

[DA74254]

When will there be an Android release of the DB48/50/51(x) version.
I'd be willing to pay for that, as I paid for Thomas Okkens excellent Plus42.

[HP67]

(10-02-2024 10:40 AM)c3d Wrote:  

(10-02-2024 08:41 AM)HP67 Wrote:  I thought the 48 ROMs were officially legally fine to use.

If so, I think a hardware clone of a 48GX would sell well, even if we had to flash the ROM upon arrival. I have no idea who all SwissMicro sells to, but if this forum represents the bulk of their market, then clearly, we are all fine with flashing this or that.

I have bought 5 or 6 SwissMicro calcs over the year, I have 3 (I think) and I gave 3 as gifts. They have proven they can deliver a quality product that is worth buying. In some ways (the titanium cases) they outdid HP. I'd like double shot keys on any future model though.

Until now they haven't given me a chance to buy a clone of my favorites (48GX, 50g). If the time comes, I would spend the money. But, it has to be 100% compatible. The I/O on the 48 and 50 is already good enough for me. I'd like a physical card slot like on a real 50g, since the internal memory is sufficient for me and a card only requires power when used.

I would not be interested in a new oddball variant based HP calcs. I think HP really nailed the UI as no other calculator company has done. For me that's part of why I prefer their calcluators over anything else that I have used.

I wonder if you have used DB48X? If so, what makes it "oddball" to you (expect for having to fit on an HP42 keyboard)? This is a community project, so what you don't like can be fixed.

I haven't seen it, no. Anyway my personal preference is for true clones. An incompatible keyboard doesn't appeal to me. Especially here, since the GX was probably the epitome of HP UI and practical usefulness, if not build quality or beauty. For me, the SX wins in beauty and the 67 in build quality. "Those were the days..."

I have enough HPs and I'm not looking for anything new. Was just responding to your "what if..."

(10-02-2024 10:40 AM)c3d Wrote:  Regarding the UI, yes HP nailed it sometimes, although they had gaffes too (the placement of the ENTER key on the HP50G being a big one). It does not mean that you cannot improve on what they did when you have better hardware. Here is a testimony from this thread.

True enough, the 50g keyboard layout is much reviled, and with good reason. But everybody knows this isn't an HP calculator in the old tradition. Given nothing else came closer, we had to live with modern...

[Eric Rechlin]

(10-01-2024 10:14 PM)c3d Wrote:  Can you think of anything I could do to make it easier? Do you remember the things that annoyed you the most?

This started out as me trying to write a response to what you could change to make it easier, but after thinking a bit I realized there really isn't anything you need to change! Instead I will just give you a brain dump on some of my thoughts about DM48X and my perceptions coming from the 50g (and its predecessors).

First, I will qualify this by saying that all my testing so far has been with the web version of DB48X, and that surely has some limitations compared to the real thing. For example, I've noticed the "hold down" functionality does not work, so I can't test the hold-key-for-help or hold-shift-for-alpha features, and I probably am missing other things also.

Second, I want to say I am so incredibly impressed with the functionality you have implemented. From native H:M:S objects, to improved SI prefix support, to the extremely flexible number display formats (the configurable point of when to switch to scientific notation is great!), to the flexibility of different alpha modes, it's just amazing all the new ideas you have, compared to what is in the HP RPL machines. The hierarchical CHAR menu is just so useful too (though the Cyrillic menu is missing some Ukrainian letters, as well as some other Cyrillic letters from languages other than Russian...). The base functionality (with automatic alpha entry which helps for HEX mode -- and also with arbitrary base sizes!) is much better implemented as well.

I don't think there is necessarily anything *wrong* with the UI, it's just that a lot of things follow a different paradigm which makes it feel foreign to someone who's been using the 48/49/50 models for 30 years.

For example, when you first turn it on, there is no softkey menu visible so the top row of keys can’t do anything. This isn’t a problem, because there’s not much you can do on an empty stack, but it was somewhat disconcerting at first to me.

Similarly, not showing any stack level numbers when those levels are empty actually probably does make more sense than past calculators showing 1-4 or even 1-7 (because those stack levels don't actually exist yet, so why show them?), but it just feels different. Here I prefer how you did it, even if it seems like a surprise at first. Maybe keeping the vertical dotted line (that otherwise separates the stack labels from the values) would make it a little less empty.

Also, the way the softkey menus change which row is highlighted each time you press the shift key is a really good touch, but at the same time it might also seem a little disconcerting to a 48/49/50 user who hits a shift key just to do a shifted operation on another key without caring about the softkey menu. Again, this is a case where what you did is great and makes sense, but it's unexpected for a 48/49/50 user. At least I was surprised when I saw the whole menu shifting colors when pressing the shift key for something else — even if there is nothing wrong with that.

Getting to things that are a bit more substantive and not just cosmetic surprises, the total lack of a RCL key seems like a problem at first, but once I started using it I didn't really miss it, especially since the VAR menu makes the store/recall shifted softkeys very clear. I was similarly concerned when I saw the command was actually called "Recall", which would be annoying to type both with the length and also with using lower-case letters, but then I realized RCL worked just fine too.

The lack of an EVAL key sometimes bothers me (for removing a tag from an object or executing a program on the stack) but maybe there's an easy workaround, and maybe it wasn't all that important after all. Relatedly I haven't even found a simple way to make tagged objects other than →Tag and Tag→, but honestly that's something I use rarely enough that it doesn't matter.

I guess there are a couple places where I don't fully understand the design decisions, however, and maybe those are places where there could be room for improvement or else places where maybe I would better understand the decisions if I knew the philosophy behind the design. For example, when you press [TRIG], the default options are |sin| |cos| |tan| (which are already unshifted keys on the keyboard) and |sin-1| |cos-1| |tan-1| which are already shifted keys on the keyboard. So this softkey menu seems totally useless unless I further press the shift key again to get at the |sec| |csc| |cot| etc. But those functions seem rare enough that they could instead get buried under the Math menu somehow with no direct key. I wonder if maybe [HYP] and [TRIG] could be consolidated. I'd be surprised if either one is frequently used.

Now, maybe you have bigger plans for this somehow -- like perhaps that menu will eventually be used for CAS functionality like the [TRIG] key on the 50g. Or maybe this is all part of a cohesive submenu system under the [MAIN] menu, where all commands will eventually reside, and different keyboard layouts (which may not even have [SIN] [COS] [TAN] keys) will have to be accommodated, but if so I wonder if it may be better to still try to optimize the limited keyboard we have to not have too many redundancies. Especially when we have such a shortage of keys, I am not sure if it makes sense to have something that would see such infrequent use on a hard key.

Similarly, everything in the unshifted [MAIN] menu already exists as a separate (shifted) key on the actual keyboard, so although it does show a cohesive single place with perhaps the main functionality, it just ensures everything else under [MAIN] is yet another keystroke away — but again, many of the [Shift] and [Shift][Shift] options on [MAIN] are already on shifted keys on the main keyboard too. I think everything but |UI| (which is also under [MODES], and double-shifted under [DISP]) has a dedicated key on the physical keyboard, making [MAIN] seem nearly redundant. Maybe get rid of [MAIN] entirely and just replace it with [UI] so everything is handled? But this just makes me wonder if maybe menus should be reorganized in such a way that even if you want to have redundances with things in menus that are also on the keyboard itself (which makes sense if everything under [HOME] is supposed to be a hierarchically-organized list of all commands available just like [CAT] is an alphabetically-organized list of all commands), perhaps menus should prioritize commands that are *not* already on the keyboard as the first 6 (available unshifted in the menu), and then leave the redundant ones on the double-shifted or single-shifted planes in that menu.

Maybe I haven't found it yet, but I'd also like to see a shortcut for switching between real and approximate mode. It seems like it's buried quite deep in the menus. I really like this feature in the 49/50 where switching between the modes (RightShiftHold-Enter) is as easy as converting a number from a fraction to a decimal (RightShift-Enter). But I guess the lack of a [→NUM] key makes it less obvious where this would go.

The alpha plane has no accent-keys like the 48/49/50 (at least not that I have yet discovered) making it not possible to type letters with diacritical marks without using the [CHAR] menu, but maybe in the real world that really isn't relevant since it seems unlikely anyone would be trying to type long strings of text in here (like one might have in the 48) anyway.

I think it would be more useful in the header to show the status of various modes in the place of where it currently just says "DB50X". For example, the current angle mode (degrees/radians), along with an indicator of exact vs approximate. I see there is a “not yet implemented” for the rectangular/polar/spherical mode, so when that is implemented maybe that could be indicated, too, though I’m not sure the necessity of that when you already distinguish between them with different object types (which is also a nice touch).

I completely agree with your abandonment of 48/49/50 source code compatibility in favor of trying to do things the "right" way this time around. Honestly there are very few programs written for the 48/49/50 that I would probably want to run on the DB50X — most of the best programs there were either to reimplement what the 48 did poorly/slowly, to add functionality that nowadays would be better served by a phone (like PIM functionality or games), or are already implemented better (or presumably will eventually be implemented better) in DB50X. Your planned future functionality (MatrixWriter, EquationWriter, some CAS features) would pretty much remove any need for things I relied on third-party programs (like MetaKernel) on the 48 for.

I'm sure I'll come up with more, but that's probably enough for now! DB48X really excites me and i can't wait to have it in a more convenient format than just a web app. All in all, I am extremely amazed with what you have put together, and so far it's really turning out to what the 48SX (HP's most elegant calculator IMHO) should have been when it first came out, had technology been advanced enough at the time.

[LinusSch]

(10-24-2024 12:00 AM)Eric Rechlin Wrote:  <grand brain dump of wise thoughts>

I have not poked at this as much as Eric clearly has, but I read all of that and could do nothing but agree and agree again. So if you want advice, Christophe, just consider that entire post seconded.

Or maybe 1.5x, I don't think my words should count quite as much as Eric's! I may have used RPL for half my life now, and thought deeply about both RPL and calculators in general a few times - but this is only since 2007, I bought my first HP from Eric. I've used the 50g only and I have not written much RPL code. Apparently I'm not the most junior user around on these forums anymore, but I'm really not at the level of the wise and knowledgeable just yet.

[LinusSch]

I'm watching the new video and I suddenly have a thought specifically about this, hardware for this software: I'm not sure that the current keyboard layout would make the most sense. I would experiment with layouts having two shift keys, with trigonometric functions in a menu, before committing to hardware.

This requires quite some experimentation and testing: leave the arrows where they are and put shifts upper right as on the R47, or put shifts lower left and arrows upper right much like the 48? Which key that isn't a shift or an arrow makes sense to move to the lower left group? What to do with the second freed up key?

I think y^x should easily be the top answer to the last question, but the previous ones seem much more tricky.

[ben.titmus]

I have to admit I was originally quite sceptical about DB48x when I heard about it because I know how much work is involved in developing a calculator due to my involvement in WP43. I think you've done an amazing job though.

I thought I would correct one comment that you made though.

(10-01-2024 09:40 PM)c3d Wrote:  They only deviated once from this philosophy, and I believe they see that as a disaster. They worked with the WP43 team to try and bring a non-HP calculator, albeit one that was clearly "in the spirit of" RPN calculators. Prototypes of the calculator were built, but then there was a dispute. I was not part of that dispute, so I can only report hearsay, but my understanding is that the creator of the WP43 project and the SwissMicros team could not come to an agreement regarding who would own the really impressive user manual. In any case, my impression is that SwissMicros derived all the wrong lessons from that, namely that working with an "external R&D department" was dangerous, and that they'd better stick to the known evils of existing HP calculators.

This is not correct, although there isn't any particular reason you should know this. I was directly involved in the negotiations as I represented the WP43 team to Michael (SM) so I have more insight. There is a post made by me on the SM forums ("Joint statement from the WP43 developers and the C43 team") that gives the reason why:

Quote:The decision has been made by SwissMicros to end the collaboration due to past and recent behaviour of Walter causing the concern that the WP43 project could negatively impact the reputation of SwissMicros.

I can tell you that this is the reason why the negotiations failed. Michael was concerned that Walter would negatively impact the reputation of SM due to his behaviour. There were several examples of this, such as his behaviour on this forum and the SM forum, his behaviour during the negotiations (there were actually two rounds of negotiations), and his behaviour when the prototypes were made. I won't go into the details of these incidents, but suffice to say that all the others involved in the negotiations agreed with Michael that Walter's behaviour was unacceptable and moved to C43 (now C47) as a result.

The 'hearsay' has some truth in it because we essentially begged Michael to allow us to continue WP43 hardware development after these incidents and Michael suggested that if we could mitigate Walter's involvement so that he didn't pose a serious risk of reputational damage to SM then it might be possible. But Walter didn't agree to any of the ideas on how this could be done as they would all have decreased his involvement in the project in some way. (One suggestion was to allow SM editorial control over the manuals so that Walter couldn't add anything inflammatory to them.) It's unclear whether the negotiations would have succeeded even if Walter did agree to these requests though.

I haven't been involved much in C47 for the past two years due to lack of time. I do greatly appreciate Walter's work on WP43 and he had a strong clear direction for the project, but I also understand why Michael didn't want to continue.

[LinusSch]

(11-09-2024 10:42 AM)ben.titmus Wrote:  reasons

Thank you, that made things clear and made it all make sense. I do not like to assume things and I do not like having such things hanging around as unanswered questions in my brain.

[c3d]

(10-24-2024 12:00 AM)Eric Rechlin Wrote:  

(10-01-2024 10:14 PM)c3d Wrote:  Can you think of anything I could do to make it easier? Do you remember the things that annoyed you the most?

This started out as me trying to write a response to what you could change to make it easier, but after thinking a bit I realized there really isn't anything you need to change! Instead I will just give you a brain dump on some of my thoughts about DM48X and my perceptions coming from the 50g (and its predecessors).

Thanks a lot for the long writeup, which I only noticed today, after focusing on the Stuttgart video and the release of 0.8.4. Pretty impressive writeup.

Quote:First, I will qualify this by saying that all my testing so far has been with the web version of DB48X, and that surely has some limitations compared to the real thing. For example, I've noticed the "hold down" functionality does not work, so I can't test the hold-key-for-help or hold-shift-for-alpha features, and I probably am missing other things also.

Mostly anything requiring file access. This includes the new reconfigurable keyboard feature.

Quote:Second, I want to say I am so incredibly impressed with the functionality you have implemented. From native H:M objects, to improved SI prefix support, to the extremely flexible number display formats (the configurable point of when to switch to scientific notation is great!), to the flexibility of different alpha modes, it's just amazing all the new ideas you have, compared to what is in the HP RPL machines.

Coming from you, this is deeply appreciated. I had 30 years to think about it ;-)

Quote: The hierarchical CHAR menu is just so useful too (though the Cyrillic menu is missing some Ukrainian letters, as well as some other Cyrillic letters from languages other than Russian...).

Does it? It's a bug. If you can spend the time listing them, I'll make sure to fix it.

Quote: The base functionality (with automatic alpha entry which helps for HEX mode -- and also with arbitrary base sizes!) is much better implemented as well.

I don't think there is necessarily anything *wrong* with the UI, it's just that a lot of things follow a different paradigm which makes it feel foreign to someone who's been using the 48/49/50 models for 30 years.

For example, when you first turn it on, there is no softkey menu visible so the top row of keys can’t do anything. This isn’t a problem, because there’s not much you can do on an empty stack, but it was somewhat disconcerting at first to me.

I wanted to make more room for the stack for simple calculations, and to have the calculator be a bit less "intimidating".

Quote:Similarly, not showing any stack level numbers when those levels are empty actually probably does make more sense than past calculators showing 1-4 or even 1-7 (because those stack levels don't actually exist yet, so why show them?), but it just feels different. Here I prefer how you did it, even if it seems like a surprise at first. Maybe keeping the vertical dotted line (that otherwise separates the stack labels from the values) would make it a little less empty.

The choice here was explicitly to let you "detect" if the stack was empty. I could easily make it configurable.

Quote:Also, the way the softkey menus change which row is highlighted each time you press the shift key is a really good touch, but at the same time it might also seem a little disconcerting to a 48/49/50 user who hits a shift key just to do a shifted operation on another key without caring about the softkey menu. Again, this is a case where what you did is great and makes sense, but it's unexpected for a 48/49/50 user. At least I was surprised when I saw the whole menu shifting colors when pressing the shift key for something else — even if there is nothing wrong with that.

In practice, it's a much more visible indicator of the shift state than the icons, so I like it for that. That being said, you can try the flat menus mode in the user interface to return to a more HP48-like experience.

Quote:Getting to things that are a bit more substantive and not just cosmetic surprises, the total lack of a RCL key seems like a problem at first, but once I started using it I didn't really miss it, especially since the VAR menu makes the store/recall shifted softkeys very clear.

This was a really tough decision. So few keys, so many functions!

Quote: I was similarly concerned when I saw the command was actually called "Recall", which would be annoying to type both with the length and also with using lower-case letters, but then I realized RCL worked just fine too.

I don't know if you noticed that you can configure the rendering to show RCL in your programs (or rcl or Rcl).

Quote:The lack of an EVAL key sometimes bothers me (for removing a tag from an object or executing a program on the stack) but maybe there's an easy workaround, and maybe it wasn't all that important after all.

EVAL is the key at the bottom left of +. Because I have so few keys to play with, I had to overload some of them with features I saw as related. That key serves multiple purposes depending on context:

- When you are not editing, it is EVAL (it was RUN/STOP on the DM42, so its position preserves muscle memory. This is one of the reasons there is a little = sign on it: when you evaluate an algebraic object, it plays the role of the = key on TI calculators, which is to complete the computation.

- When you are editing, it inserts a space (which in RPL is "evaluate the previous thing", so in my mind it made sense to connect the two).

- When you are inside an algebraic but not inside parentheses, it inserts "=" (my mental shortcut was that as long as I meant it as "=" to terminate computations, I could as well use it as "=" for equations).

- When you are inside an algebraic and inside parentheses, it inserts a ; to separate arguments (my mental logic here is that it terminates something jut like a space in RPL terminates something).

This is illustrated at 39:50 in the Stuttgard video.

Quote: Relatedly I haven't even found a simple way to make tagged objects other than →Tag and Tag→, but honestly that's something I use rarely enough that it doesn't matter.

When you are in ALPHA mode, unshifted zero inserts ::, except when you are inside text, where it inserts a single :

Also note that DB48X uses "assignment objects" for some cases where the HP calculators would have used tagged objects. For example where the HP solver would emit something like x:1.5, DB48X will emit x=1.5, which is an assignment object. If you have x=1.5 and x=2.5 on the stack, you can easily switch between the two values by selecting the one you want with the interactive stack and hitting the Evaluate key.

Quote:I guess there are a couple places where I don't fully understand the design decisions, however, and maybe those are places where there could be room for improvement or else places where maybe I would better understand the decisions if I knew the philosophy behind the design. For example, when you press [TRIG], the default options are |sin| |cos| |tan| (which are already unshifted keys on the keyboard) and |sin-1| |cos-1| |tan-1| which are already shifted keys on the keyboard. So this softkey menu seems totally useless unless I further press the shift key again to get at the |sec| |csc| |cot| etc.

Some of the initial menu and key layout was designed before things were advanced enough to get a good feel of the "weight" of each menu. I decided to postpone keyboard and menu reorganization until I had a way to make the keyboard fully configurable (not just with user mode), which happened in 0.8.4, released today. And we finally have y^x back as an unshifted key ;-)

Quote: But those functions seem rare enough that they could instead get buried under the Math menu somehow with no direct key. I wonder if maybe [HYP] and [TRIG] could be consolidated. I'd be surprised if either one is frequently used.

Menu consolidation can only happen once I know how many things there are in each menu. In 0.8.4, I consolidated integration and differentiation menus, for example. In earlier releases, I removed the I/O menu to make room for the more useful List menu, because I noticed that the Files menu was empty (and may remain that way on SwissMicros devices if David does not give me access to basic programmatic features such as listing files ;-).

Quote:Now, maybe you have bigger plans for this somehow -- like perhaps that menu will eventually be used for CAS functionality like the [TRIG] key on the 50g.

Yes, that's the idea, but circular or hyperbolic rewrites CAS functions do not exist yet.

Quote: Or maybe this is all part of a cohesive submenu system under the [MAIN] menu, where all commands will eventually reside, and different keyboard layouts (which may not even have [SIN] [COS] [TAN] keys) will have to be accommodated,

That too. My thinking was to remove friction against someone using SIN COS and TAN keys in user mode, among other things.

Quote: but if so I wonder if it may be better to still try to optimize the limited keyboard we have to not have too many redundancies. Especially when we have such a shortage of keys, I am not sure if it makes sense to have something that would see such infrequent use on a hard key.

To be honest, I'm glad to have a shifted key I think I can remove if I need to :-)

Quote:Similarly, everything in the unshifted [MAIN] menu already exists as a separate (shifted) key on the actual keyboard, so although it does show a cohesive single place with perhaps the main functionality, it just ensures everything else under [MAIN] is yet another keystroke away — but again, many of the [Shift] and [Shift][Shift] options on [MAIN] are already on shifted keys on the main keyboard too.

The same rationale as above: remove the friction to reassigning the shifted menu keys for the menus you need the most, whether it's globally by having your own keymap file or on a per-directory basis with user mode key assignments.

Also, redundancy of menu access paths is by design. It facilitates discovery of related features. One of the things that frustrates me with the HP48 or HP50 is that you have to remember the exact menu where something is. When you don't use the calculator daily, that memory fades out pretty quickly. Not to mention when you alternate between HP48 and HP50 which do not put them in the same spot.

Quote: I think everything but |UI| (which is also under [MODES], and double-shifted under [DISP]) has a dedicated key on the physical keyboard, making [MAIN] seem nearly redundant. Maybe get rid of [MAIN] entirely and just replace it with [UI] so everything is handled?

By default, [UI] is now on the right shift of [MODES] (where [OBJ] was, which was moved next to [LIST]).

[MAIN] is where a newcomer can start exploring. To me, it's a very important entry point into the calculator, and I don't mind redundancy at all, on the contrary. And also, same rationale as above: redefine menu keys the way you want because you know that [MAIN] is another way to access everything you rarely use.

Quote: But this just makes me wonder if maybe menus should be reorganized in such a way that even if you want to have redundances with things in menus that are also on the keyboard itself (which makes sense if everything under [HOME] is supposed to be a hierarchically-organized list of all commands available just like [CAT] is an alphabetically-organized list of all commands), perhaps menus should prioritize commands that are *not* already on the keyboard as the first 6 (available unshifted in the menu), and then leave the redundant ones on the double-shifted or single-shifted planes in that menu.

Menu layout optimization is something that I am doing incrementally, but it's far from finished. That being said, given the philosophy / design rationale of allowing people to customize the calculator to their needs, the current menu layout may make a little more sense.

Quote:Maybe I haven't found it yet, but I'd also like to see a shortcut for switching between real and approximate mode.

While there is a compatiblity mode for numerical results (flag -2), it's indeed not easily accessible. Real and approximate are not intended to be "modes" in DB48X, but different object representations. Some values are exact, some are approximate. 1/3 is a true fraction (exact), 0.33333 is a decimal value (approximate).

You switch between them using the `Cycle` command bound on [EEX] (or [x10^x] on my keyboard images). Like the space / EVAL key, its role is different when editing and when you are just looking at the stack.

- When you are editing and are after a number, it enters the exponents separator, e.g. type [1] [EEX] [3] [2] to enter 1E32.

- When you are editing and are in a unit, it changes the scale for the unit. So if you entered [3] [UNITS][LENGTH][m], the command line is now showing 3_m, and if you type [EEX] you get 3_km, then 3_Mm, then it cycles though other scales like mm, cm, etc.

- When you are not editing, the Cycle command applies to objects on the stack. For decimal numbers and fractions, it cycles between the two. so [1][.][2][ENTER][EEX] gives you 1 1/5, and [3][ENTER][2][/] gives you 1 1/2, which [EEX] converts to 1.5.

- The Cycle commands has other important cycles, like polar <-> rectangular, or changing the scale of a unit value while preserving its absolute value (unlike during data entry), so if you have 1.5_m on the stack and hit [EEX] you get 15._dm, then 150._cm, and so on.

This is shown at 41:09 in the Stuttgart video.

Quote: It seems like it's buried quite deep in the menus. I really like this feature in the 49/50 where switching between the modes (RightShiftHold-Enter) is as easy as converting a number from a fraction to a decimal (RightShift-Enter). But I guess the lack of a [→NUM] key makes it less obvious where this would go.

[→NUM] is [Shift][1]. The mnemonic way coming from the HP42 / DM42 is to remember "ASN" as "As Number" instead of "Assign" :-)

Quote:The alpha plane has no accent-keys like the 48/49/50 (at least not that I have yet discovered) making it not possible to type letters with diacritical marks without using the [CHAR] menu, but maybe in the real world that really isn't relevant since it seems unlikely anyone would be trying to type long strings of text in here (like one might have in the 48) anyway.

Hey, I'm French, you don't think I would have left accents out, do you? :-)

I found it hard to remember where the accents were on the 48/49/50, plus it did not scale well to other languages, so the approach taken in DB48X for diacritics is the "character catalog".

Say that you want to enter text "L'été où être naïf, ça m'a couté", the key sequence is

[Shift][Shift][ENTER] @ Text entry
[L][Shift][Shift]['()] @ L'
[Shift][ENTER] @ Shift to lowercase
[E] @ L'e
[+] @ Show character catalog
[F5] @ Select é
[T][E][F5] @ L'été
[SPC][O][U][F4] @ L'été où
[E][Shift][F1] @ L'été où ê
[T][R][E][SPC][N][A] @ L'été où être na
[I][Shift][F2] @ L'été où être naï
[F][.][SPC][C][F4] @ L'été où être naïf, ç

and so on.

Quote:I think it would be more useful in the header to show the status of various modes in the place of where it currently just says "DB50X".

It only says DB50X if you have not loaded a state file, otherwise the name of the state file shows up there.

Quote: For example, the current angle mode (degrees/radians), along with an indicator of exact vs approximate.

The 'Header' special variable can be used for that.

Code:

«
    'ANGLEMODE' RCL " " +
    IF -3 FS? THEN "Approx" ELSE "Exact" END +
»

It is per-directory, so you can have different headers based on where you are in the hierarchy.

Quote: I see there is a “not yet implemented” for the rectangular/polar/spherical mode, so when that is implemented maybe that could be indicated, too, though I’m not sure the necessity of that when you already distinguish between them with different object types (which is also a nice touch).

After implementing different object types for polar and rectangular, I have not yet found an operation where the result could not be deduced from inputs alone, so at the moment it looks like these modes will be dropped entirely, much like the polar / rectangular modes for complex numbers.

Quote:I completely agree with your abandonment of 48/49/50 source code compatibility in favor of trying to do things the "right" way this time around. Honestly there are very few programs written for the 48/49/50 that I would probably want to run on the DB50X — most of the best programs there were either to reimplement what the 48 did poorly/slowly, to add functionality that nowadays would be better served by a phone (like PIM functionality or games), or are already implemented better (or presumably will eventually be implemented better) in DB50X. Your planned future functionality (MatrixWriter, EquationWriter, some CAS features) would pretty much remove any need for things I relied on third-party programs (like MetaKernel) on the 48 for.

I'm sure I'll come up with more, but that's probably enough for now! DB48X really excites me and i can't wait to have it in a more convenient format than just a web app. All in all, I am extremely amazed with what you have put together, and so far it's really turning out to what the 48SX (HP's most elegant calculator IMHO) should have been when it first came out, had technology been advanced enough at the time.

Thanks a lot for the feedback.

[c3d]

(11-09-2024 10:42 AM)ben.titmus Wrote:  I have to admit I was originally quite sceptical about DB48x when I heard about it because I know how much work is involved in developing a calculator due to my involvement in WP43. I think you've done an amazing job though.

Thanks!

Quote:I thought I would correct one comment that you made though.

I stand corrected, and it's nice to hear it from people who were there.

It does not quite explain why SwissMicros changed their attitude towards me around that time, though.

[ben.titmus]

(11-11-2024 12:12 PM)c3d Wrote:  It does not quite explain why SwissMicros changed their attitude towards me around that time, though.

I'm afraid it explains it rather well if you think about it. They were burned with one Open Source project so naturally they will be a lot more cautious about trying another one. Remember that it cost Michael money to make the prototypes for WP43 (as well as opportunity cost).

My guess (and it is just a guess) is that Michael would be willing to consider building hardware for db48x at some point in the future.

If I can give some advice based on issues from the WP43 negotiations...

Don't be precious about insignificant details that nobody other than you will care about. You seem to be very insistent on the name of the calculator in earlier posts on this thread. But remember that Michael has many other calculator offerings and your calculator name will need to fit in there. If you have a number that was used by HP then people may expect the same functionality and interface. If you pick a higher number people might expect more functionality. This is one of the silly issues that almost derailed WP43. You may really care about the name, but almost everyone else would much rather have a physical calculator and they won't care what the name of it is.

Make sure that there won't be significant changes to the keyboard layout in the future. For example, I personally don't like the layout of any of the HP RPL calculators because they prioritise trig functions so much which is fine for certain applications, but not for every application. But more importantly it's quite a deviation from HP RPL calculators (and also the number of functions on db48x) to have a single shift key. Note that R47 (the physical version of C47 that is in the pipeline) which created the single shift key with two shift functions will have two physical shift keys.

I'm more than happy to privately discuss anything that came up with WP43 discussions that might assist your db48x discussions. And I would very much like a SM RPL calculator!

[rprosperi]

Thanks Christophe for the long and detailed replies to feedback posts, especially noting your reply to Eric's message. It takes a LOT of time to reply in such detail and the comments are very helpful for folks trying to understand both DM48/DM50 operation and your philosophy driving decisions.

Like others, I am amazed and thoroughly impressed with how much you have achieved, and look forward to watching it mature. Keep going!

[Jase]

(11-11-2024 01:41 PM)rprosperi Wrote:  Thanks Christophe for the long and detailed replies to feedback posts, especially noting your reply to Eric's message. It takes a LOT of time to reply in such detail and the comments are very helpful for folks trying to understand both DM48/DM50 operation and your philosophy driving decisions.

Like others, I am amazed and thoroughly impressed with how much you have achieved, and look forward to watching it mature. Keep going!

I don't see how Christophe does it! Does the man even sleep!??
"Impressed" is an understatement.

[c3d]

(11-11-2024 02:49 PM)Jase Wrote:  

(11-11-2024 01:41 PM)rprosperi Wrote:  Thanks Christophe for the long and detailed replies to feedback posts, especially noting your reply to Eric's message. It takes a LOT of time to reply in such detail and the comments are very helpful for folks trying to understand both DM48/DM50 operation and your philosophy driving decisions.

Like others, I am amazed and thoroughly impressed with how much you have achieved, and look forward to watching it mature. Keep going!

I don't see how Christophe does it! Does the man even sleep!??

Not very well these days. Hacking db48x at night is my way of coping with a complicated personal situation. Let's make something good out of something bad ;-)

Quote:"Impressed" is an understatement.

[c3d]

(11-11-2024 12:55 PM)ben.titmus Wrote:  

(11-11-2024 12:12 PM)c3d Wrote:  It does not quite explain why SwissMicros changed their attitude towards me around that time, though.

I'm afraid it explains it rather well if you think about it. They were burned with one Open Source project so naturally they will be a lot more cautious about trying another one. Remember that it cost Michael money to make the prototypes for WP43 (as well as opportunity cost).

That makes sense.

Quote:My guess (and it is just a guess) is that Michael would be willing to consider building hardware for db48x at some point in the future.

Well, maybe I should give it another shot, but so far, he does not seem to have been too warm to the idea. I don't want to insist to the point of alienating them.

Quote:If I can give some advice based on issues from the WP43 negotiations...

Don't be precious about insignificant details that nobody other than you will care about. You seem to be very insistent on the name of the calculator in earlier posts on this thread.

I'm a bit curious about what gave you this impression. I thought I made it clear that I did not care and that SwissMicros would be in charge of the naming (and that this was not the point of the poll), e.g.

Quote:I have thought about DM51 when writing the poll, actually :-). I think it is important to recognize that DM in the name are the initials of the company founders, so I'd rather keep that for their hardware. Of course, if they were OK with the idea of prefix change, then I would feel honored, but the recognition goes both ways.

What I meant here is that I expected the physical device to be named "DMsomething" and not "DBsomething" or "CDsomething". To me, there is no direct connection between the device name and the application name, just like an iPhone 16 can run DB48x or DB50x. That, I thought, also clarified that I was open to using another number like 51. I actually refer to a future scaled down DB35x elsewhere in the thread.

I did explain elsewhere why I had chosen DB48x as a name, and why it works for me, but this was not intended as a push back against a SwissMicros product name suggestion.

Quote: But remember that Michael has many other calculator offerings and your calculator name will need to fit in there. If you have a number that was used by HP then people may expect the same functionality and interface. If you pick a higher number people might expect more functionality. This is one of the silly issues that almost derailed WP43. You may really care about the name, but almost everyone else would much rather have a physical calculator and they won't care what the name of it is.

Again, I could not care less. They could call it JB007 for all I care ;-)

Quote:Make sure that there won't be significant changes to the keyboard layout in the future. For example, I personally don't like the layout of any of the HP RPL calculators because they prioritise trig functions so much which is fine for certain applications, but not for every application. But more importantly it's quite a deviation from HP RPL calculators (and also the number of functions on db48x) to have a single shift key. Note that R47 (the physical version of C47 that is in the pipeline) which created the single shift key with two shift functions will have two physical shift keys.

As far as I am concerned, we are very close to a final layout for the keyboard on a device with 8 rows of keys.

This would have to be revisited if SwissMicros could, at a reasonable cost (to them) build a device with 9 rows of keys like the HP48. In that case, the expectation would obviously be to mimic the HP48 key layout rather than the HP42.

It's not as obvious as it seems. Some of the choices that I made in the context of a DM42/DM32 would have to be revisited, notably the fact that function keys are not alphabetical. For example, the "character catalog" feature requires function keys to be "free" for menu use during alphabetic entry. This is not true on the HP48, where F1-F6 are for A-F. For the same reason, the hexadecimal entry optimization would not work either.

Quote:I'm more than happy to privately discuss anything that came up with WP43 discussions that might assist your db48x discussions. And I would very much like a SM RPL calculator!

There are no db48x on SM discussions at the moment, except on the forums. The polls were intended to have some data before potentially restarting them, but I have not reinitiated contact with David or Michael on that topic.

[JohnHind]

Seems to me this would be a lot easier if we did not need to have a fixed key layout with tooling costs per design, but different layouts could be swapped in and out of the same basic calculator frame as easily as firmware can be changed. It is now possible to get PCBs made from CAD files in very low volumes very cheaply (effectively zero tooling cost). Some makers have used this to produce 'PCB Art' and these techniques could be adapted to produce key label artwork. Until recently, this would be limited to one colour (the 'silk screen' layer on the PCB) plus gold (plated copper layer), but recently full colour screening has become available.

One problem is you cannot have markings on the key top only on the surround (like an overlay). One way round this is to use 'tactile buttons' with small round actuators that stand proud through holes in the PCB plane. Although the button is very small, it feels quite good because it clicks in flush with the PCB surface and does not feel harsh.

It is possible to use two parallel PCB planes with one forming the legend surface and the other the matrix wiring and mounting for the switches, but recently I discovered 'reverse mount tactile switch buttons' (for example, from Adafruit). These solder to one side of a PCB with the actuator on the bottom protruding through a hole in the same PCB, so the artwork would be on the other side.

With this approach, it would be possible to produce low volume customisations which changed both the legends and also the number and layout of the keys. The customer could easily experiment with different 'personalities' without having to buy a complete new calculator or compromise the layout to use a design intended for a different personality. Ambitious end users would even be able to design their own layouts using programability and layout customisation features in a particular firmware.