WinUAE - Amiga Emulator Forum

WinUAE

Some may wonder why use WinUAE when you can use E-UAE or another? Well, WinUAE represents the most comprehensive and compatible version of an Amiga emulator. Other emulators lag far behind and sometimes are not even updated. WinUAE is completely under active development.

UAE and E-UAE have not been updated since 2008 and 2007 respectively. They do not hold a candle to WinUAE. WinUAE is the definitive Amiga emulator in terms of compatibility - not speed. WinUAE was last updated to 2.0.1 on December 23rd, 2009 as of this writing.

--

Works great but did take a bit of configuration.

Bottle is Windows XP.

DirectX Used - web installer did not work, this full archive did. Running this archive only extracts the files. You then also need to go to the location you extracted them to and run the installer there to complete the installation. This version of DirectX is confirmed to be required, the "Modern" version included with Crossover Games is not enough.

Configurations need the following at minimum: Host -> Filter, select Direct3D. There is no OpenGL option anymore. Without making this selection performance is not acceptable. If there is a noticeable lag in the audio, this is resolved by going to Host -> Sound and setting Sound Buffer Size to 1 (one). Direct Sound only is required for any audio, others are unnecessary but can be left enabled. Adjust other sound emulation values depending on your particular hardware capability: e.g. with a slow computer turn the accuracy and sample rate down. All other settings to taste and capabilities of your machine.

IMPORTANT!: F12 brings up emulation control menu, workaround if emulation control does not correctly dismiss (pressing OK) for you: In windowed mode, middle-mouse button to un-trap the mouse from the emulation environment then in the window frame where the status displays are, click on the text label: "Power" and this will raise the emulation control menu. Accessing emulation control using this method dismisses properly for me. Emulation control correctly dismissing is important for when you have to swap disk images while emulation is active.

Bill Pickett wrote:

WinUAE

Works great but did take a bit of configuration. Needed to install
DirectX from Microsoft directly as the included "modern" install did
not perform adequately.

[link=http://www.microsoft.com/downloads/details.aspx?familyid=04ac064b-00d1-474e-b7b1-442d8712d553&displaylang=en]DirectX
Used[/link] - web installer did not work, this full archive did.
Running this archive only extracts the files. You then also need to
go to the location you extracted them to and run the installer there
to complete the installation.

Hi,
Thanks for posting this...I haven't looked at this title since the COG-8.0 release,
and the current WinUAE version I have embottled (and to which most of the material relates)
is 1.6.1 -- I knew there were some changes on the horizon for WinUAE and I was probably
deferring things until COG-9.0 was released (I figured WinUAE would've seen it's changes
in place by then as well ;)....looks like I was slightly off in the timing...but you get that...

...I'll check into this directx business - this is something I'd like to know about before
COG-9.0 starts getting bolted together...thanks for the heads-up..

Bill Pickett wrote:

In addition, once installed needed to go to Host -> Filter and
select Direct3D. There was no OpenGL option. Without making this
selection performance was not acceptable.

...this is one of those changes I knew was coming - dropping the opengl support. In linux,
I had been using the (deprecated,unsupported) opengl renderer in WinUAE but I knew it's
days were numbered...

Bill Pickett wrote:

There was also a noticeable lag in the audio and this was resolved
by going to Host -> Sound and setting Sound Buffer Size to 1 and
only selecting Direct Sound and OpenAL drivers. Direct Sound is
required for any audio, OpenAL may be extraneous. Adjust other
sound emulation values depending on your particular hardware
capability: e.g. with a slow computer turn the accuracy and sample
rate down. Other settings to taste.

...I don't think openal support is yet in the COG wine tree, but it did become a fixture
in wine-1.1.31 iirc -- I do have a support ticket lodged wrt getting the devs to look
at considering openal support as part of the feature set for COG-9.0 (a number of other
game titles require openal) - it won't be extraneous if it performs better than dsound...

Bill Pickett wrote:

Some may wonder why use WinUAE when you can use E-UAE or another?
Well, WinUAE represents the most comprehensive and compatible
version of an Amiga emulator. Other emulators lag far behind and
sometimes are not even updated. WinUAE is completely under active
development.

UAE and
E-UAE have not been
updated since 2008 and 2007 respectively. They do not hold a candle
to WinUAE. WinUAE is the definitive Amiga emulator. WinUAE
was last updated to 2.0.1 on December 23rd, 2009 as of this writing.

..indeed, it's one of the main reasons it makes an appearance here in C4...<grin>..

Bill Pickett wrote:

Issues: Function keys to access the emulator menu while running
(F12, F11, F10, F9: One of them, not exactly sure which one as I
don't have Windows to test, - I believe F11 or F12) do not work. So
once emulation is started your only control of the emulation
environment is to quit the application from the window close widget
in your host environment. This may be further complicated if running
in full-screen - you may be unable to quit, I run windowed and I'm
not going to try it. This can create issues when you need to swap
disks such as when installing Workbench or with multi-disk games.
However if in a standard Workbench environment the emulator provides
up to four emulated drives to use at once - these can have disk
images assigned to them before emulation begins. Custom filesystems
such as most games usually can only use one drive. Most of the time
this limitation is not critical and an annoying workaround is either
to use a tool to extract the files from standard Workbench
filesystems (see WinUAE site for UAEUNP) or use a native emulator
such as UAE to get files out of the disk images onto your real hard
drive. This workaround does not work for custom filesystems present
in most games.

...I'll check into this F key mapping as well..I think they were working ok
with WinUAE 1.6.1 but anything may have changed between then and now...

Btw, thanks for the detailed posting!

Cheers!

Hey cool, I didn't expect anyone to be here so fast! I've tracked down a few further things: the function keys were my problem, I had Guake console running, it was grabbing the F12 event before WinUAE so that is why it wasn't working! BUT now the event is not grabbed when I bring up the control panel dismissing it with the OK button causes an endless loop where it keeps popping up! Maybe thats my issue too ;) But the workaround as originally posted, clicking on the Power text, works fine for changing things and dismissing too! Thanks for the help, I will too to the best of my abilities! I think I needed the latest DirectX too, I had the installer anyway so it wasn't an issue to just put it in there: I may have just not set the filter to Direct3d, that may have been my issue too: can you confirm? I could create a new bottle to firmly test it but if you need to get 2.0.1 going for yourself anyway... :D

Edit: DirectX August 2009 required -> Confirmed.
Edit2: All in a new bottle, F12 works now without Guake, bringing up emulation control with F12 has issues when trying to dismiss it for me. Clicking on Power workaround works perfect.
Edit3: Bringing up emulation control with F12 in full-screen works but issue of not dismissing remains.

Bill Pickett wrote:

Hey cool, I didn't expect anyone to be here so fast! I've tracked
down a few further things: the function keys were my problem, I had
Guake console running, it was grabbing the F12 event before WinUAE
so that is why it wasn't working!

..I figured as much, just as soon as I got it installed and found F12 to be working...

Bill Pickett wrote:

BUT now the event is not grabbed when I bring up the control panel
dismissing it with the OK button causes an endless loop where it
keeps popping up! Maybe thats my issue too ;) But the workaround
as originally posted, clicking on the Power text, works fine for
changing things and dismissing too!

..it's always been a bit strange in this area here...in fact, it's actually improved
somewhat over what it was...I think...in my case, I'm always using emulated desktop ON
in winecfg (to avoid smashing into twinview)...because I know setting WinUAE itself up

and< getting the Host settings 'just right' is a lot of the battle here, I usually
define desktop_size larger than need be (in winecfg), and leave WinUAE set at 800x600
and it's a lot easier/saner doing this fooling around. The endless loop business, I could
get out of by clicking reset->restart->quit, which here kills off the emulation and leaves
you with the WinUAE GUI. You can't change anything here (and have it 'stick') unless you
shutdown the emulation first...ie; hit F12 -> reset->restart->quit -> futz with WinUAE
settings etc -> Start (the emulator again)...

(quote:353862)

Thanks for the help, I will too to the best of my abilities! I
think I needed the latest DirectX too, I had the installer anyway so
it wasn't an issue to just put it in there: I may have just not set
the filter to Direct3d, that may have been my issue too: can you
confirm? I could create a new bottle to firmly test it but if you
need to get 2.0.1 going for yourself anyway... :D

....I was going to ask about this anyway...I've never needed directx in the bottle
for WinUAE to work ; that said, I -was- using the old opengl render driver, and so
this wasn't exactly an issue....now that there is no opengl 'filter' {ahem} to
choose from anymore, this may be a requirement if it does anything to improve
the -sound- issue WinUAE now has....

...I've only had a small play with it, without directx runtime installed - the graphics
are fine ; the sound is woeful....what's worse, I know exactly where this is coming
from too => the loss of the opengl render driver. You can easily recreate the issue
too -> install WinUAE 1.6.1 -> use the OpenGL filter -> boot up something music-disky
with lotsa graphics (Sounds of the Gnome ;)...enjoy... -> shut down the emulator ->
now change to the Direct3D filter -> boot up the same disk -> the sound will be woeful
just like it is now in WinUAE 2.0.1 ...

...at the same time, relative CPU usage is also up from a before (with opengl) of about
85% to the now (stuck with Direct3D) 145% -- this, is hitting the sound. With WinUAE 1.6.1
and the opengl driver, I noticed the sound would -start- to fall apart, if the emulation
started hogging 95% or more (of an AMD64 x2 4000+ - 2.11qhz) -- if the inclusion of the
directx runtime improves this any, I've yet to find out...but if these are the sort of
results I'm seeing emulating a bog_standard A500, I'm not very hopeful...more later after
I have another swing at it...

Cheers!

Ok, first post is edited fully for now. Sound works absolutely fine for me, however I have not tested it fully in anything like OctaMED or somthing like that just RoboCod. In my bottle configuration WINE control panel, I have sound set to ALSA, hardware acceleration set to Emulation, default sample rate 11025, default bits per sample 8 and driver emulation enabled. This is mainly because my computer needs these settings with any bottle or I get horrible sound.

Further, in WinUAE, using DSOUND: Primary Sound Driver, Sound Emulation: Enabled (not 100%), Buffer Size: 1, Frequency: 11025, everything else default values.

It's adequate but if you're having issues requires further testing.

This is always my test standard with things UAE ... it's PD, free & legal...

http://www.scene.org/file.php?file=/mirrors/the_scene_archives/The_Scene_Archives_Vol_05/Disks_are_in_Here/Disks_4251_to_4300/4251-Sounds_of_Gnome.DMS&fileinfo

My A500 512/512/full ECS of course has no problems with that musicdisk (nor my A1200)...

My linux E-UAE (last WIP release) has no problem with this either...at least as good as the real A500 (in this case, host CPU load is ~45%)

WinUAE 1.6.1 using the opengl layer is at least as good as the native E-UAE build...it just hogs twice as much CPU slice..

WinUAE 1.6.1 using the Direct3D layer works as badly as 2.0.1 where you have little choice...neither work as good as the above choices ;)

It's a good test, because it pushed the stock A500 right to the limit. I'm not
really surprized this musicdisk refuses to quit cleanly, because on real Amiga
hardware it used to install a wedge of code that made it impossible to warmboot
the Amiga out of the final screen - you had to power the thing off to kill it <grin>
..but the point is, if any incantation of UAE can pull this off cleanly, you're
'in the ballpark' for good emulation performance with most everything else...

I've recently arrived on Linux ;) One of the first things I did was pull E-UAE out of Ubuntu's repositories. It just isn't fast enough in stock configuration on my machine. Doesn't do it. Now perhaps UAE would be better, I haven't the experience with that one! ;) With this build of WinUAE, testing for normal purposes: games appear to run fine. Also emulation modes such as AGA and the cycle-exact A500 and approximate cycle-exact A1200 modes should be much better with this version of WinUAE versus UAE. I say should because I'm not familiar enough with UAE to say for sure! I'm going mainly by the last updated dates on their respective web-sites and WinUAE has well over a years more development than the nearest competition. I'll see if I can dig up UAE, E-UAE I'll have to look up in Synaptic again just to check the version against the official web-site: if it's the same then that ones out. =D

Edit: I'll get that disk and try it out ;)

Cool little disk, Wasserfast reminds me of an old C64 tune from One Man and Droid! Something to keep in mind with this version of WinUAE is that it is all about compatibility. The new cycle-exact mode for the A500 for example. It is an A500! All those edge cases, where most games would emulate fine but you'd have those few that wouldn't: those few now are supposed to emulate fine! It's not surprising that the resource usage has increased as a result, you're getting into diminishing returns but it's been pushed far enough that the edges are working! Compatibility, not speed. Do you need the compatibility or is that good enough for you with UAE and you'd prefer lower utilisation of your machine?

Edit: Sound was fine on my machine and settings. Pentium D @ 3Ghz (Equivalent to a Core 2 Duo 1.8Ghz), 3GB RAM, Ati HD4670, Realtek on-board audio.

Okay...found it....it really doesn't like this combination ;

winecfg with emulate a virtual desktop on + Host->Display set to Windowed

If you're going to use Emulate a virtual desktop, you have to go into
the WinUAE Host->Display panel, and just under the Settings set Native mode:
to fullscreen. The actual resolution is set just above that in the Screen
Fullscreen: dropbox.

Once I found that, I was able to pull the Host->Sound settings back to
default, and sound works fine...

Tried installing directx runtime - didn't improve nor hurt anything.....

When it comes to compatibility versus performance questions, it really
doesn't enter my head -- I'm into realism, I have real Amiga hardware
on hand ... life is just plain too easy for me, huh? (;

Wrt UAE, or specifically WinUAE when used in conjunction with crossover/wine,
it forms a little interesting test case (there's a few about in C4) where we
have a piece of software that has native ports for both Mac/linux as well as
the windows version...and depending on which title it is, one or another port
tends to lead the rest. This being the case, I tend only to look at whether
things work properly or not...and then look at the relative system loads between
the native port and the crossover hoisted windows port, loads observed with
various different settings etc...stuff like this...it's a useful way to check
how crossover's coming along...(bzflag is a better example of sorts, because the
various ports are very close together)...

But it's been fun! Again. I'll double check these results tomorrow just to make
certain directx is indeed optional....and probably hoist a tip&trick about avoiding
running WinUAE 2.x in windowed mode inside an emulated desktop in crossover...which
is new behavior since the 1.6.1 release iirc...

Cheers!

Excellent, glad you found the root of the sound issue! That was something that my config missed ;) Yeah, I wish I still had my A500 with it's big ugly hard-drive and 28Mhz expansion passed-through before the HD, careful about moving the computer while on, might freeze! And my A1200 too, that was a nice little machine, miss it and honestly do not have a clue where it went just have a general time frame for when I lost it. For DirectX, August 2009 is required: when you run WinUAE without it is displays a dialog saying so and doesn't work. Hopefully that info will save you a bit of time. Seems to be pretty well tested for now, thank you for your help!

Just retested installation, twice, without directx installed - no problem, no error message?
Might be a constraint of of your Ati card? (I have nvidia) I get no warning dialogs about
missing directx at all - install and runs 'out of the box' as it were - still seems optional.

From a fresh bottle. When I ran WinUAE is says that August 2009 DirectX (specifically that version) or greater is required. I'd have to make sure on that, I'm sure it said it when I had modern installed. Now I have to wonder, I know I received the dialog so I don't know why you didn't.

Confirmed:

http://eab.abime.net/showpost.php?s=cdafd38e3dd6ece3c72eac83e33e2655&p=624886&postcount=2

Toni Wilen, the author of WinUAE sets the record straight ;)

Edit, Toni is actually the maintainer: see WinUAE page ;)

Edit again: That is in the context of using "filtershaders" so you may be able to squeak by without it but it should be the recommendation as that is what the developers are saying...

Ok, did it all, now ive got everything as it should as in the earlier version. Except........
i have stillthe problem when clicking f12 i cant back to the game/workbench when clicking " ok" i have choose quit, then cancel then everything will exit...... so no progression after all the work here.
Still have the same issue....as the earlier version....but then again, it can be Mac issue.

Does the workaround given in the first post of this thread work? In windowed mode, click on the "Power" text to get the menu instead of F12 and then hopefully when you click OK it will work properly?

Okay...it's actually the Direct3D filter that triggers the directx runtime warning.
If you don't set a filter at all, it still runs fine here without any directx. So
it's not absolutely required, just required if you go flicking filters...and I
guess if you head out to a P96/RTG setup, you'd probably better off with the directx
runtime than not - I'll have to check with the ninjas and see if the directx runtime
package is going to be upgraded in 9.0...

The F12 key works OK for me here, but that's emulated virtual desktop with winuae
in fullscreen mode - if you run things in a different fashion, this may account for
the differences here...

Woow.

This is amazing, I will install WinUAE and see how it works. It would be nice that Codeweavers install WinUAE support in Crossover Games.

Just yesterday I found my AmigaOS 3.9 CD I got for free from Hagge & Partnet when I was part of the Translators Team when AmigaOS 3.5 & 3.9 was developed.

BTW, Probably Codeweavers would like to translate Crossover to other languages. 😉

Regards
Ezequiel Partida
Amiga Translator Organization Member (Or at least I was) Hehe

Hi,

A c4p is on my list of things to do when the installer profiling
system becomes available in CXG.

Cheers!

Thank for your contribution. I highly appreciate your post. It's very helpful.

http://softwareoutsourcing.biz/

Hi,

Thanks for the inadvertent prompt here with this post - I'd
actually reranked this back to bronze with CXG-9.0 because it
suffered from the double-mousepointer-funky thang that was fixed
in CXG-9.1 and I've been a bit tardy getting back here to reflect
that position 8) So it's back up to silver again for me, but it's
probably a bit better than that -- not gold tho' because it's
still a bit clunkier to use (and has the F12 key hiccup on the Mac)
and it actually works a little better in Windows to the point of
those users not seeing the oddities we do...(and it'll never be
as good as a -real- Amiga anyway 8)

Cheers!