1. iProgramInCpp

    OP iProgramInCpp Newbie
    Newcomer

    Joined:
    Jun 29, 2018
    Messages:
    5
    Country:
    Japan
    Is there a way to enable and write to this flash?
    w(colon)(double slash)problemkaputt(dot)de(slash)gbatek(cot)htm

    Further Memory (not mapped to ARM9/ARM7 bus)
    3D Engine Polygon RAM (52KBx2)
    3D Engine Vertex RAM (72KBx2)
    Firmware (256KB) (built-in serial flash memory)
    GBA-BIOS (16KB) (not used in NDS mode)
    NDS Slot ROM (serial 8bit-bus, max 4GB with default protocol)
    NDS Slot FLASH/EEPROM/FRAM (serial 1bit-bus)
    I'm pretty confused, because I can't find any information on google. Everyone's trying to coax me into using libfat, but seeing as that doesn't work for me in my current development environment, I've decided to use this method instead, as it's more widely supported.
     
    Orangy57 likes this.
  2. -pm-

    -pm- Member
    Newcomer

    Joined:
    Feb 19, 2014
    Messages:
    30
    Country:
    Germany
    It is dependant on what type of storage is integrated into the card inserted on the nds slot (slot 1). That way it is comparable to savegame features on other cartridge based systems like the GBA. Flashcards usually emulate this using the embedded fpga, mapping it effectively to some kind of file on the inserted storage medium like a MicroSD-Card.

    The way you write on there is - as far as I am aware - the exact same you would use when writing to sram, as the interfaces are mostly identical, the only thing that differs is how the data is stored physically and how you "should" organize your data, as a "professional" developer should care about potential data corruption.
    Thats why usually homebrew developers recommend to use libfat, as it can handle at least some of the potential corruption cases for you.

    When using devkitpro, you should look into include/nds/card.h as this part of libnds handles the card interface. Even if the functions state "eeprom" in their name, they are also handling sram and flash types of storage on the card.

    If you're looking for an example, see card/eeprom/source/main.cpp in the nds-examples.

    Sorry that I can't write anything more specific there, I never used it myself and the last time I developed for the NDS was a few years ago. But at least you now have a response :)
     
    Last edited by -pm-, Aug 22, 2020
  3. iProgramInCpp

    OP iProgramInCpp Newbie
    Newcomer

    Joined:
    Jun 29, 2018
    Messages:
    5
    Country:
    Japan
    Thank you. I might take a look at error correction later, all I'm interested in is a method that works.


    What about enabling the EEPROM? When I built the example, I always got a "-1 type 0 size" EEPROM, what can I do about that?
     
    Last edited by iProgramInCpp, Aug 22, 2020
  4. -pm-

    -pm- Member
    Newcomer

    Joined:
    Feb 19, 2014
    Messages:
    30
    Country:
    Germany
    I guess thats something you should look up in your device or emulator configuration.

    How do you execute the example?
     
  5. iProgramInCpp

    OP iProgramInCpp Newbie
    Newcomer

    Joined:
    Jun 29, 2018
    Messages:
    5
    Country:
    Japan
    I am using Desmume. I'm looking for a way to enable the eeprom from the rom file
     
  6. iProgramInCpp

    OP iProgramInCpp Newbie
    Newcomer

    Joined:
    Jun 29, 2018
    Messages:
    5
    Country:
    Japan
    I think there should be a flag in the NDS ROM file that allows me to enable EEPROM support.
     
  7. -pm-

    -pm- Member
    Newcomer

    Joined:
    Feb 19, 2014
    Messages:
    30
    Country:
    Germany
    As far as I know, this is not how this works. When a "professional" developer masters a game, he/she doesn't simply send the rom to Nintendo for QA and "ship it". When the cartridge based distribution is chosen - as common on NDS - he also would order Nintendo to manufacture Cartridges of the chosen type determined in the order formular. Therefore, there would be no need for such a header flag - and as homebrew documents state, there is no such flag: https://dsibrew.org/wiki/DSi_Cartridge_Header

    Even though Nintendo uses devkits that support multiple memory types for quality assurance, this is usually communicated in advance in the Quality Assurance Request Form.

    In addition, most games seem to use the EEPROM memory type anyway, so emulators usually check the cartridge header, especially CRC32 and game code, and match it against lists of games with different memory types. Homebrew titles must therefore use an individual setting here if they neither use EEPROM or libfat.

    You might want to have a look at https://github.com/TASVideos/desmume/blob/master/desmume/src/saves.cpp and https://github.com/TASVideos/desmume/blob/master/desmume/src/slot1.cpp as those seem to handle how Desmume handle the Slot1- / Card-Interface and therefore also handles the savegame management. As how I read those lines, desmume does "not really care" about which type of storage would be behind the save interface of Slot1, as long as it can detect the cartridge as being of type 0x01, NDS_SLOT1_RETAIL_MCROM, which would contain a eeprom / flash / fram savegame storage.
    Homebrew might get loaded with different settings. As I dont have the ability to run desmume currently, I am unable to do more help than guessing based on the code. But it seems, this might be another nail in the coffin, why homebrew-developers usually recommend to use libfat, as it seems that desmume and other emulators simply assume a cartridge without any save storage used by homebrew.

    However, it seems as there is also another cartridge type, 0x02 NDS_SLOT1_RETAIL_NAND used by Wario Ware DIY, which seems to be overwritable nand-flash, which would allow the cartridge to be updates as well. It seems like this game is a very special and problematic case amongst the emulators and flashcards and therefore - as it is usually the "only" game to do so - gets specific patches, as the save mechanic is heavily woven into the game code on the ARM9.

    Desmume even had a subclass for handling this: https://github.com/masterfeizz/DeSmuME/blob/master/src/addons/slot1_retail_nand.cpp

    But I dont think this is suitable for your usecase, however it might be a noteworthy mention, as searching for "flash" in context of nds might become confusing, as both flash-roms as well as nand-flash are considered to be "flash". I guess it would be better to search for how to access the sram / eeprom, as the mechanic is nearly identical.

    For desmume, there seem to be "dev+"-Builds according to their forum, which would allow you to set a specific save type and size.
    Then, the example should be able to detect the chosen storage media.
     
    Last edited by -pm-, Aug 25, 2020
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - Nintendo, Write, flash