Justification for mapping it to svga_paradise is that it
provides sufficient "early" VGA compatibly without
regressions or loss of functionality.
Thanks to Jon Campbell for this recommendation and
explanation, as follows:
---
For Staging's purposes, it would be better to map vgaonly to
one of the older SVGA chipsets that lack VBE extensions, like
Tseng or Paradise emulation. Those are close enough to plain
VGA.
Fair warning though, Tseng ET4000 cards map the chained
256-color mode to planar differently from normal VGA/SVGA
cards. It can matter depending how the game accesses video
memory. One issue on DOSBox-X pointed to some Chinese made
game that appeared to chained and unchained 256-color memory
access as needed in a way that needed the Tseng ET4000 cards,
and it's possible other games need the plain VGA mapping the
same.
Maybe vgaonly could be mapped to svga_paradise instead.
---
Test cases showing that vga_paradise is sufficent and without
harm include:
1) from Jonathan Campbell:
I know of a good test case, "Get Saddam" as seen on
Shovelware Diggers that, despite supporting CGA or VGA
graphics, uses a graphics library that will crash if
VESA BIOS extensions are present. The technical
explanation is the library was obviously written
around really old VESA BIOS extensions that wrote the
mode information into the buffer without zeroing all
128 or 256 bytes of the structure. It doesn't allocate
enough space on the stack for the full structure, so
more modern code and DOSBox/DOSBox-X that does write
all 256 bytes causes stack corruption and the game
crashes. Notice when Shovelware Diggers covers it,
he's using the CGA mode because the VGA option
probably reliably crashed when he tried.
2) from NickNine:
The Need for Speed (original not SE) makes two batch
scripts NFS.BAT with NFSVESA.BAT with the second one
calling univbe before running the game
- under vgaonly it predictably does not run with
either bat since there's no VESA support at all.
- under svga_paradise it does not run from nfs.bat
but does run from nfsvesa.bat.
Thank you for this testing help, NickNine!
---
In the event svga_paradise's set of
SVGA-detectable-features causes regressions in some
games or software, then additional handling would be
needed to re-instate vgaonly as strictly that - simply
a non-SVGA card, as Jonathan Campbell (once again!) explains:
Perhaps machine=vgaonly could just be Paradise emulation
but with any extended registers blocked off so DOS games
can't detect it. Here's a collection of documentation on
what Paradise cards have in their registers for your
reference: http://hackipedia.org/browse.cgi/Computer/Platform/PC%2c%20IBM%20compatible/Video/VGA/SVGA/Paradise
Paradise cards are close enough to VGA that if you
prevent DOS games from detecting the SVGA chipset it
should be a good enough substitute for vgaonly. In
fact according to documentation at that URL there are
registers you have to write magic values to them to
"unlock" the extended registers. So then for
machine=vgaonly just don't allow the guest to unlock
those extended registers and remove any signature from
the VGA BIOS that might suggest Paradise/Western
Digital SVGA.
Thank you, Jonathan Campbell, for all the help -- both
in the current mapping decision and potential future
fix, if regressions due inface surface.
Co-authored-by: Jonathan Campbell <jonathan@castus.tv>
Co-authored-by: NicknineTheEagle <nik18.1995@gmail.com>
Various places in code used mix of uppercase and lowercase typography
for describing key combinations. Replace all those style with consistent
convention:
- Key names are always capitalized: Alt, Ctrl, Shift, Cmd, …
- Key combinations are connected with '+': Alt+F1
- Update DOSBox Staging Team copyright span to year 2021 (DOSBox Team
copyrights left untouched).
- Add DOSBox Staging Team copyright line to files we extensively
modified throughout 2020 (we add our copyright lines when number of
non-trivially modified lines gets close to 50%).
- Change "dosbox-staging team" to "DOSBox Staging Team", in line with
updated branding.
- Change MAME license identifiers to SPDX license identifiers.
- Cleanup some excessive whitespace around copyright statements.
- Do few adjustments to include order.
- Add few missing copyright identifiers (GPL-2.0-or-later,
LGPL-2.1-or-later, BSD-3-Clause) as appropriate for specific file.
- Move SPDX identifiers to the top in scripts for consistency with other
source files.
- Remove old copy of GPL2 license in italian from old translations.
These actions are not useful on modern hardware, as there are better
ways of adjusting emulation speed and VGA emulation is not as CPU
intensive as it was with old scalers.
On the other side, we can now reuse the Ctrl+F7/F8 keybinds for more
useful actions.
Also, remove all traces of these interfaces from user manual (README
file) and man page (docs/dosbox.1).
MCI (Media Control Interface) was a primary Windows interface. Code
comments and documentation claimed, that it's only for "NT, 2000, XP"
but the code was enabled for Windows 2000 or later (version > 4.0).
DX (Digital audio eXtraction (?)) could be forced on any Windows with
autodetection working only on Vista and Windows 7 (code was disabled for
Windows 8 or later - probably unintentionally).
DIO used DeviceIoControl interface and Windows-specific ioctl calls.
All 3 interfaces depend on SDL and SDL_cdrom functionality to work.
SDL_cdrom 1.2 implementation uses MCI on Windows to provide the same
functionality.
ASPI was supported by Microsoft only for Windows 95, 98 and, ME.
Adaptec supported this interface going forward for Windows NT, 2000,
and XP (32-bit only).
Fix crash reported by MiniMax (mount -u 0).
Fix bug reported by Tearex ("config -get" broken).
Add some protection that makes it harder to mount a directory from
within an executable.
Add some protection to make mounting from command /c much harder.
Add a securemode commandline switch to config and dosbox that should make it
impossible to mount a location when this isn't wanted by the user. (Addresses concerns of CVE-2007-6328)
Update documentation to reflect this.
Imported-from: https://svn.code.sf.net/p/dosbox/code-0/dosbox/trunk@3114
