Anyone interested in a SDK41 compatible version of the 41C VASM source files?

[Didier Lachieze]

If so you're lucky: I have one (GFF version), but it needs some work before publication so I would like to gauge the interest to define what priority to put on it. By interest I mean : who would use it for real output (to recompile the 41C ROM) and not just in case, for archiving purposes?

Historical background:
10 years ago there was a question on this forum about searchable versions of the HP 41 VASM listings: MCODE - anyone interested in a searchable VASM pdf? .
This was the trigger for me to start working on a text version of the VASM listings, I started with OCR but the output was pretty low quality and required manual adjustments. I decided that the best way to ensure that the result text file would be error free was to create a rom file from it and check this rom file vs. the original 41C rom for consistency.
As the development tools used with the VASM listings are not available anymore, I had to use the SDK41 assembler and linker to create the rom files. This means that I had to find a way to create a SDK41 compatible source file from the VASM text files. So I wrote some perl scripts to process the VASM text file and convert it to a SDK41 compatible format. This was a very iterative process as I progressed slowly through the original VASM listing, enriching the conversion script as I found new instructions or new line structures.

I was close to the end of this work when Jackie F. Woldering published in February 2013 his own version of the VASM listings in txt and pdf format. I was a bit disappointed as I was not aware we were working in parallel on the VASM listings, but anyway I completed my work up to the point where I could generate rom files that were identical to the original ones. This was the proof that the assembly instructions in my VASM text files were correct, however to check the consistency of the comments the rom files were useless, so I checked my VASM text file vs. Jackie’s version. This helped me to fix numerous typos in the comments but I found also that Jackie had made several modifications to the original comments:

• Fixing typos in original comments
• Replacing some abbreviated words by full words
• Rewriting some sentences

I must say that during this check process I found much more errors in my VASM txt file than in Jackie’s file. I’m amazed by the level of quality he achieved in converting the VASM listings to a text file.
At that point I stopped any work and as after the publication of Jackie’s file nobody seemed to need to generate a ROM file, it went very very low on my priority list.

The recent thread about open sourcing the HP calculator software reminded me about this work, and I think it’s a good time to bring it back.

So there is now to my knowledge two text versions of the original VASM listings:

• Jackie’s version with improved comments (and a few mistakes)
• My version with the correct assembly instructions and original comments – also available in a SDK41 compatible format that can be used to generate roms

My plan is to publish at some point:

• My VASM text and pdf files (similar to the ones published by Jackie)
• The perl scripts to generate the SDK41 source files from the VASM text file and the process to do so
• The SDK41 source files, the batch files to generate the ROMs from these source files and how to check the generated roms vs. the original roms
• The differences between my VASM text file and Jackie’s file

Now my questions to you:

• What would you do if you had access to a SDK41 compatible version of the 41C VASM source files?
• Do you prefer the original comments or the improved ones from Jackie?
• Would you see a need for a similar SDK41 compatible version of the HFF VASM listings?
• Any other suggestion on this topic?

[derekamos]

Hi Didier,
After so long (05-17-2018), it seems no-one has an interest in your well developed project.
I believe there is a couple of good reasons to pursue this though;
The 1st would be to make available a mod/rom on the web, that had the lower-case updates programmed into it. Something downloadable from TOS for instance.
Secondly, as the lowercase update is about the only one around, anyone with some bright ideas about keeping the same addressing for called routine labels, but adjusting the actual coding content for improvements, would most likely be a good reason to have interest in this project. It obviously would mean extensive re-working of the 12Kb space available, but may yield worthwhile results?
Other than that kind of effort, I don't see many/any other reasons, except as reference material for the old HP-ROM code, along with your improved comments sections.
Any one else have any sub-routine update ideas for inclusion?
(this sounds a bit like a PPC-ROM version 2 project)
DA

[Warbucks]

i used the old PDF file to quickly locate how pause, for example, was implemented so I could create a defined wait that would work independently of the host so it would pause for a second regardless of how fast you were running.

That would have been fantasic! I still intend to do some other changes, but I am spending all my time on my simulator rather than my emulator.

How long did that take you? The work would have been both hard and tedious. 0% error, fantastic.

JW

[mfleming]

I know of one patch to the original ROM image by Angel Martin that allowed the use of lowercase letters in the ED editor of the 41CX. I also have great sympathy for a comment I read some time ago by a user who thought that pressing the XEQ key should put you in Alpha mode by default (simple patch?)

None of this would help of course with an original HP-41, but with the proliferation of hardware (41CL) and software (V41) emulators, someone might want to improve upon the 41. The list of those with the skill to do so would be pretty short (!) but I at least would be interested in studying the code.

Given the MultiCalc style projects posted here by various members, maybe the availability of source code could inspire someone to develop a desktop 41 with printer and modern storage mechanism. Who knows what might result?

~Mark

[Gene]

Ah, but pressing XEQ does not mean you always want ALPHA. XEQ 00 through XEQ 99 are perfectly valid possibilities.

The designers had to choose which default to use. Perhaps a flag might have been used to indicate the XEQ mode, but life is short and flags are all used. :-)

[rprosperi]

(05-28-2018 04:15 PM)Gene Wrote:  Ah, but pressing XEQ does not mean you always want ALPHA. XEQ 00 through XEQ 99 are perfectly valid possibilities.

The designers had to choose which default to use. Perhaps a flag might have been used to indicate the XEQ mode, but life is short and flags are all used. :-)

I immediately had the same thought.... BUT, if it did default to toggle Alpha mode ON, you could always hit it again to shut it off, then enter the numbers. Since, in general, one probably uses Alpha after XEQ, rather than a numeric label, FAR more often, the price of hitting the extra Alpha when one wants to use numeric labels would be well worth it.

I use an analogous library on my 48 machines (thank you Raymond Del Tondo) which automatically enters Alpha mode when you press ['] and similar commands that require Alpha arguments. It is so natural, it's awkward when I first start to use a 50g since I have to manually enable Alpha mode.

Although trivial sounding, this small improvement is very convenient, quickly becomes second nature, and it would be nice to have it on 41CL machines, though no idea if such a change is feasible and easily implemented. If difficult, I'd say it's not worth it.

[Gene]

I don't disagree at all. It was a choice to make and they chose numeric.

Maybe to be consistent with GTO? After all, if GTO was numeric _ _ but XEQ prompted ALPHA, maybe we would be arguing over that today. :-)

Wish we had access to some (any?) of the HP 41 designers to ask these things to.

[derekamos]

Well how about altering the RPN output code to load "SYNTHO" hex codes instead?
EEX comes to mind immediately, but a whole swag-load of STO & RCL codes for those regs beyond/above the stack & others. Maybe its only saving single bytes as far as code in a program goes, but there is a speedup as well.
This doesn't seem to be just a minor alteration case, in fact it could turn out quite major --> the merging of synthetics with mainframe RPN.
DA.

[Ángel Martin]

(05-29-2018 12:15 AM)rprosperi Wrote:  Although trivial sounding, this small improvement is very convenient, quickly becomes second nature, and it would be nice to have it on 41CL machines, though no idea if such a change is feasible and easily implemented. If difficult, I'd say it's not worth it.

I've implemented the ALPHA-default on most of the functions that require an alphanumeric entry in all my modules. It's implemented as one of my favorite routines on the Library#4 ;-)

I always hated having to press ALPHA *four* times using COPY (non-assigned to a key: XEQ, ALPHA, COPY, ALPHA, ALPHA again, program name, ALPHA. The OS should be clever enough to know the data type for each function...

ÁM

[rprosperi]

(05-30-2018 04:34 PM)Ángel Martin Wrote:  I've implemented the ALPHA-default on most of the functions that require an alphanumeric entry in all my modules. It's implemented as one of my favorite routines on the Library#4 ;-)

I always hated having to press ALPHA *four* times using COPY (non-assigned to a key: XEQ, ALPHA, COPY, ALPHA, ALPHA again, program name, ALPHA. The OS should be clever enough to know the data type for each function...

I didn't mention your modules specifically, I noted the 48 since the library makes changes at the OS level, but the same is true with those as well. When I go back to 41 mainframe functions, they initially feel broken... or at least stupid. Why should I have to press Alpha, if I have to press Alpha?!

Are you familiar enough to say if it's feasible to hack that into the 41CX OS ROM, without a huge amount of effort?