Создать ответ 
 
Рейтинг темы:
  • Голосов: 0 - Средняя оценка: 0
  • 1
  • 2
  • 3
  • 4
  • 5
cso support
Автор Сообщение
sundance Не на форуме
Новичок
*

Сообщений: 7
Зарегистрирован: 15.03.2020
Рейтинг: 0
Сказал спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщ.
Сообщение: #1
cso support
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 ....

Pristine unmodified Dreamcast in perfect condition + SD Card reader on serial Port.
(Последний раз сообщение было отредактировано 18.03.2020 в 10:49, отредактировал пользователь sundance.)
18.03.2020 10:47
Найти все сообщения Цитировать это сообщение
Создать ответ 


Сообщения в этой теме
cso support - sundance - 18.03.2020 10:47
RE: cso support - kof888 - 18.03.2020, 13:42
RE: cso support - sundance - 20.03.2020, 03:31
RE: cso support - sundance - 29.03.2020, 03:54
RE: cso support - SWAT - 30.03.2020, 12:41
RE: cso support - sundance2 - 24.11.2020, 20:58
RE: cso support - SWAT - 25.11.2020, 07:01
RE: cso support - sundance2 - 25.11.2020, 09:24
RE: cso support - sundance2 - 25.11.2020, 13:05
RE: cso support - SWAT - 27.11.2020, 06:54
RE: cso support - sundance2 - 27.11.2020, 23:11
RE: cso support - SWAT - 29.11.2020, 09:42

Переход:


Пользователи просматривают эту тему: 1 Гость(ей)