New FS-UAE branches with updated emulation code from WinUAE

[FrodeSolheim]

Originally Posted by jbl007

Nice, seems to work fine now.
Full hd still doesn't work for me, now I have the following available:
1384x1080
1900x1030
1919x1026

I accidentally pushed some test code, will fix

Originally Posted by jbl007

Edit: Just noticed WinUAE sets

z3mem_start=0x40000000

and FS-UAE defaults to

z3mem_start=0x10000000

This depends on config (config, memory allocation (and JIT?) determines whether UAE uses "real" Z3 mapping or not).

[jbl007]

Originally Posted by FrodeSolheim

I accidentally pushed some test code, will fix

No problem.

This depends on config (config, memory allocation (and JIT?) determines whether UAE uses "real" Z3 mapping or not).

No JIT, mapping mode was "automatic" in WinUAE.
Anyway by forcing

uae_z3mem_start = 0x40000000

I get 4k res with 32MB gfx mem, if Z III mem is enabled with FS-UAE. So maybe it's not a bug, just a slight missconfiguration (does this word even exist?).
Looks like Z III mem is essential somehow, at least in auto mode (checked with WinUAE).

[FrodeSolheim]

Pushed a new commit which fixes clipboard sharing (and properly includes 1920x1080 uaegfx resolution).

[Foul]

Why maprom is no longer supported ? can't use Blizkick to load icon.library and many things like my real A1200

[FrodeSolheim]

Originally Posted by Foul

Why maprom is no longer supported ? can't use Blizkick to load icon.library and many things like my real A1200

Not on purpose, probably just another thing to add to the list of things to test, debug, fix?

[Foul]

okay perfect

[jbl007]

Originally Posted by FrodeSolheim

Pushed a new commit which fixes clipboard sharing (and properly includes 1920x1080 uaegfx resolution).

I can use 1080p now, thanks.
Clipboard text sharing works fine, sharing images does not work. It's a windows only feature, isn't it?

Any idea why fastest possible mode is not really fastest possible? CPU usage on the host is close to zero. It's slightly faster with JIT, but not fastest.

[BastyCDGS]

Originally Posted by jbl007

32bit works for me up to 1344x1080. 4k res crashes (not useful anyway). But I miss 1080p resolution. Where does uaegfx get the available resolutions from?

Oh, that's interesting. Do you need to install a special driver or does it work out of the box?

I just copied uaegfx to DEVS:Monitors and ran ScreenMode prefs and selected 1920x1080...i.e. usual stuff.

[BastyCDGS]

Originally Posted by FrodeSolheim

Hmm, strange, it works for me up to about 1920x1020x32, and I supposedly have 16 MB graphics memory. Strange, but will investigate further. Are you sure you get full HD @32-bit color?

Yes, it actually was 1920x1080! I also had Zorro 3 memory enabled, as you know from my logs. Didn't check however, if it was real 32bit. But choosing 16 bit gave me resolution and color corruption (gray became green and right half of screen went mad, but was "usable" in terms of detecting what's going on the screen). 8-bit mode showed only garbage.

[FrodeSolheim]

Originally Posted by jbl007

I can use 1080p now, thanks.
Clipboard text sharing works fine, sharing images does not work. It's a windows only feature, isn't it?

I haven't written code to work with images in FS-UAE, no. Text-only for now.

Originally Posted by jbl007

Any idea why fastest possible mode is not really fastest possible? CPU usage on the host is close to zero. It's slightly faster with JIT, but not fastest.

Yes, I expected there to be problems with this. It has to do with code controlling sleeps, timing, vsync, busywaits etc. There's been a lot of changes to this code since WinUAE 3.2, and I haven't gotten around to look at this area yet (except making sure non-fastest-modes work OK).

[BastyCDGS]

Originally Posted by FrodeSolheim

Hmm, it looks like 1920x0180x32 works if I also enable some Zorro III memory. (RTG RAM is then moved to memory address 0x50000000 - may or may not be relevant, or maybe the graphics driver simply needs sufficient amount of fast RAM?)

I remember from the WinUAE 3.30 beta thread, that the start address of Zorro 3 memory depends on uaeboard settings:
uaeboard = full+indirect

(which become uae_uaeboard = full+indirect in FS-UAE). Not sure if Toni changed the default in some WinUAE update. Better ask him regarding this!

[BastyCDGS]

Originally Posted by FrodeSolheim

Pushed a new commit which fixes clipboard sharing (and properly includes 1920x1080 uaegfx resolution).

Clipboard sharing works fine from Linux to Amiga, however from Amiga to Linux seems to add a CR instead of LF only. Copying from Devpac:

    moveq #0,d0
    rts

becomes pasted in Linux to bash as:

    moveq #0,d0

    rts

Guess some CR+LF conversion issue. Other way around just strips CR, which Linux doesn't care about.

[BastyCDGS]

Just a small note. It might be a good idea to replace rtgmaster.library, etc. with the versions in the latest WinUAE versions, in case something changed. I did this some time ago, when getting my configs to work with WinUAE 4.x via wine.

So maybe this also explains why you had 1080p issues.

[jbl007]

Originally Posted by BastyCDGS

replace rtgmaster.library, etc. with the versions in the latest WinUAE versions

Hm, do you think this is related? rtgmaster.library is at v42.0 and rtg.library is v40.3994

So maybe this also explains why you had 1080p issues.

I think it's because my default desktop resolution is higher, FS-UAE only uses hardcoded resolutions and 1080p was not included.

[jbl007]

Originally Posted by FrodeSolheim

It has to do with code controlling sleeps, timing, vsync, busywaits etc. There's been a lot of changes to this code since WinUAE 3.2, and I haven't gotten around to look at this area yet (except making sure non-fastest-modes work OK).

Ah, ok. At least it's fast enough for now and keeps the CPU fan quiet.

[BastyCDGS]

Originally Posted by jbl007

Hm, do you think this is related? rtgmaster.library is at v42.0 and rtg.library is v40.3994

I think it's because my default desktop resolution is higher, FS-UAE only uses hardcoded resolutions and 1080p was not included.

Strange, I have older than yours (OS3.9). rtgmaster is at v40.

I had 1080p desktop resolution, this might explain why it hadn't issue with that.

[BastyCDGS]

Found another bug with clipboard sharing:
Trying to release input grab with middle mouse button also triggers pasting from clipboard.

[BastyCDGS]

Good morning, Frode!

Did two patches for fixing the CR+LF issue on Linux.

The reason I added the secondary patch is because I'm not sure how to deal with ANSI characters in function amiga2pc.

Please note I don't know about Line ending on Mac and other supported platforms, might need special care, too.

If interested, I can try to port the Windows Bitmap stuff to SDL bitmap stuff, i.e. allow copying images via Clipboard in FS-UAE, too.

[BastyCDGS]

Regarding cross-platform image support for clipboard sharing, just figured out that SDL2 itself only seems to support text.

However, a little research brought those websites, which might help:
https://github.com/dacap/clip
https://playcontrol.net/ewing/jibber...Prototype.html
https://jtanx.github.io/2016/08/19/a...board-library/
https://forums.libsdl.org/viewtopic.php?p=24823

[FrodeSolheim]

(A quick update: the console debugger can now be used on Windows also. That has not been possible in FS-UAE previously).

Originally Posted by BastyCDGS

Found another bug with clipboard sharing:
Trying to release input grab with middle mouse button also triggers pasting from clipboard.

The solution might be to introduce a mouse_buttons=3 option. Without it FS-UAE uses the middle button exclusively (cannot be used for pasting or other purposes) and with it, you need to use the keyboard to release the input grab. EDIT: Added https://github.com/FrodeSolheim/fs-uae/issues/199.

Originally Posted by BastyCDGS

Did two patches for fixing the CR+LF issue on Linux. The reason I added the secondary patch is because I'm not sure how to deal with ANSI characters in function amiga2pc. Please note I don't know about Line ending on Mac and other supported platforms, might need special care, too.

In the old days (pre OS-X), Mac OS uses a third sequence - only CR. Go figure. Fortunately, modern macOS works like Linux/Unix and uses LF.

However, to chose between the patches; What does parsecsi do? Can we safely skip that? (It seems to - on purpose - drop some type of character sequences). Patch 1 looks safer in that regard.

Some of the code in amigatopc seems to be a pass-through (if there already is an CR in the clipboard), bypassing the parsesci stuff also. We might not want to #ifdef away that "pc = 1". Instead keep the passthrough? Optionally also strip the CRs from that string? I don't really know what the use case for this feature is, maybe some Amiga software adapted for the UAE already produces "PC-compatible" (Windows) clipboard text?

EDIT: Pushed a safe (?) version to github.

Originally Posted by BastyCDGS

Regarding cross-platform image support for clipboard sharing, just figured out that SDL2 itself only seems to support text.

Right, I remember now, that's why I left out image support. I'm not really interested in writing lots of platform-specific code for that.