PCEm. Another PC emulator.

Schedules and announcements about program releases.

Re: PCEm. Another PC emulator.

Postby SarahWalker » 2018-2-01 @ 18:08

I provided the benchmark results justifying those changes here : http://pcem-emulator.co.uk/phpBB3/viewtopic.php?f=4&t=877.
User avatar
SarahWalker
Newbie
 
Posts: 60
Joined: 2016-5-12 @ 17:07

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-2-02 @ 03:32

Thanks for showing the results.

Also, is it possible to significantly improve the performance of pcem's interpreter cpu core like in dosbox's normal core.
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

Re: PCEm. Another PC emulator.

Postby SarahWalker » 2018-2-02 @ 19:59

There might be optimisations there. But since PCem has the dynamic recompiler these days, why bother?
User avatar
SarahWalker
Newbie
 
Posts: 60
Joined: 2016-5-12 @ 17:07

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-2-03 @ 04:05

I agree given the optimizations are small. However, it would be worthwhile if the performance gains are high, such as >25%. I haven't seen any benchmarks in other x86/x87 emulators that show that gain is even possible.

One advantage is for considering or benchmarking against a dynamic recompiler core in a non-x86/x64 computer platform. There may be cases where an interpreter core is useful for other systems and where some early era of games are playable.
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-3-15 @ 05:28

Code below for exchanging openal dependency for directsound (credit to Winquake). It produces audio but requires further work and testing.
Code: Select all
Requires the following modifications in addition to the code below:
* Replace object file soundopenal.o in Makefile with dsound.o
* Link to the directsound library: LIBS += -ldsound

Only tested in an older, non-SDL2 pcem build modified
 for use of a single input sound source (ex. no CD audio)

For development only

diff -rupN pcem-orig//dsound.c pcem//dsound.c
--- pcem-orig//dsound.c
+++ pcem//dsound.c
@@ -0,0 +1,165 @@
+#include <windows.h>
+#include <dsound.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include <math.h>
+#include "ibm.h"
+#include "sound.h"
+
+#define DIRECTSOUND_VERSION 0x0500
+
+// 64K is > 1 second at 16-bit, 22050 Hz = 0x10000 buffer size
+#define SECONDARY_BUFFER_SIZE   0x4000
+
+static void*         lpData;
+static LPDIRECTSOUND       pDS;
+static LPDIRECTSOUNDBUFFER    pDSBuf;
+
+HWND            ghwnd;
+
+void dsound_init(void);
+void dsound_free(void);
+
+/*
+==================
+dsound_init
+==================
+*/
+void dsound_init(void)
+{
+   DSBUFFERDESC      dsbuf;
+   DSBCAPS         dsbcaps;
+   DWORD         dwSize, dwWrite;
+   DSCAPS         dscaps;
+   WAVEFORMATEX      format;
+   HRESULT         hresult;
+   int         reps;
+
+   memset (&format, 0, sizeof(format));
+   format.wFormatTag = WAVE_FORMAT_PCM;
+   format.nChannels = 2;
+   format.wBitsPerSample = 16;
+   format.nSamplesPerSec = 48000;
+   format.nBlockAlign = 4;
+   format.nAvgBytesPerSec = 192000;
+
+   while ((hresult = DirectSoundCreate(NULL, &pDS, NULL)) != DS_OK)
+   {
+      pclog("directSound failed hardware in use\n");
+      return;
+   }
+
+   // pclog("1\n");
+
+   dscaps.dwSize = sizeof(dscaps);
+
+   if (DS_OK != pDS->lpVtbl->GetCaps (pDS, &dscaps))
+   {
+      pclog("no DS caps\n");
+   }
+
+   if (dscaps.dwFlags & DSCAPS_EMULDRIVER)
+   {
+      pclog("no DirectSound driver installed\n");
+      dsound_free();
+      return;
+   }
+
+   if (DS_OK != pDS->lpVtbl->SetCooperativeLevel (pDS, ghwnd, DSSCL_EXCLUSIVE))
+   {
+      pclog("setCooperativeLevel failed\n");
+      dsound_free();
+      return;
+   }
+
+   // create secondary buffer
+   memset (&dsbuf, 0, sizeof(dsbuf));
+   dsbuf.dwSize = sizeof(DSBUFFERDESC);
+   dsbuf.dwFlags = DSBCAPS_CTRLFREQUENCY | DSBCAPS_LOCSOFTWARE;
+   dsbuf.dwBufferBytes = SECONDARY_BUFFER_SIZE;
+   dsbuf.lpwfxFormat = &format;
+
+   memset(&dsbcaps, 0, sizeof(dsbcaps));
+   dsbcaps.dwSize = sizeof(dsbcaps);
+
+   if (DS_OK != pDS->lpVtbl->CreateSoundBuffer(pDS, &dsbuf, &pDSBuf, NULL))
+   {
+      pclog ("createSoundBuffer Failed");
+      dsound_free();
+      return;
+   }
+
+   if (DS_OK != pDSBuf->lpVtbl->GetCaps (pDSBuf, &dsbcaps))
+   {
+      pclog ("getCaps failed\n");
+      dsound_free();
+      return;
+   }
+
+   pclog("audio format: %d channel(s), %d bits/sample, %d bytes/sec\n",
+             format.nChannels, format.wBitsPerSample, format.nSamplesPerSec);
+   return;
+}
+
+/*
+==============
+dsound_free
+===============
+*/
+void dsound_free(void)
+{
+   int      i;
+
+   if (pDSBuf) {
+      pDSBuf->lpVtbl->Stop(pDSBuf);
+      pDSBuf->lpVtbl->Release(pDSBuf);
+   }
+
+   if (pDS) {
+      pDS->lpVtbl->SetCooperativeLevel (pDS, ghwnd, DSSCL_NORMAL);
+      pDS->lpVtbl->Release(pDS);
+   }
+
+   pDS = NULL;
+   pDSBuf = NULL;
+   lpData = NULL;
+}
+
+/*
+==============
+copy_buffer
+===============
+*/
+void copy_buffer(int16_t *buf)
+{
+   int      reps;
+   DWORD      dwBytes;
+   HRESULT      hresult;
+
+   // initialize buffer
+   reps = 0;
+
+   while ((hresult = pDSBuf->lpVtbl->Lock(pDSBuf, 0, 0, &lpData, &dwBytes, NULL, NULL, DSBLOCK_ENTIREBUFFER)) != DS_OK)
+   {
+      if (hresult != DSERR_BUFFERLOST) {
+         pclog ("lock sound buffer failed\n");
+         dsound_free();
+         return;
+      }
+
+      if (++reps > 10000) {
+         pclog ("unable to restore sound buffer\n");
+         dsound_free();
+         return;
+      }
+   }
+
+   // Copy audio data into buffer
+   memcpy(lpData, buf, dwBytes);
+   pDSBuf->lpVtbl->Unlock(pDSBuf, lpData, dwBytes, NULL, 0);
+   pDSBuf->lpVtbl->Play(pDSBuf, 0, 0, 0);
+
+   return;
+}
diff -rupN pcem-orig//sound.c pcem//sound.c
--- pcem-orig//sound.c
+++ pcem//sound.c
@@ -87,8 +87,7 @@ static uint16_t *outbuffer;
 
 void sound_init()
 {
-        initalmain(0,NULL);
-        inital();
+        dsound_init();
 
         outbuffer = malloc(SOUNDBUFLEN * 2 * sizeof(int16_t));
 }
@@ -124,7 +123,7 @@ void sound_get_buffer(void *priv)
         for (c = 0; c < sound_handlers_num; c++)
                 sound_handlers[c].get_buffer(outbuffer, SOUNDBUFLEN, sound_handlers[c].priv);
 
-        givealbuffer(outbuffer);
+        copy_buffer(outbuffer);
 }
 
 void sound_reset()
diff -rupN pcem-orig//sound.h pcem//sound.h
--- pcem-orig//sound.h
+++ pcem//sound.h
@@ -16,10 +16,7 @@ void sound_speed_changed();
 void sound_init();
 void sound_reset();
 
-void initalmain(int argc, char *argv[]);
-void inital();
-
-void givealbuffer(int16_t *buf);
+void copy_buffer(int16_t *buf);
 
 extern int sound_gain;
 
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-3-23 @ 05:04

In testing the mame opl2 device, a sample rate of 49176 Hz is producing a better sound and less artifacts than 48000 Hz. The setting is in sound_opl.c.
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

Re: PCEm. Another PC emulator.

Postby Battler » 2018-3-24 @ 17:45

I am looking the recent PIC commit that implemented level-sensitive interrupts:
https://bitbucket.org/pcem_emulator/pce ... 2d0c89696f
And I have a question - wouldn't the current implementation essentially prevent any IRQ's higher than the currently pending level-sensitive IRQ from being processed at all?

Edit: Also, this:
Code: Select all
                                if (!(pic2.level_sensitive & (1 << c)))
                                        pic.pend &= ~(1 << c);
                                 pic.ins |= (1 << 2); /*Cascade IRQ*/
                                 pic_update_mask(&pic.mask2, pic.ins);

Should IMHO be:
Code: Select all
                                if (!pic2.pend & ~pic2.mask)
                                        pic.pend &= ~(1 << 2);
                                 pic.ins |= (1 << 2); /*Cascade IRQ*/
                                 pic_update_mask(&pic.mask2, pic.ins);

It's IRQ 2's pending state that you're clearing there, while you were clearing the the PIC2's interrupt from PIC1. Also, it should be cleared if and only if no interrupt is pending on PIC2 anymore.
Battler
Newbie
 
Posts: 75
Joined: 2014-3-22 @ 21:27

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-3-28 @ 08:30

The ctmouse driver works with the serial mouse from DOS. However, if instead exiting from Windows 95 (OSR2) to DOS, then loading ctmouse results in an error.
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

Re: PCEm. Another PC emulator.

Postby Battler » 2018-3-28 @ 13:56

Yes, the driver indeed errors out when run after the mouse had been moved or even just identified (which is of course the case after Windows 95 has started and exited to DOS). It's because the serial ports' FIFO emulation is very over-simplified, which causes mouse drivers to not get the ID bytes right if they ID the mouse while the FIFO had been used before. Also notably lacking is FIFO width control and a no-FIFO mode which would be needed for mostly 486 and earlier because those tend to have the Intel 8255 or compatibles (which do not have a FIFO) instead of 16550(-compatibles).
Battler
Newbie
 
Posts: 75
Joined: 2014-3-22 @ 21:27

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-3-28 @ 14:35

Thanks for identifying the cause of the issue. I will look at the serial port code.
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

Re: PCEm. Another PC emulator.

Postby Jo22 » 2018-3-31 @ 22:41

Regarding that maximum conventional memory on page 45, again..
"I have found out that IBM PC 5150 continues BIOS memory test to 704 kilobytes with undocumented
SW2 DIP switch settings ON ON OFF ON OFF and DOS automatically uses all of that as conventional memory.
This is an alternative way to utilize 64 kilobytes of RAM at segment A0000.
"
Source.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//
User avatar
Jo22
l33t
 
Posts: 2638
Joined: 2009-12-13 @ 07:06
Location: Europe

Re: PCEm. Another PC emulator.

Postby Battler » 2018-4-03 @ 00:11

I just saw this commit: https://bitbucket.org/pcem_emulator/pce ... 6702919eee .
Are we sure this is the right solution? It looks to me like this is a hack to get around the problem I pointed out, thought I need to look at the RTL8029AS specification for this.

Edit: Here's the quote from the RTL8029AS datasheet:
All bits correspond to the bits in the ISR register. POWER UP=all 0s. Setting individual bits will enable the
corresponding interrupts.

Are we sure the current implemenetation of the IMR is even remotely correct? IIRC this was originally ported from DOSBox and I have no idea whether or not the implementation there is correct. From how I interpret this, a bit from IMR, when set, makes the card issue that type of interrupt. If it's clear, such an interrupt is not issued.

Edit #2: Seems I misunderstood the code. What the code does is, checks if any unmasked interrupts are currently pending and raises the interrupt if yes, otherwise it lowers the interrupt. This is OK. However, my point about the implementation of level-sensitive interrupts still stands - it *IS* going to prevent all other interrupts from being processed, causing Windows 9x to triple fault reset when someone attempts a large download over the network.
Battler
Newbie
 
Posts: 75
Joined: 2014-3-22 @ 21:27

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-4-05 @ 00:27

In this commit: "Implement read & write masks on S3 blitter...", there is this portion:
Code: Select all
                                         if (vram_mask)
                                         {
-                                                READ(s3->accel.src + s3->accel.cx, mix_dat)
+                                                READ_SRC(s3->accel.src + s3->accel.cx, mix_dat)
+
                                                 mix_dat = mix_dat ? mix_mask : 0;
but semicolon missing from the added line.
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

Re: PCEm. Another PC emulator.

Postby Battler » 2018-4-05 @ 07:01

READ and READ_SRC are both #define'd macros, and I think any applicable semicolons are already in the code blocks the macros are #define'd to.
Battler
Newbie
 
Posts: 75
Joined: 2014-3-22 @ 21:27

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-4-05 @ 08:29

Thanks. All the other similar changes had that semicolon...

I noticed that many oal versions have looping set for the play function.
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

Re: PCEm. Another PC emulator.

Postby SarahWalker » 2018-4-05 @ 16:09

You are aware that there is a PCem forum, right? You might get more responses to your questions there than by extending this comically long thread.
User avatar
SarahWalker
Newbie
 
Posts: 60
Joined: 2016-5-12 @ 17:07

Re: PCEm. Another PC emulator.

Postby Battler » 2018-4-06 @ 09:19

I know this wasn't meant for me but I'll respond anyway - I myself do not have much choice, given I am permanently banned from the PCem forum, that's why I posted here instead.
Battler
Newbie
 
Posts: 75
Joined: 2014-3-22 @ 21:27

Re: PCEm. Another PC emulator.

Postby vvbee » 2018-4-06 @ 16:13

I registered on the pcem board more than a year ago but there was no activation. I don't need to pursue the matter though since I can post in this thread if need be.
User avatar
vvbee
Member
 
Posts: 413
Joined: 2017-2-06 @ 17:56

Re: PCEm. Another PC emulator.

Postby SarahWalker » 2018-4-06 @ 18:44

Sorry - I manually approve new user registrations due to the number of spammers that try to register, and I must have missed yours. I couldn't find any sign of a 'vvbee' user - did you try under a different name?
User avatar
SarahWalker
Newbie
 
Posts: 60
Joined: 2016-5-12 @ 17:07

Re: PCEm. Another PC emulator.

Postby hail-to-the-ryzen » 2018-4-08 @ 03:22

In my case, the ctmouse driver is now loading the serial mouse device after exiting Windows 95. The cause was in model.c which initializes the serial port for the ctmouse at a set address and irq, but this port setting was later removed wherever serial1_remove() was called and in addition any serial port setting in the bios should not use that same serial port dedicated to the serial mouse.
hail-to-the-ryzen
Member
 
Posts: 204
Joined: 2017-3-09 @ 01:34

PreviousNext

Return to Release Announcements

Who is online

Users browsing this forum: No registered users and 4 guests