ЭТЮДЫ

[Bedazzle]

А можно текст по ссылки из группы ФИДО в читаемой кодировке? А то мне браузер не даёт сменить кодировку.

Похоже, фиг

[Advertiser]

[Dart Alver]

А можно текст по ссылки из группы ФИДО в читаемой кодировке?

Похоже, фиг

А так ? https://groups.google.com/forum/?hl=...0/HRyzU9fkmU4J

[blackmirror]

В дополнение/окончание темы bin2bcd с использованием daa. Оказывается достаточно давно на форуме уже была ссылка на такую процедуру (там много чего).

Эти процедуры нельзя считать окончанием темы, поскольку на форуме были и более оптимизированные варианты. Вообще использовать 32х разрядное умножение/деление для генератора случайных чисел идея так себе. Лучше взять CRC32 и на выходе сделать XOR старшей и младшей половины, это явно будет менее 3000 тактов. А вот то, что в делении торчит add hl,bc / jc $+4 / sbc hl,bc вообще никуда не годится. Мы уже выяснили, что нужно вычитать или добавлять делитель в зависимости от знака остатка, переходя в другую ветку, если знак поменялся. Это следует из тех соображений, что после вычитания и сдвига мы должны получить 2A-2B или 2A если вычитание было ошибочным и мы делали коррекцию. При следующем вычитании мы получим 2A-2B-B или 2A-B, которое равно 2A-2B+B, то есть делать коррекцию не нужно!
Даже 8080 при всех своих ограничениях может весьма эффективно делить число любой длины на 16 разрядное, и немного менее эффективно чем zx80 одолеть и 32х разрядный делитель, правда в последнем случае ему придётся грузить делитель или минус делитель в BC частями.

[ivagor]

"Окончание" я только про bin2bcd. Варианты с вычитанием 4,4,2,1 немного быстрее, но заметно крупнее и хуже масштабируются. Для процедуры bin2bcd компактность в сочетании со скоростью для меня важнее максимальной скорости, но это для меня, у каждого свои приоритеты. Если есть еще варианты - интересно взглянуть.
А про остальные процедуры по ссылке я ничего не писал (про скорость и размер), кроме того, что они там есть, т.к. я их внимательно не смотрел.

[blackmirror]

У меня как-то была необходимость разбирать гигабайтные логи, строки там были примерно такого вида:
20/02/03 16:13:12.536 1234586903 2A8 8C 2D B3 2C 23 3E
В некоторых логах для дня или месяца могла быть и одна цифра или миллисекунды(когда их меньше 100), могли быть выведены с двумя цифрами. В десятичном счётчике число цифр тоже постоянно увеличивалось, первое 16 разрядное число могло быть как с 2, так и с 3 цифрами, ну а 16ричных байт тоже могло быть произвольное количество. Ну и количество пробелов тоже иногда плавало. В общем решением этой задачи оказалась хеш таблица размером в 65536 элементов, из строки брались символы по 4 штуки как простое 32 разрядное число, умножались на магическую константу, после чего получался индекс в таблице. По нему проверялось совпадают прочитанные цифры с тем что есть в таблице, какое они имеют значение и сколько цифр пропустить. То есть 16ричные байты читались вместе с левым и правым пробелом, а пропускались 3 символа, чтобы следующий байт прочитать точно так же, а последний из них в таблице сидел вместе с переводом строки и по нему было ясно что строка закончилась. Для счётчика тоже вытаскивалось по 4 цифры, которые добавлялись к накопленному значению умноженному на 10000. В итоге скорость разбора этих логов стала совпадать со скоростью чтения диска, даже ассемблер брать не пришлось.

[ALKO]

В общем, с компрессором пока отбой.
BMP2SCR неплохо трамбует, и можно задавать адрес декомпрессии.
Разве что пока с познакоместной пересылкой из буфера на экран со скроллом/проявлением из центра пока не знаю чё делать. Я в таких вещах лишь теоретик.

[Bedazzle]

Разве что пока с познакоместной пересылкой из буфера на экран со скроллом/проявлением из центра пока не знаю чё делать.

Вот нифига не понятно, как выглядеть должно.
Плюс непонятны ограничения по памяти/скорости.

[ALKO]

Вот нифига не понятно, как выглядеть должно.

Есть картинка. При нажатии влево - картинка скроллится познакоместно вправо за пределы экрана, и тут же вслед за ней появляется новая, скроллом.

Проявление из центра -> имеющаяся картинка на экране зарисовывается познакоместно следующей.

.Плюс непонятны ограничения по памяти/скорости

Это не экшн, так что скорость не критична. Но и слоупочно нежелательно, шоб не сильно выбешивало. Если 8px скролл выйдет тормозным, то можно и 16px.

По памяти пока я и сам точно не знаю границы. Арты пока что в процессе.

- - - Добавлено - - -

Кроме того, я хотел задействовать банки 128кб тачек.
Но это для меня темный лес.
Они еще и на 16кб разбиты, то есть инфа будет фрагментирована, если туда картинки паковать.

[Bedazzle]

Есть картинка. При нажатии влево - картинка скроллится познакоместно вправо за пределы экрана, и тут же вслед за ней появляется новая, скроллом.

Говнокод, чисто чтоб понять задачу. В правой части мерцают атрибуты, на это пока покласть.
/... удалено .../

Жесть вчера фигню наворотил
Вот поприличнее вариант:

https://www.dropbox.com/s/p6v8w3koz6...ller2.sna?dl=0

[Bedazzle]

А по-хорошему, если фуллскриновые картинки, лучше резать на 32 вертикальных блока + атрибуты и пожать zx7.
Если картинок много, то будет выигрыш по объёму.

- - - Добавлено - - -

Из центра так должно выезжать? Т.е. замещающая картинка от краёв к центру, или от центра к краям?

https://www.dropbox.com/s/z2w4b54z0z...enter.sna?dl=0

https://pastebin.com/1wT9ceMR