Thanks!
Do you feel it is dumping a bit more stable, since there was several successfully. Or more looks like random?
--------------------- MERGED ---------------------------
BTW, have you made EmuNAND dump/restore cycle somehow?
UPD: according to CID you have Sandisk 64GB card, is this right?
Last edited by duke_srg,
It's random I think. I mean, the first couple of builds I tested yesterday, One failed on the third dump, the other failed on the fifth. The last 2 builds I tested when I was trying to get the CID and CSD, they both crashed on the first time. It does work sometimes though opposed to not working at all. That's an improvement I suppose
Yes, I did it once (using d9).. It was part of installing a9lh, to back up emunand, then downgrade it, then restore the image.
And yes, sandisk 64GB
So we could say the last commits with card detect pullup fix is definitely stable since before that u derrun occurs always at half NAND dump?
The o Lynn difference in CSD comparing with my one is the size and higher read/write current requirement of yours. And don't forget my one is not UFS so runs at 50 MHz max. And SDXC have different FAT access and block size optimizations. Currently FAT32 and 32k cluster is out of specs for SDXC but this should only affect performance.
I have freed my micro SDXC 64G C10/U1 card, so will transfer data to it and test tonight, maybe this is an SDXC issue only.
As for dump/restore EmuNAND, I meant have you done this recently just to ensure the data area of the EmuNAND is updated and there is no unstable sectors.
I recommend to do so, it should not fail in case of a working card and if card is dyiing you won't be surprised suddenlyif it fails in future.
The o Lynn difference in CSD comparing with my one is the size and higher read/write current requirement of yours. And don't forget my one is not UFS so runs at 50 MHz max. And SDXC have different FAT access and block size optimizations. Currently FAT32 and 32k cluster is out of specs for SDXC but this should only affect performance.
I have freed my micro SDXC 64G C10/U1 card, so will transfer data to it and test tonight, maybe this is an SDXC issue only.
As for dump/restore EmuNAND, I meant have you done this recently just to ensure the data area of the EmuNAND is updated and there is no unstable sectors.
I recommend to do so, it should not fail in case of a working card and if card is dyiing you won't be surprised suddenlyif it fails in future.
Well, stable means it works everytime, but this isn't the case.. So I'm not sure about the stable definition here. I can only say that it has improved lol
Not as far as I remember. However, I installed a9lh about 11 months ago. 3 months after that, I was bricked due to a stupid user error, which is fixed now. Them I was away for around for 4 months with my main 3ds while this one was at home. I only came back last month, and haven't touched this 3ds for anything except for these testing.
So with the exception of the 3 months after a9lh installation (which required emunand back up and restore) I haven't touched the 3ds
Transferred to 64GB microSDXC, restored EmuNAND and dumped 5 times - no issues.
So I recommend you to refresh emunand by dump/restore cycle with any way you prefere - D9 or emunandtool.
Yes, just backup/ restore emunand and try to dump once more.
At least we have a safe guard now, since in the default libriary which all is using all sdcard errors are just ignored
Well, I just dumped emunand and restored it with D9.. Then tried to dump emunand with rxTools, and it crashed with the diagnostic msg again..Yes, just backup/ restore emunand and try to dump once more.
At least we have a safe guard now, since in the default libriary which all is using all sdcard errors are just ignored
It's worth noting that since the msg was added (after the issue of the error not appearing was fixed) it has been failing from the first try everytime.
Whether that's a coincidence or not, I don't know..
Well, I just dumped emunand and restored it with D9.. Then tried to dump emunand with rxTools, and it crashed with the diagnostic msg again..
It's worth noting that since the msg was added (after the issue of the error not appearing was fixed) it has been failing from the first try everytime.
Whether that's a coincidence or not, I don't know..
Nope, there was nothin added besides the actual text message. The only thing to play with is dblerror, on which depends how many retries will be handled before error reported.
I am trying the latest build on my main 3ds. Like I said, I didn't want to touch this 3ds, but a dump wouldn't hurt.
4 dumps so far, no errors. Fast as well. Didn't time the first run, 4.24 minutes on the second run, 4.23 on the third run, 4.22 on the fourth run
This 3ds is o3ds (Zelda ocarina of time edition) using the samsung Evo card (64gb), while the 3ds I have been using was o3ds XL (red super smash one) with the sandisk (64gb)
Edit: just to add some info on the past stuff we discussed:
- pasta mode also doesn't work here
- with the initial set up, It decrypted firmware in first boot, and extracted font on second boot, just like my other 3ds. So both of my 3ds's are doing that
Last edited by Madridi,
So don't touch Sandisk card until we didn't make a workaround to handle the issue
Pasta mode is a weird thing, anyway will be fixed as soon as we got someone who is ready to tuch CFW subsystem. We'll have a customized patching and pasta mode is just a sigchecked sysnand.
Can you check one time with only decrypted firmware removed and only font file removed. You will see the progress bar changes differently and identify it on clean install.
Or just make a of clean install, I just can't imagine how the progress could be reversed
Sadly my tests will still have to continue on this sandisk card. Like I said, I didn't want to touch the other 3dsSo don't touch Sandisk card until we didn't make a workaround to handle the issue
Pasta mode is a weird thing, anyway will be fixed as soon as we got someone who is ready to tuch CFW subsystem. We'll have a customized patching and pasta mode is just a sigchecked sysnand.
Can you check one time with only decrypted firmware removed and only font file removed. You will see the progress bar changes differently and identify it on clean install.
Or just make a of clean install, I just can't imagine how the progress could be reversed
Got it about pasta mode. We'll leave this until cfw part is sorted out.
I'm confused about the last part, remove what and keep what? And what do you mean by a clean install? Isn't what I'm doing everytime a clean install?
No!
1st try: remove font but keep firmware, on boot you'll see a progress of font extraction
2nd try: remove decrypted firmware files but keep font file, on boot you'll see a progress of firmware extraction (with caption and percents)
Notice the steps and speed, that's the only way for now to sence the difference between those two processes.
It happened exactly like expected
1st try: extracted firmware, like it always does for me, since it always decrypts firm for me on first boot and extracts font on second boot
2nd try: since font exists, I saw the firm decryption with font and everything.
---
So the test behaved exactly as expected. The only thing is that when data folder completely does not exist, it decrypts firm on first boot (with just a progress bar) and font on second boot
But in both cases opened menu after progress bar?Oops, yes I meant extracted font.
So in case /data don't exist you don't see font extraction, only firmware extraction (with no caption and percentage but definitely firmware with 3 slow steps) and then an empty menu (if press any key on full progress, since message not shown with no font).
And on second boot only font extraction with normal menu boot?
And you did not try to boot witn /data/settings.json existed by with no font and decrypted firmware, don't you?
Similar threads
-
-
-
-
@
Psionic Roshambo:
But other than PC and Amiga ports I don't think Time Soldiers had any game system ports after the Master System -
-
-
@
Psionic Roshambo:
Ohhh just noticed that myself I bet it makes the Master System port look amazing by comparison lol
-
-
-
-
-
-
-
-
-
-
-
@
SylverReZ:
If you want a good system to port it to, at least have a good programmer and knowledge.+1
-
-
-
-
@
Psionic Roshambo:
I didn't know they made an MSU cart for the Genesis.... I knew about the SNES one and the library for that is rather large but the Genesis one has very few games+1
-
-
-