Maybe the version on the Pouet download link above is corrupt? I downloaded my copy from there a couple of years ago and it crashed before the second part. I'll let Pouet.net know about the Exotica link so they can change it.

The reason is simple.
The archive contains an invalid Windows name. In the Pouet version this file is missing (therefore it is incomplete).

What I did is change the name of the file in the archive and consequently in the executable (hence the different CRC).
The one I uploaded to The Zone! works unpacked indifferently from Amiga or from the host emulator machine.

:)

I already submitted the link from Exotica to the prod's Pouet.net page, which is:

http://ftp.amigascne.org/pub/amiga/G...e/AND-Yaga.lha

Sorry.

I have changed the Pouet link.

:great

No need to sorry :)
The version in The Zone! is for EAB users convenience only, the original archive is the one on Exotica, so it's all right.

I have found something new about strange issue with " Tek/Rampage " circle scene on A1200 emulation.

Note: State file on the post $164 (page 9) is not good as it pass an very important part!
Also, the demo is AGA aware as on the loading screen gives info: AGA disabled! :)

I made an state file (for myself) just after the plane scene and did some testing:

1) In the loading scene of circle part and much before the music did "la la la" press F12 and change the CPU to 68000!
2) Return to emu and wait when the music end with "la la la" and again press F12 to change the CPU to 68020!
Note: The circle scene is not yet shown on the screen!

Now the circle scene will run with out problem with the CPU 68020.

According to this it seems the current 68020 emu mess something in the memory (in comparison to 68000 or JIT) just before the circle scene appears!
(So also that part of memory could be compared with 68000 to see what is different and why.)

PS.
This problem has nothing with CPU speed as I checked all possible combinations!
Also note there is no problem if you load state file, start it, press F12 and than change to JIT!
Also, the problem will still be there even with 68000 if you change from 68020 and after the music did "la la la" to the 68000!
I cant post any attachment as its all full! (hope Zarnal can make one state file that starts just after the plane scene is finish)

EDIT:
It will work with CPU 68020 only if both Cycle-exact Full and DMA Memory is off AND More Compatible in CPU options is off too!
But if the More Compatible is on it will still glitch! (seems like 680020 CPU prefetch mess something in the memory)

Note: The demo turns CPU cache off on start! (CACR=00000000)(so it is made to run w/o the cache)
If I force the cache to on with Shift+F12 "r cacr 1" when all Cycle-exact is off and More Compatible is on, I got squares instead of circles!
But if force the cache to on when all Cycle-exact is off and More Compatible is off, I got circles, so in this case the cache off/on does not change anything!

The 60020 JIT has also More Compatible option and testing the state file with JIT More Compatible on or off it still runs fine!
(so now it seems obvious that there is some strange problem in current 68020 More Compatible situation as JIT works fine with it)

@amilo3438

It's related to CPU speed. It has nothing to do with the chipset. Example : test this demo with 040+FullCE and AGA full CE ( floppy or WHDLoad version, exotic config ) and circles are ok. :)

You can also test Quickstart A500 and switch chipset in aga ( another exotic config ). AGA is disabled and this demo runs fine.

@ Zarnal

No, it is not a CPU speed problem!
It is the 68020/30 More Compatible problem that mess the memory before the circle scene shows on the screen!
(it does not have anything with full CE)

You prove only that 68040 full CE has no problem with this part of the demo! :)
Have you tried with 68030 full CE?
If you can prove that the demo has no problem with 68020 on some speed than we can talk about CPU speed problem.

Note: The demo is not made to run on a 68040 CPU anyway!

I may have mistranslated and misunderstood your first message. Sorry. :)
For me, CPU ( internal ) speed = issues with 020 CE mode ( not frequency or type of CPU ).

In this case I can agree as it is most probably something internal on the 68020/030 CPU Most Compatible prefetch emulation (the instruction cache is off by default by the demo itself).
Also the external CPU frequency does have nothing with this problem. (as it cant correct it)
I am afraid only how big this can affect on other (still) problematic demos problems!?

Interesting that JIT 68020/030 Most Compatible prefetch emulation does not suffer from this problem.
So I guess or JIT prefetch emulation is better or it is not "accurate enough" to behave on a such way to produce glitches.

I have two problematic demos with more or less the same issue here, on WinUAE 4.2.0 (although the same thing happened in 4.4.0):

Grid 2 by Nature https://www.pouet.net/prod.php?which=2804
Zeon by Nature https://www.pouet.net/prod.php?which=2803

The issue is that when I run them on 68040 at Approx A500 CPU speed, the JIT cpu cache needs to be 0 in order to precalc the musical instrument sounds properly, otherwise they get messed up.

But, the demo needs JIT to be full so that the demos can run properly AFTER the precalc. This means I've had to define a couple of keyboard keys to set JIT to both 0 and max.

How can I be sure to get these demos running without having to modify JIT on the fly, with ANY version of WinUAE?

Come to think of it, is it really necessary AT ALL for JIT to be changed on the fly? These are the only two demos left that need this function, until I figure out how to fix the problem.

Seems to work if "No flags" JIT option is unticked (which disables JIT CPU flags optimization, some performance is lost but JIT is still active). Some kind of rare JIT bug, probably difficult to find as usual.

Tried this, didn't fix the problem. Cache was 16384, as usual.

You are doing something wrong. It does and it has to fix it because problem is with 68020+ MUL.L which isn't translated if flags are checked. Not sure whats wrong with it.

The issue I've had is corrupted precalced audio samples if I had JIT active during the precalc. Unchecking "no flags" made no difference to them.

An example of what I mean by corrupted samples is the very beginning of Zeon: when the precalc goes wrong, there is a burst of white noise when the demo starts. Done correctly, the sound is different and more like an instrument.

Yes, sample is wrong without it. And unchecking "no flags" "fixes" it for me. (Did you uncheck it before starting emulation?)

I just did, still the same problem.

I'm including logs and config like I should've done at the start, so the problem will be easier to track down. Data was captured in Zeon after the white noise starts.

The two demos still work if I turn JIT on and off on the fly, but it's not a good solution. I'm also still on 4.2.0, but the problem occurred on 4.4.0 as well.

A new test on Hard should be done this weekend (maybe) to answer your question. I read your explanation carefully.
You say that WinUae does not emulate this " effect ". Is it because it's impossible to do it ?

Thank you also for your Fix of the Turnips demo. I made a big mistake (for the report in the Beta post) by not taking more time to check ( and not to commit this unfortunate mistake ). :)

Cubic Dream (Demo) by TRSI --> http://janeway.exotica.org.uk/release.php?id=3406

(Last it "works" in full CE was on WinUAE 3400!)

Tested on new WinUAE 4900 beta21 and it passes that problematic part with "cpu cache turned off", but also it crashes somewhere on the disk 2 at the end part with some strange gfx issues!
NOTE: It does not crash at the end part on the disk2 if CPU cache is enabled!!! (in the debugger with "r cacr 1")

PS.
"cpu cache turned off" = press both mouse buttons after the reset and check on the "Boot Options" the "Disable CPU Caches" and click on "Use"

EDIT:
So, the demo will work fine also on new WINUAE 4900 beta21 only if started with CPU caches disabled and after the problematic part is gone (at chess part) enable the CPU cashes again from the debugger !