NoV-32 issue


I am enjoying my new toys like a little kid at X-mas :)
Diego managed to get it to me on time for my 40th birthday and I am overjoyed. After having been glued to the Hepax, CCD and SandBox manuals the last two days, I decided to reconfigure my NoV-32. The module came preconfigured with CCD OS/X, Sandbox and 12K RAM.

I tried to fire up the NOV-32-H.EXE directly from the mini-CD from Diego, but got the following message:

Path/File access error in module NOV-32-H at address 1825:00A8

Then I tried a lot of different things and finally got the program to run if I copied it off the disk and onto the hard drive. It asked for the two pages to be filled with roms and I gave the file names (without extentions and made sure they were also copied to the same location on the HD). On question of confirmation I answered "Y" and the following error message came:

Path/File access error in module NOV-32-H at address 1827:0B93

I then tried to copy all the files to the HD, but then I was back to the program not running and giving me the first error again. I tried then to selectively delete files that didn't seem relevant (like clonix or NoVRam files). The program started but I can't seem to get past error message #2 - that is, on confirmation of the configuration, it crashes.

Any clues as to what I am doing wrong?


Hi, Geir;

It seems to me the midisk has a failure OR the CDROM failed to read (have you tried reading the minidisk in another CDROM unit?). Anyway, if you allow me a suggestion, try downloading the complete NoV32 software from Diego's Clonix page. At least you'll have another set of fresh files to start over.

If I am not wrong, this is the link to the zipped file with a copy of the NOV-32-H file, amongst others.


Luiz (Brazil)

Edited: 20 Oct 2006, 12:27 a.m.


Thanks. That got me quite a bit further. But not quite to the final result. It got through the NoV-32-H.exe and fired up the Mpasmwin.exe (had to copy that one from the minidisc - and also the icprog.exe), but it reported 350 errors. I tried clicking OK nevertheless, and icprog fired up. But, no HEX-file.

My config: Ccd-osx in Page #C (bank 1) and Mlrom in page #D (bank 1). Is there any files that it needs to assemble the NoV-32 that I am missing?


Hi all,

As ususal I'm not at home now, will be back by Oct. 25th... :-(

Geir, although Luiz advice is, as usual, really clever please note I realized few hours before I leave that NoV-32-H.ASM file placed at "" is corrupted!! I haven't got the time to track the problem back to its roots, but definitely the on-line version is not fully operative.

I burned your CD with the working version directly from my Hard Drive. Obviously you are encouraged to spread this working files:

NoV-32-H.asm and


to whomever could be interested in them.

Now please take this steps to try overcome the errors you've depicted above:

Make sure you copy the whole contents of the mini-CD into a directory not too far from root (C:\) This is due to some MS-DOS limitations regarding total path length.

Also make sure to remove the "read-only" mark. Remember that files copied from a CD-ROM (or any non-writable madia for that matter) are copied into the Hard Drive with the "read-only" mark active, thus it's impossible for the configuration utility to overwite the relevant files.

Hope this helps, sorry for the inconveniences

Best regards (now from "rainy" Santander), and happy birthday! ;-)



Goodie! I go the HEX-file produced.

But, ICprog won't write correctly (it fails on verify). According to the Clonix manual less than 5% of the times this will happen, and that I then should try again. I have tried several times and get a fail on verify on different addresses every time. Would this indicate a lo power-capable serial port? It does however erase the module ok. And now trying the module - it works in my 41CX. What's the consequences of a failed verify, then?

Edited: 20 Oct 2006, 5:37 p.m.


I had similar problems on my PC with ICProg in the past. It turned out that the Settings-> Hardware (or F3) I/O Delay is by default set to 10 i think. I increased that to 15-20 and that resolved all my problems with verification. The 'burn' process lasted a bit longer though but you are not doing that too often anyway.


Yepp, it worked when I put the I/O delay at 20. Thank you very much.

Now for a curiosity: Even though I erased the device, loaded the NovClr32.HEX and reprogrammed the module, my FOCAL program was still present in the module(!)

More checking: HEPDIR eturns only 1957 words (supposed to be 2600). Tried to enter 20F in address 4100, it will not take it. I can enter 0FF and 00F but not 20F - for some strange reason.

When I got the module, it was set up with CCD OS/X and Sandbox (total of 3 pages, leaving 12K for RAM). I made a new NOV-32-H.HEX with CCD OS/X (in page C) and MLrom (in page D) - and this should leave 16K for ram (times two, depending on the 9th bit in address 4100 which cannot seem to write). But, the ram is still 12K and the FOCAL program is left in there despite erasing and clearing and verifying both before I reprogram with the said NOV-32-H.HEX.

Edited: 21 Oct 2006, 8:41 p.m.


Ok; Progress and new info:

I manage to flip the blocks by editing address 4100. The correct entry is 020, not 20F as indicated in an earlier thread (spring time).

Now the mystery; the first set of blocks (with 0FF in address 4100) shows the available space as 1957 words. When I flip the blocks (with 020 in address 4100), it shows the correct 2610 words.

Help, I lost 4K in the first block set! I attribute this to the original setting where 3 pages was carved out for module space instead of the usual 2.

Anyone with ideas on how I could reclaim the lost 4K?


First of all, sorry for answering myself here and ranting about an issue that maybe only half of a handfull would care about. But, it is part of the documentation of the NoV-32.

I have now burned a full Clonix 6 page config into the NoV-32, and reburned it with the CCD OS/X + MLrom + RAM config.

It still shows 1957 words when address 4100 is set to 0FFh and 2610 words with address 4100 set to 020h. It's plain weird. Problem with the .HEX file maybe?

If you are interested, take a look at the UC-41 page to find the HEX file in question. I would be grateful if someone would try it out to see if the HEX file is indeed faulty. If it is, I would be even more grateful (even overjoyed) if that someone could send me a valid HEX file with CCD OS/X in page C and MLrom in page D and a full 2*16K RAM that can be flipped.


Hi Luiz,

Please read below about the trouble with files for NoV-32 at "".

I think they must be the source of the troubles you mentioned me during the last months, please ask Geir for a copy of the files required to properly configure NoV-32 modules. He's got them in his mini-CD.

I'm desolated for not having realized of that mistake long before, but sincerely have not idea of what the cause of this error could be.

My apologies for the hours you've spent in pursuit of that "phantom trouble", just hope you've gained a huge expertise on managing your modules and, therefore, this will revert in great advise for the whole enthusiasts community.

Best from Spain to Brazil.



Hi, Diego,

I think they must be the source of the troubles you mentioned me during the last months, please ask Geir for a copy of the files required to properly configure NoV-32 modules. He's got them in his mini-CD.

I need copies too, so I'll ask Geir. Could I put those files up on It might be convenient for other NoV-32 users.




Hi, Diego;

I believe I speak for anyone else when I thank you for all of your hard work bringing us the chance of having such Clonix/NoVRAM/NoV32 and their consequent ability of running extra ROM images in our beloved HP41 systems (cannot help adding a remark to Meindert´s MLDL2000, too...).

And I guess you are correct when you mention that "I've gained a huge expertise on managing your modules", but I´d add that maybe it is not a huge expertise, instead the expertise enough to try helping others facing similar issues when you do not have the chance to answer them quickly... If I can add some valuable info, I'll gladly do that. The least I can do, though! And if the community gained with that, that´s even better.

Please, no need to apologize. You have already done the worst part (engineering the modules), a corrupted file is a small part, even if it is the very pain in the ... Again, if I can help in any way, I am just glad to have the chance.

The interesting part of this all is that I do not remember facing the specific error messages Geir found, so I thought in his case, the files in the disk might be corrupted. In any case, I´ll go ahead and download the new ones (Geir, would you, please, send me a copy of them?) and try them with the NoV32. Maybe I´ll see the two 16KRAM blocks this time... d8^)))) I'll post as soon as I have some news.

Thanks again and best regards.

Luiz (Brazil)


Hi all again,

Now at work, (but back in The Canaries, finally... ;-))

Howard, please feel free to place whichever file you consider useful in whichever page you consider helpful for anyone. This has ever been an open project, and that's the way it should be kept.

Luiz, nothing to add to your always kind words... just thanks again :-)

Geir, please note that the managing of the Non-volatile-RAM areas *has-nothing-to-do* with the configuration utility nor the .HEX file neither...

RAM is managed *exclusively* by HEPAX OS.

The swapping between (16k) "plane 0" and "plane 1" is controlled ONLY by the "Least Singnificant Bit" in H'4100. NoV-32 documentation is not accurate on this point as it was written with the "final RAM handling procedure" in mind, regrettably, this (far more flexible and complex) procedure has not been acomplished yet... my fault :-( ... but it will be for sure... granted!! :-))

If you need to "rescue" one (or more) of the RAM pages and set it back into the HEPAX FILE SYSTEM, just use the CLRAM command from the HEPAX module (refer to HEPAX manual for details). Once you've cleared the corresponding page, switch your calc OFF and ON. HEPAX will find the "extra" RAM, will identify it as available (since it's been "zeroed") and will add the 4K to its FILE SYS automatically.

Certainly, HEPAX is a complex and highly versatile module. NOV-32 isn't simple either... Gaining enough expertising in their combined usage obviously takes a while... so... ENJOY!! ;-)) That's what this is all about! Isn't it?

Cheers from the Canary Islands.


Hope this helps.

Possibly Related Threads...
Thread Author Replies Views Last Post
  Solver issue with HP 17BII - different from 19BII Jeff Kearns 13 1,951 11-28-2013, 02:36 AM
Last Post: Don Shepherd
  HP-41 Clonix&NoV's SW Update. (For the non-Primer's guys out there... :-) Diego Diaz 21 2,823 11-13-2013, 09:00 AM
Last Post: Ángel Martin
  RPL 32 David Hayden 4 989 11-11-2013, 11:34 AM
Last Post: David Hayden
  Another minor Prime hexagesimal issue Jonathan Cameron 1 713 11-08-2013, 02:37 PM
Last Post: Michael de Estrada
  HP Prime Solver Variables Issue Anibal Morones Ruelas 8 1,606 10-19-2013, 09:45 AM
Last Post: Harold A Climer
  Voyager keyboard issue John Richards 2 742 09-27-2013, 07:43 PM
Last Post: John Richards
  Where to the 32-bit version of User Code Utiltiy for HP-41 ? Olivier (Wa) 2 724 09-26-2013, 01:55 AM
Last Post: Olivier (Wa)
  Last HP emulation, 32 & 01 Olivier De Smet 0 501 09-07-2013, 08:27 AM
Last Post: Olivier De Smet
  WP-34S: Little issue with program step indicator Miguel Toro 6 1,141 09-06-2013, 12:45 PM
Last Post: Miguel Toro
  HELP! WP-34S (Flashing Issue) Barry Mead 2 679 07-15-2013, 04:25 AM
Last Post: Marcus von Cube, Germany

Forum Jump: