Re: [hatari-users] Minor Problems with Falcon Emulation (SDL GUI keyboard shortcuts)

[ Thread Index | Date Index | More Archives ]


On lauantai 09 elokuu 2014, Ingo Schmidt wrote:
> > - Is your computer fast enough?  If it's not, you get sound issues.
> How do I know? :)
> Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz
> Not really the strongest, but I assume it is good enough? I will test
> later on my desktop computer and see if the sound is fine there.

If you see with automatic frame skip something else than "FS: 0"
in the Hatari statusbar, your machine is too slow to emulate
things at full speed, and you will get sound issues.

Some things you could try if this is the case:
- As Falcon screen content scaling can take a bit of CPU, set
  set smaller max resolution and using full screen (with that
  smaller resolution).
- if things aren't constantly too slow, increasing sound buffer
  size may improve things.  That will increase sound latency though.

[memory testing]
> Sorry, didn't understand...

Sorry, I might have rememberered this wrong.  

> Let me rephrase to see if we talk about the same thing:
> Machine = ST, TOS = 2.06 and "Patch TOS for faster boot" = on: memory
> test is skipped, booting is fast
> Machine = ST, TOS = 2.06 and "Patch TOS for faster boot" = off: memory
> test is executed, booting is slow
> So far everything as expected.

This is what the Hatari code does, I think it was added by Thomas:
        /* Fill in magic numbers to bypass TOS' memory tests for faster boot 
         * if VDI resolution is enabled or if more than 4 MB of ram are 
         * (for highest compatibility, those tests should not be bypassed in
         *  the common STF/STE cases as some programs like "Yolanda" rely on
         *  the RAM content after those tests) */
        if (ConfigureParams.System.bFastBoot || bUseVDIRes
            || (ConfigureParams.Memory.nMemorySize > 4 && !bIsEmuTOS))
                /* Write magic values to sysvars to signal valid config */
                STMemory_WriteLong(0x420, 0x752019f3);    /* memvalid */
                STMemory_WriteLong(0x43a, 0x237698aa);    /* memval2 */
                STMemory_WriteLong(0x51a, 0x5555aaaa);    /* memval3 */

> Machine = Falcon, TOS = 4.04 and "Patch TOS for faster boot" = on:
> memory test is executed, booting is slow
> And that I did not expect.

I get the same.

> So how can I achieve the skipping of the memory test for the Falcon,
> just like it works for ST?

Maybe TOS4 uses different variables, or does something which
cannot be skipped like this.  Thomas?

> > Did this happen just with PAD A, but not with PAD B?
> Yes, exactly.
> > I don't know how they're supposed to work, but code for PAD A in Hatari
> > looks buggy[1].  Does the attached patch fix your problem?
> I also had a look into joy.c and found exactly the same problem and have
> made exactly the same patch :)
> So I can confirm: Your patch is working fine!

Good, it's now commited.

> > [1] Cross-posting to hatari-devel.  Joy_StePadMulti_ReadWord() code
> > 
> >      looks even more suspicious than Joy_StePadButtons_ReadWord()
> >      code.  Could somebody knowing what it should do, comment on
> >      whether masks & shifts between PAD A & B have been verified
> >      / tested to be correct?  What game uses that interface?
> You can use Tautology II from Reservoir Gods to test it. It uses the
> following buttons:
> Fire A, Fire B, Fire C, Option. These buttons all work fine. Haven't
> tested the pause button yet.

Ok, this uses both functions.  I change the nData to Uint16
just in case.

> > It seems that Jagpad number buttons [2] aren't supported by Hatari, but
> > I assume it's otherwise same as STE joypad.
> > 
> > Does that answer your question?
> Yep, thanks.
> > [2] Only thing I know from jagpad, I just read from here:
> >
> > tick_Ports_FAQ
> Thanks for the link. Very informative.
> >> Not a problem with the emulation, but a question about the F12-GUI:
> >> Would it be possible to introduce keyboard shortcuts so that it is
> >> possible to navigate the GUI without a mouse? That would be cool.
> > 
> > What kind of additional shortcuts you were thinking of?
> Atari style ones :)
> One letter in a button is underlined. That button can be pressed with
> Alt-<letter>.

I looked into button shortcuts as they turned out to be fairly simple
to do, I commited support for it.  Shortcuts are single letter, no
modifier key is needed.

For now, only the main view buttons have shortcuts.  This allows
viewing the settings, changing them would still require mouse.

E.g. being able to fully use fileselector in SDL GUI is something
that probably would need quite a lot of work.

> Or be able to move between buttons with arrows and select with space as
> was already suggested by someone else.

This would require adding focus handling.  The indicator
for focus does not fit into 1x zoomed GUI, even adding
the shortcut key indication was so-so (with smaller font,
I needed to add it outside the button).

> I know there are already the shortcuts you mentioned (yes, I did RTFM
> before asking :)), but as soon as a GUI dialog opens, I need a mouse.
> Since I run the emulation on my HTPC in the living room, it would be
> nice, if it worked without a mouse. It's not that important, just an
> idea.

From the change I did, you can see how to add keyboard shortcuts
for other buttons.  Patches are welcome.  :-)

	- Eero

Mail converted by MHonArc 2.6.19+