Hacking [WIP] KARL3DS - Kernel access on N3DS via Ninjhax + Loadcode

  • Thread starter Thread starter Rokkubro
  • Start date Start date
  • Views Views 938,889
  • Replies Replies 4,457
  • Likes Likes 43
Status
Not open for further replies.
WulfyStylez may I have a link to the 3Dbrew page you talked about that defines the news module problem?

In a nutshell, the news module is just a system module, ie it has nothing to display graphically. The problem with this though is that we need gsp (graphics stuff) in order to gspwn in to ARM11 kernel and into ARM9. So no bueno.

Also in case anyone's curious, I've been flooded with homework for the last 3 weeks, hence not a ton of progress on process stuff. Really sucks.
I still don't understand the logic behind adding stress onto the existing stress of tests...
 
In a nutshell, the news module is just a system module, ie it has nothing to display graphically. The problem with this though is that we need gsp (graphics stuff) in order to gspwn in to ARM11 kernel and into ARM9. So no bueno.

Also in case anyone's curious, I've been flooded with homework for the last 3 weeks, hence not a ton of progress on process stuff. Really sucks.
I still don't understand the logic behind adding stress onto the existing stress of tests...

Excessive homework is a net loss for people who don't really need it :\
 
So it should definitely be able to run a GBA game and a 3DS game at the same time.

Nope, AGB_FIRM exists as a separate FIRM because of all its strict memory requirements. Because the ARM7TDMI can't do virtual memory mapping like the other CPUs, its addresses are hardcoded to a few memory areas in the system. They all seem to be within what we previously referred to as the ARM9's internal memory (the 0x08000000 region). You won't be able to run NATIVE_FIRM with all those memory regions free. I documented a night's worth of research on the ARM7 here if anyone's curious to more-or-less all I know. It's definitely really neat.
 
So I guess we could have a DS/gba rom/homebrew loader right? Or maybe add support to execute those files (gba/ds files) directly from the ninjhax homebrew loader? (maybe it'd even be possible to stretch the top screen display in DS/gba mode to the maximum possible size?)

It'd save us from coding an effective gba emu and would bring gba & ds homebrews to the 3ds without requiring any flashcart. If that's possible that'd also save us from coding a few emulators that were already working good on the DS (NES, Master System...) and also add a lot of cool homebrews to the 3DS homebrew catalog.

Screw the custom firmware guys, let's do this instead, that'd be way more useful to the scene :D
 
How is the progress for KARL 3DS coming?
I've been doing a bunch of unrelated 3DS things that won't make it into the final product (there's one I might show off once I get it working, maybe), and Shiny's been super busy with school. Same with Daz, I think. Once we get our ARM11 stuff going, though, we'll make a lot of progress quite quickly. The reason that's taking so long is that we really, really want to do it as properly as possible. This is based off our own personal research platform after all, so we need that to be quite robust.
Honestly we could do the dumb vector hijacking stuff GW does and have our ARM11 stuff up to snuff for release in a few days. That's like, objectively the wrong way to do it though. Plus it wouldn't contribute to our own research in the slightest since all we could do is some lame process patching (which we already have a dirty method to do until we're ready).
 
Beware though, as we say in french "le mieux est l’ennemi du bien".

That means you can turn something good to bad a thing by wanting it to be too perfect.
It's not so much a perfection thing really, it's just that when it comes to coding, the lazier you are in the beginning, the more painful it is to support that code in the long run.
 
Nah, there's no problem. They said that stuff is just pretty slow because of school, so when that's all sorted out, they said they'll finish with Arm11 and move on to a faster process. :)
 
It'd save us from coding an effective gba emu and would bring gba & ds homebrews to the 3ds without requiring any flashcart.
I wouldn't even bother. This would be limited to still using DS mode, meaning it'd still rely on Nintendo's craptacular scaling filter (which I think is bicubic and looks awful). For DS there's no way around that and it'd be cool to see a loader but I don't know, that's piracy and all. For GBA, an actual emulation solution implementing gPSP would be way better, with linear filtering support, savestates, button mapping, the likes.

If that's possible that'd also save us from coding a few emulators that were already working good on the DS (NES, Master System...) and also add a lot of cool homebrews to the 3DS homebrew catalog.
NES on the DS is pretty bad, the DS can't downscale anything, all games looked badly distorted - and on top of that you have the 3DS' own filter, filtering a badly distorted image and adding even more distortion. I's an abomination. Compare that to how crisp and clear the VC NES games look, they're running at native 240p. Same for master system.

I never emulated anything on the DS past GB/GBC for those reasons. The console had a bad resolution for emulation and the hardware couldn't do downscaling properly. You just have to look at Gameyob and how bad the DS version compares to the new scaling engine on the 3DS port, or the aforementioned nesDS vs NES VC.

Retroarch for 3DS is progressing, so we have a few cool things to look forward to.
 
  • Like
Reactions: Margen67
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum