Post Reply 
New HP-41 module available: Ladybug
01-12-2017, 06:38 AM
Post: #21
RE: New HP-41 module available: Ladybug
(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.
Find all posts by this user
Quote this message in a reply
01-12-2017, 01:39 PM
Post: #22
RE: New HP-41 module available: Ladybug
This is something i could really use. Thanks for the work! Also, bonus points for making a SEX and a WIN button.
Find all posts by this user
Quote this message in a reply
01-12-2017, 05:43 PM
Post: #23
RE: New HP-41 module available: Ladybug
(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
Find all posts by this user
Quote this message in a reply
01-12-2017, 07:05 PM
Post: #24
RE: New HP-41 module available: Ladybug
What an interesting explanation. Thank you.
Find all posts by this user
Quote this message in a reply
01-13-2017, 02:15 AM
Post: #25
RE: New HP-41 module available: Ladybug
A small suggestion ...

You could use the Advantage bank switching style and modify your code in LADYBUG?.ROM to use the relative lower page instead of page 4.
Code:
       : page 8       : page 9       :
------ : ------------ : ------------ :
Bank 1 : OS4.ROM      : LADYBUG1.ROM :
Bank 2 : OS4.ROM      : LADYBUG2.ROM :

It will allow to use Ángel ROM's at the same time as yours.

Sylvain
Find all posts by this user
Quote this message in a reply
01-13-2017, 04:38 AM
Post: #26
RE: New HP-41 module available: Ladybug
(01-13-2017 02:15 AM)Sylvain Cote Wrote:  A small suggestion ...

You could use the Advantage bank switching style and modify your code in LADYBUG?.ROM to use the relative lower page instead of page 4.
Code:
       : page 8       : page 9       :
------ : ------------ : ------------ :
Bank 1 : OS4.ROM      : LADYBUG1.ROM :
Bank 2 : OS4.ROM      : LADYBUG2.ROM :

It will allow to use Ángel ROM's at the same time as yours.

Sylvain

How much I would like to avoid using page 4, it is just not possible.

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.

Håkan
Find all posts by this user
Quote this message in a reply
01-13-2017, 06:58 AM (This post was last modified: 01-13-2017 06:59 AM by Ángel Martin.)
Post: #27
RE: New HP-41 module available: Ladybug
(01-13-2017 02:15 AM)Sylvain Cote Wrote:  A small suggestion ...

You could use the Advantage bank switching style and modify your code in LADYBUG?.ROM to use the relative lower page instead of page 4.
Code:
       : page 8       : page 9       :
------ : ------------ : ------------ :
Bank 1 : OS4.ROM      : LADYBUG1.ROM :
Bank 2 : OS4.ROM      : LADYBUG2.ROM :

It will allow to use Ángel ROM's at the same time as yours.

Sylvain

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

ÁM
Find all posts by this user
Quote this message in a reply
01-13-2017, 07:40 PM
Post: #28
RE: New HP-41 module available: Ladybug
(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...

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
01-13-2017, 07:46 PM
Post: #29
RE: New HP-41 module available: Ladybug
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.

Håkan
Find all posts by this user
Quote this message in a reply
01-14-2017, 01:02 AM
Post: #30
RE: New HP-41 module available: Ladybug
Hi Håkan,

This really is very nice work.

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.

Thanks for the module!

-Robert


Attached File(s) Thumbnail(s)
   
Visit this user's website Find all posts by this user
Quote this message in a reply
05-20-2017, 05:17 AM
Post: #31
RE: New HP-41 module available: Ladybug
Release 0B is available, see top post for details.

Håkan
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)