41CL V2 with V3 firmware


Hello. Late last year, I purchased a V2 41CL board that works great. Monte added the EXT-IL+ image to my board with Christoph's permission. When I found out that Monte had released V3, I purchased one and it too works great. After some discussion, Monte re-flashed my V2 board with the latest firmware that I got back last week. When Monte returned my V2 card he emailed me with this information:

The EXT-IL+ is still located where the XXXA mnemonic points.
Don't try to use the actual mnemonic for this image because the database points to an area of memory that doesn't exist on V2 boards. I'll be adding a section on modifying the Image Database to the manual soon, and then you can reprogram the database so that the correct mnemonic actually points to where the image is located on this board.

That will be cool. I've been thinking about this and I will need to compare where module images are stored in flash between the two versions. But, I would think they don't have to be at the same addresses as long as you use the mnemonics in the database. On the other hand, it makes sense that the address locations for the module images be the same for both versions for the sake of compatibility if someone writes software that doesn't use the database.

Can anyone shed more light on this situation as I think it pretty unique.



Dear Gerry,

I use 41CL version-2 with YFNZ-3B but without firmware update from Monte. About image database update I can not help you.

But of course, it is possible to load the final version of EXT-IL+ with HP-IL ( alternatively with USB interface)to a 41CL RAM page. Furthermore than you are able to store this ROM image - and some other which are not includet to 41CL to 41CL FLASH.

For example I stored EXT-IL+ and W&W-RAM-BOX opersting system to 41CL flash pages.

If needed I can send you three own documents, which describing 41CL port configuration, using 41CL version-2 with YFNZ-3B and writing to 41CL FLASH...

Best regards - Christoph


Yes, Christoph, please send the files to me and thank you. Please use the email address schultz[dot]gerald[at]ca[dot]rr[dot]com.



V3 has additional module images but for those already included in V2 there's no address changes in flash between V2 and V3, Monte's always been very conscious about compatibility.

For instance if you use the CLLIB function in the CLUTILS module, it will list/plug any of the images for both revisions (and also for V1, the beta copy).

If you upgrade your YFNS to revision 3B you'll also have to use the IBDM, as it contains the address information for all images. This is used by the PLUGxx functions, transparent to the user so no need to worry about it - unless you want to ADD new images to flash, beyond the ones already included in V3.

Just remember that the IMDB has information about more images than those existing in the V2, so some of them won't work until you add them as well. Have a look at the CL manual, they have a pink background in the listing tables.

Some of the available address in V2 are now used in V3, therefore choose carefully not to add mew images into occupied places used by the IMDB.


The first two revisions of the YFNZ software had the memory address for each image mnemonic hard-coded. As the number of images increased I ran out of room to add new mnemonics. Plus, it was a pain to release a new version with each new batch of images. Hence the idea for an image database.

The database is addressed as a function of the first and last characters of the mnemonic, and each entry contains a nibble that identifies the type of image, three nibbles that point to the starting address of the image, and two bytes that contain the middle two characters of the mnemonic. The structure of the image database can be found in the source code.

At this point I am thinking of writing a few more functions to add to a YFNZ+ that can be optionally loaded when more than the base YFNZ is needed. At this point I am thinking of including the following funtions:

DBASRCH: (Database Address Search) search the IMDB for the mnemonic that corresponds to the user-supplied memory address. This function can be used in a function like the MMUCAT function that 'Angel has written in the CLUTILS.

DBSRCH: (Database Search) search the IMDB for the address corresponding to the user-supplied mnemonic. This will tell you if a mnemonic is in use, and where the corresponding image is located in memory.

DBINS: (Database Insert) insert a database entry using the user-supplied mnemonic/type/address information. I am still thinking about this one. Since the IMDB is in Flash this can get a little complicated. I have deliberately kept the Flash sector where the IMDB resides empty until now, to simplify the process, but I am also thinking that it might be better to operate on a copy of the IMDB in RAM (probably held in the Y-function buffer area) and then require the user to explicitly write the new IMDB back to Flash.

DBBUFR: (Database buffer) copy the IMDB to the RAM buffer in preparation for modification.

DBUPD: (Database update) copy the new IMDB in RAM back to Flash.

I set the IMDB up so that any memory address can be specified - Flash or RAM, in anticipation that users might be customizing their machine. I hope that I have anticipated the variout ways that it might be used beyond just the PLUG functions.



Having DBINS will be a godsend - I spent more than 30 minutes doing just a couple of additions to my copy of the IMDB, a tricky and attention-heavy task.

Copying it into the buffer area to make the changes and then flashing it back is a good approach - I'll need to free-up the sector again though, as I had used it for a few additional ROM images.

Will also be nice to have a way to test the additions/changes with the IMDB still in sRAM, to make sure it works as intended before re-flashing it.

My function ADRID is equivalent to your proposed DBSRCH: it searches for the mnemonic (or ROM CL_ID) matching the address in Alpha. It doesn't use the IMDB at all, but a look-up table in the CLUTILS module, (in bank-2 for the POWERCL module) - so it works on both V2 and V3 revision CL systems.

How do you envision adding the new functions to the system, as an add-on ROM? The FAT in YFNS is full, that's why I wonder.



It will have to be a new add-on ROM. I figure this isn't too big a deal because it doesn't really need to be loaded all the time.

I'll have to think about providing a way to verify the changes before writing the database back to Flash. I'm not sure what is the best way to do this, because the location of the database is hard-coded in the PLUG functions.


I've been thinking about some sort of checksum function for the HP-41CL; this would be quite handy for verifying that blocks of code have the content that they are supposed to have. It would be useful when flashing (both before and after the flash operation), and also in conjunction with YIMP and YEXP.

I've even done a bit of research into checksum algorithms, but since I have done no assembly programming for the NUT/NEWT I suspect that I'll never get any further on this :-)


The last byte (actually 10 bits) of every image is reserved for a checksum. Unfortunately only the Service Module actually verifies the checksum for a plugged-in module. In addition, many of the more recent images do not include the correct checksum anyway.

I have also thought about this issue in the past. I suppose it would be fairly easy to extract the checksum algorithm from the Service Module and include it as a separate function. The problem then becomes what to do about all of the images "out in the wild" that do not contain a correct checksum... I would hate to have to go through all of the images myself and modify them with the correct checksum, let alone regenerate the entire Flash image for any future boards. But we'll see. I have also thought about doing something more robust, like a CRC for entire Flash sectors. When I get a request to upgrade the Flash for someone it is a royal pain in the rear to go through and verify every sector over the JTAG port, and having a built-in function to generate the CRC for a sector might be an easier way to verify contents.


I for one am to blame here, as hardly any of my modules have the correct checksum - too many edits and too frequently made, I guess..

The algorithm is implemented in several functions, like CHKROM in the HP-IL Development. My favorite implementation is PGSUM, in the TOOLBOX4 - which will calculate the checksum and will write it into the last word (or attempt to if not sRAM). Another one also exists in the BLDROM or DISASM, I think.

However the check I was referring to on the IMDB changes is not related to the actual checksum, but to the valid functionality instead. Food for thought, interesting things to mill over...

Edited: 25 June 2012, 4:55 p.m.


Hmmm... I have to admit that I didn't even consider the possibility that there might be some sort of checksum functions in various modules.

However, I think it might be useful to have a CL-specific checksum mechanism that generates a checksum across a range of bytes. The call signature could be similar to that of YEXP and YIMP: supply a starting address and word count in the alpha register. The return value should (probably) be in the X register, as the contents of the alpha register might be useful (as input to YEXP, for example :-)

Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 808 12-10-2013, 11:37 PM
Last Post: Les Bell
  Strange Battery Icon during updaate of Prime Firmware. Harold A Climer 7 1,026 12-05-2013, 04:40 PM
Last Post: Michael de Estrada
  How to update PRIME Firmware using Files on PC Harold A Climer 2 593 12-04-2013, 12:05 PM
Last Post: Erwin Ried
  HP-41CL setup troubleshooting Xavier A. (Brazil) 2 560 12-02-2013, 06:29 AM
Last Post: Xavier A. (Brazil)
  New firmware for HP 39gII Mic 6 799 11-26-2013, 06:23 PM
Last Post: DeboT
  Another wish for next Prime firmware release Jose Gonzalez Divasson 0 313 11-21-2013, 06:55 AM
Last Post: Jose Gonzalez Divasson
  HP-Prime firmware update on a Mac Javier Goizueta 5 742 11-15-2013, 10:52 AM
Last Post: Javier Goizueta
  [41CL] New Extra Functions version Monte Dalrymple 0 328 11-08-2013, 04:32 PM
Last Post: Monte Dalrymple
  [hp-prime] new firmware coming soon? CompSystems 1 382 11-08-2013, 01:41 AM
Last Post: Mic
  I just installed a firmware update for my Prime Michael de Estrada 2 505 10-30-2013, 05:29 PM
Last Post: Michael de Estrada

Forum Jump: