[WP34S] New GUI features

[Marcus von Cube]

The op codes are generated automatically so a "compatible" op code file is out of question.

Have you tried to add the -op option to the assembler name in the configuration?

[fhub]

(01-11-2016 03:13 PM)Marcus von Cube Wrote:  The op codes are generated automatically so a "compatible" op code file is out of question.

But I remember that we've already talked about this incompatibility many months ago, and Pauli said that it would be no problem to do it in a way that these new (complex) commands won't overwrite existing opcodes, but use free codes instead.
I don't remember the thread or posting, so I can't say how this can be done - nevertheless this would be a better solution.

Quote:Have you tried to add the -op option to the assembler name in the configuration?

I've tried it now and indeed it works - for the Qt-emulator this won't be possible, because there you can only enter the directory of the assembler (not the EXE itself, so you can't add options).

Franz

[BarryMead]

(01-11-2016 02:32 PM)fhub Wrote:  Hi Marcus!

There's a serious problem for users of the complex WP34s version when using the new 'Import program...' feature:
I'm rather sure that anyone using both (the normal and complex) emulators will probably have the assembler tools and the opcode files in one and the same directory (usually 'tools').
Now the opcode-files wp34s.op and wp34c.op are not compatible, but the GUI does not tell the assembler explicitely which *.op file he should use, and so he always uses the normal file wp34s.op - and this will of course lead to a wrong state file (with wrong or even illegal opcodes), when you import any sourcefile with the complex emulator!

I see 2 possible solutions for this problem:
1) The best way would be to change the opcode table of the complex emulator, so that 'new' opcodes (only existing in the complex version) would not overwrite opcodes of the normal version, but just use 'free' opcode numbers (there are lots of free places in wp34s.op). With this method we won't even have the need for an extra wp34c.op - all opcodes (the 'normal' and the 'complex' ones) would be in the same file wp34s.op.

2) The other method is to explicitely add the option '-op wp34c.op' in the complex emulator when calling the assembler, but in this case you would also have to add the location of the opcode file, i.e. a working option could be '-op ..\tools\wp34c.op' assuming the assembler and the opcode file both are in ..\tools.

IMO the first method with only one wp34s.op for both emulator versions is certainly the better choice (especially because the same problem exists for the QtGUI version, too!), but who can rewrite the opcode addresses in the complex emulator, so that they are at free places?

Franz

Franz: I came up with a completely different solution. I altered the source code for the QtEmulator.h file when I compiled my Qt emulators. For the Complex Branch I changed the "APPLICATION_NAME" to "WP34cEmulator" and I changed "STATE_FILENAME" to "wp34c.dat" and "BACKUP_FILENAME" to "wp34c-backup" and "LIBRARY_FILENAME" to "wp34c-lib.dat". This creates a completely different configuration file for the complex branch named WP34cEmulator.conf which I pointed at the complex branch tools directory. I did a similar thing with the "Bit's" version and it too uses a different op-code file. Now all of my emulators work perfectly and don't step on each others op-code, data, or config files.

[fhub]

(01-11-2016 07:20 PM)BarryMead Wrote:  Franz: I came up with a completely different solution. I altered the source code for the QtEmulator.h file when I compiled my Qt emulators.
...

Well, that's not so 'different' at all - Marcus has already done the same thing(s) in the normal (non-Qt) complex emulator. The problem I mentioned was only with importing files, because the call to the assembler didn't specify a special opcode file. But by adding this "-op ..." in wp34c.ini it's not a problem anymore.

A different thing is the complex Qt-version (should Pascal really create such a build): it doesn't use an INI file, so this assembler option has to be integrated in the sourcecode directly (and of course also changing the other files from 's' to 'c' as you did it in your own compile).

Franz

[Nigel (UK)]

(01-10-2016 10:12 PM)Marcus von Cube Wrote:  

(01-10-2016 09:25 PM)Nigel (UK) Wrote:  ...I've downloaded the latest code base and have begun by trying to compile the new emulator using Visual C++ Express 10 (which I've always used before).

This doesn't work.

The Express version of Visual Studio does not support MFC programming. You cannot compile the emulator.dll. (This is why I put all the GUI stuff into the DLL to make it possible to compile the rest of the emulator with Visual C++ Express.) You will have to load the wp34c_express.sln file into VC Express. The emulator DLL is part of SVN, in particular the debug version and symbols.

Sorry Marcus; I still can't compile the emulator. I've done a fresh download of the latest code; I've gone to trunk/windows in the main branch and opened wp34s_express.sln in Visual C++ Express 2010; I've tried selecting both Release and Debug as code targets; and whenever I try to compile I get the error message

Code:

..\emulator\wp34s.rc(10): fatal error RC1015: cannot open include file 'afxres.h'

I can comment out the line in wp34s.rc that is including this file (in the earlier versions I have on my system it is commented out already) but this introduces new errors. The compiler seems to be trying to build the dll itself rather than using the dll already present.

I can still build the emulator in code that I have from May last year, so the recent update of my system to Windows 10 probably isn't responsible! I suspect that the new version of wp34s.rc is to blame but my attempts to edit it have simply produced different compile-time errors. I'm afraid I don't have the expertise to solve this problem myself - can you or anyone else help?

Nigel (UK)

[Marcus von Cube]

(01-22-2016 09:58 PM)Nigel (UK) Wrote:  Sorry Marcus; I still can't compile the emulator.
...

Code:

..\emulator\wp34s.rc(10): fatal error RC1015: cannot open include file 'afxres.h'

I'll have a look. The RC file (resource file with menus, etc.) is the problem.

[Marcus von Cube]

(01-22-2016 10:26 PM)Marcus von Cube Wrote:  I'll have a look. The RC file (resource file with menus, etc.) is the problem.

I've made an attempt at fixing it for both trunk and complex_mode. Can you try again, please?

[pascal_meheut]

(01-11-2016 04:10 PM)fhub Wrote:  I've tried it now and indeed it works - for the Qt-emulator this won't be possible, because there you can only enter the directory of the assembler (not the EXE itself, so you can't add options).

I'll start working on the Qt complex_mode emulator. Renaming the state, backup & library files is easy.
When it comes to the assembler, I can hardcode the "-op" but as I'm not familiar with it, I want to be sure this of the command line syntax the emulator must execute.

[fhub]

(01-23-2016 09:32 AM)pascal_meheut Wrote:  I'll start working on the Qt complex_mode emulator. Renaming the state, backup & library files is easy.
When it comes to the assembler, I can hardcode the "-op" but as I'm not familiar with it, I want to be sure this of the command line syntax the emulator must execute.

Well, without '-op ...' option the assembler uses the file 'wp34s.op' in the same folder where the assembler is located by default. To use any other op-file you have to use this option '-op' (with the full pathname of this op-file).
So if your're calling the assembler currently with "PATH\wp34s_asm.exe PARAMS" (where PATH is the folder set in your custom tools option and PARAMS are the remaining parameters), you just have to add this '-op' option anywhere, e.g.:
"PATH\wp34s_asm.exe -op PATH\wp34c.op PARAMS"

An other possible method would be, that the user doesn't only specify the PATH of the tools folder, but even the complete call to the assembler EXE - this is the ways the normal (non-Qt) emulator works.
This means that the user has to enter the complete commandline in your tools option dialog (e.g. "..\myfolder\wp34s_asm.exe -op ..\myfolder\wp34c.op"), and the emulator just adds the rest (e.g. some other options (like -pp) and the filename to compile) - this has the advantage that the user could even add any additional wanted assembler options.
(in fact for the normal emulator it's even more flexible, because in the INI file you can even use a batchfile for calling the assembler (with any wanted options), which allows to execute other commands before or after calling the assembler, e.g. deleting temporary files).

PS: This is how I do it for the normal complex emulator:

Code:


content of my wp34c.ini:
------------------------
COM1:           # Com port
wp34c_asm.bat   # Assembler

content of my wp34c_asm.bat:
------------------------------
@echo off
..\tools\wp34s_asm.exe -op ..\tools\wp34c.op %1 %2 %3 %4 %5 %6 %7 %8 %9
rd /S /Q %TEMP%\p2xtmp-0000 >nul

Franz

[Nigel (UK)]

(01-23-2016 12:16 AM)Marcus von Cube Wrote:  

(01-22-2016 10:26 PM)Marcus von Cube Wrote:  I'll have a look. The RC file (resource file with menus, etc.) is the problem.

I've made an attempt at fixing it for both trunk and complex_mode. Can you try again, please?

All fine now - no compilation errors, and both the standard and the complex mode emulators run perfectly. Thank you!

Nigel (UK)

[pascal_meheut]

(01-23-2016 10:18 AM)fhub Wrote:  Well, without '-op ...' option the assembler uses the file 'wp34s.op' in the same folder where the assembler is located by default. To use any other op-file you have to use this option '-op' (with the full pathname of this op-file).

Ok. There is already an option to choose the "tools" directory. Isn't it enough?

If not, I'll look into a quick solution (i.e. an op file location option and/or an assembler command option) as I cannot spend too much time on the emulators at the moment.

[fhub]

(01-23-2016 02:55 PM)pascal_meheut Wrote:  Ok. There is already an option to choose the "tools" directory. Isn't it enough?

If not, I'll look into a quick solution (i.e. an op file location option and/or an assembler command option) as I cannot spend too much time on the emulators at the moment.

Yes, in principle this "tools" directory is of course enough, you just need to add '-op TOOLS\wp34c.op' to your assembler call (where TOOLS is the directory the user has entered).

My other 2 possibilities (entering the complete command or a batchfile) would just allow more flexibility for the user, but it's not really necessary.

Franz

[fhub]

(01-23-2016 12:16 AM)Marcus von Cube Wrote:  I've made an attempt at fixing it for both trunk and complex_mode.

Marcus, two questions:

1) is there any difference in emulator.dll between the normal and the complex versions?
I'm asking because sometimes (e.g. today) the emulator.dll is updated/rebuilt for only one of both branches.

2) sometimes (e.g. today) there's one additional command DBG in the opcode file - what's the purpose of this command?

Franz

[Marcus von Cube]

(01-23-2016 03:06 PM)fhub Wrote:  

(01-23-2016 02:55 PM)pascal_meheut Wrote:  Ok. There is already an option to choose the "tools" directory. Isn't it enough?
...

Yes, in principle this "tools" directory is of course enough, you just need to add '-op TOOLS\wp34c.op' to your assembler call (where TOOLS is the directory the user has entered).

My other 2 possibilities (entering the complete command or a batchfile) would just allow more flexibility for the user, but it's not really necessary.

I'd say it's almost necessary. If Perl is installed on Windows this would allow running the .pl versions instead of the .exe packages which take considerably longer to start and run.

[Marcus von Cube]

(01-23-2016 03:11 PM)fhub Wrote:  

(01-23-2016 12:16 AM)Marcus von Cube Wrote:  I've made an attempt at fixing it for both trunk and complex_mode.

Marcus, two questions:

1) is there any difference in emulator.dll between the normal and the complex versions?
I'm asking because sometimes (e.g. today) the emulator.dll is updated/rebuilt for only one of both branches.

2) sometimes (e.g. today) there's one additional command DBG in the opcode file - what's the purpose of this command?

Franz

ad 1) The resource file and possibly the menu ids differ. I'd suggest to keep both installations apart. Whether a recompiled DLL finds its way to the repository depends on the fact if I did a complete rebuild from the IDE or just the incremental build from the build scripts. Changes to the GUI may or may not trigger such a recompile.

ad 2) DBG goes to the op code file whenever I compile the debug version after the release version. The command isn't useful for the user, only for me as a developer. It only exists in the Debug builds.

[fhub]

(01-23-2016 03:18 PM)Marcus von Cube Wrote:  If Perl is installed on Windows this would allow running the .pl versions instead of the .exe packages which take considerably longer to start and run.

Well, that's not true for my asm/lib/pp versions - they are much smaller than the official ones and use only a few temporary file with a few 100 kB.
Edit: But of course you're right that allowing the user to enter the wanted assembler program (incl. options) himself would be more flexible than being able to only specify the folder to wp34s_asm.exe.

Marcus von Cube Wrote:The resource file and possibly the menu ids differ. I'd suggest to keep both installations apart.

That's a quite uncomfortable solution, we already have a 'normal' and a 'Qt' version, so I won't like to have also different folders for 'complex' (which would make 4 different installations).

So far I've not seen any problems in using the same emulator.dll, although sometimes it's from the normal and sometimes from the complex branch.

Franz

[Marcus von Cube]

(01-23-2016 03:36 PM)fhub Wrote:  

Marcus von Cube Wrote:The resource file and possibly the menu ids differ. I'd suggest to keep both installations apart.

...
So far I've not seen any problems in using the same emulator.dll, although sometimes it's from the normal and sometimes from the complex branch.

I agree that the DLLs for trunk and the complex branch should be (and in fact are) compatible. But the DLL for WP 31S definitely isn't.

[pascal_meheut]

The complex mode Qt emulator is available on SourceForge, named wp-34sc. So it uses different memory files and wp34c.op.
As I have no experience with the complex mode, I rely on users to test it.

[fhub]

(01-26-2016 06:22 PM)pascal_meheut Wrote:  The complex mode Qt emulator is available on SourceForge, named wp-34sc. So it uses different memory files and wp34c.op.
As I have no experience with the complex mode, I rely on users to test it.

Well, in principle the complex version is working, but it does not use the complex wp34c.op when importing programs (I'm talking about the Windows version).

In the Sourceforge SVN I see that you've made a few changes (regarding the assembler call), but I can't enter the assembler EXE or any options like -op ..., it still allows me to choose the tools directory, and so wp34s_asm.exe is using wp34s.op by default.
As it is now importing programs may lead to non-working code.

Why don't you make this assembler call the same way as Marcus did it in the normal emulator?
It's quite easy and should also work for the Qt version - in principle it works like this:
cmd.exe /c assembler fixed_options
(instead of cmd.exe /c you could also use %COMSPEC% /c)

assembler is the full path to the assember (.exe or .pl) incl. any user options (like -op wp34c.op), and all this has to be entered by the user in the preferences dialog (instead of only the directory)

fixed_options are the internal assembler options which the emulator needs for correctly working (-pp "%s" -o %s 1>%s 2>&1)

2 other minor problems:
- wp34s-lib.dat in the folder memory should be wp34c-lib.dat
- the font DejaVuSans.ttf in the complex emulator is an older version than for the normal emulator (IIRC there were some display problems with this version)

Franz

[pascal_meheut]

(01-26-2016 08:19 PM)fhub Wrote:  It's quite easy and should also work for the Qt version

Thinks are always easier when you do not have to do them yourself and when you take what is offered to you for granted.
A "thank you" would have been common courtesy, especially as I explained before I have very little time to work on this project.

I see no point in continuing working on this.