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.

while N not 0 do;
    decr N;
    incr X;
end;

Such a loop adds N to X, clearing N in the process. Without the optimizer, this is has time complexity O(N). The optimizer replaces it with a single macro that executes in O(1). This makes the supplied example program that computes Fibonnaci numbers run much faster.

For the next release, I’ve added more sample programs, including an example of a Bare Bones translation of a two-symbol three-state Turing machine busy beaver program. The Bare Bones program demonstrates that Bare Bones can perform any action that can be performed by a Turing machine, proving that Bare Bones is universal.

Brookshear states that Bare Bones is universal by comparing it to a Turing machine, but only actually shows that it can compute two simple functions that are computable by a Turing machine. He states that “researchers have shown that the Bare Bones programming language can be used to express algorithms for computing all the Turing-computable functions,” but unfortunately he does not give any reference to publication of such results.

One way to show that a machine or language is universal is to show that it can emulate a Turing machine, or that any Turing machine program can be translated into a program for the machine or language in question. At first glance it wasn’t obvious that Bare Bones could be universal, because a Bare Bones program can only use a finite number of variables. The key to its universality is that a Bare Bones variable can contain any non-negative integer. An infinitely long one-dimensional Turing machine tape can be represented as three variables: one contains all the symbols to the left of the head, one contains the symbol at the head, and one contains all the symbols to the right of the head. For a turing machine with an alphabet of n symbols, to move the head position right, one must execute these assignments (in pseudo-code, not Bare Bones code):

LEFT := LEFT * n + HEAD;

HEAD := RIGHT mod n;

RIGHT := RIGHT / n;

Moving the head position left is done by the same assignments, with LEFT and RIGHT swapped. For a two-symbol Turing machine, the Bare Bones code to move the head position to the right is:

# LEFT := LEFT * 2;
copy LEFT to TEMP;
while TEMP not 0 do;
    incr LEFT;
    decr TEMP;
end;

# LEFT := LEFT + HEAD;
while HEAD not 0 do;
    incr LEFT;
    decr HEAD;
end;

# HEAD := RIGHT mod 2;
# RIGHT := RIGHT / 2;
copy RIGHT to TEMP;
clear RIGHT;
copy TEMP to HEAD;
decr TEMP;
while TEMP not 0 do;
    incr RIGHT;
    decr TEMP;
    copy TEMP to HEAD;
    decr TEMP;
end;

That’s the most complicated portion of the Turing machine interpreter. I might write up an explanation of the rest at some future date. For now, anyone interested in the details can look at the example Bare Bones source code for a simulation of a three-state Turing Machine busy beaver program: tm_busy_beaver_3.bb.

Note that it is not currently practical to to use my Bare Bones interpreter to simulate a Turing machine with a long tape, because the division/modulus code used to shift the tape takes O(n) operations, where n is the number of bits to the right of (or left of) the head. To make that reasonably efficient, I’ll need to extend the interpreter’s optimizer, and make the interpreter use bignum arithmetic (probably using the GMP library). Once that’s done, it would be nice to try running a universal Turing machine in Bare Bones. The smallest two-symbol UTM I’ve heard of uses 22 states.

• clear var; — set a variable to zero
• incr var; — increment a variable
• decr var; — decrement a variable, unless it is already zero
• while var not 0 do; <statement list> end; — loop
• copy var1 to var2; — introduced for convenience

Bare Bones is universal, in that it can compute any function that can be computed by a Turing machine. In fact, it would be universal even without the clear and copy statements, as those can be synthesized from the remaining statements. Needless to say, writing programs in this language can be tricky. I wasn’t confident that the programs I wrote for the homework exercises were correct, and decided to write a Bare Bones interpreter to check them. It’s released under the GPLv3.

I wrote example Bare Bones programs to compute factorials and fibonacci numbers, and they are included with the interpreter.

Photos and the source code to his enhanced version are available from his web site.

lcdtest 1.04 should work with any keyboard layout that the host system supports, assuming that SDL’s Unicode mapping is done properly.

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.