joncampbell123/dosbox-x
1
0
Fork 0
mirror of https://github.com/joncampbell123/dosbox-x.git synced 2025-10-14 02:17:36 +08:00
Code Issues Packages Projects Releases Wiki Activity

[PATCH 1/9] Plenty of blather. Got some good ideas.

Browse Source 
NOTE: auto-magically re-imported by HAL 9000
HASH: e9561251df (original)
This commit is contained in:
Jonathan Campbell
2014-01-20 19:22:14 -08:00
committed by Wengier
parent 45b0d10251
commit 6962f16e1e
43 changed files with 5042 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

172
docs/PLANS/General TODO.txt Normal file
View File

@@ -0,0 +1,172 @@
* Clock domains
- Current DOSBox 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).
* Port to SDL 2.0
- Doing that would open up some useful 2D blitting functions and support for
multiple windows, which would be very useful for multi-monitor emulation
or implementing a debugger, or emulating a multi-head DOS setup with both
VGA and MDA/Hercules monitors.
* Support for loading BIOS images and mapping them into adapter ROM
- We could test various VGA BIOSes in DOSBox that way
- We could also run old motherboard BIOSes in DOSBox 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 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.
* Multiple DOS kernel emulation
- Instead of only emulating a general mishmash of MS-DOS 5.0 to 6.22 syscalls,
allow dosbox.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 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.
* 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.