After installing the new NoV-32 image two months ago, life has been good :)

Battery life is extended beyond my capabilities of testing (yet), the module is stable - except for two freezes on turn-on that was easily resolved by removing the batteries for a few seconds. Upon reinserting the batteries, main memory, key assignments etc was still intact. Only the clock has to be reset - as it seems to be "nulled" the moment battery is disconnected from my 41CX.

Now, this morning I turned the calc on and it was completely reset (as after MEMORY LOST), but without any MEMORY LOST message - simply just reset.

I use the NoV-32 in my 41CX every day, many times per day (config: NOV-32 in port 1 with CCD OS/X [page #C] & DAVID ASSM [page #D], 2*XM in port 2).

I wonder if anyone has had similar experiences with either the NoV-32, the NovRAM or the MLDL2000 (with HEPAX) or even with the Clonix or the MLDL2000 (without HEPAX). Anyone?

I frequently get memory resets while using MCODE programming. Often times, I have to do this myself as the unit goes haywire. I have just resided myself to not use the label function on the David Assembler as the buffer would get wiped out several times during a session. If there are any solutions to the problem I would also be interested.

About the DA label buffer: You could regulary save away the labels using BUF>REG, or maybe a WALL;-)

At least that's what I did when I used to program on the HP-41 directly.

Nowadays I'd suggest using SDK41 from Warren Furlow..

HTH

Raymond

Hi Raymond

Why do you use SDK41 instead of SDSII?

Can you explain me the diferences between these two development tools. Advantages and disadvantages.

I use SDSII. But have never used SDK41.

Thanks

MCode experimenting will certainly result in crashes.
I have seen in some occasions a MEMORY LOST when switching the HP41 on while just having attached the MLDL2000. I do not yet have a good explanation for this, but it could be that starting the MLDL2000 and charging the various capacitors are just a bit too much load.
The MLDL2000 takes about 7-10 mA when it is on, and the initial charge current could be a bit higher.
Although I am not certain, I do not think I have seen any relation with the modules that are selected in MLDL2000

Remember, a MEMORY LOST occurs when the cold start constant in the c-register is not equal to 169, so it must have something to do with current drain (so memory is not kept) or startup mcode going totally wrong. Another possibility could be that while starting, the MLDL2000 is out of SYNC and returns data on ISA on a moment it should not do that (or returns with wrong data).

Meindert

Just for info: I have not yet included any start-up MCODE in the NoV-32. The added date on the MLDL2000 is interesting, though.

When the unit is out of SYNC, it does not matter if there is mcode startup-code or not. I think for both the NoVRAM and certainly MLDL2000 this is probably the most likely cause of the problem the more I think of it.
I am going to build up my proto setup anyway and i will do some more precise measurements of the startup behavior.

Meindert

Hi,

back then when I had to decide which PC-based development system to use,

I took a look into both 'manuals', the one from the SDSII and from the SDK41,

and it appeared to me that the SDK41 was much easier to set up and use.

From my understanding, the SDS needs actual hardware connected, like an MLDL RAM Box, for simulation.

The SDK41 uses a PC-based emulator and debugger,

much more like the development tools I use for the HP-48 (SASM, RPLCOMP,Emu48).

So I decided to try SDK41, and it is perfect for my needs.

Some small make/helper scripts, and nearly everything works automatically.

Raymond

What exactly does it mean that it is "out of sync"?

Does this happen only on start-up or also while the calc is off?

Diego: Out of sync = Something to explore?

Hi,

I have chosen between both development tools like you: browsing the manuals.

But I didn´t find in SDK41 how to integrate in the same ROM module MCODE programs and USER CODE programs. (Probably, I didn´t read it well). With SDSII there is a tool to do this: BUILD.

I wrote some .bat files to automate all the compiling process.

And once I have a .ROM file with both, MCODE functions and USER code programs, I generate a .MOD file to load in V41 emulator. (So you have almost all the “Hardware” you need for simulation)

I´ll try SDK41 to learn who it works, and to test its emulator/debugger.

Jose

The details are a bit explicit, but here we go:

The HP41 uses a 56-bit (14digit) clock cycle. The start of it is indicated by the SYNC signal, and two clocks are used to indicate valid data. For any logic interfacing with the HP41 it means that the internal logic or firmware must use SYNC to synchronize the internal clocks and counters. In some cases( when the HP41 fetches data instead of instructions) the SYNC signal is not present, so the logic must reset the internal counters after exactly 56 clocks.
When the HP41 is just starting the MLDL2000 might miss a SYNC due to its own internal startup (which takes about 50 microseconds) and could think that receives an address or data at a moment that the HP41 is not intending to send that, just because the MLDL2000 is 'out of SYNC'. If a SYNC is not present this could last just a complete cycle longer.

Hope this explains a bit the situation. The MLDL2000 relies on the SYNC signal to get a good starting point, and of course it also counts clocks. I could possibly improve this by waiting for the first SYNC before doing anything else. I do not know how the Clonis/NoVRAM does it.

Meindert

Hi all,

Sorry for being so late... I'm not at home and will still be out for three more weeks (in the Dominican Republic), with very little access to the i'net.

Certainly Clonix/NoV's also "sense" SYNC signal to begin bit-counting. But as far as I've able to test there is no relation between SYNC and those unwanted resets in the Clonix/NoV's code at start up, and also think that a some mA up or down (I've "abused" up to 100mA) won't affect the overall start up process.

I have a "suspictious" to be the culprit of such an undesirable behaviour attending to the following clues:

- I've never been able to reproduce "reset's" with "just" HEPAX loaded into NoVRAM into a clean [MEMORY RESET] HP-41.

- Most (all?) of the "reset" reports comes from systems using I/O Buffers (David Assm, CX Clock Alarms) and "heavy" usage of iterrupt area (H'XFF4...H'XFFA) AEC-ROM...

Clonix code is fairly simple (mostly the ClonixLP version) but NoV's are very tight coded so chances are that I/O buffer handling leads to situatios as those described by Meindert.

Also take into consideration that, though they share the same purpose, Clonix and MLDL2000 are completely different on their working principles: MLDL2000 is HW based (if you allow me to express it that way, Meindert) while Clonix is basically a SW "machine". So it looks "peculiar" that both approaches show that similarity in this "bug". My "conclusion" is that they both are "working as expected" and simply "pushing" HP-41 systems to their "real" limits (or even beyond that point).

In short there were very few chances to get such overloaded systems (CX with HEPAX + 2*X-MEM + AEC ROM + CCD [OS-X]...) in the late eighties...

Of course they *should* work properly with *any* legal configuration... but I'd like to test with a real HEPAX + real AEC + real CCD + 2*X-MEM (and some other "heavy" configs) to have a solid coparison base. (Any beta-tester volunteers?)

Anyhow, will keep on seeking to find out the way to avoid any unwanted behaviour on our beloved machines... and will need your help (as usual) to complete that task. Namely, any info regarding the I/O buffer handling will be sincerely welcome.

Best "Caribbean" wishes :-)

Diego Diaz

Good to see you back here Diego!

One comment about power usage: I typically use my HP41 with an external supply that is connected through the MLDL2000, and no batteries in the calc. When storing the units I disconnect the MLDL from the HP41. Last time I saw the memory lost, I just connected the MLDL to the HP41 (without batteries), but also did not have the external supply connected. This probably drained the internal capacitors enough to result in memory lost.

I will look into this in more detail!

Meindert

Hi there Meindert... and all 41'ers around...

Certainly, the scenario you've described is a good candidate for [MEMORY LOST]... I also use a charger (almost permanently connected) and a refurbished NimH battery pack while running my 41.

Now I should have lots of spare time (just retired last Dec.) but still will need some extra weeks to put a few personal issues in order... some in the Dominican Republic.

Will hopefully be back to the Canaries by end March.

Enjoy the end of this Winter, and say hi! to Spring... :-))

Best wishes, Diego.