Jump to content
OGXbox.com

Bomb Bloke

Members
  • Posts

    9
  • Joined

  • Last visited

  • Days Won

    1

Bomb Bloke last won the day on January 10

Bomb Bloke had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Bomb Bloke's Achievements

Rookie

Rookie (2/14)

  • Reacting Well Rare
  • Dedicated Rare
  • One Year In
  • One Month Later
  • Week One Done

Recent Badges

10

Reputation

  1. You would indeed require 512KB clusters for a volume 6TB in size. But your largest volumes are only 2.7TB, right? Those two would only require 256KB clusters.
  2. It does happen, and the Windows File Explorer very helpfully points it out: open the Properties panel on a given file or folder, and you'll see a "Size" figure (representing the total amount of data selected) and a "Size on Disk" figure (representing the total size of the clusters that data is allocated across). The difference - the "wastage" - is your slack space. The trick is that most consumer PCs these days have their hard drives formatted using modern file tables such as NTFS, which can handle a lot more clusters per volume than FATX can. This means that larger volumes can still have smaller clusters - pretty much always just 4KB. You don't get so much slack that way. For really small files - like a few bytes - NTFS doesn't even bother to assign any clusters at all, instead simply writing the data directly where the addresses for the clusters would go! In these cases, the reported "Size on Disk" is 0! (Though technically your file index still gets larger - Windows just doesn't bother to report on that.) Good point, I went and forgot about that. I'm not entirely sure how well the average emu handles ROMs stored on volumes 7+, even if they're in the emu's own folder.
  3. Multiple ~1TB partitions would be fine in my book. 1GB partitions are out of the question - the minimum cluster size is 16KB, allowing volumes of up to 256GB, so in terms of slack avoidance there's no point in making any extended partitions that're smaller than that.
  4. There's a little more to it than that - rather, every file will consume a multiple of 512KB on the disk. So a 513KB file would eat 1024KB, for example, as that's the smallest multiple it'd fit in to. You still end up wasting less space on average as you increase your file sizes, though, as larger files means fewer files, and fewer files means fewer partially-filled clusters being wasted. Back in the day, ZipFS was considered to help deal with the slack space problem. (And the filename length problem, and the character restriction problem...) I can't remember which emulators ended up getting support coded in, but the basic idea is that you archive up a bunch of files in "store" mode (no actual compression) and mount that up as a drive. It's still not 100% efficient, but it's certainly better than dealing with the sort of slack you see with FATX. StepMania's "smzip" files are an example of this technique being put to use. More recently it was pointed out to me that we could just cram all our ROM files or whatever into ISOs, and then mount those. This would allow us to use them with emulators that don't actually have ZipFS support. Also it'd probably allow us to mount much, much larger packages of combined files, as ISOs can be split into multiple 4GB parts, and I'm not sure if we can do that with ZipFS. The catch to ZipFS and ISO mounting is that the volumes end up being read-only, so saves and config files still need to go separately into a FATX file system. Many emulators can also load ROMs from SMB shares, so that's another work around to consider. Sure we can. If you want to have a stonking great big volume with large clusters, sitting alongside a tiny little volume with small clusters, then there's nothing stopping you. In fact your C/E/X/Y/Z volumes should each already be running 16KB clusters anyway. XBMC can also mount some of the extended volumes past number 7 (G), I think something like up to six extra past that? You should be able to limit your maximum cluster size down to 64KB by spreading things out a bit more.
  5. Sure, attempt to reflash new firmware into the TSOP. If it works then the old firmware was bad. If it fails then the TSOP itself is bad. Reflashing the TSOP of an Xbox that can't boot is easier said than done, though. The easiest way I've heard of to perform such a thing would be to set up a pin header, plug on an Xblast Lite modchip, and then to follow this recovery procedure: https://bitbucket.org/psyko_chewbacca/lpcmod_os/wiki/xblast_lite_manual/Extra_features#3.2 TSOP recovery If it works, great! Take the modchip off the pinheader and you're finished. If it fails, then you can either think about desoldering the TSOP... or you can just stick with running a modchip. Of course, if the console still can't be used normally with a modchip, then obviously the original fault wasn't with the TSOP nor the firmware it contained anyway. In some cases a corrupt TSOP will result in a "coma console". These systems display a green front LED only, like a normal functioning Xbox would do, but they give no video output. They're almost always 1.0 or 1.1 units, which fortunately can often be salvaged with just a little re-wiring: https://web.archive.org/web/20050525003956/http://www.llamma.com/xbox/Repairs/ComaConsole.htm If you have further questions about TSOPs (or modchips), probably best to use another thread for those. This one is related to Dtomcat's EEPROM reader, and I don't want to drive it too far off topic.
  6. I mean, yeah, if you have the gear then you can pop a TSOP chip off your Xbox motherboard, program a new BIOS in to it, and then solder it back on. You can likewise swap in brand new replacements that way. But it's unlikely that you'll ever want to do either of those things. You'd only even consider it if you wound up looking at a console with a corrupt TSOP chip. That's not exactly a common fault, and it's one that's very difficult to confirm without installing a modchip: it generally results in a triple-boot FRAG, which can also be caused by a lot of other things. Even in cases where you know for a fact that a TSOP holds corrupt firmware, odds are the hardware itself will be ok and all that's required is a re-write. Buying a pile of spare TSOP chips to keep on-hand would be a total waste of cash, as you'd almost certainly never use any of them. What is much more common is that you'll get a system with a failed / missing HDD, and to recover from that all you need is to read the system's config data from the EEPROM chip using a reader like Dtomcat's. Then you've got the HDD key needed to install a new drive - so dump some softmod files on your replacement, lock it up, and slap it in. Once a pre-1.6 console is softmodded you can then proceed to run TSOP flashing software through the Xbox itself in order to hardmod it. 1.6 consoles unfortunately lack writable TSOP chips, storing their firmware in read-only Xyclops chips instead, so if you want to hardmod those then you're stuck with modchips. The config data in an Xbox EEPROM chip will likewise sometimes corrupt, resulting in the console's front LED going red only. This seems to happen much more often than with the BIOS data kept in the TSOP chips, and it likewise doesn't necessarily mean that the hardware itself needs replacement. If the chip itself is still good then all you need to do is use an EEPROM reader device to program something valid back in.
  7. On the contrary - you can call it what you like. Stick it in C:\BIOS, load XBlast, flash away. Winbond or not, doesn't matter. If it suits your scripts better to use a particular name, then that's cool. There's no "need" to use any particular name as far as XBlast is concerned, though.
  8. XBlast only reads BIOS files from a certain location, but it doesn't much care about the actual file names. Put multiple files with different titles in C:\BIOS and it'll list them just fine. Heimdall used the "bios.bin" title in HeXEn, which may've given you the wrong idea? That wasn't because of any limitations in XBlast, it was just so he could tell users to select that specific file name when the flashing screen came up.
  9. There appears to've been some confusion. sweetdarkdestiny told me that Heimdall might be operating under the name of ToxicMedz these days. I didn't think it likely, especially given statements such as this one, but since it'd be nice to know that H was still kicking about the place I thought I'd question him on it further anyway. That's me he's screenshotted there, asking for some sort of confirmation that ToxicMedz is "also known as" Heimdall. I figured he'd probably doublecheck his "sources" and change his mind. But it seems there's a bit of a language barrier, and he's gained the impression that I'd actually accused ToxicMedz of lying. Or something? I'm not altogether certain as to what he's thinking, if I'm quite honest, but if I've sent him down that path then I must apologise for the mix up.

Board Life Status


Board startup date: April 23, 2017 12:45:48
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.