• Hey everyone, staff have documented a list of banned content and subject matter that we feel are not consistent with site values, and don't make sense to host discussion of on Famiboards. This list (and the relevant reasoning per item) is viewable here.

StarTopic Future Nintendo Hardware & Technology Speculation & Discussion |ST| (Read the staff posts before commenting!)

Reader mode
Atheerios said:
That's interesting. The new feature that won't be available for NX is "decides can access memory mapped as IO".

What's the benefit to that?
Click to expand...
It's a method of communicating with peripherals. Sometimes it can be simpler, because you get to just treat things as memory.

It's not especially interesting by itself, but the fact that it's a new feature that's apparently functionally disabled on "NX boards" certainly catches one's attention (unless that's not meant to include devkits somehow, but that seems unlikely from context). The notes about the page buffer size thing are similarly intriguing. It's all potentially suggestive of functionality not intended for current hardware.
 
Thraktor said:
I suspect that there's going to be some kind of new functionality in the new model (beyond being more powerful) and that they'll have some exclusive games which will leverage such functionality, even if they're smaller download-only titles. My guess is still a camera or two for AR, with AR Nintendogs as the flagship exclusive for the new hardware. Granted I've been very wrong when predicting Nintendo hardware before, but they should at least have some kind of new hardware functionality we're not aware of.
Click to expand...

Yeah, at this point I think this will be more Switch 2 and not simple stronger Switch,
so Nintendo will probably want add some new feature compared to current models and simple stronger hardware, IMO some AR/VR integration would be good guess.
 
Pokemaniac said:
It's a method of communicating with peripherals. Sometimes it can be simpler, because you get to just treat things as memory.

It's not especially interesting by itself, but the fact that it's a new feature that's apparently functionally disabled on "NX boards" certainly catches one's attention (unless that's not meant to include devkits somehow, but that seems unlikely from context). The notes about the page buffer size thing are similarly intriguing. It's all potentially suggestive of functionality not intended for current hardware.
Click to expand...
Probably additional function like a camera or microphone (remember blowing in Phantom Hourglass?) for a future hardware.
 
0
Atheerios said:
The thing I'm not looking forward about Drake potentially being an iterative succesor to Switch are all the dumb conversations we're gonna have in the first few years.

We know how Nintendo is. They will say at the beginning that that will support both consoles for the foreseeable future. They will say it's a third pillar or something like that. They won't officially recognize it as a succesor nor as a revision and will be very vague intentionally, there will be endless arguing as wether it should be classified as a succesor or revision on wikis.

Then Nintendo will just slowly stop making cross generation games. More arguing will follow. "So Nintendo is really leave us all who don't have Switch Drake behind huh?", "This is a travesty, they should keep supporting the original Switch it's perfectly capable", "Does Nintendo really expect me to pay $400 to play the new Mario game?" and so on.
Click to expand...
See, the trouble with this is one would have to presume that the 2017 Switch will continue to be manufactured and sold for a long time after (it will have been out for over 6 years by the time the successor arrives), and we can be confident this won't be the case. The more likely outcome is a period of relative safety - It'll be "Nintendo Switch (2nd Gen)". That's enough of an indicator that the new generation is underway, and the 1st Gen Switch will be closing out, so, if you don't have a Switch now, and you're interested, get the new one. If you still want the older one, you know what you're getting. The assertion that consumers will feel "screwed" somehow is an overblown projection, and patronising to large sections of the public, if not a straight-up concern troll. Consumers have bought phones on contract for YEARS, and by the time the 18/24/36 months are up, they've seen new entries. They don't necessarily buy them on launch, and they don't feel "burned" one year on, even if they bought said phone months before an expected new announcement. They know support coming to an end is a reality. This "concern" doesn't happen with other consoles, either, so, it smacks of "Because Nintendo" reasoning, which, as mentioned many times, is no premise at all. It didn't stop PS5/XS, even when "believing in generations" was shown to be fraudulent play, and 3rdPs eventually stop releasing their output on the last generations, too, but yet we're expected to believe Nintendo doing the same is problematic.
 
Simba1 said:
Yeah, at this point I think this will be more Switch 2 and not simple stronger Switch,
so Nintendo will probably want add some new feature compared to current models and simple stronger hardware, IMO some AR/VR integration would be good guess.
Click to expand...
I'm also see Drake as a new gen. With this kind of power, it's no brainer to promote it as a powerful version of current gen
 
What bothers me the most is firmware version 15 being finally out yet we still don't have themes. There's no way nintendo brings the feature to switch at the very last moment of the console's life cycle before drake comes out. My cope is that the firmware on drake is improved from OG switch and adds the feature at some point.
 
niconiconick64 said:
What bothers me the most is firmware version 15 being finally out yet we still don't have themes. There's no way nintendo brings the feature to switch at the very last moment of the console's life cycle before drake comes out. My cope is that the firmware on drake is improved from OG switch and adds the feature at some point.
Click to expand...
It has nothing to do with firmware improvement & everything to do philosophy. As long as Nintendo continues to view the Switch brand as a place to jump in & play games quickly + having a snappy OS then themes will continue to get brushed aside.
 
In the next switch, it’ll follow that trend of snappiness. They’ll have enough hardware resources to have customization, features and snappiness.
 
The Wii U browser was a really great browser. I loved the shoulder button / motion control scroll where it zoomed out and stuff. Even Edge on the Xbox feels a bit naff compared to it, and that's very good really.
 
Tentacle-tropes said:
I don’t really think the Wii example is the greatest since by the time the WiiU released the Wii was functionally a dead console both hardware & software wise.
Click to expand...
Sure. As I said there is no exact parallel in Nintendo’s history. That’s why I also pointed to the New 3DS and the DSi. Let’s put it this way - no Nintendo hardware with backwards compat has launched without a first party exclusive, no matter how minor the hardware change.
 
0
Pokemaniac said:

15.0.0 - Nintendo Switch Brew

switchbrew.org switchbrew.org

🤔
Click to expand...
...huh.
Pokemaniac said:
It's a method of communicating with peripherals. Sometimes it can be simpler, because you get to just treat things as memory.

It's not especially interesting by itself, but the fact that it's a new feature that's apparently functionally disabled on "NX boards" certainly catches one's attention (unless that's not meant to include devkits somehow, but that seems unlikely from context). The notes about the page buffer size thing are similarly intriguing. It's all potentially suggestive of functionality not intended for current hardware.
Click to expand...
I was thinking devkit too, initially, but what for? If you're wiring up a debugger it's not going to be over MMIO. MMIO to GPUs is pretty common in PC land, but makes no sense on a console.

Also intriguing:
Two new SVCs were added for a new "InsecureMemory" concept.
Click to expand...

Smells JITish to me, but eventually you'd need to execute whatever you write there, so why mark it as Insecure? Unless it wasn't intended for CPU execution and you wanted to make sure that no one wrote anything executable to it? Okay, now I am wildly speculating based on nothing but... shader JIT?
 
oldpuck said:
...huh.
I was thinking devkit too, initially, but what for? If you're wiring up a debugger it's not going to be over MMIO. MMIO to GPUs is pretty common in PC land, but makes no sense on a console.
Click to expand...
The only reason I brought up devkits is that they probably have some additional hardware that could plausibly use this, but I don't have anything in particular in mind. This being intended for other hardware (i.e. Drake) seems like the more straightforward interpretation of what was written, but it's not conclusive.
oldpuck said:
Also intriguing:

Smells JITish to me, but eventually you'd need to execute whatever you write there, so why mark it as Insecure? Unless it wasn't intended for CPU execution and you wanted to make sure that no one wrote anything executable to it? Okay, now I am wildly speculating based on nothing but... shader JIT?
Click to expand...
The Switch already has mechanisms in place for JIT, currently used primarily (exclusively?) for N64 emulation. Based on some elaboration posted elsewhere, this insecure memory thing seems to be insecure as in not inside the protected memory pool that kernel stuff would typically use. If I had to guess, it's probably for passing data back to userland.
 
Hidden04 said:
What is this supposed to mean?
Click to expand...
There are multiple new kernel features (at least memory mapped IO and page buffers differently sized from the hardware page size) that seem to be disabled and/or non-functional on current Switch hardware. It doesn't necessarily mean anything, but being intended for unreleased hardware is certainly pretty high on the list of possible explanations.
Hosermess said:
Were there specific references to the "NX board" in previous versions of the firmware?
Click to expand...
It's not 100% clear what is meant by "NX board" here, or how explicit that is in the firmware itself.
 
Hermii said:
Let’s not get ahead of ourselves.

Edit: I am convinced a strong reason why Nintendo won’t have a browser, is those stats pornhub releases about game consoles.
Click to expand...
Nah it's because Webkit is full of shit that known exploits are being used to hack consoles. This is most probably the reason why Nintendo did not open the browser to the user (the switch technically has a web browser internally).
 
niconiconick64 said:
What bothers me the most is firmware version 15 being finally out yet we still don't have themes. There's no way nintendo brings the feature to switch at the very last moment of the console's life cycle before drake comes out. My cope is that the firmware on drake is improved from OG switch and adds the feature at some point.
Click to expand...
I'm almost certain it will use the EXACT same firmware and OS. Just like what Xbox is doing. Why would they even bother to split development of the OS? They've added hardware features to the OS, 1440p and 4K resolution support, plenty of things the current hardware is incapable of. They'll add themes, I'd say, alongside or in the years after Drake launches, but to every Switch, and they'll continue to update both in tandem for as long as they need to, with older consoles just having the features they can't handle turned off, as we already see them doing.

Why complicate development with multiple channels if you don't HAVE to?
 
ertaboy356b said:
Nah it's because Webkit is full of shit that known exploits are being used to hack consoles. This is most probably the reason why Nintendo did not open the browser to the user (the switch technically has a web browser internally).
Click to expand...
In fact, the OG Switch hack involves a webkit browser embedded in a game
 
0
Concernt said:
I'm almost certain it will use the EXACT same firmware and OS. Just like what Xbox is doing. Why would they even bother to split development of the OS? They've added hardware features to the OS, 1440p and 4K resolution support, plenty of things the current hardware is incapable of. They'll add themes, I'd say, alongside or in the years after Drake launches, but to every Switch, and they'll continue to update both in tandem for as long as they need to, with older consoles just having the features they can't handle turned off, as we already see them doing.

Why complicate development with multiple channels if you don't HAVE to?
Click to expand...
Horizon is not a general purpose OS. One of the reasons it is so small and snappy is because it is, in some ways, a thin security layer over the hardware. I suspect they do have to. I imagine they will share development space as long as both pieces of hardware are supported, but I expect that they will not be exactly the same
 
0

Qualcomm Snapdragon 8(+) Gen1 SoC | TechInsights

For the first time in recent memory, Qualcomm has dual-sourced their Snapdragon 8(+) Gen1 SoC with both Samsung (4LPX) and TSMC (N4). This has allowed us at TechInsights to compare a common design manufactured by two different foundries.
www.techinsights.com www.techinsights.com
⋮
Our earlier report indicated that TSMC's N4E process, an early version of TSMC's N4 process used in Mediatek's Dimensity 9000, came with a mask reduction but no shrinkage. You may wonder if TSMC's N4 process is a true optical shrink from N5? Now, we have the answer:

In our recently released First Look Report of Snapdragon 8(+) Gen1 SoC on TSMC N4, we confirmed that the TSMC N4 technology in which the Snapdragon 8(+) Gen1 SoC was manufactured is a true optical shrink from the TSMC N5 node.

Further shrinks have been found with the bitcells (smallest being a 4% shrink), while other technology features are shared with the previous technology generations and summarized in TechInsights' First Look Report (available now to our subscribers)
⋮
Click to expand...
⋮
  • Comparison between Samsung's Exynos 2200 4LPE (a major process node change with pitch scaling) and 4LPX (essentially a 5LPE technology) technologies
⋮
Click to expand...

15.0.0 added "EnableMultiCoreDownload", "DisableMultiCoreDownload", and "IsMultiCoreDownloadEnabled" for network related services.
4ZWCwKP.png

Hopefully higher download and upload speeds? And I don't how likely this is, but perhaps gigabit support for Nintendo's new hardware?
 
Last edited:
oldpuck said:
...huh.

I was thinking devkit too, initially, but what for? If you're wiring up a debugger it's not going to be over MMIO. MMIO to GPUs is pretty common in PC land, but makes no sense on a console.

Also intriguing:


Smells JITish to me, but eventually you'd need to execute whatever you write there, so why mark it as Insecure? Unless it wasn't intended for CPU execution and you wanted to make sure that no one wrote anything executable to it? Okay, now I am wildly speculating based on nothing but... shader JIT?
Click to expand...

Speaking of wildly speculating based on nothing, is there any chance these would be related to an external PCIe interface? Specifically, both CFExpress and SD Express memory cards use PCIe interfaces. I think MMIO is used for PCIe config (?), and providing an external interface with DMA presents a massive attack vector, which would necessitate some kind of managing of the memory space the PCIe device can access (ie. insecure memory). I'm probably just joining two dots that are actually completely unrelated, though.
 
15.0.0 also gives us an update on the syscall situation after 18 months. Refresher: https://famiboards.com/threads/nint...mis-summer-gameguess.2700/page-52#post-248489

Two new syscalls were implemented, using IDs within the block of 64 new ones that got added back in 12.0.0. However, there's still a gap of 16 stubbed IDs between the previous highest and the first new used one. So this would suggest that the expansion was preemptive reservation of IDs with some intention to use later on the current model, but the gap where 16 IDs remain stubbed after all this time supports the possibility that some calls could be used by another firmware build that we can't see.
 
LiC said:
15.0.0 also gives us an update on the syscall situation after 18 months. Refresher: https://famiboards.com/threads/nint...mis-summer-gameguess.2700/page-52#post-248489

Two new syscalls were implemented, using IDs within the block of 64 new ones that got added back in 12.0.0. However, there's still a gap of 16 stubbed IDs between the previous highest and the first new used one. So this would suggest that the expansion was preemptive reservation of IDs with some intention to use later on the current model, but the gap where 16 IDs remain stubbed after all this time supports the possibility that some calls could be used by another firmware build that we can't see.
Click to expand...
What are the two new syscalls and what is the reserved block? My usual sources don't have this documented.

The fact that two new syscalls appear in the middle of the block implies to me that they weren't reserved for future use, but that these syscalls were ported over from an outside branch when some userland code needed them, or as part of a syncing of the kernel from upstream
 
Quoted by: LiC
1
oldpuck said:
What are the two new syscalls and what is the reserved block? My usual sources don't have this documented.

The fact that two new syscalls appear in the middle of the block implies to me that they weren't reserved for future use, but that these syscalls were ported over from an outside branch when some userland code needed them, or as part of a syncing of the kernel from upstream
Click to expand...

12.0.0 added stubbed IDs 0x80 - 0xBF. The newly implemented IDs are 0x90 and 0x91.

https://switchbrew.org/wiki/SVC
https://switchbrew.org/wiki/12.0.0#Kernel
https://switchbrew.org/wiki/15.0.0#Kernel

What I meant by saying they were intended for future use is that they (evidently) weren't created exclusively for some new firmware build, since at least two of them are supported on the current CPU and OS.
 
Thraktor said:
Speaking of wildly speculating based on nothing, is there any chance these would be related to an external PCIe interface? Specifically, both CFExpress and SD Express memory cards use PCIe interfaces. I think MMIO is used for PCIe config (?), and providing an external interface with DMA presents a massive attack vector, which would necessitate some kind of managing of the memory space the PCIe device can access (ie. insecure memory). I'm probably just joining two dots that are actually completely unrelated, though.
Click to expand...

Actually, while I could be completely wrong on the PCIe thing, I don't think the MMIO and InsecureMemory are unrelated. The SwitchBrew page states:

  • KMemoryState_Insecure has value 0x5583817.
    • This is type 0x17 with flags CanUseNonDeviceIpc, CanUseNonSecureIpc, Mapped, CanDeviceMap, CanAlignedDeviceMap, ReferenceCounted, CanChangeAttribute, LinearMapped.
Click to expand...

I bolded CanDeviceMap and CanAlignedDeviceMap, because these are the MMIO flags, and this seems to be the only place they're used.

LiC said:
12.0.0 added stubbed IDs 0x80 - 0xBF. The newly implemented IDs are 0x90 and 0x91.

https://switchbrew.org/wiki/SVC
https://switchbrew.org/wiki/12.0.0#Kernel
https://switchbrew.org/wiki/15.0.0#Kernel

What I meant by saying they were intended for future use is that they (evidently) weren't created exclusively for some new firmware build, since at least two of them are supported on the current CPU and OS.
Click to expand...

So:
  1. Nintendo stubbed out a block of system calls which were speculated to be held for future hardware.
  2. Two of those system call IDs have now been used for flagging insecure memory.
  3. That insecure memory seems to be used for MMIO mapping.
  4. This MMIO functionality isn't supported on current Switch models.
🧐

Though, if this is specifically for some new I/O on Drake models, why is it showing up in shipping Switch firmware? Is there a part of this code which can be currently used? Or is Nintendo starting to merge Drake-specific branches into the main branch?
 
Last edited:
Thraktor said:
Actually, while I could be completely wrong on the PCIe thing, I don't think the MMIO and InsecureMemory are unrelated. The SwitchBrew pages states:



I bolded CanDeviceMap and CanAlignedDeviceMap, because these are the MMIO flags, and this seems to be the only place they're used.



So:
  1. Nintendo stubbed out a block of system calls which were speculated to be held for future hardware.
  2. Two of those system call IDs have now been used for flagging insecure memory.
  3. That insecure memory seems to be used for MMIO mapping.
  4. This MMIO functionality isn't supported on current Switch models.
🧐

Though, if this is specifically for some new I/O on Drake models, why is it showing up in shipping Switch firmware? Is there a part of this code which can be currently used? Or is Nintendo starting to merge Drake-specific branches into the main branch?
Click to expand...
I wouldn't trust that those flags aren't used elsewhere just because they're only mentioned by name in that new bullet point. The wiki is pretty sparse, lacking in context, and bereft of cross-references where they're needed. From the list of memory types here (which aren't even identified with the KMemoryState_ prefix) we can see that several of them do use those flags (bits 19 and 20, also named slightly differently from how they're referred to elsewhere).

Actually because the wiki is so bad and unsearchable, I first found a gist with the KMemoryState names and raw values, and had to infer the right bits were 19 and 20 due to the order they were listed in that bullet point, before I found the links above.
 
LiC said:
I wouldn't trust that those flags aren't used elsewhere just because they're only mentioned by name in that new bullet point. The wiki is pretty sparse, lacking in context, and bereft of cross-references where they're needed. From the list of memory types here (which aren't even identified with the KMemoryState_ prefix) we can see that several of them do use those flags (bits 19 and 20, also named slightly differently from how they're referred to elsewhere).

Actually because the wiki is so bad and unsearchable, I first found a gist with the KMemoryState names and raw values, and had to infer the right bits were 19 and 20 due to the order they were listed in that bullet point, before I found the links above.
Click to expand...
Ah, thanks. I did a search for those flags and assumed they were new.
 
0
Thraktor said:
Actually, while I could be completely wrong on the PCIe thing, I don't think the MMIO and InsecureMemory are unrelated. The SwitchBrew page states:



I bolded CanDeviceMap and CanAlignedDeviceMap, because these are the MMIO flags, and this seems to be the only place they're used.



So:
  1. Nintendo stubbed out a block of system calls which were speculated to be held for future hardware.
  2. Two of those system call IDs have now been used for flagging insecure memory.
  3. That insecure memory seems to be used for MMIO mapping.
  4. This MMIO functionality isn't supported on current Switch models.
🧐

Though, if this is specifically for some new I/O on Drake models, why is it showing up in shipping Switch firmware? Is there a part of this code which can be currently used? Or is Nintendo starting to merge Drake-specific branches into the main branch?
Click to expand...
This is a bit out of my depth, but I'd hazard a guess that the memory mapped IO and the similarly nonfunctional ability to resize page buffers go together, because that intuitively makes sense.

I'm a bit less convinced the insecure memory thing is related (at least exclusively) since I think that would let the kernal allocate memory in application visible regions, which has potential general applications for passing data around.

Whatever the case, it definitely seems pretty likely that some Drake details are starting to make their way into the main development branch, at a minimum. One important milestone to keep in mind is the factory firmware image. If Drake is actually beginning manufacturing this fall, the factory firmware image would naturally be based on the 15.x.x branch. It wouldn't necessarily be the same as the build we get, or even necessarily fully functional (that can wait until they start printing carts), but there should be retail 15.x.x builds that can run on Drake pretty soon if not already.
 
LiC said:
12.0.0 added stubbed IDs 0x80 - 0xBF. The newly implemented IDs are 0x90 and 0x91.

https://switchbrew.org/wiki/SVC
https://switchbrew.org/wiki/12.0.0#Kernel
https://switchbrew.org/wiki/15.0.0#Kernel

What I meant by saying they were intended for future use is that they (evidently) weren't created exclusively for some new firmware build, since at least two of them are supported on the current CPU and OS.
Click to expand...
Ah, excellent, the SVC call list at the wiki hasn't been updated and it confused me. Thank you!

Another interesting comparison between 12.0.0 and 15.0.0 - they are the only times Nintendo has updated the Major Version number without it corresponding to a major user facing feature. 12.0.0 came with all the necessary internals to support the OLED model (the ability to update the dock's firmware, or check for wired internet while in sleep mode) and BT headsets (the BT stack was updated) but they weren't added to the UI till 13.0.0.

That's more eyebrow raising to me than any of the individual details. It seems likely that the microkernel and core services stack are maintained separately from the UI, that point revisions are driven by stability/security needs, and "major versions" are the UI being pushed out along with the current state of the kernel underneath it.

In retrospect - and this is highly speculative - 12.0.0 felt like a soak test for the driver stack, pushing a major update out to existing hardware to clean up any issues before the hardware launch (and the BT headset support, to be fair) went out to make sure nothing would break when all eyes would be on it.

April - Version 12 adds Aula Cradle support
July - Aula announced
September - Version 13 enables Aula's features in the UI preemptively
October - Aula released

Thraktor said:
Though, if this is specifically for some new I/O on Drake models, why is it showing up in shipping Switch firmware? Is there a part of this code which can be currently used? Or is Nintendo starting to merge Drake-specific branches into the main branch?
Click to expand...
As an alternative to my "test the update driver stack won't break existing hardware prior to new hardware launch" theory, there is a possibility that these system calls are part of a group of memory systems internals updates that affect an API used by the UI.

  • More changes to SvcMapDeviceAddressSpace(ByForce/Aligned).
    • The argument which was previously a memory permission ("device_perm") is now an encoded u32 ("option").
      • The low 16 bits of this are the device permission.
      • The upper 16 bits of this are an enum (only defined values are 0 and 1).
    • If the enum-arg is not 0 or 1, svc::ResultInvalidEnumValue() is now returned.
    • If the enum-arg is 1 and the specified memory is IO, svc::ResultInvalidCombination is returned.
Click to expand...

If one of these related systems needs to check on InsecureMemory internally, then this API call may have dragged a large number of memory system updates with it.
 
oldpuck said:
Ah, excellent, the SVC call list at the wiki hasn't been updated and it confused me. Thank you!

Another interesting comparison between 12.0.0 and 15.0.0 - they are the only times Nintendo has updated the Major Version number without it corresponding to a major user facing feature. 12.0.0 came with all the necessary internals to support the OLED model (the ability to update the dock's firmware, or check for wired internet while in sleep mode) and BT headsets (the BT stack was updated) but they weren't added to the UI till 13.0.0.

That's more eyebrow raising to me than any of the individual details. It seems likely that the microkernel and core services stack are maintained separately from the UI, that point revisions are driven by stability/security needs, and "major versions" are the UI being pushed out along with the current state of the kernel underneath it.

In retrospect - and this is highly speculative - 12.0.0 felt like a soak test for the driver stack, pushing a major update out to existing hardware to clean up any issues before the hardware launch (and the BT headset support, to be fair) went out to make sure nothing would break when all eyes would be on it.

April - Version 12 adds Aula Cradle support
July - Aula announced
September - Version 13 enables Aula's features in the UI preemptively
October - Aula released
Click to expand...
As I sort of alluded to in my last post, there is kind of a reason why one would expect a pattern like this. The fully polished version of new firmware to go with new hardware isn't typically available until the hardware itself is, but they need a MVP version of it to flash onto the system at the factory months before that. 13.0.0 was the Switch OLED update, but the hardware probably (can't confirm as I don't own one myself) came with a 12.x.x version out of the box which supported everything enough to tide it over until 13.0.0 or later could be installed from online or a cartridge. Similarly, the Switch originally shipped with 1.x.x firmware when it launched, which could play games from carts but not much else, while the day 1 update actually brought it all the way to 2.0.0, which added all the online and other basic features. With a couple notable exceptions (3DS launched too early before 2.0 was ready, and little ever happened with the DSi firmware), you can trace this pattern back basically as long as Nintendo has had updateable firmware.

Could 15.x.x be Drake's factory firmware version? Nothing is confirmed, but one would expect it to be given the expected spring launch window and some of the odd tidbits that are surfacing in the datamines.
 
Pokemaniac said:
As I sort of alluded to in my last post, there is kind of a reason why one would expect a pattern like this. The fully polished version of new firmware to go with new hardware isn't typically available until the hardware itself is, but they need a MVP version of it to flash onto the system at the factory months before that. 13.0.0 was the Switch OLED update, but the hardware probably (can't confirm as I don't own one myself) came with a 12.x.x version out of the box which supported everything enough to tide it over until 13.0.0 or later could be installed from online or a cartridge. Similarly, the Switch originally shipped with 1.x.x firmware when it launched, which could play games from carts but not much else, while the day 1 update actually brought it all the way to 2.0.0, which added all the online and other basic features. With a couple notable exceptions (3DS launched too early before 2.0 was ready, and little ever happened with the DSi firmware), you can trace this pattern back basically as long as Nintendo has had updateable firmware.

Could 15.x.x be Drake's factory firmware version? Nothing is confirmed, but one would expect it to be given the expected spring launch window and some of the odd tidbits that are surfacing in the datamines.
Click to expand...
The open question, then, is can 15.x run Drake games - is there some software detection that would allow it to respond to some kind of binary header or similar?
 
oldpuck said:
The open question, then, is can 15.x run Drake games - is there some software detection that would allow it to respond to some kind of binary header or similar?
Click to expand...
There appear to be some mysterious new flag(s) related to content metadata, but it's not clear (at least from public info I can find at the moment) what impact they have yet. Even if they are relevant, it's entirely possible that whatever impact they have is only present in Drake builds.
 
LiC said:
If there was, it wouldn't be in the build of the firmware that's on the current model.
Click to expand...
To clarify - have any of the public APIs changed to accept values that were previously hardcoded which might be needed to load Drake NCAs, even if loader support isn’t present? If 15.0.0 is the basis of Drake’s factory firmware, then even if the implementation isn’t there, I’d expect those changes to make it out into the wild even if the implementation isn’t there
 
oldpuck said:
To clarify - have any of the public APIs changed to accept values that were previously hardcoded which might be needed to load Drake NCAs, even if loader support isn’t present? If 15.0.0 is the basis of Drake’s factory firmware, then even if the implementation isn’t there, I’d expect those changes to make it out into the wild even if the implementation isn’t there
Click to expand...
There is definitely a new field involved in loading game files that I don't think anyone (that I've found) has really figured out the purpose of yet. Some sort of content metadata byte.
 
I might be dumb, but I just found out that the A16 bionic has more transistors than the Xbox series X. I’m amazed by this, it took the iPhone 5 years to leapfrog the last gen console counts and this time they did it in 2. No wonder the Switch Successor will be stronger than any of us expected a year ago.
 
I don't expect the number of transistors to exceed 10 billion transistors if Nintendo and Nvidia decide to fabricate Drake using TSMC's N6 process node initially.
 
ILikeFeet said:
It helps that Apple funds a lot of tsmc advances

And those cpus are big
Click to expand...

True, but that density in a mobile device still blew my mind. Don’t know why I never payed that much attention to it, but realizing it today was something.

Dakhil said:
I don't expect the number of transistors to exceed 10 billion transistors if Nintendo and Nvidia decide to fabricate Drake using TSMC's N6 process node initially.
Click to expand...

Oh, I agree, I doubt Nintendo and Nvidia will get within spitting distance of the iPhone, but it’s still mind blowing that we can even have this conversation so early after the last gen systems launched.
 
0
ILikeFeet said:
only between the fabs' own products. tracking gains between fabs isn't too fruitful outside of actual products
Click to expand...
And in-foundry that data tends to be a little marketing-skewed.

Best data I’ve ever seen is from folks testing phones, as that is often a standard ARM proc on different nodes
 
0
Pokemaniac said:
There is definitely a new field involved in loading game files that I don't think anyone (that I've found) has really figured out the purpose of yet. Some sort of content metadata byte.
Click to expand...
Out of curiosity, can someone point me to where some of these conversations are happening? OS kernels are one of the few things I have actual knowledge about
 
Reader mode
You must log in or register to reply here.
Please read this staff post before posting.

Furthermore, according to this follow-up post, all off-topic chat will be moderated.
Last edited:


Back
Top Bottom