What is "Arch community AUR"? Can you give me a link?mikey72 said:Yeh no error msgs or any processes running in background.I installed the package from the Arch community AUR I will uninstall and try a previous version and get back to you.
It is a community maintained collection of packages for the Arch Linux distribution. AUR (en) wiimms-iso-tools.
The PKGBUILD file contains the instructions for downloading and building the program.
The PKGBUILD file contains the instructions for downloading and building the program.
- Joined
- Oct 30, 2009
- Messages
- 758
- Trophies
- 0
- Location
- Scotland
- Website
- www.wiibackupmanager.co.uk
- XP
- 174
- Country
I know this is nothing to do with WWT, but we discussed the 500 game slot limit in WBFS before and thought you'd be interested. I'm posting it here instead of a PM in case sparks interest with anyone involved with cIOS development, since the changes are needed there too for it to work.
I was messing with the CFG source and got it working using a simple solution. It's slightly different to what I have in my own code because there's some limitations, like SDHC is hard coded to use a sector size of 512 etc. My solution will work with that.
I introduced a new "hd_sec_sz_ratio" variable to wbfs.c. This is the ratio between the real sector size and the fake sector size set in the WBFS header. In wbfs_open_partition() it's calculated like this..
CODEÂÂÂÂÂÂÂÂp->hd_sec_sz = 1hd_sec_sz_s = head->hd_sec_sz_s;
ÂÂÂÂÂÂÂÂp->n_hd_sec = wbfs_ntohl(head->n_hd_sec);
ÂÂÂÂÂÂÂÂ
ÂÂÂÂÂÂÂÂhd_sec_sz_ratio=(p->hd_sec_sz)/(hd_sector_size?hd_sector_size:512);
ÂÂÂÂÂÂÂÂ
ÂÂÂÂÂÂÂÂif (!reset)
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂwbfs_free(head);
ÂÂÂÂÂÂÂÂÂÂÂÂhead = wbfs_ioalloc(p->hd_sec_sz);
ÂÂÂÂÂÂÂÂÂÂÂÂread_hdsector(callback_data,p->part_lba,1*hd_sec_sz_ratio,head);
ÂÂÂÂÂÂÂÂ}
ÂÂÂÂÂÂÂÂ
ÂÂÂÂÂÂÂÂif(!force_mode && hd_sector_size && head->hd_sec_sz_s !=ÂÂsize_to_shift(hd_sector_size*hd_sec_sz_ratio))
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂERROR("hd sector size doesn't match");
ÂÂÂÂÂÂÂÂif(!force_mode && num_hd_sector && head->n_hd_sec != wbfs_htonl(num_hd_sector/hd_sec_sz_ratio))
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂERROR("hd num sector doesn't match");
The default value is 1 and it should be reset to 1 before reading the header for the first time in wbfs_open_partition() too so the header is read with the real hd sector size first.
Every call to read_hdsector() and write_hdsector() then looks similar to this..
And that's it. What happens is that the read calls will return a full "fake sector" of data for every real sector requested. So with a fake size of 1024, internally libWBFS would use a sector size of 1024 and the file reads would use 512*2.
I've tested a build of CFG and a pen drive with a fake sector size of 1024. I was able to rip a valid game from disc, all games show up fine, the banner music plays and the dol shows up fine in the alt dol selection menu. I then transferred the DVD rip from WBFS to ISO using WBM and ran the game fine in Dolphin.
Right, so here's the big brick wall... I got a bit confused as to why the games wouldn't boot on the Wii from CFG when everything seems to be working. I just found out from oggzee that the cIOS uses it's own version of libWBFS. So all my changes mean nothing because it needs changed in the cIOS too.
I can send the working code from CFG to anyone that's interested. It's really nothing more than what I've posted above, but it could save some time.
Hopefully you're still interested and I'm not just spamming your thread.
I was messing with the CFG source and got it working using a simple solution. It's slightly different to what I have in my own code because there's some limitations, like SDHC is hard coded to use a sector size of 512 etc. My solution will work with that.
I introduced a new "hd_sec_sz_ratio" variable to wbfs.c. This is the ratio between the real sector size and the fake sector size set in the WBFS header. In wbfs_open_partition() it's calculated like this..
CODEÂÂÂÂÂÂÂÂp->hd_sec_sz = 1hd_sec_sz_s = head->hd_sec_sz_s;
ÂÂÂÂÂÂÂÂp->n_hd_sec = wbfs_ntohl(head->n_hd_sec);
ÂÂÂÂÂÂÂÂ
ÂÂÂÂÂÂÂÂhd_sec_sz_ratio=(p->hd_sec_sz)/(hd_sector_size?hd_sector_size:512);
ÂÂÂÂÂÂÂÂ
ÂÂÂÂÂÂÂÂif (!reset)
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂwbfs_free(head);
ÂÂÂÂÂÂÂÂÂÂÂÂhead = wbfs_ioalloc(p->hd_sec_sz);
ÂÂÂÂÂÂÂÂÂÂÂÂread_hdsector(callback_data,p->part_lba,1*hd_sec_sz_ratio,head);
ÂÂÂÂÂÂÂÂ}
ÂÂÂÂÂÂÂÂ
ÂÂÂÂÂÂÂÂif(!force_mode && hd_sector_size && head->hd_sec_sz_s !=ÂÂsize_to_shift(hd_sector_size*hd_sec_sz_ratio))
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂERROR("hd sector size doesn't match");
ÂÂÂÂÂÂÂÂif(!force_mode && num_hd_sector && head->n_hd_sec != wbfs_htonl(num_hd_sector/hd_sec_sz_ratio))
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂERROR("hd num sector doesn't match");
The default value is 1 and it should be reset to 1 before reading the header for the first time in wbfs_open_partition() too so the header is read with the real hd sector size first.
Every call to read_hdsector() and write_hdsector() then looks similar to this..
Code:
p->read_hdsector(p->callback_data,p->part_lba +(lba*hd_sec_sz_ratio),count*hd_sec_sz_ratio, p->head);And that's it. What happens is that the read calls will return a full "fake sector" of data for every real sector requested. So with a fake size of 1024, internally libWBFS would use a sector size of 1024 and the file reads would use 512*2.
I've tested a build of CFG and a pen drive with a fake sector size of 1024. I was able to rip a valid game from disc, all games show up fine, the banner music plays and the dol shows up fine in the alt dol selection menu. I then transferred the DVD rip from WBFS to ISO using WBM and ran the game fine in Dolphin.
Right, so here's the big brick wall... I got a bit confused as to why the games wouldn't boot on the Wii from CFG when everything seems to be working. I just found out from oggzee that the cIOS uses it's own version of libWBFS. So all my changes mean nothing because it needs changed in the cIOS too.
I can send the working code from CFG to anyone that's interested. It's really nothing more than what I've posted above, but it could save some time.
Hopefully you're still interested and I'm not just spamming your thread.
This error appears only if the game is not found in the title db.Wiimm said:There is in deed something wrongmikey72 said:
Fixed! ==> http://wit.wiimm.de/r/gbatemp-beta
@fig2k4
I will study your code in the (european) evening.
@fig2k4
I understand you code but I don't understand the reasons for using 'hd_sec_sz_ratio'.
The WBFS header already contains the value for the sector size. Just write the shift count 12 for a block size 4096 and the whole code works fine. The calling part must only remember this value in the read and write wrappers.
EDIT:
We should open a WBFS definition thread if we need a real discussion how to changes/extend WBFS. This is in the interest of all developers who using WBFS.
I understand you code but I don't understand the reasons for using 'hd_sec_sz_ratio'.
The WBFS header already contains the value for the sector size. Just write the shift count 12 for a block size 4096 and the whole code works fine. The calling part must only remember this value in the read and write wrappers.
EDIT:
We should open a WBFS definition thread if we need a real discussion how to changes/extend WBFS. This is in the interest of all developers who using WBFS.
@Wiimm, is there a "replace file" function in "wit" ? (like Wiiscrubber)
For example, I would like to use "wit" to replace main.dol in the DATA partition.
of an ISO. Is it possible ? (It should become to a Fake signing of the TMD )
(I only can find a remove file option "--rm-files" .)
For example, I would like to use "wit" to replace main.dol in the DATA partition.
of an ISO. Is it possible ? (It should become to a Fake signing of the TMD )
(I only can find a remove file option "--rm-files" .)
- Joined
- Oct 30, 2009
- Messages
- 758
- Trophies
- 0
- Location
- Scotland
- Website
- www.wiibackupmanager.co.uk
- XP
- 174
- Country
I understand you code but I don't understand the reasons for using 'hd_sec_sz_ratio'.
The WBFS header already contains the value for the sector size. Just write the shift count 12 for a block size 4096 and the whole code works fine. The calling part must only remember this value in the read and write wrappers.
Where did the 12 come from though? The ratio will work automatically with any combination of real and fake sector sizes.
Say the real sector size was 2048 and the fake size was 4096, just shifting by 12 wouldn't work, where the ratio would. So even using the shift, you still need to calculate a ratio between real and fake sizes to know the shift value.
The WBFS header already contains the value for the sector size. Just write the shift count 12 for a block size 4096 and the whole code works fine. The calling part must only remember this value in the read and write wrappers.
Where did the 12 come from though? The ratio will work automatically with any combination of real and fake sector sizes.
Say the real sector size was 2048 and the fake size was 4096, just shifting by 12 wouldn't work, where the ratio would. So even using the shift, you still need to calculate a ratio between real and fake sizes to know the shift value.
- Joined
- Oct 30, 2009
- Messages
- 758
- Trophies
- 0
- Location
- Scotland
- Website
- www.wiibackupmanager.co.uk
- XP
- 174
- Country
Yeah, because some of the external libs on the Wii use a fixed sector size of 512, it's not possible to just tell them that the sector size is 4096. Using the ratio, libWBFS just requests a read of 8 real sectors for every 1 virtual sector. That way, it's compatible with those libs.
In the WBM code, I've done exactly what you suggested in your other thread. I changed the sector size to match the size in the WBFS header. That doesn't work on the Wii because of the libs using a hard coded size of 512.
It should be fully compatible with normal WBFS drives because the ratio would be 1. It wouldn't change anything in the read/write calls when the ratio is 1.
Hopefully it's a bit clearer. It's definitely working with the CFG version I compiled or I wouldn't have mentioned it.
I'll send the code, maybe you could see what I've done better that way..
In the WBM code, I've done exactly what you suggested in your other thread. I changed the sector size to match the size in the WBFS header. That doesn't work on the Wii because of the libs using a hard coded size of 512.
It should be fully compatible with normal WBFS drives because the ratio would be 1. It wouldn't change anything in the read/write calls when the ratio is 1.
Hopefully it's a bit clearer. It's definitely working with the CFG version I compiled or I wouldn't have mentioned it.
I have installed the current WBM and formatted a drive with sector size 4096 and added some games. Then I made wwt+wit tests with this drive:
Good news:
The WIT tools are compatible to this extension since October 2009 (15 month!).
The new sector sizes was one of my first WBFS discoveries:
http://gbatemp.net/index.php?showtopic=185428#entry2326066
Good news:
The WIT tools are compatible to this extension since October 2009 (15 month!).
The new sector sizes was one of my first WBFS discoveries:
http://gbatemp.net/index.php?showtopic=185428#entry2326066
- Joined
- Oct 30, 2009
- Messages
- 758
- Trophies
- 0
- Location
- Scotland
- Website
- www.wiibackupmanager.co.uk
- XP
- 174
- Country
Nice.
I hope I made it clear enough that all I did was implement the changes to CFG, so it can work with loaders on the Wii. What I did in WBM was directly from your idea in that thread.
Now the ball's in Waninkoko's court. If he does decide to make the changes in rev22, we can eventually see this in action.
We can only hope.
I hope I made it clear enough that all I did was implement the changes to CFG, so it can work with loaders on the Wii. What I did in WBM was directly from your idea in that thread.
Now the ball's in Waninkoko's court. If he does decide to make the changes in rev22, we can eventually see this in action.
WIT: Wiimms ISO Tools v1.26a - 2011-01-27
A command line ISO+WBFS tool set for various os.
WIT (Wiimms ISO Tools) is a set of command line tools to manipulate Wii ISO images and WBFS containers. The two main tools are called wit (Wiimms ISO Tool) and wwt (Wiimms WBFS Tool, the WBFS manager).
Feature overview:
- WIT (Wiimms ISO Toolset) is a set of command line tools.
- wit (Wiimms ISO tool) is the main Wii and GameCube ISO manipulation tool.
- wwt (Wiimms WBFS tool) is a complete WBFS manager including FS checking and repairing, time stamps and multi WBFS support.
- wdf-cat and wdf-dump are WDF and CISO support tools.
- WIT supports 6 Wii disc file types (ISO, CISO, WDF, WIA, WBFS and FST) and can read from pipes (indirect RAR/ZIP/7Z support).
- wit can verify and compare (diff) Wii and GameCube ISO images.
- wit can extract and compose Wii ISO images.
- wit can patch Wii and GameCube ISO images while copying.
- wit can mix partitions from different sources into a new Wii ISO images.
- wit and wwt support many diagnostic commands.
- Advanced shell support.
Download of the current version:
- wit-v1.26a-r2223-i386.tar.gz : Linux/i386 version
- wit-v1.26a-r2223-x86_64.tar.gz : Linux/x86_64 version
- wit-v1.26a-r2223-mac.tar.gz : Mac OS universal binaries (ppc, i386 and x86-64)
- wit-v1.26a-r2223-cygwin.zip : Cygwin (Windows) version
- Other releases are available from http://wit.wiimm.de/download.html.
- QtWitGui, manipulate and convert single ISO images.
This QT based GUI focuses on manipulating single ISO images. It can do much more.
. - Wii Backup Fusion, a WBFS and ISO manager.
This QT based GUI is a complete WBFS manager and ISO tool.
. - Wii Covers Download & WBFS Manager for Windows, a WBFS and ISO manager.
This is a very young Java based WBFS manager. (GBA temp discussion)
- This is basically a maintenance update. I have fixed much things (not only bugs) from my to do list. Read the change log for details.
. - The Linux distributions are now linked 'static'. This makes the distribution compatible for most Linux installations. Because of this the tools support now the most current implementation of preallocation which results in faster file generation. A side effect is the integration of LIBBZ2 as source (and MAC support).
. - In general the user interface (layout of tables) has changed. E.g. "wit dump" prints IDs of TICKET, TMD and BOOT.BIN in the summary and the partition status (en-/decrypted, scrubbed, sign status) is printed too. I will change more in the next releases.
. - The user interface changes may break the GUI support. Therefor I have implemented the --sections support for many more commands. If option --sections is set the output is printed in machine readable sections and parameter lines. GUIs should use this very stable output.
.
Code:
wit v1.26a r2223 - 2011-01-27
- Bug fix for "wwt EXTRACT --test": If extracting to an already existing file
ÂÂ the old file was removed.
- Bug fix for "wdf +PACK": wrong data written if packing a raw file.
- Bug fix: Reading a GameCube WIA is now done without an assertion failure.
ÂÂ But remember: GameCube support is still EXPERIMENTAL!
- I have made some changes in the make system to support GCC option -static
ÂÂ and cross compiling (Linux/i386 on Linux/x86_64).
- Linux/i386: Because of the static linking I can use the latest version of
ÂÂ the Linux GLIBC with preallocation support. Copying file is now fast again.
- BZIP2 support is now included as source and should work for all systems.
ÂÂ This enables WIA/bzip2 support for Mac/x86_64.
- "wit COPY/CONVERT/EXTRACT/EDIT/MOVE/DIFF" and "wwt ADD/EXTRACT/REMOVE"
ÂÂ support now the option --sections.
- "wwt add": New user interface implemented: In a first fast loop the jobs are
ÂÂ counted with respect to the options like --update and --newer (ignore skiped
ÂÂ files). In a second loop the jobs are executed with correct job counters.
- wit DUMP: Scrubbing status of disc and partitions are printed. Example:
ÂÂÂÂÂÂ"TICKET & TMD are well signed. Partition is encrypted and scrubbed."
- "wit EXTRACT" failed if the disc title could not found in the title db.
- New commands: "wit/wwt SKELETON": Create skeleton copies of discs for
ÂÂ further analysis. Details: http://wit.wiimm.de/cmd/wit/skeleton#desc
Known bugs:
- The GameCube support is in development and EXPERIMENTAL!
ÂÂÂÂ- GameCube conversion to WIA fails.
- There are new problems while reading from non seekable sources (e.g. pipes).
ÂÂ The reason is the complete new and more intelligent wiidisc lib which makes
ÂÂ more lookups ==> The best is to use version 1.01c for pipes.The source is published under the license of GPL2. Checkout the sources directly from the SVN repository or browse the source. Visit http://wit.wiimm.de/ for more information.
Thank you!!!
Now everything works as expected and I have verified several discs coming out of WIA format... I should like to shortly release the toolset that I have been working on that incorporates your tools. It may need to wait until after my lengthy (27 days or so) work trip that starts feb 7. We'll see.
That being said, I appear to have found one more bug/oversight.
When given games that have 2 discs (such as the Baten Kaitos or Metal Gear Solid games,) your tools do not output the disc number in any way that I can find. To my knowledge, the internal disc number is the byte immediately following the DISC ID at the very front of the ISO image.
For example, Baten Kaitos - Eternal Wings and the Lost Ocean: these game discs are identical all the way up to 0x00000429 with the sole exception of byte 0x00000006. In the first disc this byte is 00 and is 01 in the second. All of my multi-disc games appear to follow this convention and seems to be confirmed by the single disc games that I have on hand. (Single disc games appear to all be 00 at this location.)
This isn't such a big deal, however, as for my needs I can simply count the disc header length as given by wit and manually probe the next byte.
Anyways, thanks again for your continued efforts!
Now everything works as expected and I have verified several discs coming out of WIA format... I should like to shortly release the toolset that I have been working on that incorporates your tools. It may need to wait until after my lengthy (27 days or so) work trip that starts feb 7. We'll see.
That being said, I appear to have found one more bug/oversight.
When given games that have 2 discs (such as the Baten Kaitos or Metal Gear Solid games,) your tools do not output the disc number in any way that I can find. To my knowledge, the internal disc number is the byte immediately following the DISC ID at the very front of the ISO image.
For example, Baten Kaitos - Eternal Wings and the Lost Ocean: these game discs are identical all the way up to 0x00000429 with the sole exception of byte 0x00000006. In the first disc this byte is 00 and is 01 in the second. All of my multi-disc games appear to follow this convention and seems to be confirmed by the single disc games that I have on hand. (Single disc games appear to all be 00 at this location.)
This isn't such a big deal, however, as for my needs I can simply count the disc header length as given by wit and manually probe the next byte.
Anyways, thanks again for your continued efforts!
Similar threads
