Threaded Mode | Linear Mode

c3d · (This post was last modified: 10-18-2023 11:21 PM by c3d.)

(07-11-2020 04:42 AM)NetMage Wrote: While I have not put too much effort into using my Prime, mostly because I don’t find it very inviting (I actually prefer the TI-Inspire CX) I am surprised no one mentioned units handling.
My main calculator is a DM42 and my second is either my 50g or more often an emulated 48Gx on my iPhone and those are pulled out for units calculation.

I would like to see a full RPL environment with unit handling on par with the 48Gx.

That's next on my to-do list. Unit objects are the last user-level remaining RPL type to implement I believe (discounting developer-level types like libraries or assembly code blobs, which will have to be implemented differently).

Quote:I don’t think languages like micro Python or Python are very good choices for a handheld programming environment which has a small keyboard. Maybe APL but not many would use it ?

APL? Interesting idea.

(07-11-2020 02:38 PM)mfleming Wrote: Agreed, regular programming languages are quite fat while APL is terse, expressive, and able to handle large datasets. But you could probably count the number of potential users on one hand

I think that looking at APL operators to see if any would fit in an RPL context can be a great idea.

(07-11-2020 02:47 PM)grsbanks Wrote: +1 -- which is why I really don't understand the whole "python on a calculator" thing, be it HP, TI or any other manufacturer. Even HP-PPL on the Prime is pushing it IMO. Keystroke programming and RPL are about the best adapted to calculators, which is but one of many reasons why machines such as the HP-41C and HP-42S (and HP 35s, although I don't care for that one very much) are so sought after today, 30 or 40 years after their release.

I am seriously considering adding some level of support for keystroke programming in DB48X. Specifically:

0. LastX command (already done) in addition to LastArg.

1. An editor that shows each RPL object as one numbered step

2. Label and Goto instructions. One question about those is whether we should RPL-ify them the way STO was, i.e. you'd have to state "Foo" Label and "Foo" Goto... :-) This would solve problems like indirect Goto, but what would indirect labels even mean? Alternatively, have some smart logic that would show 'X' Sto as Sto X when in this editor.

3. Other more obscure instructions like DSZ, etc, including their really weird counting semantics. They are not hard to implement.

4. Operators like X<0? with "Skip if false" behaviour.

That being said, DB48X is already quite efficient memory-wise. This NQueens benchmark is only 68 bytes long, vs. 135 for the HP48.

Code:

<<

  0

  DO

    8 SWAP 1 +

    WHILE

      DUP2

      DO 1 -

      UNTIL

        DUP2 5 + PICK - ABS

        DUP2 - * NOT

      END

    REPEAT

      DROP

      WHILE SWAP DUP 1 SAME

      REPEAT -

      END

      1 - SWAP

    END

    DROP

  UNTIL DUP 8 SAME

  END

  ->LIST

 >>

(07-11-2020 04:05 PM)Anders Wrote: Yeah so the reason why Python is preferable with math and science libraries is of course because of it's richness and massive active community of developers extending the libraries.

Indeed. This is one aspect that cannot be brought to the SwissMicros platform, it does not fit. It could fit in Prime-class or Raspberry-class hardware.

Quote:In the year of 2020, I do not sit and program complex solutions on a calculator if I am interested in solution productivity (both in terms of development and usage). Doing so would be nuts!

Depends on whether you are interested in delivering something that works today on existing hardware available for purchase today ;-)

Quote:In 2020, you of course do the development on a PC including debugging. You then transfer it to the calculator to solve problems in small form factor. The calculator becomes a problem solution machine - ideally! This can be extremely powerful. Wolfram is great but the form factor is not there (yet).

At least on the SwissMicros platform, the only way I see that makes this objective even remotely possible is to have a C++ SDK available for developers to build libraries you can then store on the FAT partition. 6M is plenty of space for relatively complicated computations, but RAM is a real issue (there's about 70K free on a DM42, which is plenty for RPL, but not a whole lot for complicated C++ algorithms).

Quote:20-40 years ago we had restrictions on memory and CPU speed that forced us to use more efficient programming models and languages (counting bytes and cpu cycles), but today those restrictions are gone. Further, fast forward a few more years and those restrictions will be even like gone, gone. like irrelevant.

Not at all. The trade-off SwissMicros picked is that you run on a single Lithium battery for years without ever recharging. That has value too.

I would not mind an open Prime-class calculator, and as written above, would happily port DB48X to it. But should that become available, the trade-offs would still remain vastly different from what you do on a PC.

Quote:We need to move forward not backwards. Backwards to the "good old days" of stack based languages (they are called 2nd generation programming languages for a reason) feel like a hobby for retired engineers or some form of calculator archeology with extremely small market potential for HP - not professional solution productive in 2020+.

I thought this thread was about the future not the past.

I believe DB48X is an RPL platform that can last a few decades, because it is open, and that I hope it will extend way beyond this humble DM42 beginning. But in terms of keyboard efficiency, I want it firmly stuck in the past.

The three primary reasons I don't use the Prime as a main calculator are:

1) requires to touch the screen with precision, with tiny targets that are visible for students in a classroom but not really practical for an engineer in a moving train.
2) Programming language is not convenient in the field
3) Does not support large binary numbers and arbitrary bases (e.g. 512-bit or base 3, both of which DB48X does happily).

Two of these reasons are because the Prime chose the "future" over the "past".

Let me just ask a question here: who else uses a calculator app on their PC or Mac? I certainly do. I use iHP48, running an HP50 ROM image. Do you know what is really bad about it? It's actually an iPhone app, so no keyboard support at all, which on a Mac forces me to click click click. Aaaaargh!

(07-11-2020 06:11 PM)John Keith Wrote: I agree in general that Python is not the ideal language for a hand-held calculator but it has become close to a de facto standard for educational and scientific programming. Since several other calculators support Python I would prefer to see Python replace PPL, which is not ideal for hand held use either IMHO.

The educational aspect has changed the face of HP calculators for the worse. While the original HP35 was designed for engineers, since the year 2000 at least the focus shifted towards education markets. For a good reason: they are by far the largest market for such devices.

Since then, various legislations were introduced, and they all required the most advanced calculators to be artificially restricted in what they could do. No restriction, no market. Before that, it was possible for HP to develop a high-end calculator that was actually funded by students, but still could satisfy engineers. The HP48 and HP50 were the culmination of that trend. They were a model of openness, with access to all internals, then-current interfaces with computers or measurement devices, built-in libraries to even do assembly-level coding, and so on.

The Prime had to renegade on all this for one reason and one reason only: legislations that forced HP to choose between education and scientists. HP chose education, and it was the only possible choice from a business standpoint. The Prime is a closed device, and worse, it's focused more on people learning about mathematics than on people who actually need to do mathematics.

The only interest of Python on a hand-held device, frankly, is the education market. For engineers, I see very little practical value, unless you have a device that is actually connected and on-line, i.e. one that has Wi-Fi and does not need numpy integrated because you can pip-install it when you need it. For all those who argue that there is a huge Python ecosystem out there ready to be tapped into: that's only true if your system is truly open and on-line. For engineers, it works on a Raspberry Pi. It does not work half as well on a closed Prime. Having Wi-Fi and pip-install won't work for a device that must pass the "can be used during exams" test.

Quote:Aside from being obscure and unreadable, APL is not a modern language and lacks many features programmers have come to expect. It was designed originally for array processing and not as a general-purpose programming language.

Yes. But it's interesting to see if some APL operators would make sense in RPL. I had not thought about that, and will look into it.

Quote:If I had to pick a modern programming language for a hand held calculator I would choose Haskell. It is a concise and powerful language without the mystic runes and bass-ackward syntax of APL. Haskell is also the basis of the GoferLists library for the HP 50g, which extends the "automatic list processing" features introduced on the HP-48.

Good choice for something you develop on your PC and transfer to the calculator. Haskell bindings for the C++ SDK I talked about could make a lot of sense. But typing Haskell on a calculator? Not my cup of tea!

Quote:Replacing the Prime's vestigial RPN mode with either true HP 50 emulation or New RPL would probably be the best solution overall.

I agree that the "vestigial" approach was half-hearted and does not work, see all comments about CAS mode vs. Home.

(07-12-2020 05:57 PM)Anders Wrote: I think you are right in our different perspectives is because some view a next gen calculator as tool for calculation and some want a tool of thought - truly amplifying your solution solving capabilities at conceptual level.

I think that reasonably speaking, the "tool of thought" is better handled by a PC or a tablet, notably because so much "thought" is on the Internet. So indeed, I am focusing on calculations, and on making such calculations definitely more efficient than with, say, an iPhone app. The major differentiator is a physical keyboard and software stack optimized for efficient calculations. The programmable aspect is only to extend the kind of calculations that can be done, not to perform heavy number-crunching that is best done on more powerful platforms.

Quote:I'm looking for a productive "solution solving machine" in a handheld format which is basically a tool of thought. The idea of reinventing yet another tool for calculations in 2020 is pretty meaningless in my view. HP Prime, HP42S, HP48xx, HP50g or some of Swiss micros flavor will do just nicely.

Prime does not satisfy me for the reason explained above: it targets another market than me, so it moved backwards relative to earlier generations as far as my own needs are concerned.

Quote:I do not think a Prime II should have to goal of perfecting a HP50g or similar in a new case with a modern CPU and more memory, perfecting number of key strokes it takes to perform a function, moving a few buttons around on the key board to perfect the layout or add more highly specialized functions to libraries.

It's likely DB48X will not be for you ;-)

Quote:As I wrote above in the thread, a rich CAS machine that can mix variables (unknowns), variables (known) and numbers is where it needs to go (all CAS stuff disabled in Exam mode). Take Giac, roll in new releases and aim towards Wolfram alpha.

Improving the CAS or graphic capabilities is important to me. This is one area where having Prime-class open hardware would help. DB48X has plotting features today (you can see them in the Demo package). But plotting is nowhere as fast as on a Prime. At some point, I will need to implement hardware-accelerated FP numbers to see if I can get things a bit faster that way. Also interesting would be to implement hardware-accelerated FP in the simulator. That would certainly beat the Prime.

Quote:To make the "Prime II" tool of thought truly usable in education at high schools but also at engineering universities and professionally, it has to be extendible with math and science libraries, with largest broadest spread that has the biggest market size (all students + all professionals), flourishing development and a future. Python is where the puck is going (or already is). We should also allow to leverage (which Python can do) the libraries written in R - that would open up an entire new world for a handheld device.

Where I differ with you is that I don't think you can target both educational and engineering markets, for the reasons I outlined above. So in the end, any hand-held device with a mass-market educational appeal will have to put restritions that will frustrate engineers.

Quote:The point is that a handheld platform that can leverage all the massive development that takes place to day in Python and R etc. would be truly next gen. This would truly amplify a users solution solving capability also at the high end!

Obviously programming is done an a PC/mac and transferred to the handheld device. (all programs are disabled in Exam mode).

I want the best of both worlds maximum capability in a handheld format.

I believe you are describing the iPad or the iPhone. I have one. But I don't like using it for calculations (even though I frequently do). Presently, I have 12 calculator apps installed on it, including the Prime emulator... I mostly use the HP48 emulator. But still, like on the Mac, click click click is not the same as a real HP keyboard.

(07-12-2020 07:23 PM)John Keith Wrote: This is one point I disagree with. Having to do programming on a PC defeats the point of a programmable calculator. Certainly writing large complex programs is best done on a PC but to me programming is an important part of interactive problem solving.

If I had to choose only one language I would choose Python because of its wide appeal and large base of users and freely available code. However, I still think of RPL as unbeatable for quick'n'dirty problem solving and I can't see a reason not to have both.

The reason not to have both at least on SwissMicros hardware is that one barely fits.

Clearly, a Prime version of DB48X would probably have a Python object type ;-)

That being said, Python does not work at all as a calculator user interface, including for immediate calculations.

(07-12-2020 09:47 PM)Anders Wrote: I understand that I am being sacrilegious to many here when I write this, but
RPL and other other stack based languages is not the future of programming it belong to the past - a very interesting past and that has it charm from many perspectives and so on - but nonetheless the past. We should leave it there on our old loved calculators and not continue to introduce it on a next gen machine.

As an interactive language on a hand-held device, it is close to ideal though. The HP implementation can be improved on, and DB48X improves on HP's implementation in many ways. But RPL remains much better than Python as a basic calculator UI, and better than RPN as expressiveness. This is particularly true as far as CAS-style operations are concerned.

Quote:Just for reference, I wrote an full screen editor in Forth in 1984 (I swear, I do not want inflict that pain on anyone ever!), massive volumes of programs on HP-42S 28S 48S etc. over the years. It is not a good programming model for any complexity beyond trivial and shall not be used in a future machine point, period. It is a second generation language model form the past that current generation students do not care much about - except a perhaps a Computer Science major.

Yet it is fully homoiconic, which makes it inherently more powerful than Python.

It also has a much better support for mathematical data types, and treats them very uniformly.

BTW, one area where I plan to really extend RPL is support for user-defined types. But that's for another post.

Quote:Yes, quick and dirty programming would be the only potential reason for RPL, but you might as well use Python for that too (yes it might take a bit longer to code, but a good contextual and lexical sensitive editor could fix much of that).

Well, I make a different choice: I don't want it to take longer to code while I'm in the field. My problem at that moment is not that my code can be read later, is that I need to code something to address a problem where there is no built-in solution in the device.

Quote:That way, next gen students can actually read and understand our code - even quick and dirty one.

RPL is never easy to read. That much is true.

Quote:An owner of: HP-12c, HP-15c, HP-16c, 3 HP-28S, 2 HP-42S, 3 various HP-48xx, 1 HP-50g, 1 HP-35S, HP-32S, 3 HP Primes all flavors, all the Swiss micros flavors of the same DM-xx. Let see Casio FX-602p, FX-603p and a few more I do not even remember off the top of my head...

So you have a DM42? Then you can try DB48X right away and report bugs (there are many, it's still only 0.4.7 at the moment).

(07-16-2020 08:12 PM)John Keith Wrote: Actually it may be a better thing- NewRPL is native code and much faster than the Saturn emulator the HP 50g runs on. It should really fly on the Prime which has a higher clock speed and uses a newer ARM version.

On similar hardware, NewRPL and DB48X should be in the same order of magnitude. DB48X trades some performance for memory usage, so I expect it to be a bit slower, but also to garbage-collect less often. It does fly on a MacBook Pro with a Apple M1 processor though (NQueens is less than 20ms).

(04-28-2021 02:32 PM)obelix Wrote: Perhaps the best option would be:

a) Open source the firmware
b) Create a new calculator, just cosmetically different from the HP Prime, without exam mode and without limitations to install custom firmware, just like the old 50g.

From this point the community could do anything. Perhaps integrate xcas in NewRPL just like Erable was integrated in old RPL?

I'd love both a and b. But I think the market is too small for this to ever happen. The best we have at the moment in terms of HP-style open platform is SwissMicros (there are other open calculators, I like them less overall).

(05-03-2021 02:53 AM)toml_12953 Wrote: I know I'm alone in this but I'd like to see a machine with either: CAS fully integrated or no CAS at all. I'd like no dedicated variables.

Check and check.

Quote:My main use for any machine is to be able to program it and having to know which variables are used by CAS and which are used in Home isn't helpful. So I'd like NO predefined variables. Let the user define the ones (s)he wants.

Check.

Quote:I'd also like a full version of either C, Pascal, Python, JavaScript or other standard language similar to those.

C++ SDK would be my answer.

Quote: I'd also like to be able to use USB peripherals such as a keyboard, mouse, printer, game controller, SSD, etc. Having HDMI or at least VGA video output would be good.

SwissMicros DM32 has USB-C, but I doubt it can do any of these. Storage might be within reach, and only with very simple file formats (think FAT but no ExFAT).

(01-23-2022 07:56 PM)celltx Wrote: I'd like to see a better number formatting:

- in normal mode, I'm tired counting zeros in numbers like 0.000002. It would be great to have something like Norm1 in Casio calculators, where numbers smaller than 0.01 are displayed with exponent.
- Larger numbers could have an option to be displayed with exponent too: either 10,000 or 1e4, by user choice

DB48X has a StandardExponent setting precisely for that purpose. Set it to 3, and anything below 1E-3 or above 1E3 switches to scientific mode.

There is also a "SIG" mode inspired from WP34S / C47, which shows "significant digits". Mimicking the HP48 12-digit STD mode on a 34-digit DB48X is achieved by using 12 SIG.

Recently, I added another refinement, which is MinimumSignificantDigits. It means that 0.0055 in FIX 2 does not necessarily display as 0.01. You can instead choose how many signficant digits you want in FIX mode.

Quote:- in scientific format, please remove trailing zeros in mantissa: Let 2.1e7 look like this, rather than a long 2.100000e7

You can achieve that by setting the StandardExponent to 0.

Quote:- Add engineering symbols option, so that answer 2e-12 could be shown as 2p, or 2e6 as 2M

Planned, will be part of units support. As indicateda above, for 2e-12, I would expect EEX to cycle between 2e-12 and 2_p, with possibly a display of the next level, i.e. in that case 0.0002_n and 2000_f. The underscore is the sign used in RPL, but on display, it will be a non-breaking thin space.

Quote:So far, HP number formatting is weaker than both TI's and Casio's and this leaves bad impression in everyday use. I'd guess, this gap is easy to close.

In addition to the above, DB48X lets you select between 1'000 1,000 1.000 1_000 1 000 (a "space medium math" unicode character that displays as a thin space on screen - Did I mention DB48X is 100% Unicode and utf8?). It lets you select a comma or dot as decimal separator. You can adjust spacing independently for based numbers, so you can have 1'000 and #ABCD'EFGH. There is a distinct setting for whole and fractional part, e.g. 10_000,12345_65789. And numbers are adjusted dynamically in the editor as you type them. Which was a bit hellish to code, to be honest ;-)

Also, the exponent part in scientific mode can show as 'E' or with a fancy x10 character and a superscript exponent. Similarly, based numbers show the base as a subscript on the stack display.

(01-26-2022 02:05 PM)Stefan Falk Wrote: 1. *Simple* Keyboard-based programming with only the built-in keyboard and no PC around!

I hear you. I hope that this is partly achieved with DB48X today, as long as you accept RPL as your programming model.

If you prefer RPN-style keystroke programming, as mentioned earlier, I would like to improve that with a step-oriented editor, but before that, by adding RPL commands that mimic common RPN construct. LastX is the first one.

Quote:This is doable on my 41C, and I found what Microsoft Research did with the first versions of TouchDevelop a *huge* improvement!

There is a world of difference between the two ;-) DB48X is defintely is closer to the 41C than TouchDevelop, but much more powerful.

Quote:Every bit of brainstorming to this field would be highly appreciated. So: Let us do simple programming with *much* less keystrokes than now using HPPL - directly on the device, while sitting in the train!

Exactly. If you have an opportunity to try DB48X, all feedback will lead to improvements.

Quote:2. While I understand that the CAS and Home separation is due to using the open source CAS software, I guess most of us feel that this is somewhat unnatural. Having a merged experience would be very fine and save us from things like getting a CAS function graphed and having to manually replace x with X, or having to store the function into a variable before plotting. A well-integrated world of both would highly polish the product imho.

Check.

Quote:5. RPN as a more prominent feature. Hard to do with CAS, I know, but just wanted to mention it. As just a calculator, nothing beats RPN.

I think RPL does. But you tell me.

Quote:6. I/O. Lets have the Prime control experiments and machines, take measurements from sensors, record them, plot them, and analyze them up to matching to functions and having full error propagation calculation, and easily transfer the results to the PC to write a document about the experiment. The new USB and I²C features look very promising, and I still have to try them.

That's the kind of stuff I'd like to do with the USB on the DM32 and DM42. It's not there yet, and right now, the DMCP platform provided by SwissMicros does not make the hardware accessible at a low-enough level.

Things would be different on another platform, like an open Prime.

(01-31-2022 08:19 PM)robve Wrote: Lua 5.3
Perhaps it is a long shot to ask for Lua, but Lua is small yet versatile and would make an excellent addition to HP Prime.

Lua could be a good choice. My own XL programming language could be another alternative (but it's not standard and does not have a real ecosystem, though its 3D or graphics support is stellar)

(01-31-2022 08:51 PM)KlaasKuperus Wrote: I love all your suggestions and ideas! We are always looking into making our products better and I will certainly add these points to the list. I cannot promise anything, but there's a lot I would love to see in real life!

If HP / Moravia is interested in providing a platform capable of running DB48X, I'm all ears.

(02-02-2022 09:15 PM)ndzied1 Wrote: I think it's been mentioned before but changing the Units functions to work like the 50g would be wonderful. I am especially talking about the way you can quickly convert units using the left shift key in conjunction with the soft menu.

For instance you need to convert 12in^3 to cm^3. With the Units/Volume menu up, you can type 12 (softkey in^3) then left shift (softkey cm^3). You can left shift / soft menu to convert to any compatible units. So fast and intuitive.

That's next on my to-do list.

(02-05-2022 10:09 AM)Tonig00 Wrote: Sure its been said but it would be interesting to have the precision of the dm42 from swiss micro:
Floating point standard IEEE 754-2008, 128-bit floating point precision implementation.

Done.

Quote:Additionally, related to the manual, it would be very interesting to collect many application examples given in this forum.
There are brilliant ones which could expand the actual manual.

I really would like this to happen on the DM48X documentation.

(04-25-2022 05:59 PM)Jim Horn Wrote: What would *I* like to see? A shipping date!

Shipping today in version 0.4.7 on DM32 and DM42 (shipping today from SwissMicros).

Estimated date for a 1.0: Around Christmas time, but no promise.

No idea if SwissMicros will ever ship a machine with DB48X preinstalled and a suitable keyboard layout.. You can get overlays for the DM32 or DM42 from @jeff72.

(06-02-2023 10:37 PM)Insoft Wrote: If HP did decide to get back into calculator market with a new HP Prime it would have to be a Retina display, Type-C support third party native app development using C/C++ retain PPL and allow PPL to interact with C/C++ written functions

The SwissMicros screens are quite good except in low-light conditions.
Third-party native app development: Check (and the planned library SDK would complete that).

Quote:The keyboard needs to feel like CASIO keyboard and Bluetooth for external mouse and keyboard input

One thing I certainly did not expect in a discussion about HP calculators is to get the CASIO keyboard feel! If I had to give a keyboard feel notation out of 10, HP48 would be 10, HP15C would be 9.8, HP Prime would be 9.5, DM42 would be 8.5, most TI calculators betwen 3 and 8 depending on the generation, and CASIO would consistently be between 3 and 4. The iPhone would be at 1. All a matter of taste, of course.

(06-03-2023 12:20 AM)Steve Simpkin Wrote: * Supporting third party native app development using C/C++ would be a large, expensive effort that would not make this calculator more sellable in the educational marketplace. It could also introduce security risks which could make this model unsuitable for the educational marketplace.

None of these objections applies to an open-source SDK.

Quote:* Making the keys feel more like Casio keys would eliminate one of the key elements that makes HP calculators more attractive to buyers. HP put a lot of effort into making the keys work and feel like they do. If you want the Casio keyboard feel, just buy a Casio or a TI or a Sharp.

I have to agree.

(06-30-2023 01:59 AM)dkostan Wrote: A Row of 6 Function/HW menu keys below the screen

Yes. One of my primary gripes with the Prime too.

Quote:Maybe a slightly better display resolution. On the fence since I think 7 (or more) color e-ink
display might be better for a calculator for power and persistent reasons.

I wonder if SwissMicros is considering color e-Ink displays. The ones I found were relatively expensive relative to monochrome. Does anyone have a link?

Quote:Normally I use a calculator in well lit areas (I think most do, right?) so backlight seems like a waste of juice and its annoying when it dims (on a calculator) to save power. E-ink seems better here to me.

Normally, yes, but the glass in front of the DM42 e-ink display can make it hard to read in "evening" conditions. I often have to reorient the calculator to avoid direct light sources.

The DM42 is rarely more readable than the Prime, except in really bright conditions, but the Prime is clearly ahead as soon as I have to switch the light on in my office. The DM42 is still always way ahead of the HP48, irrespective of conditions, and that alone makes DM42+DB48X a better choice than HP48 for me.

Quote:Add back in full engineering RPN support. That would include support to run RPL code.

Check.

Quote:Maybe built in emulation for the older platforms with support by adding a key mapping compatibility setting/file that could solve most issues due to the keys being different.
I use base48 and its great but I would prefer built in base number support similar to 48-50g (just add an option/setting for this style)

DB48X already has support for:

- Based number in any base, e.g. 3#212121110 is 16#433B, and 'Base' command to select arbitrary display base.

- Separators and fancy rendering of based numbers, e.g. something that shows as #433B'EF0A₁₆

- Word size higher than 64. For example 512 STWS and then #0 NOT gives you a 512-bit number.

- A large number of binary operations (shifts are still missing)

There is configurable support for based numbers with fixed base, so that you stack can display both a binary and an hexadecimal number at the same time. That is disabled at the moment, but I intend to re-enable it shortly for DB50X.

Quote:Seems like support for many interpreted and compiled languages would be "easy" these days. Many like python. I prefer C and hp ppl, but really seems like all of these could be supported with loadable packages & libs. Storage and cpu is not the limiter these days. Good community support could make this happen if the SDK was opened up.

It's not that easy on really small, power-efficient systems. But the SDK will definitely be open like the rest of the firmware.