UAE JIT BETA 2

@MickJT

ppc.use_tbc=true

I get the same in E-UAE 0.8.28
Timer frequency 66.667069 Mhz.

In Beta 1 I get this:
Timer frequency 0.066670 Mhz.



ppc.use_tbc=false

I get the same in E-UAE 0.8.28
Timer frequency 66.667069 Mhz.

In Beta 1 I get this:
Timer frequency 66.666666 Mhz.

And what about the custom build I sent you? Also, what should the frequency be? I could try to hardcode it in and you could test it.

Edit: I see from your other post, 1800mhz. Can you message me your e-mail address?

@MickJT

I don't know yet, i did have some crashes while testing your SDL version on AmigaOS3.5, maybe its some thing I did, or maybe not.

I will try it again on AmigaOS3.1 as see if it crashes as bad.

@LiveForIt

I was just curious what frequency it showed when running my build which skips AmigaOne & Sam440ep detection and assumes you have one of those machines.

@MickJT

here is the numbers for none SDL version:

use_tbc=true
66.666666 Mhz.
4601 Dystones

use_tbc=false
66.666666 Mhz
4910 Dystones

btw. does sysinfo run without UAE?
(with just Petunia or Trance?)

@KimmoK

Almost, the last version do open a screen, but graphics is rendered wrong.
Text / Font looks correct.

Just after the graphic is rendered it crashes.

http://new.amigaworld.net/modules/new ... post_id=688228&refresh=Go

http://sysinfo.d0.se/

Quote:

stuff like that might explain way,

I don't know what is on address $4000, but if the memory is not allocated it can't work on AmigaOS4.1.

Memory that is not allocated is memory protected, you can't just trash memory at random anymore.

Unless you have a Amiga1200/Amiga4000 there is no classic chips to access.

If he needs timing he most use timer.device not ciaa.resource and/or ciab.resource

@LiveForIt

E-mail sent. I'm not sure how much it will help since the X1000's CPU might need a special version like G5.

For everyone here, please note that I'm not a coder (a tweaker perhaps) and don't contribute to the development of E-UAE PPC JIT, except in the form of testing and reporting problems.

@MickJT

1800Mhz is wrong, it feels like its running 20 times slower then it should, amazing sysinfo result, but its all wrong.

http://support.amd.com/TechDocs/42119_sb600_ds_pub_3.07.pdf

the sb600 manual hints at 100Mhz as the correct value for the real time clock.

@LiveForIt

Another custom build sent to you. Let me know how it goes.

@MickJT


Quote:

Quote:

Here is the result 66.66666 Mhz is correct for X1000.

When I set the clock 100 Mhz, the seconds are longer then they should, on my PC, my analog clock completes almost 2 rotations on the seconds, in the time Clock in Utilities does it.

Next thing that I can say is that this solved the Speed problem.




It now shows Dhystones: 44694, like I think it should but.

There is also some thing noticable wrong whit this build.

* The mouse is now inverted.
* You can also see the Clock looks wrong.




Some questions come to mind.

Does the MacOSX G5 users have the same problems?

Is possible to show how unit test the micro blocks to see that they do what they should, or what we expect?

This way we can narrow down problems, also easily find problems if the code breaks.

Does anyone reading this have a Pegasos2, Cyberstorm PPC or Blizzard PPC?

http://sourceforge.net/p/euaeppcjit/tickets/32/

Run beta 2 with ppc.use_tbc=false, and it will use ReadEClock() regardless of machine type. Check if the detected value is correct.

@MickJT

Michael if i use ppc.use_tbc=false or true for me nothing change everything remain the same (sdl) in performance ...

true:
timebase frequency is 33.333333333mhz

Sysinfo mips: 52 to 54

@MickJT

If timebase frequency is too high the clock in sys:utilityes will be running too slow.
If timebase frequency is too low the clock in sys:utilityes will run too fast.

No point in trying to fix some thing that is not broken, just check that clock works.

@LiveForIt

how to change the timebase frequency ? just for make some tests?

@tlosm

I have beta for X1000 from Mike, as I say no point in changing it unless its broken.

@LiveForIt

Not trying to fix anything that isn't broken. As it is, if ppc.use_tbc is true, beta 2 detects sam440 and AmigaOne (excl. X1000), skips calibration and uses ReadEClock to get the EClock frequency. For other machines, you'll see "Calibrating timebase..." which often gets it wrong.

So, it seems X1000 and Sam460ex can be added to the list.

Did you get my latest email?

@tlosm

I'd been making custom builds with hardcoded values and sending them to him. The problem wasn't that, though. It's instructions that PA6T doesn't natively support.

Check here: http://euaejit.blogspot.com.au/2012/10/jinxed-it-more-apples.html

Something similar needs to be done for the X1000.

About the results you pasted. You have a Pegasos II? I assume it says "Calibrating timebase..." and "Timebase frequency:" if use_tbc is true, and "EClock frequency:" if false?

@MickJT

Testet beta3 now.

Mouse is working again.

44114 Dyrystones.

Graphics in Clock is broken, white circle not rendered correct.

Rise by Mellow Chips crashes.
TBL-Captured drams crashes.

Some things run really well, some demos do not.

@LiveForIt

(Don't call it beta 3. That'll confuse people)

Is this Workbench 3.1 on a hardfile, directory, or an ADF floppy disk image? I want to see if I can replicate what you're seeing.

In post #12, your settings seem to have included comments in parentheses. That won't work.

That's why you're getting:

Option `comp_optimize' requires a value of either `yes' or `no'.
Option `cachesize' requires a numeric argument.
unknown config entry: 'comp_trustbyte=indirect (see Known issues)'

You need to remove the (or higher) and (see known issues) from your .uaerc

@MickJT

Quote:

that was fixed.


There are two difference in my setup

I have:

cpu_type=68EC020/68881
cachesize=16384

I'm going to try to change this two and see if there is any difference