Just to let you know I'm still here, I did some brainstorming on where I want to take DOSBox-X next development wise.
I won't be able to do it until the next weekend because of work, but I thought I'd throw my plans for the next 4-6 months out here if you want to know what I plan to work on.
DOSBox-X (coming months):
- New CPU core: the 8088 core (also 8086). New core implementation that will develop into the 286, 386, 486, etc. core rewrites as time goes on, eventually replacing the current CPU core code entirely. I think it's weird that despite DOSBox targeting old DOS games, nobody ever thought to add a core that limits itself to only 8088 and 286 instructions, in case certain games relied on quirks that the 386 and higher cannot execute correctly. Future plans: the 286 core will also emulate 286 quirks like the LOADALL instruction, and the 386 core the 386 version of LOADALL as well as route FPU errors to INT 13 instead of INT 16 (stuff like that).
- Runtime option: dosbox.conf to control whether FPU is present or not, except to ignore the setting if cputype=pentium since by that point programmers generally assumed the FPU was present due to Intel's integration of components. Current DOSBox emulation of the FPU is weird and a bit flawed and unrealistic. For example, it was actually quite rare for 386-class systems to have an FPU, it was far more common for Windows 3.1 and 95 to have to turn on the FPU "emulation" that triggered software emulation, and that's what DOSBox needs to emulate. And there is a flaw with EFLAGS emulation where even if you set cputype=386 the AC flag can be toggled which causes games and Windows 3.1 to report a 486 regardless. And I vaguely recall a bug with the FSTENV instruction where DOSBox interpreted both forms as the 16-bit form even if 32-bit override or some silly nonsense.
- Pentium Model Specific Register emulation: Instead of just bullshitting RDMSR/WRMSR, add code to emulate the Pentium's model specific registers. That includes writing the Time Stamp Counter with WRMSR.
- PC floppy controller emulation: First test code in DOSLIB to talk to an actual controller, play with the drive, then begin writing emulation in DOSBox-X. The code needs to have conditionals for both 3.5" and 5.25" type drives. DOSBox-X emulation must have an "enable" option for the FDC, and options to specify either drive presence and type. During development, we need to see if any fancy vm86 trickery is needed for Windows 95 to "see" the controller (same hacks as IDE needed?). If so, then just like IDE emulation, we add "fakeio" and "fakevm86io" options. Note that getting Windows 95 to use it's native protected mode floppy driver would eliminate the last warning in the System dialog box about MS-DOS compatibility fallback for drive A: . I/O needs to support DMA and PIO modes. Proceed carefully. Out of all standard PC hardware the FDC is the worst and most finicky part to talk to. Code needs to emulate time delays related to motor on/off, drive select, head movement, disk rotation, read delays waiting for sector to pass under the head, etc. etc. Code needs to be added to the "imgmount" command so that when mounting a disk image to the floppy drive (either "a" or "0") the user can add something like -fdc 0 to say that the disk image should also be attached to the first floppy drive on the cable for FDC emulation (much like we do now with the -ide switch to specify which controller and master/slave setting to attach to). As development progresses, if enabled in dosbox.conf, the FDC emulation would also randomly fail reads and writes sometimes to emulate the fickle unreliable nature of floppy disk media (which is why most FDC implementations are written to retry up to 3 times on failure).
- DOSLIB: Re-add commands to play with multiple mode (testing and setting). Re-add read/write test routines for ALL modes: C/H/S single, C/H/S multiple, LBA single, LBA multiple, LBA48 single, LBA48 multiple, etc. DOSBox-X needs to implement ATAPI TEST, NOP commands, and ATA sleep/idle/power state/device reset commands like any real IDE device would.
- Windows 3.1 and Windows 95: Make sure the DOS VM can capture/restore EGA and VGA state correctly for all standard INT 10h modes 0 through 19 (non-VESA modes). If it can't, then work to make sure it can. I also remember from real Windows 95 installations that, if you ran various DOS games that used VGA Mode X unchained 256-color mode, and hit Alt+Enter to exit fullscreen mode, the DOS VM was reliable at capturing a frozen "screenshot" of the game screen despite the use of Mode X, while Windows 3.1 wasn't savvy enough to do that. Hitting Alt+Enter to return to the game was successful at restoring the display as well and resuming the game.
- CGA emulation: Most VGA cards emulate CGA 320x200x4-color mode apparently by using odd/even mode, just like the alphanumeric mode. At the very least, this is what I noticed my S3 ViRGE card doing. In other words, you could consider even/odd bytes of the CGA bytes to exist in VGA planes 0 and 1 in the same way VGA alphanumeric mode works. DOSBox-X's emulation should reflect this. BUT, you have an alternate implementation work as it does now when machine=cga because CGA does not have "planes". VGA draw code should reflect this: VGA-type CGA rendering, unless machine=cga, then use current code. Future research: what SVGA cards don't use odd/even mode for CGA 320x200x4-color? Is the Tseng ET4000 chip the odd man out again?
- Investigate claims that disk and CD-ROM swapping still cause crashes. Is it in general? Or just Win32 builds? Could it be related to the bug you found in GCC where if you have multiple constructors, and have one constructor call another, that double allocation or other weird issues crop up?
- Re-integrate Taewoong's OpenGL-based 3dfx emulation, if possible. People on the DOSBox forums want the option back to specify voodoo=opengl for performance. That means some additional work:
1. configure.ac on Linux needs to detect Mesa3D libraries, conditionally enable OpenGL if they are available, or disable voodoo=opengl if not
2. The Windows version needs to interface with Windows OpenGL.
3. configure.ac autodetect OpenGL on Mac OS X how??
4. I hear the 3Dfx emulation has had many updates and fixes since Taewoong's integration??
- Whatever happened to the guy that wanted the Brazillian thousands separator key or whatever it was?
- ISA/PCI device "separation". Devices that normally connect as ISA devices (like Sound Blaster) will add themselves to a list of ISA devices instead of directly hooking into the I/O port callback table. I/O port callbacks will be set up so that, unless claimed by other I/O callbacks, they take a "slow path" that queries each PCI and ISA device to ask if they wish to "claim" the I/O cycle. If only one devices does, then that device's I/O callback is written into the I/O port callback so that I/O emulation is as fast as before for that device. I/O callback code will provide an "invalidation" function for devices that change I/O ports (I/O slots are changed back to the "slow path"). Some devices like the voodoo and S3 emulation will add themselves as PCI devices, who will be queried the same way. PCI configuration space will invalidate I/O and mem ranges they once owned when the BARs are modified so that the guest OS can reconfigure PCI devices as needed. Eventually, the only code to have direct I/O assignment will be "motherboard" emulation, and the emulated motherboard will take on the task of querying ISA/PCI devices to claim I/O cycles. Part of this changeover will also direct ISA devices to call into the "motherboard" to signal ISA IRQ lines rather than directly to the PIC, to allow the motherboard emulation to direct the signals.
- PCI IRQ routing emulation. PCI devices will signal interrupts using emulated INT#A, INT#B, INT#C, INT#D lines. The motherboard emulation will be allowed to dictate how the PCI IRQ lines are routed, on most motherboards, the A-D lines are rotated once per PCI slot for example. Basic motherboard emulation will contain control registers to dictate how PCI INT A-D map to PIC IRQs (Intel PIIX style). For guest OSes like Windows 95 and Linux, this will also necessitate what I understand are PCI BIOS calls to query IRQ routing information. Like real PCI-based motherboards, if an IRQ is assigned to PCI, the IRQ signal from the ISA bus will be ignored. If the user has disabled PCI emulation, then the motherboard simply routes ISA IRQs directly to the PIC (in the style of 486-class and earlier motherboards).
Since PCI IRQ routing is an important part of PCI emulation, there will be no option to disable it independently of disabling PCI emulation. Additional options will be added to dosbox.conf to allow the user to specify which IRQs are assigned to PCI including the ability for INT# signals to share IRQs if ISA devices are more important, or if not specified, use the typical Intel PIIX and mid-1995 BIOS type settings where INT#A = IRQ5, INT#B = IRQ9, INT#C = IRQ10, INT#D = IRQ11.