Games or Demos needing "Cycle Exact" settings

[PARALAX]

Since I am currently testing the latest version of "Amiberry" (V 5.7.1) on my Raspberry Pi 4b via Retropie and there seem to be problems with the "Cycle Exact" settings, I am looking for a few demos and games that, according to the current state of WinUAE, absolutely require these settings in order to function normally. Since "Amiberry" is based on a stripped-down WinUAE port of the current WinUAE version, you would think that all games and demos would run with it to the same extent. Unfortunately, the two "Cycle Exact" options in the current version tend to have the opposite effect, with certain games or demos such as "World of Commodore '92" simply crashing. It only runs normally when these functions are deactivated. Now I would like to test a few games and demos that absolutely require these settings in WinUAE. Can anyone list a few of them?

[giantclam]

The latest release of amiberry for RPi hardware is v5.7.3 ~ retropi is still based on Debian buster, and the latest amiberry included for that distrib is amiberry v5.7.1

Since "Amiberry" is based on a stripped-down WinUAE port of the current WinUAE version, you would think that all games and demos would run with it to the same extent.

Incorrect assessment -- see https://github.com/BlitterStudio/ami...t-Installation for reference. The correct statement is, amiberry v6.x is based upon the current winuae-core stuffs ; amiberry v5.x is based upon the previous (v4.4) winuae-core stuffs.

Ergo... the succinct question here, is "How many Amiga titles (demos and games) absolutely require (chipset) Cycle Exact to be enabled to run correctly, using WinUAE v4.4.0?"

The reason one has to be succinct here, is it's possible some Amiga titles may have absolutely required (chipset) Cycle Exact to be enabled in WinUAE v4.4.0, however, that might no longer be the case wrt WinUAE v5.3.0, due to changes/improvements within WinUAE itself.

[kremiso]

i don't know if you are interested also in the opposite cases too

ie Deep Core, both 1.0 and 1.01 CD32 versions, require cycle exact to be turned off to reach ingame

[Photon]

Cycle Exact can mean a few things. (And AFAIK AGA or 68020+ are not cycle exact in any emu yet, so the below is only for OCS/68000 - but see "too fast CPU")

Two parts: CPU and chipset.

Chipset
First, one thing must be cycle exact, or many games would be very glitchy - the Copper. So this cannot be switched off to make it "not cycle exact", and comes for free.

Rest of chipset: 1985-1992 ish games chased the raster (single buffering), and also some later games (for A500) that had lots of gfx and sound and couldn't fit a double buffer in 512k chipmem.

If blits are too fast (not cycle exact), bobs can look hollow or sometimes go in and out of being seen. They are faster than the raster, not chasing and that's why. (*1)

If blits are cycle-exact(chipset) and CPU is not cycle-exact, unpatched missing blitwaits can fail, causing corrupted blits.

If gfx is rendered by the CPU (e.g. non-full framerate ST ports) usually nothing bad happens. If they are full framerate they can chase the raster and then the same (*1) above happens.


CPU
Also two parts: "Too fast CPU" and the rest.

CPU too fast: Makes raster waits fail: waiting for vblank, waiting to reload sound registers = complete mess and everything running to fast. the CPU would have to be about 100 times faster than 68000 or more to ruin the vblank wait, but some busy loop can be destroyed by just a little faster CPU (usually though it's a busy wait loop for some HW timer like the raster). So test Cycle Exact options with the base CPU (e.g. 68000 for A500) to not get fooled by this.

CPU rest: The only thing left (I think) is when the CPU is generating Copper values. Because the Copper is cycle-exact for free, wrong timing will cause short horizontal lines with fixed columns, like a TV test picture that's "bleeding horizontally". Or even write bitplane pointers too soon, resulting in wrong buffer being shown or black screen. The same is true for sprite pointers, this causing the classic "rolling sprites" glitch (vertical teleporting 16px pillars with crap in them).

Games that chase the raster:

• Gravity-Force/Kingsoft
• Sorceror's Apprentice
• Aunt Arctic Adventure
• Unreal
• Pseudo 3D racing games (raster road)

Fast ST ports:

• Vroom

Early ST ports:

• Super Hang-On
• Space Harrier
• Out Run

Some of the racing games can be OK if they double-buffer the Copper lists (e.g. Lotus series). But I think some pre-1993 ones didn't.

Demos:
1988-89, then it got better. E.g. Megademos from these years could have timing-dependent glitches. They should be a good thing to try. My ADF collection has many demos from this period, and all Megademos.

I'm sorry that I don't know any off-hand that I know for sure have emu glitches - it's just I only run demos and games on real HW. Except for some quick testing.

But this is supposed to be a fairly complete eagle-eye overview of most of the glitches that can happen in emu from these settings and what they look like.

You should be able to run a few of the mentioned ones at least, and get a glitch, so you don't have to run everything.

>>> Note that you must run ADFs or files, WHD patches the glitches out.

[paraj]

From helping out with pistorm compatibility I would recommend this:
Find something that doesn't work correctly that you can QUICKLY test. Debug that, fix and repeat (or try something else if it seems too difficult right now). Debug only w/ max compatibility against real machine behavior. Never against WinUAE in less than max compatibility mode. Fast/less compatible modes should always be an afterthought.

[PARALAX]

I am currently involved in a delicate discussion about the copy-protected version of Zarathrusta (IPF version) and the demo "World of Commodore '92". Due to time constraints, I have not been able to test much more. These titles ran flawlessly on my Raspberry Pi 4b via Amiberry at least up to version 5.2 with the "Cycle Exact" function activated, but not since one of the later versions after the corresponding update. Unfortunately, this has not really been addressed so far, as the developers claim that these options are counterproductive or "unnecessary". But that is not what I am concerned about, quite apart from the fact that my Raspberry Pi 4b with 2 GHz on each core is more than fast enough for this. Because even if the games or demos run fine without this function, and they actually do, it is a mystery to me why they no longer run properly on Amiberry 5.7.1 (based on WinUAE 4.4.0) with the two "Cycle Exact" options, but run fine on my PC with WinUAE 4.4.0 and the current version 5.3.0. So there must be something else to blame. I have been using these options for A500 and A1200 games and demos for many years and have never had any problems with them - on the contrary!

If you use a Raspberry 4b, you can try it in conjunction with Retropie or the current standalone version of Amiberry. In the case of "Zarathrusta.ipf", the spaceship is immediately destroyed during the first mission and the sound drops out, but not with version 5.2 (I was unable to test other versions). With WinUAE, there are no problems with version 4.4.0, 5.2.0 or 5.3.0 that can be traced back to activating the two "Cycle Exact" options. This phenomenon must therefore be related to one of the latest Amiberry updates.

[Photon]

Cycle exact is absolutely required, if you want to be able to enjoy in emu, the demos or games that push the limits on real Amiga.

Or put another way, the accuracy of emus is repeatedly tested by demos and games written for real Amiga.

The below won't help you prove an update made the emulation less accurate, unless a previous version run these correctly in Cycle Exact mode, and the update shows glitches in the below parts, and the glitches are not present on real A500 512/512k. (The below glitches are not present on real A500 512/512k.)

Cycle Exact Off in WinUAE 5.2.0
WOC92: Slowdowns in the first shadebobs part / bluish filled-circle-worms. (Watched until the end)

Arte: Slowdowns in the stars part after the Einstein picture. (Didn't watch quite until the end)

Hologon:

1. 1 scroll register hiccup on the lower text in the first part
2. glitches in top left of first blue octahedron stencil vector part
3. distinct consistent glitches in the light-shaded textured cube parts

(Didn't watch until the end)

These go away when cycle-exact is ticked.