DB48X: HP48-like RPL implementation for DM42

[nickapos]

Hi, I am following the discussion and tried to compile the simulator.
I got this error:

nickapos@MacBook-Pro.local ~/t/DB48X-on-DM42 > make sim 06:48:03
mkdir -p build/DM42/release
touch build/DM42/release/.exists
echo "#define DB48X_VERSION \"0.4.1\"" > build/DM42/release/version-0.4.1.h
cp build/DM42/release/version-0.4.1.h src/dmcp/version.h
cd sim; qmake simulator.pro -o simulator.mak CONFIG+=release
Info: creating stash file /Users/nickapos/testing/DB48X-on-DM42/sim/.qmake.stash
WARNING: Failure to find: ../recorder/recorder.c
WARNING: Failure to find: ../recorder/recorder_ring.c
make: *** No rule to make target `sim/gcc111libbid-Darwin-x86_64.a', needed by `sim/gcc111libbid.a'. Stop.
nickapos@MacBook-Pro.local ~/t/DB48X-on-DM42 >

I have installed all the dependencies so I wonder what am I missing here. Can you advise please?

[gwh]

(08-10-2023 05:51 AM)nickapos Wrote:  Hi, I am following the discussion and tried to compile the simulator.
I got this error:

nickapos@MacBook-Pro.local ~/t/DB48X-on-DM42 > make sim 06:48:03
mkdir -p build/DM42/release
touch build/DM42/release/.exists
echo "#define DB48X_VERSION "0.4.1"" > build/DM42/release/version-0.4.1.h
cp build/DM42/release/version-0.4.1.h src/dmcp/version.h
cd sim; qmake simulator.pro -o simulator.mak CONFIG+=release
Info: creating stash file /Users/nickapos/testing/DB48X-on-DM42/sim/.qmake.stash
WARNING: Failure to find: ../recorder/recorder.c
WARNING: Failure to find: ../recorder/recorder_ring.c
make: *** No rule to make target `sim/gcc111libbid-Darwin-x86_64.a', needed by `sim/gcc111libbid.a'. Stop.
nickapos@MacBook-Pro.local ~/t/DB48X-on-DM42 >

I have installed all the dependencies so I wonder what am I missing here. Can you advise please?

You have to fetch the submodules. Either by

Code:

git clone --recursive https://…

or by running

Code:

git submodule init; git submodule update

(not 100% sure of the syntax but that's the idea.)

[nickapos]

(08-10-2023 08:06 AM)gwh Wrote:  

(08-10-2023 05:51 AM)nickapos Wrote:  Hi, I am following the discussion and tried to compile the simulator.
I got this error:

nickapos@MacBook-Pro.local ~/t/DB48X-on-DM42 > make sim 06:48:03
mkdir -p build/DM42/release
touch build/DM42/release/.exists
echo "#define DB48X_VERSION "0.4.1"" > build/DM42/release/version-0.4.1.h
cp build/DM42/release/version-0.4.1.h src/dmcp/version.h
cd sim; qmake simulator.pro -o simulator.mak CONFIG+=release
Info: creating stash file /Users/nickapos/testing/DB48X-on-DM42/sim/.qmake.stash
WARNING: Failure to find: ../recorder/recorder.c
WARNING: Failure to find: ../recorder/recorder_ring.c
make: *** No rule to make target `sim/gcc111libbid-Darwin-x86_64.a', needed by `sim/gcc111libbid.a'. Stop.
nickapos@MacBook-Pro.local ~/t/DB48X-on-DM42 >

I have installed all the dependencies so I wonder what am I missing here. Can you advise please?

You have to fetch the submodules. Either by

Code:

git clone --recursive https://…

or by running

Code:

git submodule init; git submodule update

(not 100% sure of the syntax but that's the idea.)

Thank you very much, I got the dependencies cloned, and I am now getting an error about the intel floating point library.

nickapos@MacBook-Pro.local ~/t/DB48X-on-DM42 > make sim 13:24:46
mkdir -p build/DM42/release
touch build/DM42/release/.exists
echo "#define DB48X_VERSION \"0.4.1\"" > build/DM42/release/version-0.4.1.h
cp build/DM42/release/version-0.4.1.h src/dmcp/version.h
cd sim; qmake simulator.pro -o simulator.mak CONFIG+=release
Info: creating stash file /Users/nickapos/testing/DB48X-on-DM42/sim/.qmake.stash
make: *** No rule to make target `sim/gcc111libbid-Darwin-x86_64.a', needed by `sim/gcc111libbid.a'. Stop.

I am not sure what package to install to resolve this dependency issue. Investigating

[c3d]

(08-10-2023 02:47 PM)nickapos Wrote:  

(08-10-2023 08:06 AM)gwh Wrote:  You have to fetch the submodules. Either by

Code:

git clone --recursive https://…

or by running

Code:

git submodule init; git submodule update

(not 100% sure of the syntax but that's the idea.)

Thank you very much, I got the dependencies cloned, and I am now getting an error about the intel floating point library.

nickapos@MacBook-Pro.local ~/t/DB48X-on-DM42 > make sim 13:24:46
mkdir -p build/DM42/release
touch build/DM42/release/.exists
echo "#define DB48X_VERSION "0.4.1"" > build/DM42/release/version-0.4.1.h
cp build/DM42/release/version-0.4.1.h src/dmcp/version.h
cd sim; qmake simulator.pro -o simulator.mak CONFIG+=release
Info: creating stash file /Users/nickapos/testing/DB48X-on-DM42/sim/.qmake.stash
make: *** No rule to make target `sim/gcc111libbid-Darwin-x86_64.a', needed by `sim/gcc111libbid.a'. Stop.

I am not sure what package to install to resolve this dependency issue. Investigating

You have to build that library manually, unfortunately.

[c3d]

Version 0.4.2 is out.

https://github.com/c3d/DB48X-on-DM42/rel...tag/v0.4.2

New features:

Display folder marker on directories in VariablesMenu (#309)
Alternate menu styles (sqare vs. rounded, single-line or 3-line) (#310)
line, circle, ellipse, rect and rrect graphic commands (#311, #316, #318)
linewidth, foreground, background graphic commands (#312)
ppar special variables for user coordinates (#319)
cllcd to clear the screen
drax to draw plotting axes (#321)
draw command to plot a function (#323)
wait command to wait for a delay or key press (#324)
Bugs:

Memory corruption when GC was triggered in a constructor (#325)
Improve complex_promotion to avoid undesirable complex format changes
Wrong pattern alignment in screen blitting operations
Off by one error in width and height of blitter rectangles (#
Conversion of fractions to uint32 (#321)
Conversion between bignum and uint32 / int32
Improvements:

Update dmcp commit to include a single fix for _exit
Better rendering of folder menus, looks more like a folder (#310)
Add .clang-format file to facilidate standard code formatting
Add AUTHORS file
Global variable lookup is now case-independent

[spiff72]

Hello...

I have been curious about something for a while so I will ask here...

I have noticed that the QSPI file for DB48x is quite large compared to the QSPI file for WP43 and C47. It is comparable in size to the stock firmware QSPI, though. C47/WP43 are less than 200KB, while stock is about 1.4MB and DB48X is 1.5MB.

What drives the size of that file? I like to keep all the PRG files in the root of my DM42, and I have separate folders for "offline" storage of the relevant QSPI files for each of the calc programs I switch between (C47, DB48X, stock, and WP43). Unfortunately there isn't quite enough storage for all of them, so I have to leave out the one for DB48X.

[c3d]

(08-15-2023 10:16 PM)spiff72 Wrote:  Hello...

I have been curious about something for a while so I will ask here...

I have noticed that the QSPI file for DB48x is quite large compared to the QSPI file for WP43 and C47. It is comparable in size to the stock firmware QSPI, though. C47/WP43 are less than 200KB, while stock is about 1.4MB and DB48X is 1.5MB.

Short version: C47/WP43 uses their own floating-point code (derived from WP34 I believe), whereas DM42 and DB48X use the Intel decimal floating-point library.

Long version: the Intel library is IEEE-compliant, and takes a lot more space, notably due to relatively large tables used to accelerate various computations.

DB48X builds its own QSPI so as to be compatible with the DM42 program, to make it quicker to switch back and forth between the two .PGM files. So it includes the symbols used by the DM42 firmware, and adds on top of that its own data (fonts, read-only data generated by the C++ compiler). So you can run the DM42.PGM file with the DB48X QSPI, but the opposite is not true.

Note that in the long term, my intent is to switch to a variable-precision floating-point implementation similar to that of newRPL. When this happens, it is likely that I won't be able to keep both the Intel and the new code at the same time, so I may find myself in the same situation as C47, i.e. a smaller QSPI but not compatible with DM42.

On a side note, at some point, I tried to run code from the QSPI. This is supposed to work according to the spec sheets (it's a feature called XIP or "execute in place"). But experience shows that while it works fine on USB power, the system "pauses" executing code in the QSPI until you plug USB. In practice, the pre-releases of DB48X with this problem would hang if you run 'sin' on battery power, until you plug the USB back.

Quote:What drives the size of that file? I like to keep all the PRG files in the root of my DM42, and I have separate folders for "offline" storage of the relevant QSPI files for each of the calc programs I switch between (C47, DB48X, stock, and WP43). Unfortunately there isn't quite enough storage for all of them, so I have to leave out the one for DB48X.

You should be able to use the DB48X QSPI to run your DM42 program. Let me know if it does not work.

[spiff72]

(08-16-2023 05:53 PM)c3d Wrote:  

(08-15-2023 10:16 PM)spiff72 Wrote:  Hello...

I have been curious about something for a while so I will ask here...

I have noticed that the QSPI file for DB48x is quite large compared to the QSPI file for WP43 and C47. It is comparable in size to the stock firmware QSPI, though. C47/WP43 are less than 200KB, while stock is about 1.4MB and DB48X is 1.5MB.

Short version: C47/WP43 uses their own floating-point code (derived from WP34 I believe), whereas DM42 and DB48X use the Intel decimal floating-point library.

Long version: the Intel library is IEEE-compliant, and takes a lot more space, notably due to relatively large tables used to accelerate various computations.

DB48X builds its own QSPI so as to be compatible with the DM42 program, to make it quicker to switch back and forth between the two .PGM files. So it includes the symbols used by the DM42 firmware, and adds on top of that its own data (fonts, read-only data generated by the C++ compiler). So you can run the DM42.PGM file with the DB48X QSPI, but the opposite is not true.

Note that in the long term, my intent is to switch to a variable-precision floating-point implementation similar to that of newRPL. When this happens, it is likely that I won't be able to keep both the Intel and the new code at the same time, so I may find myself in the same situation as C47, i.e. a smaller QSPI but not compatible with DM42.

On a side note, at some point, I tried to run code from the QSPI. This is supposed to work according to the spec sheets (it's a feature called XIP or "execute in place"). But experience shows that while it works fine on USB power, the system "pauses" executing code in the QSPI until you plug USB. In practice, the pre-releases of DB48X with this problem would hang if you run 'sin' on battery power, until you plug the USB back.

Quote:What drives the size of that file? I like to keep all the PRG files in the root of my DM42, and I have separate folders for "offline" storage of the relevant QSPI files for each of the calc programs I switch between (C47, DB48X, stock, and WP43). Unfortunately there isn't quite enough storage for all of them, so I have to leave out the one for DB48X.

You should be able to use the DB48X QSPI to run your DM42 program. Let me know if it does not work.

Ok - so then I could theoretically keep the DB48X QSPI tucked away in the backup folder on my DM42 and remove the stock one, saving 1.4MB of space.

I will give that a try tonight and confirm I can drop the stock QSPI. That would at least get me to the point where ALL of the necessary files are on the calculator at any given time - but I still need a PC to access that pesky drive and move (or ideally COPY) the right QSPI file to the root.

[Helix]

(08-16-2023 05:53 PM)c3d Wrote:  Note that in the long term, my intent is to switch to a variable-precision floating-point implementation similar to that of newRPL. When this happens, it is likely that I won't be able to keep both the Intel and the new code at the same time, so I may find myself in the same situation as C47, i.e. a smaller QSPI but not compatible with DM42.

The Intel library seems very fast. According to a test given in the SwissMicros forum, the DM42 is 5 times faster than C47 on floating-point calculations, which is a big difference! I suspect that a variable-precision library would be even slower than C47, and such a step backwards would be a disappointment to me.
That would imply that I never upgrade DB48X when the Intel library is replaced by the variable-precision library, unless you maintain two versions...

[c3d]

(08-16-2023 10:44 PM)Helix Wrote:  

(08-16-2023 05:53 PM)c3d Wrote:  Note that in the long term, my intent is to switch to a variable-precision floating-point implementation similar to that of newRPL. When this happens, it is likely that I won't be able to keep both the Intel and the new code at the same time, so I may find myself in the same situation as C47, i.e. a smaller QSPI but not compatible with DM42.

The Intel library seems very fast. According to a test given in the SwissMicros forum, the DM42 is 5 times faster than C47 on floating-point calculations, which is a big difference!

Based on a few very early experiments, I don't think the Intel library is particularly fast. I noticed that C47 is slower (overall, not just floating-point). I'm trying to find a balance between performance and compactness for DB48X. So far, it is looking acceptable.

Quote: I suspect that a variable-precision library would be even slower than C47, and such a step backwards would be a disappointment to me.

Variable precision does not have to be slow. newRPL is quite fast AFAICT, including for floating point.

Quote:That would imply that I never upgrade DB48X when the Intel library is replaced by the variable-precision library, unless you maintain two versions...

We will see. My intent is to keep things fast and lean. For example, at some point I might add support for hardware-accelerated 32-bit FP, for use during plotting for example. Time will tell, and there is so much left to do!

[c3d]

(08-16-2023 09:12 PM)spiff72 Wrote:  I will give that a try tonight and confirm I can drop the stock QSPI. That would at least get me to the point where ALL of the necessary files are on the calculator at any given time - but I still need a PC to access that pesky drive and move (or ideally COPY) the right QSPI file to the root.

Wouldn't it be nice if you could load a QSPI like you load a program? Without having it erased from the flash after use?

[Gjermund Skailand]

I think it would be excellent even if you had to connect usb or external power to do the changeover.

[Helix]

(08-17-2023 08:29 AM)c3d Wrote:  Variable precision does not have to be slow. newRPL is quite fast AFAICT, including for floating point.

I had this summation benchmark in mind, which relies heavily on mathematical functions. Of course, this is an extreme case.
For 1000 loops, the DM42 takes 6.64s (34 digits), and newRPL on the HP 50g 8.2s (32 digits).
Remember that newRPL runs at 200 MHz, while the DM42 runs only at 24 MHz on battery. So on this benchmark, newRPL is not so impressive.
But obviously, my concern here is very premature.

[Gilles]

(08-17-2023 10:00 PM)Helix Wrote:  

(08-17-2023 08:29 AM)c3d Wrote:  Variable precision does not have to be slow. newRPL is quite fast AFAICT, including for floating point.

I had this summation benchmark in mind, which relies heavily on mathematical functions. Of course, this is an extreme case.
For 1000 loops, the DM42 takes 6.64s (34 digits), and newRPL on the HP 50g 8.2s (32 digits).
Remember that newRPL runs at 200 MHz, while the DM42 runs only at 24 MHz on battery. So on this benchmark, newRPL is not so impressive.
But obviously, my concern here is very premature.

Interesting benchmark. About newRPL for HP50g processor speed

An interest that I see with the variable precision in newRPL is that it allows the use of long integers (< 2000 digits) very quickly. It's very easy to use (SETPREC and GETPREC that can be mixed in a program). I also like in newRPL the visible difference between an exact decimal number (ex: 2.5) or approximate (2.5.). I remember the very early (Alpha) versions of the newRPL didn't use the intel variable precision library and calculatations were indeed faster. But you couldn't use very long intergers.

PS: the same benchmark newRPL HP50 with a precision of 128 digits takes 30 sec.

[Paul Dale]

(08-16-2023 05:53 PM)c3d Wrote:  Short version: C47/WP43 uses their own floating-point code (derived from WP34 I believe), whereas DM42 and DB48X use the Intel decimal floating-point library.

Long version: the Intel library is IEEE-compliant, and takes a lot more space, notably due to relatively large tables used to accelerate various computations.

The C47/WP43 do indeed use the WP 34S as a base. That was based, in turn, on IBM's decNumber library which is also IEEE compliant and supports variable length numbers.

Intel's library does include a lot of lookup tables. It also uses binary floating point to get estimates which are refined to get a decimal results -- this will also add space since two libraries are being carried. It is very much a space for speed trade off.

One distinction between the C47/WP43 and the WP 34S is that the latter is targeting 16 digit accuracy whereas the former are targeting 34 digits. The extra digits will slow things down, although the amount varies depending on the function.


Pauli

[c3d]

New release v0.4.3, graphics stabilization

https://github.com/c3d/DB48X-on-DM42/rel...tag/v0.4.3

This one comes with a demo file.

[TomC]

Perhaps there are directions I've missed:

1. How do I update my DM42 to the DB48X?
I've followed the update instructions on the SM site - ie I've copied both the .pgm file and the .bin file the the DM42 USB disk , ejected the DM42. The machine remains in its DM42 state.

2. Is it possible to keep the DM42 software and DM48 software on the DM42 hardware and switch between them without reconnecting to the PC?

Thank you,
TomC

(08-28-2023 01:10 AM)c3d Wrote:  New release v0.4.3, graphics stabilization

https://github.com/c3d/DB48X-on-DM42/rel...tag/v0.4.3

This one comes with a demo file.

[ijabbott]

(08-28-2023 07:15 PM)TomC Wrote:  Perhaps there are directions I've missed:

1. How do I update my DM42 to the DB48X?
I've followed the update instructions on the SM site - ie I've copied both the .pgm file and the .bin file the the DM42 USB disk , ejected the DM42. The machine remains in its DM42 state.

(Assuming you are starting from the normal DM42PGM app....) From the DM42 setup main menu, press 5. System >, then 2. Enter System Menu. From the System Menu, press 4. Reset to DMCP menu. From the DMCP menu, press 3. Load Program. From the Load DMCP Program browser, navigate to the .pgm file you want to load. Press 'ENTER' to confirm. This will erase the current app (DM42PGM) from flash memory and load the new .pgm file in its place.

Quote:2. Is it possible to keep the DM42 software and DM48 software on the DM42 hardware and switch between them without reconnecting to the PC?

Yes, you need to put the DM42-x.xx.pgm file (where x.xx is the version number) on the USB disk. There should be a way back from the DB48X application to the DMCP menu where you can load the DM42-x.xx.pgm file to return to normal DM42 operation. (I haven't actually used DB48X myself yet, so don't know the details.)

There is a limit to the number of times you can erase the flash memory to load a .pgm file, but as the minimum endurance is 10000 erase cycles you are unlikely to wear it out.

[c3d]

(08-28-2023 08:06 PM)ijabbott Wrote:  

(08-28-2023 07:15 PM)TomC Wrote:  Perhaps there are directions I've missed:

1. How do I update my DM42 to the DB48X?
I've followed the update instructions on the SM site - ie I've copied both the .pgm file and the .bin file the the DM42 USB disk , ejected the DM42. The machine remains in its DM42 state.

(Assuming you are starting from the normal DM42PGM app....) From the DM42 setup main menu, press 5. System >, then 2. Enter System Menu. From the System Menu, press 4. Reset to DMCP menu. From the DMCP menu, press 3. Load Program. From the Load DMCP Program browser, navigate to the .pgm file you want to load. Press 'ENTER' to confirm. This will erase the current app (DM42PGM) from flash memory and load the new .pgm file in its place.

This is not sufficient for DB48X. Due to size reasons, DB48X also needs a QSPI update with a lot of additional data it needs. So you need to run the "Load QSPI from FAT" entry before loading the .pgm file (or .pg5 for the DM32). However, that QSPI file should allow you to also run the DM42 program.

Quote:

Quote:2. Is it possible to keep the DM42 software and DM48 software on the DM42 hardware and switch between them without reconnecting to the PC?

Yes, you need to put the DM42-x.xx.pgm file (where x.xx is the version number) on the USB disk. There should be a way back from the DB48X application to the DMCP menu where you can load the DM42-x.xx.pgm file to return to normal DM42 operation. (I haven't actually used DB48X myself yet, so don't know the details.)

The same "Setup" key (shift 0) gives you a slightly different menu, notably because it direclty contains a "5. Load Program" which lets you load the DM42 program directly.

Note that when you switch programs like this, the calculator state will be lost. So you should save the DM42 state before loading another program (using the same menu), and reload it after you return to DM42.

Switching back and forth between DM42 and DB48X takes less than one minute. I recommend doing it while on USB power, because flashing is likely to consume more power than other calculator operations.

Quote:There is a limit to the number of times you can erase the flash memory, but the minimum endurance is 10000 erase cycles so you are unlikely to wear it out.

[TomC]

A'Thank you for the prompt reply.

I have DB48 'working' now, HOWEVER,

The XEQ key does not allow me to key in text. The cursor changes to 'A' which indicates I should be in text entry mode, but I cannot enter text - ie hitting the '4' key yields a 4 rather than a T.????

Also, not a bug, but a preference - the stack number levels on the left side are very small - can these be made larger?

Thank you,
TomC

(08-28-2023 08:15 PM)c3d Wrote:  

(08-28-2023 08:06 PM)ijabbott Wrote:  (Assuming you are starting from the normal DM42PGM app....) From the DM42 setup main menu, press 5. System >, then 2. Enter System Menu. From the System Menu, press 4. Reset to DMCP menu. From the DMCP menu, press 3. Load Program. From the Load DMCP Program browser, navigate to the .pgm file you want to load. Press 'ENTER' to confirm. This will erase the current app (DM42PGM) from flash memory and load the new .pgm file in its place.

This is not sufficient for DB48X. Due to size reasons, DB48X also needs a QSPI update with a lot of additional data it needs. So you need to run the "Load QSPI from FAT" entry before loading the .pgm file (or .pg5 for the DM32). However, that QSPI file should allow you to also run the DM42 program.

Quote:Yes, you need to put the DM42-x.xx.pgm file (where x.xx is the version number) on the USB disk. There should be a way back from the DB48X application to the DMCP menu where you can load the DM42-x.xx.pgm file to return to normal DM42 operation. (I haven't actually used DB48X myself yet, so don't know the details.)

The same "Setup" key (shift 0) gives you a slightly different menu, notably because it direclty contains a "5. Load Program" which lets you load the DM42 program directly.

Note that when you switch programs like this, the calculator state will be lost. So you should save the DM42 state before loading another program (using the same menu), and reload it after you return to DM42.

Switching back and forth between DM42 and DB48X takes less than one minute. I recommend doing it while on USB power, because flashing is likely to consume more power than other calculator operations.

Quote:There is a limit to the number of times you can erase the flash memory, but the minimum endurance is 10000 erase cycles so you are unlikely to wear it out.