There hasn’t been much to report on Nonpareil development lately. I haven’t had much time to spend on it, but I have made some progress. Most notably:
I came up with a scheme to fake the Woodstock pointer wrap behavior well enough that the HP-29C and HP-67 label search code works. I don’t yet know exactly how the real hardware works, so my hack probably doesn’t match it perfectly. The Woodstock pointer register normally wraps from 13 to 0 if you increment, or from 0 to 13 if you decrement. So if the pointer is 13 and you increment twice, you’ll get 1. But the label search code expects that starting from 13 the sequence increment, increment, test for zero will actually yield a positive test result, even though the final pointer value is 1.
Anyhow, the good news is that the HP-22, HP-27, HP-29C, and HP-67 (sans card reader) will be supported in the next release of Nonpareil, due out “Real Soon Now”.
The sound code I added so that the 41C family can make its TONEs and BEEPs has been very problematic. It crashed on Windows, and it sounded wrong on Linux. Both turned out to be the same thing. But naturally I spent a lot of time looking for the bug in the wrong places before I finally found it this evening.
On Linux, the tones sounded “choppy”, with audible discontinuities, as if some samples were getting dropped. I thought the problem was scheduling of the callback function that the SDL library uses to get another buffer of audio samples. I spent a lot of time hackiing the sound support up to run in its own thread, which proved not to help at all.
Tweaking the compile-time parameter that controls how many samples SDL requests for each invocation of the callback didn’t help, but it did provide the crucial information I needed to find the real bug. Certain values of that parameter caused the program to crash. Unfortunately when it was run under GDB, the crash always occurred with memory so corrupted that I couldn’t get any useful information.
To make a long story short, it turns out that the “len” parameter passed to the SDL audio callback function is a length in bytes, not a length in samples. I’m using 16-bit samples, so my routine to fill a buffer was overrunning the end of the buffer. It’s amazing that this didn’t cause more obvious problems sooner. Anyhow, since it was adjusting the waveform phase angle based on the wrong sample count, that explained the audible discontinuities as well.
I expect that the sound should work on Windows now, but I haven’t yet tested it.