Neo Geo Pocket Cartridge Protection Information Database

You guys are great! You really make this NGPC homebrew community work.

After my last post explaining some technical details about NeoGeo Pocket SaveGame Backups, we got a little dialog going. Loïc chimed in with a proposal to build a database of information about known cartridges. The idea is that, when the information would not be retrievable from the cartridge, a database lookup could supply the necessary information about the cartridge.

Well, not only was this a good idea, but Loïc took it several steps further. He effectively built a database of NGPC cartridge identification and protection information. He was able to obtain information about almost every cartridge. From his data, it seems that he’s only missing data on 12 cartridges. Of these 12, some can be inferred from other data or dumped by someone else.

At the moment, I’m working on other things, but I need to come up with the best way to store and parse this data. Then it can be integrated into future builds of NeoLinkmasta.

If you are interested in working on adding this (or any other feature) to the software, please get in touch with me.

Thanks guys!

35 comments on “Neo Geo Pocket Cartridge Protection Information Database”

  1. Morden Reply

    Nice work! If this was implemented, would each cartridge be recognized correctly, and all saves would work properly when flashed back onto the cartridge? Also, would this in any way fix the Cotton save problem, or is that completely on the game software side and required a ROM fix?

    • Flavor Reply

      That’s the idea. When checking the protection info of a cart, it could then be compared to the database. If there was a mismatch, the software would know that it was probably a flash cartridge. Then it could use the database info to properly handle savegame data (instead of relying on the protection info from the cartridge).

      I don’t think this has anything to do with Cotton. I think that will need a ROM patch. There’s something about that game that does something different than the others.

      • loïc Reply

        does it means that cotton have savegame issue on a flashcard, and is ok on an original cartridge ?

        • Flavor Reply

          Yes, I think so. My guess is that somehow Cotton tries to read protection info, but I have not been able to track that down anywhere.

          • loïc

            So the game have some kind of test that makes him skip the flash write function ?

            I don’t really know how to disassemble stuff, but with neopop, I can see that save function depend on fixed address :

            DIS 2D83F4: LD RW3, 0x08 “C7 31 03 08”
            DIS 2D83F8: LD RA3, 0 “C7 30 A8”
            DIS 2D83FB: LD RB3, 0x11 “C7 35 03 11”
            DIS 2D83FF: LD (0x6F), 0x4E “08 6F 4E”
            DIS 2D8402: SWI 1 “F9” # erase block 17 (0x0FA000)
            DIS 2D8403: LD A,RA3 “C7 30 89”
            DIS 2D8406: CP A,0 “C9 D8”
            DIS 2D8408: RET NZ “B0 FE”
            DIS 2D840A: LD RW3,6 “C7 31 AE”
            DIS 2D840D: LD RA3,0 “C7 30 AS”
            DIS 2D8410: LD RBC3,1 “D7 34 A9”
            DIS 2D8413: LD XHL3,0x00004724 “E7 30 03 24 47 00 00”
            DIS 2D841A: LD XDE3,0x000FA000 “E7 38 03 00 A0 0F 00”
            DIS 2D8421: LD (0x6F),0x4E “08 6F 4E”
            DIS 2D8424: SWI 1 “F9” # write data at 0x0FA000
            DIS 2D8425: LD A,RA3 “C7 30 89”
            DIS 2D8428: RET “0E”

            this function seems to be called from 3 points in the rom :
            0x2D86FA
            0x2D8A0F
            0x2E7205 => at least when the games saves high-score

        • Flavor Reply

          Great data once again, loïc.

          Let’s decode this a bit more.

          First it is doing system call 0x08 to erase the memory at 0xFA0000-0xFBFFFF. From my data, this should be unprotected. It then checks the return code of that erase to see if it completed properly. This is the only place in your ASM dump that would return prematurely, and I assume it is where it fails, but let’s look further.

          The system call to erase a flash sector will send the commands to flash and then poll the flash until the operation is complete. There are a few ways this can fail.
          1) The system detect that there isn’t a chip at the requested location (unlikely).
          2) While polling, it runs out of time. It will only poll it 0x200000 times and then give up.
          3) While polling, the flash memory returns an error.

          I’ll look at the flash writing one in a bit, but I think it’ll be very similar. I don’t know why it would be failing.

          Is there anything before these calls at 0x2D86FA, 0x2D8A0F, and 0x2E7205 that might be checking flash mem?

          • loïc

            well, no, the code before 0x2E7205 is a loop until player input the “A” button, then test a value in ram to know if you need to call 0x02D83F4.

            I’ll try to skip that test and see what’s going on.

          • loïc

            well, with nop instead of ret nz, it’s the same.
            With bung card, when I change life number, after ‘saving’ life is set to 1 (either with nops or ret nz), so something is writen… I’ll try to search a bit more later, but that’s my first time playing at disassembly

        • Flavor Reply

          [the code before 0x2E7205 is a loop until player input the “A” button, then test a value in ram to know if you need to call 0x02D83F4.]

          What RAM value are they testing? What’s the address? Maybe it’s a system value (or maybe Cotton-specific).

          • loïc

            no, the address is in the range of ram data (4000+ if I remember), not a system value.
            But I’ve tested with neo geo cup 98, and savegame fails (not the same way).
            So… (need more testing), maybe it’s because of the under 16mbits cartridge structure.
            16mbits and 32mbits have the same layout, but 8 and 4 are different.
            Block 17 is only 2000 bytes on 8mbits cartridge, and 10000 bytes on 16/32mbits
            can it be the source of problem ? ie any under 16mbits game that saves data in a block under 10000 byte will fail ?

            maybe I’m wrong, but I’ll test a bit later with that. Tell me what’s your opinion on the subject.

            I could also try to change coton to a 16mbits cartridge, and relocate savegame… don’t know how hard it can be :-/

        • Flavor Reply

          You are on a good track with this idea of the block structure.

          I think we could easily test this by hacking the code you pasted above to clear a different block.

          What can happen is that it clears block 17, but that block isn’t quite the same spot as it would be for a 16mbit chip. Interesting. Yeah, this is hackable. Let me think a moment.

          As a quick hack, though, it could be changed to block 15 (instead of 17). This could cause other problems, but let me think.

        • Flavor Reply

          Okay, how about this.

          Change the 00A00F00 that appears at byte 0xD841D to 00A01F00.
          Also change the C7350311 that appears at byte 0xD83FB to C7350321.

          I think that’s the fix, but let me know. Thanks, loïc.

        • Flavor Reply

          You probably also need to change the 08A00F00 that’s at byte 0x131AC to 08A01F00.

          • Flavor

            Yeah, there’s a 00A02F00 at 0xD83D7 that (I think) needs to be 00A03F00.

            What’s worse is that I typed some stuff wrong too. I see it now. So, here’s the list. They may not all be necessary. They may not be everything, but I don’t see others at the moment.

            Change the C7350311 at addr 0xD83FB to C7350321.
            Change the 00A00F00 at addr 0xD841D to 00A01F00.
            Change the 00A02F00 at addr 0xD83D7 to 00A03F00.

            Change the 08A00F00 at addr 0x131AC to 08A01F00. [I am not sure about this one]

  2. Morden Reply

    Does the Bung cartridge fail the exact same way, and is there a way to correct this within the flash cartridge, so that there’s no need to hack every single title with displays this particular problem?

    • Flavor Reply

      Well, let’s make sure this hack/patch technique actually works properly. Then maybe I could come up with a fix. One option might be to automatically patch a ROM while writing it to the cart.

      I haven’t come up with a good way to do this in the cart, yet.

      The Bung cart actually has another odd issue with erasing that I found when I made the multirom menu thing. Anyway, I can’t type right now. I gotta run.

    • loïc Reply

      Sorry for the delayed reply.

      @morden : bung fails the same, I do my tests on them as I don’t own Flavor’s flash unit ^^
      I don’t know about actual flashmasta, but cartridge must have a programmable controller to overcome this issue, having a dedicated chips that emulate the block layout for 4/8mbits games, making them more complex I suppose.

      @flavor : I’ll try to take a look at your changes. relocating savegame seems tricky… easy for the saving part, but harder regarding the retrieving data process because the code can do direct readings on the flash, so it requires a full disassembled code to search for address within save range. And some addresses could be computed in ram, mostly base + computed offet :-/

      • Flavor Reply

        I agree that this isn’t a fix for each case. However, I think that the save info in Cotton is very limited. I think the hacks mentioned may be all there is. I think maybe there is one place that saves and one that restores. I did a quick test on NeoPop, and it seemed to work, but it would definitely need testing.

        Also, it kinda breaks our idea how to handle savegames by using the dumped protection info. 🙂

        • loïc Reply

          I think the savagame handling is still relevant, at least for 16/32mbits games (42/105).
          Do you think it’s possible to add 4/8mbits handling to the flashmasta cartridge ? (it certainly is, but is it worth the pain ?)

          • Flavor

            Keep in mind that this isn’t a problem for all 4/8mbit games. It’s only a problem for those ones that save to the boot block area.

            To make the Flash Masta cart handle this, there would need to be some way to somehow write to the CPLD. Either that or there could be a physical switch that you could toggle based on cart size. Neither of these options is that great/realistic, really.

            I’ll think on this a bit more.

  3. Morden Reply

    A lot of GameBoy Advance clients would patch ROM images to save correctly when flashing them onto a cartridge. That would work, and the database would ensure that each ROM requiring a patch is recognized and patched correctly.

    This would fix games that won’t save at all, but what about save import / export and swapping them between original games and those on the Flashmasta? At the moment, restoring saves to games on Flashmasta isn’t really working, but with the fixes you guys are talking about here, would it be possible to, for example, dump a save from a legit copy of Cotton, upload it to Flashmasta and have the game working, saving further progress, etc.? And could that progress be later dumped and transferred to the original game without any glitches?

    That’s a lot of questions, but there’s so much I’d like the client software and the cartridge to be capable of doing, and as a user, I’d like everything to work perfectly. Haha.

    • loïc Reply

      I’ve modified my Cotton dump
      (nearly the same as yours :
      Change the C7350311 at addr 0xD83FB to C7350321.
      Change the 00A00F00 at addr 0xD841D to 00A01F00.
      Change the 00A02F00 at addr 0xD83D7 to 00A03F00.
      Change the 08A00F00 at addr 0x131AC to 08A01F00.
      )

      First, I did nothing more and flashed… and it failed.
      I guess there’s a memory test after writing, so I created a 16mbits image by copying twice the patched rom and now I’m able to play Cotton with savegame.

      I’ve finished the game with emu (dragon boss is tough, last one is too easy), it seems ok (graphical glitches in the last cut scene, but maybe the same with original rom)
      I think morden would be interested in the rom, but I don’t know if I need to create an ips patch + copy /b patched_rom + patched_rom new_rom_with_save_enable

      • Flavor Reply

        Oh, that 0xD841D change was probably just an accident on my part. I’ll edit mine above.

        When I tested it on NeoPop, instead of making a copy of the game twice, I just filled the second 0x100000 bytes with 0xFF. Though, I would have thought that it would do the same thing. Odd.

        One interesting thing is that, on some Bung carts, the flash chip they used has a sector erase and a block erase. I think they consider a block to be 0x100 bytes (IIRC offhand). The command for erasing a block on that chip is the same as the command for erasing a sector on official carts. I’m surprised that this hasn’t caused more problems on those carts.

  4. Morden Reply

    If you could upload an IPS patch that would fix the “widely available” ROM image [CRC B8A12409], I’d be happy to try it. I don’t remember any glitches, but completing the game doesn’t take that long, so I could check both versions, the patched one, and the original.

    Too bad the save issue wasn’t fixed in the Capital release. There is a +4 trainer for this game, and they must have noticed the save error if they played it on the Bung cartridge. Oh well.

    • loïc Reply

      I’ve created 2 ips :
      one for Japanese rom with CRC B8A12409
      one for EU rom with CRC 1BF412F5

      Let me know if you find issue. I’ll upload that on the forum if Ed don’t mind.

  5. loïc Reply

    here’s a list of game that must have broken savegame with flash cartridge :

    B.M.Unitron1
    BM2000
    COOLBOARDERS
    COTTON-NGP-C
    CRUSH ROLLER
    HANAFUDA DJ
    InfinityCure
    KOIKOIMARJAN
    MELON
    MEMORIES OFF
    Mahjong K2
    N.C.M.color
    N.Mystery B.
    NGC98+COLOR
    NGP BBall
    NGP YAKYUU
    NIGE-RONPA
    NeoGeo Cup98
    PACMAN
    PTennisColor
    PUYOPUYO2
    PUZZLE LINK2
    PocketTennis
    SHANGHAIMINI
    TSUNAGETE P2
    party mail
    shogi color
    shogi

    Other games can have problems too, as some of them uses 0xF0000 for saving, but have block 0x0F8000 and 0x0FA000 protected. So saving will erase data of these 2 “protected” blocks

  6. Dawn Reply

    I just saw something about this on television. It talked the same things you wrote about.

    I go to school in Canada and we just now are learning about this in our class.
    Thank you for helping me with the last little
    bit of my report.
    Thanks for the outline of tv stuff.
    I definitely think that cable tv is going to go away.
    Or at a minimum have to change with the times.
    Online tv is definitely the wave of the future.
    As internet speeds get quicker, everyone will be watching their tv shows on sites
    like this.
    What do you know about this? I think there’s a lot more to the subject
    I was just watching this on television this week.
    They spoke the same things you wrote about.

    My site :: tv free (Dawn)

  7. Dewitt Reply

    Im glad i check this out. I was actually concerned with accomplishing this very same thing within my home.
    It doesn’t seem which bad right now.

    my web site: Furnace Maintenance (Dewitt)

Leave a Reply to Flavor Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.