The card reader bug is present in the 1E version of the card reader (and probably 1D), and fixed in the 1G version. I haven’t got a 1D or 1F to check. I discovered the bug around 1981, and I think I saw it mentioned by someone else in the PPC Journal at one point.

With the card reader plugged in, press the key sequence

GTO . EEX 0 0 backspace backspace

What you should see after that is

GTO .1__

If you have the bug, the display rotates so it reads

0      GTO .1

From study of a instruction trace, it appears that the bug is due to the card reader ROM’s I/O service poll routine violating one of the requirements of the mainframe polling code. From the mainframe source code:

All subroutine levels are available except in I/O service entry. If PKSEQ is set then I/O service routines must either preserve three subroutine returns on the subroutine stack or else terminate the partial key sequence.

The CR-1E I/O service poll code uses two levels of subroutines. Perhaps the CR-1G ROM was changed to not need two levels of subroutines, though I haven’t yet disassembled the code to determine what the actual changes are.

For the first half of the product life of the HP-41CV, and the tail end of the product life of the HP-41C, the mainframe ROMs used were the “GFF” ROMs, which fixed most of the serious known bugs of earlier ROMs. Some of those bug fixes upset early synthetic programming fans, such as fixing “bug 2″ which allowed program memory and status registers to be accessed by addresses that wrapped around, and “bug 3″ which allowed altering system flags. Of course, other methods were developed for doing those things without reliance on bug 2 and bug 3.

Around late 1983, the HP-41CV changed to using the “HFF” ROM set. As far as I know, there is no published explanation of the difference between ROM 0 revisions G and H. Aside from the version number and checksum, there are two actual changes, at address range 01c9..01f3, and the single word at 081a. I haven’t figured out the latter, but I’ve discovered what the 01c9 change does.

The HP-41 mainframe ROMs have code to support expansion ROMs using “buffers” of registers allocated in main RAM, just after the key assignments. The first register of a buffer contains two copies of the buffer number, used by an expansion ROM to identify the buffer it owns, and a buffer length which is used to locate the next buffer, or the end of the buffers.

There was a longstanding bug in the mainframe ROMs which would cause a hard lockup if the length of a buffer was mismarked as zero. The code to scan the buffers would sit in a tight loop looking at the same zero-length buffer forever. This situation could easily be caused by buggy synthetic programs. The ON-backspace trick wouldn’t recover from this, because the buffer check happened before the ON-backspace check. Recovery generally requires removing the batteries until the RAM contents are lost.

The code change at 01c9 in the 0H ROM, and also the 0N ROM of the 41CX, fixes this bug! They reversed the order of the tests, so that the ON-backspace test is done before the buffer scan, so that it can avoid the zero-length buffer lockup.

It has been reported that the 41CV with HFF ROMs may have the “buzz mode” of the 41CX (PPCJ v10n9p24), but I don’t have a 41CV with HFF ROMs so I can’t confirm that.

The ability to cross-compile a Windows version has been broken for a while, but now I’ve got it going again, thanks in no small part to Ronald Burkey’s IMCROSS, a package which automates building cross-development environments for Windows and Mac OS X.

I’ve nearly completed the conversion to having each calculator defined by two files, an .ncd (Nonpareil Calculator Definition) file that defines everything about the behavior of the calculator, and an .nui (Nonpareil User Interface) file that defines GUI interface.  The .ncd file is a compressed XML file, while the .nui is a ZIP file containing a .kml file defining the user interface, and a lot of .png files for the calculator background (without buttons or legends), overlay (shifted legends), and buttons.  The intent is that a given calculator model (e.g., 34C) needs only one .ncd file, which would normally never need to be altered, but any number of .nui files that might present different appearances, window sizes, etc.

For the 41C family only, the actual firmware for the mainframe, peripheral, and option ROMs comes from .mod files rather than the .ncd file.

I still need to integrate an NSIS installer builder into the Nonpareil build system.  Some time back, Christoph Giesselink contributed an .nsi file that will serve as the basis.  However, rather than having the details of which calculator models are included and which files they need present in the .nsi file, I want to have the SConstruct generate them from its own data structures and the .ncd and .nui files.

Aside from some bug fixes, there probably won’t actually be that much in the way of new features visible to the user.  There will be support for the 29C and for a 67 without card reader.  Jacques Laporte helped me quite a bit with figuring out how the card reader instructions work, and he has the card reader working in his Java-based simuulator, but I don’t want to hold up the Nonpareil release until I get it working in my simulation code.  I do plan to have it in a future release.  I still don’t have a complete understanding of the ACT processor’s pointer wraparound behavior, but I know how to fake it well enough to avoid the hang in the label search code in the 19C, 29C, 67 and 97.

The Voyager calculators (11C, 12C, 15C, and 16C) will NOT be included in the next Nonpareil release, but will be in a separate add-on package.  This is because the ROM files for the Voyager calculators are not available under a Free Software license, so a package containing them cannot be included in Fedora, Debian, or various other Linux distributions.  By splitting them into a separate package, at least the base Nonpareil package can be accepted into Linux distributions.   I really should have avoided this problem by putting them in a separate add-on package in the first place.

The new release (other than the Voyager add-on package) will be released  under the GPLv3, rather than the GPLv2 that was previously used.

I’m used to new operating system installations wanting a very small amount of personal information from the user. Windows asks for the user’s name and company, though it allows the user to leave the company blank, as would be typical for home users. Fedora Core Linux asks for the users full name (not required) and a username. Neither of these seem very onerous, and the reasons for requesting the user’s name are reasonably clear. It’s less obvious why Microsoft wants a company name, but since you can omit it, I don’t much care.

Mac OS X, on the other hand, requires the user’s full name, postal address, phone number, expected place of use (home, small business, medium business, large business, etc), and industry. It will not allow the user to proceed until this information is entered. I don’t mind entering my name, but I’ll be damned if I’m going to tell my computer any of that other stuff without a very good reason. If I don’t put personally identifying information into a computer, that makes it less likely that the information will be misused or compromised. I’m pretty sure that the C compiler isn’t going to need any of that in order to compile my programs successfully.

The pages requesting the information have a button to view Apple’s privacy policy, which explains that Apple collects the information in order to provide an exceptional user experience. Exceptionally bad, in my opinion. I was put in the position of lying to the computer. I put “n/a” for all the fields that would accept that, and all nines for the ZIP code and phone number. I selected “home” for the place the computer will be used, though I wasn’t very happy about it. I selected “other” for the industry.

Apple shouldn’t force the user to choose between revealing personal information for no good reason, and providing false information. They should allow the user to skip providing the unnecessary information, or better yet, not even attempt to collect it.

There are major changes in progress that are mostly “under the hood.” The released versions of Nonpareil install KML, image, and ROM files in a library directory (or with the Program Files in Windows). There has been no clear distinction made between the files relating to the user interface, and the files that define a calculator model. In fact, the KML files contain both kinds of information.

In the next major release (probably to be numbered 0.90), there is a clean division. The user interface will be defined by “.nui” files (Nonpareil User Interface), which are ZIP files that contain a KML file and a bunch of .png images. Instead of a single image, there are now separate background and overlay images, and separate images for each key. But since they are all bundled together into a .nui file, there is actually less clutter.

The ROM code and the information formerly in the KML file that defined a calculator model (non-UI) will now be in a “.ncd” (Nonpareil Calculator Definition) file.

Generally there will only be a single .ncd file for each model of calculator (e.g., HP-25, HP-38C, HP-41CV, etc.), but there may be any number of .nui files for a model. I am only going to supply one .nui file per model initially, based on the graphics developed by Maciej Bartosiak for the MacOS X port, but it is intended that other people be able to create more relatively easily. Thus people that prefer photorealistic images can create new .nui files to suit.

The Voyager calculators (11C, 12C, 15C, 16C) will be removed from the base “nonpareil” package, and instead will be part of a “nonpareil-voyager” add-on package. This is due to the the Voyager firmware being covered by a non-GPL license, most likely the Creative Commons Attribution-Noncommercial-Sharealike 2.5 license. (The Voyager firmware has never been covered by the GPL or licensed for distribution, despite the fact that most of Nonpareil is covered by the GPL.)

Note that the trunk of the Subversion source code repository is not usable at the moment; in fact, it is rarely expected to be usable. Any time that there is a significant improvement or bug fix to the code, and it is usable, I publish a release. The purpose of allowing anonymous access to the source code repository is so that people can look at the history, or at what’s changing.

There is no change to the actual Nonpareil code.  Nonpareil development continues slowly.  Aside from work and school, I have a higher priority personal project that will probably prevent me from finishing the next major Nonpareil release until spring.

The upcoming release of Nonpareil probably will not have any other new models.  I need to convert to using Maciej’s images for the Classic series, fix the KML files for the Voyager series, figure out a better way for the build system deal with the ROM files, and get the source tarball and Windows cross compilation working again.

I’m considering adding support for SVG (vector-based) illustrations in the future; right now they are all PNG format (raster).

I hope to have a new release ready in time for the HHC 2006 conference in about three weeks. The release will add support for the HP-22 and HP-27 models.

Since non-RPN calculators (even the HP-01 and HP-10) aren’t really consistent with the name Nonpareil, I’ve decided to put them into an optional “downgrade pack”.

I’m not sure whether the TI-57 will make it into the next release, which I’m trying to finish up this month. If not, it will be in the following release.