HP Forum Archive 18

[ Return to Index | Top of Index ]

NoV-32/HEPAX bug, further research Message #1 Posted by Geir Isene on 22 Mar 2008, 11:33 a.m. Any comments, suggestions or pointers on this? Further research show that upon doing either: 1. SHIFT+ON or 2. Fast SST in PRGM mode in HEPAX ram (resulting in the program pointer suddenly jumping to user ram [first program there]) 3. Fast SST in ASSM mode (David Assembler) ... the HEPAX module reallocates itself to page #8 (the first HEPAX ram page), effectively removing access to any programs in the first HEPAX ram page. The other ram pages (#9, #A and #B) are left intact and usable. Turning the calc off and on again resets the HEPAX ram to page #6. This is consistent. Any suggestions?

Re: NoV-32/HEPAX bug, further research Message #2 Posted by Meindert Kuipers on 22 Mar 2008, 12:08 p.m., in response to message #1 by Geir Isene I have identified a similar problem with the MLDL2000, when doing fast SST with DAVID Assembler in ASSM, also when no HEPAX was present. This turned out to be due to a timing problem inside the MLDL2000, and it occurs only on some units. It was solved with a new firmware update that will be distributed when the new MLDL2000 software is finished. Some units have been updated already. The only change in the firmware is changing the synthesis parameters to make it more reliable. The problem was that timing of ISA output (when reading MLDL contents) was sometimes off by one clock, and wrong data would be returned. For some reason this was more clear when doing repeated keystrokes. Maybe this helps in identifying the problem with NoV-32. Meindert

Re: NoV-32/HEPAX bug, further research Message #3 Posted by Diego Diaz on 22 Mar 2008, 12:55 p.m., in response to message #2 by Meindert Kuipers Hi Geir, I'm now back at home and will seek the time to research that infamous bugs. Certainly I agree with Meindert's hint regarding this is more likely a timing issue. I have to find my fastest and slowest 41's to run comparative tests, and will let you know. Again a real HEPAX and David ASSM testing would be of an unvaluable help... alas, seems that noone is available... :( Best wishes. Diego

Re: NoV-32/HEPAX bug, further research Message #4 Posted by Geir Isene on 22 Mar 2008, 3:05 p.m., in response to message #3 by Diego Diaz Thanks guys. You are valuable assets to my "official insanity" (HP calculator collecting, that is :)

Re: NoV-32/HEPAX bug, further research Message #5 Posted by Geir Isene on 23 Mar 2008, 6:56 p.m., in response to message #3 by Diego Diaz Diego, Is there any way to put David Assm in page D, the Label Rom in page F and let HEPAX ram reside in pages 9 to C (leaving page E for the card reader or rom module and page 8 free for HEPAX to reallocate in at its whim :)?

Re: NoV-32/HEPAX bug, further research Message #6 Posted by Diego Diaz on 23 Mar 2008, 11:19 p.m., in response to message #5 by Geir Isene Hi Geir, As far as I remember David Assembler requires an even page and Labels in the odd page of the same port, but I'm not an expert on that. What I can assure is that Hepax RAM can not be placed into pages 9-C. Let's try this config instead: HEPAX RAM: pages 8-B (as ususal) David ASM: page C Labels: page D Card Reader: page E With this config HEPAX will allocates itself either into page 5 41C or CV, or page 6 CX without printer, or page 7 CX with printer, or F CX with HP-IL. Let me know if it works. Best regards from Spain. Diego

Re: NoV-32/HEPAX bug, further research Message #7 Posted by Geir Isene on 24 Mar 2008, 3:54 a.m., in response to message #6 by Diego Diaz Right, The setup you suggest is the one I currently have, and it works well until HEPAX relocates itself to page 8 when the above mentioned conditions occur. I wanted to free up page 8 as a work-around so that HEPAX can relocate itself there without me loosing any HEPAX RAM.

Re: NoV-32/HEPAX bug, further research Message #8 Posted by Diego Díaz on 24 Mar 2008, 3:28 p.m., in response to message #2 by Meindert Kuipers Hi Meindert, On the line of the suspected "timing issue" I'm going to build a modified NoVRAM with a faster Xtal... (little above the reccomended overclocking limit) just to see if this finally fixes the bug. Is it posible to you to perform a similar modification into MLDL2000 to run comparative tests? In other order of things I hopefully will get a lent HEPAX for a few months (thanks Peter for your offer!) so chances are that we can finally have a solid reference of the *real thing* behaviour. Crossed fingers!! ;-) Best wishes from the Canaries. Diego.

Re: NoV-32/HEPAX bug, further research Message #9 Posted by Meindert Kuipers on 24 Mar 2008, 3:57 p.m., in response to message #8 by Diego Díaz Hi Diego, Good to see that you have a bit more time now! Looking forward to see you coming up with some new things! The MLDL2000 is fully static, meaning that it only uses the HP41 clocks for its timing. There is no external XTAL to 'overclock'. What I did with the firmware upgrade, is to synthesize the VHDL with the option for Speed Optimization instead of Space Optimization. The code is identical, so there are no functional changes. The previous firmware that worked OK was built with an older version of the Xilinx tools. The problem came up with my own proto setup (it has longer wires) in combination with the tool upgrade and did not appear on my completely built unit. So far I had one user in the field with the problem, and that was solved with the new firmware. I do not expect any issues with HEPAX. I noticed my problem very early in the development of the MLDL2000 when finetuning the ISA output registers and output enables, when I used only the David Assembler for testing, and nothing else. The ISA contents for the output sometimes shifted one bit. Regards from a cold Netherlands! Meindert

Re: NoV-32/HEPAX bug, further research Message #10 Posted by Diego Diaz on 25 Mar 2008, 3:37 a.m., in response to message #9 by Meindert Kuipers Hi Meindert, Thanks for your reply. Hopefully I'll have a real HEPAX handy in short... I can tell a lot more as I run comparative tests. Will download your latest MLDL2000 firmware upgrade also to get the whole picture. Best wishes from the (now cloudy) Canaries. Diego

Re: NoV-32/HEPAX bug, further research Message #11 Posted by Meindert Kuipers on 25 Mar 2008, 3:55 a.m., in response to message #10 by Diego Diaz I will prepare an email with the latest firmware and software to program it for you later. The current released version of the software does not allow reliable prgramming of firmware! Meindert

Re: NoV-32/HEPAX bug, further research Message #12 Posted by Diego Diaz on 24 Mar 2008, 3:36 p.m., in response to message #1 by Geir Isene Hi Geir, Soory for the question, supposedly I would know the answer already but I'm a litte bit messy about my customers... :-( Do you have NoVRAM too or only NoV-32? In case you have both, can you run same test on NoVRAM. Just to point it out, I do not have a "commercial" NoVRAM, Clonix or NoV-32. My units are sligthly modified for debugging purposes... I know, I know... I should have a set of "standard" modules to test... but... time... always short of time!! :) Hopefully I'll have enough spare time in the near future. Let's see. Cheers. Diego.

Re: NoV-32/HEPAX bug, further research Message #13 Posted by Diego Diaz on 26 Mar 2008, 2:44 a.m., in response to message #12 by Diego Diaz Hi, Thanks Meindert, you've got mail! Geir, I've isolated the cause for the "Clock issue"... just NoVRAM "thinks" that the calc has gone to deep sleep and therefore decided to go to sleep itself (in other words... it goes to reset routine) unfortunatelly, HP-41 does not wake-up from SLEEP, but simply re-takes the RUN mode, leaving NoVRAM in the arms of Morpheus... :-( and unable to perform the required re-location. Seems that this is due to the interrupt routine in charge of monitoring AUTO-OFF (a well known old friend... ;-) Will keep you informed... Cheers Diego.

Re: NoV-32/HEPAX bug, further research Message #14 Posted by Geir Isene on 27 Mar 2008, 6:23 p.m., in response to message #13 by Diego Diaz Thanks. I will be patient :) Good that you are onto something regarding the issue. BTW: I have only the NoV-32 (until the time when a NoV-64 is ready... I'll be first in line :)

Re: NoV-32/HEPAX bug, further research Message #15 Posted by Diego Diaz on 27 Mar 2008, 6:44 p.m., in response to message #14 by Geir Isene Hi Geir, Thanks for the feedback. Please note that you can always config your NoV-32 using NoVRAM.EXE, and it will bahaves exactly as a NoVRAM, though it won't make any difference regarding this particular bug. In the meantime you may prefer to press [ON] twice to exit Watch Mode thus avoiding the HEPAX to move to page #8 (I think you've alredy find that out, but it could help some other users). Regrettably the possibility of testing with a real HEPAX has turned out to be impossible so far. I'll have to work just with the emulation and oscilloscope :( Anyhow, I've finally build a "standard" NoVRAM to run test in the same conditions. Will keep you informed by mail. Best wishes from Spain. Diego.

Re: NoV-32/HEPAX bug, further research Message #16 Posted by PeterP on 27 Mar 2008, 11:10 p.m., in response to message #15 by Diego Diaz Diego, are you planning to be at any of the conferences either here or in Europe?

[ Return to Index | Top of Index ]

Go back to the main exhibit hall