FS-UAE <= 2.9.x development series

[Foul]

jit_compiler = 1
jit_memory = indirect
uae_compfpu = 1
#uae_cachesize = 8192

Still not starting

[FrodeSolheim]

Originally Posted by Foul

jit_compiler = 1
jit_memory = indirect
uae_compfpu = 1
#uae_cachesize = 8192

Still not starting

Hmm, OK, I just tested your config (even though I don't have the HDs, etc), and it segfaults, so yes, there is some unidentified issue. I'm looking into it.

[Foul]

yes, it's not me

[jbl007]

Originally Posted by FrodeSolheim

I should probably just let the jit compiler silently default to indirect when using Blizzard accelerators

Yeah, conflicting options are a problem... BTW: "fs-uae --amiga_model=A1200/1260 --jit_compiler=1 --jit_memory=indirect" still crashes for me.

I haven't had time to think about lua lately, and how I want it to work, and therefore I haven't look at the pull request in detail. I feel I should think through some stuff in more detail before I can consider it.

Ah, I see, too bad. Perhap some time...

[FrodeSolheim]

Originally Posted by jbl007

"fs-uae --amiga_model=A1200/1260 --jit_compiler=1 --jit_memory=indirect" still crashes for me.

Yes, this is the same problem as Foul has. The cause is easy enough to identify, it's due to Blizzard code allocating a separate memory region for Blizzard memory (> 0xffffffff on x86-64), and the JIT compiler does not like this.

Easy fix is to use my new uae_vm_allocate function with UAE_VM_32BIT flag, but there are some issues with allocating the memory when Blizzard RAM area gets large (256 MB). The easy fix works on my x86-64 Linux box with up to 128 MB Blizzard RAM though.

Better fix is probably to use an available slice of the already reserved memory region, but due to the way the UAE code is structured, this fix is a bit more complicated. I'll have to work some more on this...

[Toni Wilen]

Originally Posted by FrodeSolheim

YEasy fix is to use my new uae_vm_allocate function with UAE_VM_32BIT flag, but there are some issues with allocating the memory when Blizzard RAM area gets large (256 MB). The easy fix works on my x86-64 Linux box with up to 128 MB Blizzard RAM though.

256M goes very high in memory because Blizzard boot ROM is annoying and does not accept it anywhere else even when other smaller sizes can be located in multiple addresses. (due to way SIMMs work)

But because most accelerator emulations are only "meant" for testing compatibility with programs that assume specific drivers, memory locations etc.. I don't personally see much need for perfect JIT support.

[FrodeSolheim]

Originally Posted by Toni Wilen

256M goes very high in memory because Blizzard boot ROM is annoying and does not accept it anywhere else.

That's not the problem, the 256 MB RAM is mapped from (Amiga space) 0x40000000 to 0x50000000 and that would be well within the 2 GB reserved area in this case

The problem was that this memory is separately allocated with xmalloc regardless of whether it would fit within the reserved area or not. Quick fix is to replace xmalloc with uae_vm_alloc(..., UAE_VM_32BIT).

I had some issues allocating an additional 256 MB region on x86-64 Linux. It looks like this issue is a combination of 1: MAP_32BIT flag possibly really means "MAP_31BIT" on Linux, and addresses below 0x40000000 may be reserved (though it does not appear in vmmap listings). And since the 2 GB reserved area is now at 0x50000000 by default on Linux, and there is some existing smaller allocations between 0x40000000 and 0x5000000, uae_vm_alloc fails to allocate 256MB.

I can handle this by making uae_vm_map more flexible and manually "probe" addresses above the reserved region, or move the reserved region higher up (the latter should be easier).

I'll also just need to test a bit on OS X and Windows too, and make sure the code is flexible enough, and that there is enough virtual memory (space) available.

(For the 32-bit versions, this is not a problem, and xmalloc can be used there as before).

[Toni Wilen]

Originally Posted by FrodeSolheim

That's not the problem, the 256 MB RAM is mapped from (Amiga space) 0x40000000 to 0x50000000 and that would be well within the 2 GB reserved area in this case

I thought Blizzard 256M had to be from 0x70000000 to 0x80000000 but it seems I found lower address range that works. (0x70000000 is still used if there is "real" Z3 RAM enabled at the same time. Which is not possible in real world but..)

Anyway, problem was something else, never mind

[yesplease]

Omg, this is really more than simple rocket science. BTW who knows which world is the real one.

[FrodeSolheim]

Originally Posted by jbl007

BTW: "fs-uae --amiga_model=A1200/1260 --jit_compiler=1 --jit_memory=indirect" still crashes for me..

Should be fixed in GIT now (see http://eab.abime.net/showpost.php?p=...8&postcount=58 for information about other fixed JIT issues as well).

Originally Posted by yesplease

Omg, this is really more than simple rocket science. BTW who knows which world is the real one.

Rockets are for wimps

On an unrelated note, QEMU-UAE has been fixed for 64-bit Windows as well now, so the upcoming 64-bit FS-UAE (and WinUAE) versions are soon full-featured

[FrodeSolheim]

Quite a bit of input changes are being implemented for the next version. The current list of input-related changes is:

* Using (Left) Alt as a keyboard shortcut modifier as by default.
* Workaround to allow Alt+Tab to work on non-Windows/non-OS-X platforms.
* Most built-in shortcuts are now configurable.
* Actions for built-in shortcuts are now available for mapping.
* Actions for F11 and F12 (release) can be customized.
* Ungrab mouse and keyboard when entering the menu.

I'm also writing new and improved documentation for everything keyboard related:
https://github.com/FrodeSolheim/fs-u...cs/keyboard.md (if you read this, please let me know if you find errors, spelling - or more serious ones).

One of the main change is introducing Left Alt (Cmd on OS X) as a shortcut modifier key by default, in addition to F11/F12. This allows easier use on keyboards/systems where the F12 is awkward to use. This modifier key will not be usable in (seen by) emulation to prevent issues. This also works well with using Alt+Tab to switch to other windows, as the Alt key press will not be seen by the emulated Amiga. More information in the linked documentation!

Other planned changes include:

* Introduce a shortcut combination to enable "full keyboard emulation". This basically means disabling the Alt/Cmd modifier key so it is usable for emulation instead.
* Introduce a "modifier_key" option to ... you guessed it... choose another modifier key!
* Use low-level keyboard hooks if possible on Windows to suppress some system shortcuts, for example to allow the "Windows key" to be used by FS-UAE.

If you have other gripes about keyboard support in FS-UAE, this is a good time to bring it up

Code is available on githut.com, there will not be a new development release until Sunday.

[Toni Wilen]

Originally Posted by FrodeSolheim

Use low-level keyboard hooks if possible on Windows to suppress some system shortcuts, for example to allow the "Windows key" to be used by FS-UAE.

Why not use RawInput? It supports nearly all keys and combinations.

Hooks are too stupid

[FrodeSolheim]

Originally Posted by Toni Wilen

Why not use RawInput? It supports nearly all keys and combinations.

Hooks are too stupid

If that allows me to suppress key shortcuts, even better I actually have working (disabled) rawinput support already. I used it when FS-UAE used SDL 1.x because I did not get detailed enough key information (if I recall correctly). When I started using SDL 2.x, I was able to use the same SDL-based key handlers on all platforms, but since Windows is not my main system, I probably did not notice any change in Windows shortcut behavior.

[Toni Wilen]

Originally Posted by FrodeSolheim

If that allows me to suppress key shortcuts, even better

Yes, only shortcuts that applications are not allowed to suppress, like alt-tab, ctrl-alt-del are not supported.

RIDEV_NOHOTKEYS flag is the important bit.

[jbl007]

Stealing Amiga's Alt key by default you will people make complain about non-working Alt key, because usually they don't read the docs (Who does this? ) and you will have to answer support questions like "Help, I can't play pinball!" etc. If you can get Windows/Super key to work, perhaps this is the better choice for the Mod key.

If you have other gripes about keyboard support in FS-UAE, this is a good time to bring it up

- allow the use of multimedia keys for action assignment, something like XF86AudioRaiseVolume=action_volume_up could be a pre-configured logical default setting
- many mice have more than 3 buttons, if we could use these...
- an OSD message for action_disk_swapper_next/pref, currently you have to guess which disk is active in the "slot". (perhaps not really on topic here, but thats what I miss)

[FrodeSolheim]

Originally Posted by jbl007

Stealing Amiga's Alt key by default you will people make complain about non-working Alt key

Unfortunately probably true. The reason I'm inclined to choose this key is that it will be used as modifier key anyway by many people (Alt+Tab), and it is nice to remove side-effects from the modifier key. But yes, there would probably be complains, but I already get (other) complaints about the F12 key ;-)

Possible "solutions" (apart from reading the docs, which you point out doesn't really work) include:
- Onscreen message if you press/release the modifier key alone telling you how to enable full keyboard emulation.
- Use the modifier key (alone) to open the FS-UAE menu (then it is at least obvious why the key does not trigger the flipper...) + a visible GUI option for toggling full keyboard emulation.

The most important thing, I think, is that it will at least be configurable, so it won't annoy people too much - as long as people can easily figure out what to do if they don't like the default (?)

Originally Posted by jbl007

- allow the use of multimedia keys for action assignment, something like XF86AudioRaiseVolume=action_volume_up could be a pre-configured logical default setting

I have now included support for "volumeup", "volumedown" and "mute" keys (defaults to the obvious actions, but available for custom input mapping).

Originally Posted by jbl007

- many mice have more than 3 buttons, if we could use these...

Do you mean in combination with custom input mapping? Such as mouse_button_4 = action_something? https://github.com/FrodeSolheim/fs-uae/issues/66

Originally Posted by jbl007

- an OSD message for action_disk_swapper_next/pref, currently you have to guess which disk is active in the "slot". (perhaps not really on topic here, but thats what I miss)

Sounds like a good idea, should be easy to implement.

Btw, perhaps a good use of audio "next track" and "previous track" multimedia buttons is to map these to disk swapper actions by default?

(Warp speed would be another natural action for "next/forward" audio key).

[jbl007]

Originally Posted by FrodeSolheim

The most important thing, I think, is that it will at least be configurable

As long as I can map it to lsuper, I'm happy with it. This should already work now if the window manager does not grab the key by its own.

Do you mean in combination with custom input mapping? Such as mouse_button_4 = action_something? https://github.com/FrodeSolheim/fs-uae/issues/66

Yes. Ah, I knew it has been requested before, but it wasn't me AFAIR. :-)

Btw, perhaps a good use of audio "next track" and "previous track" multimedia buttons is to map these to disk swapper actions by default?

Yeah, I like that. And because actions pref/next alone do nothing perhaps also map the audio-play key to action_disk_swapper_insert_0.

[FrodeSolheim]

A new development version has been released. Changes in FS-UAE 2.7.3dev:

• Support for multimedia keys: volume up, volume down and mute.
• New shortcut Mod+K to toggle full keyboard emulation.
• Using (Left) Alt (Cmd on OS X) as default keyboard shortcut modifier.
• Workaround to allow Alt+Tab to work on non-Windows/non-OS-X platforms.
• Most built-in shortcuts are now configurable.
• Actions for built-in shortcuts are now available for mapping.
• Actions for F11 and F12 (release) can be customized.
• Ungrab mouse and keyboard when entering the menu.
• Added support for reading controller configs from fs-uae.dat.
• Support for creating static / fully self-contained .exe on Windows.
• JIT: Better fldcw_m_indexed fix (can use all x86-64 registers).
• Fixed RSP inc/dec for x86-64, shadow stack space on Windows / x86-64.
• Fix callee-saved registers for Windows x64 ABI.
• Fixed crash when using Blizzard accelerators and x86-64 JIT.
• Respect cpu option when checking for Zorro III config problems.
• Compile with -fno-strict-aliasing to avoid potential aliasing bugs.
• Removed some SDL 1.2 code.

Known issues:

• Opening the F12 menu / Using the modifier key causes FS-UAE to blink on Windows due to ungrabbing input (might have to disable this feature on Windows).

Hi Frode,

On OSX, the issue I raised here: http://eab.abime.net/showthread.php?t=79821 is fixed in the latest development version. Also the mouse grabbing is much smoother when I switch to/from FS-UAE. Thanks!

If I want to transition to 64 bit, what's the upgrade path? Do I need to compile custom qemu stuff to work with the 64 bit binaries? And how to enable JIT? Furthermore what would be the benefit?

Thanks!

[FrodeSolheim]

Originally Posted by esc

If I want to transition to 64 bit, what's the upgrade path?

Just replace the FS-UAE apps with the x86-64 versions, and download the x86-64 versions of the plugins as well (they can be co-installed with the 32-bit x86 versions).

I haven't published the 64-bit versions of qemu-uae yet. I'll try to make that happen tonight

Originally Posted by esc

And how to enable JIT? Furthermore what would be the benefit?

Same as for 32-bit version, use option jit_compiler = 1. Benefit is *much* faster m68k emulation compared to non-JIT version if you want to emulate a high-end Amiga. You don't want to use it if accuracy is the primary goal.