Battler wrote:

but what do you expect from a project where the main developer insists on developing the emulator with a "fix/implement something if a relevant enough piece of software is found that uses it" rather than with a "do everything by the specification" approach

Hey, it's worked for me for ~15 years, why change? 😀

(which yould IMHO yield much cleaner code and less bugs)

In my experience this tends to lead to either a huge amount of non-functional code that's a nightmare to debug, or a bored developer who gives up part way through...

Re: multiple video cards - it's been something that's been on my todo list for PCem for a while now, but other things that I find more interesting keep coming up...

SarahWalker wrote:

Hey, it's worked for me for ~15 years, why change? 😀

But the needs of the userbase have changed. Back then, there were many more real 386+ machines around where people could run things that PCem could not, now there are less and less. Though I would personally be satisfied if PCem got the 386+ breakpoints going. And I am perfectly prepared to add them myself, just like I added present bit checking on read/write within a segment (which is something 386LOAD actually tests - it uses LOADALL386 to successfully load a segment with the present bit clear, then tries reading/writing within that segment, expecting it to correctly fail with a GPF) which is going to be among the things I'm going commit as patches after v11 is released, however the code as it is right now left me scratching as to where I would put the breakpoint handling code. Then we would have at least the 386 up to spec, and could then focus on fixing other things.

In my experience this tends to lead to either a huge amount of non-functional code that's a nightmare to debug, or a bored developer who gives up part way through...

Actually, I think it would be easier to debug as if the CPU emulation was to the specification, then if something did not work, you could exclude the CPU from the suspects, while right now you can not.

Also, about multiple pieces of the same hardware... I tried to add support for a second CD-ROM drive, but everything CD-ROM-related is hardcoded to one drive, so it would be a mess to do. A second graphics card would be nice too - you could have one on port 3C0-3DF and one on 3A0-3BF, with a second window for the secondary card. And sound card wise, it would be nice to be able to have an AdLib or AdLib Gold in addition to a Sound Blaster 1 or 2, and it should be pretty easy to do.

90% of the time, the way MAME is developed: emulate along until you hit unemulated opcodes or something and the emulation goes off into the weeds. Implement what's missing. Continue testing.

10% of the time, the way MAME is developed: carefully read all specifications and create one whole emulation from specs with every feature implemented.

Sorry to say Battler, but while every MAME team member operates slightly differently, generally speaking the world's largest and oldest open-source emulator develops things Sarah's way. Even though it may bother you, it's a time-tested approach. 😀

Battler wrote:

But the needs of the userbase have changed. Back then, there were many more real 386+ machines around where people could run things that PCem could not, now there are less and less.

There weren't exactly many back then either.

Battler wrote:

Though I would personally be satisfied if PCem got the 386+ breakpoints going.

Unlikely to be feasible, if you still want the emulator to run with any level of speed.

Battler wrote:

Actually, I think it would be easier to debug as if the CPU emulation was to the specification, then if something did not work, you could exclude the CPU from the suspects, while right now you can not.

Well, no you couldn't exclude the CPU in that case, as you'd likely have a large chunk of basically untested code that you'd have no idea whether it was being exercised or not. At least with my method, when you have something that uses currently unimplemented behaviour you at least have an obvious test case!

Not to mention the specification is sometimes wrong/often incomplete.