12-10-2016, 02:39 AM
Post: #41
 DavidM Senior Member Posts: 544 Joined: Dec 2013
(12-10-2016 01:25 AM)rprosperi Wrote:  The BETA and compatibility warnings (fully appropriate to do so and appreciated) are bit of an impediment.

...which is a good reason to try things on an emulated system first. I realize not everyone has that option, but it's a nice way to safely try things out if you have it available.

Years ago when I first started digging into SysRPL I learned very quickly that one of the first things I needed to do was to create a customized backup and restore suite that would work for both Emu48 and the real calcs. It's probably my most used set of apps now.
12-10-2016, 10:02 AM (This post was last modified: 12-20-2016 10:48 PM by Software49g.)
Post: #42
 Software49g Junior Member Posts: 46 Joined: Mar 2014
Hello

> Yes, it is reproducible. What information do you need me to provide?
Basically everything that you have done to reproduce the bug.
I can only fix it if I am able to reproduce it.

In this case more information is better than less, even if you believe it is not important.

This includes (but is not limited to)
- ROM version
- flag settings (system and user)
- installed sw and where stored
- etc.

If you are able to reproduce it in the emulator, then please send me a snapshot of it. This would make things a lot easier for me.

Please provide the _exact_ steps needed for reproducing the bug.
Remember:
"The only good bug is a dead bug"
(Starship Troopers, 1997, Paul Verhoeven)

As you have already noticed, there can only be one library with a SOL replacement installed, so it may well be, that two libraries are conflicting as they try to fight for the same resources.
And if such two libraries reside in the system it will lead to conflicts sooner or later.

> Warning:
> Invalid Card Data
These means something really screwed up and corrupted memory in a non recoverable way.

> an incompatibility with my large 772 library
What is this?

HTH + BR,
Andreas

http://www.software49g.gmxhome.de
12-10-2016, 11:31 AM (This post was last modified: 12-10-2016 11:44 AM by JDW.)
Post: #43
 JDW Member Posts: 181 Joined: Jun 2016
Andreas,

My 50g has the latest 2.15 ROM.

My calculator has a lot of flags but most are set to the default. If you need them all then tell me how to easily report all of them to you.

The only software I have is my 772 Library (I will PM that to you) and the standard HP libraries (226, 227, 229) in Port 2.

I cannot reproduce it in an Emulator because each time I try to install your MessagesEnglish.hp Library, when I Warm Start the emulator, it crashes -- every time. I am using the HP Virtual Calculator Version 3.1.29 with HP50g(1024x768) skin, running on my iMac using Crossover (WINE). I can install my 772 and other Libraries in that emulator just fine. But again, your Library crashes the emulator. But that could just be a bug in WINE (the app that lets me run Windows apps on my Mac). Here is how I try to install your Library on my Emulator:

1. Drag "MessagesEnglish.hp" to the emulator's screen.
2. Stack level 1 says: Library 261: Engli...
3. I put 0 (zero) on the stack and press ENTER.
4. I press the STO button.
5. LeftShift & APPS (FILES) shows IRAM has dropped to 148K, which means it's stored in Port 0.
7. I right-click the ON button to keep it held down, and then I click F3.
8. A couple seconds later, I get an error dialog that says:

The program HP50g Virtual Calculator.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience.

If I click the Show Details button, I see the following:

Code:
 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x0082c447). Register dump:  CS:001b SS:0023 DS:0023 ES:0023 FS:1027 GS:000f  EIP:0082c447 ESP:00fef544 EBP:00fef55c EFLAGS:00010297(  R- --  I S -A-P-C)  EAX:00000000 EBX:00000007 ECX:00000000 EDX:00856820  ESI:00000000 EDI:00000014 Stack dump: 0x00fef544:  00856820 00856820 0000000f 00000000 0x00fef554:  00000000 0000000f 00fef614 0082c799 0x00fef564:  00000000 00000000 0058c07c 000800ff 0x00fef574:  00000014 0082f942 00856820 00000000 0x00fef584:  000800ff 00000014 00000001 008328bf 0x00fef594:  000d6ba7 00856820 00857c50 00857c50 0204: sel=1027 base=7ff80000 limit=00000fff 32-bit rw- Backtrace: =>0 0x0082c447 in kos50 (+0xc447) (0x00fef55c)   1 0x0082c799 in kos50 (+0xc798) (0x00fef614) 0x0082c447: movl    0x0(%eax),%edx Modules: Module    Address            Debug info    Name (284 modules) PE      340000-  34c000    Deferred        command PE      350000-  35c000    Deferred        xml PE      360000-  37a000    Deferred        gui PE      380000-  397000    Deferred        macro PE      3c0000-  3d4000    Deferred        info PE      400000-  447000    Deferred        hp50g virtual calculator PE      780000-  78b000    Deferred        prefs PE      7a0000-  7b2000    Deferred        tips PE      7d0000-  7e2000    Deferred        connect PE      820000-  867000    Export          kos50

I don't have a Windows PC at home, nor do I have Boot Camp setup on my Mac.

--James
12-10-2016, 03:09 PM
Post: #44
 rprosperi Senior Member Posts: 2,553 Joined: Dec 2013
(12-10-2016 02:00 AM)JDW Wrote:  I then performed another Warmstart so I could see 143241 of free RAM in the upper right again. I pushed-and-held the TOOL button for more than 1 sec. and released, and my menu bar vanished (as it should). Free RAM down to 121650. I long-pressed TOOL again to toggle the menu bar back ON. Free RAM down to 105986. I pressed TOOL to toggle again and now RAM reports 89299. Repeated toggle again and now it's 74147. Again and now it's 59796. Then 45196. Then 30621, 18808, 5098, and then it's back to 141597 again. No lockup, so I guess that's normal?

The RAM was being consumed by the library and not being restored probably because Garbage Collection had not occurred. The MEM command forces Garbage Collection and then reports free RAM. Try this after toggling the menu on/off and you will likely see the reported RAM restored. All this is normal, you simply have visibility into what's happening via the new RAM display; until now the only way to see it is via MEM (or the File Manager) which do garbage collection before reporting.

--Bob Prosperi
12-10-2016, 10:08 PM
Post: #45
 Software49g Junior Member Posts: 46 Joined: Mar 2014
Hello,

> The only software I have is my 772 Library
That sounded to me as you are using a library that you developed for you own purpose.

The latest Library 772 you are referring to is commonly known as "Library 772: EEPro ß5A GaaK" which was an (unsuccessful) attempt of bringing EE Pro for the 48GX (by Sparcom) to the 49G platform. Details about this is available in the internet / comp.sys.hp48 newsgroup.

This "Library 772: EEPro ß5A GaaK" is
- abandoned software
- beta software
- and by the time I devolved EEI for TB I found several serious EE calculations errors as I checked EEI for TB against EEpro ß5A
- additionally it contains several severe bugs, in terms of both: EE calculations and implementation to the 49G platform

If you are looking for a serious software for electrical engineering then I strongly suggest that you take a look at Electrical Engineering For TreeBrowser, which is unrelated to EEpro but offers a similar feature set. However, it does require TreeBrowser and GUISLV/GUIMES which is part of the MLP/OSE.

For your convenience I have attached the documentation for my Library 1666 (which is Electrical Engineering For TreeBrowser) and which does not contain the bugs of EEPro ß5A.

However, I can not reproduce the problem you are mentioning (although I did some minor code changes since the last release), neither with EEPro ß3A nor with EEPro ß5A.
I am getting "Insufficient Memory" as error, as expected.

Software in Port0

Warmstart

Press [TOOL] for ca. 1 sec.

Press [RS] [CAT] -> "Insufficient Memory" error as expected

Please try with the attached newer release and let me know any further bugs you might find.

> I am using the HP Virtual Calculator Version 3.1.29
Please consider using Emu48 from Christoph Giesselink, the software runs fine in it and this is what I am using for testing it.

TIA
Andreas

http://www.software49g.gmxhome.de
12-10-2016, 10:59 PM
Post: #46
 matthiaspaul Senior Member Posts: 388 Joined: Jan 2015
(12-10-2016 11:31 AM)JDW Wrote:  My 50g has the latest 2.15 ROM.
[...]
I cannot reproduce it in an Emulator because each time I try to install your MessagesEnglish.hp Library, when I Warm Start the emulator, it crashes -- every time. I am using the HP Virtual Calculator Version 3.1.29 with HP50g(1024x768) skin, running on my iMac using Crossover (WINE).
FWIW, the HP 50g VC 3.1.29 is using 2.16 ROM (the latest), whereas the hardware calculator uses 2.15.

Greetings,

Matthias

--
"Programs are poems for computers."
12-10-2016, 11:12 PM
Post: #47
 Software49g Junior Member Posts: 46 Joined: Mar 2014
Hi Matthias,

thanks for the info.

AFAIK ROM 2.16 is not available to the public, neither as pure Saturn ROM nor as ARM enhanced ROM. (Although the pure Saturn ROM could be extracted from the emulator.)

Regards,
Andreas

http://www.software49g.gmxhome.de
12-10-2016, 11:22 PM (This post was last modified: 01-27-2017 07:44 AM by JDW.)
Post: #48
 JDW Member Posts: 181 Joined: Jun 2016
Andreas,

I just tried your new version Library on my 50g (not the emulator). With both the 772 library and your library, when I try to open CAT, I now get the Insufficient Memory error rather than a lockup.

The 772 library was just something I found on the internet long ago and which I used as a "large filesize library test." But thank you, Andreas, for pointing out that it has calculation errors and for posting the manual to your EE software. When I have time later today I will try other large libraries at the same time I have your library installed, but probably they would act the same with regard to limited memory. For now, it seems you fixed the lockup by making it trigger an Insufficient Memory error instead.

Thank you gentlemen for the information on ROM versions. Yes, I was referring to my actual 50g calculator only when I said I had 2.15.

By the way, has anyone other than myself and Andreas actually tested Andreas' library on a 50g emulator or calculator? If not, it takes no time at all -- give it a go!

Best,

James
12-10-2016, 11:46 PM
Post: #49
 Software49g Junior Member Posts: 46 Joined: Mar 2014
Hello,

please try testing under forced low memory conditions.
I’d interest in what you find out and if there are any special circumstances to cover.
As always, I must be able to reproduce it.

TIA,
Andreas

http://www.software49g.gmxhome.de
12-11-2016, 12:42 AM
Post: #50
 DavidM Senior Member Posts: 544 Joined: Dec 2013
(12-10-2016 11:22 PM)JDW Wrote:  By the way, has anyone other than myself and Andreas actually tested Andreas' library on a 50g emulator or calculator? If not, it takes no time at all -- give it a go!

Yes, I have as well. Not the latest one that Andreas posted, but the previous one. For what it's worth, I also ran into both a lockup and a warmstart when in memory-constrained conditions (ie. when a GC still wouldn't leave more than 2-3K or so available). I was never able to find a repeatable pattern to it, though. I'll try the latest one as well when I can.

If you're wanting to to reduce the memory available, there's several ways to do it that are easier (and possibly safer) than installing libraries. The easiest that comes to mind is to use MAKESTR to make a very large string object. You can either leave it on the stack or store it somewhere, depending on what part of the calculator's memory you want to affect.

MAKESTR takes one argument, which is a number representing the number of characters that will be in the string object it creates. The 50g is perfectly happy making large strings this way, so you can create large objects to fill up whatever memory area you prefer. MAKESTR is a command from the Development Library which is built-in to all 50g's, but you may have to attach library 256 to make sure it's available.
01-12-2017, 09:51 AM
Post: #51
 Software49g Junior Member Posts: 46 Joined: Mar 2014
Hello,

by rearranging and further compression of the code I was able to squeeze the new functionality into the German version of the MLP - so I believe, that this is the last beta of the message library that allows hiding the soft menus
Please report any bugs that you might find.

This library contains also many bug fixes and speed improvements.
Note that this version will run from any port - as a matter of fact it is designed to run from a covered port without speed penalties.
However, there is still the limitation of a max. of 12 display lines (Font6/MiniFont with Header0 and the menu activated) as I am really running out of space.

Also note, that the new ChooseBoxEngine has a severe bug that will crash your machine under low memory conditions.
The ChooseBoxEngine creates some of its routines into TempOb and then creates a program that calls this routine via a pointer and that pointer is in TempOb.

This is what the ChooseBoxEngine does when a key is pressed:

1. it creates a program in TempOb and the
PTR_[in TEMPOB]ProgramCreatedIn_KeyHandler
is on Level1 of the SYS-RPL DataStack
2. Now a piece of ML code wraps this pointer from Level1 into another secondary.
:: TakeOver GetMetaVStack DROP PTR_[in TEMPOB]ProgramCreatedIn_KeyHandler 11GETLAM SetMetaVStack ;

But it is not allowed to put a pointer [in TEMPOB] into a secondary as a garbage collection will not recognize it as a referenced pointer and therefore a garbage collection might delete or move the code the pointer it referring to. For that reason, ::N (or similar SYS-RPL commands) embeds the content of a pointer into the secondary so that it is part of the secondary to be created.
Now if a garbage collection might happen in GetMetaVStack due to low memory conditions, then the garbage collection might delete or move the code the pointer it referring to and the HP 50g will crash.
Note also that this is a worst case scenario for the garbage collection as in this case it must keep track of ~ 850 catalog entries (exact number depends on installed libraries), the SYS-RPL DataStack content, the SYS-RPL ReturnStack content, additional VStacks, LAMs and further internal pointers. So garbage collection may take up to ninety seconds on a real machine!

Bugs like this are hard to find, because it will work fine unless the garbage collection happens directly inside the program (created by the ML code of the ChooseBoxEngine) before the embedded pointer.
Note again, that it is strictly forbidden having pointer in secondaries that point into TempOb. However it is save to use, if this a pointer into a memory area that is not covered by the garbage collection, e.g. ROM or absolute RAM.

This has been fixed, where the MLP/OSE uses the new ChooseBoxEngine (help entries choose list, catalog of all commands), but the error still resides in the ROM for other choose boxes called by the O.S.!

HTH+BR,
Andreas

http://www.software49g.gmxhome.de
01-12-2017, 01:15 PM
Post: #52
 BartDB Member Posts: 105 Joined: Feb 2015
Hi,

Sorry for the lack of participation - however I have followed this with interest but just have not had much time recently.

I have not tried Andreas' solution as he states it is not compatible with MLP/OSE and I am using his OSE. (I guess because one of the MLP/OSE libraries already has a replacement SOL and this would cause a conflict).
I hope it will be incorporated into future MLP/OSE releases.

I am trying out David's solution at the moment (although I had to change my calculator's date due to the expiration of the beta status of the library).

At this stage I like the menuless stack with line numbers (13 lines displayed with mini font & no headers).

Many thanks to all participants.
01-12-2017, 03:55 PM
Post: #53
 DavidM Senior Member Posts: 544 Joined: Dec 2013
Hey Bart -

Thanks for experimenting with the NoMenu prototype. The version posted by James in this post has a later expiration date that should allow you to leave the date set properly (at least until 2017-02-20). It also had a few minor changes and bug fixes.

That said, I have to say that Andreas' solution is much more robust and has been designed from the ground up as a finished product. The NoMenu library is merely a prototype, and its focus is more on testing certain features and not so much on optimizing performance (load up your stack and you'll see what I mean ).

NoMenu was originally targeted at simply removing the menus, but quickly changed to be an experiment with a different goal. Namely, testing out a user interface that dynamically changes based on context. Since the initial feature was removing the menus, the first thing I wanted to test was having the menus automatically reappear in certain contexts. While I'm not yet convinced that my specific implementation of that is the best approach, I do still believe the concept is worth further investigation. It could also apply to display features other than the menus (eg. the header and its contents, stack level numbers, other as-yet-unavailable indicators).

I will confess that part of my motivation for this came from playing with NewRPL. The additional space allocated to NewRPL menus made me begin to think about alternatives to how to use the available display real estate.
01-24-2017, 12:55 PM
Post: #54
 BartDB Member Posts: 105 Joined: Feb 2015
Hi David,

Thank you, I have been using it for a few days now and it's working great. My personal preference is the 10 lines in normal font with line numbers. Your method of toggling and holding menus works nicely.

I have not tested it comprehensively in a wide range of scenarios, but so far in my day-to-day use I have not experienced any errors or crashes.

Regards, Bart
01-24-2017, 03:48 PM
Post: #55
 Software49g Junior Member Posts: 46 Joined: Mar 2014
Hello,

although I wished that more feedback would be given I am happy to announce that the final version of the MLP/OSE allowing hiding the soft menus will be released soon.
If no further bug is found, I’ll recompile it for all languages and for all help entries which takes some time…

Some highlights:
- finally runs from every port while hiding the menu
- very fast and very robust, additionally fixes for internal errors in the ROM
- supports seven languages (EN/DE/IT/FR/ES/PT/PL)
- modified display routine completely written in Saturn-ML (except where calls into the ROM happen)
- improved and faster help
(additionally available: built in help for all commands, including examples for every command (RPL and ALG), stack diagrams, access, flag settings, "hyperlinked" navigation to related commands and more, see video for more info
DEUTSCHE HILFE für den HP 50g - Eingebaute Hilfe für alle Befehle
HP 50G Full Command & Function Reference incorporated into the O.S.)
- help engine completely written in Saturn-ML
- improved EQNLIB with faster and improved solver
- a GUI for the multiple equation solver
- and much more

Hiding the soft menus will now be part of the MLP/OSE and the update section of my website will include these updates asap.

Enjoy,
Andreas

http://www.software49g.gmxhome.de
01-24-2017, 04:17 PM
Post: #56
 BartDB Member Posts: 105 Joined: Feb 2015
(01-24-2017 03:48 PM)Software49g Wrote:  Hiding the soft menus will now be part of the MLP/OSE and the update section of my website will include these updates asap.

As I am using your OSE I will be looking forward to that, thank you.

Regards,
Bart
01-27-2017, 08:03 AM
Post: #57
 JDW Member Posts: 181 Joined: Jun 2016
Andreas,

Sorry for my testing delay, but I didn't have time until today.

I installed your Version 2.11 beta into Port 0 (without my large 772 installed) and found it runs fine. I then noted that you said it could be run in any port, so I did a warm-start (ON-C) with BACKSPACE held down (to prevent the library from loading), and then I deleted your library. After that, with my SD card still inserted, I copied your MessagesEnglish.hp to Port 2 (Flash). But when I do a warm-start (ON-C), it displays the "(C) 2017..." text screen forever, with the hourglass displaying the whole time. Pressing ON does nothing. Pressing right-shift-ON does nothing. I cannot use ON-C to warm-start. And even ON-A-F doesn't work! So I had to press the RESET button on back with a paperclip and then I held down BACKSPACE to keep the library from loading. That worked. But doing ON-C causes the same lockup, so this is a repeatable bug.

After all that, I deleted your library from Port 2 (flash) and then copied it from my SD to Port 1 (ERAM). I then pressed ON-C to warm-start, but it showed me the following text error screen:

Out of Memory

Purge?

Last Stack

I pressed A which corresponded to YES. Then "Last Stack" changed to "Last Arguments" and I pressed YES again. Then "Arguments" changed to "Alarms" and I grew frustrated so I pressed F for "No" but that changed "Alarms" into "STARTUP (Program)" and I grew upset. So I pressed ON-A-F and then NO to wipe everything. Of course that didn't wipe "everything" because your library was still sitting in Port 1 (ERAM), so I used the filer to delete it.

All said, I cannot use your library version 2.11 beta "in any port" as you describe. If there is some trick to do so, please let us know what it is.

I would encourage the rest of you following this thread to try the same on your own 50g's.

Thanks.
01-27-2017, 02:09 PM
Post: #58
 Software49g Junior Member Posts: 46 Joined: Mar 2014
Hello,

well, it is a ßeta - but thanks a lot for testing.
However, it does work fine in Port1/2 here, so I am curious what is happening.
Which ROM version are you using?
Can you try again in Port2 with a fresh/clean machine (preferable by deleting everything with [ON]-[A]-[F] and removing all other libs) and tell me what is happening?
The software does need a couple of internal system RAM to store its status/information and more. If this interferes with another lib then there will be trouble. And it is not easy to find RAM that is unused for this, as of course the 50g needs internal RAM to for saving its information.

The final version should not have this problem (so you gotta wait for it :-) but of course I can not test all possible combinations out there (especially in combination with other beta libs).

HTH,
Andreas

http://www.software49g.gmxhome.de
01-28-2017, 01:55 AM (This post was last modified: 01-28-2017 05:27 AM by JDW.)
Post: #59
 JDW Member Posts: 181 Joined: Jun 2016
When I type VERSION and press ENTER, it shows me:

Version HP50-C
Revision #2.15

Furthermore, holding down the + and the - keys while pressing the reset button on back shows:

BOOT V4.01.03.03

I also performed the FLASH test and the SRAM test and found no problems.

Using ON-A-F to reset followed by installation of your library in either Port 1 or Port 2 does not resolve the problem. There are no other libraries installed, except for the 3 stock HP equation and periodic table libraries that always appear in Port 2 (flash):

226: EQLIB
227: EQLIB
229: PRTBL

So again, for me, your library works fine in Port 0 (assuming I don't have any other big libraries in Port 0), but your library gives me trouble in Port 1 and Port 2.

I would like to encourage David and others reading this thread to give your library a try in Port 1 and Port 2 so we then have a greater pool of data that can be analyzed.

Thanks.

James
01-28-2017, 01:41 PM
Post: #60
 DavidM Senior Member Posts: 544 Joined: Dec 2013
(01-27-2017 08:03 AM)JDW Wrote:  Sorry for my testing delay, but I didn't have time until today.

The same applies to me.

(01-27-2017 08:03 AM)JDW Wrote:  I installed your Version 2.11 beta into ...
...Port 0...
...Port 1...
...Port 2...

I would encourage the rest of you following this thread to try the same on your own 50g's.

I tried the same 2.11 beta on a "totally empty" v2.15 50g -- there were no objects other than the messages library installed in any port (not even periodic table or eqn lib), and ON-A-F was performed to clear all standard memory. The only change from factory reset was to change to RPN mode.

My results were exactly the same as James'. The library appeared to work properly from Port 0, but would not install itself successfully on warmstart from Port 1 or 2.

Andreas: is version 2.11 the correct one for testing from covered ports? That's the latest one I saw posted in this thread.
 « Next Oldest | Next Newest »

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