EZ-Flash USA Forum

Ah! I had tried the August 2 one, didn't notice there was another from August 6. It works perfectly with jEnesisDS, thank you very much. I'll pass this on to the jEnesisDS developer. Thank you for improving my experience with the EZ-V so much.

Yeah ! great fix ps2aich !
Tested too and no prob now.

Thanks !

So, that are good news

I will update the driver at the official dldi website this weekend then!

Then I will also fix the ez5sdhc driver accordingling...

Makes sense with the dma, it could too easily interfere with programs that already use DMA. I still have to wonder if it would be possible to temporarily appropriate a channel, though, and whether a dma card interface to slot1 would be faster.

I agree about the CRC not really being the bottleneck, though I think there is also some compromise going on in EZV regarding card speed (or perhaps frequency of the bus?) - especially since one used to be able to manually set it in older kernels. Too bad SD CRC isn't handled automatically in the fpga additionally, would have really cut down some data and calculations and likely be faster if done right (ie: ever look at the r4 dldi source?)

Do you understand the difference between sd and sdhc addressing? Did they expand the addresses or just change block size?

Ah well, with the little info you have and the mangled driver I started you have done very well for us EZ5 owners, even if the gain isn't tonnes. Thanks ps2aich

I think to remember when I browsed some dldi sources last year that there exists slot-1 flashcards that used dma in their dldi driver, but I don't know if this worked in all circumstances.


I hadn't a look. I also never compared write speeds of different cards, I only have the figure from Mbmax and the cyclods (cycloDS score 1.784MB/1sec), but never had figures from other cards. perhaps the cyclods is extremely fast and the ez-v speed is perhaps normal for most cards? I will test it with my r6gold (which has a very slow read speed currently with my january2008 batch).


That is not fully clear to me: when I look at the sdcard specification and on some example code how sdhc is detected and used, I do not found anything of this in the ez5sdhc driver. In fact, I must re-memorize and recheck this, because it was last year when I tried to understand sdhc initialization and handling. As far as I remember it was like this:
1. In initialization code, detect sd or sdhc card
2. Dependent on this, set blocksize ( in sdhc mode, it is fixed to 512 Byte, as in sd mode you can set it in the driver,
so it is done in the sd_initial code in the non-sdhc driver

In the new driver, the sd_initial code is missing, that is an indication that the ez-v team initializes the sdhc card not via the ez-v interface between nds and ez-v card, but only between ez-V card and microsd card.

I once tried last year to implement sdhc support by myself in the old driver, and failed, because the communication between nds and sdcard via the ez-v didn't allow the correct detection of the sdhc (a command to the sd card had to be issued, and that fails on non-sdhc cards, but I was unable to get the failure response via the ez-V).
So they solved it by their new design ez-v plus, and the sd_initial code was removed from the ez5sdhc driver.
That is what I guess.

Btw. regarding sdhc cards: check at your location the sandisk 4GB microsd (class 4). At my place, these cards are very cheap currently (about 12 euro or 18 usd).

Japan cards are definitively the best choice, but they are quite hard to find.
BTW, the ez5 hybrid mode is always ON now so even "slow cards" works well (like sandisk one).

The only places I have found that stock any SDHC at this point, only have chiefly overpriced SD format and not TF format. I did find a 4G sandisk TF though, at $99.99 it's no better than the other. Again, this is locally (which means it wouldn't be some weeks in customs to get here), Canada pricing seems to always be a few months behind anywhere else on this sort of product.

I paid around $30 for an 8GB SDHC a couple of months ago. It's only a class 4 AData but it works fine so far.

Thank you very much for this, ps2aich! I hope ezteam can review your improvements and use this in the official kernel.

You can get a transcend class 6 4 GB here for 12 EUR.
Also there is a new Sandisk Micro Mobile Ultra Class 6 for ca. 16 EUR.
(this sounds very promising)

I have bought an a-data for 18 EUR ... but this one has really a low access latency.

MBMax ... I do not think that japan or not matters with SDHC cards.
This was important for SD cards (<=2 GB)

Japan microSD card are made by Toshiba and are definitively the best choice for any flashcart.
Samsung oem (some kingston made in Taïwan with P/N MM8GR01GUACY, it's a 1GB size) are good too but for instance i haven't have the opportunity to test a SDHC from this manufacturer (MM8GR04GUACY).
And you are right you must buy a sandisk ultra "bidule" much more expansive to have the same RAT than a toshiba Japan one.

@cory1492 : check this link. It could be a Japan one because Toshiba only sell class 4 SDHC cards for instance. (As you know classes mean nothing inside a flashcart, but the RAT of those memory cards is great !)
Not sure about that but drop a e-mail to them.

Here are pictures of my Kingston Japan 4GB class 4 SDHC. It has very good access time and work perfectly in clean mode in a SCDS one or a clycoDS evo.



Ps : I wonder if the Kingston 8GB is not a Japan one too ...

Mbmax: I notice you regularly state that "Made in Japan" are the best choice for Flashcarts of any kind, and that the Class has little or no bearing on it's performance in such a device. I'm sure that you have dealt with many MicroSD/HC cards, so I ask this: Do you reckon that since my Class 6 card is "Made in China", this may explain why FF3, Elite Beat Agents, and Castlevania: Portrait of Ruin occasionally freeze?

It would make sense, no? I mean, other than those games, it's a smashing 8GB card, and it only cost me £22.

---

I remember DLDI a few months ago (A friend introduced me to flashcards, but didn't understand computers, so got me to DLDI-patch all their Homebrew), pratting with the command-line patchers. It's brilliant that it's all done in-kernel now, for the benefit of less technically-able users. Of course, I imagine most of us are already "competent"...
I'm impressed that you've pretty much got SDHC FAT32 to a tee now (I've had no problems with any Homebrew), so all I can say is "Good stuff, Oh those of Mad Skillz".

Thanks mbmax, shipping from them is $15.56 extra on that item (not to mention, I know for a fact it only costs $9 to ship a bigger and heavier expedited/insured/tracked item from there to here.)

Sorry to ask for more, but I'm curious as to whether there's an incompatibility between SNEmulDS and the EZ-V's DLDI patch. I've tried a number of them, right up to the latest (which fixed jEnesisDS compatibility), but there still seems to be problems with saving, but only in some games. The ones I've noticed are the Donkey Kong Country series and Mario Paint; the saves they write are simply nonsense; here's part of DKC2's save:

It goes on like that until the end of the file. Would this be a problem with the DLDI patch, or some other incompatibility with the EZ-V? I can't confirm Mario Paint, but have been told that the DKC games save fine on other flash cards. Again, sorry to keep bugging people about emulator saving.

EDIT: Actually I just did a routine format and the DKC games now save just fine. The only game which doesn't save now is Mario Paint, and that might just be the emulator, I'm not sure.

Finally found a SDHC locally for a sane price (in store $16.88CAD for taiwan 4G class 4.) HD Tach is pegging it at just over 20M/s in it's short/small test, so it seems fast enough.

To summarize the goop below, unaligned reads can be added with minimal work (just copy over ps2aich's code) and next to no speed impact to aligned reads. No big change speed wise, though I'd say writes could use some work for sure...
changes over the source uploaded by windirt:
-iotype: EZ5H (instead of EZ5S)
-identifier: "EZ Flash 5+ (SDHC Card)" (handy to have a different name for the dldi patchers to work with)
-ps2aich unaligned read code added
stable as far as I can tell, all dldi tests pass. Can be used to replace the sdhc dldi in ez5's moonshl directory.
ez5sdhc_p1.zip
LMK if you have any issue with this ps2aich, it is your code - all I really did was test that it was directly portable (and working OK as far as I can tell) into the sdhc driver.

results for current (18ob5) in-kernel auto patched in sdhc drivers:
DLDI testing tool - Unaligned read fails, Error 0.

Sequential 512B avg: 151us
Sequential 4KiB avg: 1138us
Sequential 16KiB avg: 4516us
Random 512B avg: 942us
Random 4KiB avg: 1802us
Random 16KiB avg: 5171us

untouched compile of current sdhc source (aside from chaning uint32 to unsigned int, used DKP R21):
DLDI testing tool - Unaligned read fails, Error 0.

Sequential 512B avg: 146us
Sequential 4KiB avg: 1129us
Sequential 16KiB avg: 4489us
Random 512B avg: 529us
Random 4KiB avg: 1400us
Random 16KiB avg: 4757us
slightly faster...

copied over ps2aich's changes verbatim from the code box earlier in this thread:
DLDI testing tool - all tests passed.

Sequential 512B avg: 147us
Sequential 4KiB avg: 1134us
Sequential 16KiB avg: 4502us
Random 512B avg: 531us
Random 4KiB avg: 1404us
Random 16KiB avg: 4770us

-------
chkdsk 0.4
built in drivers with 18ob5:
read:
平均単純リード速度(single): 1.680MB/1sec
平均複数リード速度(block): 4.627MB/1sec

0MByte付近 Single: 1.726MByte/秒 Block: 4.627MByte/秒
490MByte付近 Single: 1.767MByte/秒 Block: 4.628MByte/秒
980MByte付近 Single: 1.685MByte/秒 Block: 4.628MByte/秒
1470MByte付近 Single: 1.757MByte/秒 Block: 4.628MByte/秒
1960MByte付近 Single: 1.611MByte/秒 Block: 4.627MByte/秒
2450MByte付近 Single: 1.715MByte/秒 Block: 4.627MByte/秒
2940MByte付近 Single: 1.512MByte/秒 Block: 4.625MByte/秒
3430MByte付近 Single: 1.666MByte/秒 Block: 4.625MByte/秒

write:
平均単純ライト速度(single): 0.088MB/1sec
平均複数ライト速度(block): 0.099MB/1sec

0MByte付近 Single: 0.073MByte/秒 Block: 0.093MByte/秒
490MByte付近 Single: 0.073MByte/秒 Block: 0.093MByte/秒
980MByte付近 Single: 0.065MByte/秒 Block: 0.093MByte/秒
1470MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒
1960MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒
2450MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒
2940MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒
3430MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒

modified with ps2aich's code: (for this test I had to replace the .dldi file in the moonshell directory)
read:
平均単純リード速度(single): 1.677MB/1sec
平均複数リード速度(block): 4.614MB/1sec

0MByte付近 Single: 1.734MByte/秒 Block: 4.614MByte/秒
490MByte付近 Single: 1.776MByte/秒 Block: 4.616MByte/秒
980MByte付近 Single: 1.685MByte/秒 Block: 4.616MByte/秒
1470MByte付近 Single: 1.728MByte/秒 Block: 4.615MByte/秒
1960MByte付近 Single: 1.617MByte/秒 Block: 4.613MByte/秒
2450MByte付近 Single: 1.702MByte/秒 Block: 4.614MByte/秒
2940MByte付近 Single: 1.511MByte/秒 Block: 4.612MByte/秒
3430MByte付近 Single: 1.659MByte/秒 Block: 4.612MByte/秒

write:
平均単純ライト速度(single): 0.086MB/1sec
平均複数ライト速度(block): 0.099MB/1sec

0MByte付近 Single: 0.065MByte/秒 Block: 0.093MByte/秒
490MByte付近 Single: 0.065MByte/秒 Block: 0.093MByte/秒
980MByte付近 Single: 0.065MByte/秒 Block: 0.093MByte/秒
1470MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒
1960MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒
2450MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒
2940MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒
3430MByte付近 Single: 0.098MByte/秒 Block: 0.102MByte/秒