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

Shaos · Post by **Shaos** » 12 Jul 2006 06:03

cr0acker wrote:
Shaos wrote:
cr0acker wrote:
Shaos wrote:
cr0acker wrote:Пиксель клок будет 16Мгц что в теории даст.640х200, что достаточно для вывода текста в формате 80х25. Пока bw-only
Для вывода текста в формате 80х25 хватит экрана 480х200 (одно знакоместо 6х8 пикселов) - на это должно хватить 10 МГц с заталкиванием кадра в видимую область NTSC и PAL. Надо?
Угу
Если 1 бит на пиксел, то это будет 60 байт в строке или 12000 байт в кадре. Логику можно сделать на рассыпухе или действительно в ПЗУ затолкать.

По идее можно и чисто текстовое решение сделать (графику в этом случае можно будет псевдографикой городить - 160х50 пвсевдопикселов). Быстрее будет текст программно выводиться и заморочек меньше с синхронизацией.
Или так.
Вобщем прикидываю чисто текстовое решение - 80x25 со знакоместом 6x8 (получается 480x200 в PAL/NTSC). На мелкой логике схема будет более чем монстроидальная - даже с использованием ПЗУ или программируемой логики. Быстрый микроконтроллер типа SX-28 надо фтыкать.
А если графика 480х200? Вроде попроще должно быть

Не - сложность в синхросмесях

Shaos · Post by **Shaos** » 02 Aug 2006 18:57

Shaos wrote:Вобщем прикидываю чисто текстовое решение - 80x25 со знакоместом 6x8 (получается 480x200 в PAL/NTSC). На мелкой логике схема будет более чем монстроидальная - даже с использованием ПЗУ или программируемой логики. Быстрый микроконтроллер типа SX-28 надо фтыкать.

Вроде придумал как обойтись одной ПЗУ на 2К и некоторой обёрточной логикой - так что вполне можно соорудить на советских микросхемах

Shaos · Post by **Shaos** » 04 Aug 2006 19:56

Shaos wrote:
Shaos wrote:Вобщем прикидываю чисто текстовое решение - 80x25 со знакоместом 6x8 (получается 480x200 в PAL/NTSC). На мелкой логике схема будет более чем монстроидальная - даже с использованием ПЗУ или программируемой логики. Быстрый микроконтроллер типа SX-28 надо фтыкать.
Вроде придумал как обойтись одной ПЗУ на 2К и некоторой обёрточной логикой - так что вполне можно соорудить на советских микросхемах

Ещё добавим 2К ПЗУ на знакогенератор - 256 символов 5x7 в досовской кодировке плюс альтернативный шрифт для псевдополутоновой псевдографики 80x50 (16 "полутонов") - выглядеть оно будет примерно так:

Ну и ещё 2К ОЗУ на видеопамять...

Shiru Otaku · Post by **Shiru Otaku** » 04 Aug 2006 20:07

Ооо, чанки. ZX-демомейкеры будут очень довольны;)

Shaos · Post by **Shaos** » 04 Aug 2006 20:48

Shiru Otaku wrote:Ооо, чанки.

Причём заметь - "аппаратные" чанки

Shiru Otaku wrote:ZX-демомейкеры будут очень довольны;)

Боюсь неочень - тут ведь Z80 не будет

cr0acker · Post by **cr0acker** » 04 Aug 2006 22:42

Круто, жду схемы.

Mac Buster · Post by **Mac Buster** » 04 Aug 2006 23:03

Эх, жаль к ЦЦ'06 не успеем

Shaos · Post by **Shaos** » 05 Aug 2006 20:41

HardWareMan · Post by **HardWareMan** » 05 Aug 2006 23:51

Respect! Вот если бы еще его повторить..... Когда доки будут?

Shaos · Post by **Shaos** » 06 Aug 2006 19:31

Shaos wrote:
Shaos wrote:
Shaos wrote:Вобщем прикидываю чисто текстовое решение - 80x25 со знакоместом 6x8 (получается 480x200 в PAL/NTSC). На мелкой логике схема будет более чем монстроидальная - даже с использованием ПЗУ или программируемой логики. Быстрый микроконтроллер типа SX-28 надо фтыкать.
Вроде придумал как обойтись одной ПЗУ на 2К и некоторой обёрточной логикой - так что вполне можно соорудить на советских микросхемах
Ещё добавим 2К ПЗУ на знакогенератор - 256 символов 5x7 в досовской кодировке плюс альтернативный шрифт для псевдополутоновой псевдографики 80x50 (16 "полутонов") - выглядеть оно будет примерно так:

Ну и ещё 2К ОЗУ на видеопамять...

А вот примеры текстовых экранов (только что закончил подготовку шрифта):

HardWareMan · Post by **HardWareMan** » 06 Aug 2006 20:24

Не трави душу! Когда будет готово?

Shaos · Post by **Shaos** » 07 Aug 2006 06:15

HardWareMan wrote:Не трави душу! Когда будет готово?

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

HardWareMan · Post by **HardWareMan** » 07 Aug 2006 06:29

Shaos wrote:
HardWareMan wrote:Не трави душу! Когда будет готово?
Прежде чем городить окончательную схему, надо определиться - либо я даю полный адресный доступ к видеопамяти, либо оперирую тремя (четырмя) портами для заполнения видеопамяти.

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

cr0acker · Post by **cr0acker** » 07 Aug 2006 09:10

HardWareMan wrote:
Shaos wrote:
HardWareMan wrote:Не трави душу! Когда будет готово?
Прежде чем городить окончательную схему, надо определиться - либо я даю полный адресный доступ к видеопамяти, либо оперирую тремя (четырмя) портами для заполнения видеопамяти.
Ну, если это все равно символный экран, т.е. маленький, можно и портами... Чтобы проводков меньше было.

Соглачен.

Shaos · Post by **Shaos** » 07 Aug 2006 19:02

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

Ну тогда можно и к 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. Кроме того в будущем можно вообще избавиться от "мёртвых зон" тщательно подсчитав тактирование так, чтобы заведомо более медленный центральный проц всегда попадал своими запросами на свободную видеопамять (причём без насильственного торможения центрального проца).