4dsdev
Views: 614,054 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 11-23-17 05:09 PM
Guest:

Main - Posts by StapleButter

Pages: 1 2 3 4 5 6 7 8 9 10
StapleButter
Posted on 11-25-14 01:58 PM, in GPU stuff to investigate Link | #30
Posted by smea
- see if it's possible to reset the GPU once it "freezes" <= most important thing anyone could ever do ever (could be just GSP freezing waiting for something ? could be that GPU is still waiting for us to send it something more until it does anything ? who knows !)

Just make sure to not enter a gspWaitForP3D() call or you're frozen for good. Unless you have another thread that realizes rendering is taking ways too long, and fake-signals the P3D event to free the first thread and resets the GPU.


Speaking of that, I don't know about you smea but I have observed subpar performance. Back then it took about 6ms to render like 4 triangles, and now the hardware renderer's display lists take about 10ms to execute, even though the polygon counts are still far from the theoretical limits.

neobrain's theory on that is that the GPU is in some power-saving mode. Would make sense.

Where was the GPU reset sequence taken from, already?


Another thing is about command 0x0100. It's commonly set to 0x00E40100. The E4 there got my interest, even though last time I tried to mess with it, nothing changed.

E4 = 11 10 01 00 = 3 2 1 0

I suspect that, used maybe along some other bit, this enables color component swizzling. Hell, maybe it's one of those bits I thought were just being weird.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 11-26-14 07:29 PM, in Ninjhax APT reboot Link | #31
The issue with Ninjhax is that APT stuff like return to home menu or sleep mode don't work. While return to home menu isn't very important (just having a button that does nothing is meh), sleep mode is more desirable.

In our case, APT is already initialized, and the event handles that were given to the game are lost.

Of course, doing the normal APT init sequence fails because it's already inited.


I observed that when calling APT::Initialize with flags=1, it succeeds and returns handles. However those handles never get signaled.

Might be onto something.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 11-28-14 08:30 PM, in Welcome to 4dsdev! (rev. 2 of 11-28-14 08:31 PM) Link | #34
Hah, don't trust the footer. I actually modernized it internally.

I'll also modernize the interface a little bit (a post toolbar or quick reply wouldn't be too much imo, for example).

But hey, this is secure, fast, straightforward, and has a low footprint. Compared to the typical bloated enterprisey software and its "we have tons of resources so who cares if we waste them" philosophy, it's not bad at all, really.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 11-29-14 04:38 PM, in Welcome to 4dsdev! Link | #36
Indeed. There's a thread about all that junk in the site feedback forum.

I can try to make a theme, but I kinda suck at graphics design.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-01-14 06:20 PM, in blargSnes -- SNES emulator for the 3DS Link | #40
Version 1.2 is out. Will update this (and the website) whenever I'm not lazy.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-01-14 06:36 PM, in GPU abstraction layers Link | #41
So this thread is going to list the current known efforts for a stable 3DS graphics layer.


ctrgl by minexew

This is the most interesting I guess. ctrgl is aiming at becoming an OpenGL implementation.

There are still some nonstandard bits that could be made standard, but it's being worked on. So far it looks pretty close to standard OpenGL.


blargGL by StapleButter

(source here)

blargGL isn't aiming at being an OpenGL implementation. It's a thin wrapper around ctrulib's GPU API. Its role is mostly to hide the ugly details like the specific order in which the various GPU-related functions have to be called.

It was made for blargSNES, but could be used anywhere really (just keep in mind it's under the GPL). It also lacks a few features (like index arrays).

The blargSNES codebase also contains a simple block-based VRAM allocator in mem.c.


gs.c by smealum

This is used in smealum's 3dscraft. Not really a graphics layer per se, this code provides support for matrix stacks and VBOs.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-02-14 08:55 AM, in GPU abstraction layers Link | #43
What comes to my mind is the function you coded for uploading shaders.

OpenGL has glShaderBinary.

Not that it matters much, though. That part is pretty much specific to the 3DS.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-02-14 07:52 PM, in DSP reverse engineering Link | #45
I wanted to start by the basics and determine how the DSP memory is mapped, and what is what on the DSP side.

DSP RAM goes from 1FF00000 to 1FF7FFFF. So far we have:

1FF00000 - 1FF3FFFF? -> program RAM (DSP exception vectors at 1FF00000+)
1FF40000 - 1FF5FFFF -> data RAM region 1 (1FF50000-1FF5FFFF exposed read-only to ARM11 userland)
1FF60000 - 1FF7FFFF -> data RAM region 2 (1FF70000-1FF7FFFF exposed read-only to ARM11 userland)

Does the program RAM end at 1FF3FFFF or 1FF1FFFF? (if then, what's in the leftover space?)

The DSP can only address 65536 words without switching banks or something in the like. That is, 128K. Assuming the two data RAM regions map to X-RAM and Y-RAM, and the program RAM goes from 1FF00000 to 1FF1FFFF, what would be in the leftover space? DSP-side I/O?

Well uh, clearly this DSP is able to address more than 128K of memory. There has to be a way to select which chunk of memory is being accessed, like on the SNES where they have DBR and PBR to specify which banks the CPU will access.


The docs mention movp and movd instructions, moving from/to data/program RAM. But nothing precises if the regular mov instructions access program RAM or data RAM.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-03-14 07:29 PM, in 4dsdev cosmetics thread Link | #47
First attempt at a theme is on.

We still need a banner, though.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-03-14 07:52 PM, in 4dsdev cosmetics thread (rev. 2 of 12-04-14 03:29 AM) Link | #49
Font used is Roboto Regular. I like it... maybe you can try changing your font size setting in your profile.

Alternately maybe this is some cross browser shit... or the font really looking bold. It's a little bolder than your typical font, but I didn't expect it to be that noticeable.

This theme is a first incarnation after all, so I can change that :)

Also, I need to add browser-specific versions for gradients. The theme looks like shit on mobile browsers.


Oh and maybe we'll need new icons/whatever for what little graphics this board has. But that shit is low priority, really.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-04-14 08:50 AM, in Homebrew coding pitfalls (rev. 2 of 12-08-14 06:27 PM) Link | #50
Threading

Threading on the 3DS is cooperative. That means that threads in your app need to be responsible and not take all the CPU time.

Calling any system function (anything that uses SVC calls) triggers scheduling and gives other threads a chance to run.

However, if you have a thread that does time-consuming operations without any system call, it will prevent other threads from running until it terminates or does a system call.

In such cases, you should insert regular dummy system calls (for example svcSleepThread(1)) within the operations.

This restriction only applies to threads from the same process on the same CPU core.


Memory allocation

When passing buffers to GPU or CSND calls, they must be allocated with linearAlloc().


Writing assembly code

Take note of this when writing assembly code in a userland app.

Code goes in .text, data goes in .data.

Mess this up and you'll crash. It may seem common sense, but it is important on a system like the 3DS. The 3DS security implies that .text is read-only and code can't execute from .data.

(in particular, you may run into this issue if you're porting ASM code from GBA/DS homebrew)

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-04-14 01:03 PM, in DSP reverse engineering (rev. 5 of 12-04-14 01:27 PM) Link | #51
Dunno. I'm not really on that either.


Anyway, have more shiz.

Binary loading process

Binary is verified and segments are written to their appropriate locations in DSP RAM. As far as I can see, they're written directly, there is no fancy specific transfer mechanism involved. At this point it seems that the DSP isn't running.

Bits are set in some registers that control DSP RAM mapping (0x1EC40000, 0x1EC40008).

pdn:d command 0x100C0 sent 3 times:
1. params = 0, 1, 0
2. params = 1, 1, 0
3. params = 1, 1, 1

If bit 0 in 0x1ED03008 is zero, sets it to 1 and waits 0x60 cycles

Waits until bit 2 in 0x1ED0300C becomes zero

If bit 0 in 0x1ED03008 is nonzero: clear bits 9-11 in 0x1ED03008, set 0x1ED03010 to 0, set 0x1ED03018 to 0xFFFF, wait 0x60 cycles, issue reads from 0x1ED03024, 0x1ED0302C and 0x1ED03034 (read values ignored), wait 0x60 cycles

Set some bit (val unknown, maybe comes from DSP binary?) in 0x1ED03008, wait 0x60 cycles

Clear bit 0 in 0x1ED03008, wait 0x60 cycles

Set 0x1ED03014 (semaphore mask) based on that same unknown value, wait 0x60 cycles

If some bit is cleared: read DSP reply from command slot 0, wait 0x60 cycles; repeat until reply is 1
Repeat above for command slots 1 and 2

Write shit to 0x1ED03008 and 0x1ED03014, origins not quite known

Bit 11 in 0x1ED03008 is set to one then zero.
Simultaneously, bit 15 in 0x1ED03014 is set to zero then one.

*(vu16*)0x1ED03008 |= 0x0800;
*(vu16*)0x1ED03014 &= ~0x8000;
*(vu16*)0x1ED03008 &= ~0x0800;
*(vu16*)0x1ED03014 |= 0x8000;

Do those registers really match what is documented in NO$GBA's help text? The bits that are toggled here would be interrupt enable bits; makes little sense to toggle them if that's what they are. My guess is that they play a role in resetting the DSP?

This seems to also be done when unloading the DSP binary, so not quite sure.

Then there are two commands sent to cdc:DSP

cmdbuf[0] = 0x70040
(byte) cmdbuf[1] = 1

cmdbuf[0] = 0x80040
(byte) cmdbuf[1] = 1


Binary unloading (and turning the DSP off)

Same shit as above with 0x1ED03008 and 0x1ED03014.

Then it waits for bit 15 in 0x1ED0300C to become zero. Writes 0x8000 to 0x1ED03030 and does some wait loop (0x60 cycles).
-> sends command 0x8000 via command slot 2
then waits for bit 12 in 0x1ED0300C to become one. Reads reply from 0x1ED03034.

Reply is ignored.

Waits for bit 0 in 0x1ED03008 to become zero. Sets that bit to one, waits 0x60 cycles. Waits for bit 2 in 0x1ED0300C to become zero.

Sends pdn:d command 0x100C0.
cmdbuf[0] = 0x100C0
(byte) cmdbuf[1] = 1
(byte) cmdbuf[2] = 1
(byte) cmdbuf[3] = 0

Sends same command with params 0, 1, 0

Sends commands to cdc:DSP

cmdbuf[0] = 0x70040
(byte) cmdbuf[1] = 0

cmdbuf[0] = 0x80040
(byte) cmdbuf[1] = 1

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-04-14 03:42 PM, in DSP reverse engineering Link | #52
Ugh. Apparently it doesn't like it if a usermode app tries to use pdn:d or cdc:DSP, even if they're in the exheader.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-05-14 03:23 AM, in Welcome to 4dsdev! Link | #56
A Like button could be a nice idea, heh.

However I'm not for hooking that to some sort of notification system. It's kinda annoying to get notifications at GBAtemp from all the people who like your posts :P

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-05-14 03:24 AM, in 4dsdev cosmetics thread Link | #57
That's coming, whenever I get around having a decent banner :)

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-05-14 06:10 AM, in Welcome to 4dsdev! Link | #59
Haha, release some homebrew project and you'll see what I mean :P

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-10-14 08:46 AM, in 3DS homebrew IRC channel (rev. 2 of 07-25-15 12:35 PM) Link | #60
Our IRC channel is there:

#3dsdev on irc.efnet.net

IRC is usually a good option if you need to get quick answers to your questions. (it's not an excuse for not reading documentations, though)


Posts from this board will also be reported in that IRC channel. coming soon!

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-10-14 06:39 PM, in Testing thread nevermind me Link | #61
This is meant to test post reporting. Don't look at it, it's crap.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-10-14 06:41 PM, in Testing thread nevermind me (rev. 3 of 12-10-14 06:48 PM) Link | #62
dfsgsdgfds


Oh and I need to make the board not awfully wide, too.

And perhaps make it show who is browsing forum X or thread Y, not just on the index page.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

StapleButter
Posted on 12-10-14 07:19 PM, in Testing thread nevermind me Link | #63
Okay uh, this shit made its time. Goodbye!

____________________
blargSNES -- SNES emu for 3DS
More cool stuff
Pages: 1 2 3 4 5 6 7 8 9 10

Main - Posts by StapleButter

Page rendered in 0.060 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 99/99, time: 0.031 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.