HP Forums

Hi,

Excuse if this is a stupid question but I see that the Perl version of the assembler is at revision 2093 and the exe version is at just 1698, instead (updated two months ago). Could I still use wp34s_asm.exe to assemble for version 3.0?

Thanks,

Miguel

Hi Miguel,

Sorry, but the EXE is VERY out of date at the moment. And it is not a silly question at all.

There are some significant changes happening to the calculator binary images that would mean that 1698 will not build correct translations for the RAM/state file. I am trying to get those format changes resolved this week.

1698 might have a chance of building a flash image for V3, though the size limits will be quite constrained (V3 has a single consolidated flash image now instead of many smaller 'pages').

There are many new checks that 1698 will not undertake. For example, it will not force the image to have an END statement if you have forgotten to include one -- something the latest calculator needs.

I will try and get an EXE built soon.

(Here is my flimsy excuse:) I have to do the EXE compilation on a special, stripped down Windows machine (I develop the Perl on Ubuntu) which I have to get out and setup every time (including plugging in a special hard disk!). I have to admit to a certain laziness at doing this (and I have to find room on the dining room table).

However, the Perl is always up to date. Is there a chance of you installing one of the many Perl packages available -- at least for the short term? The documentation mentions and gives coordinates for several distributions.

(I had not been aware of anybody actually using the EXE versions... I never hear feedback about them. :-)

Best regards...

Hi Neil,

I always used the exe versions that always did a good job, so I am one of its fans! if not the only one perhaps :-) So please, do not forget us, poor and lazy people not wanting to deal with Perl.

Thank you for your excellent work and regards,

Miguel

Quote:

---

I will try and get an EXE built soon.

---

I've now found IndigoPerl 9.02 (Perl 5.10+) and installed this here because it's a lot smaller than ActivePerl or Strawberry.

And after many tests I've found that there's definitely a problem with your scripts when it comes to calling another script - at least under Windows!

Your pp is working perfectly, your asm is working perfectly as long as I don't use the -pp switch, but both the lib script (which always calls asm) and the asm script with -pp don't work at all: they just don't find the called script (there's an OS error message like "Command or file not found" and then a few more errors from the scripts, because they don't get any output file from the called script).

Since there's also a perl2exe on the IndigoPerl website (which BTW create EXEs of your scripts with only about 900kB!), I've tried it with both methods: running your scripts directly with Indigo's perl.exe and also as compiled EXEs (with perl2exe), but there's no difference: as long as the script doesn't call another script everything is ok, but calling another script fails (and I've set the path to perl.exe correctly and even made a file association from .pl to this perl.exe!).

So there must be some problems in your code for calling another script - maybe your method of calling another perl script doesn't work under Windows!?

Franz

Edited: 31 Dec 2011, 12:17 p.m.

Thanks for the feedback. I will look at it soon.

Off slaying other alligators...

OK, Franz. I have had a look at my tool-set creating the EXE.

The brand new LIB tool definitely has issues (but it is not officially released yet).

The EXEs I build using the compiler I have here (and I can't recall where I got it but it is documented in this forum) generates both ASM and PP that work fine. I can run ASM with the '-pp' switch and it does everything it is supposed to.

I suspect that there is a difference in the extraction of the script name, directory, and suffix in line 341 of ASM WRT to your compiler and mine. This is likely resulting in an invalid build up of the command I want to run.

Try this experiment and let me know the results:

1) Set the following environment variable to 1 in order to print some debug details.

$ set WP34s_ASM_PRESERVE_PP_DBG=1

2) Give me the command line you ran and any and all error logs generated using.

I downloaded Indigo but have not installed it. It sounds promising that its footprint is much smaller.

When I have some time to install it, I will give you more info.

Unfortunately, the Indigo Perl2EXE has exactly the same issue as the other attractive one I identified (thread). The license does not allow output from unregistered copies of the tool to distributed.

I am not really interested in spending money for a tool that is of little use to me.

Quote:

---

I suspect that there is a difference in the extraction of the script name, directory, and suffix in line 341 of ASM WRT to your compiler and mine. This is likely resulting in an invalid build up of the command I want to run.

---

Here's the complete output after setting this debug option.

First for running the script:

C:\WP34S\tools>perl wp34s_asm.pl primesieve_pp.wp34s -pp -o Test.dat

// WP 34S assembly preprocessor enabled: '-pp'

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// Running WP 34S preprocessor from: wp34s_pp.pl

// Running: 'wp34s_pp.pl  -m 90 -cat  .__0.037200927734375.tmp -v3 -sd 4'

Befehl oder Dateiname nicht gefunden.

Use of uninitialized value $lines[-1] in pattern match (m//) at wp34s_asm.pl line 1421.

// WARNING: wp34s_asm.pl: V3 mode: Missing terminal "END" in file 'wp34s_pp.lst'. Appending after last statement in source...

// WP 34s version: 30

// CRC16: FE44

// Running in V3 State-mode. Max words: 922

// Total words: 1

// Total steps: 1

C:\WP34S\tools>wp34s_asm primesieve_pp.wp34s -pp -o Test.dat

// WP 34S assembly preprocessor enabled: '-pp'

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// Running WP 34S preprocessor from: wp34s_pp.pl

// Running: 'wp34s_pp.pl  -m 90 -cat  .__0.554046630859375.tmp -v3 -sd 4'

Befehl oder Dateiname nicht gefunden.

Use of uninitialized value $lines[-1] in pattern match (m//) at C:\WP34S\TOOLS\WP34S_ASM.EXE line 1421.

// WARNING: WP34S_ASM.EXE: V3 mode: Missing terminal "END" in file 'wp34s_pp.lst'. Appending after last statement in source...

// WP 34s version: 30

// CRC16: FE44

// Running in V3 State-mode. Max words: 922

// Total words: 1

// Total steps: 1

I just had another idea:

Looking into your asm script I don't see anywhere that you explicitely call/run/start perl.exe !?

I don't know which OS you're using (Linux/Unix?), and maybe on your OS it works if you just use "wp34s_pp.pl" on the commandline, but this doesn't work under Windows, not even if you have associated perl.exe with the fileextension .pl

In Windows you have to enter "perl wp34s_pp.pl" (or at least "start wp34s_pp.pl") for running this script, the scriptname alone is not enough! Maybe this is the reason for the failure (and the error message "Command or filename not found")?

Franz, have you set the PATH to point to the directory containing the .pl scripts?

Quote:

---

Franz, have you set the PATH to point to the directory containing the .pl scripts?

---

It depends on how perl looks for a script. If it takes the present working directory into account, ok; if not, no luck. The original Unix behavior is not to have "." in the search path.

I think what is happening is that, for some reason, your executable is coming back with capital ".EXE" and not lower case ".exe". Why this would be different from my setup, I don't know -- unless its because I don't use the bare program name but tend to type "wp34s_asm.exe" instead of "wp34s_asm".

Unfortunately, my script is case specific and it is looking for lower case ".exe". The capitals are befuddling it. This is easily fixed by changing line 348 of the ASM from:

  if( $script_name =~ /\.exe$/ ) {

to:

  if( $script_name =~ /\.exe$/i ) {

and line 351 from:

    $preproc =~ s/\.pl$/\.exe/;

to:

    $preproc =~ s/\.pl$/\.exe/i;

This makes the search and replacement case insensitive. If you can try this at your end and let me know the result, I will make the official change in my source.

(This is deduced because the second invocation is still trying to run the Perl version of PP and not an EXE version. Therefore the search. and thus the replace as well, failed.)

The other thing this log is telling me is that you don't have the MS-DOS file associations setup correctly. (See the Assembler documentation, section 7.2.2, footnote 28.) This is why you are still required to use "perl" in front of your Perl commands. Fixing the file associations will solve this. As noted in the documentation, some packages set these up for you (all should!!) and some don't.

Question: If you have Indigo up and running, why not just use it with the native Perl scripts rather than go to the trouble of the EXE? If you get the file associations setup correctly, it should "just work".

Marcus,

MS-DOS is different from a Unix/Linux system. Close, but different. MS-DOS searches the current directory first, and only if this fails to find the program being sought does it resort to the PATH statement. Its exactly the same as if the path was setup with "./:${PATH}". Hence, that is probably not the problem.

It is more likely the file associations: ftype, assoc, and PATHEXT still need to be setup for Franz's Perl installation. This, along with the small change to the Perl script should solve the problem.

Franz,

Another thing you should try -- before you modify the Perl script -- is to run the program using the fully named executable:

$ wp34s_asm.exe -pp ...

This is likely the difference between your invocation and mine.

Ok Neil, I've now tried your suggestion with adding this "i" to make it case-insensitive, compiled new EXEs of your scripts and 'in principle' it works now. 'In principle' because calling the pp.exe from the asm.exe works, but now I have another problem: this crappy 'free' Indigo perl2exe displays a text like "This exe file was created with ..." after each run of such a compiled EXE, and this text is now appended to the preprocessor file wp34s_pp.lst, and so of course the assembler gives an error message because this text is just 'nonsense' at the end of this file!

So I'm again in the same situation - your scripts compiled with this Indigo perl2exe don't work.

BTW, since your libmanager contains the same code (checking for .exe) I've made the same changes with this "i" here, but for the lib.exe it didn't work - it still doesn't call the asm.exe (I've no clue why, it should work the same as for asm with -pp).

And this libmanager was indeed my main goal, because I always can run the preprocessor separately before using the assembler, but the libmanager works only with calling the asm.

And why don't I run the scripts directly? Well, because it doesn't work!

I've already said that I have set the file association (.pl to perl.exe), because if I enter "start xxx.pl" or if I choose xxx.pl in TotalCommander then perl.exe is called automatically - so the file association is ok. But of course just entering "xxx" or "xxx.pl" on the commandline does NOT work, because Windows/MSDOS doesn't recognize this as any executable command (like xxx.bat for example) - and I don't know HOW I should tell Windows to accept "xxx.pl" as such a 'command' (using perl.exe to execute it).

Well, I've now really enough of all those troubles and I'll probably stop trying to get these Perl scripts working correctly - I've already wasted MANY hours trying all possible tricks to get them running. I've already told you long time ago that it would certainly be much more comfortable to have all your scripts in one single tool (e.g. wp34s_tool.pl) and adding -asm, -lib or -pp to choose what you need to do - this would avoid all those damned problems under Windows with calling one script by another one (there would just be 3 subroutines WITHIN one script). But you decided NOT to make it that simple, and so we have now these problems under Windows - and I'm finally giving up now. :-(

Franz

Edited: 1 Jan 2012, 3:25 p.m.

Sounds like you don't have your PATHEXT variable set correctly if DOS is not recognizing the Perl scripts as executables. Did you look up and follow all three steps in the footnote?

Puttting everything in a single tool is actually a goal but it is not quite so simple as you think. Partly because, as with many designs, it has been extended WAY beyond what its original intentions were. It has begun but don't hold your breath -- it will be a while.

As I said, LIB has not been officially released for public use yet. It still has many issues -- none of which are things you have identified. I haven't completed the code for it to work with DOS so Ii am not surprised it has issues there.

Quote:

---

Sounds like you don't have your PATHEXT variable set correctly if DOS is not recognizing the Perl scripts as executables. Did you look up and follow all three steps in the footnote?

---

Isn't there a simple way that I could just add "perl" or "perl.exe" in your scripts where those other scripts are called?

Quote:

---

Well, I've just looked at those instructions but that's nothing I can do here. Although I have of course also newer computers (with Windows XP, Vista and 7), but most of the time I'm working on my very old notebook here (which is the only one connected to the internet), and on this notebook the only OS is Windows 98! And I'm sure you can imagine that these things just don't work in Win98. ;-)

---

Well, you beat me! There seems to be nothing I can do to get antiquated Windows 98 running with this Perl stuff. I guess you are firmly in the EXE-land. Hopefully, we can make the EXEs work on that O/S. (Incidentally, it is because of Windows 98 -- or more particularly, CMD.EXE from MS-DOS -- that the name of the executable came back as ".EXE" instead of the ".exe" that I was expecting.)

Quote:

---

Isn't there a simple way that I could just add "perl" or "perl.exe" in your scripts where those other scripts are called?

---

I thought I supplied a method to do this but it does not work in this case. I supplied a mechanism to change the name of the script which was called. However, it doesn't allow you to put a "perl.exe " in front of it because the name is also used as a search parameter so I know where to get the script to launch. No good deed goes unpunished!

I am in the process of trying to get LIB working with the EXE. I could have it tonight -- or it may take longer....

The other 2 EXE's have been update but not committed. I will commit all 3 as a set.

Note that there are still issues with LIB and it is still not officially released for public use yet. There is no documentation and has been little testing. Expect you fingers to hurt from the sharp edges!

Hi Miguel,

Happy New Year!

I have put the latest versions of both tools (ASM and PP) up on the SVN server.

Since I have been discussing this with Franz I might as well give some wider comment: There is also a newer tool called LIB (wp34s_lib.exe) designed for the V3 calculator (only!). This one is still pretty rough but its intention is to allow the user to add new programs to a library, remove existing programs, or replace programs of the same name. It works with both the flash (wp34s-lib.dat) and the brand new state-file (wp34s.dat) formats.

I am afraid there is no documentation as yet other than the standard '-h' switch. The program will likely attempt to pull a few surprises before we polish it up. Be patient with it.

Depending on what you have asked LIB to do, it may execute each of the other 2 programs several (many!?) times in sequence. Therefore, for the EXE version, the first time it runs it could take a while (because the previously documented decompression latency). Thereafter it should speed up.

Hi Neil,

Happy new year for you too!

Thanks for this update and I will also test the new tool. I will report to you on those "surprises" if any.

Thanks again and regards,

Miguel

Edited: 1 Jan 2012, 6:54 p.m.

Quote:

---

There is also a newer tool called LIB (wp34s_lib.exe) designed for the V3 calculator (only!).

---

I've made a few short tests with the new wp34s_lib.exe but no matter which function (i.e. options) I use, I always get an error message from the assembler about a missing "dat file '2'".

Here's one example where I just wanted to diplay a catalog:

C:\x>wp34s_lib -ilib wp34s-lib.dat -cat

ERROR: Cannot open dat file '2' for reading: No such file or directory

Initial library catalogue (format: flash file)

ERROR: WP34S_LIB.EXE::print_prog_name: First line of propram was not a correctly  formatted LBL: ''

BTW, I could manage to 'crack' the Indigo perl2exe, so now it doesn't display this 'evaluation' message anymore, and I could successfully compile all your 3 scripts to EXEs - and they work exactly the same way as your versions, but are only about 900 kB and also start much faster.

(of course the lib.exe does also not work - same error as above with your version).

Franz

Franz,

Turn on more debugging by adding "-d 2" to the command line of LIB. Capture the output and send both the output and the input "wp34s-lib.dat" file to me via email. I will have a look.

(I thought I had posted this same message last night but I must have screwed something up.)

Ok Neil,

I've now done the 2 steps again from the scratch (assembling 3 source files to a dat file and then trying to list them again with the libmanager with -cat, here's the console output:

C:\TEMP>wp34s_asm PF.wp34s TVM.wp34s TRIGON.wp34s -o wp34s-lib.dat

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// WP 34s version: 30

// CRC16: 6839

// Running in V3 State-mode. Max words: 922

// Total words: 596

// Total steps: 575

C:\TEMP>wp34s_lib -ilib wp34s-lib.dat -cat -d 2

// DEBUG: WP34S_LIB.EXE::disassemble_binary: Processing library binary for 'wp34s-lib.dat'

// DEBUG: WP34S_LIB.EXE::run_prog: Spawning command line: 'wp34s_asm.exe -dis wp34s-lib.dat -s 2 -ns'

ERROR: Cannot open dat file '2' for reading: No such file or directory

// DEBUG: WP34S_LIB.EXE::run_prog: Output of spawned program:

Initial library catalogue (format: flash file)

Use of uninitialized value $prog_line in pattern match (m//) at C:\TEMP\WP34S_LIB.EXE line 1036.

Use of uninitialized value $prog_line in pattern match (m//) at C:\TEMP\WP34S_LIB.EXE line 1036.

Use of uninitialized value $prog_line in concatenation (.) or string at C:\TEMP\WP34S_LIB.EXE line 1046.

ERROR: WP34S_LIB.EXE::print_prog_name: First line of propram was not a correctly formatted LBL: ''

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// WP34S_ASM.EXE: Source file(s): wp34s-lib.dat, 2

I guess there's some problem in the communication between the lib and the asm tool, probably this file "&1" shouldn't have been created at all but there should be some temporary output of the disassembler which is then the input for the libmanager!?

Quote:

---

// DEBUG: WP34S_LIB.EXE::run_prog: Spawning command line: 'wp34s_asm.exe -dis wp34s-lib.dat -s 2 -ns'
ERROR: Cannot open dat file '2' for reading: No such file or directory

---

The problem is MS-DOS COMMAND.EXE. This command shell does not handle the redirection of both STDOUT and STDERR as I was expecting. The mysteriousness is all coming from LIB line 784. The '2>&1' thingy is designed to capture both STDOUT and STDERR to STDOUT. However, COMMAND.EXE is not recognizing this and is instead interpreting this as "2 > &1" which would translate to a file called "2" and redirection of the STDOUT to a file called "&1".

All subsequent errors and nonsense stem from this single line not behaving as expected.

I will have to see if there is a cure for this. If not, all sub-par shells, such as COMMAND.EXE from MS-DOS might be "out of the running" -- at least until I get a unified program together.

(I do have one other trick up my sleeve but will have no way to test it since I don't have any MS-DOS based computers at hand. It is a long shot.)

Quote:

---

The '2>&1' thingy is designed to capture both STDOUT and STDERR to STDOUT.

---

Quote:

---

I will have to see if there is a cure for this.

---

I was already long ago wondering why your asm expects a "-o outfile" but your pp requires an indirection "> file" to get a file instead of a console output.

With "-i" and "-o" you could certainly avoid all those problems with redirecting files ...

Edited: 2 Jan 2012, 11:01 a.m.

I've now tried it again after removing this 2>&1 in the line 784 (i.e. now it's just `$cmd`), and now the libmanager seems to work - no more error messages.

This is what I get when I run it:

C:\Temp>wp34s_lib -ilib wp34s-lib.dat -cat

Initial library catalogue (format: flash file)

  Source: wp34s-lib.dat, Program name: PF, Line number: 1

  Source: wp34s-lib.dat, Program name: TVM, Line number: 31

  Source: wp34s-lib.dat, Program name: TRI, Line number: 293

Library details:

// WP 34S assembly preprocessor enabled: '-pp'

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// Running WP 34S preprocessor from: wp34s_pp.exe

// WP 34s version: 30

// CRC16: EA42

// Running in V3 Lib-mode. Max words: 4094

// Total words: 596

// Total steps: 575

Edit: I've now also tried the other 2 main functions of the libmanager (adding and removing a file to/from the library) and both functions seem to work fine. :-)

There's only one thing that confuses me a bit: if I create a library from a few files which are together larger than about 520 steps, then the displayed CRC of the asm is different from the CRC which lib -cat shows!?

(and there's difference in the asm CRC between creating the lib.dat file with or without the option -lib)

Here's an example:

C:\TEMP>wp34s_asm TVM.wp34s TRIGON.wp34s -o Test.dat -lib

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// WP 34s version: 30

// CRC16: C1BB

// Running in V3 Lib-mode. Max words: 4094

// Total words: 565

// Total steps: 545

C:\TEMP>wp34s_lib -ilib Test.dat -no_pp -cat

Initial library catalogue (format: flash file)

  Source: Test.dat, Program name: TVM, Line number: 1

  Source: Test.dat, Program name: TRI, Line number: 263

Library details:

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// WP 34s version: 30

// CRC16: 43C0

// Running in V3 Lib-mode. Max words: 4094

// Total words: 565

// Total steps: 545

Edited: 2 Jan 2012, 12:28 p.m.

Quote:

---

Why do you use these redirections (with ">") at all?
Why not simply (and consistently) use "-i infile" and "-o outfile" whenever you need a temporary file for the communication between your modules?

I was already long ago wondering why your asm expects a "-o outfile" but your pp requires an indirection "> file" to get a file instead of a console output.
With "-i" and "-o" you could certainly avoid all those problems with redirecting files ...

---

Sigh! It must be nice to be so smart.

You do realize that much of the development in the last few days has been to solely support you and your antiquated system. No one else is having the issues you are having and it is all related to your choice of obsolete platform. Some amount of gratitude might be in order.

The changes you have made are fine as long as no errors occur anywhere in the tool chain. The reason that specific style of redirection was used was to ensure that messages sent to STDERR were also captured. Sure I could have used intermediate files for errors but every other command shell deals with these things correctly. I use the facilities that are available to me.

Hi Neil,

I tested both wp34s_asm and wp34s_lib (great tool!) and so far so good. The programs work flawlessly so far. I first created a wp34s-lib.dat and then added some other routines, using -cat to see the results and not a single problem found. It is nice not to have to install Perl in my machine :-)

Thank you very much for a great job and regards,

Miguel

Edited: 2 Jan 2012, 5:23 p.m.

Thanks, Miguel. Its nice to know something is working. :-)

I have revamped the error handling mechanism in order to better support obsolete platforms. I can only test it on the COMMAND.EXE that comes with Windows XP. Works fine with that shell. We'll see what happens... So new Perl and EXE are available.

Quote:

---

I have revamped the error handling mechanism in order to better support obsolete platforms. I can only test it on the COMMAND.EXE that comes with Windows XP. Works fine with that shell. We'll see what happens... So new Perl and EXE are available.

---

Your new scripts are now also working perfectly in Win98 - at least as EXE versions (I've made again my own EXEs with perl2exe, because they are much smaller and faster).

Regards from an obsolete user on an obsolete OS, ;-)

Franz

Glad to hear that. Now I can get back to doing what I should have been doing to support the latest design wave. :-) The Australian and German wolves are howling at my door...

Only the 1st invocation of the current EXEs are vveeerrry ssslllooowww. Since LIB runs both ASM and PP, it will be even ssssssslllllllooooowwwwwwer the 1st time around. Subsequent runs come from cached copies of the decompressed image(s) so they are much faster.

It is still possible that these images can be made smaller with the tool I am using but I don't intend to look more deeply into it. :-) "It works for me!"

I suspect you will have to "refresh" yours every few weeks because the Indigo demo version of the tool probably has a time limit built into it the output EXE. Technically, you will be in violation of the terms of the Indigo Perl2Exe license if you use it beyond 30 days unless you register your copy (and pay the license fee).

Quote:

---

It is still possible that these images can be made smaller with the tool I am using but I don't intend to look more deeply into it. :-) "It works for me!"

---

Quote:

---

I suspect you will have to "refresh" yours every few weeks because the Indigo demo version of the tool probably has a time limit built into it the output EXE.

---

Quote:

---

Technically, you will be in violation of the terms of the Indigo Perl2Exe license if you use it beyond 30 days unless you register your copy (and pay the license fee).

---

But for working on my private computer in my own home I don't care about such things like copyrights or licenses at all - what I'm doing behind closed doors is solely my business. ;-)

Franz

Quote:

---

But for working on my private computer in my own home I don't care about such things like copyrights or licenses at all - what I'm doing behind closed doors is solely my business. ;-)

---

That is fine, but that is also why I cannot build and distribute anything built using that tool -- unless I purchase a license -- something I don't see a need to spend my money on right now.

I'd rather spend money acquiring a 19BII than Indigo Perl2Exe. :-)

Quote:

---

I'd rather spend money acquiring a 19BII than Indigo Perl2Exe. :-)

---

BTW, since your tool for creating Perl EXEs is free, can it be downloaded anywhere?

Maybe I could have a look at it, but of course only if it's running under Windows ...

Yes it is free and the output is freely distributable. Where I got it, I cannot recall but it was probably CPAN (Comprehensive Perl Archive Network). I will look at my notes and see if I was careful enough to have recorded it.

I run it under Windows XP since I am creating a Windows EXE. I believe it can cross compile from Linux but I have never tried -- one step too many for me...

Hi Neil,

I've already posted this 2 days ago but maybe you've overlooked it in this long thread:

There's a difference in the displayed CRCs of wp34s_asm and wp34s_lib if all files together are bigger than the RAM limit (about 520 steps).

Here's a sample output:

C:\TEMP>wp34s_asm PF.wp34s TVM.wp34s TRIGON.wp34s -o Test.dat

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// WP 34s version: 30

// CRC16: E0E8

// Running in V3 State-mode. Max words: 922

// Total words: 596

// Total steps: 575

C:\TEMP>wp34s_lib -ilib Test.dat -cat

Initial library catalogue (format: flash file)

  Source: Test.dat, Program name: PF, Line number: 1

  Source: Test.dat, Program name: TVM, Line number: 31

  Source: Test.dat, Program name: TRI, Line number: 293

Library details:

// WP 34S assembly preprocessor enabled: '-pp'

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// Running WP 34S preprocessor from: wp34s_pp.exe

// WP 34s version: 30

// CRC16: 78C8

// Running in V3 Lib-mode. Max words: 4094

// Total words: 596

// Total steps: 575

If I create the dat file directly with wp34s_lib, then this shows also CRC16: 78C8 at the end (i.e. different to the asm output).

Is this ok or is there a bug anywhere? (Maybe these 2 CRCs (of asm and lib) have different meaning?)

For a single file or if the files together are smaller than the RAM limit, this does not happen - here both tools show the same CRC.

Franz

The ASM run is reporting that the output is in "state mode" while the LIB is reporting "flash mode". The CRC and format are definitely different for these 2 modes***.

The ASM should not be able to write a state-mode file by itself. At the very least, it would need an initial (valid) wp34s.dat from the emulator to modify. (And I was not aware that the ASM even had this ability -- that is part of LIB. A surprise to me!)

Looks like a bug in the ASM.

For now, when building for the V3 calculator, I would use the LIB tool when creating flash images. The ASM tool will likely become obsolete as a standalone tool for pure assembly in V3 calculator very shortly. It will still have standalone uses as a disassembler though. Disassembly does not care if it is a state file or a flash file. Its primary use in the V3 flow is as a utility for LIB.

ASM will (hopefully) still work as the main front end for the V2 flow, as before. LIB is not designed for the V2 flow.

(Aside: LIB asserts several undocumented command line parameters when launching ASM -- designed only for the V3 flow. The user should not normally be setting these switches.)

I will look at this tonight.

*** The state file is the file emitted by the emulator covering the RAM, registers, and (well) the state (wp34s.dat). The flash format is the format used for the flash region (wp34s-lib.dat). They have different structures and uses. For example, the location and coverage of the CRC is different in the two formats. I am not sure if this is documented yet.

Quote:

---

The ASM run is reporting that the output is in "state mode" while the LIB is reporting "flash mode". The CRC and format are definitely different for these 2 modes***.

---

C:\TEMP>wp34s_asm PF.wp34s TVM.wp34s TRIGON.wp34s -o Test.dat -lib

// Opcode map source: wp34s.op (local directory)

// Opcode SVN version: -- unknown --

// WP 34s version: 30

// CRC16: E0E8

// Running in V3 Lib-mode. Max words: 4094

// Total words: 596

// Total steps: 575