In fact, FSK modulation is almost trivial, so I had the encoder written in less than an hour.

For decode, I decided to use the Goertzel algorithm, which is a simplified DFT that only looks for a single frequency.  I’ve used the Goertzel algorithm before on fixed-point DSP processors. There are app notes on using it for DTMF detection.  For FSK demodulation, I just use two Goertzels, one for the space frequency and one for the mark frequency.  The audio samples are dealt with in windows that are a fraction of a bit time, and the levels indicated by the two Goertzels are compared to decide which frequency predominates in that window.

Implementing the decoder program took a few hours last night and a few hours today.  It’s now basically working, at least for the perfectly sinusoidal waveforms generated by my encoder.  I still need to test it on some real tapes.

I’m currently using an 8 kHz sample rate for my audio files, although the encoder can be told to use a higher sample rate if desired, and the decoder will work with whatever sample rate the audio file uses.  Since the FSK frequencies are 1200 Hz and 2400 Hz, there should be no advantage to using a sample rate higher than 8 kHz.

I’m currently using libsndfile to read and write audio files.  I’d like to also use PortAudio to support direct access to the audio hardware, but I haven’t yet tried that.  While I’m doing the development on Linux, in principle the programs should work if compiled on Windows or MacOS.

I’ll release the programs under the GPLv3 license when I’ve verified that they work reasonably well.

I spent over an hour trying to figure out why libsndfile was claiming that it couldn’t recognize the format of a perfectly good .wav file.

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.

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.

1. GNOME 3 was designed by idiots for idiots.  They’ve tried to make it completely drool-proof, and in the process made it unusable by anyone with half a clue.  Use xfce instead.
2. To make suspend work on 2.6.35 kernel (or newer?): put acpi_sleep=nonvs on kernel command line.  Necessary for many laptops, but not all.  Definitely necessary on the Sony VPCEB17FX.  https://bugzilla.kernel.org/show_bug.cgi?id=16396 https://bugzilla.redhat.com/show_bug.cgi?id=641789
3. To find the UUIDs of your partitions: blkid
4. To display the LUKS header of an encrypted partition: cryptsetup luksDump /dev/sda6
5. To boot a Fedora live CD such that it all gets loaded into RAM, and the CD is ejected:  add live_ram to the kernel command line.