Вектор-06Ц: Общие вопросы

[svofski]

У Вектора четко разнесены промежутки времени в которые память доступна процессору и видео. Сигналы формируются ПЗУ, но без схемы под рукой точнее не скажу. Отсюда растут ноги у знаменитой растактовки с округлением каждого М-цикла вверх до числа тактов, кратного четырем.

[ivagor]

Чуть дополню svofski конкретикой. Сигнал READY проца формируется из старшего бита РЕ3 D36 и двух бит слова состояния.

[Improver]

svofski, ivagor, вот сейчас разглядываю схему 02-го (там ПЗУшек меньше): сигнал МХ2 формируется триггером Д79.2 и, судя по схеме, он равен 750кГц, чистый прямоугольник с равными промежутками, что как раз и получается 1/4 от тактовой частоты 3МГц. И далее на его основе формируется сигнал "READY" для процессора триггерами Д85.2 и Д79.1, теперь стало более-менее понятно.

[Smalovsky]

А у меня такой вопрос.
Почему бы не совместить графические плоскости в одно адресное пространство по аналогии с EGA? Сэкономим 24 килобайта памяти, так как графическая память будет занимать участок в 8 килобайт, а не 32 килобайта.
Введем ещё два-три регистра:
маска плоскости(четыре бита по числу плоскостей). Запись по адресу графики вносит изменения в те плоскости, биты которых в данном регистре были установлены в 1.
маска битов. Для каждого байта в каждой плоскости запись по адресу графики изменяет те биты, которые были установлены в 1 в данном регистре.
номер плоскости для чтения( можно совместить с регистром маски плоскости, старшие биты - плоскость с которой читаются данные, младшие четыре бита - маска плоскости). Чтение по адресу графики получает байт плоскости чей номер в этом регистре.
Реально видеопамять будет адресоваться через 8 килобайт основной памяти, а не через 32.
Плюсуй, если согласен.

[LeoN65816]

В Корвете этот принцип реализован. Да, бейсиковский оператор PAINT работает очень шустро (именно для него эта аппаратная заточка). Однако, практическая графика в играх (спрайты) скорострельностью не блещет...

[Improver]

А у меня такой вопрос.
Почему бы не совместить графические плоскости в одно адресное пространство по аналогии с EGA? Сэкономим 24 килобайта памяти, так как графическая память будет занимать участок в 8 килобайт, а не 32 килобайта.

Что-то я не могу справится с арифметикой, чтобы охватить все точки нужно 256х256 х 4бита на цвет = 262144 бита на экран, если брать 8бит=1байт, то получается, что нужно никак не меньше 32кБайт памяти. Как можно их затолкать 8кБайт?

Ну и далее... Любое вмешательство в экран без сохранения полной совместимости со старым ПО, даже многократно улучшающее обращение к нему, приведёт к тому, что надо будет всё ПО переписывать заново. Можно, конечно, всё переделать, и даже, при должном умении, добавить в схему 2Д/3Д ускоритель, но если нельзя будет запускать старое ПО, то это будет уже не Вектор, а совершенно новый компьютер... :-( Имеет ли смысл сейчас изобретать такой велосипед?

[LeoN65816]

то получается, что нужно никак не меньше 32кБайт памяти. Как можно их затолкать 8кБайт?

Smalovsky имеет ввиду 8КиБ адресного пространства проца на все 4 параллельные цветовых плоскости, как у Корвета 48КиБ ГЗУ (3 цветовых плоскости) адресуются через 16КиБ адресного пространства проца.
НО! Вопрос Smalovsky: как/чем аппаратно ты планируешь использовать освободившиеся 24КиБ (0xA000-0xFFFF или 0x8000-0xDFFF)?

Ну и далее... Любое вмешательство в экран без сохранения полной совместимости со старым ПО, даже многократно улучшающее обращение к нему, приведёт к тому, что надо будет всё ПО переписывать заново. Можно, конечно, всё переделать, и даже, при должном умении, добавить в схему 2Д/3Д ускоритель, но если нельзя будет запускать старое ПО, то это будет уже не Вектор, а совершенно новый компьютер... :-( Имеет ли смысл сейчас изобретать такой велосипед?

Вероятно, Smalovsky подразумевает новую схемотехнику под новое ПО.
Как я уже отметил, работа с такой графикой будет тормознее, чем у Вектора в штате.

[Improver]

Smalovsky имеет ввиду 8КиБ адресного пространства проца на все 4 параллельные цветовых плоскости, как у Корвета 48КиБ ГЗУ (3 цветовых плоскости) адресуются через 16КиБ адресного пространства проца.

По всей видимости, мне надо будет посмотреть схему Корвета...

Вероятно, Smalovsky подразумевает новую схемотехнику под новое ПО.

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

[svofski]

Если это сделать опциональной фичей, то 4× выигрыш может быть на заполнении больших областей, очистке экрана, рисовании одноцветных спрайтов итд. Вопрос можно ли что-то подобное сделать ловким трюком с парой микросхем и маленьким мотком мгтфа, или это должна быть новая разработка?

[ivagor]

Несколько лет назад, когда баловался с разными модернизациями v06cc svofski собирался попробовать добавить ega/корветоподный доступ к плоскостям вектора. Меня тогда остановило отсутствие современного эмулятора с открытыми исходниками, чтобы добавить туда эту фичу для удобства разработки. Теперь есть аж два таких эмулятора, но у меня теперь недостаточно задора для этой штуки (хотя, если честно, скорее всего и тогда не хватило бы для чего-то стоящего). Ну и такой момент - параллельный доступ к плоскостям и организация памяти - это все же разные вещи, связывать их не обязательно. Можно оставить имеющуюся организацию видеопамяти (как я и собирался) с отключаемым параллельным доступом, можно добавить диспетчер памяти, гибко работающий с окнами по 8 Кб (а можно не добавлять, кваз Баркаря хоть и не идеально, но решает большинство проблем с организацией памяти).