From 03777cffb483dc426b7fd1b82a4c8e844f6c3553 Mon Sep 17 00:00:00 2001 From: angelosa Date: Thu, 7 Dec 2023 19:56:11 +0100 Subject: konami/viper.cpp: implement Epic PCTPR, housekeeping --- src/devices/video/voodoo_banshee.cpp | 1 + src/devices/video/voodoo_render.cpp | 4 + src/mame/konami/viper.cpp | 166 +++++++++++++++++++---------------- src/mame/misc/comebaby.cpp | 3 +- src/mame/misc/xtom3d.cpp | 3 +- 5 files changed, 98 insertions(+), 79 deletions(-) diff --git a/src/devices/video/voodoo_banshee.cpp b/src/devices/video/voodoo_banshee.cpp index a23311802c8..b266a5f2bca 100644 --- a/src/devices/video/voodoo_banshee.cpp +++ b/src/devices/video/voodoo_banshee.cpp @@ -467,6 +467,7 @@ void voodoo_banshee_device::device_start() m_io_regs.write(banshee_io_regs::sipMonitor, 0x40000000); m_io_regs.write(banshee_io_regs::lfbMemoryConfig, 0x000a2200); u32 dram0 = 0x00579d29; + // HACK: VMI_DATA_6 / VMI_DATA_5 strapping pins if (m_fbmem_in_mb == 16) dram0 |= 0x0c000000; // Midway Vegas (denver) expects 2 banks of 16MBit SGRAMs else diff --git a/src/devices/video/voodoo_render.cpp b/src/devices/video/voodoo_render.cpp index 4ad88890275..8127bea35e1 100644 --- a/src/devices/video/voodoo_render.cpp +++ b/src/devices/video/voodoo_render.cpp @@ -840,6 +840,10 @@ void rasterizer_texture::recompute(voodoo_regs const ®s, u8 *ram, u32 mask, r // Add check for upper nibble not equal to zero to fix funkball -- TG if (texlod.tmultibaseaddr() && texlod.magic() == 0) { + // TODO: konami/viper.cpp still don't work right here + // it seems to expect relative offsets in every game, + // where the base addresses are actually set with negative numbers + // (i.e. 0xff0000, 0xffc000, 0xfff000 ...) base = (regs.texture_baseaddr_1() & addrmask) << addrshift; m_lodoffset[1] = base & mask; base = (regs.texture_baseaddr_2() & addrmask) << addrshift; diff --git a/src/mame/konami/viper.cpp b/src/mame/konami/viper.cpp index 09639aa49f9..0d26a03c49a 100644 --- a/src/mame/konami/viper.cpp +++ b/src/mame/konami/viper.cpp @@ -144,7 +144,7 @@ -=========================================================================================================================== +=================================================================================================== Konami Viper Hardware Overview (last updated 5th June 2011 10:56pm) @@ -223,75 +223,8 @@ MB81G163222-80 - Fujitsu MB81G163222-80 256k x 32-bit x 2 banks Synchronous Grap LM358 - National Semiconductor LM358 low power dual operational amplifier (SOIC8 @ U14) 6379AL - NEC uPC6379AL 2-channel 16-bit D/A converter (SOIC8 @ U30) ADC0838 - National Semiconductor ADC0838 Serial I/O 8-Bit A/D Converters with Multiplexer Options (SOIC20 @ U13) - DS2430 - Dallas DS2430 256-bits 1-Wire EEPROM. Has 256 bits x8 EEPROM (32 bytes), 64 bits x8 (8 bytes) - one-time programmable application register and unique factory-lasered and tested 64-bit - registration number (8-bit family code + 48-bit serial number + 8-bit CRC) (TO-92 @ U37) - The OTP application register on the common DS2430 and the Police 911 2 DS2430 are not programmed - (application register reads all 0xFF and the status register reads back 0xFF), so it's probably safe - to assume they're not used on any of them. - It appears the DS2430 is not protected from reading and the unique silicon serial number is - included in the 40 byte dump. This serial number is used as a check to verify the NVRAM and DS2430. - In the Police 911 2 NVRAM dump the serial number of the DS2430 is located at 0x002A and 0x1026 - If the serial number in the NVRAM and DS2430 match then they are paired and the game accepts the NVRAM. - If they don't match the game requires an external DS2430 (i.e. dongle) and flags the NVRAM as 'BAD' - The serial number is not present in the CF card (2 different Police 911 2 cards of the same version - were dumped and matched). - When the lasered ROM is read from the DS2430, it comes out from LSB to MSB (family code, LSB of - S/N->MSB of S/N, CRC) - For Police 911 2 that is 0x14 0xB2 0xB7 0x4A 0x00 0x00 0x00 0x83 - Family code=0x14 - S/N=0x0000004AB7B2 - CRC=0x83 - In a DS2430 dump, the first 32 bytes is the EEPROM and the lasered ROM is 8 bytes and starts at 0x20h - For Police 911 2 that is.... - 00000000h CB 9B 56 EC A0 4C 87 53 51 46 28 E7 00 00 00 74 - 00000010h 30 A9 C7 76 B9 85 A3 43 87 53 50 42 1A E7 FA CF - 00000020h 14 B2 B7 4A 00 00 00 83 - It may be possible to hand craft a DS2430 for a dongle-protected version of a game simply by using - one of the existing DS2430 dumps and adjusting the serial number found in a dump of the NVRAM to pair them - or adjusting the serial number in the NVRAM to match the serial number found in one of the dumped DS2430s. - This Police 911 2 board was upgraded from Police 911 by plugging in the dongle and changing the CF card. - The NVRAM had previously died and the board was dead. Normally for a Viper game that is fatal. Using - the NVRAM from Police 911 allowed it to boot and then the NVRAM upgraded itself with some additional - data (the original data remained untouched). This means the dongle does more than just protect the game. - Another interesting fact about this upgrade is it has been discovered that the PCB can write to the - external DS2430 in the dongle. This has been proven because the serial number of the DS2430 soldered - on the PCB is present in the EEPROM area of the Police 911 2 DS2430. - Here is a dump of the DS2430 from Police 911. Note the EEPROM area is empty and the serial number (from 0x20 onwards) - is present in the above Police 911 2 DS2430 dump at locations 0x11, 0x10 and 0x0F - 00000000h FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF - 00000010h FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF - 00000020h 14 A9 30 74 00 00 00 E7 - This proves that the EEPROM area in the DS2430 is unused by an unprotected game and in fact the on-board - DS2430 is completely unused by an unprotected game. That is why any unprotected game will work on any - Viper PCB regardless of the on-board DS2430 serial number. - The existing DS2430 'common' dump used in the unprotected games was actually from a (dongle-protected) - Mahjong Fight Club PCB but that PCB was used to test and run all of the unprotected Viper games. - M48T58Y - ST Microelectronics M48T58Y Timekeeper RAM (DIP28 @ U39). When this dies (after 10 year lifespan) - the game will complain with error RTC BAD then reset. The data inside the RTC can not be hand created - (yet) so to revive the PCB the correct RTC data must be re-programmed to a new RTC and replaced - on the PCB. - Regarding the RTC and protection-related checks.... - "RTC OK" checks 0x0000->0x0945 (i.e. I can clear the contents after 0x0945 and the game will still - happily boot). The NVRAM contents are split into chunks, each of which are checksummed. It is a 16-bit checksum, - computed by summing two consecutive bytes as a 16-bit integer, where the final sum must add up to 0xFFFF (mod - 65536). The last two bytes in the chunk are used to make the value 0xFFFF. There doesn't appear to be a - complete checksum over all the chunks (I can pick and choose chunks from various NVRAMs, as long as each chunk - checksum checks out). The important chunks for booting are the first two. - The first chunk goes from 0x0000-0x000F. This seems to be a game/region identifier, and doesn't like its - contents changed (I didn't try changing every byte, but several of the bytes would throw RTC errors, even with a - fixed checksum). I'd guess that the CF verifies this value, since it's different for every game (i.e. Mocap - Boxing NVRAM would have a correct checksum, but shouldn't pass Police 911 checks). - The second chunk goes from 0x0010-0x0079. This seems to be a board identifier. This has (optionally) - several fields, each of which are 20 bytes long. I'm unsure of the first 6 bytes, the following 6 - bytes are the DS2430A S/N, and the last 8 bytes are a game/region/dongle identifier. If running - without a dongle, only the first 20 byte field is present. With a dongle, a second 20 byte field will - be present. Moving this second field into the place of the first field (and fixing the checksum) - doesn't work, and the second field will be ignored if the first field is valid for the game (and in - which case the dongle will be ignored). For example, Police 911 will boot with a valid first field, - with or without the second field, and with or without the dongle plugged in. If you have both fields, - and leave the dongle plugged in, you can switch between Police 911 and Police 911/2 by simply swapping - CF cards. + DS2430 - Dallas DS2430 256-bits 1-Wire EEPROM. + M48T58Y - ST Microelectronics M48T58Y Timekeeper RAM (DIP28 @ U39). 29F002 - Fujitsu 29F002 256k x8 EEPROM stamped '941B01' (PLCC44 @ U25). Earlier revision stamped '941A01' CN4/CN5 - RCA-type network connection jacks CN7 - 80 pin connector (unused in all games?) @@ -309,17 +242,88 @@ MB81G163222-80 - Fujitsu MB81G163222-80 256k x 32-bit x 2 banks Synchronous Grap CF card version of the same game can be swapped and the existing RTC works but sometimes the RTC data needs to be re-initialised to factory defaults by entering test mode. Sometimes the game will not boot and gives error RTC BAD meaning the RTC is not compatible with the version or the dongle is required. - See DS2430 above for more info. + See DS2430 below for more info. 28-WAY - Edge connector used for connecting special controls such as guns etc. DIP(4) - 4-position DIP switch. Switch 1 skips the CF check for a faster boot-up. The others appear unused? +[DS2430] Has 256 bits x8 EEPROM (32 bytes), 64 bits x8 (8 bytes) + one-time programmable application register and unique factory-lasered and tested 64-bit + registration number (8-bit family code + 48-bit serial number + 8-bit CRC) (TO-92 @ U37) + The OTP application register on the common DS2430 and the Police 911 2 DS2430 are not programmed + (application register reads all 0xFF and the status register reads back 0xFF), so it's probably safe + to assume they're not used on any of them. + It appears the DS2430 is not protected from reading and the unique silicon serial number is + included in the 40 byte dump. This serial number is used as a check to verify the NVRAM and DS2430. + In the Police 911 2 NVRAM dump the serial number of the DS2430 is located at 0x002A and 0x1026 + If the serial number in the NVRAM and DS2430 match then they are paired and the game accepts the NVRAM. + If they don't match the game requires an external DS2430 (i.e. dongle) and flags the NVRAM as 'BAD' + The serial number is not present in the CF card (2 different Police 911 2 cards of the same version + were dumped and matched). + When the lasered ROM is read from the DS2430, it comes out from LSB to MSB (family code, LSB of + S/N->MSB of S/N, CRC) + For Police 911 2 that is 0x14 0xB2 0xB7 0x4A 0x00 0x00 0x00 0x83 + Family code=0x14 + S/N=0x0000004AB7B2 + CRC=0x83 + In a DS2430 dump, the first 32 bytes is the EEPROM and the lasered ROM is 8 bytes and starts at 0x20h + For Police 911 2 that is.... + 00000000h CB 9B 56 EC A0 4C 87 53 51 46 28 E7 00 00 00 74 + 00000010h 30 A9 C7 76 B9 85 A3 43 87 53 50 42 1A E7 FA CF + 00000020h 14 B2 B7 4A 00 00 00 83 + It may be possible to hand craft a DS2430 for a dongle-protected version of a game simply by using + one of the existing DS2430 dumps and adjusting the serial number found in a dump of the NVRAM to pair them + or adjusting the serial number in the NVRAM to match the serial number found in one of the dumped DS2430s. + This Police 911 2 board was upgraded from Police 911 by plugging in the dongle and changing the CF card. + The NVRAM had previously died and the board was dead. Normally for a Viper game that is fatal. Using + the NVRAM from Police 911 allowed it to boot and then the NVRAM upgraded itself with some additional + data (the original data remained untouched). This means the dongle does more than just protect the game. + Another interesting fact about this upgrade is it has been discovered that the PCB can write to the + external DS2430 in the dongle. This has been proven because the serial number of the DS2430 soldered + on the PCB is present in the EEPROM area of the Police 911 2 DS2430. + Here is a dump of the DS2430 from Police 911. Note the EEPROM area is empty and the serial number (from 0x20 onwards) + is present in the above Police 911 2 DS2430 dump at locations 0x11, 0x10 and 0x0F + 00000000h FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF + 00000010h FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF + 00000020h 14 A9 30 74 00 00 00 E7 + This proves that the EEPROM area in the DS2430 is unused by an unprotected game and in fact the on-board + DS2430 is completely unused by an unprotected game. That is why any unprotected game will work on any + Viper PCB regardless of the on-board DS2430 serial number. + The existing DS2430 'common' dump used in the unprotected games was actually from a (dongle-protected) + Mahjong Fight Club PCB but that PCB was used to test and run all of the unprotected Viper games. + +[M48T58Y] When this dies (after 10 year lifespan) + the game will complain with error RTC BAD then reset. The data inside the RTC can not be hand created + (yet) so to revive the PCB the correct RTC data must be re-programmed to a new RTC and replaced + on the PCB. + Regarding the RTC and protection-related checks.... + "RTC OK" checks 0x0000->0x0945 (i.e. I can clear the contents after 0x0945 and the game will still + happily boot). The NVRAM contents are split into chunks, each of which are checksummed. It is a 16-bit checksum, + computed by summing two consecutive bytes as a 16-bit integer, where the final sum must add up to 0xFFFF (mod + 65536). The last two bytes in the chunk are used to make the value 0xFFFF. There doesn't appear to be a + complete checksum over all the chunks (I can pick and choose chunks from various NVRAMs, as long as each chunk + checksum checks out). The important chunks for booting are the first two. + The first chunk goes from 0x0000-0x000F. This seems to be a game/region identifier, and doesn't like its + contents changed (I didn't try changing every byte, but several of the bytes would throw RTC errors, even with a + fixed checksum). I'd guess that the CF verifies this value, since it's different for every game (i.e. Mocap + Boxing NVRAM would have a correct checksum, but shouldn't pass Police 911 checks). + The second chunk goes from 0x0010-0x0079. This seems to be a board identifier. This has (optionally) + several fields, each of which are 20 bytes long. I'm unsure of the first 6 bytes, the following 6 + bytes are the DS2430A S/N, and the last 8 bytes are a game/region/dongle identifier. If running + without a dongle, only the first 20 byte field is present. With a dongle, a second 20 byte field will + be present. Moving this second field into the place of the first field (and fixing the checksum) + doesn't work, and the second field will be ignored if the first field is valid for the game (and in + which case the dongle will be ignored). For example, Police 911 will boot with a valid first field, + with or without the second field, and with or without the dongle plugged in. If you have both fields, + and leave the dongle plugged in, you can switch between Police 911 and Police 911/2 by simply swapping + CF cards. + The PCB pinout is JAMMA but the analog controls (pots for driving games mostly) connect to pins on the JAMMA connector. The 2 outer pins of each pot connect to +5V and GND. If the direction of control is opposite to what is expected simply reverse the wires. The centre pin of each pot joins to the following pins on the JAMMA connector..... Pin 25 Parts side - GAS POT Pin 25 Solder side - STEERING POT -Pin 26 Parts side - HANDBRAKE POT (if used, for example Xtrail Racing) +Pin 26 Parts side - HANDBRAKE POT (if used, for example Xtrial Racing) Pin 26 Solder side - BRAKE POT For the gun games (Jurassic Park III and Warzaid) the gun connects to the 28 way connector like this...... @@ -620,6 +624,8 @@ private: uint32_t eicr = 0U; uint32_t svr = 0U; + uint8_t pctpr = 0xfU; + int active_irq = 0; MPC8240_IRQ irq[MPC8240_NUM_INTERRUPTS]{}; @@ -971,6 +977,7 @@ void viper_state::mpc8240_soc_map(address_map &map) return m_i2c.sr; }), NAME([this] (offs_t offset, u8 data) { + // TODO: very wrong, only bits 4 & 2 writeable m_i2c.sr = data; LOGI2C("I2CSR %02x\n", data); }) @@ -1128,6 +1135,12 @@ void viper_state::mpc8240_soc_map(address_map &map) // epic_update_interrupts(); }) ); + map(0x60080, 0x60080).lw8( + NAME([this] (offs_t offset, u8 data) { + m_epic.pctpr = data & 0xf; + epic_update_interrupts(); + }) + ); // IACK map(0x600a0, 0x600a0).lr8( NAME([this] (offs_t offset) { @@ -1193,8 +1206,9 @@ void viper_state::epic_update_interrupts() { if (m_epic.irq[i].pending) { - // pending interrupt can only be serviced if its mask is enabled and priority is non-zero - if (m_epic.irq[i].mask == 0 && m_epic.irq[i].priority > 0) + // pending interrupt can only be serviced if its mask is enabled + // and priority is above PCTPR (> 1 for Konami Viper) + if (m_epic.irq[i].mask == 0 && m_epic.irq[i].priority > m_epic.pctpr) { if (m_epic.irq[i].priority > priority) { @@ -1255,6 +1269,7 @@ void viper_state::mpc8240_epic_reset(void) } m_epic.active_irq = -1; + m_epic.pctpr = 0xf; } /*****************************************************************************/ @@ -1991,6 +2006,7 @@ void viper_state::viper_map(address_map &map) map(0x80000000, 0x800fffff).m(*this, FUNC(viper_state::mpc8240_soc_map)); map(0x82000000, 0x83ffffff).rw(FUNC(viper_state::voodoo3_r), FUNC(viper_state::voodoo3_w)); map(0x84000000, 0x85ffffff).rw(FUNC(viper_state::voodoo3_lfb_r), FUNC(viper_state::voodoo3_lfb_w)); + // I/O space, Voodoo 3 sets 0x00800001 as BAR2 map(0xfe800000, 0xfe8000ff).rw(FUNC(viper_state::voodoo3_io_r), FUNC(viper_state::voodoo3_io_w)); map(0xfec00000, 0xfedfffff).rw(FUNC(viper_state::pci_config_addr_r), FUNC(viper_state::pci_config_addr_w)); map(0xfee00000, 0xfeefffff).rw(FUNC(viper_state::pci_config_data_r), FUNC(viper_state::pci_config_data_w)); @@ -2715,7 +2731,7 @@ void viper_state::viper(machine_config &config) ATA_INTERFACE(config, m_ata).options(ata_devices, "hdd", nullptr, true); VOODOO_3(config, m_voodoo, voodoo_3_device::NOMINAL_CLOCK); - m_voodoo->set_fbmem(8); + m_voodoo->set_fbmem(8); // TODO: should be 16, implement VMI_DATA_5 strapping pin in Voodoo core instead m_voodoo->set_screen("screen"); m_voodoo->set_cpu("maincpu"); m_voodoo->set_status_cycles(1000); // optimization to consume extra cycles when polling status diff --git a/src/mame/misc/comebaby.cpp b/src/mame/misc/comebaby.cpp index eac475f439a..a8ab69e8de2 100644 --- a/src/mame/misc/comebaby.cpp +++ b/src/mame/misc/comebaby.cpp @@ -304,8 +304,7 @@ void comebaby_state::comebaby(machine_config &config) // TODO: all untested, check clock #if ENABLE_VOODOO VOODOO_3_PCI(config, m_voodoo3, 0, m_maincpu, "screen"); // "pci:0d.0" J4D2 - m_voodoo3->set_fbmem(2); - m_voodoo3->set_tmumem(4, 4); + m_voodoo3->set_fbmem(16); m_voodoo3->set_status_cycles(1000); // TODO: fix legacy raw setup here diff --git a/src/mame/misc/xtom3d.cpp b/src/mame/misc/xtom3d.cpp index 0214c780916..425a420c2fd 100644 --- a/src/mame/misc/xtom3d.cpp +++ b/src/mame/misc/xtom3d.cpp @@ -395,8 +395,7 @@ void xtom3d_state::xtom3d(machine_config &config) #if ENABLE_VOODOO VOODOO_BANSHEE_PCI(config, m_voodoo, 0, m_maincpu, "screen"); // "pci:0d.0" J4D2 // TODO: confirm values - m_voodoo->set_fbmem(2); - m_voodoo->set_tmumem(4, 4); + m_voodoo->set_fbmem(16); m_voodoo->set_status_cycles(1000); //subdevice(PCI_AGP_ID":voodoo")->vblank_callback().set(FUNC(xtom3d_state::vblank_assert)); -- cgit v1.2.3