Interest in 32-bit version of User Code Utiltiy for HP-41

[MichaelG]

The subject says it all. Is there any interest in a 32-bit Windows version of Leo Duran's User Code Utility for the HP-41?

The port does not seem that difficult but has one feature I'd like to change. The command seems to accept wildcards for input file names. I'd like to remove that feature and accept only real filenames.

Is is worth the work?

Michael

[Massimo Gnerucci (Italy)]

Sure!
Why not move one step forward? Thank you.

Greetings,
Massimo

[Egan Ford]

I'd prefer a POSIX version that could then be compiled on any platform. For Windows you'd use DJCPP.

[Massimo Gnerucci (Italy)]

A Windows only version is fine to me... :p ;)

Massimo

[Geir Isene]

A Linux only version is fine with me :)

[Massimo Gnerucci (Italy)]

Fine! But since it started as a DOS pgm... ;)

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

[Geir Isene]

POSIX... Compiled for Linux... forget the Windows.

[Ángel Martin]

PLs. don´t forget Windows - some of us still (must) use it , even if we loath it.

Looking forward to the port!

[Massimo Gnerucci (Italy)]

Quote:

---

PLs. don´t forget Windows - some of us still (must) use it , even if we loath it.

---

Since it is my bread and butter I won't loathe it. Rather I loathe some fruity boxes... ;)
+1 for the Win version!

Massimo

[MichaelG]

I haven't that good news. I've been a software engineer for almost 30 years. Not to blame the author of the tool but I personally judge the source code as highly unmaintainable. It is by far more effort necessary than I am willing to invest for the port. It took me a long while to find a not initialized variable in the original code which created big problems. All my experience tells me even if I get it to work there is a huge amount of testing needed.

The good news are it seems that the conversion from txt to raw works. Having the above information in mind what are the most important conversions for you. The converter support n x m conversions. Can we reduce that for the time being to a needed minimum?

Michael

[David Hayden]

I'm curious to see the source code. Can you say where you found it? I can't seem to locate the source with google.

[MichaelG]

I found it here: http://hp41.claughan.com/file/hp41uc.zip

After digging a bit deaper into the code I finally gave up. The reason is the port might be possible. But I see the port only as a first step to move the tool to the 32-bit platform. If I port something I also want to be able to maintain the code up to a certain extend (like previously the A41, L41). I see no chance here. I think its better to rewrite the tool. Perhaps its possible to find the logic (its well hidden).

Michael

[David Hayden]

Thanks for the pointer to the source code.

I see what you mean about the logic. The overall design seems to be "there are a few dozen distinct translations that can happen, let's code them all and factor out the common parts." If I were writing it, I think I would translate each supported format to/from one common format (maybe RAW). Then each translation would involve two steps: input format to raw, and raw to output format. It might take a little longer at run time, but it would drastically simplify the code.

Another problem is that the code assumes it's running on a little-endian machine. A 32-bit version should probably have source code that works on either little- or big-endian hardware.

Dave

[Kerem Kapkin (Silicon Valley, CA)]

+1 for the Win 32 version.
Regards, Kerem

[MichaelG]

As estimated it is by far easier to start from scratch. And I started it. The compiler now uses the classis technology and is fully table driven. First step is the lexical analysis (the tokenizer) then do what is needed based on the table entry. There is an entry for each statement describing its opcode, parameters etc. The core compiler is only 260 lines.

The good news is the compiler already creates reasonable output (from txt to raw). The error handling is prepared, thats the next step.

I know some people won't love what's comming now: this version is written in C#/.Net 4.0. Besides the new structure it is one reason why the development can be that fast.

I'm not decided yet whether I go for a command line tool or some sort of GUI. Your input is welcome. For my tests the compiler has a window :-)

And I plan to introduce defines or however it gets called finally. The idea is you can define a constant and use that constant for the rest of the program. The compiler replaces the constant with the assigned value. E.g.

#def IAMACONST 12
RCL IAMACONST

results in

RCL 12

Michael

Edited: 29 Jan 2012, 8:08 a.m.

[David Hayden]

The only time I've used hp41uc was to convert a bunch of programs to several different formats, so the command line abilities were my preference. I was able to create a script to convert all the files.

Note that what this really means is that it would be nice to be able to do some sort of batch conversion. A windowed utility could do that too.

One nice feature of a windowed interface might be the ability to expand/collapse LIF directories so you can convert individual files within them.

As for a pre-processor, I'd be happy with the C pre-processor.

Dave

[MichaelG]

Here is the first 32-bit beta version v0.7 of the txt to raw compiler:

download.michael-goericke.de/FocalComp.zip

Right now without docu. The zip contains a small test file that shows how the defines work. The emulator V41 loads the raw files.

The command line is very simple:

FocalComp <filename>

No option right now. Filename needs to be fully qualified (with extension). The output filename is constructed by exchanging the extension with .raw.

As mentioned the runtime environment .Net 4.0 is required. Specifically the client profile version is sufficent. Its standard under Win 7 and there are installer available for XP and Vista in case it isn't already installed on your system.

Special characters in strings aren't handled yet like append

Michael

Edited: 30 Jan 2012, 2:29 p.m.