I think it depends largely on two factors. One is at what level you want to emulate. Do you require cycle-exact emulation so you get *exactly* what you would on real hardware (and can you live with the low performance of this type of emulation), or can you live with approximations that give you a "close enough" result by cutting a few corners? If you approximate it saves a lot of time, both writing the emulator and running it.

It also depends greatly on how much information is available. How can you emulate the OPL2 chip found on many sound cards, if you only have a datasheet which explains how to interface with the chip, but does not cover how the chip works internally?

I would even go so far as to say that writing the emulator is the easy bit, but figuring out how the hardware works in enough detail to emulate it is the hard part. Just look at DOSBox - the emulator has been around for a long time but people are still finding games that don't quite behave as expected because of some new undocumented feature having just been discovered.

Also, if you haven't seen it, Adrian Cable wrote an 8086 emulator in only 4043 bytes of C code. (Note that 4043 * 2 = 8086). It's obviously very basic, but it's emulation of a whole CPU in less than a page of text. I won't say it's easy to do something like that, but it's much easier with good documentation on how the hardware works - way beyond what you get in most datasheets.

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

Moi Marko,

I think OPL chips are not manufactured any more.

Malvineous said the most important things, but there might not be a way to emulate anything "perfectly" related to sound cards.

Even if you had a perfect emulator for a given sound chip (like OPL3), it is possible that the whole emulator (like DosBox) generates sound 1ms at a time, so basically it is not cycle exact and some tricks like PCM playing can sound wrong.

Also different sound chips run at different sampling rates. OPL3 runs at fixed non-integer rate of approximately 49716 Hz, while Sound Blasters playing PCM can be set to play PCM at almost any rate between 4000 and 45000 Hz, while modern PCs most of the time run at fixed sampling rates (48kHz, maybe 96kHz or 192kHz). So whenever a game is playing FM music and SB sound effects, you need to resample everything to native sound card rate, and if this mixing/resampling is done in software, you have to do it real-time and with good enough sound quality.

And what this does not emulate is the analog circuitry on sound cards, like DAC and low-pass filters (DAC anti-alias filters), and such things. For example, a real Adlib has a 10-bit DAC with 16-bit range, and after that an op-amp circuit with 4th order Butterworth type low pass filter at around 15kHz. Of course these can be emulated, but it comes with extra CPU cost.

Terve sinnekin!

On wikipedia page https://en.wikipedia.org/wiki/Yamaha_YMF262 I found link to https://github.com/gtaylormb/opl3_fpga which was very interesting. Didn't know people have been investigating the internal structure of the chip like this.

There have been threads on Vogons about the reverse engineering efforts on the OPL3. IIRC the emulation is quite good already. Keep in mind that the latest version 0.74 is quite old now, current SVN is more advanced.
If you need a more precise emulator have a look at PCem. DOSBOX cuts corners where possible, the goal is to make games work. It is easily possible to write programs that work under DOSBOX but not on any physical machine.
The good thing that most DOS games did have to work on a whole range of machines so cycle-exact emulation is not necessary for the most part, unlike with consoles (see discussions on higan for SNES).

Ever since I quit development of the PCem code, I have spent many months (and many hours nearly each day) building a new emulator built from the PCE code. While admittedly it is very basic as far as the upcoming build of the "normal" version is concerned, there is also a special version in the making for which I have devoted a great deal of time over the past few months which adds support for Intel 80386 CPUs, including the early steppings and all of the problems that they had.

Emulating a machine, as many in this topic have pointed out, is no easy task. In my case, it is not to simply get the software up and running, but rather to recreate each aspect of the machine itself (even the physical ones) as it originally existed when it was first new, and this by the way was the reason for why I chose PCE as the base for my project, since I knew for sure that I was starting out with an already similar emulator and continuing its development from there.

When building the 80386 emulator over the past few months, great care had to be taken in order to write down each changed CPU register down to the each detail. And I'm still dealing with it to this day (adding in 8192 segment descriptor tables all while maintaining a reasonable file size is no easy task).

Emulating different revisions of each chip is also often quite a challenge, especially when those problems also were very often the result of failures in the electrical design. Particularly, one such case was with a problem that the very early (nearly prototype) A1 stepping had, that would cause it to simply not terminate a memory cycle if the one pin (F13) happened to be disconnected from the 5V power supply. With the help of a friend of mine, however, and some C programming references that he gave me recently, I managed to implement even that, by using the "while" loop to simulate the same type of behavior in the PCE code if the emulator detects that pin F13 happens to be disconnected if it finds an A1 stepping running.

Developers of other emulators, on the other hand, have in many cases done at best very poor emulation of different CPUs. Even when the CPU is known to "work", the testing being done is often very questionable at best - I once saw one case of a problem in the MESS emulator, of one game causing a blue screen error in Microsoft Windows 95, which was automatically assumed to be a problem with the CD-ROM, even when they completely ignored the fact that "Exception 0E" specifically refers to "Page Fault", which is generated by the CPU when the system writes to a page that is either unavailable or in use, yet they apparently wanted to believe that the culprit was with the CD-ROM simply because they didn't want to accept that there was anything wrong with the emulated CPU.

Another point of mine is that an emulator of ANY type should also be easily readable as far as the code is concerned, so that it can be developed by other people, and easily extended in the future. The original PCE CPU code for the 8086 and 80186 was already like that, so it was very easily extendable to quite a number of 80386-style operations, not to also mention already being cycle-accurate, so it was very easy to change the 8086 clock cycles to their 80386 counterparts.

Reading the code of other emulators, however, is such an unthinkably unbearable mess that I cannot even begin to properly describe it all here. From reading the PCem CPU code, the commands were so cryptic that sometimes I actually had to guess what each statement referred to. It also doesn't help when developers don't leave decent comments in their source code so that people can actually understand it. Lesson to be learned: If you want your CPU code to be developed further by other people, then make sure that it's as easy to read and understand as possible.

--------------------------------

EDIT: From looking back at this thread, it seems that the discussion turned more towards emulation of sound chips (such as the OPL2 and OPL3 used in the Ad Lib and Sound Blaster). But my point still stands.

SoftPCMuseum_ wrote:

Developers of other emulators, on the other hand, have in many cases done at best very poor emulation of different CPUs. Even when the CPU is known to "work", the testing being done is often very questionable at best - I once saw one case of a problem in the MESS emulator, of one game causing a blue screen error in Microsoft Windows 95, which was automatically assumed to be a problem with the CD-ROM, even when they completely ignored the fact that "Exception 0E" specifically refers to "Page Fault", which is generated by the CPU when the system writes to a page that is either unavailable or in use, yet they apparently wanted to believe that the culprit was with the CD-ROM simply because they didn't want to accept that there was anything wrong with the emulated CPU.

While I don't want to comment on MESS's CPU emulation, I should add that their conclusion is entirely plausible - the Windows 95 CD-ROM driver isn't very resilient, and will quite often bluescreen if the CD-ROM emulation gets anything even slightly wrong.

Reading the code of other emulators, however, is such an unthinkably unbearable mess that I cannot even begin to properly describe it all here. From reading the PCem CPU code, the commands were so cryptic that sometimes I actually had to guess what each statement referred to.

Well you could have asked...

SarahWalker wrote:

While I don't want to comment on MESS's CPU emulation

Why not, Sarah? 😀

FWIW if it's licensing, the i86/386 CPU cores are effectively dual-licensed MAME license and BSD "3 Clause" license right now, just waiting for all our ducks in a row to remove the MAME license. 😀

Stiletto wrote:

Why not, Sarah? 😀

Because I've never used it? Nothing more sinister than that. I was merely commenting on SoftPCMuseum_'s insistence that this _must_ be a CPU bug, and pointing out that it's entirely possible it isn't.

SarahWalker wrote:

Stiletto wrote:

Why not, Sarah? 😀

Because I've never used it? Nothing more sinister than that. I was merely commenting on SoftPCMuseum_'s insistence that this _must_ be a CPU bug, and pointing out that it's entirely possible it isn't.

Alright, no problem! 😀

SarahWalker wrote:

While I don't want to comment on MESS's CPU emulation, I should add that their conclusion is entirely plausible - the Windows 95 CD-ROM driver isn't very resilient, and will quite often bluescreen if the CD-ROM emulation gets anything even slightly wrong.

Knowing the amount of other bugs and endless problems that the so-called "CPU code" in MESS had, I would think that I'm pretty certain on that one. No kidding; in one case, they even took years to implement the ARPL (Adjust Requester Privilege Level) instruction, which broke nearly every protected mode operating environment up to that point. Yet I had no problems at all adding it into my own CPU code. Believe me, if they can ignore or break entire opcodes, then that alone is pretty clear evidence to me. I would like to think that you're correct, but all of the evidence from past experiences clearly tells us otherwise.

My favorite one though was one case where an instruction was so badly managed that it would cause a fault, only instead of returning to where it left off, it would then cause another fault, and so on, until the emulator completely killed itself. Pretty clever, huh?

And believe me, this is not by far the only complaint that I have regarding MESS either - one wonders why almost all of its 80286 and higher machines are completely broken; is it because they think that they weren't widely used as "home" machines?

SarahWalker wrote:

Well you could have asked...

But the whole point of being able to read the source code is so that you can easily work with it yourself, without having to request assistance from someone else with every function. Also, another thing that I am doing with the PCE code that I am reusing for my own emulator, is that I am also strictly interpreting it in accordance with the 80386 Programmer's Reference Manual from 1987, and even including comments where necessary, in order to explain how each feature works.

I also try to keep the source code as simple and lightweight as possible by not overcomplicating things. So if someone wants to look at the CPU instructions, then they will see exactly that - the CPU instructions. This was how the original PCE code did it and this is how I intend to do it. I'm also doing the same thing for other areas of the emulator in addition to this, such as matching each line of source code with the IBM PC Technical Reference, not only so that each function will be explained in detail, but also so that people developing the code won't have to keep two different Technical Reference manuals on hand when adding in support for newer IBM machines such as the IBM PC/AT and IBM PS/2 series.

i'm pretty sure repacking other's emulators with batch files and roms does not constitute as writing an emulator

leileilol wrote:

i'm pretty sure repacking other's emulators with batch files and roms does not constitute as writing an emulator

Uh, apparently, you can't read.

1. I have been spending many months developing an Intel Inboard/386 PC emulator for what, like nearly six months already? Yet you completely ignored ALL of what I wrote and basically assumed that I just "repacked other emulators with batch files and ROMs".

2. The only reason why I released the emulator like it is now is that the upcoming features are not yet ready to test. Yet I think that I have made it perfectly clear in my previous posts that I already was developing other features for builds of it in the future, such as the Intel Inboard/386 PC emulation (before the IBM AT and IBM PS/2 series emulation is ready), and even in the next build, I am already working on matching each and every line of source code with the IBM PC Technical Reference. You don't believe me? Fine, I'll just quote from myself:

static void pc_setup_dma (ibmpc_t *pc, ini_sct_t *ini) { unsigned long addr; ini_sct_t *sct; mem_blk_t *blk; […]
Show full quote

static
void pc_setup_dma (ibmpc_t *pc, ini_sct_t *ini)
{
unsigned long addr;
ini_sct_t *sct;
mem_blk_t *blk;

/* IBM PC (Model 5150): Quote from "Technical Reference"; DMA: */
/* The microprocessor is supported by a set of high-function support */
/* devices providing four channels of 20-bit direct-memory access */
/* (DMA), three 16-bit timer/counter channels, and eight */
/* prioritized interrupt levels. */
/* */
/* Three of the four DMA channels are available on the I/O bus and */
/* support high-speed data transfers between I/O devices and */
/* memory without microprocessor intervention. The fourth DMA */
/* channel is programmed to refresh the system dynamic memory. */
/* This is done by programming a channel of the timer/counter */
/* device to periodically request a dummy DMA transfer. This */
/* action creates a memory-read cycle, which is available to refresh */
/* dynamic storage both on the system board and in the system */
/* expansion slots. All DMA data transfers, except the refresh */
/* channel, take five microprocessor clocks of 210-ns, or 1.05-us if */
/* the microprocessor ready line is not deactivated. Refresh DMA */
/* cycles take four clocks or 840-ns. */
/* */
/* Of the eight prioritized levels of interrupt, six are bussed to the */
/* system expansion slots for use by feature cards. Two levels are */
/* used on the system board. Level 0, the highest priority, is */
/* attached to Channel 0 of the timer/counter device and provides a */
/* periodic interrupt for the time-of-day clock. Level 1 is attached */
/* to the keyboard adapter circuits and receives an interrupt for each */
/* scan code sent by the keyboard. The non-maskable interrupt */
/* (NMI) of the 8088 is used to report memory parity errors. */
sct = ini_next_sct (ini, NULL, "dmac");

ini_get_uint32 (sct, "address", &addr, 0);

pce_log_tag (MSG_INF, "DMAC:", "addr=0x%08x size=0x%04x\n", addr, 16);

/* IBM PC (Model 5150): Quote from "Technical Reference"; I/O Channel Diagram: */
/* Signal Name: */
/* - +DRQ2 (Input): DMA Request 1 to 3: These lines are asynchronous channel requests */
/* used by peripheral devices to gain DMA service. They are prioritized with DRQ3 being */
/* the lowest and DRQ1 being the highest. A DRQ line must be held high until the */
/* corresponding DACK line goes active. */
pc->dma_page[0] = 0;
pc->dma_page[1] = 0;
pc->dma_page[2] = 0;
pc->dma_page[3] = 0;

/* IBM PC (Model 5150): Quote from "Technical Reference"; I/O Channel Diagram: */
/* Signal Name: */
/* - -DACK3 (Output): DMA Acknowledge 0 to 3: These lines are used to acknowledge DMA */
/* requests (DRQ1-DRG3) and refresh system dynamic memory (-DACK0). They are active low. */
/* - -DACK1 (Output): See -DACK3 */
/* - -DACK0 (Output): See -DACK3 */
pc->dack0 = 0;

e8237_init (&pc->dma);

blk = mem_blk_new (addr, 16, 0);
if (blk == NULL) {
pce_log (MSG_ERR, "ERROR: Unable to allocate memory for Direct Memory Access (DMA) controller.\n");
return;
}

mem_blk_set_fct (blk, &pc->dma,
e8237_get_uint8, e8237_get_uint16, e8237_get_uint32,
e8237_set_uint8, e8237_set_uint16, e8237_set_uint32
);

mem_add_blk (pc->prt, blk, 1);

/* This is a hack. HLDA should be connected to the CPU core. Instead,
* this will keep it permanently at high. */
e8237_set_hlda (&pc->dma, 1);

/* IBM PC (Model 5150): Quote from "Technical Reference"; I/O Channel Diagram: */
/* Signal Name: */
/* - -DACK3 (Output): DMA Acknowledge 0 to 3: These lines are used to acknowledge DMA */
/* requests (DRQ1-DRG3) and refresh system dynamic memory (-DACK0). They are active low. */
/* - +DRQ3 (Input): See +DRQ2 */
/* - -DACK1 (Output): See -DACK3 */
/* - -DACK0 (Output): See -DACK3 */
e8237_set_dack_fct (&pc->dma, 0, pc, pc_set_dack0);
}

So, in assuming that I had basically done no work at all? Well, you were wrong.

3. One of the reasons why I quit with the PCem code was because of your attitude. Basically, that anyone who develops anything differently from you is somehow stupid, and how the project will never evolve simply because it started as a continuation of another project (which in itself is a straw man). I spent many months working on the emulated 80386 CPU alone for one of my upcoming emulator builds, and all you can do is make fun of it?

4. You want to know how much time it took me to compile just this one emulator build? An entire night. Yes, you read that right, it took me one whole night to compile, simply because of all the people in the world who I could have possibly turned to for helping me through the compilation process, only one person was of any help: Me. That, and John Elliott, who helped me finish the compilation job in the end. You want to know why I didn't seriously just ask for help on any website at all? Because practically no one would have helped me out in the end - they would have either made fun of me for being able to make major changes such as an Intel 80386 emulator and yet not be able to compile a single build, or they would have attacked me for my choice in operating system, or they would have made fun of my project in other ways (as you have already demonstrated here), or both. Of all the people available, John Elliott was one of VERY few people who I could have POSSIBLY turned to in that case. And I was right.

Note to the site moderators: I apologize if I sounded rather angry and harsh with this post. It wasn't meant to be like that, just that I really do not appreciate users such as leileilol attacking me for my efforts, not to mention straw man arguments such as "just repacking other emulators" when I spent many hours compiling this one build and getting the build environment working. If I had simply redistributed one of Hampa Hug's binaries then I would have said so.

SoftPCMuseum_ wrote:

4. You want to know how much time it took me to compile just this one emulator build? An entire night. .

...... it took me literally less than one minute to get the tar.gz's from here, extract in a directory, msys my way over and type ./configure and then make just to see pce-atarist.exe/pce-ibmpc/pce-macplus/pce-rc759/pce-sim405/pce-sim6502/pce-simarm/pce-sims32/pce-img/pri/psi.exe files produced. Just standard Unix procedure. It took longer to write this post than actually doing it

Different things which can slow you down, including but not limited to:

1) Esoteric or undocumented build dependencies.
2) Code generator optimizations for resource constrained platforms.
3) Platform specific scripts / build system brokenness.

Just to be clear, I have no skin in this fight either way. I don't know the PCEM codebase, the experience SoftPCMuseum_ has with said codebase, or any specifics to know if any of the above is applicable. I'm simply suggesting your evident familiarity with PCE and it's build system would save you time and effort as compared to someone like myself who knows UNIX quite well but has never built PCE before. Quantifying this in your statement would improve the presentation of your reasoning and be of value to other forum readers.

I've never built PCE before until today. The dependencies it needed are just SDL from what I can tell. Even the INSTALL file included with the source teaches you the compiling basics

leileilol wrote:

I've never built PCE before until today. The dependencies it needed are just SDL from what I can tell. Even the INSTALL file included with the source teaches you the compiling basics

There you go. It's not always like this.

leileilol wrote:

I've never built PCE before until today. The dependencies it needed are just SDL from what I can tell. Even the INSTALL file included with the source teaches you the compiling basics

Yeah, except when you actually try to compile it in Cygwin. It just simply errored out. And yes, with the help of John Elliott, I had to patch the source files so that SDL would build, so no, I did NOT "just need to read the INSTALL file". I already knew HOW to compile it; the problem was with linking the SDL binaries.

If by "PCE" you meant my emulator, then of course it builds, because I was the one who patched it up so that it would build using the SDL binaries under Cygwin, once again as I said before with the help of John Elliott. It took me hours because I knew for sure that I would have no help on sites such as this, especially not from people such as yourself. Finally, I decided to contact John Elliott to help me out with it and he did, and I also explained to him the attitude that some people have towards helping others with their project, and really to be honest he was a LOT more help to me than you'll ever be. If you choose to dislike me then that's fine, but isn't it better to just ignore it and simply leave it at that rather than rubbing it in even further.

This is exactly the problem with requesting assistance from people online; too many of them simply assume bad faith towards others - either they assume that the person is completely stupid for requesting help, or, they assume bad faith from users of other operating environments (such as those like myself who are developing open source software on Windows), and/or they assume bad faith for other reasons. And believe me, when I made my decision to simply not request assistance from people any longer, you in particular were pretty high up on my list - let's just say that. And it's not just me either - you have also behaved very badly towards Battler from what I have seen, and towards quite a lot of other people in addition to this. To this day I don't even know why I even bother responding to people such as yourself; I guess because it's that I don't take kindly to insults such as yours 24/7.

gdjacobs wrote:

Different things which can slow you down, including but not limited to: […]
Show full quote

Different things which can slow you down, including but not limited to:

1) Esoteric or undocumented build dependencies.
2) Code generator optimizations for resource constrained platforms.
3) Platform specific scripts / build system brokenness.

Just to be clear, I have no skin in this fight either way. I don't know the PCEM codebase, the experience SoftPCMuseum_ has with said codebase, or any specifics to know if any of the above is applicable. I'm simply suggesting your evident familiarity with PCE and it's build system would save you time and effort as compared to someone like myself who knows UNIX quite well but has never built PCE before. Quantifying this in your statement would improve the presentation of your reasoning and be of value to other forum readers.

Well this is all quite a moot point by now anyway since I already have the build system working perfectly under Windows, and I'm already planning for upcoming emulator builds anyway, and patching the source code to link with the SDL libraries was what finally did it in the end, thanks to John Elliott's help. What I was simply saying is that leileilol's argument that I simply "repacked someone else's emulator" is a straw man argument in itself since I worked pretty hard on getting this build to compile and I really don't appreciate it when people demean or belittle my work by making it out to be less than it actually is. And in return, rather than simply getting an apology, I instead get his attitude in return that I apparently don't know how to compile my own emulator builds.

Was Cygwin easier than MinGW?