v1.22 (13/12/2008)

[Yann]

Télécharger :

Phantasie Conquest - v1.22 - HP48 SX & GX - Français & English

Mirror : Phantasie Conquest - v1.22 - HP48 SX & GX - Français & English


Important Note : Bug reported when using an HP48GX with no RAM expansion card (thanks Klaus)

Nouveautés :
Passage au compresseur LZD, pour une meilleure réactivité et un code plus compact.
Fonctionne même sur un port FREE
Sélection des destinations beaucoup plus rapide

[Klaws]

Hi,

first of all, I'm sorry that I my grasp of the french language is not sufficient to discuss anything more complex than ordering food and saying "Merci beaucoup", so I have to resort to English ;-)

Now, my problem: I downloaded Phantasie Conquest to my computer, tranferred the english version to my (unexpanded) HP48GX via Conn48x into a variable 'Phastasie.LIB', placed the content of this variable on the stack (via VAR) and then I hit 0 STO to store the library. Then I hit right-shift LIBRARY....wondered why the no new library appeared....took me about 5 minuted to remember that I need to power cycle the HP48.... ;-)

Yup, after power cycling the library was there. I hit right-shift LIBRARY, hit PHAN in the menu, then PHAN to start Phantasie Conquest, and yessss, I was greeted by the start screen. Hitting ABOUT confirmed that this I'm runnign version 1.22.

Now, I tried to create a world. I hit CREAT and reache the WORLD MANAGEMENT screen. I then hit WORL....and the HP48 responds with "MENU ERROR: Invalid Syntax". The low 4 stack entries are

4:<1d>
3: " WORLD NAME*Su..." (well, that's as close as I can get transcribe the HP font...)
2: "MIDGARD"
1: 2

Now I'm stuck, obviously. I'm too dumb to install and play the game. I don't know if the game contains a bug or if I madde a mistake when installing the game...

Can anyone help me?

Thanks in advance!

Best regards, Klaus

[Yann]

Thanks for reporting Klaus

I will check that.
Strange that this escaped the torture test, as it seems an important and pretty straightforward bug you are describing....

[EDIT]
I tried to reproduce your problem, starting with a fresh install, on both SX Rev E and GX Rev R, but it worked without a problem.
So i guess we need to dig a bit further to understand what's happening. Could you please :
1- Specify your ROM Version
2- Check if you are limited by main memory
3- Best of all, if you are able to reproduce your problem on an Emu48 emulator (which is not easy , so if you don't know Emu48, you don't have to try), could you please send a snapshot of it ?
This way, the bug can be reproduced and tracked much more easily.

Regards

[Klaws]

I tried to reproduce your problem, starting with a fresh install, on both SX Rev E and GX Rev R, but it worked without a problem.
So i guess we need to dig a bit further to understand what's happening. Could you please :
1- Specify your ROM Version

My 48GX says it's ROM version is R (VERSION command output is "Version HP48-R"). I also ran the self-test which confirms that RAM and ROM are okay.

2- Check if you are limited by main memory

The MEM command answers 32084.5. My HP48GX contains no RAM cards, so I'm stuck with 128K RAM. I also purged the variable which contained the downloaded program (not used any more since it's installed as a library), which means that MEM now returns 78098.5. Phantasie Conquest still fails as desribed above, even with more RAM free.

Actually, I did a full reset of my 48GX this morning (ON+A+F, answering "no" to the question concerning the recovery of memory). After that, I downloaded only the X-Modem server of Conn4x (which I then used to download Phantasie Conquest).

3- Best of all, if you are able to reproduce your problem on an Emu48 emulator (which is not easy , so if you don't know Emu48, you don't have to try), could you please send a snapshot of it ?
This way, the bug can be reproduced and tracked much more easily.

Sorry, I've never used Emu48.

I'll try and repeat the procedure from the start; perhaps something went during the transfer.

[EDIT]
Same procedure as above (including full reset/memory clear, but this time remebering to turn the HP48 off and on before attempting to access the library...) and again the same result.

However, trying it multiple times I noticed two different behaviours on the "Create Screen". If I press the WORL menu key the usual way, I receive the mentioned error. If I give the key only a very quick tap, the screen goes blank (the menu bar remains, but the "main area" above gets blanked completely) and there's also none of the indicators above the normal display area active (yes, even the hourglass symbol disappears). Whenever I now press a key, the hourglass indicator appears for maybe half a second or so. The menu buttons still work; I can press EXIT and get back to the start screen, or I can press WORL agan and receive the mentioned error message.

Further content of the stack is:

17: { "NAME" "SIZE" "...
16: " WORLD CREATIO..."
15: " WORLD NAME*S..."
14: "*Creating World...."
13: "Small(24)"
12: "Normal(48)"
11: "Large(72)"
10: "H-Globe"
9: "Square"
8: "Single"
7: "Multi"
6: "Auto"
5: 70.8405

Best regards, Klaus

[Yann]

Your specs are more than enough to run the program on your calculator.

A good way to check if the transfer was correct is to do a "BYTE" command with library object on stack1.

It should give you :
Size : 46136
Checksum : #B5F9h (use HEX command if your result is Decimal)

[Klaws]

Full reset again ;-), download again. The BYTES command yields the correct size and checksum. Again I installed the library from the stack with 0 STO, again I tried to create a world, and again it failed :-(

Best regards, Klaus

[Yann]

trying it multiple times I noticed two different behaviours
If I give the key only a very quick tap, the screen goes blank

This i can explain, as this is known limitation, on all menus with Greyscale graphics.
When pressing a key, the interruption is trapped by the program which displays the greyscale graphics (this is an "active" program, because greyscale is not native to HP48).

The displayer stop its activity and the menu manager then kicks in.
It reads again the key buffer,
but if the key is no longer pressed, it detects nothing. This must be very quick, because the switch between the displayer and the menu manager is fast.

In this case : The Greyscale graphics is no longer displayed (blank screen), but the menu manager is still active, waiting for a valid key to be pressed.

This is a limitation i still have to find a way to tackle.

Further content of the stack is (...)

I see, thanks for detailed report,
these are the "ressources" used by the interactive screen.
They apparently did not even had a chance to get saved into temporary memory,
and therefore are still lying in the stack.
This helps me to understand where the problem could be,

Why i'm not able to reproduce the same effect is a mystery...

One last question :
Which directory is current when the problem happens ?
(it should be written on the top left status bar, line 2).

Regards

[Klaws]

(this is an "active" program, because greyscale is not native to HP48).

Yes, I already thought so - I never did a lot on the HP48GX (during school I had an HP-41C, and when I was in university, the HP-28S was still the most recent model; the HP-48 series came out two or three years later, and it took me even a few more years to convince me that I should buy it (used)...), but I already suspected that "greyscale mode" works by "page flipping".

One last question :
Which directory is current when the problem happens ?
(it should be written on the top left status bar, line 2).

It's { HOME PHAN.DIR MONDE }.

I also tried the whole procedure with the french version; same effect.

[EDIT]
I also downloaded version 1.17a from here; it displays the same error message...

Best regards, Klaus

[Yann]

OK, thanks very much, this is enough to start investigation right now.

There *must* be a bug, i just don't understand how come i'm not reproducing it, but i'll look directly into the source, and scrutinize anything suspect.

In the meantime, you may try a previous version of the game if you wish.
It should not change the result, as this part of the code had very little changes, but should there be any different result, this would target the problem with even better accuracy.

[Klaws]

Okay, I checked a few versions. Procedure was to reset the HP48 with ON+A+F (and "no" to recover). This time I transferred the files manually with Conn4x, just to make sure that the XModem Server library doesn't interfere with anything. A quick check with manual transfer and version 1.22 revealed that the problem occurs regardless of the XModem Server library.

I just checked if the world creation gets past the first keystroke without error. I tested the english version, whenever available (except 1.22 where I had already tried both language versions)

Anyway, here are my results:

1.06 works
1.13 works
1.15 works
1.16 fails (both compressed and uncompressed versions)
1.17 fails
1.22 fails

"fails" means that I received the same error as with 1.22, "works" means no apparent error (I get to the next screen where I alter the size, etc).

On 1.16 I noticed that the content of the stack looks similar to 1.22 (well, French instead of English, okay, and I didn't compare entry by entry, I just gave it a quick look), but the path is { HOME N RESS HATCH NONDE }. Obviously, I downloaded the Phantasie Conquest launcher to a variable named N.

Best regards, Klaus

[Yann]

OK, i may have something. Looks strange but ....

the "2" on stack1 when error happens comes from the command :
2 MENU

This is a standard UserRPL command, which basically do the same as the key "VAR", that is the menu display objects stored in current directory, 6 by 6.
"2 MENU" is really standard, valid UserRPL, so there is no good reason why it should fail.

Could you please try it ?
If it fails, then there is definately a problem with the ROM.
If not... well, i need to look harder.

Now, i'll look into older versions of Phantasie too, to see in details what they are doing differently.

[EDIT] Mmmh, i've looked at previous versions, and indeed, the functions where the "2 MENU" happens has not changed.
So why should it work there and not on newest versions ?
My latest possibility is that the problem happens elsewhere, earlier, but stays hidden, and only result in a crash during the "2 MENU" call.
Which will make it very difficult to track down...

Typical situation creating such a crash is a memory leak, for example non-freed temporary memory. There are many new things happening at version 1.16, and maybe one of them is prone to such an issue.

[Klaws]

I tried
2 MENU
on the HP48's keyboard (actually, 2 ENTER alpha alpha M E N U ENTER) and it works (it displays the VAR menu, as it should).

Other menu numbers work as well. Actually, I do not know how I could get the MENU command to throw an error; the AUR even states that MENU will accept any object and store it in CST. It also mentions that a "Bad Argument Type" error may occur when the HP48 tries to display an invalid menu. However, this is not the error message I received...

The AUR also mentions that the error message "Invalid Syntax" occurs when the: "HP 48 unable to execute ENTER, OBJ->, or STR-> due to invalid object syntax.". I do not currently see the connection to "MENU" here...

Perhaps it might be a side effect, caused by disruption of some internal calculator register or data structure (as already hinted at, I know close to nothing about HP48 programming, but I know anout other HP calculators which could be easily disturbed by altering "system registers").

Best regards, Klaus

[Yann]

Thanks Klaus

It seems to be a problem which becomes apparent at the "%2 xMENU" command, but is in fact triggered much before.
Well, this is going to be a pretty difficult one.
Especially if i cannot reproduce the bug.

This remember me that, some time ago, i had some issue with unreleased LAMs (temporary objects, only accessible from sysRPL cource code). For some reason, i have no more any issue with these. The Garbage collector seems to correctly reclaim memory, even if not explicitly freed.
So could it be that my system is having a "cleaner" behavior ? If so, why ?
Maybe, as you mention, this could be due to System Flags, but we both started by purging completely our calc (ON+A+F), so no system flag is supposed to resist this one.

I'm puzzled...

[Yann]

Hurray !
i could recreate the bug !

Now that's a strange one.
The bug only occurs when there is no memory expansion card plugged in.
Up to now, i kept my memory expansion card within, and just disabled it. In this case, there is no problem. I have to physically remove the expansion card to get the same bug as you. Really weird.

Now, i don't have a solution yet, but at least, i can study the problem...

[Klaws]

Now that's a strange one.

Yes, indeed! I would have understood it if it was the other way around...

The only idea which came to my mind was a timing bug - something where my or my HP48 was, like 250ns faster or slower...but I don#t really consider myself qualified for such assumptions.

Best regards, Klaus

[Yann]

Well, the only good news so far, is that not-yet-released v1.30 seems free of this bug.
Unfortunately, v1.30 is a major rewrite of Phantasie Conquest, which is not completed so far.

With this result, i tried to swap a few routines from v1.22 by equivalent from v1.30, but without success, the same bug occurs under the same condition.
I tried to rewrite some old code which i considered not clean enough, but here too, without any effect.

Still something to find....

The only idea which came to my mind was a timing bug - something where my or my HP48 was, like 250ns faster or slower

Well, It could still be consistent with the problem observed. With an unplugged memory expansion, i would suspect access to main memory to be a bit faster.
But this nonetheless should not be enough to trigger such a bug.

I may find something by studying more closely the differences between v1.15 & v1.16, as you identified when things start to break up.

[Sponsored content]