VOGONS

Search

Common searches

Search results

Display options

Display options

Re: Unipcemu slow on Android?

Posted on 2017-05-12, 21:54

I've modified the rendering code to precalc the start of the row to render on the rendering surface, avoiding multiplications every pixel, reducing it to once every scanline(on the main rendering surface rendered to SDL, which is flipped into view(forced update actually, using the custom 'flip' …

Re: Unipcemu slow on Android?

Posted on 2017-05-12, 16:21

I might have found a problem in the text surface rendering code, which may have been the cause of the extreme screen updates: it was checking the border of a character cell for updating clickable text(e.g. the Set button in the bottom right of the screen to open the Settings menu), but was comparing …

Re: UniPCemu 80286+ problems?

Posted on 2017-05-11, 10:11

I've just implemented proper support for 16-bit and 32-bit BIU. Now the SuperSoft/Landmark BIOS(from minuszerodegrees) halts during the protected mode test(passing all other tests, except before display is filled it still gives audio tones signifying hardware problems not showed on screen. Those are …

Re: (S)VGA Chain-2 / Odd/Even mode

Posted on 2017-05-08, 11:03

As far as I know(and implemented in UniPCemu): Sequencer memory mode register bit 3 set write and read memory to use chain-4 mode(different mapping on Tseng SVGA vs all other VGA's). Otherwise, it uses either planar or odd/even mode: Sequencer Memory mode register bit 2, when cleared , sets odd/even …

Re: Unipcemu slow on Android?

Posted on 2017-05-07, 18:02

I've optimized the text surface rendering by precalculating all horizontal and vertical(horizontal and vertical axis seperarated in two precalc buffers) locations of the screen, which maps the screen coordinates to the text surface coordinates. Now the GPU_textrenderer doesn't even show the GPU_ …

Re: Unipcemu slow on Android?

Posted on 2017-05-07, 12:49

After adding a seperate batch file for analyzing the results from the profiling run(and looking at the resulting data), it seems the main problem is the text surface renderer itself: this takes up most of the CPU time. CPU_initLookupTables can be ignored(it's only called once when emulation of a …

Re: Unipcemu slow on Android?

Posted on 2017-05-07, 11:54

I just found out something: triggering UniPCemu's RALT-F4 termination shortcut makes it handle the termination the emulator way, triggering SDL_QUIT event and emulator shutdown properly, logging the gmon.out file in the project's used directory. So for some reason, the SDL_QUIT event(or SDL …

UniPCemu 80286/80386+ protected mode problems?

Posted on 2017-05-06, 16:30

When I try to run software other than the basic IBM AT BIOS starting up or running 80(1)86 MS-DOS software, it will end up at strange points in the executable code. Windows 95 setup(on the 80386+ emulation) will simply end up with infinite General Protection faults on an REP MOVSD instruction. The …

Re: Unipcemu slow on Android?

Posted on 2017-05-05, 18:41

I've just ran it on my Samsung Galaxy S7, but no gmon.out file is generated when i terminate the application(it's called in the source code, though). Startup code: #ifdef NDK_PROFILE setenv( "CPUPROFILE_FREQUENCY", "500", 1 ); // interrupts per second, default 100 monstartup("libmain.so"); is_ …

Re: Unipcemu slow on Android?

Posted on 2017-05-05, 18:26

I've managed to make it continue compiling up until it tries to compile GPU_mcount.S(with a lot of compiler errors): [arm64-v8a] Compile : android-ndk-profiler <= gnu_mcount.S C:/androiddevdir/android-ndk-r12b/sources/android-ndk-profiler/gnu_mcount.S: Assembler messages: C:/androiddevdir/android- …

Re: Unipcemu slow on Android?

Posted on 2017-05-05, 16:16

Well, that's the strange thing: I specify the report path (C:/androiddevdir/android-ndk-r12b/sources or it's subdirectory makes no difference), but it refuses to find it. Specifying an invalid path makes it throw a warning that it's ignoring the invalid import path(e.g. adding xxx to test to the end …

Re: Unipcemu slow on Android?

Posted on 2017-05-05, 13:06

It uses a Samsung Exynos 8890 Octa CPU(Android) as far as I know(clocked at 2.4GHz). I'm trying to get the android-ndk-profiler to compile, but it just won't take the NDK_MODULE_PATH I pass to the ndk-build.cmd. I execute "androidprompt.bat profile" in the Windows command prompt(or through shortcut …

Unipcemu slow on Android?

Posted on 2017-05-05, 11:50

When I try to run it on Android, it's very slow (+16000 cycles/second, supposed to be ~4770000/second (14318180/4/second to be exact). Is this simply because of it's 0ns delays every few cycles? (Source code in dignature) Is there a good way to profile on Samsung Galaxy S7 w/ Android NDK (Windows)? …

Re: UniPCemu cycle accurate 8088 implementation

Posted on 2017-05-03, 16:41

That looks a bit better. Next problem: the bus going idle only happens after a T4 state completes (it doesn't interrupt the current transfer). As you have it, the idle is between the T3 and T4 states (e.g. line 3155). I've currently just implemented the bus going idle logic with the T1 state …

Re: UniPCemu cycle accurate 8088 implementation

Posted on 2017-05-03, 13:34

I've modified the BIU to take those idle cycles without increasing the T-state. I've modified opcode 0xEB to use 16 execution cycles, of which the first 6 cycles idle the BIU, keeping the same T-state. This is the new log: https://www.dropbox.com/s/9qk4rzcm67vxeh9/debugger_8088MPH_credits_20170503_ …

Re: UniPCemu cycle accurate 8088 implementation

Posted on 2017-05-03, 12:29

That's actually a jump being executed(JMP 026C). It uses 15 CPU EU cycles, of which 15 cycles BIU disabled(cycles_OP is loaded with 15 and BIU idle cycles is loaded with the (same) value in cycles_OP to make it idle around, preventing fetches from starting on T1). So it's the effective 16 idle EU …

Re: UniPCemu cycle accurate 8088 implementation

Posted on 2017-05-03, 11:51

It's essentially the same? Idle is/becomes T1 when there's something to do(first state of transfer), idle otherwise. On the real hardware, the T1 state is when the address to access is placed on the bus. So if the EU needs to start a bus access, it will be able to if the current bus state is idle …

Re: UniPCemu cycle accurate 8088 implementation

Posted on 2017-05-03, 10:14

I've made a new log(with the new simplified timings): https://www.dropbox.com/s/di8u0d73unag9m1/debugger_8088MPH_credits_20170503_1207.zip?dl=0 It now leaves out all those cycle information, using only the first part (T-, S- or W-state) and leaving all other cycle timings that were set by the CPU. …

Re: UniPCemu cycle accurate 8088 implementation

Posted on 2017-05-03, 07:18

It's essentially the same? Idle is/becomes T1 when there's something to do(first state of transfer), idle otherwise. Edit: I've modified the BIU to fix the problems with BUS control on T1/T3(it kept having an inactive BUS in the middle of transfers during the BIOS execution, causing it to infinitely …

Re: UniPCemu cycle accurate 8088 implementation

Posted on 2017-05-02, 21:16

So if I understand it correctly, I should make it keep T1 state while nothing is to be done? Thus starting any transfers(Instruction or data) the very same cycle something's ready to process. So keep it stuck at T1 state until something's requested(or DMA takes over) instead of the current inactive …

Page 152 of 229

Go to top of page Go to top of page
Close window
Close window