Hacking Atmosphere-NX - Custom Firmware in development by SciresM

  • Thread starter Thread starter Waze0613
  • Start date Start date
  • Views Views 2,709,151
  • Replies Replies 9,235
  • Likes Likes 92
No, 1.0.0 will get the stuff first because it's SciresM's choice.
(from what I did heard in ReSwitched)
It's not because just choice. As other poster explained, 1.0.0 has been widely opened for developers, so implementing CFW, EMUNAND and such would be easier. After getting the CFW at workable (especially for end user), you get to the phase of debug and revise it to get more stable version or add more feature. 3.01+ is more difficult and debug would take more time to get a stable release.
 
Last edited by tivu100,
  • Like
Reactions: TotalInsanity4
It's not because just choice. As other poster explained, 1.0.0 has been widely opened for developers, so implementing CFW, EMUNAND and such would be easier. Then you have phase to debug and revise it. 3.01+ is more difficult and debug would take more time to get a stable release.
I think the bigger issue is that the bug affecting 3.0.1+ could still potentially exist in later Switch versions if they don't release it
 
So I've noticed that a lot of developers tend to favor C over C++. For instance, the Vita, 3DS and Wii often had devs use C over C++. What's the reasoning? Personal preference? I figured C++ would be much better due to features such as overloading, automated memory management(and the choice to manually manage memory if you'd like), etc...
 
@SciresM Honest Question:

Whats the reason to develop a Custom Firmware for lower software versions than the current one? as example, why not force users to update to the current version and develop the Firmware for it, avoiding to write the core for several firmwares?
This way its just update the core of the code for the ongoing versions?

I see the idea of supporting other firmware, but wouldn't that just make users stays on lower versions when they can update right now? again this is very honest question, not a demanding nor a troll.
 
@SciresM Honest Question:

Whats the reason to develop a Custom Firmware for lower software versions than the current one? as example, why not force users to update to the current version and develop the Firmware for it, avoiding to write the core for several firmwares?
This way its just update the core of the code for the ongoing versions?

I see the idea of supporting other firmware, but wouldn't that just make users stays on lower versions when they can update right now? again this is very honest question, not a demanding nor a troll.
some people want to separate sysnand from their emunand
 
avoiding to write the core for several firmwares?

If a user on 4.1.0 wants to create an emuNAND with a copy of 1.0.0 and boot into that, we should support that.

If a user on 1.0.0 wants to create an emuNAND with a copy of 4.1.0 and boot into that, we should support that.

If a user on 2.0.0 wants to boot into linux, we should try our best to support chainloading into that instead of Horizon.

The core of the CFW shouldn't be firmware-specific at all -- it should generally support everything that it can.

@SciresM EmuNAND or RedNAND? Or both?

I think they're pretty damn interchangeable.
 
If a user on 4.1.0 wants to create an emuNAND with a copy of 1.0.0 and boot into that, we should support that.

If a user on 1.0.0 wants to create an emuNAND with a copy of 4.1.0 and boot into that, we should support that.

If a user on 2.0.0 wants to boot into linux, we should try our best to support chainloading into that instead of Horizon.

The core of the CFW shouldn't be firmware-specific at all -- it should generally support everything that it can.



I think they're pretty damn interchangeable.
Got it, Thanks!
 
FW 1.0-4.1.0 are pretty much blown wide open.
Multiple people have coldboot with full exploit chains on all current firmware.
The 3 key firmwares right now are 1.0.0, 3.0.0, and 4.1.0.

1.0 is the oldest, has the most flaws, and already has the most work put into it making it the easiest to release for first. Plus why update past this, if you happen to have this?

If you missed out on 1.0, and you have 2.0-3.0.0, just update to 3.0.0 as they already have a full exploit chain for 3.0.0 already, plus public homebrew, so why not.

If you missed out on 3.0.0, update to 4.1.0, for the same reasons as above.

Giving us key firmwares, and telling us to update to the next key firmware if you missed the previous, gets everyone to a few set firmware. This reduces the number of incremental firmware that cfw and underlying exploits must be tailored to.

As to the question of why they don't just release the latest, instead of starting at the oldest. It may be that they just don't want to scrap all of the work that they put into the older firmware. Not to mention they want to keep access to already fleshed out exploits in new updates, meaning they won't burn an exploit just to release it to the public.

I have a switch on 3.0.0, bought it new on that FW. I have a BotW cartridge version 002 and I might buy another game to try play on FW 3.0.0, but I wanna play my game cartridge and maybe others without upgrading. You think it would be a good idea to hold off updating?
 
@SciresM Honest Question:

Whats the reason to develop a Custom Firmware for lower software versions than the current one? as example, why not force users to update to the current version and develop the Firmware for it, avoiding to write the core for several firmwares?
This way its just update the core of the code for the ongoing versions?

I see the idea of supporting other firmware, but wouldn't that just make users stays on lower versions when they can update right now? again this is very honest question, not a demanding nor a troll.
Homebrew. The homebrew launcher developing group is very against piracy. They deem staying a little behind the latest fw now is better to kickstart homebrew scene than just allowing people focusing on piracy. SciresM made no judgement on people using CFW for piracy but developers from one group to work with other group and find an agreement is better for the community in long term
 
Atmosphere will *eventually* be launchable from all versions 1.0.0-4.1.0.

However, 1.0.0 will be able to use it first via jamais vu.

Some time later (probably at least a few months, I give no ETA on Atmosphere) it will be usable via deja vu on 2.0.0-3.0.0.

Then some unknown time later than that, it will be usable on 3.0.1-4.1.0.

Oh man! What bad news!
I thought that people in 3.0.1-3.0.2 would not have to wait that long.
Anyway, thanks for your great work.
 
So I've noticed that a lot of developers tend to favor C over C++. For instance, the Vita, 3DS and Wii often had devs use C over C++. What's the reasoning? Personal preference? I figured C++ would be much better due to features such as overloading, automated memory management(and the choice to manually manage memory if you'd like), etc...
C++ doesn't have any type of automatic memory management or garbage collection. You have to delete what you create, and though some generics from boost could be used to help with it, I don't think it's the popular way of going around.
Other than that, perhaps many developers prefer pure procedural, you know, it may be the case.

Also many may argue that the typical style of programming of OOP may lead to the creation of many new objects that are later deleted, rinse and repeat, and that this adds overhead. Also they may argue that the whole concept of polymorphism adds overhead, because you know, deciding what is the right method to call in base of the actual class of an object is done in real time and requires some extra code to be executed.

Are those overheads relevant? I don't think so, but sure one may argue so.
 
No, if you're on 3.0.1 you may as well update to 4.1.0 and get some eShop games before you settle in for the long wait.

So this long wait is where the modchip makes sense right? because if i understand correcly both TX modchip and this Atmosphere cfw do the same thing right? TX is trying to beat SciresM to the goal, at least in 4.1 (Besides the TX claim that the chip will work on all future firmwares)
 
So this long wait is where the modchip makes sense right? because if i understand correcly both TX modchip and this Atmosphere cfw do the same thing right? TX is trying to beat SciresM to the goal, at least in 4.1 (Besides the TX claim that the chip will work on all future firmwares)
If you're all and only aim for for piracy, that is. CFW is still very much rooting for homebrew scene. The slower approach of release is to nurturing the homebrew scene
 
I think the bigger issue is that the bug affecting 3.0.1+ could still potentially exist in later Switch versions if they don't release it
yeah idk if the the next one will patch it but the one after that will definitively patch it.

--------------------- MERGED ---------------------------

If a user on 4.1.0 wants to create an emuNAND with a copy of 1.0.0 and boot into that, we should support that.

If a user on 1.0.0 wants to create an emuNAND with a copy of 4.1.0 and boot into that, we should support that.

If a user on 2.0.0 wants to boot into linux, we should try our best to support chainloading into that instead of Horizon.

The core of the CFW shouldn't be firmware-specific at all -- it should generally support everything that it can.



I think they're pretty damn interchangeable.
are there any deflections Nintendo can do to tell if the consoles modded because whats the point of genning if your just going to get banned.
 
  • Like
Reactions: TheMCNerd2017

Site & Scene News

Popular threads in this forum