Older blog entries for brouhaha (starting at number 79)

Nonpareil release 0.68

Nonpareil now has much better looking LCD displays for the HP-41C and Voyager series calculators. Now instead of single-pixel-wide "stick digits", they have segments that look pretty much like the real thing, thanks to the scaling and compositing features of gdk-pixbuf. The Voyager annunciators are also now implemented.

The .png image files contain an oversized digit/character template, with each segment in a different color. The KML file specifies where the segment tempate is, how big it is, and what colors (RGB) the segments are. At startup, Nonpareil extracts the segments individually, changes their color to black, scales them, and converts the result to alpha channel data for compositing.

Display updates are also faster because display update requests now only invalidate the digits and annunciators that have actually changed, and the expose event handler uses the update region to determine which ones need to be repainted.

Updated the About box. Added some animation and an easter egg.

27 May 2005 (updated 27 May 2005 at 08:18 UTC) »
HP-41CX in Nonpareil

In release 0.67, the HP-41CX is now mostly working. I implemented the basic Phineas chip (Time Module) functionality, though apparently the stopwatch uses the TESTB mode which I haven't put in yet. The clock runs at real time, though it is not initialized from nor does it track the system time. Clock mode and alarms work, though there isn't yet sound support. There are various bug fixes and improvements under the hood.

Much thanks to Chris Roccati and Christophe Gottheimer for their work on making the Phineas chip and bank switching work in NSIM, and Thomas Olesen for doing the same for Nonpareil. I didn't incorporate much of their code due to planned infrastructure changes, but used it quite a bit for reference.

Thomas Olesen has been working on Nonpareil sound support using the SDL library, and Christophe Gottheimer has got the HEPAX module working in NSIM. I'll probably merge those changes in the near future.

Nonpareil - fixed it again

The Nonpareil bugs I introduced last night were easy to find by comparing traces captured with the last stable version against traces captured with the latest code. Fixes are checked into Subversion. I've started integrating Phineas chip support (real-time clock chip used in HP-41C Time Module and in HP-41CX), loosely based on the work of Thomas Olesen and Chris Roccati.

Howard Owen has a slightly earlier release of Nonpareil running on pdaXrom on a Sharp Zaurus C860. He found some trouble loading mod files with the latest code out of Subversion, so I added some debug output for him to try. He has expressed interest in porting to other Zaurus platforms, which use the Qt widget library. I have a Zaurus SL5500 and would love to run Nonpareil on it, but I don't like C++ programming so I'm not motivated to write a Qt-based front end.

Broke Nonpareil good

There's been an item on my Nonpareil TODO list for quite a while to refactor the low-level arithmetic and register operations out of the Nut processor simulation, and share them with the Classic and Woodstock processors. This is desirable because the Nut code turned out to be better organized and cleaner than the others. I finally got around to doing it tonight. I moved the code to src/digit_ops.[ch], and updated proc_{classic,woodstock,nut}.c to use it. Nut still works, but Classic and Woodstock are quite broken at the moment. I guess I should learn the adage ``if it ain't broke, don't fix it''.

I also implemented Nut bank switching in preparation for the HP-41CX, Advantage Module, and the HEPAX module. Did cursory testing with the Advantage module. Trivia of the day: during development HP was planning to package the Advantage Module in transparent plastic and call the ``Clear Advantage'', but clear plastic generally isn't as sturdy and durable as colored plastic, so it didn't meet HP standards.

The simulator now can load HP-41 ROMs from ``.mod'' files, the format Warren Furlow came up with for V41. The ``.mod'' file format is pretty good for representing HP-41 modules, but not so good for other calculators. I'm thinking about coming up with my own compressed-XML module file format for Nonpareil, but also supporting ``.mod''.

It appears that zlib doesn't provide any easy way to set the comment or extension fields of the zlib header. It would be nice to do that for state save and module files so that the ``file'' command could identify them. I could do it by munging the stream as it is written. What I'd really like to do is start the file with a ``#!/usr/bin/nonpareil'' line followed by the gzip-compressed data, so that executing a state save or module file would start Nonpareil automatically. The drawback is that other XML processing tools like xmllint that normally handle gzip-compressed XML files wouldn't be able to make heads or tails of it. I'm considering proposing a standard marker for use in a file that starts with a ``#!'' line to indicate that compressed XML content follows; then I could submit a patch to libxml2 to recognize the marker on input and Do The Right Thing.

Nonpareil 0.66

I started work on a RAM display window for Nonpareil's GUI debugger. The first attempt resulted in a window taller than the screen; I had to learn how to use a GTK viewport to get scrolling capability. Now the window starts out way to small, but at least is resizable. I'll have to figure out how to set the initial size to something reasonable.

Like the register display window, it isn't yet fully functional. Although they both use editable entry boxes for the display, if you edit them the change is not actually written back to the register or memory. And they don't update automatically, so you have to close the window and reopen it to see simulation changes. Still, it's been somewhat useful for debugging.

I'm not happy with the use of the standard GTK+ entry widget. I really want a widget that displays a number using a fixed base and digit count, in a monospaced font (or at least with the characters in fixed column positions), so that the digits in all the registers or RAM locations line up vertically, and there isn't extra empty space at the right side of the widget. Colored highlights for the P and Q pointer positions would also be useful. I'll have to write such a widget myself, and I probably won't get around to it for a while.

Google revealed that Adam Sampson has built a GARstow package for Nonpareil, and was frustrated with SCons. I discussed it with him by email, and all of his problems were really due to inadequacies in the way I used SCons, rather than with SCons per se. For instance, my SConstruct/SConscript files supported a "prefix" configuration option, but not "bindir" and "libdir" for more flexible filesystem layout, nor "DESTDIR" for a virtual filesystem root for installation packaging. Also, doing "scons install" was putting ".sconsign" files into the installation directories, which was resulting in file conflicts between various packages that use SCons.

I expect the same problems would affect almost any packaging system, including my own anticpated effort to offer RPMs for Fedora Core 3 and 4, so I've fixed them today for release 0.66. I added "bindir" and "libdir", as well as "destdir" (note lower case for consistency with other Nonpareil configuration options).

Also, by putting an "SConsignFile()" directive in the SConscript, it will put all of the signature information it uses for dependency analysis and tracking into a single ".sconsign.dblite" database file in the top directory, so it no longer puts .sconsign files into the install directories.

I added caching of the configuration options in "nonpareil.conf" to replace my previous "local.py" configuration file. And a "Help" directive so that "scons -h" will show all of the configuration options with their default and current values. To revert all options to the defaults, you can simply delete the "nonpareil.conf" file from the top directory.

I updated the INSTALL file as well as the credits in the README, added the people from the credits to the About dialog box, and moved the code for the About dialog box into separate about.c and about.h source files.

Thomas Olesen has sent me his patches to get the HP-41CX running, based on earlier modifications to nsim by Chris Roccati. I should have that integrated for the next release.

I sent Maciej Bartosiak email about the possibility of using POSIX threads in place of the glib thread support on MacOS X, and it turns out he'd already done that. He sent me his modified version of proc.c.


Finally squashed a nasty bug. I thought I'd previously managed to fix the calculator state restoration bug, but it turns out that the bug only manifested on 32-bit machines and I was trying to debug it on a 64-bit machine. There was a call to strtoul() that should have been strtoull().

It's unfortunate that the C standard doesn't specify any replacement for those that is based on the actual size of the type (e.g., uint32_t, uint64_t) rather than the weakly defined ``unsigned long'' and ``unsigned long long''. I suppose the correct thing to do would either be to have a configuration test at build time to pick the right one, or to use sscanf() instead, since the C standard does provide size-appropriate format specifier strings in <inttypes.h>. Perhaps I'll add a strtouint64() function in my utility package, based on sscanf().


lcdtest release 1.01 has a new ``dots'' test pattern, and an on-screen help message.


Release 0.63 of Nonpareil now simulates the HP-11C, HP-12C, and HP-15C calculators.

13 May 2005 (updated 13 May 2005 at 05:40 UTC) »
First impression of Eclipse

When I heard that Fedora Core 2 was going to include natively-compiled Eclipse, I was excited since I'd wanted to try Eclipse for quite a while but had never been able to make it work. Unfortunately the native Eclipse didn't actually make it into FC2 or even FC3, but it is part of the forthcoming FC4.

I'm running Fedora Core 4 Test 3 on an Athlon 64 3500+ with 1 GB of RAM, so I thought I'd give the native Eclipse a try, along with CDT for C development. I haven't done much with it yet, but the feature set seems quite nice. I use SCons instead of make, so I wanted to try the SConsBuilder plugin, but there isn't yet a version for Eclipse 3. I installed the Subclipse plugin for use with the Subversion configuration management system, but I haven't yet figured out how to use it.

The big problem is that Eclipse is mind-numbingly slow. Even just right-clicking on a source file takes a long time to bring up a context menu. If it's this slow when natively compiled on an Athlon 64, I can't even imagine what running a non-native version must be like. How can anyone find this useful?

Finally a new release of Nonpareil

I released version 0.61 of Nonpareil last night. Now it has support for the HP-16C "Computer Scientist" calculator, and due to bug fixes the HP-34C, HP-37E, HP-38E, and HP-38C finally work correctly.

The big news is that there is finally support for saving and restoring the calculator state, so there is finally "Continuous Memory", even for calculators that didn't actually have that as a hardware feature.

The state save uses compressed XML files thanks to libxml2.

This is also the first release that builds with SCons instead of make.

I had to solve a tricky memory corruption bug to get this release ready. One of my data structures was being corrupted. I used GDB to set a hardware watchpoint on a field of the structure, but the watchpoint never tripped, even though the field did get changed! Possibly a problem with 64-bit GDB in Fedora Core 4 test 2.

Nonpareil ad nauseum

I've been fixing bugs in Nonpareil, and improving the SCons build files I use instead of Makefiles.

I've finally got the 14/15-digit display mode of the Woodstock processor (ACT) working correctly, as far as I can tell. That's used in the HP-19C, HP-67, and the HP-9x printing desktop calculators. I'm trying to get the HP-67 running.

The HP-67 normally uses the "KEYS -> A" instruction to read the keyboard, then does fairly complicated stuff to the value in A to determine where to branch. Earlier calculators just used "KEYS -> ROM", which directly replace the low eight bits of the program counter with the hardware keycode (not the same as the user-visible keycode). I was not able to figure out what the hardware keycodes should be from Tony Duell's reverse-engineered schematics, which is not his fault, but rather because I don't have enough documentation on the ACT. I tried to figure out what they should be by studying a microcode disassembly, and by trial and error, but it was very slow progress and it wasn't easy to figure out the correct codes because many incorrect codes map to normal operations. I finally decided that the best thing to do was to write a test program to run on the actual calculator. I don't currently have a means to do that, but I wrote the program and tested it on the simulator. As each key is pressed, it displays the hardware keycode as a three-digit octal number.

Bernhard Engl build a EPROM-based ROM emulator and has it interfaced to an HP-67 in place of the normal ROM chips, so I sent him my code. He burned it into EPROMs and ran it, and we were both surprised that it worked correctly the first time. He was able to determine all of the hardware keycodes and email them to me, and when I plugged them into the KML file and fixed a few minor bugs, the HP-67 started partially working in simulation. Bernhard says that he'll send me some photos of his hardware setup.

I've studied a lot of disassembled Woodstock code, but that's the first Woodstock code I've written. Just reading and studying the code others have written before wasn't enough to give me a full appreciation for how challenging it can be, due to the non-orthagonality of the registers. I'm thinking about writing a game in microcode to get more practice. Too bad most people will never be able to play it except on the simulator.

Currently the HP-67 simulation works until you do anything that requires the calculator to search for a label in program memory. The search routine enters an infinite loop. The loop is entered with P=1, and each iteration through the loop P gets incremented by 2. The maximum value of P is 13, beyond which it wraps to zero, so the next loop value after 13 is 1. However, the test for the end of the loop tests for P=0. An engineering spec for the ACT states that when P wraps on either an increment or decrement, the position "disappears" for one cycle. I suspect that this vague description is wrong, and that in this particular case P happens to have a transient value of 0 at the time the comparison is made. It's possible that this behavior is different than that of the earliest ACT chips; it is known that some revisions of the HP-67 and HP-97 microcode are not compatible with all ACT chips, and perhaps this could be why.

Typical SCons "Builders" take one source file and produce one target file. To define a rule that produces multiple target files, it is necessary to write an "Emitter". As part of the Nonpareil build process, the uasm microassembler gets built, then uasm is used to assemble microcode for several calculator models. Although it's not strictly necessary, I want the assembly to result in listing files as well as object files. I tried to write an Emitter for that months ago, based on the examples in the SCons documentation, and didn't get very far. Now that I know a tiny bit more Python, I hacked on that a bit more, and now it's basically working. The remaining problem is that I want the listing files to go into the obj subdirectory where the object files go, but it's actually creating another obj directory under that for them, so that they are in paths like obj/obj/hp45.lst.

It turns out that I'm not the only person that has been surprised that SCons doesn't come with good support for building source code distribution tarballs. Only recently this has come up on the scons-users mailing list, and Paul Davis posted a nice source tarball Builder. I tried to get it working with the Nonpareil SConstruct and SConscript files, and get an error I don't understand. So I created a simpler test case, and it works for that. Seems to be something about the way my hierarchy works. I hope to have it figured out soon, since I want to package a new source release.

8 May 2005 (updated 8 May 2005 at 23:06 UTC) »

This morning I was trying to figure out why Nonpareil isn't coming anywhere close to simulating the HP-67 correctly. It comes up with a single decimal point lit in the display, and the only visible responses to the keyboard are for the decimal point to move to another position or disappear.

So I captured an execution trace from the simulator, and started studying it. Almost immediately, I found that they are doing a ``DELAYED ROM SELECT'' instruction preceding a ``A -> ROM'' instruction.

On the real hardware, I don't know whether DELAYED ROM SELECT is only delayed by one instruction, or whether it is delayed until the next branch. When I wrote the Woodstock CPU code, I implemented it as being delayed until the next branch. But I forgot to handle it with the ``GOTO KEYS'' and ``A -> ROM'' instructions, which are computed branches based on the keycode and A register, respectively.

I also determined that opcode 0120 octal is almost certainly the ``KEYS -> A'' instruction.

Adding KEYS->A and fixing the DELAYED ROM SELECT did not fix the HP-67 problem. But it did fix the problems with the HP-34C, HP-37E, HP-38E, and HP-38C, all of which now seem to work correctly!

70 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!