nedoPC.org

Забыл уточнить: Горизонтальный скроллинг отдельных строк.

Кстати, раз уж на то пошло:

• 80-BF - «10URGGBH» стандартные атрибуты ВГ75
• C0-DF - «110PPPPP» выбор палитры
• E0-E3 - «111000??» резерв?
• E4-E5 - «1110010F» переключение параграфа знакогенератора
• E6-E7 - «1110011?» резерв?
• E8-EF - «11101???» резерв?
• F0-F3 - «111100SS» управление циклами ПДП
• F4-FF - «1111TTTT» управление табуляцией

Если чуточку поднапрячься, можно счётчик пикселей (D3 ИЕ4 в схеме РК) принудительно сбрасывать кодами (например, E0-E3) и обеспечить очень точный попиксельный скролл по горизонтали (что в тех же играх придало бы максимум плавности) всей отдельной строки.

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

Сейчас перерабатываю исходный код Монитора и подошёл к подпрограмме F82D по адресам FACE…FAFC. Основная цель - унифицировать подпрограмму так, чтобы приложению не нужно было самостоятельно обращаться к ВТ57 и ВГ75.
(Строго говоря, авторы РК вообще не предусмотрели никакого API для работы с периферией, из-за чего большинство программ напрямую всё программируют сами, нарушая совместимость и переносимость.)

Так, вот исходный код Монитора:А вот мой вариант:Где XXXX - некий адрес свободной области в ПЗУ под таблицу описания исходного режима ВТ57/ВГ75 РК.
При этом:

• Ячейки 7620/7621 хранят адрес таблицы стандартного режима или пользовательского
• «CALL FACE» - восстанавливают исходный режим
• «CALL FAD6» - устанавливают пользовательский режим

Конечно, в исходном Мониторе это реализовать несколько проблематично и не имеет смысла, однако в рамках моего Монитора реализовать несколько легче, так как там имеется набор подпрограмм и для доступа к ROM-Диску.

Для остальных пользователей - подгружаемый вариант для изучения алгоритма работы.

Я тут подумал…

Раз есть i8080A и i8255A, почему бы не, хотя бы, гипотетически, разработать i8275A?

1. Полная совместимость по всем выводам¹
2. Полная совместимость на программном уровне
3. Снятие ограничений на максимальную длину знакоряда в 80 знакомест - до 128
4. Снятие ограничений на количество атрибутов в знакоряде - до 128
5. Возможность управления режимами через ПДП-поток
6. Внутренний буфер²

¹ - в расширенных режимах есть нюансы.
² - цикл ПДП можно включать разово программно лишь после изменения содержимого буфера. Иначе говоря, при отключении ПДП экран не пустеет, а отображает всё из внутреннего кэша (скажем, на тех же РУ6).

Так, если ВГ75 по команде Сброса 00 принимает четыре байта режима (в РК - это «4D 1D 99 93»), то можно добавить ещё байтик управления шириной/высотой «бордюра», что сильно не хватало всегда!
Обычная ВГ75 вернёт в слове статуса C001 флаг «Improper Command» бит 3 маска 08h.

С другой стороны, запрет на приём из ПДП-потока двойного кода «Стоп ПДП»…
Например: «F3 00 F3 00» - подготовка к установке нового режима…
То есть, «F3 00 F3 00 4D 1D 99 93 VH XX YY» передаст в регистры режима стандартные параметры и ещё дополнительные, где «VH» - высота и ширина «бордюра», а «XX» и «YY» - позиция курсора.
Тем самым, задав в ПДП буфер экрана 76D0…7FFF, концовка может быть следующей:И программе не нужно лезть в порты, чтобы изменить позицию курсора.
Просто настраиваем ПДП на какой-либо буфер, а сам режим - задаём в самой памяти.
(Естественно, ещё нужен котрольный байт, чтобы подтвердить валидность режима в ОЗУ.)

P.S.: Есть ещё некоторые соображения предопределения режима для каждой строки отдельно, типа как в тех же Atari.
Но тогда несколько сложнее всё получится.

Наконец-то дошли руки до написания кода тестирования тройного знакогенератора.

Попытался написать предельно быстрый алгоритм горизонитальной прокрутки области 64x25.
Примерно, 821 такт на прокрутку пятидесяти символов - около 26272 тактов на экран.

Написал процедуру прокрутки экрана с предельной производительностью.

Программный скролл? Через ВГ75+ВТ57 аппаратно же можно скроллить

Ну, так это да.
На программном уровне просто было любопытно посмотреть, на сколько сложно прокручивать экран без трюков с ВТ57/ВГ75 - только стек.
Получается, порядка 13 тактов на знакоместо + 10 тактов на строку: 13x64+10=842 такта на строку - 21050 тактов на 25 строк.
То есть, за секунду - 84 fps прокрутки.

Это быстро получается

Ты SUPERPAN забыл сюда прицепить
(я его чегой-то не заметил)
Чем он от SUPERSCROLLAR отличается?

http://www.nedopc.org/forum/viewtopic.php?f=93&t=10577&view=unread#p173116
Только направлением прокрутки.

Можно, конечно, реверс вверх/вниз реализовать - уже нашёл способ (мысленно), но не писал ещё - нет практической необходимости.
А вот реверс влево/вправо - нельзя в один код описать. И вправо скорость несколько меньше - +1 такт на каждую пару знакомест: +40 тактов на строку.

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

Это хорошая идея

В строке точно 78 знакомест. Я смотрел исходники игр для Апогея.

Жаль, что дальше теории тема не сдвинулась.

Вот, сделал набросок одного из возможных вариантов синхронизации ВГ75 от внешнего источника композитного видео.
Из всех доработок:

1. Отрезаем вывод 7 ВГ75 к выводу 4 ЛП5 и оба выводим к дополнительному ТМ2
2. Отрезаем выводы 2 и 3 у ИЕ4 от массы и подключаем к дополнительному ТМ2

Логика работы схемы следующая:

1. Первая половина ТМ2 включена в режим инвертирования сигнала «BURST» от LM1881 и пока не пришёл ССИ как лог. "0", с вывода 6 выдаётся лог. "0" на вывод 4 элемента ЛП5 D5.2
2. В конце графической линии растра ВГ75 вырабатывает сигнал HRTC и стробирует загрузку "1" с первой половины ТМ2 во вторую половину ТМ2
3. Загруженная лог. "1" с вывода 9 поступает на выводы 2 и 3 ИЕ4, переводя его в состояние сброса, чем прерывается поступление частоты сигналом CCLK на ВГ75 в ожидании синхроимпульса от внешнего источника
4. Когда LM1881 обнаруживает синхроимпульс и вырабатывает лог. "0" на «BURST», с вывода 6 ТМ2 на вывод 4 ЛП5 D5.2 поступает лог. "1". Также лог. "0" на «BURST» сбрасывает вторую половину ТМ2 и на выводе 9 устанавливается лог. "0", разращая работу счётчика ИЕ4 в штатном режиме
5. Так как ВГ75 всё это время находилась без тактирования по CCLK, теперь начинается отсчёт длительности сигнала HRTC уже с началом ССИ от внешнего источника, тем самым позволяя программисту использовать параметр «ZZZZ» как величину определения левого "бордюра"

Главное условие корректной работы: HRTC должен приходить раньше сигнала ССИ внешнего источника.
Решение: Либо чуть повысить частоту тактирования ИЕ4, либо в коде инициализации ВГ75 константу 93h заменить на 92h.

P.S.: Вариант схемы очень черновой и нигде не проверялся.
Также, в схеме нет (пока что) синхронизации по кадрам: Картинка будет прыгать.

В очередной раз перечитывая документацию к ИМС i8275/ВГ75, задумался над примечанием:Тем самым, если в конце строки разместить код F1 или F3 в конце кадра, любой следующий символ будет прочитан, но проигнорирован самой ВГ75.
А это - целых 256 комбинаций кода!

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

Осталось лишь разработать схемку...

• Вентиль 5-И отлавливает ситуацию с кодами F0-FF
• Триггер ТМ2 защёлкивает флаг "управляющего кода"
• Регистр ИР27 запоминает следующий Dummy-байт

В общем, всё просто!

Тем самым, подобно как и в ПК Atari-XE, можно под каждую строку изменять и режим интерпретации символов (пропускать код через знакогенератор, непосредственно рассматривать его как три четырёхцветных CGA-пикселя или два восьмицветных пикселя и т.п.).