EZ5i Kernel 3.0 OB1 and EZ5i firmware v101

[FAST6191]

EZ5i Kernel 3.0 OB1 and EZ5i firmware v101
10th June 2010- massive changes afoot

The EZTeam have released an update aimed at the EZ5i (other lines will be updated soon- this release will still work for them though). It represents a big change in the way the EZ5i operates and should see big improvements as a result.

Spoiler: Changelog

Change log (v3.0 OB1):

Firmware
-note you need to at least be on firmware v12 prior to using this firmware update-
Current firmware is displayed in the options section of the kernel, do not try to downgrade.
For [805] users
http://filetrip.net/f6069-EZ5i-firmware-update-12.html
For [705] users
http://filetrip.net/f6173-EZ5i-firmware-update-14.html

1.New unified EZ5i firmware- 705 and 805 hardware revisions now use one firmware. EZ5i users will need to update to this to use 3.0 properly.
2.Fixed problems with DSi XL on all versions
3.Emulated ROM reads under 0x8000 at firmware level "0x8000 inhibitor"- a common flash cart detection method now blocked.
4.EZTeam member Feng rewrote DLDI to v3 and general write crc calculations now performed on card FPGA rather than on the DS CPU- massive speedup resulting on all writing related activities.
5.Improved handling of certain microSD(HC) models- issues with memory made in Taiwan should be sorted

Kernel changelog
1.Added "special mode" that disables ARM9 patching- combined with the under 0x8000 read emulation most present and possibly future AP methods will be blocked. This does disable extra functions so patches will still be necessary.
2.Special mode speed setting- highest speed 0, lowest 10. Allows users with slower memory to set a speed.
3.Rewrite to accommodate new firmware- old kernels will not work any more
4.Added multi-splash screen and splash screen animation capability
5.EZ5i now uses ez5isys.bin replacing ez5sys.bin (which will be kept/updated for older models)

EZFlash.cn thread (Chinese language)

EZFlash US forums thread

Filetrip mirror

 Discuss

 

[Mbmax]

Thanks FAST6191 for the news on GBAtemp.
My EZ5i 705 will at last work properly on my DSi XL now.

 

[9600pro]

EZ Flash team rulez!
I Update my card now.

 

[elixirdream]

Thanks FAST6191 for the news on GBAtemp.
My EZ5i 705 will at last work properly on my DSi XL now.

time to test the new cheat engine!!!

EZ5 strikes back

 

[Mbmax]

time to test the new cheat engine!!!

EZ5 strikes back

I doubt they have found the time to fix that yet. But you can test quickly. You know how to white screen the beast.

 

[elixirdream]

time to test the new cheat engine!!!

EZ5 strikes back

I doubt they have found the time to fix that yet. But you can test quickly. You know how to white screen the beast.

Awwww...
read that quite a number of them was having problem with RC16
i will test it later
thanks

 

[grindbart]

which games get fixed in the release?

 

[Mbmax]

With the x8000 inhibitor feature ? quite a lot.

They should call it x8000 terminator.

 

[grindbart]

e.g.??


i dont know about this stuff

 

[Aurora Wright]

e.g.??


i dont know about this stuff

http://gbatemp.net/index.php?showtopic=223...p;#entry2860202
If it emulates the behavior of the original carts correctly, I think that the EZ5 won't need any AP fix again

 

[FAST6191]

AP and you (the, hopefully, condensed version).

Flash carts work by allowing the DS to think an original cart is in there- that is to say when the DS sends out a normal read request the flash cart will take it, translate it into a SD read request and send it back however it needs to be sent.
Part of this protocol is that the DS can not read below offset 8000 hex in the rom image (the no$gba specs here http://nocash.emubase.de/gbatek.htm#dscartridgeprotocol have the entire scenario if you do a page search for "Get data")- flash carts would often process such a read anyway and send back what was actually there in the rom image and in doing so made them detectable to the game (which would then erase saves, go to demo mode, make the game impossible, crash or whatever AP does in a given game). This should never happen in normal use so it is now properly accounted for at firmware level in the EZ5i (indeed I am told all the old patches that targeted the read below 8000 checks have been left out of this build) and should not trouble the EZ5i ever again. While it is a big help this is not the whole AP story though so carrying on:

Another method by which AP works (and should have a bypass method, albeit requiring a trade off, as part of this update) is to detect if the binary (the code behind the game) was changed in any way. The usual method is by doing a checksum- the simplest example being add up all the data in a given area, a change in the data will change what it all adds up to. This is a combination type attack in the end as it troubles two things flash carts do

1)Saving. Generally being able to save is a good thing (indeed some roms will fail to work if they can not save) however the saves come in various types depending on the game (think RPG vs a puzzle game's high score list), developer, publisher/financier and a whole slew of other reasons that do not matter here.
Earlier models of the EZ5 had a savelist as do some newer carts that meant the save memory would be emulated- that is to say the DS would think some flash memory or EEPROM and version/size after that was actually there (this is what an FPGA is actually very good for- most people get hung up on having a fast "processor" in there) eliminating the need for save patching.
However when the R4 began the meteoric rise to become the dominant flash cart in many areas many flash cart makers chose to drop the fairly fiddly savelists (on the DS the type of save is not easily detectable from the ROM itself so it is a manual process) in favour of patching the game to just use the save memory that was on the flash cart (this is what drag and drop meant for roms).
At the time with no real AP to speak of (the early rom that got patched a few versions back on the EZ5 actually detected this by timing the save start to finish and to our knowledge was the first protected rom) this was probably the superior way if you can ignore massive saves*.
*Your cart probably uses 512 kilobytes saves where the common save size of a game is 64kbit=8 kbytes or 504 more than the ROM knows what to do with but your cart wastes anyway- only really the DSX attempted to tackle this with the use of save compression).

2) Flash cart features like cheats, soft reset and whatever other fancy extras a cart might have. They have to inject code into the rom to work and this means a change and a detection method.
On DS roms there are effectively three sources of binaries- the ARM9, ARM7 and overlays (can be for ARM7 but only ever used for ARM9 in commercial roms).
Unlike homebrew only the ARM9 is really used for the game proper (the ARM7 often handles saves and other "boring" things and is common across games- this is why the ARM7 swap works for some games that can not save on older software). "Special mode" here prevents anything that is not the game from touching the ARM9 binary which includes cheats, real time save, soft reset and all the other niceties but for losing them you should hopefully gain the ability to run a game before the AP is cracked (something we have already seen pay off for several games). A true "clean mode" can and does also prevent the ARM7 from being touched but that is a different matter for a different day.

These checks (both the checksums and below 8000) can number over a hundred (and even slow the game down making the flash cart version better when it gets cracked) and to work properly each one has to be found and bypassed.
Some AP software vendors/developers/publishers make (or did make) fairly easy/simple checks to detect (and few of them) by adding the checks in at the end just before compiling or with a tool allowing automatic onboard patching to then appear (and probably automated tools behind closed doors of the flash cart makers), I am not sure where the EZ5i stands on this one but it is one thing that some other flash cart makers/devs attempted in the past. The last few months though have surely shown this to not be effective on the latest AP- to say a few words here and once again breaking my "condensed version" promise this can include checks in overlays (code loaded usually later in the game) and checks in THUMB mode (a secondary instruction set/mode that the ARM processors used in the DS have) meaning they pretty much have to be found by hand.

There will probably be other AP methods in the future but anyone that has ever played in this world before knows it is a back and forth game.

 

[lrwr14]

after updating, The clean megaman zero collection Rom works....well the graphics aren't mess up now.

 

[shakirmoledina]

the bit of knowledge from fast was amazing though i cant say i understood 100% but well said
if i could summarize it
- React in a way the cartridge would, ie dont be smart to load things which originally shouldnt]
- Dont change the rom in a way that the DS can determine this game is not as originally given by the manufacturer

i guess thts the two methods, hopefully i am right and thanks for the amazing info... really showed me what problems emu and cart firmware makers are having

Lets hope other carts use this method quickly and possibly eliminate future troubles for cheapskates like me

 

[poipo32]

Is this update supposed to get rid of the stupid tak icon?

 

[lolzed]

Is this update supposed to get rid of the stupid tak icon?

What icon do you want?
And no it doesn't get rid of it(AFAIK)

 

[BoxShot]

Is this update supposed to get rid of the stupid tak icon?

What icon do you want?
And no it doesn't get rid of it(AFAIK)

It shouldn't get rid of it anyways. It is essential to the 1.4x bypass.
Who cares anyways? You look at the screen for only a few seconds before you launch it.

 

[Mbmax]

which games get fixed in the release?

I have updated the USA forum thread so you know what the x8000 Terminator* feature brings to EZ5i owners.

*sorry, i dreamed to call it like that. I know it's inhibitor the right word, but Terminator amused me.

 

[JackSakamoto]

I want the DSi emulation for hybrid games ! (only in EZ flash Vi,of course.)
EDIT : About tak icon,ez team use it because it's a unknow-game.
If it was New super Mario bros,Nintendo attacks the team.

 

[regnad]

About tak icon,ez team use it because it's a unknow-game.
If it was New super Mario bros,Nintendo attacks the team.

What does this even mean?

 

[Drag0nflamez]

About tak icon,ez team use it because it's a unknow-game.
If it was New super Mario bros,Nintendo attacks the team.

What does this even mean?

Well, Nintendo has lots of flashcarts to test if new firmware blocks them. Nintendo probably knows about the Tak thing, but doesn't attack them (only hint THQ). If they found out that they faked New Super Mario Bros., Nintendo would get angry because it's their game and they would be going to block every flashcart (which would harm launch-day DSi's like mine)