Баг в depacker от hrust1.3?

[psb]

выход из ситуации - добавить в конец пакуемого блока кучу нулей. штук так 50-200.

[Advertiser]

[psb]

именно так.

[moroz1999]

А разве распаковщик не знает, каков размер неупакованного блока? Всё еще с трудом понимаю, почему нахлест возникает. Ему для распаковки нужен какой-то буфер, который приплюсовывается к архиву, и поэтому оно не влезло?
Просто я почитал первоначальный пример - там у меня распакованный файл весил примерно 6кб. Упакованный, соответственно, тоже не больше. Распаковка велась на 49152 - то есть 16 кб до конца памяти было, должен был влезть и упакованный, и распакованный вариант.
Кстати, а megalz тоже так свободно по памяти катается?

[psb]

следите за руками:

0. допустим, есть у нас исходный файл в 6к, сжатый до 3х.

1. распаковщик перемещает упакованный 3к блок так, что последний байт упакованного блока совпадает с посл. байтом будущего распакованного (т.е. он старается не занимать места больше, чем распакованный блок, не вылезать из этого окна).

2. начинает распаковывать. чем дальше к окончанию распаковки, тем указатели ОТКУДА (упак.) и КУДА (распак.) ближе друг к другу. в идеале, в самом конце они совпадают

3. при определенных условиях (те самые плохо сжимающиеся данные в конце) распакованные данные начинают перезатирать еще не распакованные... всё, капут.

таким образом, просто добавляем много нулей в конец пакуемого блока и бережем нервы. когда ничего не перезатирается, когда есть запас, все хорошо

[Vitamin]

таким образом, просто добавляем много нулей в конец пакуемого блока и бережем нервы. когда ничего не перезатирается, когда есть запас, все хорошо

Ну не всегда есть такая возможность. Иногда блок находится четко в конце памяти.

[John North]

Непонятен этот шаг с перемещением запакованного блока в конец распакованного.
Для чего?
Ведь запакованный блок УЖЕ находится в памяти. Неужели нельзя брать байты для распаковки прямо оттуда?
Зачем его таскать по памяти то лишний раз?

[jerri]

John North,
еще раз

hrust программа универсальная и считает что файл который она распаковывает имеет размер #a000 и находится по адресу #6000
поэтому он всегда старается переместить упакованный блок как можно дальше

что и видно на данном фрагменте исходника

DEHRUST PUSH DE
PUSH HL
берем размер распакованого блока
INC HL
INC HL
LD C,(HL)
INC HL
LD B,(HL)
INC HL

вычисляем конец распакованых данных

DEC BC
EX DE,HL
ADD HL,BC
EX DE,HL

берем длину пакованого блока

LD C,(HL)
INC HL
LD B,(HL)
DEC BC

проверяем на вероятность затирания

по умолчанию считается что блок будет загружен туда же куда будет распакован


POP HL
ADD HL,BC
SBC HL,DE
ADD HL,DE

JR C,LL4019
оставляем на месте

LD D,H
LD E,L
LL4019 LDDR

но последние 6 байт упакованного файла всегда сохраняются вместе с упаковщиком

но если блок находится по адресу 60000
а распаковывать надо например заставку он этот блок трогать не будет

[psb]

Иногда блок находится четко в конце памяти.

ну тогда ппц. городить костыльчик с перебрасыванием откуда-то еще.

Ведь запакованный блок УЖЕ находится в памяти. Неужели нельзя брать байты для распаковки прямо оттуда?

они могут пересекаться. универсальное решение, типа, привести к такому вот виду.

[Vitamin]

Непонятен этот шаг с перемещением запакованного блока в конец распакованного.
Для чего?
Ведь запакованный блок УЖЕ находится в памяти. Неужели нельзя брать байты для распаковки прямо оттуда?
Зачем его таскать по памяти то лишний раз?

Ё-моё... ну ты хоть соображалку включи и представь что будет, если распаковывать в ту же память, где лежит упакованный оригинал.

[moroz1999]

Мне, честно говоря, даже в голову не приходило, что можно попытаться распаковать блок с пересечением с упакованным файлом.
Имхо, в таком случае в распаковщик нужно добавить проверку - если в памяти достаточно места, то не делать копирование. Размер распаковщика, конечно, вырастет, но геморроя уменьшится.
С MegaLZ я не встречал такой ситуации ни разу - MegaLZ работает иначе или мне еще "повезет"?