Support for Dosbox Direct3D Patch's shaders would be nice too but that's not really essential or high priority. eFX + SweetFX already provides similar functionality for such a thing and it works with PCem 😀

(mainly for the CRT shader which really helps on an LCD, though AdvancedCRT with SweetFX tries to force a certain pixel resolution and looks bad in most cases.)

CHEERS on the Fullscreen mode... loving the various options (square pixels, 4:3, etc.) Truly well done! And thank you also to SA1988 for working on porting over NE2000 support. That will be fantastic as well. For the future, some kind of integrated HLSL would be delightful 😀

I'd just like to point out one other very cool feature that exists in ykhwong's DOSBox SVN, that could easily be ported over to PCem, if anyone is so inclined. There is a video mode called "cga_mono" which accurately re-creates the effect of running games in CGA through a monochrome monitor, with white, green and amber options to choose from. This is a bit more involved than simply shading the normal CGA colors to scales of green, amber or grey. CGA cards apparently have special alternate palette configurations that are used in such a situation, and DOSBOX's "cga_mono" was painstakingly designed for perfect accuracy. In fact, the development process for that mode was carried out right here on VOGONS in this thread:

VIDEO - CGA w/ Monochrome Monitor Support

It would be incredible to have access to this wonderful add-on in PCem, and probably a very quick port job. I'd do it myself but things are just too hectic now with work... a worthy little mini-project for anyone so inclined 😀

also, on some early Windows 95 builds, such as 58s, 73g and 81, Adlib plays but hangs the system (the OS inside PCem of course), what can I do to fix this problem? (well, betas are betas, but this problem didn't happen on some later early builds of the same OS, such as 122 and 189 or on other emulators, such as qemu and mess, etc)
Edit: Nice that windows 98 setup works again on PCem! Great job!

(re: cga_mono)

ecksemmess wrote:

This is a bit more involved than simply shading the normal CGA colors to scales of green, amber or grey. CGA cards apparently have special alternate palette configurations that are used in such a situation, and DOSBOX's "cga_mono" was painstakingly designed for perfect accuracy.

That's not really the case though... the patch is kind of a compromise, or a "fanciful approximation" if you will. There was no standard to that stuff, so different cards had their own silly ways of mapping CGA colors to monochrome shades, plus the RGB color model kind of limits how well you can simulate something like that. Hell, I couldn't even come up with a single mapping that looked acceptable in all cases (that's the only reason for the two alternate palette settings).

But yep, it all boils down to hard-coded RGB values so porting it over should be simple enough. Though if I were to redo it today, I'd probably go for a shader or so.

Thanks for clearing that up, VileRancour. I had thought there was a bit more standardization, but in any case, your DOSBox version of the patch is fantastic and I've spent more time with it than I can count. It really does capture the overall feel of CGA Monochrome as I remember it. I'm glad you took the trouble to put it together, and I truly hope it shows up in the next full DOSBox release. And with PCem taking such great strides lately, it'd be spot on to have a port there too. As you said, it'd be very straightforward, so I'm sure one of us will be able to get to it sooner or later.

Incidentally, does PCem currently offer any way to switch the regular MDA or Hercules monochrome graphics between white, amber and green? I haven't had a chance to look, and can't run it on this computer. If not, that'd be a great little feature to have. It's just not the early '80s without "green plasma" 😉

I'm not adding any more features for a while by the way, just getting the emulator to a stable enough state for a release. I may look at some of this stuff in the new year.

TomWalker wrote:

I'm not adding any more features for a while by the way, just getting the emulator to a stable enough state for a release. I may look at some of this stuff in the new year.

Yeah, it's been a while since 0.7, and so much has been added as it is. 0.8 will be a huge step forward just with the current features. I look forward to seeing it, and also whatever 2014 has in store for this emu. I tend to come up with a lot of ideas and suggestions for projects like this, old hacker habits dying hard I suppose. Hopefully I haven't come off as too demanding in this thread! 😀

Hi all, please can you tell me if you are after sound PCEM in the newly compiled version from Swampfox me unfortunately not even when I put my setup in many games and get away with it but I hear nothing

can not be an error somewhere in the compilation. Please anyone who would compile the latest version of the sound but went to thank everyone and especially for the work SarahWalker ... Sorry for the English, I used a translator

CZ

Zdravím všechny prosím můžete mi říc jestli vám jde zvuk v pcemu v té nové zkompilované verzy od swampfox mě bohužel nejde i když když dám setup v mnoho hrách tak to projde ale nic neslyším

nemůže být chyba někde v compilaci. Prosím kohokoliv kdo by skompiloval poslední verzy ale aby šel zvuk děkuji všem a hlavně za práci SarahWalker... Promintě za angličtinu použil jsem translator

Sound works for me in the latest compiled version.

Noticed this with Doom 1.0 with 486DX (any) though....

Also the PCem process still remains after closing.

It looks like Quake 1. 😎

You can send me pls your version?

well, IBM OS/2 1.00, strangely, works on PCem out of the box, but the installer of Microsoft OS/2 1.00 (which is different) doesn't (it hangs after displaying the boot information) (not even in both in the 286, 386, 486 clones, or in the IBM AT), the 1.10x (both IBM and Microsoft) versions install fine, but get a black screen after installation completes (the log says a data seg is missing), IBM OS/2 1.20 traps with garbled characters from the kernel (but Microsoft OS/2 1.21, strangely, works fine without problems) (well, these problems have been out since the stock 0.7 release) 😀
Edit: maybe borrowing some code from MESS could resolve this problem? (since, with MESS, all these versions work fine)

swampfox wrote:

Here you go, friends. https://drive.google.com/file/d/0B4pIOIy0EbSj … dit?usp=sharing […]
Show full quote

Here you go, friends.
https://drive.google.com/file/d/0B4pIOIy0EbSj … dit?usp=sharing

Compiled Windows-i686 binary for those who can't compile 😀

One bug I've found so far. When configuring using a 386 or higher, the options available in the CPU Type drop-down box are kinda screwy.
There are invalid entries such as "430VX" and "486 class" that will cause a CTD if clicked. The only valid entries are Intel, AMD, Cyrix, and IDT. There are also duplicates, but you can click either one if they are valid like I mentioned.

Otherwise, everything seems to work.

A few warnings during compilation. I should've piped out a logfile. Will report shortly.

Sarah, you are doing an excellent job so far. A badass little utility if I do say so. Keep up the good work.

And to those wanting a Linux build, it appears that PCem currently uses win32api/DirectX libraries exclusively atm. Perhaps one could reroute commands/calls to SDL/OpenGL?

greet me this version works well but does not like the sound of the flood Verzy PCEM 0.7 mi sound goes, and I have the exact same setup as new only used dos

Buricz wrote:

greet me this version works well but does not like the sound of the flood Verzy PCEM 0.7 mi sound goes, and I have the exact same setup as new only used dos

I'm really sorry about that!

It has something to do with the OpenAL development libraries used to build it, more specifically ALUT, the AL Utility Toolkit. Despite using multiple compatible libraries including Creative's SDK and Freealut, audio output with each compile ranges from unstable (CTDs and static) to not-working.

SarahWalker, forgive me if you have already posted this, but could you tell us what your build environment is like? Using MinGW32/GCC 4.8.1 with the libraries required to build as the makefile claims.

Also I should mention I didn't touch any of the code, not even the compile flags.

MinGW32/GCC 4.7.2. The OpenAL/ALUT I'm using claims to be 'OpenAL-0.099-mingw', if that's any help.

SarahWalker wrote:

MinGW32/GCC 4.7.2. The OpenAL/ALUT I'm using claims to be 'OpenAL-0.099-mingw', if that's any help.

Found your OpenAL archive in the form of a "devpak", which I had to use a program called Packman to extract. You wouldn't happen to be using Bloodshed's Dev-C++ IDE, would you? I just use MSYS. I used Dev-C++ a long time ago, when I wanted to convert the Visual C 6 project files for the NES emulator "nesterJ" to MinGW makefiles.(which iirc worked well). Likely the only time though.

Either way, I used the libraries and headers in it to compile. This time, when I started PCem, it did not complain about the lack of a libalut or OpenAL32 dll, which I found odd. No sound this time either, and figured it was due to the lack of that dll in the directory. Placing the OpenAL32 dll from the OpenAL-0.099-mingw archive in the same directory, it crashes. Replacing that with OpenAL32.dll from Creatives SDK, it starts up again, yet no sound still.

And using the same hard disk image and machine settings; sound works in previous builds.

On a less related note, DOOM seems faster with the latest build (changeset 53) than the compiled 0.7 on your site on the same hardware (AMI 486 clone, i486DX4-100, 16MB RAM, Fast PCI, SB16, Bahamas64). However, going into Options ingame, cursor flips out.

Swampfox, your executable crashes immediately on Windows XP SP3. Fortunately I can compile the executable myself (Like this). May just as well attach it now.

-one line changed in sound.c: sound_handlers[c].get_buffer((int16_t *)outbuffer, SOUNDBUFLEN, sound_handlers[c].priv);
-several lines changed in cdrom-ioctl.c: DeviceIoControl(hIOCTL,IOCTL_CDROM_READ_TOC, NULL,0,&ltoc,sizeof(ltoc),(PDWORD)&size,NULL);
-icon added to pc.rc.

Edit: now actually updated to 16 december. Before I had the source files from 2 december.
Edit: deleted file, since PCem V0.8 release version made it obsolete.

gerwin wrote:

Swampfox, your executable crashes immediately on Windows XP SP3. Fortunately I can compile the executable myself (Like this). Ma […]
Show full quote

Swampfox, your executable crashes immediately on Windows XP SP3. Fortunately I can compile the executable myself (Like this). May just as well attach it now.

-one line changed in sound.c: sound_handlers[c].get_buffer((int16_t *)outbuffer, SOUNDBUFLEN, sound_handlers[c].priv);
-several lines changed in cdrom-ioctl.c: DeviceIoControl(hIOCTL,IOCTL_CDROM_READ_TOC, NULL,0,&ltoc,sizeof(ltoc),(PDWORD)&size,NULL);
-icon added to pc.rc.

Edit: now actually updated to 16 december. Before I had the source files from 2 december.

Oh, rad. Wish I had read your post earlier; would have saved me a lot of trouble!
Thanks!

/me just compiled the latest pcem from bitbucket and wonders what operating systems to try

PCem v8 is now available.