Что максимум можно выжать из КР580ВГ75 Intel 8275? Обсуждение

[freddy]

Усё пришлось переработать заново. Оказалось, что схеме таки не помешает чтение буфера и регистров. К этому меня подтолкнуло наличие светового пера. Это ж одна из изюминок ВГ75. В современных видеочипах такого нет. Вот я и подумал что не плохо было бы его читать Так я родил новый дешифратор сигналов управления шины, а сама читалка обошлась в еще один регистр КР580ИР82.
Поясню немного как оно работает, вдруг кто то захочет приколхозить в самодельный комп. Входные сигналы IA0-IA15, ID0-ID7, ~RD,~WR, ~RES. И так если на шине адреса диапазон адресов видеоадаптера (выбирается джампером), то дешифратор U14 разрешит прохождение сигналов ~RD, ~WR в схему (с помощью U17A, U17B), там они называются ~MWR и ~MRD. Они заведены на свои обработчики прерываний. Кроме того по ~MWR или ~MRD происходит автоматическое защелкивание адреса и данных в буфере U16, U18,U19. Таким образом у мозга видеокарты есть достаточно времени, чтоб оттуда их забрать, так как следующий цикл записи шины наступит еще не скоро (по меркам AVR). Дальше ничего интересного. Через 7 тактов AVR выпадет в прерывание и еще через 3 такта буфер данных и адреса будет считан. Всего в обработчике 11 тактов (с учетом выхода из прерывания), что обеспечит не хилый такой показатель в 1000000 сивмолов в секунду при тактовой 20Мгц. Это если постоянно не писать на каждый символ атрибуты. Если атрибуты вообще не нужны, то тогда можно подать единичку на IA0 видеокарты.
По сигналу ~RD происходит выдача данных из защелки U20. Она также облегчает AVR жизнь и способствует повышению пропускной способности - не нужно париться о длине сигнала ~RD. При чтении реакция немного другая. В буфере U16, U18,U19 все также защелкивается какая то ботва с шины. Только теперь пофиг что в U16, важен только адрес U18,19. Обработчик прерывания защелкнет нужные данные в регистр U20. И основной проц при следующем цикле сможет их оттуда взять. Т.е. самый первый цикл чтения ничего не даст. Зато в последующих циклах чтения будут всегда возвращаться данные предыдущего цикла. В итоге при чтении любого блока или рандомных ячеек, получаем всего один левый цикл.
Схема и печатка в файле. На печатке оставил место под плюшки. Буду признателен, если кто то проверит печатку на соответствие схеме, так как я ее пока еще не заказывал. Вложение 58600

- - - Добавлено - - -

Еще сорри за многословие. Чего то прорвало сегодня. Проанализировал свою схему и... понял, что она приспособлена под графический режим. Входная защелка на 16 адресных линий и данные уже есть. Дешифратор есть. Только немного по-другому развести, чтоб текстовый буфер занимал 4к гдето в первой половине, а графический буфер 32к второй половины. Итого 36к. Вполне можно пожертвовать и забить на текстовый экран и не дешифровать его в графическом режиме. но однако тут потеряется одна из очень вкусных плюшек - спрайтовый движек и возможность нелинейного разворачивания графического буфера.
Итого насчитал 5шт К555КП11, 1шт КР580ВА86, 1шт SRAM 32кб, 1шт К555ЛН1. Итого +8. Можно выполнить в виде Add On карты и цеплять сверху в сокет ПЗУ. При этом схема сможет программно переключаться, ничего не сломается, все достигнутые плюшки сохранятся. В графическом режиме можно подгрузить свой знакогенератор и тоже рисовать текст через текстовый буфер. В графическом режиме будет только монохром.

[Advertiser]

[Error404]

Проанализировал свою схему и... понял, что она приспособлена под графический режим. Входная защелка на 16 адресных линий и данные уже есть. Дешифратор есть. Только немного по-другому развести, чтоб текстовый буфер занимал 4к гдето в первой половине, а графический буфер 32к второй половины. Итого 36к.

А сложно ли будет реализовать несколько текстовых экранов? Чтобы с хоста переключать какой из них активный и какой видимый? Раз уж к Меге добавляется ОЗУ в которую она имеет доступ? Поставить SRAM более емкую (напр. 64к) и добить до 32к+4к+4к+4к+4к+4к+4к+4к+4к. Ну или сделать чтобы те 32к были бы либо одним графическим экраном, либо 8 шт. текстовых (переключаемый режим).
В текстовом режиме по записи хостом в "регистры обмена" по прерыванию Мега перепишет данные из регистров в SRAM в активный текстовый экран, а при отрисовке по запросу ДМА от ВГ75 на выводе строки выдаст данные не из своего внутреннего ОЗУ, а из внешней SRAM - со смещением по адресу видимого текстового экрана. Это было бы мегаудобно для многозадачных текстовых ОС (например UZIX/FUZIX).

[freddy]

А сложно ли будет реализовать несколько текстовых экранов? Чтобы с хоста переключать какой из них активный и какой видимый? Раз уж к Меге добавляется ОЗУ в которую она имеет доступ? Поставить SRAM более емкую (напр. 64к) и добить до 32к+4к+4к+4к+4к+4к+4к+4к+4к. Ну или сделать чтобы те 32к были бы либо одним графическим экраном, либо 8 шт. текстовых (переключаемый режим).

Это не к меге добавляется ОЗУ. Это для ВГ75 ОЗУ знакогенератора. Мега туда писать не сможет, только компьютер будет иметь доступ, и только аппаратно все будет.
У меги задача заставить ВГ75 разворачивать графический буфер в заданной последовательности. Можно играться например с нелинейным отображением кусочков графического буфера. Для меги то он состоит из 4000 спрайтов 16х8 точек. Можно читерить.

В текстовом режиме по записи хостом в "регистры обмена" по прерыванию Мега перепишет данные из регистров в SRAM в активный текстовый экран, а при отрисовке по запросу ДМА от ВГ75 на выводе строки выдаст данные не из своего внутреннего ОЗУ, а из внешней SRAM - со смещением по адресу видимого текстового экрана.

Где то выше я уже писал, что так можно, нужно приладить под текстовый режим меге еще одну SRAM. Пока так делать не буду, с внутренней памяти резвее работает. При переключении задач, можно экран перерисовывать из компа. 4000байт переписать - это очень быстро, а без атрибутов 2000байт еще быстрее. На глаз будет не заметно.