UAE has been forked since the original author seems to have disappeared and the WinUAE developers have gone out of their way to try to make their updates not work on unices. This updated UAE is a port of many of the new features found in WinUAE, including networking and the new JIT-core for x86.
Created attachment 23747 [details] app-emulation/uae-0.8.23_pre20040107.ebuild
That 20040107 release wasn't really a 0.8.23pre, it was stil 0.8.22 based. A new, 0.8.23 based source is available from Richard Drummond's website. Just having a look at that ebuild, there's still stuff there only relevant to the 'old' UAE, e.g. most of the myconf stuff and the threads/scsi bit. All you need to compile the 'new' UAE is ./configure --enable-jit --with-sdl-gfx --with-sdl-sound I'm no ebuild expert but I might take a look at this later when I've got time.
Created attachment 24450 [details] New UAE ebuild OK I've modified David Holm's ebuild to better reflect the way Richard Drummond's new UAE works. It's crude, but then I'm no ebuild expert, in that it forces you to use SDL, but then UAE works best when you do this anyway. This ebuild builds a JIT-enabled binary - the new UAE may do this by default if you don't specify it but I'm not sure. GTK2 will be used for the GUI if it's installed on the system. I don't know what minimum version of GTK is required. I also saw the AMD64 'bug' filed, so I added in ~amd64 to the allowed archs, don't know if it compiles though.
Calling the ebuild 0.8.22_20040107 is not allowed by portage, and 8.22_pre<date> is not legal which is why I used 0.8.23. It really is 0.8.23_pre<date> since it is based on the WinUAE 0.8.23 sourcecode. Forcing JIT is not a good idea either since the configure script autodetects it. It might break the ebuild on non-x86 archs where the JIT-compiler isn't available. Thanks for the update.
According to Richard's website, the 20040107 release is still based on 0.8.22. The releases in the last 2 days are the first ones based on the 0.8.23 WinUAE source tree. To quote the man himself: "UAE-0.8.23-20040125 released My first release based on WinUAE 0.8.23 is now available for download. Lots of new stuff and bug fixes in here including improved Picasso96 emulation, support for raw key-mapping when built against LibSDL, and support for building the GTK+ GUI against GTK+ 2.x. Binaries for all the usual suspects will be available as soon as I can build them." I'm no ebuild expert, so I am not too familiar with the naming/numbering conventions used, but I understand what you mean about calling it 0.8.23_pre so tha it would supercede the existing uae ebuild. Fair comment w.r.t. JIT - however, the only architecture that would be affected by JIT causing problems would be amd64, which I suppose could be removed from the ebuild, since both x86 and ppc (which is what Richard actually develops the new UAE on) work fine w/ JIT. It would be good if this got into portage proper; Richard's updated UAE is vastly superior to the old one in every regard.
I tried compiling it with --enable-jit on my PowerBook but it just disabled it by default. ./configure --help says that it only works on x86 anyway. Berndt Meyer was/is working on a JIT for ppc but I don't know if it will ever be released :(. JIT should work on amd64 though since they are binary compatible with x86. I didn't want to add the ebuild to portage since I'm not part of the games herd. But unless someone wakes up soon and finds this bugreport I might do it myself anyway.
Sorry, you're right, I didn't realise JIT didn't work on PPC. I just looked at Richard's homepage there - I assumed that since he developed on PPC, he'd have JIT working on that. At least the config automagically disables JIT on PPC. I saw the other bug report from the amd64 team requesting that it be added to the arch list, maybe someone there could confirm JIT works, afaik the JIT engine uses a fair bit of x86 ASM. I don't think we'll be seeing anything from Berndt again, and with the amount of abuse he and Brian King got thrown at them I can't blame them.
I added a slightly modified version of your new UAE ebuild for version 0.8.23_pre20040129. Please test it and let me know how it works for you.
David It's great to finally get this into portage. I know I said it was crude to force SDL, but it's also good. The binary built using your new ebuild doesn't use SDL - even though it's in my USE settings and installed. Maybe editing the ebuild to use the myconf="--with-sdl-sound --with-sdl-gfx" configuration if you have SDL installed. AFAIK you need to explicitly call SDL at the configuration stage, it doesn't use it by default, even if it is installed. The reason for wanting to use SDL btw is for full sceen switching with F12+S. It 'seems' (I know that's objective) to run smoother, and faster, if the % speed in the bottom right of the emu screen is to be believed, with the ebuild I cobbled up that forces SDL. IMHO for Richard's source, SDL should be made a requirement.
Created attachment 25393 [details] The UAE ebuild I use Just for completeness, here's the ebuild that I use, it's not really any different from the earlier one, just a version bump and pulling the JIT bit out of configuration, but you might want to try it and see if it runs well on your box.
I didn't realise that it didn't enable SDL even though it found it. I added your modification to the ebuild (again ;)... I'm commit it later after I see if I can make it use less RAM while compiling the cpu-core.
Nice one. I didn't realise it was such a memory hog when compiling - although I reckon if you have 256MB ram and 256MB swap you should be OK - I was compiling QT 3.3 at the time and constantly checking memory usage with 'free' - the totals never looked like they added up to more than 512 although I may be wrong.
Apparently it failed on one system, bug #40968.
I wonder what else is being run there. I've just recompiled UAE using my own ebuild, and had a closer look at memory usage using Gnome System Monitor. The max usage I saw was ~460MB of 504MB physical memory, and ~130 MB of 533MB swap used. This was with my system running- X, Gnome 2.4.2/Metacity, Firebird browser 0.7, Gnome SysMon and a Gnome terminal with two windows, one compiling kdebase-3.2.0 and the other compiling UAE. Maybe quitting X, unloading modules, stopping daemons and installing from the command line would enable lower memory systems to compile OK.
I tracked down the memory problems to the compilerflag "-O3". (With "-O3" compilation fails even with 1GB of memory and 2GB swap space) I suggest: inherit flag-o-matic replace-flags "-O3" "-O2"
Ok, I have commited the suggested fixes. Please test the ebuild as soon as it has been spread to your local rsync mirror. (I didn't bump the revision)
FWIW I use -Os compile flags which might explain why the memory usage is a bit more sane (?) here.
David Booted into plain Gnome and tried your ebuild - 401MB max used here, and 0 swap. Your ebuild uses SDL fine here now, with fullscreen niceness. The enable-scsi-device config option isn't supported (yet?). Hopefully Richard can drag this up to date as well, iirc the old uae scsi support was dependent on a very specific version of cdrecord (i.e. pre cdrtools).
That's probably enough testing. dholm can you close this one please?
Nu bugs reported lately, so I guess the script to reduce memory usage is working well. Closing.
x86 stable, thanks JD and Myckel, all arches done
