HP Forums

Hi, all;

Forgive me posting again, I´ll do that only this second time. I thought I'd have a few replies, but neither I got an e-mail about the subject. I guess the actual NoV32 users/owners did not read this, so I decided to keep it up for a couple of days. Hope you don't mind...

I would like to know who of the current Clonix/NoVRAM/NoV32 owners are interested on sharing knowledge, experiences and curiosities. I know that Diego Diaz is THE guy to start such thread/issue, but it seems to me that he was somehow busy with his own activities that he had no time to answer to some of my last questions. As you remember, he added a post a few days ago telling he’d be out till the end of May.

I myself have a particular doubt. I did not succeed configuring my NoV32 to run HEPAX emulation with the full 32KRAM available. The best I could do was a NoVRAM-like configuration: HEPAX emulation running with 16KRAM. Interesting fact: as expected, when the calculator is first turned ON after inserting a NoV32, the HEPAX emulation goes to port #8. After turning the HP41C/CV (CX) off and on again, it locates itself in port #5 (#6), if no extra module is inserted. I have this behavior in both modules, but I still did not find the way to use the full 32KRAM available in the NoV32.

Any clues? My best guess would be using a standard .HEX file from someone that succeeded doing so...

BTW: although the CLONIX/NoVRAM/NoV32 are new designs, they all belong to the HP41 'family'. So, I see no trouble posting about them here. Is that O.K. for you all?

Cheers.

Luiz (Brazil)

Hi Luiz,
unfortunately I have no NoV32, only Clonix & NoVRAM, so I cannot be of help.

All the best,
Massimo

Hi Luiz,

Yes, just like Massimo, I'm just a simple Clonix+NovRam user!

But I'd love to discuss issues under the 24KB level :-))

Have a nice day!

Etienne

Luis,

Did you try writing the bits at 4100H?

Doug

Hi Doug, Etienne, Massimo; thank you all for answering!

I followed the main recipe: erased the entire NoV32 memory with the NoVclr32.HEX; procedure returned O.K. Then I used NOV-32-H.EXE to generate the .HEX file. The first thing that called my attention was that the NOV-32-H.EXE main window had a small dialoge input asking for any two ROM images at the remaing 8K, and I simply answered with [ESC], so they were marked [void]. I'm not sure if this is the correct procedure.

Then I noticed that ICPROG proceeded with recording the generated .HEX file, but I remember that it gave the message of recording 16Kwords; maybe the HEPAX emulation. After the procedure finished OK, I noticed that HEPROOM returned the equivalent to 16KRAM only (something closed to 2600). The first step was to execute HEXEDIT and verify position 4100. There it was: 00F instead of 0FF. I keyed 0FF in and [BST] to check if it was there. O.K., position 4100 now has 0FF instead of 00F.

Turned the HP41CV off and on... What the h... It does not turn on. I had to press and hold [CLx] while pressing [ON] a few times till MEMORY LOST came to the rescue. No MEMORY LOST! Instead, CLX appeared at the left of the LCD (??!!??). Well, the HP41CV is finally turned ON and I could check postion 4100 again. Surprise: 00F, not the 0FF I wrote before. This time I wrote 0FF, resumed HEXEDIT and performed HEPROOM prior to turn the HP41CV off and on again. It froze! Had to remove batteries this time.

Then I decided to ask Diego for directions, but it seems to me he was already setting his stuff up for his travel: no answer.

What I have in mind is simply testing a suitable, working .HEX file, must check for the proper name in this case. For CLONIX it is CLONIX6P.HEX, I guess that it must have a similar name for the NoV32 module. Unfortunately I allowed the software to overwrite the original .HEX file that I had from the first installation. So I might try to recover it from the original zipped files, but I decided to post about this and ask for suggestions, maybe I did something wrong and did not realize. Is there a chance that you have a working .HEX file for the NoV32 that allows accessing the full 32KRAM?

Thanks again for your interest, guys.

Cheers.

Luiz (Brazil)

Edited: 11 Apr 2006, 1:32 a.m.

Hi Luiz,

I'm in a gap between flights, (will leave tomorrow afternoon...) and will be "dis-connected" form a while...

Currently there is no way to make a NoV-32 "see" its whole 32K RAM area as a single block from "H'8000" to "H'FFFF".

Tha hardware is ok with the idea and was in fact designed with this possibility in mind, but there're still some SW issues to make it work reliabily.

Therefore the 32K RAM area is splitted into two swappable 16K blocks. The swapping procedure is, (as you probably know already) based on the bit 0 at address "H'4100". Only bit 0 is meaningful, if it's 0 then chip 0 is enabled... if it's 1... well... you know... ;-)

My apologise for the unsual delay... hopefully I will get back to my usual responsive status before summer.

Best regards...

Diego.

Hi Diego,

I also have a question:

Is there a chance to use all 4 banks with a Clonix?

The Clonix6p prog only offers bank 1 or 2,

but I could need four banks, and maybe even address block #4000 .

Is there a manual workaround to create a .HEX file

where 4 ROM pages are on the same address, but different banks?

Does the Clonix firmware support four banks at all?

Best Regards

Raymond

Yes, maybe the question is somewhat special,

but the project I'm working on is special, too;-)

Hey Diego, thank you so much!

O.K., I got it. Sorry if I misunderstood the whole procedure...

When I read about the swapping procedure in the NoV32 manual, I wrongly considered the first port map (Page 2, under 'NoV32 On-Line RAM Mapping') as the actual memory map, so I based all my reasoning on it. In fact, I understood that the overlapped mode was not yet implemented, and based on what you wrote now, it is.

To be honest, I see three big advantages on that:
1) we can use two separate, 'swappable' blocks of RAM, something like the primary and secondary registers in the HP67/97 (cool comparison, ahn?);
2) it is possible to load and configure two extra ROM images (pages #C and #D) and use the NoV32 capability in its full extent; and
3) an additional module can be plugged in the upper port, maybe the card reader.

Thanks again. I'll proceed with the new configuration and let you all know about it ASAP.

Cheers and thanks again, Diego. And thank you all who participated.

Luiz (Brazil)

Edited: 11 Apr 2006, 4:47 p.m.

Hi, All;

After reading Diego's answer I repeated the whole procedure and took the time to test possibilities. If you follow me, please...

Set a point in time: NoV32 configured as Advanced HEPAX emulator (HEPAX 1D ROM image) and inserted in an HP41CV. HEXEDIT with address 5000h briefly returns HEPAX ROM, pages #6 and #7 are free, pages #8 to #B show HEPAX headers O.K., pages #C and #D have CCD ROM. All's well, CAT'2 works fine, HEPROOM returns 2,610.0000 to the X-register, as expected.

HEXEDIT with address 4100h returns

4100 00F _ _ _

20F

After that I tried many combinations, and one of them showed me something strange. I wrote 2F0 at address 4100h and HEPDIR returned

H:NO FILESYS

Although Diego mentioned that bit #9 is the only one meaningfull, I read again the NoV-32 documentation and decided to try the overlapped configuration. So I wrote 3F0 at address 4100h (i.e.: (b4 to b7)=1, b8=1, b9=1) and the calculator froze. After removing batteries and placing them back, the calculator starts to behave weirdly, even after complete MEMORY LOST a few times. I had to remove the NoV32 and let both calculator and module resting for a while. Tested it again. I tried many values in the range 0xx, 1xx (not valid) and 2xx, and the NoV32 worked fine, although only the four pages in lower 16KRAM block seemed to be addressable. Some values I tested the range 3xx froze the calculator (It's written in the NoV32 documentation that the overlapped mode was not available, but I decided to run the risk).

Well, I know Diego is out till the end of May, so I'll try a few other configurations in the meanwhile. If any of the NoV32 owners/users has a similar configuration (meaning Advanced HEPAX emulation, using or not using the two remaining ROM addresses) and wants to share with me a copy of the .HEX files (sounds spacey...) available at the directory created to hold the NoV32 related files, I'd appreciate a lot.

If I have any news I'll let you know.

Cheers.

Luiz (Brazil)

Edited: 13 Apr 2006, 1:32 a.m.

Thanks for your kind words (in the other thread).

I don't own a 41 but I love reading about this stuff. Because I'm not familiar with your kit, I may not be aware of the unspoken stuff that passes between people who are familiar with the subject. With that caveat in mind...

Diego said:

Quote:

---

Only bit 0 is meaningful, if it's 0 then chip 0 is enabled... if it's 1... well... you know... ;-)

---

You read 0x0f from 4100 which means that chip 1 should have been enabled. To subsequently enable chip 0 you'd need to write 0x0e.

Forgive me if this is tangental or irrelevant. My eye was drawn to the discrepancy between Diego's b0 and your b9.

Cameron

Hello, Cameron; thank you for your support and help.

I see what you mean, and I think I based all of my reasoning on Diego's original documentation. Now that you mentioned, it conflicts with what is written in his last post. I think you are right.

In Diego's original documentation, bit #9 @4100h is considered by the NoV32 as a control bit, not bit #0. So, the pattern I believe he used is the following: (consider the regular weight for a bit: rightmost is the lowest, leftmost is the highest)

bit#      9  8  7  6  5  4  3  2  1  0

value     0  0  0  0  0  0  1  1  1  1  ->  00F

RAM/page  -  -  F  E  D  C  B  A  9  8

The eight rightmost bits enable/disable any of the eight RAM blocks, 4KRAM, 10-bit words each, in their corresponding pages. I tested the standard configuration, meaning any value from 000 to 00F, and the related RAM pages behaved accordingly: 002 - only RAM in page #9 active, 00F - all low-numbered four RAM pages active, and all possible conbinations, respecting that page #9 must always be active (NoV32 configuration restriction). Then I tested 20F, meaning:)

bit#    9  8  7  6  5  4  3  2  1  0

value   1  0  0  0  0  0  1  1  1  1  ->  20F

bit#    9  8  7  6  5  4  3  2  1  0

value   1  1  x  x  x  x  x  x  x  x  ->  3xx

I agree with what you wrote, and you see, the contents @4100h are actually a `control word`, right? And based on what I tried so far, I thought Diego followed the standard weight for each bit. And please, if you find any flaw in my reasoning, I`d like very much to read about it. And, of course, this wish of mine extends to the text I post in the other thrad, too. BTW, would you, please, add the link to your HP16C site again? I lost it, cannot remember, sorry...

Best regards and thanks again.

Luiz (Brazil)

Edited: 14 Apr 2006, 12:02 a.m.

Hi Luiz,

Although I don't have a NoVRAM-32, I'm trying to understand it.

I'm guessing that HEPAX is now in ROM at pages 6-7, is that correct? Note, we don't want rom and ram at the same page (Diego mentions crashes in these cases).

Is this the way you understand it?

00F sets NVR 0-3 into 8-B (default at first power)

0FF sets NVR 0-7 into 8-F (Diego above, says this don't work)

20F sets NVR 0-3 into 8-B (which is the same as the default)

3F0 sets NVR 4-7 into 8-B

That's what I'm reading from the docs, possibly 3FF (or 3xx) is not good. Try only 330, 370 and 3F0. So as seeing it now, ram cannot go to pages C-F at all. Then the only six configurations are 003, 007, 00F, 330, 370 and 3F0? Bit 8 is defined differently in the second figure so...

Yes, 4100h is just a signal, there is nothing there, the mldl watches for WROM or FETCH at this address and directs data from/to an internal store. In some respect this is a problem for me as I use page 4 for ram.

Most of fun!
Doug

Edited: 14 Apr 2006, 4:17 a.m.

Hi, Doug; thank you for your interest and your comments!

Let me go with your post 'step-by-step', O.K.?

Quote:

---

Although I don't have a NoVRAM-32, I'm trying to understand it.

---

Quote:

---

I'm guessing that HEPAX is now in ROM at pages 6-7, is that correct?

---

Quote:

---

Note, we don't want rom and ram at the same page (Diego mentions crashes in these cases).

---

Quote:

---

Is this the way you understand it?

00F sets NVR 0-3 into 8-B (default at first power)

---

Quote:

---

0FF sets NVR 0-7 into 8-F (Diego above, says this don't work)

---

Quote:

---

20F sets NVR 0-3 into 8-B (which is the same as the default)

---

Quote:

---

3F0 sets NVR 4-7 into 8-B

---

Quote:

---

That's what I'm reading from the docs, possibly 3FF (or 3xx) is not good. Try only 330, 370 and 3F0. So as seeing it now, ram cannot go to pages C-F at all.

---

Quote:

---

Then the only six configurations are 003, 007, 00F, 330, 370 and 3F0? Bit 8 is defined differently in the second figure so...

---

002 - only page #9

003 - pages #8 and #9

006 - pages #A and #9

007 - Pages #8, #9 and #A

009 - Pages #9 and #B

00B - Pages #8, #9 and #B

00E - Pages #9, #A and #B

00F - Pages #8, #9, #A and #B

If you use the same configurations shown above but starting with 2 instead of 0, you'll get the same results. Also, if you start with either 0X, 1X or 2X, being X in the range 0 to F, you'll get the same results, too. Some configurations starting wit 3 will cause the calculator to crash, others will cause address 4100 being filled with the default 00F. In any way, I remember that after trying some configurations starting with 3, the NoV32 seemed to have its code corrupted: the calculator behaved weirdly and only got back to normal operation with the NoV32 after clearing its memory and loading the .HEX file again (I have done it about five times already).

Quote:

---

Yes, 4100h is just a signal, there is nothing there, the mldl watches for WROM or FETCH at this address and directs data from/to an internal store.

---

Quote:

---

In some respect this is a problem for me as I use page 4 for ram.

---

And yes, it's been a pleasant fun to either write or read about this subject.

Thanks to you all... and hope to read/write more about this.

Cheers.

Luiz (Brazil)

Edited: 15 Apr 2006, 3:35 p.m.