I’m using the open source FatFs code to implement the FAT filesystem.  It’s configured to work with two “drives”, the internal SPI FRAM chip in the DIY4, and the SD card.  I used the SD interface code from the “generic” example, with only minor changes necessary.

I still have to write a -41 microcode ROM to provide the equivalent of the HP-IL module’s mass storage commands, but talking to the SD card rather than HP-IL.

I analyzed bugs in the microcode of the HP-41 and card reader, reverse-engineered portions of the Extended I/O ROM, and made a lot of progress on the DIY4 calculator which runs the original HP-41 microcode.

I may do a little more today, but don’t expect to have any additional significant progress to report by the end of the day, so I am declaring the project a success.  It will remain to be seen whether it is judged worthy of a prize, but regardless of that, I am happy with what I’ve accomplished. I wish I could get this much accomplished in my spare time every month!

My first attempt at making the PWM work failed because I had overlooked a relatively obscure note in the EFM32G reference manual which observed that the REP0 (repeat 0) register needs to contain a non-zero value, even though it is not counting down in the PWM mode. Once I added code to initialize REP0 to 1 (or any non-zero value), I could read the timer value in software, and verify that it counts down, and when it underflows, reloads the appropriate value from the COMP0 register (which sets the PWM period). However, the actual PWM pin was never changing.

I spent a lot of time studying the LETIMER chapter of the reference manual, and corrected several bugs in my code, but still didn’t get the pin to change. Finally I looked at the LETIMER application note. The text of the application note didn’t help much, but I noticed that their overly complicated example code was initializing REP1 to a non-zero value, while the reference manual had only indicated that REP1 was used in some other auto-reload mode and did not indicate that it was used or necessary for PWM.

I added a few lines to initialize REP1 to 1, and the PWM started working.  Now I can adjust the display contrast, from too light to too dark, in 16 steps. Fortunately there are midrange values that are somewhat reasonable.

Both the reference manual and the application note could certainly use some more thorough explanation of the requirements to make PWM mode work.

For the keyboard, I program the scan lines as open-drain outputs with pullups, and the return lines as inputs with pullups.  What I found was that my keyboard scan code was reliable at 1 MHz, but had subtle problems at 7 MHz and not-so-subtle problems at 14 MHz and higher.

What I figured out with Richard Ottosen’s help is that because I’m using open-drain outputs for the scan lines, when I stop driving one scan line low, and start driving the next, the first line takes longer than I anticipated to get pulled high.  It needs to rise from very close to 0V to 0.7 Vdd, 2.17V, before I drive the next scan line low.

The data sheet gives a typical pullup value of 40 Kohms, but doesn’t specify a minimum or maximum. To be conservative, we’ll assume a maximum of 100 Kohms. If we also assume that the total capacitance on the line is 10 pF, that gives a time constant of 1 us.  To reach 3/4 of Vdd will require about 1.4 time constants, so I need to delay 1.4 us between releasing one scan line and driving the next.  At 14 MHz that is about 20 instructions, so for now I’ve put in 20 NOP instructions. That fixed both the obvious keyboard scan problems, and a not-so-obvious problem where the ON key would terminate a running program, but the R/S key would not.

A better solution might be upon releasing a scan line, to briefly change the pin mode from open drain with pullup to totem pole actively driven high, then back again. That would pull up the line fast enough that it would be essentially processor speed independent.

In the course of testing this we also made some other observations:

• The bit-banging SPI for the FRAM works at 28 MHz with no additional delays required.
• The FRAM port configuration doesn’t raise the deep sleep mode current.
• Some of the other recent keyboard scanning changes, namely not raising the processor speed unless at least one key is pressed, reduces the deep sleep mode current from 20 uA to 10 uA.

This is on the DIYRPN 4 hardware, which is a calculator using an Energy Micro EFM32G280F128 microcontroller based on an ARM Cortex-M3 core.  The calculator is running a microcode-level simulation of an HP-41C.  At a CPU clock of approximately 14 MHz (using an uncalibrated internal RC oscillator), it runs roughly 14 times faster than an actual HP-41C. There is a lot of room for optimization of the simulator code.  It is also possible to run the chip at 21 MHz or 28 MHz, though that introduces a wait state for the internal flash memory.

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.

Compared to other recent HP calculators, the 35s returns to a double-wide ENTER key in the row immediately above the digits, keys in straight rows, and shift keys in highly contrasting colors. The functionality appears to be improved over the 33s, particularly in that the limit on the number of storage registers has been lifted.

Given that there have been hoax calculator introductions by HP calculator fans before, I was skeptical at first, but there is a CE declaration of conformity on the HP site, so this one is real.

[h/t ssf, Gerson, and Hugh on the MoHPC forum]