New version of the WP34s Qt Emulator



#32

I've just uploaded a new version of the Emulator for the 3 platforms, svn revision 2745.

It implements a better keyboard support, closer to the WP34s behavior including autorepeat (on arrow keys) as well as NULL after a while.

There is also an option in Preferences/Keyboard to activate or not the H-shift shortcut by clicking on the green label.
It is true by default.

The "Always use H-shift click" options allows clicking on the green label to override existing F or G shifts. It is false by default.

I've also uploaded new versions of the WP34sFlash tool for the 3 platforms. No big change but a few cosmetic improvements and I've added a text only version too.
I've not fully tested this flashing tool. It works, implements the exact same protocol as MySamba and should be harmless but I would be glad to hear from the first users.

Have fun and a nice week-end.


#33

Quote:
I've just uploaded a new version of the Emulator for the 3 platforms, svn revision 2745.

Thanks, working fine now!

The 'serious bug' (oops, sorry, of course I meant 'tiny problem' ;-)) with the keyboard is fixed now.

BTW, you're ahead of your time: while the SVN still is at version number 2749, your emulator already shows 2750! :-)

Franz


#34

yeah, take those emulator revision numbers with a grain of salt. The build scripts assume you will check in the emulator and a calc.bin and so increment the string to what the revision will be if checked in.


#35

Dominic, just add a command line parameter to the CreateRevision program to increase or not the revision number and all is fine if you do not set it for the Qt builds.

#36

Thanks, Pascal, but I want to let you know that the bug I detected whereby the Qt emulators will not properly read user-compiled state files persists.

This is what I do to reproduce the bug. I delete what wp34s.dat file, then create a fresh one by opening then quitting the Qt emulator.

I then use this wp34s.dat file as a "seed" upon which to build a new wp34s.dat by compiling and inserting the contents of my text listing ram.txt:

$ wp34s_lib.pl -ilib wp34s.dat -state -olib wp34s.dat ram.txt

The new wp34s.dat compiles fine. But when I use it as the wp34s.dat RAM state file for the Qt emulator, the first time the Qt emulator opens the display shows "Erased" and there is nothing in my RAM catalog.

HOWEVER, if I take this very compiled file, move it over to the directory where my Windows (not Qt) emulator lives, the emulator opens fine and the RAM catalogue is just as I compiled it. Moreover, once I close out the Windows emulator and wp34s.dat is resaved, I can use it in the Qt emulator now and it behaves as it should've in the first place. It is as though opening and resaving it in the Windows emulator fixed some glitch so that the file could be read by the Qt emulators.

This isn't a Windows vs. Mac thing. It happens with both the Windows and Mac Qt emulators. I can't speak for the Linux version.

Pascal, this may be an esoteric thing to some users, and there is indeed a workaround (open and resave a compiled wp34s.dat file in the Windows emulator before using it in a Qt emulator), but for serious program and library management it would be nice if this worked with the Qt emulators as seamlessly as it does with the original Windows emulator.

Many thanks in advance,


Les

P.S. I should note this applies only to libraries compiled for RAM usage using the -state switch. Libraries compiled in the flash format as wp34s-lib.dat are read just fine.


#37

I guess that the state files created by the Qt emulators don't follow the exact same format used by the Windows emulator or the device (RAM image). Most probably the checksum generated by wp34s_lib.pl is not recognized as valid by the Qt implementation. What is the size of the state file created by the Qt version of wp34s? Does it change after wp34s_lib.pl has touched it?


#38

The file starts out at exactly 2048 bytes and does not change.


#39

I do not know what the problem is and I am not at home this week-end but I'll look into it next week.
Should be easy to fix.

#40

Quote:
What is the size of the state file created by the Qt version of wp34s?

I've now made a few tests with the standard emulator and the QtGui version (both on Win7):

If I start both emulators without any wp34s.dat and let them create one after closing the emulator, both files have 4 bytes different in the last 32 bytes (of 2048).

If I load the same program from the flash library wp34s-lib.dat into RAM (with RCL from the catalog) in both emulators, then (after closing) suddenly both wp34s.dat files are exactly the same, i.e. those 4-byte-difference has disappeared.

Since I don't find any infos about the layout of this 2048 bytes in wp34s.dat (especially the last 32 bytes), but I guess it contains the RAM state (regs, flags etc.), so I think this 'initial RAM state' is a bit different in the QtGui and the standard emulator, and maybe that's the reason for the reported problems!?


#41

Franz, the layout is in data.h. Look at the PersistentRam structure.


#42

Quote:
Franz, the layout is in data.h. Look at the PersistentRam structure.

Well, that would be some work for a non-C-programmer to rebuild this table, because I'm not even sure about the sizes of all those (un)signed short/int/long in C.

This is definitely easier for you, I'm sure you'll immediately know the meanings of those table locations, so here are these 4 differences in the new created wp34s.dat:

000007E0: 00 01
000007EE: 00 01
000007FE: 8C B7
000007FF: A1 00
The 1st byte is from the standard emulator, the 2nd from QtGui.

I guess the last 2 bytes are the CRC, but I've no clue what 7E0 and 7EE are.

Both files work in both emulators, but if you use this wp34s.dat as base in the libtool (with -ilib), then only the 1st one is working in the QtGui-emulator, the 2nd one gives "Erased" again and removes every program added by libtool.

One strange thing is that after I load any program from the library (wp34s-lib.dat), then both state files are equal. So I think the problem is only that the very first statefile created by the QtGui version is buggy (the CRC and those other 2 bytes), but after loading any program into RAM this statefile is corrected.

Edited: 1 Apr 2012, 11:30 a.m.

#43

Les, one more question: On what type of machine are you testing the Qt version (processor and OS)?


#44

Quote:
Les, one more question: On what type of machine are you testing the Qt version (processor and OS)?

I run the Mac version on a Mid-2007 24-inch iMac (iMac 7,1, 2.4 GHz Intel Core Duo) running OS X 10.7.3. The Qt Windows version is run on Windows XP, virtualized via the latest version of VMWare Fusion running on the same Mac. As I sad before this error occurs with Qt emulator both in Windows XP and OS X.

Also, though I should admit I don't spend as much time doing this stuff on the other computer, I have encountered the exact same thing on my 2007 black Macbook with a 2.2 GHz Core Duo processor running OS X 10.7.3. I really am suspecting this a quirk of the Qt emulator irrespective of OS, processor, etc.

Les

Edited: 1 Apr 2012, 9:29 a.m.


#45

I had suspected a problem with a big endian processor (Power Mac) but this is all Intel. You can try if the Qt emulators and the classic Windows emulator accept the same state file.

#46

I should also add that I downloaded and set up the Qt Linux version in my rarely used Ubuntu VM. Exact same problem. This is a Qt issue, not an OS issue. I think Franz is onto something.

Les


#47

There were a few updates to the RAM layout recently. You can only reliably compare identical revisions.

OTH, the assembler output shouldn't be affected by these changes. That a state file updated by the tool isn't accepted is certainly unintentional.


#48

This is indeed a CRC problem. I'll have a deeper look once I'm back at home with access to a proper debugging environment.


#49

Looks fixed, Pascal, on the recent upload. Thank you!!! I will test the Windows and Linux version too, when I get a chance, but at the moment the Mac version behaves as desired.

Best,

Les


#50

Thanks. And it was not really a CRC problem, just me calling the init routine where the check is done twice.


#51

I am glad I could help you find the bug. You got it fixed quickly.

Next, when I get the chance, I am going to try to figure out what I am doing wrong with the flash tool. I have tried both the Windows and Mac versions, and am getting an "unable to connect" error. MySamba still works fine, and, as I have said before, the serial commands with the Qt emulators work great. It's a shame that I still have to rely on MySamba under Windows, given that I can do everything else in OS X.

The question I have for you is this--does one prepare the calc differently for flashing than one does with MySamba? That could be my problem. What do you do?

TIA,

Les


#52

I'm sending the exact same bytes as MySamba. The only thing I do differently is closing/opening the port at each try. This is what SAM-BA does and I found it to improve reliability.
I'll check if this can cause a problem.

I've just flashed a WP34s with the new flash tool but as usual, I had connection problems. As I have the same with MySamba, I cannot tell yet where they come from. I'll investigate more in the next weeks.

What kind of cable & driver are you using on the Mac?

P.S: Serial communication is really a pain to debug. It depends a lot on timing which depends on the USB->serial adapter, the driver, the options used to open the port...

#53

Hi Pascal,

I've just discovered a new bug (in yesterdays release):

clicking on the green key label (i.e. the h-shifted function) does not work for the 4 keys [1],[2],[3] and [-]. For all other keys it's ok.

PS: Ahh, looking at your '.xskin files I see that for these keys it says height="-33"!?

I guess this should be "33" instead - must try it ...

Franz

Edited: 2 Apr 2012, 11:19 a.m.


#54

Yes, it doesn't work with the compact skins but ok with the medium one. I'll look into it.


#55

Quote:
Yes, it doesn't work with the compact skins but ok with the medium one. I'll look into it.

Yep, I just saw that there's more wrong for this row of keys, also the y="436" is not ok.

#56

Quote:
also the y="436" is not ok.

Not sure what you mean, can you be more specific?


#57

Quote:
Not sure what you mean, can you be more specific?

Well, for the "Down" key (key code="30") the y-value is correctly set to y="403" (402 would even be better), but for all other keys in this row it's set to y="436", and that's the bottom of the key but not the top.

Edited: 2 Apr 2012, 11:57 a.m.


#58

I was surprised as the .xskin files where created from the old .skin files. But this is because the top & bottom are inverted in the .skin file.

I've fixed it and I will build and upload distributions later.


#59

I've uploaded the fix.


#60

Quote:
I've uploaded the fix.

Thanks!

Now it's time for Marcus to also fix his 'Compact' and 'LED' skin, because I just found out that the error is already in his old skins.

key=30,36,403,79,436,   {40,77}
key=31,88,436,131,403, {49,97}
key=32,139,436,183,403, {50,98}
key=33,191,436,236,403, {51,99}
You see that for keys 31-33 the 436 and 403 are swapped, so it was in fact not your fault. ;-)

It seems that for the full key this wrong order of top and bottom number doesn't matter, but it confused your conversion routine for xskin-files and made a problem with the area for your h-shifted keys.

Franz


#61

This is original HP code I'm afraid. If I find the time I'll fix it but this has low priority.


#62

Quote:
This is original HP code I'm afraid. If I find the time I'll fix it but this has low priority.

Oh, then it's HP's fault - unless they also say "This is original ... code". ;-)

And a fix is indeed not so important, because it doesn't hurt your emulator version.


Possibly Related Threads...
Thread Author Replies Views Last Post
  wp34s Emulator (-Infinity Difference) Barry Mead 1 387 07-24-2013, 03:52 PM
Last Post: pascal_meheut
  wp34s Emulator (Display Residual) Barry Mead 3 501 07-23-2013, 04:22 AM
Last Post: Barry Mead
  New version of WP34s iOS emulator pascal_meheut 4 656 07-22-2013, 03:55 PM
Last Post: Matt Agajanian
  WP-34S QT emulator bug: real menus for catalogs Marcel Samek 8 991 07-09-2013, 11:25 PM
Last Post: pascal_meheut
  Catalogs as menus in WP34s Qt Emulator pascal_meheut 9 921 05-16-2013, 03:42 AM
Last Post: John Abbott (S. Africa)
  New version of the WP34s iOS emulator pascal_meheut 15 1,334 04-23-2013, 01:58 AM
Last Post: Walter B
  Improved debugger on WP34s Qt Emulator pascal_meheut 0 313 04-15-2013, 03:52 PM
Last Post: pascal_meheut
  WP34s iOS emulator now available pascal_meheut 33 2,463 03-26-2013, 01:21 PM
Last Post: pascal_meheut
  [WP34s] New TVM-solver version fhub 43 3,514 12-26-2012, 06:12 AM
Last Post: fhub
  New HP-82240B emulator in WP34s distribution pascal_meheut 6 721 10-07-2012, 05:07 PM
Last Post: Christoph Giesselink

Forum Jump: