PCem

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-compati...

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 wit...

Personally, I'd be inclined to move the repo to GitHub, but hey, I'm biased as that is what I use for my own projects. Also never could really figure mercurial out.

But at the end of the day, it's your project, so I'll work with whatever you decide to do.

Oh my. Some very unhappy developers... https://community.atlassian.com/t5/Bitbucket-articles/What-to-do-with-your-Mercurial-repos-when-Bitbucket-sunsets/ba-p/1155380 I don't know why. It's not like BitBucket are going to delete issues, pull requests and wikis. And they're providing an automated tool...

You'll probably want OpenAL-Soft. It is a CMAKE project.

OpenAL-Soft seems to provide a toolchain file for cross-compiling with MinGW-w64 at https://github.com/kcat/openal-soft/blo ... ompile.txt.

Does this help?

altheos wrote: ↑

Fri 24 May, 2019 10:14 am

Hi,

I can't apply your patch against a stock v14 : do you have a compatible version of your patch ?

Regards.

Sorry, not at the moment. I need to rebase the patch on V15, and I'm not really in a PCem frame of mind at the moment, so it could be a wee while yet.

BTW, compiled for me fine on MinGW-w64 with GCC 7.2

It looks like Sarah added some makefile fixes not too long ago at commit 51e4eb5, is that the problem?

The makefile does have an absolute path to a mingw install for Wx. other than that, it compiles fine (for gcc 4.7.2 win32 anyway) It always has. Thankfully you can override make variables on the command line, so I've got a batch file that points to the location of my WX install. I started to try an...

This patch would be awesome for v15, but it's not ready yet, right? I'm working on it! Hope to have it ready by the feature freeze, but no guarantees. Nope, wasn't able to get it working in time I'm afraid. Currently scratching my head over why Windows (or Hyper-V) doesn't like my differencing VHD....

This patch would be awesome for v15, but it's not ready yet, right? I'm working on it! Hope to have it ready by the feature freeze, but no guarantees. Nope, wasn't able to get it working in time I'm afraid. Currently scratching my head over why Windows (or Hyper-V) doesn't like my differencing VHD....

seth wrote: ↑

Thu 18 Apr, 2019 7:26 pm

This patch would be awesome for v15, but it's not ready yet, right?

I'm working on it! Hope to have it ready by the feature freeze, but no guarantees.

It does support multi-parent chains. But I was thinking more about your comment about the handling of file paths and text encodings. As far as I can tell, the Dosbox-X implementation uses no external libraries for that, and it does it with a pretty small amount of code. Also, for the purposes of PC...

Might it be helpful to look at how VHDs are implemented in Dosbox-X? https://github.com/joncampbell123/dosbox-x/blob/master/src/ints/bios_vhd.cpp Interesting, I hadn't seen that before. After a (very) brief look at the code, I think my implementation will be more complete. For example, the DosBox-X...

This is a very useful addition! I just managed to apply the patch and compile the emulator. I did some quick tests with a VHD hardfile and it seems to work fine, from now on I will probably only use VHD files. If it's possible to include it in the next official release that would be great, it has m...

I'm not an expert by any means, but I believe that PCem doesn't accurately emulate the full 80-bit precision of the floating point co-processor. Word is probably sensitive enough to detect the inaccuracy, or it's doing something to make the PCem FPU emulation trip up. As, I said, I'm no expert, just...

Hi, As stated, I have have been creating VHD support for PCem. I think I have dynamic images pretty well sorted, and I'm currently trying to get differencing support working (reading works, but I haven't got creation support yet, nor any of the parent/child integrity checks). The original VHD format...

MSYS2 is a Windows build environment Please forgive my silly question, I saw all those $ shell commands that looked like linux That's because MSYS2 is basically a stripped down linux distribution (Arch I believe) compiled to run on windows. It contains a linux shell, package manager, and all the *n...

EDIT: I deleted the contents of this post, because I realized I had made a colossal arse of myself. Turns out, the bitmap macros I was using were incorrect for VHD's (the order was reversed). This mistake will also explain why I've been having so much trouble with differencing VHD's, as they rely ex...

I mean, well, once it has installed win95 and rebooted (after the whole setup routine), for now, it's fine, but once adding one file (as little as 32kb for example) in the vhd (after closing PCem), it would result in some files (not all) missing like vwin32.vxd, etc, thus, corrupting and making win...

Your latest patch solves my issue, thanks! Edit: At least, just partially, attempting to add files from winimage or mounted through imdisk results in missing other files or corruption again. Siigh... maybe something a little less subtle is required. Are you able to provide a detailed step-by-step o...

So I went ahead and implemented some sector bitmap handling. It basically does nothing on reads, but updates the sector bitmap if required on writes. At least that's what I INTEND it to do... Whether I've done it correctly or not... I've attached a test patch, which can be applied on top of my V4 pa...

I think I can see what a potential issue MIGHT be. Unlike Windows (10) and MiniVHD, Winimage actually appears to use the sector bitmap for sparse images. This COULD lead to a potential issue where Injecting a file into the image via Winimage creates a new block with some sectors marked clean. MiniVH...

I'm going to have a closer look at this. There may be some funny business going on with Winimage. I say may, because the first thing I tried with Winimage had a problem, but subsequent uses have behaved themselves. Will try with a blank fresh VHD image to see what winimage is doing, hopefully I can ...

Just trying to narrow down whether it's a bug with my VHD code, or a bug with Winimage.

SA1988 wrote: ↑

Sat 29 Dec, 2018 12:01 pm

Nice patch! However, I found a bug in this patch. The bug is about when win95's first phase setup is finished, opening a dynamic/sparse vhd to view files with winimage results in a corrupt/blank vhd (with winimage).

Does this bug happen with Windows created dynamic VHD's as well?

I've updated the original guide to hopefully make it clearer that one needs to switch shells from the "Prepare and Compile PCem" step onward.

That's weird. I can't think of anything that would have fundamentally changed since I made this guide. In fact, I recently updated my own MSYS2 installation a few weeks ago. Are you using the MSYS2 MingGW shell. You should be using that, and not the MSYS2 MSYS shell. It's really strange that it's no...

Araripe wrote: ↑

Tue 25 Dec, 2018 5:16 pm

How do I apply the patch? I wanna test the VHD feature but I don't have a single clue on where to begin. Do I need a compiler or something?

PM sent.

Patch updated again. See this post for details => http://pcem-emulator.co.uk/phpBB3/viewtopic.php?f=4&t=3056&p=11503#p11618 As mentioned in that post, if anybody wants to assist me to try and get differencing support working, please feel free! I've basically slammed into a brick wall on that one oth...

Unless anybody discovers any issues or bugs, I think I'm done with this. So, umm, about that.... I decided to simplify the sector read/write functions. The old "fast" path has been dropped in favor of improving the old "slow" path to be, well, not slow. Basically minimized the use of fseek() where ...