The Pointer to PCI Data Structure is supposed to be two bytes. It is described in the PCI Firmware Specification Revision 3.0, section 5.1.1. PCI Expansion ROM Header Format.
The pointer is two bytes at 0x18. The pointer is supposed to be a multiple of 4 which means there's always at least two bytes of padding after the pointer. Some BIOS firmware images may use the 2 bytes following the pointer for other purposes (plus additional bytes before the PCI Data Structure) so we cannot assume the bytes will be zero.
Some PCI expansion ROMs may include both BIOS and Open Firmware images.
Fixed an issue where TBR doesn't have full 64-bit range. The original calculation was 64 bit and ended with a ÷ 10^9. This means the max for the upper 32 bits is 2^32/10^9 = 4. The solution is to use a multiplication method that supports a 96 bit product. core/mathutils.h contains functions for that. TBR driving frequency is assumed to be less than 1 GHz. Some minor modification is required for future > 1 GHz support.
Fixed an issue where get-msecs-601 and get-msecs-60x were not returning the same value. RTC was being calculated using timebase frequency instead of nanosecond frequency. 601 uses RTC. 60x uses TBR. On a real Mac, a G3 CPU won't have a RTC and accessing RTC would cause an exception. This is not the case for dingusppc but I don't think that's a problem.
Fixed an issue where RTC was not being updated if only the upper 32 bits (seconds) was read.
Also simplified things by always updating the timestamp instead of only when the seconds changes.
Fixed an issue where the following would cause inconsistent results (tb in the left column would sometimes decrement instead of always incrementing):
2 0 do 2 0 do cr tb@ 8 u.r ." ." 8 u.r loop 2 0 do cr 12 spaces rtc@ 8 u.r ." ." 8 u.r loop 2 0 do cr tb@ 8 u.r ." ." 8 u.r space rtc@ 8 u.r ." ." 8 u.r loop loop
RTC and TBR could not be used simultaneously because they are both incremented by an amount based on the last time stamp but that time stamp can be changed by accessing either RTC or TBR. The solution is to have a different time stamp for each.
Fixed a typo that caused rtc@ to always return 0 for the upper 32 bits (represents seconds).
The problem could cause the following to hang on Power Mac 7500:
cr 2000 0 do get-msecs u. 1 ms loop
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.