FS-UAE <= 2.9.x development series

[FrodeSolheim]

Originally Posted by Speedvicio

frode this is the error message for me in fs-uae last dev on linux mint

Hi! I managed to reproduce a similar crash by downloading and running the i386 deb on my AMD64 Ubuntu 12.10 system, so I'm on the case..! (The i386 version does not crash on system it was built, btw).

Do you run the i386 version on a 64-bit OS?

[Speedvicio]

Originally Posted by FrodeSolheim

Hi! I managed to reproduce a similar crash by downloading and running the i386 deb on my AMD64 Ubuntu 12.10 system, so I'm on the case..! (The i386 version does not crash on system it was built, btw).

Do you run the i386 version on a 64-bit OS?

No Frode, i'm running a i386 deb on 32 bit os

This problem appear from first 2.1.x devel release

[FrodeSolheim]

Originally Posted by Speedvicio

No Frode, i'm running a i386 deb on 32 bit os
This problem appear from first 2.1.x devel release

Does this version fix the problem?
http://fengestad.no/fs-uae/devel/2.1...ev3-0_i386.deb

[Speedvicio]

Originally Posted by FrodeSolheim

Does this version fix the problem?
http://fengestad.no/fs-uae/devel/2.1...ev3-0_i386.deb

Great Frode, working perfect

Hi,

I try to follow the compilation instructions (http://fengestad.no/fs-uae/compiling) for windows (win7 64 in my case) and it was not so easy

Here the way i succeeded :

1. install mingw and msys : ok no problem
2. get glib, zlib, libpng and gettext-runtime compiled versions from http://www.gtk.org/download/win32.php : ok
3. unpack them in the mingw directory : ok
4. for SDL, i get the SDL dev version for mingw (http://www.libsdl.org/download-1.2.php) i unpack to my msys users directory (C:\Users\Onaryc\Travail\MinGW\msys\1.0\home\Onaryc) and execute the "make native" command in a msys shell : this was not cleary explain in the compilation instructions
5. extremely important, get the pkg-config tool here http://www.gtk.org/download/win32.php and unpack it in the mingw directory.
6. get the openal-soft from here http://kcat.strangesoft.net/openal.html#download and unpack it in the mingw directory.
7. opengl lib seems to be directly included in the mingw package...
8. If you try now to execute the make command in a msys shell, you will have 2 link errors : one for libpng and the other to openal. I have to rename "libpng14.dll.a" from the lib directory of mingw to "libpng.dll.a" and copy libOpenAl32.dll.a from "lib/win32" to "lib" directory
9. after the compilation succeeded, i copy the "out/FS-UAE.exe" to the last beta installation (2.1.1dev2) and try to execute it, but "libpng14-14.dll" could'nt be found (the libpng 1.4.3 dynamic library) only the "libpng15-15.dll" (i imagine you are using the last libpng version) was there. But after copying the correct file, it worked...

My next moves :
* try compiling with the last libpng lib and understand why i didn't have the "libpng.dll.a".
* run the launcher and learn python
* try to help with the dev (if i find the time )

ok i get the last libpng version (http://prdownloads.sourceforge.net/l...ar.gz?download), i unpack it into my msys directory and i launch the following commands :
./configure --prefix=/c/users/onaryc/travail/MingW
./make check
./make install

After that i "remake" FS-UAE and no more problem relative to libpng...

[FrodeSolheim]

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

• Fix for running from directory with non-ASCII characters on Windows.
• Use mmap to allocate executable memory on non-Windows platforms, fixes segmentation faults with i386 versions.
• Patch amiga-os-130.rom to default A500 rom on demand (3 byte diff).
• Don’t use warning-related compiler options by default, (useful for older compiler versions), enable again with make devel=1.
• Updated translations: it [Speedvicio].
• (Launcher) New setting dialog pages for video, input, scan and experimental settings, common options added to these pages.
• (Launcher) New option to disable use of built-in configurations.
• (Launcher) Can use amiga-os-130.rom as kick34005.A500 for WHDLoad, will patch on demand.
• (Launcher) amiga-os-130.rom, default A500 rom and overdumped default A500 rom can be used together in net play mode (they are all normalized to default A500 rom).
• (Launcher) Use wxversion.select to specifically choose wxPython 2.8.
• (Launcher) Fix for running from directory with non-ASCII characters, and when user’s home directory contains non-ASCII characters.

Originally Posted by Onaryc

Hi, I try to follow the compilation instructions (http://fengestad.no/fs-uae/compiling) for windows (win7 64 in my case) and it was not so easy Here the way i succeeded

Thanks for posting the steps you performed. I know the page currently only contain very high-level instructions. I have linked to your post from the compilation page

[nexusle]

Originally Posted by FrodeSolheim

dd if=/dev/zero of=test.hdf bs=1024 count=32768

This will create a 32 MB file with all zero bytes. Set count to 262144 (1024*256) for a 256 MB file, etc.

This way works too...

For OS X I mean the "Disk Utility" found in "/Applications/Utilities"

@Frode

Does FS-UAE support images that grows with stored data?

[FrodeSolheim]

Originally Posted by nexusle

Does FS-UAE support images that grows with stored data?

Good question! Not officially, but WinUAE seems to support growable VHD files (and the VHD code is included in FS-UAE as well), and the WinUAE lets you create "dynamic HDF". So the answer is: yes, probably.

(A quick glimpse at the code, it seems "dynamic HDF" in WinUAE creates a dynamic VHD file).

[Foul]

is it normal 2 screens are saved with "print screen" key ? i got one "normal" and one cropped...

[FrodeSolheim]

Originally Posted by Foul

is it normal 2 screens are saved with "print screen" key ? i got one "normal" and one cropped...

Yes, this is by design The cropped version could in theory be overcropped (loss of data), but if FS-UAE already automatically zooms nicely, why should you have to crop it manually? The cropped version corresponds to what part of the Amiga display you see. There could have been different keyboard shortcuts etc, but this way is simple and quite foolproof.

The screenshot types have different prefixes so it easy to delete either group if you take many screenshots and want to keep either just the full or the crop versions.

[Foul]

oki

[nexusle]

The cropped image could also be used for in-game-screenshots for the database ;-)

[FrodeSolheim]

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

• New option “mouse_speed” – set mouse speed in percentage(1-500).
• Escape key can be used to navigate back and exit FS-UAE menu.
• Use new state subdirs based on configuration name ny default. New options state_dir and state_dir_name to tweak the new behavior.
• Remove use of “Floppy Overlays” and “Flash Memory” dirs, save files in state directory instead (same as launcher already does).
• Will autoload saved state if “Saved State.uss” exists in state dir.
• Merged updated emulation core from WinUAE 2.5.0beta24.
• New option middle_click_ungrab (can be set to 0).
• Updated translations: pl [grimi], de [nexusle].
• Patch amiga-os-310.rom to default A4000 rom on demand.
• Removed the default slight gamma correction which was applied before.
• (Launcher) Automatically fill in WHDLoad Arguments when zip file is loaded.
• (Launcher) Screenshots/titles/covers don’t need to be put in letter subdirs.
• (Launcher) Use direct subdirs in save states dir, don’t add letter unless an old state dir already exists.
• (Launcher) Added many more options to the settings dialog, including the new mouse speed option.
• (Launcher) Updated translations: pl [grimi], de [nexusle].

The state dir change is not backwards compatible unfortunately, but I think it is for the better, and makes FS-UAE standalone behavior same as using FS-UAE with the Launcher. No data is lost though, old floppy overlays and state files are kept where they are, and they can be moved other to the new per-configuration state dir when necessary. (The per-configuration state dir is created while FS-UAE is running, and is deleted on shutdown if there is no state). If you use FS-UAE Launcher, you should not notice anything.

[rofl0r]

Originally Posted by FrodeSolheim

FS-UAE 2.1.1dev http://fengestad.no/fs-uae/download-devel[*](Launcher) Use wxversion.select to ensure 2.8 is used if also older versions of wxPython are installed.

wait, does that mean i have to have python, wxwidgets, *and* a python wrapper for that, installed in order to compile FS-UAE ?

i was considering adding FS-UAE to my lightweight linux distro, but many dependencies will make that hard or unpractical.

do you have a list of all required compile-time/runtime deps ?

[FrodeSolheim]

Originally Posted by rofl0r

wait, does that mean i have to have python, wxwidgets, *and* a python wrapper for that, installed in order to compile FS-UAE ?

i was considering adding FS-UAE to my lightweight linux distro, but many dependencies will make that hard or unpractical.

do you have a list of all required compile-time/runtime deps ?

No, these requirements are for FS-UAE Launcher only. The library dependencies for FS-UAE are listed here: http://fengestad.no/fs-uae/compiling (SDL 1.2, libpng, zlib, glib (2.24 or newer), OpenAL / OpenAL Soft, OpenGL). Build dependencies are also listed there.

FS-UAE Launcher is pure Python code and depends on Python itself and the following Python extensions to be able to run: setuptools, wxPython, pygame.

[rofl0r]

hmm my distro doesnt have MESA, because it has a lot of dependencies and binary 3D drivers are only shipped linked against glibc ( my distro uses musl libc http://www.musl-libc.org/ ).
so currently it uses only framebuffer, which works well for other (2D) games (gnuboy, openBOR...).

it there a way to make the GL code fallback to SDL when GL is not available ?

[FrodeSolheim]

Originally Posted by rofl0r

Is there a way to make the GL code fallback to SDL when GL is not available?

There is no code in FS-UAE to render to anything but OpenGL, so no, not without writing another video renderer. I do not plan to do this for the foreseeable future.

[Milanchez]

Originally Posted by FrodeSolheim

There is no code in FS-UAE to render to anything but OpenGL, so no, not without writing another video renderer. I do not plan to do this for the foreseeable future.

Frode, but what about OpenGL ES?
Do you plan to implement FS-UAE version for Raspberry Pi?

[FrodeSolheim]

Originally Posted by Milanchez

Frode, but what about OpenGL ES?
Do you plan to implement FS-UAE version for Raspberry Pi?

I don't think I should stretch myself any thinner at this point. I would now rather concentrate on making FS-UAE and related projects better I will implement support for OpenGL ES when/if it is needed, for example if I later port FS-UAE to a device/platform with OpenGL ES.

[yesplease]

Hi Frode,
about the joystick configuration. I learned how to setup a controller file, with the joystick config tool inside the launcher. (unfortunately in osx mountain lion, it doesn't launch anymore, because Apple has deinstalled the default X11 system since this version, but it asks you whether you want to reinstall it at least)

But I have another approach. I assume the most joysticks more or less comply to the default mapping, right? (at least for simple 4 directions and fire). Why not first detect the controller files for the joysticks plugged in and use that for them (as FSUAE does already today), and additionally for plugged in joystick controllers which do not have a controller mapping file, FSUAE can just automatically map them to the most generic default mapping. That way at the end, almost every simple joystick might work out of the box, without having to bother about to specify a controller file.

I saw this for example for the "virtual c64" emulator for osx, which just understands every simple controller you plugged in.

what do you think ?