## DM41X ED$Bug in SLOW-mode Please report issues with the DM41X Beta Firmware in this sub-forum hth313 Posts: 36 Joined: Thu Jun 15, 2017 8:00 pm ### Re: DM41X ED$ Bug in SLOW-mode

No, I do not have any DM41X, but I am always interested in anything related to the HP-41. I am trying to understand the DM41X and what the limitations are, to see if it is suitable for me.
STS-741
Posts: 40
Joined: Sun Nov 01, 2020 7:48 am
Location: Europe

### Re: DM41X ED$Bug in SLOW-mode hth313 wrote: Sun Nov 08, 2020 6:35 am No, I do not have any DM41X, but I am always interested in anything related to the HP-41. I am trying to understand the DM41X and what the limitations are, to see if it is suitable for me. Ha, I'm in the same situation right now, I'm also very interested in the DM41X, not only for technical reasons but also due to the historical significance of its predecessor, the HP-41CX. So every little improvement is eagerly awaited from me. Ángel Martin Posts: 109 Joined: Mon Apr 24, 2017 8:19 pm ### Re: DM41X ED$ Bug in SLOW-mode

hth313 wrote:
Sat Nov 07, 2020 11:52 pm
So I will conclude that the modules I write that rely on timing loops in certain situations do not work well on the DM41X.
AFAIK the emulator is capable to interpret time-counting loops and behave as expected, i.e. as if the machine was in SLOW mode for the execution of those loops. I believe this is achieved at the low level DMCP code.
JurgenRo
Posts: 3
Joined: Sat Oct 05, 2019 11:50 pm

### Re: DM41X ED$Bug in SLOW-mode Just for the sake of completeness: according to my observations, the "video jumping" happens actually also in FAST-mode! It is just so, that the jumping-events simply occur less frequently than in SLOW-mode (I actually have observed up to 30 seconds between 2 events). However, in FAST-mode this is acceptable in my opinion because it does not really affect the work with ASCII-files. hth313 Posts: 36 Joined: Thu Jun 15, 2017 8:00 pm ### Re: DM41X ED$ Bug in SLOW-mode

Ángel Martin wrote:
Sun Nov 08, 2020 10:03 am
AFAIK the emulator is capable to interpret time-counting loops and behave as expected, i.e. as if the machine was in SLOW mode for the execution of those loops. I believe this is achieved at the low level DMCP code.
That sounds indeed pretty magic. Would be cool if it actually just works. I will have to wait and see.
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

### Re: DM41X ED$Bug in SLOW-mode hth313 wrote: Sun Nov 08, 2020 7:26 pm Ángel Martin wrote: Sun Nov 08, 2020 10:03 am AFAIK the emulator is capable to interpret time-counting loops and behave as expected, i.e. as if the machine was in SLOW mode for the execution of those loops. I believe this is achieved at the low level DMCP code. That sounds indeed pretty magic. Would be cool if it actually just works. I will have to wait and see. It works, the interpreter "reads ahead" and detects timing loops structures in the code. I'm pretty sure that the flickering is not related to this implementation but to the general approach of the emulator to interpret the instructions. I think the ED$ case is more difficult to get it picture-perfect due to the intrinsic MCODE HP used in that function - very CPU intensive: there's no partial key sequencing in there (it came on the bank-switched bank in the CX, remember?) so everything works using GETKEYs. It's not by chance that ED$has a time-out embedded in the code to exit the mode after 100 iterations of the idle loops... hth313 Posts: 36 Joined: Thu Jun 15, 2017 8:00 pm ### Re: DM41X ED$ Bug in SLOW-mode

Ángel Martin wrote:
Mon Nov 09, 2020 7:36 am
hth313 wrote:
Sun Nov 08, 2020 7:26 pm
Ángel Martin wrote:
Sun Nov 08, 2020 10:03 am
AFAIK the emulator is capable to interpret time-counting loops and behave as expected, i.e. as if the machine was in SLOW mode for the execution of those loops. I believe this is achieved at the low level DMCP code.
That sounds indeed pretty magic. Would be cool if it actually just works. I will have to wait and see.
It works, the interpreter "reads ahead" and detects timing loops structures in the code. I'm pretty sure that the flickering is not related to this implementation but to the general approach of the emulator to interpret the instructions. I think the ED$case is more difficult to get it picture-perfect due to the intrinsic MCODE HP used in that function - very CPU intensive: there's no partial key sequencing in there (it came on the bank-switched bank in the CX, remember?) so everything works using GETKEYs. It's not by chance that ED$ has a time-out embedded in the code to exit the mode after 100 iterations of the idle loops...
I was thinking that it could detect backward jumps and examine the instruction sequence, if they are just inc/dec, check keyboard and jumps, then it is very likely a timing loop.

Regarding ED and such, it is easier to busy wait on the keyboard and as a bonus it is possible to animate the display. The disadvantage is that it draws full power, so you have batter checks and timeout to terminate. Partial key sequences have certain built-in behavior that you may need to work around when you use/abuse it.