All the reverse-engineering work comes from AntonioND [1].
A new video backend API has been added to grab video images.
By default, a dummy backend is provided.
However, an OpenCV based backend is also provided (if enabled at
compile-time with OPENCV=1 in Makefile).
Other implementation should be possible (GStreamer for instance ?) in
the future.
With the OpenCV backend, the video device selection can be done using
the Core parameter:
[Core]
GbCameraVideoDevice=<my_device>
Where <my_device> can be either an integer which represent the device
number (0 for default) or a string which specify the video device path.
Tested with 64DD Mario Talent Studio (Japan), a transfer pak plugged
in the first controller with a Japanese GameBoy camera. Also since the
core currently requires a cart ROM (even if should strictly be required)
I used Perfect Dark (Japan) to allow using the Transfer Pak. This is a
core/ui limitation not related to this PR.
[1] https://github.com/AntonioND/gbcam-rev-engineer
For now, the bio pak only report hard-coded BPM value.
In future work remote heart rate monitoring methods (rPPG) could be
implemented to provide an experience similar to the Bio Sensor pak using
a regular webcam. However it could be quite CPU intensive and may prove
challenging in multi-player context.
Another idea to create an "equivalent" Bio Sensor experience without the
original device, could be to derive the reported heart rate from the
BPM (or any relevant quantity) from a user specified audio clip.
Previously, the RDRAM detection/initialization was wrong and a post
RDRAM initialization hack was triggered (just before initial PI DMA)
to force specified amount of RDRAM to be recognized.
With this PR, several aspects of the RDRAM have been implemented which
results in proper detection of RDRAM by the IPL3:
- support for up to 8 (IPL3 hardcoded limitation) RDRAM modules
- partial support for individual rdram address mapping,
ADDR_SELECT has not been implemented though
- support broadcast register writes
- simulating read failure when current calibration is not done yet
Also
* Move backends implementations under backends directory.
* Rework file_storage to be a real implementation of storage_backend.
* Fixup PIF_PDT_EEPROM types
* Extract joybus stuff from pif module.
* Extract cart stuff from pif module.
* Extract controllers and paks from si module.
Main changes in this partial rewrite are:
- channel processing is done in 2 separate steps. First is the channel
setup done when 0x1 is written in the "pif status byte". The second step
is the effective channel processing which allow each channel device to
answer. This step is done just before DMA reads. This is in accordance
with Patent 6394905. (Fig5B - Pif Macro). This allowed to greatly
simplify pif channel processing (no more strange bytes to parse in pif
ram and no duplicated code for that).
- "pif status byte" is treated as a bitfield with each flag indicating
which action to take.
- command processing interface has been reworked to separate the
transmitted data (Tx,TxBuf) from the the received data (Rx, RxBuf).
- reworked the code to allow custom pif channel processing
callback. This should allow to implement "raw" processor to let an
external device (such as a Raphnet controller) do the channel
processing.
- Validate pif commands
- Fixed eeprom write command which missed the status byte.
- Updated the controller input backend to split pak detection from
controller connection test.
- Consolidated all input plugin compatibility code inside one module
(eg. controller_input, rumble and pif processings functions).
- Added PIF channel printing debug
- Explicitly name asm_defines_gas.h and asm_defines_nasm.h rather than
using a wildcard rule: otherwise make automatically deletes the latter
after the build is complete(!?) - see [1].
- Add missing dependency of the awk rule on ../../tools/gen_asm_defines.awk.
[1]
https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html
This didn't work correctly for two reasons:
- The symbols were being marked as undefined (imported) rather than
exported. I could fix that by adding an initializer (= {0}), but then
the binary gets huge; not sure if there's a way around that.
- Mach-O binaries don't store symbol sizes. You can get nm to try to
calculate them with --size-sort, but I'm not sure if this will always
output the correct result.
In lieu of more complicated platform-specific fixes, I switched to an
approach that renders the value as hex, allowing the object file to be
piped directly to awk on all platforms.
- Fix BITS=32 build (-Wl,-m,elf_i386 obviously doesn't work, and -m32
isn't needed since another part adds '-arch i686' to CFLAGS).
- Change -bundle to -dynamiclib. (-bundle has been effectively
deprecated altogether since the early days of OS X, and was never the
right setting for .dylib files.)
- Only pass '-read_only_relocs suppress' on 32-bit. On x86-64 this flag
just emits a warning saying that it has no effect, and evidently isn't
necessary. (On 32-bit x86 it enables text relocations, which are used
by some of the asm stuff.)
