markot wrote:

About the OPL2/OPL3 chips. Are they still manufactured today?

Are the OPL-SA chips still being manufactured, even?

gdjacobs wrote:

Was Cygwin easier than MinGW?

Cygwin itself is much better to use than MinGW is/was, by far. Cygwin actually has at least the advantage of being a much more professional UNIX-style environment, has all of the Bourne shell commands available, and is almost like an operating system in itself in many ways (though some may disagree with this), with the disadvantage of course that like all environments, it takes up a great deal of disk space.

However, the problems that I ran into with compiling this first build when I was setting up the build environment for the first time were not problems with Cygwin itself but rather due to major flaws in the GNU Compiler Collection (or GCC for short). One being that the sources had to be patched for SDL to link, as I already explained earlier. Another case was where it simply decided not to compile anything at all for the sole reason that it couldn't tolerate spaces instead of tabs, even despite the fact that C (the language that this emulator is written in) is supposed to be a free form language. Major thanks by the way to John Elliott for helping me with both; I greatly appreciated it.

I am also planning the ability to provide a Microsoft Visual Studio build environment for easy building on Microsoft Windows, and possibly also the ability to build it using other Windows-friendly compilers such as Open Watcom, while at the same time keeping the ability to use the existing commands to build the sources on Linux and other related systems. That way, each user can build the source code in a way that is appropriate for each system. But remember though that I am doing all of this in my spare time, so some things will need to wait a bit before they are ready.

I can confirm that those GCC problems are not an issue in native Linux. I can't be sure about MinGW as I haven't used it in a long, long time , but I suspect this is Cygwin being crotchety.

So, you were dealing with item 3 on my list of wrenches in the software works.

Another thought would be to try cross compiling from Linux to Win32.

gdjacobs wrote:

I can confirm that those GCC problems are not an issue in native Linux. I can't be sure about MinGW as I haven't used it in a long, long time , but I suspect this is Cygwin being crotchety.

So, you were dealing with item 3 on my list of wrenches in the software works.

Another thought would be to try cross compiling from Linux to Win32.

You realize of course that the whole point of this was to be able to build Windows-based software on Windows, right? Because using Linux to build software for a completely different environment such as Windows is overkill, and takes too much out of the machine's CPU resources just to virtualize a totally different operating environment, not to mention far more inconvenient for the vast majority of those who simply want an easy way to develop Windows software (though some Linux users will no doubt attack me for this, labeling those who develop open source software using "proprietary" environments as "hypocrites", but I couldn't care less what those types think anyway so they would basically be talking to themselves).

Anyway, regardless of what the culprit is, I at least have the development environment working, but I'm still going to migrate it to Microsoft Visual Studio for Windows users while keeping the existing setup for other environments.

I understand what you're saying. I'm just stating the sad fact - Cygwin is not a first class citizen for most of the dev tools you're using to compile PCEM.

gdjacobs wrote:

I understand what you're saying. I'm just stating the sad fact - Cygwin is not a first class citizen for most of the dev tools you're using to compile PCEM.

PCE, actually. I'm developing my emulator from the PCE code now as I've explained previously, since I didn't agree with the way that things were handled with PCem.