@ChrisH

I am sorry if I misquoted your forum post. My intention was more like a generic comment on the expectations.
I still believe that the 10 times speed-up is not achievable (at least not with the current structure) and the actual speed increase is depending on the executed code highly, so an average 4-5 times faster execution sounds more reasonable.

@LiveForIt

This error usually happens when the program somehow jumps into a random memory address.

I will remove stopping the JIT compiling on this error later on, it is only for testing anyway. But among normal circumstances this must not happen.

Okay, the fix is done. The problem was: in DOS.lib a fix was made for the ExamineDir function, now it returns only those fields in the ExamineData structure which were requested for.

For example in DiskDaisy I only asked for the file name:

APTR context = IDOS->ObtainDirContextTags(EX_StringName, name, EX_DoCurrentDir, TRUE, EX_DataFields, EXF_NAME, TAG_END);

EX_DataFields tag - EXF_NAME only. Yet, obviously I also needed the size and the item type too. Previously these fields were populated by default, now these are only populated on request. So the fix is:

APTR context = IDOS->ObtainDirContextTags(EX_StringName, name, EX_DoCurrentDir,TRUE, EX_DataFields, EXF_NAME | EXF_SIZE | EXF_TYPE, TAG_END);

I will release a new version with this fix soon.

I am pretty sure there will be other apps with similar problem, this was really easy to miss.

Nope. I just found this when I was lazy enough to search in Google for DiskDaisy on OS4Depot... :P

Should I sue? ;)

BTW, a fun fact:

http://www.daisydiskapp.com

There was a bug in 1.1 which might cause that problem. I strongly suggest to update to 1.2.

Thanks for letting me know about this. I haven't updated my OS since update 2.

I will have a look and let you know what I had found.

(No need for donation... :))

Hi everyone... :)

I thought it is time to say a few words to this topic.

You all have nice ideas, actually what you described here is how Petunia works mostly:

1. it runs directly on the compiled code and leaves it only if there was an indirect jump comes to let the system find out the target address code type.

2. It maps all 68k registers to PPC registers in a static layout, the remaining registers are used for any other operations and base pointers.

Why these are not working for E-UAE:

1. the emulation needs some time for emulating the environment, it is not just about the processor emulation only. The execution often leaves the compiled code to let the other routines work. (It happens at every jump instruction for now.)

2. The static register layout seems to be a good idea, but actually there are big trade-offs when it comes to the context switching: all registers must be saved/restored and that is a lot of (often useless) memory operations.
In E-UAE the compiling uses a dynamic register allocation functionality only. A register is loaded from the memory only if it would be used in the actually executed code chunk and will be saved back when the execution leaves the compiled code.
This is much more flexible and does not need unnecessary memory operations whenever any C function is called (like lots of the memory operations for the custom chip access).

Since the macroblock optimization is not implemented yet all instructions are emulated for every aspect (like updating flags, loading modified registers, etc.)
As soon as enough instructions are implemented I will implement the optimization routine, which will eliminate all of the unnecessary macroblocks that produce any results which will be overwritten in the same compiled code chunk.
By this optimization useless register loading, flag emulation and (sometimes) even whole instructions will be eliminated.

@LiveForIt

Offset addresses? What is that? (I don't know how UAE is working internally, so forgive my ignorance.)

@ZeroG

It was not completely native, but only the decoder and some routines were compiled for PPC (avcodec.library and moovidppc.library, namely).

@samwel

Two more weeks. (tm)

@AmiGubbe

When it's done?

@samwel

Quote:

Actually, it outperforms 68060/50MHz on 604/200MHz most of the time and 68040/40 every time.

So, if you have an expansion board with 68040/25MHz and any PPC processor, then the emulated software will be faster than the native 68k execution.

However, OS4 and the JIT emulation requires more memory than OS3.x, theoretically it can run with 32 MB (without JIT emulator), but I would suggest 128MB. (When swapping will be ready then less memory will be enough, but then it will be significantly slower. Oh well, you can't have everything, I guess.)

@Atheist

Why memory protection is important: imagine a program, which is buggy (all programs have bugs) and write into memory at random places. (Becuase it is using wrong pointers or whatever reason, there might be plenty.) If the system has no memory protection (like OS3.x) then it slips unnoticed, even the program might seem to work properly. But it has already placed the mines around the memory, for example it trashed one of the items in the free memory list. You quit the program and go on using your system, then once (when the system reaches THAT exact free memory node): BAAANG, the whole system goes down.

The memory protection won't prevent you doing everything which is legal on the OS. It prevents you doing illegal things. The program, which is not able to cooperate with memory protection MUST GO.
Demo coders must learn how to code system friendly finally. Can you point out any tricks which cannot be done with memory protection? (It's just lazyness, to tell you the truth, why l33t coders are doing such a crappy code.)

The memory protection itself is not slowing down significantly the OS, done by the MMU, the amount of data has to be moved around while task switching is minimal. (On PPC, other processors might have different needs.)

Speaking from experience: memory protection decreased the number of required reboots on OS4. This is a fact. The system is more stable, the badly behaving applications kicked out, even it helps the developers to track down hidden bugs.

Actually, warm reboot on my system takes about 4 secs. Time to turn on UDMA for HDD?

@Jack

I am using this KVM switcher between A1 and PC:

http://www.jaht.com/products/kvm/jcs102pb.htm

I had my doubts when I bought it, but it worth the price, which was fairly low: about 30 EUR.

Picture quality is great, but takes its power from the PS/2 ports, though. I don't use the mouse part, because the converted USB mouse had trouble with it.

The only annoying thing is: for switching I have to push CTRL or ALT twice, and these buttons are often used together with mouse presses in programs, sometimes it just want to switch while I drag icons around with qualifier or so. (I don't know if this happens when I use the mouse port too, probably not.)

@Skov

I have created 1024x768@75 with almost these parameters right now. The only difference was the VSYNCMIN=60. Maybe it worth a try. (I don't know how would that be effect the vsync values, but you can never know.)

One can never get bored in the World of Amiga... :P

@Arnie

Then probably it is not connected to the outside. Anyway, it wouldn't make any difference.

@Arnie

I am pretty sure that your card is dualhead, almost all Radeons are. Don't you have two separate monitor connectors (D-sub15 and DVI)?