I noticed two things from the installation procedure.
1. After installing E-UAE the default CPU-setting is a 68000 in 24bit addressing mode.
This means that you can't set Z3 memory before you have changed CPU type and addressing mode. Ie. the cpu setting should be done before memory setting in the guide.
2. The installation instructions does not mention P96 memory. But I guess you have to set that as well (I did) or AmiKit probably won't look pretty after startup ;)
Other that that it seems to run. Though E_UAE is horribly slow so it's unusable. (yes I have JIT enabled). The P96 emulation is "slower than superhires 256 color on an unexpanded A1200" to give you some idea.
I copied over my AF2006 p96 setup from my A1 to my PS3 then created a linux flavoured .uaerc file of the same one i use under OS4 The PS3 on face value performs slower than A1XE with OS4. Thats just by watching a few demos like shaft7 etc. Admittedly I've not tried to tweaking any yellowdog or E-UAE settings yet. I don't think i'll try amikit just yet.
Other that that it seems to run. Though E_UAE is horribly slow so it's unusable. (yes I have JIT enabled). The P96 emulation is "slower than superhires 256 color on an unexpanded A1200" to give you some idea.
Which does not help :) I use 32Bit ubuntu and which kernel drivers/modules that are loaded are decided by the Ubuntu package management system, I'm not going to mess with that and risk getting a non updateable system. Besides, everything else runs just fine, including native linux 2d/3d-games as well as wine (such as steam games, hl2 etc).
Edit: Just to be very clear: I do not blaim AmiKit for these problems. It's more likely an Ubuntu and/or (e)uae problem.
Ahh I found out what the speed problems were about. P96 is still rather slow, but the cpu emulation is faster.
The default JIT translation buffer is set to 0 when installing euae. Setting it to 16Kb make it go swoosh. The AmiKit linux install guide might need to mention this.
The emulated amigaos gurus after the amikit wb is loaded however. I haven't figured out what the problem might be on the amiga side, but I'll wait for 1.5 of amikit before doing that.
My install is a clean amikit 1.4 install without any updates or manual changes.
I fiddled around with the JIT settings but every time I got it to a running state (ie non guru after wb has loaded) it goes back to being super slow. Mouse pointer locking up 0.5 seconds every 1 second (every time the clock in the bar at the bottom updates).
These are my jit settings:
Could someone with a fast smooth euae setup post their jit settings please :)
[b]Could someone with a fast smooth euae setup post their jit settings please :)[]/b
Wow, that's the craziest GUI I ever saw. Where did that come from.? It has no reality.. There is no such thing as "JIT" settings for EUAE. It never had a JIT engine developed. I play with AmiKit on the A1 and make changes to work in a non-JIT enviroment. So if i wrong, the cyber police should arrest me. They should arrest that designer of your GUI -- it's a fraud.
I have same settings as you. EUAE (on Linux or anything else) is much slower than the latest WinUAE. WinUAE author should really help EUAE people to port all the latest stuff into EUAE. Because of speed AmiKit, f.ex., is unusable on EUAE when it's usable on the latest WinUAE on the exactly same hardware. (The previous WinUAE was slower.) (I have Ubuntu 8.04 and tested WinUAE on XP. My x86 machine is 32bit.) AmiKit on Linux EUAE is incredibly slow (like slide show). (WinUAE website is not accessible at the moment but I think they made a lot of optimizations to the latest version to make it faster, if I can remember.)
Well I thought the latest WIP4 EUAE had JIT even on PPC and A1 !?!
(Edit: I read this same topic on AmiKit forum just after posting this message here. Nothing new there.)
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
I can remember wrong that PPC JIT thing (and it looks like so).
I found this from UAE readme: "JIT direct memory access only works on Linux/x86 and, by default, you may only emulate up to 32MB of direct ZIII RAM; select more than that and the JIT will fall back on indirect memory access and hence will be slower. This is due to a system limit on the size of a POSIX shared memory segment. You can overcome this limit my modifying the value of the procfs setting, /proc/sys/kernel/shmmax."
Just checked and I have set 128MB of Z3 mem so it's worth to try with 32MB only.
Edit: I changed Z3 RAM from 128 to 32MB and all JIT options from "Indirect" to "Direct" and it's still slow. I hope someone EUAE and JIT expert could give us some hints and suggest some proper settings. (I don't understand anything of these JIT direct and indirect stuff.) I have now:
Byte access - Direct Word access - Direct Long access - Direct Address lookup - Direct Flags - Always generate Icache flushes - Hard Compile through... - Enable JIT FPU - Enable -16384 (max) buffer
(Edit again: I'll take some of my words back !)
I tried to get rid of icons in start menu of AmiKit but couldn't find any related settings. Then I tried to edit sm.prefs file in Utilities/EXTENSION (or was it EXPANSION) and now the taskbar is huge vertically. I don't know how to get it back to normal.
And menus are always problem in AmiKit. It's almost impossible to select anything before the whole menu has disappeared. (At least on slow systems.)
Edited by TSK on 2008/8/5 23:58:57 Edited by TSK on 2008/8/5 23:59:36 Edited by TSK on 2008/8/6 0:45:37
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Already did, (32MB), with no luck. Tried fiddling with the jit settings but just went from, sluggish, sluggishier to guru prone. I've even compiled it myself several times with several different settings and messed about the code back and forth but couldn't get anywhere with it.
I guess that at this point Richard Drummond is probably the only one that can sort it out in a reasonable time frame.
I was really looking forward to playing around with amikit, but ohh well ...
orgin wrote: 1. After installing E-UAE the default CPU-setting is a 68000 in 24bit addressing mode.
That's right: the 68000 has a 16MB address space
Quote:
This means that you can't set Z3 memory before you have changed CPU type and addressing mode. Ie. the cpu setting should be done before memory setting in the guide.
Z3 memory isn't supported unless you emulate a 32-bit CPU.
Quote:
Other that that it seems to run. Though E_UAE is horribly slow so it's unusable. (yes I have JIT enabled). The P96 emulation is "slower than superhires 256 color on an unexpanded A1200" to give you some idea.
The JIT isn't enabled when emulating a 68000. See docs/configuration.txt
The problem seems to be related to how e-uae detects cpu type/cpu-features when using a 64 Bit cpu in 32Bit mode.
Testing on a P4 system (32Bit only) jit runs just fine on Ubuntu 8.04 when using the jit settings in the image of my earlier post in this thread.
To emulate this I removed all 64 bit cpu support from the source tree and changed compemu_raw_x86.c so that a 64 bit cpu isn't detected (A fallback to amd athlon).
The emulation runs faster, but still not fast enough.
This is a message I sent on the amikit beta list:
Quote:
Hello again.
I've been playing around a bit more trying to get jit to work on my 32 bit ubuntu system with dual core amd x86-64 cpu.
I modified the euae code so that a 64 bit cpu can't be detected and removed the 64 bit support files.
It runs a lot faster now (still not satisfactory) and it doesn't make amikit guru at startup. But:
From the code in compemu_raw_x86.c it seems from a quick glance that cpu type isn't everything that controls what e-uae tries to do. The picture is more complex than that. It looks for different cpu features and seemingly uses the features it finds. My wild guess would be that it finds features in the amd 64 cpu that it shouldn't be using in a 32bit system but uses them anyway. The emulated cpu throughput runs fast in batches with small pauses in between, behaving a bit as if it causes the host cpu to invalidate its cache and has to flush it all the time. (Not saying that that is what happens, it just behaves as if that would be the case).
Digging deeper into the code is beyond the scope of the amount of time I can put into it though.
If anyone wants to try the binary then you can find it here:
Note: There's no GUI in it so you'll need to use your existing 0.8.29-WIP4 to change jit settings or edit .uaerc manually.
I can provide my trashed sources if anyone wants them (as per gpl). Though I doubt anyone would find them very useful since I hacked away directly into them rather than bothering with defines and such for the changes.