Cyberdyne wrote on 2021-07-26, 07:05:

Usually if a excellent good open source software gets a new maintainer/developer, the thing just "dies", it is just my observation 🙁

Well sometimes the developer really dies 🙁

Exactly!!
I hope Sarah to have a nice rest and take all the time she need to recover and then when she is ready to come back
on PCEm otherwise will be very difficoult to PCEm project to survive.

Before this thread is closed by moderation (and thank you moderators!), I'd like to also share my appreciation. I've probably always been into retro computing ever since I had a computer. Probably because I hardly ever throw away or delete anything, except by accident, flood, or don't-have-the-space-when-moving. But I'm also terrible at keeping track of things.

I digress. Thank you Sarah and community. I've only been getting back into DOS/Win9x revisiting in the last year, and even more recently been using PCem (until then VirtualBox and to a lesser extent QEMU). I look forward to participating in the community when the new maintainer announces, and am amazed at the legacy that's been created to date. Cheers.

SarahWalker wrote on 2021-07-01, 09:44:

PCem has now been taken over by a new maintainer. I'll let them step up and announce more concrete details when they're ready.

wondering if the above is still happening.
cheers,

r.

maxwellb wrote on 2021-08-07, 14:14:

Before this thread is closed by moderation (and thank you moderators!), I'd like to also share my appreciation.

I would like to join with you in showing my appreciation and respect and thanking Sarah
for her dedication that she put into her projects over the years.
My best wishes and hopes for the future also.
Hopefully there comes a time when she can look back at these days
again without feeling sad and uncomfortable.

Thank you sarah for making PCem. I had the chance to use it recently and it is amazing.

Thank you for all of your hard work. I hope you are well.

Have a good day,

tk421

Unfortunately the new maintainer of PCem has had to withdraw. Anyone interested in volunteering to take the project on?

Hi Guys! cause Pcem (one of the best project ever done in my opinion) is unfortunately dead Do You know if the HDD are compatible with 86Box ?

I think should be compatible

Re: 3D Accelerated Games List (Proprietary APIs - No 3DFX/Direct3D)

Thanks to Stiletto, he pointed me to ATI Rage video card emulation https://github.com/dingusdev/dingusppc/blob/m … deo/atirage.cpp
not sure on how it implemented but it can be helpful.

RaVeN-05 wrote on 2021-11-07, 09:45:

Thanks to Stiletto, he pointed me to ATI Rage video card emulation https://github.com/dingusdev/dingusppc/blob/m … deo/atirage.cpp
not sure on how it implemented but it can be helpful.

Well, it's licensed GPLv3+ which means it cannot be integrated into PCem as is, because PCem is GPLv2, but it's a start.

VHD PSA

If you're on Windows, and you're using differencing VHDs and you live in a DST'ing time zone, uncheck "automatically adjust clock for Daylight Saving Time" in your Windows time zone settings. This will restore access to the diff VHDs you have made before the DST change. This issue has been filed.

FYI, Pcem crashes on Manjaro Linux when Voodoo emulation is enabled. Crash happens after boot when the desktop is loading.

Looks like NULL pointer access in wx-thread.c function thread_wait_event:

1Thread 26 "Main Thread" received signal SIGSEGV, Segmentation fault.
2[Switching to Thread 0x7fffaa7fb640 (LWP 41458)]
30x0000555555a75b9c in thread_wait_event ()
4(gdb) bt
5#0  0x0000555555a75b9c in thread_wait_event ()
6#1  0x00005555559e18ce in voodoo_wait_for_render_thread_idle (voodoo=0x555558ba9880) at .../src/vid_voodoo_render.h:330
7#2  0x00005555559e2030 in voodoo_readl (addr=4194304, p=0x555558ba9880) at vid_voodoo.c:181

zirkoni wrote on 2021-11-09, 15:31:

FYI, Pcem crashes on Manjaro Linux when Voodoo emulation is enabled. Crash happens after boot when the desktop is loading. […]
Show full quote

FYI, Pcem crashes on Manjaro Linux when Voodoo emulation is enabled. Crash happens after boot when the desktop is loading.

Looks like NULL pointer access in wx-thread.c function thread_wait_event:

Copy code to clipboard

1Thread 26 "Main Thread" received signal SIGSEGV, Segmentation fault.
2[Switching to Thread 0x7fffaa7fb640 (LWP 41458)]
30x0000555555a75b9c in thread_wait_event ()
4(gdb) bt
5#0  0x0000555555a75b9c in thread_wait_event ()
6#1  0x00005555559e18ce in voodoo_wait_for_render_thread_idle (voodoo=0x555558ba9880) at .../src/vid_voodoo_render.h:330
7#2  0x00005555559e2030 in voodoo_readl (addr=4194304, p=0x555558ba9880) at vid_voodoo.c:181

Did anyone manage to fix this?

EDIT: The problem apparently is not just limited to Voodoo. I tried other 3D cards and they also CTD or crash the emulator alone.

The latest version of 86box handles Voodoo emulation just fine..

Except it does not run on mac or linux, only crapindows. I did see some people wanting to compile for these platforms on project’s github, but I haven’t got a reply from them…

That's unfortunate.

Bruninho wrote on 2021-11-26, 12:46:

Except it does not run on mac or linux, only crapindows. I did see some people wanting to compile for these platforms on project’s github, but I haven’t got a reply from them…

I'm sure someone will compile it for Linux eventually. As for Mac, who gives a shit? Isn't the point of using a Mac being proud of doing with what Apple offers you because Apple knows best?

They're doing it for both as I can see from a PR on their github, so it's a matter of time to have it for all three platforms. Even if they don't, the linux port can easily be modded to run on Mac if the GUI is indeed based on WxWidgets. Same approach was used for PCem.

As for your unecessary and disrespectful commentary towards Apple/Mac, I won't give any attention. I am not that kind of fanboy and it was clearly an attempt to start another flame war. Bye.

BTW, the crash seems to happen only with the release build so a quick fix is to compile the debug build:
./configure --enable-debug

zirkoni wrote on 2021-12-04, 06:57:

BTW, the crash seems to happen only with the release build so a quick fix is to compile the debug build:
./configure --enable-debug

That sounds like a compiler problem. I haven't tried building PCem for Linux but what if you built it with -O2 instead of -O3? Or with Clang instead of GCC?