Threaded Mode | Linear Mode

leoduran · (This post was last modified: 06-19-2016 05:19 PM by leoduran.)

This in an update to my original project listed here:
http://www.hpmuseum.org/software/41uc.htm

Version 2.00 - Uploaded: June 11, 2016
I've revised the HP41UC utility so that it works as a Win32 console application. In the process, I fixed a compiler bug for "{STO*, STO/, STO+, STO-} IND xx", and included a nicer looking Users Guide.

Here's the link to the HP41UC project I've created in SourceForge:
https://sourceforge.net/projects/hp41uc/

The Win32 executable is here:
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/

Cheers!
Leo.

=== UPDATE ===
Version 2.10 - Uploaded: June 19, 2016

1) Fix bug to allow compiling multiple files into a LIF file.
2) Add support for building with GNU tools.
3) Add statically-linked 32-bit x86 ELF executable for Linux.

The Linux (32-bit) executable is here:
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/

Dieter · 09-09-2016, 08:47 PM

(06-10-2016 09:10 PM)leoduran Wrote: This in an update to my original project listed here:
http://www.hpmuseum.org/software/41uc.htm

I think it's time to say Thank You here.

hp41uc is a great tool for every HP41 user, both for the real thing as well as emulators like V41. I am using it right now to generate raw files for the HP67/97 Games Pac project in the General Forum. Also generating listings or editing programs with re-arranged code parts can be done without much effort.

(06-10-2016 09:10 PM)leoduran Wrote: Version 2.00 - Uploaded: June 11, 2016
I've revised the HP41UC utility so that it works as a Win32 console application.

I am using version 1.30 from 2007 and it works fine for me. But what are the benefits of the recent update (apart from the mentioned bugfixes)?

Anyway, thank you again for this great tool.

Dieter

Massimo Gnerucci · 09-09-2016, 10:20 PM

(09-09-2016 08:47 PM)Dieter Wrote:
(06-10-2016 09:10 PM)leoduran Wrote: Version 2.00 - Uploaded: June 11, 2016
I've revised the HP41UC utility so that it works as a Win32 console application.

I am using version 1.30 from 2007 and it works fine for me. But what are the benefits of the recent update (apart from the mentioned bugfixes)?

Anyway, thank you again for this great tool.

Dieter

Up to version 2.40 right now!

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

(09-09-2016 08:47 PM)Dieter Wrote:
(06-10-2016 09:10 PM)leoduran Wrote: This in an update to my original project listed here:
http://www.hpmuseum.org/software/41uc.htm

I think it's time to say Thank You here.

hp41uc is a great tool for every HP41 user, both for the real thing as well as emulators like V41. I am using it right now to generate raw files for the HP67/97 Games Pac project in the General Forum. Also generating listings or editing programs with re-arranged code parts can be done without much effort.

(06-10-2016 09:10 PM)leoduran Wrote: Version 2.00 - Uploaded: June 11, 2016
I've revised the HP41UC utility so that it works as a Win32 console application.

I am using version 1.30 from 2007 and it works fine for me. But what are the benefits of the recent update (apart from the mentioned bugfixes)?

Anyway, thank you again for this great tool.

Dieter

I suggest you review the "UsersGuide" to get a better idea about the changes.
The main difference is that v1.30 is a 16-bit VisualC (MS-DOS) application, whereas the newer code base has been ported to 32/64-bit Visual Studio and also to GNU C.

The GNU code can be compiled for Linux and most versions of Windows, including Windows XP. So you can benefit from all the bug fixes even if you're still running an older version of Windows. Of course, you'd need to use a proper GNU toolchain like:
1) DJGPP: http://www.delorie.com/djgpp/
2) MinGW: http://www.mingw.org/

BTW, an important goal for me is to maintain backwards compatibility.
So you can upgrade without fear of losing functionality.

HTH,
Leo

leoduran · 09-10-2016, 07:59 PM

(09-09-2016 10:20 PM)Massimo Gnerucci Wrote:
(09-09-2016 08:47 PM)Dieter Wrote: I am using version 1.30 from 2007 and it works fine for me. But what are the benefits of the recent update (apart from the mentioned bugfixes)?

Anyway, thank you again for this great tool.

Dieter

Up to version 2.40 right now!

Actually, I just uploaded v2.41.

Thanks to the collaboration and testing from Gonzalo Fernandez (fellow HP-41 enthusiast from Spain), I've uploaded quite a few bug fixes and enhancements.

Cheers!
Leo

Massimo Gnerucci · 09-10-2016, 08:11 PM

(09-10-2016 07:59 PM)leoduran Wrote:
(09-09-2016 10:20 PM)Massimo Gnerucci Wrote: Up to version 2.40 right now!
Actually, I just uploaded v2.41.

Thanks to the collaboration and testing from Gonzalo Fernandez (fellow HP-41 enthusiast from Spain), I've uploaded quite a few bug fixes and enhancements.

Cheers!
Leo

Got it. :-)
Thank you Leo (and Gonzalo)!

Dieter · 09-11-2016, 04:45 PM

(09-10-2016 07:53 PM)leoduran Wrote: The main difference is that v1.30 is a 16-bit VisualC (MS-DOS) application, whereas the newer code base has been ported to 32/64-bit Visual Studio and also to GNU C.

The GNU code can be compiled for Linux and most versions of Windows, including Windows XP. So you can benefit from all the bug fixes even if you're still running an older version of Windows.

Hmmm... I tried to run the .exe on Windows XP and got an error message (not a valid 32-bit application). Also release.txt says that at least Windows 7 is required.

Is there a special reason for this limitation? What is the benefit?

(09-10-2016 07:53 PM)leoduran Wrote: Of course, you'd need to use a proper GNU toolchain like:

1) DJGPP: http://www.delorie.com/djgpp/
2) MinGW: http://www.mingw.org/

Sorry, I am not a "compile your own" guy. ;-)
I'm just a user.

(09-10-2016 07:53 PM)leoduran Wrote: BTW, an important goal for me is to maintain backwards compatibility.
So you can upgrade without fear of losing functionality.

Hm – see above.

Dieter

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

(09-11-2016 04:45 PM)Dieter Wrote:
(09-10-2016 07:53 PM)leoduran Wrote: The main difference is that v1.30 is a 16-bit VisualC (MS-DOS) application, whereas the newer code base has been ported to 32/64-bit Visual Studio and also to GNU C.

The GNU code can be compiled for Linux and most versions of Windows, including Windows XP. So you can benefit from all the bug fixes even if you're still running an older version of Windows.

Hmmm... I tried to run the .exe on Windows XP and got an error message (not a valid 32-bit application). Also release.txt says that at least Windows 7 is required.

Is there a special reason for this limitation? What is the benefit?

(09-10-2016 07:53 PM)leoduran Wrote: Of course, you'd need to use a proper GNU toolchain like:

1) DJGPP: http://www.delorie.com/djgpp/
2) MinGW: http://www.mingw.org/

Sorry, I am not a "compile your own" guy. ;-)
I'm just a user.

(09-10-2016 07:53 PM)leoduran Wrote: BTW, an important goal for me is to maintain backwards compatibility.
So you can upgrade without fear of losing functionality.

Hm – see above.

Dieter

According to this article, my newer VisualStudio source code can target Windows XP:
https://msdn.microsoft.com/en-us/library/jj851139.aspx

So I've just re-built the application as the article suggests, without any changes to the source.
Please try the .EXE on XP and let me know if it works for you (I don't have XP to test it, but it still works fine on Win7).
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/

Leo

Dieter · (This post was last modified: 09-11-2016 06:56 PM by Dieter.)

(09-11-2016 05:31 PM)leoduran Wrote: So I've just re-built the application as the article suggests, without any changes to the source.
Please try the attached .exe on XP and let me know if it works for you (I don't have XP to test it, but it still works fine on Win7).

Still doesn't work as MSVCR120.DLL is missing. Looks like a runtime library.
Probably this DLL can be found somewhere for download – or maybe you can include it in your zip file...?-)

Dieter

leoduran · 09-11-2016, 07:58 PM

(09-11-2016 06:54 PM)Dieter Wrote:
(09-11-2016 05:31 PM)leoduran Wrote: So I've just re-built the application as the article suggests, without any changes to the source.
Please try the attached .exe on XP and let me know if it works for you (I don't have XP to test it, but it still works fine on Win7).

Still doesn't work as MSVCR120.DLL is missing. Looks like a runtime library.
Probably this DLL can be found somewhere for download – or maybe you can include it in your zip file...?-)

Dieter

Ummh... You probably already have a copy of it on your system.
Try opening a CMD window and from there:
> C:
> cd \
> dir MSVCR120.DLL /s

HTH,
Leo

jch · 09-11-2016, 07:59 PM

(09-11-2016 06:54 PM)Dieter Wrote:
(09-11-2016 05:31 PM)leoduran Wrote: So I've just re-built the application as the article suggests, without any changes to the source.
Please try the attached .exe on XP and let me know if it works for you (I don't have XP to test it, but it still works fine on Win7).

Still doesn't work as MSVCR120.DLL is missing. Looks like a runtime library.
Probably this DLL can be found somewhere for download – or maybe you can include it in your zip file...?-)

Dieter

Did you install Visual C++ Redistributable Packages ?

Jean-Christophe.

Dieter · 09-11-2016, 08:10 PM

(09-11-2016 07:59 PM)jch Wrote: Did you install Visual C++ Redistributable Packages ?

No, why should I ?
I do not use Visual Studio or any other MS programming environment.

I think I'll stick with version 1.30.
Works fine and will continue to do so.

Dieter

jch · 09-11-2016, 08:23 PM

(09-11-2016 08:10 PM)Dieter Wrote: No, why should I ?
I do not use Visual Studio or any other MS programming environment.

Dieter, even if you use no MS programming environment, I guess Leo has to use one to build his project.
Nowaday programs rely on a framework, hence my suggestion to try installing this redistribuable package.
Leo, are you working with Visual Studio 2013 ?

Jean-Christophe.

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

(09-11-2016 08:23 PM)jch Wrote:
(09-11-2016 08:10 PM)Dieter Wrote: No, why should I ?
I do not use Visual Studio or any other MS programming environment.

Dieter, even if you use no MS programming environment, I guess Leo has to use one to build his project.
Nowaday programs rely on a framework, hence my suggestion to try installing this redistribuable package.
Leo, are you working with Visual Studio 2013 ?

Jean-Christophe.

JC,
Yes, I'm using VS2013.
BTW, I've just re-built the application using a static-link option, so it should no longer require the external runtime environment:
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"

Dieter,
Please download the .ZIP file again and give this newer (and bigger) .EXE a try.
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/

Thanks,
Leo

Dieter · 09-11-2016, 09:46 PM

(09-11-2016 08:38 PM)leoduran Wrote: BTW, I've just re-built the application using a static-link option, so it should no longer require the external runtime environment:
(...)
Please download the .ZIP file again and give this newer (and bigger) .EXE a try.

Great, this time it works. Thank you.
Re. the "bigger .exe": it's even smaller than version 1.3 (162 vs. 188 KB). ;-)

May I add a feature request? As far as I can see only a few peripherals and their XROM codes are supported (i.e. recognized by their command names). That's fine by me, but I just wonder why an ..."exotic" device like the plotter ROM is included but the card reader is not, unlike the two other classic peripherals (Printer and Wand). This way translated HP67/97 programs only show XROM codes instead of their command names. Do you think that some distant day the card reader commands will make it into hp41uc...?

Dieter

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

(09-11-2016 09:46 PM)Dieter Wrote:
(09-11-2016 08:38 PM)leoduran Wrote: BTW, I've just re-built the application using a static-link option, so it should no longer require the external runtime environment:
(...)
Please download the .ZIP file again and give this newer (and bigger) .EXE a try.

Great, this time it works. Thank you.
Re. the "bigger .exe": it's even smaller than version 1.3 (162 vs. 188 KB). ;-)

May I add a feature request? As far as I can see only a few peripherals and their XROM codes are supported (i.e. recognized by their command names). That's fine by me, but I just wonder why an ..."exotic" device like the plotter ROM is included but the card reader is not, unlike the two other classic peripherals (Printer and Wand). This way translated HP67/97 programs only show XROM codes instead of their command names. Do you think that some distant day the card reader commands will make it into hp41uc...?

Dieter

Well, I recently refactored the source to make it easy to add XROMs, so adding the "Card Reader" was not painful at all.

I just pushed v2.42:
1) The Win32 executable runs stand-alone (static-link) under Windows XP and later.
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/
2) The Card Reader (module #30) is added to the list of supported XROMs.

Have fun!
Leo

Dieter · (This post was last modified: 09-12-2016 07:19 AM by Dieter.)

(09-12-2016 12:04 AM)leoduran Wrote: Well, I recently refactored the source to make it easy to add XROMs, so adding the "Card Reader" was not painful at all.

Great – thank you very much.

(09-12-2016 12:04 AM)leoduran Wrote: 2) The Card Reader (module #30) is added to the list of supported XROMs.

Indeed the compiler recognizes card reader commands like RDTAX or 7DSP2. But decompiling a resulting .raw file generates a listing that only includes XROM commands for these functions, while e.g. printer commands have their correct names.

Example:

Code:

 01 LBL "PRDTA"

 02 1.004

 03 RDTAX

 04 RCL 03

 05 RCL 04

 06 *

 07 PRX

 08 RTN

 09 END

Store this as test.txt and compile it: hp41uc /t=test /r /n /k
This produces test.raw.
Decompile this again: hp41uc /r=test /t /n
and get this new test.txt:

Code:

 01 LBL "PRDTA"

 02 1.004

 03 XROM 30,03

 04 RCL 03

 05 RCL 04

 06 *

 07 PRX

 08 RTN

 09 END

Hmmm...

Dieter

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

(09-12-2016 07:09 AM)Dieter Wrote:
(09-12-2016 12:04 AM)leoduran Wrote: Well, I recently refactored the source to make it easy to add XROMs, so adding the "Card Reader" was not painful at all.

Great – thank you very much.

(09-12-2016 12:04 AM)leoduran Wrote: 2) The Card Reader (module #30) is added to the list of supported XROMs.

Indeed the compiler recognizes card reader commands like RDTAX or 7DSP2. But decompiling a resulting .raw file generates a listing that only includes XROM commands for these functions, while e.g. printer commands have their correct names.

Example:

Code:

01 LBL "PRDTA" 02 1.004 03 RDTAX 04 RCL 03 05 RCL 04 06 * 07 PRX 08 RTN 09 END

Store this as test.txt and compile it: hp41uc /t=test /r /n /k
This produces test.raw.
Decompile this again: hp41uc /r=test /t /n
and get this new test.txt:

Code:

01 LBL "PRDTA" 02 1.004 03 XROM 30,03 04 RCL 03 05 RCL 04 06 * 07 PRX 08 RTN 09 END

Hmmm...

Dieter

Dieter,
I just tried your compile/decomplie sequences and the decompiler said this:

Code:

 01 LBL "PRDTA"

 02 1.004

 03 RDTAX

 04 RCL 03

 05 RCL 04

 06 *

 07 PRX

 08 RTN

 09 END

Did you by chance add a "/x30" switch to the decompiler, like this:
hp41uc /r=test /t /n /x30

Attached is "dieter.txt" showing the results I observed.
Leo.

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

(09-12-2016 02:13 PM)leoduran Wrote: Did you by chance add a "/x30" switch to the decompiler, like this:
hp41uc /r=test /t /n /x30

No. I know about the /x option but I did not use it.

(09-12-2016 02:13 PM)leoduran Wrote: Attached is "dieter.txt" showing the results I observed.

Here is what I got (can't remember the last time I used "type"):

Code:

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

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

.END. found on line 9.

 size[ 0019 ]  ( 25 bytes )

25 bytes written.

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

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

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

102 bytes written.

F:\>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

It shows the same output after compiling, but the decompiler writes 102 bytes because "XROM 30,03" is longer than "RDTAX". #-)

I even thought I had run 2.41 instead of 2.42, but the version is correct.
Strange.

Dieter

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

(09-12-2016 06:18 PM)Dieter Wrote:
(09-12-2016 02:13 PM)leoduran Wrote: Did you by chance add a "/x30" switch to the decompiler, like this:
hp41uc /r=test /t /n /x30

No. I know about the /x option but I did not use it.

(09-12-2016 02:13 PM)leoduran Wrote: Attached is "dieter.txt" showing the results I observed.

Here is what I got (can't remember the last time I used "type"):

Code:

F:\>hp41uc /t=test /r /n /k txt[ F:\test.txt ] => raw[ F:\test.raw ] .END. found on line 9. size[ 0019 ] ( 25 bytes ) 25 bytes written. F:\>hp41uc /r=test /t /n Overwrite F:\test.txt (Yes/[No])?y raw[ F:\test.raw ] => txt[ F:\test.txt ] 102 bytes written. F:\>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

It shows the same output after compiling, but the decompiler writes 102 bytes because "XROM 30,03" is longer than "RDTAX". #-)

I even thought I had run 2.41 instead of 2.42, but the version is correct.
Strange.

Dieter

Yes, that is odd... Since we exchanged .EXE files a few times, I'm wondering if we're just out of sync?

Please delete copies of hp41uc.exe you may have, and let's try this .EXE:
https://sourceforge.net/p/hp41uc/code/ci...32App_x86/
in a new/clean 'test' directory:
> F:
> mkdir test
> cd test
> (unzip the attached .EXE here, at F:\test)
> (copy your test.txt here, at F:\test\)
> hp41uc /t=test /r /n /k
> hp41uc /r=test /t /n

Does that work?
Leo.