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>
src/hardware/reelmagic/driver.cpp
src/hardware/reelmagic/mpeg_decoder.h
src/hardware/reelmagic/player.cpp
src/hardware/reelmagic/vga_passthrough.h
src/hardware/reelmagic/video_mixer.cpp
src/hardware/reelmagic/docs/...
src/hardware/reelmagic/tools/...
This matches the other multi-component modules that have
their own subdirectory like: mame, mouse, and serialport.
This allows for dropping the redundant filename prefixes, and
simply call the component-code was they represent within the
Reel Magic design.
It also co-locates the tools and documentation, and makes
small modifications to reflect the new paths and names.
The RealMagic support can now be toggled off and on during
runtime with tear-down of all active resources (the driver,
callbacks, interrupt handler, VGA mixing, and audio channel)
Add shutdown/destroy routines to the initialization phase.
Also simplifies the set of configurable items down to just
the on/off states, key, and frame-rate code.
The other settings were mostly for debugging and testing,
and these values already exist as static-globals within the
reelmagic code - so developers can continue to tweak and test
those at compile-time.
The majority of people building Staging want release builds without
complications due to system libraries. This includes users on windows
using MSYS2, Raspberry Pi users (via RetroPie), macOS users, and Linux
users with OSes that might be very new or slightly out-of-date.
Packagers can configure meson to use shared libraries and not fallback
to wraps, and additionally ask to have specific libraries provided
from the system using -Duse_system_libs=lib1,lib2, instead of wraps.
Thanks to @PatTheMav for the suggestion: "As for the
Homebrew issue, it might make sense to remove that
requirement from the macOS docs then as the package
seems only intended for use as a dylib."
- Mention system-update to install xcode
- Add python3, pkg-config, and cmake as related tools
Staging itself doesn't depend on these, but Meson uses pkg-config and cmake)
To work with Staging sources, we have many helpful python3 scripts
- Add notes about giving the terminal permissions
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
Meson is fully operational, old buildsystem is not (on this branch).
Remove following files:
- .gitignore files that we needed to support clean in-tree builds
- all automake files in all subdirectories
- m4 macros
- Autoconf-specific documentation for tests
- configure.ac, autogen.sh, and other Autotools-related files
Few .gitignore files were adjusted, as they had entries unrelated
to Autotools.
