>spend hours setting it all up yourself. Lmao it takes about 10 minutes at most to set up.
>spend hours setting it all up yourself. Lmao it takes about 10 minutes at most to set up.
On "why?" then it gives you an immediate and considerable library of software to play with, development options and most besides. No other reason or justification is needed.
The library may not be as refined (it is largely going to be java based), open, or specialised as something like Debian's ARM build or whatever emulator/game distro the kids are excited about this week but if the end result is programs which run in real time/useful timeframes for humans then that is what is needed here.
If the mere act of doing it offends your sensibilities then might want to look into that. Or were you all so blinded by the lack of anything on the 3ds compared to that which came before that you are blind to the potential?
Custom junk? It is almost like we have never seen hardware reverse engineered and drivers made
http://archive.oreilly.com/pub/post/bountydriven_project_to_revers.html
https://www.raspberrypi.org/blog/quake-iii-bounty-we-have-a-winner/
https://learn.adafruit.com/hacking-the-kinect/overview
The library may not be as refined (it is largely going to be java based), open, or specialised as something like Debian's ARM build or whatever emulator/game distro the kids are excited about this week but if the end result is programs which run in real time/useful timeframes for humans then that is what is needed here.
If the mere act of doing it offends your sensibilities then might want to look into that. Or were you all so blinded by the lack of anything on the 3ds compared to that which came before that you are blind to the potential?
Where are people thinking that? While I doubt many would be going home in the "gun to head, alter the kernel in this way" test (compiling might even be a push) and there have been some suspect comments, some getting hung up on odd things (thinking it has to replace the full OS when dual boot and hypervisors are options) but having just gone through it I am not seeing the "ease" set represented.
Custom junk? It is almost like we have never seen hardware reverse engineered and drivers made
http://archive.oreilly.com/pub/post/bountydriven_project_to_revers.html
https://www.raspberrypi.org/blog/quake-iii-bounty-we-have-a-winner/
https://learn.adafruit.com/hacking-the-kinect/overview
- Joined
- Jun 24, 2007
- Messages
- 12,004
- Trophies
- 3
- Location
- In the Murderbox!
- Website
- www.twitch.tv
- XP
- 16,134
- Country
My mistake was disregarding certain words. Dual boot and hypervisors are entirely possible. The question remains of it being plausible to the end user. Obviously not, since the ones dying to try such a devious task are more than 'average' end users.
Has anyone here had experience with such an odd task? I would like to hear some educated opinions. Just guessing (as we are ALL doing at this point) that custom drivers will need to be created. Not just for the tablet itself, but also the peripherals. Assuming the dock works as normal, and Bluetooth is functional. The basics should be covered right out the gate, right? Then you've got the Switch specifics. Gyro, IR, NFC in the controllers etc..
I am genuinely curious now as to how this would play out. Given time, I will have my answer.
I'll admit, I'm ignorant in this area. I probably shouldn't have come off as so arrogant, couldn't be helped given my nature I guess. (Got some work to do zzzzzzzzzzzzzzzzzzzz)
Last edited by Kioku,
As a side note, if someone can figure out how to make a flash card that boots into Android, that would totally be worth buying! No piracy just a card dedicated to booting directly into Android with just enough storage space for a few basic apps. Obviously the version of Android on the card would need to support adaptable storage so that people could install additional apps, games, ect to the SD card. Are Switch game cards even read/write or just read only?
Typically prebaked installers/images get made available for the end users such that any old guide follower (read something like https://3ds.guide/ or https://sites.google.com/site/completesg/ and then read a linux install guide for one of the more conventional modern distros, though arch is not so far gone either -- the tone, the layout, the underlying logic will all be the same). That is not a particular problem.
People are already playing with the switch controllers ( https://github.com/mfosse/JoyCon-Driver ) and we have third party controllers. The very same data that allows that to happen in turn works just fine for custom drivers on another system. That is the whole point of pulling it apart and documenting it. People have been doing similar things for decades, though at one point the makers of such hardware often listed it or would otherwise tell you. Not everything needs to be in place either -- Gyro, IR, NFC are useless toys for most; buttons, stick and dpad will do fine for 90% of it. Docked mode would be nice but as long as one or the other works you have something to be getting on with.
Equally not all functionality of a given piece of hardware needs to be in place and highly refined as long as the core functionality works -- oh no enterprise wifi does not work in custom drivers, now I can't use work's wifi to play it, whatever shall I do?
The switch debug options are not the greatest but if the control over the system is as much as TX's stuff appears to promise then it should not be too bad to hook into the switch system to observe it natively.
Doubtless it will be many weekends and holidays from skilled electrical engineering/coding types that goes into making it refined but it is far from an insurmountable task, and there is likely to be a fair bit of motivation for this one (if obscure phones have it done for them then a millions selling device can probably gain some interest).
The kinect link from above
https://learn.adafruit.com/hacking-the-kinect/overview
It covers peripheral style hacking pretty well.
My general choice for device hacking is
https://nostarch.com/xboxfree
People are already playing with the switch controllers ( https://github.com/mfosse/JoyCon-Driver ) and we have third party controllers. The very same data that allows that to happen in turn works just fine for custom drivers on another system. That is the whole point of pulling it apart and documenting it. People have been doing similar things for decades, though at one point the makers of such hardware often listed it or would otherwise tell you. Not everything needs to be in place either -- Gyro, IR, NFC are useless toys for most; buttons, stick and dpad will do fine for 90% of it. Docked mode would be nice but as long as one or the other works you have something to be getting on with.
Equally not all functionality of a given piece of hardware needs to be in place and highly refined as long as the core functionality works -- oh no enterprise wifi does not work in custom drivers, now I can't use work's wifi to play it, whatever shall I do?
The switch debug options are not the greatest but if the control over the system is as much as TX's stuff appears to promise then it should not be too bad to hook into the switch system to observe it natively.
Doubtless it will be many weekends and holidays from skilled electrical engineering/coding types that goes into making it refined but it is far from an insurmountable task, and there is likely to be a fair bit of motivation for this one (if obscure phones have it done for them then a millions selling device can probably gain some interest).
The kinect link from above
https://learn.adafruit.com/hacking-the-kinect/overview
It covers peripheral style hacking pretty well.
My general choice for device hacking is
https://nostarch.com/xboxfree
This thread is pretty senseless since it's nothing but speculation but I was always one of those guys wishing for a solution to be able to use Android APKs on the Switch.
Why should I buy a Shield (or another Android tablet) as I'm already taking the Switch with me?
It's got everything it needs hardware sided:
200 GB micro SD cards are cheap enough so I'm fine with having digital games just there.
The internal memory should be enough for the Switch OS and Android.
We'll see how this turns out but I'm pretty sure it will happen at some point in a few years.
You don't like it? You don't see a reason why you would use it?
Then leave it.
Edit:
Why should I buy a Shield (or another Android tablet) as I'm already taking the Switch with me?
It's got everything it needs hardware sided:
- ARM CPU
- multi finger touchscreen
- Bluetooth
- WiFi
- Sound
200 GB micro SD cards are cheap enough so I'm fine with having digital games just there.
The internal memory should be enough for the Switch OS and Android.
We'll see how this turns out but I'm pretty sure it will happen at some point in a few years.
You don't like it? You don't see a reason why you would use it?
Then leave it.
Edit:
That's a great idea as well, saving the whole space on the Switch for itself but I don't see this working. Cartridges contain launchable Switch titles. So you would have to turn the whole Android OS into a launchable Switch title but Switch titles (aka games) are running inside the Switch OS rather than shutting it down and booting into "something else". But who knows what will come across.
Last edited by lordelan,
Similar threads
- Locked
