Просмотр полной версии : 80 символов в строке и режим 512 точек вообще
Подумал, что я никогда не пытался даже точечку нарисовать в этом режиме. А скорость вывода текста в МикроДОС всегда навевала тоску. И решил попробовать сделать сам. Провозился день, но понял только, что МикроДОС не пальцем деланый и с учетом обстоятельств выводит текст еще даже можно сказать быстро.
Моя совсем пока неотесанная попытка (гист в прекрасме (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/d8a4a92e0d64b85cfd4bbd44311d577b/raw/28e4429f1f9e7da337455ecee12c2e568ad98b71/text512-ivagor.asm)).
Сначала сделал вариант честный, который очищает сам себе знакоместо (это blx_jumptbl), как это требуется в эмуляции терминала. Потом сделал второй, который считает, что текст всегда печатается по заранее очищенной области слева направо (nblx_jumptbl). В условиях эмуляции терминала это нельзя гарантировать, но в других случаях это по-моему разумное ограничение.
Шрифт 6х8 разворачивается половинками глифов: 8 байт для плоскости A000 + 8 байт для плоскости C000 (используются младшие три бита, в Векторовской проекции это получается сдвиг на 5).
Впечатления довольно тяжкие. 512 точек -- ужасно неудобный для рисования режим, а уж 80 символов в строке, при том, что получается по три бита на знакоместо -- восьмикратно неудобный. Думаю, может быть я вообще что-то неправильно понял и можно совсем не так все делать. Было бы прикольно, если б получилось выжать за прерывание хотя бы строку. Сейчас выходит только 43 символа. То есть если 80х25, то нужна почти секунда, чтобы заполнить весь экран текстом.
Нету ли, кстати, в удобном виде шрифта, который используется в МикроДОС-е? Тот шрифт 6x8, который я нашел, только родная мама способна полюбить.
Improver
11.07.2022, 14:55
А скорость вывода текста в МикроДОС всегда навевала тоску.Кстати, в теме про операционки, ivagor проводил исслелования по скорости вывода текста (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=568511&viewfull=1#post568511), рекорд был за РДС, следом Т-34 и Т-72...
Нету ли, кстати, в удобном виде шрифта, который используется в МикроДОС-е? Тот шрифт 6x8, который я нашел, только родная мама способна полюбить.Шрифт в бинарном виде есть в тех же исходниках РДС (https://github.com/ImproverX/RDS), в текстовом виде через "DB ..." я делал в исходниках Т-34 (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=1006342&viewfull=1#post1006342) и Т-72 (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=1060074&viewfull=1#post1060074), но удобным его тоже не назовёшь.
DB это достаточно удобно. А где эти самые исходники?
Ну что ж, у меня примерно 2150cps с упомянутыми ограничениями. В сравнении с 776cps это кажется много, но в МикроДОСе работает еще эмуляция терминала, и вряд ли шрифт хранится развернутым в 4КБ памяти. Так что пока мой результат так себе. RDS мощна.
- - - Добавлено - - -
P.S. Увидел ссылки на исходники.
Improver
11.07.2022, 15:41
Ну что ж, у меня примерно 2150cps с упомянутыми ограничениями.Это почти в три раза быстрее! :) Упомянутые ограничения же не замедлят вывод в три раза?
Тут, кстати, есть ещё такой ньюанс: тест ivagorа выводил не полную таблицу символов, а у Т-72 и Т-34 из-за особенностей драйвера кириллица выводится медленнее, чем латиница. Так что средняя скорость вывода там будет меньше, и 2150 символа в секунду -- это прямо хороший результат по сравнению с ДОСами. Можно ещё сравнить скорость со скоростями в мониторах-отладчиках, для полноты картины.
вряд ли шрифт хранится развернутым в 4КБ памятиДОСы так его и хранят в памяти, развёрнутым, но не на 4кБ, а всего 1792 байта в Т-72 и 2560 байт в РДС...
Трудно предсказать, что именно съест время, поэтому все-таки сравнивать лучше эквивалентные вещи.
В моем примере все символы равноценны и их 256, так проще. Вот как у РДС получилось 2560 байт вместо 4096 -- любопытно. Предполагаю, что отрезанием непечатных и подменой глифов типа русская A / латинская A ?
Меня огорчает, что в этом развернутом хранении используются три бита от каждого байта. Обидно столько замечательных бит терять, ведь люди делали. Но все сдвиги и маскирования на 8080 даются ужасной болью.
Думаю, может быть можно что-то выгадать, если сразу принять, что строка 80 символов рисуется целиком залпом. Определенно небольшое количество вычислений координат можно упростить, но это вряд ли даст очень много - в моем бенчмарке максимум можно будет увидеть следующую букву, может полторы. Все-таки львиная доля -- это сдвиги, загрузки, маскирование.
- - - Добавлено - - -
Update: 44 символа =) Там конечно есть еще чуть чуть лишнего, но до 80 так вряд ли получится доехать.
Сразу скажу, что blit не переделал (поленился), но и на примере nblit примерно понятны пределы роста. Можно еще быстрее, но совсем на чуть-чуть.
- - - Добавлено - - -
И еще вот так можно
Думаю, может быть можно что-то выгадать, если сразу принять, что строка 80 символов рисуется целиком залпом.
А если столбцами? Там можно кое-что выгадать, я думаю.
Особенно если рисовать, как делает Manwe, побитовыми столбцами.
Моск приблизился к точке кипения, стала проскакивать тупая копипаста, но почти букву еще выгрыз
Improver
11.07.2022, 22:46
Вот как у РДС получилось 2560 байт вместо 4096 -- любопытно.Получается в шрифте РДС на один символ 2560 / 256 = 10 байт, вполне нормально, даже с запасом на надстрочные и подстрочные "закорючки"... Надо посмотреть исходники РДС, как там символы кодируются.
ivagor, спасибо! у меня тоже моск выкипел честно говоря. При беглом просмотре вижу, что у тебя примерно что и у меня в последних изменениях -- ты сделал вторую половинку в обратную сторону (чтобы делать dcr на второй странице) и креативное используешь bc в некоторых сдвигах. Попробую разобраться когда немножко остужу моск.
- - - Добавлено - - -
А bc/de/hl ты переставил чтобы pchl использовать?
- - - Добавлено - - -
А, вижу, ты битмапы развернул хитро.
ivagor, взял твою версию, пожульничал с ней -- 128 символов, четыре развертки, плюс убрал вычисление терминальной строки на каждый символ. Получилось 53 символа, почти 54 без самой тютельки. В первом сообщении обновил ссылку.
- - - Добавлено - - -
Получается в шрифте РДС на один символ 2560 / 256 = 10 байт, вполне нормально, даже с запасом на надстрочные и подстрочные "закорючки"... Надо посмотреть исходники РДС, как там символы кодируются.
Это да.. в смысле, что хранить так нормально, но для быстрого рисования это компромисс.
- - - Добавлено - - -
Upd: выстрадал тютельку, полных 54.
- - - Добавлено - - -
А если столбцами? Там можно кое-что выгадать, я думаю.
Особенно если рисовать, как делает Manwe, побитовыми столбцами.
Что такое побитовые столбцы? Тут в принципе и так столбцами, но не обязательно организованными наилучшим образом. Одна из проблем в том, что ширина текстовых колонок, если их 80 конечно, не кратна байтам.
Что такое побитовые столбцы? Тут в принципе и так столбцами, но не обязательно организованными наилучшим образом. Одна из проблем в том, что ширина текстовых колонок, если их 80 конечно, не кратна байтам.
Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. То есть, маска бита на весь столбец фиксирована, м идём сверху вниз, сдвигая изображение стобца и по переносу определяя, закрашивать писель или нет. Т.е. символ хранится не горизонтально, а вертикально нарезанный. Выходит унифицированный код вместо зоопарка со сдвигом на 0/2/4/6 пикселя.
Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. ...
Получится значительно больше операций с памятью, а они медленные.
Или при горизонтальном выводе тоже каждый пиксель отдельно на экран выводится?
Подозреваю, что байт читается, дополняется текущей маской и сохраняется в экран. При высоте символа 8 пикселей, выходит в лучшем случае 16 чтений, 16 записей, в худшем 32/32. Если каждый пиксель выводить отдельно, то всегда 48 чтений, 48 записей.
Немного капитанства. В рамках выбранного подхода осталось разве что добавить оставшиеся промежуточные предсдвиги (увеличить память под предсдвинутый фонт вдвое). Дальше уже только за счет стека. Там полный предсвдиг, а для x_6 и x_7 даже по 2 байта на строку, чтобы убрать "лишние" логические операции. Если не запрещать прерывания, то придется добавить по 2 байта между символами. Вычисление адреса буквы опять замедлится, рисование ускорится. "Нет худа без добра, сказала лиса, зато ты сможешь разместить предсдвинутые фонты в квазе". Смысл стековый вариант имеет, если выводить символы группами, один раз сохраняем sp, выводим группу (без вызовов процедур, только переходы), восстанавливаем sp.
Получится значительно больше операций с памятью, а они медленные.
А сдвиги -- они быстрые? Ведь при горизонтальном выводе пиксели надо ещё и сдвигать. 16-разрядным сдвигом, поскольку они могут заехать в соседний байт. В худшем случае -- сдвигать на 4 бита. 32 16-разрядных сдвига. А так всего 48, по разу на пиксель, чтобы достать очередной бит.
Хотя, разумеется, можно завести таблицу на 512 байт и вращать через неё.
... разместить предсдвинутые фонты в квазе". ...
Во-во, распаковать предсдвинутые фонты на кваз, в файл. Его адрес (на квазе) сохранить для возможности прямого доступа, а не через файловую систему.
Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. То есть, маска бита на весь столбец фиксирована, м идём сверху вниз, сдвигая изображение стобца и по переносу определяя, закрашивать писель или нет. Т.е. символ хранится не горизонтально, а вертикально нарезанный. Выходит унифицированный код вместо зоопарка со сдвигом на 0/2/4/6 пикселя.
Получается, что по одному пикселю за шаг мы закрашиваем? Это может быть удобно/интересно для компактного хранения, но точно не для быстрого рисования. Как упражнение можно будет попробовать, даром что фонт в моем примере изначально как раз лежит на боку.
- - - Добавлено - - -
Немного капитанства. В рамках выбранного подхода осталось разве что добавить оставшиеся промежуточные предсдвиги (увеличить память под предсдвинутый фонт вдвое). Дальше уже только за счет стека. Там полный предсвдиг, а для x_6 и x_7 даже по 2 байта на строку, чтобы убрать "лишние" логические операции. Если не запрещать прерывания, то придется добавить по 2 байта между символами. Вычисление адреса буквы опять замедлится, рисование ускорится. "Нет худа без добра, сказала лиса, зато ты сможешь разместить предсдвинутые фонты в квазе". Смысл стековый вариант имеет, если выводить символы группами, один раз сохраняем sp, выводим группу (без вызовов процедур, только переходы), восстанавливаем sp.
Предсдвиги здорово помогли для тех случаев, где было четыре и три сдвига. В текущем варианте третий предсдвиг дал очень мало. Для спорта тут все способы хороши, но для практики я думаю достаточно двух.
Со стеком я не очень понимаю как тут выгадаешь. Потому что ldax inr ldax inr -- это 32 такта, а pop mov mov -- это 28, 4*16 = 64 такта. Ухуху. Но на подготовку и восстановление затраты отнимут 60 тактов (если память не изменяет, может быть и хуже). 4 такта в лучшем случае, проще выпилить xchg там, где он остался от лени. Выгоду можно получить только если вынести подготовку-восстановление за скобку на все рисование строки, но тогда это совсем жесть и даже бенчмарк непонятно как тогда делать.
Если говорим о простой пересылке (без логических операций), то без стека 32 такта/байт, как ты написал, а стеком pop mov inr mov inr - 22 такта/байт. При выводе 16 байт выигрыш 160 тактов и, как уже я написал, лучше сохранять стек один раз на группу символов, это здорово сэкономит время.
Если говорим о простой пересылке (без логических операций), то без стека 32 такта/байт, как ты написал, а стеком pop mov inr mov inr - 22 такта/байт. При выводе 16 байт выигрыш 160 тактов и, как уже я написал, лучше сохранять стек один раз на группу символов, это здорово сэкономит время.
Погоди, как так. Я тоже странно посчитал. Все зачеркиваем.
Для столбцов не разбитых на два:
Загрузка двух строк по ссылке: ldax \ inr \ ldax inr -- это 32 такта. Стеком две строки: pop mov mov = 12 + 16 = 28. Выгода 4. Это выгода на пару строк, то есть умножаем на 8 пар, итого -32.
Если столбцы разбиты на два, сразу для двух строк считаем. Загрузка по ссылке: ldax ldax inr ldax ldax inr = 48 тактов, стеком: pop mov mov mov mov = 44 такта. Опять то же самое, 4 выигрыш. Те же -32.
Как у тебя получились такие большие цифры?
Я считал время простой (без дополнительных операций) пересылки (_x_0)
Без стека: ldax inr stax inr - 8+8+8+8=32 такта/байт
Стеком: pop mov inr mov inr - 12+8+8+8+8=44 такта/2 байта=22 такта/байт
- - - Добавлено - - -
Посчитаем время пересылки с OR для x_1 - x_5
Без стека: ldax inr ora mov inr - 8*5=40 тактов/байт
Стеком: pop mov ora mov inr mov ora mov inr - 12+8+4+8+8+8+4+8+8=68 тактов/2 байта=34 такта/байт, тут выигрыш меньше, 6 тактов/байт
Для x_6 - x_7 мне лень считать, если уж только это будет очень принципиально.
Понял, ты с записью вместе считаешь, это у тебя mov m. Тогда вижу. Но это частный случай для сдвига 0, если есть предсдвиг в 0. А остальные 7?
А остальные 7?
Я расписал 6 (1+5) из 8, еще 2 не очень хочется считать, там много.
Еще один резерв - высота символа. В зависимости от шрифта символы могут быть максимум 7 или даже 6 (или даже 5) точек. Если нужна скорость любой ценой, то стоит воспользоваться. Знакоместо будет повыше, чтобы буквы не слипались, просто одна-две-три линии будут всегда пустые.
Угу, я видел и прочитал. Считать по-моему больше не нужно, вполне понятно и так.
Одну строку наверное можно отрезать, если шрифт расчитан на нулевой зазор между строками (вот этот именно может быть такой и есть). Две это как-то слишком, мы заходим в территорию условно-читаемых шрифтов 3х4.
- - - Добавлено - - -
Ломать не строить, отрезал одну строку (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/d8a4a92e0d64b85cfd4bbd44311d577b/raw/569a0e234e896d8b6c7794067105cc0978c6bfb4/text512-ivagor7.asm). 58 символов. Вроде даже gj итп не пострадали. Маленькие x и m повышенной уродскости в этом фонте, ну это не важно пока.
- - - Добавлено - - -
58 это почти 60, а 60 это почти 80 =)
Еще в жизни все-таки бывают пробелы. Это легко может быть где-то +15 на строку.
Насколько могу судить уже сейчас (без стека) получилась самая быстрая печать 80 (85) символов в строке в HiRes. Если не секрет - для чего? Спортивный интерес или для какого-то конкретного применения?
Спортивный конечно. Вообще я не ожидал, что будет так тяжело.
... Одну строку наверное можно отрезать, ...
А если для красоты оформления понадобятся символы псевдографики?
KTSerg, ну вот такая тяжелая судьба, что ты будешь делать.
С псевдографикой как минимум 2 варианта:
1. Обрабатывать такие символы отдельными более медленными процедурами
2. Уменьшить общую высоту знакоместа до высоты выводимых символов
Ну или делать красоту не текстовым способом. Все-таки у нас довольно специфическая платформа и с универсальностью подходов проблемы, наоборот приходится искать частности, чтобы создать иллюзию удобства и красоты. Проще всего наверное красоту нарисовать линиями, их можно сделать очень быстрыми. Псевдографика это для настоящих текстовых режимов, где графики нет. А у Вектора-то все ровно наоборот.
Хотел было попробовать со стеком, да понял, что для этого надо разворачивать шрифт по-старому бесхитростно.
Я наверняка все делаю не так (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/d8a4a92e0d64b85cfd4bbd44311d577b/raw/a816e9c23ff8f09b5285dcd375a430feda91c775/text512-painstack.asm). Но оверхед на использование стека съедает столько, что едва-едва получилось добиться того же результата, что был без стека.
- - - Добавлено - - -
(Ну то есть, если заменить загрузку символа из строки на перебор всех символов как раньше, то получается увидеть на три символа больше. Но и во вчерашнем примере можно было выкинуть четыре пуш-попа во внешнем цикле и это дало бы может еще и больше).
Upd: 63 символа, '!' до '_'. Но это совсем уже мир беспощадного профессионального спорта.
Upd: 64 с частичным применением советов ivagor-а
Хорошо, что ты созрел на стек, но пока это не совсем спорт высоких достижений. Нужно полностью предсдвинуть, в процедурах вывода убрать сдвиги. И убрать тормозные mov a,d и mov a,e. xchg тоже не нужен (кроме x_0)
pop h\ ldax d\ ora l\ inr e \ ldax d\ ora h\ inr e
Удалось изыскать небольшие резервы и в умеренно-консервативном варианте, еще добавил blitы, потом выложу. В принципе оттуда можно кое-что пересадить и в спортивные достековые варианты.
Рад тому, что ты сохраняешь свежесть взгляда. Предсдвинуть остальные позиции можно в $8000. Но сам я пока беру тайм-аут как минимум до позднего вечера.
Мне кажется, что если сделать внешний цикл как стековый в достековом варианте и засунуть туда вычисление столбеца по таблице, выигрыш может получиться точно такой же, а то и лучше.
Оптимизированный умеренно-консервативный вариант. Если первый дефайн закомментирован, то активны blitы, иначе nblitы. Любители ВМ1 могут дополнительно оптимизировать большинство nblit, там напрашивается.
Многочисленные
Любители ВМ1
Это как я понял вариант для пожилых? Здесь сохранены blit с аккуратным стиранием, никаких стеков и восьмикратных развертываний. Такой вариант, особенно если убрать nblit и бенчмарк, подошел бы на роль рыбы HELLO WORLD для режима 512.
Если мне понадобится 80-85 сравнительно неспешных (хотя они в разы быстрее имеющихся аналогов) символов в HiRes, то буду использовать blitный вариант из 5. К спортивному стекованию думаю еще вернемся, но все же это именно для спорта или для каких-то специальных случаев.
74 спортивных символа
(https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/d8a4a92e0d64b85cfd4bbd44311d577b/raw/4daad45901d2cb821997f31e3b2419d75bd7c75a/text512-painstack.asm)
Я пока пожалуй выдохся, хотя там вон 'k' уже нос показывает, самую тютельку бы до 75..
Вот это, понимаю, спорт. На мой взгляд остался еще шаг - отдельно удвоенно предсдвинуть для x_6 и x_7, чтобы совсем избавиться от and.
pop d\ mov a,m\ ora e\ mov m,a\ inr h\ mov m,d\ inr l
pop d\ mov m,d\ dcr h\ mov a,m\ ora e\ mov m,a\ inr l
Я думал об этих ana-х, но увидел, что один mov заменяется на ora, почувствовал прирост и угомонился. Идея сделать альтернативную двойную развертку для этих сдвигов мне в голову не приходила.
Успокоившись спортивными достижениями можно подумать о спокойной печати шрифтом плашмя, примерно как предложил Sandro. Для большого спорта это конечно не подойдет, но для Hello World 512 как раз может быть хорошо потому что шрифт хранится компактно и не требует разворачивания.
Это будет очередной виток диалектической спирали. Сначала (в мониторе, в старых досах) был вывод столбцами. Потом (в T34, РДС) сделали вывод строками. И вот на горизонте замаячил вывод столбцами, но на более высоком уровне. Надо бы сделать, поддерживаю.
Да. В общем идея сделать режим 512 более дружелюбным для всяких проб пера и написания тестов.
Вот это, понимаю, спорт. На мой взгляд остался еще шаг - отдельно удвоенно предсдвинуть для x_6 и x_7, чтобы совсем избавиться от and.
pop d\ mov a,m\ ora e\ mov m,a\ inr h\ mov m,d\ inr l
pop d\ mov m,d\ dcr h\ mov a,m\ ora e\ mov m,a\ inr l
Пришлось повозиться и немного все упорядочить, но теперь 79 - дошли до 'o' (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/d8a4a92e0d64b85cfd4bbd44311d577b/raw/61dfa4d0a43d0242f399ef47a1491db9152e6a85/text512-painstack.asm).
Есть\\\был довольно толстый скрытый резерв -- первый и последний pop используются только наполовину.
Upd: 79
Ультимативное демомейкерство, почти в 5 раз быстрее самых шустрых досов.
Сдвиги 0-5 не отличаются ничем, кроме mvi h. 6-7 аналогично. С этим практически ничего нельзя поделать, но напрягает.
- - - Добавлено - - -
Пожалуй, всё. Можно убрать хлам и поформатировать, но суть все сказано: 81 обсценно-демосценный символ за прерывание (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/d8a4a92e0d64b85cfd4bbd44311d577b/raw/2f20c1340f0dafabf6fd39624177b98900f41015/text512-painstack.asm).
- - - Добавлено - - -
P.S. Впредь буду печатать буквы только очень медленно, вызывая setpixel для каждой точки.
Круто, можно печатать 50 строк в секунду. Еще бы blitы добавить для полного счастья. Если ты не соберешься, может я потом когда-нибудь созрею.
Круто, можно печатать 50 строк в секунду. Еще бы blitы добавить для полного счастья. Если ты не соберешься, может я потом когда-нибудь созрею.
Тут полная демосцена -- иллюзия печати строки, но на самом деле мы печатаем номера столбцов. Мне кажется, что практического применения этому примеру нет, это просто памятник абсурдной оптимизации в ущерб здравому смыслу. Но все же 81, да и как кладезь всяких диких трюков это забавно.
Целесообразность добавления blit-ов именно в этой версии для меня лично тут невысокая. Сам я если чего-то и буду еще здесь делать, так это медленные столбцы, например. А в этом варианте последняя осмысленная версия по-моему была твоя, где код символа был столбцом в битмапе шрифта. Если делать пример-заготовку, я бы взял ее, причем только с nblit-ами, чтобы был минимум барахла. По-моему в рыбе важно, чтобы было минимум лишнего. А то у меня часто руки опускаются от одного вида избыточной универсальности.
Если отвлеченно фантазировать, то быстрая печать символов пригодилась бы для специальной версии доса. Актуальность такой штуки маленькая, но думаю никто не был бы против, если бы она была.
Моя отправная точка была -- как медленно отрисовыватся рогалик, вдруг можно сделать его хотя бы чуточку пошустрей. К STALK1.SAV это тоже относится. Но это так, очень отвлеченно. Делать какие-то движения в эту сторону я пока не созрел. Но этим программам в принципе ничего кроме эмуляции терминала не нужно, поэтому версия с nblit к ним теоретически приклеивается. Насколько можно ускорить тот же РДС, тут я не знаю. Подозреваю, что он тоже не пальцем деланый и места свободного под всякие модные оптимизации в нем так просто не найдешь.
Improver
15.07.2022, 15:26
Насколько можно ускорить тот же РДС, тут я не знаю. Подозреваю, что он тоже не пальцем деланый и места свободного под всякие модные оптимизации в нем так просто не найдешь.РДС и по своему функционалу хорош, и в работе быстр, но там далеко не всё оптимизировано, есть ещё резервы, я уверен. :)
есть ещё резервы, я уверен
Все равно вряд ли много можно выжать без того, чтобы отдать полпамяти под развернутые битмапы. А в формате биоса ограничения на возможности оптимизации вообще довольно жесткие получаются. Это же не демосцена, тут надо делать так, чтобы все остальное не рассыпалось.
Если без увеличения места под процедуры, то у меня так (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=950946&viewfull=1#post950946) получалось. Интересно, как там еще можно ускорить (без увеличения размера).
Если без увеличения места под процедуры, то у меня так (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=950946&viewfull=1#post950946) получалось. Интересно, как там еще можно ускорить (без увеличения размера).
А можно эти оптимизации смержить в тот РДС, что на гитхабе? А то вот я бы никогда не нашел их. Да и сейчас не знаю, что именно с ними делать. Говорит: отсутствует COMMAND.SYS.
Improver
15.07.2022, 16:47
Если без увеличения места под процедуры, то у меня так получалось.Хорошо, но что там было оптимизировано сложно будет понять и перенести в новую версию без исходников, было/стало. :(
В исходниках РДС 3, файле VIRT (https://github.com/ImproverX/RDS/blob/master/RDS/virt.asm), как я понимаю, сосредоточены все функции отрисовки символов, которые вызываются из DISP (https://github.com/ImproverX/RDS/blob/master/RDS/disp.asm). Можете их обновить в соответствии с улучшениями, сделанными в РДС 2.04 / 2.05? И запас по байтам там есть небольшой, VIRT можно увеличить на 36 байт, если что... А я уж сделаю всё остальное и соберу новый вариант. :)
1. Методику инсталляции РДС помню примерно так: нужен диск в дисководе с COMMAND.SYS РДСа. А файл РДСа (старого или нового) можно загрузить через внешнее пзу. При старте форматируем кваз (LCtrl в эмуляторах) и все должно заработать. Альтернативный вариант - взять где-нибудь готовый образ кваза для РДС. Tim0xA делал такой, вроде в комплекте VV это он. Или в комплекте Kings Bounty. Не исключено, что есть более простой подход. HDDшный РДС скорее всего может взять COMMAND.SYS с HDD.
2. Исходники патча вывода символов РДС (надеюсь) на другом компе, выложу в воскресенье, если этот вопрос останется актуальным.
Improver
15.07.2022, 17:34
1. Методику инсталляции РДС помню примерно так: нужен диск в дисководе с COMMAND.SYS РДСа.Вообще-то не нужен -- при запуске РДС с форматированием КД (с нажатым УС) он там будет создан автоматически, как и OS.COM. Для инсталляции РДС вообще ничего не нужно, кроме самого РДС, в "большом" файле rdsXXX.rom. :)
2. Исходники патча вывода символов РДС (надеюсь) на другом компе, выложу в воскресенье, если этот вопрос останется актуальным.Спасибо, посмотрим, что там...
Да, я забыл/напутал. БезHDDшным РДСам достаточно любого диска (без COMMAND.SYS), чтобы дойти до командной строки. А HDDшным (при наличии HDD или образа HDD) и дискета не нужна.
У меня получилось отформатировать диск и РДС запустилась. Почему-то клавиатура в DX-Forth не работает.
- - - Добавлено - - -
Набросал на скорую руку совершенно бесхитростный вывод столбцами.
13 печальных символов за прерывание (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/d8a4a92e0d64b85cfd4bbd44311d577b/raw/d0a921d9f4faaf884b54651ca2a934d570ee6ea1/text80-columns.asm).
Для рыбы многовато развернутых циклов, но вообще компактно и все-таки это хелло вролд с минимальной эмуляцией терминала.
Гениально! 16.
- - - Добавлено - - -
Чего-то не то форум глюканул, не то ты удалил vert2..
Эх, я думал успел удалить и шито-крыто. Поторопился с vert2, там получился nblit вместо blit. А если переделать в blit, он медленнее vert.
Немного безумия. Можно сэкономить на проверках. Ультимативный вариант - берем весь байт (столбец) и диспетчер вызывает одну из 256 процедур (они ничего не проверяют, только рисуют свой уникальный столбец). Могу предположить, что это не найдет понимания, поэтому компромиссный вариант - полубайт и 16 процедур, но тут уже надо считать, будет ли выигрыш.
Не, ну смотря для чего. Если для спорта, то да. А если для эмуляции терминала и хелло вродла, то надо чистенько и компактно по-моему.
Для подавляющего большинства шрифтов (кроме каких-нибудь инверсных) характерно заполнение чернилами <50%, поэтому выгоднее изменить операции. И еще там мелкие оптимизации по размеру.
Нашел какой-то слонопотамский фонт 6х8, выглядит неплохо. Правда почему-то налезает псевдографика сверху, никак не могу понять что не так. Если увеличить интервал между строками, видно, что сам фонт в порядке.
Версия на основе ivagor-ского вертикала с blit-ами v 3. (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/b9e849b6280e56bf59b934f5af37ba83/raw/47c3e434c3ff9f61bef9cd0718ad4b2f08ce6540/text512v.asm)
Со слонопотамским фонтом стало заметно (заворот нижней строки наверх), что в colorset не хватает mvi a,255\ out 3
Стало хорошо (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/b9e849b6280e56bf59b934f5af37ba83/raw/c858fd1f05d28924f4b402ee31e51be14ce4b0e4/text512v.asm). Вот только что это за чудо-юдо кодировка я никак не могу понять. Буковки в ней вроде как cp1251, но там есть еще псевдографика. И вот чему она соответствует я не пойму. Фонт откуда-то с форума электронщиков с LCD индикаторами, им наверное все равно.
С кодировкой надеюсь получится разобраться (или найти другой шрифт, может BOLD BIOS PPC глянуть?), а тем временем еще порция бодрости для процедуры
1. Маска по таблице
2. Быстрая очистка пустых столбцов, можно включить/отключить по #DEFINE ZeroColumn
И вероятно финальная (для меня) столбцовая версия. Оптимизированы переходы по плоскостям и между плоскостями. Каждый второй байт фонта зеркалится в другую сторону, это для наглядности, а так надо просто один раз зеркальнуть и потом пользоваться преобразованным фонтом. Получается приблизительно в 2 раза медленнее умеренного строчного варианта, зато фонт полтора килобайта, а не 4.
Что еще можно сделать - отдельно хакнуть вывод пробела. Хака может быть условной - один раз проверяем, что символ 32 пустой и настраиваем хаку.
И насчет варианта с 256 процедурами. Посчитал, что каждая из них влезет в 32 байта, т.е. 1.5 Кб знакогенератор+8 Кб развернутых процедур.
Для спорта это все конечно чудесно, особенно 256 процедур мне нравится. Эдак ты скоро обгонишь 80 символов за прерывание.
Но для рыбов я думаю даже ZeroColumn уже слишком, потому что начинает смотреться слишком спортивно. Элегантность столбцового метода теряется. Кроме того, такой код отпугивает казуальщика, приросты скромные, а лохматость растет геометрически и желание позаимствовать ее для своего будущего шедевра все меньше и меньше. Вот сделать поддержку инверсии, а то может быть даже и цвета, это было бы интересно и практично.
Так-то вообще, между прочим, для казуальщика режим 64 символа в строке тоже может быть интересен. Понятно, что в нем нет такой интриги, как мы тут получаем с 80.
BTW, прокрутка через dad h -- огонь. Я бы никогда не додумался, хотя теперь, увидев, развидеть это уже не могу.
Если нужен максимум гибкости (возможность задавать цвет символов и цвет фона) при сохранении сравнительной компактности - надо рисовать через setpixel. Скорость будет соответствующая.
Почему так категорично? Разве прямой и инверсный вывод в двух плоскостях -- это не то, что нужно для вывода произвольной комбинации цвета-фона?
Разве прямой и инверсный вывод в двух плоскостях -- это не то, что нужно для вывода произвольной комбинации цвета-фона?
Еще "полный 0" и "все 1" в рамках знакоместа. Или 4 варианта setpixel для 4 цветов.
Мне цветной текст в HiRes не особо нужен, да и сделать его не так уж сложно с имеющимися наработками. Зато уже много лет никак не соберусь (вернее надо бы, но не хочется) сделать полный опрос клавиатуры.
Это может быть не очень практично, но есть что-то волшебное в таком не без труда добытом тексте, да еще и в цвете.
Пока до такой крутотени еще далеко. Мне очень тяжело дается преодоление 512 точек, особеннно в цвете, поэтому я пока сбацал такую незамысловатую шпору (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/1623c1468a7a90d91d3b797622b19bdc/raw/e7a66ecc956dce8e216b78cef1373d008d679ba5/test512-4col.asm).
- - - Добавлено - - -
Вообще с хорошей шпорой делов-то оказалось не так и много. Далеко не идеал конечно пока и не совсем честно цвета работают (цвета 1 и 2 не затирают друг друга), но в общем это цветной текст в режиме 512 (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/099593d2d2dbcab6b44b2034747e8d96/raw/1adc58eb4213f23e9cb5945525e59c0c5381db28/text512v+reverse+color.asm) и тормозит все-таки не совсем как через setpixel.
Цветной текст в HiRes с минимальными доработками - это хорошо. Платой за простоту, насколько понимаю, является ограничение числа комбинаций цветов, но основные на первый взгляд есть.
А я добрался до исходников патчей РДС. В 205 еще и фонт надо заменить.
Платой за простоту, насколько понимаю, является ограничение числа комбинаций цветов, но основные на первый взгляд есть.
Ты имеешь ввиду разные сочетания фона и переднего плана? Их неудобно получать, но есть-то они есть. Но пользоваться этим пока неудобно, потому синий текст например затирает все -- потому что он красный + зеленый -- а красный и зеленый своих дополнительных плоскостей не затирают -- потому что так и получается синий -- и это можно доделать как-то более оптимально, чем вызов пучара дополнительного цвета с пробелами. Тогда уж можно разойтись и сделать установку комбинаций фон + передний план и поддержку расширенных ESC-команд VT-52.
Не самый скорострельный текст получается, чего и говорить.
- - - Добавлено - - -
Дема с вариантами милых сердцу (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/099593d2d2dbcab6b44b2034747e8d96/raw/16a71a54ad85ef07ab6545d45e17d244edd3fdb5/text512v+reverse+color.asm) любого бэкашечника и писишечника восьмидесятых палитр.
Их неудобно получать, но есть-то они есть
Пардон, протормозил. Для тормозов вроде меня нагляднее были бы 16 (или 12, если исключить одинаковые фоны+чернила) комбинаций цветов в качестве примера.
Вспомнился пример из библиотеки PPC, были там цветные комбинации цветов текста в HiRes.
Понятно, ну это потом, если. У меня пример-то пока на коленке бацаный.
Подход к цвету, без рекордов.
Я чуть чуть только дописал красоты и палитры вернул (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/099593d2d2dbcab6b44b2034747e8d96/raw/d6cd95876f68dfe65d4e51326fcc5af01e1f0b4f/text512v+reverse+color.asm).
Теперь и мне видно, что шрифт немного мутант - в основном CP1251, а псевдографика из ALT.
Я забыл, что называли ALT-ом, но по-моему как раз cp866. Если cp866, то это тоже не совсем оно -- в cp866 псевдографика совпадает с cp437 и начинается с B0. Это было удобно для нортон коммандеров, но неудобно для перебора буковок по порядку (если подумать, ути-пути какое неудобство - заставлять компьютер так вкалывать). А в 1251 никакой псевдографики в принципе нет, зато буковки снова стали по порядку. Кроме ё.
В общем если будут идеи как сделать лучше, перетасовать местами глифы в шрифте -- дело нехитрое. У меня все равно есть скрипт, который его на бок ложит из "исходника". Так-то вообще русские буквы из ассемблера работают и хорошо.
Судя по этой информации (http://segfault.kiev.ua/cyrillic-encodings/#gr-alt), область кодов псевдографики как в основной кодировке ГОСТа, а порядок - как в альтернативной
Improver
19.07.2022, 12:51
В общем если будут идеи как сделать лучшеИдея такая: в части букв и спецсимволов использовать KOI-8R, как я понимаю, эта кодировка наиболее близка Векторовским МДОСам и с просмотром текста на большом ПК проблем не будет.
- - - Добавлено - - -
В справке к VC (из комплекта РДС) есть ещё упоминание некой КОИ-8М, но информации по ней в инете не нашёл, возможно там с KOI-8R отличия как раз в псевдографике.
Я не думаю, что просмотр старых Векторовских текстов -- это насущная проблема для кода, который мы сейчас разрабатываем (я собственно вообще не знаю, какая проблема для него насущная). Собственно псевдографика тоже мне кажется немного странной темой на графическом экране, особенно при том, что линия рисуется молниеносно, а вот за буковку надо потерпеть. Для тех редких случаев, что без нее никак, можно воспользоваться таблицей и ввести нужные коды.
Improver
19.07.2022, 14:11
Я не думаю, что просмотр старых Векторовских текстов -- это насущная проблема для кода, который мы сейчас разрабатываемСогласен, не насущная. Но, с другой стороны, выбор хорошей кодовой страницы может дать в дальнейшем некую возможность практического применения этого кода, тогда это будет не просто "разработка ради разработки". :)
Собственно псевдографика тоже мне кажется немного странной темой на графическом экране, особенно при том, что линия рисуется молниеносно, а вот за буковку надо потерпеть.
Рамку (там где строго вертикальные и горизонтальные линии) можно нарисовать сравнительно быстро (хотя я бы не стал преувеличивать скорость рисования линий, особенно в HiRes), но в псевдографике еще есть блоки.
- - - Добавлено - - -
А что касается кодировок - были бы шрифты хорошие, а к ним можно добавить таблицы перекодировки во что нужно.
Слегка тангенциально, но в v06x с шейдером lottes crt на 4k (и даже 2k) мониторе текст в этом режиме смотрится нереально лампово.
- - - Добавлено - - -
Рамку (там где строго вертикальные и горизонтальные линии) можно нарисовать сравнительно быстро (хотя я бы не стал преувеличивать скорость рисования линий, особенно в HiRes), но в псевдографике еще есть блоки.
Насколько я знаю, на Atari ST было схожее ограничение - 4 цвета текста и при этом стандартный VT52 с небольшими дополнениями для установки цвета. С ходу не нашел, но может быть где-то есть клад из ATASCII цветной графики. Там правда понадобится шрифт с соответствующими специфичными для Атари закорючками.
Еще разумеется можно пользоваться блоками разной плотности заливки как паттернами и изображать ими полутона.
А что касается кодировок - были бы шрифты хорошие, а к ним можно добавить таблицы перекодировки во что нужно.
Этот шрифт отличается от Векторовского канона, но он по-моему симпатичный.
Без цвета, вот такой шрифт (6x10) и вот такая кодировка у PPC в BoldBIOS. nblitы не переделал на 10 строк, только blitы.
- - - Добавлено - - -
И для коллекции шрифт из F51. Исходно он столбцовый 5x8. В оригинале выводился в знакоместо 6x10, поэтому я сбоку добавляю пустой байт, а по вертикали слипается, нужно шаг 9 или 10 сделать.
Upd: убрал первый вариант, т.к. выложил доработанный
Буквы кои-8, а псевдографика тот же фарш, что в "моем".
Поправил вчерашний F51 и добавил ямахово-кувтовый шрифт (тоже вариация КОИ-8). В ямаховском буквы совместимы со знакоместом шириной 6 точек, а псевдографика не полностью. "Классические" шрифты пока не воодушевили, в рыбе текущий шрифт лучше.
Про фонт PPC - скорее всего там первые 32 буквы не определены, можно отрезать начальные 320 байт.
Мне нравятся все эти кракозябры в первых 32 символах. Когда они есть, конечно.
Я слегка сбит с толку всем разнообразием замечательных вариантов, которое у нас получилось. Надо как-то подводить итоги, пока все не сгинуло в пучине форума. Мы уже на 9 странице.
Цветной по-моему годный в последней рыбе. К нему основное требование не скорость, а удобство и разноцветность. И там хорошо с этим вышло. А за чб я бы наверное предпочел взять последний вариант перед цветным, только с добавленной инверсией.
Может быть фонты рыбов, PPC и Ямахи можно привести к общему варианту и сделать рыбу со всеми тремя, если в них есть какие-то объективные достоинства? Я лично сомневаюсь, что там какое-то ценное разнообразие, но в делах щемящей душу ламповости как я могу указывать кому что любить.
Improver
20.07.2022, 18:13
Буквы кои-8, а псевдографика тот же фарш, что в "моем".Не совсем фарш. Интересная фраза есть в документе к BoldBIOS, в MDOSBU.DOC:
Система поддерживает кодировку Вектор ( смесь альтернативной
и КОИ-8 ) ...
Проверил, и действительно на Векторе, в РДС, коды псевдографики от 128 до 175 совпадают с альтернативной кодировкой ([код Альт.] - 48), и диапазон 176...190 = [Альт.] - 64. Просто для информации...
Мне нравится цветной вариант с красотой (https://zx-pk.ru/threads/34508-80-simvolov-v-stroke-i-rezhim-512-tochek-voobshche.html?p=1158712&viewfull=1#post1158712). Дальнейшие вялые поиски в основном показали, что имеющийся шрифт лучше не менять.
Из нецветных мне ближе этот вариант (https://zx-pk.ru/threads/34508-80-simvolov-v-stroke-i-rezhim-512-tochek-voobshche.html?p=1158231&viewfull=1#post1158231). Возможно стоит все же сделать с вариант с более компактным (в 2 раза) шрифтом (упаковать полубайты в один байт) и добавить инверсию. Процедуры укрупнятся (но не на 2 Кб) и замедлятся (не в 2 раза), зато общий размер уменьшится.
Мне нравится цветной вариант с красотой. Дальнейшие вялые поиски в основном показали, что имеющийся шрифт лучше не менять.
Из нецветных мне ближе этот вариант. Возможно стоит все же сделать с вариант с более компактным (в 2 раза) шрифтом (упаковать полубайты в один байт) и добавить инверсию. Процедуры укрупнятся (но не на 2 Кб) и замедлятся (не в 2 раза), зато общий размер уменьшится.
Согласен по всем пунктам. Если ты будешь это делать, может быть возьми за основу вариант с красотой.
Не совсем фарш.
( смесь альтернативной и КОИ-8 ) ..
- Баба мылом морду моет.
- У бабы не морда. У бабы лицо.
- Нет, все-таки немножечко морда.
Если плюнуть на скорость для двухцветного варианта, то его можно сделать частным случаем четырехцветного:
1. Меняем раскладку плоскостей для цвета, вместо 1+3 и 2+4 делаем 1+4 и 2+3
2. Добавляем ограничение доступа к плоскостям, как screen2 в бейсике
А какого масштаба получается плевок? Если можно сделать легко настраиваемый универсальный вариант, то я за.
Если грубо прикинуть, то будет быстрее цветного почти в 2 раза (kapec 3 раза вместо 6).
Про фонт PPC - скорее всего там первые 32 буквы не определены, можно отрезать начальные 320 байт.
Абсолютно верное предположение. Первые 32 символа были отброшены чтобы сэкономить память.
Мы не смогли найти ни одной CP/M программы, которая бы их выводила. Это не означает что таковых нет в природе, но, скажем SID заменяет эти символы на точки, WordMaster при вводе <Ctrk>+{<A>...<X>} - на "^A..^X".
Hа всякий случай. По ссылке ниже, в архиве, в подкаталоге \tools лежит дисковый редактор шрифтов для создания/редактирования битмапов в формате Bold BIOS
http://http://sensi.org/scalar/ware/835/
Должен работать на всех МикроДОСах. Писан на C, если надо, я могу выложить сырки для его дальнейшего творческого развития.
Мы долго в своё время думали по поводу смены кодовой страницы псевдографики, но оставили кодировку как была в оригинальном МикроДОСе. Думаю, это наиболее верно, даже сейчас не стоит менять. Кстати, в оригинальном МикроДОС один или 2 из уголков одиночной линией были не прорисованы.
К псевдографике я бы вообще относился с бо'льшим пиететом: консоль расцветает новыми красками в "псевдо"-оконных приложениях. Интерактивные меню, листбоксы, прокрутки - всё это не просто возможно а уже было сделано несколько раз разными авторами. Псевдографику желательно оставить и кодировку не менять, так думается.
Если уж так хочется менять кодировку, то всегда можно замутить промежуточный устанавливаемый консольный драйвер с LUTом на перехват I/O и для BIOS и для BDOS
Мы не смогли найти ни одной CP/M программы, которая бы их выводила.
Я думаю, что это потому что эмуляция терминала (или настоящий терминал) воспринимает их исключительно как управляющие. Но в шрифте-то мы можем что хотим рисовать и совсем необязательно эмулировать терминал. "Бывают же и просто буквы".
Это безусловно так и есть, они изначально воспринимаются драйвером консоли как управляющие.
Подозреваю что вообще не выйдет их вывести документированными средствами CP/M как символы.
Даже недокументированный вход в MDS800 оставшийся от ISIS уже обрабатывал часть из них как управляющие. Я про вот это (изначально это вообще ROM код был)
; mds monitor equates
co equ 0f809h ;console char from c to console out
; EQUATES FOR NON GRAPHIC CHARACTERS
CTLC EQU 03H ;CONTROL Cе
CTLS EQU 13H ;STOP/START SCREEN
CTLU EQU 15H ;LINE DELETE
CTLE EQU 05H ;PHYSICAL EOL
CTLP EQU 10H ;PRNT TOGGLE
CTLR EQU 12H ;REPEAT LINE
CTLX EQU 18H ;=CTL-U
CTLZ EQU 1AH ;END OF FILE
RUBOUT EQU 7FH ;CHAR DELETE
TAB EQU 09H ;TAB CHAR
CR EQU 0DH ;CARRIAGE RETURN
LF EQU 0AH ;LINE FEED
CTL EQU 5EH ;UP ARROW
А BIOS и плясал от MDS, дальше-больше.
Можно наверное через GSX, но там драйверы графические нужны под Вектор, тогда будет стандартно. Но это заморочно. Тогда уж наверное проще сделать какой-то BDOS extension вход для 50й функции, там вроде 3 входа зарезервированы для юзера.
Конечно, эти 32 символа могут пригодиться для какой-то не CP/M программы на голом Векторе без ОС.
Но смысл такую делать если уже есть ОС, которая обеспечивает вывод 80 символов в строке?
Ну досов для голого вектора вроде и нет, а загружать например монитор-отладчик для программки в несколько килобайт неудобно.
Ну да, можно сделать библиотеку для 80-колоночного вывода текста на экран. Правда сразу захочется иметь перевод строки как минимум. В общем и это решаемо, можно просто функции вызывать по концу строки.
Я всё пытаюсь вспомнить, мог ли монитор-отладчик показывать хоть какие-то символы из диапазона 0-0x1F
Это к тому, что возможно стандартные МикроДОСы и могли часть символов показать через 0F09h MDS вызов. Иначе, для чего там были битмапы всех 256 символов которые мы резанули...
Но смысл такую делать если уже есть ОС, которая обеспечивает вывод 80 символов в строке?
Это на тот случай, если хочется сделать ромчик, который загружается без доса и печатает 80 символов в строке, или совмещает текст с графикой 512x256.
Это на тот случай, если хочется сделать ромчик, который загружается без доса и печатает 80 символов в строке, или совмещает текст с графикой 512x256.
Ну да, можно и ромчик, но туды придётся фонт запихивать.
А можно и наоборот. Вот, разрыл (в аттаче, запускать под МикроДОСом).
Исходник говорит мне что это был сентябрь 1990. Рекомпильнул.
Disclaimer: не реклама, просто это из всех телеков в Питере в 90м показывало...
Разговоры о текстовом Бейсике заставили вспомнить, что я забыл орыбить цветной 80-символьный текст. Исправляюсь - https://svofski.github.io/pretty-8080-assembler/?text80-color
И заодно подумал, что 64 цветных символа -- пусть не такой серьезный челлендж, как 80, но нужный и полезный режим и хорошо бы его сделать.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot