(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.

(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.

It is not using page 4 due to bank switching, it is using it to make the alternative keyboard mode work reliably.

All bank switching takes place inside the same page. It flips banks back and forth and have code fragments in the two banks aligned so that it can continue at the next PC location, but in the other ROM.

Using the advantage's method is not really an advantage (put intended), in fact it'd be worse since it occupies two ports instead of one - so I don't see the need to change what already works ;-)

We can put the code in the Library#4, difficult due to its over-capacity state but not impossible if something else goes. The bigger question however is whether having that code in the library#4 and without the ladybug is compatible with the rest of modules also polling the I/O interrupt (OS/X, SandMath, CCD, AECRom, etc...).

(01-13-2017 06:58 AM)Ángel Martin Wrote: The bigger question however is whether having that code in the library#4 and without the ladybug is compatible with the rest of modules also polling the I/O interrupt (OS/X, SandMath, CCD, AECRom, etc...).

There is a very clever guy named Ángel that frequents this forum, suggest you ask him. If he has no ideas, then tell him "you may be right, it could be impossible" then he surely will find an answer. He always does...

Just found out that Ladybug does not work properly on very early 41C ROMs, when the PACH11 routine is missing (the one that fixes the display synchronization problem). Will be fixed in next release. As a bonus, you get the PACH11 fix to your very old 41C.

I've been trying it out on the i41CX+ emulator (iPhone) and it seems to work well.

I also took the liberty to create an overlay, that I've attached in case any one else wants it. It is for the "retina" display resolution (since that is what I have). It isn't perfect, but it gets the job done.