NedoText на рассыпухе

[Shaos]

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

Вроде получается без мёртвых зон (при условии, что частота внешнего процессора будет ниже тактирования схемы т.е. при 10 МГц схемы можно устроить стабильную работу при 2 или даже 5 МГц процессора).

[Ball Bess]

А как насчёт двухпортовой памяти?

[Shaos]

А как насчёт двухпортовой памяти?

ну мы строим видеомодуль из доступных компонентов - т.е. советская память и мелкая логика или их аналоги - среди советского двухпортовую память не встречал...

[Shaos]

в качестве проверки концепции (уточнение работоспособности выбранных растактовок) предполагаю сделать первый вариант недотекста на микроконтроллере SX-28 - для того, чтобы вытянуть 10 миллионов точек в секунду (для желаемых 80x25 символов в кадре) микроконтроллер должен работать на 60 МГц (при условии наличия снаружи сдвигового регистра) - причём этот же микроконтроллер будет являться знакогенератором (правда лишь на ASCII набор символов из диапазона 0x20...0x7F) - снаружи микроконтроллера также будет 2К срам в качестве видеопамяти - из неё микроконтроллер будет забирать сразу 80 символов строки и затем не трогать эту память в течение семи следующих строк развёртки (восьмая строка развёртки текстовой строки всегда пустая, ну или с курсором - там будет произодится забор следующих 80 символов из видеопамяти)

[Shaos]

в качестве проверки концепции (уточнение работоспособности выбранных растактовок) предполагаю сделать первый вариант недотекста на микроконтроллере SX-28 - для того, чтобы вытянуть 10 миллионов точек в секунду (для желаемых 80x25 символов в кадре) микроконтроллер должен работать на 60 МГц (при условии наличия снаружи сдвигового регистра) - причём этот же микроконтроллер будет являться знакогенератором (правда лишь на ASCII набор символов из диапазона 0x20...0x7F) - снаружи микроконтроллера также будет 2К срам в качестве видеопамяти - из неё микроконтроллер будет забирать сразу 80 символов строки и затем не трогать эту память в течение семи следующих строк развёртки (восьмая строка развёртки текстовой строки всегда пустая, ну или с курсором - там будет произодится забор следующих 80 символов из видеопамяти)

Начал практическую релизацию вышесказанного - читать тут: viewtopic.php?t=8553

[cr0acker]

ООООО Шаос играет в Дюну2%)

[Shaos]

ООООО Шаос играет в Дюну2%)

Угу - хорошая игрушка

[cr0acker]

ООООО Шаос играет в Дюну2%)

Угу - хорошая игрушка

Я тоже с неё гначинал играл всегда за Харконенов:) Потом была 2000ные, где момм основным юнитом была боевая маневренная группа составленная из двух легких пехотинцев и трех тяжелых.

[Shaos]

ООООО Шаос играет в Дюну2%)

А теперь тоже самое на экране ТВ:



Читать тут

[Shaos]

Первый вариант девайса готов:



Читать тут

[Shaos]

Обещанные растактовки для 10 МГц:

NTSC (60 frames/sec * 262 lines * 636 pixels):

Code: Select all

Lines 0...199:
    ____^^^^^^^^^^^^^^^^^^^^__
|__|
 48  84     480 (screen)    24

Lines 200...224:
    __________________________
|__|
 48           588

Lines 225,226,227:
 __
|  |__________________________
 48           588

Lines 229...261:
    __________________________
|__|
 48           588

в реальном коде ступенька перед сигналом в строках 0...199 была поуже - примерно 67 тактов (а ступенька после сигнала практически не считалась, т.к. строка висела на прерывании)

PAL (50 frames/sec * 312 lines * 640 pixels):

Code: Select all

Lines 0...199:
    ____^^^^^^^^^^^^^^^^^^^^__
|__|
 48  84     480 (screen)    28

Lines 200...243:
    __________________________
|__|
 48           592

Lines 244,245,246:
   ____________   ____________
|_|            |_|
24     296     24      296

Lines 247,248:
___________                 __
           |_______________|
    276          318        46

Line 249:
___________    _______________
           |__|
    276     48       316

Lines 250,251:
   ____________   ____________
|_|            |_|
24     296     24      296

Lines 252...311:
    __________________________
|__|
 48           592

растактовка PAL на 10 МГц является чисто теоретической (NedoText так и не научился её генерить), основанной на опыте создания NedoVideo, который у меня мог генерить и NTSC, и PAL

P.S. частота строк: NTSC - 15734 Гц, PAL - 15625 Гц

[Shaos]

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

Ну тогда можно и к NI-15 его присобачить

Примерный расклад такой - имеем 4 порта:
#B0 - порт управления (пока мыслится один бит 0 - обычный шрифт "0" или псевдографика "1")
#B1 - порт координаты X (допустимые значения 0...79)
#B2 - порт координаты Y (допустимые значения 0...24)
#B3 - код символа в указанных координатах (прочитать или записать)
Все порты функционируют и на запись, и на чтение. Ввиду того, что схема не будет тормозить центральный проц в случае занятости, центральный проц должен будет переспрашивать значение символа после каждой записи, чтобы убедиться, что он действительно записан:

Code: Select all

PRINT: ; B-x, C-y, D-code
 MOV A,B ;5t
 OUT #B1 ;10t
 MOV A,C ;5t
 OUT #B2 ;10t
PRINT1:
 MOV A,D ;5t
 OUT #B3 ;10t
 IN #B3 ;10t
 CMP D ;4t
 JNZ PRINT1 ;10t
 RET;10t

Время выполнения подпрограммы - 40+39*N тактов, где N - количество попыток записи. Вывод одного символа в лучшем случае займёт 40+39=79 тактов (или 25316 символов в секунду при 2 МГц), но с учётом того, что в пределах кадра будут "мёртвые зоны", внутри которых видеопамять будет недоступна внешнему процессору, реальная скорость будет меньше (будет больше неудачных попыток записи) - предположительно "мёртвые зоны" будут занимать 6% всего времени (это для PAL, а для NTSC больше - 7.2%).

P.S. В будущих версиях можно прикрутить автоматический инкремент координат по чтению или успешной записи символа (будет устанавливаться двумя битами в порту управления).

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

Для упрощения можно разрешить на чтение и запись только порт символа - остальные только на запись. К видеопамяти можно обращаться не по координатам, а по адресу в микросхеме - в этом случае не придётся ставить лишний сумматор, на вычисление адреса из координат - хотя сумматор(ы) всё равно будет, чтобы в процессе отрисовки считать смещение в видеопамяти 80*y+x = (y<<6) + (y<<4) + x. Ну и скролл можно добавить - для круглоты например поддержав 64 строки, замкнутые в кольцо (это 5Кб) и на экран выводится 25 строк идущие подряд по указанному в порту управления смещению плюс флаг разрешения записи (чтобы можно было спокойно 3 байта один за другим заполнить не вызывая порчу данных на экране по неполным координатам):

#B0 - порт управления (7й бит - разрешение записи в видеопамять, 6й бит - обычный шрифт "0" или псевдографика "1", ну и 6 младших битов - смещение экрана в строках)
#B1 - старший байт адреса видеопамяти (#00...#14 т.е. 3 старших бита остаются неиспользуемыми - поддержать в будущем цвет?)
#B2 - младший байт адреса видеопамяти
#B3 - код символа по указанному адресу (прочитать или записать)

Адрес видеопамяти из координат X и Y можно получить так (Offset это вертикальное смещение для скрола):

BigY = Y + Offset (6-битный сумматор)
Address = X + BigY<<4 + BigY<<6 (один 10-битный сумматор с 11-битным выходом и один 12-битный сумматор с 13-битным выходом)

По идее этот сложный тройственный сумматор можно реюзать и для вывода, и для записи, т.е. в портах B1 и B2 могут быть действительно координаты (причём сразу в пределах видимой области) - или слишком сложно выходит? С другой стороны наличие возможности писать и читать за пределами области прокрутки используя полный адрес позволит хранить в видеопамяти дополнительные данные (в случе 8Кб микросхемы ОЗУ это будет аж 3Кб дополнительной памяти)...

[Shaos]

Возможный вариант с поддержкой 3 бита на цвет:

Code: Select all

0 - black on white background (inversion)
1 - blue
2 - green
3 - cyan
4 - red
5 - magenta
6 - brown (or dark yellow?)
7 - white on black background

P.S. Или инвертировать надо, чтобы цвет 0 означало нормальный режим белым по черному?

P.P.S. По идее это вообще может означать номер палитры, а запись в палитру делать как запись в видеопамять по старшим (невидимым) адресам - скажем поддержать 4 уровня яркости на каждую цветовую составляющую (00->#00, 01->#55, 10->#AA, 11->#FF) - это 6 бит на цвет задаваемых одним байтом (00RRGGBB) причем старшие 2 бита могут кодировать цвет фона (4 варианта - черный 00, темно серый 01, светло серый 10 и белый 11). Режим по умолчанию - ярко белым по черному (00111111) и любая запись в палитру будет сбрасывать этот режим. Цвет может храниться во второй микросхеме видеопамяти - по байту на знакоместо т.е. теоретически возможно иметь 64 разных цвета одновременно на экране (а в режиме псевдографики - когда каждое знакоместо представляет из себя 2 графические точки с 16 градациями яркости каждая - количество одновременно отображаемых цветов может достигать 4096 в псевдографическом экране 80x50) т.е. это палитра не на отображение, а на запись - на уровне знакоместа всегда хранится полный цвет...