New HP-41 module available: Ladybug

[hth]

(01-12-2017 06:38 AM)Ángel Martin Wrote:  

(01-11-2017 08:16 PM)hth Wrote:  I assume you mean "JNC +00" goes to next line? I saw that in the CX ROM, often before an ENROM instruction. I do not really understand why, but suspect that they are there to avoid having a GOSUB go to that location and get trapped by the NOP means RTN feature, as ENROM really is a NOP variant.

But in the advantage it is done at the destination. Does it switch on the fly as well? Do you do the same in your banked modules?

First I meant "JNC +01"", not "00" - sorry for the typo. Both the CX and the advantage are similar in that the bank changes are not happening in the same page that issues the ENBANK instruction, so being "on the fly" is not an issue I suppose. Having said that the banking is managed by the module itself, so its behavior will be suited to the hardware it's running on - or so I thought. This is why the Zeproms manage to have FOCAL code in bank-switched pages, but this is not related to this case.

Second typo - those JNC +01 are not in the destination but right before the ENBANK instructions. Again, I thought this to be a whimsical note due to the hardware used. The HEPAX does *not* include those superfluous jumps ... so all this may off the point.
In my modules I use the HEPAX model, which ultimately also relies on a working "on the fly"model but all bank switches are made in the same routines, which are duplicated on each bank.

As I said it works just fine on V41. Will burn to a CL flash this week-end, but I don't expect any issues there either.

The PACKING issue is somehow bothersome - I guess this was one case not accounted for in the IO_POLL code? Hope you can patch it as well.

Thank you for the description of the bank system. Sounds like there should not be an issue then, but it is up to the memory system used. While I have tried it on a CL, it was with a connected MLDL 2000.

The PACKING issue is actually quite innocent, but it looks scary.

HP says, the two first digits in the buffer header register are the same, like AA for timer alarms. In reality, it is the second digit that is significant for the buffer number. The first one is either 0 for a buffer that can be removed, or non-zero for a buffer that is active.

At power up, the first digit is changed to 0 by the OS, then it is up to modules to reclaim their buffers by changing it back (or at least make it non-zero). I always just incremented it to make it 1, which works fine. After this, the OS examines the buffers again and those that still have a 0 in the first digit are removed.

What happens in this case is that once long time ago I used a buffer number that was not 0. Later on, it was changed to 0. The code that writes the initial buffer header does the double digit as suggested by HP, so it writes BufNumber twice (a define). Only, now they are both 0. So it creates a buffer that is marked as removable. I did not think about that when I changed the value of the define.

PACK actually removes buffers that are marked as unused, something I was not aware of. (And even if I knew, I doubt that I would have made the connection when changing BufNumber.)

So if you trigger a PACK, the buffer goes away. If you cycle power, it gets incremented to 1 and stays on as it should.

I have fixed it on my side, I just want to give it some time to collect some other potential early issues before I make another release.

Håkan