PCem

I have finally had the chance to try v15 on a modern laptop. It is a Lenovo laptop using the Intel Core i7 9750H processor. The cpu in question can exceed 4 Ghz, with speeds of 4.15 Ghz not uncommon. From time to time the machine will reach 4.25 ghz. I have seen spurts of 4.33 Ghz, even moments with 4.43 Ghz.

PCem v15 runs ok in a VMware virtual machine running Win XP on this Lenovo laptop. MSI and Acer laptops seem to run PCem within VMWare better than this lenovo machine. First impressions for Intel emulated CPUs are generally favorable.

The AMD K6-2 350 works ok with only a little sputtering sound. Strangely if I change the emulated CPU beyond the K6-2 350, say to 450 or even 500 Mhz, then the emulated win95 PC will not start, but it will give windows protection errors. The K6-III line of emulated CPUs produce the same error on start. Has anyone seen this?

The Intel CPUs I tried in PCem never produce any of these errors, only the high end K6 CPUs seem to be affected. What should I do to fix this error?

Real behavior. Win95 will actually throw protection errors on CPUs that fast! There's a patch for it, but generally it's easier to install Win98 (or better) instead.

I'd forgotten to actually test that, so I'm glad to see the K6 timings are accurate enough to break Win95a.

Thank you.

I am glad PCem provides accurate emulation for these CPUs. I will do my best to fix this Windows Protection Error. If this is not possible, then loading Windows 98 will not be a problem.

Double-posted on me, Ignore.

Xanarki wrote: ↑Mon 17 Jun, 2019 11:33 pm

CryptidWorks wrote: ↑Mon 27 May, 2019 12:22 am

SarahWalker wrote: ↑Sun 26 May, 2019 7:04 am Not a lot for the most part; the main CPU load is the CPU emulation, and that's strictly single threaded. The only reason to go past 4 cores is if you want to emulate a Voodoo 2 SLI setup, as the Voodoo emulation can use up to 3 threads per card.

This disappointing but understandable since it's hard to multi-thread emulation of components that were originally single-threaded.

On another note is there a plan to eventually let the problem use more of the CPU? On mine hang-ups and speed drops can happen even though I'm not even hitting 60% usage on any of the cores. Seems to be caused mostly by the emulator reading data from my optical drive so I'm tempted to try ripping my games to ISOs when I play them in PCEM.

On 2 seperate machines, I have noticed the optical drive will almost surely cause a slowdown. Making ISOs and putting it on the virtual drive is highly recommended.

I dunno why, but using an external virtual drive like PowerISO versus PCEM's gives me better performance, too.

As weird as it sounds, that was 100% right.

I ripped an ISO and directly mounted as an image with PCEM. Now the game runs full-speed with no slow down on the same virtual hardware configuration. I guess reading from system's physical drive isn't totally ironed out yet and causes hitches.

After ironing things out by using ISOs instead of the discs I've got a Ryzen 3600X with precision boost enabled that hits around 4.3Ghz sustained single core boost and 4.1Ghz all core running Windows 98 games on a Pentium MMX 233Mhz fulls-speed without issue. I also have a Voodoo 2 installed in the virtual system but I haven't tried any 3D accelerated games yet.

Tested Paintbrawl 2.

It has this weird quirk where only the Glide option works at 640x480 (you have to use 800x600 for the 3D card option to take) but it does remain at 100% speed when running a 3D accelerated game on a Voodoo 2.

However badly this game wants to run on any settings just of it's own accord.

SarahWalker wrote: ↑Mon 20 May, 2019 7:35 am

omarsis81 wrote: ↑Sun 19 May, 2019 10:09 pm Thank you! v15 finally arrived!
One question Sarah: do you have more ideas for further optimisations?

Yes. It's mainly a matter of time and energy, and I don't have any of the latter left at the moment!

Hi Sarah! How are you feeling? It has been many months since the last Commit. I wonder what are you up to?

Having a nice break, getting a couple of long overdue non-PCem projects done. I'll probably get back to PCem in a couple of months or so.

Get some rest Sarah You well deserve it and need it

This may be off-topic, but then maybe not. Id like to congratulate you on the release of Arculator 2.0 which has been released a few days ago.

It emulates many Acorn Archimedes systems with very high compatibility. I guess many people in this forum are interested in old computers in general, so go check it out: http://b-em.bbcmicro.com/arculator/

The Archimedes range is particularly interesting, because they are something like the precursors of Raspberry Pie and the descendants of their ARM CPUs are in everybodys mobile phone, etc.

Finally gotten around to upgrading. (I've not been active for a while on account of dealing with heart failure and the fitting of a pacemaker).

I've noticed a "bug" that's probably been around for a while, and this prompted me to update to v15. However the bug is still there.

PCem does not cope with unicode path names where non-ASCII characters exist. It doesn't bomb out or anything - it just decides that the "floppy" is unreadable. If I move self-same floppy image to a path that is pure ASCII then it works ok.

I guess someone needs to update their core code library for the windows path handling to use modern unicode strings and API calls. They have after all been around since at least the turn of the century.

BigAlUK wrote: ↑Mon 06 Jan, 2020 5:07 am Finally gotten around to upgrading. (I've not been active for a while on account of dealing with heart failure and the fitting of a pacemaker).

I've noticed a "bug" that's probably been around for a while, and this prompted me to update to v15. However the bug is still there.

PCem does not cope with unicode path names where non-ASCII characters exist. It doesn't bomb out or anything - it just decides that the "floppy" is unreadable. If I move self-same floppy image to a path that is pure ASCII then it works ok.

I guess someone needs to update their core code library for the windows path handling to use modern unicode strings and API calls. They have after all been around since at least the turn of the century.

It's not really a bug per se, but yeah, PCem currently is not unicode aware on Windows when it comes to file path handling and opening.

And unfortunately, it's not a simple fix (otherwise it probably would have been done already!). The main problem is Windows handles things completely differently to other OS platforms. On *nix OS's, fopen() happily accepts UTF-8 file paths. And the locale is (usually) set to UTF-8. fopen() on Windows only accepts paths that are encoded in the current system code page, which is ASCII plus some locale specific characters. For unicode support, one must use a different function _wfopen(). However, _wfopen() only accepts paths encoded in UTF-16LE. So now you've got to a) decide how to internally store strings in your program, and b) perform conversions to/from it. Easy in most programming languages, a pain in the ass in C, as there is no standard string encoding conversions built into C, one must use the OS provided libraries, find a cross platform library, or roll your own implementation.

PCem might be able to leverage WX for some of the path encoding issues, but one still has to deal with the different fopen()'s.

Note that a lot of these problems are inherent to PCem being a cross platform program. If writing for *nix, everything's probably in UTF-8 for free. If writing a windows program, one specifies the UNICODE macro and not worry too much about it.

I've looked into making PCem unicode aware, but there's a fair bit that would need changing, and it is tedious as f***. C does NOT make it easy.

Any chance of getting the cassette to also use files in the formats that PCE (and MAME) use? That would be CAS-binary, mainly (tho' PCE also has PWM).

It would make it a lot easier for transporting code on tape between the emulators for comparative testing.

Pretty please?

I Believe even OBattler is standardising on CAS. (Tho' if he ain't, I will pester him 'till he does )

shermanp wrote: ↑Mon 06 Jan, 2020 6:45 am And unfortunately, it's not a simple fix (otherwise it probably would have been done already!).

Actually, it can be! All you need to do is allow unicode in the dialog (which I guess is what standard Windows Dialogs will give you anyway) and then apply the Windows API to turn that into a DOS-compatible short path. This should eliminate any unicode because short paths are afaik always ANSI - ineed probably ASCII - and this would let you use the ANSI path string exactly as you already do.

And if you record the original path wherever you already do for any power-cycle persistence as a unicode string, you can re-translate (or simply use it) if you need to provide said persistence back to that Windows dialog. That way the user never sees the short path, and the PCem internal code never sees any unicode when actually processing the files.

BigAlUK wrote: ↑Mon 06 Jan, 2020 1:47 pm

shermanp wrote: ↑Mon 06 Jan, 2020 6:45 am And unfortunately, it's not a simple fix (otherwise it probably would have been done already!).

Actually, it can be! All you need to do is allow unicode in the dialog (which I guess is what standard Windows Dialogs will give you anyway) and then apply the Windows API to turn that into a DOS-compatible short path. This should eliminate any unicode because short paths are afaik always ANSI - ineed probably ASCII - and this would let you use the ANSI path string exactly as you already do.

And if you record the original path wherever you already do for any power-cycle persistence as a unicode string, you can re-translate (or simply use it) if you need to provide said persistence back to that Windows dialog. That way the user never sees the short path, and the PCem internal code never sees any unicode when actually processing the files.

And then there's the config files, which is where the path is saved. What do you save that as? I guess one could use the short path too, but yuck.

shermanp wrote: ↑Mon 06 Jan, 2020 6:56 pm And then there's the config files, which is where the path is saved. What do you save that as? I guess one could use the short path too, but yuck.

The Windows Registry accepts user-level entries in unicode.

Go on! Have a play in the mud. You know you want to.

BigAlUK wrote: ↑Mon 06 Jan, 2020 1:40 pm Any chance of getting the cassette to also use files in the formats that PCE (and MAME) use? That would be CAS-binary, mainly (tho' PCE also has PWM).

It would make it a lot easier for transporting code on tape between the emulators for comparative testing.

Pretty please?

I Believe even OBattler is standardising on CAS. (Tho' if he ain't, I will pester him 'till he does )

I tried to write cassette support with some degree of abstraction, so it could support other formats than PZX. But given I never managed to get cassette writes reliably working, I certainly never considered implementing alternative read formats. You might just as well pester the MAME / PCE devs to support PZX, or work on improving the conversion tools between the formats.

https://www.youtube.com/watch?v=0GAwqI8tWTA

Tested an obscure Christian Game called The War in Heaven and it works pretty well on a Voodoo 2 (newest DX7 driver with DX7 installed) and a Pentium 233.