Hacking A theory about the Acekard RPG

[TD-Linux]

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?

 

[DavePS]

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

 

[golden]

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

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....

 

[Normmatt]

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.

 

[Electric_Wizard]

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.

 

[DavePS]

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?

 

[Deleted User]

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.

 

[TD-Linux]

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

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.

 

[leetcakes]

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

 

[golden]

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

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.

What site did you order your AK from?

 

[TD-Linux]

What site did you order your AK from?

Bamboogaming.com, and I know how long it took to ship to you

Left shanghai on the 10th. (technically shipped on the 9th)

 

[golden]

What site did you order your AK from?


Bamboogaming.com, and I know how long it took to ship to you

Left shanghai on the 10th. (technically shipped on the 9th)

Expect it by the end of this week.

Did you think their price was respectable?

 

[cracker]

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

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.

 

[TD-Linux]

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.

 

[golden]

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.

That just sounds like it will get even slower to me.

 

[gratefulbuddy]

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?

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.

 

[Jaejae]

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.