Вопрос, разумеется, в первую очередь, к CaH4e3'у, ибо
Цитата:
Довольно быстро РОМ был зверски препарирован, а алгоритм запаковки - полностью изучен.
Вот всё никак не пойму, в чем заключается непосредственно сжатие. На первый взгляд собака порыта здесь:
Код:
seg005:9007 sub_9007: ; CODE XREF: sub_C3D1-3548p
seg005:9007 STA byte_14; на входе в аккумуляторе упакованный единичный байт, соответствующий нужному указателю(?)
seg005:9009 AND #$F8 ; '°'
seg005:900B STA byte_15
seg005:900D LSR A
seg005:900E LSR A
seg005:900F LSR A
seg005:9010 TAY
seg005:9011 ADC byte_15
seg005:9013 STA byte_15
; b15 := ((ptr&$F8) shr 3)+ptr&$F8 Что за странная арифметика? Очевидно, что в b15 не
;учитываются младшие три бита упакованного байта. И результат является индексом указателя в таблице указателей в РОМе
seg005:9015 LDA byte_14
seg005:9017 AND #7
seg005:9019 BEQ loc_9022
; Если младшие 3 бита не выставлены, это означает, что инкремент значения будущего считанного указателя больше восьми, и его
;надо читать отдельно (становится возможным увеличить значение указателя вплоть до $FF, но, очевидно, теряется вообще весь
;эффект от сжатия указателя, т.к. использованы уже два байта)
seg005:901B TYA
seg005:901C ADC byte_14; b14 := (ptr&7)+ptr shr 3 - (?! зачем это)
seg005:901E TAY
seg005:901F INY
seg005:9020 LDA ($A),Y ;Загрузка инкремента младшего байта указателя
seg005:9020 ; Смещение относительно 9435 - начало таблицы указателей
seg005:9022
seg005:9022 loc_9022: ; CODE XREF: sub_9007+12j
seg005:9022 LDY byte_15
seg005:9024 ADC ($A),Y ; Загрузка младшего байта из таблицы байтов указателей в РОМе
seg005:9026 STA Low_Ptr_Byte
seg005:9028 INY
seg005:9029 LDA ($A),Y ; Загрузка старшего байта из РОМа
seg005:902B ADC #0
seg005:902D STA Hi_Ptr_Byte
seg005:902F RTS
Итак, какие отсюда сдедуют выводы. Непосредственно значений байтов базовых указателей в lookup table может быть аж $FF shr 3 = $1F или аж целых 15 двухбайтовых указателей. Очевидно, что все ситуации с указателями будут решаться за счет именно трех младших битов (или, если их не хватит, дополнительного прочитанного байта). Зачем тогда эти арифметические головоломки с индексом указателя в таблице и индексом инкремента? Не легче ли было бы просто разделить на старший и младший байты и просто упаковать старшие байты указателей RLE, к примеру. Думаю, это бы значительно перекрыло по эффективности этот странный способ. Я уж не говорю вообще об идее паковать как-то указатели, в то время, как сам текст не сжат.
Не ошибся ли я где-нибудь? Может быть, дело вообще обстоит по-другому?
Спасибо.