Nonpareil news; HP-41 file format opinion request


I just released version 0.65 of Nonpareil, which finally fixes the bug in state restoration. ("This time, for sure!") I thought I'd fixed it a few days ago, but it turned out that the problem only manifested on 32-bit machines, and my primary development environment is now an Athlon 64.

Now that it is a very usable 41CV (soon to be 41CX, thanks to the efforts of Chris Roccati and Thomas Sonne Olesen), I'm considering adding the ability to load and save 41C programs and data registers from external files. This will be in a raw binary format. I can't decide, though, whether the files should have the 32-byte LIF directory entry prepended. I think there are good arguments both ways, and there are utilies than can strip the LIF directory entry, but it's harder to create a new one. I'm leaning toward including the LIF directory entry, but if anyone is strongly opposed to that, I'd like to know why.





AFAIK there are already file save/restore options for Emu42S,

so maybe that file format could be used,

and the LIF extension as option only.



Well, all the solution book programs I've uploaded here don't include the LIF directory header... My linux LIF utilities can optionally include the header when extracting a file from a disk, but the default is not to do so. All my decoding filters, etc in the LIF Utilies for Linux distribution require that the input file does not include the header.

And AFAIK the .raw format used by the MSDOS tools doesn't include the header either.

I don't think the LIF directory entry for an HP41 file includes anything that can't easily be recreated (unlike the entry for some HP71 files which contain record size info, etc). So there would seem to be little point in requiring it.


Hmmm... I thought using the LIF directory entry would be useful since it allows the simulator (and other programs) to easily distinguish programs, data, key assignment, and "write all" files. This is useful in the simulator when one gives an "open" command, so that the simulator can automatically do the right thing. It would also allow the Linux/Unix "file" command to tell one what type of file it is (provided that the appropriate description is put into /usr/share/file/magic).

It would be even better if the LIF directory entry had a fixed magic number in it somewhere, but the LIF file type is probably good enough to identify 41C/71/75 files other than plain LIF1 text (which is used for 41C ASCII files).


Hi Eric!

Just a quick note: Display ok, keybord ok, currently I try to "synchronize" the debounce logic (now and then a key hit is droped). On my plan: emulate Low-Bat (works for HP-41), discard dead code used only for HP-41, key hit while CPU running (not trivial as the host-OS is originally not designed for that). More off-list.



Low Bat is detected in the display chips on HP-11C and -12C. So I am _not_ going to emulate that.



Low Bat is detected in the display chips on HP-11C and -12C. So I am _not_ going to emulate that.

Bummer! :-)

I had this idea a few days ago for an evil plan to give away simulators that need "batteries", and selling the "batteries" on my web site. The batteries would be locked to a MAC address and good for a limited time, though someone could cheat by rolling back their system clock.

Of course, I'm not actually going to do such a thing.


I dunno Eric, you could be onto something... You could
enhance the simulation by offering a "recharger" for
your "batteries" for a few dozen extra bucks. You'd
be (barely) compensated for your hard work and we could
all enjoy the eBay ads for the "very rare", NIB,
Nonpareil "battery pack" and "recharger" that
would appear in a few years from now.




Hehe, "Bummer"!, yes - of cause!!

NutEm checks the CPU load at 160 LLD (HP-mnemonic), or ?BAT (ZENROM disassembler), or ?LOW BAT (Jacobs/De Arras-mnemonic). Here my 'user exit' that returns 1 if CPU load > 95%

 * * * Top of File * * *                                                
/*Low Level Detect*/"PIPE CP IND!split 60-6c!drop!var p"; return p > 95
* * * End of File * * *

NutEm *only* emulates the CPU and everything else (display, keybord, ...) is a simulation close to the host-OS. For example for the display of the Voyager I re-arrange the "on-off-bits" of the segments, transliterate to EBCDIC and merge with the punctuation (transliterated too). Drawback: incomplete display during keybord test (ON + /). So dropping the low bat annunciator for the Voyagers is a remissible omission, IMHO.

BTW - anybody here who could test "my" HP-12C on VM/ESA and/or z/VM? I am about to publish it this week.



IMHO, the best would be a format usable in Emu41 of JF Garnier and V41 of Warren Furlow. So files could be sent to someone else without discussion about the emulator (or simulator if you prefere).



I've decided to use my own XML-based format, but to provide import and export in other formats usable with V41 (and probably with other simulators and tools).


Does that include the 'raw' binary program/sdata file? If not, you're cutting out all the solution book programs I carefully read in and uploaded...


I assume that what you're talking about is the equivalent of the 41C file formats used on LIF volumes, without a directory entry?

I'll definitely provide for use of raw binary files, though it won't be the default format.



Leo Duran wrote a MESSDOS utilty to convert HP41 user code file formats, available on TOS/LibView.cfm?Command=View&ItemID=32

In the Readme.txt file the different formats are described.

The RAW format is described there as

[compiled code] + [1-byte checksum] + [trailer]

In fact V41 use only the [compiled code] or generates only the [compiled code]. Emu42 is compatible with the V41 RAW code. The [1-byte checksum] and [trailer] section is ignored in both emulators. Leo Duran's program accept these also a RAW files where V41 and Emu42 also accepts Leo Duran's RAW format.

Emu42 has two minor modifications of this format:

The [compiled code] can contain more than one GLOBAL_END.



When V41 load such a user code file it load's only the first global label, LBL "B" is ignored.

When V41 see code like


you have the ability to save the LBL "A" and LBL "B" object on V41. In Emu42 this makes problems when you select more than one global label. In this case the section between LBL "B" and GLOBAL_END would be twice on the user code file. To avoid this Emu42 shows only LBL "A".

Further V41 has a minor bug, it cannot save FOCAL programs like


The part before LBL "A" is ignored. In Emu42 this problem has been solved. V41 has no problems to load the code above.

You don't have to take care about the link fields inside the user code. Both V41 and Emu42 recalculate them during the user code load. This is especially neccessary in Emu42 because you may have more than on global label which aren't together in the source. Second Emu42 is making a PACK and adding some HP-42S specific 00 bytes after numbers at loading, so the link offsets in the source are wrong most times anyway.

Happy implementing,


BTW, you should send Leo Duran a copy of your format that he can add it to his program. ;-)


I was a few days off, so here a delayed addition: The emulated HP-42S interprets correctly the 'short form exponent'. More clearly: E23 (short form) in a program is the same as 1E23 (normal form). Currently I am only abel to generate the short form by loading a RAW from an HP-41 emulator.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-41(CL): The easiest way to transfer FOCAL programs from a Linux PC to the HP-41 Geir Isene 13 2,748 12-05-2013, 02:40 AM
Last Post: Hans Brueggemann
  Prime: how to detect date format giancarlo 1 715 12-02-2013, 11:21 AM
Last Post: Michael de Estrada
  HP 50g - displaying result in engineering format Sean Freeman 10 1,568 11-24-2013, 05:44 AM
Last Post: C.Ret
  Trivial news of the 43S (no Prime) Walter B 117 11,306 11-22-2013, 03:26 AM
Last Post: Raymond Del Tondo
  HP PRIME: Fixed 4 number format 0.001000 Joseph Ec 18 2,541 11-07-2013, 11:51 AM
Last Post: Geoff Quickfall
  Cannot delete file Les Koller 4 975 11-07-2013, 12:17 AM
Last Post: Les Koller
  Prime feature request Stefan Dröge (Germany) 0 493 11-06-2013, 11:06 AM
Last Post: Stefan Dröge (Germany)
  request M.E. pac for HP-67/97 wallet cover scan Ignacio Sánchez 0 540 11-06-2013, 09:36 AM
Last Post: Ignacio Sánchez Reig
  PRIME: re-format the flash drive to recover the operating system Harold A Climer 2 838 11-06-2013, 12:22 AM
Last Post: Michael de Estrada
  File Format: hpprgm Thomas Chrapkiewicz 6 1,336 10-30-2013, 09:32 PM
Last Post: Thomas Chrapkiewicz

Forum Jump: