New third party firmware (Not HP'PRIME TEAM)

[DrD]

It's probably just a marketing thing. I bought the Prime as a utility device, not a development platform. In short, (for me), the hp Prime just isn't "it" for stimulating my inner-innovator. If you are finding a thematic lack of interest on this board, I'm not surprised, but perhaps you are trying to motivate the wrong audience here?

If you can come up with something that leverages a stock hp Prime in a new way, that would be interesting. If you can discover (or resolve) problems, and offer to help the community, by guiding the direction of future hp firmware releases, your effort (and skill) will be very well appreciated. If you have a great modification, that takes the hp Prime in a whole new direction, and market it as a whole new product, perhaps a well-beaten pathway to your door, will be your reward. Otherwise, hitching a ride on the existing Prime hardware, with third party firmware, is sort of missing the "Gee!" spot.

This is my own feedback, as just one reader of this forum. Lord only knows what the majority sentiment might be.

-Dale-

[toml_12953]

(01-04-2016 11:24 AM)DrD Wrote:  This is my own feedback, as just one reader of this forum. Lord only knows what the majority sentiment might be.

-Dale-

I can only speak for myself, of course, but I'd like to see a third party firmware that adds the GOTO command to HPPL (I have thousands of BASIC programs to translate and GOTO would save a lot of time!) or Linux running on the Prime!

Tom L

[cyrille de brébisson]

Hello,

Adding GOTO to PPL would be "hard" even for HP, so I (unfortunately) would not hold my breath waiting for a 3rd party hack to do it.

PPL programs are not a linear sequence of unrelated instruction, but a non-linear tree of instructions sequences. This makes it hard to do a GOTO as each sub-sequence has temporary data associated to it and doing a GOTO would force the GOTO instruction to be able to detect if the destination is in the tree, and then properly destroy and initialize the right sub-sequence temporary data (including local variables creation).

Cyrille

[toml_12953]

(01-05-2016 03:45 AM)cyrille de brébisson Wrote:  Hello,

Adding GOTO to PPL would be "hard" even for HP, so I (unfortunately) would not hold my breath waiting for a 3rd party hack to do it.

PPL programs are not a linear sequence of unrelated instruction, but a non-linear tree of instructions sequences. This makes it hard to do a GOTO as each sub-sequence has temporary data associated to it and doing a GOTO would force the GOTO instruction to be able to detect if the destination is in the tree, and then properly destroy and initialize the right sub-sequence temporary data (including local variables creation).

Cyrille

True but if the entire firmware could be replaced with an HPPL (extended?) interpreter, it wouldn't have to follow the same implementation logic as the stock version.
Hmmm. A thought. HPPL is fast enough that I could write my own BASIC interpreter using it and still have plenty of horsepower left to run serious programs. Well, it's off to my coding zone!

Tom L

[DrD]

I was trying to imagine a program flow so reliant on a goto verb, that it couldn't be accomplished with subroutine structures. I sure created a lot of MITS Altair BASIC programs using goto's, but it wasn't very long before the term "spaghetti" code was coined, and displaced by "structured" programming.

Would you happen to have an example PPL program, where a "goto" would be especially useful?

-Dale-

[smp]

(01-05-2016 02:39 PM)toml_12953 Wrote:  Hmmm. A thought. HPPL is fast enough that I could write my own BASIC interpreter using it and still have plenty of horsepower left to run serious programs. Well, it's off to my coding zone!

Tom L

Tom, if you are serious about writing a BASIC language for the Prime, please keep us posted. I would be *very* interested in trying that out!

smp

[eried]

Even modern implementations of basic try to avoid the use of Goto:
https://msdn.microsoft.com/en-us/library/69whc95c.aspx

It is just not a good practice and it should be avoided.

[parisse]

Abuse of goto should be avoided, but it is sometimes much better to have a goto than complicated booleans that are required if goto are avoided. This is especially true for "implicit" gotos inside loops like break and continue.

[toml_12953]

(01-05-2016 06:10 PM)eried Wrote:  Even modern implementations of basic try to avoid the use of Goto:
https://msdn.microsoft.com/en-us/library/69whc95c.aspx

It is just not a good practice and it should be avoided.

Three glasses of champagne a week prevents Alzheimer's disease but three bottles a day will probably kill you. Moderation is always a good idea!

I do avoid GOTO when writing new programs but since I have over two thousand (and counting) non-trivial BASIC programs to translate, I would never have time to restructure them all. It will be faster for me to write an interpreter in HPPL and avoid all that translation work.

Tom L

[toml_12953]

(01-05-2016 03:57 PM)smp Wrote:  

(01-05-2016 02:39 PM)toml_12953 Wrote:  Hmmm. A thought. HPPL is fast enough that I could write my own BASIC interpreter using it and still have plenty of horsepower left to run serious programs. Well, it's off to my coding zone!

Tom L

Tom, if you are serious about writing a BASIC language for the Prime, please keep us posted. I would be *very* interested in trying that out!

smp

I am quite serious. It may take me a while but once it's done, I'll offer it free to anyone who wants it. Don't expect a lot of tech support at that price, though!
(although bug reports will certainly be welcomed)

Tom L

[cyrille de brébisson]

Hello

>Abuse of goto should be avoided, but it is sometimes much better to have a
>goto than complicated booleans that are required if goto are avoided.
>This is especially true for "implicit" gotos inside loops like break and continue

I use got every once in a while.

The numerical solver has a bunch of them because it was lifted verbatim from the HP48 code which is full of them, and I was unable to extract a clear structure.

An other use of goto is to exit a function in case of error when you have a number of finalization to do.

But, by far the most frequent use of goto is to exit a double (or more) deep loop. This happens all the time and is VERY frustrating to me.

This is why, in PPL, you can do break n; or continue n; (where n is an integer), which allows to break out of n level of loops. This reduces the number of legitimate goto use by at least 90%!

Cyrille

[Claudio L.]

(01-05-2016 02:39 PM)toml_12953 Wrote:  True but if the entire firmware could be replaced with an HPPL (extended?) interpreter, it wouldn't have to follow the same implementation logic as the stock version.

Rewriting a language like HPPL is not so trivial. But perhaps something simpler, like adding more types and math code to a Lua interpreter, or actually LuaJIT, would probably be doable, and much faster than HPPL.

[eried]

(01-06-2016 05:28 AM)cyrille de brébisson Wrote:  Hello

>Abuse of goto should be avoided, but it is sometimes much better to have a
>goto than complicated booleans that are required if goto are avoided.
>This is especially true for "implicit" gotos inside loops like break and continue

I use got every once in a while.

The numerical solver has a bunch of them because it was lifted verbatim from the HP48 code which is full of them, and I was unable to extract a clear structure.

An other use of goto is to exit a function in case of error when you have a number of finalization to do.

But, by far the most frequent use of goto is to exit a double (or more) deep loop. This happens all the time and is VERY frustrating to me.

This is why, in PPL, you can do break n; or continue n; (where n is an integer), which allows to break out of n level of loops. This reduces the number of legitimate goto use by at least 90%!

Cyrille

In my opinion when goto is used just to exit a loop, and not freely jump around in the code, it does not really represent the hated/demonic roots of the goto instruction; and this is totally acceptable. C# has goto/label to exit nested loops, similar to other languages that use break "label", etc.

But I am guessing toml is thinking on the other goto the one that makes possible to have certain state machine behavior without a clean design.

[toml_12953]

(01-06-2016 07:23 PM)eried Wrote:  

(01-06-2016 05:28 AM)cyrille de brébisson Wrote:  Hello

>Abuse of goto should be avoided, but it is sometimes much better to have a
>goto than complicated booleans that are required if goto are avoided.
>This is especially true for "implicit" gotos inside loops like break and continue

I use got every once in a while.

The numerical solver has a bunch of them because it was lifted verbatim from the HP48 code which is full of them, and I was unable to extract a clear structure.

An other use of goto is to exit a function in case of error when you have a number of finalization to do.

But, by far the most frequent use of goto is to exit a double (or more) deep loop. This happens all the time and is VERY frustrating to me.

This is why, in PPL, you can do break n; or continue n; (where n is an integer), which allows to break out of n level of loops. This reduces the number of legitimate goto use by at least 90%!

Cyrille

In my opinion when goto is used just to exit a loop, and not freely jump around in the code, it does not really represent the hated/demonic roots of the goto instruction; and this is totally acceptable. C# has goto/label to exit nested loops, similar to other languages that use break "label", etc.

But I am guessing toml is thinking on the other goto the one that makes possible to have certain state machine behavior without a clean design.

Since the BASIC programs I have to run on the Prime use GOTO for all sorts of branches, my interpreter must allow them also. As I said earlier, I don't use GOTO in my new programs but I have no control over what those other programmers did. I actually prefer ANSI/ISO Full BASIC which allows programs with no GOTOs at all but that BASIC won't run some of the old programs I need to run. Besides, the exercise of writing an interpreter in HPPL seems like it will be fun!

Tom L

[DrD]

Historically, as hand held calculators and personal programmable devices evolved, additional software features were desired to add value to a product genre. Are these same challenges present in the Prime? Perhaps, a greater value isn't the Prime firmware replacement. A Prime with a different hardware personna, incorporating the equivalent of a digital multimeter, SCADA, and possibly signal generation; together with enhanced comm's, would make this product much more useful, i.e., "interaction" with the outside world. (Assuming battery viability is commensurate to the task).

Somehow, creating a remake of an old BASIC interpreter just seems retrogressive. Of the "thousands of programs" mentioned above, written in (goto) BASIC, how many of those get used, say, per annum? For the subset that are actively being used, it might be more efficient to just re-code them in PPL, specifically for the Prime, and maybe broader user appeal. (Advantage gained: becoming more familiar with the Prime itself).

From a high-level perspective, what is the advantage gained in the pursuit of (BASIC or third party firmware)? Will either add-on realistically create greater utility value for this particular product? Maybe for déjà vu, or novelty; but otherwise, please help me realize the better mousetrap.

-Dale-

[Claudio L.]

(01-08-2016 11:55 AM)DrD Wrote:  Historically, as hand held calculators and personal programmable devices evolved, additional software features were desired to add value to a product genre. Are these same challenges present in the Prime? Perhaps, a greater value isn't the Prime firmware replacement. A Prime with a different hardware personna, incorporating the equivalent of a digital multimeter, SCADA, and possibly signal generation; together with enhanced comm's, would make this product much more useful, i.e., "interaction" with the outside world. (Assuming battery viability is commensurate to the task).

But hardware like that is not (in general) within reach of hobbyists. There's a significant cost to develop that.

(01-08-2016 11:55 AM)DrD Wrote:  Somehow, creating a remake of an old BASIC interpreter just seems retrogressive.

That's not a bad thing, is it? In 2016, I would consider a person using calculators retrogressive, developing on and for calculators = retrogressive. This is actually a museum site = retrogressive.
If you were thinking on cutting edge, you are in the wrong forum.
This is a museum site, all about keeping the old code alive (be it BASIC, RPL, etc), and keeping calculators alive, so I think retrogressive in this context is not a bad thing at all. We are all retrogressive here.

(01-08-2016 11:55 AM)DrD Wrote:  From a high-level perspective, what is the advantage gained in the pursuit of (BASIC or third party firmware)? Will either add-on realistically create greater utility value for this particular product? Maybe for déjà vu, or novelty; but otherwise, please help me realize the better mousetrap.

-Dale-

It's not about "this particular product", as open source software can be made relatively portable these days. It's the Prime hardware today, and also perhaps a desktop application for PC, and perhaps a phone/tablet app in the future, or a port to a platform doesn't yet exist. Hardware can be replaced when it ages, and open source projects can outlive the hardware they were created for. Open source software has value by itself, regardless of the hardware it runs on.

Developing new firmware is not to "add value to the hardware", but to use the hardware to "host the new project" for the time being. Just a matter of perspective.

[DrD]

-- Hardware
Hardware, like I mentioned, hasn't found it's way to the consumer marketplace. The marketplace is rich with calculator and other programmable devices, and selection of one or another isn't much more than competition looking for opportunity, driving costs down. There are quite a few things that can be done, at the layman's level, with regard to a hand held versatile device, that hasn't been exploited to this market segment (yet). It might easily cross over everything from automotive to medical, to scientific, weather technologies, etc., well beyond mere calculation. I think such a consumer grade product would be quite a marketable item.

-- Museum antiquities
Reviving legacy software may not be a totally bad thing, but, what's the point? Proving that your fathers software can be made to run on a machine intrinsically capable of better performance, is great for capturing a moment in time; but hardly a countermeasure for problem solving "performance" limitations, such as an inter-woven web of goto branching.

-- Open source
It's conceptually, a good thing. I readily agree. More to the point, there isn't anything about the Prime internally, that IS open source. Open season, perhaps. Developing third party firmware, or overlaying an old BASIC language interpreter, (I predict), isn't going to find much momentum, here or anywhere else. What percentage of Prime owners are likely to implement either? Re-purposing the Prime, isn't much better than using Arduino or similar devices, or leveraging retired PLC's, where open source has greater opportunity.

--
So, like they used to say in the legacy photography business, we'll just have to "watch and see what develops."

[toml_12953]

(01-08-2016 04:07 PM)DrD Wrote:  Developing third party firmware, or overlaying an old BASIC language interpreter, (I predict), isn't going to find much momentum, here or anywhere else. What percentage of Prime owners are likely to implement either?

It's my hobby and if other folks like the interpreter I produce, great! If not, that's OK, too. I'm not out to change the world or produce a great piece of software that will make me rich. I'm just going to write an interpreter for my own use and will freely share it with anyone interested (and foolhardy?) in BASIC. BASIC has provided me a comfortable living since 1971 and I really like it. It works the way I think (or did it form the way I think?) and there's a great nostalgia value. You can keep OOP. I'll keep on with good ol' Von Neumann, thanks!

Tom L

[smp]

(01-08-2016 05:55 PM)toml_12953 Wrote:  I'm just going to write an interpreter for my own use and will freely share it with anyone interested (and foolhardy?) in BASIC.

I am eagerly waiting to see your progress, Tom.

If you need anyone to test your package as you go along, please let me know.

smp

[DrD]

(01-08-2016 05:55 PM)toml_12953 Wrote:  It's my hobby and if other folks like the interpreter I produce, great! If not, that's OK, too. I'm not out to change the world or produce a great piece of software that will make me rich. I'm just going to write an interpreter for my own use and will freely share it with anyone interested (and foolhardy?) in BASIC. BASIC has provided me a comfortable living since 1971 and I really like it. It works the way I think (or did it form the way I think?) and there's a great nostalgia value. You can keep OOP. I'll keep on with good ol' Von Neumann, thanks!

Tom L

That's the best reason to do it, Tom. Good luck, and enjoy the ride!

-Dale-