Примерно посчитал вариант b2mа, если не ошибся получилось 139 тактов/символ, весьма шустро. 29 байт/символ (+таблица 256 байт), символов максимально 64 и минимум 2 из них служебные (перевод строки и конец текста).
Прикинул вариант с 256 символами (16 байт/символ + дополнительно надо посчитать), но с полезной матрицей 8x6 + 2 строки пустые, у меня получилось в районе 200 тактов/символ.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Можно быстрее.Сообщение от ivagor
1. Учесть, что часть байтов повторяются, тогда часть lxi меняем на mvi или убираем.
2. Совсем другой вариант на базе идей Дениса Грачева. Адрес текста в SP, но не коды букв, а адреса процедур. Базовый вариант:
2.1. Свободны 4 регистра в которые можно поместить 4 наиболее используемых в символах байта (один явно будет 0). Меняем соответствующие mvi m,data на mov m,r.Код:;SP - адрес текста ;HL - экранный адрес ;A - младшая половина экранного адреса inr h mov l,a mvi m,data0\ inr l ;7 повторов ... mvi m,data7 ret
2.2. При сдвиге на 1 строку можно выводить нулевые байты только если они идут после ненулевых. Плюс досрочное окончание процедуры если внизу остались только нули. Тогда вывод пробела сокращается до
Код:inr h\ mov l,a\ ret
Правильно ли я понимаю вашу мысль, что вы предлагаете не сдвигать экран, а просто перепечатывать его поверх особым образом, сдвинув на один пиксель вверх? Неужели это может быть быстрее, чем сдвигать блок 8*8 вверх на пиксель?
И сразу оговорюсь, что в используемом шрифте нижняя строка не всегда пустая. Я точно помню, что как минимум "y" занимает низ. У меня из-за неё скорллинг "мазал" (оставлял след) в одном из моих экспериментов.
А что при таком варианте делать с верхней и нижней с текстовыми строками?
Вообще в оригинале, который я пытаюсь скопировать 1:1, текст попиксельно появляется снизу, и также попиксельно исчезает сверху. Я пока для упрощения нижнюю строку просто печатаю целиком, но тоже в дальнейшем обязательно планировал привести к должному виду.
С уважением, Станислав.
Попробуй сочинить сравнимую по скорости процедуру сдвига, вряд ли это возможно.
Второй вариант хорошо подходит, добавляется девятая нулевая строка только для букв у которых восьмая не пустая.
1. Отдельные "классические" процедуры для верхней и нижней строки.
2. Или вывести верхнюю строку быстрой процедурой и сразу стереть лишнее, аналогично для нижней.
- - - Добавлено - - -
Ступил, в букве с ненулевыми строками будет в начале mov l,a поэтому в пробеле это не нужно и остается только inr h\ ret
Запутался.
- Вариант b2m не подходит по причине того, что нужно принудительно стирать линию ниже. Ну либо же потом отдельной рутиной стирать её. А если делать шрифт высотой 10 пикселей, чтобы две нижних строки были гарантированно пустыми?
- Варинат ivagor выглядит привлекательным, но там текста почти на 4 кило, а при этом в памяти ещё нужно место под музыку и 7 картинок. Таким образом, чтобы закодировать 4 кб текста процедурами просто не хватит памяти.
Либо я не понимаю того, что вы предлагаете.
С уважением, Станислав.
Почему нет? В каждой процедуре добавится 4 байта lxi d,0 + push d.
Т.е. место для 4 кб есть, а для 8 кб нет? Тогда вариант b2m.
Но меня смутило про "закодировать 4 кб текста процедурами". Число процедур зависит от числа букв, не от размера текста, у b2m 64 процедуры максимум по 30 байт (если 10 строк) + таблица переходов 256 байт.
Значит, я не до конца понял идею. Я твой пример интерпретировал как кодирование каждой буквы текста (не фонта!) отдельной процедурой. У меня не тут уровень, конечно - я всё делаю по-деревянному, чисто в лоб.
С уважением, Станислав.
Я вижу, что вы понимаете друг друга с полуслова, но прошу всё-таки пояснить и разжевать для тупых суть этого волшебного метода. Я даже подключил ИИ к вашему диалогу, но и он трактует то, о чём вы тут пишете, как последовательность процедур печати каждого символа без всяких таблиц на 256 байт. Что за таблица, какова её структура? Как можно переходить на таблицу по "JMP TABFONT "? Можно чуть полнее код увидеть?
С уважением, Станислав.
Если я все правильно понял, в таблице команды JMP на адреса фрагментов кода для вывода различных символов, выравненные по границе 4 байт. Старший бит адреса таблицы фиксированный, младший выбирается записью в операнд команды JMP (STA $+20) кода символа, умноженного на 4. Во втором варианте отдельной таблицы нет, строки кодируются просто последовательностью адресов фрагментов кода, рисующих символы, в обратном порядке.
Как уже написали достаточно младший байт в адресе перехода поправить, это стандартная штука для lut таблиц, они как правило выравниваются на 256 байт в паяти.TABFONT выглядит как список джампов, примерно так:
jp drawLetter0 : nop : jp drawLetter1 ; nop и.т.д
Я вот немного не понял зачем выравнивать по 4 байта, jmp+адрес вроде 3 занимаютМожно договорится что код символа умноженные на три юзаем и тогда 85.33333 влезет тайла ) на спектруме ещё jr можно заюзать для служебных...
Но мне кажется твой вариант "в лоб" выглядит вполне ок, я бы не упарывался ради текста )
Последний раз редактировалось DenisGrachev; 20.09.2025 в 06:44.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
