English Amiga Board - New FS-UAE branches with updated emulation code from WinUAE

English Amiga Board (https://eab.abime.net/index.php)

- support.FS-UAE (https://eab.abime.net/forumdisplay.php?f=122)

- - New FS-UAE branches with updated emulation code from WinUAE (https://eab.abime.net/showthread.php?t=85313)

Quote:

Originally Posted by FrodeSolheim (Post 1322174)

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.

Sounds like a possible workaround for the issue.

Quote:

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.

It seems to skip escape sequences, those starting with ESC[ and 0x9B, but why? Maybe ask Toni about this?

Quote:

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.

The variable set is called pc, which seems to indicate clipboard text which is already in PC format (maybe if text copied from Amiga is in CR+LF notation, CrossDOS or from PC emulator on Amiga).

Quote:

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?

Best idea is probably to ask Toni about this or check the commit when he introduced this.

Quote:

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.

This library from my links above seems to fulfill all requirements:
https://github.com/dacap/clip

It supports text and images and is available for Windows, MacOS and Linux (X11). Is it worth a try in your eyes?

BTW, what about bsdsocket.library? It's the last thing besides pcem stuff which is missing, if I'm right? I will do a PPC test with OS3.9 again to see it's still slow.

EDIT: PPC test done. Still slow as hell. But look at output, PPC CPU is detected as 71MHz!

ADoomWOS 1.7 (07.11.2000)

ADoomWOS parameters are:

-forcedemo -maponhu -rawkey -rotatemap -chunkyppc -music

CPU is PPC604e running at 71 MHz
Bus clock is 196 MHz.

DOOM 2: Hell on Earth v1.10

EDIT2: Did secondary test with FS-UAE 2.8.3 stable (it's slow as hell as well, so it might be also an issue with my PPC config, instead of FS-UAE, will try on WinUAE with wine):
ADoomWOS 1.7 (07.11.2000)

ADoomWOS parameters are:

-forcedemo -maponhu -rawkey -rotatemap -chunkyppc -music

CPU is PPC604e running at 540 MHz
Bus clock is 135 MHz.

DOOM 2: Hell on Earth v1.10

EDIT3: WinUAE reports 540MHz, too. But speed sucks here, too. So it is NOT a FS-UAE problem. Guess I fucked up my PPC config somewhere.

Quote:

Originally Posted by BastyCDGS (Post 1322186)

This library from my links above seems to fulfill all requirements:
https://github.com/dacap/clip It supports text and images and is available for Windows, MacOS and Linux (X11). Is it worth a try in your eyes?

It looks like a good alternative (except for not having support for Wayland). But I don't see myself prioritizing doing work on clipboard images any time soon.

Quote:

Originally Posted by BastyCDGS (Post 1322193)

BTW, what about bsdsocket.library? It's the last thing besides pcem stuff which is missing.

Working on it. (There are also other problems, like fastest-possible-mode not being fast, graphics cards other than uaegfx not working, and mouse integration is also broken, I believe).

Quote:

Originally Posted by FrodeSolheim (Post 1322194)

It looks like a good alternative (except for not having support for Wayland). But I don't see myself prioritizing doing work on clipboard images any time soon.

Image support hasn't high priority for me, either. BTW, is formatted text supported? Didn't test that yet.

Quote:

Working on it. (There are also other problems, like fastest-possible-mode not being fast, graphics cards other than uaegfx not working, and mouse integration is also broken, I believe).

I could test other gfx cards, but I'm missing the DEVS:Monitor drivers. I would then test gfx cards both on OS3.9 and OS4.1. Is there other stuff I can test for you?

I've pushed a commit fixing and re-enabling bsdsocket.library, so you can help test that :)

It probably does not work with uaeboard indirect mode, since I've not made sure that the new trap_* functions (e.g. trap_put_long) are used in all places, but hopefully it works fine in regular/old mode. I've just done a basic test using AWeb to load a web page (worked).

(Oh, and it looks like FS-UAE crashes if software such as AWeb tries to use bsdsocket.library without the FS-UAE option bsdsocket_library enabled. I've not investigated that yet)

Quote:

Originally Posted by FrodeSolheim (Post 1322231)

I've pushed a commit fixing and re-enabling bsdsocket.library, so you can help test that :)

Works for OS3.9. AWeb was successfully tested using a short Google search.

Quote:

It probably does not work with uaeboard indirect mode, since I've not made sure that the new trap_* functions (e.g. trap_put_long) are used in all places, but hopefully it works fine in regular/old mode. I've just done a basic test using AWeb to load a web page (worked).

Correct, OS4.1FE crashes at boot phase. Even with bsdsocket disabled. Can't boot into it anymore. Logs attached for that!

EDIT: bsdsocket.library under OS4.x isn't supported in WinUAE itself, too. But it doesn't crash on boot when it is enabled.

I removed the list because it isn't useful. First of all, I can run grep myself ;-) But most importantly, only a (relatively) few put_longs should be replaced. And also, put_longs was just an example, there are other similar functions which needs replacement. There is no quick fix, just tedious work...

Quote:

Originally Posted by FrodeSolheim (Post 1322265)

Have deleted the obselete post. In the meanwhile I tested uaesnd with AHI trying to play the test sound in the prefs. No audio output, but no crash either. Logs attached!

With latest git patch, I get crash with OS4.1FE when clipboard_sharing is enabled. Logs attached.

Clipboard sharing works in WinUAE with OS4.1FE. Previous OS4.1FE related crash report because of enabled bsdsocket.library could be actually this cause instead.

Booting OS4.1FE with bsdsocket.library enabled doesn't crash at least now.

So, finally tested x86 bridgeboard emulation a bit.

Good message! It works pretty good.

The main difference I found, when x86 CPU crashes in fs-uae that restarting PC emulation freezes Amiga completely, while WinUAE gets into display hassle for a short time but doesn't hang.

Also I noticed a crash when I'm rapidly moving the edit cursor in MS-DOS 6.22 EDIT.COM.

I've attached logs for a small session where I did extract some files via PKZUNIP.EXE from bridgeboard floppy to harddisk and then starting EDIT to cause the above mentioned crash and finally try to restart PC Color from WB with the freeze.

Overall, excellent work! Thank you very much, Frode!

:great Been testing bridgeboard emulation a bit this evening as well, and starting working on getting vga output working (and at the same time get Picasso cards working again). Not working yet, but probably soon :)

I've pushed fixes for Picasso / RTG cards. Picasso II-IV works again both in classic AmigaOS and AmigaOS 4 (Also, the VGA card for bridgeboard "works", I'll push code soon with keyboard actions for allowing to switch to the VGA display).

EDIT: Shortcut (Mod+F9) commit pushed. Also, the VGA RTG display has some flickering issues (double-buffering-related, I know about it. Epileptics may want to steer clear until it has been fixed).

Yay, Picasso IV OS4 works. a2065/slirp works as well. :great

Do you have any plans to update the config of the A4000/OS4 amiga_model to use all the new bells and whistles like directory hard drives and uaegfx? Or maybe create a new one to preserve compatibility...?

Quote:

Originally Posted by jbl007 (Post 1322798)

Yay, Picasso IV OS4 works. a2065/slirp works as well. :great

Quote:

Originally Posted by jbl007 (Post 1322798)

Do you have any plans to update the config of the A4000/OS4 amiga_model to use all the new bells and whistles like directory hard drives and uaegfx? Or maybe create a new one to preserve compatibility...?

Haven't put that much thought into it, but might not need a new model. If the user chooses to use a directory hard drive, I can just add the necessary uaeboard configuration automatically. The same kind of applies to UAEGFX - if the user chooses that as graphics card instead of Picasso IV, I'll just make sure it works.

(Does UAEGFX work out of the box in AmigaOS4.1 without driver installation btw? I haven't had time to test AmigaOS4.1 with UAE expansions yet. Maybe I'll do that now...)

Quote:

Originally Posted by FrodeSolheim (Post 1322805)

If the user chooses to use a directory hard drive, I can just add the necessary uaeboard configuration automatically. The same kind of applies to UAEGFX - if the user chooses that as graphics card instead of Picasso IV, I'll just make sure it works.

That sound like a plan.

Quote:

(Does UAEGFX work out of the box in AmigaOS4.1 without driver installation btw?

Haven't tried yet. According BastyCDGS it does. http://eab.abime.net/showpost.php?p=...2&postcount=68

Quote:

Originally Posted by jbl007 (Post 1322806)

Haven't tried yet. According BastyCDGS it does. http://eab.abime.net/showpost.php?p=...2&postcount=68

From all what I tested, the only remaining issue with OS4.1FE is the segfault at boot when clipboard sharing is enabled.

Mouse integration is fine till now, too. :)

UPDATE: Had a graphics corruption with OS.41FE right now, window border stuff and background was garbarged after opening a few screens and switching to DiskMaster2 from Utilities directory.

Comparison to WinUAE within wine showed total freeze of emulator at exact almost the same situation. So behaviour is different, but FS-UAE is more stable. Strange stuff!

Good evening, Frode!

Tested Bridgeboard A2386 now. Installation of MS-DOS 6.22 works fine except one thing:
x86 IDE controller hardfile doesn't work anymore after very fresh install of DOS and after a complete emulator restart.

It either says if trying to boot from, that no boot sector is there. And if I try to boot from floppy DOS, fdisk recognizes the harddrive and capacity, but can't write on it. It seems to work only with very fresh created hardfile.

I double checked with WinUAE, it boots fine there from HDD.
Logs attached including A2386 BIOS settings (HDD is set to 41 (AUTO)). Shadowing enabled and both floppies set to 1,44MB.

EDIT: Strange, when I set geometry to 1024 cyls, 16 heads and 63 sectors and enable RDB mode, it starts to work. Also set that geometry manually in A2386 BIOS.

Good morning, Frode!

I just tried to build latest git with LTO enabled and optimizations for my native CPU (AMD Bulldozer first generation). It builds fine until the final link stage.

I configured build as:

Code:

./configure CFLAGS='-flto -march=native -mtune=native' CXXFLAGS='-flto -march=native -mtune=native' CPPFLAGS='-flto -march=native -mtune=native' LDFLAGS='-flto'

Error at end:

Code:

basty@cdgs-basty:~/src/fs-uae$ make -j16

make  all-recursive

make[1]: Entering directory '/home/basty/src/fs-uae'

make[2]: Entering directory '/home/basty/src/fs-uae'

g++ -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -DLUA_USE_POSIX -pthread -I/usr/include/mirclient -I/usr/include/mircookie -I/usr/include/mircore -I/usr/include/AL -I/usr/include/libdrm -I/usr/include/libpng16 -D_REENTRANT -I/usr/include/SDL2   -fno-strict-overflow -fno-strict-aliasing -Wmissing-declarations -Waddress -fvisibility=hidden -I/usr/include/mpeg2dec -flto -march=native -mtune=native -no-pie  -flto -o fs-uae src/fs-uae/config.o src/fs-uae/config-accelerator.o src/fs-uae/config-common.o src/fs-uae/config-drives.o src/fs-uae/config-graphics.o src/fs-uae/config-hardware.o src/fs-uae/config-model.o src/fs-uae/config-paths.o src/fs-uae/config-sound.o src/fs-uae/input.o src/fs-uae/joystick.o src/fs-uae/keyboard.o src/fs-uae/main.o src/fs-uae/menu.o src/fs-uae/mouse.o src/fs-uae/paths.o src/fs-uae/plugins.o src/fs-uae/recording.o src/fs-uae/uae_config.o src/fs-uae/video.o src/ppc/ppcd.o src/sndboard.o  src/moduleripper.o  libuae.a libcpuemu.a libfsemu.a  libmanymouse.a libglad.a  libpcem.a  libudis86.a  libprowizard.a  -lm -ldl     -lgthread-2.0 -pthread -lglib-2.0 -lopenal -lGL -lpng16 -lz -lSDL2 -lX11 -lz  -lmpeg2 -lmpeg2convert

src/sana2.cpp:172:8: warning: type 'struct asyncreq' violates the C++ One Definition Rule [-Wodr]

 struct asyncreq {

        ^

src/uaeserial.cpp:116:8: note: a different type is defined in another translation unit

 struct asyncreq {

        ^

src/sana2.cpp:176:19: note: the first difference of corresponding definitions is field 's2p'

  struct s2packet *s2p;

                   ^

src/uaeserial.cpp:120:6: note: a field with different name is defined in another translation unit

  int ready;

      ^

src/scsiemul.cpp:49:8: warning: type 'struct devstruct' violates the C++ One Definition Rule [-Wodr]

 struct devstruct {

        ^

src/uaeserial.cpp:123:8: note: a different type is defined in another translation unit

 struct devstruct {

        ^

src/scsiemul.cpp:50:6: note: the first difference of corresponding definitions is field 'unitnum'

  int unitnum, aunit;

      ^

src/uaeserial.cpp:124:6: note: a field with different name is defined in another translation unit

  int open;

      ^

src/blitter.cpp:81:15: warning: type of 'cycle_line' does not match original declaration [-Wlto-type-mismatch]

 extern uae_u8 cycle_line[256];

               ^

src/custom.cpp:277:8: note: array types have different bounds

 uae_u8 cycle_line[256 + 1];

        ^

src/custom.cpp:277:8: note: 'cycle_line' was previously declared here

/tmp/ccqStKra.ltrans0.ltrans.o: In function `sb_get_buffer_emu8k(int*, int, void*)':

<artificial>:(.text+0x1d3c8): undefined reference to `emu8k_update(emu8k_t*)'

collect2: error: ld returned 1 exit status

Makefile:3881: recipe for target 'fs-uae' failed

make[2]: *** [fs-uae] Error 1

make[2]: Leaving directory '/home/basty/src/fs-uae'

Makefile:4504: recipe for target 'all-recursive' failed

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory '/home/basty/src/fs-uae'

Makefile:2555: recipe for target 'all' failed

make: *** [all] Error 2

Quote:

Originally Posted by BastyCDGS (Post 1323562)

Good morning, Frode! I just tried to build latest git with LTO enabled and optimizations for my native CPU (AMD Bulldozer first generation). It builds fine until the final link stage.

Morning :) I did some quick fixes to allow for compilation with LTO - pushed!