joevt b654424465 Fix PCI config r/w of byte and word and unaligned
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 pci_cfg_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.

The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3.

The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses.

pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read.

pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify.

Other changes:
- for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings.
- for unimplemented config register reads and writes, pcidevice now includes offset in log warnings.
- pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices.
- ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset.

Notes:
- 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.
2022-09-02 03:39:50 -07:00
2022-05-21 15:14:30 +02:00
2022-05-21 14:51:27 +02:00
2021-04-19 00:13:33 +02:00
2020-03-26 23:30:27 -07:00
2020-05-12 23:55:45 +05:00
2020-05-12 21:20:57 +05:00
2020-12-03 00:53:28 +01:00
2020-03-26 12:32:24 -07:00
2019-07-19 14:24:39 -07:00
2019-07-19 14:24:39 -07:00
2019-07-01 19:13:30 -07:00
2022-08-22 16:47:38 -07:00

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
Languages
C++ 93.7%
C 4.2%
Python 1.2%
CMake 0.8%