4 replies to this topic

[fpefpe]

Hello -- what is the possibly of supporting compressed ISO formats like used with DEAMON tools (mdx?)

[elegantinvention]

(Topic moved to Requests)

Without knowing the specifics of any compressed formats, I will say this is probably possible, but not useful.
What I mean is, assuming the format is publicly available and the license permits usage in products like isostick, it would most likely be technically possible for me to add on-the-fly decompression to the isostick firmware. However, the isostick's processor is probably far too slow to do this in a useful manner.

I don't have any experience in (de)compression algorithms though, so I may be wrong I've added this to the todo list as a low priority, and I will definitely play with it in the future, but I am not hopeful.

For reference if anyone is familiar with decompression algorithms and their compute/memory requirements: isostick uses an AVR32 architecture (closely mirroring ARM Cortex-M3 and similar), which is a 32bit CPU operating at 66MHz and achieving roughly 66MIPS for most things. Memory is CPU-local SRAM (on-die, single-cycle access), of which I can spare 32kB for this, give or take.

[Wonko the Sane]

@fpefpe
Set aside the technical limitations/possibilities, I would be curious to understand the reasons why a compressed format could be useful for use with ISOstick, can you post some of the reasons why you would like/need this added feature?


Wonko

[fpefpe]

@fpefpe
Set aside the technical limitations/possibilities, I would be curious to understand the reasons why a compressed format could be useful for use with ISOstick, can you post some of the reasons why you would like/need this added feature?


Wonko

Hello -- thanks for the feedback -- one thought is that since the compressed image would be smaller, more can fit on the stick and in the case of
daemon tools, they support s split / spaned format -- but if the isostick can support the output of the unix split comand, I guess that might be moot --
also, if I understand the specs, it would suppot a sdxc(mini) card with storage 64gb and greater?

lastly in the case of unix, would a

foo.iso.gz
or
foo.iso.bz2

make sense as a support format?

[Wonko the Sane]

The point is IMHO slightly different.
A compressed image needs *somehow* to be expanded, but much more than that it must be expanded *somewhere*.
The issue - as I see it - is more than anything else the *somewhere*.
If this *somewhere* is actual PC RAM, then you can use grub4dos (which support natively gzip compression) or Syslinux's memdisk (which supports both gzip and zip compression) and of course no issue with.AVR32 performance, as the decompression is made by the PC processor.

If this *somewhere* is "on the SD card", besides the "load" on the ISOstick processor, something like a "swap" partition as big as the size of the largest .iso (expanded) is needed.

So if the largest .iso loaded on the SD card is (say - and let's for the moment keep aside the split .iso's) that of a "single sided" DVD , i.e. around 4.5 Gb, you would need to keep some 5 Gb of the SD "free" for "swap" usage, and the loading would become anyway, very, very slow.

A possible alternative would be to use a format like CISO:
http://www.pismotechnic.com/ciso/
AND have NATIVE support for it in the actual Operating System that is booted through it, something that has a probability to happen so low IMHO that it could make the Heart of Gold travel for a zillion of parsecs.....

Personally I would find smarter (and easier) to make the famous ISOstick cap protector that several people asked for, and add in it a "pocket" for a couple additional mini SD's...

Split images are already supported:
http://reboot.pro/to...s-for-isostick/


Wonko