Homebrew Injecting roms into VC? With only the web browser? Sure.

  • Thread starter Thread starter shutterbug2000
  • Start date Start date
  • Views Views 114,403
  • Replies Replies 523
  • Likes Likes 17
Is there a way to get the source of the Loadcode? Also, awesome project, works great and hoping for more great things because of this! I actually bought Shantae just for this :P
 
Quick status update:

1st of all: Thank you KazoWAR for all your work on this!

Now, here's where I stand: I want a way to inject roms and save data(if at all possible). Why? My idea is: since it is temporary, why not make a loader AND backup tool. So:

1: No losing progress in original game.

2. No losing progress in injected game.

So, my plan? Make a "gui". Since there's no way to "scan files"(like a DIR listing in command prompt, for example), we make a predefined list in a text file.
Then, we can, with a selected rom in the list, we can:

1. Inject with save

2. Inject W/O save

3. Backup save to sd

I'm not sure how to get the save though...

Would that be stored in memory like the rom?


I second this.
If a "gui" can be made for rom selection to choose a GBC from the root or /GBC directory that would eliminate using multiple .bin and renamed roms (nothing fancy, for example the rom selection in emulators like Lameboy or GameYoB, Before the Green/Yellow/Red screen and browser crash).

As of now I've been using data management in 3ds settings to create backups of my mario golf VC, You can create multiple backups of the same game that have both the suspend point/savedata and the restore point saved to backup. Made 2 save backups there, one is my vanilla mario golf save, and the other is mario golf with a restore point of my hamtaro ham-hams unite save c:

But yes a save dumping/injecting option in said gui could definitely work with .sav's. they're pretty universal when it comes to compatibility for gb/gbc games/emu's. Restore point dumping/injecting would be awesome too (Obviously not as .sav though, whatever formatting nintendo uses for restore points)
 
I second this.
If a "gui" can be made for rom selection to choose a GBC from the root or /GBC directory that would eliminate using multiple .bin and renamed roms (nothing fancy, for example the rom selection in emulators like Lameboy or GameYoB, Before the Green/Yellow/Red screen and browser crash).

As of now I've been using data management in 3ds settings to create backups of my mario golf VC, You can create multiple backups of the same game that have both the suspend point/savedata and the restore point saved to backup. Made 2 save backups there, one is my vanilla mario golf save, and the other is mario golf with a restore point of my hamtaro ham-hams unite save c:

But yes a save dumping/injecting option in said gui could definitely work with .sav's. they're pretty universal when it comes to compatibility for gb/gbc games/emu's. Restore point dumping/injecting would be awesome too (Obviously not as .sav though, whatever formatting nintendo uses for restore points)


Right now, I've been working on something "basic". Loading the rom based on what physical button is pressed(a,b,l,etc.). So, you could have an: a.gbc ,b.gbc, etc.

Something basic, but cool :D.
 
  • Like
Reactions: TUWieZ
Having some problems:

Code:
#include "spider.h"
#include "fs.h"
 
int SizeCheck(int size);
 
int uvl_entry()
{
    FILE *fin = (void *)0x08F10000;
    unsigned int addr;
    int *buf = 0x18410000;
    int *read_len = 0x08F10020;
    int i;
    unsigned int hid;
    unsigned int offset;
    int VCSize;
    int ROMSize;
 
 
    addr = 0x16800000;
    offset = 0;
hid = 0x10146000;
 
    GSPGPU_FlushDataCache(addr, 0x10000);
    GX_SetTextureCopy(addr, buf, 0x10000, 0, 0, 0, 0, 8);
    GSPGPU_FlushDataCache(buf, 0x10000);
    svcSleepThread(0x400000LL);
 
    offset = 0;
    for (i = 0; i < 0x4000; i++)
    {    //constant in all GB/C ROMs, its part of the Nintendo Logo
        if (buf[i] == 0x6666EDCE)
        {
            offset = addr + ((i - 0x41) * 4);
        }
    }
 
    if (offset != 0)
    {
while (1 < 2){
   
            for (i = 0; i < 0xE100; i += 3)
        {
            buf[i] = 0x00FF0000;
            buf[i + 1] = 0x0000FF00;
            buf[i + 2] = 0xFF0000FF;
        }
       
    GSPGPU_FlushDataCache(buf, 0x00038400);
 
    GX_SetTextureCopy(buf, 0x1F48F000, 0x00038400, 0, 0, 0, 0, 8);
 
    svcSleepThread(0x400000LL);
 
    GSPGPU_FlushDataCache(buf, 0x00038400);
 
    GX_SetTextureCopy(buf, 0x1F4C7800, 0x00038400, 0, 0, 0, 0, 8);
 
    svcSleepThread(0x400000LL);
    i = 0;
            for (i = 0; i < 0xE100; i += 3)
            {
                buf[i] = 0x00FFFF00;
                buf[i + 1] = 0xFF00FFFF;
                buf[i + 2] = 0xFFFF00FF;
            }
 
    //draws solid color to screen
    GSPGPU_FlushDataCache(buf, 0x00038400);
 
    GX_SetTextureCopy(buf, 0x1F48F000, 0x00038400, 0, 0, 0, 0, 8);
 
    svcSleepThread(0x400000LL);
 
    GSPGPU_FlushDataCache(buf, 0x00038400);
 
    GX_SetTextureCopy(buf, 0x1F4C7800, 0x00038400, 0, 0, 0, 0, 8);
 
    svcSleepThread(0x400000LL);
   
        GSPGPU_FlushDataCache(hid, 0x1);
    GX_SetTextureCopy(hid, buf, 0x1, 0, 0, 0, 0, 8);
    GSPGPU_FlushDataCache(buf, 0x1);
   
if(buf[0] == 1){
        IFile_Open(fin, L"dmc:/rom.gbc\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", FILE_R);
                    for (i = 0; i < 0xE100; i += 3)
            {
                buf[i] = 0x0000FF00;
                buf[i + 1] = 0xFF0000FF;
                buf[i + 2] = 0x00FF0000;
            }
    GSPGPU_FlushDataCache(buf, 0x00038400);
 
    GX_SetTextureCopy(buf, 0x1F48F000, 0x00038400, 0, 0, 0, 0, 8);
 
    svcSleepThread(0x400000LL);
 
    GSPGPU_FlushDataCache(buf, 0x00038400);
 
    GX_SetTextureCopy(buf, 0x1F4C7800, 0x00038400, 0, 0, 0, 0, 8);
 
    svcSleepThread(0x400000LL);
                    break;
        }
}
        fin->pos = 0x00;
 
        VCSize = SizeCheck(buf[((offset - addr) + 0x148) / 4] & 0xFF);
 
        IFile_Read(fin, read_len, buf, 0x200);
 
        ROMSize = SizeCheck(buf[0x148 / 4] & 0xFF);
 
        if (ROMSize <= VCSize)
 
        {
 
            fin->pos = 0;
 
            //Overwrites VC ROM 32KB at a time.
 
            for (addr = offset; addr < (offset + ROMSize); addr += 0x8000)
 
            {
 
                IFile_Read(fin, read_len, buf, 0x8000);
 
                GSPGPU_FlushDataCache(buf, 0x8000);
 
                GX_SetTextureCopy(buf, addr, 0x8000, 0, 0, 0, 0, 8);
 
                GSPGPU_FlushDataCache(addr, 0x8000);
 
                svcSleepThread(0x400000LL);
 
            }
 
 
            //Green - Success!
 
            for (i = 0; i < 0xE100; i += 3)
 
            {
 
                buf[i] = 0x0000FF00;
 
                buf[i + 1] = 0xFF0000FF;
 
                buf[i + 2] = 0x00FF0000;
 
            }
        }
        else
 
        {
 
            //Yellow - ROMSize is larger than VCSize
 
            for (i = 0; i < 0xE100; i += 3)
 
            {
 
                buf[i] = 0x00FFFF00;
 
                buf[i + 1] = 0xFF00FFFF;
 
                buf[i + 2] = 0xFFFF00FF;
 
            }
        }
    }
 
    else
 
    {
 
        //Red - Failed to find VC ROM in RAM
 
        for (i = 0; i < 0xE100; i += 3)
 
        {
 
            buf[i] = 0x00FF0000;
 
            buf[i + 1] = 0x0000FF00;
 
            buf[i + 2] = 0xFF0000FF;
 
        }
    }
 
 
    //draws solid color to screen
 
    GSPGPU_FlushDataCache(buf, 0x00038400);
 
    GX_SetTextureCopy(buf, 0x1F48F000, 0x00038400, 0, 0, 0, 0, 8);
 
    svcSleepThread(0x400000LL);
 
    GSPGPU_FlushDataCache(buf, 0x00038400);
 
    GX_SetTextureCopy(buf, 0x1F4C7800, 0x00038400, 0, 0, 0, 0, 8);
 
    svcSleepThread(0x400000LL);
 
 
 
    return 0;
 
}
 
int SizeCheck(int size)
{
    return (0x8000 << (size & 0x0f)) + ((size > 0x0f) ? (0x8000 << (size >> 4)) : 0);
}

The red(first part of while loop) is displayed, but the yellow(second part) crashes back to home. Any ideas?
 
Having some problems:

Code:
-snip-

The red(first part of while loop) is displayed, but the yellow(second part) crashes back to home. Any ideas?

What if you change i to a different letter for each differnt color? eg:
for Green use g, for Yellow use y and for red use r?

idk thats just a thought :)
 
  • Like
Reactions: SinkyChan17
If that's the case, we *could* do this, right?
Check the GB memory mapping, IIRC GB save ram is a plain memory space, so it must exist somewhere near ROM data for normal emulation.
BTW can't see link to KazoWAR build in the first post, instead only big red "GBC is not working"
It will be a good idea If you both collaborate the code and make a single GB/GBC injector. Or even Bette create a github repo and merge code.
I second this.
If a "gui" can be made for rom selection to choose a GBC from the root or /GBC directory that would eliminate using multiple .bin and renamed roms (nothing fancy, for example the rom selection in emulators like Lameboy or GameYoB, Before the Green/Yellow/Red screen and browser crash).
I believe I'll manage to make a bookmark-based ROM selection way much sooner than any ROP/ARM11 based GUI will be made ;)
 
Haven't really been working on that. I would love to have it myself, but here's my concern: piracy. What's going to stop someone from just injecting a full, commercial game into the memory? Nothing. So, I've just been focusing on vc for now.
Lol, how is a full game going to fit into the 3ds' tiny ass memory? It wouldn't even run because there would be 0 mb of RAM left for the game to utilize.
 
  • Like
Reactions: Margen67

Site & Scene News

Popular threads in this forum