QUOTE said:
AceKard isn't 100% compatible: Download Play fails on many games.
CronoTrig: that will likely be corrected when they figure out what it is in their OS that is leaving bad data in the DS memory after it exits.
Alot of people don't seem to get this:
FAT/FAT32 have access time overhead BECAUSE of possible fragmentation. Most file systems are
made that way because the OS's that use it frequently write and rewrite files that change size (cost of speed is less than seeking large enough blocks to contain and move an entire file to when it outgrows it's current allocation).
DS carts don't write at all - meaning the entire file system
never changes (thus fast seek times because the data is always where it is supposed to be - at an offset wrather than a block addressed by a FAT table). Putting a DS file system on a FAT device adds a second file system overhead which has to be accounted for with delays (processor time and seek time), and additional patching if the program running expects the data faster.
As with GBA games, the data needs to be stored sequentially to be accessed as it if was native to the device (meaning: no time lost seeking fragments). To do this, there are 2 options: use a flash chip and store the data sequentially, with no fragmentation, or, use RAM to copy the data to before using it, so it is available sequentially like the device expects it to be.
What AceKard apparently does: uses the SD card as if it was the flash chip in a flash cart. It stores the data sequentially with no fragmentation so that the AceKard, when doing it's hardware based address translation, does not have to recalculate for every fragmented block, and does not need an excessively large controller with a higher power draw to do those microsecond consuming seeks (that would crash many games without patching) and feed the correct data to the DS. The price of this is having to manage consecutive free space.
What this means to the end user: higher compatibility of essentially a flash cart, on a removable/replaceable/upgradeable memory storage device (with much higher write speeds than most types of other flash chips that Chinese manufacturers would use on such a device). All without buying a flash cart per game, without worrying about onboard flash chips failing, with far better non-manufacture supported compatibility (ie: dont need to update because xx game isnt working today) and without having to buy a whole new flash cart when you want to upgrade the amount of memory there is.
That said, I always ask this question of software that handles flash chips on a page level: how does it account for bad blocks? If my F2A gets a bad block near the beginning, the whole thing is pretty much unusable.
I think AK is a great idea, and just like SC, M3 or G6 the initial menu software is going to have it's flaws. The fact is, you say the software is buggy - but it has damn high compatibility already considering the bugs (and lack of features; like English in the Chinese version).
