Значит, я не до конца понял идею. Я твой пример интерпретировал как кодирование каждой буквы текста (не фонта!) отдельной процедурой. У меня не тут уровень, конечно - я всё делаю по-деревянному, чисто в лоб.Цитата:
Сообщение от ivagor
Вид для печати
Значит, я не до конца понял идею. Я твой пример интерпретировал как кодирование каждой буквы текста (не фонта!) отдельной процедурой. У меня не тут уровень, конечно - я всё делаю по-деревянному, чисто в лоб.Цитата:
Сообщение от ivagor
Я вижу, что вы понимаете друг друга с полуслова, но прошу всё-таки пояснить и разжевать для тупых суть этого волшебного метода. Я даже подключил ИИ к вашему диалогу, но и он трактует то, о чём вы тут пишете, как последовательность процедур печати каждого символа без всяких таблиц на 256 байт. Что за таблица, какова её структура? Как можно переходить на таблицу по "JMP TABFONT "? Можно чуть полнее код увидеть?
Если я все правильно понял, в таблице команды JMP на адреса фрагментов кода для вывода различных символов, выравненные по границе 4 байт. Старший бит адреса таблицы фиксированный, младший выбирается записью в операнд команды JMP (STA $+20) кода символа, умноженного на 4. Во втором варианте отдельной таблицы нет, строки кодируются просто последовательностью адресов фрагментов кода, рисующих символы, в обратном порядке.Цитата:
Сообщение от CityAceE
Как уже написали достаточно младший байт в адресе перехода поправить, это стандартная штука для lut таблиц, они как правило выравниваются на 256 байт в паяти.TABFONT выглядит как список джампов, примерно так:Цитата:
Сообщение от CityAceE
jp drawLetter0 : nop : jp drawLetter1 ; nop и.т.д
Я вот немного не понял зачем выравнивать по 4 байта, jmp+адрес вроде 3 занимают :) Можно договорится что код символа умноженные на три юзаем и тогда 85.33333 влезет тайла ) на спектруме ещё jr можно заюзать для служебных...
Но мне кажется твой вариант "в лоб" выглядит вполне ок, я бы не упарывался ради текста )
Да, ничего не мешает в варианте b2ma сделать 85 символов/тайлов. Если нужно 256 символов, то +22 такта и таблица 1024 байта (тут уже придется умножать на 4, на 3 долго на ходу).
Я кстати не особо понял как такой вывод на экран Специалиста делать, он же вроде линейный или я что-то путаю? :)Цитата:
Сообщение от ivagor
Даже 86, таблица вылезет на 2 байта за 256.Цитата:
Сообщение от ivagor
Экран специалиста можно рассматривать как перевернутый и расширенный в полтора раза битплан вектора.Цитата:
Сообщение от DenisGrachev
Наконец-то, после разжёвывания и до меня дошло ;) Получается, конечно, громоздко и сложно. Но это очевидно - тут либо скорость, либо краткость.
Учитывая, что всё это для скроллинга, то тут придётся рулить отдельными строками.
Вот и я уже начинаю подумывать, что упарываться не стоит. Хотя, безусловно, хочется получить максимально идеальную картинку. Но, видимо, придётся просто оптимизировать то, что есть + пропускать пустые строки.Цитата:
Сообщение от DenisGrachev
В общем, проверил на практике метод b2m! Снял было с эмулятора видео, но несовпадение частоты сильно портит впечатление.
https://plvideo.ru/watch?v=TNtbeJ87CA43
Перемещается текст действительно шустро. Но всё равно сказывается отсутствие какой-либо синхронизации - строки прыгают.
Запас скорости в таком случае можно потратить на уменьшение разрывов добавлением задержки после каждого сдвига. Так будет меньше разрывов/минуту и субъективное впечатление улучшится.