4100a80f96
dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. pcidevice: - The logging macros should be used to handle all config register access logging. - Unaligned PCI config register accesses will be output as ERROR instead of WARNING. - The logging macros include the offset and size. They also include the value for named registers or for writes. - Added MMIODevice read and write methods so that PCIDevice is not abstract if a PCIDevice doesn't override the read and write method since some PCIDevices don't have MMIO. pcihost: - Added pci_find_device stub for handling PCI bridges in future commit. bandit and mpc106: - PCI host controllers will handle all PCI config access alignment and sizing. A PCIDevice will always access config registers as 32 bits on a 4 byte boundary. The AccessDetails passed to a PCIDevice config read or write method is there only for logging purposes. bandit: - Common MMIO code is moved to new BanditHost class so both Bandit and Chaos can use it. PCI related code is moved to new BanditPCI class. - Simplify IDSEL to/from PCI device number conversion by removing the shift or subtract. - Remove BANDIT_ID_SEL check. The IDSEL conversion to PCI device number can find the bandit PCI device. - For logging, make best guess of PCI device number from invalid IDSEL - the result is always reasonable for device 0x00 to 0x0A when accessing config register 0x00 (as one would do when scanning for PCI devices like lspci does). mpc106: - Common config space code is put in cfg_setup. It handles extracting the offset. - Added code to log access to unimplemented config registers of grackle. - Don't call setup_ram when writing to config registers that setup_ram doesn't use. - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian. atirage: - The changes correctly place user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. |
||
|---|---|---|
| .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