WinUAE 2.4.1 does not boot with attached HD anymore

[Jasmin68k]

Hi!

I recently switched from 2.4.0 to 2.4.1 and noticed that without any changes in my configurations WinUAE does not boot anymore from a directory attached as bootable HD or a bootable hardfile. It just stays there doing nothing showing a black screen.

When I remove the bootable HD from the configuration it starts normally, of course just showing the Kickstart Screen, since it has nothing to boot from.

Switching back to 2.4.0 everything works fine again.

I also tried 2.4.2 beta 4, which does not work either.

Attached you find the bootlog from both versions.

Let me know, if you need any additional info, which might help with tracking down the problem.

[Toni Wilen]

Attach also winuaelog.txt (Enable checkbox in misc panel).
Does latest 2.4.2 beta work?

[Jasmin68k]

From what I can see in the sticky thread the latest beta is 2.4.2 beta 4, which does not work either, as stated in the original post

Logs are attached.

[Toni Wilen]

Oops

Include log using latest beta and last working version, beta includes more HD logging than older versions.

[Jasmin68k]

There you go.

[Toni Wilen]

Does it work if you select 68020 CPU?

68030 (or higher) + cycle-exact isn't fully supported combination when using expansion hardware.

[Jasmin68k]

Yes, it does ...in both 2.4.1 and 2.4.2b4.

Can you elaborate a little more on what the source of the problem is?

Should 68030 + cycle-exact not be used?

And what changed from 2.4.0, when it was still working?

[Toni Wilen]

Originally Posted by Jasmin68k

Yes, it does ...in both 2.4.1 and 2.4.2b4.

Can you elaborate a little more on what the source of the problem is?

Problem is native (x86 C code) threads that need to directly access Amiga memory, bypassing CPU emulator's data cache.

If emulated Amiga program reads some memory location, it gets loaded to 68030's data cache. Following reads from same location reads the data in cache, memory is not accessed.

Things go bad if thread writes new value to above address. Emulated program still sees the original value because cache is not flushed.

Threads bypass the cache emulation because it would add overhead to function that is used very regularly. (each CPU memory access)

There are some simple workarounds but they are not perfect and because 68030 cycle-exact is far from exact, there really isn't any need anyway.

Should 68030 + cycle-exact not be used?

Depends on configuration. It can have problems with expansions that use native threads (filesystem, uaescsi, bsdsocket etc..)

And what changed from 2.4.0, when it was still working?

No idea. Unsupported = It may or may not work. If you are interested, you can try to find which was first non-working beta.

[Jasmin68k]

Thanks for the detailed explanation.

I guess, since 68030 cycle-exact is not that perfect anyway, easiest would be to just leave it off.

BTW I noticed using 2.4.1 that the same configuration with the hardfile as bootdrive, boots faster on 68020 with cycle exact than with 68030 without cycle exact, nothing else changed

Well, whatever, important thing is it works now, thanks a lot!

[CapnJack]

A workaround for this is to just boot up a standard quick config to the kickstart screen (ex A4000), press F12 then load your custom configs with HD attached. Press start and the hangup no longer occurs.