Post Reply 
DB48X: HP48-like RPL implementation for DM42
11-17-2024, 02:17 AM
Post: #441
RE: DB48X: HP48-like RPL implementation for DM42
(11-16-2024 11:13 AM)raprism Wrote:  Is there a possibility to call Edit action of stack menu programmatically with input of var name?

Then it might be possible to create a Cst Entry EDIT to modify any variable name (like 'CST' itself ...) in any directory, edit it directly and saving it automatically in current directory (either overwriting or creating a new one, if original variable was looked up at higher directory levels).

The EDIT command edits what is on the stack, but for a name it edits the name, not the content of the variable.

I think that what you are asking is for the VISIT command, which is not implemented yet.

DB48X,HP,me
Find all posts by this user
Quote this message in a reply
11-17-2024, 02:43 AM
Post: #442
RE: DB48X: HP48-like RPL implementation for DM42
I have not seen any of these issues with current version.

(11-12-2024 10:34 PM)c3d Wrote:  
(11-12-2024 07:44 PM)grbrum Wrote:  Hello Christophe. I had a bug with convert function.

this simple example:
1_m/min
1_ft/s
I run << CONVERT >> from the CAT

I get correct result = 0.05468....
I get error: "Convert Error: Too few arguments"

if I run << CONVERT >> from CONV menu (2shift 5) I don't get errors.

running 0.8.3 (i did not have opportunity to install the latest version, but I read the change notes and did not see if this was reported before).

This may not be obvious, but in my opinion this is most likely this one from the release note:

* Fix a problem when a garbage collection while parsing a fraction could cause a large fraction of the subsequent program to be skipped. This normally led to anomalous `Inconsistent units` messages when this caused a unit such as `254/10_mm` for `in` to be incorrectly parsed as `254/10`.

Because the problem was a maladjusted pointer, other symptoms were possible.

Quote:PS, I had another bug that I am trying to reproduce.
It went something like: I had a simple unit in stack, maybe other units were there as well.
such as 1_m/min

I added a name variable (I remember clearly being 'a') then I don't remember if I entered or direclty clicked STO.
the result was that all levels of the stack were populated by a. I had to restore the state file.
If I can replicate the bug I will post here.

thank you.

This one is extremely weird. I hope that you can replicate to give me a chance to fix it.
Find all posts by this user
Quote this message in a reply
11-17-2024, 03:32 AM
Post: #443
RE: DB48X: HP48-like RPL implementation for DM42
(11-12-2024 11:02 AM)c3d Wrote:  
(11-12-2024 10:44 AM)nickapos Wrote:  Thanks for that
I managed to do 1_cl in alpha but not in transient. All i get is 1_c*l i am sure i am missing something here.

Here is the key sequence that works for me: [1][Hold Right][-][C][L][Release Right]. The unit prefix _ is available in transient alpha for both left and right because there are both upper and lowercase units. So for example, 2_MB can be entered with [2][Hold Left][-][M][B][Release Left]. Of course, if you want 2_MiB you are out of luck and need the more touchy [2][Hold Left][-][M][Release Left][Hold Right][I][Release Right][Hold Left][B][Release Left]. Still "relatively" fast.

Let me know if it still fails for you.

Quote:Christophe when you mention EEX i assume you are referring to x10^n button in the app?

Correct.
Hi Christophe, I did not know that you can do hold right or left and add underscore with -. This makes everything so easy. Thank you very much
Find all posts by this user
Quote this message in a reply
11-17-2024, 12:10 PM (This post was last modified: 11-17-2024 12:10 PM by raprism.)
Post: #444
RE: DB48X: HP48-like RPL implementation for DM42
(11-17-2024 02:17 AM)c3d Wrote:  
(11-16-2024 11:13 AM)raprism Wrote:  Is there a possibility to call Edit action of stack menu programmatically with input of var name?

Then it might be possible to create a Cst Entry EDIT to modify any variable name (like 'CST' itself ...) in any directory, edit it directly and saving it automatically in current directory (either overwriting or creating a new one, if original variable was looked up at higher directory levels).

The EDIT command edits what is on the stack, but for a name it edits the name, not the content of the variable.

I think that what you are asking is for the VISIT command, which is not implemented yet.

Yes, it seems to be the VISIT command I didn't know before. I recognize it on your implemented / to-do list for 1.0 release, and looking forward. Thanks for your response!
Find all posts by this user
Quote this message in a reply
11-17-2024, 12:31 PM
Post: #445
RE: DB48X: HP48-like RPL implementation for DM42
(11-17-2024 02:03 AM)c3d Wrote:  
(11-16-2024 11:23 AM)raprism Wrote:  If there is an error on DM42, EXIT kills the error state / message rather immediately. If I use the simulator on Linux (made with make sim with libraries similar to current fedora setups) I have to wait 30 seconds to be able to kill this error state (with message). How to disable this ineffective behaviour? Or is it problem not occuring on Mac or Windows?

There is a sound configuration problem causing Qt to not be able to play sound correctly in some cases, but take forever to fail. That sounds very similar to what you describe.

If that's what it is, just using the setup or UI menu to disable beep (you can use screen flash as an alternative) should fix the problem for you.

Great - disabling beep is the solution.

Could be seen as a showstopper, because if one is not used to RPL, the "Too few arguments" error is your friend (or enemy). So if it is possible to disable beep by default for sim, this might help people trying db48x out.

But I do not know, if this happens on Windows, too. If binaries would be made available for that OS, this is probably the easiest and most popular entry, if one wants to get some normal usage experience with keeping states (otherwise wasm on your web site is even easier).
Find all posts by this user
Quote this message in a reply
11-17-2024, 01:30 PM
Post: #446
RE: DB48X: HP48-like RPL implementation for DM42
(11-12-2024 12:35 PM)Dashier Wrote:  I attempted to install DB50x V0.8..5 and my DM32 crashed when running the qspi file with a "hard fault". Pressing EXIT failed again as did pressingt the reset button on the back.

Code:

Oops, I've crashed! Please try
To reproduce it, then report the
Steps taken and following info:

Hard Fault
 R0=00020008  r1=200087c0
 R2=9002d4a8  r3=00020008
R12=ffffeeee  lr=081317e3
 Pc=0814818c psr=21000200

Press EXIT to RESET the calculator...
Have I bricked my DM32, or is there a recovery method?

Crossing my fingers.
--David

Given that someone besides me encountered this problem, I added a protection. This situation is now detected at launch, and the program just refuses to launch, asking you to load the QSPI and PGM from the exact same build.

Coming in the release I plan to make today.

DB48X,HP,me
Find all posts by this user
Quote this message in a reply
11-17-2024, 01:50 PM
Post: #447
RE: DB48X: HP48-like RPL implementation for DM42
(11-17-2024 12:31 PM)raprism Wrote:  
(11-17-2024 02:03 AM)c3d Wrote:  There is a sound configuration problem causing Qt to not be able to play sound correctly in some cases, but take forever to fail. That sounds very similar to what you describe.

If that's what it is, just using the setup or UI menu to disable beep (you can use screen flash as an alternative) should fix the problem for you.

Great - disabling beep is the solution.

Could be seen as a showstopper, because if one is not used to RPL, the "Too few arguments" error is your friend (or enemy). So if it is possible to disable beep by default for sim, this might help people trying db48x out.

But I do not know, if this happens on Windows, too. If binaries would be made available for that OS, this is probably the easiest and most popular entry, if one wants to get some normal usage experience with keeping states (otherwise wasm on your web site is even easier).

It does not happen in all cases on Linux either. Depending on the machine, I've seen one of three behaviours:

- No sound but quick exit. This is the case if you run the simulator over X11 for example. In my case, I also get a "Underrun occurred". This seems to be the case also if there is really no sound card at all.

- No sound but very slow exit. It's not very clear why it takes Qt so long to detect that it does not know how to play sound. I have not reproduced locally yet, but you are the second person to report the issue IIRC. Maybe if you could open an issue and provide the output of lspci -v on your machine, we can dig further.

- Simulated sound works as it should. This is the case on those of my Linux machines that have a sound card. For example, on my Lenovo Thinkpad running Fedora 41 (but same with earlier releases), sound works just fine.

So I don't want to disable sound for everyone running Linux on the basis that a few have an issue that AFAICT is a relatively well known Qt issue. I would like to address the issue, so let's use the proper channel (https://github.com/c3d/db48x/issues) and see if can figure it out.

DB48X,HP,me
Find all posts by this user
Quote this message in a reply
11-17-2024, 01:52 PM
Post: #448
RE: DB48X: HP48-like RPL implementation for DM42
(11-17-2024 01:50 PM)c3d Wrote:  So I don't want to disable sound for everyone running Linux on the basis that a few have an issue that AFAICT is a relatively well known Qt issue. I would like to address the issue, so let's use the proper channel (https://github.com/c3d/db48x/issues) and see if can figure it out.

One thing I can do in the meantime is add a command line option (or environment variable) to disable sound, to make it easier for people who have the problem.

While we are at it, Qt also has trouble figuring out scaling factors for high-DPI screens in a few cases. One known scenario to me is running over X11 to XQuartz with a 4K display. The workaround in that case is to pass the -s 2 option.

DB48X,HP,me
Find all posts by this user
Quote this message in a reply
11-17-2024, 02:24 PM
Post: #449
RE: DB48X: HP48-like RPL implementation for DM42
(11-17-2024 01:52 PM)c3d Wrote:  
(11-17-2024 01:50 PM)c3d Wrote:  So I don't want to disable sound for everyone running Linux on the basis that a few have an issue that AFAICT is a relatively well known Qt issue. I would like to address the issue, so let's use the proper channel (https://github.com/c3d/db48x/issues) and see if can figure it out.

One thing I can do in the meantime is add a command line option (or environment variable) to disable sound, to make it easier for people who have the problem.

While we are at it, Qt also has trouble figuring out scaling factors for high-DPI screens in a few cases. One known scenario to me is running over X11 to XQuartz with a 4K display. The workaround in that case is to pass the -s 2 option.

Issue #1351 created for beep on error Qt problem. Luckily I have no HiDPI issue ...
Find all posts by this user
Quote this message in a reply
11-17-2024, 02:43 PM
Post: #450
RE: DB48X: HP48-like RPL implementation for DM42
(11-17-2024 02:14 AM)c3d Wrote:  
(11-16-2024 11:04 AM)raprism Wrote:  [...]
The unit cycling during input mode currently (todays dev) does only work with single letters, but not with multiletter units or e.g. Ω or °.

Should be fixed on dev now.

I read that a new release will take place today. Nevertheless for people interested to compile snapshots on Linux the attached zsh script might be of help:

- checks if DM42 has activated USB Disk
- script toggles available to disable simulator builds and/or test DMCP building w/o transfers to DM42
- uses specific 10.3 arm-none-eabi version (newer compiler versions on my system give errors on DM42 with local variables programs ..., see issue #1286 on Github)
- resetting locally changed versioned file related to CRC

I still have to perform git reset --hard after builds to be able to pull new versions. This could be due to inconsistent line endings.

There are 3 lines specifically for zsh usage. If you use the simpler version, then e.g. bash can be also used.


Attached File(s)
.txt  update_db48x.sh.txt (Size: 2.66 KB / Downloads: 7)
Find all posts by this user
Quote this message in a reply
11-17-2024, 06:20 PM
Post: #451
RE: DB48X: HP48-like RPL implementation for DM42
(11-17-2024 02:43 PM)raprism Wrote:  
(11-17-2024 02:14 AM)c3d Wrote:  Should be fixed on dev now.

I read that a new release will take place today. Nevertheless for people interested to compile snapshots on Linux the attached zsh script might be of help:

- checks if DM42 has activated USB Disk
- script toggles available to disable simulator builds and/or test DMCP building w/o transfers to DM42
- uses specific 10.3 arm-none-eabi version (newer compiler versions on my system give errors on DM42 with local variables programs ..., see issue #1286 on Github)
- resetting locally changed versioned file related to CRC

I still have to perform git reset --hard after builds to be able to pull new versions. This could be due to inconsistent line endings.

There are 3 lines specifically for zsh usage. If you use the simpler version, then e.g. bash can be also used.

Thanks. Here are a few things I would change to your script:

You need to run the build twice only if the CRC fails, so I would rewrite:

Code:

# perform make and ignoring error
make OPT=$OPT CC=$CC CXX=$CXX AS=$AS OBJCOPY=$OBJCOPY AR=$AR SIZE=$SIZE || :
# 2x for CRC
make OPT=$OPT CC=$CC CXX=$CXX AS=$AS OBJCOPY=$OBJCOPY AR=$AR SIZE=$SIZE

as

Code:

# perform make and ignoring error (2x if CRC computation fails)
make OPT=$OPT CC=$CC CXX=$CXX AS=$AS OBJCOPY=$OBJCOPY AR=$AR SIZE=$SIZE || \
make OPT=$OPT CC=$CC CXX=$CXX AS=$AS OBJCOPY=$OBJCOPY AR=$AR SIZE=$SIZE

There is already an install procedure, all you need is to provide the mount point. I would use it instead of that part of your script, because it will stay up to date as new files are added to the distribution. So I would replace:

Code:

cp db48x.pgm ${DMCP_RELDIR}/db48x_qspi.bin ${MNTDIR} & progress -mp $!

for d in {${MNTDIR},${BINDIR}}; do
  # before all directory names on DM42 were changed to lower case
  mkdir -p ${d}/help ${d}/state
  cp help/db48x.md help/*.bmp ${d}/help & progress -mp $!
  cp -r help/img ${d}/help & progress -mp $!
  #
  # # simpler version (works also for bash)
  # cp -r config/* ${d}/config & progress -mp $!
  # # zsh variant
  # # DO NOT OVERWRITE keymap.cfg
  setopt extendedglob
  cp -r config/^keymap.cfg* ${d}/config & progress -mp $!
  unsetopt extendedglob
  #
  cp -r library ${d} & progress -mp $!
  cp state/Demo.48S ${d}/state & progress -mp $!
done # for

with something like:

Code:

make install MOUNTPOINT="$MNTDIR" EJECT="udisksctl unmount -b ${BLKDEV}"

For dm32, replace install with dm32-install.

DB48X,HP,me
Find all posts by this user
Quote this message in a reply
11-17-2024, 06:49 PM
Post: #452
RE: DB48X: HP48-like RPL implementation for DM42
(11-17-2024 06:20 PM)c3d Wrote:  [...]
Thanks. Here are a few things I would change to your script:

You need to run the build twice only if the CRC fails, so I would rewrite:
[...]

I believe CRC was always failing for me, but in general your proposal is more logic. (Could be though that I had to wrote it that way to avoid stopping whole script in bash on CRC error.)

Usage of ready-made install routine in Makefile (with proper settings of variables as shown by you) would be fine for me, if there would be a way to keep own settings, and also in place used. In particular this is currently the keymap.cfg for me, but e.g. units.csv might be also worth to keep own versions in future.

Would it be an idea to distribute default settings in a sub directory defaults of config, so that config/defaults/{keymap.cfg,units.csv,...} are used, if there is no custom file like e.g. config/keymap.cfg ?
Find all posts by this user
Quote this message in a reply
11-17-2024, 11:23 PM
Post: #453
DB48x v0.8.6: Bug fixes and help improvements
Release v0.8.6 is out.

This is a bit of a pot-pourri of bug fixes, improvement, on-line help corrections and relatively minor features suggested on this forum.

(This was a short week-end for me).

Notably not there yet: significant additions to the equations library contributed by Jean Wilson, mostly by lack of time for testing them.

DB48X,HP,me
Find all posts by this user
Quote this message in a reply
11-18-2024, 08:01 AM (This post was last modified: 11-18-2024 08:04 AM by c3d.)
Post: #454
RE: DB48X: HP48-like RPL implementation for DM42
Replying here to a private message containing bug reports.

Narek Wrote:Hi,
Thank you for your great work and effort I am enjoying your creation.
I'm facing some issues and suggestions using using db48x on my dm42n that I would like to repport.

1- In plot section I tried to use Xrange and Yrange option and when I indicated value (like 5) tge graph was not showing anymore and also everytine I tried to plot a function my screen turned to black. I restarted my calculator fo fix it which made me re do all the customisations that I did before.

XRange any Yrange take two values. So when you say "value (like 5)" I don't understand what you mean. If I try 5 5, this gives an "Invalid plot parameters" error. If I try just 5, this gives a "Too few arguments" error.

As for restarting the calculator, I assume you tried to interrupt program execution with EXIT and it did not work? How fast did the screen turn black, was it little by little, or all at once?

Quote:2- When I tried to solve a 2 by 3 matrix and do a summation to another 2 by 3 matrix it shows me error. [[2 3 4][1 2 3]] + [[1 2 4][1 2 3]].

The issue has been fixed in 0.8.6. Please try again and report if it still fails.

Quote:Couple of suggestions:

1- After using the plot command the function gets deleted fo no reason.

Yes, it is deleted for a reason: the command consumed it ;-) See the Stuttgart talk for the philosophy behind it. The "EQ" based plotting environment does not exist yet, what exists at the moment is just the underlying commands doing the plotting in various styles.

Quote: The function is only approachable by going to hist which makes editing the equation difficult.

There are at least three other ways to recover the function: LastArg, Undo and duplicating it before running "Plot". Each of them is pretty inexpensive.

Quote:2- I suggest to have access to history of evaluated values in stack by pressing edit. For example if I evaluate this formula '1/sqrt(2)' if I press edit I will only have access to edit the final value and not the formula. This would be very helpful for people like me who are dealing with big formulas every day and making lots of mistakes.

This already exists. Here are a few ways to do it:

1. The "History" function itself contains the last 8 things you entered, including those you did not ENTER (i.e. the history is kept if you cancel a command line with EXIT). It is quickly accessible with the "transient edit" mode, i.e. you hold the right/down arrow and hit F2 to move back in history. This is the same thing as the unshifted F2 key in the EDIT menu, which moves the cursor one word to the left, but when used at the beginning of the line, moves to the previous history entry.

2. You can put various expressions on the stack and then enter the interactive stack (left / up arrow). From there, you can "Edit" any level of the stack with F6, then bring that level down to the first level with Pick, and then do whatever operation you want with it, e.g. the Function plot.

3. You can store your expression in a variable with STO, and use the VAR menu to recall / edit / store it quickly.

Quote:3- if there could be an option to modify the editing indicator which is a vertical line with a D on it to a simple '.' Or '_' that would be great.

Can you elaborate on why you think it would be great?

The 'D' plays an important role, telling you that you are in direct entry mode, i.e. pressing the 'SIN' key will execute it, and pressing the key left of the + key will insert a space. There are a few other modes, where the same 'SIN' key will behave differently:


- 'S' means it's searching, so SIN will search for the J character incrementally.
- 'L' means entering lowercase text, 'C' uppercase text, so it will insert j or J.
- 'P' means you are in program entry mode, so it will enter the text SIN with spaces around it.
- 'A' means you are in algebraic entry mode, so it will enter the text SIN() and put the cursor inside the parentheses. If you type the R/S key left of +, it will insert =
- 'E' means that you are in expression mode inside an algebraic, i.e. inside parentheses. SIN will behave like for A, the R/S key will insert a semicolon.
- 'M' means that you are in matrix mode. This mode is not fully functional yet, for the moment it's quite similar to 'P'
- 'B' means you are in based number mode (after #). The second row of keys enters ABCDEF directly for quick hexadecimal entry
- 'U' means you are in Unit mode, which means that typing the E / EEX / x10n key would insert a unit SI prefix.

The cursor also changes colour to tell you if you are in alpha mode without having to look at the top of the screen to check.

I do not fully understand why you think not having the information would be an improvement. If this is simply a matter of personal taste regarding the shape of the cursor, I invite you to submit a patch drawing the cursor the way you like it.

DB48X,HP,me
Find all posts by this user
Quote this message in a reply
11-18-2024, 09:13 PM
Post: #455
RE: DB48X: HP48-like RPL implementation for DM42
First, I want to express my gratitude to anyone involved in this project. I've been recently reading about it, and checking the web version of DB48X and I love it. I've been also watching Christophe's superb presentation (I'm like 80% done. Been watching it between breaks) and many of the annoyances and missing features in other calculators pointed out by the presenter are things that I've also noticed, but couldn't have solved as elegantly as DB48X does, even if I had decided to write programs to solve them.

The many input modes and the "smart" functions (like the space/;/eval key) are a bit intimidating but I'm sure it's just a matter of getting used to them.

I recently bought a DM42, and I have to admit it was a bit discouraging to read that the DM32 is deemed more powerful and it has its own separate build (DB50X) that while still identical to the DB48X right now, could eventually have more features. Makes me feel like I should have bought the DM32 instead Sad

So I have a couple of questions:
Are there already features that can't fit in the DM42? or are we still not "close to the limits" of the DM42 at which the DB50x(i.e: DM32) will start getting features that DB48X (and thus the DM42) will lack?

What about the DM42n? Is the DB50X going to be available on that hardware eventually?

Regards,
Visit this user's website Find all posts by this user
Quote this message in a reply
11-18-2024, 10:10 PM (This post was last modified: 11-18-2024 10:26 PM by LinusSch.)
Post: #456
RE: DB48X: HP48-like RPL implementation for DM42
I've finally arrived at the point where I try to run
Code:
make sim
but I seem to be hitting some path problems.

Code:
WARNING: Failure to find: ../recorder/recorder.c
WARNING: Failure to find: ../recorder/recorder_ring.c
WARNING: Failure to find: ../recorder/recorder.c
WARNING: Failure to find: ../recorder/recorder_ring.c

Eventually the build process stops with an error that I assume to be a result of the situation mentioned by those warnings:
Code:
make: *** No rule to make target 'recorder/recorder.h', needed by 'recorder/config.h'.  Stop.

According to instructions I'm running make from the top-level db48x directory, so looking for files in the parent directory should fail - but why is it happening? I have searched for recorder in the Makefile and tried to figure it out, seemed readable enough but I'm clearly not familiar enough with makefiles yet to solve this on my own.

Additionally, another line of output (in between the warnings and the stoppage) references a directory that does not exist in my freshly cloned copy of 0.8.6:
Code:
cat: help/db48x-images: No such file or directory

Help will be greatly appreciated but there is no need to hurry. I may or may not take an entire week to try any solution.

Edit: I guess I should have posted this in Issues on Github instead. Sorry, I started writing this post with a sense of my problem being user error rather than a bug. But now that I've written the report it looks like a bug. I can copy it to over there if you want me to.

On the upside I think I have my dependencies figured out, an update for BUILD.md to help Debian users is coming when I have a successful build.
Find all posts by this user
Quote this message in a reply
11-18-2024, 10:19 PM
Post: #457
RE: DB48X: HP48-like RPL implementation for DM42
(11-18-2024 09:13 PM)battlecoder Wrote:  What about the DM42n? Is the DB50X going to be available on that hardware eventually?

The DM42n hardware is the same as the DM32 hardware (from a coding standpoint) and as such the same software runs on both. I've seen at least one user already reporting success with that.
Find all posts by this user
Quote this message in a reply
11-18-2024, 11:41 PM
Post: #458
RE: DB48X: HP48-like RPL implementation for DM42
(11-18-2024 10:19 PM)LinusSch Wrote:  
(11-18-2024 09:13 PM)battlecoder Wrote:  What about the DM42n? Is the DB50X going to be available on that hardware eventually?

The DM42n hardware is the same as the DM32 hardware (from a coding standpoint) and as such the same software runs on both. I've seen at least one user already reporting success with that.

Yes - I have been providing DB50x overlays to several people who have the DM42n, so it definitely can be used on that hardware.

WP31S/WP34S, WP43/C47, newRPL (various), and DB48X adhesive and tabbed overlays:
https://www.hpmuseum.org/forum/thread-20113.html
Find all posts by this user
Quote this message in a reply
11-19-2024, 12:15 AM (This post was last modified: 11-19-2024 12:16 AM by raprism.)
Post: #459
RE: DB48X: HP48-like RPL implementation for DM42
(11-18-2024 10:10 PM)LinusSch Wrote:  I've finally arrived at the point where I try to run
Code:
make sim
but I seem to be hitting some path problems.

Code:
WARNING: Failure to find: ../recorder/recorder.c
WARNING: Failure to find: ../recorder/recorder_ring.c
WARNING: Failure to find: ../recorder/recorder.c
WARNING: Failure to find: ../recorder/recorder_ring.c

Eventually the build process stops with an error that I assume to be a result of the situation mentioned by those warnings:
Code:
make: *** No rule to make target 'recorder/recorder.h', needed by 'recorder/config.h'.  Stop.

According to instructions I'm running make from the top-level db48x directory, so looking for files in the parent directory should fail - but why is it happening? I have searched for recorder in the Makefile and tried to figure it out, seemed readable enough but I'm clearly not familiar enough with makefiles yet to solve this on my own.

Similar to C47 building (Wiki) the source has dependencies to submodules.

Code:

> git clone https://github.com/c3d/db48x.git --recurse-submodules
# # default is stable branch
> cd db48x
# # dev branch
> git switch dev

It's possible to 'fix' already checked out repo with git submodule

On current Ubuntu this works to get build tools and libraries:

Code:

> sudo apt install qmake6 qt6-base-dev qt6-declarative-dev qt6-multimedia-dev
# # no QMAKE variable in Makefile so far
> sudo ln -s /usr/bin/qmake6 /usr/local/bin/qmake
> make sim
Find all posts by this user
Quote this message in a reply
11-19-2024, 03:42 AM
Post: #460
RE: DB48X: HP48-like RPL implementation for DM42
(11-18-2024 10:19 PM)LinusSch Wrote:  
(11-18-2024 09:13 PM)battlecoder Wrote:  What about the DM42n? Is the DB50X going to be available on that hardware eventually?

The DM42n hardware is the same as the DM32 hardware (from a coding standpoint) and as such the same software runs on both. I've seen at least one user already reporting success with that.

Awesome! Because I was already thinking on getting a DM42n at one point!

(11-18-2024 11:41 PM)spiff72 Wrote:  Yes - I have been providing DB50x overlays to several people who have the DM42n, so it definitely can be used on that hardware.
Nice! As soon as I get a DM42n I might be placing an order of the overlay ! Although I'd assume the DM42n would use the same overlay as the DM42 and not the DM32 overlay, despite being able to run DB50x correct?
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




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