Posts: 4,027
Threads: 172
Joined: Aug 2005
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)
Posts: 882
Threads: 23
Joined: Jan 2005
Hi Luiz, unfortunately I have no NoV32, only Clonix & NoVRAM, so I cannot be of help.
All the best, Massimo
Posts: 464
Threads: 10
Joined: Jan 2005
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
Posts: 41
Threads: 0
Joined: Jan 1970
Luis,
Did you try writing the bits at 4100H?
Doug
Posts: 4,027
Threads: 172
Joined: Aug 2005
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.
Posts: 774
Threads: 93
Joined: Aug 2005
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.
Posts: 1,841
Threads: 54
Joined: Jul 2005
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;-)
Posts: 4,027
Threads: 172
Joined: Aug 2005
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.
Posts: 4,027
Threads: 172
Joined: Aug 2005
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 _ _ _ as expected, too. According to Diego's instructions, only bit #9 is meaningfull, so I keyed in: 20F and saved it. According to Diego's post, this way I was swapping both 16KRAM blocks with each other. Exited HEXEDIT, turn the calculator off and on again, working fine. HEPROOM returns 2,610.0000 again and HEXEDIT with address 4100h verifies 20F recorded. Now for the test: I wrote a small program and saved it through HSAVEP. HEPDIR showed it was there. HEXEDIT again, address 4100, I recorded 00F in order to swap the blocks back. Exit HEXEDIT, calculator off and on again, HEPDIR and... there it is the progranm that was supposed to be hidden in the other 16KRAM block. HEXEDIT, Address 4100: found 00F there. Changed address 4100 to 20F and back to 00F and found the same program with both of them.
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 I decided to navigate through RAM with HEXEDIT and found that only page #9 had its heading, and that address 4100h had its contents changed to 2F2. This actually agrees with Diego's documentation about NoV32: page #9 is always active.
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.
Posts: 53
Threads: 6
Joined: Dec 2005
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
Posts: 4,027
Threads: 172
Joined: Aug 2005
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 As we are dealing with 10-bit data, the lefmost character (hex) is in the range 0h->3h.
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
and I got the same contents, i.e., either 00F or 20F address the same four 4KRAM blocks, and they are located in the same pages, from page #8 to page #B. I also tested 3xx, meaning:)
bit# 9 8 7 6 5 4 3 2 1 0
value 1 1 x x x x x x x x -> 3xx and the calculator locks. In Diego's original documentation related to the NoV32, he mentions the overlapped mode, i.e., when bit 9=1, then bit 8 accepts either 0 (lower 4 RAM blocks) or 1 (upper 4 RAM blocks). But he mentions that the overlapping was supposed to be fully implemented at the end of 2005. Well, based on all that Diego has already done, I'd like to help him more than to wait for he to achieve results, but I do not know how. That's the main reason I'm doing so many experiments (and seeing my HP41's to freeze so much...)
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.
Posts: 41
Threads: 0
Joined: Jan 1970
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.
Posts: 4,027
Threads: 172
Joined: Aug 2005
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.
That makes two of us...d8^D In fact, I see no difficulties to understand the operation, I am actually trying to figure out what's going on with my unit.
Quote: I'm guessing that HEPAX is now in ROM at pages 6-7, is that correct?
In fact, HEPAX first 'appearence' happens at page #8, then it goes to page #5 after turnning the calculator off and back on (if I use a CX it goees to page #6; I did not try it with an HPIL yet, but it will surely go to page #7). Quote: Note, we don't want rom and ram at the same page (Diego mentions crashes in these cases).
O.K., I'd even say that this would cause problems in any system... or it would demand sharing clock cycles somehow...
Quote: Is this the way you understand it?
00F sets NVR 0-3 into 8-B (default at first power)
O.K.
Quote: 0FF sets NVR 0-7 into 8-F (Diego above, says this don't work)
O.K.
Quote: 20F sets NVR 0-3 into 8-B (which is the same as the default)
O.K.
Quote: 3F0 sets NVR 4-7 into 8-B
At least it should... instead, doesn't.
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.
In fact, I consider that 3XX is not good so far (XX = 00 to FF). I think that some additional software control is needed to fully implement overlapping RAM pages. At least I did not succeed so far.
Quote: Then the only six configurations are 003, 007, 00F, 330, 370 and 3F0? Bit 8 is defined differently in the second figure so...
There are some valid configurations:
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.
O.K., I see what you mean. The actual contents handled at address 4100 are stored inside the NoV32 memory, it is just a matter of redirecting the FETCH procedure. The NoV32 internal clock is 4×12MHz, it has time enough to cheat the slow HP41 nut processor... Quote: In some respect this is a problem for me as I use page 4 for ram.
This is, indeed, interesting!
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.
|