24 May 2005 brouhaha   » (Journeyer)

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.

Latest blog entries     Older blog 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!