MEGA65: different results - run from diskimage vs. injecting

[ghost]

Describe the bug

The injection of a .PRG via CLI/drag'n'drop leads since version Xemu/MEGA65 20230201214849 (master) - maybe earlier? - to a different result compared to starting the .PRG directly from disk image. Some time ago I already briefly addressed this on discord.

For clarification, I've attached the disk image and the separate .PRG.

• run "START" from disk-image versus
• inject .PRG (.D81 need to be mounted)

[ghost]

FYI: With version Xemu/MEGA65 20220613133247 (master), which I stayed with for a long time, injecting still worked.

[lgblgblgb]

@xhl77 What is the difference exactly you experience? As far as I can tell by testing it, the result is similar. One thing I noticed the difference is the slightly different scene though. It can be explained if you use the $D610 (hardware accelerated ASCII keyboard scanner) feature. The problem here, that people often forget to empty the "queue" resulting in picking up previous, potentially old and irrelevant keypresses. This was a major problem that Xemu users developed software not running properly on a real MEGA65, as with injecting the keyboard buffer is empty, which is never the case with a real MEGA65 since you need to LOAD with some typing usually. Thus I introduced a feature to inject some characters into the queue to reveal these kind the problem and not fool users to think their programs are OK and just later revealing the problem on a real MEGA65 then.

I am not sure if it is the issue here, or other kind of difference I should be noted. But even when using the "normal" disk method, and press RETURN key and then typing LOAD produces (as far as I can see) the same effect you have with injecting. Since Xemu exactly pushes that sequence into the keyboard buffer.

If it is really the problem, then never ever forget to empty hw accel keyboard buffer before start to using it.

Btw the mentioned change in Xemu: https://github.com/lgblgblgb/xemu/commit/f446ac43c34c525a672f84024ddcd64aed4f9efe

[ghost]

Sorry for the inconvenience, yes it has to be that. It's just a shame that I can't do it, not even with the example from discord by gardners, hmm... I'm doing something wrong.

BTW: On hardware it's working properly, clearing the key-buffer that is. I'm totally confused now.

However, thanks.

[lgblgblgb]

I don't know that example, but something like this should work (surely when I/O is at $Dxxx and VIC-IV I/O aka MEGA65 I/O mode is seleted), calling that at near of your program or something:

clear_kbd_buffer:
  LDA $D610
  BEQ @ret
  STA $D610
  BRA clear_kbd_buffer
@ret:
  RTS

Just writing it by hear now, maybe there is more "cleaner" solution, in theory simply 5 x STA without any condition/jump etc should work as well, however then it's implementation dependent how deep the queue is, which may change in the future?

[ghost]

I don't know if I understand correctly.

My situation: Emptying the keyboard buffer always worked like I always do.

• on real hardware
• xemu master version from june 2022 later on versions it doesn't work anymore

mine is the same

    !:  lda $d610
        beq !empty+
        sta $d610
        bra !-
    !empty:

[lgblgblgb]

I find that very interesting if it wouldn't work, since it would also mean, keypresses are not removed at all. But that would also mean that you would constantly get key events since cannot be removed, though, if I press (lower case) 'L' I see firing effect but it does not repeat when I release 'L'. Thus during the normal gameplay loop key is removed normally in/by your program. But this "make kbd queue empty" is basically the same stuff, removing keys if there is any ... So in nutshell I can't see the reason why it would make a difference then. Are you sure you use this make-empty stuff at the beginning of you program but after everything is set up, ie I/O is enabled at $D000, VIC IV aka MEGA65 I/O mode is selected?

[ghost]

setting up the system, writing hot registers and never touch them afterwards (leaving enabled), setting basepage, clearing mult-registers, clearing the key buffer, some init routines and then enabling irq and entering the main loop ...

[ghost]

I'm really embarrassed now. Seems like I'm doing stuff in the init routines that somehow messes up the key buffer. @lgblgblgb I have to sincerely apologize, it's all my fault. Sometimes you need someone to ask you the right question that will lead you to the solution.

Thank you very much, I would have been at a loss without your support.

[lgblgblgb]

@xhl77 No worries :) It's always worth to find the root cause, it has already turned out (not even once) that I can find some Xemu problem after all, even if it's not the original supposed-to-have problem, so usually I try to reach the final conclusion before the final verdict. It also great for the reporter - I guess - if the problem is found, let it be Xemu or not ... So it's kinda win-win situation, anyway ;) Closing this now.