So much personal problems since 2 weeks ago sorry@ Billy Acuna How's Lima3DS coming along, any new developments? Look forward to hearing back from you [emoji3]
Sent from my iPhone using Tapatalk
So much personal problems since 2 weeks ago sorry@ Billy Acuna How's Lima3DS coming along, any new developments? Look forward to hearing back from you [emoji3]
Sent from my iPhone using Tapatalk
I'm very sorry for what you are going through, hoping for the best [emoji1317] Personal things should definitely be first priority.So much personal problems since 2 weeks ago sorry
Shall I use the current prealpha (4) or wait for a potential future beta version who might functions correctly with DS cartridges? (I would like to change my RxT while keeping most of its non-CFW functions)Actually I didn't touch entry points and CFW at all. Only menu system and actual tools was refactored. Literally only code in /rxtools subfolder was changed.
BTW, current rxTools fork is less hardcoded than any existing 3DS CFW. 3DS file formats, NAND format, SD boot sectors - all has been moved to structures from the hardcoded values.
You can try to use current version because there is no plans for beta in mean time since I currently have no time for developmentShall I use the current prealpha (4) or wait for a potential future beta version who might functions correctly with DS cartridges? (I would like to change my RxT while keeping most of its non-CFW functions)
Yeah I was talking about interest from the community, not the devs. Clearly everyone is only supporting what they are supporting. I hope that doesn't remain to be the caseFor now it's not an interest but just idle talks. It's clear that many, if not the most, of the people wants to have a nice looking swiss-army-knife tool, but as a matter of fact almost none of them are able to contribute.
Interest will grow as soon as AL9H support will be added and I'm not capable of doing that.
This is a branch of rxTools Ver. 3 and I'm not sure it was ever working.+1, here's the branch with arm9loaderhax support.
Yeah that's true. It was implemented after the decision to get rid of the tools. I did not move to rxtools v3 because of that.This is a branch of rxTools Ver. 3 and I'm not sure it was ever working.
My branch was forked from the very last commit of version 2, just before the 'tools' were ripped out.
If someone have balls to check that branch at least can boot, I could reverse commits and add to my fork.
Yeah that's true. It was implemented after the decision to get rid of the tools. I did not move to rxtools v3 because of that.
While I can't test atm, I can only pass on the information that was available at the time: it does work, but the initial installation didn't work through a9lh. Had to be done first through mset/spider, etc..
Edit: also, why would you reverse commits? I don't get what you mean by that.
I won't claim to know much about addresses, but from what I understand, the correct addresses in the payload for a9lh is 0x12000 .. Not sure if that helps in anyway but I'm sure people can weigh in.I just meant to take only the a9lh changes from that branch to give this one a bump.
Just looked into that commit, it looks like entry point is altered for use with a9lh but not the actual entry point address address, NAND mount seems to be broken (since unsuccessfull mount continues boot process, unlike in older versions).
Anyway to test either version we need a tested since I don't have a9lh enabled unit or desire to make a hardmod atm.
The good news is that devkitPro bundle has been recently updated, so master fork could be updated with the new libctru and other depenedencies.
It is the payload offset, I'm talking about the start address, check the mentioned commit commentI won't claim to know much about addresses, but from what I understand, the correct addresses in the payload for a9lh is 0x12000 .. Not sure if that helps in anyway but I'm sure people can weigh in.
In any case, I would be able to test anything you might decide to implement. I am just not able to test the older a9lh implementation atm.
What I meant by my comment is that the a9lh implemented in the main rxTools right now uses different files than the original branch, and I didn't replace that as I use an older version (the beta from 15th October I believe) where everything at the time worked. I was never interested in the tools stripped out version.It is the payload offset, I'm talking about the start address, check the mentioned commit comment
I didn't track a9lh changes, whats the different implementations?
If you have a working a9lh-enabled unit and also able to launch rxTools, that is enough to test.What I meant by my comment is that the a9lh implemented in the main rxTools right now uses different files than the original branch, and I didn't replace that as I use an older version (the beta from 15th October I believe) where everything at the time worked. I was never interested in the tools stripped out version.
Sure, I'll try that in a while, though I'm surely going have some problems with it due to missing firms or something. I don't remember what it requires anymore. I'll report my findings hereIf you have a working a9lh-enabled unit and also able to launch rxTools, that is enough to test.
Older rxTools version can be easily backed up and restored with just folder renaming.