Homebrew Homebrew Development

[PewnyPL]

What's the 0x0D in front of the 0x0DAB(x coordinate) for?

So in order to get the x coordinate you would need to use (xCoord = read_word(0x1014280C) >> 8) in order to remove the two bytes on the end, but how would I remove the t3wo bytes on the beginning(the 0xAB) ?

I'm not a specialist at bitwise operations, but you could do it like this:
xCoord = read_word(0x1014280C) << 8;
xCoord = xCoord >> 16;
This should shift it left, removing the first byte, then shift it to right removing the last byte and placing the number in the lower bytes (resulting in the correct number).

This is of course assuming, that the value in that part of memory is always doubled like this. (as in, AB0DAB0D, or for example AA00AA00)

 

[ernilos]

Yes, please share the source, I would love to look at your 3d code.

The code it's ugly as hell, so i don't mind share the source, but I can share the 3D code if you want
http://pastebin.com/1204nKSv

Edit: Just change *(u8*)0x10144000 to *(u8*)0x10144001

 

[the-green]

nice, let's hope to see in the future a homebrews channel & why not DS/3DS ROM's manager !!

 

[CalebW]

I'm not a specialist at bitwise operations, but you could do it like this:
xCoord = read_word(0x1014280C) << 8;
xCoord = xCoord >> 16;
This should shift it left, removing the first byte, then shift it to right removing the last byte and placing the number in the lower bytes (resulting in the correct number).

This is of course assuming, that the value in that part of memory is always doubled like this. (as in, AB0DAB0D, or for example AA00AA00)

I thought that by shifting it left 8 bits would just add a 00 byte to the end...

 

[Abcdfv]

nice, let's hope to see in the future a homebrews channel & why not DS/3DS ROM's manager !!

I want to see a better web browser. I'm not sure how much of it, but I know the 3DS's browser uses some open source code, so hopefully that should give a better base to build from.

The code it's ugly as hell, so i don't mind share the source, but I can share the 3D code if you want

http://pastebin.com/1204nKSv

Is anyone's code pretty right now lol...

 

[CalebW]

The code it's ugly as hell, so i don't mind share the source, but I can share the 3D code if you want
http://pastebin.com/1204nKSv

Thanks for that, but I was also interested in how you drew your graphics with the 3d offset...

By the way... ugly source code doesn't bother me, my Breakout source is the same way...

 

[PewnyPL]

I thought that by shifting it left 8 bits would just add a 00 byte to the end...

Well, if you first shift it left, it will add it. But when you, afterwards, shift it right by 16 bits, it will remove it AND the last byte read from memory.

 

[Abcdfv]

Well, if you first shift it left, it will add it. But when you, afterwards, shift it right by 16 bits, it will remove it AND the last byte read from memory.

This might be a silly question, but what exactly do the memory shifts accomplish? Does it have anything to do with this "NX" bit I'm hearing about sometimes?

 

[CalebW]

Ernilos I think somethings wrong with the 3D, I see two images and it makes my eyes hurt looking at it.(And that doesn't happen when I look at the 3D...)

Perhaps you could also add a pause screen...

 

[CalebW]

This might be a silly question, but what exactly do the memory shifts accomplish? Does it have anything to do with this "NX" bit I'm hearing about sometimes?

Memory shifts move the bits(8 bits equals one byte) over to the left or right. So if you have B9(one byte) which would be 1011 1001 in bits, and you wanted to remove the nine you would use B9 >> 4, which would move the 1001 bits to the right thereby deleting them. If you used B9 >> 2, your bits would look like: 0010 1110 which would be 2E.

 

[Abcdfv]

Memory shifts move the bits(8 bits equals one byte) over to the left or right. So if you have B9(one byte) which would be 1011 1001 in bits, and you wanted to remove the nine you would use B9 >> 4, which would move the 1001 bits to the right thereby deleting them. If you used B9 >> 2, your bits would look like: 0010 1110 which would be 2E.

I understand that, my question was more why are you trying to delete the bits? just so everything fits into the proper exploited memory locations? Sorry if my question isn't clear, but I don't know enough about what's being discussed to phrase it better.


for Gateways loader Snake2 fails and gives a handled exception, requiring a system restart. Worked 1st try using waffles. I'm not seeing the double images, but it looks like my snake has a partially transparent pixel for it's head, with 3D on and off.

 

[CalebW]

I understand that, my question was more why are you trying to delete the bits? just so everything fits into the proper exploited memory locations?


for Gateways loader Snake2 fails and gives a handled exception, requiring a system restart. Worked 1st try using waffles. I'm not seeing the double images, but it looks like my snake has a partially transparent pixel for it's head, with 3D on and off.

No, because the offset at 0x1014280C is 0xAB0DAB0D with 0x0DAB being the x coordinate, it's right in the middle of the offset, so you need to remove the first and last byte in order to get the correct read.

It's not really "double images", it's more blurry.

 

[Abcdfv]

No, because the offset at 0x1014280C is 0xAB0DAB0D with 0x0DAB being the x coordinate, it's right in the middle of the offset, so you need to remove the first and last byte in order to get the correct read.

It's not really "double images", it's more blurry.

Ok, I understand(better) now. Still not fully, but I'll learn more about memory addressing and such as I get into more advanced books. Not gonna try to get you to give me a lecture when I don't know enough yet to do anything with it.

Yeah, I see that too. to my unprofessional self it looks like the sprites just aren't filling out the "space" between the pixels, making each pixel "pop" rather than the image as a whole. But it could be something in the code...

 

[Coto]

What's the 0x0D in front of the 0x0DAB(x coordinate) for?

So in order to get the x coordinate you would need to use (xCoord = read_word(0x1014280C) >> 8) in order to remove the two bytes on the end, but how would I remove the t3wo bytes on the beginning(the 0xAB) ?

i'd use

#include <stdio.h>
#include <stdint.h>
 
int main(){
  uint32_t u32val=0,*u32p;
  u32p=&u32val;
  *u32p=0xAB0DAB0D; //u32p (fake 0x1014280C) equals to 0xAB0DAB0D
 
  printf("%x",(*u32p&0xffff00)>>8); //xxxxxx minus 8 bits (right)
}

throws:
0xdab (compiler ignores zero if absolute on left side)

 

[YoshiInAVoid]

Can someone show me an example of double buffering?

 

[CalebW]

Can someone show me an example of double buffering?

I don't think it's possible right now, as we can't separate the framebuffers...I may be wrong though.

 

[YoshiInAVoid]

I don't think it's possible right now, as we can't separate the framebuffers...I may be wrong though.

Is this not all that is needed?

#define FRAMEBUFFER_SEL 0x20184E59
#define TOP_LEFT_FRAME1 0x20184E60
#define TOP_LEFT_FRAME2 0x201CB370
#define TOP_RIGHT_FRAME1 0x20282160
#define TOP_RIGHT_FRAME2 0x202C8670
#define SUB_FRAME1 0x202118E0
#define SUB_FRAME2 0x20249CF0

 

[profi200]

#define FRAMEBUFFER_SEL 0x20184E59

Nope, read 3dbrew.

http://3dbrew.org/wiki/LCD#0x1EF00X78

€:
Not accessible on ARM9.

 

[CalebW]

Is this not all that is needed?

#define FRAMEBUFFER_SEL 0x20184E59

I don't know what this is for...where did you find it?

 

[Abcdfv]

I don't know what this is for...where did you find it?

It's part of the CTRUlib(sp?) Smea released, but it's currently useless to us since we don't have arm11 execution.