- Added support for FreeBSD, OpenBSD, NetBSD and DragonFly BSD.
+ It is quite unlikely that the original Win32 implementation worked with the HX DOS extender on DOS as it required loading inpout32.dll which depends on a Windows kernel driver. This implementation is expected to work, because it supports direct I/O too. I am unable to verify that though.
- Made direct I/O available on all platforms, because it is desirable everywhere, including on Windows. On the BSDs it is the only interface available.
+ Least amount of latency. I/O through inpout32.dll/inpoutx64.dll or Linux's ppdev adds a significant amount of overhead. Measurements with inpout32.dll show that practical, real-world overhead can be as large as 400%, i.e. I/O taking 4 times longer than direct I/O.
+ For some devices, direct (read) access to the parallel port control register is needed which ppdev does not allow.
+ Not all parallel port PCI(e) cards are supported by ppdev. Perhaps most are not. Direct I/O works everywhere, because no host OS support is needed.
+ Made possible on 64-bit Windows by giveio64 and on 32-bit Windows by AllowIO (part of the PortTalk package). On Linux, FreeBSD, OpenBSD, NetBSD and DragonFly BSD on x86(_64), direct I/O will be enabled after opening a special device (/dev/io on FreeBSD & DragonFly BSD) or making a special system call (*iopl()).
- Visual Studio allows inline assembly only for x86 builds. However, the intrinsics __in{byte, word, dword}() and __out{byte, word, dword}() work for both x86 and AMD64 builds. Visual Studio versions older than 2015 have _inp{w, d}() and _outp{w, d}(). Those intrinsics also work on both x86 and AMD64 platforms. Visual Studio 2022 still has them too, but only for C (not for C++).
- Put inpout32.dll/inpoutx64.dll loading code in the new passthroughio library so that the functionality can be shared between parallel port and other pass-through code. For example, the original OPL pass-through functionality by Ralf Grillenberger ("h-a-l-9000", author of DOSBox Megabuild 6 where virtually all pass-through code in DOSBox-X originated from) could be enabled, although it looks there has not been any demand for that in DOSBox-X (the Windows-only implementation in DOSBox-X has been disabled a long time ago). Regardless, it is cleaner to separate the low-level I/O code from the parallel port pass-through code.
- Since the PortTalk interface (src/libs/porttalk) is no longer being used I removed it.
+ AllowIO can still be used on systems where the PortTalk device driver could be used.
- Direct I/O will be used if possible. Only on Linux one can actively avoid that by specifying realport instead of realbase in the configuration file.
+ On Linux and the BSDs the code will use direct I/O only if the effective user ID is 0 (root), because only then direct I/O is possible.
+ On Windows the code installs an exception handler and it will load inpout32.dll/inpoutx64.dll only if direct I/O causes an exception. Be aware that if reallpt is specified in the configuration file, when debugging with Visual Studio, that exception will be caught by the Visual Studio debugger instead (unless you start giveio64 beforehand).
- Solved issues with writing to the control register (changing I/O direction with ppdev was not implemented).
- Applied a better solution to a former issue in src/hardware/parport/parport.cpp that caused PARALLEL_Read() and PARALLEL_Write() to silently fail. See https://github.com/joncampbell123/dosbox-x/issues/2214.
- Corrected write to potentially invalid ECR address in CDirectLPT::~CDirectLPT() (ecpbase was ignored when restoring the value of the extended control register).
- Corrected code that enabled parallel port IRQ (could have caused trouble for some people as the code does not and cannot install an IRQ handler on most host OSes).
- Re-enabled code that sets the parallel port to bidirectional mode when using direct I/O and added code that does the same for Linux's ppdev.
+ Bidirectional mode is the most compatible mode.
+ Setting *a* mode is better than just relying on whatever is set in the BIOS or UEFI or whatever the state of a PCI(e) parallel port card is in after booting.
- Added code to reset the EPP Time-out state.
- Made log messages explicit about whether pass-through has been enabled, identifying the parallel port, thereby clarifying the situation to the user.
- passthroughio.cpp compiles cleanly with MinGW (GCC 9), MinGW-w64 (GCC 12 and Clang 15), Cygwin 32-bit (GCC 11), Cygwin 64-bit (GCC 11), Visual Studio 2015 (x86 & amd64), Visual Studio 2019 (x86 & amd64), Visual Studio 2022 (x86 & amd64), GCC 12 on Linux/x86_64 and GCC 8 on Linux/armv7.
+ The resulting code has been successfully tested on Windows 10 Pro, Linux/x86_64 and Linux/armv7.
- All changes compile cleanly as part of DOSBox-X v2022.12.26 with MinGW (build-mingw, build-mingw-lowend (after manual intervention because of broken build scripts), build-mingw-lowend-sdl2 (after adding "-lz -liconv" to LIBS in src/Makefile)), Visual Studio 2019 (amd64), GCC 12 on Linux/x86_64 (build-debug-sdl2) and GCC 8 on Linux/armv7 (build-sdl2).
- The resulting DOSBox-X executables (MinGW (build-mingw, build-mingw-lowend) & ones built with native GCC) have been successfully tested with actual (non-printing) hardware attached to a parallel port on:
+ Linux (Raspberry Pi OS) on Raspberry Pi 2B (with pi-parport, using ppdev)
+ Windows 2000 and Windows XP on laptops using inpout32.dll and AllowIO (tested on Windows 2000 only) (thanks to Mystic_Merlin)
+ Linux (Debian) on HP Thin Client T510 using ppdev (thanks to NorQue).
The executable produced with build-mingw-lowend-sdl2 failed on a DirectSound issue during start up (on Windows XP and Windows 10).
PR #4054 broke the macOS CI for pull requests and the nightly builds.
As a follow-up requested in the PR this is an attempt to fix it.
* Add a parameter to `configure.am` to define a build-time variable for
use in `Makefile.am` to specify the executables we will be depending
upon for the `dosbox-x.app` rule.
* Fix an issue in the first library scan section of the `dosbox-x.app`
rule in the `Makefile` causing a failure to build on an Apple Silicon
mac when there is no `x86_64` binary present.
* Fix failure to build SDL1 variant after a previous SDL2 build attempt
by deleting `vs/sdl2/linux-host` before attempting the SDL1 build.
* Use `make clean` instead of `make distclean` in the build scripts'
`do_cleanup` function to not clean absolutely everything.
* Make sure we remove the achitecture-specific copies we create of the
`dosbox-x` executable before building, as these are meant to be
used for the universal binary creation with `lipo` and the presence
of an old copy will cause the `dosbox-x.app` bundle to potentially
contain mismatched copies for each architecture, or contain an
architecture that is not intended to be included.
* Add a `distclean-local` rule to `src/Makefile.am` to remove the
architecture-specific temporary copies of the `dosbox-x` executable
when running `distclean` as these shouldn't remain in the tree.
Signed-off-by: Dani Llewellyn <dani@bowlhat.net>
