JIT still crash ! Prob found ?!?

[Foul]

Just tried with 46.4.513 some icons are still corrupted.(dot icons)

File attached with some dot icons...

Thx

[PeterK]

Ok, I've tried your icons on WinUAE 68020 JIT with OS 3.1 and 3.1.4/3.9, icon.library 46.4.527 (68020) or (TC020), but no problems at all.

Which version of FS-UAE should I test? I've never done that yet. Where to download? But I don't have any CF cards or similar disks, only HDF or Windows drawers. Which filesystem exactly? Btw, what is your host system for FS-UAE?

[Foul]

i'm using FS-UAE 3.0.3 from Frode's PPA (https://fs-uae.net/download-devel#ubuntu)
but it happens with old version too...

Filesystem : PFS 3 from Toni Wilen (Author of WinUAE) : http://aminet.net/package/disk/misc/pfs3aio

My host : Linux KDE Neon x64 : based on Ubuntu/Debian LTS/Stable (https://neon.kde.org/)

is happens too with a copy of my CF cards on a simple file , done with command "dd" on Linux

fs-uae config file to load the "hard drive" : hard_drive_0 = AmigaHD_WHDLoad_Update_08-12-2018.hdf

exemple : with icon 46.4.513 and

JIT ON :



JIT OFF :

[PeterK]

Ok, I can reproduce this issue with FS-UAE and the Blizzard 1260 now. The problem exists since my build 477 when I changed my "ReadPlanarImage" routine. Versions until 476 are working.

This bug does not occur under WinUAE with exactly the same configuration (Jit ON) and also not on FS-UAE without the 1260 card, but with a simple 68020 CPU. Strange!

I will try to find the exact reason for this issue tomorrow.

[Foul]

Excellent !!!

[Toni Wilen]

Perhaps it is simply JIT direct being active with 1260 which isn't JIT compatible due to maprom mirror space. (None of accelerators with maprom can't be used with JIT without weird and unexpected side-effects) EDIT: Not just maprom but 1260 having multiple memory aliases. 2060 or CSMK3 or similar that uses normal memory mapping is more "compatible" option.

[FrodeSolheim]

Originally Posted by Toni Wilen

Perhaps it is simply JIT direct being active with 1260 which isn't JIT compatible due to maprom mirror space. (None of accelerators with maprom can't be used with JIT without weird and unexpected side-effects)

@Foul can you try with option

jit_memory = indirect

[Foul]

it's already set !

jit_compiler = 1
jit_memory = indirect
uae_compfpu = 1

With direct : fs-uae can't work :

[FrodeSolheim]

Ah, right, forgot about that check

[FrodeSolheim]

@foul Can you send me a minimal and self-contained .hdf which exhibits the problem? If so, I'll try to reproduce here.

[Foul]

Done, uploading and sending you url in PM

modify the Default.fs-uae hard_drive_0 = /mnt/Amiga/Downloads/WORKBENCH/ to match your system.

if you want to test with a good system:

- edit the startup-sequence, remove icon.library from the Blizkick line (redit in C: to edit)
- rename icon.library44.543 to icon.library
- Boot

[FrodeSolheim]

The good news is that it looks like it's working in the upcoming FS-UAE version

(After disabling maprom and blitzkic to get it boot; "UAE Maprom and accelerator board emulation are not compatible")

[Foul]

The goal for me is to use the same system (CF card) under my Real Amiga and FS-UAE

[PeterK]

This issue seems to be a timing problem, maybe because I load the complete icon data with an unbuffered Read() from the filesystem all at once into memory, and that may happen asynchronously to the CPU on the blizzard 1260 card. I don't do any Flush() or CacheClearU(), but this works with a 68060, just not with the blizzard 1260 card.

The blizzard CPU tries to read icon data from memory before the Read() (DMA ?) has finished copying. When I add a few useless instructions before the data access takes place, this delay causes the issue to disappear and most icons are loaded correctly again (some very large icons would need additional delays at other locations in the code).

The first instruction that tries to access the data in memory is a MOVEM.W 4(A1),D0-D1, which should sign-extend the data from word to long. I need the icon width and height as longwords in D0 and D1.

I'm not sure if the 1260 code really does this correctly under racing conditions, because inserting MOVEQ #0,D0 and MOVEQ #0,D1 above the MOVEM.W fixes the bug already, but two MOVEQ #-1 won't do it, although the delay should be the same.

[FrodeSolheim]

Interesting, it could make sense that it is timing sensitive - and not a bug with the JIT compiler: As mentioned, the icons seem to work in the upcoming FS-UAE versions. So I quickly tried to backport the JIT compiler from the current development code of FS-UAE to v3.0.3, but the icon problem remained. So in any case, it isn't solely dependent on the JIT code...

[Foul]

at least I would have put my finger on something ... and it's been a while that lasts

My first post concerning my prob was http://eab.abime.net/showpost.php?p=...postcount=1742

22 November 2016, 15:39

[PeterK]

I've checked the "MOVEM.W 4(A1),D0-D1" again, using my original code now without delays from additional instructions, but changed the following calculations with D0 and D1 from longword to word size, and that works too.

Conclusion: there is something going wrong in the MOVEM.W sign-expansion from word to long at least for data registers in the 1260 JIT code. Maybe the sign or the N-flag in the condition code(1) is not updated from the lower word, read or correctly expanded into the upper word of the data registers (not tested with address registers yet).

Btw, how can I set the FS-UAE CPU to fastest possible speed like in WinUAE?

And, 3 times already, I had some problems with my mouse when I clicked on Start in FS-UAE. I could not move the mouse in Windows anymore, which has never happened anywhere else yet. Seems that FS-UAE is blocking the mouse driver sometimes.

(1) Sorry, but MOVEM doesn't change the condition codes.

[Foul]

uae_cpu_speed = max

[FrodeSolheim]

FS-UAE already runs at max speed when emulating 68030, 68040 or 68060.

@PeterK FS-UAE is supposed to grab the mouse by default. You can release the mouse by middle-clicking / Alt+G, and you can also use the options initial_input_grab and automatic_input_grab to control when the mouse is grabbed.
If the behavior seems buggy, please tell me more about the mouse problem.

Anyway, regarding the possible JIT bug, since it seems to not occur in the in-progress development version, I suggest we wait and do more testing when the next development release is out.

[PeterK]

Originally Posted by Foul

uae_cpu_speed = max

and @FrodeSolheim

Thanks, I've totally forgotten that Foul's HDF configuration runs on PAL without FBlit from slow ChipMem.

Ok, I will wait with further testing until your next FS-UAE release.

Concerning the mouse, it just freezes completely sometimes, but rarely. Then I cannot move it in the emulation, nor in the Launcher, nor in Windows. It behaves like being dead and this happened only when I clicked onto "Start". I had to restart Windows. It's a Logitech cordless mouse, but uses the normal MS HID USB mouse driver.