Улучшение архитектуры Специалиста

Хочу обдумать в этой теме варианты улучшения своей платы Специалиста, чтобы сделать его пригодным под разные актуальные ранее (и также сейчас) задачи. Тут уже речь будет идти о существенных доработках, в основном связанных с тем, каким образом включить дополнительную банку ОЗУ 565РУ5. Задача увеличить ОЗУ, сохранив базовую архитектуру и сделать так, чтобы ОЗУ годилось не только под VDISK, но чтобы из него можно было работать с экраном.

Спойлер:

Базовый Специалист даёт 35.75 кб свободного ОЗУ, что едва больше половины адресного пространства процессора. Для размещения в ОЗУ игр этого достаточно, хотя 48 кб для этого было бы лучше (т.к у ZX-Spectrum почти все приличные игры имеют объём кода до 42 кб, при 35 кб можно конвертировать только мелкие игры ZX из сезона 1982-83 годов, когда он выпускался ещё с маленьким ОЗУ).

Проблема в своё время была лишь в том, где брать эти игры и другие программы для Специалиста. Их могли написать только сами пользователи Специалиста. Некоторые люди уже знают, что легче всего писать программы на языках высокого уровня (ЯВУ). Увы, Специалист не смог предложить разработчику ни одного ЯВУ (BEST-C и Паскаль от Микроши это не инструменты, а игрушки). И даже из ассемблеров Специалист мог предложить лишь тот же самый ущерный пакет разработчика, сделанный Барчуковым и Фадеевым для РК86. Неудобный полу-экранный редактор и убогий примитивный ассемблер позволяли странслировать лишь небольшой объём кода, максимум, в 2 кб.

Если программа имеет бОльший объём, то МИКРОН-ом приходилось транслировать код по кусочкам, переписывая на лист бумаги адреса внешних модулей, подпрограмм и переменных в модулях, и корректируя их при каждой перетрансляции в каждом модуле, затем транслировать по отдельности, выгружать объектный код на ленту, а затем все модули последовательно впритык загружать в ОЗУ (причём для этого нужен приличный RAM-монитор, допускающий загрузку не по адресам с ленты, а на произвольный адрес, а такой у Специалиста только один, это - ленинградский монитор Специалиста). И эту процедуру надо повторять при разработке серьёзной программы многие сотни раз. Неудивительно, что все крупные игры для РК и Специалиста написаны кросс средствами на Электронике-60 или ДВК (они тогда были массовыми ЭВМ в промышленности).

Если Вы встретите в тематических форумах человека, который утверждает, что по кусочкам создавать программы с объёмом более 2 кб на РК и Специалисте было очень удобно, сразу знайте, - это болтун, который сам никогда этим не занимался. Трудоёмкость такого процесса очень высока и быстро разрушает нервы программиста. ОРИОН увеличил свободное ОЗУ до 48 кб, но изначальная концепция, что банкой для программ является банка 0 (а банка 1 это лишь ОЗУ для цвета и хранения файлов ORDOS) позволили и на нём тем же примитивным ассемблером МИКРОН транслировать программы с объёмом кода лишь до 3 кб.

Единственным пригодным ассемблером для серъёзного программирования на ассемблере являются дисковые ассемблеры. Они не ограничены объёмом исходника и соответственно объёмом выходного кода (при желании можно странслировать одномодульную программу с объёмом кода более 64 кб, хотя я не могу подсказать, как её можно загрузить и прогонять с помощью CPU адресующего только 64 кб). Также и полноценные компиляторы ЯВУ есть только для дисковых ОС.

К сожалению, дисковые ОС нуждаются в дисках, т.е в каких-либо носителях в которых сохраняются файлы и сама ОС. Сами дискеты стоили тогда не очень дорого (всего 15 рублей за штуку, это цена ~20 обедов в столовой, или ~3-4 килорубля в современных реалиях), но вот цены на дисководы зашкаливали. Ретро флоп на 35/40 дорог с улиткой и резиновым пассиком и полезным объёмом диска в 140/180 кб стоил 250 рублей новый, 150 рублей - в хлам изношенный, а современный дисковод 5305 новый стоил 600 рублей (хотя б/у всего лишь 400), при окладе инженера в 130.

В принципе проблема диска для DOS решалась и дешевле. Путём использования эл.дисков из ОЗУ, как это впервые было изобретено в ОКЕАНЕ-240. 565 РУ7 стали доступны в 1989 и поначалу они были никому не нужны (т.к первые самодельные печ.платы, куда их можно применить, появились лишь в 1991, платы Правец-16). Эл.диск может быть внешним или организован из ненужного для программ ОЗУ самого компьютера. Это вполне удовлетворительное решения, хотя, если эл.диск не является энерго-независимым (т.е это не флэш-карта и не статика 62256 с батарейкой), то эл.диск надо загружать файлами с МГ-ленты (256К грузятся 20 минут).

Но увы, DOS, для которых имеются ЯВУ и ассемблеры, имеют одно неприятное свойство. У них почему-то объём кода непомерно (по меркам 8-ми разрядки) большой: ~10 кб (из промышленных ДОС доступна естественно лишь CP/M). CCP CP/M размером в 2 кб загружается в TPA, потому TPA обычно имеет адрес на 8 кб ниже RAMTOP. Если CP/M загрузить в Специалист или РК86, то для программ останется всего 27 или 20 кб соответственно. Для ЯВУ этого, естественно мало, но сАмому простому ассемблеру этого уже достаточно.

Все другие программы работать не будут, даже простейший текстов редактор WM.COM. Потому что, для экранных программ надо иметь драйвер VT52. Но чисто текстовые программы, которые выводят буквы только в текущую строку (если им хватает уровня TPA) работают без пробем даже на РК86 с TPA в 20 кб. Драйвер для экрана Специалиста сейчас (в отличие от 1990 года) существует, проблема не в его наличии. Приличный драйвер для графической машины занимает минимум 6 кб, а обычно 8 кб и более. А куда его загрузить в Специалисте?

А вот ОРИОН может предложить 60 кб сплошного ОЗУ и ещё 48 кб для загрузки драйверов. Даже не особо разбираясь в арифметике, нетрудно догадаться, что 60+48= 108 кб, - это намного больше, чем 35 кб, что даёт Специалист. А главное, - на ОРИОНЕ достигается TPA в 55 кб (у меня есть такая версия ACP/M ОРИОНА, я пользуюсь ей для ЯВУ, но широко-распространённые версии CP/M ОРИОНА дают лишь 51 кб TPA). Благодаря этому ОРИОН и стал привлекательным и буквально за год-полтора резко сократил популярность Специалиста. Потому нет игр для Специалиста написанных после 1991 года.

Довольно массовой версией платы в 1988-89 годах была кооперативная плата ЭКСПРЕСС, отличающаяся малым размером, числом корпусов всего 38 и использующая ОЗУ 565 РУ5. Я покупал такие кооперативные платки в магазине "Электроника" (в 1988 за 25, в 1989 за 38 рублей). Нетрудно сообразить, что при ОЗУ на РУ5-тых в адресном пространстве ПЗУ пользователя, т.е в области D000...F7FF, можно "открыть" 10 кб ОЗУ, располагающегося в старших под-ПЗУ-шечных адресах DRAM 565 РУ5 (т.к в эту область программы никогда не обращаются). Для этого даже не нужны микросхемы, это можно сделать диодами.

Потому версии CP/M Специалиста для дисковода вошедшие в моду в 1990-1992 годах использовали открытое ОЗУ в 10 кб в верхних адресах. Туда загружалась CP/M. Чтобы CP/M считала вершиной BDOS адрес 8F06, достаточно в ячейку 0006 поместить адрес 8F06, а с адреса 8F06 поставить промежуточный JMP в реальный BDOS (находящийся в верхнем ОЗУ) и 8 байтов векторов дисковых ошибок BDOS. Таким образом в CP/M достигается колоссальный размер TPA в 35.75 кб. Такого TPA уже достаточно, чтобы загрузить любые программы Специалиста (увы, для компиляторов ЯВУ этого всё-равно не хватает). Есть лишь с пяток программ Специалиста с размером в 31-32 кб.

Такая CP/M не имеющая VT52 вполне пригодна для использования как файловая система (т.е, лишь чтобы хранить и запускать старые программы Специалиста), но число пригодных программ для CP/M будет малым и даже годящиеся программы будут малополезны. Например, при запуске MBASIC-а с размером в 28 кб, ОЗУ для хранения бейсик-программы остаётся с гулькин нос. А если захочется воспользоваться MSX-бейсиком с размером кода в 33 кб, то программа на бейсике д.быть не более, чем в несколько десятков строк.

Такой CP/M достаточно, чтобы хранить и запускать программы, но для разработки ПО и даже для простейшей текстообработки нужен драйвер VT52 и повышение уровня TPA хотя бы до уровня 48 кб. В 1990-91 годах, когда такая CP/M использовалась на Специалисте, не была решена проблема драйвера VT52, т.к в базовом Специалисте его было просто некуда грузить. Но, если совместимость с играми Специалиста не важна, то т.к для нужд CP/M вполне достаточно 8 кб ОЗУ D800...F7FF, можно сделать ПЗУ 6 кб в адресах C000...D7FF, где ~2 кб занимают п/п-ммы ввода/вывода и ещё ~4 кб остаются для экранного драйвера VT52.

Но возможности базовой архитектуры Специалиста открытием верхнего ОЗУ ещё не исчерпаны. Ещё можно поставить ПЗУ 27256 (панелька на плате ЭКСПРЕСС под неё предусмотрена) и переключать это ПЗУ странично, что позволит разместить в ПЗУ 27256 и CP/M и драйвер. CP/M при этом придётся переделать для работы из ПЗУ (такой версии в Интернете пока не нашёл). Но TPA это всё-равно никак не поднимет. Экран с 9000 маячит по центру адресного пространства и его не убрать.

Чтобы поиметь TPA больше 35 кб остаётся только менять базовую архитектуру, делать существенные апп.доработки. Ясно, что высокий TPA был реально необходим только 30 лет назад, когда в стране было много любителей Специалиста, многие из которых пытались освоить программирование и писать программы. Чтобы поиметь инструментарий для этого и нужна была CP/M с драйвером и высоким TPA. Сейчас, очевидно, высокий TPA не актуален. Т.к на реальной 8-ми разрядке уже никто программы для неё не пишет. Есть гораздо более удобные в эксплуатации эмуляторы, кросс-средства для PC и возможность (если Win XP) использовать CP/M компиляторы в окне MSDOS (с помощью 22NICE и подобным).

Для запуска программ не нужен TPA более 32 кб, т.к программ Специалиста большего размера я пока не встречал. А если всё-же понадобится сделать программу крупнее 35К, то можно сделать её дисковой оверлейной. Тогда оверлеи будут по мере необходимости подкачиваться с дискеты. Все приличные компиляторы ЯВУ поддерживают разработку оверлейных программ, т.к для программ из под ЯВУ это особенно актуально. Ведь ЯВУ генерят исполняемый код, который (в зависимости от эффективности компилятора) даёт код в 4-6 раз больший, чем аналогичный код написанный на ассемблере.

Но так лишь с точки зрения пользователя. С другой стороны, т.е со стороны программиста, не всё так тривиально. ОЗУ TPA нужно не только, чтобы в нём уместить сам код программы, но и в этом ОЗУ хранятся данные, которые обрабатывает или использует программа. Например нортон с приличным интерфейсом.

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

Для программы сделанной под конкретную архитектуру уже не обязательно, чтобы доступное ОЗУ было сплошным. Оно может быть в другом окне (например в верхнем ОЗУ в 10 кб, странично включаясь вместо кода CP/M). Для использования под буфера не важно, где, в каком ОЗУ находится буфер. Важно лишь, что в нём можно временно сохранить данные. Но для скорости буфера д.быть в той же странице, где находится сама программа.

Для удобства пользования дисковой системой нужен удобный интерфейс. Даже просто для запуска игр, чтобы их посмотреть, удобно иметь нортон. Т.к молодёжь севшая за PC уже в эпоху Windows (т.е в последние 20 лет) уже не знают что такое нортон, поясняю.

Нортон это такая программа выполненная в так называемом, "текстовом графическом интерфейсе". Она выводит имена файлов в виде таблицы, обычно на две панели (но бывают и однопанельные, две панели ни к чему, если дисковый привод всего один). По именам файлов с помощью курсорных клавиш пользователь перемещает указатель в виде цветной или инверсной балки (называемой в литературе балкой подсветки) и выбрав таким образом файл, можно с ним осуществить какое-нибудь мероприятие (типа скопировать, переместить, удалить, переименовать и т.п). Некоторые операции можно сделать и с групой файлов. Для этого нужные файлы маркируют (обычно путём нажатия на пробел или клавишу <T>, от слова tagged). Маркированные файлы обычно отображаются другим цветом (а на монохромных машинах галочкой).

Нортоны для MSDOS обычно пишутся на Турбо-Паскале с использование ООП пакета Турбо-Vision, который как раз и предназначен для разработок в стиле "текстовый графический интерфейс". В этом интерфейсе можно открывать множество перекрывающихся цветных окон. Открываемые цветные окна могут иметь вертикальную (а иногда и горизонтальную) балку прокрутки (которая позволяет в маленьком окне прокручивать многострочные или широкие тексты), заголовок, рамку, а иногда даже строку состояния. Кроме того этот интерфейс предусматривает, так называемые, вертикальные спадающие меню. Это списки выбора (обычно команд), по которым вертикально перемещается указатель в виде балки подсветки. Чтобы исполнить какую-либо команду, пользователь выбрав перемещением балки подсветки нужную строку нажимает <ВК>. В интерфейсе есть и другие элементы. Для случая нортона можно ещё упомянуть строки с чек-боксами, они предназначены для задания параметров.

Увы, для 8-ми разрядки Турбо-Паскаль есть, но нет пакета для поддержки "текстового графического интерфейса". Если нортон нужно сделать более-менее удобным и красивым, весь интерфейс программисту приходится делать вручную. Конечно, возможен и совсем примитивный нортон без открывающихся окон, но он некрасив и пользоваться им неудобно. Лишь простую монохромную нортоно-подобную запускалку программ для Специалиста можно сделать имея всего 35 кб TPA. Но, для того, чтобы даже лишь монохромный нортон Специалиста был приличным, недостаточно всего 35 кб TPA. Нужно где-то надыбать ещё хотя бы 16 кб ОЗУ.

При 35 кб ОЗУ в CP/M не попользуешься SuperText-ом (это такая очень удобная программа для редактирования текстов), ему надо, минимум, 48 кб TPA и 200 кб диска. Более простыми текстовыми редакторами можно воспользоваться, если дополнить ПЗУ драйвером VT52. Для этого разумно ввести многостраничность ПЗУ. Удобнее всего сделать окно ПЗУ в 8 кб и из ПЗУ 27256 поиметь 4 страницы ПЗУ по 8 кб каждая. Тогда драйвер VT52 прошивается в ПЗУ, а CP/M довольствуется оставшимися 6-ю килобайтами в верхнем окне E000...F7FF.

Таким образом минимальная доработка Специалиста (не считая всего, что относится к дисководу или иному дисковому приводу), чтобы поиметь CP/M или другую DOS в минимально-приемлемом варианте, - это открытие верхнего ОЗУ в 6 кб и установка ПЗУ 27256 странично (с окном ПЗУ в 8 кб). В минималистском варианте можно ограничиться двумя страницами ПЗУ по 8 кб. Для коммутации всего 2-х страниц достаточно одного бита, в качестве которого дешевле всего задействовать бит НП из ППА клавиатуры. Расход деталей для такого тупого лобового увеличения ОЗУ на 6К и ПЗУ до 32К не превысит куска проволоки и нескольких диодов.

При этом мы получаем CP/M с TPA на ~34 кб (т.к ~2 кб ОЗУ ниже экрана уйдут под буфера CP/M) и за счёт присутствия драйвера VT52 сможем пользоваться текстовым редактором. Но важнее, что драйвер нужен для нортона. Скромный и почти корректный нортон, использующий драйвер D6, со шрифтом 6*9 имеет размер менее 10 кб, хотя, т.к монохром, то он может открывать всего одно окно, выводя его инверсно.

Двухбитовый цвет А.Волкова позволяет лишь незначительно украсить и улучшить интерфейс. Кстати, резко улучшить родной цвет Специалиста можно и при двух битах на цвет добавив РПЗУ для переназначения логических цветов в физические и 4 или 8 палитр. При этом расход деталей (не считая 2 штуки 565РУ6 плюс несколько TTL-корпусов в схеме цвета) увеличится на 155РЕ3 и двух (или четырёх) битовый регистр для кода палитры. РПЗУ позволяет тем же 2-битовым кодом задать цвет не только INK, а как INK, так и PAPER. Но из-за двухбитовости - всего 4 сочетания цветов. Для системных программ этого достаточно. Не стеснённые в средствах владельцы Специалиста могут добавить и третью 565РУ6, что в такой схеме даст уже 8 сочетаний цветов (чего достаточно для всего).

Для более красивых шрифтов и специальных оконных драйверов, 34 кб TPA уже недостаточно. Есть ещё один вариант для однобанкового Специалиста (использующий заворот верхней памяти), что позволяет использовать банку 565РУ5 не всего лишь на 48+6= 54 кб, а на полные 64 кб. Для однобанкового Специалиста это очень неплохая и прогрессивная идея (т.к позволяет увеличить TPA). К сожалению, пока нет поддержки этой концепции эмуляторами.

Кроме вышеприведённой идеи (с заворотом верхней памяти) можно просто открывать целиком всё под-ПЗУ-шечное ОЗУ C000...F7FF (например, записав в порт F800 по биту D7 единицу). Это добавит лишь 14 кб ОЗУ (т.е всего 48+14= 62 кб). Такой вариант тоже имеет свои преимущества. В частности, с таким режимом FULL RAM, удобно разрабатывать и отлаживать ПЗУ C000, что важно на этапе разработки. Я имел такой вариант с сплошным ОЗУ в 62 кб в начале 90-тых (код ROM-BIOS грузился на C000 по сбросу из стартового ПЗУ 8 кб включённого с адреса 0).

Но мне лично всё-равно недостаточно одной банки РУ5 в Специалисте, даже если она используется на все 64 кб. Нужно, как минимум две банки 565РУ5, что с учётов 2 кб на порты, даёт всего 62+62= 124 кб. Вторая банка мне нужна даже не для целей эл.диска. Эл.диск из ОЗУ нужен для отладки дискетного и винчестерного ПО, а в готовой системе нужен для копирования файлов на одном дисководе (иначе с одним НГМД замаешься переставлять дискеты при копировании файлов).

Кроме того при наличии второй банки ОЗУ с 62 кб, можно иметь в ней CP/M с TPA в 55-56 кб, что очень хорошо для компиляторов ЯВУ, хотя на реальном Специалисте транслировать программы на ЯВУ сейчас никто не станет, т.к это делается слишком медленно. Реальная программка в 20 кб кода на Паскале МТ+ транслируется 5 минут, не считая линковки модулей. А компилятор PLMX будет транслировать программку в 20 кб, вероятно, минут 20 (и это при непрерывном износе дискеты), хотя 20 кб кода сгенерированного PL/M это намного более крупная программа, т.е содержит намного больше строк исходника, чем исходник на Паскале давший 20 кб кода от компилятора Паскаля (это потому что PL/M даёт в разы более плотный код, чем Паскаль).

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

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

Как оказалось у меня есть одна точно рабочая банка 565 РУ7 (стоит в эл.диске) и ещё пару банок возможно удастся собрать из кучки поддохших РУ7, что не проходят тест в эл.диске (потому что там период регенерации большой, а в самом Специалисте он малый, так что полудохлые РУ7 с утратившими ёмкость накопительными конденсаторами ещё вероятно смогут пару лет проработать при маленьком периоде регенерации).

При РУ7 в Специалисте возникает дилемма. Дилемма между РУ7 и РУ5, т.к у них разная регенерация (у РУ5 - семибитовый вектор регенерации, а у РУ7 - девятибитовый). Заменить РУ7-ми все РУ5-е не проблема, - я так сделал в своём Специалисте в 1990 году (для этого достаточно соединить выводы 1 на панельках для 565 РУ7 и перекинуть две цепи адресов, т.е требовалось подпаять 4 проводка). Проблема в том, что когда основное ОЗУ на 565 РУ7, то и для цвета надо тоже ставить 565 РУ7 (т.к мультиплексор адреса - общий). Это не очень экономично, особенно, если делать 16 цветов.

Можно конечно оставить имеющуюся банку РУ5, а банку РУ7 для страниц ОЗУ 1...4 смонтировать на платке прикрученной к основной плате. Но сейчас для меня это слишком утомительно, нужны самые простые варианты. Т.е или всего 2 банки РУ5 или неэконмично банка РУ7 и ещё 6 штук РУ7 на цвет.

Если задаться вопросом, что для игр лучше, - базовая ИРИША или базовый Специалист, то базовая ИРИША даже с учётом её вдвое меньшего быстродействия (которое легко поднимается в 1.6 раза с помощью доп.платки из 2-х корпусов) вероятно предпочтительнее, чем базовый Специалист без цвета или даже с журнальным цветом. Т.к в ИРИШЕ есть попиксельный цвет и свободного ОЗУ в 1.5 раза больше. В обоих случаях скорости и объёма ОЗУ маловато для достаточно объёмной и крутой игры.

Но если противопоставить Специалист и ИРИШУ в задаче разработки достаточно объёмной и крутой игры, допустим, "Принц Персии" или файлового менеджера в стиле GUI, то в голову приходят следующие соображения.

Для базовой ИРИШИ  "Принца Персии" сделать невозможно (имеется в виду, чтобы было не со скоростью артритной улитки, вызывающей быстрое засыпание игрока). Но это всё-же кое-как возможно на несложно доработанной ИРИШЕ. Имеется ввиду введение бестормозного ОЗУ, что ускоряет реальное быстродействие до 1.77 МГЦ (1.77 это не учитывая доступ в экран, т.к доступ в экран всё-равно тормозится). Получится плохо, т.к даже такая повышенная скорость на 35...40 % ниже, чем у Apple-IIe для которого программист Джордан Мехнер оригинально написал игру "Принц Персии".

Вариант повышения клока CPU при его работе с медленным ОЗУ даёт незначительное ускорение. Большой рост скорости даёт сочетание бестормозного ОЗУ с заменой на плате ЦП процессора КР580 на Z80 и удвоением его клока. При 3.54 МГЦ клока Z80 среднее быстродействие будет ~3 МГЦ, по причине того, что в ИРИШЕ половина адресного пространства всегда тормозная (~1 МГЦ) и доступ в экран программы даже из быстрого ОЗУ всегда тормозится.

Значительно бОльший рост быстродействия даёт применение альтернативной платы ЦП на Z80 с встроенным ОЗУ (при этом родная плата ЦП на КР580 временно отключается). Вариант с отдельной платой Z80 (что уже не ИРИША, а другой компьютер с граф.адаптером ИРИШИ) позволяет поиметь скорость прогона аж до 8 МГЦ (и даже выше, если удастся поиметь Z84C0020, w24257 должны работать без WAIT при 20 МГЦ). Но такая доработка ИРИШИ достаточно трудоёмка.

Как обстоит со Специалистом? Он при Z80 без хлопот турбируется до эффективных 3.2 МГЦ - это достигается при кварце 9 МГЦ и Турбо с WAIT (клок Z80 4.5 МГЦ, ОЗУ на 2.25 МГЦ). При желании можно получить и реальное быстродействие в 4 МГЦ (кварц тот же 8 МГЦ, но двойное Турбо), но это может потребовать подгонки фронтов и замены 589 АП16 на 1533 АП6.

Теоретически, возможно разогнать Z80 в Специалисте и до 8 МГЦ, но это не поднимет реальное быстродействие намного (~4.75 МГЦ), т.к ОЗУ на 2 МГЦ сильно тормозит процессор и 8 МГЦ клока Z80 ускоряют только его внутренние циклы. Конечно при полной переделке Специалиста под статическое ОЗУ можно достичь и большего быстродействия, но все мои платы Специалиста на РУ5, для статики слишком много переделок.

Потому выбор стоит между Специалистом имеющим быстродействие 3.2 МГЦ и ИРИШЕЙ с пока неизвестным быстродействием, - потенциально в простом варианте менее 3 МГЦ, а в более сложном (на новой плате ЦП) : ~7 МГЦ (это 8 МГЦ клока Z80 с некоторой потерей из-за медленного доступа в экран).

Теперь сравним по архитектуре. Архитектура Специалиста с увеличенным до 128 Кб ОЗУ (см.картинку ниже) вероятно оптимальна. Здесь лишь открывается ОЗУ в неиспользуемой области выше ПЗУ и добавляется одна или несколько банок ОЗУ, коммутируемых в окне 62 Кб. Если есть внешний привод, то в Специалисте, как и в ИРИШЕ, вполне достаточно 128 Кб.

В отличие от ИРИШИ, в Специалисте программа из любого места ОЗУ работает с одной скоростью. А в ИРИШЕ из 64 Кб адресного пространства программа в его половине 32 Кб будет прогоняться быстро, а в остальных 32 Кб медленно со скоростью ~1 МГЦ. Это не особо вредно, т.к критичные к скорости прогона участки можно размещать в быстром ОЗУ. Для ОЗУ 128 Кб диспетчер памяти ИРИШИ немного более удобен.

Сравним экраны, графику и цвет. Цвет Специалиста не тормозит, тогда как вывод в цвете в ИРИШЕ тормозит вдвое. 8 цветов в групповом режиме для игры предпочтительнее, чем 4 цвета пусть и с попиксельным разрешением. Организация самогО экрана у Специалиста, естественно, лучше, чем у ИРИШИ (т.к INC R быстрее и удобнее, чем загрузка регистровой пары плюс двухбайтовое сложение). Для игр важно, что у Специалиста темп прогона абсолютно ровный, а темп прогона ИРИШИ скачет как сумасшедший в зависимости от положения луча на экране и того, откуда читается машинная команда (и арифметика помочь в рассчёте длительности времени прогона фрагмента бессильна).

Ещё следует учесть, что платформа Специалиста всё-же реально существует, тогда как платформа ИРИШИ с полным основанием может считаться практически вымершей, а возможно и мертворождённой.

Архитектура Специалиста с доработкой до двух банок 565 РУ5:



Учитывая тормознутость и громоздкость ИРИШИ, ранее я собирался заниматься Специалистом с улучшенным цветом и с доп.ОЗУ в 32К (что сделать просто, - достаточно в панельку 28 ног поставить 62256 и добавить логику коммутации банок), что даёт для программы ОЗУ (35.5 + 6 + 32) = 73.5 Кб. Под 6 Кб имеется в виду верхнее ОЗУ, открытое над ПЗУ (см.вышепоказанную карту памяти), а 32 Кб это доп.ОЗУ на статике, что при переключении банки включается в окне 0...7FFF.

Это весьма простая в аппаратном исполнении доработка - по сути требуется монтаж проводками только цвета, (который конечно не журнальный, а доработанный, чтобы был цвет фона, а не только цвет букв). И к тому же ещё остаётся возможность при нужде, напаяв второэтажную 62256, получить целую банку доп.ОЗУ в 62 Кб (но для начала и 73 Кб вполне хватит).

Но буквально несколько дней назад Виктор подсказал идею введения второй платы ЦП в ИРИШУ. Которая уже может быть на порядок проще, чем базовая плата ЦП на КР580, т.к никто не заставляет тащить в эту плату всякие малополезные извраты из базовой платы ЦП на КР580 и, главное, - она может быть на совершенно любом микропроцессоре (понятно, что имеются ввиду CPU с 8-ми разрядной шиной) с любым клоком, который он осилит. Конечно изготовить это трудоёмко, но результат по параметрам шикарный. В то время, как для Специалиста труд по его доработке невелик.

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

Не нужно умирать с голоду, сделайте, точнее замутите уже МП-Z80, а там я и платку по схеме разработаю, и может и памяти подкинем на неё, заодно...

Viktor2312 пишет:сделайте, точнее замутите уже МП-Z80

Тут два варианта о какой платке речь.

Во-первых, можно вести речь о полноценной плате ЦП на произвольном процессоре. Хоть на том же КР580 (с ВК28), но разогнанным до 3.5 МГЦ (с радиатором), которая будет отличаться от родной платы ЦП ИРИШИ лишь отсутствием трех ненужных БИС, разумным использованием ППА (т.е без мультиплексора на входах) и, если CPU Z80, то даже без буферизации (чем процессор скоростнее, тем мощнее у него выходы, потому было правильно покупать Z80B, а не A).

На такой плате, кроме задающего генератора и CPU понадобится лишь адаптер ASCII-клавиатуры 589 ИР12, ПЗУ 27256, ОЗУ 62256/w24257 и иришин диспетчер памяти. ОЗУ 32К ставится в дырках карт 1 и 3. Этого достаточно для совместимости по играм. На базовой ИРИШЕ игра идёт в карте 2, и тут может идти в карте 2 и, увы, с той же скоростью. Но специально переделанная для карты 1 программа может работать быстрее (т.к тут есть 32 кб бесторомозного ОЗУ с которым прогон в 1.6 раза быстрее). Т.к на высокой частоте КР580 много не тянет, возможно понадобится буферизовать адреса (данные уже буферизует ВК28).

На такую плату можно поставить и второй ППА. Который, в принципе, можно попробовать сделать универсальным. Имею в виду, что если напрячь серые клеточки мозга (как говорил Эркюль Пуаро), можно попытаться IDE-контроллер подключенный к этому ППА встроить в плату и сделать так, чтобы он не конфликтовал с другой периферией подключенной к ППА. Удобно, когда этот же ППА послужит для подключения УФ-ПЗУ прошивателя, РПЗУ-556 прожигателя и ROM-диска от ОРИОНА/РК86.

В этом случае контроллер IDE-винта не придётся паять на картонке (всего две дешёвых TTL-микросхемы) и подключать в разъём. Но т.к деталей на плате всё-равно немного, можно для контроллера IDE-винта поставить и отдельный ППА, причём так чтобы при незапайке деталей от контроллера IDE он мог обслуживать контроллер microSD от vinxru.

Такая платка получится всё-равно вдвое меньше стандартного конструктива плат ИРИШИ. Если надо дотянуть размер платы до стандартного, то можно добавить банки ОЗУ на статике (что потребует буферов) или занять макетным участком (слепышом). Хотя, чтобы не страдало быстродействие ИРИШИ (из-за несинхронности базового ОЗУ) достаточно всего 32К статики (т.к всё-равно больше, чем 32К в адресное пространство скоростной памяти не включить, так уж устроена ИРИША). А с Z80 можно поиметь намного более высокий клок, хотя при этом возможно понадобится больше буферов.

Но это полноценная плата ЦП. Имея которую родную плату ЦП ИРИШИ останется только вытащить из крейта и выкинуть, т.к она будет вообще не нужна. Но для меня это слишком уж сложно. В смысле, я эту плату разработать конечно могу, но спаять её у меня точно не хватит энтузиазма.

А я думал о плате для CPU работающем как сопроцессор, которая во многие разы проще (менее 10 корпусов), отчего её удастся спаять проводками всего за пару дней. А именно, - вот об этом (ссылка работает для зарегистрированных).

Заняться ИРИШЕЙ я всё-ещё подумываю, и если соберусь, то недельки через две. Да ещё несколько дней уйдёт на её восстановление. И так как те, кому хоть что-то по ИРИШЕ интересно, отсутствуют как класс, отчего без разницы, что мне делать с ИРИШЕЙ, то велика вероятность, что я не удержусь и займусь изготовлением платки сопроцессора не на КР580 или Z80, а на более приятном процессоре.