Some plans for future DOSBox-X developments =========================================== * Clock domains - Current DOSBox-X emulation is CPU-centric, which is OK, I guess, but not ideal for much of the emulation. - Many delays and timing are based on floating point values in milliseconds. If clock domains were implemented, devices could count very accurately in clocks at a rate of their choosing and better maintain timing that way. - Clock domains could be coded to cascade as well. The obvious example is original PC hardware where the ISA 14.31818MHz clock is divided by 12 to produce the 1.193182MHz clock used to drive the 8253 PIT and other system components. - One part of the emulation that would definitely benefit from clock domain based timing would be the VGA emulation. Pixel and scanline counting would become very accurate if counted with integers according to pixel clocks instead of using the floating math it does now. - Another part of the emulation that would benefit would be the I/O delay emulation. Instead of bumping a fixed number of CPU cycles, the code could more accurately delay CPU timing according to, say, an ISA bus clock domain set to 8.3333MHz and knowledge of a typical ISA bus cycle. Or, if the I/O cycle is directed at the PCI bus (clock domain set to 33.3333Mhz) delays emulated according to PCI bus cycle or PCI burst I/O cycle counting. * Runtime hooks for patching - If told to do so, DOSBox-X can look for an IPS file (or DOSBox-X equivalent) and when a particular EXE is loaded into memory, patch the executable image before executing it. The idea being that DOS gamers can use this mechanism to fix bugs in a game or demo without modifying the original EXE. It can also be a fun way to cheat :) - We could assist this mechanism with the ability for the user to force an EXE file to be loaded at a specific segment, in case the patch is sensitive to segment values. Loading must fail of course if we cannot put the EXE at that location. - We could also add the ability for DOSBox-X to patch data files when the game reads them from disk, to hack textures, sounds, etc. Again the data file remains unmodified on disk. - On a related note, it would be cool if we could implement something like Bochs volatile mode where data is read from the file, but writes to the file are directed to a temporary file which is thrown away on exit, keeping your files unmodified. - If executable unpacking is involved, some additional tools could be provided where the patch does not modify the loaded EXE, but can be instructed to patch an area of memory when the instruction pointer hits a specific location in the EXE (usually when the EXE has finished unpacking and checking it's integrity). * Support for loading BIOS images and mapping them into adapter ROM - We could test various VGA BIOSes in DOSBox-X that way - We could also run old motherboard BIOSes in DOSBox-X that way * Convert I/O and memory handler callback system to on-demand bus mapping and tracing design - Instead of statically assigning I/O and memory handlers, all handlers are initialized to a lookup function. - The DOSBox motherboard emulator at this point would also maintain it's own setup of a system bus hierarchy (system resources and RAM vs forwarding to the ISA bus, or a PCI-based system that forwards to PCI which can forward via PCI-ISA bridge to ISA, etc.). - When the lookup function is called, the function goes through the "slow" path where it asks the motherboard what function to call, and the motherboard returns a function pointer according to it's designation of routing, which is then written into the I/O handler. In other words, once an I/O port has been accessed, further access is a direct call to the I/O callback. - If resources or mappings change on the bus, then all I/O ports affected have the I/O handler changed back to the slow path lookup function, so that changes take effect when the lookup function returns the new result according to changed routing. - If the memory access involves resources that don't overlap but are too small for DOSBox's 4KB granularity, then the "slow path" function will always be invoked for that memory I/O because it is impossible to write both callbacks to that memory page callback. - Once all I/O and memory resources are routed this way, it becomes easy for DOSBox to emulate devices that can change I/O ports such as ISA PnP type devices that allow you to change the base I/O port of a resource. Sound Blaster ISA PnP emulation will no longer emit a warning when Windows or any DOS program attempts to reprogram the base address. It would also allow DOS or Windows to change, relocate, enable/disable PCI resources. The only performance penalty is that everytime a mapping changes, the emulator has to invalidate all I/O and memory callbacks to allow the "slow" path to do it's work again. - The reason we don't do bus lookup every time is one of performance. DOSBox-X already has an array of IO handlers and memory page handlers, so why not make use of it as a cache for callbacks once the slow path has been taken? Doing it this way should have almost no impact on emulator performance. * Motherboard & BIOS oriented system construction - Rather than the one way the DOSBox kernel does it, the user could instead specify that DOSBox-X emulate a particular motherboard with a particular BIOS. The code could then construct I/O and memory mangement to emulate the known chipsets on that board. Example: If instructed to, it would emulate the system board on an old laptop of mine with a Chips & Tech 386 AT ASIC, or it could emulate an old AST motherboard and instruct PIC emulation to act like a Unicorn Microelectronics UM8259A-2. The default of course would carefully mimic for backwards compatability the DOSBox mainline "motherboard" and "bios" configuration. - Such construction may include (if on original hardware), VGA emulation tuned to mimic the onboard VGA of the original hardware if user says it should be enabled. * CD audio - Refactor the code to ensure we feed out CD audio in a way the guest can track it's time accurately. - IDE/ATAPI emulation needs to support the mode select or whatever commands used by DOS programs to change CD audio volume. * Full Intellimouse scrollwheel emulation - Apparently it's possible to respond to scrollwheel events via SDL, so add code to receive them. - Add code to store scroll wheel deltas in mouse event queue. - Add code to take overall scrollwheel delta and transmit as 4th byte in Intellimouse mouse on AUX. - And toughest of them all: Figure out how the hell Windows 98 is able to use scrollwheel data when it is still reliant on the INT 15h device callback that's documented only to carry the X, Y, and button state data. If VirtualBox can do it, so can I! The ONLY documentation I have on this are snippets of code from CuteMouse that is apparently able to turn on PS/2 BIOS scroll wheel capture for DOS. In any case perhaps the best course of action is to write a program in DOSLIB that hooks the device callback and records the values on the stack during the call, with and without the Intellimouse knock sequence in effect. * Multiple DOS kernel emulation - Instead of only emulating a general mishmash of MS-DOS 5.0 to 6.x syscalls, allow dosbox-x.conf setting (and command line at runtime) to choose that a particular brand and version is emulated. For example, if you say that you want DOSBox-X to emulate MS-DOS 3.3, then it will return values and act like MS-DOS 3.3 (including the shorter form of the disk parameter table prior to MS-DOS 4.0). With the current code, if you say that you want DOSBox-X to emulate MS-DOS 7.1, then it tries to return values and act like MS-DOS 7.1 (including support for FAT32 drives and long filenames). * Misc - If PCI emulation is enabled, then byte-sized writes to port 0xCF9 should follow Intel PIIX chipset documentation: if bit 1 changes from 0 to 1 the system undergoes a "soft reset", and if bit 2 changes from 0 to 1 the system undergoes a "hard reset". Reset method confirmed working on an old Pentium system of mine, and it complements the keyboard and port 0x92 methods well. - So what exotic method are older demos using the clear the screen anyway? Can you figure it out? Their failure to clear the screen properly is causing graphic anomolies during certain parts. - Memory and I/O resource management code. Rather than just pick regions of memory and I/O space, the emulation code should have a way to mark that such and such region has been taken for e.g. "VGA BIOS" and "ROM BIOS". It would make it possible for adapter emulation to know if the region it is trying to take is already occupied, and provide a way for said adapter (unless instructed by user) to automatically pick a location that it can claim. It would also make for good debugging information. - Peripherals should assign themselves to a bus if possible. Sound Blaster emulation for example would register itself to the I/O ports on the ISA bus. Voodoo 3dfx emulation would register itself to the PCI bus. - Support not just for declaring an ISA bus and it's frequency, but also for ISA devices that you would declare "attached" to the bus (same with PCI). Instead of DOSBox's design where peripherals are static and only one at a time is possible, we would allow you to declare peripherals and declare them attached to the ISA bus slots. If you want to emulate a DOS machine with three Sound Blaster cards, you could declare three of them (with different resources of course) and have them attached to the ISA bus. - If I wanted DOSBox-X to emulate a VESA local bus peripheral, would I have to do anything extra to do it? - CMOS emulation. The current code sucks. Why exactly are all values hard-coded? That's not how the RTC/CMOS works! The real deal has clock registers in the first 14 bytes and the rest is non-volatile RAM! Fix! - RTC/CMOS emulation: support non-realtime mode (where the clock does NOT follow host time but follows time accurately according to emulation). But of course the option to follow realtime would also be available. - IDE/ATA emulation: What exactly is triggering the debugger when you boot MS-DOS 6.22 using the OAK CD-ROM driver? It needs to be removed, it makes using MS-DOS 6.22 with debugger builds annoying. - VGA Linewise rendering is currently hardcoded for 16bpp RGB. Why? Add option to allow the user to choose 32bpp RGBA linewise rendering. - VGA output: add optional scalar or post-processing that can auto-detect fake high-color VGA modes in demos, and process the scanlines such that the RGB spreads vertically to mask the raster scanline effect (so that the picture is presentable even if rescaled later) - VGA output: Add support for VESA 24bpp modes (DOSBox's scalers are currently hard-coded for 8/16/32bpp). There are some demos (a 1997 Coma demo comes to mind) where if a 24/32bpp mode is chosen the demo assumes 24bpp RGB arrangement. - VGA debugging function: Add code that, if triggered, allows DOSBox to pause emulation and allow you to examine/play with the VGA palette, DAC, registers, screen bytes, etc. The reason I want to do this is that there are some demos (listed elsewhere in the BUGS section) where for whatever reason there are VGA palette errors, some entries remain black despite palette animation. The "debugger" would overlay the VGA screen, of course. - VGA "fixed output" mode. A scalar would be invoked if enabled that upscales all VGA raster output to a specific resolution and frame rate (the frame rate would be 250Hz, 300Hz, or 1000Hz so that refresh rate changes are better represented accurately). This would be one way to capture demos that change VGA modes once per section in one AVI file. Scalar would include common VGA resolutions like 640x400, 640x480, 800x600, and 1024x768. The scalar could also distort the picture if the CRT timing is known to cause older VGA monitors to squeeze the picture (such as some older DOS demos that speed up vertical retrace knowing it would cause older VGA monitors to focus the raster beam in the center for a "widescreen" effect). - VGA overscan border rendering. Update/rewrite the raster linewise renderers to include overscan border in output if asked to. - ODML AVI capture. The current code works great until you hit 2GB, then falls apart. I would be willing to throw in code I've written for other professional projects to write AVI files that are ODML compliant to enable longer captures >= 2GB (contain both the AVIOLDINDEX and ODML AVI index).