SoftPCMuseum wrote:All of the new Intel chipset-based machines that I added are based on the correct Intel chipsets, since I have definitely looked at reliable component listings from PC Magazine articles. For example, all of the Gateway 2000 machines are based on the actual Intel chipsets and system boards that they shipped with when first new, and I also tested each new machine to make sure that it was able to boot up, and I also put down a list of issues in the V100README.TXT file.
Sure, you got the Intel 4*0*X chips right, but have you got the Super I/O chips right? Have you got any other auxiliary chips right? Your readme even openly admits that you went and used the existing emulated chips in place of the correct ones, even though the correct ones might operate entirely diffrently.
Also, testing each new machine to make sure it boots up is not enough - you need to test more extensively. You need to make sure that reconfiguring COM ports, etc., all works as intended. It doesn't, you've given the word a wrong chip or the chip is impoperly emulated.
And your readme says a lot of stuff that are basically "the board has problems, I have no idea why, so use a workaround instead". That's not an acceptable standard, sorry.
ake my latest changes to the Intel chipset emulation for example. I have already made major changes in order to accomodate new features for future versions of the emulator such as numerous new Intel chipsets and even the AGP bus, especially for machines that were available/current on the same day in 1998. However, the developers of 86Box and VARCem seem to find that to be "too modern/new" for those emulators to handle, leaving only my own emulator fork.
They are not too modern/new - they need Pentium Pro/Pentium II emulation, which as you can see, I already started, but it's not as easy as you think it is.
Also, if you checked the entire directory tree of the CPU code, you will see that I actually made quite a few changes to the CPU code. There are many new CPU models, for example (including the UMC 486 CPUs),
Did you get their timings anywhere close to the real ones? Did you add any manufacturer-specific instructions? Were you able to find official datasheets for any of the new CPU's?
and even the base CPU core has changed in many ways to be more accurate to how the original CPUs actually worked (especially for Pentium and higher CPUs).
I'm doing this with the 808x emulation these days, and even that took me over two weeks to
port from reenigne's cycle-accurate XTCE emulator. You're telling me you did the same work on the Pentium (which is much more complex than the 808x) in less time,
from scratch? Sorry, but I find that hard to believe.
And no, as reenigne, Scali, trixter, etc. have already explained to you on the Vogons forum before, just blindly copying the cycle counts from a datasheet is not it.
The machine listings are mainly reorganized in the order of brand name or system manufacturer (such as IBM, COMPAQ, Intel, et...) instead of in the order of the CPU socket type. I also tried to clean it up a bit by using hopefully more accurate product names and model numbers.
For the end user, organization by CPU type/socket type is much more relevant, as it allows them to find machines of a given period more easily. Your list also has a lot "categories" and "separators" which are really machines - if you want actual categories and sepatators in the list, you need to use something more advanced that a standard combo box, which is going to mean have to write a lot of your own code to handle the stuff.
The new machines that are extremely incomplete were also disabled in the source code anyway. You could theoretically re-enable them yourself but I am not at all guaranteeing that they are going to even be usable, unlike with the machines that were actually enabled for this release.
No, a lot of your branded machines that are enabled in the source code, use the existing machines' init functions, even though they probably use entirely different Super I/O chips, etc.
The reason why there are all of these separate forks is that we all have significant disagreements on which direction that this emulator should be heading in, and so a lot of the changes that one "fork" makes might not be considered acceptable by the developers of another fork.
I'm going to respond to that in PM.
Also, there are a lot of new machines which I am personally interested in adding from a whole series of brand names (some quite rare and others much more commonplace back when they were new), but I'm not really sure as to whether they would be of any interest to the developers of the other emulator forks. Like many of my program's new machines, for example. Lots of these machines used similar Intel chipsets and even Intel system boards, and so I'm not exactly convinced that the other emulator forks would find them to be of any use to their projects considering that they already have basic emulation of standard Intel boards.
They are of interest, but often it's difficult to find out which Super I/O chip, etc. they use, and sometimes their BIOS'es flat out don't work (eg. any Phoenix 486 or Pentium BIOS'es I've tried so far). That's why they're not there. You also never asked me at all about any of it. I believe that I had invited you to directly contribute to 86Box. I think I'm one of the few emulator developers that is actually willing to sit down, have a talk, and find a compromise acceptable to both sides.
.
