dingusppc/devices/memctrl/mpc106.cpp

297 lines
10 KiB
C++
Raw Normal View History

/*
DingusPPC - The Experimental PowerPC Macintosh emulator
Copyright (C) 2018-22 divingkatae and maximum
(theweirdo) spatium
(Contact divingkatae#1017 or powermax#2286 on Discord for more info)
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
*/
/** MPC106 (Grackle) emulation. */
#include <devices/common/hwcomponent.h>
#include <devices/common/mmiodevice.h>
#include <devices/deviceregistry.h>
#include <devices/memctrl/memctrlbase.h>
#include <devices/memctrl/mpc106.h>
#include <memaccess.h>
#include <cinttypes>
2020-05-12 18:55:45 +00:00
#include <cstring>
#include <iostream>
2021-09-15 22:46:38 +00:00
#include <loguru.hpp>
#include <string>
#include <vector>
MPC106::MPC106() : MemCtrlBase(), PCIDevice("Grackle"), PCIHost()
{
2020-03-14 13:23:46 +00:00
this->name = "Grackle";
supports_types(HWCompType::MEM_CTRL | HWCompType::MMIO_DEV |
HWCompType::PCI_HOST | HWCompType::PCI_DEV);
// populate PCI config header
this->vendor_id = PCI_VENDOR_MOTOROLA;
this->device_id = 0x0002;
this->class_rev = 0x06000040;
this->cache_ln_sz = 8;
this->command = 6;
this->status = 0x80;
// add PCI/ISA I/O space, 64K for now
2020-03-31 19:12:06 +00:00
add_mmio_region(0xFE000000, 0x10000, this);
// add memory mapped I/O region for MPC106 registers
add_mmio_region(0xFEC00000, 0x300000, this);
}
int MPC106::device_postinit()
{
std::string pci_dev_name;
static const std::map<std::string, int> pci_slots = {
{"pci_A1", 0xD}, {"pci_B1", 0xE}, {"pci_C1", 0xF}
};
for (auto& slot : pci_slots) {
pci_dev_name = GET_STR_PROP(slot.first);
if (!pci_dev_name.empty()) {
this->attach_pci_device(pci_dev_name, slot.second);
}
}
return 0;
}
uint32_t MPC106::read(uint32_t rgn_start, uint32_t offset, int size) {
2020-03-31 19:12:06 +00:00
uint32_t result;
if (rgn_start == 0xFE000000) {
// broadcast I/O request to devices that support I/O space
// until a device returns true that means "request accepted"
2020-03-31 19:12:06 +00:00
for (auto& dev : this->io_space_devs) {
if (dev->pci_io_read(offset, size, &result)) {
return result;
}
}
LOG_F(ERROR, "Attempt to read from unmapped PCI I/O space, offset=0x%X", offset);
2020-05-12 18:55:45 +00:00
} else {
2020-03-31 19:12:06 +00:00
if (offset >= 0x200000) {
2020-05-12 18:55:45 +00:00
if (this->config_addr & 0x80) // process only if bit E (enable) is set
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 10:32:28 +00:00
return pci_read(offset & 3, size);
2020-03-31 19:12:06 +00:00
}
}
// FIXME: reading from CONFIG_ADDR is ignored for now
return 0;
}
void MPC106::write(uint32_t rgn_start, uint32_t offset, uint32_t value, int size) {
if (rgn_start == 0xFE000000) {
// broadcast I/O request to devices that support I/O space
// until a device returns true that means "request accepted"
2020-03-31 19:12:06 +00:00
for (auto& dev : this->io_space_devs) {
if (dev->pci_io_write(offset, value, size)) {
return;
}
}
LOG_F(ERROR, "Attempt to write to unmapped PCI I/O space, offset=0x%X", offset);
2020-05-12 18:55:45 +00:00
} else {
2020-03-31 19:12:06 +00:00
if (offset < 0x200000) {
this->config_addr = value;
2020-05-12 18:55:45 +00:00
} else {
if (this->config_addr & 0x80) // process only if bit E (enable) is set
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 10:32:28 +00:00
return pci_write(offset & 3, value, size);
2020-03-31 19:12:06 +00:00
}
}
}
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 10:32:28 +00:00
uint32_t MPC106::pci_read(uint32_t offset, uint32_t size) {
2019-08-23 19:30:30 +00:00
int bus_num, dev_num, fun_num, reg_offs;
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 10:32:28 +00:00
bus_num = (this->config_addr >> 8) & 0xFF;
2019-08-23 19:30:30 +00:00
dev_num = (this->config_addr >> 19) & 0x1F;
fun_num = (this->config_addr >> 16) & 0x07;
reg_offs = (this->config_addr >> 24) & 0xFC;
if (bus_num) {
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 10:32:28 +00:00
LOG_F(
ERROR,
"%s err: read attempt from non-local PCI bus, config_addr = %x, offset = %x %02x:%02x.%x @%02x.%c",
this->name.c_str(), this->config_addr, offset, bus_num, dev_num, fun_num, reg_offs,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
return 0xFFFFFFFFUL; // PCI spec §6.1
}
2020-05-12 18:55:45 +00:00
if (dev_num == 0 && fun_num == 0) { // dev_num 0 is assigned to myself
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 10:32:28 +00:00
return this->pci_cfg_read(reg_offs + offset, size);
} else {
if (this->dev_map.count(dev_num)) {
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 10:32:28 +00:00
return this->dev_map[dev_num]->pci_cfg_read(reg_offs + offset, size);
2019-08-23 19:30:30 +00:00
} else {
2020-05-12 18:55:45 +00:00
LOG_F(
ERROR,
"%s err: read attempt from non-existing PCI device %02x:%02x.%x @%02x.%c",
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 10:32:28 +00:00
this->name.c_str(), bus_num, dev_num, fun_num, reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
return 0xFFFFFFFFUL; // PCI spec §6.1
2019-08-23 19:30:30 +00:00
}
}
return 0;
}
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 10:32:28 +00:00
void MPC106::pci_write(uint32_t offset, uint32_t value, uint32_t size) {
2019-08-23 19:30:30 +00:00
int bus_num, dev_num, fun_num, reg_offs;
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 10:32:28 +00:00
bus_num = (this->config_addr >> 8) & 0xFF;
dev_num = (this->config_addr >> 19) & 0x1F;
fun_num = (this->config_addr >> 16) & 0x07;
reg_offs = (this->config_addr >> 24) & 0xFC;
if (bus_num) {
2020-05-12 18:55:45 +00:00
LOG_F(
ERROR,
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 10:32:28 +00:00
"%s err: write attempt to non-local PCI bus, config_addr = %x, offset = %x %02x:%02x.%x @%02x.%c = %0*x",
this->name.c_str(), this->config_addr, offset, bus_num, dev_num, fun_num, reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size,
size * 2, flip_sized(value, size)
);
return;
}
2020-05-12 18:55:45 +00:00
if (dev_num == 0 && fun_num == 0) { // dev_num 0 is assigned to myself
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 10:32:28 +00:00
this->pci_cfg_write(reg_offs + offset, value, size);
} else {
if (this->dev_map.count(dev_num)) {
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 10:32:28 +00:00
this->dev_map[dev_num]->pci_cfg_write(reg_offs + offset, value, size);
2019-08-23 19:30:30 +00:00
} else {
2020-05-12 18:55:45 +00:00
LOG_F(
ERROR,
"%s err: write attempt to non-existing PCI device %02x:%02x.%x @%02x.%c = %0*x",
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 10:32:28 +00:00
this->name.c_str(), bus_num, dev_num, fun_num, reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size,
size * 2, flip_sized(value, size)
);
2019-08-23 19:30:30 +00:00
}
}
}
2020-05-12 18:55:45 +00:00
uint32_t MPC106::pci_cfg_read(uint32_t reg_offs, uint32_t size) {
#ifdef MPC106_DEBUG
LOG_F(9, "read from Grackle register %08X", reg_offs);
#endif
if (reg_offs < 64) {
return PCIDevice::pci_cfg_read(reg_offs, size);
}
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 10:32:28 +00:00
uint32_t offset = reg_offs & 3;
reg_offs &= ~3;
if (~-size & offset) {
LOG_F(
WARNING, "%s: unaligned read @%02x.%c",
this->pci_name.c_str(), reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
}
return pci_cfg_rev_read(READ_DWORD_LE_A(&this->my_pci_cfg_hdr[reg_offs]), offset, size);
}
2020-05-12 18:55:45 +00:00
void MPC106::pci_cfg_write(uint32_t reg_offs, uint32_t value, uint32_t size) {
#ifdef MPC106_DEBUG
LOG_F(9, "write %08X to Grackle register %08X", value, reg_offs);
#endif
if (reg_offs < 64) {
PCIDevice::pci_cfg_write(reg_offs, value, size);
return;
}
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 10:32:28 +00:00
uint32_t offset = reg_offs & 3;
reg_offs &= ~3;
if (~-size & offset) {
LOG_F(
WARNING, "%s: unaligned write @%02x.%c = %0*x",
this->pci_name.c_str(), reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
);
}
// FIXME: implement write-protection for read-only registers
2021-02-03 22:39:19 +00:00
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 10:32:28 +00:00
uint32_t *addr = (uint32_t *)&this->my_pci_cfg_hdr[reg_offs];
WRITE_DWORD_LE_A(addr, pci_cfg_rev_write(READ_DWORD_LE_A(addr), offset, size, value));
if (this->my_pci_cfg_hdr[0xF2] & 8) {
#ifdef MPC106_DEBUG
LOG_F(9, "MPC106: MCCR1[MEMGO] was set!");
#endif
setup_ram();
}
}
2019-08-23 19:30:30 +00:00
2020-05-12 18:55:45 +00:00
void MPC106::setup_ram() {
uint32_t mem_start, mem_end, ext_mem_start, ext_mem_end, bank_start, bank_end;
uint32_t ram_size = 0;
2020-05-12 18:55:45 +00:00
uint8_t bank_en = this->my_pci_cfg_hdr[0xA0];
for (int bank = 0; bank < 8; bank++) {
if (bank_en & (1 << bank)) {
if (bank < 4) {
2020-05-12 18:55:45 +00:00
mem_start = READ_DWORD_LE_A(&this->my_pci_cfg_hdr[0x80]);
ext_mem_start = READ_DWORD_LE_A(&this->my_pci_cfg_hdr[0x88]);
2020-05-12 18:55:45 +00:00
mem_end = READ_DWORD_LE_A(&this->my_pci_cfg_hdr[0x90]);
ext_mem_end = READ_DWORD_LE_A(&this->my_pci_cfg_hdr[0x98]);
} else {
2020-05-12 18:55:45 +00:00
mem_start = READ_DWORD_LE_A(&this->my_pci_cfg_hdr[0x84]);
ext_mem_start = READ_DWORD_LE_A(&this->my_pci_cfg_hdr[0x8C]);
2020-05-12 18:55:45 +00:00
mem_end = READ_DWORD_LE_A(&this->my_pci_cfg_hdr[0x94]);
ext_mem_end = READ_DWORD_LE_A(&this->my_pci_cfg_hdr[0x9C]);
}
bank_start = (((ext_mem_start >> bank * 8) & 3) << 30) |
(((mem_start >> bank * 8) & 0xFF) << 20);
bank_end = (((ext_mem_end >> bank * 8) & 3) << 30) |
(((mem_end >> bank * 8) & 0xFF) << 20) | 0xFFFFFUL;
if (bank && bank_start != ram_size)
LOG_F(WARNING, "MPC106: RAM not contiguous!");
2021-02-03 22:29:48 +00:00
ram_size += bank_end - bank_start + 1;
}
}
if (!this->add_ram_region(0, ram_size)) {
LOG_F(ERROR, "MPC106 RAM allocation failed!");
}
}
static const PropMap Grackle_Properties = {
{"pci_A1",
new StrProperty("")},
{"pci_B1",
new StrProperty("")},
{"pci_C1",
new StrProperty("")},
};
static const DeviceDescription Grackle_Descriptor = {
MPC106::create, {}, Grackle_Properties
};
REGISTER_DEVICE(Grackle, Grackle_Descriptor);