superfury wrote on 2024-01-22, 11:39:

Why does everyone keep calling it 'UniPCEM'? It's name is UniPCemu.

Isn't it obvious? The new name resembles PCem that exists for 15+ years, it's easier for people to remember the prefix rather than the complete name and capitalization. I understand your justified frustration though.

A

konc wrote on 2024-01-22, 13:20:

superfury wrote on 2024-01-22, 11:39:

Why does everyone keep calling it 'UniPCEM'? It's name is UniPCemu.

Isn't it obvious? The new name resembles PCem that exists for 15+ years, it's easier for people to remember the prefix rather than the complete name and capitalization. I understand your justified frustration though.

In fact, the reason it was originally renamed from x86EMU was because of a software compatibility layer with the same name (different case) conflicting causing confusion.

UniPCemu came from 'Univeral PC emulator', as the main thought behind it was a PC emulator that's cross-platform and easier usable on gaming consoles etc. (Starting off on the Sony PSP after all, because Dosbox was difficult to control with such inputs and not accurate enough to my tastes). I saw the Danzeff method and still found it slightly clunky, so made an improved version based on that. Finally also implemented Gaming mode (eventually with multiple mappings) to that for easier setup and gaming as well (Supporting 5 different mappings switched with 2 multi-button taps, which is down arrow + face button optionally)

superfury wrote on 2024-01-22, 14:23:

UniPCemu came from 'Univeral PC emulator', as the main thought behind it was a PC emulator that's cross-platform and easier usable on gaming consoles etc. (Starting off on the Sony PSP after all, because Dosbox was difficult to control with such inputs and not accurate enough to my tastes). I saw the Danzeff method and still found it slightly clunky, so made an improved version based on that. Finally also implemented Gaming mode (eventually with multiple mappings) to that for easier setup and gaming as well (Supporting 5 different mappings switched with 2 multi-button taps, which is down arrow + face button optionally)

Is your intended user base still PSP users? I imagine that niche is getting pretty small.

Both the PSP and PSVita ended up becoming very niche products, as smartphones evolved and became more powerful. People simply emulate these consoles on their smartphone. Personally, I love them both, and I intend to acquire them in the future for nostalgic reasons.

Rikintosh wrote on 2024-01-22, 16:28:

Both the PSP and PSVita ended up becoming very niche products, as smartphones evolved and became more powerful. People simply emulate these consoles on their smartphone. Personally, I love them both, and I intend to acquire them in the future for nostalgic reasons.

Luckily the PS Vita ports were pretty easy for the app, mainly due to PSP being similar and SDL2 being available. WiFi on the PSP was a bit of extra time implementing due to manual control of the WiFi signal that needed to be implemented into the app (official SDL_net 1.2 for PSP didn't exist until I ported it (relatively easily by modifying the header and adding a Makefile for pspsdk which doesn't support cmake (on Windows at least))). After that, I needed to add WiFi access point (dis)connecting support to the base framework as well (just for the PSP, as all other builds have it externally in the base OS).

Though I must admit the PSP might be getting a bit too slow for it nowadays (mainly because of it becoming heavy wrt the CPU emulation and perhaps some hardware (video cards) a bit as well), I still keep the code compatible with builds and still include it for releases (besides Vita and ofc all other platforms (Windows x86, Windows x64, Android (as many as the devkit(Android Studio or old ndk tools(mainly mips being dropped nowadays on the former)) allows) and Linux as well (though you'll need to compile it yourself due to the many flavours of it and me not knowing how to release it properly for it))).

I have a PSP and I used to have a Game Gear. Can't find the GG anywhere might have lost it when I moved to a new apartment. The PSP is still working tho

Hopefully I'm not hijacking this topic, because I don't feel that the question deserves a completely new thread.

Recently I tried 86box for the first time and installed FreeDOS to play some DOS games. 86box is configured to emulate a 486DX2 @ 66 MHz with Sound Blaster 16 and a PS/2 mouse. Generally, everything works quite right, as far as I can tell, but the mouse pointer movement feels exceedingly rapid, especially noticeable at lower screen resolutions like 320x200. This is in stark contrast with the smooth mouse movement I'm used to in DOSBox, which does not feel different from that of the host system.

At first I tried lowering mouse sensitivity in 86box settings, but it still did not feel right. Then I decided to tackle this from the side of the OS in the emulated machine. FreeDOS uses the CuteMouse driver, which has adjustable resolution settings, and I after some experimenting I set it to 1 for both mouse axes (which I guess is the original resolution without amplification?). It kind of fixes the excessive pointer movement speed, but still feels different from the DOSBox mouse behaviour. I have tried different drivers instead of CuteMouse, but they either don't work at all (DRMOUSE, for some reason), or cause glitches (original IBM PS/2 driver), or do not work with some games (PhysTechSoft MOUSE.COM). Digging a bit deeper, it looks like 86box tries to stay very accurate to how a real PS/2 mouse would work. Have I been spoiled by DOSBox in this respect?

MrFlibble wrote on 2024-02-03, 10:28:

the mouse pointer movement feels exceedingly rapid, especially noticeable at lower screen resolutions like 320x200.
...
CuteMouse driver, which has adjustable resolution settings, and I after some experimenting I set it to 1 for both mouse axes (which I guess is the original resolution without amplification?). It kind of fixes the excessive pointer movement speed

Yea, that was the acceleration. DOS/Windows, Mouse Acceleration and you

but still feels different from the DOSBox mouse behaviour

The github link you posted already explains why and what the solution is (although it probably still won't be as smooth); use ps2rate, or use the MS mouse driver and increase the rate: Mouse polling rate/smoothness in DOS

AFAICT Dosbox doesn't emulate mouse behavior of old hardware.

eddman wrote on 2024-02-03, 11:25:

Yea, that was the acceleration. DOS/Windows, Mouse Acceleration and you

The github link you posted already explains why and what the solution is (although it probably still won't be as smooth); use ps2rate, or use the MS mouse driver and increase the rate: Mouse polling rate/smoothness in DOS

Thanks for the links!

I thought ps2rate was a Windows-only programme.

MrFlibble wrote on 2024-02-03, 11:33:

I thought ps2rate was a Windows-only programme.

Well, it is. I meant it as a solution for the mouse rate in general, if the OS doesn't have to be DOS. You'd have to use MS mouse then, or another driver that can change the rate.

I think I figured out what was "off" with CuteMouse using default settings. This is from the v1.9 changelog:

- Small mouse movements are now also doubled in auto resolution mode.

Apparently, the original intent is/was that "small movements" should be unaffected by the resolution selection:

CTMOUSE supports 9 fixed resolution levels and auto resolution. Resolution defines how the mouse movements are added to the curs […]
Show full quote

CTMOUSE supports 9 fixed resolution levels and auto resolution. Resolution
defines how the mouse movements are added to the cursor position. Small
mouse movements at any resolution produce the same cursor movement; this
allows precise cursor positioning on the screen. Larger mouse movements
are multiplied by resolution level to produce the cursor movement; this
allows rapid cursor movement across the screen without big efforts.
~emphasis added

I suppose that at the 320x200 resolution, there's a greater chance of "small" movements overall, so no wonder the pointer would zip across the screen like it did in auto mode if small movements are also doubled. This also explains why I could get kind of okay mouse movement in 320x200 games but somewhat sluggish movement at 640x480 resolution when manually selecting lower resolution settings.

I suppose I should be sticking with resolution 1 or 2 for the time being (I guess resolution 1 means no multiplication, i.e. the "raw" mouse movement?). BTW, resolution 1 works okay in Warcraft II, although setting it to 2 makes it somewhat more robust.

In fact, there are a lot of complaints about the mouse on the 86box, they tried to improve it compared to the PCEm, but it ended up making it just as bad.

I also think that mouse drivers are resolution oriented.

On real hardware, I once had a mouse driver installed normally in VGA mode (it was in autoexec.bat),
then I had switched to CGA emulation manually by using a mode utility.

The result was that the mouse pointer was moving oddly and that it nolonger moved across the whole screen (application was a CGA painting program).

I then exited then application, removed mouse driver from memory (or disabled it) by issueing the appropriate command line switch and loaded the mouse driver again.
This time, with the mouse driver being executed in CGA emulation, the application ran as expected.

Jo22 wrote on 2024-02-03, 16:33:

On real hardware, I once had a mouse driver installed normally in VGA mode (it was in autoexec.bat),
then I had switched to CGA emulation manually by using a mode utility.

The result was that the mouse pointer was moving oddly and that it nolonger moved across the whole screen (application was a CGA painting program).

Interesting, I had a sort of similar problem (although not really graphics mode related, at least it seems so) when I tried the PhysTechSoft driver. It worked fine in the Allegro 3.0 setup programme used in MBF 2.04, but when I started The Elder Scrolls: Arena, the cursor only moved across the left half of the screen.

Even more oddly, when I tired the 1987 (?) IBM PS/2 driver that you had posted a while ago, it caused the screen of the Allegro setup programme to be split into two duplicates with halved width.

Anyway, CuteMouse seems to work fine. Except it's odd that the default mode tries to speed up the pointer no matter what.

There's one more thing I'm noticing. When I play first-person games that use VGA mode 13h, like Heretic, in DOSBox there's some very pronounced screen tearing when turning around. However, in 86box it seems much less noticeable -- I wonder why? is it just me, or perhaps more accurate VGA card emulation produces this result. 86box' default renderer setting is to "synchronise with video", and I haven't touched that, nor have I enabled VSync.

MrFlibble wrote on 2024-02-03, 17:46:

Interesting, I had a sort of similar problem (although not really graphics mode related, at least it seems so) when I tried the […]
Show full quote

Jo22 wrote on 2024-02-03, 16:33:

On real hardware, I once had a mouse driver installed normally in VGA mode (it was in autoexec.bat),
then I had switched to CGA emulation manually by using a mode utility.

The result was that the mouse pointer was moving oddly and that it nolonger moved across the whole screen (application was a CGA painting program).

Interesting, I had a sort of similar problem (although not really graphics mode related, at least it seems so) when I tried the PhysTechSoft driver. It worked fine in the Allegro 3.0 setup programme used in MBF 2.04, but when I started The Elder Scrolls: Arena, the cursor only moved across the left half of the screen.

Even more oddly, when I tired the 1987 (?) IBM PS/2 driver that you had posted a while ago, it caused the screen of the Allegro setup programme to be split into two duplicates with halved width.

Anyway, CuteMouse seems to work fine. Except it's odd that the default mode tries to speed up the pointer no matter what.

UniPCemu tries to side-step the whole problem by making the mouse only use real movement (translating depending on screen DPI reported by SDL2 and up, defaulting instead on SDL1 (where it isn't available)). It records all mouse movement in both mickeys and mm to get compatibility with the mouse using that.

PCEm v.17 is generally more stable for me compared to 86box. The biggest problem with PCEm is the CD Audio is bugged, sometimes it won't work and it's volume is lower than it should.

86Box doesn't have this issue but i can see more games crashing on it, more often. But the biggest issue with 86box for me is the lack of VRR... I use a 240hz monitor and 2D scrolling games on PCEm scroll very smoothly if the emulation speed is 100%. On 86box is a stutter fest because it won't sync properly (again, emulation speed is 100% in all cases, it's not a performance issue).

For that reason alone PCEm is the superior choice.

After dosbox I find pcem quite functional and once setup configured it can be used just like a normal pc unfortunately my host machine is lacking and best I can do is stable win95 and patchy win98.
Dosbox is quite involved and I’m not very dos savvy and always need to use cheat sheets to mount and adjust settings

Imgema wrote on 2024-02-21, 07:02:

86Box doesn't have this issue but i can see more games crashing on it, more often. But the biggest issue with 86box for me is the lack of VRR... I use a 240hz monitor and 2D scrolling games on PCEm scroll very smoothly if the emulation speed is 100%. On 86box is a stutter fest because it won't sync properly (again, emulation speed is 100% in all cases, it's not a performance issue).

I've not tested 86box' renderer options very thoroughly, but it has a vsync option as well as an option to set the frame rate. Can I assume from your report that these do not work as intended and there are vsync problems in 86box even with the option enabled?