IsoBuster beta with added new consoles support

[Peppe90]

I thinking Yours "E:\" have around 233GiB. This isn't true? IsoBuster assuming that standard partition (X - E) have standard size. So if ISB assume that E ends like in normal environments, a next partition starting at LBA 496203120, then space between them assign as unassigned partition (empty space).

E: is under Xbox Shell Partition, it's 4,77GB, it's correct. I never touched original partitions (with a softmod it'd just result in a unusable HDD I think...)

And name "Unassigned Partition 06" comes from partition in order. It is seventh area found/interpreted (00 >> 01 >> 02 >> 03 >> 04 >> 05 >> 06).

IsoBuster showing whole data logic on i.e HDD, not only those partitions which can be parsed. So if E wasn't recognize as should, the rest of it threat like unknown data.

I understand. I didn't thought that a 500GB HDD has actually 700GB of data logic (694,97GB to be precise).
Anyway all sizes are correct. It's 465.82GB (C+E+X+Y+Z+F+G), considering wasted space by partition's formatting, this is the correct space you can have with a 500GB HDD, isn't it?

 

[Berion]

I'm blind old gingerbread then. Of course it cannot be larger! Something definitely goes wrong in this build. ^^

On softmod, probably depend of BFM BIOS. I never thought it is even possible until You mentioned about Xbox Partitioner.

 

[Peppe90]

I'm blind old gingerbread then. Of course it cannot be larger! Something definitely goes wrong in this build. ^^

Btw I don't think it's a problem, maybe it is a previous partition that got deleted as you was mentioning. I formatted that HDD many times before (using Chimp firstly, then XBP 1.3) using different sizes for F and G. Maybe IsoBuster can find some old references in partition table or so...

Btw it correctly see all the current partitions.

On softmod, probably depend of BFM BIOS. I never thought it is even possible until You mentioned about Xbox Partitioner.

I never modified standard partitions but I remember people doing it (is some old forums, like xbox-hq, epg-forum, xbmc4xbox, theisozone, etc...).
I don't know if it is possible now also with a softmodded Xbox. But I seems to remember it wasn't a recommended thing to do in any case. I think that mostly were developers changing standard partitions size for testing purposes.[/QUOTE]

 

[Peppe90]

Found a quite recent link about stock partition enlarging: Creating E Drive larger than 4-5GB? - XBMC4Xbox

So it seems I remembered wrong, there isn't any problem even on softmodded Xbox. Maybe cold-booting games could lead to problems btw...


EDIT: See also about this XBP bug: xbox hard drive upgrade [Archive] - Amibay.com Forum

You can find a lot of thread about it. Indeed I remember I had to format partitions more than one time with different HDDs. I usually formatted with XBP, then UX (that wrongly format big partitions with 16kb cluster, but it was good for the job anyway), then XBP again.

 

[IsoBuster]

If I may chime in quickly. Re F and G being swapped somehow.
The issue is simply that Partition G appears to be 'logically' located 'before' partition F (when sorted based on Logical Block Address (LBA)). The software assigns drive letters to volumes based on the order of the partitions the volumes are located in, since the drive letter is not stored in the file system. I suppose for F and G specifically, since the drive letter *is* recorded in the partition name, latter information can be used to fix this issue.

 

[Berion]

Modifying cache partitions is bad idea for sure (because games will not use larger and can have problems with smaller than default 750MiB) but been on modchip, in case of E and C I don't see anything against it. I just test it and my Evox M8+ see "C:\" 300MiB and "E:\" 20GiB. However, I don't see any reasons for doing that. Especially that now we can use PATA-SATA converters and really large disks, for which F and G partitions are "designed".

As I mentioned, I have made "mess HDD" and all partitions are correctly recognized. So I dunno now why Your case looks improper.

 

[Berion]

@IsoBuster Yet still there is improper size recognize in @Peppe90 dump and huge "island" between E and G. ^^
And, partition label can be any, not only i.e "XBOX F" but i.e "LOREMIPSUM" or even all 20h values.

 

[IsoBuster]

> Yet still there is improper size recognize in @Peppe90 dump and huge "island" between E and G. ^^

The size of the disc is correct !

But the size of partition F is not. The size, as stored in the partition table, goes well beyond the size of the drive.
Which is why IsoBuster shows the red x (as in unreadable parts)
Which is why you can see the blocks map for partition F have grey blocks (as in beyond the disk space)

I think this is your source of confusion ?

IsoBuster, when it parses the partition table, will show things are they are stored there.

(Unassigned) Partition 6 seems to contain an XFAT file system !
But it is not part of the partition map anymore, as you can see.
So it is seen as unallocated space.
It looks like an old partition that is not used anymore and its space is available, but not being used at the moment

> And, partition label can be any, not only i.e "XBOX F" but i.e "LOREMIPSUM" or even all 20h values.

And in that case the best guess for a volume label is the logical order of the partitions the volumes are located in (sorted by LBA)

 

[Coro]

> Yet still there is improper size recognize in @Peppe90 dump and huge "island" between E and G. ^^

The size of the disc is correct !

But the size of partition F is not. The size, as stored in the partition table, goes well beyond the size of the drive.
Which is why IsoBuster shows the red x (as in unreadable parts)
Which is why you can see the blocks map for partition F have grey blocks (as in beyond the disk space)

I think this is your source of confusion ?

IsoBuster, when it parses the partition table, will show things are they are stored there.

(Unassigned) Partition 6 seems to contain an XFAT file system !
But it is not part of the partition map anymore, as you can see.
So it is seen as unallocated space.
It looks like an old partition that is not used anymore and its space is available, but not being used at the moment

> And, partition label can be any, not only i.e "XBOX F" but i.e "LOREMIPSUM" or even all 20h values.

And in that case the best guess for a volume label is the logical order of the partitions the volumes are located in (sorted by LBA)

Welcome to the forum!

 

[Berion]

Yes, exactly.

So it seems that implementation of Xbox HDD is finished (from my side everything works, and it looks like that from @Peppe90 and @Haker120 sides too). ^^ Thank You very much for Your time and that all those console features are in free version!

To sum up why so much hassle with the implementation:

• Unhacked Xbox'es doesn't use any partition table. Firmware have hardcoded paths to each of standard partitions (X, Y, Z, C and E) and they always have the same size, even on later models with 10GiB HDD (2GiB staying unused for some reason).
• F and G doesn't exist on unhacked consoles.
• Hacked consoles with custom and/or modified BIOSes using partition table if exist (if some tools created them).
• There is space for more partitions than those for covering up X, Y, Z, C, E, F, G but only those will be visible by current dashboards and majority of homebrew apps.
• There is no standard for partitions labeling and identifying besides order in partition table.

 

[Peppe90]

Modifying cache partitions is bad idea for sure (because games will not use larger and can have problems with smaller than default 750MiB) but been on modchip, in case of E and C I don't see anything against it. I just test it and my Evox M8+ see "C:\" 300MiB and "E:\" 20GiB. However, I don't see any reasons for doing that. Especially that now we can use PATA-SATA converters and really large disks, for which F and G partitions are "designed".

Actually you may need a bigger E: if you have a lot of games that install DLCs (as the one from the topic I linked), you can easilly need more than 8GB. There's no way for making games to install DLCs on F/G.

 

[Berion]

Changes are already merged to official beta, so everyone can try. Version 4.6.9.06:
https://www.isobuster.com/betadownload.php

I have also edited first post, crossing text about G because now it is properly supported and added information about Xbox One external HDD support. Also XDFS support was improved (earlier implementation has some flaws resulting not all files and folders was visible).

@Peppe90 Actually this can be possible by crosslinking TDATA and UDATA to some other folders on i.e "F:\". Probably no one try it yet but in theory it is possible in the same way as on i.e MCFS which is also FAT kind fs family as FATX. ^^

 

[Peppe90]

> Yet still there is improper size recognize in @Peppe90 dump and huge "island" between E and G. ^^

The size of the disc is correct !

But the size of partition F is not. The size, as stored in the partition table, goes well beyond the size of the drive.
Which is why IsoBuster shows the red x (as in unreadable parts)
Which is why you can see the blocks map for partition F have grey blocks (as in beyond the disk space)

I think this is your source of confusion ?

IsoBuster, when it parses the partition table, will show things are they are stored there.

(Unassigned) Partition 6 seems to contain an XFAT file system !
But it is not part of the partition map anymore, as you can see.
So it is seen as unallocated space.
It looks like an old partition that is not used anymore and its space is available, but not being used at the moment

> And, partition label can be any, not only i.e "XBOX F" but i.e "LOREMIPSUM" or even all 20h values.

And in that case the best guess for a volume label is the logical order of the partitions the volumes are located in (sorted by LBA)

F: size is 408,30, I'm pretty sure is correct (I should be able to fix the Xbox later, so I'll check it).

About unassigned partition 06 I think so. I partitioned that HDD many times before not only with XBP bat also with Chimp (G: partition also with UnleashX) using every time different sizes fo F and G.

Also I confirm with new beta F and G are correctly named.

 

[Peppe90]

Here's the debug dump of the 1TB HDD, all seems fine.

I've dumped with this IsoBuster beta:

Note: I risked to burn the HDD because of those damned chinese adaptors... When it comes to Xbox HDDs is not that easy to find compatible adaptors.
I firstly tried with the 2,5" SATA to USB 3.0 case (I use it also for the Ps2 HDD without any problem) but no program could see the HDD on PC.

Then I tried with the IDE to USB 2.0 adaptor I used with the 500GB IDE HDD (leaving the StarTech SATA to IDE board I use on the Xbox, connected). This way xboxHDM could se the HDD so I unlocked it. Btw neither IsoBuster nor FATXplorer could see it (IsoBuster detected it, also the correct overall size, but shows the warning at boot and can't see any partition).

Tried again, now with another SATA to USB 2.0 adaptor. ISOBuster could see it correctly but as soon as I started the debug the HDD done a loud bad scream and shut-down itself. But I almost expected it, since is evident they made those adaptors from crap (the power supply adapter part).

Finally I tried with another SATA to USB 3.0 cable (from Kaico UK) and it worked flawlessly with all programs.

Ps2 formatted HDDs perfectly work with any adapter.

 

[Peppe90]

> Yet still there is improper size recognize in @Peppe90 dump and huge "island" between E and G. ^^

The size of the disc is correct !

But the size of partition F is not. The size, as stored in the partition table, goes well beyond the size of the drive.
Which is why IsoBuster shows the red x (as in unreadable parts)
Which is why you can see the blocks map for partition F have grey blocks (as in beyond the disk space)

Actually it seems that the red X is simply advising that there are missing infos in the dump.

For example, this is the 1TB HDD dump just opened:

I now go i.e. to G:\Emulators:

All is fine so far. But if I now enter one of the emulators folders, it'll make IsoBuster aware of the lack of their data/sectors (since I haven't opened them during the debug dump). So opening here a folder and coming back will result in this:

 

[Berion]

F: size is 408,30, I'm pretty sure is correct (I should be able to fix the Xbox later, so I'll check it)

But drive cannot contain more sectors than it have capacity. I thinking that those apps break the partition table. But of course I'm still curious what console will said.

Thanks for the another debug dump and report. ^^

I don't see why USB controllers would read PS2 HDD and not read Xbox HDD. They doesn't know and doesn't understand what the logic structure is. I thinking it is only differences in needed power.

 

[IsoBuster]

Actually it seems that the red X is simply advising that there are missing infos in the dump.

That is indeed a correct interpretation.

However, the difference with this (second) image is that it is from a ~1TB drive and partition G is located completely inside the addressable space. So as long as IsoBuster doesn't need to read a sector that is unreadable (for instance because it's not recorded in the image) no red X will be shown.

Your first image was from a ~500GB drive and partition F was logically (and partially) located beyond the addressable space. So even without reading any (unreadable) sector from that partition IsoBuster knew the object (Partition in this case) was (at least partially) unreadable, hence IsoBuster showed the red X immediately.

I hope this makes sense ?

 

[Peppe90]

I don't see why USB controllers would read PS2 HDD and not read Xbox HDD. They doesn't know and doesn't understand what the logic structure is. I thinking it is only differences in needed power.

It is so, for some reason.

When connecting the HDD using the SATA to USB 3.0 case (that's a good one) XboxHDM couldn't list any HDD.
It is not a power problem, since if I PFS format the HDDs they work (with Ps2 related programs).

In this case the Xbox HDD is a Seagate Barracuda ST1000LM048. I PFS formatted another one (same exact model) for a friend and moved games from PC using that exact SATA to USB 3.0 adaptor.
I also always used this adaptor for my Ps2 main HDD that's the 2TB version of the above mentioned HDD: ST2000LM015.

I noticed these problems since a long time, when I upgraded from a IDE 2 USB 2.0 to a IDE 2 USB 3.0 adaptor. But using the latter XboxHDM couldn't unlock the HDD (it could list it though). At the time I wasn't sure if it could be a question of speed or anyway something related to USB 3.0 protocol.
But I later realized that compatibility doesn't depend on that, since some IDE to USB 3.0 adaptors work flawlessly.

It is not a PC USB controller problems (it always detect the connected device), it is like FATX related programs need to read the HDD in a particular way that's not possible with some adaptors.
I'm not a developer I'm clueless about what the actual reason can be.

That is indeed a correct interpretation.

However, the difference with this (second) image is that it is from a ~1TB drive and partition G is located completely inside the addressable space. So as long as IsoBuster doesn't need to read a sector that is unreadable (for instance because it's not recorded in the image) no red X will be shown.

Your first image was from a ~500GB drive and partition F was logically (and partially) located beyond the addressable space. So even without reading any (unreadable) sector from that partition IsoBuster knew the object (Partition in this case) was (at least partially) unreadable, hence IsoBuster showed the red X immediately.

I hope this makes sense ?

I see. But shouldn't that lead to corruption problems??

I was helping a friend upgrading his Xbox HDD some months ago, he didn't formatted it correctly first time (using XBPartitioner). Btw all seemed fine on UnleashX end and he started moving games. Only the first installed one worked though. He noticed corruption problems immediately, missing games, data overwriting, etc... (indeed opening back XBP it had the ERR message on F and G partitions).

I almost filled up F partition in my 500GB HDD (it was fuller before), never had problems, also XBP showed no errors.

It is possible that that red X error have something to do with older partitioning?

Also, I don't know if it matters but that HDD is quite old (as all IDE ones), never had major problems but sometimes it failed FTPing files back to PC (especially emulators with a lot of tiny files, but also it happened exctracting games and rarely even installing, also on E partition. Indeed I used to install things little by little).

The new 1TB HDD has never failed even once (and I never worried moving files into it, or exctracting, all togheter).

 

[Berion]

@Peppe90 If this happen only in case of those programs on the same device connected by the same controller, then Your conclusion is correct.

Corruption probably no, error during copying data, yes, if FTP server will try reach sectors beyond capacity.

 

[Peppe90]

@Peppe90

Corruption probably no, error during copying data, yes, if FTP server will try reach sectors beyond capacity.

It really makes sense. But in this case I think FTP problems were related to the HDD being old, 'cause if failed sometimes, then wen trying again it succeeded (extracting the same file), also I could see some corrupted files. For example I remember some game video previews that stopped to play or started to glitch when playing and I think I remember it failed when trying to FTP them on PC.

I think I'll try extracting that glitched preview directly on PC.

Btw it mostly failed when extracting, not when installing (it was very rare as i said and could happen with any partition, also standard ones).