be45a6a020
Add PCI bridge and multi-function device support. Overview: - A multi-function device is two or more PCIDevices with the same device number but one device is function zero (as with currently implemented PCIDevices) and the other functions have function numbers between 1 and 7. The device number and function number are properties of the PCIDevice's parent PCIHost connection. - A PCIBridge is a PCIHost (it can connect child PCI devices) and a PCIDevice (it has config space, BARs, and expansion ROM). - A PCIDevice has Type 0 header. It has 6 BARs. - A PCIBridge has Type 1 header. It has 2 BARs. The config space registers beginning from offset 0x18 differ from those of a PCIDevice. Possible future modifications: - Add a PCICardBus class. It is a PCIHost. It has Type 2 header. It has one BAR. The first 20 bytes match Type 0 and Type 1 headers. These exist in New World Macs. They allow hot-plug of PCI devices. - Split base PCI registers (first 16 bytes) into a PCIBase class. Type 1 and 2 have two or one BAR but I think all 6 BARs belong in PCIBase class anyway. - Split PCIHost into two classes: Currently existing PCIHosts (Bandit, Grackle) are PCIHost and PCIRoot (they have the broadcast I/O requests functionality) while PCIBridge is PCIHost only - it can propagate I/O requests but does not originate the broadcast. - pci_register_mmio_region should maybe return a pointer to a region struct so that it can be used for unregistering or modifying the region's range. This may be useful for PCI bridges which have ranges that may constrain memory BARs of their downstream devices. PCIDevice - Moved expansion ROM BAR handling to a separate function pci_wr_exp_rom_bar so that it can be used by both PCI devices and PCI bridges which have the ROM BAR in different locations. It now supports unmapping expansion ROM. Also made exp_rom_bar not writable if there's no ROM. - Added num_bars field which specifies the number of valid BARs since Type 0, 1, and 2 headers have different number of BARs. - map_exp_rom_mem now properly unmaps expansion ROM (using new function unmap_exp_rom_mem) before mapping it again. - Added function set_multi_function which modifies hdr_type to indicate if a device has other functions. This is to be applied only to devices with function number 0. PCIHost - When attaching a PCI device, it will check if it's a multi-function device (there exists an attached function that is not zero) and adjust hdr_type of function 0 of the device accordingly. - Attached PCI bridges are added to a list of PCI bridges attached to the host. - Added pci_io_read_loop and pci_io_write_loop which loop through attached PCI devices to find one that will perform the action for the given I/O address without logging an error (since some other device might perform the action). - Added pci_io_read_broadcast and pci_io_write_broadcast which are used by a PCI root (bandit/grackle). They will log an error if the action is not performed. They should probably do a machine check exception to match real Power Macs. - pci_find_device (used by PCI root) will recursively find a PCIDevice for type 1 config register accesses. - Logging from PCIHost now includes the name of the PCIHost instead of just "PCIHost" because there can be multiple PCI hosts. PCIBridge - Sets num_bars to 2 and hdr_type to 1. - I/O ranges set in the config registers are handled correctly by pci_io_read and pci_io_write. - Memory ranges set in the config registers do not currently affect memory mmio regions. It is assumed that Open Firmware and the OS will set the ranges and BARs correctly to allow all BARs to be accessed fully. bandit, mpc106 - Bandit and Grackle now call pci_io_read_broadcast and pci_io_read_broadcast to pass I/O accesses to downstream PCI devices. - Chaos is modified to work like Bandit even though it will never have PCI bridges attached or devices that support I/O accesses. It's simpler this way. |
||
|---|---|---|
| .github | ||
| benchmark | ||
| core | ||
| cpu/ppc | ||
| debugger | ||
| devices | ||
| machines | ||
| thirdparty | ||
| utils | ||
| zdocs | ||
| _config.yml | ||
| .clang-format | ||
| .gitignore | ||
| .gitmodules | ||
| CMakeLists.txt | ||
| CMakeSettings.json | ||
| CONTRIBUTING.md | ||
| dppcicon.ico | ||
| endianswap.h | ||
| icon.rc | ||
| LICENSE | ||
| main.cpp | ||
| memaccess.h | ||
| README.md | ||
| vcpkg.json | ||
DingusPPC
Written by divingkatae and maximumspatium
Be warned the program is highly unfinished and could use a lot of testing. Any feedback is welcome.
Philosophy of Use
While many other PowerPC emus exist (PearPC, Sheepshaver), none of them currently attempt emulation of PPC Macs accurately (except for QEMU).
This program aims to not only improve upon what Sheepshaver, PearPC, and other PowerPC mac emulators have done, but also to provide a better debugging environment. This currently is designed to work best with PowerPC Old World ROMs, including those of the PowerMac G3 Beige.
Implemented Features
This emulator has a debugging environment, complete with a disassembler. We also have implemented enough to allow Open Firmware to boot, going so far as to allow audio playback of the boot-up jingles.
How to Use
This program currently uses the command prompt to work.
There are a few command line arguments one must enter when starting the program.
-r, --realtime
Run the emulator in runtime.
-d, --debugger
Enter the interactive debugger.
-b, --bootrom TEXT:FILE
Specifies the Boot ROM path (optional; looks for bootrom.bin by default)
-m, --machine TEXT
Specify machine ID (optional; will attempt to determine machine ID from the boot rom otherwise)
As of now, only the Power Macintosh G3 Beige is implemented.
How to Compile
You need to install development tools first.
At least, a C++11 compliant compiler and CMake are required.
You will also have to recursive clone or run
git submodule update --init --recursive
This is because the CubeB module is not included by default. All other components are already included in the thirdparty folder and compiled along with the rest of DingusPPC.
For example, to build the project in a Unix-like environment, you will need to run the following commands in the OS terminal:
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make dingusppc
You may specify another build type using the variable CMAKE_BUILD_TYPE.
Future versions may drop SDL 2 as a requirement.
For Raspbian, you may also need the following command:
sudo apt install doxygen graphviz
Testing
DingusPPC includes a test suite for verifying the correctness of its PowerPC CPU emulation. To build the tests, use the following terminal commands:
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make testppc
Intended Minimum Requirements
- Windows 7 or newer (64-bit), Linux 4.4 or newer, Mac OS X 10.9 or newer (64-bit)
- Intel Core 2 Duo or better
- 2 GB of RAM
- 2 GB of Hard Disk Space
- Graphics Card with a minimum resolution of 800*600
Compiler Requirements
- GCC 4.7 or newer (i.e. CodeBlocks 13.12 or newer)
- Visual Studio 2013 or newer