HP-41 MCode Assembler/Linker 32-bit version

[MichaelG]

The current HP41 MCode development suite SDK41 from Warren Furlow was developed about a decade ago. The environment is developing and under the modern 64-bit Windows the 16-bit tools do not work anymore.

I started some research whether it is possible with low effort to move up the tools to the 32-bit level. And indeed the assembler A41 ist running well. The linker L41 produced its first .rom a few minutes ago.

Now everything needs to be tested.

My question for you all: Are you interested in the 32-bit versions at all? Or do you don't care? Meaning is that worth the effort? Do some people volonteer to help me testing the versions? E.g. comparing 16-bit results with the 32-bit results?

The suite contains more tools than A41 and L41. Which tools do you think should be ported to 32-bit as well (hopefully not all)? I guess the disassembler most probably.

Michael

[cgh]

Hello,

I have ported the SDK41 of Warren Furlow under Linux and *BSD. It works on 32-bits. It need GCC to be compiled, so it may be usable under DOS/Windows with the GCC. I used a41 to generate MCODE and d41 to disassemble. The linker l41 seems to work but I never went further. The t41 compiles, but I never use it. I have tried to make working the emulatotr m41, but I have preferred to start a rewrite of NSIM (nsimII) from Eric Smith.

Christophe

[Geir Isene]

I am very interested in your Linux version - could you send it to me?

I don't care about a 32-bit Windows version as I haven't used Windows since 12 years (except for some once-in-a-blue-moon weird reason)

[Eric Smith]

I'm interested in the Linux version of SDK41 also. Maybe there's enough interest to warrant putting it on a web page? Warren would probably be willing to put it on The Site That Must Remain Nameless.

[cgh]

OK. The work is sleeping from several years and will be delivered as is. I gave up. Currently, I have no time to continue this job. I will send it to Warren and see with him to put it on TOS.

Edited: 18 Jan 2012, 5:33 p.m.

[Geir Isene]

If it works OK, it would be an improvement over running the SDK in a Dosbox under Linux.

[MichaelG]

Thank for your offer. The Windows 32-bit port of A41 and L41 is already finished. Btw, I'm using Visual Studio 2010, so I don't need to deal with command line tools :-)

All the credit goes to Warren. The SDK is written in pure C and beside one or two little glitches they compile and run as 32-bit versions. Some years ago I ported a cross assembler and linker and that was really a pain.

To be honest I changed to behaviour of the assembler a bit. I simply couldn't live with the fact that the assembler modifies the original source code. I did a lot of assembler programming over the years with different tools but never came across that "feature".

The only difference now is the A41 only reads the source file and creates (on demand) a new listing file with the extension .lst.

Another new feature is the A41 now operates fully case-insensitive on the source file.

Lets see whether the demand of the 32-bit Windows version exists (at least for me since I have only 64-bit OSs running).

Michael

[Frido Bohn]

Well, at least for me a Windows 32-bit version would be very welcome (as I have given up struggeling with Linux for years).

The command-line structure of the assembler/disassmbler/linker complex is not just the state-of-the-art environment nowadays.

I don't know if you have integrated their functionality in one application. That would be nice.

Anyway, I would like to test it as long as you give the instructions what exactly you would like being tested.

[MichaelG]

Quote:

---

I don't know if you have integrated their functionality in one application. That would be nice.

---

This feature has already been availble. It is documented but I admit I came across that while studying the source code. If you list source files instead of object file in the linke file the linker calls the assembler automatically. Additionally when using this feature a small "make" feature makes it even more interesting. The linker checks the last modification date of both the source file and the object file and only runs the assembler if the source file has been modified after the last assembly run.

I discovered some major problems in this area. They seem to be solved now.

Next modification I made to both tools: you HAVE to specify the file extension of all input files. That also includes the object and source files in the linker project file. No implicit file extensions any more.

I think I can go public with the first beta version tomorrow.

Michael

[MichaelG]

I dare to go public. My tests show good results. E.g. I built Monte's huge source file for the CL and compared the ROMs. They are identical. That seems to be a good starting point for the 32-bit version.

If you are interested you can download the tools, a small manual (which lists the differences) and a small expample:

download.michael-goericke.de/SDK41R6.1-32v1.zip

I would be a great help if you have the chance to compare more ROM images created with both the 16-bit and the 32-bit version.

Michael

[Frido Bohn]

Thanks for sharing!

[Meindert Kuipers]

Thanks for sharing, result is a ROM file which is 100% identical to something I made for myself with the original SDK41 under DOSBOX. We finally have somthing running perfectly on a Windows 7 64 bit system. The command line had to be modified slightly though ...

Meindert

PS. the disassembler is not urgent for me, I have a very flexible version in the MLDL2000 manager software, this is not a commandline tool, but interactive under Windows.

[MichaelG]

Thx, great news.

What ideas do have in mind regarding the command line?

I started to look at the disassembler. It already creates some reasonable sources but I get some strange errors at the end. Stay tuned...

Michael

[Diego Diaz]

Hi Michael,

Every contribution to keep the HP-41 alive and kicking is very welcome to most of us... :-)

Thanks for sharing this new tool!

Cheers.

Diego.

[MichaelG]

Good news the disassembler is running fine. Again there are some slight changes all documented in the PDF:

1) As with the A41 and D41 you need to include the file extension for all input files.

2) Trailing NOPs are omitted

3) You can create both a pure source file or a list file that contains the object code as well as the mnemonics (same format as the list file created by the assemble).

To be consistent I change the format of the options of the tools once again. There are few options that need more data. Option and data are now separated by a colon. Its about these option: D41: /l:file.lbl, /p:9
A41: /a:<xx>

I am sure that makes the options a bit more readable - for humans :-)

The link to the tools is still the same:

download.michael-goericke.de/SDK41R6.1-32v1.zip

Michael

[MichaelG]

New version uploaded. The A41 now creates a list file with columns to beautify the output. New option /x added which turn on the expansion of the macros .FILLTO and .BSS.

Michael

[Monte Dalrymple]

One thing that I would find useful for A41 would be the ability to fill with 0x3FF instead of 0x000. This would leave unused locations unprogrammed when loaded into a Flash memory...

[MichaelG]

Shouldn't be a big deal. Do you need equivalents for both .BSS and .FILLTO? I could think of an optional parameter for both directives or 2 new directives. To be honest 2 new directives is a bit easier to implement. Any ideas for the names?

Michael

PS: I don't know whether you all get a notification mail when someone posts in a thread. At least I don't get one. In order to speed up some communication you can write me to hp41(at)michael-goericke.de

[Monte Dalrymple]

I haven't used .BSS yet. New directives might be preferable. A new directive could be .UNFILLTO ;-)

[MichaelG]

Ok, new version is ready for download (same link). I added a new directive .FILLTOVAL that takes 2 parameters <address> and <value>. E.g.

.FILLTOVAL 0045 35F

That enables you to fill with any value you like.

Michael