Strange problem with Nov32 / Hepax

[giastar]

I use my Nov-32 with Hepax to store Focal programs, executing them within Hepax. I've been working in this way for several months without problems.

Last night I allowed the batteries to run down (forgot I'd executed "ON"). This morning the batteries were flat. The Hepax contents were all there thanks to the Nov-32. I cleared the HP41 memory to be safe, and started work...

Now the strange bit: The Focal programs in Hepax cannot be directly executed as before. They have not been corrupted: if I COPY to main memory they run as expected. But when I attempt to run a program in Hepax it returns immediately, without any error message but without executing any of the program. BUT, if I GTO that program and press R/S it runs correctly!

It seems to be only the ability to execute Hepax programs directly that has been affected. This applies both to my original programs and a test program I just created and saved to Hepax. Any ideas, before I resort to reprogramming the Nov32 from scratch?

[giastar]

More info:

I have tried the Nov32 in a different HP41, with the same results, so the problem appears to be corruption of the Nov32 contents.

If I manually execute a program in Hepax memory using GTO xx followed by R/S then programmable key assignments to labels in that program don't work but show an XROM code, e.g. XROM 63,12.

[Diego Diaz]

Hi,

Certainly, this is a weird behavior. Not so strange due to the fact that the system has been brought to an unpowered state in very irregular way: i.e. leaving the batteries runnig out overnight.

NoV-32 is not designed to face such situation and, although not harmful to the hardware itself, it may well have led NoV-32's RAM contents to a corrupted state.

With this in mind, I'm affraid that your better choice is to erase NoV-32's RAM pages and reload the programs. Sorry for the bad news.

As you're handling FOCAL programs you could move them to main RAM and use a card reader to avoid re-typing.

Please let us know about the results.

Cheers.

Diego.

[giastar]

Thanks, Diego. I'll try this later. No time at the moment as I'm working to a deadline, and fortunately the Focal programs I'm using for this job will fit (just!) in main memory.

This is indirectly related to the fact that Nov32 doesn't like the auto-off function of the HP41. So I normally manually execute "ON" to be safe - this time I forgot to switch off and the charger wasn't plugged in either. Ooops.

Is there any way to support auto-off or is this a fundamental limitation of the HP41's expansion bus?

Peter

[Diego Diaz]

Hi again,

I'll need a while to check my code database, but I think I fixed the auto OFF bug, both for NoVRAM and NoV-32!! At least I'm positive I did for the NoVRAM code, but I may have forgotten updating the NoV-32 code, oops sorry if this was the case...

For the records, this was not a limitation of the 41 I/O interface whatsoever, on the contrary, PWO and SYNC lines perfectly define the HP-41 power state in any case. However, as NoV's are designed to minimize power drain, I leave PIC processor into sleep as soon as PWO goes low, thus, handling the SYNC line to detect Auto OFF, msut be done via interrupt to allow PIC "wake-up".

It took a nice code compression effort to make enough room for the interrupt handling routine that allows such handling. I finally got the time to rethink the power management and write the appropriate line by '05 3rd quarter, while I was dealing with NoV-32 developement.

In any case, you won't need to execute "ON", should your 41 goes to Auto OFF, just unplug NoV-32, plug it again and turn your calc ON. It won't lose a single bit, granted.

Best wishes.

Diego.

[giastar]

> I think I fixed the auto OFF bug, both for NoVRAM and NoV-32!!

That's excellent news! This was the only problem I had with the otherwise excellent Nov32. It's made the HP41 much more useable - no need to mess around with card reader etc except for occasional backups.

Unfortunately the unplug/plug/power-on routine didn't work reliably for me, occasionally resulting in a high-current state in the Nov32 which would pull down the supply and corrupt the HP41 memory. That's why I usually execute ON to be safe. (we discussed this by email a few weeks ago: I'm peter at giastar com.) So support of auto-off is very useful.

I'll download the latest Nov32 firmware before continuing with this. Perhaps you could confirm when/whether the auto-off fix is included in the Nov32 firmware - I don't mind waiting for this, my NOV32 is still working fine as a non-volatile memory, I just have to COPY any stuff I'm using to main memory first.

Peter

Edited: 27 Jan 2006, 5:13 p.m.

[Howard Owen]

Hi, Diego,

Does the latest Nov32 code have the sleep mode fix? I'm still using the original version I got with the module, and it has the problem with deep sleep on the mainframe.

Regards,

Howard

[Diego Diaz]

Hi,

I've had to dig a bit into my "old versions" directory to find out what happened to the *Auto-OFF bug free* version of "NoV-32-H.asm".

Finally I manage to re-create the "crime scene" :-)

- I wrote the code for NoV-32 based on NoVRAM (obviously), this code was intended to provide enable/disable features at page (4k) level.

- Then I modified the NoVRAM code to fix Auto-OFF bug.

- Modify the NoV-32 code in the same way

- At this point page enable/disable feature revealed unreliable and I rush to correct that.

- I modified NoV-32 again to allow "block" (16K) swapping... but (here it the point) I did it on the file that wasn't been modified with the code to fix Auto OFF bug... Ouch!!

Please accept my apologise, I'm confident I can rebuild a bug free version for NoV-32 along next week.

Best regards.

Diego.

[giastar]

Ooops! Anyway, it's really good news that auto-off will soon be working on the Nov32. This module has transformed my HP41, which is still the calculator I reach for when I want to do serious work.