Game Name

Notes from Guru:

1. Mr Driller 2 uses normal flash ROM / mask ROM which is why the dumps are good. Most EPROM programmer
   manufacturers don't support NAND ROMs correctly even if they say they do. That is why there are
   several incorrect NAND-based game dumps. These early NAND ROMs are highly unstable and susceptible
   to rot and/or degradation of the data. The System 10 boards need to be secured and dumped ASAP!


2. Why are the dumps bad?
   NANDs have bad blocks but most EPROM programmers expect people to want only the good data so they
   skip those by default but that screws up the dump because Namco knows about the bad block table
   and jumps to the good block via a block location table at the start of the ROM. If the bad blocks
   are not in the dump the good data is in the wrong place so the bad block holes need to be there in
   the dump. The program knows where the bad blocks are and will skip them. If you dump NAND ROMs
   always do a full dump of all 1024 blocks, sometimes called 'Hard Copy' or 'Treat All Blocks' or
   'Full Address Read' and also dump the spare area too. For one dump that had damaged ROMs that most
   likely happened because that person didn't have the correct equipment and enough knowledge and
   experience to handle the fragile TSOP48 NAND ROMs. Pay particular attention to the second paragraph
   listed above the game listing. If you have never done it before don't try to play russian routlette
   with your board because you will not be successful and you will most likely break it beyond any
   kind of possibility of a repair. You've been warned.


3. The list of working EPROM programmers that have been verified(*) to correctly dump the Samsung
   K9F2808U0x NAND ROMs are.....  (*) verified means it boots IN MAME
       - Xeltec SuperPro 3000U (Guru has this). NAND settings are UBA start block: 0000, RBA start
         block: 0400, Boot start block: 0000, Size of UBA blocks: 0400, Size of RBA blocks: 0000,
         Size of boot blocks: 0001, Spare Area (ECC): Used, Bad Block Handling Mode: Hard Copy,
         Boot Check Assert: Enabled. For K9F5608 replace 0400 with 0800.
       - TL866iiPlus (TeamEurope dumped unks10md with it and WindyFairy says the dump looks fine)
       - Beeprog2C (user size area 1024 and select Treat All Blocks so the whole chip is dumped
         including bad blocks and full spare area)
       - Hilo ALL-100 with special NAND Module (Guru has this)
       - EETools Topmax II (Guru has this). Algorithm: Physical Address Read, Start Block 0, End
         Block 1023. Spare Area: User Data. Works with correct NAND settings. Default settings don't
         even read the chip, just get a message 'Too Many Bad Blocks' then stops.


4. Some games that require a CDROM show boot-up color bars, FOR USE IN JAPAN message then a black
   screen if the CDROM is not hooked up and working. Currently only the Taiko no Tatsujin games
   are known to do this. Guru has redumped the physical CDROMs for TK2, TK4 and TK6 as MODE1_RAW
   with sub-channel data. These should be better 'archival quality' dumps.


5. There are no alternative versions with the same software revision/sticker. If you dump one of these
   games and get a different dump it means you didn't clear the factory defaults in test mode and some
   highscores are still in the NAND ROM. There is no eeprom on these boards, highscores etc and stored
   in the NAND. Before dumping go to test mode and reset to factory defaults. Additionally, due to NAND
   ROMs having bad blocks, a dump from 2 identical boards can be different. Just remember, if the game
   is listed as dumped check the version number sticker or in Test mode. Likely it will be the same as
   the existing dump listed here which means it's already dumped so just move on ;-)


6.  Games marked GREEN are done and fully working. No need to look further.




Information About Checking Dumps

WindyFairy wanted to pass along these instructions to do a first-pass check on System 10 dumps.
This is a quick python script for testing:
https://gist.github.com/987123879113/3198d88f75774b6612488c952ea0f757

An easy way to tell if a dump is likely to be good is to open the first NAND file (ROM at location 8E)
in a hex editor to look at the redirect table at the top.

Look for 0001 yyyy (where y is usually 03ff or 03fe) which means to redirect x to block y. Calculate the
absolute offset using y * 0x4200 and check data at offset.
The most common offsets are 0x1076e00 and 0x1077c00.
But you need to understand how to calculate the offsets because they won't always be 0x3ff or 0x3fe.
The table (listed below) is an example of the invalid NAND block table in the ROM and they reserve all
of the upper blocks after 0x3ec for redirected blocks.
The Point Blank 3 dump for example has a bad block 0x3ff (marked as bad from the factory from the looks
of it) so it uses 0x3fe, but if 0x3fe was also a factory marked bad block then they'd used 0x3fd, etc.
When you look at the table at the top of the ROM dump, you will see data like this....

  x    y
0001 03ff
0002 03fe
0003 03fd
0004 03fc
...

The game uses this table to build a list of table mappings internally. It will remap block x to y
(not exactly, in the game it's actually something like x+8 but you don't need to worry about that).

You calculate y * 0x4200 to get the absolute address of in the ROM dump to where the block is pointed to.
So 0x3ff * 0x4200 = 0x107be00 means that you open the ROM and go to offset 0x107be00 and check the data
there. That's the first encrypted program code block and if that's not valid data then it's almost surely
not going to boot.


You should see one of two things typically:
- A bunch of random looking bytes.
- A bunch of bytes that aren't as random and you will probably spot an above normal number of AAs in the
  data because all of the code in that section will be XOR'd with AA. You *may* see a bunch of AAs
  depending on the dump, but typically not only AAs for the very first redirect block.


What you should not see is:
- A bunch of FFs. This means you have not dumped ALL of the ROM blocks. Be sure you dump all 1024 blocks.
  EPROM programmers have settings for NAND ROMs and the defaults seen so far are less than 1024
  (in hex: 0x0400). This is the primary reason why there were so many bad dumps before. People just
  assumed the EPROM programmer was dumping it all like what would be done with a regular ROM. NAND ROMs
  are different and you need to tell the EPROM programmer to dump all the blocks including the bad blocks.
- The word "darkscript" (due to endianness it'll be shown as "adkrcsirtp"). This is a block that's
  duplicated in all of the later blocks on all of the NANDs for a game. I think it's just a way they
  dummied out blocks reserved for redirect usage, but that's speculation. I haven't been able to find a
  game that tries to use a darkscript block and it's absolutely not the program code, so if that's what
  you see when you go to the redirected block it's likely a bad dump.




Check the MAME source code for more detailed info about the format of the NAND data.....
https://github.com/mamedev/mame/blob/master/src/mame/namco/namcos10.cpp