DM-42 and WP-43S

[vido]

(03-01-2017 11:38 AM)Paul Dale Wrote:  I can't locate the precise processor being used in the DM-42 at the moment It is a decently resourced ARM core.

That's a bit of a problem. Does SwissMicros keep this kind of information a secret ?

[Hsilop]

(03-01-2017 11:38 AM)Paul Dale Wrote:  We never figured out why the Yagarto 4.6.0 compiler worked and others didn't.

The Yagarto 4.6.0 compiler is the way to go, then.

Does anybody have a step-by-step guide on exactly how to build this thing? No point in going the scenic route if it is not necessary...

[Massimo Gnerucci]

(03-01-2017 08:10 PM)vido Wrote:  

(03-01-2017 11:38 AM)Paul Dale Wrote:  I can't locate the precise processor being used in the DM-42 at the moment It is a decently resourced ARM core.

That's a bit of a problem. Does SwissMicros keep this kind of information a secret ?

Why should this be a problem?
Just give me a DM-42.

[Guenter Schink]

(03-01-2017 11:38 AM)Paul Dale Wrote:  I can't locate the precise processor being used in the DM-42 at the moment It is a decently resourced ARM core.

Pauli

The DM42P uses this board, plus 8MB of flash ram, thus total flash memory 9MB.
Günter

[emece67]

(03-01-2017 08:59 PM)Hsilop Wrote:  Does anybody have a step-by-step guide on exactly how to build this thing? No point in going the scenic route if it is not necessary...

This is, more or less, how I did it. Inside a virtual machine (a 20 GB one will be enough, but you'll only get about 5 GB free):

1. Install Windows 7 Enterprise
2. Install Java JRE (needed by the next)
3. Install jEdit (needs JRE, this is just the text editor I use to use, change to whatever you want)
4. Install TortoiseSVN
5. Install MinGW (mingw-get-setup.exe) with:
   • mingw-developer-toolkit
   • mingw32-base
   • mingw32-gcc-g++
   • msys-base
   • mingw32-libpdcurses (bin, dev)
   • mingw32-pdcurses (bin)
   • put the bin and msys\1.0\bin folders of MinGW in the PATH
     
6. Install Active Perl (ensure that its perl.exe is in the PATH before the perl.exe of MinGW)
7. Install MS VisualC++ Studio 2010
8. Install Yagarto 4.6.0 (ensure that yagarto\4.6.0\bin is in the PATH)
9. Checkout the SVN repository (svn://svn.code.sf.net/p/wp34s/code)
10. Tune the scripts makeflash.cmd and makelib.cmd inside the folder you have just checked-out to suit your system (one contains the path to the yagarto compiler)
11. Open a command shell inside the folder you just checked-out and execute the makeflash.cmd script. This may build the .bin ROM images for the wp34s
12. Open a shell inside the trunk folder and execute command: mingw32-make qt_gui_dist. This may build the emulator
    

Surely you will need some fine-tuning of makefiles, other scripts, the features.h file,... until you get a successful build.

Perhaps I may find a slot to check if the current, shiny, version of the ARM compiler can now cope with this build, instead of yagarto.

May the Force be with you.

[vido]

(03-01-2017 09:39 PM)Guenter Schink Wrote:  The DM42P uses this board, plus 8MB of flash ram, thus total flash memory 9MB.

Gee, thanks ! That's a bunch of much needed documentation !

[Paul Dale]

(03-01-2017 08:10 PM)vido Wrote:  That's a bit of a problem. Does SwissMicros keep this kind of information a secret ?

No, it isn't a secret. My home Internet connection is dead at the moment...

Still, the answer has been found.


Pauli

[pascal_meheut]

(03-01-2017 08:59 PM)Hsilop Wrote:  Does anybody have a step-by-step guide on exactly how to build this thing? No point in going the scenic route if it is not necessary...

Having a look at the project, reading the misc README files and maybe trying can be an interesting approach.

[Hsilop]

(03-02-2017 03:38 AM)pascal_meheut Wrote:  

(03-01-2017 08:59 PM)Hsilop Wrote:  Does anybody have a step-by-step guide on exactly how to build this thing? No point in going the scenic route if it is not necessary...

Having a look at the project, reading the misc README files and maybe trying can be an interesting approach.

I have, and I notice your name in the README_Linux.txt file. I don't see that Yagarto is mentioned anywhere in the source code or readme files, though.

[pascal_meheut]

(03-02-2017 08:59 AM)Hsilop Wrote:  I have, and I notice your name in the README_Linux.txt file. I don't see that Yagarto is mentioned anywhere in the source code or readme files, though.

Probably because being able to build, run & debug one of the emulators is the preferred way to start contributing to the project.
You were talking about the build system and the Yagarto compiler is not the real issue now that Paul & others have found a working version.

[Paul Dale]

(03-03-2017 02:47 AM)pascal_meheut Wrote:  You were talking about the build system and the Yagarto compiler is not the real issue now that Paul & others have found a working version.

It was Marcus not I


Pauli

[Nigel (UK)]

(03-02-2017 08:59 AM)Hsilop Wrote:  

(03-02-2017 03:38 AM)pascal_meheut Wrote:  Having a look at the project, reading the misc README files and maybe trying can be an interesting approach.

I have, and I notice your name in the README_Linux.txt file. I don't see that Yagarto is mentioned anywhere in the source code or readme files, though.

If you look here you will find instructions I wrote based on my own experiences. Other pages on that site may be helpful too. Good luck!

Nigel (UK)

[Matt Agajanian]

Hi there.

Thank you, Pascal, for offering iOS versions of both WP-31S and WP-34S. They are both quite easy and pleasant to use. Will you be offering an iOS version of the 43S?

[pascal_meheut]

(03-21-2017 11:53 PM)Matt Agajanian Wrote:  Thank you, Pascal, for offering iOS versions of both WP-31S and WP-34S. They are both quite easy and pleasant to use. Will you be offering an iOS version of the 43S?

I do not know: the 43s ETA is undefined so I cannot predict whether I will have the time and the interest when it arrives.

[vido]

(03-22-2017 09:02 AM)pascal_meheut Wrote:  the 43s ETA is undefined

It looks like a beta release is planned within a few weeks at most.

[pascal_meheut]

(03-22-2017 08:58 PM)vido Wrote:  It looks like a beta release is planned within a few weeks at most.

Is it? I guess I missed the info and as I've never had any information about the WP-43s except what I read here from time to time, it was easy to do so.

To be 100% honest, working on the WP-34s has been kind of a mixed experience so I'm not sure I want to continue.

[vido]

(03-23-2017 02:56 AM)pascal_meheut Wrote:  

(03-22-2017 08:58 PM)vido Wrote:  It looks like a beta release is planned within a few weeks at most.

Is it? I guess I missed the info and as I've never had any information about the WP-43s

Oops, sorry, I was talking about the DM-42, of which a beta release is expected soon-ish. In turn, the DM-42 is going to be used by the WP-43S developers as a development platform... but of course, there is no deadline for the WP-43S (it is developed as a hobby after all) and it may very well take a couple of years, if not more.

[c785]

I'm new to this forum, but not to HP, having got through university (and beyond) on an HP48G extended to 128kB.

I recently discovered WP34s, that's why I came here, and I'm in fact going to own one soon. Playing around with the simulator (as well as with Free42) I discovered that I don't quite understand why people love these machines so much, apart from the "geek factor": just those two lines in the display with X: and Y: on the 42 should put almost everybody off immediately. I'm not new to keypress programming, having had a chance to write some serious stuff in the 99 (cryptic!) steps offered on the HP20s, but that's another story because it isn't RPN.

What I don't get is why nobody considered actually adapting to the possibilities of new hardware. Faster processors and matrix LCDs would be ideal for:

1. fixing the RPN logic, which is somewhat weird on the 42 and WP34s (when exactly to press ENTER and when not); in fact, the HP48 has already done it.

2. fixing the fixed-size stack, also done on the HP48.

3. replacing keypress programming and its labels and gotos with RPL or similar for a much more robust and scalable programming experience. Again, the HP48 is miles ahead of everything else in this respect. Actually, it isn't even that different from keypress programming as far as program entry is concerned.

So, why isn't there any need for HP48-like features on the DM42, and why is exact HP42 compatibility such a high priority? I'm not talking about graphing, just the stack logic and programming.

[bhtooefr]

The simple answer is that, once you're used to the older behavior, it's faster than the newer behavior for many operations, especially with the stack replicating at its top level. (Of course, if you're NOT used to it, or you're doing something that logically works better with more stack... But the older enter key behavior is never slower once you're used to it (the quickest (although not the most efficient stack utilization) way to square on a RPN calc is ENTER *, but on an RPL or Entry RPN calc, it's either a shift and x^2 (slower when your fingers are down on the number area), or ENTER ENTER *), and I rarely run out of stack.)

And, there's another project to recreate an RPL environment if you want RPL - newRPL. I suspect it'll end up ported to this hardware. These firmwares are for people who want the 41 and 42 behavior.

[rprosperi]

(04-04-2017 03:43 PM)c785 Wrote:  ...
1. fixing the RPN logic, which is somewhat weird on the 42 and WP34s (when exactly to press ENTER and when not); in fact, the HP48 has already done it.

2. fixing the fixed-size stack, also done on the HP48.

3. replacing keypress programming and its labels and gotos with RPL or similar for a much more robust and scalable programming experience. Again, the HP48 is miles ahead of everything else in this respect. Actually, it isn't even that different from keypress programming as far as program entry is concerned.

I'm afraid the question of whether RPL 'fixes' RPN or not is a religious question, not a technical one.

The 34S painstakingly follows the RPN/entry model of the 34C, 42S, and other RPN machines because that's what thousands of users want it to do. There are no doubt certain advantages when using RPL, but many, many users prefer the simplicity and elegance of RPN with a stack-depth of 4, and keystroke programming.

As to why they prefer this, search the archives of these forums, there are likely > 1000 threads that cover this topic from many angles. There is no 1 simple answer that you may have missed, there are many, many simple answers, that when taken together form a compelling argument that the complexity and subtleties of RPL do not justify it's clearly higher power.

Just an opinion...