why don't you guys try to port ubuntu or a n64 or gamecube emu?
Because they don't have access to all the hardware. It's also not feasible to port ubuntu with unity and the whole shebang, porting the linux kernel is entirely possible given that we can use all the hardware. There will never be a gamecube emulator, the hardware is not nearly enough powerful.
why dont you guys try to port ubuntu or a n64 or gamecube emu?
Should be able to get n64 working tho.
No way. The PSP could barely do it, and that was by virtue of it having a similar MIPS architecture.
This. The only way for a N64 emulation to work on 3DS, would be to do what Nintendo did on Wii - game specific versions, with speed hacks for each game.
PSX on the other hand, that should be possible. Maybe even in 3D (in the same way that nVidia does on PCs)
it will work depending on the hardware really. If we code efficiently it will work, but if we let the 3DS do all the job then, its not to think about.
I believe i saw portal on the ds, then we can make really decent home brew for the 3ds. We just need a complete suite of the 3ds. I dont know how to run a compiled file or with what to compile in my pc. Although I can compile C code with codeblock and g++.
I believe i saw portal on the ds, then we can make really decent home brew for the 3ds. We just need a complete suite of the 3ds. I dont know how to run a compiled file or with what to compile in my pc. Although I can compile C code with codeblock and g++.
What you saw wasn't exactly "Portal on the DS", but rather, Smea's own game, developed for the DS, with the theme and mechanics of Portal. It was not a port, it was a stand-alone game, much like how Mario64DS was not actually a "Port" per-say, but instead a redesigned and reprogrammed game made for the DS. The only way we could run an N64 emulator with any real speed though would be to activate overclocking on the arm11 cores. We don't even yet know if there's kernel functions that support doing it though, so don't get your hopes up yet. The only thing we know is that the chip's specs should allow running it at 1GHz, or more, but we don't have any information on it as no one has publicly come forward to confirm that it is possible yet.
Literally the first post in the thread has links to ALL the information on how to set up the enviroment, exploit and how to compile.
Just start reading this thread from the beginning. Every 2 or 3 posts has something useful
Is someone experiencing like me glitches drawing in ARM11 mode? I have the problem that randomly the value of some pixels don't change (even if the new value is correctly stored in the buffer, I checked it). Drawing in other position of the screen makes appear gradually the previously not correctly showed pixels. Very strange. Probably some sync problem with GPU.
If you want I can post the ARM11 version of my TE3DS to show more clearly the problem.
It's very annoying now that I can use the touchpad and the joystick. I would like to code somethin new, but I'm stuck on this problem.
If you want I can post the ARM11 version of my TE3DS to show more clearly the problem.
It's very annoying now that I can use the touchpad and the joystick. I would like to code somethin new, but I'm stuck on this problem.
Do you think it has something to do with the random switching issue of the frame buffer? Perhaps, while drawing in arm11 mode, your attempt to correct the flaw by drawing in both buffers is instead confusing the GPU, as it might be pushed into a different mode when accessed in arm11 mode that we're not familiar with. Did you try only drawing in one buffer and seeing if it drew it in both instead as it's supposed to? Heck, maybe you can actually lock the buffers now, who knows, arm11 is kinda a bit uncharted right now, so anything's possible.
I couldn't get the tetris demo's launcher.dat to run on it (the non-qt version).
It will definitely be very slow though
Even Kane's compiled Launcher.dat that demonstrated arm11 code had that issue iirc. The squares often don't draw completely. Overall everything is just really broken.
So, basically, the only way around this issue is loading the entire 3DS OS into RAM from NAND (Or SD), patching it on-the-fly for unsigned code running (Or hard-patching and loading the copy from SD), adding an auto-execute routine (or configurable binary loader) to the boot chain at the end (or just redirecting a system app shortcut to a hardcoded location on SD), and then having the complete, unbroken (but patched) services run the homebrew code from there I guess. In short, the whole OS needs to be reversed before anything, and an OTF patcher needs to be coded to get things started. That'll be a pain, but it's not like it hasn't already been done a few different times. I guess it's either do this, or wait for Smea. I just wish I had the skills to do all that myself. It sucks waiting to get into college courses, seriously.
Hello everyone, here my 3DNES emulator with a lot of bug(it's a prototype to test).
*removed URL - Contains Retail ROM*
Features: Super Mario Bros
The Joypad doesn't work(and my knowledge in NES is very low :c) and the clear-screen doesn't work too.
*removed URL - Contains Retail ROM*
Features: Super Mario Bros
The Joypad doesn't work(and my knowledge in NES is very low :c) and the clear-screen doesn't work too.
I'm not writing in both buffer(http://gbatemp.net/threads/homebrew-development.360646/page-44#post-4936942). Thank you kane for not clearing that first pixel
.Anyway, attached you can find the arm11 version of Te3DS (it's yet the rotated version, had no time to port the mod by snail, maybe later). It's only to show the problem to someone who asked me. I'll update the code when there will be some new things.
PS: Accessing GPU in ARM11 do not crash the code, but commands are igniored. Still can't swap buffer, but at least with my code to identify active buffer, I can use back buffer to assemble a frame and then I can copy it to active frame in one time.. This should help st4rk progresses with his emulators.
