Some screen corruption with JIT enabled

[Leffmann]

I have a small test-program which occasionally displays some bitplane corruption when the JIT is active in 1.5.3 and the latest beta.

I've inspected the bitplane data and it's valid, the corruption is only visible in the bitmap output. What happens is that there is a blank bitmap line inserted somewhere among the upper 10 lines, and the rest of the bitplane data is offset one line down.

Configuration and exe here:
http://zb.stolendata.net/test.zip

[killergorilla]

JIT has and never will be 100% guaranteed, Toni has always said that.

If it works without JIT I'd consider it fine!

[Toni Wilen]

I can't duplicate.

[Ironclaw]

I never us JIT, no one should. It should ONLY be used if you REALLY need the speed (which should be never, I didn't even use it in 3D games like Genetic Speciec I think, still got full speed).

[Toni Wilen]

How useless reply. (Offtopic warning!)

[Leffmann]

Originally Posted by Toni Wilen

I can't duplicate.

It only appears rarely, maybe 1 in 20 runs. Sorry can't give any more details other than the config file and that exe. The error doesn't persist with state files.

I agree that the JIT shouldn't be used for anything than speeding some processes up. The Workbench is probably the only thing I actually use it for as it makes things very zippy. I wouldn't use it for games or any detailed tests, though I would never expect it to affect the video display emulation.

BTW I noticed another thing while doing some tests. When I switch from fullscreen to fullscreen+v-sync in the display settings, the emulation slows down greatly. It's as if the CPU emulation normally runs in turbo speed during the vertical blanking, and the effect is canceled when you use v-sync. Is this expected behavior?

[Toni Wilen]

Originally Posted by Leffmann

It only appears rarely, maybe 1 in 20 runs. Sorry can't give any more details other than the config file and that exe. The error doesn't persist with state files.

Ah, I have seen similar single black line randomly. Unfortunately it does happen really rarely.

BTW I noticed another thing while doing some tests. When I switch from fullscreen to fullscreen+v-sync in the display settings, the emulation slows down greatly. It's as if the CPU emulation normally runs in turbo speed during the vertical blanking, and the effect is canceled when you use v-sync. Is this expected behavior?

Not expected behavior, currently vsync works as expected only in a500 modes.

[Leffmann]

I found another thing :P

Between vpos $138 and $0 the CPU seems to break the chipset timing. In this interval of 1 or 2 rasterlines I have enough time to do more than 300 000 longword moves from chipmem to chipmem.

I understand this is because this interval will be longer than the real ~64us due to the speed of the emulation, but isn't it possible to limit the RAM access speed here? It would make for more realistic emulation of non-A500 systems.

[Toni Wilen]

JIT = fastest possible, accuracy isn't important. JIT runs in bursts, it can't be told to stop after n cycles, it will run complete translated block until it returns.

JIT directly access all memory, emulation can't detect if it is chip ram or fast or whatever ram access, it completely skips all normal memory accesses for best performance.

Do not use JIT if you want timing accuracy or care about accuracy.

[Ironclaw]

Originally Posted by Toni Wilen

Do not use JIT if you want timing accuracy or care about accuracy.

Exactly.... don't ever use JIT unless you really need to .

When using it I can get crashes, dodgy graphics, failure to load games, sound delay in recordings, sound errors etc etc etc.

But it's darn good to have JIT as an option for when you need to run programs and stuff fast, to try things out....

[Leffmann]

The last example is without using JIT. A plain unexpanded A1200 configuration.

[Toni Wilen]

Originally Posted by Leffmann

The last example is without using JIT. A plain unexpanded A1200 configuration.

Title says "JIT" so..

[Leffmann]

Originally Posted by Toni Wilen

Title says "JIT" so..

You mean I should write a new thread? I thought I could just squeeze that in as well, you see I'm not as orderly as you are

Give us the verdict on the turbo charged CPU and chipmem!

[Toni Wilen]

Originally Posted by Leffmann

You mean I should write a new thread? I thought I could just squeeze that in as well, you see I'm not as orderly as you are

Just mentioning non-JIT mode. Title has highest priority = all posts mean JIT until someone mentions non-JIT. Simple!

Give us the verdict on the turbo charged CPU and chipmem!

Long burst between frames is weird behaviour (not sure how or why, not my code..) but the main problem is CPU caches (again). I can't make chipram as slow as real Amiga (in 68020+ modes) because it would make average speed too slow, especially if code is in chipram and cpu caches are enabled (usually always)

[Leffmann]

Alright I understand it's not easily solved when it depends on the caches. At least this can be fixed programmatically, with a copper interrupt on one of the last lines holding until line 0 things should be fine.

Thanks!