A theory about the Acekard RPG

Discussion in 'Acekard' started by TD-Linux, Jan 21, 2008.

Jan 21, 2008
  1. TD-Linux
    OP

    Newcomer TD-Linux Member

    Joined:
    Dec 30, 2007
    Messages:
    33
    Country:
    United States
    I got an idea about how the Acekard RPG works.

    Maybe it doesn't patch the commercial ROMs at all. It might emulate a real commercial card, and somehow have flash that it programs into one nonfragmented file. That would explain the old original Acekard RPG with its own file system - it didn't patch the games either, hence its 100% compatibility. I don't think the Acekard RPG patches games for saving either - I think it has a built-in EEPROM. This would explain why saves are only written the next time the Acekard is powered up. Fortunately, we can avoid the problem by making a ROM patcher, but as you know, these aren't always perfect. The hardware is a great fallback if necessary, and IMHO saving to EEPROM is just fine for me.

    To confirm this, does anyone have some hi-res scans of the Acekard RPG internals?
     
  2. DavePS

    Newcomer DavePS Advanced Member

    Joined:
    Aug 23, 2006
    Messages:
    82
    Location:
    East Yorkshire
    Country:
    United Kingdom
    If you have a look thru the acekard source, you will see it modifies some of the header info in games. This by definition is patching
     
  3. golden

    Member golden What a Digital Dummy!!!

    Joined:
    Dec 1, 2007
    Messages:
    1,453
    Country:
    United States
    Nice find.

    And about the AK internals, the GBATemp review is the only place I know for pix of the AK guts.
    Also, instead of acting all Sherlock Holmes detective style work, why not just ask acekard? They might tell you. Or they might not....
     
  4. Normmatt

    Member Normmatt Former AKAIO Programmer

    Joined:
    Dec 14, 2004
    Messages:
    2,135
    Country:
    New Zealand
    Actually it doesn't do any 'patching' to get roms to run the only patching the RPG does is for ARDS, soft reset and the save patching as it saves to a hidden sector of the nand so there's no reason to worry about loosing your save if you dont turn your nds back on in a hurry.
     
  5. Electric_Wizard

    Member Electric_Wizard GBAtemp Regular

    Joined:
    Feb 1, 2003
    Messages:
    172
    Location:
    Lewes
    Country:
    United Kingdom
    Golden's right, I would have thought they'd just tell you. They seem pretty keen to get people developing for their card. It wouldn't make much sense to make their firmware open source and then get all "mum's the word" about the hardware.
     
  6. DavePS

    Newcomer DavePS Advanced Member

    Joined:
    Aug 23, 2006
    Messages:
    82
    Location:
    East Yorkshire
    Country:
    United Kingdom
    Hmmm, what about the patching of the game header info where the SD speed is slower than the game expects, it then modify's the speed the game is expecting. Doesn't it also redirect IO calls to the AK's IO interfaces?
     
  7. deufeufeu

    Member deufeufeu GBAtemp Advanced Fan

    Joined:
    Nov 21, 2005
    Messages:
    880
    Country:
    Cote d'Ivoire
    Here is the process of booting a rom in the acekard, step by step from the power on

    1) the acekard rpg hardware intializes and jump to the execution of the second partition of the NAND (I think it's the second, but it might be the first). On this partition is a special loader.
    2) the loader initializes the fat system of the acekard, and it runs akmenu.nds
    3) when a rom is run, akmenu loads another version of the loader, this loader is in charge of loading the save, patching when you've asked him (softreset, ect...), then it iniatializes the special registers of the acekard to specify the address of the rom as the base of rom access.
    4) when a game access data, the acekard translates the address to the proper segment of the fat, and it sends the data of the rom.

    So a game can't tell it's run from an original cartridge or from the acekard.
    If you have more questions, ask me.
     
  8. TD-Linux
    OP

    Newcomer TD-Linux Member

    Joined:
    Dec 30, 2007
    Messages:
    33
    Country:
    United States
    Wow, deufeufeu, that is great! So my suspicions are confirmed... the Acekard maps the Flash directly into the address space of the parallel bus!

    This means two things:
    1. It should be super easy to modify the bootloader... will have to see though, I really can't tell without a card [​IMG]
    2. Games run perfect and high-speed, at least from the built in flash.

    I think the best thing for me to do right now is wait till I get my Acekard (shipping is slowww, they really need a distributor in the western hemisphere). Most of my questions can be answered with 5 minutes of access to the real thing.
     
  9. leetcakes

    Member leetcakes GBAtemp Regular

    Joined:
    Jul 29, 2007
    Messages:
    148
    Country:
    Belize
    is the long process why the acekard is way slower in booting up, booting roms, and deleting stuff? compared to DSTT, R4, and slot 2 supercards. ive personally used all of them
     
  10. golden

    Member golden What a Digital Dummy!!!

    Joined:
    Dec 1, 2007
    Messages:
    1,453
    Country:
    United States
    What site did you order your AK from?
     
  11. TD-Linux
    OP

    Newcomer TD-Linux Member

    Joined:
    Dec 30, 2007
    Messages:
    33
    Country:
    United States
    Bamboogaming.com, and I know how long it took to ship to you [​IMG]
    Left shanghai on the 10th. (technically shipped on the 9th)
     
  12. golden

    Member golden What a Digital Dummy!!!

    Joined:
    Dec 1, 2007
    Messages:
    1,453
    Country:
    United States
    Expect it by the end of this week. [​IMG]

    Did you think their price was respectable?
     
  13. cracker

    Member cracker Nyah!

    Joined:
    Aug 24, 2005
    Messages:
    3,132
    Country:
    United States
    In the loader most of the slowness is due to the fact that every time you change a directory it will scan through all the files and the ones that are DS games will be opened, the headers are read, the file is closed, the icon data in the header is copied into an array and only after all the files are gone through will it display the icons. I was thinking about editing the source and making an icon cache. It would be a little faster if it was cached in the converted array format that is the final step before displaying the icons. If it was stored in a single file then it might gain a little speed since multiple files wouldn't have to be opened and closed. The drawback would be that it wouldn't update changed icons but that's a pretty unlikely case.
     
  14. TD-Linux
    OP

    Newcomer TD-Linux Member

    Joined:
    Dec 30, 2007
    Messages:
    33
    Country:
    United States
    A better solution would be to read all the files, sort them, and display them, then go back and read the files to get the icon, etc. The sorting would be by file name and not by the actual DS name, but it's usually close enough. The order might even be cached.

    Basically, the UI has to not lock up when memory is being read.

    Also, an in-memory cache of previously visited directories would be nice.
     
  15. golden

    Member golden What a Digital Dummy!!!

    Joined:
    Dec 1, 2007
    Messages:
    1,453
    Country:
    United States
    That just sounds like it will get even slower to me. [​IMG]
     
  16. gratefulbuddy

    Member gratefulbuddy amateur lunatic

    Joined:
    Apr 4, 2007
    Messages:
    802
    Location:
    on the wheel
    Country:
    United States
    Not hi-res, but here are some pics(bottom of page): http://www.geocities.jp/acekard2ch/rpg/rpg.html. Looks like all chips and markings are plainly visible.
     
  17. Jaejae

    Member Jaejae Superfly Don't Used

    Joined:
    Sep 23, 2007
    Messages:
    625
    Location:
    Auckland, New Zealand
    Country:
    New Zealand
    No EEPROM, but a hidden section to which the games save.
    The brief loading when you boot the RPG is the loader copying the save from the hidden section to the user accessible section.
     

Share This Page