Sprinter/mame
2
0
Fork 0
mirror of https://github.com/holub/mame synced 2025-05-18 19:49:35 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

viper.c: added some notes about the 'RTC OK' check based on real PCB tests (nw)

Browse Source
This commit is contained in:
Guru 2014-12-13 14:28:37 +00:00
parent 4eb6fa675f
commit 334051d085
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
src/mame/drivers/viper.c
View File

@ -125,6 +125,27 @@ MB81G163222-80 - Fujitsu MB81G163222-80 256k x 32-bit x 2 banks Synchronous Grap
the game will complain with error RTC BAD then reset. The data inside the RTC can not be hand created 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 (yet) so to revive the PCB the correct RTC data must be re-programmed to a new RTC and replaced
on the PCB. 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.
29F002 - Fujitsu 29F002 256k x8 EEPROM stamped '941B01' (PLCC44 @ U25). Earlier revision stamped '941A01' 29F002 - Fujitsu 29F002 256k x8 EEPROM stamped '941B01' (PLCC44 @ U25). Earlier revision stamped '941A01'
CN4/CN5 - RCA-type network connection jacks CN4/CN5 - RCA-type network connection jacks
CN7 - 80 pin connector (unused in all games?) CN7 - 80 pin connector (unused in all games?)