DB48X: HP48-like RPL implementation for DM42

[c3d]

(12-11-2024 09:47 PM)battlecoder Wrote:  

(12-11-2024 05:07 PM)n1msr Wrote:  I did wonder if there is a setting I could make in the DB48X calculator to change the way the functions behave, i.e. accept Real Numbers as well as, or instead of Real Integers?

This is an interesting problem. I've not used the DB48X much (yet! waiting for a DM42n and overlay to arrive) but it could be implemented like some programming languages do; If a function expects a parameter of type T, but a parameter of type P is supplied, it would check if there's an straightforward conversion from P->T, and apply it automatically to the input.

RPL is a highly polymorphic language, where the exact conversions that are allowed are really per command, and not really consistent across HP models.

So in that context, any kind of implicit conversion is practically out of the question. This is even more true for conversions that would lose value, like decimal to integer. FIX, for example, accepts 2.3 as input, and truncates it to 2. FACT, on the other hand, does not truncate fractional input, and clearly should not.

[Orome]

(12-11-2024 10:42 PM)c3d Wrote:  Among the problems that I am aware of:

1) I have not found a way to use the same directory across variants of the application. This is probably only a concern to me, but iOS treats DB48x and DB50x as two entirely distinct applications, even if they share the same file types. According to the documentation, one application should be able to read the documents from the other, but so far, it does not work.

2) The data directories sometimes disappear until you reboot your device. This notably happens when you upgrade (or, in my case, when I install a new version, but not every time).

3) iCloud directories created by one version of the application may become inaccessible by the next version of the same application (this is the "operation not permitted" you saw). What is really weird about this one is that if I start an iPhone simulator from scratch and connect it to my iCloud account, then I can access the directory, but not if I reuse a simulator where the previous version had been installed.

So in short, at the moment, iCloud support is very theoretical. When it works, it works well and you can sync your state files across multiple devices (even an iPhone and iPad in my case), but it sometimes goes boom for reasons that I don't understand yet. Sometimes, just restarting the iPhone fixes the problem, but it seems absolutely insane that you would have to do that.

I'm doing something wrong in the code, but I don't know what yet.

That's a very helpful summary, and coincides exactly with what I'm seeing.

FWIW, what I do to sync macOS and iOS is just use iCloud as a depot and copy and past through their to/from the respective sandboxed folders. (Sometimes I can directly maintain state in macOS in iCloud, but not reliably.)

[n1msr]

The DB48X project is ongoing and interesting.

I wanted to try an alternative font or two and this is relatively easy given that the release for the calculator can be obtained from Github (thank you c3d).

There are potential copyright issues with some fonts, so I am ignoring that here, because many are free for private use. What I am interested to know is if there is a deterministic way to get the parameters for the ttf2font code (in the build for db48x) that takes a TTF file and creates a set of four ".cc" file as per the Makefile (lines 182 through 189).

The three parameters are below (specified in ttf2font in the tools directory). You can see them used in the Makefile after the BASE_FONT is specified. In the release, the BASE_FONT is FogSans-ddd.ttf.

-s: this is the fontSize - this is the place to start I think, and then adjust the next two parameters to make the fontSize work for the calculator display.
-S: heightPict (this is also described as scaling)
-y: yAdjustPixles (this always needs some adjusting from -10 through 0 to +10 based on my experience with the fonts I have used so far. It keeps the bottom of the characters towards the base or the floor of the display space they occupy (e.g. in the softkey and the stack displays).

I have to play about with the numbers to get something that eventually "fits" the four calculator fonts: Stack, Editor, Reduced (the softkeys I think) and Help. Luckily the sim[ulator] can be used for preliminary testing, which is quite quick. I would prefer that when I try a new font, I get to a working set of parameters quicker than I do :-)

If you have any hints/tips from your experience, please share them. Thank you.

[c3d]

(12-16-2024 02:17 PM)n1msr Wrote:  The DB48X project is ongoing and interesting.

I wanted to try an alternative font or two and this is relatively easy given that the release for the calculator can be obtained from Github (thank you c3d).

There are potential copyright issues with some fonts, so I am ignoring that here, because many are free for private use. What I am interested to know is if there is a deterministic way to get the parameters for the ttf2font code (in the build for db48x) that takes a TTF file and creates a set of four ".cc" file as per the Makefile (lines 182 through 189).

The three parameters are below (specified in ttf2font in the tools directory). You can see them used in the Makefile after the BASE_FONT is specified. In the release, the BASE_FONT is FogSans-ddd.ttf.

-s: this is the fontSize - this is the place to start I think, and then adjust the next two parameters to make the fontSize work for the calculator display.
-S: heightPict (this is also described as scaling)
-y: yAdjustPixles (this always needs some adjusting from -10 through 0 to +10 based on my experience with the fonts I have used so far. It keeps the bottom of the characters towards the base or the floor of the display space they occupy (e.g. in the softkey and the stack displays).

I have to play about with the numbers to get something that eventually "fits" the four calculator fonts: Stack, Editor, Reduced (the softkeys I think) and Help. Luckily the sim[ulator] can be used for preliminary testing, which is quite quick. I would prefer that when I try a new font, I get to a working set of parameters quicker than I do :-)

If you have any hints/tips from your experience, please share them. Thank you.

I don't think there is any magic trick, which is why I had to add these parameters. Turning an outline font into a small-size bitmap is an art form. As you and I discussed elsewhere, the C47 team went through the trouble of pixel-editing their fonts, which makes them look a little better, but then much harder to modify, reuse or extend.