Разделение памяти между процессором и видеоконтроллером (Страница 2 из 2)

Более того, на Яблочке тоже такое есть: #1, #2.

Если на двухпортовке в виде отдельной карточки в слот:
1. При переключении на новую текстовую/графическую страницу получаем мусор до перерисовки экрана.
2. На слоте надо отслеживать запись не только всего адресного пространства памяти, но и регистр режима ДК $C7xx, регистры маппера $C1xx, Яблочные регистры $C05x. На слот это все прозрачно транслируется? Надо смотреть схему.
3. Новый ДК будет по определению не синхронизирован с основным, а значит "привет" эффектам с использованием таймерных прерываний (только на новом ДК!)...

PS. Не ПЛИС, а малинка и подобное (программная эмуляция железа в родном железе) - это резиновая женщина, ИМХО... :(

AlexBel, ИМХО, это совершенно очевидные вещи, и меня удивляет, что ты этого не видишь... :(

Ты не понял о чем речь...
Представь, ты включаешь АГАТ с новым ДК в таком слотовом исполнении. Без дисководов. Включается режим 2Т, Монитор переходит в режим диалога. Ты хочешь проверить работу ДК в режиме МГВР - обращаешься по $C703. Родной ДК переключается в МГВР и отображает содержимое нулевой страницы физической памяти: мусор по включению питания. Одновременно новый ДК также включается в МГВР - и должен показывать также содержимое нулевой страницы прозрачной копии физической памяти. А прозрачной записи-то в эту страницу еще не было... А содержимое после включения питания однозначно разное... Экраны двух ДК будут совпадать?

Это только один из примеров. Да, практическая ценность в этом стремится к нулю. Однако, истина остается истиной. Быть может, где-то в какой-то проге этот момент и проявится знАчимым.

Наверное, да (при условии, что все транслируется на слоты прозрачно).

Отслеживание регистра режима ДК - очевидно.

Аналогично и по Яблоку.

По мапперу: ДК умеет экранизировать в графрежимах всю физическую память 128КБ (все 16 страниц), в текстовых режимах только первые 64КБ. И разные страницы могут быть подключены на разные сегменты. Поэтому новому ДК нужно для себя дублировать маппер, чтобы правильно отслеживать прозрачную запись в страницы копии физической памяти из сегментов адресного пространства процессора.

Ох, сколько раз на форуме ты менял свои мнения и суждения... ;)

Рассинхронизация видеопамяти и допДК на старте не проблема - ни одна вменяемая прога не расчитывает на то, что память при включении будет заполнена чем-то предсказуемым. Тем более разные материнки изображали довольно разные картинки на старте.

Мне известно две ошибки в прогах, которые приводили к зависимостям от начального состояния ОЗУ: цвет курсора в Агат-Авторе при первом обращении к процедуре ввода (цвет задавался только в режиме редактирования и если обратиться к процедуре ввода до входа в редактирование текста то курсор был непредсказумого цвета). Также была какая-то ошибка в ИКП, в поиске принтера: если ячейки принтера нет, события развивались в зависимости от какой-то ячейки в ZP. Ненормальных, которые бы расчитывали на предсказуемое заполнение (видео)озу, не было.

Другое дело, что иногда, например, прога сперва чистила страницу, потом переключала c7xx, и только потом что-то рисовала на странице. Поэтому при эмуляции нужно будет держать на ДопДК полный объём базового озу. Что, по нынешним меркам, не так уж чтобы много.

А вот нужен ли мапер озу - дело не такое простое как кажется.
У семёрки мапер не нужн - базовые 32 кб на своих адресах всегда.
У девятки никто уже архитектуру IOSub не менял и там, во всяком случае текстовый режим, всегда мапиться при выводе
на те же адреса, что и в семёрке. Иначе придётся переделывать одну мелкую процедурку, которая расчитывает адрес строки в памяти из номера строки на экране и адреса страницы. Либо процедурку, которая расчитывает адрес начала страницы из программног о переключателя страницы. А кому оно надо ? Не думаю, что и в игрушках кто-то сильно напрягался.

Вообще, прог, которые бы использовали маппер девятки, не так уж много. Этим занимались, в основном, операционки и отдельные крупные проги, типа копировщиков. А игрушки, например, были тянуты с эпла или семёрки и им вполне хватало ОЗУ без переключений.

Насчёт совмещённых режимов ДК: вроде на этом форуме или ещё раньше - где-то были уже сообщения о том, что на девятках разных версий эти режимы работали по разному (что-то там с периодом прерываний). И, вроде бы, между семёркой и девяткой есть отличия. Реальные проги, которым это было нужно, были на семёрке, под Рапирой. Так что это можно выкинуть, практически ничего не теряя.

C1xx, С7xx, C05x - конечно они есть на слоте - кто бы и зачем их фильтровал на материнке ?
Как бы работала ячейка 121, если бы ей были недоступны C05x ?
Да и модули доппамяти ожидают полные шины адреса и данных для работы.

>  то GBS8200 стоит прмерно 1300 рублей.
Но нужно держать в зубках паяльник, чтобы сделать кабели для агата. И, возможно, потом ещё подстроить эту плату.

>  Если нужно HDMI, дополнительно конвертер будет стоить ещё 250р.
Купил я такой, только наоборот (hdmi -> svga), но он кой где работает, кой где- нет. А одна железка просто валится при его подключении - вроде как напряг просаживается, то ли кз из-за косяков распиновки, то ли что-то ещё, но не из-за питальник железки - он ещё ампер-два в запасе имеет.

Цели две: да, просто сократить место. И число проводов и, соответственно, сложность сборки агата (у меня он хранится разобранным). Слот, даже в набитой семёрке, есть свободный. И ещё - возможно, некоторое упрощение ремонтов.

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