UNDFN IO Library error

[patryckpo]

I'm testing here and got this error for several games and they're showing the same code. 01007364 E3A00405 4000001F 0200A1D0

On a sidenote: This emu is only for DS and DS Lite? I'm testing on a DSi.

[Gericom]

Which games show this error? Also, it's interesting, because the address it crashes on is in my abort handler.

It should work on all systems DS, DS Lite, DSi and 3DS in DS(i) mode

[patryckpo]

All the games I tested until now unfortunately... I can list if you want though.

[Gericom]

Did you try a game such as yoshi's island or mario kart super circuit? And have you sram patched if needed?

[patryckpo]

Wait a sec, I'll try here...

[patryckpo]

Tried here, but no luck. I'll wait for now, because I can't patch those files (got no PC to test further), odd thing is all files do this same error. Anyways thanks for now.

[Gericom]

Mario Kart Super Circuit doesn't need patching. Maybe you're using a bad bios? Is the MD5 okay? Does it show the bios intro?

[patryckpo]

No BIOS. Begins loading on the red screen, with the bottom on white showing FIND and COPY, then after a while it brings a green screen overwriting the red, with the bottom in white again but showing the error. Gbaemu4ds runs fine here, even though it's an unnecessary information. MD5 is right, even gone an extra mile on getting another file but still not working. Maybe the DSi I have isn't seeing something DS Lite would...(Model TWL-001eur)

[Gericom]

Strange, you must be doing something wrong... Which card do you use

[patryckpo]

Or even it's my flashcart or something (I have another but it's an outdated version of the one I'm testing now)... Considering the BIOS doesn't boot, maybe it's my DSi that's not compatible.

[Gericom]

But you run it in ds mode, right? Then it should just work. It must be your card or something

[ghost]

Ds lite dsi and 3ds all work for me

[patryckpo]

The flashcart is one that sold on r4-sdhc.com and it's the 2.10T version (use web.archive.org to get a pic of the cart)

[ghost]

I have a r4i-sdhc I will test shortly

[Gericom]

@patryckpo You could try the read from arm9 branch (if you are not already using it).

[patryckpo]

I'm using the version on 2nd page of gbatemp thread of this project. When I get access to my PC again I'll try some more. Thanks

[ghost]

Can confirm it is an issue with the flashcard, not the system.

I'm getting a "UNDF DLDI(boyakkey ver.)" on the bottom screen with green top screen after find and copy red screens with sdhc flashcard on all devices... which sucks because my acekard runs it fine but is not compatible with the 3ds or dsi. Anyways he probably mentioned it before but here are the codes under "UNDF DLDI(boyakkey ver.)":

01007364 E3A00405 4000001F 0200A1D0

This shows up before the bios shows.

Further instructions how to read from the arm9 branch? I'm just making it from the root folder.

EDIT: oh i see it's another branch. Okay i'll try it

EDIT2: Okay tried it.

No more green screen. But no more copy or find either. Just the first thing that shows up is a red top screen, white bottom and the only thing on the bottom is "LAST DLDI(boyakkey ver.)"

Do you have any idea what's going on?

[Gericom]

LAST means it couldn't find the file (either bios.bin or runner.gba).

[ghost]

Everything is on the root of the microSD guaranteed. Same setup for both flashcards. The arm9 build just needs it at the root too right?

EDIT: Oh perhaps I'm dong something wrong with the arm9 speed build, I'm getting a LAST on the acekard too. But it can be noted for the non-arm9 speed build I did get it to work on the acekard but no the sdhc. Don't know what I'm doing wrong with the new branch though did the exact same thing

[Gericom]

The new branch works fine for me on an original r4 with wood firmware

[ghost]

Well then it was fun while it lasted. AKAIO is on the acekard, YSMENU on the sdhc.

[Gericom]

I don't understand why it wouldn't work. It's correctly using DLDI

[ghost]

Beats me. In summary:

1) Master build works on my acekard (AKAIO) 2) Master build results in green screen with "UNDF DLDI(boyakkey ver.)" after find, copy screens with following error codes on r4i-SDHC (YSMENU): 01007364 E3A00405 4000001F 0200A1D0 3) arm9 speed read build results in LAST on both acekard and r4i-sdhc 4) Results are device-independent

Maybe the error codes from the master green screen can provide info?

[Gericom]

"01007364 E3A00405 4000001F 0200A1D0" Looking at this it shouldn't even have a reason to call the undefined handler

[patryckpo]

Wow, so I have to get an Acekard... no worries, hope you can fix it, when you need to, you can close this issue as it is per-device bug (good to know acekard runs fine). Thanks for clarification @Cruplezone On a sidenote: Gbaemu4ds shows the cart uses "DEMON IO Library", maybe this can help solve the problem.

[cotodevel]

I had the same issue with ARM9 branch. Couldnt get it to work. Anyway: I'll speak for master branch only, But if the dldi has not ARM code @ io_dldi + 8 But garbage is expected to prefetch / undefined abort to happen (invalid dldi). So to my eyes, master branch is OK. ARM9 branch will require further testing

[Gericom]

Are there dldi drivers that don't have an init function for example? That might give a problem. But for the LAST, it means that it was actually able to read from the sd, but couldn't find the file for whatever reason. Would be interesting to see why that happens. I don't think reading to vram (16 bit) is an issue, since it appearently read the boot sector correctly

[cotodevel]

I have the feeling both dldi will work just fine with any normal dldi nds homebrew, but the dldi header on r4i-SDHC is altered/scattered on purpose ("DEMON IO Library" vs "UNDF DLDI(boyakkey ver.)".

"LAST DLDI(boyakkey ver.)" is invalid since "LAST" vram part is written by one of the debug opcodes gericom had there while booting gbarunner2.

So what both @Cruplezone @patryckpo could do: run http://www.mediafire.com/file/zzi8krg0oeqkhc0/dldiextract.nds from your carts. (from the carts that prevent master branch gbarunner2 to boot). This extract your dldi to sd card.

1) You could post them here

2) download also http://www.mediafire.com/file/tcdj9w2pht9rveo/dldipatcher.zip

3) install moonshell2 (to sd), dldipatch (move your extracted dldi to dldi folder of dldipatcher)

4) run dlditool32, choose your "DEMON IO Library" dldi, I doubt the "UNDF DLDI(boyakkey ver.)" will apear. And patch moonshell2 (whatever version 2.10 will do). Also backup your r4i-SDHC sd card

5) format: FAT32, 32K cluster size your SD cards, put back all kernel stuff

6) run moonshell2, and run from there gbarunner2 (the master branch) as the steps gericom said

[ghost]

Will do give me 5 minutes

EDIT: @cotodevel so kind of confused. i dumped the dldi and got a "DSTT DLDI(boyakkey ver.).dldi", when I load this with dldi patcher what do I put as binaries? Also, got a link to the moonshel you want me to use?

[cotodevel]

1) moonshell2 2.10: download: http://www.mediafire.com/file/o2pjpxkovfwh8v3/201002161705_moonshell210stable.exe (safe .exe, its just the embedded installer) and install (connect r4i-SDHC sd card, choose drive letter)

2) dldipatcher.zip > decompress

open dldipatcher folder

open dldi folder

run dlditool32.exe, choose moonshel2 (moonshl2.nds that just got installed), dldi patch . open mshl2.nds from r4i-SDHC, run gbarunner2 master branch and see if the same happens

[ghost]

Alright thanks @cotodevel I succesfully patched moonshel2.nds. I did not patch moonshl2_Altloader or moonshl2_DirectBoot. I also did not dldi patch gbarunner2.

Booted YSMENU, ran moonshel2.nds on my cart, booted fine and ran gbarunner2, still got LAST DLDI(boyakkey ver.)

I am patching with the DLDI I dumped right?

EDIT: @cotodevel here is the dldi I patched moonshel with: http://www.mediafire.com/file/6pimbokbrkp1c5u/DSTTDLDI%28boyakkeyver.%29.dldi

EDIT2: Oh wait... silly me I was doing this with the arm9 branch hold on I will test the master branch haha.

EDIT3: @cotodevel And the final ACTUAL test results for the master branch are that it's still the green screen UNDF DLDI(boyakkey ver.) with the same green screen as before. This is with the latest bios from microsd card root version. Will test the one before this in a while but will post results when I do.

[cotodevel]

ok, thank you for the tests. Finally I have tested

97223ad (master branch) is working fine. (the last good one)

78945c3 (master branch) UNDF green screen undefined exception

DSTTi , r4igold.cc here.

[ghost]

GBARunnerBuildScript-Cruplezone.txt

There I got so sick of building it I made a script for everyone on mac/linux have fun. Will copy the bios from your desktop into the build for 97223ad only.

And yes I can confirm with @cotodevel on the SDHC card 97223ad loads the rom but 78945c3 green screens, @Gericom afraid something broke in the reading bin from the sd card commit.

Game runs and shows: DSTT DLDI(boyakkey ver.) on bottom screen.

EDIT: actually now that I have it actually running, it runs MUCH poorer on this card... a lot of lag in comparison. No moonshell needed though. Again this is a shame because the older r4 cards it does run better on do not support newer devices.

[Gericom]

Hmm, I'll have a look at it. Could you guys try fat32 with 4 kb clusers? Maybe reading 32k at once overwrites something (shouldn't).

[Gericom]

Oh, I could also try to make a sub branch that includes the bios in the rom again, but still reads from arm 9

[ghost]

@Gericom 4kb clusters sped the rom speed right on par with my other card!

[Gericom]

Nice! It's because when it needs to read one 32 bit value for example it would have to read 32 kb. There's probably some cluster size that's perfect. You could try to find the sweet spot

[Gericom]

And could you try 4 kb clusers with the arm 9 branch too?

[ghost]

Yeah no problem so far I have 1) Internal bios build runs at full speed now 2) Latest master with external bios now works (no more green screen)

Will edit in the arm9 test in a minute

EDIT: arm9 branch still red screen LASTs before find and copy. EDIT2: @Gericom I'll also note that lot's of the pink missing/error textures I used to have aren't there anymore on the master build because of the external bios loading, not the 4kb clusters (weird don't know why...)! Graphics are looking good only thing that's really needed now is to stretch the image and speed it it up a little which hopefully the arm9 branch will come through with :)

[Gericom]

The 32k clusters are giving problems with bios loading currently, because I'm copying whole clusters and the bios is 16k.

I'll have to do further research into the LAST problem

[Gericom]

I think I'm gonna make a build that dumps all names it finds to the bottom screen. So we can see what happens

[cotodevel]

I got Undefined exception when mis aligned read / writes also in gbaemu4ds. Perhaps LAST is being up ALTS or ATSL .. the offseting for halfword single load stores is picky.

[cotodevel]

I meant that for bios.bin search pattern ;) my mistake

[Gericom]

LAST is fine. It's the error code I put there. Just like UNDF. Mis aligned reads shouldn't invoke undefined exception and also shouldn't happen in my sd code anyway.

[Gericom]

What do you mean

[cotodevel]

Basically you hardcode the sector offset by 512 (fat?), But ARM byte swap halfword reads at odd offset (truncated as halfword). That is misalign and that mean exception.

[cotodevel]

Which would explain why is not finding your hardcoded filenames. Thats what I mean.

[Gericom]

I don't know if you saw I'm using READ_U16_SAFE, which can read from unaligned addresses

[cotodevel]

But I mean from reads to write to vram. Are you sure vram is not swapping your fetched sectors.

[Gericom]

I don't think so, because it was able to detect the boot sector and fat32 file system. As I said I'll make some stuff to debug this. I'm sure we'll be able to fix this

[cotodevel]

Another stuff: vram @ arm7 can do single multiple load stores 8 16 and 32 bit . Vram@ arm9 can only 16 and 32 . What if _DLDI_readSectors_ptr is storing sector data wrongfully truncating to 16 bits.