summaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
author Guru <mr-t-guru@users.noreply.github.com>2014-12-13 14:28:37 +0000
committer Guru <mr-t-guru@users.noreply.github.com>2014-12-13 14:28:37 +0000
commit334051d08553c1dfa9c846c78ba02741caccf98f (patch)
tree4442c9d23fd23ddcaea8ce768992d17b820f280d
parent4eb6fa675f78d584c50c87cac81c51bdf31cf49c (diff)
viper.c: added some notes about the 'RTC OK' check based on real PCB tests (nw)
-rw-r--r--src/mame/drivers/viper.c21
1 files changed, 21 insertions, 0 deletions
diff --git a/src/mame/drivers/viper.c b/src/mame/drivers/viper.c
index 1fbe2602948..3ee35cda61a 100644
--- a/src/mame/drivers/viper.c
+++ b/src/mame/drivers/viper.c
@@ -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
(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.
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?)