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.