Специалист: графика [Архив] - Speccy

CityAceE

24.01.2019, 03:30

HardWareMan

24.01.2019, 07:08

Я хотел продолжить эксперименты с графикой на Специалисте, и тут до меня дошло, что мы можем только записывать цвета в порт, но узнать какого цвета конкретная точка на экране не можем. Получается, что если, например, делать графический редактор, то придётся где-то в пользовательском ОЗУ отдельно хранить дубликат цветов всех точек (байтов), чтобы можно было работать с цветами и иметь возможность сохранить результаты своих трудов.
Зато работает быстро. С другой стороны, предлагалась доработка автоматического чтения цвета в регистр цвета из плоскости атрибутов если происходит чтение из экранной области. Это дает возможность копировать экранные объекты в оригинальном цвете а так же доступ к цвету нужной точки.

Также встал вопрос с синхронизацией. Где-то на страницах форума находил упоминание, что у Специалиста нет возможность синхронизировать вывод изображения с ходом луча. Неужели это правда? Как же тогда правильно мигать цветами для получения эффекта большего количества цветов и использовать подобные трюки?
Жили без этой идеи и дальше проживем. Это не спектрум, тут экран 12КБ. Мигать подменой экрана слишком накладно. А вот в Орионе это можно сделать переключением экрана.

И как-то на Специалисте вообще уныло с графикой. За всё время существования платформы никто так и не сделал (наконвертировал) красивых картинок, не сделал просмотрщик графики. Да что там! Я даже ничего отдалённо похожего на стандарт хранения цветной графики не нашёл.
Графредакторы были какие-то, надо смотреть кассеты кружка (которые я так и не досчитал еще), но в целом ты прав: и загрузку спектрумских картинок, и графические примочки, вроде "линзы" и прочее мы писали всё сами. Надеюсь оно сохранилось всё на тех же кружковых кассетах.

Titus

24.01.2019, 07:27

Как же тогда правильно мигать цветами для получения эффекта большего количества цветов и использовать подобные трюки?
И хорошо, что нет такой возможности)
Подобные эффекты и на Спектруме были очень условны в своей эргономичности, и то, скорее стараниями фильтров эмуляторов.

ivagor

24.01.2019, 07:32

Имхо самое большое ограничение - отсутствие возможности синхронизации с лучом, что делает невозможными качественные скроллеры.

CityAceE

24.01.2019, 09:32

С другой стороны, предлагалась доработка автоматического чтения цвета в регистр цвета из плоскости атрибутов если происходит чтение из экранной области.
Сам-то цвет на Специалисте сложно назвать стандартом, хотя он и был официально описан в Моделисте-Конструкторе ещё в те годы, но особого распространения, к сожалению, так и не получил. Цветные игры можно пересчитать по пальцам. А уж чтение из порта и вовсе не стандарт. Поэтому будем считать, что такой вариант нам недоступен. В итоге придётся держать в памяти ещё 12 кБ данных о цвете, что при доступных пользователю 36 Кб является весьма существенным объёмом. Но в ущерб скорости обработки можно хранить в одном байте информацию о цветах для 32 точек (4 байта) и таким образом сократить объём до 3 дополнительных килобайт.

Мигать подменой экрана слишком накладно.
Да, но иногда можно помигать только частью экрана (спрайтом).

Надеюсь оно сохранилось всё на тех же кружковых кассетах.
Будем надеяться, что оно уцелело и в скором времени будет считано.

И хорошо, что нет такой возможности)
И всё-таки лучше когда оно есть, а уж пользоваться данной возможностью или нет - это дело программиста.

Имхо самое большое ограничение - отсутствие возможности синхронизации с лучом, что делает невозможными качественные скроллеры.
Вот про это я и говорю. Синхронизацию с лучом можно ведь не только для мигания цветами задействовать, но и много для чего ещё гораздо более полезного!

Всем заинтересованным лица предлагаю для начал разработать формат хранения картинок стандартного цветного Специалиста. Имея некий стандарт можно будет озадачится созданием разного рода прекодировщиков и конветрторов готовой графики для Специалиста. Чтобы можно было удобно просматривать картинки и на РС, и в случае необходимости перекидывать их на Специалист, чтобы там можно было просмотреть нативным просмотрщиком.

В условиях отсутствия какой-либо готовой графики для цветного Специалиста сложно оценить в полной мере его графические возможности. Для меня стало откровением, как хорошо смотрится графика из Exolon'а на Специалисте. А ведь графика может быть ещё лучше, учитывая то, что в одном знакоместе Специалиста может находиться до 8 цветов одновременно! Наверняка можно использовать какие-то художественные трюки, чтобы свести к минимуму ограничение только на чёрный цвет бумаги.

Итак, предложение формату картинок Специалиста. Вернее даже пока не предложения, а вопросы для обсуждения:

1. Где хранить информацию от цвете: отдельно для каждого байта непосредственно следом за самим байтом, которому принадлежит этот цвет, либо же, как в Спектруме, хранить информацию о всех цветах единым блоком сразу после копии видео ОЗУ?
2. Как хранить информацию о цвете: 1 байт - информация о 8 горизонтальных пикселях, либо 1 байт - информация о 4 строках по 8 пикселей?
3. Нужен ли хедер для картинок для идентификации и прочих (каких?) целей? Либо можно отказаться от хедера и по стандартной длине файла определять, что это картинка для Специалиста?
4. Нужно ли в файле хранить информацию о целостности картинки - контрольную сумму?
5. Может быть нужно что-то ещё?

ivagor

24.01.2019, 10:59

Если чисто из принципа, то на специалисте можно синхронизироваться с лучом "полуавтоматически". Делаем цикл с периодом равным кадру и возможностью его чуть сократить или удлинить. Рисуем в этом цикле некую опорную фигуру и предлагаем пользователю подвинуть ее клавишами (которые позволяют сокращать/удлинять цикл) в нужную позицию. Когда пользователь настроил, то дальше мы знаем, где луч и можем делать что нужно. Но это жутко неудобно и непрактично.
Насчет хранения графики для специалиста. Если главное - скорость, то удобно хранить черезстолбцово цвета и саму графику. Если для MX, то столбец цвета - столбец графики, для 8 цветов: столбец цвета - 2 столбца графики, для 4 цветов: столбец цвета - 4 столбца графики. Если хранить не весь экран, а фрагменты, то можно аналогично, только построчно-побайтно, т.е. например для 8 цветов: байт цвета - 2 расположенных рядом байта графики.

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

Рисуем в этом цикле некую опорную фигуру и предлагаем пользователю подвинуть ее
Поправочка, раз палитры и цвета бордюра нет, то не подвинуть, а увидеть/не увидеть. Т.е. рисуем что-то в определенном месте и сразу стираем. Например можно заполнить столбец 128ю парами 00h FFh.

Serg6845

24.01.2019, 13:36

Мигать подменой экрана слишком накладно. А вот в Орионе это можно сделать переключением экрана.

В Специалисте переключение экранов можно сделать добавлением одного корпуса ТМ2 (ну и одного адреса чтобы в него писать). Другое дело - поддержка...

ivagor

24.01.2019, 18:19

zx_

24.01.2019, 19:47

ivagor, добавило бы интриги в мир игр специалиста
сам процесс - загрузил, засинхронизировал и давай рубиться
:v2_dizzy_step:

svofski

24.01.2019, 19:59

ivagor, добавило бы интриги в мир игр специалиста
сам процесс - загрузил, засинхронизировал и давай рубиться
Во времена механических телевизоров модели покруче для богатых имели пульт дистанционного управления -- выносная крутилочка для ручной подстройки синхронизации.

ivagor

24.01.2019, 20:08

Ну я сразу написал, что формально привязаться к развертке можно, но потом использовать крайне трудно и неудобно. Нужно сохранять равенство тактов в цикле одному фрейму, чтобы ничего лишнее не выплыло в активную область. Скорее всего какой-то короткий эффект можно реализовать, но игру - вряд ли, нужен огромный энтузиазм и, вероятно, специализированный инструментарий для упрощения проверки времени цикла. Вот на MX проще, там есть таймер синхронизированный с процессором, пример векторовского эксолона (и эмулятора zx опять же на векторе) показывает, что таймер в таких делах вполне применим.

zx_

25.01.2019, 12:03

дык таймер для Специалиста существует в нескольких вариантах даже
т.е не является препятствием при написании какихто прог его кабы отсутствие
монитор SP -580 включал доработку с таймером, и являлся почти дефолтной игровой доработкой( знач игры под SP 580 и сейчас можно )
Лик вообще вместе с ним выпускался

если ув ivagor, издаст Exolon под SP-580 это не будет нарушением хода истории
:v2_dizzy_priest:

ivagor

25.01.2019, 12:23

С большим интересом посмотрю, если кто-то адаптирует эксолон на специалист (или другой компьютер с 8080), но сам не возьмусь, это слишком объемная и долгая задача.

tnt23

25.01.2019, 12:42

С большим интересом посмотрю, если кто-то адаптирует эксолон на специалист (или другой компьютер с 8080), но сам не возьмусь, это слишком объемная и долгая задача.

А я уже сдул пыль веков с "Океана-240" и приготовился вкушать доселе невиданное :(

ivagor

25.01.2019, 15:19

Думаю, что когда-нибудь эксолона портируют на специалист, но вот когда и кто это сделает - вопрос.

svofski

25.01.2019, 15:24

Главное не забыть сделать в нем непроходимую заставку.

DDp

26.01.2019, 22:20

И как-то на Специалисте вообще уныло с графикой
Долой уныние! :v2_laugh:
67843

fifan

27.01.2019, 08:38

Вот через эмулятор скриншоты захватил.

https://i.ibb.co/s3p012d/color-scr.png (https://ibb.co/12YDXLt)

CityAceE

27.01.2019, 09:11

Долой уныние!
А какие-нибудь подробности будут? Оно на ходу конвертируется из какого-то формата или просто разжимается из заранее подготовленного файла?

Самое любопытное, что это всё 4-х цветные картинки!

ivagor

27.01.2019, 10:30

Такие картинки можно сразу на экран выводить, потом раскрашивать, т.е. обойтись без буфера. Тогда можно, например, сразу больше картинок загрузить.

ivagor

27.01.2019, 19:31

Или вот такой вариант под 8 цветов. К сожалению на компе, за которым я сейчас, нет матлаба, а без него как без рук. Пришлось использовать для транзита BMP2SCR с разрешением 256x192. В 384x256 получилось бы лучше.

DDp

28.01.2019, 00:01

... или просто разжимается из заранее подготовленного файла?
Да. Просто дамп экрана, цвета константные, забиты в выводилке.

Такие картинки можно сразу на экран выводить, потом раскрашивать, т.е. обойтись без буфера.
Можно и так. Хотел обойтись без лишних мельканий экрана. И сверху вниз, а не дампом слева направо.
А, вот, ещё живая загрузка (во вложении).

ivagor

28.01.2019, 18:29

Если нужно выводить в один прием и сверху-вниз, то можно использовать буфер на несколько строк, для примера в parrot3lines.zip - буфер на 3 строки.
Живая загрузка - это хорошо, на CPC есть демка - Breaking Baud (https://www.youtube.com/watch?v=TFEYf0290Jg). Может и на спеке такое есть, я не в курсе.

Попробовал несколько вариантов конверсии в 8 цветов. Полностью не один не устраивает, разве что аляповато-грубый parrot8c_384 понравился насыщенностью. Для сравнения рядом картинка DDp (она растянута по горизонтали чуть сильнее, чем моя).
6786567866

CityAceE

29.01.2019, 13:40

Я в код не лазил, и так и не понял в каком формате хранятся эти картинки. Почему они занимают даже меньше экранного ОЗУ, потому что предварительно чем-то запакованы?

Что касается самих картинок. В 8 цветов картинка безусловно ярче и контрастнее, но вместе с тем в глаза бросаются грубые рваные края в местах перехода цветов.

Мне кажется, что получить идеальную картинку, при ограничении на только чёрный цвет бумаги, будет очень проблематично. Но подумать над алгоритмом всё-таки стоит. В своём конверторе спектрумовской графики я зажигаю пиксели и крашу их в тот цвет (чернила или бумаги), пикселей цвета которого больше в обрабатываемом байте (Optimization On). Думаю, что это самое очевидное, что приходит в голову, но на всякий случай поинтересуюсь, использовал ли ты подобный метод при конвертировании цветных картинок? А может быть стоит как-то через строчку красить пиксели? Например, если в верхнем байте чередуются чёрные и красные пиксели, а в нижнем байте желтые и чёрные, то на итоговой картинке создаётся иллюзия, что чередуются красные и жёлтые пиксели.

ivagor

29.01.2019, 14:18

Картинки и у DDp и у меня упакованы MegaLZ.

зажигаю пиксели и крашу их в тот цвет (чернила или бумаги), пикселей цвета которого больше в обрабатываемом байте
parrot8c_384 получен с аналогичным преобразованием на финальной стадии. Но важно и что было до этого, какой дизеринг, какая фильтрация (если была). Еще я с гаммой и другими параметрами экспериментировал. У DDp дизеринг скорее всего какой-то вариант error diffusion.

ivagor

29.01.2019, 17:58

Слегка подкрутил параметры преобразования и стало получше. Слева - "новый" вариант, справа - "старый".
6787467875
По поводу определения значений "переднего плана" и атрибутов. Возможен подход с преобразованием в YUV (или в похожую систему), фильтрацией цветоразностных для уменьшения их пространственного разрешения и значения переднего плана получаем из Y, а атрибутов из YUV.

ivagor

30.01.2019, 17:55

Попробовал сконвертировать лису в режим DDp. Получилось не идеально, но близко. Справа - настоящий DDp, слева - фэйковый. И еще DDp сильнее растягивает по горизонтали.
6788767888

ivagor

31.01.2019, 17:58

Немного капитанства. Для конверсии на MX можно использовать BMP2SCR, режимы MLT/Hicolor modes. Да, разрешение и цветовые возможности MX не будут раскрыты на 100%. Зато есть редактор для творческих личностей.

medvdv

29.03.2019, 18:19

Слушайте а ведь просто же приколхозить прерывание по кадровому импульсу? Было бы по человечески. Отключалось бы через (а там есть своб бит в 55?) 55 скажем

Или чуть менее человечно - бит статуса в 55 который на обратном рейтресе 1

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

Мне вообще непонятна эта страсть отечественных дизайнов эмэйчур компов не иметь кадрового прерывания

Как заговор какой прямо, чтобы игр хороших не писали ;-)

Впрочем и 2мгц 8080 при 16 кб буфера кадра это не про скроллеры и тд

Эх почему не было в СССР советского VDP типа TMS99 или хотя бы текстового контроллера типа мотороллы 6845 или как там ее звали

zx_

29.03.2019, 21:12

medvdv, хороших игр не писали не потому что процессор 8080 и нет прерываний-)
а просто потому что не писали, и содрать не у кого было

balu_dark

30.03.2019, 17:22

Потому что в то время - компьютеры были РАДИОЛЮБИТЕЛЬСКИМИ и собирали их в основном люди с несколько другими увлечениями и наклонностями. Программы были в основном заточенные под радиолюбительство же - контроль и каталог радиосвязей, расчет цепей и схем, разводка плат и остального. Хотя некоторые вещи вполне рождались и в таких условиях и на Специалист и на Орион. Просто когда пришло время коммерциализации - время ориона и прочих просто прошло... Спектрум продержался какое то время именно благодаря тысячам довольно хороших программ, как прикладных так и системных. Да и штамповать клоны стали все кому не лень, опять же потому что популярность рождалась в том числе количеством программ.
А потом пришли Деньди с Сегой. И компы стали не интересны для нового поколения.

fifan

30.03.2019, 18:06

Господа, вы несколько ушли от темы.

AlexBel

04.05.2020, 10:03

Нужно несколько бинарников с содержимым памяти экрана "Специалиста". Посмотрел эмуляторы emu и emu80 и не нашёл, как сохранять области памяти в файл. Если кто-нибудь поделится картинками (чем больше - тем лучше) стандартного чёрно-белого "Специалиста", буду очень благодарен.

SYR-ALEX

04.05.2020, 10:34

Да в общем то не проблема . В EMU запускаете программу с интересующей картинкой , вызываете отладчик . В отладчике Ctrl+S в появившемся окне указываете адреса начала и конца блока памяти ( для экрана 9000 - BFFF) ,нажимаете ENTER . Присваиваете имя файлу XXXXXXX.BIN .
72484

CityAceE

01.10.2023, 20:50

Чтобы проверить геометрию изображения (https://zx-pk.ru/threads/35304-voprosy-po-arkhitekture-quot-spetsialista-quot.html?p=1186346&viewfull=1#post1186346) по-быстрому набросал скрипт, который берёт однобитный ч/б BMP с разрешением 384*256 и делает из него RKS-файл, который загружается сразу в видео-память Специалиста и стопорится. Проверено на работоспособность на живом Специалисте и в Emu80. Внимание! Никаких проверок на валидность входного файла не производится!

Использование довольно простое, но через командную строку:

python bmp2spec.py FILENAME.BMP

На выходе получим FILENAME.rks

https://pic.maxiol.com/thumbs2/1696182525.780858384.emu80.png (https://pic.maxiol.com/?v=1696182525.780858384.emu80.png&dp=2)

CityAceE

03.10.2023, 17:18

Есть ли какой-то известный алгоритм которых более-менее хорошо жмёт стандартный ч/б экран Специалиста размером 12 Кб? Чтобы можно было на PC запаковать, а на Специалисте потом быстро распаковать.

И ещё может кто-то уже экспериментировал. Как выгоднее сжимать: по столбцам или по строкам? Понимаю, что всё сильно от картинки зависит, но тем не менее может какая-то статистика есть на этот счёт?

Titus

03.10.2023, 17:38

И ещё может кто-то уже экспериментировал. Как выгоднее сжимать: по столбцам или по строкам? Понимаю, что всё сильно от картинки зависит, но тем не менее может какая-то статистика есть на этот счёт?
Только по столбцам. Гораздо эффективнее на 99% картинок.

lexarr

03.10.2023, 20:21

Думаю, эффективнее тем же ZXx упаковывать, он универсален. Хотя такие фотографические изображения с дизерингом, как на скриншотах, жмутся с трудом. Сжатие обсуждается здесь (https://zx-pk.ru/threads/29679-szhatie-dannykh.html) и здесь (https://zx-pk.ru/threads/23155-szhatie-i-upakovka-obsuzhdenie-i-sravneniya.html)

CityAceE

14.12.2023, 16:22

С помощью программы DaDither (https://zx-pk.ru/threads/32400-dadither-eshche-odna-programka-dlya-dither-ga-kartinok) получил вот такой результат для Специалиста:

https://pic.maxiol.com/images2/1702560976.780858384.cupheadorig.png https://pic.maxiol.com/images2/1702559422.780858384.cuphead.png

Однако программа не позволяет сохранять цветные изображения, так как до сих пор не существует никакого формата для хранения цветных изображений.

Первое же, что приходит в голову - это хранить информацию о цветах отдельно от пикселей. Собственно, так оно и хранится на Специалисте. Но хранить эту информацию можно разными способами. И опять же, первые два способа, которые приходят в голову:
1. Хранить цвет байта, непосредственно перед самим байтом для удобства вывода на экран, поскольку блок из 8 горизонтальных пикселей кодируется двумя байтами.
2. Хранить цвета всех байтов скопом непосредственно после самих байтов, то есть сразу после содержимого видеоОЗУ.

Оба способа имеют как плюсы, так и минусы. Но в результате экспериментов я пришёл к выводу, что универсальнее хранить цвета всё-таки по второму способу. То есть получается примерно как на Спектруме. В итоге я преобразовал полученную картинку этим методом и сделал крохотный (и медленный!) загрузчик её в Специалист:

https://pic.maxiol.com/images2/1702559867.780858384.20231214160450.png https://pic.maxiol.com/images2/1702560578.780858384.20231214162832.png https://pic.maxiol.com/images2/1702560602.780858384.20231214162912.png

По меркам Специалиста файл получается просто огромным - 24 кб. Безусловно, требуется его сжатие. Но соглашение о типе сжатия оставим на следующую итерацию. А пока прилагаю и сам файл, и RKS для загрузки в эмулятор. После загрузки в эмулятор, запустите программу по директиве G и получите на экране картинку.

Dec

14.12.2023, 17:44

Я бы еще предложил хранить в файле и тип палитры, для которой создавалось изображение. Или в начале файла, или между блоком пикселей и блоком атрибутов, или в конце файла.

CityAceE

14.12.2023, 18:36

Я бы еще предложил хранить в файле и тип палитры
Весьма резонное дополнение, которое я почему-то упустил из внимания. Действительно, ведь помимо того, что цвета для 8-ми и 5-ти цветных вариантов отличаются, так ещё же есть и Специалист МХ, где можно задавать цвет фона.
Соответственно, тип можно хранить в виде количества цветов, вернее по номеру последнего цвета, если считать от нуля: 4, 7, 15. В этом случае вторая половина байта будет свободна под будущие нужды.

А вот где его хранить, вопрос интересный. Тип палитры для отображения нам нужно знать заранее, то есть удобнее хранить его вообще первым байтом. Но очень хочется иметь совместимость и с ч/б вариантом, с размером картинки 12 кб, чтобы просто откинуть информацию о цвете и иметь монохромную картинку. И если в варианте без компрессии всё равно где хранить информацию о палитре, то если всё-таки договориться о том, что по умолчанию можно использовать некоторый вид компрессии, то для просмотра таких картинок на реальном компьютере лучше иметь эту информация в несжатом виде, то есть в самом начале. Но опять же, если использовать сжатие, то лучше иметь разные его варианты, а это потребуется ещё одного байта с информацией о типе компрессии. И если принадлежность к картинке Специалиста у несжатого файла можно будет определять по его длине, то для сжатого файла потребуется какой-то заголовок. Можно, например отдельно сжимать пиксели, а отдельно цвет и потом их параллельно распаковывать при выводе на экран. И, соответственно в заголовке файла хранить области начала данных для пикселей и их цветов. Но, вероятно, всё-таки вариант со сжатием следует оставить для следующих итераций разработки формата. А для начала нужно подумать о несжатом формате.

В общем, как я предположил выше для совместимости с ч/б информацию о палитре лучше хранить после слепка видеоОЗУ: либо сразу после массива пикселей, либо в самом конце после информации о цвете. И мне кажется, что более логично всё-таки хранить эту информацию до массива данных о цвете, хотя это и лишает нас манёвра для расширения. Можно под возможное расширение и для выравнивание под 16 бит, зарезервировать ещё один байт. То есть вот так:

0x0000-0x2FFF: Данные о пикселях
0x3000: Тип палитры - 0x04, 0x07, 0x0F
0x3001: Резерв - 0x00
0x3002-0x6001: Данные о цветах

Dec

14.12.2023, 21:42

0x0000-0x2FFF: Данные о пикселях
0x3000: Тип палитры - 0x04, 0x07, 0x0F
0x3001: Резерв - 0x00
0x3002-0x6001: Данные о цветах

Добавил сохранение в этот формат в DaDither. Но не для MX, поскольку метод кодирования его атрибутов мне не был объяснен. И не забывайте, что sps-файлы можно смотреть в TotalCommander (https://zx-pk.ru/threads/31106-predprosmotr-snapshotov-v-total-commander-i-windows-explorer.html).

CityAceE

14.12.2023, 23:07

Добавил сохранение в этот формат в DaDither.
Ох, как оперативно! А я как раз продолжил думать и экспериментировать и пришёл к заключению, что всё-таки информацию о типе палитры удобнее размещать последним байтом. То есть вот так:

0x0000-0x2FFF: Данные о пикселях
0x3000-0x5FFF: Данные о цветах
0x3001: Тип палитры - 0x04, 0x07, 0x0F

Просто в этом случае на реальном компьютере будет быстрее и удобнее переключаться с данных о пикселях на данные о цвете. Если выровнять расположение до 0x100, и расположить адрес в HL, то для переключения будет достаточно прибавлять и отнимать от регистра H 0x30.

Так что предлагаю всё-таки остановиться именно на этом варианте. И можно будет просить эмуляторописателей поддержать данный формат.

Но не для MX, поскольку метод кодирования его атрибутов мне не был объяснен.
Там тоже всё предельно просто. В одном байте хранится информация о цвете пикселя и цвете фона. Примерно как на Спектруме. Но там яркость не привязана к цвету пикселя и фона - яркость может быть разной. Ну и ещё тёмный чёрный и яркий чёрный отличаются на экране. В верхней половине байта хранится цвет пикселей, а в младшей - цвет фона. А вот так кодируются цвета:
http://xn----7sbombne2agmgm0c.xn--p1ai/images/colortable2.png

И не забывайте, что sps-файлы можно смотреть в TotalCommander.
Отлично! Спасибо, я не знал про этот плагин. Он для меня будет очень полезен! Как раз думал, что нужно будет что-то подобное сделать.

Dec

14.12.2023, 23:31

0x0000-0x2FFF: Данные о пикселях
0x3000-0x5FFF: Данные о цветах
0x6001: Тип палитры - 0x04, 0x07, 0x0FОбновил программу. В теме программы DaDither предлагаются оптимизации для DDp-like изображений.

ivagor

15.12.2023, 07:14

вот так кодируются цвета
Особенно "коричневый"

CityAceE

15.12.2023, 08:59

Обновил программу.
Отлично! Спасибо за оперативность!

В теме программы DaDither предлагаются оптимизации для DDp-like изображен1ий.

Да, предложение по оптимизации дельное! Тогда предлагаю придерживаться следующего соглашения для подобного типа изображений:

Расширение: *.sps
Определение типа: по размеру файла 12291 (0x3003) байт.
Структура файла:

0x0000-0x2FFF: Информация о пикселях (слепок видеоОЗУ)
0x3000: цвет для первой строки триад, начиная с самой верхней на экране.
0x3001: цвет для второй строки триад, начиная со второй сверху на экране.
0x3002: цвет для третьей строки триад, начиная с третьей сверху на экране.

А что делать с последней строкой, которая является остатком от деления на 3? Понятно, что нужно оставлять её пустой или закрашивать в чёрный цвет. Стоит ли это как-то отдельно упоминать или просто оставить на откуп пользователя?

Особенно "коричневый"
Да, согласен, что название цветов несколько искажено и мне они тоже глаз режут. Но информацию я предоставил напрямую с сайта fifan'а. А откуда он взял именно такие названия мне неизвестно, явно ведь не сам придумал.

Dec

15.12.2023, 10:00

предлагаю придерживаться следующего соглашения для подобного типа изображений
Без байта типа палитры?

CityAceE

15.12.2023, 10:14

Без байта типа палитры?
Хм... Резонный вопрос. Что-то я снова упустил этот момент. А он-то ведь тоже нужен и здесь тоже! Тогда по аналогии с предыдущим форматом предлагаю поместить его в самый конец:

Расширение: *.sps
Определение типа: по размеру файла 12292 (0x3004) байт.
Структура файла:

0x0000-0x2FFF: Информация о пикселях (слепок видеоОЗУ)
0x3000: цвет для первой строки триад, начиная с самой верхней на экране.
0x3001: цвет для второй строки триад, начиная со второй сверху на экране.
0x3002: цвет для третьей строки триад, начиная с третьей сверху на экране.
0x3003: тип палитры - 0x04, 0x07 или 0x0F

ivagor

15.12.2023, 10:36

Что касается коричневого, то дело не в названии.
1. Если посмотреть схему видеовыхода MX, то при подключении к нормальному среднестатистическому ТВ коричневый там не получится (а получится желтый или темно-желтый).
Единственное предположение, откуда он пошел исторически - у автора MXа был соответствующий монитор CGA. Можно за него порадоваться и перейти ко второму пункту.
2. ПО, в котором точно нужен и используется коричневый - оно существует? Желтый (или темно-желтый) используется по крайней мере в портах игрушек с компов, где он был (в отличие от коричневого).
3. Современные эмуляторы Emu и Emu80 не пришли к единой палитре для MX и заметно отличаются по светлым оттенкам цветов, но коричневого нет ни в одном ни в другом.

Dec

15.12.2023, 15:18

Обновил DaDither и плагин. Теперь всё сохраняется по спецификациям. Нужно тестировать, особенно режим 16 цветов. Поскольку определенности с палитрой нет, то использовал ту палитру, что была ранее. Если будут уточнения по цветам - пишите, буду править.

CityAceE

15.12.2023, 15:39

Нужно тестировать, особенно режим 16 цветов.
Вроде похоже на правду. Но это под эмуляторами, а реального компа у меня нет.

https://pic.maxiol.com/images2/1702643854.3280329127.emu80.png https://pic.maxiol.com/images2/1702643880.3280329127.emu.png
В Emu80 выглядит понасыщеннее.

Файл для запуска на эмуляторах прилагаю.

CityAceE

15.12.2023, 16:22

С линейным форматом тоже похоже на правду:

https://pic.maxiol.com/images2/1702646468.3280329127.lines.png

Файл для запуска на эмуляторе во вложении.

CityAceE

15.12.2023, 16:59

Нужно тестировать
Потестировал и понял, что я обманул с кодами для 4-х цветов! Я полагался на таблицу интерфейса с сайта fifan'а, а получается, что там перепутаны биты синего и красного. Ибо оба эмулятора в режиме 5-ти цветов для 5-ти цветного изображения показывают сейчас вот такую картинку:

https://pic.maxiol.com/images2/1702648392.3280329127.emu804.png

Я поднял даже первоисточник - журнал Моделист-Конструктор, но там, как обычно толком ничего не написано. Просто перечислены возможные значения, а каким цветам они соответствуют не указано.

Таким образом получается, что всё-таки коды цветов для белого, красного, зелёного, и синего для компьютеров с 5-ю и 8-ю цветами идентичны! Это видно, если в Emu80 загрузить линейную картинку сохранённую для 5-ти цветной модели и потом на лету переключать режим эмулятор с 5-ти на 8-ми цвет. Ничего не меняется!

ivagor

15.12.2023, 17:16

Я поднял даже первоисточник - журнал Моделист-Конструктор, но там, как обычно толком ничего не написано. Просто перечислены возможные значения, а каким цветам они соответствуют не указано.
МК88\7, стр.47
В левой колонке в конце второго абзаца снизу: "Таким образом светлые элементы изображения окрашиваются в один из четырех цветов: белый, красный, зеленый, синий."
В средней колонке внизу: "где, COLOR=0/64/128/192"

CityAceE

15.12.2023, 17:20

МК88\7, стр.47
В левой колонке в конце второго абзаца снизу: "Таким образом светлые элементы изображения окрашиваются в один из четырех цветов: белый, красный, зеленый, синий."
В средней колонке внизу: "где, COLOR=0/64/128/192"
Да, это я видел. И теоретически, действительно, можно совместить эту информацию, данную в разных местах статьи. Но чёткого определения всё-таки дано не было.

Dec

15.12.2023, 17:38

перепутаны биты синего и красного

Т.е. правильная таблица такая?

0x00 - Белый
0x10 - Красный
0x40 - Зелёный
0x80 - Синий
0xD0 - Чёрный

Судя по картинке и зеленый тоже ошибочен.

CityAceE

15.12.2023, 19:12

Т.е. правильная таблица такая?
Всё протестировал на эмуляторе и вот правильная кодировка:

0x00 - Белый
0x40 - Красный
0x80 - Зелёный
0xС0 - Синий

Чёрный цвет пикселя задать нельзя! Чёрным может быть только фон.

И это абсолютно точно для 5-ти цветного режима, во всяком случае на Emu80. А Emu80 нет оснований не доверять. К тому же эти цифры подтверждают и данные из журнала. Но, блин, это же опять идет вразрез с цветами 8-ми цветной схемы. Ничего не понимаю...

На всякий случай принудительно протестировал в 5-ти цветном режиме следующие номера цветов и получил следующие результаты:

0x50 - Красный
0x90 - Зелёный
0xC0 - Синий

Что, впрочем только породило больше вопросов. Возможно, это эмулятор так по-своему интерпретирует данные. Нужно тестировать на реальном 5-ти цветном компе, которого у меня нет. Предлагаю всё-таки ориентироваться на данные журнала, которые не опровергают и мои тесты.

Dec

15.12.2023, 19:44

ориентироваться на данные журналаЭто какие конкретно цифры?

CityAceE

15.12.2023, 19:50

Это какие конкретно цифры?
Вот на эти:

МК88\7, стр.47
В левой колонке в конце второго абзаца снизу: "Таким образом светлые элементы изображения окрашиваются в один из четырех цветов: белый, красный, зеленый, синий."
В средней колонке внизу: "где, COLOR=0/64/128/192"

https://pic.maxiol.com/images2/1702659434.3280329127..png

На всякий случай, первоисточник про 8-ми цветный режим:

https://pic.maxiol.com/images2/1702659803.780858384.20231215200233.png

Dec

15.12.2023, 20:17

Обновил, нужно тестировать

ivagor

15.12.2023, 20:20

это же опять идет вразрез с цветами 8-ми цветной схемы.
Это идет вразрез с текстовым утверждением из МК90\8, стр.28 "Несложные переделки в схеме приставки позволяют увеличить число цветов с пяти до восьми, то есть получить все существующие цвета, сохранив при этом программную совместимость", но не со схемой. Чтобы получить полную совместимость (а не только по белому и синему) авторам 8-цветного варианта пришлось бы усложнить свою схему. Они пошли самым простым путем, сопоставив каждому биту один базовый цвет из RGB, а в 4(5)-цветном такого соответствия нет, там дешифратор.
В этом предложении есть еще и "получить все существующие цвета", что вряд ли можно считать корректной формулировкой.

CityAceE

16.12.2023, 12:26

нужно тестировать
Проверил все возможные варианты под Emu80 с разными режимами цвета (за исключением ч/б). Всё отображается корректно! К сообщению прилагаю и исходные SPS, и готовые файлы для запуска под эмулятором.

Смущает только одно. Линейные картинки для 8-ми цветного режима корректно отображаются и со схемой под 5-цветов, и со схемой под 8-цветов. Но если делать такую же картинку чётко под 5 цветов, то корректно она отображается только с 5-ти цветной схемой, а в 8-ми цветной схеме палитра съезжает в CGA. Тут нужно либо на реальном железе с 4-ми цветами тестировать, либо кто-то с хорошими знаниями схемотехники сможет пояснить, как должно быть на самом деле.

ivagor

16.12.2023, 13:22

Это не схемотехника, это арифметика и если угодно элементы дискретной математики. В 8 дополнительный бит с весом 10hex, в 4 он не влияет на цвет, вот и все.
C0h - синий в 8 и 4
90h - зеленый в 8, в 4 работает как 80h, т.е. тоже зеленый
50h - красный в 8, в 4 работает как 40h, т.е. тоже красный
У схемы 4 есть ограниченная обратная совместимость с 8. Если делать WRGB программы для 8, то они будут одинаково работать и на 4.
Прямой совместимости нет, на 8 совпадают только белый и синий от 4.

CityAceE

16.12.2023, 13:31

Это не схемотехника, это арифметика и если угодно элементы дискретной математики. В 8 дополнительный бит с весом 10hex, в 4 он не влияет на цвет, вот и все.
Посчитать-то легко. И да, конечно, сразу видно этот "лишний" бит. Но по схемотехнике вопрос стоит в том, как именно на этот лишний бит должен реагировать компьютер. То ли игнорировать, как в эмуляторах, то ли вести себя ещё как-то иначе.

ivagor

16.12.2023, 13:52

Уточню/дополню, пока схемотехники не закидали чем-нибудь.
В 4-цветной схеме значение бита с весом 10hex не влияет на цвет, но стоит учитывать, на какой версии специалиста работает эта схема. Если в эмуляторах или в некоторых новых клонах, то проблем при использовании дополнительного бита нет. А вот если на оригинальном специалисте, то щелканье битом начального пуска будет менять конфигурацию адресного пространства.

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

Можно еще чуть дополнить - включить пзу не проблема, а вот чтобы вернуться обратно надо постараться. Понятно, что это возможно если ориентироваться на конкретное содержимое пзу и расположить переключение по определенному адресу. Даже выкладывал когда-то игрушку с подобным элементом автодетекта. Но тут всплывает возможная несовместимость с разными вариантами и клонами, поэтому не могу рекомендовать такой подход и сам делал только одну такую штуку для пробы.

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

Неожиданно сообразил, что можно и без привязки к пзу, но все равно это не очень хороший вариант для совместимости с произвольными клонами специалиста.

CityAceE

16.12.2023, 14:50

ОК. Тогда всё-в ущерб универсальности таки будем придерживаться оригинальных рекомендаций. Так будет правильнее, на мой взгляд.

CityAceE

23.12.2023, 12:14

Снял ролик с демонстрацией процесса конвертации и загрузки в Лик:

https://youtu.be/w_Ne730wTAk

YandexGPT довольно точно пересказал содержание ролика:

00:01 Графика ПК Специалист

• Видео рассказывает о ПК Специалист, компьютере, разработанном в 1985 году.
• В 1987 году была опубликована его схема и описание программы.
• Графика ПК Специалист была пиксельной, с разрешением 384x256.
• В дальнейшем была добавлена возможность добавления цвета.

04:12 Загрузка графики

• Автор загружает картинку с обычного компьютера в программу DIT, которая конвертирует ее в формат, понятный для старых компьютеров.
• Затем картинка сохраняется в формате SPS.

07:22 Загрузка картинки на ПК Специалист

• Автор использует скрипт на Python для преобразования SPS файла в формат, пригодный для загрузки на ПК Специалист.
• Затем картинка загружается на экран компьютера с помощью смартфона.

12:36 Результат

• Графика на ПК Специалист выглядит достойно, особенно по сравнению с другими компьютерами того времени.
• Автор считает, что если бы у него был такой компьютер в 1985 году, он был бы на седьмом небе от счастья.

Shumadan

23.12.2023, 15:20

в те времена я бы тоже писал от счастья увидев такого качества картинку. Кстати каким образом можно было создать и загрузить картинку используя возможности того периода?

CityAceE

23.12.2023, 16:27

Кстати каким образом можно было создать и загрузить картинку используя возможности того периода?
К сожалению, на Специалисте в то время (да и сейчас ничего не изменилось) даже толкового графического редактора не было. Картинки в основном тягали со Спектрума. Была такая программа, которая позволяла загружать с магнитофона стандартные заставки со Спектрума.

ivagor

23.12.2023, 17:15

Стоит упомянуть графический редактор Волкова (МК88\8), может он не очень развитый и удобный, но при большом желании рисовать можно.

CityAceE

23.12.2023, 17:20

Стоит упомянуть графический редактор Волкова (МК88\8)
Да, я его и имел ввиду, потому как я лично других и не знаю. И вообще сомневаюсь, что кроме него что-то ещё было и есть. Но, безусловно, очень хорошо, что он был опубликован на страницах М-К.

CityAceE

29.12.2023, 15:40

Рассказал для обывателей про цветную графику на Специалисте. Местные завсегдатаи ничего нового и интересного в этом ролике не найдут. Я сейчас уже даже боюсь что-то на форум выкладывать, так как обязательно огребу за ошибки, неточности и т.д. ;)

https://youtu.be/pPF3icSGODY

fifan

30.12.2023, 13:46

Очень красочное видео. Разместил на странице (http://www.xn----7sbombne2agmgm0c.xn--p1ai/index7.html). Появится с Нового года.

Dec

02.05.2024, 17:18

CityAceE

03.05.2024, 13:20

В программу добавлен ordered dithering, с ним картинки выглядят более аккуратно
Отлично, спасибо! Этого типа обработки действительно не хватало в программе.

CityAceE

18.09.2025, 12:22

Для иллюстрации мысли о возможности интерактивной синхронизации с разверткой набросал программку. Как я понимаю, у специалиста в строке 128 тактов, сколько строк точно не знаю, но предположил, что 312. В emu (b2m) похоже именно такие параметры, в emu80 (Pyk) вероятно другие, там запускать нет смысла. Что будет видно в emu. После запуска видим 4 скроллящиеся столбца с диагональной "помехой". Нажав пробел "помеху" можно выдвинуть за пределы экрана. Если дальше жать пробел, то помеха вернется сверху и так по кругу.

Проверил на последней версии Emu80, там действительно можно лесенку увести за пределы экрана, но она через короткое время снова выползает.
На реальном Сябре всё сильно хуже. Лесенка быстро движется вверх, а нажатие на пробел лишь незначительно снижает её скорость.
На подходе мой обновлённый ЛИК, который благодаря усилиям двух профессионалов (AlexBel и Serg6845 - один разработал и изготовил плату расширения, а второй подключил и исправил ошибки) обзавёлся цветом, SD и таймером. Проверю в воскресенье, как с ним ситуация. Там ещё Сергей по моей просьбе немного сдвинул картинку влево, потому что 4 пикселя справа обрезались (https://zx-pk.ru/threads/35304-voprosy-po-arkhitekture-quot-spetsialista-quot.html?p=1186346&viewfull=1#post1186346). Может быть это тоже как-то может повлиять на результат.

ivagor

18.09.2025, 13:10

Проверил на последней версии Emu80, там действительно можно лесенку увести за пределы экрана, но она через короткое время снова выползает.
На реальном Сябре всё сильно хуже. Лесенка быстро движется вверх, а нажатие на пробел лишь незначительно снижает её скорость.
Так проявляются разные параметры развертки, которые у клонов специалиста и эмуляторов не стандартизованы. Подобные программы приходится нацеливать на конкретные среды исполнения (я подгонял под emu). Вот насчет Сябра сомневаюсь, что под него можно подогнать, а учитывая что у него нет нормального арбитража доступа к памяти между процом и видео лично для меня это неприемлемый вариант специалиста.

Smalovsky

18.09.2025, 14:11

А как насчёт игр? Например, внешняя видеокарта
https://zx-pk.ru/threads/36330-otkrytaya-videokarta-dlya-8-itnykh-sistem-na-mikroskhemakh-ttl-serii-74.html

ivagor

18.09.2025, 16:14

теперь это работает и в emu и в современных версиях emu80

Проверил на последней версии Emu80, там действительно можно лесенку увести за пределы экрана, но она через короткое время снова выползает.
Перепроверил - в версиях 4.0.532 и 4.0.535 (последняя публичная на сегодняшний день) лесенка стоит на месте и если ее увести за пределы видимой области, то она там и остается, не выползает.
У меня есть догадка, что ты проверял в конфиге специалиста с z80, а не в классике с 8080, на которую я рассчитывал.

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

Теоретически можно сделать универсальную для 8080 и z80, но это еще усложняет и так непростую задачу выдерживания периода. Проще даже сделать две отдельные версии для 8080 и z80 (или три если с 8085).

CityAceE

18.09.2025, 17:14

У меня есть догадка, что ты проверял в конфиге специалиста с z80
Ты абсолютно прав! Вообще у меня всё время запущен конфиг именно с i8080, а тут я что-то проверял на Z80 и он так и остался стоять, а я даже не заметил! Переключил на i8080 и всё действительно заработало, как ты описываешь!

CityAceE

18.09.2025, 17:30

Ну и коли уж про скроллинг заговорили, может подскажете, как его организовать грамотно если уж не совсем без тиринга, то хотя бы с минимально заметным?

Нужно плавно попиксельно двигать окно высотой 112 пикселей и шириной 40 байт.

Я сходу сделал сдвиг столбцов через стек с развёрнутым циклом. Но получилось, мягко говоря, не очень (на реале и под эмулятором выглядит всё-таки получше, чем после захвата):

https://plvideo.ru/watch?v=NWiHr-k-b_69

Потом я просто в лоб без всяких стеков и выкрутасов решил двигать построчно. Построчно, имеется виду, строка текста высотой 8 пикселей. Стало, конечно, медленнее и всё равно плохо, но, как по мне, для глаза всё же поприятнее.

https://plvideo.ru/watch?v=QXrxz0DTXtT9

Там почти весь текст (но не весь!) идёт через пустую строку высотой 8 пикселей. Думаю как-то этот факт учитывать и не трогать пустые строки. Но пока эту головоломку отложил в строну, так как хужо-бедно работает. Но, так оставлять, конечно, нельзя.

b2m

18.09.2025, 17:52

Там почти весь текст (но не весь!) идёт через пустую строку высотой 8 пикселей. Думаю как-то этот факт учитывать и не трогать пустые строки.
Я предлагал в соседней теме делать вывод текста через push. Если нижняя строка шрифта пустая, то можно печатать текст поверх, смещая его на 1 пиксель вверх.

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

К примеру, вот так выглядит "код" буквы:

SPHL ; в HL адрес экрана, прямо под буквой
INR H
INX B
LDAX B ; в BC адрес "текстовой строки", загружаем следующий символ
STA $+20
LXI D,0
PUSH D
...
LXI D,0
PUSH D
JMP TABFONT

Нужно заранее сдвинуть коды букв на два бита влево, чтобы получалось смещение в таблице TABFONT (её конечно выровнять на границу 256 байт). Символ с кодом 00 - конец строки, выход из п/п печати.

ivagor

18.09.2025, 18:47

Для подобной задачи считаю более подходящим вариант с построчным выводом, как уже писал. Не обязательно по одной строке, можно по 2х байтным вертикальным блокам
024...
135...
или
135...
024...

Преимущество скорости постолбцового вывода меркнет перед многочисленными разрывами.

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

Вполне возможно подойдет компромиссный вариант - выводить символ естественным образом (по столбацам, можно через стек), а потом смещаться вправо и выводить следующий символ и так всю строку.
Что касается пустых строк да и всех пробелов, то их конечно не нужно выводить, если у каждого ненулевого (с точками) символа нижняя строка или две (смотря какой шаг сдвига) нулевые.

CityAceE

18.09.2025, 19:29

Вполне возможно подойдет компромиссный вариант - выводить символ естественным образом (по столбацам, можно через стек), а потом смещаться вправо и выводить следующий символ и так всю строку.
Во втором видео я как раз так и делал. Правда, без оптимизации, просто посмотреть как это будет выглядеть.

ivagor

18.09.2025, 21:19

Примерно посчитал вариант b2mа, если не ошибся получилось 139 тактов/символ, весьма шустро. 29 байт/символ (+таблица 256 байт), символов максимально 64 и минимум 2 из них служебные (перевод строки и конец текста).
Прикинул вариант с 256 символами (16 байт/символ + дополнительно надо посчитать), но с полезной матрицей 8x6 + 2 строки пустые, у меня получилось в районе 200 тактов/символ.

ivagor

19.09.2025, 05:57

139 тактов/символ
Можно быстрее.
1. Учесть, что часть байтов повторяются, тогда часть lxi меняем на mvi или убираем.

2. Совсем другой вариант на базе идей Дениса Грачева. Адрес текста в SP, но не коды букв, а адреса процедур. Базовый вариант:

;SP - адрес текста
;HL - экранный адрес
;A - младшая половина экранного адреса
inr h
mov l,a
mvi m,data0\ inr l ;7 повторов
...
mvi m,data7
ret
2.1. Свободны 4 регистра в которые можно поместить 4 наиболее используемых в символах байта (один явно будет 0). Меняем соответствующие mvi m,data на mov m,r.
2.2. При сдвиге на 1 строку можно выводить нулевые байты только если они идут после ненулевых. Плюс досрочное окончание процедуры если внизу остались только нули. Тогда вывод пробела сокращается до

inr h\ mov l,a\ ret

CityAceE

19.09.2025, 09:27

Правильно ли я понимаю вашу мысль, что вы предлагаете не сдвигать экран, а просто перепечатывать его поверх особым образом, сдвинув на один пиксель вверх? Неужели это может быть быстрее, чем сдвигать блок 8*8 вверх на пиксель?

И сразу оговорюсь, что в используемом шрифте нижняя строка не всегда пустая. Я точно помню, что как минимум "y" занимает низ. У меня из-за неё скорллинг "мазал" (оставлял след) в одном из моих экспериментов.

А что при таком варианте делать с верхней и нижней с текстовыми строками?

Вообще в оригинале, который я пытаюсь скопировать 1:1, текст попиксельно появляется снизу, и также попиксельно исчезает сверху. Я пока для упрощения нижнюю строку просто печатаю целиком, но тоже в дальнейшем обязательно планировал привести к должному виду.

ivagor

19.09.2025, 10:12

перепечатывать его поверх особым образом, сдвинув на один пиксель вверх? Неужели это может быть быстрее, чем сдвигать блок 8*8 вверх на пиксель?
Попробуй сочинить сравнимую по скорости процедуру сдвига, вряд ли это возможно.

И сразу оговорюсь, что в используемом шрифте нижняя строка не всегда пустая. Я точно помню, что как минимум "y" занимает низ. У меня из-за неё скорллинг "мазал" (оставлял след) в одном из моих экспериментов.
Второй вариант хорошо подходит, добавляется девятая нулевая строка только для букв у которых восьмая не пустая.

А что при таком варианте делать с верхней и нижней с текстовыми строками?

Вообще в оригинале, который я пытаюсь скопировать 1:1, текст попиксельно появляется снизу, и также попиксельно исчезает сверху. Я пока для упрощения нижнюю строку просто печатаю целиком, но тоже в дальнейшем обязательно планировал привести к должному виду.
1. Отдельные "классические" процедуры для верхней и нижней строки.
2. Или вывести верхнюю строку быстрой процедурой и сразу стереть лишнее, аналогично для нижней.

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

inr h\ mov l,a\ ret
Ступил, в букве с ненулевыми строками будет в начале mov l,a поэтому в пробеле это не нужно и остается только inr h\ ret

CityAceE

19.09.2025, 11:47

Запутался.
- Вариант b2m не подходит по причине того, что нужно принудительно стирать линию ниже. Ну либо же потом отдельной рутиной стирать её. А если делать шрифт высотой 10 пикселей, чтобы две нижних строки были гарантированно пустыми?
- Варинат ivagor выглядит привлекательным, но там текста почти на 4 кило, а при этом в памяти ещё нужно место под музыку и 7 картинок. Таким образом, чтобы закодировать 4 кб текста процедурами просто не хватит памяти.
Либо я не понимаю того, что вы предлагаете.

ivagor

19.09.2025, 12:07

А если делать шрифт высотой 10 пикселей, чтобы две нижних строки были гарантированно пустыми?
Почему нет? В каждой процедуре добавится 4 байта lxi d,0 + push d.

текста почти на 4 кило, а при этом в памяти ещё нужно место под музыку и 7 картинок. Таким образом, чтобы закодировать 4 кб текста процедурами просто не хватит памяти
Т.е. место для 4 кб есть, а для 8 кб нет? Тогда вариант b2m.
Но меня смутило про "закодировать 4 кб текста процедурами". Число процедур зависит от числа букв, не от размера текста, у b2m 64 процедуры максимум по 30 байт (если 10 строк) + таблица переходов 256 байт.

CityAceE

19.09.2025, 13:04

Число процедур зависит от числа букв, не от размера текста,
Значит, я не до конца понял идею. Я твой пример интерпретировал как кодирование каждой буквы текста (не фонта!) отдельной процедурой. У меня не тут уровень, конечно - я всё делаю по-деревянному, чисто в лоб.

CityAceE

19.09.2025, 20:00

Pyk

20.09.2025, 00:20

Что за таблица, какова её структура? Как можно переходить на таблицу по "JMP TABFONT "?
Если я все правильно понял, в таблице команды JMP на адреса фрагментов кода для вывода различных символов, выравненные по границе 4 байт. Старший бит адреса таблицы фиксированный, младший выбирается записью в операнд команды JMP (STA $+20) кода символа, умноженного на 4. Во втором варианте отдельной таблицы нет, строки кодируются просто последовательностью адресов фрагментов кода, рисующих символы, в обратном порядке.

DenisGrachev

20.09.2025, 05:44

Я вижу, что вы понимаете друг друга с полуслова, но прошу всё-таки пояснить и разжевать для тупых суть этого волшебного метода. Я даже подключил ИИ к вашему диалогу, но и он трактует то, о чём вы тут пишете, как последовательность процедур печати каждого символа без всяких таблиц на 256 байт. Что за таблица, какова её структура? Как можно переходить на таблицу по "JMP TABFONT "? Можно чуть полнее код увидеть?

Как уже написали достаточно младший байт в адресе перехода поправить, это стандартная штука для lut таблиц, они как правило выравниваются на 256 байт в паяти.TABFONT выглядит как список джампов, примерно так:

jp drawLetter0 : nop : jp drawLetter1 ; nop и.т.д

Я вот немного не понял зачем выравнивать по 4 байта, jmp+адрес вроде 3 занимают :) Можно договорится что код символа умноженные на три юзаем и тогда 85.33333 влезет тайла ) на спектруме ещё jr можно заюзать для служебных...

Но мне кажется твой вариант "в лоб" выглядит вполне ок, я бы не упарывался ради текста )