Hacking Official SaltFW - "Slim Alternative Firmware"

  • Thread starter Thread starter Shadowhand
  • Start date Start date
  • Views Views 88,070
  • Replies Replies 456
  • Likes Likes 7
Nice, variety is always a good thing.

The SALT team have contributed huge amounts to the betterment of the scene, particularly in documenting the architecture of the 3DS' system software. More than any other group or individual, and an immeasurable amount more than you (immeasurable because thus far you have contributed nothing).
More than any other group or individual
Yellows8's contributions alone debunk that claim.
 
Okay, at this point you're just being an asshole for the sake of it. This is not how you gain the support of the community or fellow devs.

The SALT team have contributed huge amounts to the betterment of the scene, particularly in documenting the architecture of the 3DS' system software. More than any other group or individual, and an immeasurable amount more than you (immeasurable because thus far you have contributed nothing).

Perhaps you should have done a little more research beforehand then? Bitter and unwelcoming is what GBAtemp does best.

I can think of at least half a dozen devs that have either left the scene, or made their work private in the past 12 months as a direct result of the GBAtemp's welcoming embrace (including the SALT team).

I'm not being an asshole, I'm just saying things the way I see them.

It's one thing to do thing privately and not release them, and another thing to work privately but release the product publicly (without source code).
While both don't advance anything, the second one is worse because we know you've got this thing, but we can't use it because you decided to keep it closed source. This isn't just for the SALT team. It's the same for NTR dev, and "simple 3ds to cia converter" dev.

Check my post count, it says 50. I'm not a GBATemp regular. I don't even visit this site to read comments. If I had known, I really wouldn't release it publicly.
I've come to conclusion that even if I had done what @Aurora Wright did (post in upstream's thread, without a rename), people would still be salty. At least this way her thread is clean.
 
I'm not being an asshole, I'm just saying things the way I see them.

It's one thing to do thing privately and not release them, and another thing to work privately but release the product publicly (without source code).
While both don't advance anything, the second one is worse because we know you've got this thing, but we can't use it because you decided to keep it closed source. This isn't just for the SALT team. It's the same for NTR dev, and "simple 3ds to cia converter" dev.

Check my post count, it says 50. I'm not a GBATemp regular. I don't even visit this site to read comments. If I had known, I really wouldn't release it publicly.
I've come to conclusion that even if I had done what @Aurora Wright did (post in upstream's thread, without a rename), people would still be salty. At least this way her thread is clean.

Honestly I don't get why people are just so salty over this. I've seen a few of these, and well who really cares. If its end product is going to be different then let it be.

Because I would rather wait, and let something flourish instead of bashing it into the fucking ground.
 
Last edited by n1-d,
It's one thing to do thing privately and not release them, and another thing to work privately but release the product publicly (without source code).
While both don't advance anything, the second one is worse because we know you've got this thing, but we can't use it because you decided to keep it closed source. This isn't just for the SALT team. It's the same for NTR dev, and "simple 3ds to cia converter" dev
 
After extensive testing (two rounds) SaltFW is confirmed to be 0.1s faster than Luma.
lmao you forgot to tell people this was after 'extensive defragmentation' as well :P

If you wanna make it a lot slimmer, remove all console code and replace error messages with screen colors. Here's my sample implementation:

Code:
void clear_screen(u8* fb, u32 rgb){
    u32 sz = fb_sz(fb)/3;
    u8 packet[] = {rgb & 0xFF, (rgb >> 8) & 0xFF, (rgb >> 16) & 0xFF};
    while (sz--)
        memcpy(fb + sz*3, packet, 3);

    return;
}

All fb_sz() does is return the size of the framebuffer (either 400*240*3 or 320*240*3, depending on top or bottom screen)
 
Last edited by Wolfvak,

Site & Scene News

New Hot Discussed User Submitted