PCem

EDIT: I am going to retract this statement due to the recent announcement on GitHub,

Since I am doing some major changes to the core environment, dev builds are going to be very different from V17, so I will accept bug reports, and ill just check to see if they are still an issue on V18

V18 will be switching to Qt and I am aware of the issues with Dynarec on the dev builds. I think it might be an issue with GCC 11, GCC 10 doesn't seem to have major dynarec problems as Debian seems fine

How can we download dev builds?

Will there be a new stable version called PCem V18 later in 2022?

Arjen42 wrote: ↑Sat 18 Jun, 2022 7:10 pm How can we download dev builds?

In GitHub Actions, https://github.com/sarah-walker-pcem/pcem/actions

Jonathan McEvoy wrote: ↑Sat 18 Jun, 2022 11:06 pm Will there be a new stable version called PCem V18 later in 2022?

Working on a release this year, finishing the plugin API and some bug fixes so hopefully soon!

Okay, I found it. I downloaded #140: Commit 6f69f3e. I put the bin files in a separate folder and copied over the config, nvr, and rom files.

However this version appears to replace existing machine configuration settings with incorrect values. Including hard drive geometry and floppy drive types. This makes it impossible to boot an operating system.

Whenever I use CD-Rom Player for the PCem there is a lag but the only way to run games more fast on CD-Rom is ISO?

MichaelJManley wrote: ↑Sun 19 Jun, 2022 1:40 am Working on a release this year, finishing the plugin API and some bug fixes so hopefully soon!

Good to know!

Am surprised that wasn't your initial notice/announcement. Seems like a handful of people are curious about V18 and the next solidified step of development.

See top for new information

MichaelJManley wrote: ↑Sat 18 Jun, 2022 6:23 pm V18 will be switching to Qt

This may regress XP/Vista/7/8/8.1 support. Several emulators moving to QT (PCSX2, Dolphin) gave up 7 because they had no choice in the matter when that decision's from upstream and/or develop on Win10/linux unaware of the platform regression creep issues.

OTOH it's great that the emulation's being decoupled from the GUI so maybe a fltk implementation could also happen, or perhaps a libretro core (which may have usability issues given it's not emulating games directly and system config driven)

leilei wrote: ↑Tue 21 Jun, 2022 7:25 pm

MichaelJManley wrote: ↑Sat 18 Jun, 2022 6:23 pm V18 will be switching to Qt

This may regress XP/Vista/7/8/8.1 support. Several emulators moving to QT (PCSX2, Dolphin) gave up 7 because they had no choice in the matter when that decision's from upstream and/or develop on Win10/linux unaware of the platform regression creep issues.

OTOH it's great that the emulation's being decoupled from the GUI so maybe a fltk implementation could also happen, or perhaps a libretro core (which may have usability issues given it's not emulating games directly and system config driven)

Partially that's why I'm still hesitant to go Qt as well, I'm really trying to make it work under wxWidgets.

The biggest thing is might even decouple from SDL, and make a low-level header that deals with video drawing, keyboard, and mouse, as even Qt is a pain to work with SDL. Then I would just use Qt's OpenGL Drawing routines, and keep SDL for legacy wxWidgets. Will make it super easy to do alternate display engines.

I ain't dumping wxWidgets out, so if someone wants to build for older systems.

MichaelJManley wrote: ↑Sat 18 Jun, 2022 6:23 pm ...V18 will be switching to Qt ...

Qt 4.x was good but 5 or 6 is "very nice" for redistibute...
1.5MB of pcem + 200 MB Qt shit...

Are there any plans in the pipe for speeding up or optimizing the emulation any?

As of now even with CPU tweaks via a batch file (disabled SMT and forcing high-priority) I'm topping out at a Pentium II 233 on my 5600X and it would be nice if I could at least iron out the brief second of emulation lag that sometimes happens navigating the OS and accessing a folder

I have a doubt, what is the best requirement for Windows XP on PCem?

Jonathan McEvoy wrote: ↑Sun 19 Jun, 2022 9:09 pm Whenever I use CD-Rom Player for the PCem there is a lag but the only way to run games more fast on CD-Rom is ISO?

Best way is to put in NO CD cracks to replace the EXE for games with DRM or if you just don't want to fuss with ISO's all the time though a lot of my childhood educational software doesn't have NO CD Cracks sadly that I'm aware of. Either way make sure it will match the patch! No pun intended.

That would be for example like Sims 1 Complete Collection if you have the fastest VooDoo 5 5500 Graphics with 64 MB and then run more oldest games for the future

- The Sims doesn't care about 3D APIs.
- Like V2SLI, the Voodoo5's amount of video memory is a ruse. It's also not very more game compatible than the Voodoo3 we have now. (apart from supporting some more texture formats/sizes)

MichaelJManley wrote: ↑Sat 18 Jun, 2022 6:23 pm EDIT: I am going to retract this statement due to the recent announcement on GitHub,

Since I am doing some major changes to the core environment, dev builds are going to be very different from V17, so I will accept bug reports, and ill just check to see if they are still an issue on V18

V18 will be switching to Qt and I am aware of the issues with Dynarec on the dev builds. I think it might be an issue with GCC 11, GCC 10 doesn't seem to have major dynarec problems as Debian seems fine

I didn't see any announcement when clicking on that link. Just a bunch of files.

MichaelJManley wrote: ↑Sat 18 Jun, 2022 6:23 pm EDIT: I am going to retract this statement due to the recent announcement on GitHub,

Since I am doing some major changes to the core environment, dev builds are going to be very different from V17, so I will accept bug reports, and ill just check to see if they are still an issue on V18

V18 will be switching to Qt and I am aware of the issues with Dynarec on the dev builds. I think it might be an issue with GCC 11, GCC 10 doesn't seem to have major dynarec problems as Debian seems fine

What is QT can anyone explain in layman's terms? What will that do for PCEM that it can't do now?

Qt is a software development library for creating user interfaces. PCem currently uses wxWidgets. Qt is more common than wxWidgets and is known for being used in KDE. Because Qt is more popular, it is expected to have more features, less bugs, and to be easier to work with, especially for developers already familiar to Qt.

mangado wrote: ↑Wed 29 Jun, 2022 11:01 pm

MichaelJManley wrote: ↑Sat 18 Jun, 2022 6:23 pm ...V18 will be switching to Qt ...

Qt 4.x was good but 5 or 6 is "very nice" for redistibute...
1.5MB of pcem + 200 MB Qt shit...

Really only affects Windows, Linux users don't have that issue, which is kinda what I develop for, though I try to keep Windows still functional as it's a big market.

mangado wrote: ↑Wed 29 Jun, 2022 11:01 pm 1.5MB of pcem + 200 MB Qt shit...

If 200 MB is too big for your PC, then you'll probable won't need PCem.

mangado wrote: ↑Wed 29 Jun, 2022 11:01 pm

MichaelJManley wrote: ↑Sat 18 Jun, 2022 6:23 pm ...V18 will be switching to Qt ...

Qt 4.x was good but 5 or 6 is "very nice" for redistibute...
1.5MB of pcem + 200 MB Qt shit...

Citra, dolphin, duckstation and pcsx2 use Qt 5 or 6 and those files range from 18.3 to 19.5 MB.

One of the exceptions is yuzu where it's 131 MB, however, the bulk of that size comes from the Qt WebEngine files (which the other emus don't have). Without those files the size is 27.5 MB.

I'm not a programmer and don't exactly know what the Qt WebEngine is used for in regard to emulation. Is it even needed for PCem?

MichaelJManley wrote: ↑Fri 24 Jun, 2022 5:48 am

leilei wrote: ↑Tue 21 Jun, 2022 7:25 pm

MichaelJManley wrote: ↑Sat 18 Jun, 2022 6:23 pm V18 will be switching to Qt

This may regress XP/Vista/7/8/8.1 support. Several emulators moving to QT (PCSX2, Dolphin) gave up 7 because they had no choice in the matter when that decision's from upstream and/or develop on Win10/linux unaware of the platform regression creep issues.

OTOH it's great that the emulation's being decoupled from the GUI so maybe a fltk implementation could also happen, or perhaps a libretro core (which may have usability issues given it's not emulating games directly and system config driven)

Partially that's why I'm still hesitant to go Qt as well, I'm really trying to make it work under wxWidgets.

The biggest thing is might even decouple from SDL, and make a low-level header that deals with video drawing, keyboard, and mouse, as even Qt is a pain to work with SDL. Then I would just use Qt's OpenGL Drawing routines, and keep SDL for legacy wxWidgets. Will make it super easy to do alternate display engines.

I ain't dumping wxWidgets out, so if someone wants to build for older systems.

If Qt is faster than wxWidgets and provides much better PCem performance then this might be a good idea for PCem going forward. However, I would be concerned if XP/Vista/7/8/8.1 support were to be dropped from future versions of PCem. Testing new versions of PCem is very easy in a Win XP VM through VMWare.

PCem performance in a Win XP vm is very close to native performance because of the very low system requirements and PCem has always proven itself to be very easy to use on so many different operating systems. Other emulators have difficulty competing with PCem in many areas, namely performance and ease of use.

If the switch to Qt did improve PCem performance on a modern windows 10/11 PC, it would be interesting to see if the P2 450 would work much better than it does now.

tk421 wrote: ↑Mon 11 Jul, 2022 7:33 pm

MichaelJManley wrote: ↑Fri 24 Jun, 2022 5:48 am

leilei wrote: ↑Tue 21 Jun, 2022 7:25 pm

This may regress XP/Vista/7/8/8.1 support. Several emulators moving to QT (PCSX2, Dolphin) gave up 7 because they had no choice in the matter when that decision's from upstream and/or develop on Win10/linux unaware of the platform regression creep issues.

OTOH it's great that the emulation's being decoupled from the GUI so maybe a fltk implementation could also happen, or perhaps a libretro core (which may have usability issues given it's not emulating games directly and system config driven)

Partially that's why I'm still hesitant to go Qt as well, I'm really trying to make it work under wxWidgets.

The biggest thing is might even decouple from SDL, and make a low-level header that deals with video drawing, keyboard, and mouse, as even Qt is a pain to work with SDL. Then I would just use Qt's OpenGL Drawing routines, and keep SDL for legacy wxWidgets. Will make it super easy to do alternate display engines.

I ain't dumping wxWidgets out, so if someone wants to build for older systems.

If Qt is faster than wxWidgets and provides much better PCem performance then this might be a good idea for PCem going forward. However, I would be concerned if XP/Vista/7/8/8.1 support were to be dropped from future versions of PCem. Testing new versions of PCem is very easy in a Win XP VM through VMWare.

PCem performance in a Win XP vm is very close to native performance because of the very low system requirements and PCem has always proven itself to be very easy to use on so many different operating systems. Other emulators have difficulty competing with PCem in many areas, namely performance and ease of use.

If the switch to Qt did improve PCem performance on a modern windows 10/11 PC, it would be interesting to see if the P2 450 would work much better than it does now.

In the case of PCem, Qt would only be used to build a graphical interface.
Don't expect a PC performance boost after switching to Qt. xD
Switching to Qt also means that you need to use qmake for compilation.

I would wish that if V18 is released then we can run new voodoo graphics cards on a newer machine?

How's PCEM V18 going now that we are onto September? Maybe it will be released on the 21st night of September?

Sooga wrote: ↑Mon 05 Sep, 2022 1:53 am How's PCEM V18 going now that we are onto September? Maybe it will be released on the 21st night of September?

Working on it, Changing an entire GUI framework does take time, it's a major overhaul. And PCem isn't my day job so I don't get 24/7 to code on it.

MichaelJManley wrote: ↑Tue 06 Sep, 2022 9:32 pm

Sooga wrote: ↑Mon 05 Sep, 2022 1:53 am How's PCEM V18 going now that we are onto September? Maybe it will be released on the 21st night of September?

Working on it, Changing an entire GUI framework does take time, it's a major overhaul. And PCem isn't my day job so I don't get 24/7 to code on it.

Just glad to know that. Little tidbits like that go a long way even if it isn't much to show just mentioning what your working on time to time is often just enough to help us not be impatient. And by 'us' I mean those who read but don't register for fear of getting their head chewed off.

When you (as in dev teams on a long term project) go radio silence too long it makes fans anxious (which is still no excuse to be rude to the dev teams) but often both sides don't see past each other: Hell when a project goes too long just a quick tibit or even a screen shot or two when something is presentable is enough for most of us to be pleased. Honest we don't bite.

It may seem like no big deal to you but to us who are waiting it's enough to know and I feel a lot better that there are no major snags. Thanks for the GUI mention .

Sooga wrote: ↑Wed 07 Sep, 2022 2:48 am It may seem like no big deal to you but to us who are waiting it's enough to know and I feel a lot better that there are no major snags. Thanks for the GUI mention .

The github page has a little more going on and you get to see every change almost realtime. Though its not for everyone i know. I am really not into compiling stuff all the time so I just stick with v17 for now, but it works fine for the most part for my geekouts.

Is there a possible date when the new version of PCem V18 to be released?