1. superfury Avatar superfury
  2. My projects
  3. UniPCemu
  4. Issues

Running on Android

Issue #1 resolved
Макс Волошин created an issue

I've successfully compiled your emulator for Android with libSDL by Pelya, but it is unusable due to controls designed for PSP, etc. This implementation of SDL uses standard PC keyboard.

Comments (118)

  3. Макс Волошин reporter

    And I cannot switch to Direct input mode, because I am unable to press both mouse buttons (because of touchscreen).

  4. Макс Волошин reporter

    It would be nice to add separate controls for Android (#ifdef ANDORID ... #endif)

  5. superfury repo owner

    So on Android (when ANDROID is defined) builds, it should just always be in Direct Input mode(Mapping keyboard/mouse input to emulated keyboard/mouse)? Or should a new input method be added to the existing input methods(which currently are PSP input(using Keyboard/PSP/Joystick), Direct Input and Gaming mode)?

  6. superfury repo owner

    What method would be easiest to implement into the current system(see emu/io/input.c, of course without breaking the current system on other devices, by using #ifdef ANDROID ... #endif blocks)?

  7. Макс Волошин reporter

    If Direct Input mode will be active by default and even in the BIOS menu, it would be better.

  8. superfury repo owner

    The problem is, that the Settings menu only responds to non-direct input mode (PSP or PSP-mapped mode to be exact). This is to provide support for the original device(development of the emulator originallly started on the PSP SDK after all, it's just too heavy to run on a PSP fluently atm). I could add a little fix that remaps the direct input mode keyboard input to PSP buttons when the settings menu is opened, but this gives a final problem: When to open the settings menu? On the PSP it has seperate mapping to be able to reserve one key(SELECT key) for opening the menu. When it's in Direct Input mode all the time, when should the settings menu be opened? Should this be done using a reserved finger action or location instead? Also, the only thing the Direct Input mode does is map mouse and keyboard actions directly into the emulated system(keyboard/mouse input on the 8042 PS/2 controller or IBM PC keyboard&serial mouse).

  10. Макс Волошин reporter

    I want to be able to navigate BIOS menu on Android with arrows, space, enter keys, etc.

  11. superfury repo owner

    I can make it so that the arrows map as usual on the PC(arrows->PSP digital arrow buttons), space maps to PSP circle, enter maps to PSP cross. It will automatically switch to this new PSP-compatible input mode when entering the Settings menu. Should that be enough to work with? Also, I would need to know the exact differences in how data is input on an Android system compared to a PC. Is this the same(with some kind of keyboard-mapped input)?

  13. Макс Волошин reporter

    Then, if I press Enter key on Android keyboard, it will be handled as PSP circle when in the BIOS menu. Did I understand you right?

  14. superfury repo owner

    Not exactly: When not in Settings menu, it's Direct Input. When in the Settings menu: Arrows act as PSP arrows(dpad). Enter is mapped to PSP Cross to confirm options. Escape is mapped to Circle to go back through the menus. Space is mapped to Triangle to reset the default setting or unmount disks.

    Would that be enough? Of course this means a physical keyboard, not an OSK.

  16. superfury repo owner

    I've implemented the mapping from the keyboard to the settings menu buttons. The settings menu can be opened by the PSP SELECT button(Backspace on the keyboard). When the emulation is started normally, there's currently no way to enter the settings menu, as I don't know how to check for the keys other than keyboard/mouse/joystick input. Do you know how I can detect those three physical buttons on the device? Then I can map one of them to open the BIOS settings menu.

  17. Макс Волошин reporter

    You can use Menu (SDLK.MENU) button, because it is present on my keyboard and does not have any useful functions. Then libSDL by Pelya allows redefining it to Android physical Menu button.

  19. Макс Волошин reporter

    Inside the application built with this libSDL implementation there is custom hardware keyboard (not just Android OSK).

  20. superfury repo owner

    I notice there being SDLK_HOME, SDLK_MENU and SDLK_CANCEL, but there's also SDLK_AC_HOME, SDLK_AC_BACK and SDLK_AC_REFRESH? Which ones are the normal buttons on the phones?

  21. Макс Волошин reporter

    SDLK_HOME. This is not physical button on the phone, but I can remap it in libSDL by Pelya's AndroidAppSettings.cfg.

  22. superfury repo owner

    I think it's best to remap them to the AC buttons, as they're unused on the normal PC input map, to prevent conflicts. Is that possible too?

  23. Макс Волошин reporter

    I'm not sure. Then, I have never used Home button on keyboard. Try SDLK_HOME at first.

  26. superfury repo owner

    I've mapped SDL2 fingers being pressed/released to make the text surfaces register the fingers individually (8-bit finger ID, which is currently ignored). Now finger movement is mapped to emulated mouse movement, and the text surfaces should respond to a finger being pressed/released on supported text surfaces, making normally entering the BIOS possible by touching it with your finger. I only still need to add a virtual keyboard for full input and/or PSP-style input based on the press/release on the text surfaces.

  27. superfury repo owner

    I've fixed some bugs in the SDL2 finger system, as well as implemented an OSK for the emulator, with full 104-key PC keyboard support. Simply click/tap the input status indicator (the K(eyboard)/M(ouse)/G(aming)/D(irect)/O(SK) to switch it to OSK mode (or enable it when normal input is disabled, when it shows a disactivated O). When it's activated, the 'O' has a yellow border and the OSK is visible, which maps directly to normal SDL keyboard events(Using SDL_PushEvent), which is handled by the emulator like a normal keyboard.

    I've tested this using the OSK on Windows(Both the mouse clicks/hold and touching the letters make the keyboard respond to it).

    Is it working on Android?

  28. superfury repo owner

    Btw, just added mouse using fingers emulation as well. When the Finger OSK isn't activated, the left third of the screen presses the left mouse button, the top third of the screen presses the middle mouse button(currently unemulated) and the right third of the screen presses the right mouse button.

  30. superfury repo owner

    Do you know what commit it's based on(In YYYY/MM/DD HH:MM format)? That way I can quickly compare for differences. There's a Makefile.android, which is currently a copy of Makefile.win. It's to be adjusted for Android makefile using the normal Makefile+Makefile.multiplatform.

    Then, call it by executing "make android build" to execute the build directive in Makefile.android. Although I don't know if it's possible that way?

    Do you mean you've added some #ifdefs, or are those from the normal UniPCemu commits by me?

  32. superfury repo owner

    Do you mean #ifdefs applied to SDL itself, or #ifdefs in UniPCemu source code? I think you mean SDL itself, since UniPCemu isn't that old yet(nor is this discussion)?

    Btw, doesn't it compile with SDL2? SDL2 should be Android-compatible afaik, according to the official site?

  34. superfury repo owner

    When searching using Visual Studio and Windows search, there's only one modified file with new Android support: headers/emu/directorylist.h, which adds ANDROID to the psp define to use non PSP-style (Windows, Linux) structures. Is that correct?

  35. superfury repo owner

    I've added the new files you supplied, moved the files from the project to the UniPCemu subfolder(still need to modify the Makefiles and VIsual C++ projects for the new paths though). I've also modified the directorylist.h with the new changes. I see that the name x86EMU is still called in the Android files(that you've supplied in the root folder of the archive). Can this safely be changed to UniPCemu to keep compilation intact for Android(using Windows notepad)? Or will that cause problems with line endings?

  37. superfury repo owner

    I've changed it to UniPCemu where it either seems to be a directory name or project title. All others are now in lower case.

    I've also updated the tools repository for the new paths with new support for specifying the tools repository directory in remake.bat for the new psp paths. The same for all other Makefiles. They assume you're either in the usual Android path(the root of the repository) or in the project directory (UniPCemu directory in the repository) when building.

    Is it working?

  38. superfury repo owner

    Btw what's up with the SDL.zip file you've supplied? First, they're 32-bit BIOSes, which can't be run yet currently, until I've fully implemented the 32-bit CPU extensions (286/386/486 CPU emulation). Then it's BIOSes for Bochs, not UniPCemu(which has a different folder layout)?

  39. Макс Волошин reporter

    It is sample SDL.zip file, you should replace its contents with UniPCemu data and BIOS.

  40. superfury repo owner

    What happens to that zip file when the project is compiled? Is it extracted into a folder when compiling or included in the .apk to be extracted when installing?

    UniPCemu by itself can run without any added files. The only stuff that is optional to use is different kinds of files in different folders: The folder "ROM" contains any ROMs you want to use in the emulation, if you want to use any ROMs at all(it should also be able to run without ROMs, using an internal BIOS much like(and video service interrupt&keyboard interrupt handlers based on Dosbox), but you will still need floppy/hard disk images to boot). The folder "music" contains any music you want to play in the Settings menu's Music player. The folder "soundfonts" contains any soundfonts you want to use with the MPU-401(which has the Intelligent interface from Dosbox, with my homemade SoundFont 2.0 emulator as a backend(compare to Dosbox, which uses the host OS/hardware instead). So essentially Dosbox MPU-401 with my own MIDI sound device emulator as a backend. The folder "disks" contains any disk images used with the emulator(currently sfdimg(dynamic hdd), img(static floppy/hdd) and ima(static floppy only) filetypes are supported).

    The folders are automatically created when the software starts to do anything with them(e.g. when you select an option in the BIOS that uses the folder, or try to boot in BIOS mode without the directory being existant).

    The emulator also automatically creates a SETTINGS.DAT file containing all settings for the emulator. This is automatically createn when the emulator is started(and rewritten when corrupted or settings are changed for any reason). Kind of like a binary data blob containing a simple checksum and all settings that are configurable in the Settings menu, as well as some stored information to use for portability accross devices(allocated RAM and Video memory sizes, which is currently automatically redetected when either the data isn't present(corrupt/non-existant SETTINGS.DAT file) or some settings are changed(e.g. changing from SVGA to VGA and VGA to SVGA makes the emulator redetect the Video RAM size, which is usable on the current device. Also any time the RAM/VRAM data can't be allocated, memory is either redetected and used if possible, or the application is terminated(when running out of RAM, since it can't run without RAM, VRAM and Expanded memory(EMS))).

    All those directory and SETTINGS.DAT are currently fixed to use the current working directory. I know it's the executable directory on Windows and PSP devices, but I don't know what it's pointing to at Android/Linux? Is it a writable directory at all? Or does it need a custom root path (instead of the current working directory)?

  41. superfury repo owner

    I've added a Settings menu option to switch between Android /storage/external_SD/UniPCemu and /storage/sdcard0/UniPCemu directories. That way it can be used on devices, where the current working directory isn't the project directory(and writable).

  44. superfury repo owner

    I've fixed the errors and warnings you've given. I've also added a general define to the different platform-specific types.h for cross-platform directory creation(using #ifdef to detect available functions)) and removal. Is it compiling and running correctly now?

  45. Макс Волошин reporter

    bios/biosmenu.c: In function 'BIOS_MainMenu': bios/biosmenu.c:1644:14: error: 'advancedoption' undeclared (first use in this function) optioninfo[advancedoption] = 5; //Change storage medium! ^ bios/biosmenu.c:1644:14: note: each undeclared identifier is reported only once for each function it appears in

  47. Lubomyr Lisen

    Answers on some questions: Anroid port used custom SDL(1) lib provided by pelya pelya's libSDL much powerful than official SDL2 (for android)

    SDL.zip - is android assets file. Content of this file libSDL unzip on the first run of app to Android/data/superfury.unipcemu.sdl/files folder (on sdcard or other storage) (it is a working directory of app or root app dir)

  50. superfury repo owner

    That 'zero' is actually an O, which is the On-screen keyboard toggle. Tapping it should open the OSK implemented using SDL 2.0(or 1.0 using mouse events).

    I've managed to get it working here too using the tutorial at lazyfoo.net/tutorials/SDL/52_hello_mobile/android_windows/index.php

    Now it indeed isn't responsive for some reason (nor does it seem to get past initialization for some reason).

    I see the SETTINGS.DAT is correctly being generated in the UniPCemu folder on the internal memory, so the directories used seem to work. Now I still need to find out why it crashes.

  51. superfury repo owner

    I've improved SDL2 windowing on Android. Currently figuring out why the touch input doesn't work.

  52. superfury repo owner

    I've improved the SDL2 windowing some more in the latest commit. I've also added some data logs that show something strange:

    Literal log(timings not copied, typed by hand): (... lots of joystick motion etc. events) Input event finished! gettimepassed checksmalldelay smalldelay updatevideomain tickvideomain cpurunmain Starting core loop Checking allcleared... Validating registers... Executing instruction state OK! BeforeExec! Set debugger for instruction! Execute CPU! Step debugger! Handle callbacks! Stepping timing! backgroundevent backgroundevent

    That it's sending the backgroundevent twice is normal: once for the normal main capture(which has do be done using a filter for iOS, according to the SDL2 documentation) and once for the main thread seeing the event too.

    The strange thing is, that before it occurs(3 seconds after the "Stepping timing!" event) nothing happens in the main thread according to the log?

    After looking and debugging the timing used by the main thread: I notice that the PIT rate is correct: ~1.19M ticks per second. But, for some reason, the tick duration becomes 1.728413e-306 instead of ~838.09? Does this mean that the Android compiler calculates an invalid number during compilation(since it's set at compilation time)? Or is something android-specific going horribly wrong?

  53. superfury repo owner

    Do you know what causes these floating point abominations? The result that's supposed to be at that variable is inaccurate to say the least. This will cause the PIT to use about 1.7e-306, instead of 838.09, causing an insane amount (about 1e305) amount of PIT ticks (and probably the same for all other hardware using accurate timing in any form at high speed), which will hang the application.

    Is there a way to fix this for Android builds?

  54. superfury repo owner

    Can that issue be fixed by, instead of loading it at compile time (with vartype var = <initialvaluehere>;), actually loading that value in code? In the case of the hardware, loading it at the point the hardware is initialized (the init<hardwarename> functions)?

  55. superfury repo owner

    I've changed all updating timings used to be assigned when initializing the hardware it applies to(which is always done in some way to use the hardware or timing). Does UniPCemu not crash on Android now and run correctly? It compiles fine here, but atm I cannot test it yet(can't connect my Android device to test the theory, as I am not in a place where I'm allowed to do that atm(remote controlling my PC I'm compiling it on)).

  56. superfury repo owner

    I've just tested it on my Android device: UniPCemu now runs! ;D The only problem left is that, when I try to open the Settings menu, the application seems to crash for some reason.

  57. Макс Волошин reporter

    Please, change UniPCemu/profUniPCemu to UniPCemu/UniPCemu in AndroidBuild.sh

  59. superfury repo owner

    Well, I've found out so far it's trying to start the Settings menu(since it's a first boot, which will be the case until the settings are saved for the first time).

    The error I've found happens both during normal emulated Settings menu execution and initial(like mentioned above) Settings menu execution. So there's something going wrong executing the settings menu on Android devices. I'm currently debugging it.

  60. superfury repo owner

    I've fixed the paths used by the emulator for loading and storing files(all 256-bytes big now, sufficient for Android paths).

    The Settings menu now correctly loads and displays the main menu. Eventually it tries and check for shutdown, to which shuttingdown() returns 1 apparently(since it won't go past that point. So it's either requesting shutting down for a reason or the shuttingdown check is part of the cause(crashing?).

    So the Settings menu seems to be somewhat responsive(since it properly quits the menu when clicked on).

  61. superfury repo owner

    I've changed the settings and paths to be detected using the SDL2 storage paths functions(SDL_getAndroidExternalStoragePath and related functions). Is this working on libSDL as well?

  62. superfury repo owner

    I've fixed the BIOSROM.BIN and verification ROM paths. The BIOS should now load correctly on Android systems(all in it's usual directory of /storage/sdcard0/Android/data/com.unipcemu.app/files). Simply place the ROM directory and all other used directories in that folder.

    Does the Android build work with your compilers?

  63. superfury repo owner

    I've renamed the android-project name to be the same as your provided name. That way, the directories should match between the two Android builds.

    I notice one thing: data written on the MicroSD(at /storage/sdcard/Android/data/superfury.unipcemu.sdl/files) isn't moved to/from the MicroSD/phone when selecting to do so in the Android menu. Anyone knows what causes this? Isn't that data supposed to move as well(and reflected onto the application in some way)?

  64. Lubomyr Lisen

    for pelya's libSDL i added #ifdef PELYAS_SDL strcpy(UniPCEmu_root_dir, getenv("SDCARD")); //path! strcat(UniPCEmu_root_dir, "/Android/data/superfury.unipcemu.sdl/files/"); #else .... updated files https://dl.dropboxusercontent.com/u/47797448/unipcemu/bios.c //added flags PELYAS_SDL https://dl.dropboxusercontent.com/u/47797448/unipcemu/Makefile.android //added on-screen joystick for selecting menu https://dl.dropboxusercontent.com/u/47797448/unipcemu/AndroidAppSettings.cfg

    apk based on pely's SDL https://dl.dropboxusercontent.com/u/47797448/unipcemu/unipcemu-debug.apk app dir - storage/sdcard0/Android/data/superfury.unipcemu.sdl/files/

    I can select menu but i don't know which keycode used for enter into sub-menu.

  65. superfury repo owner

    I've implemented those changes you've suggested in SDL1(Pelya's define) and SDL2 too. But it won't ever switch to External_SD, even though the SDCARD environment variable should be used? Is there a way to detect which one to use(/storage/sdcard0 vs /storage/external_SD)?

  66. Макс Волошин reporter

    I cannot select menu entries with SDL Enter. And text is too small and hard to read on my 800x480.

  67. Lubomyr Lisen

    I don't know how to detect external storage my device have: /storage/sdcard0 (external, microsd) /storage/sdcard1 (build-in storage, with read-only access while inserted microsd)

  68. superfury repo owner

    Btw there's a virtual OSK that can be used anytime for keyboard input. Simply tap the O (or any other letter that indicates the current keyboard input method) in the bottomright corner. It should start to glow(yellow border on the text) and the OSK should pop up(can be handled using both normal mouse events(tested on Windows) and SDL2 FINGER events(tested on Android)). Those keypresses are directly passed on to the input handler itself to simulate virtual keypresses(e.g. the SDL_FINGERDOWN and SDL_FINGERUP affect the keyboard, by setting the status of the key pressed/released(bit value being 1 for pressed or 0 for not pressed) in the text surface, which is read by the keyboard passthrough handling (updateFingerOSK function), which responds to the pressed and released keys by adding events to the SDL input queue to simulate the corresponding SDL_KEYDOWN and SDL_KEYUP events. This should work on Android as well? It does work on my Windows computer. For some reason my Android device doesn't respond to the OSK?

  69. Макс Волошин reporter

    I tried pressing O, but it seems it is too small to touch or simple does not function.

  70. superfury repo owner

    It is very small indeed(only 8x8 pixels, as defined by the used CGA font and text surface limitations). I cannot make it any bigger, because that wouldn't fit on the screen(it's built to fit on a PSP screen).

    I've added some visual feedback to the OSK, making the border become the active color when a key is pressed.

    The OSK currently contains 480 pixels width(PSP screen width and apparently my Android device's screen width(portrait mode)), 272(PSP screen height) pixels height. The full width is used to fit the OSK atm, so to keep PSP compatibility more cannot be added?

  71. Макс Волошин reporter

    I am unable to call OSK under Android. Can you test it on your Android device?

  72. superfury repo owner

    Just tested it on my Android device: all OSK input is recognized, only not by the Settings menu. Tapping the options still works.

  74. superfury repo owner

    It seems that Pelya's libSDL uses joystick events to give it's touch events(instead of the way SDL2 does it). I'm currently implementing those...

  76. superfury repo owner

    I've fixed some little bugs concerning the Direct Input mode being disabled when the Settings menu is opened and closed(it wasn't locking input in one case when it was needed. Also when not compiled with SDL2 it wouldn't execute the Direct Input mode changes on Android(like usage with Pelya's libSDL), thus handling Direct Input incorrectly).

    This should fix the Direct Input mode in your cases, and fix data corruption when the Settings menu is entered and exited by pressing Select(Backspace) during the BIOS boot messages being visible, causing a reboot of the emulator.

  80. Lubomyr Lisen

    It compiles and runs. Touch input - not works. I can't navigate between menu item via up, down, left, right as in previous version.

  81. superfury repo owner

    Just tried the Windows version with remote control on Android(SDL2) and tried controlling it in touch mode with the emulator's OSK. It works without problems.

    The buttons in SDL1 are handled as follows:

    • JOYBALL motion events are converted from 16-bit range to normalized -1.0 - +1.0 values by dividing by 32767 and passing that value to the SDL2 motion function only when the button is pressed already. Unpressed buttons just have their normalized location updated. event.jball.ball contains the used finger(0-15 decimal).

    • JOYBUTTONDOWN events are handled as SDL2 FINGERDOWN events, with the normalized location being the result of the last JOYBALL event.

    • JOYBUTTONUP events are the same as JOYBUTTONDOWN events, but are handled as SDL2 FINGERUP events instead

    Both the JOYBUTTONDOWN and JOYBUTTONUP events ignore releases when unpressed and presses when not released.

    Is that the correct way to translate the touch events to the SDL2 touch events?

    That last update fixed the way it switches between Direct Input(as the emulation is running) and PSP-style input(as the Settings menu is running). When the emulation and UniPCemu starts, it executes a middle mouse button toggle to toggle Direct Input mode on(to redirect both virtual and physical keyboard keys to the emulated PC). Once the Settings menu is opened, on Android, it toggles it again to go back to PSP-style input. Once the settings menu is closed, it toggles it once again to switch back to Direct Input mode.

    The Direct Input thus should be disabled(PSP-input compatible, as used by the Settings menu) in the Settings menu, while enabled in the rest of the emulator. Unless there's an excess toggle somewhere? Input not working in the Settings menu means either it's in Direct Input mode, or there's something wrong with the keymappings and/or Settings input retrieval itself?

    The basic keymapper works with my Android device, but somehow fails when in the Settings menu, just like yours. Although I don't know for sure: since the input toggle is all that's changed, that might be the cause of it not working, or being related to the problem?

  82. superfury repo owner

    Well I've found out something's definitely wrong with the Direct Input toggling: letting the emulator boot normally shows it's in PSP mouse mode, while it should be in Direct Input mode. So there's a missing toggle or a toggle top much somewhere(or memory is corrupted, somehow affecting the toggle)...

  83. superfury repo owner

    Just found the cause of the problems with Direct Input toggling: The psp_input_init was called twice instead of once: one time during emulator initialization(main.c) and once in the core initialization(emucore.c). I've removed the call at main.c to fix the initialization input toggle on Android devices.

    I've also found out that psp_input_done wasn't called at all, causing emulator reset to be stuck in the input(Direct Input vs PSP input) mode, because it wasn't untoggled and retoggled, but instead only untoggled when the emulator starts again.

    Also, the toggle when returning from the Settings boot option(yellow text) when not clicked on Android, was called even when the Settings menu was disabled, causing a toggle when not supposed to(although this isn't the case currently, since the Settings menu is currently always enabled(special Settings menu enable define is always defined).

    This should fix the Settings menu, as well as the input during normal execution, to be correct.

    Edit: I've added a little button labeled "Set" to the Android version of the input screen. Clicking this will now enables a flag, which causes the Settings menu to be opened(as an alternative to the usual PSP Select key, since it's unavailable due to Direct Input mode, as well as being required during Direct Input mode for being mapped to the normal backspace key in the emulated system).

    Is the Android version working correctly now(and the OSK)?

    Edit: Btw, how do i release the application in apk format? Must I call ant release with a seperate keystore file? Since it's a public repository, shouldn't those keys be privately kept(since it's the password is of a Google Account or something like that?) According to http://www.varunpant.com/posts/signing-android-release-apk-from-the-command-line-via-ant

  84. superfury repo owner

    The Android buttons are now working as they should: PSP Select(Previously Backspace conflicting)&Start(Previously Enter conflicting) is disabled(Settings menu is enterable by that new button I've mentioned). Enter is mapped to PSP cross, Escape to PSP circle and Space to triangle. Square is still mapped to numpad 4(which is usable through the OSK).

    The Settings menu now properly stops Direct Input mode, and when normal emulation is resumed, Direct Input mode is enabled again. The reboot doesn't have bugs anymore.

    How is your version working(Pelya's SDL)?

  85. Lubomyr Lisen

    I receive reaction only on arrow buttons. All other codes (RETURN,SPACE,KP4,ESCAPE,BACKSPACE) - not works. O, Set - (buttons in right-bottom corner) - not work For menu i changed screen-resolution same as for PSP (480x272)

  86. superfury repo owner

    Is ANDROID defined in your builds(Does #ifdef ANDROID take effect?)? The emulator only applies those mappings when ANDROID is defined as a constant by the compiler(Makefile). I've added the -DANDROID CFLAGS to the Makefile.android CFLAGS just to be sure(if the compiler doesn't already do this automatically). That should make sure the Android functionality is enabled.

    What do you mean you've changed the screen resolution for the menu? This is automatically set by the emulator?

    Can you take a look at emu/io/input.c? Are the parts within "#ifdef PELYAS_SDL" correctly done? I've assumed that sdl_joybuttondown and sdl_joybuttonup have which set to 0 and button set to the button that is pressed/released(0x0 - 0xF)? Is that correct?

    The movement of fingers (as wel as the location of a newly pressed finger, which should fire before the sdl_buttondown for newly pressed fingers in order to work) only happens when jball.which is 0 and ball is the button(0x0 - 0xF)? For those valid balls(actually finger indexes), xrel and yrel are the normalized 16-bit location on the rendered screen? So -32767 to +32767 range translate to SDL2's 0.0 - 1.0 range? I've changed this in my latest commit. It does assume that for newly pressed fingers, the movement event should fire before the finger press event. Otherwise the finger press event will use the previous screen coordinates for the fingerpress(using the previous location).

    Is this all correct? Is it working now(with my latest commits)?

  87. Lubomyr Lisen

    ANDROID flag transfered via previous SDL script and used by Makefile Not necessary to add it into Makefile.

    By default app tried to open 800x600 screenmode. Menu text very small with it. #if defined(ANDROID) && defined(PELYAS_SDL) //Get device display mode xres = PSP_SCREEN_COLUMNS; yres = PSP_SCREEN_ROWS; GPU.fullscreen = 1; //Forced full screen!
    goto windowready; //Skip other calculations! #endif

    Sorry but i do not have any knowledges about joystick event. I can't test now, maybe tomorrow

  88. superfury repo owner

    Just had an idea: instead of lowering the resolution the app uses(and waste the device's highres screen), I can also adjust the text surface to scale itself up to the used resolution by stretching itself instead of plotting directly. That way, the text can become as big as it can be(resized to the screen width/height while keeping it's aspect ratio), while being better readable and touchable, but keeping screen quality maximized. Should be a simple matter of calculating the same way it currently renders VGA graphics, but applying that enlargement factor to the pixels on the screen(<1 with 800x600) and of course adjusting the GPU&text surface's click coordinates and surface dimensions(on the screen, not the character buffer itself). Shouldn't be too difficult to implement?

  89. superfury repo owner

    I've changed a few things about PSP&Android rendering and detection:

    • SDL1&2 non-PSP devices now automatically detect the first available high-resolution screen resolution to use.

    • With Android devices, the text surfaces now stretch themselves to fullscreen resolution(including touch actions), making them more readable.

    • A new define has been added to add new, unsupported devices to use static screen resolutions.

    • Added click and render priority to the text surfaces (instead of just processing all of them during clicking, the top surface (last registered surface that renders) will, when clickable, make the other surfaces ignore the click. Also, empty text surface areas won't be clickable anymore(allowing the Settings menu to passthrough click actions to lower surfaces, like the Escape key on the OSK, which is under the Settings surface, in priority and rendering, to make Settings options clickable).

    • Settings defaults now apply the required settings for the static screens automatically(according to the global define).

    • Fixed an error in the Keypad 6 key on the OSK.

    Is your version working now?

  90. Lubomyr Lisen

    Menu is readable now. But i still do not have any reaction on keyboard pressures except arrow keys. (tested with real and virtual keyboards). Set and O button also not works.

    P.S. If you work with creating android SDL2 port, i'm not sure that developing another android port can have any sense.

  91. superfury repo owner

    Currently trying to go with the method of Portable Ubuntu described at Pelya's page (https://github.com/pelya/commandergenius).

    First try failed with extracting the Portable Ubuntu.exe(cannot open archive for some reason). Second try failed on a dll extraction. Third try (after manually deleting the destination folder) extracts fully.

    Now to install the tools needed? I've downloaded the android SDK and NDK for linux. Also need to install the tools somehow? Any tutorial available for this?

    Btw, I try to keep UniPCemu compatible with SDL1(Also including the version you're using) and SDL2. Since it's written for SDL1 originally, but uses SDL2 extensions(Joystick mainly) when available(compiled using -DSDL2 flag). That makes it compatible with you guys using SDL1(and ports of it, like the PSP I made it for originally, as an better gaming alternative to Dosbox and Bochs ports), but use SDL2 for systems supporting it(Atm Windows, Linux and Android). Unfortunately, it's too heavy for the PSP(and my Android phone too it seems(emulation running at 3-5% speed on my LG-P710(sound hardware disabled in the settings), 1% on the PSP, last time I checked), although the OSK is reasonably responsive.

    Any way to make it much faster, without losing quality&compatibiliy? Dosbox is reasonable, but it cheats(hacks, cheap inaccurate emulation etc) in accuracy afaik?

    Also, you guys seem to be using Pelya's SDL instead of SDL2?

  92. superfury repo owner

    I've locked the Android display to fullscreen, with support for orientation changes(although it should be disabled by the compilation process's flags), using the SDL_WINDOWEVENT_SIZE_CHANGED on SDL2 builds.

    I've changed both Android scripts to use Landscape display.

    I've fixed the I/O module loading of disk images. I've also changed much of the hardware to use a global 14MHz clock, which is used by all supported hardware not using their own clocking based on nanosecond time.

    I've also optimized the GPU Text Surface rendering and optimized Adlib/OPL2 to use precalculated Tremolo/Vibrato values. Further, I've added PCI change handling, which is used by the ATA IDE controller to force it's interrupt line to 0xFF for better detection of Parallel ATA.

    I've also fixed a bug in rendering text surfaces, which was drawing from invalid memory(rendering too much lines from the text surface). Further I've fixed the quality of the stretched text surface when in fullscreen mode(when not Directly Plotting the text on the screen 1:1). That should improve quality and readability, as well as fix the crash of Android builds.

    Is the Android version working now? Does it run the used BIOS(CPU percentage isn't 0)?

  93. superfury repo owner

    Looking at https://github.com/pelya/commandergenius/blob/sdl_android/project/jni/application/xserver/gfx.c leads me to believe that the coordinates specified by xrel and yrel during the JOYBALLMOTION event are the coordinates on the screen itself, instead of relative coordinates. I've modified the code accordingly. Does touch input work now?

    Edit: I've looked at the source code itself: https://github.com/pelya/commandergenius/blob/sdl_android/project/jni/sdl-1.2/src/video/android/SDL_androidinput.c line 441. It seems it sends the push button event first, immediately followed by it's coordinates in a joyballmotion event. I've modfied Pelya's SDL support to now set the button status to 2(meaning pending button press). The following joyballmotion events then execute the touch press for the first event. This will also set the button status to 1(button pressed), changing the joyballmotion events from the press event into motion events. The release event is unchanged. If a release event immediately follows the press event, but no motion in between, the touch event won't be registered(since it has no coordinates) and any motion events following the release event will register the new coordinates, but won't affect anything by executing the SDL touch events themselves(status=0 means that the button isn't used atm). Basic coordinates sent without presses will move the location of the finger, but won't affect the emulator(which runs based on the finger functions).

    Is this correct? Is the touch input working now?

  96. superfury repo owner

    Your APK still has the problems that were solved in my latest commits. Otherwise, touch input is working without any problems (it should have been fixed in commits https://bitbucket.org/superfury/unipcemu/commits/d40014e27d89567c86f92445347d4a5bb3244b93 and https://bitbucket.org/superfury/unipcemu/commits/1fc00bdce60ed3b883abdb721f122e8c9edc7f83 ).

    Now I still need to find out why the CPU emulation seems to be idle all the time(or running really, really slow on my LP-P710 phone) after running the Settings boot escape instruction. Any clue what's going wrong there?

  97. superfury repo owner

    I've added a little timing to the Android CPU speed display: it now also displays the amount of cycles the CPU executes each second. Does it display any other amount of cycles than 0? If it's constantly 0, then the CPU isn't running at all when the emulation is running. That could indicate a timing error in the nanoseconds timer, or something else, causing the CPU emulation to become unresponsive.

  101. superfury repo owner

    I've modified the MMU to:

    • CPU mapped segment:offset accesses are handled in MMU.c, paging.c and the protection.c(For protected mode).

    • Memory and MMIO access are handled in mmuhandler.c/h.

    • Removed the MMU_translateaddr function, as it isn't used anymore.

    Furthermore, some "MMU" functions have been renamed "memory" functions, as they deal with (memory mapped) memory instead of MMU(segment:offset) memory(a.k.a. linear non-paged memory), since this applies to DMA memory transfers as well.

    I've also fixed two important bugs: - The FIFO buffer was initializing it's data(laststatus), even when it isn't allocated(dereferencing a NULL pointer).

    • The lastxy variable, used to store coordinates for finger motion, had it's block sizes reversed (lastxy[2][0x100] should be lastxy[0x100][2]). It was thus overflowing it's size with more than 2 fingers were used.

    What about this commit? Is it running correctly now with touch and execution?

  102. superfury repo owner

    I've just managed to fix the Sound rendering that was generating too many samples(about 40 seconds of samples using a 4096 sample buffer), which was overflowing and causing the application to crash on Android.

    I've also added a case-insensitive "nosound" parameter, which will disable sound output(but it will still be generated by the hardware. The rendering process itself (SDL init, SDL cleanup and rendering from the buffers to SDL) is disabled, when it's specified. That's convenient when someone wants to run it without sound support available(instead of the application crashing because it can't find a sound output device).

    Further: - Fixed the plain SDL(2) SDL_getTicks needing to wrap around 32-bits instead of 64-bits, thus fixing the high-resolution timing on plain SDL timings builds(where there's no other timers (like Windows/PSP) supported). - Audio should now be able to run, even at 1 cycle settings(rendering whole chunks of 1 second audio in that case). - Support has been added for the SDL2's SDL_QueueAudio function(currently disabled for all builds, can be enabled by enabling the define). - Fixed many paths used throughout the emulator. Now the Dynamic/Static/Floppy creation, Disk conversion from various types, logs&capture cleanup, VGA color dumping(VGA Dump option in the Settings menu), VGA VRAM Text dump(also the VGA Dump option in the Settings menu) and ISO disk dumping for mounting and booting from it should all use their correct paths(disks/log/captures paths), instead of looking in the current working directory on Android.

    This should fix a lot of little bugs that were on Android builds(except for the case-insensitive "nosound" parameter now being supported as a parameter for the application). The Android build from Windows now runs without crashing. The only problem left is that it's terribly slow atm(it gives 101 cycles/S after a while. The logs had about 40 second gaps between each instruction executed?).

    Also, the text surfaces seem to be incorrectly updating their data for some reason(not clearing text when required to).

    How are your builds running?

  103. superfury repo owner

    I've managed to fix the updating of the screen: the renderer mode wasn't always clearing the screen for the text surfaces to be written on, so old pixel data would stay on the screen until overwritten(by changes of the text surface's contents) until the first actual screen is rendered by the graphics card emulation.

    The emulation is still quite slow (it starts 101 cycles/second, finally ending up with ~87 cycles/second). Any idea why there is about 40 seconds between every instruction executed? The emulator will execute a delay using SDL_Delay(0) effectively, but do you have any idea why this ends up with such huge delays (according to the logs, which are based on the high resolution clock, in this case SDL_getTicks)?

    Edit: After a while, it currently gets to 250 cycles/S according to the application's measurement.

  104. superfury repo owner

    I found a bug in the updateAdlib function(which updates Adlib state when emulated): There were 2 parameters (timepassed(ns) and MHZ14passed(14MHz ticks)). It was using the MHZ14passed, but the caller(emucore) only used one parameter(MHZ14passed). Removing the timepassed from the function parameters fixed the big problem causing the Adlib to update an incorrect amount of 14MHz cycles(junk that's in RAM).

    Now the emulation runs at ~2250 up to 2500 cycles/S. Also, the application is runnable again(It's responsive, although the emulation itself is very slow, compared to PC).

  105. superfury repo owner

    I've modified the OSK and Android builds to respond to both the OSK's new Android-style(Enter/Escape/Space), as well as the PC-style(Using the numpad buttons). I've also added Backspace as an alternative to Escape on Android builds. This should make the OSK better usable(since the buttons can be hidden behind the Settings menu, causing it to be difficult to use). Since there's now the alternative buttons supported on the OSK as well, this fixes the troubles between PC and Android builds(using the OSK), as well as making the Escape key have alternatives (Backspace(unused otherwise on Android) and Numpad 4 on the OSK). They have better locations on the screen as well, since always at least one of those is available on the OSK(and not being behind the Settings menu's text, which makes it hard to tap).

    Edit: I've just made the OSK easier to use: it now will detect the area covered by the key (and adding one horizontal and vertical character column/row to it), then use that area as a button. That way the text surface is practically unchanged, but the buttons on the OSK are bigger and easier to touch. As long as you hit on or to the right/below the label, it will now see it as a press of that key(essentially the area has been enlarged from just the visible label characters to become the entire area of the label with one extra row and column).

    How are your Android builds running? Mine runs without problems, although it's still slow(2250-2500 cycles/second).

  106. superfury repo owner

    I've fixed the VGA timer initialization, optimized the GPU to only render frames that are dirty, increased text surface rendering to perform it in two stages(first rendering the font to an immediate buffer, then rendering that immediate buffer to the rendering buffer, instead of rendering it to the rendering buffer immediately(and requiring each pixel to be calculated up to 9 times. This also speeds up font decoding, since it can read the font once, then split it into it's 8 font pixels, instead of having to check the font, character and shift each time). I've also improved the DRO player to respond to the termination of the emulator, so it won't crash when the application is terminated while a DRO file is playing.

    Do your Android builds now run faster as well? The PC version(Windows) seems to have sped up quite a lot (up to 2-3 times as fast now), mostly due to it's decrease of calculations needed when rendering text surfaces to the prerendered buffer.

  108. superfury repo owner

    Is there a way to profile on Android and see what's slowing it down so terribly much? It's literally running at a fraction(<1%) of the PC 2.0GHz speed(The Android LG-P710 should be able to handle it , normally?).

  109. superfury repo owner

    I've optimized the app a bit by using nanosleep(0ns) to implement delays(instead of SDL_delay) and gettimeofday(Windows version moved to the highrestimer.c for general support on Windows) to provide accurate timing better than SDL_getTicks. It now seems to run up to ~4500-5000 cycles per second(~0.1% speed) while heavy stuttering sound during playback of music when set to use 1 cycle clock(1kHz cycle clock), running at ~15% (60-80 cycles/second).

    Can you see why it's having troubles on Android compared to the PC version(which runs at ~100%@4.0GHz, ~40%@2.0GHz). I'm using a LG-P710 Android phone to test it.

    Is there any way to profile Android apps on Windows? android-ndk-profiler refuses to compile into UniPCemu. I've put the repository files of the profiler into the android_ndk_r12b/sources/android-ndk-profiler folder, but the compiler doesn't find the library and refuses to compile(import)?

  110. superfury repo owner

    I've just managed to get it compiling: I needed to patch the Android.mk/Android_static.mk to use the profile parameter as a full variable as well, specifying the android-ndk-r12b, which in turn contains the sources directory, which in turn contains a android-ndk-profiler directory containing the files from the android-ndk-profiler repository. I've simply cd-ed to the folder in the Android prompt(MS-DOS batch file in the root of my UniPCemu repository) and execute ndk-build to compile it for usage.

  111. superfury repo owner

    After the recent commits, I've finally managed to get it's speed better(up to 20% with 8088 XT with CGA)! Various parts have been improved and updated(CD-ROM fixed with VIDE-CDD.SYS, 80486 implemented(minus TLB), various CPU bugfixes(80286+)). So now is a good time to recompile again! :D

  113. superfury repo owner

    I've just added a commit that remaps PSP SELECT&START to = and '. Also, I've removed the automatic Direct Input toggles, as they can be executed with RALT-F10(Both on virtual keyboard and physical keyboard). Can I assume all Android devices have either a touch screen, keyboard with RALT/Alt gr. and F10 keys or both?

  116. superfury repo owner

    Does the "Application has stopped" message disappear when manually editing the SETTINGS.INI file to not use 1 cycle/second(either 1kIPS(in IPS mode) or 1K cycles/second(in cycle-accurate mode))? I'm currently trying to work out what causes the 1 cycle/second mode to crash the whole app(even when running the initial instructions required to start the settings menu when starting the app). Somehow everything that's configured below 2 cycles/second(either setting a value of 2 and up or selecting 0(which will load a default CPU-specific cycle setting instead, which is the default setting)) causes the Android app to crash(but no known/noticed issues with the Windows version. So it seems to be something timing-related(the size of a block of time to step the hardware).

  117. superfury repo owner

    Managed to fix two of the possible causes: - Negative pointer address parsing the redirect.txt contents. - Underflow offset fixed with CPU older than 80286, reading an invalid CPU timing table for 80(1)86 CPUs. - Various memset calls had non-pointer variables passed without required &-prefix, passing integer variables implicitly casted to pointers that were cleared.

    No bugs other than normal CPU bugs observed atm.

    I haven't released it yet due to unfound CPU bugs with some software, but you should still be able to compile it? Is it still running with Pelya's SDL?

  119. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
resolved
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!