Leaderboard

It’s always google, I have bought a domain and site hosting so have to redo the downloader script. Might be slower to download stuff but it should never go down. Google was good, easy to update files and quick. Now it’s a pain as it keeps limiting files, even the small ones.

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.

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.

My print bed is 33cm square, yes. The case is 30cm at its widest

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.

If it’s built like an ender you can buy the Aluminium square section and essentially cut your own that will give the area then you need a bigger heater bed. The heater beds are fairly generic across the market. Then just get a bigger glass pad or magnetic sheet or what ever you use to match. the printer parameters can be adjusted in Marlin software, so it can be told to expect a bigger bed. Slicer software obvs can be set up to what ever you want.

Xeucter2 BIOS Manager (X2BM 2.3 is the last release.) You need a short ( less than 3 foot long I believe was mentioned somewhere; however, I believe I used a shielded cable that was longer) 25-pin straight through DB-25 printer cable, not a serial cable.

I would say owning a Dremel or similar tool is a requirement.

You beat me to posting the info. However I'd not read down this far in the thread before I posted.

I've used Rust-Oleum white and black metallic spray paint before. I did several light coats and it turned out very nice. I will be extra careful with silver/chrome.

The Canary Yellow looks very nice, but I will go with silver or chrome to try and match the original. I think silver is too flat and chrome too shiny, but it's as close as I can get it. There is a metal polishing/chroming place near me so I may bring it in to get a quote. I don't except it to be cheap. Thanks for the tip.

Not sure if this shines any light on this for you or not. You can always reach out to Kaos and see what he recommends.

Paint.net is what I used too. The exact information about the imported logo, especially the specific DDS format recommended, are or should have been included in the EVTool readme along with some DDS samples too. These are the two Evox logos I eventually settled on:-