Просмотр полной версии : Помечтаем или вопрос о видеовыходе
Как-то вечером, мысленно сравнил видеовыходы РКшки и Дендика. Если отбросить большую кучу мелочей ;), то в принципе они одинаковы - в обоих компах производится отображение на экран заранее зашитого в ПЗУ знакогенератора. В дендике, однако, есть вариант использования знакогенератора не из ПЗУ, а предзагруженного в ОЗУ, из ПЗУ процессора. Вот и возникает вопрос: а что было бы, если бы знакогенератор РКшки отображался бы на основную память (скажем, на часть неиспользованной)? Ведь в этом случае вполне было бы возможно прямо при исполнении программы предзагружать туда картинки, выполненные в "дендевском" виде (как знакогенератор), тогда бы и играбельность машины была бы выше, и не только буковками рисовать пришлось бы тот же Тетрис или Ралли. Конечно, ВГ75 не знает про спрайты, да и скорострельность машинки мала, и 1К знакогенератора бесстыдно мало..., но всё же...
А может это уже ранее обсуждалось?
А монитор РК переписывать согласны?
Такое уже было: Партнёр 01.01 + модуль МЦПГ
---------- Post added at 00:57 ---------- Previous post was at 00:57 ----------
Правда, там знакогенератор в отдельной памяти был, зато цветной.
Такое уже было: Партнёр 01.01 + модуль МЦПГ
Еще на ПК8000 похоже.
в Микроше ПЗУ знакогенератора - 2к, переключается битом дополнительной ВВ55.
мультиплексировать знакогенератор в доп ОЗУ огромный геморой, как пол компьютера получится.
Rokl, там ничего сложного не будет, кроме предзагрузки "стандартного" ЗГ. Ну раздуется еще на 2К, ничего страшного ;)
b2m, значит уже было, не углядел. Спасибо.
Atari, вот это уже, конечно, ближе к "нормальному" объему.
Про гемор понимаю прекрасно, ибо в 6538 возможностей поболее, нежели в ВГшке, вот поэтому и опустил "кучку мелочей" в первом посте.
Всем спасибо за просвещение!
Можно поставить статическую память вместо ПЗУ, добавить 3 мультиплексора, 1 шинный формирователь.
При этом, можно поставить 4 микросхемы ОЗУ и сделать цветные символы. Тогда будет видео в чем то похожее на NES без спрайтов.
В дендике, однако, есть вариант использования знакогенератора не из ПЗУ, а предзагруженного в ОЗУ, из ПЗУ процессора. Вот и возникает вопрос: а что было бы, если бы знакогенератор РКшки отображался бы на основную память (скажем, на часть неиспользованной)?
В Денди для видеоОЗУ/ПЗУ шло отдельное ПЗУ или ОЗУ. Т.е. это ОЗУ не лежало в поле основной памяти, на сколько я помню.
В Денди для видеоОЗУ/ПЗУ шло отдельное ПЗУ или ОЗУ. Т.е. это ОЗУ не лежало в поле основной памяти, на сколько я помню.
Ага, не лежало.
Копирование данных из ОЗУ процессора в ОЗУ видеопроцессора только через регистры (адрес, данные) и во время обратного хода.
Есть еще третье независимое ОЗУ. ОЗУ спрайтов размером 256 байт. В него данные записываются с помощью контроллера DMA. Заносишь в порт 4014h число 12h, и область 1200h-12FFh основного ОЗУ копируется в память спрайтов.
---------- Post added at 09:28 ---------- Previous post was at 09:18 ----------
Идея кстати очень интересная, можно украсить и придать цвет многим старым играм.
А ещё был Арго ФВ-6511. Там знакогенератор, вроде, в основной памяти. Но по нему очень мало информациии. К тому-же он на Z80 и при определённой настройке портов (в том числе и ВГ75) совместим со спектрумом. Т.е. ВГ75 показывает экран спектрума!
Titus, про отображение на основную память РКшки я упомянул ну как бы из-за возможной "простоты" реализации, ибо, как правильно отметил vinxru, таких няшек, как в 6538, в РКшке нет...
b2m, кассеты ещё не всплыли? :(
Можно поставить статическую память вместо ПЗУ, добавить 3 мультиплексора, 1 шинный формирователь.
При этом, можно поставить 4 микросхемы ОЗУ и сделать цветные символы. Тогда будет видео в чем то похожее на NES без спрайтов.
без ПЗУ все равно не обойтись, т.к. копировать основной знакогенератор при каждом сбросе утомительно, и опять таки жрет память один раз в расширенном мониторе, второй раз в памяти предоставленной микросхеме знакогенератора.
+ как всегда забыты "скрытые расходы" - дополнительная логика-обвязка для функционирования этих 3-х мультиплексоров и шинного формирователя.
Можно к ВВ55-ой припаяться.
+ как всегда забыты "скрытые расходы" - дополнительная логика-обвязка для функционирования этих 3-х мультиплексоров и шинного формирователя.
Да не обойтись там тремя мультиплексорами. минимум десяток и 2 шинных формирователя. Это ж РК-86, а не Орион-128.
Нарисовал бы, да некогда. :)
не обойтись там тремя мультиплексорами. минимум десяток
имелось в виду три корпуса.
VovanRK86
12.04.2013, 13:32
Нарисовал бы, да некогда.
А может хотя бы схематично, а то очень интересная тема, ведь Z80 уже прикрутили к РК.
Вопрос к знатокам, возможно ли в теории такое: ставим ОЗУ РУ10 в придачу к ПЗУ, при начальном старте используем ПЗУ, далее программа включает ОЗУ вместо ПЗУ и программирует ВГ75 на перебор адресов, а через 2 АП16 подключаем ОЗУ к ШД и пишем в неё новый знакогенератор. Или с ВГ75 не прокатит и придётся адреса через мультиплексоры подключать к ША?
Сложно очень.
Адреса перебирает ВТ57. Можно задать ей диапазон из одного байта.
Но при этом мы отключим обновление ОЗУ.
---------- Post added at 12:37 ---------- Previous post was at 12:36 ----------
Я бы хотел вместо ПЗУ подключить очень большую ОЗУ. И что бы символ был не черно-белым, а был 16-цветной картинкой. Можно даже разрешение увеличить.
Получилось бы подобие MSX. Только без спрайтов и со скроллом, который почти никто не использует.
VovanRK86
12.04.2013, 13:56
Адреса перебирает ВТ57
Так входы ПЗУ знакогенератора подключены к ВГ75?
Разве не её надо программировать, меня смущает что младшие адреса это строки
Но при этом мы отключим обновление ОЗУ
В такой гипотетической реализации не страшно, всё равно в таком компе основное ОЗУ будет статика.
И что бы символ был не черно-белым
У меня стандартная доработка для цвета есть, о других вариантах даже мысли не возникают пока.
У меня стандартная доработка для цвета есть, о других вариантах даже мысли не возникают пока.
Я тут описал, как цвет прикрутить.
http://zx-pk.ru/wiki/%D0%94%D0%BE%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D 0%B0_%D1%87%D1%91%D1%80%D0%BD%D0%BE-%D0%B1%D0%B5%D0%BB%D0%BE%D0%B3%D0%BE_%D0%BA%D0%BE% D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%B0_%D 0%90%D0%BF%D0%BE%D0%B3%D0%B5%D0%B9-%D0%91%D0%9A01_%D0%B4%D0%BE_%D1%86%D0%B2%D0%B5%D1% 82%D0%BD%D0%BE%D0%B3%D0%BE_%D0%90%D0%BF%D0%BE%D0%B 3%D0%B5%D0%B9-%D0%91%D0%9A01%D0%A6
---------- Post added at 13:19 ---------- Previous post was at 13:08 ----------
Так входы ПЗУ знакогенератора подключены к ВГ75?
Разве не её надо программировать, меня смущает что младшие адреса это строки
Простых идей у меня пока нет.
1) Либо завести ССИ на порт расширения, что бы компьютер знал какая сейчас строка на экране.
2) Либо поставить мультиплексор на строки. А строки так же завести с порта расширения.
Ещё вариант - номер линии считывать через порт расширения, думаю проц успеет.
Программировать надо будет так:
1. заполняем строки одним байтом, т.е. первая строка байтом 00, вторая 01, и т.д.
2. ждём кадрового СИ
3. ждём нужную линию (от 0 до 7)
4. записываем байт знакогенератора
5. повторяем 8 раз с п.3
6. переходим к следующему символу и повторяем 24 раза п.п. 3-5
За один кадр можно будет задать знакогенератор для 24 символов.
---------- Post added at 16:03 ---------- Previous post was at 16:02 ----------
Или даже 32, если запрограммировать режим 32х78 символов.
---------- Post added at 16:10 ---------- Previous post was at 16:03 ----------
По-моему, будет достаточно вообще только младший бит номера линии контролировать. Хотя, там могут быть особенности, ВГ75 не сразу после окончания КСИ отображение начинает.
По-моему, будет достаточно вообще только младший бит номера линии контролировать. Хотя, там могут быть особенности, ВГ75 не сразу после окончания КСИ отображение начинает.
Или пожертвовать пару мультиплексоров, и просто управлять шиной адреса знакогенератора.
VovanRK86
13.04.2013, 01:38
Или пожертвовать пару мультиплексоров, и просто управлять шиной адреса знакогенератора.
Этот вариант основной, но я думаю можно ли обойтись без мультиплексоров, заставить вг75 перебирать адреса.
Ещё вариант - номер линии считывать через порт расширения, думаю проц успеет.
Порт расширения, это усложнение как и мультиплексоры, а про проц успеет и за один кадр уложится это для меня вообще дебри, я про идею один раз перезалить
знакогенератор, для одной проги, а другая для себя сама зальёт, используя перебор адресов вг75, если это возможно (вг знаю плохо, читать не знаю совсем, поэтому и советуюсь), все что выше это я так понимаю уже спрайты, и можно использовать для игр в динамике меняя знакогенератор, может усложнение того стоит, но кто будет писать проги?, а я хотел бы простыми средствами например заменить пару символов и пользоваться ими пару дней до новой замены. (один из вариантов ПЗУ 8кб и регистр их выбирать, но ОЗУ интересней) Вот и советуюсь, новому РК на z80 может это надо?
Вот и советуюсь, новому РК на z80 может это надо?
Идея очень хорошая. Перезагружаемый знакогенератор - это то, что как раз не хватает 86РК.
VovanRK86
13.04.2013, 01:51
Кстати в компьютере КР04 возможно это реализовано, но схему я так и не нашёл.
используя перебор адресов вг75, если это возможно
Перебор я уже описал выше, надо лишь всю строку одинаковым байтом забивать. Тогда старшие 7 бит адреса знакогенератора будут этим байтом, а младшие 3 бита - номер линии. Вопрос только в синхронизации ВГ75 и процессора (момент записи в знакогенератор).
Конечно, можно и без синхронизации. Просто после кадрового СИ подождать определённое число тактов и между записями в знакогенератор тоже ждать некоторое число тактов, которое подобрать экспериментально. Там проблема лишь в том, что ПДП притормаживает процессор, и подобрать нужные задержки может оказаться сложным.
VovanRK86
13.04.2013, 13:48
Перебор я уже описал выше, надо лишь всю строку одинаковым байтом забивать. Тогда старшие 7 бит адреса знакогенератора будут этим байтомСпасибо, уже кое что.
младшие 3 бита - номер линии
т.е. на них мультиплексор надо, так как управлять ими не сможем, или следить за ними и в зависимости от состояния загонять нужный байт, правильно понял?
т.е. на них мультиплексор надо, так как управлять ими не сможем, или следить за ними и в зависимости от состояния загонять нужный байт, правильно понял?
ага
Я думаю, что рассчитать время, когда рисуется очередная строка будет сложно. ВГ75 загружает в себя данные рывками, по 78 байт перед рисованием каждой строки символов (10 графических строк).
И вот тут надо смотреть, насколько загружен процессор. Может быть, что процессор стоит каждые 2 графических строки, пока ВГ75 грузит данные. То есть в это время обратится к ВГ75 не получится.
т.е. на них мультиплексор надо, так как управлять ими не сможем, или следить за ними и в зависимости от состояния загонять нужный байт, правильно понял?
Мне кажется, не надо мультиплексор. ВГ75 и так будет их подряд перебирать. Главное вовремя байт записать.
ВГ75 загружает в себя данные рывками, по 78 байт перед рисованием каждой строки символов (10 графических строк).
Это тоже настраивается. Возможны пакеты по 1,2,4,8 байт. Между пакетами задержка конфигурируется по 0,7,15,...,55 тактов (время отображения одного знакоместа на экране).
Вопрос новичка :v2_dizzy_coder: почему на ЭЛТ телевизоре изображение РК-86 нормальное, а на LED оно сдвинуто влево?
...Вопрос к знатокам, возможно ли в теории такое: ставим ОЗУ РУ10 в придачу к ПЗУ, при начальном старте используем ПЗУ, далее программа включает ОЗУ вместо ПЗУ и программирует ВГ75 на перебор адресов, а через 2 АП16 подключаем ОЗУ к ШД и пишем в неё новый знакогенератор. Или с ВГ75 не прокатит и придётся адреса через мультиплексоры подключать к ША?
Старая тема, но интересная. Я даже схему себе частично прорисовывал. Но получалось очень грамоздко. Возможен графический режим в РК при переводе его на VGA в DOS mode, но для этого нужны мультиплексоры хитрые 2х2 на каждый вход ОЗУ(я их на PLD 22V10 синтезировал, а в рассыпухе вообще огромное количество корпусов получается), пара обычных мультиплексоров на выходы ОЗУ и 245 шинный формирователь и ещё по мелочи не мало и 2 ОЗУ. Почему 2 ОЗУ? Потому, что бы проц успевал отрисовывать кадр в одной ОЗУ, когда выводится на экран кадр из другой ОЗУ. Потом ОЗУ меняются местами. Вместо ПЗУ сделать как в Орионе загружаемый стандартный знакогенератор. Размер графического ОЗУ зависит от разрешения графики и размера ОЗУ самого РК. С 32к вопрос вообще отпадает, т.к. графика по пикселям становится аналогичной псевдографике ПЗУ да и саму программу графическую где то хранить нужно. Опять же быстродействие проца под большим вопросом.
А подгружаемый знакогенератор на РУ10 смысла не имеет. Что нужно такого в ЗГ, чего нет в ПЗУшном? строчные буквы? Новые шрифты? Вы что, печатать на РК будете? А для расширения псевдографических символов остается совсем мало места буквально десяток байт, всё зависит от того, чем вы готовы пожертвовать в стандартном знакогенераторе...
---------- Post added at 23:51 ---------- Previous post was at 23:47 ----------
Вопрос новичка :v2_dizzy_coder: почему на ЭЛТ телевизоре изображение РК-86 нормальное, а на LED оно сдвинуто влево?Это зависит от заводской настройки видеопроца телевизора. Один проц не видя строчногасящие импульсы, которых нет в РК, рисует картинку сразу (типа, что вижу то вывожу), а другой видеопроц, видя, что строчногасящие импульсы отсутствуют, сам синтезирует их, и центрует изображение на экране.
Старая тема, но интересная. Опять же быстродействие проца под большим вопросом.
А на какую частоту можно разогнать 8080? если охладить
VovanRK86
04.12.2013, 23:32
А подгружаемый знакогенератор на РУ10 смысла не имеет.
Почему? Мне бы хватило.
Вы что, печатать на РК будете?
Конечно нет! Хотя я нашёл LX100 и буду подключать
А для расширения псевдографических символов остается совсем мало места буквально десяток байт
Вот они мне и нужны! Заменить их (оперативно перед загрузкой оболочки se) на псевдографику от IBM (я их когда то даже в ЗГ записал) и получить в se.com привычную картинку от vc.com:), ну с ограничением по в количестве символов по горизонтали конечно.
Ну и сделать было бы в железе интересно, но только что бы попроще, а графика мне не нужна т.к. писать проги под неё я не смогу точно, с тем что есть разобраться бы.
Ну и сделать было бы в железе интересно, но только что бы попроще,
Попроще нужно пользовать Р6845. Он умеет сам перебирать адреса. Соответственно ИК57 можно из схемы убрать. Но всеравно схема получается очень не простая:
http://s020.radikal.ru/i719/1312/67/b1904abd65ef.png
VovanRK86
07.12.2013, 22:30
А по подробнее? Интересно ведь! Особенно схема!
Яндекс на запрос Р6845 такое выдаёт:)
Яндекс на запрос Р6845 такое выдаёт
Искать нужно MC6845 - Мотороловский контроллер ЭЛТ www.reenigne.org/crtc/mc6845.pdf
Пример использования - http://retro.hansotten.nl/uploads/eljunior/ukvducard.pdf статья из журнала Elektor за сентябрь 1983.
Искать нужно MC6845
http://zx-pk.ru/showthread.php?t=7218
А по подробнее? Интересно ведь! Особенно схема!
Яндекс на запрос Р6845 такое выдаёт:)
Да, конечно МС6845, тут я маху дал.
Схема достаточно сырая и до ума я её не довел. На макетке собрал, но оживать не захотела (нужно хитро программировать полтора десятка регистров МС6845 и хитро подключать его к шинам процессора). Суть схемы - симбиоз даташита МС6845 и схемы микрокома. У меня схема получается сложной на PLD-мультиплексорах и компик получается программно несовместимым с РК. И самое обидное, для VGA режима нужен был кристалл МС6845, который работал на тактовой частоте 3 мгц(абсолютно недоставаемый). А стандартные кристаллы МС6845 работают на тактовой частоте 1 Мгц(CGA,EGA).((( На ВГ75 схема получается по сложности похожая, можно получить графический VGA режим и нет проблемы 3х мегагерц.
А по подробнее? Интересно ведь! Особенно схема!
Может она:v2_conf3:
http://www.swtpc.com/mholley/DS68/DS68_2a.jpg
http://www.swtpc.com/mholley/DS68/DS68_3a.jpg
---------- Post added at 23:51 ---------- Previous post was at 23:47 ----------
Это зависит от заводской настройки видеопроца телевизора. Один проц не видя строчногасящие импульсы, которых нет в РК, рисует картинку сразу (типа, что вижу то вывожу), а другой видеопроц, видя, что строчногасящие импульсы отсутствуют, сам синтезирует их, и центрует изображение на экране.
Ты был прав! все зависит от LED-TV, тогда смысла не вижу пытаться подключать РК-86 к VGA монитору
HardWareMan
13.12.2013, 18:33
Забавно, но именно SUPRA (24" FullHD) у меня тоже показывает Специалист просто идеально!
http://savepic.su/2539223m.jpg (http://savepic.su/2539223.jpg)http://savepic.su/2552535m.jpg (http://savepic.su/2552535.jpg)
Изображение просто радует, особенно пропорции.
ну что ж, и я отмечусь) http://savepic.su/4157677.jpg
Supra как бы создана для этих целей =)
Сделал теневой знакогенератор на ОЗУ. Мапится в область с F800 размером в 2к. Переделок МОНИТОРа НЕ ТРЕБУЕТСЯ, схему меняется точно так же как и при подключении FDD, т.е. + ИД7 (если уже подключен, то и переделывать ничего не надо). Переключается тумблером.
В знакогенератор можно грузить не только шрифты, но и спрайты (для примера поменял несколько символов для игры Клад - почти графика!)
В архиве дана схема, программа copy (размещается и запускается с адреса 800, с 0 по 7FF должен быть загружен шрифт или спрайты), игра "Клад" и шрифт для нее (загружаем шрифт с 0 по 7FF, программу copy с 800 и запускаем G800, грузим игру "Клад" и запускаем, переключаем тумблер на доп. ОЗУ)
На фото:
1. Оригинальный вид игры "Клад"
2. С "теневыми" шрифтами
3. Шрифт 8х14
4. Шрифт 6х8
оп. ОЗУ)
На фото:
1. Оригинальный вид игры "Клад"
2. С "теневыми" шрифтами
3. Шрифт 8х14
4. Шрифт 6х8
Шрифт №3 8х14 очень похож на 8х8...на примере нет ни одного символа длинее 8 строк, или шире 8 пикселей.
И не понятно, как программно недоступное ПЗУ знакогенератора мапится на адреса монитора?
Нам бы схемку, аль чертеж...
Шрифт №3 8х14 очень похож на 8х8...
Это шрифт 8х14, я давал его в теме РК на новый лад http://zx.pk.ru/showpost.php?p=709049&postcount=352 Кстати там и редактор шрифтов, при помощи которого делал изменения для игры Клад...
Нам бы схемку, аль чертеж...
Схема есть в аттаче.
И не понятно, как программно недоступное ПЗУ знакогенератора мапится на адреса монитора?
Мапинг происходит так же как и, например, ВТ57 мапится на ПЗУ монитора - читает Монитор, а пишет - в ПДП. Все простанство, отведенное в оригинале под Монитор, делится на 4 части как в схеме подключения дисковода, почему я и написал, что если есть дисковод, то практически ничего в схеме менять не нужно, иначе - порезать пару дорожек. В такой конфигурации Монитор выбирается с адреса F800 на чтение, а вот на запись - мапится теневое ОЗУ, т.к. контроллер ПДП "переезжает" на родной адрес Е000.
Несколько замечаний по схеме:
1. Схема дана для варианта РК с ПЗУ фонтов 2К и линейной адресацией. Для стандартного РК нужно из схемы исключить сигнал LC3 и сместить сигналы CC0-CC6 на разъеме JP1 "FONT" на выв.4-10, 11 - подать землю, на JP3 "ADDR" на выв 11 - подать землю.
2. Сигнал /CE_FONT с разъема JP4 "DO" подается на выв. /OE DD12 РК (предварительно отрезав от земли).
3. Микросхема IC3, сигнал /CS_DMA , /CS_DMA* /CS_ROM* - подключаются в соответсвии со схемой подключения дисковода. Если это уже есть, то IC3 из схемы можно исключить, а сигналы взять из контроллера дисковода.
4. На разъем JP2 "ROM/RAM" подключается переключатель. В положении 1-2 выбирается ПЗУ знакогенератора, 2-3 - теневое ОЗУ.
5. На JP7 "DI" подаются сигналы с шины данных РК.
6. Сигналы с 1 по 8 JP4 "DO" подаются на выв. D0-D7 DD12 РК.
Плату пока не даю, т.к. сделана по первоначальной схеме, а текущая схема изменена. Постараюсь завтра-послезавтра развести плату и тогда выложу.
Все простанство, отведенное в оригинале под Монитор, делится на 4 части как в схеме подключения дисковода, почему я и написал, что если есть дисковод, то практически ничего в схеме менять не нужно, иначе - порезать пару дорожек. В такой конфигурации Монитор выбирается с адреса F800 на чтение, а вот на запись - мапится теневое ОЗУ, т.к. контроллер ПДП "переезжает" на родной адрес Е000.
Секунду...что то я не понимаю, в РК ПЗУ знакогенератора пользуется только ВГ75 и всё. Это ни с чем не связаный кусок схемы кроме ВГ75-ПЗУ ЗГ.
Как, не перелопачивая всю схему РК, можно сремапить ПЗУ ЗГ на адресное пространство процессора и при том исключить конфликты обращения ВГ75 к ОЗУ? да ещё при условии чтения/записи ОЗУ(Псевдо ПЗУ ЗГ) для ВГ75???
Что тоя не вкурю этот тонкий момент. Ведь схема РК принципиально не предполагает отражение адресного пространства ЗГ на адреса Процессора.
Да, можно переназначит адреса видео ОЗУ, перепрограммируя ВТ57, но байты, что там будут записаны всеравно отразятся через ВГ75 и ПЗУ знакогенератора??? Ну сделаете вы теревой ЗГ...без проблем, а как ОЗУ в ЗГ отразить с изменяемыми символами...не понимаю????
VovanRK86
29.05.2014, 02:16
что то я не понимаю
И я... что то не понимаю, но может конечно догадываюсь (схему смотрел).... Вы что решили мою проблему о замене шрифта простыми средствами... ру10 вместо(вмести) рф2/5 и пара мультиплексоров на её загрузку... НО ВСЁ ЖЕ КАК!!!
подробности в студию!
---------- Post added at 01:50 ---------- Previous post was at 01:46 ----------
2. С "теневыми" шрифтами
ВесчЪ!!!! именно моя мечта, но не в играх, а SE.COM псевдографикой Нортона наделить!!!
---------- Post added at 01:55 ---------- Previous post was at 01:50 ----------
и линейной адресацией
???
---------- Post added at 01:56 ---------- Previous post was at 01:55 ----------
а вот на запись - мапится теневое ОЗУ, т.к. контроллер ПДП "переезжает" на родной адрес Е000.
???
---------- Post added at 02:00 ---------- Previous post was at 01:56 ----------
Я вроде даже понял ВСЮ КРУТЬ! реализации, НО... очень хочется разжёванного ответа!
---------- Post added at 02:16 ---------- Previous post was at 02:00 ----------
Я всё же вроде догнал под звуки соловья, это Именно схема подмены ПЗУ РФ2 (ЗГ) на ОЗУ РУ10 Программно загружаемую НОВЫМ ЗГ, ВСЕГО! посредством нескольких мультиплексоров и регистров. Я об этом и мечтал и спрашивал и даже сам сделать хотел, но...
СПАСИБО!!! ОТДЕЛЬНОЕ ОГРОМНОЕ!
Попытаюсь объяснить принцип работы.
Режим записи в РУ10 (активно ПЗУ знакогенератора), 0 на входе 2 JP2 "ROM/RAM":
Через IC1, IC2, IC4 (мультиплексоры 2в1 х4, они же КП11) вход А подается шина адреса, которая идет на адреса РУ10 и сигнал выбора /CS_ROM* (формируется на IC3, она же ИД7, установить если ее нет, см. Радио 2/1993 стр.19), который выбирает РУ10 при обращении к Монитору или к ней, при этом если активен /RD - читаем Монитор, /WR - пишем в РУ10. Активен буфер IC6, т.е. шина данных подается на входы данных РУ10. Буфер IC7 находится в высокоомном состоянии. Сигнал /WR через диод D1 (схема ИЛИ на элементах D1+D2+R3) поступает на соответствующий вход РУ10. В таком режиме РУ10 мапится в ОБЩЕЕ адресное пространство процессора на запись по адресу F800.
Режим чтения РУ10 (активно теневое ОЗУ знакогенератора), 1 на входе 2 JP2 "ROM/RAM":
При переключении режима, 1 подается на вход 2 триггера IC5 и записывется по кадровому импульсу. Этот сигнал переключает мультиплексоры IC1, IC2, IC4 на вход В, через который поступают сигналы LC3-LC0 и CC6-CC0 с ВГ75 на адреса РУ10 и сигнал VSP. Буфер IC6 переходит в высокоомное состояние, а буфер IC7 подключает шину данных РУ10 ко входам сдвигового регистра ИР13. Сигнал /WR блокируется 1 через диод D2 (схема ИЛИ на элементах D1+D2+R3). Сигнал /CE_FONT блокирует работу ПЗУ знакогенератора. В таком режиме РУ10 не доступна процессору и полностью управляется ВГ75.
Вот как-то так.
Еще раз напомню, если есть уже установленная ИД7 для контроллера дисковода (для /CS_DMA* и /CS_ROM*), то в схеме РК нужно сделать ОДИН надрез - отрезать сигнал /OE ПЗУ знакогенератора от земли и подать на него сигнал /CE_FONT. Все остальные сигналы просто берутся с платы!
Эту схему можна использовать не только для РК, но и для всех подобных, например, Микро-80, ЮТ-88, ну и клоны РК...
Для VovanRK86
"Линейная адресация" - в данном случае это для режима VGA сигналы с ВГ75 LC0-LC3 идут A0-A3, а CC0-CC6 -на A4-A10. В схеме от Rokl сигнал LC3 идет на A10. При таком подключении неудобно располагать шрифты в ПЗУ, надо перетасовывать прошивку. Поэтому я переделал схему на "линейную адресацию" и изменил прошивку знакогенератора на более удобную для редактирования (все байты символа располагаются по порядку, линейно). Один минус в таком подключении - даже для стандартного ТВ режима 6х8 прошивка все равно занимает 2к, т.к. на каждый символ отводится по 16 байт(первые 8 используются, остальные 8 - FF).
Немного измененная схема (для удобства разводки) и плата (в зеркальном виде, для ЛУТ). Плата разведена немного коряво - правил предыдущую версию, лень переразводить полностью.
На фото предыдущая версия платы, все изменения на другой стороне навесным монтажом (забыл сделать фото).
Для любителей класики замена:
74AC138 - ИД7 (155 и т.п.)
74AC257 - КП11 (155 и т.п.)
74LS244 - АП5 (лучше побыстрее, например, 1533 и т.п.)
74AC74 - ТМ2 (155 и т.п.)
диоды КД522
VovanRK86
29.05.2014, 16:14
Класс! Как раз то что мне нужно, а джампер РОМ/РАМ на порт заменить, он у меня уже есть 0FFh, первые три бита страничное ОЗУ, четвертый Турбо режим, пятый значит будет выбирать ЗГ! как раз свободен.
---------- Post added at 16:14 ---------- Previous post was at 16:09 ----------
У меня была мысль использовать ВГ75 для перебора адресов РАМ, для записи ЗГ в неё, что бы обойтись без КП11 и адресную шину не тянуть.
Схема есть в аттаче.
Носом ткни конкретно, что то не увидал.
Носом ткни конкретно
Схема была в архиве
http://zx.pk.ru/showpost.php?p=713206&postcount=44
Здесь исправленная и с платой
http://zx.pk.ru/showpost.php?p=713506&postcount=50
---------- Post added at 09:37 ---------- Previous post was at 09:13 ----------
Как раз то что мне нужно, а джампер РОМ/РАМ на порт заменить
Я бы оставил еще возможность переключать тумблером, а то в случае сбоя или выхода из строя РУ10 прийдется в слепую переключать знакогенератор, ну или ресет...
У меня была мысль использовать ВГ75 для перебора адресов
Аппаратно попроще будет (нужно только ВГ75 такировать вручную для перебора адресов LCxx), но программно сложнее.
Сделал теневой знакогенератор на ОЗУ.
В знакогенератор можно грузить не только шрифты, но и спрайты
Понравилась фишка: теневой знакогенератор.
а как загружать если нет FDD? с магнитофона?
У меня тоже нет ФДД, гружу при помощи эмулятора РОМ-диска http://zx-pk.ru/showthread.php?t=22821
Чтоб я не запутался, можно задам еще большой вопрос?
По порядку.
У вас: - плата РК-86
- плата теневого знакогенератора
- плата эмулятора РОМ-диска
Вы редактируете знакогенератор РК-86 на РС с помощью вашего редактора. Создаете файл font.bin, затем с помощью эмулятора РОМ-диска загружаете его в РУ10 теневого знакогенератора. Переключаете тумблер и ваш РК-86 работает уже с созданным знакогенератором?
Всё точно так, только гружу не сразу в РУ10, а в память командой U - с адреса 800 загружаю загрущик, а с 0 по 7FF должен быть загружен шрифт или спрайты, затем запускаю загрузщик, он копирует фонт в РУ10. Можно попробовать грузить сразу в РУ10 или скопировать фонт командой "Т", но я не сделал так для того чтобы избежать возможных конфликтов ПЗУ и РУ10 (при работе подпрограмм "U" и "T"). Вообще-то была задумка это все делать автоматически, объеденив загрузщик, фонт и программу/игрушку...
Хочу в журнальный вариант Радио-86рк (32к) внедрить схему VGA от Микроком-85. Т.к. я ни разу не программист, прошу "помощь зала" :)
Какие ячейки в журнальном мониторе-32к мне нужно будет изменить, касательно настроек ВТ57 и ВГ75?
Фрагмент схемы от Микрокома, которую хочу перенести в журнальный вариант РК:
Смотрите, начиная с 33 страницы http://zx-pk.ru/showthread.php?t=19685
Конкретней
http://zx-pk.ru/showpost.php?p=709049&postcount=352
http://zx-pk.ru/showpost.php?p=712884&postcount=354
http://zx-pk.ru/showpost.php?p=712917&postcount=355
начиная с 33 страницы
Как можно получить 80 видимых символов \ 30 видимых строк? Что-то изменить в настройках ВГ75 или придется заново пересчитывать тайминги синхронизации?
Что-то изменить в настройках ВГ75 или придется заново пересчитывать тайминги синхронизации?
Нужно пересчитать тайминги и изменить настройки. Но вопрос другой - совместимость с оригинальным Радио-86РК!
Понятно. Вопрос о 80 символов в строке исчерпан, т.к. совместимость с оригинальным РК важнее.
Еще такой момент, контроллер ПДП тактируется от генератора процессора. Если будет тактироваться от тактовой ВГ75, страшного ничего не случится?
Вообще-то была задумка это все делать автоматически, объединив загрузчик, фонт и программу/игрушку...
Увидев и вникнув в твою разработку - сразу пришел к такому-же выводу, нужно адаптировать игрушки и программы под теневое ОЗУ, загрузил, запустил и все! Только переключалку ЗГ тоже к порту или еще чему привязать, чтобы все само делалось.
Только переключалку ЗГ тоже к порту или еще чему привязать, чтобы все само делалось.
VovanRK86 хотел подцепить переключатель на порт FF:
Класс! Как раз то что мне нужно, а джампер РОМ/РАМ на порт заменить, он у меня уже есть 0FFh, первые три бита страничное
ОЗУ, четвертый Турбо режим, пятый значит будет выбирать ЗГ! как раз свободен.
Можно стандартизировать, но вместо обычного регистра лучше поставить или триггер или регистр с общим сбросом + отдельная кнопка сброса, что бы можно, не сбрасывая весь комп, вернуться к стандартным настройкам. Только вот вопрос - нужно ли кому-то это, а то тема как-то угасла и у меня такое ощущение, что теневой знакогенератор есть только у меня... :)
Можно стандартизировать, но вместо обычного регистра лучше поставить или триггер или регистр с общим сбросом + отдельная кнопка сброса, что бы можно, не сбрасывая весь комп, вернуться к стандартным настройкам. Только вот вопрос - нужно ли кому-то это
Не сомневайся - нужно!
И стандартизировать нужно, к примеру на основе СРАМ версии РК.
to Alex_LG
Ваша разработка потрясающа, наверное буду делать нечто подобное. Есть мысль повторить Ваше устройство 3 или четыре
раза, тогда тайлы (спрайты) можно заливать цветные!
- - - Добавлено - - -
UPD: to Alex_LG
Определился, начну с полного копирования Вашей разработки, потом буду прикручивать цвет.
В свете последних обсуждений в разделе РК тоже возникала идея сделать ещё два "слоя" памяти что даст цвет а системе RGB, что будет по аналогии с РС, и даст возможность делать цветные спрайты. Пока это только идея, но реализация очень проста - добавить порт на выбор "слоя" и пару РУ10 с регистрами сдвига. На данный момент занят другим, поэтому, если есть желание сделать подобное, могу только потдержать морально ;)
UPD:
Сегодня много думал над темой. Итак, если кому-то интересно, излагаю, что придумал.
Во первых если выкинуть сдвиговый регистр на выходе ОЗУ, но вместо этого перебирать адресные входы, а память увеличить в четыре раза, то мы решаем проблему цвета на одной микросхеме ОЗУ.
Итак, берем 8К SRAM, это 13 адресных линий, и 8 линий данных.
4 адресных линии отдаем под строки (LC0-LC3), 7 отдаем под код символа (CC0-CC6), остаются 2...
Эти две мы подключаем к счетчику, который подключен к тактовому генератору пикселей (ЕМНИП 8 МГц), еще одну
линию этого счетчика подаем на счетверенный мультиплексор 2x4, который выбирает либо (D0-D3), либо (D4-D7), и они
подаются на выход, это и есть RGBI 16 цветов.
Во вторых Всем этим нужно управлять, для чего я предлагаю поставить регистр с параллельным заносом, и подключить
к дешифратору адреса (в адрес FFFF), если мы туда пишем байт, то он записывается в регистр.
Линия 0 этого регистра будет отвечать за отображение, если там записан 0, то мультиплексор перекидывает видеовыход
на классический выход с ПЗУ, и работает родной знакогенератор, если записана единица, то мультиплексор переключается на нашу систему и отображается загруженный, цветной знакогенератор.
Еще 2 линии управляющего регистра выбирают страницу, в ОЗУ знакогенератора, ведь "теневая" область имеет размер
2К, а цветной знакогенератор 8К, следовательно 2 бита выбирают одну из 4 страниц.
Порядок действий такой: По сбросу управляющий регистр обнуляется, и так-как нулевой бит оказывается сброшен, то ПЭВМ запускается в классическом виде, тогда модифицированная игра (имеющая загрузчик тайлов + сами тайлы), загружает знакогенератор, а потом переключает бит 0 в регистре управления, и система переходит в цветной режим.
Дальше загрузчик передает управление игре.
Пока так.
В ближайшее время нарисую и выложу блок схему.
- - - Добавлено - - -
Сделал набросок схемы на одном ОЗУ. Сначала буду пробовать на макетке с МГТФом, когда отлажу, буду править схему и наконец разводить плату.
Материал повышенной сложности
Ниже излагается идея по настоящему графического РК86. Идея не сразу воспринимается, а некоторые некомпетентные читатели, увы, так и не смогут понять. За повреждение мозга вследствие чрезмерного умственно напряжения у лиц с пониженными или средними умственными способностями администация сайта и участники форума ответственности не несут.
Эту идею придумал и первым реализовал freddy в своём VGA-адаптере на базе ВГ75. Я лишь озвучиваю эту идею применительно к РК86.
При описании данной схемы есть сложности с терминологией, т.к используется двухступенчатая адресация. Строкой ниже называется строка ВГ75, а фонт-строкой называется буфер размером в 64*High в загружаемом ОЗУ фонтов, где High высота строки ВГ75 в линиях растра. Фонт-строка содержит 64 графических блока (или символа для ВГ75) размером High*8.
Идея заключается в том, что загружаемый фонт включается в адресное пространство CPU. Видео-схема РК используется для того, чтобы в каждой строке последовательно выдавать на экран символы с кодом от 0 до 63. В следующей строке аппаратно включается следующий фонт и также выводятся символы с кодами от 0 до 63. Каждая строка выводится своим фонтом. Таким образом каждый фонт становится буфером соответствующей строки (отсюда вводим термин фонт-строка). В итоге на экране выводятся 30 строк, в каждой строке выводится свой фонт, т.е графическое содержимое фонт-строки. Меняя то, что загружено в фонт-строку, мы программно меняем графическое содержимое строки.
В итоге, РК86 становится графическим компьютером с разрешением в 64*8=512 точек по горизонтали. Разрешение по вертикали меняется программно. Даже на TV видимы не менее 256 линий растра. Т.о имеем графический экран 512*256 занимающий 16 кб ОЗУ. С помошью фонт-строки в 64 символа содержашей нули формируются бордюрные строки по кадрам (пустые строки сверху и снизу видимого растра). В режиме строк высотой в 8 линий, ВГ75 программируется на вывод 38-ми строк, плюс строка на обратный ход кадровой развёртки. Общее число линий растра точно равно стандарту 39*8= 312, что сохраняет частоту кадров в: 1:(39*64*8)= 50 ГЦ.
Добавив 2 кб ОЗУ для цвета, получаем полноценный цвет на знакоместо 8*8, что лучше для быстродействия, т.к здесь вывод происходит графическим образом. Для вывода одного символа надо записать уже не один байт, а минимум, 8 байтов. Экран организован нелинейно по горизонтали. 8 байтов - графика первого знакоместа ВГ75, затем 8 байтов - графика знакоместа ВГ75 расположенного справа. Под знакоместом здесь понимаются не знакоместо видимого шрифта, а знакоместо с которым имеет дело ВГ75. Реальный шрифт видимый на экране формируется программно и может быть любого размера - ширина и высота шрифта может быть любыми. Но только шрифт шириной в байт выводится быстро.
Итак, берём схему загрузки фонта от Alex_LG, но вместо 537РУ10 ставим 62256 и включаем её в адресах A000...BFFF. На старшие адреса этой 62256 (A10, A11, A12, A13) заводим 4 атрибутных сигнала ВГ75. Высота "символа", "строки" и знакоместа ВГ75 - 8 (но изменив режим ВГ75, это легко изменить). В 62256 64 фонтов в 0.5 кб, в каждом из которых 64 загружаемых символов 8*8 (символы 65-127 не нужны). Для получения полноценной графики, достаточно выводить эти фонты в каждую строку (свой фонт в каждую строку). Для этого в позицию 0 каждой строки заносится атрибутная команда 10xx.xxxx, которая включает фонт соответствующий 4-х битовому коду строки. Каждая строка заполняется инкрементируемыми кодами 0,1,2,3...63, что приводит к последовательному выводу в каждой строке 64-х символов текущего фонта. В каждой следующей строке отображается содержимое очередного фонта.
Тем самым ОЗУ для загрузки фонта превращается в экранное ОЗУ, а основное ОЗУ РК86 становится просто коммутатором, позволяющим на выходах ВГ75 появляться инкрементированным в каждом знакоместе кодам от 0 до 63, которые и адресуют экранное графическое ОЗУ.
Таким образом, полноценная графика достигается в схеме Alex_LG лишь за счёт замены ОЗУ 537РУ10 на 62256. Для работы схемы достаточно 30 загружаемых фонтов 8*8 по 64 символа в каждом. Так как 4 атрибута позволяют выбрать адреса в ОЗУ только для 16-ти строк, то ставится триггер, который сбрасывается по КСИ, а устанавливается по атрибуту 1111, т.е после 15-й строки. В момент когда после атрибута 1111 устанавливается атрибут 0001. Тогда в начале 16-й строки будут адреса с атрибутных сигналов 0001 и 1 старший адрес с триггера. Тем самым, можно иметь до 32-х РАЗНЫХ строк. Но всего число строк ВГ75 может быть любым. Атрибут 0000 соответствует пустой строке, с помощью которой формируется бордюр по кадрам.
С формированием ССИ в данной конструкции иначе, чем в базовом РК86. А именно, ССИ и сигнал гашения по кадрам формируются аппаратно. ССИ формируется из HRTC с помощью АГ3 (можно и с помошью 1533 ТМ2). Аппаратное формирование ССИ необходимо потому что шаг по строкам д.быть степенью 2-х. Т.е годится или шаг в 64 или в 128. Шаг 128 по многим причинам невыгоден (напр, тормозит вдвое), потому используется шаг 64. Из-за чего уже нельзя применить "трюк программного гашения по строкам", отчего приходится использовать ВГ75 правильно, а не извращённо.
В такой схеме цвет можно вводить только за счёт параллельной банки ОЗУ цвета, т.к атрибуты заняты для переключения "фонтов" по строкам. Т.к строка переносится просто записью в её начало атрибута, можно делать мгновенный аппаратный ролик вверх-вниз.
Но, если вышеописанную схему дополнить счётчиком по ССИ, реализующим автоинкремент "фонтов-строк" после вывода каждой строки, то все 4 атрибута ВГ75 освобождаются от задачи коммутации фонтов-строк и используются для управления цветом. РК86 превращается в графический компьютер с цветом за счёт атрибутов.
За счёт доработки в 10 микросхем, РК превращается в графический цветной компьютер. В таком режиме в качестве экранного ОЗУ можно использовать экранное ПЗУ размером в 38*64=2432 байт, содержащее 38 повторяющиеся строк, состоящих из инкрементируемых кодов X, 1, 2, 3 ... 63, где вместо X код атрибута выдающий номер каждой фонт-строки. Это ПЗУ может стоять на E000...EFFF, что освобождает все 32К для программ.
Вот эта идея - оригинальная и привлекательна. Она даёт схеме от Alex_LG совершенно иное качество - не спрайтовую графику и загрузку красивых фонтов, а полноценную графику. Графическое ОЗУ (ОЗУ фонтов-строк) размером в 16 кб можно включить в адресах A000...BFFF в виде двух страниц по 8К.
Проблема в том, что спаять проводками такую конструкцию сможет лишь человек умеющий паять конструкции на слепыше. А таких очень мало, основная масса владельцев РК менее трудолюбива и в состоянии только запаять детали в готовую плату.
Если кому-то интересно, излагаю, что придумал
Интересно, интересно. Но жаль, что Вы не указали цель данной доработки. Актуальна задача оцвечивания и ографи-чивания антикварных монохромных игр РК86, причём ценой в минимальное число деталей и труда. Но Вас возможно интересует какая-то другая задача. Например, просмотр 16-ти цветных картинок полученных конверсией фотографий в 16-ти цветные BMP-файлы. Или задача иметь красивый цветной фонт для текстообработки. Но для этого есть лучшее решение - полноценно графический РК86, что получается из платки Alex_LG, если заменить в ней ПЗУ на 62256 и грамотно программировать (см.выше)
Во-первых если выкинуть сдвиговый регистр на выходе ОЗУ, но вместо этого перебирать адресные входы, а память увеличить в четыре раза, то мы решаем проблему цвета на одной микросхеме ОЗУ. Итак, берем 8К SRAM, это 13 адресных линий, и 8 линий данных. 4 адресных линии отдаем под строки (LC0-LC3), 7 отдаем под код символа (CC0-CC6), остаются 2... Эти две мы подключаем к счетчику, который подключен к тактовому генератору пикселей 8 МГц, еще одну линию этого счетчика подаем на счетверенный мультиплексор 2x4, который выбирает либо (D0-D3), либо (D4-D7), и они подаются на выход, это и есть RGBI 16 цветов.
Не лучшим образом излагаете материал. Было бы неплохо сначала выразить идею, тогда последующий текст был бы понятен уже после первого прочтения. А Ваша идея, если я верно понял, заключается в том, что для КАЖДОГО пикселя по горизонтали, которых по-прежнему 384 в строке, считывается свой байт из ОЗУ цвета адресуемого кодом символа из основного экранного ОЗУ.
Есть поправка. Вы указали, что только 2 адреса остаётся для "адресации" в пределах 8 битов байта графики. Это значит, что цвет задаётся сразу на два бита. Чтобы адресовать 8 битов надо 3 адреса. Однако и 3-й бит в такой схеме есть. Незачем заводить LC3, т.к используется режим с высотой знакоместа в 8 линий растра, где LC3 всегда 0. Таким образом: 3 линии адресов на LC0, LC1, LC2, 7 битов - код символа, и 3 бита остаётся для адресации пикселей в знакоместе по горизонтали. Объём памяти при этом увеличится не в 4, а 8 раз.
Однако трудно реально реализовать схему с таким быстродействием. Такт сдвига точек составляет 8 МГЦ, что соответствует периоду в 125 НСЕК. Из 10-ти 62256, что я имел в начале 90-х, только одна тянула в ЭВМ с тактом 8 МГЦ, основная масса тянула только 5 МГЦ (несмотря на паспортное быстродействие в 100 ns). В такой схеме разумно применять High Speed 10-15-ти наносекундные CMOS RAM.
Несмотря на то, что объём такого ОЗУ цвета в 8 раз больше объёма фонта в 1 кб, это не скажется на быстродействии игр. Т.к ОЗУ цвета загружается только один раз в начале игры, и никого не волнует если это будет длиться целых полсекунды.
Возможность раскрашивать символы с разрешением каждый пиксель любого цвета, - абсолютно бесполезна без ОЗУ спрайтов, т.е без исходной схемы от Alex_LG. Зачем раскрашивать во все цвета радуги буквы КОИ-7 из основного фонта РК86? То есть частично параллельно ОЗУ цвета должно быть включено ОЗУ фонта-графики, с объёмом в 1 кб, содержащее спрайты, например на двух 6514 (с организацией 1К на 4, это КМОП аналог 541РУ2).
Если организовать дешёвый выпуск плат под именем МЦПГ-РК86, это даст возможность для РК86 делать игры с качеством графики лучше чем в Денди, не говоря уж о ZX-Spectrum. Однако более-менее массовой может стать только очень простая конструкция (в идеале реализуемая за 2 часа работы паяльником на основной плате РК). Сложная cкоростная конструкция работающая на пределе возможностей обычных TTL (нужны скоростные) не привлечёт массы. Смотрите, разве конструкцию Alex_LG повторили многие? И организовать выпуск плат тоже не получилось. Ваша сложная конструкция не найдёт поклонников и заказчиков на платы, даже если Вы одновременно предложите все игры РК оцвеченные с высоким разрешением. Нужна максимально простая платка, дающая только те возможности, которые реально востребованы.
Схема загрузки фонтов от Alex_LG, дополненная 8К ОЗУ цвета, позволяет заимствовать спрайты от любых компьютеров, без ограничений на цветовое разрешение.
Высокое цветовое разрешение для игр не требуется. Даже в Денди огранились лишь 2-мя цветами в пределах 8-ми экранных битов. А т.к графику спрайтов всё-равно придётся брать от Синклера или из машин, где в лучшем случае цвет CGA, то разумно схему упростить. Можно сократить в 4 раза скорость доступа к цветовому ОЗУ до всего 2-х раз за время вывода знакоместа. Тогда имеем 8 битов на 4 пикселя. Можно использовать идею CGA - 2 бита на пиксель, отчего по-точечное разрешение по горизонтали снижается вдвое. Тогда удобно снизить вдвое разрешение и по вертикали, сделав цветовой пиксель 2*2. А лучше использовать 8 бит традиционно, 16 цветов для INK и 16 цветов для PAPER. 2 цвета в пределах 4-х точек.
Ну, а если чуть подумать, то выяснится, что при заимствовании спрайтов от ZX-Spectrum и ОРИОНА, достаточно 2-х цветов в пределах 8-ми битов, т.е то что предлагал я в теме "Модульный РК86".
А если ещё подумать, то выяснится, что цвет в спрайтовых играх достаточно задавать сразу на всё знакоместо, что позволит использовать спрайты от ZX-Spectrum, и сократит объём цветового ОЗУ в 8 раз. Тогда ОЗУ загружаемого фонта - 1 кб, а ОЗУ загружаемого цвета - 128 байт, столько же сколько символов.
Интересно, интересно. Но жаль, что Вы не указали цель данной доработки. Актуальна задача оцвечивания и ографи-чивания антикварных монохромных игр РК86, причём ценой в минимальное число деталей и труда.
Именно эту цель я и преследую.
Но Вас возможно интересует какая-то другая задача. Например, просмотр 16-ти цветных картинок полученных конверсией фотографий в 16-ти цветные BMP-файлы. Или задача иметь красивый цветной фонт для текстообработки.
Нет, такая задача меня не интересует.
Но для этого есть лучшее решение - полноценно графический РК86, что получается из платки Alex_LG, если заменить в ней ПЗУ на 62256 и грамотно программировать (см.ниже)
Думал над этим, но во-первых, РК слаб, для работы с полноценной динамической графикой, а во вторых, это означат, что все старые игры - на помойку, а новые никто писать не будет.
Во-первых если выкинуть сдвиговый регистр на выходе ОЗУ, но вместо этого перебирать адресные входы, а память увеличить в четыре раза, то мы решаем проблему цвета на одной микросхеме ОЗУ. Итак, берем 8К SRAM, это 13 адресных линий, и 8 линий данных. 4 адресных линии отдаем под строки (LC0-LC3), 7 отдаем под код символа (CC0-CC6), остаются 2... Эти две мы подключаем к счетчику, который подключен к тактовому генератору пикселей (ЕМНИП 8 МГц), еще одну линию этого счетчика подаем на счетверенный мультиплексор 2x4, который выбирает либо (D0-D3), либо (D4-D7), и они подаются на выход, это и есть RGBI 16 цветов.
Не лучшим образом излагаете материал. Было бы неплохо сначала выразить идею, тогда последующий текст был бы понятен уже после первого прочтения. А Ваша идея, если я верно понял, заключается в том, что для КАЖДОГО пикселя по горизонтали, которых по-прежнему 384 в строке, считывается свой байт из ОЗУ цвета адресуемого кодом символа из основного экранного ОЗУ.
Да пикселей по прежнему 384, а символов по прежнему 64, только байт - два пикселя по четыре бита. Считываемый байт делится на два пикселя в формате RGBI.
Есть поправка. Вы указали, что только 2 адреса остаётся для "адресации" в пределах 8 битов байта графики. Это значит, что цвет задаётся сразу на два бита. Чтобы адресовать 8 битов надо 3 адреса. Однако и 3-й бит в такой схеме есть.
2 адреса это горизонтальная развертка знакогенератора (там где ранее использовался регистр сдвига), а третий - выбор пикселя из двух, которые в байте (это делает мультиплексор на выходе).
Так, что горизонтальная развертка знакоместа 3 бита.
Незачем заводить LC3, т.к используется режим с высотой знакоместа в 8 линий растра, где LC3 всегда 0.
Не всегда, очень часто используется режим 6x10, и если не брать LC3, то на 9 и 10 линии появятся пиксели со 1 и 2 соответственно.
Таким образом: 3 линии адресов на LC0, LC1, LC2, 7 битов - код символа, и 3 бита остаётся для адресации пикселей в знакоместе по горизонтали. Объём памяти при этом увеличится не в 4, а 8 раз.
Я уже написал, что для горизонтали итак используется 3 бита, и 4 по вертикали.
Однако трудно реально реализовать схему с таким быстродействием. Такт сдвига точек составляет 8 МГЦ, что соответствует периоду в 125 НСЕК. Из 10-ти 62256, что я имел в начале 90-х, только одна тянула в ЭВМ с тактом 8 МГЦ, основная масса тянула только 5 МГЦ (несмотря на паспортное быстродействие в 100 ns).
Такт сдвига в ОЗУ составляет 4 МГц, а 8 МГц - это такт переключения выходного мультиплексора, выбирающего или линии D0-D3 или D4-D7.
Несмотря на то, что объём такого ОЗУ цвета в 8 раз больше объёма фонта в 1 кб, это не скажется на быстродействии игр. Т.к ОЗУ цвета загружается только один раз в начале игры, и никого не волнует если это будет длиться целых полсекунды.
С этим согласен, на то и расчитано. Только поправка, фонт в 4 раза больше по обьему. Ранее фонт был монохромным (1 битным), а теперь 4х битный (16 цветов).
Возможность раскрашивать символы с разрешением каждый пиксель любого цвета, - абсолютно бесполезна без ОЗУ спрайтов, т.е исходной схемы от Alex_LG. Зачем раскрашивать во все цвета радуги буквы КОИ-7 из основного фонта РК86? То есть частично параллельно ОЗУ цвета должно быть включено ОЗУ фонта-графики, с объёмом в 1 кб, содержащее спрайты, например на двух 6514 (с организацией 1К на 4, это КМОП аналог 541РУ2).
Моя схема базируется на схеме Alex_LG, это раз.
Во вторых, с чего Вы взяли, что я собираюсь раскрашивать буквы КОИ-7?
Моя "задумка" позволяет на месте любого символа (буквы) нарисовать любую картинку, в формате 6x8x16 или 6x10x16. Может так понятнее?
Вот теперь мы, наконец, подошли к идее по настоящему графического РК86. Идея не сразу воспринимается, а некоторые особо тупые читатели, увы, так и не смогут понять.
Я к этому и стремлюсь.
Итак, берём схему загрузки фонта от Alex_LG, где вместо 537РУ10 ставим 62256 (цоколёвка совпадает). На старшие адреса этой 62256 (A10, A11, A12, A13) заводим 4 атрибутных сигнала ВГ75. В 62256 32 фонта в 1 кб, в каждом из которых 128 загружаемых символов. Для получения полноценной графики, достаточно коммутировать эти фонты в 128 байт каждые 2 строки (в строке 64 символа). Для этого в начало каждой второй строки заносится атрибутная команда 10xx.xxxx, которая включает следующий фонт. Каждые две строки заполняются инкрементируемыми кодами 0,1,2,3...127, что приводит к последовательному выводу на экран всего фонта в 128 символов в 2-х строках. Всё экранное ОЗУ РК заполняется такими инкрементируемыми кодами с шагом в 2 строки, отчего в каждых двух строках отображается содержимое очередного фонта. Тем самым ОЗУ для загрузки фонта становится экранным ОЗУ, а основное ОЗУ РК86 становится просто коммутатором, позволяющим на выходах ВГ75 появляться инкрементированным в каждом знакоместе кодам от 0 до 127, которые и адресуют экранное графическое ОЗУ РК86.
Примерно так и работает моя схема. Кстати, Вы со схемой ознакомились? Которую я вчера выложил?
За счёт доработки в 10 микросхем, РК превращается в полноценно графический цветной компьютер. В такой схеме в качестве экранного ОЗУ можно использовать экранное ПЗУ, причём размером всего в 256 байт (чтобы уместились 2 строки размером в 80 байт). Это ПЗУ может стоять на E000...EFFF, что освобождает все 32К для программ.
У меня тоже около 10 микросхем...
Необходимо отметить, что эту идею придумал и первым реализовал freddy в своём VGA-адаптере на базе ВГ75. Я лишь озвучиваю эту идею применительно к РК86.
Вот эта идея - по-настоящему привлекательна. Она даёт схеме от Alex_LG совершенно иное качество - не спрайтовую графику и загрузку красивых фонтов, а полноценную графику. Тогда графическое ОЗУ (ОЗУ фонтов) размером в 16 кб можно включить в адресах A000...BFFF в виде двух страниц по 8К. Проблема в том, что спаять проводками такую конструкцию сможет лишь человек умеющий паять конструкции на слепыше. А таких очень мало, основная масса владельцев РК менее трудолюбива и в состоянии только запаять детали в готовую плату.
Именно, когда закончу, может и конструктор сделаем.
Но вернёмся, к схеме доработки платы Alex_LG до цвета за счёт параллельной банки цвета. Если организовать дешёвый выпуск плат под именем МЦПГ-РК86, это даст возможность для РК86 делать игры с качеством графики лучше чем в Денди, не говоря уж о ZX-Spectrum. Однако более-менее массовой может стать только очень простая конструкция (в идеале реализуемая за 2 часа работы паяльником на основной плате РК).
Я планирую так, неделя на пайку макетки с МГТФ, все уже закупил. Неделю на отладку. И неделя на разводку платы. Итого, грубо месяц.
Сложная cкоростная конструкция работающая на пределе возможностей обычных TTL (нужны скоростные) не привлечёт массы. Смотрите, разве конструкцию Alex_LG повторили многие? И организовать выпуск плат тоже не получилось. Ваша сложная конструкция не найдёт поклонников и заказчиков на платы, даже если Вы одновременно предложите все игры РК оцвеченные с высоким разрешением. Нужна максимально простая платка, дающая только те возможности, которые реально востребованы.
Моя конструкция не намного сложнее конструкции Alex_LG, и вообще я пока еще ничего не создал. Просто выложил идею.
Если получится хорошая железка, подумаем о выпуске. Посчитаем себестоимость, и все такое.
- - - Добавлено - - -
UPD: Я позже чуть подробнее напишу как работает схема, вижу что не все и не всем понятно.
Я понял Вашу идею экономии одного бита, используя бит VIDEO из платы Alex_LG. Это громоздко. Зачем 2 банки, если можно обойтись одной на высокой скорости?
В Вашем варианте одно ОЗУ на плате Alex_LG на такте 1 МГЦ (период вывода знакоместа), а второе Ваше, дополнительное, работающее на учетверённом такте 4 МГЦ. Инженер должен максимально экономить детали и учитывать цели для которой разработка делается. Избыточность не нужна.
С двумя банками Вы читаете из одной банки графику, а из скоростной банки четыре раза за знакоместо читаете цвет. Итого имеете на цвет аж 4*8= 32 бита. Не слишком ли жирно это для РК86, на котором и примитивный цвет за счёт атрибутов никто не сумел полезно использовать? Зачем столько цветов, если у Вас цель только оцветить древние игры? Где спрайты в основном односимвольные, для которых достаточно цвета ОРИОНА (2 цвета на 8 точек), и даже цвета ZX-Spectrum (2 цвета на блок 8*8).
Ваша идея не нова. Это уже обсуждалось в теме "Модульный РК86". Вы доработали эту идею в плане, чтобы делать не одно обращение к ОЗУ за период вывода знакоместа, а целых 4. Идея здравая, но доведена до абсурда. Достаточно делать 2 обращения и иметь от этого 16 битов при всего одной банке ОЗУ.
Но я сторонник не цвета из паралельного ОЗУ фонта, а из параллельного ПЗУ фонта. Потому-что заменить ПЗУ сможет любой, а вот паять плату, боюсь, что кроме меня, Вас и Alex_LG не станет никто. Да и я собирался это делать только, чтобы проще было разрабатывать спрайты для ографи-чивания, а позднее и оцвечивания старых игр. Надо быть реалистом. Сначала должны появиться старые игры РК86 в резко улучшенном качестве графики и цвета. И только потом можно думать о разработке и производстве периферийных печатных плат для РК86.
Мне гораздо более симпатична идея от freddy для введения в РК86 режима полноценной графики. А для игр это ничуть не медленнее, т.к чтобы получить такой же символьный режим достаточно перепрограммировать ВГ75 и загрузить спрайтовый фонт в 1 кб. Цвет в этой идее тоже из параллельной банки. Т.е получается и оцвечивание игр и полноценная графика. Ну а насчёт того, что скорости не хватит. Ориону с тактом 2.5 МГЦ хватило при экране в 24 кб. Значит и для турбированного заменой кварца РК86 с реальной скоростью в 3 МГЦ хватит. Кроме того в графических играх достаточно графического экранчика 256*128, как во многих играх ZX-Spectrum.
Идею полноценнной графики я еще даже не обдумал до конца. Можно иметь 32 строки с шагом в 2 строки, но тогда нужно аппаратное формирование ССИ (это 1 доп.корпус, даёт строчный шаг в 64). Можно обойтись сохранив программное формирование бордюра слева-справа, увеличив высоту знакоместа до 16-ти, но тогда чуть неприятнее программировать. Можно истратив счётчик, освободить атрибуты. Т.е тут ещё надо много думать, чтобы выбрать максимально простой вариант.
поправка, фонт в 4 раза больше по обьему. Ранее фонт был монохромным (1 битным), а теперь 4х битный (16 цветов).
Мне кажется, что фонт в Вашем варианте стал не 4-х плоскостным, а 5-ти плоскостным. Одна плоскость из платы Alex_LG, а ещё 4 из Вашего скоростного ОЗУ.
Если уж так хотите 2 банки ОЗУ для фонта, почему бы не сделать их на одной и той же скорости - 4 обращения за период вывода знакоместа. А лучше 3 обращения и фонт оставить 6*8 (не менять на 8*8). Тогда получаем за знакоместо 3*8=24 байта (8 цветов на каждый пиксель, что ничуть не хуже 16-ти цветов, а скорость работы ОЗУ ниже). Еще лучше пойдёт и всего 2 обращения, что даёт 16 битов из одной банки ОЗУ фонта. Т.е вторая банка вообще не нужна.
А ещё лучше и проще, - всего одно обращение к ОЗУ за период знакоместа и то, что я предлагал давно - 2 банки ОЗУ на такте 1 МГЦ - дающие цвет CGA (4 цвета на пиксель). Из 2-х банок можно также получить цвет по принципам ОРИОНА (байт на графику, байт на цвет), что упрощает заимствование спрайтов. Вторая банка - вторым этажом, что существенно сокращает трудоёмкость монтажа.
По-моему, Ваша конструкция с двумя банками на разных частотах слишком громоздка для целей оцветки и не даёт настоящей графики. Поэтому идея freddy и проще и результаты лучше.
Я понял Вашу идею экономии одного байта, используя бит VIDEO из платы Alex_LG. Это громоздко. Зачем 2 банки, если можно обойтись одной на высокой скорости.
Какая экономия одного бита??? Какой бит VIDEO ??? Какие 2 банки???
Вы Вообще о чем?
В Вашем варианте одно ОЗУ на плате Alex_LG на такте 1 МГЦ (период вывода знакоместа), а второе Ваше, дополнительное, работающее на учетверённом такте 4 МГЦ. Инженер должен максимально экономить детали и учитывать цели для которой разработка делается. Избыточность не нужна.
Как раз я и сэкономил детали, у меня всего одно ОЗУ, одна микросхема озу, единственная. Обозначена IC1. Загляните в схему.
С двумя банками Вы читаете из одной банки графику, а из скоростной банки четыре раза за знакоместо читаете цвет. Итого имеете на цвет аж 4*8= 32 бита. Не слишком ли жирно это для РК86, на котором и примитивный цвет за счёт атрибутов никто не сумел полезно использовать? Зачем столько цветов, если у Вас цель только оцветить древние игры? Где спрайты в основном односимвольные, для которых достаточно цвета ОРИОНА (2 цвета на 8 точек), и даже цвета ZX-Spectrum (2 цвета на блок 8*8).
Глупости. Откуда Вы взяли 2 банки? Какая еще скоростная?
У меня всего ОДНА банка, и из нее я читаю BMP картинку, и таких картинок 128, номер картинки дает ВГ75.
Ваша идея не нова. Это уже обсуждалось в теме "Модульный РК86". Но я сторонник не цвета из паралельного ОЗУ фонта, а из параллельного ПЗУ фонта. Потому-что заменить ПЗУ сможет любой, а вот паять плату, боюсь, что кроме меня, Вас и Alex_LG не станет никто. Да и я собирался это делать только, чтобы проще было разрабатывать спрайты для ографи-чивания, а позднее и оцвечивания старых игр. Надо быть реалистом. Сначала должны появиться старые игры РК86 в резко улучшенном качестве графики и цвета. И только потом можно думать о разработке и производстве периферийных печатных плат для РК86.
Как раз я и занимаюсь и ографичиванием и оцвечиванием.
Мне гораpдо более симпатична идея от freddy для введения в РК86 режима полноценной графики. А для игр это ничуть не медленнее, т.к чтобы получить такой же символьный режим достаточно перепрограммировать ВГ75 и загрузить спрайтовый фонт в 1 кб. Цвет в этой идее тоже из параллельной банки. Т.е получается и оцвечивание игр и полноценная графика. Ну а насчёт того, что скорости не хватит. Ориону с тактом 2.5 МГЦ хватило при экране в 24 кб. Значит и для турбированного заменой кварца РК86 с реальной скоростью в 3 МГЦ хватит. Кроме того в графических играх достаточно графического экранчика 256*128, как во многих играх ZX-Spectrum.
Это Ваше дело, какая идея Вам более симпатична, а пока я вижу, что Вы даже не разобрались, в чем моя идея.
Идею полноценнной графики я еще даже не обдумал до конца. Можно иметь 32 строки с шагом в 2 строки, но тогда нужно аппаратное формирование ССИ (это 1 доп.корпус, даёт строчный шаг в 64). Можно обойтись сохранив программное формирование бордюра слева-справа, увеличив высоту знакоместа до 16-ти, но тогда чуть неприятнее программировать. Можно истратив счётчик, освободить атрибуты. Т.е тут ещё надо много думать, чтобы выбрать максимально простой вариант.
Кто напишет под это игры?
Глупости. Откуда Вы взяли 2 банки? Какая еще скоростная?
У меня всего ОДНА банка, и из нее я читаю BMP картинку, и таких картинок 128, номер картинки дает ВГ75.
Теперь я уже совсем ничего не понимаю. Сначала я считал, что Вы читаете 4 раза, получая 32 бита и распределяя их, не то среди 6 пикселей, не то среди 8-ми пикселей (это не уточнено) и получаете 16 или 8 цветов на пиксель. Оказалось, что я не так понял. В ответе Вы убедили меня, что имеете ещё и бит Video, который берётся из банки ОЗУ на плате Alex_LG (не из основного же фонта на плате РК), что и позволяет задействовать 2 адреса на ОЗУ вместо 3-х. Тогда я и сделал вывод, что у Вас 2 банки, - одна на плате Alex_LG из которой читается графика и Ваша скоростная банка из которой читается цвет. Как можно было иначе понять Ваши сообщения? К тому же в стартовом сообщении Вы собирались повторить схему Alex-LG 4-5 раз, что можно понять только как наращивание банок.
И не "кипятитесь" пожалуйста, лучше не торопиться с ответом, мы ведь не спешим. Схему я смотрел, но понял из неё только то, что ОЗУ читается 4 раза за период вывода знакоместа и цвет кодируется 4-мя битами.
Идею полноценнной графики я еще даже не обдумал до конца... тут ещё надо много думать, чтобы выбрать максимально простой вариант
Кто напишет под это игры?
Кто-нибудь напишет, а скорее адаптирует. Есть совместимость с базовым РК и есть возможность оцветить старые игры... Кому это мешает, если расхода деталей нет? Зато текстообработкой можно заниматься на 80 символов в строке. А если уж полноценная графика не нужна, то уж 16 цветов на пиксель для оцвечивания старых символьных игр, - тем более.
Для оцвечивания старого ПО достаточно одной банки ОЗУ фонта, читаемой 2 раза за знакоместо. По моему это оптимально. Но если фонт 6*8, то проще напаять банку для цвета вторым этажом. Дилемма - распараллеливание банок против временнОго мультиплексирования при одной банке.
Ваше дело, какая идея Вам более симпатична
Не только мне. Потому что идее цвета за счёт параллельных банок ОЗУ или чтения ОЗУ дважды - не менее 50 лет. А вот до идеи нетрадиционно использовать ВГ75 и получить из неё графику не смог додуматься никто из 7 млрд людей за 40 лет со дня её разработки.
Теперь я уже совсем ничего не понимаю. Сначала я считал, что Вы читаете 4 раза, получая 32 бита и распределяя их, не то среди 6 пикселей, не то среди 8-ми пикселей (это не уточнено) и получаете 16 или 8 цветов на пиксель. Оказалось, что я не так понял. В ответе Вы убедили меня, что имеете ещё и бит Video, который берётся из банки ОЗУ на плате Alex_LG (не из основного же фонта на плате РК), что и позволяет задействовать 2 адреса на ОЗУ вместо 3-х. Тогда я и сделал вывод, что у Вас 2 банки, - одна на плате Alex_LG из которой читается графика и Ваша скоростная банка из которой читается цвет. Как можно было иначе понять Ваши сообщения?
И не "кипятитесь" пожалуйста, лучше не торопиться с ответом, мы ведь не спешим. Схему я смотрел, но понял из неё только то, что ОЗУ читается 4 раза за период вывода знакоместа и цвет кодируется 4-мя битами.
Начну с конца, я не кипячусь, я скорее озадачен. Чем больше я пытаюсь разьяснить, тем более Вам не понятно... :v2_blink:
Мы действительно не торопимся, хотя сесть паять руки чешуться, а я еще до 9 буду на работе.
Но меня осенила догадка, возможно Вы посчитали, что моя плата используется вместе с платой Alex_LG, как приставка к приставке дающая цвет...
Если Вы так подумали, то это не так. Моя плата заменяет плату Alex_LG, даже я бы сказал, что это ее модификация.
Итак, как работает плата Alex_LG: Когда знакоместо меняется, то ВГ75 выдает код на линии CC0-CC6, это 128 вариантов, также на линии LC0-LC3
выдается номер строки. Получаемый адрес выбирает ячейку в ОЗУ и оттуда выводится байт на вход регистра сдвига, который тактируется пиксельной
частотой, и таким образом в этом байте содержится вся линия всего знакоместа, все 8 пикселей. Из них берется 6, но можно оставить и 8, что повышает горизонтальное
разрешение видеосистемы до 512 точек.
Кстати я тоже еще не определился, сколько нужно пикселей в знакоместе 6,7 или 8. Практика критерий истины, поэтому когда попробую станет ясно.
Чем отличается моя схема, от схемы Alex_LG. Также, когда ВГ75 дает код символа, то происходит те-же самое, что и у Alex_LG, выбирается ячейка
и читается байт, только этот байт содержит не 8 монохромных пикселей, а всего 2, но в каждом 4 бита.
Весь период отображения первого пиксела мультиплексор IC2, отправляет в дисплей первые четыре бита из байта (D0-D3), отображается цветной пиксел.
Затем когда приходит время отобразить второй пиксел, то мультиплексор отправляет на дисплей вторые четыре бита (D4-D7), и отображается 2й цветной пиксел.
Далее, когда приходит время показать 3 пиксел, то мультиплексор встает обратно на линии (D0-D3), а триггер IC9B, дающий 2 перепада за период знакоместа (каждые 2 пикселя),
устанавливает линию A0 ОЗУ из нуля в единицу, и на выход ОЗУ поступает следующие 2 пикселя (3й и 4й), мультиплексор IC2 опять разделяет их по времени и выдает в монитор.
Сначала я хотел просто повторить схему Alex_LG в четырех экземплярах, но представляете, что бы вышло?
Тогда я понял, что вместо этого можно разогнать схему в четыре раза, и она будет работать как те одинаковые 4 платы.
При этом получается, что в знакоместе каждый пиксел может иметь свой цвет из 16ти, а не как в спектруме, где он по знакогенератор по прежнему монохромный, но он выбирает
цвет символа и цвет фона.
Еще проще, Вы заливаете 128 шестнадцатицветных "картинок" в ОЗУ, а они отображаются вместо букв.
:v2_cheer:
- - - Добавлено - - -
Кстати, насчет того, понравится ли или нет моя разработка сообществу. Я пока не ставлю целей, всем угодить и сделать шедевр, это такой шажок в моем увлечении.
Покажу, что может, сделаю себе, если кто-то еще захочет, помогу сделать, и т.д.
А уж на вкус и цвет все фломастеры разные.
to Barsik.
Думал над Вашей идеей "чисто графического режима", в принципе это тоже реализуемо, на моей плате без особых переделок.
Можно получить из 32 кБ видеопамяти разрешение 320x200 при 16 цветах. Что лучше, чем CGA PC XT...
Тогда можно "замаппить" эти 32 кБ в область A000-BFFF, что 8 кБ, и сделать переключатель четырех страниц.
Все получится, но повторюсь, мне думается, слабоват процессор.
Посему предлагаю так: Сначала я делаю, то, что начал, когда на макетке все заработает, я сажусь за разводку платы, а макетку перепаяю, под графику. Может даже удастся совместить обе разработки на одной плате, где режим переключается.
Надеюсь на моральную поддержку.
Сначала я делаю, то, что начал, когда на макетке все заработает, я сажусь за разводку платы, а макетку перепаяю, под графику. Может даже удастся совместить обе разработки на одной плате, где режим переключается.
Паяльник - это конечно хорошо.. И я даже догадываюсь, с какой стороны он включаеЦЦа.
Но все же предлагаю альтернативный взгляд на отладку железок 30-ти летней давности в современных реалиях
На "альтернативно-дружественном" форуме отлаживают сперва в Протеусе, а потом паяют
http://www.nedopc.org/forum/viewtopic.php?f=93&t=16296&sid=2c9ad1763c818ef27f4692108dff1dc4
Про FPGA и ПЛИС наверное промолчу.
Ну и так, для общего развитийя, оттеда же. свежайя заметка
http://www.nedopc.org/forum/viewtopic.php?f=93&t=17237
Error404
21.03.2017, 17:19
Паяльник - это конечно хорошо.. И я даже догадываюсь, с какой стороны он включаеЦЦа.
Но все же предлагаю альтернативный взгляд на отладку железок 30-ти летней давности в современных реалиях
На "альтернативно-дружественном" форуме отлаживают сперва в Протеусе, а потом паяют
http://www.nedopc.org/forum/viewtopic.php?f=93&t=16296&sid=2c9ad1763c818ef27f4692108dff1dc4
Про FPGA и ПЛИС наверное промолчу.
Ну и так, для общего развитийя, оттеда же. свежайя заметка
http://www.nedopc.org/forum/viewtopic.php?f=93&t=17237
да-да, помним. "Лучше день потерять, потом за 5 минут долететь!" :)
Чтобы проверить небольшую схемку - сначала в Протеусе весь комп съэмулировать.
Про FPGA и ПЛИС наверное промолчу.
Ну и так, для общего развитийя, оттеда же. свежайя заметка
Про FPGA и CPLD что-то слышал.
А на самом деле, профессионально работаю с ними, и сталкиваюсь каждый день. И, вобщем, могу всю РКшку + SVGA video с 2мБ на борту
сделать на одном спартане, но не стану.
Во первых, из-за того, что я по работе с ними сталкиваюсь - меня от них тошнит.
Во вторых, "теплая ламповая логика" и есть база моего увлечения.
И в третьих, никогда не поставлю плисину в РК, это противоречит философии моего хобби,
это шаг в сторону эмуляторов.
Ну и так, для общего развитийя, оттеда же. свежайя заметка
http://www.nedopc.org/forum/viewtopic.php?f=93&t=17237
Да, я это уже видел, но спасибо.
- - - Добавлено - - -
UPD: to Barsik. Для полноценного граф. режима нужно просто выкинуть тм2 (ic9) и поставить 15 битный счетчик, который будет разворачивать ОЗУ на экран. Он должен сбрасываться по КСИ, и инкрементироваться по пиксельклоку, и еще вставать на паузу, во время ССИ и бланкирования, вот, собственно, и все.
UPD: Отпишусь, кому интересно как продвигается.
Сел паять, макетка хорошая, рассыпохи и МГТФ вдоволь.
Как советовал уважаемый Barsik микросхема ОЗУ заменена на UT62256 (32кБ).
Запланировано 3 режима работы:
1. Прямое пропускание. Этот режим проводит сигнал с родного адаптера на базе ПЗУ на выход, сделано что-бы не перетыкать. Он устанавливается по умолчанию при сбросе ПЭВМ.
2. Режим тайлов. Этот режим заменяет символы в видеопамяти на тайлы, предварительно загруженные в ОЗУ устройства. Перепрограммировать можно на лету. Всего предусмотрено 512 тайлов, каждый может содержать одновременно
16 цветов. Можно создавать двигающиеся тайлы.
3. Полностью графический режим. 320x200x16 или 384x170x16. Здесь полностью графический режим, каждый пиксел на экране можно зажечь независимо от остальных, любым из 16 цветов.
ОЗУ 32 кб, разбито на страницы по 4 кб (8 страниц), оно отражается в одну из областей (8000-8FFF),(9000-9FFFF),(A000-AFFF),(B000-BFFF), выбираемой перемычкой. ОЗУ доступно как для записи, так и для чтения.
В области ПЗУ (F800-FFFF) расположен регистр управления, в нем выбирается режим (один из трех вышеуказанных) и номер страницы ОЗУ, которая мэпится в выбранную область.
Отписываюсь.
Плата почти готова. Возникло 2 проблемы. Первая это я неожиданно понял, что у меня нет PAL кодера. Это пока не очень меня беспокоит, может по RGB подключу, а может по YPrPb... А может спаяю какой-нибудь кодер.
Другая проблема, включил вчера микрошу хотел бейсик загрузить для удобства отладки, а она не грузится, вернее грузится, но всегда с ошибкой. Посмотрел 140УД608, вроде все нормально - на осцилографе красивые "меандры". До ВВ55 доходят. Попробовал громкость порегулировать - бесполезно. Все равно с ошибкой. Скопировал директивой монитора дамп ПЗУ в нулевую область и выгрузил, а потом снова загрузил, и то что загрузилось мало похоже на оригинал...
Пока думаю "Чо за фигня???" :)
UPD: починил микрошу, сел за отладку. Планирую сделать демки на бейсике.
UPD: Отладка идет, но с трудом. Например обнаружил, что в микроше в адресном пространстве ПЗУ сидит контроллер ПДП... :v2_blink:
SYR-ALEX
08.04.2017, 18:37
ZEvS , заинтересовала ваша разработка . И возник вопрос . Какая частота сдвига для точек ? Если стандарт 8 МГц то количество точек растра удваивается , так как период содержит H/L уровни и КП11 за 1 период будет формировать 2 точки в отличии от ИР13 . Для пиксель клока нужно 4 МГц . Я правильно понимаю ?
ZEvS , заинтересовала ваша разработка . И возник вопрос . Какая частота сдвига для точек ? Если стандарт 8 МГц то количество точек растра удваивается , так как период содержит H/L уровни и КП11 за 1 период будет формировать 2 точки в отличии от ИР13 . Для пиксель клока нужно 4 МГц . Я правильно понимаю ?
Изначально так и планировал, но потом решил, что шрифт должен содержать 8 точек по горизонтали на знакоместо вместо 6ти. Это и разрешение повышает и память используется вся (а не часть).
Поэтому пришлось собрать тактовый генератор 10.6(6) МГц. А именно 8/6*8. Такую частоту удалось получить из частоты 32 МГц, поделив ее на 3.
Сейчас все тестирую (на бейсике) и подбираю параметры. Скоро выложу первые результаты и схему.
SYR-ALEX
08.04.2017, 20:08
10,6 МГц это примерно 480 видимых точек для ИР13 и 960 для КП11 ?
При таком пиксель клоке на строку символа получается 16 точек . А если 10,6/2 то как раз 8 точек тоесть 4 байта на строку символа и 32 байта на символ 8Х8.
10,6 МГц это примерно 480 видимых точек для ИР13 и 960 для КП11 ?
При таком пиксель клоке на строку символа получается 16 точек . А если 10,6/2 то как раз 8 точек тоесть 4 байта на строку символа и 32 байта на символ 8Х8.
А, я понял о чем Вы. Да, входной клок делится на 2 в микросхеме кр1533ие19. Фронт происходит с частотой 10,(6) МГц, а изменение состояния "фронт/спад" в два раза реже. Кроме того деление на 2 необходимо для получения скважности 50 %, иначе четные пиксели отличаются от нечетных по "длинне".
Забудьте прошлую схему, что я выкладывал (это набросок был), она претерпела много изменений. Скоро будет новая.
SYR-ALEX
16.04.2017, 19:14
ZEvS , здравствуйте . Есть результат по новой схеме ?
ZEvS , здравствуйте . Есть результат по новой схеме ?
Да, пока что довожу. Гемор, конечно с тем, что приходится возится с загрузкой всего этого хозяйства через WAV файлы...
Всяких дисководов и SD у меня пока-что нет.
В общем, немного терпения. И все скоро будет, и фото, и схема, и видео демок.
Платы буду заказывать непременно.
DonkeyHot
20.02.2018, 07:17
кстати да, идея наложения адресного пространства на ROM суперична (бггг, пардон за англицизм), сохраняется адресная аутентичность, просто ROM выбирается сигналом RD, а RAM ЗГ по WR, единственное что стоит добавить это программный интерфейс с переключателем источника шрифтов - ROM/RAM
это потребует исправления монитора в части ввода нескольких команд - при резете и старте включение ROM, переключение на RAM (как и запись своего шрифта) производится уже самой пользовательской программой
Да, пока что довожу. Гемор, конечно с тем, что приходится возится с загрузкой всего этого хозяйства через WAV файлы...
Всяких дисководов и SD у меня пока-что нет.
В общем, немного терпения. И все скоро будет, и фото, и схема, и видео демок.
Платы буду заказывать непременно.
Жалко что проект не закончен
Можно ли переделать монитор Радио-86РК для другого компьютера где не будет ВВ55 и ВГ75? Желательно также ссылку на исходники монитора, чтобы можно было переделать подключение ROM диска, клавиатуры и экрана.
Проще, тогда, взять Монитор от "Специалиста" и убрать от туда ВВ55 для клавиатуры, а опрос, например, глянуть в Мониторе-0 от ЮТ-88...
Проще, тогда, взять Монитор от "Специалиста" и убрать от туда ВВ55, например, глянуть на Монитор-0 от ЮТ-88...
Но у меня в компьютере будет символьный экран. И программы для РК-86 надо загружать.
Тогда от ВГ75 можно избавится по методу самого же Радио-86рк, см. статью про замену ВГ75 на рассыпухе.
Много ли программ перестанет работать, если не будет соответствия между адресом символа в ОЗУ и расположением символа на экране? Предполагается только совместимость при выводе символов через подпрограммы монитора.
На сколько я помню, в Радио было сказано, что будут работать проги, которые работают со стандартными ПП Монитора, все программы с прямым обращенем к вт57 или вг75 на такой замене работать не будут.
- - - Добавлено - - -
К стати, Монитор под рассыпуху свой.
- - - Добавлено - - -
Но совместим по точкаам входа в ПП.
OldSpeccer
06.01.2025, 17:22
Сорри за некропостинг. Перековырял схему так, чтоб теневой ЗГ можно было загружать простой командой Т монитора.
Схема под стандартный РК. Может пригодится кому
81809
Перековырял схему так, чтоб теневой ЗГ можно было загружать простой командой Т монитора.
А в чем отличия от оригинальной схемы? Честно говоря, лень искать и сверять... ;)
OldSpeccer
13.01.2025, 12:53
А в чем отличия от оригинальной схемы? Честно говоря, лень искать и сверять... ;)
У схемы нет отличий. Отличие в подключении, чтоб схема заработала на оригинальном РК-86. Линии данных разведены как надо, а не как удобно, ровно как и подключение LC0..LC2, CC0..CC6 согласно схеме РК, мультиплексируемые с нужными адресами, только и всего.
Оригинальная схема соответствует сигналам Радио, в самом Радио ничего перепаивать не нужно, подключается просто. В принципе для ОЗУ не важно как подключать - что записано, то и считано, это уже обсуждалось не раз. Нестандартное подключение ОЗУ ни на что не влияет, кроме удобства разводки платы.
В оригинальной схеме тоже можно записывать простой пересылкой или копировпнием.
OldSpeccer
17.01.2025, 15:28
Здравствуйте, Alex_LG! Во-первых конечно - спасибо за схему, ибо это то, чего от роду не хватало РКшке! И очень разумно было ЗГ спрятать в тень ПЗУ.
Все так как вы говорите - я вроде сам тоже лет 40 с паялом, и с принципом "В принципе для ОЗУ не важно как подключать - что записано, то и считано, это уже обсуждалось не раз" тоже знаком, ведь каждый адрес уникален, то есть не суть важно к каким именно адресам подключены входы, ровно как и данные - главное что на входе - то и на выходе, а как оно на самом деле - никого не волнует.
Но у меня не заработало. Собрано у меня все на маленькой макетке втыкаемой вместо ПЗУ ЗГ, МГТФ-ом, удобно - обратно-совместимо. Сначала я конечно разобрался, что адреса должны быть смещены (если нет LC3), переподключил - благо МГТФ, и ничего. Потом заметил, что вместо диодов воткнул стабилитроны на 3,3в. Ну ничего, исправил - но воз и далее на месте. То есть мусор на экране. И так и эдак. Два дня сидел, сушил голову, смотрел в скоп, как дурак, ибо все сигналы на месте - и ничего не работает. Обидно. Самое плохое, что принцип вроде тоже понятен - но не идет, и все. В попытках отладить, подумал - пойду обратным путем, сначала заставлю отображаться штатный ЗГ на месте РУ10-й, перепаял входы-выходы согласно схеме, воткнул ПЗУ вместо ОЗУ - работает. Воткнул ОЗУ - чОрт, тоже работает! После этого у меня еще обнаружился битый файл фонта, но это детали. Странности добавляет, что у меня шина данных регистров входа выхода ввиду МГТФа соединена сначала между регистрами, и оттуда уже к ОЗУ. Так вот, я их не трогал, только переразвел данные на самой ОЗУ, то есть ошибка в этом месте исключена...
Может, конечно, но очень маловероятно, что я что-то напартачил при МГТФинге, потому как все проверялось-перепроверялось, звонилось во все стороны, и пепаивалось несколько раз за двое суток. Ну, и я на МГТФе устройства раз в 10 посложнее собирал, то есть как бы скиллы есть. В итоге я бросил размышлять что это было, просто накидал себе версию схемы, которая у меня взлетела. И надо сказать, полет прекрасный!!
Правильно я понимаю, что если оторвать диод D2, то в ОЗУ ЗГ можно будет писать при включенном софт-ЗГ? Это чем-нибудь чревато, кроме "снега"? Потому как если так, то и плевать - мне интересна идея переписывать ЗГ на лету, не дергая при этом триггер переключателем или портом.
81846
Ведущий_специалист
17.01.2025, 18:55
Правильно я понимаю, что если оторвать диод D2, то в ОЗУ ЗГ можно будет писать при включенном софт-ЗГ? Это чем-нибудь чревато, кроме "снега"? Потому как если так, то и плевать - мне интересна идея переписывать ЗГ на лету, не дергая при этом триггер переключателем или портом.
81846
Я пробовал быстро переключать и рисовать онлайн, выводя весь знакогенератор на экран и прописывая в ОЗУ знакогенератора свою инфу. Снежить не будет - если делать это в момент окончания кадра и обратного хода луча. Но получается довольно медленно.
Встречный вопрос - а для чего вам менять зг онлайн? динамические эффекты таким образом не посмотреть - да и окошко совсем маленькое получается из 127 символов. Это учитывая что в пальмире высота символа 16 точек. В рк в 2 раза меньше будет.
OldSpeccer
17.01.2025, 19:44
Не совсем понятно, какие именно динамические эффекты вы имеете ввиду, но думаю, что перепрограммирование нескольких знаков ЗГ будет происходить молниеносно, и этого более, чем достаточно, чтоб условный человечек дергал ногами во время бега, например. Граф. игры на Commodore VIC-20 все так сделаны, например, хотя тот же VIC - чисто текстовый. И медленно оно получается как раз потому что надо дергать портом. Ну и потом, зачем дергать, если можно включить и забыть?
"молниеносно" -- это не про РК
но думаю, что перепрограммирование нескольких знаков ЗГ будет происходить молниеносно
Так и есть, можно сравнить со скоростью вывода спрайтов. Шевеление травы, движение звёзд, все мелкие детали вполне можно переносить на тайлы. В итоге картинка становится по крайней мере динамичной.
OldSpeccer
18.01.2025, 10:32
Так и есть, можно сравнить со скоростью вывода спрайтов. Шевеление травы, движение звёзд, все мелкие детали вполне можно переносить на тайлы. В итоге картинка становится по крайней мере динамичной.
В общем случае, для плавной анимации любого "тайла" типа бегущего человечка или летящего снаряда достаточно пепепрограммировать 2 символа, т.е. 16 байт. При том, что это совершенно необязательно делать каждый кадр. А если сильно не хватает времени проца - можно просто набить ЗГ уже готовыми фазами анимации.
Правильно я понимаю, что если оторвать диод D2, то в ОЗУ ЗГ можно будет писать при включенном софт-ЗГ? Это чем-нибудь чревато, кроме "снега"? Потому как если так, то и плевать - мне интересна идея переписывать ЗГ на лету, не дергая при этом триггер переключателем или портом.
Немного поясню по схеме.
На диодах собран обычный логический элемент "ИЛИ", т.е. запись в ОЗУ будет происходить при обращении к ЗГ. Если убрать Д2, то будет происходить запись при любой записи в память или внешние устройства, т.е. будет мусор, а не знакогенератор. Так же писать в ОЗУ ЗГ можна в любой момент, дергание тумблером - это переключение между ПЗУ и ОЗУ ЗГ и оно никак не влияет на запись, а только на то, что видите на экране. Триггер стоит для синхронизации переключения между ОЗУ и ПЗУ в момент смена кадра.
P.S. Что бы не плодить разнообразие, я предлагаю использовать переключение битом 6 по адресу СЕ00, как это сделано в "Пальмире".
Перековырял схему
А нет ли нормального размера, читабельного?
OldSpeccer
21.01.2025, 20:16
Есть, конечно. Вот, держите гуглдрайв (https://drive.google.com/file/d/1veSYsGbbbWHzIJX2LnDFF30bDAzGwNmK/view?usp=sharing)...
о... я правильно понял? теперь на радио можно свой знакогенератор программно записывать? прям рисовать спрайты для игры без заморочек?
Изучил ЗГ Пальмиры со стороны программирования. Написал демку 81884
https://zx-pk.ru/attachment.php?attachmentid=81885&d=1737963295
За время обратного хода луча получилось проапдейтить 12 символов 8x8 с применением стековых операций. Но то на Пальмире в режиме 78х64, где ПДП забирает 69% процессорного времени...
Очень интересно, что получится на РК с правильным ССИ в (https://zx-pk.ru/threads/36010-skhema-pravilnogo-ssi.html) режиме 64х35!
В любом случае, получается так, что нужно сначала все тайлы класть в буфер, а потом буфер, во время обратного хода луча, быстро загонять в РУ10. Тогда нет снега, и можно проапдейтить максимальное количество знакомест.
Сам девайс спаять я не смогу, поэтому готов финансово участвовать в разработке и заказе платы. Хотелось бы, чтобы сама плата была ориентирована на криворуких и имела крепёжные отверстия, например, повторяла одну сторону крепления платы формата ITX. Кучу проводов идущих к РК тоже не хочется. Разумно сделать переходники со шлейфами, которые втыкаются в панельки ПЗУ и ВГ75. Иначе корпус РК превратится в коробку с МГТФ, если подключить еще плату дисковода, например. Так же можно добавить к девайсу Пикселтрон (https://zx-pk.ru/threads/35812-ot-chjornogo-k-belomu-(skhema-kod).html).
Очень буду ждать такой продукт!
В демке ещё эмулируется затухание амплитуды нот. У Пальмиры три канала смикшированы. Дублируя канал, можно увеличивать амплитуду ноты.
81884
исходник?
Появится на гитхабе разработчиков Пальмиры :v2_dizzy_roll:
Ведущий_специалист
27.01.2025, 23:16
исходник?
https://github.com/maxadler1979/palmira/tree/main/games/SOFT/DEMO
о... я правильно понял? теперь на радио можно свой знакогенератор программно записывать? прям рисовать спрайты для игры без заморочек?
Давно уже можно! :D
Смотрите здесь:
https://zx-pk.ru/threads/20714-pomechtaem-ili-vopros-o-videovykhode.html?p=713206&viewfull=1#post713206
Второе бы ОЗУ под цвет бумаги и чернил. Тогда можно траву сразу зелёной рисовать, небо синим, а героя отделять от фона. Получится очень СИЛЬНАЯ машина.
Hammer, интересная идея, надо подумать. Байт на знакоместо, его можна разделить и получится 16 цветов на фон и 16 на чернила. Можна разделить по 2 бита, тогда будет в одном знакоместе 2 цвета фона и 2 цвета чернила, что дает 4 цвета на знакоместо...
- - - Добавлено - - -
....если использовать разную палитру, при 2х битной кодировке, для фона и чернил, то можно получить 8 цветов на знакоместо...
А больше ничего и не надо, РК сразу становится игровым. Ни повышения частоты не надо (хотя я 24 мГц пробовал кварц ставить), ни кучу памяти (графика в битах, а не в псевде). Всё становится на свои места, и можно писать игры в экономном режиме 64х35. Лучше ничего не придумать с ВГ75.
https://86rk.ru/emulator/#eyJjb21wIjoicmFkaW8tODZyazYwIiwiZmlsZSI6InJhbWZvb nQucmsifQ==
https://86rk.ru/emulator/#eyJjb21wIjoicmFkaW8tODZyazYwIiwiZmlsZSI6InJhbWZvb nQucmsifQ==
Быстрое ограбление Пальмиры, просто на ходу кальсоны подрезали )))
Интересно, ссылка ведет не только на программу, но и на конфигурацию "железа".
А исходник адаптации есть?
Продумываю ещё игру простенькую с тайлами, жаль на реальном железе пока не проверить. Без железки я бы не смог демку отладить. Хорошо, что Ведущий Специалист и Виктор Пыхонин помогли с тестированием на своих Пальмирах. И этот порт демки сначала бы надо на реале погонять - скролл то дрожит, то нормально работает в эмуляторе.
Ведущий_специалист
30.01.2025, 12:12
Быстрое ограбление Пальмиры..
Хороший софт должен разлетаться на все платформы, в свое время плюк тоже в течении пары дней поселился в пальмире.
У Виталия хороший аппарат получается. Ждем в железе и с документацией. Я как то хотел подрезать его идеи в пальмиру но не стал. Во первых плодить пальмиры неохота во вторых есть нюансики по железу... Нужно додумывать. Не все так просто.
- - - Добавлено - - -
...интересная идея, надо подумать....
Мне давно как то предложили идею. Вешаем вторую ру10 в параллель, но включаем ее битиком от первой ру10. шд второй выводим на цвет. Получается запись в первую ОЗУ сможет активировать цвет линии знакоместа второй ОЗУ. Остается только продумать как ее переключать в адресное пространство. Нужно умно и с минимум микросхем ибо хейтеры экономисты микросхем достали... Все бы попроще да двумя микросхемами вторым этажом....
Адрес нужен для второй РУ10. Или теряем бит цветности/яркости.
Вопросы назрели по схеме:
https://zx-pk.ru/attachment.php?attachmentid=81901&d=1736173232
https://drive.google.com/file/d/1veSYsGbbbWHzIJX2LnDFF30bDAzGwNmK/preview
1. IC6 нужна чтобы данные ОЗУ не падали на ШД процессора? Можно ли заменить на АП6?
2. IC7 нужна чтобы данные при записи в ОЗУ не падали на ИР13?
3. Сигнал /CE_FONT идёт на прямой выход триггера, так и должно быть, ничего не сгорит?
81901
1. IC6 нужна чтобы данные ОЗУ не падали на ШД процессора? Можно ли заменить на АП6?
2. IC7 нужна чтобы данные при записи в ОЗУ не падали на ИР13?
3. Сигнал /CE_FONT идёт на прямой выход триггера, так и должно быть, ничего не сгорит?
1. Да. Можна менять на ап6, как это сделано в Пальмире. Я ставил ап5, что бы не играться с сигналами направления передачи, но ап6 проще для разводки платы.
2. Не совсем. Чтобы небыло конфликта с данными из ПЗУ в момент когда проц обращается к ру10.
3. Не сгорит, т. к. он я вляется выходом для подачи на соответствующий вход ПЗУ знакогенератора, который нужно предварительно отрезать от "земли".
- - - Добавлено - - -
Второй ру10 лучше управлять отдельно. Мне видится это как выбор соответсвующей микросхемы одним из управляющих битов порта се00, там вроде есть незадействованные.
- - - Добавлено - - -
Еще один плюс в пользу отдельного управления озу цвета - в стандартном текстовом режиме можно получить раскраску текста (и при этом не использовать память под атрибуты!) и "писать" хоть черным по белому, хоть белым по черному, а можна как монохром - зеленым по черному, всего один лишь раз заполнив память цвета при старте компа...
Второй ру10 лучше управлять отдельно.
Наверное да, но в любом случае надо оставить возможность переключать половинки РУ10 атрибутом, чтобы было два программируемых ЗГ.
Это может очень полезным оказаться для анимации. Я мог бы в своей демке обновлять тайлы в одной половинке ЗГ, а потом переключать половинки. И тогда не нужен программный буфер, а значит демка заметно прибавит в скорости.
https://i.ibb.co/sp5q3B7j/tmp1.png (https://ibb.co/sp5q3B7j)
Предварительный вариант, пока заготовка. Используется бит 4 порта СЕ00 для выбора между ОЗУ ЗГ и цвета. Не реалезовано использование старших битов ЗГ. В данном варианте будет 16 цветов на знакоместо (2 цвета из 16 одновременно, как в Спектруме), при использовании старших битов - будет 32 цвета на строку (два цвета из 32 одновременно). Формат цвета: младший полубайт - чернила, старший полубайт - бумага, BRGI.
P.S. Вместо АП5 поставил АП6 и "по справочнику" развел шину данных, до адресов пока не добрался...
Цвет надо защёлкивать в регистре типа ИР23-27, иначе не будет совпадать со знакоместом.
Очень круто получается!
https://i.ibb.co/b5wLyssy/tmp2.png (https://ibb.co/b5wLyssy)
Вариант реализации (на IC13 и IC14) порта СЕ00 на Радио-86РК. !CS_CRT берется с выв.9 DD11 (ИД7), сигнал !CS_CRT* подается на выв.22 DD8 (ВГ75). Если сделано по данной схеме, то инвертор на транзисторе T1 и резисторах R3 и R10 не нужен: COLOR подается на выв.10 IC11, FONT - на выв.5 IC11.
- - - Добавлено - - -
Подправил
https://i.ibb.co/991Ccw73/tmp1.png (https://ibb.co/991Ccw73)
Возможность использовать высокие буквы, или возможность переключать банки ЗГ? Не пойму пока, что важнее... Наверное стоит пожертвовать LC3, но на линию A10 обеих РУ10 завести атрибут GPA0. Для анимации вероятно так полезнее будет.
Поскольку плата уже большая, не имеет смысла экономить на обвязке. Уровни RGBI можно сразу снизить до 0.7-1В (SCART, VGA).
Возможность использовать высокие буквы, или возможность переключать банки ЗГ?
У Виталия работают оба.
https://86rk.ru/emulator/#eyJjb21wIjoicmFkaW8tODZyazMyIiwiZmlsZSI6ImRlbW8uc msifQ==
У Виталия работают оба.
https://86rk.ru/emulator/#eyJjb21wIjoicmFkaW8tODZyazMyIiwiZmlsZSI6ImRlbW8uc msifQ==
Дык пусть расскажет про свою схему, покажет возможности. По эмулятору ничего не понять.
Элементарно (с) Он заставил работать LA0.
- - - Добавлено - - -
По эмулятору ничего не понять.
Понять, что совершенно все атрибуты работают, и переключение ЗГ тоже. одновременно. Благодаря еще одному атрибуту E5/E4.
Понять, что совершенно все атрибуты работают, и переключение ЗГ тоже. одновременно. Благодаря еще одному атрибуту E5/E4.
Непонятно, в чём фишка?
Цвет не атрибутами сделан? Да вроде видно при выводе текста, как цвет до конца строки добивает, значит атрибутами. Ну переключается ЗГ, у меня тоже ПЗУ через атрибут переключается.
Я изначально за то, чтобы атрибуты оставить для работы с текстом. Это очень важно для интерфейсов, а не игрулек. Я писал трекер, как в нём ноты выделить, как обозначить выбор скорости? Да никак! Влажные мечты по поводу выделения текста через цвет фона в ЗГ - лажа полнейшая. В том же музыкальном трекере ноты меняются каждый четвертый кадр, перерисовка фона под ними сожрёт всё процессорное время. А если вы используете буквы нот ещё где-то, то и они перекрасятся. Чтобы разгрузить процессор и придуманы атрибуты. Не надо менять их назначение.
Вот сейчас рождается схема, которая во многих местах по скорости обгоняет Спектрум, а уж по плотности цвета оставляет его далеко позади. Мне уже пофиг даже на размер платы, наконец-то всё будет работать чётко и быстро!
E5/E4 - это LA атрибуты. Значит нужно менять высоту линии подчёркивания постоянно, значит где-то в тексте подчёркивание и перечеркивание уже не будет работать. Чего вы постоянно новые трудности придумываете? Это удобно только для формирования сигнала записи в ЗГ по Аликберову. Очень интересная схема, вот лучше бы её параллельно реализовали. Схема Руслана гиперкрутая за счёт невероятной скорости обновления ЗГ.
Попробуйте написать что-нибудь более сложное, чем вывод разноцветного текста, сами поймёте, что не дураки i8275 разрабатывали. Им просто надо научиться пользоваться, этот контроллер покрывает все потребности РК! А теперь ещё и цвет нормальный будет!
E5/E4 - это LA атрибуты
Это атрибуты неиспользуемой псевдографической примочки (рамки Нортона).
где-то в тексте подчёркивание и перечеркивание уже не будет работать
https://www.youtube.com/watch?v=LqWOQEpzhDE&t=65
Это атрибуты неиспользуемой псевдографической примочки (рамки Нортона).
Я и говорю, что работа этой примочки целиком и полностью зависит от заданной настройках ВГ75 высоты линии подчёркивания. Если пользоваться этим атрибутом, придётся ограничивать себя в использовании подчёркивания. Например, невозможно будет перечеркнуть слово посередине, или что-то подобное, уж не знаю, как там у Виталия реализовано.
Ведущий_специалист
02.02.2025, 22:21
Второй ру10 лучше управлять отдельно. Мне видится это как выбор соответсвующей микросхемы одним из управляющих битов порта се00, там вроде есть незадействованные.
Еще один плюс в пользу отдельного управления озу цвета - в стандартном текстовом режиме можно получить раскраску текста (и при этом не использовать память под атрибуты!) и "писать" хоть черным по белому, хоть белым по черному, а можна как монохром - зеленым по черному, всего один лишь раз заполнив память цвета при старте компа...
Я вот в Вашей схеме никак не могу понять как Вы отключаете ПЗУ шрифта во время работы ОЗУ. У меня в пальмире спецом для этого кп11. Причем пытался развести уже ркшку вместе с этой схемой, у меня технически никак не получается всего три кп11.
Посмотрел Ваши наброски схемы с цветом. По сути именно так и хотел, единственно, раз уж не используются целых 2 бита от ЗГ (6 и7) хотел запрячь поработать их. Но в принципе Вы уже как то додумали включение цвета без их участия. Логику еще не продумывал но судя по запараллеленному адресу получается что уникальный цвет будет запрограммирован каждой строке КАЖДОМУ из 128 символов .
Схема реализации вывода цвета пока что не нравится - по мне чего то не хватает, но пока еще досконально не разбирался. Думаю если время позволит то в ближайшем будущем схему можно будет проверить живьем и внедрить в рк как официальную удобную доработку. Стоит отметить, что эту схему очень ждут программисты уже в железе. Да и сам бы не прочь уже чего нибудь на такое написать.
Вот кстати оперативное переключение фонта до 256 (которого очень прям не хватает). Тут нужно кооперироваться с Виталием и официально закреплять доработку переключения фонтов по е4/е5.
- - - Добавлено - - -
Я и говорю, что работа этой примочки целиком и полностью зависит от заданной настройках ВГ75 высоты линии подчёркивания. Если пользоваться этим атрибутом, придётся ограничивать себя в использовании подчёркивания. Например, невозможно будет перечеркнуть слово посередине, или что-то подобное, уж не знаю, как там у Виталия реализовано.
Зря. ИМХО атрибуты вообще нужно искоренить и далее упоминать о них как о вреде. Но е5/е4 надо оставить. очень удобно переключать банки фонтов, и Виталий это уже показал. А перечеркнуть слово посередине - даром не нужно учитывая какой муки это будет стоить (или вообще о чем речь не пойму.... какое еще нафиг перечеркивание).
Но е5/е4 надо оставить. очень удобно переключать банки фонтов, и Виталий это уже показал.
У Виталия цвет сделан атрибутами, поэтому и приходится извращаться т,к. свободных атрибутов нет. В схеме выше, все атрибуты свободны. Для банок фонтов опять же предусмотрены два атрибута общего назначения. Одним всключать программируемый ЗГ, вторым переключать банки. Почему вас так прёт всё сделать наоборот???
А перечеркнуть слово посередине - даром не нужно учитывая какой муки это будет стоить (или вообще о чем речь не пойму.... какое еще нафиг перечеркивание).
Мы этого не знаем. Главное правило программиста и инженера - если работает, не трогай! Жертвовать е5/е4 ради переключения банков - даром не надо. Использовать е5/е4 как сигнал прохождения лучом заранее заданной строки - да, можно пожертвовать подчёркиванием.
По схеме. Я бы ещё сразу во второй ИР27 защёлкивал все атрибуты + HRTC + VRTC. Последние два сигнала опережают вывод символа, что фигово для тех же конвертеров VGA и цветовых кодеров.
Я вот в Вашей схеме никак не могу понять как Вы отключаете ПЗУ шрифта во время работы ОЗУ. У меня в пальмире спецом для этого кп11. Причем пытался развести уже ркшку вместе с этой схемой, у меня технически никак не получается всего три кп11.
Посмотрел Ваши наброски схемы с цветом. По сути именно так и хотел, единственно, раз уж не используются целых 2 бита от ЗГ (6 и7) хотел запрячь поработать их. Но в принципе Вы уже как то додумали включение цвета без их участия. Логику еще не продумывал но судя по запараллеленному адресу получается что уникальный цвет будет запрограммирован каждой строке КАЖДОМУ из 128 символов .
Схема реализации вывода цвета пока что не нравится - по мне чего то не хватает, но пока еще досконально не разбирался
ПЗУ отключается очень просто - сигнал /CE_FONT заводится на ПЗУ знакогенератора. Вы неправильно его подключили в Пальмире, вот здесь я описывал подключение данной схемы к РК:
https://zx-pk.ru/threads/20714-pomechtaem-ili-vopros-o-videovykhode.html?p=713293&viewfull=1#post713293
"2. Сигнал /CE_FONT с разъема JP4 "DO" подается на выв. /OE DD12 РК (предварительно отрезав от земли"
Как я уже написал, использование старших 2-х бит с ЗГ я пока не доделал, но вот стал вопрос их применения - если их задействовать, то данную схему нельзя будет использовать в версиях РК где вывод сделан на VGA. Поэтому думаю... Больше уже склоняюсь к мысли их не трогать, и так 16 цветов на строку более чем достаточно, у Спектрума на всё знакоместо так и то умудряются красивые картинки рисовать...
Схему реализации вывода цвета специально сделал так - похожа на Спектрум, легче будет конвертировать графику.
и так 16 цветов на строку более чем достаточно, у Спектрума на всё знакоместо так и то умудряются красивые картинки рисовать
Достаточно! И в принципе переделать РК на отображение 8 точек в линии не сложно, без всякого VGA. Возможно даже, что это хороший вариант. Не все повторяющиеся тайлы (текстуры) можно вписать в прямоугольник, но почти все можно вписать в квадрат.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot