Полная версия: cso support
Вы просматриваете yпpощеннyю веpсию форума. Пеpейти к полной веpсии.
I've been looking for *.cso (compressed iso) support on DreamShell.
This capability is mentioned here and there, in a few places, and more importantly, there are traces of this support in many places throughout the code base.

However, every time I tried to load a .cso file, it resulted in a crash.

I was lucky enough to receive a hint from @ChristinaDreamcustDC, stating that .cso support might have been dropped in recent versions of DreamShell.
There is, indeed, one short line on the topic in the middle of RC4 release note, firmware section :

> Removed support for CSO in IDE loader to save memory =(

So that's interesting for a few reasons :

1) I'm not using IDE, but a SD Card reader on serial port. From the spelling, one could believe that it should not be impacted by the change on IDE, since after all, within `DS/firmware/isoldr`, there are distinct `ide.bin` and `sd.bin` files.

Well, the Serial Port config is clearly impacted. To confirm, I downloaded RC3, and attempted again to load the *.cso file. This time it worked.

So something broke support of *.cso files for all storage types in RC4.

2) "to save memory"

OK, this one is even more interesting. I've been looking at the code in `modules/isofs` pretty closely, and, provided that the *.cso file is using LZO compression, there is nothing that makes it consume more memory than a direct read on *.iso file. LZO decompression only costs a handful of stack variables, nothing significant.

Note that this is fairly different from zlib compression, where there is a state, which costs memory. I want to underline that I'm targeting LZO-compressed *.cso file as my primary application, precisely because it costs less memory and cpu at decompression time.

3) The code is still there.

As mentioned, I've been looking pretty closely at the code in `isofs`, and a little bit at `isoldr` and `firmware/sd`.
It's pretty clear that the ciso code is still here.
More than that, it's still active, it's not gated, and it ends in the produced binary file, meaning it consumes space, and exposes all expected symbols.

Yet, I've not found where exactly the *.cso support is disabled, if it is.

Presuming I would like to re-enable this support, is there a place to look at ?
Can this support be enabled with a simple build flag at compilation time ?

I'm interested in this topic, and may even provide some patches to improve performance of this code path. That is, if there is a way to test the code changes ....
I personally think that the cso format will take extra time and is not very good for compatibility
*.cso support seems broken directly within `applications/iso_loader`.
It doesn't even reach the point where `sd.bin`, the actual SD Card reader firmware, can start its work.
I suspect that iso_loader tries to read the *.cso file once it's selected in GUI, in order to extract some information, such as the name of the game.
It crashes right there, with ugly traces and core dump.

All versions of the iso_loader app crash the same way since RC4 (while RC3 works correctly).
That means this bug has been out since ~4 years.
The ability to print and read traces would help a lot for debugging.
So far, I'm limited to code reviewing, which can catch a few "obvious" things, but is insufficient for serious debugging.

Anyway, having fixed a nb of minor trivial bugs in iso_loader code path, probably without visible consequences,
I've now reached a part where I suspect the *.cso related crash may lie.

Selecting a *.cso file (or any other type of image) on GUI
triggers `fs_iso_mount()`,
which, after successful loading and mounting, invokes `virt_iso_init_percd()`.
That's where it seems to go wrong for *.cso.
`virt_iso_init_percd()` invokes `get_toc_and_lba()`,
of which 2 versions exist in source code, but one is commented, hence only one is valid.
There is no explanation as to why the other version is commented out though left in the code.

Comparing these 2 versions, the code paths for *.cso look very different.

The new code invokes `get_lba_from_mki()` to determine `lba`.
If it doesn't, it unconditionally set it to 150 (a magic number without a name),
and there is this an associated comment :
// TODO: isofile_find_lba(ifs);

which looks suspicious.

This only matters if `get_lba_from_mki()` fails, but without traces, it's difficult to determine if it's what happens.
In most cases for repacked ISO images used LBA 150, this is a zero LBA for DC GD-ROM.
If ISO is a part of GDI (track03), then LBA fixed to 45000.
CSO doesn't support in IDE loader since RC4, only SD loader support it.
Is ISO image has another LBA, then I try search MKI string in ISO header, that's leave mkisofs at image creation.
But it's not good way, so I put TODO here for it.
URL ссылки