The download service you chose requires registration to download. You should look into another service if you want more people to try it.

I am confused about this:

>> In this case, the current SPCM binaries are a hex-edited and resource-edited version of the PCem binaries,

You mean you are not compiling it from sources?

Will you be providing sources to SPCM? How different is SPCM from PCem?

Regards,
Vlad.

collector wrote:

The download service you chose requires registration to download. You should look into another service if you want more people to try it.

I just re-uploaded it. It seems that for some reason, the link that I provided didn't work before, but I just checked it, and it works perfectly fine now with no registration required. Still, thanks for telling me about it. There should be no problems from now on, but if there are, then I'll gladly move the files to another host.

Vlad wrote:

I am confused about this: […]
Show full quote

I am confused about this:

>> In this case, the current SPCM binaries are a hex-edited and resource-edited version of the PCem binaries,

You mean you are not compiling it from sources?

Will you be providing sources to SPCM? How different is SPCM from PCem?

Regards,
Vlad.

Well, I have already provided the source code for the version of PCem that I am currently basing this on, before moving it to the latest source code.

And indeed, I'm starting out with a version of the PCem binaries that I know are fully working, since I still need some time to get the compile environment working for the latest and newest source code. I have already made several improvements, however, such as improved dialog boxes that are easier to understand (creating and installing hard disks, for example, is now easier), a slightly modified menu bar so that it doesn't conflict with the keystrokes in any of the emulated machines, and a new name for the configuration file (SPCM.INI) so that it is easier to open and modify straight from the Windows user interface.

I have also started work on adding configurations, so that rather than just launching the emulator binaries directly as you do currently with PCem, you instead run a specific configuration for each machine which in turn loads the emulator from there. You might want to try one of the sample machines that I provided just to see for yourself how it works. I'll also be starting work on a proper user interface soon anyway.

EDIT: Sorry, forgot to add the download link to the PCem source code. It's in the main post now!

I feel I should point out that the GPL licence requires that you provide source code for all the changes you make to the original code, not just the original code itself.

The reason why I wasn't able to provide it earlier was that the few changes that I have made so far have been made to an already compiled binary in a resource editor, so it would be a lot harder to provide the source code for that. But I'll see what I can do. I'll try opening it up in ResEdit just to see if I can export the changes that I have made so far to the user interface and dialog boxes at least.

Once I get the new compile environment working, then I'll be able to provide source code easily. However, it currently has been quite difficult for me to get the PCem-X source code to compile, thanks to the developers of Mingw32 and MSYS2 whose main goal is to make sure that everyone has to be some sort of advanced user of Linux/GNU before they can even figure out how to even use it, let alone compile source code with it. At the moment, I'm just getting errors on some of the files, and the documentation is written in such a way that it makes no sense for me as a Windows user. PCem V9 compiles fine with no issues by the way; it's PCem-X that has problems.

I've also been thinking about moving everything to Code:Blocks once I can get the source code to compile without any errors, since I find that that would be far more suitable for developing Windows applications anyway, and I could then provide a copy of it with the source code for the emulator itself which would make it far more easier for the majority of people to test it out and experiment with the source code without needing to install special tools that are difficult to set up and configure.

SoftPCMuseum_ wrote:

The reason why I wasn't able to provide it earlier was that the few changes that I have made so far have been made to an already compiled binary in a resource editor, so it would be a lot harder to provide the source code for that. But I'll see what I can do.

Just use xdelta to make a patch relative to the original binary that you edited, and then provide the patch along with the CRC32 of said binary.

Jorpho wrote:

SoftPCMuseum_ wrote:

The reason why I wasn't able to provide it earlier was that the few changes that I have made so far have been made to an already compiled binary in a resource editor, so it would be a lot harder to provide the source code for that. But I'll see what I can do.

Just use xdelta to make a patch relative to the original binary that you edited, and then provide the patch along with the CRC32 of said binary.

But that's not the same as the source code, but rather another copy of the same binary. He specifically requested the source code.

Learning how linux build systems work will help you a lot in the future and honestly once set up mingw/msys is easy as pie. Btw., mingw/msys goal is NOT " to make sure that everyone has to be some sort of advanced user of Linux/GNU before they can even figure out how to even use it, let alone compile source code with it." It's aim is to make it possible to compile source code that only has linux build stuff. Before switching to OS X I was using this to build a couple of projects WITHOUT having ever used Linux...

Dominus wrote:

Learning how linux build systems work will help you a lot in the future and honestly once set up mingw/msys is easy as pie. Btw., mingw/msys goal is NOT " to make sure that everyone has to be some sort of advanced user of Linux/GNU before they can even figure out how to even use it, let alone compile source code with it." It's aim is to make it possible to compile source code that only has linux build stuff. Before switching to OS X I was using this to build a couple of projects WITHOUT having ever used Linux...

Would it be possible for you to set up the source code to work with Code::Blocks? I could send you the latest source code if you would like to help.

Also, the reason for why I am criticizing the user interface of Mingw32 and MSYS2 is that it is obviously designed for users porting Linux and GNU applications to Windows. Having such a user interface would make far more sense if I was maintaining versions for both platforms (GNU/Linux in addition to Windows), but since I am only developing for Windows (or OS X at most if someone decides to develop the emulator for the Mac), then it makes no sense to have to learn how to use anything from a completely different environment that you're not even going to develop for. If I was developing for Linux or GNU in addition to Windows then that would be a different case altogether. Which is why I suggested for you to set it up to compile from Code::Blocks above, since I find that that would be a far more suitable environment for developing Windows applications.

SoftPCMuseum_ wrote:

Jorpho wrote:

SoftPCMuseum_ wrote:

The reason why I wasn't able to provide it earlier was that the few changes that I have made so far have been made to an already compiled binary in a resource editor, so it would be a lot harder to provide the source code for that. But I'll see what I can do.

Just use xdelta to make a patch relative to the original binary that you edited, and then provide the patch along with the CRC32 of said binary.

But that's not the same as the source code, but rather another copy of the same binary. He specifically requested the source code.

But since you were modifying the binary directly, there is no "source code" per se – unless you compiled something to get whatever you inserted into the binary, I guess. It's not clear exactly what you did.

nice, another pcem "blackjack & hookers" fork that doesn't really give back to upstream using a fork of early unfinished features from the tree.with the intention to "one up" PCem with its "superiority"

72mb of source code makes this sound promising and shows no incompetence at all

EDIT: Investigating it, it's PCE and various different outdated PCem builds repacked with roms PCem doesn't ship with. It also has a bunch of .lnk shortcuts that don't even work properly (i.e. paths to SOMEONE'S DOCUMENTS FOLDER).

The PCem userbase is already small, no need to divide and mislead with a "i am master emulater!!!" bundle. BTW Sarah doesn't appreciate binaries built from her early dynarec code and has made it clear to not post them anywhere

Please do NOT upload binaries built with this anywhere, it's a bit too early for that.

but nah, people don't listen and prefer exploitation over courtesy and useful testing/feedback.

SoftPCMuseum_ wrote:

Dominus wrote:

Learning how linux build systems work will help you a lot in the future and honestly once set up mingw/msys is easy as pie. Btw., mingw/msys goal is NOT " to make sure that everyone has to be some sort of advanced user of Linux/GNU before they can even figure out how to even use it, let alone compile source code with it." It's aim is to make it possible to compile source code that only has linux build stuff. Before switching to OS X I was using this to build a couple of projects WITHOUT having ever used Linux...

Would it be possible for you to set up the source code to work with Code::Blocks? I could send you the latest source code if you would like to help.

Also, the reason for why I am criticizing the user interface of Mingw32 and MSYS2 is that it is obviously designed for users porting Linux and GNU applications to Windows. Having such a user interface would make far more sense if I was maintaining versions for both platforms (GNU/Linux in addition to Windows), but since I am only developing for Windows (or OS X at most if someone decides to develop the emulator for the Mac), then it makes no sense to have to learn how to use anything from a completely different environment that you're not even going to develop for. If I was developing for Linux or GNU in addition to Windows then that would be a different case altogether. Which is why I suggested for you to set it up to compile from Code::Blocks above, since I find that that would be a far more suitable environment for developing Windows applications.

I'm on OS X and am very fine with the linux build system. I prefer this much more than any IDE.
And that is also the point of mingw and msys, to provide the same environment for compiling stuff as on Linux. No fancy pants GUI to distract from everything. Criticizing it for that makes no sense at all.
Deliberately abandoning the cross-platform build system for something like Code::Blocks is what I don't understand and can't and won't support.
Abandoning the cross-platformness of a project to make a one platform fork is evil IMO, btw.

And you better shape up your skills with whatever you are going to use, be it Code::Blocks or Linux build system, or your project is already doomed. Binary hacking will only get you a little bit on your way...

If installing an unix like environment under windows appears too complex, I suggest installing linux so you have the correct environment natively. (Linux can run under virtual machine on your main PC, dual-boot on your main PC or just clean install on spare PC). You only need to install few extra packages which is usually very easy through graphical software package installers found on many modern linux distributions. For example, it should not take much more than an hour to install linux, install version control programs such as git and C/C++ compilers, clone the ScummVM git repository and build a working ScummVM binary.

(I also use Code::Blocks as a build environment in linux if a project has no native linux build system, but only because I am lazy and just want to have something working quickly. But it is not a real production-quality multiplatform solution as said before).

leileilol wrote:

nice, another pcem "blackjack & hookers" fork that doesn't really give back to upstream using a fork of early unfinished feature […]
Show full quote

nice, another pcem "blackjack & hookers" fork that doesn't really give back to upstream using a fork of early unfinished features from the tree.with the intention to "one up" PCem with its "superiority"

72mb of source code makes this sound promising and shows no incompetence at all

EDIT: Investigating it, it's PCE and various different outdated PCem builds repacked with roms PCem doesn't ship with. It also has a bunch of .lnk shortcuts that don't even work properly (i.e. paths to SOMEONE'S DOCUMENTS FOLDER).

The PCem userbase is already small, no need to divide and mislead with a "i am master emulater!!!" bundle. BTW Sarah doesn't appreciate binaries built from her early dynarec code and has made it clear to not post them anywhere

Please do NOT upload binaries built with this anywhere, it's a bit too early for that.

but nah, people don't listen and prefer exploitation over courtesy and useful testing/feedback.

The shortcuts are pretty simple to fix; just change them to the correct directory path on your machine where you have the emulator installed. Still, it will have to do until I start work on a proper GUI for this (I'm already experimenting a bit, but I will need some free time to work on it some more).

Also, the whole point of releasing pre-release builds of the emulator itself (or ANY emulator for that matter) is for users to report bugs. Of course there are going to be lot's of things that don't work correctly and that need to be fixed, and once the project begins developing on its own, then expect it to improve a great deal pretty quickly.

Jepael wrote:

If installing an unix like environment under windows appears too complex, I suggest installing linux so you have the correct environment natively. (Linux can run under virtual machine on your main PC, dual-boot on your main PC or just clean install on spare PC). You only need to install few extra packages which is usually very easy through graphical software package installers found on many modern linux distributions. For example, it should not take much more than an hour to install linux, install version control programs such as git and C/C++ compilers, clone the ScummVM git repository and build a working ScummVM binary.

(I also use Code::Blocks as a build environment in linux if a project has no native linux build system, but only because I am lazy and just want to have something working quickly. But it is not a real production-quality multiplatform solution as said before).

Using those types of environments makes far more sense for users developing for both, the Windows and Linux platforms. But since I don't develop for Linux or GNU and have no intention of doing so, it to me makes no sense whatsoever to have to learn another (completely different) environment that you're not even going to support, just to develop for Windows. If I was developing for Linux in addition to Windows then that would be different. Still, I am trying my best to use Mingw32 for what I need it to do, which is compiling source code, and I have been literally fighting it out with it daily trying to get it to compile PCem-X. I'm getting a lot closer to being able to produce binary builds of it daily, but it's a lot harder than it seems, and remember that I don't have all the free time there is either. So I will at least do what I can at the moment for the time being.

SoftPCMuseum_ wrote:

Also, the whole point of releasing pre-release builds of the emulator itself (or ANY emulator for that matter) is for users to report bugs. Of course there are going to be lot's of things that don't work correctly and that need to be fixed, and once the project begins developing on its own, then expect it to improve a great deal pretty quickly.

Well, is this the sort of binary that Sarah didn't want distributed? Because if so, that's ... not good. You can certainly report bugs without posting binaries.

Jorpho wrote:

SoftPCMuseum_ wrote:

Also, the whole point of releasing pre-release builds of the emulator itself (or ANY emulator for that matter) is for users to report bugs. Of course there are going to be lot's of things that don't work correctly and that need to be fixed, and once the project begins developing on its own, then expect it to improve a great deal pretty quickly.

Well, is this the sort of binary that Sarah didn't want distributed? Because if so, that's ... not good. You can certainly report bugs without posting binaries.

It was based on a binary build of PCem-X that was distributed by Battler on SoftHistory along with the source code, and which was made publically available at that.

Also, the emulator at the moment is obviously just a tweaked PCem, based on PCem-X which I've decided to use as a starting point. However, what I am hoping for is that once development begins full swing, I'll be able to start making much more significant changes to it that will be significantly different from what is currently present in PCem. I'm currently planning a major overhaul of several features such as disk controller support (as in, adding support for full emulation of the IBM PS/2 as well as various COMPAQ machines, creating a true MFM disk controller emulator to replace XTIDE, and possibly also adding support for other disk formats such as TeleDisk, ImageDisk, Transcopy, SuperCard Pro, and Kryoflux). Once the project is finished, it will actually be quite different from PCem, and will support things that PCem will likely never support, such as what I mentioned above.

That being said, once I can get the compiler to work correctly and start producing binary builds on a daily basis, then it will continue development separately from PCem. It may not be that much different from PCem currently, but I've already planned some very radical changes down the road.

I would have thought getting a compiler to work correctly would be substantially easier than any of those changes you are proposing.

Jorpho wrote:

I would have thought getting a compiler to work correctly would be substantially easier than any of those changes you are proposing.

Well, that's exactly what I wish was the case, but unfortunately it's not. And it certainly doesn't help that most of the documentation (for the Mingw/GCC compiler, etc...) is very poor at best, and badly written at worst. Still, I have had several people trying to help me get it to work.

With the changes that I plan on adding in, at the very least, there are datasheets provided for different hardware components such as system boards, BIOS ROMs, hard disk controllers, video adapters, and so on, not to mention the very fact that such code exists in other emulators such as PCE, which includes emulation of one of the Western Digital MFM hard disk controllers from around mid-1984 as well as support for ImageDisk and I think even Transcopy disk images, so it would be largely a matter of taking existing code and modifying it for use in my emulator, or at most interpreting datasheets released for each device. I've even been reading up on the development of PCem and other emulators just to have an example of how that is done in the source code.

leileilol wrote:

nice, another pcem "blackjack & hookers" fork that doesn't really give back to upstream using a fork of early unfinished features from the tree.with the intention to "one up" PCem with its "superiority"

I wonder why you have so much of a problem with any fork of PCem? You don't seem to have problems with TheGreatCodeholio's DOSBox-X which also doesn't really give anything back to stock DOSBox, which makes me wonder why you apply different standards to PCem forks than you do to DOSBox forks?

72mb of source code makes this sound promising and shows no incompetence at all

EDIT: Investigating it, it's PCE and various different outdated PCem builds repacked with roms PCem doesn't ship with. It also has a bunch of .lnk shortcuts that don't even work properly (i.e. paths to SOMEONE'S DOCUMENTS FOLDER).

Well, I agree this kind of stuff is a problem. The person distributing his own work should package stuff properly.

The PCem userbase is already small, no need to divide and mislead with a "i am master emulater!!!" bundle.

Yes, the PCem user base is already small, which is precisely why we should get along, and appreciate each other's work, rather than attempt to fragment the community by personally attacking anyone who does anything someone disagrees with. You're the one bringing discord to the community by assuming that anyone who forks the project is doing it in bad faith to "outcompete" PCem, while all we're doing is bringing to public attention work that might or may not end it to the PCem mainline but we still want people to test it.

BTW Sarah doesn't appreciate binaries built from her early dynarec code and has made it clear to not post them anywhere

Please do NOT upload binaries built with this anywhere, it's a bit too early for that.

but nah, people don't listen and prefer exploitation over courtesy and useful testing/feedback.

I certainly do provide testing / feedback, and there's just going to be more of it provided if people who may not have time to compile builds or may not know how to use MinGW/MSYS2 are given access to builds with the recompiler so they can run them and do tests.
Also, are you sure the restriction even still applies, considering the DYNAREC flag is gone, and there no longer even is a way to compile an executable without the recompiler, and there hasn't been since late August?

SoftPCMuseum_ wrote:

With the changes that I plan on adding in, at the very least, there are datasheets provided for different hardware components such as system boards, BIOS ROMs, hard disk controllers, video adapters, and so on, not to mention the very fact that such code exists in other emulators such as PCE, which includes emulation of one of the Western Digital MFM hard disk controllers from around mid-1984 as well as support for ImageDisk and I think even Transcopy disk images, so it would be largely a matter of taking existing code and modifying it for use in my emulator, or at most interpreting datasheets released for each device. I've even been reading up on the development of PCem and other emulators just to have an example of how that is done in the source code.

I REALLY suggest you contribute your work directly to PCem-X instead, especially since that way, once it's all considered stable enough, we can make proper patches out of it and submit them to SarahWalker for inclusion into stock PCem, which would bring our work to the biggest possible audience.

And yes, let me reiterate again, the intention of PCem-X is not and has never been to disrespect Sarah and her emulator, or to outcompete them. The plan is to eventually provide patches to Sarah so she can then decided what of it to add to stock PCem. Hence why the accusations of trying to fragment the PCem userbase are wrong. Also, PCem-X relies on stock PCem and I always merge in stock PCem patches unless they conflict with work I have done (eg. if I did something before Sarah did it, or if a piece of code differs drastically between two, as is the case with the FDC, and even then I tend to look at the patches and come up with an equivalent), and without Sarah's work, PCem-X wouldn't even exist.
And while it's true I haven't yet provided stuff back to Sarah, that's solely because the work of me and my friends on PCem-X-specific things is itself still far from stable and it would be useless to provide patches of unfinished work. Hence why patches will only be provided when the work is all considered stable enough.

Edit: And leileilol, I hope you realize that you're behaving as if you were SarahWalker's personal police officer, policing the entire PCem userbase to make sure noone does the slightest thing you perceive wrong, and I don't think SarahWalker needs her own personal police officer doing that, as she does a perfectly good job pointing out wrong behaviors herself.