Threaded Mode | Linear Mode

Dieter · 09-12-2016, 07:18 PM

(09-12-2016 06:49 PM)leoduran Wrote: Please delete copies of hp41uc.exe you may have, and let's try this attachment in a new/clean 'test' directory:

I tried it in a new directory. I've also run hp41uc without parameters to make sure it's version 2.42. But the result is still the same. No RDTAX after decompiling.

Code:

F:\test>hp41uc

User-Code File Converter/Compiler/De-compiler/Barcode Generator - Version 2.42

Copyright (c) Leo Duran, 2000-2016. All rights reserved. leo.duran@yahoo.com.

Supported File Formats:

  LIF [ /l ]: transfer file for Trans41

  P41 [ /p ]: archive file for HP-41 programs on ftp sites

  RAW [ /r ]: input/output file for LIFUTIL

  DAT [ /d ]: input/output file for EMU41 (using INP, OUTP)

  BIN [ /b ]: output file from 41UCC

  TXT [ /t ]: program listing (text)

  PCL [ /h ]: barcode printable file (Hewlett Packard PCL)

  PS  [ /s ]: barcode printable file (Postcript)

  WND [ /w ]: barcode hex-dump (Wand file)

File Converter:

  [ LIF, P41, RAW, DAT, BIN ] => [ BIN, DAT, RAW, P41, LIF ]

Compiler:

  [ TXT ] => [ LIF, P41, RAW, DAT, BIN ]

De-compiler:

  [ LIF, P41, RAW, DAT, BIN ] => [ TXT ]

Barcode Generator:

  [ RAW ] => [ PCL, PS, WND ]

Use a single option[ /b, /d, /h, /l, /p, /r, /s, /t, or /w ] for help.

F:\test>hp41uc /t=test /r /n /k

txt[ F:\test\test.txt ] => raw[ F:\test\test.raw ]

.END. found on line 9.

 size[ 0019 ]  ( 25 bytes )

25 bytes written.

F:\test>hp41uc /r=test /t /n

Overwrite F:\test\test.txt (Yes/[No])?y

raw[ F:\test\test.raw ] => txt[ F:\test\test.txt ]

102 bytes written.

F:\test>type test.txt

 01 LBL "PRDTA"

 02 1.004

 03 XROM 30,03

 04 RCL 03

 05 RCL 04

 06 *

 07 PRX

 08 RTN

 09 END

F:\test>

Dieter

leoduran · 09-12-2016, 07:33 PM

(09-12-2016 07:18 PM)Dieter Wrote:
(09-12-2016 06:49 PM)leoduran Wrote: Please delete copies of hp41uc.exe you may have, and let's try this attachment in a new/clean 'test' directory:

I tried it in a new directory. I've also run hp41uc without parameters to make sure it's version 2.42. But the result is still the same. No RDTAX after decompiling.

Code:

F:\test>hp41uc User-Code File Converter/Compiler/De-compiler/Barcode Generator - Version 2.42 Copyright (c) Leo Duran, 2000-2016. All rights reserved. leo.duran@yahoo.com. Supported File Formats: LIF [ /l ]: transfer file for Trans41 P41 [ /p ]: archive file for HP-41 programs on ftp sites RAW [ /r ]: input/output file for LIFUTIL DAT [ /d ]: input/output file for EMU41 (using INP, OUTP) BIN [ /b ]: output file from 41UCC TXT [ /t ]: program listing (text) PCL [ /h ]: barcode printable file (Hewlett Packard PCL) PS [ /s ]: barcode printable file (Postcript) WND [ /w ]: barcode hex-dump (Wand file) File Converter: [ LIF, P41, RAW, DAT, BIN ] => [ BIN, DAT, RAW, P41, LIF ] Compiler: [ TXT ] => [ LIF, P41, RAW, DAT, BIN ] De-compiler: [ LIF, P41, RAW, DAT, BIN ] => [ TXT ] Barcode Generator: [ RAW ] => [ PCL, PS, WND ] Use a single option[ /b, /d, /h, /l, /p, /r, /s, /t, or /w ] for help. F:\test>hp41uc /t=test /r /n /k txt[ F:\test\test.txt ] => raw[ F:\test\test.raw ] .END. found on line 9. size[ 0019 ] ( 25 bytes ) 25 bytes written. F:\test>hp41uc /r=test /t /n Overwrite F:\test\test.txt (Yes/[No])?y raw[ F:\test\test.raw ] => txt[ F:\test\test.txt ] 102 bytes written. F:\test>type test.txt 01 LBL "PRDTA" 02 1.004 03 XROM 30,03 04 RCL 03 05 RCL 04 06 * 07 PRX 08 RTN 09 END F:\test>

Dieter

OK, somehow the decompiler thinks it should not decode that XROM... Since I can't duplicate it, I'll need your help to debug this... I'll add some output to give us a clue as to what the decoder is doing in this case(I'll attach an .EXE a little later today - I'll bump the rev# to 2.43 to make sure we're testing with the right one), OK?

Dieter · (This post was last modified: 09-12-2016 08:13 PM by Dieter.)

(09-12-2016 07:33 PM)leoduran Wrote: OK, somehow the decompiler thinks it should not decode that XROM... Since I can't duplicate it, I'll need your help to debug this... I'll add some output to give us a clue as to what the decoder is doing in this case

Fine. I appreciate your help to resolve this.

(09-12-2016 07:33 PM)leoduran Wrote: (I'll attach an .EXE a little later today - I'll bump the rev# to 2.43 to make sure we're testing with the right one), OK?

OK – whatever "today" means in your time zone. ;-)
I'm in Central Europe, which is UTC+2 (CET DST) i.e. 7 hours ahead of TX.

Edit: I noticed a detail that may give a hint here. We know that the printer functions are correctly handled with their function names. The non-programmable functions (e.g. LIST) are (correctly) not recognized and throw a compiler error (both with and without /x29). On the other hand even the non-programmable Card Reader functions VER and WPRV appear in the decompiled text file as XROM 30,05 and XROM 30,09. Does this give any clue?

Dieter

leoduran · (This post was last modified: 09-12-2016 11:04 PM by leoduran.)

(09-12-2016 07:48 PM)Dieter Wrote:
(09-12-2016 07:33 PM)leoduran Wrote: OK, somehow the decompiler thinks it should not decode that XROM... Since I can't duplicate it, I'll need your help to debug this... I'll add some output to give us a clue as to what the decoder is doing in this case

Fine. I appreciate your help to resolve this.

(09-12-2016 07:33 PM)leoduran Wrote: (I'll attach an .EXE a little later today - I'll bump the rev# to 2.43 to make sure we're testing with the right one), OK?

OK – whatever "today" means in your time zone. ;-)
I'm in Central Europe, which is UTC+2 (CET DST) i.e. 7 hours ahead of TX.

Edit: I noticed a detail that may give a hint here. We know that the printer functions are correctly handled with their function names. The non-programmable functions (e.g. LIST) are (correctly) not recognized and throw a compiler error (both with and without /x29). On the other hand even the non-programmable Card Reader functions VER and WPRV appear in the decompiled text file as XROM 30,05 and XROM 30,09. Does this give any clue?

Dieter

1) Wow... Now I'm really confused!
What do you mean by "non-programmable functions (e.g. LIST)...throw a compiler error"?

2) OK, attached is the .EXE (v2.43), I expect the output to include:
XROM: module=30 function=3 count=32 list=11 flag=1
Decoded XROM function: RDTAX
XROM: module=29 function=20 count=32 list=11 flag=1
Decoded XROM function: PRX
97 bytes written.

3) What version of Windows are you running? (32 or 64 bit?)

Dieter · (This post was last modified: 09-12-2016 10:17 PM by Dieter.)

(09-12-2016 09:42 PM)leoduran Wrote: 1) Wow... Now I'm really confused!
What do you mean by "non-programmable functions (e.g. LIST)...throw a compiler error"?

Have a text file with a non-programmable printer command like LIST (XROM 29,07) and this line will not compile. hp41uc /r will display an error message saying that the command in this line of the text file is not recognized and the user should try XROM xx,yy instead:

Error: unrecognized or incomplete function[ LIST ]
If [ LIST ] is an external module function, try: [ XROM mm,ff ]
Compiler error on line 8.
0 bytes written.

This is fine since LIST cannot be used in a program. It is not programmable and can only be used in Run mode.

On the other hand non-programmable card reader commands like VER run through the compiler without any error. De-compiling this back to a text file shows XROM 30,05.

(09-12-2016 09:42 PM)leoduran Wrote: 2) OK, attached is the .EXE (v2.43), I expect the output to include:
XROM: module=30 function=3 count=32 list=11 flag=1
Decoded XROM function: RDTAX
XROM: module=29 function=20 count=32 list=11 flag=1
Decoded XROM function: PRX
97 bytes written.

The output is:
...
XROM: module=30 function=3 count=32 list=11 flag=0
Decoded XROM function: RDTAX
XROM: module=29 function=20 count=32 list=11 flag=1
Decoded XROM function: PRX
102 bytes written.

So it's flag=0 for RDTAX, not flag=1.

BTW it's the same with VER that can never appear in a program:

XROM: module=30 function=5 count=32 list=11 flag=0
Decoded XROM function: VER

(09-12-2016 09:42 PM)leoduran Wrote: 3) What version of Windows are you running? (32 or 64 bit?)

I am running hp41uc on an XP SP 3 machine, i.e. 32 bit.

Dieter

leoduran · (This post was last modified: 09-13-2016 10:36 AM by leoduran.)

(09-12-2016 10:04 PM)Dieter Wrote:
(09-12-2016 09:42 PM)leoduran Wrote: 1) Wow... Now I'm really confused!
What do you mean by "non-programmable functions (e.g. LIST)...throw a compiler error"?

Have a text file with a non-programmable printer command like LIST (XROM 29,07) and this line will not compile. hp41uc /r will display an error message saying that the command in this line of the text file is not recognized and the user should try XROM xx,yy instead:

Error: unrecognized or incomplete function[ LIST ]
If [ LIST ] is an external module function, try: [ XROM mm,ff ]
Compiler error on line 8.
0 bytes written.

This is fine since LIST cannot be used in a program. It is not programmable and can only be used in Run mode.

On the other hand non-programmable card reader commands like VER run through the compiler without any error. De-compiling this back to a text file shows XROM 30,05.

(09-12-2016 09:42 PM)leoduran Wrote: 2) OK, attached is the .EXE (v2.43), I expect the output to include:
XROM: module=30 function=3 count=32 list=11 flag=1
Decoded XROM function: RDTAX
XROM: module=29 function=20 count=32 list=11 flag=1
Decoded XROM function: PRX
97 bytes written.

The output is:
...
XROM: module=30 function=3 count=32 list=11 flag=0
Decoded XROM function: RDTAX
XROM: module=29 function=20 count=32 list=11 flag=1
Decoded XROM function: PRX
102 bytes written.

So it's flag=0 for RDTAX, not flag=1.

BTW it's the same with VER that can never appear in a program:

XROM: module=30 function=5 count=32 list=11 flag=0
Decoded XROM function: VER

(09-12-2016 09:42 PM)leoduran Wrote: 3) What version of Windows are you running? (32 or 64 bit?)

I am running hp41uc on an XP SP 3 machine, i.e. 32 bit.

Dieter

1) On the non-programmable functions, that was an oversight on my part: VER, WALL, and WPRV should now behave as LIST does.

2) Regarding RDTAX, for some 'strange' reason its decode flag is set to 0 (flag = 0) on your computer.

Let's try again with this attached .EXE.
Leo.

Dieter · (This post was last modified: 09-13-2016 06:02 AM by Dieter.)

(09-12-2016 11:03 PM)leoduran Wrote: 2) Regarding RDTAX, for some 'strange' reason its decode flag is set to 0 (flag = 0) on your computer.

Let's try again with this attached .EXE.

Same result: flag=0.

Hmmm... just an idea: does your program require a CPU with SSE2 support? Visual Studio seems to have this turned on by default.
But even if SSE2 is required – the printer functions work fine, it's only the card reader that doesn't.

Dieter

leoduran · (This post was last modified: 09-13-2016 08:01 PM by leoduran.)

(09-13-2016 05:58 AM)Dieter Wrote:
(09-12-2016 11:03 PM)leoduran Wrote: 2) Regarding RDTAX, for some 'strange' reason its decode flag is set to 0 (flag = 0) on your computer.

Let's try again with this attached .EXE.

Same result: flag=0.

Hmmm... just an idea: does your program require a CPU with SSE2 support? Visual Studio seems to have this turned on by default.
But even if SSE2 is required – the printer functions work fine, it's only the card reader that doesn't.

Dieter

Nah... I don't think it has to do with SSE2, this seems more like a stack growing too much in one my functions and overwriting (clearing) the flag that was initially set to 1.

Anyway, please try this one (attached). I expect the output to be:
F:\>hp41uc /r=test /t /n
Overwrite F:\test.txt (Yes/[No])?y
raw[ F:\test.raw ] => txt[ F:\test.txt ]
flag[30]=1
XROM: module=30 function=3 count=32 list=11 flag=1
Decoded XROM function: RDTAX
XROM: module=29 function=20 count=32 list=11 flag=1
Decoded XROM function: PRX
97 bytes written.

Leo.

Dieter · (This post was last modified: 09-13-2016 07:38 PM by Dieter.)

(09-13-2016 10:35 AM)leoduran Wrote: Anyway, please try this one (attached). I expect the output to be:
(...)

Bingo – this time it seems to work:
...
flag[30]=1
XROM: module=30 function=3 count=32 list=11 flag=1
Decoded XROM function: RDTAX
XROM: module=29 function=20 count=32 list=11 flag=1
Decoded XROM function: PRX
97 bytes written.

Resulting txt file after decompiling the raw file:

Code:

 01 LBL "PRDTA"

 02 1.004

 03 RDTAX

 04 RCL 03

 05 RCL 04

 06 *

 07 PRX

 08 RTN

 09 END

I also tried some other card reader commands, and there was no problem either. VER was not accepted, so that's fine as well. This time everything seems to work as advertised. ;-)

BTW, there is one thing that could be improved.
Consider the original test.txt file after one command has been manually added:

Code:

01 LBL "PRDTA"

02 1.004

03 RDTAX

   7DSP2

04 RCL 03

05 RCL 04

06 *

07 PRX

08 RTN

09 END

This does not compile with option /n since the compiler seems to interpret the inital 7 of the 7DSP2 command as a line number. It doesn't compile without /n either since there is no command "01 LBL "TEST"". The only way to handle this is adding a dummy line number at 7DSP2.

It's essentially the same problem as with numeric constants under the same circumstances. The logic that detects line numbers and removes them seems to handle everything that starts with a numeric digit as a line number to remove. So "7DSP2" gets interpreted as line 7 with a "DSP2" command. This was OK if the line was "7 DSP2" (with a blank after the 7), but I think the current logic is a bit strict here. ;-)

Anyway, I don't want to complain. Thank you very much for all your efforts.

Dieter

leoduran · (This post was last modified: 09-13-2016 08:26 PM by leoduran.)

1) Very cool, I'm glad to hear it's working now!
But... Just to confirm, please try again with the released version I just pushed:
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/
(It won't have the debug output, like "flag=1" and so on).

2) As for the 7DSP2 issue: The behavior is as intended.
The compiler expects line numbers either in or out for each and every line... you can't mix modes (ponder on that a bit, and I think you will agree).

BTW, as you well mentioned, the workaround is to insert a dummy line number (the compiler does not care about the numbers being in sequence)... So this would work:
01 LBL "PRDTA"
02 1.004
03 RDTAX
10 7DSP2
04 RCL 03
05 RCL 04
06 *
07 PRX
08 RTN
09 END

Thanks,
Leo

Dieter · (This post was last modified: 09-13-2016 09:07 PM by Dieter.)

(09-13-2016 07:58 PM)leoduran Wrote: 1) Very cool, I'm glad to hear it's working now!
But... Just to confirm, please try again with the released version I just pushed:
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/
(It won't have the debug output, like "flag=1" and so on).

That one also works fine. Great.

(09-13-2016 07:58 PM)leoduran Wrote: 2) As for the 7DSP2 issue: The behavior is as intended.
The compiler expects line numbers either in or out for each and every line... you can't mix modes

Mixing lines with and without numbers is fine if the command name does not start with a digit. It's only these commands that cause a problem.

(09-13-2016 07:58 PM)leoduran Wrote: (ponder on that a bit, and I think you will agree).

Hmm.... maybe I have to think harder. ;-)

Final remark: both the manual and hp41uc's help screen refer to raw files with regard to LIFUTIL. I do not know how common and widespread the latter is, but I suppose that the number of V41 users is probably larger. So maybe it's a good idea to add V41 as another application that reads and writes raw files.

Dieter

leoduran · (This post was last modified: 09-14-2016 12:05 AM by leoduran.)

(09-13-2016 07:58 PM)leoduran Wrote: ...
Final remark: both the manual and hp41uc's help screen refer to the raw format with regard to LIFUTIL. I do not know how common and widespread the latter is, but I suppose that the number of V41 users is probably larger. So maybe it's a good idea to add V41 as another application that reads and writes raw files.

Dieter

Good point about V41... I just updated the UsersGuide accordingly. Thanks,

Dieter · 09-14-2016, 09:04 PM

(09-13-2016 07:58 PM)leoduran Wrote: 1) Very cool, I'm glad to hear it's working now!

I just noticed that the card reader's 7RCLΣ function (XROM 30,35) appears as "7RCL" in listings generated by hp41uc. Maybe this can be fixed and, like other statistic functions, the compiler may even accept both "7RCLS" and "7RCLSigma".

Dieter

leoduran · (This post was last modified: 09-15-2016 01:22 PM by leoduran.)

(09-14-2016 09:04 PM)Dieter Wrote:
(09-13-2016 07:58 PM)leoduran Wrote: 1) Very cool, I'm glad to hear it's working now!

I just noticed that the card reader's 7RCLΣ function (XROM 30,35) appears as "7RCL" in listings generated by hp41uc. Maybe this can be fixed and, like other statistic functions, the compiler may even accept both "7RCLS" and "7RCLSigma".

Dieter

Noted.

leoduran · (This post was last modified: 09-22-2016 08:16 PM by leoduran.)

(09-14-2016 09:04 PM)Dieter Wrote: I just noticed that the card reader's 7RCLΣ function (XROM 30,35) appears as "7RCL" in listings generated by hp41uc. Maybe this can be fixed and, like other statistic functions, the compiler may even accept both "7RCLS" and "7RCLSigma".

Dieter

OK, please try this one.... "7RCLS" should now work.
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/

leoduran · (This post was last modified: 09-22-2016 09:29 PM by leoduran.)

Dieter, et al,

I've uploaded v2.44 to SourceForge:
Feature enhancements and clean-up.
1) Add support for external XROM files with “/m” option
2) Dump internal XROMs with “/x” option
3) Exclude internal XROMs in compiler with “/x” option
4) Clean-up to use macros instead of numbers:
e.g., HP41_ERROR and HP41_OK as return codes.

Please give it try and let me know if you find any issues.
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/
Thanks,
Leo

P.S.
In a nutshell, this version allows compiling/decompiling XROM functions defined in an external text file... Be sure to read these new sections in the UsersGuide:
1) Supported XROM Modules
2) Importing XROM Modules

Dieter · 09-25-2016, 01:19 PM

(09-22-2016 08:19 PM)leoduran Wrote: Please give it try and let me know if you find any issues.
...
In a nutshell, this version allows compiling/decompiling XROM functions defined in an external text file... Be sure to read these new sections in the UsersGuide:
1) Supported XROM Modules
2) Importing XROM Modules

No problems so far. And I really like the idea of adding your own XROM function set. I'm not sure if I like the appended XROM numbers the decompiler generates.

BTW, what character set does the program support? Since it does not use "≠" or "Σ" it looks like it can handle only plain ASCII or maybe ANSI. What about Unicode? This would allow the two mentioned characters.

FTR: With the built-in card reader functions disabled (/x30) I tried my own card reader file with all the XROM 30, nn functions and only 7RCLS replaced with 7RCLΣ. This file was saved as "reader.txt" using Windows Notepad with Unicode encoding.

Then I tried
hp41uc /t=test /r /x30 /m=reader.txt /n /k

The result was an error message saying that no end-of-line character could be found. Then I stored the same file using notepad++ and this time the EOL-warning did not show up. Instead hp41uc did not understand the line defining the 7RCLΣ command as it could not decode the Σ character:

XROM Error: invalid arguments[ 7RCL╬ú 30,35 ]

I assume fixing this is not trivial, so it may stay the way it is.

Dieter

leoduran · (This post was last modified: 09-25-2016 05:15 PM by leoduran.)

(09-25-2016 01:19 PM)Dieter Wrote: No problems so far. And I really like the idea of adding your own XROM function set.

That's good, thanks for the feedback.

(09-25-2016 01:19 PM)Dieter Wrote: I'm not sure if I like the appended XROM numbers the decompiler generates.

This is useful because some function names are duplicated in multiple modules, so this tells you which module was actually decompiled.

(09-25-2016 01:19 PM)Dieter Wrote: BTW, what character set does the program support? Since it does not use "≠" or "Σ" it looks like it can handle only plain ASCII or maybe ANSI. What about Unicode? This would allow the two mentioned characters.

Here's a cut-paste from the "Importing XROM Modules" section in the UsersGuide: XROM modules may be imported from one or more ASCII text files...

(09-25-2016 01:19 PM)Dieter Wrote: FTR: With the built-in card reader functions disabled (/x30) I tried my own card reader file with all the XROM 30, nn functions and only 7RCLS replaced with 7RCLΣ. This file was saved as "reader.txt" using Windows Notepad with Unicode encoding.

Then I tried
hp41uc /t=test /r /x30 /m=reader.txt /n /k

The result was an error message saying that no end-of-line character could be found. Then I stored the same file using notepad++ and this time the EOL-warning did not show up. Instead hp41uc did not understand the line defining the 7RCLΣ command as it could not decode the Σ character:

XROM Error: invalid arguments[ 7RCL╬ú 30,35 ]

I assume fixing this is not trivial, so it may stay the way it is.

Dieter

Interesting thought on supporting unicode; but yes, it would not be trivial, and frankly IMO not necessary... Remember, function names are not part of the actual user-code encoding (as that is simply of the form XROM mm,ff). What is important is that the text in the XROM file is consistent with the text used in the program listing (function names in the XROM files simply serve as a lookup, so that HP41UC can use the corresponding 'mm,ff' ID's).

So as you alluded to, I suggest replacing HP-41 special characters with reasonably equivalent printable ASCII characters, for example: using 'S' for 'Σ', and '#' for '≠'.

leoduran · (This post was last modified: 06-04-2020 06:07 PM by leoduran.)

=== UPDATE ===
Version 3.00 - Uploaded: June 3, 2020

Skip over Line-Feed (0x0A) characters on input DAT files.
NOTE: This feature does not require any extra arguments.

Main page for HP41UC on SourceForge:
https://sourceforge.net/projects/hp41uc/

Users Guide (PDF, Download)
https://sourceforge.net/p/hp41uc/code/ci...sGuide.pdf

Win32 executable (ZIP, Download):
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/

Linux (32-bit) executable (ZIP, Download):
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/

**rprosperi** · 06-04-2020, 03:04 PM

FYI - The links to the executable files are bad, but they're easy to find in the SF repository.