А VGA он потащит?Сообщение от barsik
А VGA он потащит?
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
По мне забудте о ВГА на 8-битах. 555 не тащат 28Мгц=) И 20 не тащат. Сколько не читал (не тут, тут фантазеров хватает) 10 Мгц – это финал. Это касается только +5В, и всяких штук с 80г. А это львиная доля всего (форума).
- - - Добавлено - - -
Вот зачем вам ВГА – умерло для меня 15 лет назад (HDIM пришло на смену). А SCART – жив.
Электроника КР-02, MSX YIS-503IIR, Орион-128, Ленинград-2, Pentagon-128k, MSX2 YIS-503IIIR, MSX-EXT, ...
Нет, я имел ввиду буквально. На самом деле часа слишком много, достаточно нескольких минут. Но видимо, мы имеем ввиду разные вещи. Итак, сколько же времени надо, чтобы написать эмулятор VT52? Один час или "куда больше трёх недель".
Речь о том, чтобы на 8-ми разрядном компьютере или на PC обеспечить визуализацию символов поступающих из линии. Вопросы связанные с линией передачи не рассматриваем. Итак, есть скоростное ядро Z80B на такте 8 МГЦ с ОЗУ 62 кб на w24512 и ПЗУ РФ2 (там только BOOT), выдающее символы в линию. Какая же программа мне нужна когда в качестве терминала я хочу использовать ОРИОН-128 (процессор Z80, реальный такт 4 МГЦ, экран 384*256, кстати не плющенный).
Для получения терминала VT52 я загружаю в ОЗУ ОРИОНА драйвер, например, D6$, который работает в банке 0, грузится на векторы ПЗУ F800, даёт 64 символа в строке на 25 или 32 строки и обслуживает все основные управляющие коды VT52 (кстати, в том числе и вставка и удаление строки, т.е ролики вверх-вниз, что ускоряет работу редактора SuperText и Турбо-Паскаля). Дополнительно драйвер обслуживает управляющие коды для работы с окнами, в частности, открытие цветного окна, закрытие окна и вывод рамки окна с заголовком и без, и, естественно, поддерживает цвет.
Такой драйвер резко упрощает создание оконных программ. Так что всё что остаётся мне сделать, это написать программу, которая в цикле ждёт очередного символа с линии, после чего делает CALL F809. Итого, если считать, что приём с линии тут не рассматривается, то вся программа состоит лишь из одной команды Z80. Вопрос на засыпку, сколько времени мне надо чтобы набрать в текстовом редакторе одну строку и странслировать ?
Теперь расмотрим вариант, когда в качестве терминала я вдруг захочу использовать IBM PC. У меня есть рабочая 386-тая и 486-тая. Есть и несколько неиспользуемых VGA дисплеев. Т.е надо написать программу в MSDOS или в древних LINUX (например REDHAT 5.0 из 1998). Для MSDOS ещё с середины 90-тых у меня есть мой цветной драйвер 64 символа в строке для VGA для всех режимов до 16*640*480 (а вот SVGA режимов, т.е 800*600 и выше - уже нет). В нём обрабатываются основные упр.коды VT52. Итого, ситуация аналогичная - вся программа это одна команда CALL CONOUT.
А вот для LINUX придётся писать программку на Турбо-Паскале. Удобно написать и отладить именно на Турбо Паскале в MSDOS (Windows), а после отладки уже странслировать LINUX транслятором Паскаля, который совместим с Турбо-Паскалем (но не имеет IDE, поэтому отлаживать удобнее в Турбо-Паскале). Что так трудно написать на ЯВУ программу, которая выводит символ в текущую позицию экрана 80*25 (для позиционирования есть оператор GOTOXY)? Можно управлять и цветом. Т.к управляющих кодов VT52 довольно много, поэтому я и указал, что на разработку может уйти целый час. А если вдруг "приспичит" использовать в качестве терминала более современную IBM PC, где Windows изуродована до того, что уже не может запускать программы MSDOS, то кто мешает взять Турбо Паскаль для Windows или Delphi и странслировать эту же программу в консольное приложение.
Что за ерунда ? Даже примитивный ASM.COM Digital Research 1977 года создаёт PRN-файл, где отмечены ошибки трансляции. Это только в UNIX ошибки идут в отдельный канал. А что это за дурное СИ, если оно так неудобно. Бесконечный экранный буфер с возможностью прокрутки, это не из CP/M. Вы хотите, чтобы в Вашем терминале были возможности, которых в CP/M отродясь не было и не будет. Да и как можно в ДОС в которой всего 64К тратить ОЗУ на подобную ерунду? Если даже функцию 10 (ввод строки) за 40 лет не удосужились доработать, чтобы был тимплет символов (т.е память на ранее введённые строки) и удобное редактирование, рассчитанное уже на экран, а не на АЦПУ. Получается, что Вы сами себе придумали проблему, отчего пришлось изуродовать свои программы плюсиками вместо нормальной псевдографики и цвета.
Кстати, не понимаю зачем терминалу надо совмещаться лишь по управляющим кодам с М-2 ОРИОНА, где обслуживается всего лишь несколько управляющих кодов от VT52. У Вас же нормальная CP/M, а не CP/M ОРИОНА из 1990 года, где нет драйвера, а весь CP/M-вывод переадресован напрямую на п/п-мму F809 ПЗУ ОРИОНА.
Последний раз редактировалось barsik; 22.06.2017 в 00:21.
Ну свет на них клином... LS - самая тормозная серия (после 133/155).
Нифигасе умерло... из каждого телека и монитора торчит. А вот SCART (причем настоящий RGB, а не огрызок) поди поищи еще.
И VGA2HDMI конвертеров как говна за баней по три копейки за пучок.
Последний раз редактировалось TomaTLAB; 21.06.2017 в 23:03.
Вопрос д.быть таким: будет ли достаточная для VGA частота строк при желаемом числе точек в строке. Ведь можно получить VGA при низком пиксель клоке и всего 256 точках в строке, но кому это надо. В монохроме хватит (т.к зараз читается 16 бит), а вот в цвете с трудом. Готовую схему для VGA найти не удастся, т.к БИС была в моде, когда VGA еще не было. Но скорее всего достаточно в схеме для CGA просто поднять такт покуда тянет и получится VGA.А VGA он потащит?
GDC выпускаются на такт 2.5, 5, 6, 7 и 8 МГЦ. Но это не пиксель клок, а такт процессора. Связь между пиксель клоком, тактом GDC и частотой обращения к ОЗУ зависит от схемы. У меня 2 схемы моно адаптеров с GDC и ещё 2 словесных описания цветных схем. В схемотехнике я не разбирался, т.к рассчитывал лишь тупо повторить готовую конструкцию. В одной цветной конструкции пиксель клок 10 МГЦ (416 точек) частота обращения к ОЗУ в 8 раз меньше - 1.25 МГЦ. А в монохроме частота ОЗУ д.быть в 16 раз ниже пиксель клока. В [Литературе] описан GDC 1984 года с пиксель клоком в 20 МГЦ. Это почти VGA, т.к в РК86 с выводом на VGA по схеме Alex_LG стоит кварц 24 МГЦ.
Это не не проста шалабушка без мозгов типа ВГ75, 1809ВГ3, 6845 или V9938, что только и умеет отображать. А это процессор, он не только отображает, но и выполняет команды (попиксельное панорамирование во все 8 сторон, ZOOM, масштабирование, рисование линий, квадратов, кругов, эллипсов, работа с окнами и т.п). Но программирование очень сложное. На немецких форумах ругались, что ИНФО из даташита недостаточно. Похоже, никто и не использовал процессорные возможности GDC в радиолюбительских машинах, кроме как для обычного вывода текста и вывода статических картинок.
Кстати, и одна 7220 может работать с цветом. В журнале RFE 04/1988 и 04.1989 описаны цветные адаптеры GDC-1 и GDC-2 (2 банки РУ7, 4 плоскости), предназначенные для любой 8/16-ти разрядной ЭВМ. Эта БИС рассчитана для работы с графикой на машинах невысокого класса (первой половины 80-тых), для пакетов деловой графики (конструкторская документация, чертежи, принципиальные схемы, разводка печ.плат), но когда появились 386-тые и SVGA у которых мощности и плоскостей намного больше, то БИС стала не нужна. А для игр эта штука не подходит. Использовать её для вывода текста удобно, т.к деталей мало, но по сути это как из пушки по воробьям. Скорость вывода текста даже в графике быстрая, т.к можно использовать команду OTIR или DMA в РК86. Для вывода символов используется просто пересылка блоков.
Возможно, можно ещё больше упростить схему из FA 08/1990, использовав экранное ОЗУ на 8 бит (выбросив одну 62256 и один регистр ИР24). Хотя понадобится скоростная GDC (у меня как раз есть скоростная), т.к при том же такте получится экран только 320*200.
У меня есть русскоязычный ДОК на 1809ВГ4 (~100 листов), но я не собираюсь её программировать и разрабатывать для неё программы для работы с конструкторскими чертежами или принципиальными схемами. Достаточно дизассемблировать чужой BIOS, что поддерживает текст 80*25 и адаптировать это для своей ДОС.
[Литература]
Electronic Design, New York. 07/1984, Seite 135.
H.Assarpour. Graphic controller chip raises video data rate, is simpler to program.
'MC', Muenchen. 04/1985, Seite 136.
F.Oettle, T.Reichler. Die mc-Farbgrafik-Karte.
Radio Fernsehen Elektronk, Berlin. 04/1988, Seite 253.
T.Wolf, M.Fisher. Farbgrafikmodul mit Grafik-Display-Controller U 82720.
Microprocessors and Microsystems, GuildFord. Volume 8, Issue 6, July–August 1984, Pages 284-289
S.Manohar, N.Murali, L.Patnaik. Design of a Multibus-compatible colour graphics subsystem.
Купить даже не журнал, а лишь PDF-файл статьи за $35.95
Последний раз редактировалось barsik; 22.06.2017 в 05:25.
barsik, малое разрешение не подходит. В текстовом режиме 640х200 минимум. Ну и самое главное, 7220 труднодоступна и из-за этого дорога, а ВГ75 продаются на вес.
Последний раз редактировалось Xrust; 22.06.2017 в 05:45.
...в общем, тема ушла к обсуждению вторичной периферии, а о самом СР/М- компьютере ни слова...
rw6hrm, а что еще можно обсуждать? Периферия - это как раз то, что обслуживает ОС. Предложите, на что еще следует обратить внимание.
Ещё раз хочу пояснить суть темы: обеспечить максимальную совместимость с cp/m. Чтобы не пришлось потом мучиться, как с РК, например.
P.S. Проект сейчас развивается. Собираю отдельные узлы на макетных платах. Раньше работ такого уровня сложности делать не приходилось. Да и то, что делал, было ..дцать лет назад. Сейчас нахожу спустя годы некоторые свои поделки, и удивляюсь: неужели это мое? Так что мелкими шажками...
Пока что собрал узел на вм80а + гф24 + вк38 + ру10 + 2764 + мелочевка. Далее подключу вв51 и нужно будет что-то прошивать в ПЗУшку...
Последний раз редактировалось Xrust; 22.06.2017 в 09:53.
Не будем забывать, что ОС СР/М обслуживает себя через биос, который пишется для каждой отдельно взятой машинки в соответствии с применённым железом. Однозначно, все вопросы по периферии необходимо решать в свете подключения оной как устройств ввода/вывода. Мапировать периферию на общее поле памяти полный отстой (почему не стоит брать "Специалист" за базовую схему, к примеру). Далее, периферия не должна занимать ресурсов основного процессора и, соответственно, не отсвечивать в биосе. Иначе говоря, она должна "эмулировать терминал" - машинка выкинула байт в порт, далее этим байтом самостоятельно занимается периферия, и наоборот. Иначе мы получаем тормозную машинку, которая только и делает, что обслуживает периферию, а на собственно работу времени остаётся с гулькин нос. Поэтому считаю, что периферия вторична и заслуживает отдельного обсуждения по каждой железке. А как она будет подключена - по параллельной шине или последовательной - не важно. Главное - "стандартное", с точки зрения ОС, подключение к базовой системе. Расписали порты, что к чему подключать, и придерживаемся этого.
Что интересно лично мне, и в чём я до сих пор не разобрался - страничная адресация памяти. В идеале базовый вариант машинки должен содержать 64К ОЗУ с отключаемым загрузочным ПЗУ, вся память отдаётся ОС. Экран, как упомянуто ранее, должен сидеть в области адресации УВВ и иметь собственную память, не пересекающуюся с основным ОЗУ (как бы нам не хотелось сократить кол-во чипов). Далее, если юзверь вырос технически и организационно, он может добавить себе основного ОЗУ со своим управляющим блоком. Программно это уже должно быть стандартизировано в средствах ОС (вот только где, и какие базовые адреса под это зарезервированы в стандартной СР/М? Просветите плз). Причём надо предусмотреть различные варианты такого расширения - кто-то тащится от кучи РУ3/5/7, которых, как раз и просто "страничить", а у кого-то ( у меня, к примеру) есть куча статических ОЗУ по 32/64К каждая (из кэшей 486-х машин). Значит схема управления страницами должна быть разная, но одинаково выглядящая для софта.
Продолжаем разговор. В ТЗ до сих пор не определено, какой должна быть машинка, её базовый вариант и возможности расширения. По какой шине это должно быть соединено. ТЗ разрабатывается для одноплатной системы или многоплатной... Если для многоплатной, то всё уже сделано до нас - шина S-100 и полностью развязанные руки, максимальная совместимость, дело только за низкоуровневым софтом. Если одноплатный вариант, то обсуждать что-то канонiчное невозможно, каждый исходит из наличия комплектухи (см. разговор про м/с ОЗУ выше или Ваше, Xrust, сообщение). Для одноплатного варианта более чем подходит разработка Гранта Сирла, следует только заменить двойной SIO на удобоваримый ВВ51, хотя бы на один. Второй порт сделать параллельным как раз на дисплей/клаву, но программно он должен работать как терминал (выше описано). Кого припрёт - поставит шинные буферы. У кого есть время и возможности - сделает динамическое ОЗУ (подключаемое как статическое или отдельной платой в шину).
...а вы говорите - не на что обратить внимание...
Последний раз редактировалось rw6hrm; 22.06.2017 в 10:13.
27МГц там только регистр сдвига должен тащить, КМК.
- - - Добавлено - - -
А чем она, собственно, должна заниматься? Это же всё-таки ПК, как ни крути. А его основная задача - обслуживание периферии, опять-таки.Иначе мы получаем тормозную машинку, которая только и делает, что обслуживает периферию, а на собственно работу времени остаётся с гулькин нос.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
