There’s been an item on my Nonpareil TODO list for quite a while to refactor the low-level arithmetic and register operations out of the Nut processor simulation, and share them with the Classic and Woodstock processors. This is desirable because the Nut code turned out to be better organized and cleaner than the others. I finally got around to doing it tonight. I moved the code to src/digit_ops.[ch], and updated proc_{classic,woodstock,nut}.c to use it. Nut still works, but Classic and Woodstock are quite broken at the moment. I guess I should learn the adage “if it ain’t broke, don’t fix it”.
I also implemented Nut bank switching in preparation for the HP-41CX, Advantage Module, and the HEPAX module. Did cursory testing with the Advantage module. Trivia of the day: during development HP was planning to package the Advantage Module in transparent plastic and call the “Clear Advantage”, but clear plastic generally isn’t as sturdy and durable as colored plastic, so it didn’t meet HP standards.
The simulator now can load HP-41 ROMs from “.mod” files, the format Warren Furlow came up with for V41. The “.mod” file format is pretty good for representing HP-41 modules, but not so good for other calculators. I’m thinking about coming up with my own compressed-XML module file format for Nonpareil, but also supporting “.mod”.
It appears that zlib doesn’t provide any easy way to set the comment or extension fields of the zlib header. It would be nice to do that for state save and module files so that the “file” command could identify them. I could do it by munging the stream as it is written. What I’d really like to do is start the file with a “#!/usr/bin/nonpareil” line followed by the gzip-compressed data, so that executing a state save or module file would start Nonpareil automatically. The drawback is that other XML processing tools like xmllint that normally handle gzip-compressed XML files wouldn’t be able to make heads or tails of it. I’m considering proposing a standard marker for use in a file that starts with a “#!” line to indicate that compressed XML content follows; then I could submit a patch to libxml2 to recognize the marker on input and Do The Right Thing.
Hi,
I’m a longtime Unix geek who learned to program on an HP-41C in 1982. Finding your software was a great delight therefore. I did a port to pdaXrom, which is a debian-like X11 based distro for the Sharp Zaurus clamshell models. These all run some version of a PXA ARM chip at clock speeds around 400Mhz. On my Zaurus SL-C860 development box, I get the following error trying to load the HP41cv.kml file:
root@zaurus|171# nonpareil hp41cv
Unrecognized or inconsistent values in MOD1 file header
fatal error: can’t read object file ‘/usr/share/nonpareil/hp41cv.mod’
The file in question is a link to the actual install location, but replacing it with the real file makes no difference. I’m using a svn pull I did today about 10:00 AM PDT. The code works in each of the following combinations:
Software Version OS/Platform Simulation
===========================================================
0.62 download RHEL4/AMD64 all nut based
0.62 download pdaXrom/Xscale PXA255 ditto
0.67pre (svn) RHEL4/AMD64 ditto
0.67pre (svn) pdaXrom/Xscale PXA255 11c,12c,15c,16c
I realize you are just hacking mod support into the software, and that I might therefore have tickled a transient bug. Then again, maybe there is a binary representation issue with the mod format you were unaware of. I thought it was worth putting in the bug report, just in case.
I have an idea for a “Calculator Construction Kit” that would build on your work. Since you have generalized the placement and function of calculator buttons, I would let users generate their own layouts, mixing and matching functions and appearance alike. This is ripe for all sorts of confusion, so it sounds like it would be fun.
If it turned out to be too tractable, I could add support for TI calculators as well, since there are GPLd microcode emulators avialable for those. That would require abstracting the communication between functional modules in a calculator, so that any keypress could produce a given output, *and* fit into a programming model too.
It’s probably not completely possible, but it might be nice to discover where the limits were, One limitation is my skill as a C++ programmer. (I think this would demand OO programming, and I’d like to use Qt as a toolkit.) I’m also fairly limited as a graphics programmer, so this would be an interesting exercise to see if I would hit a brick wall in my programming skill or in what is actually possible first. The trick there would be to discern the nature of the brick wall after I hit it the first time.
At any event, I’m a fan of your software, and I would kill for your domain name. (So I guess that means we should just correspond for now.
I will in any event be tracking your progress for the port to pdaXrom. I may try a Qt port too, to get it on to some of the other Zaurus platforms, many of which use variations of Qt embedded.
Regards,
Howard Owen