WHDLoad First Samurai 1 & 2 Errors

[ghost]

Hi, I tested these two games. First Samurai completely exits the emulator for some reason. Second Samurai AGA has completely corrupted graphics.

All these games I think also suffer from the 'Play Too Fast, need Cycle Exact'. But that's a whole new problem. Will AmiBerry ever get some sort or Cycle Accuracy ?, maybe DMA/Memory Accesses just to get the many games to play at the correct speed on WHDLoad, or will it make the Raspberry Pi 3 slow down to a crawl ?

[midwan]

Thanks, I'll test them and see what we find. Cycle exact is coming as part of the big merge from WinUAE 2.8.1 that is currently underway.

[midwan]

@windale Have you tried disabling JIT? I didn't get the emulator to exit, but I did get Guru meditations when JIT was enabled.

[ghost]

I can't remember actually, I'll try tomorrow. Not that it matters anyway because of the unplayable speed difference at the moment. I'm not sure if these games also have problems with the floppy versions.

[midwan]

@windale I tried the floppy versions only here for now... :)

[ghost]

So I just tried these WHDLoad games again. I used a standard config, A1200, 14Mhz, 2MB Chip 8MB Fast NO JIT.

First Samurai - Exits the emulator when entering the game (you can skip the intro by pressing fire at the start)

Second Samurai - Exits the emulator when entering the game

Second Samurai AGA - Has corrupted graphics and exits the emulator when entering the game.

I also tried with JIT ON. No difference.

I got a Red screen for a few seconds when the emulator exited a couple of times, not sure if it was related to JIT.

[ghost]

These problems may automatically get fixed with your big merge update. Do you have a rough release date for the new "big" update and/or will there be anymore binary releases before then ?

[midwan]

@windale Did you test this with the SDL1 or SDL2 version? I'm curious about the emulator crash, as I haven't seen that yet in my tests, but I only tested it on the SDL2 version so far.

Most compatibility issues like these will probably be fixed with the update as you say, which is coming. I don't have a date, as it's a bit difficult to predict that at this point, but the biggest chunk of the code has been done already. I'm currently working on the JIT part which is rather big, so I expect it would at least take a few more weeks before we have a version that works.

[ghost]

I've only used the SDL1 version from the 2.1 binary from this Github. I normally only use pre-compiled binaries so I'm always behind until the next binary release. Is there a pre-compiled binary of the SDL2 version and is it compatible with RetroPie ?

I always keep JIT turned off as it creates problems on a few games and demos (well it did with UAE4Arm). I would only use it for heavy 3D games like Breathless, Gloom, Alien Breed 3D etc.

[midwan]

@windale OK, that would explain why I didn't see the same things. It might be a bug that causes a crash that has been fixed in SDL2.

There is no pre-compiled binary for SDL2 yet, that will happen when we are ready for a release, or at least a beta version. You could follow the instructions on the README of that branch to compile it from source if you want to try it out.

[ghost]

When you say "the big merge from WinUAE 2.8.1 that is currently underway", isn't UAE4Arm already using stuff from WinUAE 2.8.1 ? Is AmiBerry stripped down at the moment and less compatible ?

[midwan]

@windale I found out that UAE4Arm only has bits from 2.8.1 (and those are modified/stripped down) and most of the code is based on older versions of WinUAE. Amiberry is incorporating stuff from WinUAE 2.8.1 at the moment so I would say the opposite is true - it's more compatible than UAE4Arm. Although for now, the changes are minimal as in the master and SDL2 branches I'm focusing on fixing bugs mostly, until the big merge is done (which is happening on the "winuae281" branch).

The other problem that UAE4Arm has is that it uses stuff that was put there for Pandora due to its hardware limitations (e.g. only 16-bit display, everything else is converted) which do not apply on the Pi. So while working with it I have to check which parts make sense to keep and which ones should be taken away. It's a lengthy process unfortunately...

[Voljega]

Hello I can confirm the bug on both games in WHD Load, amiberry 2.1 on Pi2 crashes immediately on entering first stage after intro/selection and for Second Samurai menu is also a little bit graphically messed up too. Exactly as windale said

Both of them worked fine on uae4arm 0.4, I may be able to test it on uae4arm 0.5 if you're interested

[Voljega]

So I was able to investigate a little more by changing the executable used by my script :

• amiberry : crashes on entering first level
• uae4arm chips 0.5 : crashes on entering first level
• uae4arm chips 0.4 : doesn't even launch anymore.

Now I definitely tested those two games back with quite the same uae on uae4arm chips 0.4 and they worked fine, the only thing that changed since is installing the additional libs needed by uae4arm 0.5 and then by amiberry

I don't know if this helps you, but the problem seems to be in the linking to those libraries, I seem to remember that at least guichan and SDL were upgraded during those processes

You have by my other issue for what was needed during upgrading from uae4arm 0.5 to amibery 2.1 For the upgrade from uae4arm 0.4 to 0.5 those were added : ld-linux.so.3 libSDL_image-1.2.so libSDL_ttf-2.0.so.0 libguichan-0.8.1.so.1.1.0 libguichan_sdl-0.8.1.so.1.1.0 libjbig.so.0 libmpg123.so.0 libpng12.so.0.50.0

Also if these can help, I'm on a Pi2 and pastebin of the uae used to launch both games : http://pastebin.com/QGVRubfZ

[midwan]

@Voljega Thanks, every detail helps in tracking bugs down. I didn't have time to get into this one yet, as I'm busy upgrading the custom chipset, drawing, blitter and events routines from WinUAE 3.4.1 (which should fix several compatibility issues).

Once I get into this I'll find out what's causing it.

[Voljega]

No prob just a look at github issues and I can see there's a lot on your plate !

I can still try one thing : launch my scripts and thus the emulator through command line and see if there's an explicit error in console when it's crashing, that could help a lot

[ghost]

You need to have '24-bit addressing' ticked and the games don't crash (Second Samurai has graphic and sound errors). If it's unticked then it crashes the emulator.

[Voljega]

Thank you for the tip but 24-bit adressing is greyed out for me how to ungrey it ?

[ghost]

'24-bit addressing' is only greyed out when the CPU is set at 68000 or 68010. You only need to tick '24-bit addressing' for the WHDLoad version of First Samurai (68020+). The ADF version works fine on 68000. Second Samurai OCS/AGA menu screen doesn't really work properly on UAE4Arm/Amiberry (yet).

[Voljega]

@blinkydoos sorry long time without responding but I beg to differ, my 24-bit adressing thing is clearly greyed out while using 68040 CPU http://imgur.com/a/aW5Ek

Maybe it's a issue with my uae ? So I included some other screens for debug and here is the pastebin of my uae : https://pastebin.com/QGVRubfZ

For the record i'm using amiberry v2.1 last release on Pi2

[ghost]

Yeah, I just checked and it's only available on 68020 on Amiberry/UAE4Arm (on WinUAE it's available on 68000-68030). You'll have to switch to using 68020 (which is recommended anyway). According to TomB who did the original port of UAE4Arm, 68030 and 68040 are not fully implemented yet.

Note: In current version, you will not see a difference in the performance for 68020, 68030 and 68040. The cpu cycles for the opcodes are based on 68020. The different cycles for 68030 and 68040 will come in a later version.

[Voljega]

OK but as you can see in my UAE I try to keep my configuration as simple as possible (I do'nt know much about amiga hardware) so in there I only said I'm using an AGA chipset, CPU as been set automatically to 68040 by Amiberry.

Is it normal ? Shoudl I force in the UAE the CPU to 68020 while keeping an AGA chipset ?

[ghost]

The Amiga is quite a complex machine that can use many different configurations. For WhdLoad games my defaults would be :-

68020 24-bit addressing ON JIT OFF 14 MHz (or more depending on the game) AGA Blitter Normal 2 mb Chip Ram 8 mb Fast Ram ROM kickstart 3.1 (A1200)

If you're using Amiberry SDL1 or UAE4Arm then 'fast copper' ON will give a speed increase but will be more accurate turned OFF.

For larger WHDload games, if you see the screen flashing black while loading you can untick '24-bit addressing' (which will enable 32-bit addressing) and add some Z3 Fast Ram which will 'pre-load' more of the game into memory.

[Voljega]

Thank you i'll try that as soon as I can

[Voljega]

@blinkydoos since i'm in vacation I took some time to retest and with your config the game launches but there is no floor tiles they are missing only characters and objects are displayed.

This is for First Samurai with amiberry 2.1

[midwan]

Fixed with 29fe7770ec61a26224fef6ad74dfe679b248ed53 in dev

[midwan]

the dev branch will be merged into master as soon as beta testing is complete, so we can close this issue for now.