EZ-Flash USA Forum

Update
There was a large amount of development for both the original and SDHC DLDI drivers, as of 1.90 open beta 6 they are part of the official kernel. None the less you can grab the both here
http://dldi.drunkencoders.com/index.php?title=EZ_Flash_5_(SD_Card)

Update 3. EZ5i 3.0 rewrite sources:
Only compatible with EZ5i in firmware v101.
download/file.php?id=571

Edit by FAST6191.
This thread was split from another thread that was dealing with some issues with the microSDHC with an EZ5plus.
However the information/discussion regarding DLDI development became too important to lose to a support thread so this was made and consequently may appear slightly disjointed when reading, please bear with it though.

Background.
It is assumed you are aware of DLDI and what it does.
For those that are not just quickly it is a patch the end user (or nowadays the cart the end user has) to apply to homebrew files to allow access (read and write) to the memory card of the cart.
Prior to the release of DLDI (and with a few notable exceptions in the likes of early moonshell builds) a cart had to be added to the support library and with them often being incompatible with each other and the lack of support for newly released carts (or older homebrew that was not updated) meant it was a mess.
Today it is the de facto standard across the DS homebrew for means of cart access and is there are two libraries that most people use (others use modifications of these libraries is available and sometimes forgo cart access entirely).
These are libfat and gba_nds_fat. Both made by chishm and available here:
http://chishm.drunkencoders.com/libfat/
gba_nds_fat is an older library (precursor to libfat) but had DLDI support added to it primarily for the older applications that needed it. Developers are encouraged to use libfat instead of gba_nds_fat.

The EZ5 plus supports microSD and microSDHC and does so using two distinct DLDI (one for microSD and the other for microSDHC) files contained within the moonshl folder of the loader you place on the memory card and named accordingly.
Autopatching (as in the EZ5 does it) is available from the EZ5 and should work on almost all occasions meaning most people should simply have to copy the homebrew file (and any level data, sounds, log file, ini files......). Hard patching (as in altering the binary) is possible but should not be necessary in almost all cases.

This thread deals with issues of speed (it is relatively simple to slow the reading and writing down), issues of compatibility (for instance the need to be compiled to run on the ARM7 of the DS for homebrew such as DSVideo), issues concerning how the DLDI file operated (unaligned reading for example).
Would be developers are advised to have a working knowledge of the language C and ARM assembly (ARM7 and ARM9 as well as the THUMB aspects of the TDMI "range") for a great deal of this is coded in C and hand optimised at the assembly level.
Source code is now available for both drivers:

It is suggested you read this thread as there may be newer versions available
DLDI (microSD), see also development discussion in this thread.
http://dldi.drunkencoders.com/index.php?title=EZ_Flash_5_(SD_Card)

DLDI (micoSDHC)
http://www.ezflash.cn/zip/ez5sdhc.rar


-----------------------------------------------------------------------------------
Original post

ps2aich. Just a little question.
I have tried on my EZ5 NYE, check disk tool from moonlight (OS sakura : \SYSTEM\m3sakura\launch\Check disk for NDS Ver0.4.nds) under kernel 1.85a with ez5s.dldi that comes with it.
I have this result with read test :

平均単純リード速度(single): 0.998MB/1sec
平均複数リード速度(block): 2.716MB/1sec

Under kernel 1.41 with Check disk for NDS Ver0.4.nds patched with the same e5s.dldi from k1.85a i have the same result but with the old one from chishm website i have :

平均単純リード速度(single): 1.128MB/1sec
平均複数リード速度(block): 4.601MB/1sec

MicroSD Toshiba 2GB SD-C02G Japan, FAT 16, cluster 32kB

Any idea

Ps : write speed is the same with both dldi file. 0.103MB/1sec where cycloDS score 1.784MB/1sec
4.589MB/1sec is the score in read test for the cylcoDS.

The one from chishm's website is the original one made by cory1492, but chism's dldi site is outdated, the most current
you find on the DLDI site.
This is cory1492's one modified by me for passing unaligned read test.

So I would suggest to use this one to try again.
But without sourcecode of the new dldi driver of the 1.85, it is difficult to say anything.
Perhaps its an initialisation issue?

I also will test the newest speedtester again (it was recently improved), so we can compare our results.

So, results with current libfat speed tester, EZV, MicroSD speed set to 3, Kingston 1GB Japan
Sequential 512B avg: 180us
Sequential 4KiB avg: 1401us
Sequential 16KiB avg: 5586us
Random 512B avg: 472us
Random 4KiB avg: 1551us
Random 16KiB avg: 5741us

Edit: I can't currently access http://mdxonline.dyndns.org/archives/20 ... er04.shtml,
to verify your results.

Oh you are right the website is outdated. But did you modify the cory1492 dldi file that came from chishm site or from the cory1492 website ? because i remember something i saw when he was coding his homebrew for the 3in1 ...


Ok. I will test under kernel 1.85a and cory1492 dldi file to see if reading result are the same or not.
Also will give a try to the one you give me but i'm pretty sure it's the one that came with the last kernel ...

Edit : under kernel 1.85a with the ez5s.dldi from chishm website, i have the same result than under 1.41 (read: 4.601MB/1sec) so it's something about the dldi file that came with new kernels. I will check the crc to see if it's the same than on the link you gave me.

Edit 2: 99BCBA1F. it's the same in kernel 1.85a so no need to retry my test.
Team ez has taken your dldi file in their new kernel.

So now why this slow down with your modification ?

Not yet tested, but i will give a try, so we can compare.


yep. Moonlight seems to has taken down his website.

Ps : i'm very sorry but be pleased my english is very bad.

Hm, are you really sure? Then I am a little puzzled how they realized sdhc support, since
the old dldi driver definitely does not have sdhc support, except they had implemented
it in hardware, since according to the sd card spezification, the initialization routine is
different for sdhc cards.

Edit: I will download the 1.85a kernel and check, sorry, I'm currently an infrequent user
of my EZ-V and this forum, perhaps they deliver 2 different dldi drivers, one for normal EZ-V
and one for the EZ-Vplus with SDHC support.


I will try cory1492's original dldi with the speed tester to see if there are differences in speed.

The changes I made for unaligned read are very simple:

The original code:

The modified one:


So, the difference is, that I have added 4 single byte writes instead of one 32 bit write (which is of course faster),
but that it is that faster I will check.

Edit: The results of the speed tester with cory1492's original driver:
MicroSD speed set to 3, Kingston 1GB Japan
Sequential 512B avg: 144us
Sequential 4KiB avg: 1125us
Sequential 16KiB avg: 4486us
Random 512B avg: 402us
Random 4KiB avg: 1275us
Random 16KiB avg: 4639us

So, the old one (with failing unaligned read) is definitely faster, but only about 20% (at the 16KiB),
so it would be interesting, which blocksize moonlight uses for his chkdsk.

If it works for you, you can use the old driver, but some homebrew does not work correctly with it
(e.g.wolfenstein 3d).

According to your results, I will change the DLDI page for the EZ-5 so that both versions will be offered again.

The drivers I did originally were basically stripped and packed into DLDI format from the original source EZ shared. I have to wonder why no one has made a simple DLDI dumper based on one of the auto patchers yet...

Hi cory !


Yep i'm sure and as you can see in kernel 1.85a, the team has made a special version for the ez5Plus named ez5sdhc.dldi. I'm sorry i'm not able to do some bench with my 4GB Japan microSD HC because i don't have an EZ5 Plus.
I wonder if i rename the ez5sdhc.dldi into ez5s.dldi what will happen ...


Here are my results :
EZV NYE k1.85a, Toshiba 2GB Japan,FAT16, 32kB cluster, new ez5s.dldi (crc 99BCBA1F) :

Sequential 512B avg: 181us
Sequential 4KiB avg: 1404us
Sequential 16KiB avg: 5594us
Random 512B avg: 607us
Random 4KiB avg: 1681us
Random 16KiB avg: 5875us

with ez5s.dldi v1 (crc 3D959C81) :

Sequential 512B avg: 148us
Sequential 4KiB avg: 1127us
Sequential 16KiB avg: 4489us
Random 512B avg: 538us
Random 4KiB avg: 1403us
Random 16KiB avg: 4768us

with ez5s.dldi v2 (crc B6FB8633) :

Sequential 512B avg: 146us
Sequential 4KiB avg: 1133us
Sequential 16KiB avg: 4512us
Random 512B avg: 538us
Random 4KiB avg: 1410us
Random 16KiB avg: 4792us


Agreed, it's faster.

I have those information at work, i will post that tomorrow.

edit : here are the complet results of check disk for nds with a MicroSD Toshiba 2GB SD-C02G Japan, FAT 16, cluster 32kB






Sorry for the Japanese text but i don't know a word of this language. ^^

Hi Mbmax,

thanks for posting your results.

I hope I'll find some time to think it over next week and try to optimize the new dldi (for this
unaligned read thing), I simply didn't know that the consequences are such dramatic, since I
never did extensive speed tests before and after that change.

Perhaps it's an easy thing to detect wheater the buffer is aligned or not, and only in unaliged
cases to use the new code, otherwise the old one.

Btw, from where did you get the ez5sdhc.dldi, I haven't found it in the ez5kernel080717.zip.
It would be nice to test it against the non-plus EZ-5

You are welcome.

I was thinking the same thing. But i'm not a coder in real life, so i can't help you.

ez5sdhc.dldi is inside /moonshl directory since kernel 1.80 if my memory is good, so you might try to re-download the file because i have it inside ez5kernel080717.zip.

Just tried this file on my ez5 NYE (renamed in ez5s.dldi). As expected it doesn't work. The homebrew can't access to libFAT.

Thanks, you are right, I simply missed it..

Unaligned detect... >> 1 or >> 2, if the register gets set that you lost precision then... have to do that in asm and I'm not sure of the register (existence.) Of course there is modulo as well; I think that the resulting asm for such a detect would not be faster than just using the unaligned code straight out, and the result would further slow down the current unaligned code more.

This doesn't make sense to me:


perhaps...

or

would assemble into something faster (or I missed some of the context of your code snippet?) Some performancing should be done on some of these routines in the driver, there is some things that can be done much more efficiently if hand assembled (don't look at me, I just know it can be done, not completely how.) It'd definitely be nice to have the current ez5p DLDI source if they aren't going to bother to optimize it in this way.

Hi cory1492,

I think all your examples are much or less equivalent
is the same as , and I think also the loop will not change the speed.
The problem are the bytewise addressing itself, the former code was that did the job in one asm-command.

What I plan to do is:
1. detect if ppbuf is 4byte-aligned or not (by simply looking at the lower two bits of the address ppbuf points to)
2. dependend on (1), the old code or the new code will be used.
3. test it (with speed tester and dldi test tool)
3. Now hopefully 99% of homebrew will run faster again, and only calls with an unaligend buffer will be slower.

I simply does not know when I will have time to implement and test it, but I definitivly will do this.

The loop version assembles to about 8 commands smaller, but I agree - I doubt it will be any faster and may likely be slower looking at the asm from it. Also, adding a check in WILL slow down unaligned further and will not be as optimal as the original... besides, how the heck do you do bitwise operator on a address from a pointer? I keep getting "error: invalid operands to binary &" (as I always have when trying to analyze address values from a pointer) and I'm not seeing anything that would explain this behavior... this definitely compiled but did not work (dldi will not initialize):


There is far too much to the protocols for me to understand fully without developing hardware myself I do think the EZ dldi/driver does many things it doesn't need to, that could well be points of speed improvement.

Any rate, with EZ5p:
built in driver, 1.85a kernel (080717), my 512M kingston and the app from pineight you posted earlier
Sequential 512B avg: 179us
Sequential 4KiB avg: 1405us
Sequential 16KiB avg: 5601us
Random 512B avg: 528us
Random 4KiB avg: 1637us
Random 16KiB avg: 5812us

with my dldi (from here on noautopatch used):
Sequential 512B avg: 145us
Sequential 4KiB avg: 1129us
Sequential 16KiB avg: 4500us
Random 512B avg: 479us
Random 4KiB avg: 1359us
Random 16KiB avg: 4728us

with the source ps2aich suggests for unaligned reads:
Sequential 512B avg: 165us
Sequential 4KiB avg: 1286us
Sequential 16KiB avg: 5124us
Random 512B avg: 519us
Random 4KiB avg: 1521us
Random 16KiB avg: 5343us

with a mod to the source ps2aich suggests, using a loop instead (definitely not faster, too many slow jumps added in ):
Sequential 512B avg: 186us
Sequential 4KiB avg: 1467us
Sequential 16KiB avg: 5848us
Random 512B avg: 570us
Random 4KiB avg: 1692us
Random 16KiB avg: 6036us

Some interesting work there guys although I am not feeling like hand optimising assembly for this one (not to mention my knowledge of C is less than brilliant (read might as well be nonexistent) or I would try and muck in).

The reason when I was doing the EZ5plus review (unfortunately sans SDHC) in which I tested DSvideo, a homebrew video player (wavelet compression based) which uses the ARM7 for the purposes of the file system (the ARM9 is taken up entirely with decoding and it does not look like that will change ever).
I had to hardpatch the ARM7 DLDI file the DSvideo people provided (nothing too unexpected) but wondered if it would be possible (or indeed necessary) for the SDHC to gain an ARM7 using DLDI (I can not see any source anywhere and despite it being a fairly minor change to the makefile ( http://dsvideo.recoil.org/ 12th of Feb 2008 post) the resulting binary is sure to be quite different).

It is far from critical (my EZ4 reads it fine as does the custom non SDHC EZ5 DLDI file) and it is the only app I have ever seen do it and while it is nice it is not really suited for day to day use.

So, now the fix is done:

ez5s.zip

I've run dlditester and speed tester successfully.

Mbmax, can you please test again with the checkdisk?

When everything is fine, I will update the dldl wiki accordingly.

@cory1492
I also had problems at the beginning, there was some unnecessary code (reading into temp2).

No prob. I will give a try.
Thanks

Edit : Here we are. MicroSD Toshiba 2GB SD-C02G Japan, FAT 16, cluster 32kB


Great ! Nice job ps2aich !

Now the ez team needs to do something for the write speed because if they plan to add RTS feature to the EZ5, writing the state file could take years !
Hope the kernel don't have the same writing code ...