Hardware Misc Is it possible to overclock a TN new 3ds display?

[KleinesSinchen]

At that point I don't even want to bring up overclocking ram, which could help with running games at higher frame rates. "No, u can't add more ram" "No, overclocking the ram just makes it faster" "but the n3ds ram is only 256mb, you can't add more ram" ""

We had such questions in the past (overclocking (N)3DS CPU)

Spoiler: Guess the answer

No!

Sadly I'm missing the expertise regarding such topic (and therefore mostly stay quiet: "Better say nothing than make a fool of yourself!"). Questions like this are interesting, not only overclocking. The more RAM question is actually interesting. Asking it would result in this:

Could more RAM be added to a 2|3DS? Are standard RAM chips used that could be replaced with bigger ones? How would the OS react? Could the software be adjusted to make use of more RAM (thinking of a web browser for example). → "No! Use your phone for browsing. Problem solved. [/thread]"

Could the Wii U MLC NAND be replaced with a bigger one (it has been done on the Switch)? → "No! Connect external HDD, problem solved. [/thread]"

Could[…]? → "No. Stop creating useless threads!"

I have some strange questions in mind myself. But I refrained from asking them, because I really don't need such non-answers.

 

[XRTerra]

We had such questions in the past (overclocking (N)3DS CPU)

Spoiler: Guess the answer

No!

Sadly I'm missing the expertise regarding such topic (and therefore mostly stay quiet: "Better say nothing than make a fool of yourself!"). Questions like this are interesting, not only overclocking. The more RAM question is actually interesting. Asking it would result in this:

Could more RAM be added to a 2|3DS? Are standard RAM chips used that could be replaced with bigger ones? How would the OS react? Could the software be adjusted to make use of more RAM (thinking of a web browser for example). → "No! Use your phone for browsing. Problem solved. [/thread]"

Could the Wii U MLC NAND be replaced with a bigger one (it has been done on the Switch)? → "No! Connect external HDD, problem solved. [/thread]"

Could[…]? → "No. Stop creating useless threads!"

I have some strange questions in mind myself. But I refrained from asking them, because I really don't need such non-answers.

Adding more ram is actually a fun idea. One day it would be fun to add 256 mb of ram to the 3ds to see if it's stable. the n3ds works fine with 256 mb. It would require soldering, and I don't have a solder kit and an old 3ds handy plus 3ds compatible FCRam.

The new 3ds xl uses Fujitsu MB82MK9A9A, but the issue is that the old 3ds xl runs Fujitsu MB82DBS16641. That's definitely different. We shouldn't have to change the entire motherboard to get 256 mb of ram in an old 3ds xl, because that just defeats the entire point of using an old 3ds xl mobo. Unless they're just changing the name to mess with people.

So instead of physical ram, why not vram? Virtual ram is almost never as fast as physical ram, but partitioning maybe 128 mb of virtual ram from the sd card could be an interesting experiment on the old 3ds. If it works properly, why not try partitioning 256 mb for a n3ds? Lots of cool possibilities, but according to the experts we have, "you can't add more ram, just get a n3ds". Partitioning memory from the sd card probably wouldn't work easily on the 3ds anyways, so why not try partitioning from the available nand space? There's only 512mb available on the 3ds. To prevent anything bad from happening, we can use maybe only 64-100 mb of that without having the need to delete anything. Most modern android phones allow you to use the system flash memory to be used as normal memory, but there's usually a limit depending on the phone. My phone can add 1 gb of vram unless I can add more and missing it.

There could be lots of potential room to overclock the 3ds, but it might not be worth it because not a lot of games are gonna look at virtual memory and start running at 60 fps. Since the cpu and gpu can't be overclocked(or they could if a major breakthrough is discovered, and I would 100% jump on it), the only potential things left are the littler things. If we could figure out a way to downsample 3ds games to make that 240p resolution look even a little better, that would be cool too.

 

[ghjfdtg]

At that point I don't even want to bring up overclocking ram, which could help with running games at higher frame rates. "No, u can't add more ram" "No, overclocking the ram just makes it faster" "but the n3ds ram is only 256mb, you can't add more ram" ""

The answer to this is not possible because the only register that can change RAM speed has 2 options. Fast or slow and Nintendo already uses fast by default. There is no PLL or anything to make it faster.

 

[Sono]

At that point I don't even want to bring up overclocking ram, which could help with running games at higher frame rates. "No, u can't add more ram" "No, overclocking the ram just makes it faster" "but the n3ds ram is only 256mb, you can't add more ram" ""

I don't know if overclocking RAM is possible, I'd need to poke around some unknown registers. There are some registers which modify how the FCRAM behaves, which is needed for GBA mode (speculation is that the FCRAM is put into some fixed-timing mode so it can be accessed like SRAM, although I'm not sure how true/false it is, as I lack the skills and equipment to verify it).

As for adding more RAM, I have a very very strong suspicion that the RAM size is hardcoded into the fabric (fancy memory address decoder), and since I think that RAM is not mirrored (haven't tested this myself, but pretty sure that 3dbrew would mention if it was mirrorable, like with the ARM11 bootrom), it's not possible to add more RAM without seeing the newly added region.
Also due to the actual pinout of the RAM chip (that is, you could use jumper wires if it was virtually pin-compatible, but not physically) it might not be possible at all to add a different RAM chip due to CAS/RAS select line count differences.

As for RAM overclocking again, overclocking the RAM would make the 3DS (especially old3DS) a hell of a lot faster. I did some tests, and in some cases the speed difference was unmeasurable due to the massive performance difference compared to cached vs. uncached execution and data access.
While overclocking the new3DS has some slight benefits, overclocking the new3DS without L2 seems to just make it actually SLOWER. Enabling L2 has huge benefits even at non-overclocked mode.
The funny thing happens when you rephrase the old3DS cache size: instead of saying 16k icache and 16k dcache, I could say that the old3DS can store 4096 instructions in cache, and 4096 32bit numbers, none of which are a lot, especially the instruction cache part. No wonder the poor thing is so damn slow!

Adding more ram is actually a fun idea. One day it would be fun to add 256 mb of ram to the 3ds to see if it's stable. the n3ds works fine with 256 mb. It would require soldering, and I don't have a solder kit and an old 3ds handy plus 3ds compatible FCRam.

The new 3ds xl uses Fujitsu MB82MK9A9A, but the issue is that the old 3ds xl runs Fujitsu MB82DBS16641. That's definitely different. We shouldn't have to change the entire motherboard to get 256 mb of ram in an old 3ds xl, because that just defeats the entire point of using an old 3ds xl mobo. Unless they're just changing the name to mess with people.

So instead of physical ram, why not vram? Virtual ram is almost never as fast as physical ram, but partitioning maybe 128 mb of virtual ram from the sd card could be an interesting experiment on the old 3ds. If it works properly, why not try partitioning 256 mb for a n3ds? Lots of cool possibilities, but according to the experts we have, "you can't add more ram, just get a n3ds". Partitioning memory from the sd card probably wouldn't work easily on the 3ds anyways, so why not try partitioning from the available nand space? There's only 512mb available on the 3ds. To prevent anything bad from happening, we can use maybe only 64-100 mb of that without having the need to delete anything. Most modern android phones allow you to use the system flash memory to be used as normal memory, but there's usually a limit depending on the phone. My phone can add 1 gb of vram unless I can add more and missing it.

There could be lots of potential room to overclock the 3ds, but it might not be worth it because not a lot of games are gonna look at virtual memory and start running at 60 fps. Since the cpu and gpu can't be overclocked(or they could if a major breakthrough is discovered, and I would 100% jump on it), the only potential things left are the littler things. If we could figure out a way to downsample 3ds games to make that 240p resolution look even a little better, that would be cool too.

The name of the mechanism you're describing is either swapping (backed by the swap/swapfile on Linux), or pagefile (backed by the pagefile). What happens is that memory not in active use gets written to disk, then unmapped from virtual memory, to be repurposed somewhere else.
When accessing a swapped virtual memory region, an exception will happen, as the virtual memory region you're trying to access is unmapped. The kernel knows that this memory region was mapped before, so it loads the memory from disk again, then gives back the memory region, being usable again as if nothing has happened.
(Sorry for the janky explaination, currently lack capacity to explain it properly)

I don't think it's possible to map arbitrary memory under userland, but I might be wrong.

If you could map arbitrary memory to arbitrary virtual memory space then you could actually do this trick using hooked exception handlers (loaded from TLS), but you'd have to sadly manage this yourself.

Considering that games and everything are already programmed with fix memory size in mind, this would only be useful for homebrew (if it was even possible in the first place), and even then the homebrew itself would have to manage virtual memory and the other stuff.

 

[KaduPSE]

Love how it's always @Sono messing with the coolest and most obscure things of the 3DS hardware: GBA and DS scaling, the LEDs, display overclocking.

 

[XRTerra]

Considering that games and everything are already programmed with fix memory size in mind, this would only be useful for homebrew (if it was even possible in the first place), and even then the homebrew itself would have to manage virtual memory and the other stuff.

Then why not mod the games to have a different memory size in mind? Probably a stupid question, because adding ram doesn't work well, but what if there was a way to make the 3ds think it has more ram? Instead of directly adding it in different ways?

What if the 3ds thought it had a gigabyte of ram? Would it try to use the memory that doesn't exist in the slightest bit? What if a game thought it had a gigabyte of ram to play around with?

How would the 3ds react if it realized it had a battery bigger than 2,000 mah? Would the battery percantage not work? Could there be a software on boot that recognizes said large battery? If one that can fit in the 3ds even exists?

I have so many thoughts in my head on if theres any possible way to make the 3ds run better other than finding a magical spell from narnia that could allow the 3ds to overclock..

Both the switch and 3ds run on arm, no? I know they're different versions of arm and the switch is significantly more powerful than the 3ds, but why not have a version of atmosphere running on n3ds? It'll probably take a lot of work, as luma is made for the lower power of the n3ds compared to the vita. I personally think atmosphere on n3ds won't happen anytime soon, as luma already works amazing. It would also be pretty weird to say "Oh I run atmosphere cfw!" "which one?"

I want to finish typing this comment but I gotta go do something but I just want to post what I want to say

 

[Sono]

Then why not mod the games to have a different memory size in mind? Probably a stupid question, because adding ram doesn't work well, but what if there was a way to make the 3ds think it has more ram? Instead of directly adding it in different ways?

What if the 3ds thought it had a gigabyte of ram? Would it try to use the memory that doesn't exist in the slightest bit? What if a game thought it had a gigabyte of ram to play around with?

How would the 3ds react if it realized it had a battery bigger than 2,000 mah? Would the battery percantage not work? Could there be a software on boot that recognizes said large battery? If one that can fit in the 3ds even exists?

I have so many thoughts in my head on if theres any possible way to make the 3ds run better other than finding a magical spell from narnia that could allow the 3ds to overclock..

Both the switch and 3ds run on arm, no? I know they're different versions of arm and the switch is significantly more powerful than the 3ds, but why not have a version of atmosphere running on n3ds? It'll probably take a lot of work, as luma is made for the lower power of the n3ds compared to the vita. I personally think atmosphere on n3ds won't happen anytime soon, as luma already works amazing. It would also be pretty weird to say "Oh I run atmosphere cfw!" "which one?"

I want to finish typing this comment but I gotta go do something but I just want to post what I want to say

oof, I'm way too crippled atm to answer all of these correctly >.<

Pretty sure games have a hardcoded RAM amount, so changing it should be effectively impossible due to having to search the entire code for references, and modify them. But even then, there is no guarantee that the game will ever use that much RAM, considering that these games are designed with fixed and limited amount of RAM available.

I'm pretty sure the 3DS OS couldn't do anything with the extra RAM either. The memory sizes are hardcoded into the kernel, and the virtual memory regions are downsized to the exact amount of RAM we have available.
Even if you managed to somehow find and hack every occurrance in the kernel, you would most likely just cause a nullptr deref afaik, as the memory size would be out of bounds of what the SDK is hardcoded to do. As for what happens if you also hacked the game to not crash... idk, it's already a really stupid idea due to how extremely difficult and time-consuming it is, sorry. No idea how games would react though if you did manage to do all patches, as the way I keep repeating myself, they were simply just designed with fixed amount of RAM, and not ready to handle a sudden change in RAM size.
My guess is that the game would just keep running like nothing happened, although I do expect a few outliars to simply just crash or something. We may never know...

Batteries, hmm...
I know that there are weird tables inside of the MCU_FIRM, probably used for capacity-to-percentage mapping, but that aside I have no idea, as I don't have the tools to be able to investigate this any further.
In this case all I can do is speculate. Considering that I don't know the source of the data, my guess is that they map voltage to percentage, and call it a day. So my guess is that as long as the modified battery has the same voltage curve when charging/discharging, then it should work without any issues.
Also, can't detect battery capacity, pretty sure the 3DS lacks hardware for that. I think it's simply just voltage measurement, and trying to curve it.
A higher capacity battery can't fit into the 3DS without modifying the entire shell, as we're limited by energy density, meaning that bigger batteries simply just need more space, and anyone else claiming otherwise is a scam.

No idea what Atmosphere does, as none of my Switch consoles are hackable (without a shill modchip, which I refuse to install due to lacking funds and trust).

As for overclocking the old3DS, pretty sure that idea should be thrown out the window.
Two things I feel *might* be overclockable: the FCRAM, and the GPU.
The FCRAM is simply just an underexplored hardware, as it's only ever poked in GBA mode, and that's how we found that these registers even exist in the first place.
As for the GPU, who knows if some of the glitch bits actually overclock the GPU, which cause the glitches. We may not know for some time...

 

[XRTerra]

oof, I'm way too crippled atm to answer all of these correctly >.<

Pretty sure games have a hardcoded RAM amount, so changing it should be effectively impossible due to having to search the entire code for references, and modify them. But even then, there is no guarantee that the game will ever use that much RAM, considering that these games are designed with fixed and limited amount of RAM available.

I'm pretty sure the 3DS OS couldn't do anything with the extra RAM either. The memory sizes are hardcoded into the kernel, and the virtual memory regions are downsized to the exact amount of RAM we have available.
Even if you managed to somehow find and hack every occurrance in the kernel, you would most likely just cause a nullptr deref afaik, as the memory size would be out of bounds of what the SDK is hardcoded to do. As for what happens if you also hacked the game to not crash... idk, it's already a really stupid idea due to how extremely difficult and time-consuming it is, sorry. No idea how games would react though if you did manage to do all patches, as the way I keep repeating myself, they were simply just designed with fixed amount of RAM, and not ready to handle a sudden change in RAM size.
My guess is that the game would just keep running like nothing happened, although I do expect a few outliars to simply just crash or something. We may never know...

Batteries, hmm...
I know that there are weird tables inside of the MCU_FIRM, probably used for capacity-to-percentage mapping, but that aside I have no idea, as I don't have the tools to be able to investigate this any further.
In this case all I can do is speculate. Considering that I don't know the source of the data, my guess is that they map voltage to percentage, and call it a day. So my guess is that as long as the modified battery has the same voltage curve when charging/discharging, then it should work without any issues.
Also, can't detect battery capacity, pretty sure the 3DS lacks hardware for that. I think it's simply just voltage measurement, and trying to curve it.
A higher capacity battery can't fit into the 3DS without modifying the entire shell, as we're limited by energy density, meaning that bigger batteries simply just need more space, and anyone else claiming otherwise is a scam.

No idea what Atmosphere does, as none of my Switch consoles are hackable (without a shill modchip, which I refuse to install due to lacking funds and trust).

As for overclocking the old3DS, pretty sure that idea should be thrown out the window.
Two things I feel *might* be overclockable: the FCRAM, and the GPU.
The FCRAM is simply just an underexplored hardware, as it's only ever poked in GBA mode, and that's how we found that these registers even exist in the first place.
As for the GPU, who knows if some of the glitch bits actually overclock the GPU, which cause the glitches. We may not know for some time...

Atmosphere is just cfw for the switch. It allows you to overclock the switch, but I'm not sure if it's via an application or its built in. I want to mod my switch badly, but I'm in the same camp as you. I'm not gonna just buy a modchip, despite the fact I have a modifiable switch(I'm thinking of just keeping my switch on the current system software until homebrew catches up)

Then we explore FCRAM. Once we figure out how it works on old3ds, then we try to overclock it on the new 3ds. Same with the gpu, but it might be harder to overclock the gpu on the new 3ds. If the only possible thing thats overclockable is FCRAM, that's something at least something! Maybe exploring how FCRAM works with overclocking could help with a lot of things.

 

[Shadow#1]

Atmosphere is just cfw for the switch. It allows you to overclock the switch, but I'm not sure if it's via an application or its built in. I want to mod my switch badly, but I'm in the same camp as you. I'm not gonna just buy a modchip, despite the fact I have a modifiable switch(I'm thinking of just keeping my switch on the current system software until homebrew catches up)

Then we explore FCRAM. Once we figure out how it works on old3ds, then we try to overclock it on the new 3ds. Same with the gpu, but it might be harder to overclock the gpu on the new 3ds. If the only possible thing thats overclockable is FCRAM, that's something at least something! Maybe exploring how FCRAM works with overclocking could help with a lot of things.

"until homebrew catches up"

What do u mean by this?

 

[XRTerra]

"until homebrew catches up"

What do u mean by this?

Until I don't need a mod jig.

 

[Shadow#1]

Until I don't need a mod jig.

Oh that's never gonna happen

 

[XRTerra]

Oh that's never gonna happen

I have faith. Homebrew developers are very talented. Though I might bite the bullet and get a mod jig soon. I really don't want to though.

Something extra, I want to make my own open source homebrew gui thats multipurpose but I barely know how to code. I can write an extremely simple text based program in Python, but that's the extent of my abilities lol. Also I was decent in scratch.mit.edu but that's meant to be easy. Maybe I'll try making a simple text based utility app first, then go from there.

 

[XRTerra]

I'm gonna add to this thread. Since we can overclock the display's refresh rate(thanks to @Sono being a gigachad), is overclocking the resolution possible?

Most games probably won't support it/will break, but it would be fun to see a 3ds home menu in 480p on the native hardware.

 

[Sono]

I'm gonna add to this thread. Since we can overclock the display's refresh rate(thanks to @Sono being a gigachad), is overclocking the resolution possible?

Most games probably won't support it/will break, but it would be fun to see a 3ds home menu in 480p on the native hardware.

Well, it's not possible to add more pixels to the display (the panel itself is 240x800), but *running* the display at a higher resolution is possible (I mean, that's actually how the framerate is limited in the first place, since the pixel clock is not controllable), you just won't see any more of it than what the actual panel can display (the image will be cut off).

Or if you meant running the GPU at a higher resolution, then it's pretty limited, and there are even bugs in hardware which cause it to deadlock if you try running it at a higher resolution. The maximum due to register size limitations is 1024x1024, but there are waaaay too many issues with that to list them all.
Assuming you have some magical display which only needs like a single blanking or something, I could probably make it run at 1020x1020, but no such display exists with such magical timing requirements.
As for the GPU... yeah, it is way too complex to explain, sorry. I think even 800x480 has some issues, so double resolution might not be fully possible.

As for Home Menu running at higher resolution... yeah no, you'd have to patch way too much of it, including the layout files, and other garbage.
However, Mario Kart 7 might be a good place to try to do this patch, as having looked into this years ago, it seemed the easiest to patch, but I did not actually do it, as I had no benefit from it to continue with the experiment, especially since I couldn't even see if it has actually worked or not. You'd have to have the 3DS hooked up to some sort of external display if you'd want to be able to see everything of it.

 

[XRTerra]

Well, it's not possible to add more pixels to the display (the panel itself is 240x800), but *running* the display at a higher resolution is possible (I mean, that's actually how the framerate is limited in the first place, since the pixel clock is not controllable), you just won't see any more of it than what the actual panel can display (the image will be cut off).

Or if you meant running the GPU at a higher resolution, then it's pretty limited, and there are even bugs in hardware which cause it to deadlock if you try running it at a higher resolution. The maximum due to register size limitations is 1024x1024, but there are waaaay too many issues with that to list them all.
Assuming you have some magical display which only needs like a single blanking or something, I could probably make it run at 1020x1020, but no such display exists with such magical timing requirements.
As for the GPU... yeah, it is way too complex to explain, sorry. I think even 800x480 has some issues, so double resolution might not be fully possible.

As for Home Menu running at higher resolution... yeah no, you'd have to patch way too much of it, including the layout files, and other garbage.
However, Mario Kart 7 might be a good place to try to do this patch, as having looked into this years ago, it seemed the easiest to patch, but I did not actually do it, as I had no benefit from it to continue with the experiment, especially since I couldn't even see if it has actually worked or not. You'd have to have the 3DS hooked up to some sort of external display if you'd want to be able to see everything of it.

CTGP-7 even makes use of the n3ds cpu for better rendering, so CTGP-7 could be a good place to start trying to make it run at a higher resolution.

 

[ZeAnmol]

I don't know if overclocking RAM is possible, I'd need to poke around some unknown registers. There are some registers which modify how the FCRAM behaves, which is needed for GBA mode (speculation is that the FCRAM is put into some fixed-timing mode so it can be accessed like SRAM, although I'm not sure how true/false it is, as I lack the skills and equipment to verify it).

As for adding more RAM, I have a very very strong suspicion that the RAM size is hardcoded into the fabric (fancy memory address decoder), and since I think that RAM is not mirrored (haven't tested this myself, but pretty sure that 3dbrew would mention if it was mirrorable, like with the ARM11 bootrom), it's not possible to add more RAM without seeing the newly added region.
Also due to the actual pinout of the RAM chip (that is, you could use jumper wires if it was virtually pin-compatible, but not physically) it might not be possible at all to add a different RAM chip due to CAS/RAS select line count differences.

As for RAM overclocking again, overclocking the RAM would make the 3DS (especially old3DS) a hell of a lot faster. I did some tests, and in some cases the speed difference was unmeasurable due to the massive performance difference compared to cached vs. uncached execution and data access.
While overclocking the new3DS has some slight benefits, overclocking the new3DS without L2 seems to just make it actually SLOWER. Enabling L2 has huge benefits even at non-overclocked mode.
The funny thing happens when you rephrase the old3DS cache size: instead of saying 16k icache and 16k dcache, I could say that the old3DS can store 4096 instructions in cache, and 4096 32bit numbers, none of which are a lot, especially the instruction cache part. No wonder the poor thing is so damn slow!



The name of the mechanism you're describing is either swapping (backed by the swap/swapfile on Linux), or pagefile (backed by the pagefile). What happens is that memory not in active use gets written to disk, then unmapped from virtual memory, to be repurposed somewhere else.
When accessing a swapped virtual memory region, an exception will happen, as the virtual memory region you're trying to access is unmapped. The kernel knows that this memory region was mapped before, so it loads the memory from disk again, then gives back the memory region, being usable again as if nothing has happened.
(Sorry for the janky explaination, currently lack capacity to explain it properly)

I don't think it's possible to map arbitrary memory under userland, but I might be wrong.

If you could map arbitrary memory to arbitrary virtual memory space then you could actually do this trick using hooked exception handlers (loaded from TLS), but you'd have to sadly manage this yourself.

Considering that games and everything are already programmed with fix memory size in mind, this would only be useful for homebrew (if it was even possible in the first place), and even then the homebrew itself would have to manage virtual memory and the other stuff.

By the way, you will find many videos about this on YouTube

 

[Sono]

By the way, you will find many videos about this on YouTube

What kind of videos? Can you please link some?

 

[jeffyTheHomebrewer]

Holy shit, I just tried lenny on my N3DSXL (both screens report TN from 3DSident) and I'm getting a constant 99.1/99.2 FPS here!

 

[Sono]

Holy shit, I just tried lenny on my N3DSXL (both screens report TN from 3DSident) and I'm getting a constant 99.1/99.2 FPS here!

It can actually run much faster (pretty sure I vaguely remember pushing the new3DSXL display to 320FPS and the GPU capping off at around 319-309FPS), but I made the demo slow enough to not damage old3DS screens, as I wanted the demo to be runnable by everyone.
Trying to overclock an old3DS screen past ~90Hz has a chance for the display to turn dark, and start burning in extremely fast due to the controller glitching out.

 

[jeffyTheHomebrewer]

It can actually run much faster (pretty sure I vaguely remember pushing the new3DSXL display to 320FPS and the GPU capping off at around 319-309FPS), but I made the demo slow enough to not damage old3DS screens, as I wanted the demo to be runnable by everyone.
Trying to overclock an old3DS screen past ~90Hz has a chance for the display to turn dark, and start burning in extremely fast due to the controller glitching out.

Oh jesus, it could make an o3ds catch fire?!
Well, in that case what I'd do is have a check at the start BEFORE it doe s anything; If O3DS/2DS, cap overclock to 80hz or so. If N3DS/2DS, no cap, push it to at least 300.