![]() |
![]() |
#1 |
Registered User
|
![]()
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?
|
![]() |
![]() |
#2 | |
Registered User
Join Date: Jan 2015
Location: australia
Posts: 585
|
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
Quote:
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. |
|
![]() |
![]() |
#3 |
Registered User
Join Date: Dec 2020
Location: Italy
Posts: 2,003
|
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 |
![]() |
![]() |
#4 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,755
|
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:
Fast ST ports:
Early ST ports:
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. ![]() 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. Last edited by Photon; 05 July 2024 at 16:12. |
![]() |
![]() |
#5 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,298
|
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. |
![]() |
![]() |
#6 |
Registered User
|
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. Last edited by PARALAX; 07 July 2024 at 08:13. |
![]() |
![]() |
#7 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,755
|
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:
These go away when cycle-exact is ticked. |
![]() |
![]() |
#8 |
Registered User
|
![]()
The result with Amiberry 5.7.1 (the latest Retropie binary) on the Raspberry Pi with activated "Cycle Exact" emulation:
WOC '92: Crashes immediately Arte: Runs normally, no slowdowns Hologon: Runs normally, no glitches without Cycle Exact emulation: WOC '92: Runs normally Arte: Runs normally, slowdowns in the starfield part Hologon: Runs normally, no glitches I saved myself further tests because the result is already clear based on WOC '92 and Zarathrusta. The "Cycle Exact" emulation is therefore faulty and only partially usable, not optional as is the case with WinUAE. |
![]() |
![]() |
#9 |
HOL/FTP busy bee
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 32,503
|
Shouldn't this thread be in 'support.OtherUAE'?
|
![]() |
![]() |
#10 |
Registered User
Join Date: Jan 2015
Location: australia
Posts: 585
|
|
![]() |
![]() |
#12 | |
Registered User
Join Date: Jan 2015
Location: australia
Posts: 585
|
Quote:
BTW, good explanations there @Photon |
|
![]() |
![]() |
#13 | |
Registered User
|
![]()
Unfortunately, I saw the area too late and of course I don't mind if someone moves it.
That's what I thought too, but unfortunately the facts prove the opposite. Of course, I was only referring to the Amiga crashing due to the demo and not to the emulator itself, otherwise I would have ended up back in the Retropie selection menu. Quote:
I'm happy to do further tests if there's enough time. I'm well known in the scene for my thoroughness and perseverance and I'm happy to help improve emulators and programs of this kind, as long as it's appreciated. It would be nice if the Amiberry programmers would also show the same insight. ![]() Last edited by PARALAX; 08 July 2024 at 18:00. |
|
![]() |
![]() |
#14 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,298
|
If you really want to get to bottom of it, you should set yourself to be able to build Amiberry from source and use "git bisect" to figure out which commit broke it.
In the abstract (I've done the same with WinUAE before) 1. Get a setup where you can build Amiberry from source (in particular from the git repo) and make sure it works. 2. Make a state file that is just before the divergence (I assume Amiberry supports these, otherwise the next steps will be more painful). I.e. a state file that when loaded works in an old version, but crashes in a newer one. Making these at just the right time is a bit of an art. Start out well before the divergence, so you're sure an appropriate state has been captured, and then you can more or less slowly advance in time making new state files until you have one close enough. 3. git bisect, build (you may need to skip some commits that don't build - at least that's the case for WinUAE) and test the state file until you find the commit that broke it |
![]() |
![]() |
#15 |
Registered User
|
I'm able to get the state files before the crash and am happy to make them available, both for version 5.2 and 5.7.1. Beyond that, I can unfortunately only offer my services for bug testing, as I don't know anything about programming, including "git bisect".
|
![]() |
![]() |
#16 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,298
|
You probably need an interested developer or at least someone who is able to build the code. One or more easy-to-test state files is probably appreciated by the developers if they're interested in fixing it regardless.
|
![]() |
![]() |
#17 | |
Registered User
Join Date: Jan 2015
Location: australia
Posts: 585
|
Quote:
...Retropi is only good for Debian-10 (buster)...and LTS for that stopped June 30th.. ....that further complicates matters, because of the use of KMSDRM (which has old linux kernel bugs...'old' meaning prior to Debian11/12 kernels), it's using the older SDL2 v2.0.x libraries (and everything else besides)... ....and to put even more lumps in the porridge, Toni has confirmed there is a problem somewhere in the custom chipset code in WinUAE, but he's not going to debug the issue because it is corner-case, he's currently involved with a rewrite of that code, and he's suspicious that various hacks & ugly special case code (that is being written out) in the custom chipset implementation may be responsible. Toni has said, if after the custom chipset code rewrite is done these 'problematic' Amiga titles should be retested, and if they still behave badly, only then will he debug things further in an attempt to discover the cause. Ergo.... the 'interested developer' here should probably be the Retropi crew, to adopt a more recent Debian release, so testing is possible against current SDL2/other library releases, and of course the linux kernel itself... Given Toni's insights, I've dropped testing these titles in amiberry, until the custom chipset code rewrite in WinUAE is done, and merged into the amiberry tree. When/if that is so, and I find any issues with these & other Amiga titles (in amiberry), then we can move forward with this...but right now, that's where we are =) |
|
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Celtic "Meeting Demo", Timing problems in Cycle Exact Mode | StingRay | support.WinUAE | 5 | 26 January 2018 15:15 |
"Approximate A500/A1200 or cycle-exact" at +500% CPU Speed | Foebane | support.WinUAE | 2 | 28 January 2017 08:11 |
cud i start a list of 'cycle exact' needing games please | kirk | support.Games | 4 | 25 April 2009 23:11 |
Extremely slow GFX without "Cycle-exact" | tomtom14 | support.WinUAE | 1 | 19 August 2007 12:33 |
"Cycle Exact" how many games need it? | rsn8887 | New to Emulation or Amiga scene | 2 | 02 November 2006 20:43 |
|
|