Games to test and add to 68000 mode if required.

[HoraceAndTheSpider]

Harlequin
New Zealand Story
Barbarian (Palace)
Technocop
Magic Pockets

Noted from issue #25 - games which appear to run too fast / require 68000

[HoraceAndTheSpider]

NZS on 68000 is slower than the original, and choppy, probably due to the extra blitterwaits, but seems to be fixable with immediate blitters on.

Magic Pockets also seems choppy on 68000/010 , pretty much the same situation. i would like to check these on real hardware. they are certainly not unplayable (like Barbarian was) on 68020/7mhz, so just need to check these before adding to the lists.

I have yet to test the others.

[ghost]

seems choppy

I tried Magic Pockets and New Zealand Story (ADFs) on WinUAE will Full Accuracy and it plays the same, that's the original intended speed. Maybe because you've been playing games at the wrong speed and ratio on the Pi you've forgotten what they were really like :)

As i've said many times before, you could just only use 68020 and 7mhz as nobody seems to notice anyway ! As long as I can manually change it in the Python script for my own personal preference I don't really care.

[HoraceAndTheSpider]

The speed on NZS might be -about- right but I am relatively sure the choppiness is not correct (I could be wrong) but it would only take a game loop to be slightly slower than a refresh for it to be affected.

It’s the last game I ever completed on an A500 so one i know quite well.... plus I did a lot of testing of it when updating the Whdload slave, so I know it is very particular about timing (bad emulation can cause the game to run half-speed or break the music etc)

Will update once I’ve done some h/w testing. Should be able to run it from original disk on my a600.

[HoraceAndTheSpider]

Right, i can officially put the NZS issue to bed.

I am afraid either the memory cheats for you @blinkydoos or your assessment via WinUAE is incorrect.

I have filmed 4 videos of NZS, on level one. Moved Tiki across the screen to his death. I then freeze video at the first frame of the 5 second mark for comparrison.

1 - Real A600, 68000 only Gotek loaded ADF.

http://www.ultimateamiga.co.uk/HostedProjects/RetroPieAmiga/debug/NZS_A600.PNG

We can see here that Tiki should have reached certain doom and be showing a 'red' electrocution . As a test on real hardware, the original processor and using the original game (no WHD blitter patches etc) this should be the benchmark for the speed we are trying to achieve.

I will add that there is a 'smoothness' factor lacking and will cover that in a mo.

2 - Amiberry/Pi, 68000 , WHDLoad - Immediate Blitters

http://www.ultimateamiga.co.uk/HostedProjects/RetroPieAmiga/debug/NZS_PI_68000_IMMEDIATE.PNG

The reason this should be correct is that the game is not hampered by the newly added blitterwaits, instead performing its game cycle in processing time to the original. Amazingly, as you can see the returned the exact same frame as the A600 mode.

3 - Amiberry/Pi, 68020 , WHDLoad - Wait for Blitter

http://www.ultimateamiga.co.uk/HostedProjects/RetroPieAmiga/debug/NZS_PI_68020_NORMAL.PNG

As suspected, not perfect, this does indeed run a little fast, but not much. As you can see Tiki is not touching the ground yet in his electrocution animation. Over the course of the 5 seconds, he only 1 frames away from where he should be (the next animation frame is the same as the above two)

4 - Amiberry/Pi, 68000 , WHDLoad - Normal Blitter

http://www.ultimateamiga.co.uk/HostedProjects/RetroPieAmiga/debug/NZS_PI_68000_NORMAL.PNG

Miles off i'm afraid. The speed which i stated was slower and choppy (more so than the A600), and the game is simply considerably slower than it should be. The above demonstrates this really is down to the added blitter waits since that setting alone can solve the problem (and perhaps the slave should be updated to allow their removal)

Obviously this test has a slight wiggle room for human error, but gives a nice visual indicator for comparions.... in essence, the 68020 mode could even be performing exactly right in terms of time, with the blitter wait enabled should be very close. It also seems to have an added smoothness that was not present on the A600 - either this this the cause of a display refresh (i.e. Indivisions fault) or the game is coded well enough to take advantage of a few extra cpu cycles.

I will try to look at some of the other games listed in the same way also.

[ghost]

Oh my god ! You did all this to prove me wrong ! Please stop now. I repeatedly keep saying to leave it as you originally had it. No 68000 mode. Let's end this thread now :)

[HoraceAndTheSpider]

no, i did not do this to prove anyone wrong. This is to try and get the most accurate experience of emualtion - part of the point of this project is to find optimal settings.

I happen to LOVE New Zealand Story - it is one of my top 5 games of all time, especially the Amiga version, so this was done so that I could enjoy it correctly.

Ther fact is there are some games that on WHD may have older slaves that do benefit from the 68000, so i'd like to identify them without making them slower than they should be.

[ghost]

But you never would have been doing this if I hadn't of brought it up in the first place.

[HoraceAndTheSpider]

Actually i've been wanting to look at the NZS running speed (and others, like Barbarian) for ages.

It was also a good excuse for me to connect my A600 in my new setup.

[ghost]

One thing you didn't try is the WHDLoad version on a real A600. Then see if the blitter waits affect the real hardware the same as Amiberry.

You're not going to get an 'accurate experience' without cycle accuracy.

[HoraceAndTheSpider]

because at the moment, i have no idea where my A600's CF card is ... but yeah, i need to find that eventually anyway and will give it a go.

[ghost]

Well this may be a reason for it. You are currently comparing the original ADF version with the WHDLoad version+blitter waits. Try your camera antics out on WinUAE.

[HoraceAndTheSpider]

i dont use WinUAE , as i dont run Windows. I am also not interested in the WinUAE performance if i'm honest - i prefer to benchmark against actual hardware. I have just tried on FS-UAE with 'full accuracy' and can confirm that 68000 + WHDLoad is also slow there (might even be the same frame it reaches), so it would seem not to be an Amiberry issue.

http://www.ultimateamiga.co.uk/HostedProjects/RetroPieAmiga/debug/NZS_FSUAE_68000_WHD.PNG

The above show that we have two possible setups for amiberry that compare favourably to the original 68000 machine on disk, but with the bonus of using WHDLoad load times and other bug fixes.

The reason for me to check the blitterwait issue on a real 68000 would only be for personal curiosity and for me to update the WHDload slave, and restore the original timing via a CUSTOM tooltype. Howver, i'm not really spending time on WHDload slaves at the moment for obvious reasons.

[HoraceAndTheSpider]

To finalise this, the above games still need “wait for blitter” enables manually at present.