Porting Yabause to Android

[Paul]

- This slot is reserved for the latest build, source code, screen-shots, and miscellaneous links -


Since I've really not had the time needed to put into this project, I've decided to hand it of to another developer.  Zack has agreed to take the lead on the project, and I'll be helping him out as I am able.  He has started his own thread here.  I am officially closing this thread, and letting Zack handle updates and support from his thread.

Yabause, Android Edition (AE)

Alpha Testing Underway!

Latest Builds:
Alpha Test APK  (source code)  09 May 2012 (Yabause core: r2892) with audio, VERY slow!
Alpha Test APK  (source code)  03 May 2012 (Yabause core: r2891) using dynarec, GLES rendering


Archived Builds:
Pre-Alpha Test  (source code)  12 March 2012 (Yabause core: r2849) accurate frame width/ stride
Pre-Alpha Test  (source code)  08 March 2012 (Yabause core: r2849) faster


Compatibility Spreadsheet  (editable, please update as you test games, and as app improves)


Bug-fixes completed so far during this round of testing:

-


Known Issues:

- Need to restructure code for easier compiling/ debugging
- Need to figure out why audio and/or GUI causes extreme lag
- Need way to build multi-APK containing both ARM6 and ARM7 builds
- Need to implement controller 2
- Need to implement NiGHTS controller analog
- Need to make app HC/ ICS friendly (deprecated Menu button)


Notes about building from source:

I am currently in the process of setting the project up in a more normal form (where you can use the simpler ndk-build and ant commands to create the APK), but I need to study the cmake syntax first to figure out how to set up the build flags in Android.mk.  In the mean time, use the following complex procedure to set up and build the project from source code:

(These steps are for setting up the project in Ubuntu Lucid (Linux).  The procedure will be slightly different in other OS's).

1) Install the Android SDK and NDK if you haven't already.
2) Install Sun Java JDK if you haven't already.
3) Install cmake  (sudo apt-get install cmake)
4) Add the SDK tools, SDK platform-tools, and NDK folders to your path   (in ~/bashrc)
5) Set JAVA_HOME if you haven't already   (in ~/bashrc)
6) Create a new folder to contain the android-9 toolchain
7) Follow the steps in "Invoking the compiler (the easy way)" in the NDK doc "STANDALONE-TOOLCHAIN.html" to create the android-9 toolchain
8) Add the android-9 toolchain bin/ folder to your path    (in ~/bashrc)
9) Unzip the source code somewhere on your computer
10) Edit the file yabause/src/android/android.cmake and edit the path to the android-9 toolchain's sysroot/usr/ folder
11) Create a subfolder called build/ under the Yabause source folder if it doesn't already exist
12) From the build/ folder, run cmake ../yabause -DCMAKE_TOOLCHAIN_FILE=../yabause/src/android/android.cmake -DYAB_PORTS=android
13) From the build/ folder, run make.
14) Transfer the file build/src/android/bin/MainActivity-debug.apk to your phone and install

For anyone worrying that I am going to be abandoning Mupen64Plus to work on this project, don't.  I won't be focusing a lot of time on this project (it is more for when I need a short break or when I get burned out).


Yabause AE is not affiliated with, nor authorized, endorsed or licensed in any way by Sega Corporation, its affiliates or subsidiaries. All trademarks are property of their respective holders. All individual games screen shots or audio that are simulated by Yabuse AE are property of their respective copyright holders and are only used for the purpose of informing the customer of the software's functionality.  You must have the right to a given BIOS or ISO before you play it.

[Paul]

- This slot is reserved for the project overview -

[scorpio16v]

Your explanation is a little confusing for me.
What I did :
- downloaded the Windows Version of Yabause
- downloaded an valid bios file.
- downlo... made a valid backup from SonicJam as .bin and .cue. 
- tested these config on Windows, to make sure it works.
- installed your .apk, made roms/saturn
- placed the bios and renamed to bios.bin
- placed and renamen the .bin as SonicJam.bin
- placed and renamed the .cue to SonicJam.cue
- opened the .cue and found the following

Code: [Select]

FILE "SONIC JAM.BIN" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PREGAP 00:02:00
    INDEX 01 59:38:59
- renamed file to SonicJam.bin and saved the .cue

So what' confusing me is

CD image must be named SonicJam.cue

An image should be the .bin, not the .cue. The .cue is some kind of directory of the CD.

On another ROM, that i've tested on PC, I got the same result than on Android. It ends on the CD Player of Saturn.

Have you tested your SonicJam.bin on PC before, to make sure it works ?

Logcat didn't get much feedback of the emulator. So I can't say what's wrong. 

edit
even if I rename the ROM, it semms that the emu starts in player mode.
the onscreen gamepad recognized sometimes input. so it semms to depend on the slow emulation speed, if it will work.
On Windows, the emulator will ask for iso or .cue. So the.cue file semms to start the .bin. Maybe you reversed both extensions somewhere in the code ?

[Paul]

I pointed it to the cue file (you're right the "image" is the bin file, but the cue file is technically also part of the image as well, because a header is needed to show where the audio tracks start.. confusing that this isn't just combined into one format).  Anyway I think the best thing will be to test it on the PC version to make sure my image isn't corrupt.  This is hard-coded into the "front end", so I just need to figure out if I'm hard coding it the right way.

[Epic_bubble]

Woo I can finally give this a shot now

And I am not sure how it is with saturn emulation but when I created my own ISO's for PS1 games I always deleted the bin file, maybe its needed for saturn games though.

EDIT: The dpad seems to work for me, it just seems unresponsive sometimes because the emulation is so slow.

Video of the emulation:
http://www.youtube.com/watch?v=imxAS4TfY0I

I got a new app that can record my phones screen, its kind of like fraps for android.

[scorpio16v]

The differend bios files gave another time counter on the player.
1.0 and 1.01 (jap) time is 728:14.
1.0.1a, the same as in Epic_bubble's video,ends with time 999:59 (blinking)

Has the Saturn a region lock and bios and ROM must be the same region ?
On PC there is an auto-detect option for the ROM. If you enabled the wrong version, the ROM didn't start.
So it is necessary to select the right binaries for an successfull test.

[Epic_bubble]

For now I would say it would just be easiest if we used the US bios with US games, an auto detect feature would probably be more useful when games actually run.

[Paul]

I don't think the problem is related to regions, though.  I built the Linux version for my PC, and with it, whenever the region is set incorrectly, the CD deck shows the message "This disk is not compatible on this system" (or something along those lines).  In the Android build, it doesn't show this message.  It looks more like it thinks there is an audio CD in the drive.

Also, one big reason this thing is so slow, is due to how the frame is being drawn:

Code: [Select]

    for(y = 0;y < info.height;y++) {
        for(x = 0;x < info.width;x++) {
            *((uint32_t *) pixels + x) = *(buffer + x);
        }
        pixels += info.stride;
        buffer += buf_width;
    }
Drawing pixel-by-pixel in a nested for loop is not the way to do graphics!  At the very least, this needs to be blitted.  Preferably, though, this should just be done with GLES and a call through JNI to flip the EGL buffers.  The "core" (if you can distinguish it as such) uses Ari64's dynarec, which can emulate the N64 CPU well enough to run Mario64 at a decent speed on most phones, so it shouldn't have any problem emulating Sega Saturn's less advanced CPU.  If the emulator is still slow after fixing the rendering, then the slowdown is most likely elsewhere in the code (which is good news for me, because I am not intelligent enough to tinker with assembly, haha)

[Epic_bubble]

Maybe thats why the DS emulator was so slow? Although the dev who made it has made plenty of emulators before so maybe it was something else.

[shuy3n]

 ;Di cant wait for this emulator to mature!

[Navi]

EDIT: The dpad seems to work for me, it just seems unresponsive sometimes because the emulation is so slow.

Video of the emulation:
newbielink:http://www.youtube.com/watch?v=imxAS4TfY0I [nonactive]

Wow, and people were calling this slow:

newbielink:http://www.youtube.com/watch?v=K_VGuLmj-rA [nonactive]

[Epic_bubble]

EDIT: The dpad seems to work for me, it just seems unresponsive sometimes because the emulation is so slow.

Video of the emulation:
http://www.youtube.com/watch?v=imxAS4TfY0I

Wow, and people were calling this slow:

http://www.youtube.com/watch?v=K_VGuLmj-rA

Its mainly this slow because like paul said earlier "Drawing pixel-by-pixel in a nested for loop is not the way to do graphics!"

Once this is changed there should be a speed boost.

[androidian]

Hi, i'm new to this forum and i have few questions
If there is any chance that this emulator in future works on my phone?In mupen64 1.4 runs very laggy even super mario 64 but fpse works great,so i guess there is a chance
my phone:samsung I550 armv6,768 mhz overclocked runs on cyo 7 mod
Sorry for bad english
Edit: i just try this early version it works(slow like at that video) can control that four buttons but it takes a few seconds to respond

[Paul]

Yes, I think a Saturn emulator has the potential to run a lot better than an N64 emulator.  The N64 had a 64-bit 93.75 MHz CPU, while the Saturn had two 16-bit 28.63 MHz CPUs.  In theory, that's even less processor power than the Playstation's single 32-bit 33.87 MHz CPU.  The developers understood their system's capabilities when they developed the games, so that should mean a lot more Saturn games will be able to run at full speed on slower hardware compared to N64 games.

From what I can tell, the biggest things holding back the speed of this emulator now are the software rendering and the "frame swapping" method that is drawing each frame one pixel at a time.  Once these functions are being done through GLES instead, there will be a huge performance boost.

[scorpio16v]

Did you have success to boot a ROM ?
Did you run a test with the setting, Guillaume from Yabause forum replied to you ?
Here is a game compatibility list from pandora port. Maybe you should try another game that is proven to run better.
And i read, that a bios file isn't allways neccessary for the pandora port and the maemo binary for n900.

https://docs.google.com/spreadsheet/lv?key=0Aq4SN3wYVIxgdHB4Z2hHcE9fQ3lTaTVMelEyZVBsVFE&hl=en_US#gid=0

Here is the N900 thread at maemo.org with some videos and different precompiled binaries.
http://talk.maemo.org/showthread.php?t=75992&highlight=yabause