Wii backup Manager for Windows

Discussion in 'Wii - Backup Loaders' started by fig2k4, Oct 30, 2009.

Oct 30, 2009

Wii backup Manager for Windows by fig2k4 at 2:17 PM (4,121,633 Views / 12 Likes) 2,800 replies

  1. FoGBaV

    Newcomer FoGBaV Advanced Member

    Joined:
    Jan 31, 2008
    Messages:
    82
    Country:
    Sweden
    Yes ... please ... WBFS file format support ... this would be great ...

    And ... an HTML-Report-Export of ALL Games ... games on HDD1 ... Games on HDD2 ... etc ...

    i'm loosing my orientation on all the HDDs ...8)
     


  2. fig2k4
    OP

    Member fig2k4 GBAtemp Advanced Fan

    Joined:
    Oct 30, 2009
    Messages:
    758
    Location:
    Scotland
    Country:
    United Kingdom
    Thanks for your replies. I'll address the comments and suggestions tomorrow, I need some sleep. [​IMG]

    I've just posted version 0.1.5 with FAT32 and WBFS file support. I have tested it a lot and it seems to be working fine. I've converted from WBFS to CISO to WBFS files and loads of different combinations. I checked the .wbfs files byte for byte against the output from wbfs_file using Hxd hex editor's file compare function and the files were identical.

    As you probably know, hermes IOS 222 rev 4 is needed to use the FAT32 drives in Configurable..

    A side note: Be careful when formatting drives if you're not sure what you're doing. Chances are, you've got other stuff on your FAT32 drive that you'll lose if you format. Just don't blame me [​IMG]
     
  3. OtakuGamerZ

    Member OtakuGamerZ GBAtemp Fan

    Joined:
    Feb 19, 2009
    Messages:
    459
    Country:
    United States
    Thanks!!!! [​IMG]
     
  4. redia

    Member redia GBAtemp Fan

    Joined:
    Mar 9, 2008
    Messages:
    371
    Country:
    Switzerland
    I checked a couple of files.
    and I confirm that too.
    edit 3 please disregard this confirmation. I only checked the last chunk for each dump... should have checked all

    am I missing something or there is no isociso direct conversion ?

    thanks for the hard work.
    Cheers,
    R

    edit :
    I noticed you are not creating the info file.. not a big deal as we are accessing the file through your manager, but I just thought I would point it out.


    edit 2 :
    I am testing more files.. and there are some differences.
    if you need details let me know. I will try to find what exactly.
     
  5. oggzee

    Member oggzee GBAtemp Addict

    Joined:
    Apr 11, 2009
    Messages:
    2,335
    Country:
    Slovenia
    Nice job!
    Although I am getting some differences.
    I have tried it with wii sports and the n_hd_sec doesn't match, are you calling wbfs_trim(), it should take care of that.

    This is hexdump from wbfs_file:
    00000000 57 42 46 53 00 13 f0 00 09 15 00 00 01 00 00 00 |WBFS............|

    This is hexdump from your manager:
    00000000 57 42 46 53 01 18 24 00 09 15 00 00 01 00 00 00 |WBFS..$.........|

    Now, if the n_hd_sec doesn't match the file size, cfg loader will refuse to load it, with an error:
    hd num sector doesn't match

    Also, running wbfs_file on that created file reports this:
    wbfs_file.exe i:/wbfs/RSPP01.wbfs ls
    hd num sector doesn't match

    File size is: 668991488, that is 1306624 sectors, in hex: 0013F000 which you can see in the first hexdump.
    The value in your header is: 01182400 which is 18359296 sectors, giving 9399959552 file size, which is of course the full dual layer size that the program begins with.

    Also another little difference, but this is not important, it seems you use 0xFF to fill the unused padding (same as wiiscrubber does) while libwbfs uses 0x00, so the resulting .wbfs file differ in this too in the last padding block.

    I hope i haven't missed something...
     
  6. redia

    Member redia GBAtemp Fan

    Joined:
    Mar 9, 2008
    Messages:
    371
    Country:
    Switzerland
    ok I guess I don't need to give any more details.. lol.. thanks oggzee.
    if I am not mistaken we don't really care about the FF padding.. or does it make a difference ?

    R
     
  7. oggzee

    Member oggzee GBAtemp Addict

    Joined:
    Apr 11, 2009
    Messages:
    2,335
    Country:
    Slovenia
    Yes, as i said, it's not important, it's never used.
     
  8. fig2k4
    OP

    Member fig2k4 GBAtemp Advanced Fan

    Joined:
    Oct 30, 2009
    Messages:
    758
    Location:
    Scotland
    Country:
    United Kingdom
    Hi, I think i know where the problem is. Haven't debugged it yet, but it looks like the header isn't rewritten after the trim(). The FF are empty blocks and the num sectors are still at the full size. I'll try to find why it happens.

    Edit: I've fixed the num sectors problem. I commented out the code in the trim() function, duh. And the info text file was deleted straight after it was created, silly last minute copy n paste error. I'll test some more to make sure the header is getting written correctly when the file is split.
     
  9. redia

    Member redia GBAtemp Fan

    Joined:
    Mar 9, 2008
    Messages:
    371
    Country:
    Switzerland
    fig2k4,

    great news.

    sorry I do not mean to pressure you, but do you have any idea if you plan to implement the titles.txt ? (notice I am not asking "when" [​IMG])
    about isociso.. did I miss it, or it is not implemented ?
    and once again I am offering you to translate the software for you if you need

    Cheers,
    R
     
  10. Wiimm

    Member Wiimm Developer

    Joined:
    Aug 11, 2009
    Messages:
    2,078
    Location:
    Germany
    Country:
    Germany
    Filling with 0x00 is the better solution because some file systems support sparse files: If whole disc blocks contains only zero bytes there is no need to allocate disc space for that block. Most modern unix files systems supports sparse files.
     
  11. fig2k4
    OP

    Member fig2k4 GBAtemp Advanced Fan

    Joined:
    Oct 30, 2009
    Messages:
    758
    Location:
    Scotland
    Country:
    United Kingdom
    As I suspected, it was the block allocation table that had the FFs. It was a bug in the code I converted from.

    The trim() function had this..
    // make all block full
    memset(p->freeblks,0,p->n_wbfs_sec/8);

    When it should've been...

    memset(p->freeblks,0,ALIGN_LBA(p->n_wbfs_sec/8));

    and in Delphi..

    ZeroMemory(FreeBlocks, AlignLBA(NumWBFSSectors div 8));

    So I was only filling up to the size of the table with zeros, not to the end of the block, causing the free blocks (FF) to remain.
     
  12. oggzee

    Member oggzee GBAtemp Addict

    Joined:
    Apr 11, 2009
    Messages:
    2,335
    Country:
    Slovenia
    Ah I haven't checked the offset of the 00 vs FF difference carefully, I just assumed it was a block of padding data.
    Anyway, glad to hear you solved that, I take it you fixed the num_hd_sec too...
     
  13. oggzee

    Member oggzee GBAtemp Addict

    Joined:
    Apr 11, 2009
    Messages:
    2,335
    Country:
    Slovenia
    This made me check if that could be a problem in the existing code, but it doesn't seem to be, because:
    p->freeblks = wbfs_ioalloc(ALIGN_LBA(p->n_wbfs_sec/8));
    wbfs_memset(p->freeblks,0xff,p->n_wbfs_sec/8);
    And while it is true that the freeblk allocation is lba aligned, only p->n_wbfs_sec/8 is used.
    The rest is already set to 0 because wbfs_ioalloc already does that (at least my variant does it)
    So, the original
    memset(p->freeblks,0,p->n_wbfs_sec/8);
    Will work fine and changing it to
    memset(p->freeblks,0,ALIGN_LBA(p->n_wbfs_sec/8));
    Will be ok too.
    In other words, the current wbfs_file does not have this problem.
    I assume you changed this:
    wbfs_memset(p->freeblks,0xff,p->n_wbfs_sec/8);
    To:
    SetMemory(FreeBlocks, 0xFF, AlignLBA(NumWBFSSectors div 8));
    Or whatever the delphi syntax is...
     
  14. fig2k4
    OP

    Member fig2k4 GBAtemp Advanced Fan

    Joined:
    Oct 30, 2009
    Messages:
    758
    Location:
    Scotland
    Country:
    United Kingdom
    That's basically what I did. [​IMG]

    FillChar(FreeBlocks^, AlignLBA(NumWBFSSectors div 8), $FF);

    If I didn't, the memory would be filled with junk anyway, not 0xFF. Since the extra part doesn't get used, the only time it matters is when it's trimmed so I think it'll be OK just to leave it like that. I could zero the memory, then set the correct size to 0xFF, but it's an extra step for nothing really eh?

    I've posted version 0.1.6 with the fixes if anyone has time to test..
     
  15. oggzee

    Member oggzee GBAtemp Addict

    Joined:
    Apr 11, 2009
    Messages:
    2,335
    Country:
    Slovenia
    Yes, it's perfectly fine this way. I was just trying to clear why it works the way it is in wbfs_file, because I use:
    #define wbfs_ioalloc(x) calloc(x,1)
    To make sure there is never any junk in allocated memory.
    (calloc will set the memory to 0, in case anyone wonders)

    btw, in wbfs_file/libwfs_os.h i also commented this:

    // some allocations are not cleared in libwbfs, so,
    // we're using calloc to get always the same reproducible output
    #define wbfs_malloc(x) calloc(x,1)
    #define wbfs_ioalloc(x) calloc(x,1)

    I was hoping it would be spotted, by whoever was modifying this [​IMG]
     
  16. oggzee

    Member oggzee GBAtemp Addict

    Joined:
    Apr 11, 2009
    Messages:
    2,335
    Country:
    Slovenia
    I have tested it with WiiPlay and it creates binary exact same files as wbfs_file.exe
    I have tested it with 'all' and with 'game only' partition selection and in each case the produced files are exactly the same as with wbfs_file -a or -g.
    I haven't tested it with any game that would require splits.

    ps. I have added a link to your wbfs backup manager in my cfg loader first post and fat faq.
     
  17. fig2k4
    OP

    Member fig2k4 GBAtemp Advanced Fan

    Joined:
    Oct 30, 2009
    Messages:
    758
    Location:
    Scotland
    Country:
    United Kingdom
    Nice. Thanks for testing.
     
  18. redia

    Member redia GBAtemp Fan

    Joined:
    Mar 9, 2008
    Messages:
    371
    Country:
    Switzerland
    fig2k4,

    just tested 0.1.6
    the info file is there [​IMG]
    the file are PERFECTLY identical..
    I tested with two game below 2GB and two games over 2GB requiring split. all chunk are good.

    R
     
  19. madtamski

    Member madtamski GBAtemp Fan

    Joined:
    Oct 15, 2008
    Messages:
    404
    Location:
    Glasgow, Scotland, UK
    Country:
    United Kingdom
    Brilliant, great work!

    I was hoping something like this would come along [​IMG]
     
  20. FoGBaV

    Newcomer FoGBaV Advanced Member

    Joined:
    Jan 31, 2008
    Messages:
    82
    Country:
    Sweden
    Yeah ... thank you very much ... nice work !!
     

Share This Page