Флейм только по теме "Радио-86РК".

Разработчики РК86 при желании могли сделать РК86 существенно более скоростным. Для минимального ускорения на 14% даже не надо доп.деталей, достаточно сделать один разрез печати и кинуть один проводок. Ускорение на 70% обойдётся в припайку вторым этажом одной не очень дорогой TTL-микросхемы и замену кварца. А для ускорения более, чем в 2 раза потребуется дополнительно выкусить на плате 155 ИЕ4 и запаять на её место 155 ИЕ5. А вот чтобы ускорить РК86 более, чем в 7.5 раз потребуется, наряду с заменой процессора КР580 на Z80, спаять проводками на макетке внешнюю платку содержащую около десятка микросхем.

На выходе 155 ИЕ4 присутствует частота 1.333 МГЦ, что является частотой смены знакомест (по аналогии с пиксель-клоком можно обозвать знакомест-клоком), а также частота 2.666 МГЦ. В оригинале ВТ57 тактируется частотой 1.777 МГЦ и этот его CLK вовсе не обязан быть синхронным с тактом процессора. При подаче частоты 2.666 МГЦ вместо 1.777 МГЦ ПДП ВТ57 будет в 2.666/1.777= 1.50 раза быстрее загружать буфера ВГ75 и соответственно отнимать у процессора не ~25% времени, а в 1.5 раза меньше, то есть 25/1.5= ~16.6%. Таким образом процессор будет полезно скворчать не 75%, а уже 100-16.6= 83.4 процента общего времени. Т.о эффективный такт составит - 1.77*0.834= ~1.48 МГЦ, что на ~14% быстрее, чем скорость оригинала. Да и программные звуки станут вдвое менее хриплыми. Частота 2.666 МГЦ также оказывается удобной при установке процессора Z80. Более высокая частота CPU уже снижает надёжность без принятия особых мер.

Т.о торможение работы CPU из-за ПДП при клоке ВТ57 в 2.66 МГЦ составляет 14%. У меня 580 ГФ24 нормально заводился с кварцами до 35 МГЦ (естественно при условии, что кварц включён последовательно с фазосдвигающей ёмкостью в 3-4 пф, иначе он генерит не то). Для видеосхемы, т.е для работы ВГ75 нужна частота 8 МГЦ (она присутствует на выводе D3/12). Частоту 8 МГЦ можно получить не только делением 16 МГЦ на 2, но и как недавно удалось обнаружить, частоту 8 МГЦ можно получить и из частоты 24 МГЦ с помощью делителя на 3.

Если, используя это ценное открытие, у ГФ24 поставить кварц 24 МГЦ, то такт КР580 и ВТ57 как раз и будет 24/9= 2.666 МГЦ, а эффективная скорость процессора составит 2.666*0.834= 2.22 МГЦ (т.е такая же как во Львове, где ГФ24 с кварцем 20 МГЦ). Такая скорость в ~1.7 раза быстрее оригинального РК с кварцем 16 МГЦ.

Для получения необходимого пиксель клока 8 МГЦ понадобится смонтировать только одну микросхему 155 ТМ2, на которой собирается делитель на 3, хотя конструктивно удобнее на стоящую на плате 155 ИЕ4 напаять сверху 155 ИЕ5, включённую как делитель на 3.

Ещё более приятное ускорение достигается при применении у ГФ24 кварца частотой 28 МГЦ при одновременном расширении фонта с 6 до 7 пикселей. Для этого вместо 155 ИЕ4 (делящего 8 МГЦ на 6) требуется поставить 155 ИЕ5 (делящий 9.33 МГЦ на 7). При этом знакомест-клок остаётся тем же (1.333 МГЦ) и, соответственно, параметры видео сигнала остаются стандартными. Знакоместо при этом становится 7*8 пикселей (симпатичный фонт, у меня первоначально в РК86 стоял такой фонт, взятый, кстати, от Apple-II, где знакоместо в текстовом адаптере также шириной в 7 точек), отчего в псевдографике левые пиксели в матрице разложения знакоместа 2*2 на четверть уже правых (это потому что, как известно тем, кто ещё помнит арифметику: 7 нацело не делится на 2).

Зато при таком кварце такт КР580 и ВТ57 будет 28/9= 3.11 МГЦ, а эффективный такт процессора составит ~2.67 МГЦ (что быстрее, чем самый скоростной советский 8-ми разрядный компьютер ОРИОН-128 с его 2.5 МГЦ). Заметим, что всё что требуется переделывать для такого ускорения (и попутно улучшения фонта) - это лишь заменить кварц на 28 МГЦ,  впаять 155 ИЕ5 вместо 155 ИЕ4 и сверху на неё смонтировать вторую 155 ИЕ5 (в качестве делителя на 3). В принципе при ширине знакоместа в 7 точек псевдографический пиксель по горизонтали можно сделать "лесенкой", т.е чётные линии в пикселе состоят из 4 точек, а нечётные из 3 (но ещё не факт, что это лучше выглядит визуально).

Более кардинальное ускорение в 2.67 раза при том же процессоре КР580 можно поиметь, если всю основную плату РК86 отдать на нужды видео-отображения, отделив эту часть схемы от остального МП-ядра с ОЗУ и ПЗУ буферами АП6. Для этого выкусываем (или как-то иначе удаляем) из платы CPU КР580, обе ППА ВВ55 и ПЗУ F800, а через системный разъём ГРПМ-61 подключаем платку реализующую МП-ядро, содержащее все эти выкушенные элементы, плюс ОЗУ w24257 (и, естественно, для совместимости реализуется та же адресация), но это МП-ядро подключается к шине платы РК уже через три буфера АП6. Эти буфера при работе аппарата почти всегда закрыты и открываются только кратковременно во время обращения процессора в экранное ОЗУ выше 7600 и для доступа к ВТ57 и ВГ75. У ВТ57 соединяем HRQ и HLDA и этот же сигнал для избежания конфликтов на шинах должен запрещать открытие трёх буферов АП6 и вызывавать сброс триггера READY, если при HRQ=1 происходит обращение процессора в экранную область. Тем самым в случае обращения процессора в экран во время ПДП-обмена, буфера не открываются, процессор стопорится на WAIT и ожидает конца ПДП-обмена. После конца ПДП-обмена, т.е когда HRQ станет равным 0, открываются буфера, а ещё через такт по входу S триггера взводится сигнал готовности READY для КР580 и он завершает своё обращение.

Тогда процессор из-за ПДП не тормозится (нет захватов шины в циклах ПДП, вход HOLD КР580 заземлён), со скоростным статическим ОЗУ работает на полной скорости без WAIT, но если совпадает обращение в экран процессора и цикл ПДП пересылающий в ВГ75 восемь очередных экранных байтов, то для процессора начинается цикл WAIT, который в худшем случае длится 32 периода CLK ВТ57 (но программно это можно сократить до 16 задав в пачке 4 байта) до исчезновения запроса ПДП HRQ. Но процедура записи в ОЗУ выше 7600 выполняется на пониженной скорости (добавляется 1 или 2 цикла WAIT), т.к быстродействие 565РУ5 существенно ниже, чем у статики w24257. Т.к процессор в экран обращается редко, а совпадения с циклом ПДП происходят с вероятностью 14%, то общее торможение будет маленьким (менее 1% в самых динамичных играх). Экранное ОЗУ на 565РУ5 на плате РК можно включить только на запись (тогда вместо АП6 можно поставить АП4). Тормозное динамическое ОЗУ дублируется скоростным статическим ОЗУ и при чтении области экранного ОЗУ будет читаться скоростная статика без WAIT.

Процессор КР580 в такой схемотехнике точно можно разогнать до 3.5 МГЦ причём реального (эффективного) такта, что даёт ускорение аж в 2.67 раза относительно оригинального тормозного РК86. Ещё более соблазнительно сделать такую переделку с использованием Z80, чтобы поиметь полностью совместимый РК86, но с реальным тактом в 10 МГЦ. А теоретически, исходя из существования китайских процессоров Z840020, можно и 20 МГЦ (но для этого скорее всего быстродействия статического ОЗУ уже не хватит). Это будет скорость в 7.66 раза быстрее, чем скорость оригинального РК86.

По аналогии с акселераторами для компьютера Apple-II (которые давали компьютеру ускорение от 2.5 до 14 раз, при сохранении совместимости) такую сложную доработку можно назвать также акселератором.

Для меня особенно интересно, что в такой схеме режим захвата шины вообще отсутствует. А именно режим захвата мешает поставить в РК86 интересные (хотя и более примитивные из-за того, что в них транзисторов вдвое меньше), процессоры 6502 и 6802, у которых режим ПДП с переводом шин в Z-состояние не предусмотрен (у этих процессоров есть лишь режим останова по сигналу HALT, что всё-же кое-как позволяет поиметь в системе ПДП, но это требует развязки шин дополнительными буферами).

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

Вышеизложенная идея по отделению всего узла видео от узла микропроцессора с помощью трёх буферов АП6 по сути превращает плату РК86 в плату текстового адаптера подключенную через разъём ГРПМ-61 к отдельному МП-ядру. С тем же успехом такой получившийся из РК текстов адаптер через три АП6 можно подключать и к любому бытовому компьютеру.

Если на плате РК микросхемы CPU, PPA и ROM стоят на панельках, то вероятно даже можно обойтись совсем (или почти) без коррекций на самОй плате РК. Что делает такую (пусть для ручного монтажа достаточно громоздкую) доработку легко реверсивной. А главное, - такая идея позволяет подключать в разъём ГРПМ-61 разные МП-ядра (например на разных микропроцессорах или реализующие разные архитектуры).

Кстати, безотносительно к вышеизложенной идее про отделение ПДП от CPU буферами. В качестве архитектуры для существенного и максимально простого улучшения РК86 сейчас мне видится самой удачной такая архитектура.

Задача - сохранив 100% совместимость, максимально просто увеличить объёмы резидентного ОЗУ и ПЗУ, ввести рамки и удобные в программировании инверсию знакомест и цвет для псевдографики. ПЗУ удобнее всего расширять в окне кратном 8 кб, а именно на E000...FFFF, а ОЗУ - в окне 16 кб 8000...BFFF. При этом добавлять дешифратор на В/У остаётся только в области C000...DFFF. Дешифрация этой области с помощью 555 ИД7 оставляет (как и требуется) ровно 1 кб для адресации ВГ75 (C000...C3FF) и добавляет ещё 7 чип селектов для периферии.

Чтобы в одном участке памяти могли адресоваться и оба ППА и одновременно работать доп.память в окне 16 кб, требуется программное отключение чип-селектов 8000 и A000 от входов /CS обоих ППА. При отключении ППА в этой области должно включаться ОЗУ. На такое переключение вовсе не требуется "городить громоздкий огород", как поступили авторы РК-Макси (изобретя так называемый "программируемый дешифратор").

Потому-что на реализацию этой идеи тратится лишь одна дешёвая микросхема 155 ЛЛ1. А для формирования управляющего сигнала (т.к тумблером это делать уже не модно) потребуется лишь ещё один триггер из 155 ТМ2, включённый по принципу "программного ключа" из Apple-II (если не в курсе, то почитайте рефрэнс-мануал). На управление тратим два чип-селекта D800 и DC00, - переключение по факту обращения (данные не важны и запись или чтение без разницы). По обращению на адрес D800 вместо двух ППА будет включаться окно ОЗУ в 16 кб (возврат ППА портов на 8000 и A000 по обращению на DC00).



В этой схеме при записи в триггер ТМ2 единицы прохождение чип-селектов на оба ППА запрещается с помощью верхних вентилей ЛЛ1 и вместо этого при обращении CPU в область 8000...BFFF двумя нижними ЛЛ1 разрешается прохождение импульса /CAS на ОЗУ, что и образует сплошные 48 кб ОЗУ в области 0...BFFF. Нарисованный на схеме вентиль ЛИ1 нарисован для удобства понимания схемы, а в реале функциональный вентиль "И" образуем из двух освободившихся в схеме вентилей из ЛА3.

Вторую половинку 155 ТМ2 тратим на включение альтернативного фонта (что даёт нормальные рамки и инверсию знакомест). Таким образом, расширение ОЗУ до 48 кб в РК86, в котором ОЗУ сделано на 565 РУ5, обходится всего лишь в два, причём даже не самых дорогих, TTL-корпуса 155-той серии. А расширение ПЗУ до 8 кб обходится вообще без доп.микросхем (т.к это уже изначально предусмотрено в РК), требуется лишь смонтировать на месте 24-х нОгой панельки - 28-ми нОгую.

Совершенно очевидно, что именно такая архитектура доработки РК является не только самой простой, но и самой оптимальной (и кстати, при 565РУ5 совсем не грузящей шины). Если добавить ещё узел формирования RGB для псевдографики, реализующий цвет за счёт кодов самих символов (когда биты D7, D6, D5 задают цвет знакоместа), на что надо истратить ещё две дешёвых TTL-микросхемы, то с таким небольшим расходом доп.ИМС и ничтожной трудозатратой получается на порядок лучший бытовой компьютер, чем оригинальный РК86.

А для идеи с отделением буферами микропроцессора от микросхемы ПДП, то с учётом того, что встречаются РК-игры ставящие экран с 4000, то проще всего схемотехника получается, если во внешнем МП-ядре поставить скоростную статику w24257 (её объём 32К) в виде двух фрагментов по 16К - в окне 0...3FFF и в окне 8000...BFFF. А в тех адресах, где в РК86 располагается экранный буфер, т.е в окне 4000...7FFF оставляем динамическое ОЗУ из основной платы РК (при этом ради экономии РУ5-тых разумно вместо них установить РУ6). Тогда программа в статическом ОЗУ w24257 будет выполняться на полной скорости процессора, а при доступе к медленному динамическому ОЗУ в области 4000...7FFF будет добавляться один такт WAIT, что удлинит время обращения к нему.

Недавно догадался, что можно получить дополнительную пользу от выхода INTE процессора КР580 в РК86 и ОРИОНЕ. Как всем известно, в этих компьютерах РК86 и ОРИОН этот единственный программно управляемый вывод процессора сдуру истрачен на вывод музыки и звуков. Но если сообразить, что возможны устройства, которыми люди пользуются без одновременной выдачи музыки и звуков, то можно нагрузить этот вывод INTE какими-либо другими полезными функциями.

При использовании журнальной платы РК86 разумно следующее использование запасного ППА D14. Основная польза от запасного ППА D14 в своё время заключалась в подключении к нему ROM-диска, платки прошивателя УФ-ПЗУ 573 РФ2 (где стоит лишь панелька на 24 ноги и 155ЛА3) и очень редко - адаптера принтера (что обычно представлял собой просто буфер на двух 155 ЛН2 с открытым коллектором). Хотя через запасной ППА можно подключать и другие полезные узлы (например, контроллеры флэш-накопителя, винчестеры, таймер и AY, эл.диски с записью на статике, интерфейсные узлы, например для обмена по проводной линии с ПК).

С другой стороны на плате РК справа от системного разъёма ГРПМ-61 (около ПЗУ с фонтом) есть ряд отверстий позволяющих там смонтировать две 14-ти или 16-ти-ногих TTL-микросхемы или одну 28-ми ногую панельку для ПЗУ. Удобнее всего истратить это посадочное место под резидентный ROM-диск, т.е смонтировать там панельку ROM-диска подпаяв выводы этой панельки к выводам ППА D14 (PB и PC - адреса, PA - данные, /CS на земле). Тогда ROM-диск будет резидентным (не будет волочиться на длинной косе, постоянно падая и всё замыкая, ломая и обрывая провода).

Чтобы ПЗУ ROM-диска (27256 или 27512) не требовалось вытаскивать из панельки, когда к ППА D14 надо подключить другое устройство, можно поставить микро переключатель (временно подающий +5В на /CS ПЗУ ROM-диска).

Но выгоднее, дешевле и грамотнее делать отключение ROM-диска программно сигналом INTE процессора. Это возможно, потому что, когда читают ROM-диск или работают с другой периферией, музыка одновременно не играет и выход INTE (выдающий звуки) не задействован. Так что кусочек проволоки решает проблему одновремнного использования одного ППА и для ROM-диска и для других устройств. Из чего совершенно ясно, что городить третий ППА F600 в ОРИОНЕ не имело совершенно никакого смысла.

Ещё большую пользу выход INTE принесёт, если его задействовать под адрес A16 ПЗУ расширенного 128-ми килобайтового ROM-диска. Если же и 128-ми килобайтового ROM-диска мало, то вывод INTE выручит и в этом случае (точнее его использование позволит не грузить шину доп.портом и с'экономит доп.детали). Для этого выводы порта PB ППА клавиатуры заводим на входы регистра (например, 555 ТМ8 или 555 ТМ9), а на вход С этого регистра подключаем INTE. При этом, чтобы записать в доп.регистр номер банки ROM-диска, достаточно выдать номер банки в порт клавиатуры и выдать программный фронт на вывод INTE. Без INTE эта задача потребовала бы установки доп.микросхем для получения дополнительного чип-селекта и установки регистра банки в шину (а в шину РК86 ничего включать уже нежелательно, т.к она и так слабая). Т.о использование INTE не только экономит одну TTL-микросхему, но и сохраняет нагрузочный ресурс шины.

Кстати, если резидентный ROM-диск вообще не актуален, то альтернативно это посадочное место для 28-ми ногой микросхемы можно использовать под 580ВИ53 или под 28-ми ногую музыкалку AY-8912.

И эту же идею использования вывода INTE можно применить для управления архитектурой. Точнее лишь для новых устройств, т.е для тех устройств о которых программы выводящие звук через выход INTE просто не знают. Например, не добавляя упр.портов можно переключать страницы в окнах ПЗУ или ОЗУ организованных в неиспользуемых областях адресного пространства выше 8000. Например, переключать две 8-ми килобайтовые страницы ПЗУ в окне E000...FFFF или две 8-ми килобайтовые страницы ОЗУ в окне A000...BFFF.

.

Тут возник законный вопрос так ли уж с целью поиметь РК86 с ОЗУ 48 Кб необходимо иметь в РК86 двухрежимную коммутируемую архитектуру. Может быть этому есть альтернативы.

Чтобы компилировать РК-игры на бейсике компиляторе желательно иметь 48 кб сплошного ОЗУ, что даст для откомпилированной игры около 44 Кб, а это уже очень солидная величина. Считая что компилятор бейсика даёт раз в 6-7 менее плотный код, чем ассемблер, программа объёмом в 44 Кб из под бейсика эквивалентна 6-7 кб программы написанной на ассемблере. А если использовать более эффективный компилятор (т.е Си или Паскаль), то 44 Кб для кода из под ЯВУ эквивалентны ~10 Кб кодов из под ассемблера (я уж не говорю о PLMX у которого фактор разбухания кода всего ~1.5, по крайней мере точно не более 2).

Однако расширению ОЗУ в  базовой архитектуре мешает положение порта клавиатуры посередине адресного пространства. Если порт запасного ППА D14 можно перенести в любой адрес проктически без потерь программ (в худшем случае это УФ-прошиватель, печать на принтере и контроллер microSD от vinxru), то перенос порта клавиатуры сразу приводит к потере почти всех игр РК86. Тогда потребуется переделка этих почти всех игр, а именно, - изменение в них адреса порта.

Если в СССР это сделать было не так просто, т.к это было возможно сделать только вручную очень медленно трассируя код отладчиком, то сейчас эта задача (переделки игр) упрощена наличием безтормозных отладчиков в эмуляторах. Сейчас в принципе поменять адресацию ППА клавиатуры в программах стало несложно и видимо любой достаточно трудолюбивый новичёк совершенно не имеющий опыта на ассемблере может сделать переработку всех РК-игр на другой адрес ППА всего за несколько дней, а то и быстрее. Для этого достаточно загрузить игру в эмулятор в котором есть ловушка на доступ к ячейкам памяти и найдя с его помощью места в программе, где происходят обращения в порт клавиатуры тут же встроенным отладчиком изменить адрес порта клавиатуры. При наличии эмулятора где можно задать не один адрес, а целый диапазон ловушки и конфигом задать одновременно и новый и старый адрес порта (чтобы по мере смены адресов ППА в игре, работоспособность не исчезала), переделать игру можно всего за несколько минут.

Но в 80-тые годы в СССР у любителей еще не было не только эмуляторов, но даже и машин на которых эмуляторы могли бы работать. Тем не менее, если бы нашёлся пассионарий с горящими глазами, который бы с детства мечтал иметь РК86 с бОльшим ОЗУ, чем 32 Кб, то он мог бы это сделать. Отловить точки программы с которых происходит работа с клавиатурой можно было сделать без эмулятора на реальном РК86 с помощью прерываний. С помощью аппаратно-программной ловушки на прерываниях.

Идея простая. Попадание процессором в окно клавиатуры фиксируем по активности сигналов /WR или DBIN и чип-селекте ППА клавиатуры =0, что означает обращение процессора в порт клавиатуры. По этому сигналу взводится триггер вызывающий апп.прерывание, а программа прерывания определяет и заносит в таблицу адрес откуда произошло прерывание (естественно адрес заносится лишь раз, повторные попадания в порт игнорируются). После прогона игры в такой машине в таблице получаем все адреса из которых идёт обращение в клавиатуру. Т.о получается, что можно было ещё в 80-тые годы даже не особо надрываясь переделать все РК-игры под другой адрес порта клавиатуры. Теоретически можно и другие порты в РК-играх переставить, но нет смысла.

Т.о можно сделать РК86.48 с сплошным ОЗУ в 48К и отличающимся от журнального РК лишь адресами ППА D20 и D14. Понятно, что на таком РК нельзя тестировать игры для обычного РК86, но теперь, в отличие от 80-тых годов это не играет роли. Если сделал программу для 48-ми килобайтовой версии, то эту программу не проблема перетранслировать поменяв в исходнике адрес порта (и соответственно раб.ячеек ПЗУ в области 7600...76CF), а проверку результата придётся сделать в эмуляторе.

Есть и ещё одно соображение в пользу наглого несовместимого переноса порта клавиатуры в доработанной 48-ми килобайтной версии РК. С учётом вышеописанной ловушки с прерыванием можно эмулировать порт 8000 также аппаратно-программно. Тогда по обращению в ППА клавиатуры по адресу 8000 также будет вызываться апп.прерывание и по нему будет определяться куда и как обращался ППА в предыдущей команде и это действие затем выполняется для реальной клавиатуры. Т.е если было чтение порта А из 8000, то в аккумулятор перед возвратом из прерывания грузится содержимое реального порта А клавиатуры.

Такая эмуляция клавиатуры по прерываниям тормознёт всего на доли процента. Подобная техника эмуляции отсутствующего реально железа на прерываниях - это вполне профессиональный метод. Например, так вот в этой книге эмулируется дисковод, когда его конструкция или адреса иные.

Если сделать РК86/48 без порта 8000 со сплошным ОЗУ, то получится примерно вот такая архитектура.




Это соображение я привёл, чтобы подумать, что лучше - один раз переделать все РК-игры с помощью ловушки в эмуляторе или делать доработанный РК с 2-мя режимами архитектуры - на 32 Кб и на 48 Кб. Есть какие-либо мнения на этот счёт?

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

barsik пишет:
Отловить точки программы с которых происходит работа с клавиатурой можно было сделать без эмулятора на реальном РК86 с помощью прерываний. С помощью аппаратно-программной ловушки на прерываниях.
Есть какие-либо мнения на этот счёт?

Отличная идея. Остается нарисовать схему контроллера прерываний и внедрить его в схему новодела. Одновременно хотелось бы (раз уж начали про прерывания) и одно под какой нибудь любой системный таймер на 10-100мс.
Предлагаю раз уж заговорили нарисовать ВАМ схему, а я соответственно мог бы внедрить это в схему и поддержать программно. Мысли даже такие, поручить это своего рода резидентной программе наподобии ОС (раз уж она на прерываниях) то можно смело перенаправлять адреса портов куда угодно. Для этого еще бы пригодился таймер.

А вообще, если уж на то пошло..... Давно пора "отучивать" РК86 от портов по 8кб. Ну ей богу 35 лет терпим это безобразие. Напишу списком:
1 - все те, кто хотел повторить рк - его повторили ради поиграть в булдердаш или клад. Далее судьба этого компа собирать пыль на полке.
2 - Что есть игры на рк86, ради которых все так и пытаются угробить новодел опять в свои 32 кб и потом ненавидеть свое творение.... Ради чего????? Ради игры вулкано, господи... которая раз в секунду курсором перерисовывает экран??? Или ради ассемблера микрон, остались ли те, кто на нем хоть что то напишет? Или понастольгировать в любимый бейсик микрон?... Давайте прекращать....
3 - Из рк86 можно оставить только монитор, доработаный монитор, который своего рода будет давать холодный старт.
4 - Вы не задумывались почему молодежь даже не понимает что такое рк86?
5 - А ведь молодежь до си пор изучает в универах коды вм80, и наверняка найдутся те, которые захотят закрепить свои знания на современной хорошей машинке, от которой хоть что то осталось.... название, логика.... монитор, но это будет отличный аппарат с памятью цветом и звуком.... Да что говорить, будет ли интерес у кого то изучать 35 летнюю мертвую с рождения технику??????
6 - Продолжать дальше? Будем еще лет 10 обсуждать эмуляцию портов по 8 килобайт дабы по....ть в игру вулкано?
Добавлю.... Мне совершенно непонятно, что при желании добавить в схему новодела цвет от апогея мне начинают писать.... мол как же так, это же получится не рк86 а апогей.... А по моему этот комп чем и отличается от рк86 так это тем, что в нем исправлены эти гадкие ошибки экономии и всех тех моментов что описаны выше. Видел ли кто нибудь в ближайшие 10 лет новую игру для рк86? Я лично нет, зато некий винксру (я его никоим образом не рекламирую) спокойно заделал пару игр в цвете и графике.... Задумались почему?

Пока вопрос переделки РК-игр под другую архитектуру останется риторическим. Т.к я не смог найти эмулятор РК с приличным отладчиком, т.е где была бы ловушка хотя бы на один адрес ОЗУ. Ещё надо проверить на этот счёт эмуляторы для MSDOS из 90-тых.

Если бы был эмулятор с ловушкой на область адресов или хотя бы на один адрес, то любой человек за один день смог бы конвертировать все РК-игры под клавиатуру стоящую по другому адресу. Возможно придётся писать такой эмулятор самому (это не так уж сложно, имея блок эмуляции процессора и РК-клавиатуры, - остаётся только эмулировать ВГ75).

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

ведущий_специалист пишет:

barsik пишет:ловушки на прерываниях...
. . . . . . . . .
Есть какие-либо мнения на этот счёт?

Отличная идея.

Вопрос был не о том. Под словами "на этот счёт" я имел в виду мнение насчёт выбора между совместимой доработкой с двумя архитектурами и абсолютно несовместимой доработкой вообще не имеющей порта 8000. А не насчёт прерываний. Прерывания это не тот вопрос, что надо обсуждать.

Если надо, то можно увеличить громоздкость и добавить в РК и прерывания или даже таймер ВИ53 (чтобы читать из него время). Хотя, если прерывания от кадрового бланка планируются, чтобы что-то делать во время гашения экрана, то для этого прерывания не нужны, т.к в регистре статуса читается IR флаг, дубль того, что идёт на выход IRQ, потому можно узнать (не понял точно) начало (или конец) кадрового бланка.

Это кстати, способ в базовом РК замерить быстродействие машины (в частности, так программно можно узнать кварц у ГФ24 стоит 16 МГЦ или 20 МГЦ). Е.Седов использовал эту фичу, для счёта времени, чтобы программно вычислить скорость вращения шпинделя в дисководе. Хотя IRQ, чтобы считать время, слишком короткий (длиной в строку 64 мкс) и слишком частый (50 Гц). А вот внешний меандр частоты 5 ГЦ для счёта времени вполне годится (т.к с ним потерь на опрос мало - достаточно считывать лишь раз в 100 мс).  Кстати простейший апп.таймер в виде меандра можно читать через порт светового пера, не тратя отдельный порт.

ведущий_специалист пишет:Мне совершенно непонятно, что при желании добавить в схему новодела цвет от апогея мне начинают писать.... мол как же так, это же получится не РК86 а Апогей...

А Вы видели, чтобы в эмуляторах РК86 был поддержан цвет Апогея?

Я вообще даже не знаю, что это такое, т.к Апогеем никогда не интересовался, не имел и желания поиметь никогда не было. В эмуляторе EMU80 есть на выбор цвет Толкалина и цвет Акименко, а цвета Апогея нет. Вроде бы там несовместимость по сдвижке на знакоместо, а может и ещё что-то. А у Партнёра есть МЦПГ, почему тогда не тащить его?

Если уж речь об РК86, то и смотреть надо в первую очередь на его схемы, а не на схемы Партнёра, Апогея, Арго или Юниора. Если ваша новая платформа будет несовместима с РК, а по идеям и архитектуре ближе к Апогею, то нельзя вводить людей в заблуждение и применять в названии слово РК86.

А какая иная может быть реакция на предложение превратить РК86 в Апогей, когда у РК давно есть свой официальный атрибутный цвет узаконенный в 1992 году печатным словом 100 тысячным тиражом. Причём, как показала история, даже он - этот официальный цвет, - никого глубоко не взволновал за 28 прошедших лет, а упомянутые в статьях аж 40 оцвеченных кооперативных игр так почему-то и не всплыли (может они у кого-то и есть, но он даже не знает, что они оцвечены).

Я цвета не имел, но убедился в неудобности атрибутов на RVV (инверсии знакомест). На ЯВУ программирование атрибутного цвета возможно полегче, но до программирования цвета я ещё не созрел, отчего совершенно равнодушен к нему. А т.к толпы программистов мечтающих программировать для РК86 не только в цвете, но даже и в монохроме я не наблюдаю, то моё отношение к атрибутному цвету должно быть понятно.

ведущий_специалист пишет:Ну ей богу 35 лет терпим это безобразие.
. . . . . . . .
Давайте прекращать...

Всё, что Вы перечислили знает каждый, кто в теме РК86. И это нисколько не оправдывает создание новой несовместимой платформы на ВГ75. И надо прояснить - речь о создании новой платформы или о производстве единичного экземпляра. Мне кажется, что создать новую платформу сейчас тяжело, а на ВГ75 - совсем невозможно. У совместимой платформы хотя бы есть гипотетический шанс на сбыт небольшой партии плат. А вообще такие вещи, как говорится, не стоит решать с кондачка (т.е не надо спешить). Лучше всё тщательно обдумать и обсудить. И не только в этом форуме, есть форум, где хотя и троллей хватает, но зато есть и любители РК. 35 лет ждали, можно подождать ещё.

А если речь заходит о новой платформе на ВГ75, то неизбежен вопрос - на кой хрен создавая новую платформу бытового компьютера тащить в него нелепый и губящий быстродействие ВГ75. Да и вообще текстовая платформа это был нонсенс уже в 1986, хотя винить авторов в этом нельзя, т.к доступа к западным журналам в СССР почти никто не имел.

Авторы применили ВГ75 в 1985 году видимо из-за того, что просто его поимели в своём НИИ, ну и сразу применили. Ясно, что сдуру. Потому что текстов видеоадаптер на логике и проще и дешевле, параметры лучше и не тормозит. Вот сравните, то же время (даже чуть раньше), те же ОЗУ 565РУ3, но другие инженеры - типовой компьютер с текстовым адаптером на дешёвых TTL-микросхемах. Выкиньте из этой платы ВЧ-модулятор, блок питания и кнопку сброс и получится плата в две трети журнальной эркашной. Две БИС ВТ57 и ВГ75 стоят дороже, чем десяток TTL корпусов ценой по 40 копеек, не говоря уже о дефицитности сверхновых отечественных БИС.

Кстати, судя по журналу МПСС за 1985 г с нормальной (т.е не DEC) шиной в стране тогда уже начали производить ещё 2 другие БИС для построения видео - 1809ВГ4 - (это клон видеопроцессора NEC 7220) для видеокарт графических рабочих станций и 1809ВГ6 (клон 6845) - что был нужен, чтобы ставить его в ЕС1840.

Я всегда веду разговор лишь о простейших доработках, чтобы увеличить апп.возможности готовой журнальной платы. Мне интересны доработки, что делаются на базовой плате РК86. У меня нет и не было планов стать пассионарием и посвятить все свои силы на создание какой-то новой платформы, а уж тем более на базе РК86, используя схемотехнику 40-летней давности.

Для меня сюжет всегда был в том, чтобы простейшими средствами получить лишь больше ОЗУ и ПЗУ, по возможности скорость и несколько фонтов (что надо для повышения красоты игр). Больше ОЗУ надо было для CP/M или другой DOS и чтобы ОЗУ хватало для программ из под ЯВУ. ПЗУ для удобства и потому, что его расширение по трудам почти ничего не стоит. А 8 фонтов в электрически перезаписываемом ПЗУ нужны, чтобы попробовать делать тайловые графические игры. Железо для меня вовсе не цель, а средство, потому мне от РК больше ничего не надо.

ведущий_специалист пишет:Видел ли кто нибудь в ближайшие 10 лет новую игру для РК86?

Ну 2020 год ещё не кончился, а за 2019-й и 2018-й год новых игр не встречал, зато в 2017 появилось аж 3 новых игры. И кстати, если Вы быстро странслируете для базового РК на C8080 хотя бы пяток новых (или аналогов старых) игр на Си (для хорошо знающего Си это не особо трудно, в основном трудность придумать саму игру и алгоритм, как её реализовать программно, остальное дело техники), то создадите доверие к себе и новой платформе.

barsik пишет: Причём, как показала история, даже он - этот официальный цвет, - никого глубоко не взволновал за 28 прошедших лет, а упомянутые в статьях аж 40 оцвеченных кооперативных игр так почему-то и не всплыли (может они у кого-то и есть, но он даже не знает, что они оцвечены).

Понятное дело, люди до начала 2000 использовали ламповые телевизоры рекорд в312, понятно что поколение рк программистов выросло на этих телевизорах в качестве монитора, конечно о цвете и знать никто не будет, а подключить оцветненный рк к современному жк телеку довольно проблематично.

Что уж говорить. Мы сами загоняем себя в рамки. Мы ненавидим рк и его изобретателей, но при хотя бы начинании исправлять ошибки возникает существенные ограничения. Это нельзя - то нельзя.... Причем Вас послушать - так действительно, либо делать что то крайне новое, либо лепить на плате вторым этажом доп микросхемы для каких то приятных изменений. Ну и ладно, я все записываю ))).
Я тут вообще что подумал. Если делать новодел, не обзывая его рк86, но придерживаться какой то логики, используя рассыпуху на логических микросхемах и доступных бис (можно и гибридов типа нового z80 и тп), то видеоадаптер можно вообще применить в виде микроконтроллера о 48 лапах с цветом и шиной данных и адреса. Причем все видеоОЗУ будет размещаться внутри него и аппаратно связываться напрямую шиной данных. Для восьмибитного компьютера будет достаточно и VGA разрешения с 8 битами цвета на точку. Действительно, зачем эта глупая связка вт57 вг75.
Мне достался вот такой аппарат 
Как видите уплотнено все оч сильно, дорабатывать я его пыался, в результате получился ежик из проводов, а ведь это всего лишь клавиатура и диск, что говорить об остальном.
Поэтому меня и сподвигло на новодел, поэтому я и здесь... Первые мысли переделать эту плату - подключить ее к монитору (а если подключать к монитору - а почему бы не....) ну вы поняли... Народ здесь грамотный, авось чего и посоветует. А там и покодить можно, в мыслях оочень много чего под него написать как в плане игр так в плане и операционки.
Добавлю. И кстати, основная причина появления меня на именно этом форуме - так это нахождение тут на просторах достаточно грамотно выполненного дешифратора адресов с совместимостью с оригиналом.

ведущий_специалист пишет:Мы сами загоняем себя в рамки... при хотя бы начинании исправлять ошибки возникают существенные ограничения

Трудно что-то обсуждать не понимая о чём идёт речь (о единичном изделии или о новой платформе). Навскидку видятся несколько вариантов, что можно обсуждать.

1. Создание совсем новой платформы без оглядки на совместимость с чем-либо и на любых деталях. Разработка новой платформы никак не связанной с РК86 это слегка мимо темы (чтобы избежать порицаний объявим это производным от РК в идейном плане).

2. А если забыть об РК, но помня о необходимости совместимости с чем-либо, есть очень разумный вариант. Небольшая по объёму, совместимая доработка "Специалиста", заключающаяся в чуть изменённом цвете, использовании всех 64К ОЗУ (за счёт разворота блока 16К или режима FULL RAM с отключённым ПЗУ), на Z80 с реальным тактом 3.2 МГЦ. Машина идеальная для программиста, максимально простая и дешёвая, уже имеющая программы и до неё не сложна доработка обычной платы "Специалиста" на РУ5-тых. Для такой машины реально написать игру "Принц Персии" и оболочку DOS в стиле GUI (т.е с пиктограммами и указателем).

3. Расширение существующей РК-платформы за счёт двухрежимной архитектуры (не важно получаемой за счёт блокирования портов 8000...BFFF или с помощью двухрежимного дешифратора на 155РЕ3), дающей в альтернативном режиме сплошное ОЗУ в 48 Кб. Куча фонтов или возможно схема загрузки фонта. Стандартный журнальный цвет из ж.Радиолюбитель 04.1992.

4. Создание условно новой РК-платформы, что отличается от РК лишь отсутствием порта на 8000 (отчего переделка РК-игр не проблема), что даёт сплошные 48К, как и в Микроше с его картой доп.ОЗУ. Этот вариант можно назвать - "правильная Микроша" (ибо реальная Микроша из 1987 года неправильная, в ней все БИС-ы переставлены, а клавиатура перевёрнута портами A и B). Также фонты и цвет.

5. Приплету ещё один вариант. Он даже в тему, т.к РК остаётся. Вместо добавления периферии, наоборот к РК86 добавляем МП-ядро - превращаем плату РК86 в видеокарту для скоростного 10-ти мегагерцового ядра на Z80. В США была такая популярная серия мини компьютеров Wang (их было десятки моделей, две самые ранние из них даже клонировали в СССР) - в них устройство вывода было в виде текстового адаптера управляемого процессором 8080 (позднее Z80). Это и позволило машинам Wang преуспеть. Мы из РК делаем то же самое - программа прошитая в ПЗУ РК читает команды через порт D14, по получении выполняет, а на досуге проверяет порт клавиатуры D20 на предмет замыканий в матрице клавиш. А по нажатию клавиши, считывает и пересылает в скоростное МП-ядро уже готовый ASCII-код. Все команды - про экран и музыку. Т.е вывести символ, считать символ, погудеть 0.75 сек на частоте 1 КГЦ, сделать ролик экрана (или окна) вверх/вниз/влево/по-диагонали. Такая система с ловушкой на область экрана по прерываниям сможет прогонять программы любого компьютера (с такими же или худшими видео возможностями).

---

РК-базируемые варианты имеют плюсом то, что текстовый режим позволяет делать игры с тайловой графикой, т.е на базе той же идеи, что привела к рекордному успеху Денди (тираж 70 млн, что очень много для 80-тых). Как следствие текстовости снимаются проблемы нехватки скорости и программы можно писать на ЯВУ. Этим меня и привлекает. Но и тут, вспомним, что даже предлагая что-то совместимое с РК86 за последние 10 лет сделать это ни у кого не получилось. Вам бы почитать о попытках сделать улучшенный РК в разделах РК86 формума ZX-PK.ru. Они потерпели крах, потому что у них не было идеи для облегчения разработки и улучшения качества игр.

Совсем новая платформа это может и интересный вариант, но ненужный. Потому что уже 35 лет как существует недооценённая платформа Специалиста, которая даже в своём антикварном варианте даёт почти всё, что надо, если кому-то нужна графика, быстрый нетормозящий цвет и самая быстрая из всех отечественных машин клавиатура.

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

И неизбежен вопрос - сделаете Вы эмулятор такого компьютера (без чего платформа сейчас просто не существует)? Заметьте, что уже 30 лет никто не предлагает абсолютно новых платформ, все продвинутые новоделы совместимы с чем-то уже имеющим программы! А всё, что не совместимо, так и осталось в одном-двух экземплярах. Да и совместимость не гарантия успеха продвинутого клона.

ведущий_специалист пишет:Мы сами загоняем себя в рамки... при хотя бы начинании исправлять ошибки возникают существенные ограничения. Это нельзя - то нельзя

Да нет ограничений и всё можно. Если речь только об единственном экземпляре для себя, без оглядки на других людей.

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

Если речь о создании новой платформы, то имеют значение два аспекта. Первое это проблема набрать заказчиков на партию печ.плат, хотя бы штук 10. А второй - это ответственность. Станет ли это авантюрным предложением другим людям собрать бесперспективное изделие (без программ и без шансов на то, что они появятся хотя бы в минимальном количестве и качестве)? Примеры - ЮТ88, ЭРИК с тиражом в один экземпляр и ОРИОН-ПРО с тиражом более 1000 проданных печ.плат из коих в итоге заработала в лучшем случае пара десятков (да и те прогоняют лишь программы ОРИОНА-128).

ВажнО не железо, а программы. Взять тот же РК86 с простейшим атрибутным цветом и с 32-мя фонтами и добавить к нему две тысячи программистов (фанатичных или просто хорошо оплачиваемых). Тогда РК86 возродится и станет максимально популярным. Начинать надо с программ. Кстати, тогда и яснее станет, что из доп.железа реально стоит добавить.

ведущий_специалист пишет:Вас послушать - так действительно, либо делать что то крайне новое, либо лепить на плате вторым этажом доп микросхемы для каких то приятных изменений.

Вы считаете, что я враг прогресса. Но сейчас трудно говорить о прогрессе, если программистов для 8-ми разрядок осталось так мало. Потому, на мой взгляд правильный путь к прогрессу, это расширить в базовой плате РК число фонтов (у многих владельцев хватит денег на кусочек проволоки и найдётся возможность допрошить РФ2, а увидев возможности тайловой графики захотят применить 27256 с 32-мя фонтами). И начать делать РК-игры используя ЯВУ. Освоив монохром, можно попробовать делать игры в цвете. И только когда кончится ОЗУ, т.е объём кода одной из игр превысит лимит, то понадобится сделать следующий шаг - ввести каким-либо способом расширение ОЗУ до 48 Кб. Если дело упрётся в скорость, то следующий шаг - это установка Z80 и подъём клока, сколько РУ5-е потянут. Если скорости всё-равно мало, то делаем следующий шаг, меняем 565 РУ5 на статику, что тянет бОльший клок.

А пока я не написал ни одной динамической игры на ЯВУ, мне хватает и базового железа с доп.фонтом, а прогрессу на ниве РК86 может подождать. Доработки нужны для чего-то, т.е если они необходимы кому-то для создания программ, а не просто потому, что наличие микросхем и знаний позволяет их сделать.

ведущий_специалист пишет:видеоадаптер можно вообще применить в виде микроконтроллера о 48 лапах с цветом и шиной данных и адреса.

Это новая несовместимая платформа. Если это единичный образец, то всё решает автор. А если это делается из-за графики, то чем это для программиста лучше "Специалиста" ? В нём линейный экран, к котором всё просто и удобно, нетормозящий цвет и клавиатура сканируемая всего за два чтения. Ничего лучшего за 35 лет не придумали.

ведущий_специалист пишет:Мне достался вот такой аппарат... уплотнено все очень сильно

Вот и добавьте к нему ПЗУ 27256 с фонтом и превратите в терминал для отдельного Z80-ядра на 10 МГЦ.

ведущий_специалист пишет:Первые мысли переделать эту плату - подключить ее к монитору

видимо VGA. Так сделайте, соберите опыт о переделке под VGA. После может и другие захотят иметь РК выводящий на VGA.

ведущий_специалист пишет:причина появления меня на именно этом форуме - так это нахождение тут на просторах достаточно грамотно выполненного дешифратора адресов с совместимостью с оригиналом.

Дешифратор адресов на 556РТ4 (меняющий архитектуру и адресацию БИС) обещали опубликовать ещё разработчики РК86, потому и требовалось на плате РК ставить D11 на панельку.

Дешифратор - это же простейшая и понятная вещь для любого, кто не поленился прочитать книгу "Дж.Коффрон, Технические средства МП-систем". Сначала рисуем один дешифратор (с адресацией как у D11), затем другой (уже на желаемые адреса портов), а затем рисуем однобитовый порт реализованный на 1533 ТМ2 (включённом по схеме D-триггера) который эти дешифраторы по очереди (т.е по одному за раз) включает (разрешает их работу) двумя инверсными друг относительно друга сигналами поданными на их входы /CS взятыми с выходов этого порта-триггера.

Но по деталям выходит намного проще (и к тому же не грузит дополнительно шины), архитектура в которой надо переключать (а точнее отключать) всего один порт 8000, на что расход деталей всего в два вентиля из 155 ЛЛ1. Т.е выгоднее адрес порта D14 перенести с A000 куда-то ещё, тогда в участке памяти A000...BFFF будет сразу ОЗУ и его не надо коммутировать. А коммутируемый дешифратор проще всего на 155РЕ3 или 556РТ4 (а сейчас возможно и на соответствующих GAL).

ведущий_специалист пишет:Мы ненавидим РК и его изобретателей

Глупости. Никто их не ненавидит, это было бы нелепо. Они сделали изделие соответствующее их знаниям того времени, доступу к деталям и поставленной редакцией задаче на минимизацию числа корпусов. Хотя никому так и не понятно почему разработчики забыли инверсию знакомест и совсем не заложили возможности расширения, потребность чего уж всяко была им очевидна, ибо они 8 лет до того занимались микропроцессорами и даже имели CP/M.

Неудачу РК (и соответственно скудость ПО) вызвало как раз то, что все, в т.числе и авторы сочли, что делать доработки и что-то улучшать в нём нет смысла. А вот в других соц.странах, как я уже писал, радиолюбительский компьютер авторы не бросили и 5 лет развивали и дорабатывали - потому, начиная с текстовой шалабушки с рабочим ОЗУ в 1 кб, уже к 1989 году поимели CP/M (при общем ОЗУ в полные 64К !) работающую на эл.диск 256 Кб на 41256, что по деньгам доступно всем (да и дисковод подключили). А у нас до этого никто по сути не добрался и к 1993.

ведущий_специалист пишет:А там и покодить можно, в мыслях очень много чего... написать... в плане игр

Не можно, а нужно, и не там [в смысле когда-то], а прямо сегодня. Напишите для базового РК86 с доп.фонтом "Super-Mario" или хотя бы "Galaxians" или "Pac-Man" (желательно и ещё пяток старых игр от Атари), чтобы они выглядели и имели игровой аспект не хуже, чем их версии на Atari 2600 из 1979 года.

Так что насчёт того, чтобы Вам не торопиться, не гнать лошадей, не решать с кондачка, а сначала всё обдумать, может быть даже обсудить? Т.е повременить с новодельным железом или доработками старых плат, а используя компилятор Си и ассемблер заняться написанием игр для базового РК86 с доп.фонтом (куда заливаются тайлы реализующие спрайты игры). Вам, как профессионалу в Си, это не составит большого труда.

Получается, что я ошибался считая схему с открытием ОЗУ под портами 8000 и A000 за счёт блокировки их чип-селектов с помощью 4 вентилей 155 ЛЛ1 самой простой и оптимальной. Т.к если запасной ППА D14 фиксированно перенести на другой адрес, то схема доработок до 48 Кб вообще упрощается до предела, хотя точно также решает задачу - даёт пользователю сплошные 48К при сохранении совместимости.

Как в предыдущем посте упомянуто, если с целью упрощения коммутации между режимами 32 и 48 Кб запасной ППА D14 навсегда перенести в другой адрес, то останется коммутировать всего одну цепь - выборку окна 8000...9FFF между /CS ППА D20 и разрешением доступа к ОЗУ в этом участке памяти, что существенно упрощает доработку. Расход деталей всего один корпус 155 ЛЛ1 (дешифратор на область C000...DFFF всё равно надо ставить, т.к иначе где взять чип-селекты для доп.периферии).

Если, установка однобитового порта 1533 ТМ2 для управления переключением 32/48 Кб окажется слишком обременительной для владельца электропаяльника, то можно управлять переключением режима 32/48 с помощью одного из битов ППА D14 (стоящего теперь не на A000, а где-то ещё). Кстати, однобитовый порт (и вообще всё, что выходит на шины CPU) надо ставить 1533 серии (чтобы меньше грузить шину), а вот во внутренних цепях схемы РК86 можно смело применять токожрущую 155-ю серию. Теоретически для переключения объёма ОЗУ можно использовать и биты PC1 или PC2 ППА клавиатуры, но тогда не применить клавиатуру MS7007.

Спойлер:

Кстати, в такой схеме (с ППА D14 перенесённым с адреса A000 куда-то ещё) в режиме 32 Кб на самом деле доступно не 32 Кб, а 40 Кб, т.к в окне на старом месте этого ППА D14 всегда ОЗУ из 565 РУ5, ставшее "видимым" после переноса ППА D14. Кстати, те кому хватит 40 Кб могут вообще обойтись практически без доработок, достаточно перекинуть выборку ППА D14 к доп.дешифратору ИД7 и двумя диодами открыть ОЗУ в окне занятом ранее D14. А дешифратор ИД7 для получения дополнительных чип-селектов это даже не доработка, т.к он и без того стоит у тех, кто подключил к РК86 какую-либо периферию (типа винт, флоп, эл.диск, тестер микросхем, ВВ51 для связи...). Таким образом 40 Кб обходятся в одну второэтажную микросхему, а 48 Кб в две микросхемы.

Вот такая карта памяти. И вот такая схема. Уж проще-то некуда. И никакие громоздкие коммутируемые дешифраторы (типа применённого в РК-макси его разработчиками Матвеевым и Седовым) не нужны.

Так наверное будет быстрее. Даю кусок схемы. Дешифратор в этой схеме оригинальный, не знаю правда, номера микросхем правильно стоят или нет, не суть. Вместо ПЗУ монитора стоит 8кб , и есть дополнительные 2 микросхемы по 8кб статики. Сможете приведенную выше вами схему согласовать с данной? если да, это достаточно серьезно толкнет меня к дальнейшей постановке новой схемы и результату.

barsik пишет: 1. ППА D14 перенесённым с адреса A000 куда-то ещё


2.  ППА D14 навсегда перенести в другой адрес, то останется коммутировать всего одну цепь - выборку окна 8000...9FFF

1. Куда именно?



Немного вот не понимаю. Схема, переключая CS D20 куда то там.... неизвестно, также как СS D14 тоже где то неизвестен, делает 48 кб.Перефразирую так,как я это понимаю... перекиньте CS обеих ППА куда нибудь, а потом соберите простейшую схемку переключения D20 на родное место и будет счастье... 

Схема эта меня путает тем больше чем больше я на нее смотрю.

куда уж проще то.....

ведущий_специалист пишет:

barsik пишет:
ППА D14 перенесённым с адреса A000 куда-то ещё
ППА D14 навсегда перенести в другой адрес

1. Куда именно?

Это дело вкуса конструктора. Это же не окончательная схема для изготовления платы, а чтобы показать идею. И ведь неизвестно, где поставлен дешифратор добавляющий нужные дополнительные чип-селекты. Его (дешифратор) обычно в РК ставили на область E000...FFFF. Так например в ж.Радио 01.1993 (или 02.1993 это уже надо смотреть). А Е.Крылова, чтобы поиметь чип-селект для ВИ53 делила дешифратором область A000.

Спойлер:

А я считаю, что делить надо область C000...DFFF, т.к очень ценно наличие ПЗУ 8 Кб (или даже больше, если страничное переключение). ПЗУ 8 Кб значит, что делить область E000 мы не можем, область A000 тоже делить не может (т.к там мы открываем ОЗУ из 565 РУ5). Вот и не остаётся других вариантов кроме как делить область C000...DFFF.

Чтобы устройств было побольше можно использовать ИД7. Он делит участок C000...DFFF на 8 участков с шагом 400. Понятно, что первый чип-селект C000...C3FF - для ВГ75. А вот как назначать адреса портам? Это зависит от схемы. Если только переносим запасной ППА D14, оставляя клавиатурный ППА D20 навсегда на 8000, т.е создаём фрагментированное ОЗУ из 2-х кусков - основное и дополнительное, например в окне 8800...BFFF (14К). Тогда для ППА D14 адрес следующий - C400.

Но, если схема с отключением ППА клавиатуры на 8000, то возникают два варианта. Первый вариант это иметь доступ к ППА клавиатуры только на адресе 8000 (тогда в режиме 48К в порт клавиатуры не залезть никак). Можно на 8000 ППА отключать, но иметь его дублирующий адрес в области доп.дешифратора, например на C400. Понятно, что чип-селекты 8000 и C400 объёдиним на ЛИ1 (или 2-мя диодами, как сделано в плате ЦП в ИРИШЕ у D19). Тогда программа может обращаться к ППА как по адресу 8000 (когда он не отключен), так и по адресу C400, когда порт 8000 недоступен.

Это в принципе не обязательно, но даёт определённое удобство, т.к в противном случае программе на 48К, чтобы залезть в клавиатуру надо предварительно её вернуть в адресное пространство, а поработав с ним снова отключить. И стек нельзя ставить на область 8000...87FF.

А ежели для ППА клавиатуры в области C000 есть дублируюший чип-селект, то гонять туда-сюда режимы архитектуры для чтения клавиатуры не требуется. В принципе чип селектов хватает, а два диода или даже вентиль из ЛИ1 не особо дороги. Это можно сделать и проводами на старой РК-плате.

Ладно, давайте чтоб было хорошо, сдублируем ППА клавиатуры. Тогда, чтобы проглядывала приемственность и логика, сохраним порядок портов, т.е сначала ППА D20 на C400, затем D14 на C800. Далее РК-КНГМД, он был первым серъёзным В/У. Затем надо ставить винт. А затем может стоять контроллер micro-SD. А вообще, чтобы выбирать архитектуру надо знать о чём речь. О единичном образце? О плаформе с изготовлением печ.плат? Или о доработке проводками на старой плате? У вариантов разный подход и критерии.

Теперь о том, что такое /CS48K и /CS32K. Это именно чип-селекты, а на триггере реализован так называемый программный ключ. Он переключается не в соответствии с данными на ШД, а чип-селектами (таких программных ключей в Apple-II и его периферии - как грязи). Выигрыш от применения программного ключа в том, что ШД совсем не грузится (потому портов можно добавить тысячи).

Для программного ключа нужно два чип-селекта - один взводит триггер, второй его сбрасывает (т.к один чип-селект подключен на вход S, другой на R). Важно только само обращение в порт программного ключа (в Apple-II даже неважно чтение или запись). При обращении по адресу по которому формируется /CS48K естественно должен включаться режим ОЗУ в сплошные 48К.

Но программный ключ это для самого простого варианта доработки проводками на имеющейся плате. Если речь о изготавливаемой промышленным способом печ.плате, то естественно разумно поставить 1533 ТМ9 как обычный порт на запись, тогда появится и возможность переключать страницы ОЗУ и ПЗУ и включать/выключать прерывания.

Чтобы порты В/У в области C400...DFFF шли подряд и логично, я и предложил чип-селекты программного ключа перенести на самые верхние адреса ИД7, т.е на D800 и DC00. По записи на один из них триггер взводится, а по обращению на другой сбрасывается. Если у Вас всего один чип-селект, то придётся применять не программный ключ, а традиционный однобитовый порт выходящий на ШД, - тогда триггер включают по схеме D-триггера и образуется однобитовый порт. Но по этому биту он и грузит шину данных, что нежелательно в РК86.

Формирование /CS основного ОЗУ в базовой схеме происходит объёдинением 4-х чип-селектов с выхода D11. Но тот же сигнал это А15 - он равен 0, когда идёт обращение в область 0000...7FFF. Потому почти вся логика на плате РК, что формирует /CAS-ы освобождается, если использовать А15. И вентили на нижней части схемы не дополнительные, а те, что освободились, те что шли с выходов D11. Т.е на этой схеме ЛП5 и ЛИ1 это освободившиеся элементы на основной плате.

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

Изменил схему в вышестоящем посте. Подписал те элементы, что использованы из освобождённых на основной плате. Т.к на выборку формирователя /CAS теперь заведён (через диод заменяющий ЛИ1) адрес А15 (блокированный сигналом НП, чтобы при сбросе ОЗУ на 0 не было), то теперь элементы D5.3 и D10.4 больше не нужны и удобно используются в доработке платы РК проводками.

Т.к теперь у D11 ИД7 нужны всего 4 выхода, то при проектировании своей печ.платы можно в роли D11 поставить половинку ИД14, а область C000 разделить второй половинкой ИД14. Что с'экономит целый дешифратор, но вдвое сократит число адресов доп.портов, т.к область С000...DFFF с помощью половинки ИД14 разделится лишь на 4 куска. А т.к один чип-селект на C000 уже автоматически занят на ВГ75, то остаётся остаётся всего три чип-селекта (один из которых нужен для переключения режима.

Тогда на переключение архитектуры 32К/48К ставим вместо программного ключа обычный D-триггер (это тратит один чип-селект вместо двух) и остаётся два чип-селекта. Один понятно под запасной ППА D14, а второй под винт. Мне этого бы хватило, т.к у меня больших планов на РК нет, хочу только посмотреть на игры с тайловой графикой и всё. Но если надо ещё включать прерывания, переключать банки ПЗУ, управлять схемой загрузки фонта, то с ИД14 на это чип-селектов уже нет.

Кстати, чёрная схема совсем не видна, бесполезна

barsik пишет:
Кстати, чёрная схема совсем не видна, бесполезна

Спасибо за развернутый ответ. Это расставило на свои места все, что нужно было знать. Насчет черной схемы, вроде как высокого качества делал а этот сайт, куда нужно ее заливать сам ее уменьшает. Я с этим немного повоюю. По сути да, хочу с Вами согласиться, переключатель на тм2 штука хорошая, но тм9 тут будет гораздо красивее и удобнее смотреться. Там ведь тоже просто у меня, переключать либо CS порта клавиатуры, либо CS 8ми килобайтной статической озу на этот адрес. Схема (думаю) будет еще проще. Записал в адрес(где висит ТМ9) слово состояния - работает микросхема клавиатуры на 0х8000, записал другое слово - висит 8 кБ ОЗУ. Должно получиться просто гениально.
Чтобы было понятно, рисуется схема РК с доработками и обязательно будет новая плата. У меня с этим строго ))). Если решил делать - то по любому выведу результат. Кстати клавиатуру уже вывел на печать, собираюсь заказывать в работу платку. Могу показать.

Ещё вот такая "химическая" идея, что тоже может найти применение при строительстве двух-архитектурного дешифратора. У 555 ИД7 можно напрямую соединять выходы (тот выход, где 0 утягивает оба соединённых выхода на 0), а у 1533 тоже самое не работает.

На установленный в плате 555 ИД7 D11 сверху напаяем дополнительный 555 ИД7 D11' с запайкой большей части ног в параллель. Лишь у второэтажной ИД7 выход D11/11, что соответствует адресу 8000 не запаиваем в параллель с нижним ИД7, а отгибаем (этим сигналом объединённым с выборкой A000 в режиме 48К будет выбираться ОЗУ в окне 8000...BFFF). Ногу D11/10, т.е выборку A000, тоже не запаиваем в параллель, а отгибаем - этот сигнал в режиме 48К тоже должен открывать ОЗУ.

Потому отогнутые ноги 11 и 10 верхней ИД7, т.е выборки 8000 и A000 соединяем вместе отрезком проволоки или каплей припоя (такое закорачивание экономит вентиль ЛИ1 нужный по теории для их объединения) и этим сигналом должно открываться ОЗУ (8000...BFFF) из 565 РУ5 в режиме 48К (это можно сделать 2-мя диодами или вентилем из ЛИ1, что образует ИЛИ по нулям, на входе D10.2/4).

Также у верхнего ИД7 отогнуть выход для выборки C000 (D11/9) и отдельным (где-то рядом вторым этажом припаянным) ещё одним ИД7 разбить эту область C000...DFFF на 8 участков и естественно младший выход ИД7/15 соответствующий адресу C000 подключить проводом к родному D11 ИД7/9 (т.е впаянному в плату РК). Выборку обоих параллельных D11-тых ИД7 сделать в противофазе - нижний базовый ИД7 выбран в стандартном совместимом режиме 32К, а верхний ИД7 - в режиме 48К.

В такой схеме в режиме 32К, как в ППА D20, так и в ППА D14 можно обратиться только по их родным адресам 8000 и A000. Альтернативные адреса в области C400...DFFF как этих портов, так и вообще всех остальных портов в режиме 32К недоступны. И только в режиме 48К становится активен верхний ИД7 D11' и появляется доступ к доп.портам C400...DFFF. Эта схема позволяет запасной ППА D14 в режиме 32К оставить на родном месте A000 (что важно, чтобы не менять прошивку контроллера micro-SD и программу обслуживания УФ-прошивателя), как и ППА клавиатуры 8000. А в режиме 48К, как тот так и другой ППА будут иметь другой адрес.

Такое запараллеливание 555 ИД7 позволяет с'экономить число вентилей и диодов, а вся схема в режиме 32К остаётся родной. Всё равно доп.дешифратор ИД7 на плате РК придётся напаивать где-то вторым этажом, так пусть хоть сама напайка (в параллель) с'играет роль коммутатора режимов 32/48 Кб.

PS. Это конечно "химия", т.к коротить выходы TTL-микросхем не принято. И не исключено, что 74LS138 какой-либо фирмы такое не понравится.

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

Здесь я описал включение параллельного дешифратор ИД7 (что заменяет D11 в режиме 48К) таким образом, что абсолютно на 100% сохраняет совместимость, как и в оригинале на все порты 8000, A000, C000, E000 выделены целиком 8 Кб участка. Потому, например, команда записи в DFF0 прекрасно попадёт в порт ВГ75 в точности, как при команде записи в адрес C000 - т.к в РК86 из-за расточительности разработчиков РК86 значение при адресации в ППА имеют лишь 2 младших бита адреса - потому в участке 8 Кб возможно 2048 вариантов адресации попадающей в ППА.

А в режиме 48 Кб, где родной дешифратор ИД7 КП11 деактивирован и работает альтернативный ИД7 КП11', в области C000...DFFF вдруг вместо одной БИС ВГ75 (занимающей все 8 Кб) возникает 8 чип-селектов, оставляя для ВГ75 крошечный участок всего в 1 Кб. А порты 8000 и A000 вообще исчезают (на их месте возникает ОЗУ), но теперь становятся доступными в адресах C400 и C800 соответственно.

Однако никто не заметил, что я тут упустил один момент. Никто не задал вопрос: "А как же включить режим 48 Кб ?" Ведь системный регистр который делает такое переключение управляется доп. чип-селектом полученным делением области C000 на 8 участков. А если в режиме 32 Кб эти доп. чип-селекты отсутствуют как класс и весь участок 8 Кб занимает ВГ75, то никак не включить режим 48 Кб.

В таком варианте придётся не ставить ПЗУ 8 Кб, а добавить на плату 1533 ЛА3 (дающую в области E000...FFFF две выборки E000 и F000) и триггер ТМ2 как порт, что даст возможность управлять переключением 32/48 Кб командой OUT (F800),A. Но наличие ПЗУ 8 Кб в пять миллионов раз ценнее, чем совместимость с лишь теоретически возможными очень неметкими программами, что адресуют ВГ75 не на адресах C000/C001 и C0C0/C1C1, а неприцельно попадают по всему участку в 8 Кб.

Потому необходимо и выборку по адресу C000 (D11/9) альтернативного ИД7 КП11' запараллелить с выводом 9 родного ИД7, исходно стоящего на плате РК, и уже этот объёдинённый выход разбивать дешифратором ИД7 второго уровня на 8 участков, с целью поиметь дополнительные чип-селекты. Тогда дополнительные устройства и системные регистры выбираемые в адресах C400, C800, CC00... DC00 будут доступны и в режиме 32 Кб.

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

Предлагаю вот такое распределение адресов при разбиении области C000...DFFF дешифратором с целью поиметь дополнительные чип-селекты. Это сделано логично в соответствии с хронологическим порядком появления конкретных устройств для РК86, по мере появления занимая очередной адрес снизу вверх.

Я еще пока особо не вникал, но как быть с подгружаемым знакогенератором на оперативке, который на кп11 зеркалится в основное адресное пространство.....Тут загвоздка. Если не ошибаюсь, он зеркалился куда то в область монитора чтоли. Как быть с ним?
Адресное пространство в принципе меня полностью устраивает и это МОЖНО повторить в железке. Но хотелось бы конечно играться с загружаемым знакогенератором на лету.... Да, я понимаю, набор из сотен килобайт со всевозможными шрифтами.... Но согласитесь, иметь озу и подливать в него данные с диска намного приятнее и эстетичнее. Я думаю стоит обдумать эти моменты.

Раз уж тема пофлеймить.
Я долго обдумывал тему насчет отладки и эмуляции монитора для новодела. Также как и отладки дешифраторов и прочей железокасающейся рутины. Постоянно перешивать пзу монитора, также как и знакогенератора при отладке видеочаасти рк и написания операционки как то наводили на большую трату времени.
Так вот. может оно конечно и выглядит совсем пошло но.....
Мысли пришли такие, всю процессорную часть с основной памятью 32 кб дма контроллером и ПЗУ е000-ffff поручить 32х битному микроконтроллеру с крутящимся внутри эмулятору. Благо этот момент отработан у меня еще в далеком 2012 году.
Так вот... Данный момент хорошо разгрузит все рутинные работы в отработке нового монитора, написания новой биос и соответствующего меню в плане выбора режима совместимого с стандартным 32 кБ рк. Также можно великолепно довести до ума работу винксру с его аля нортоном и читалкой SD карт, доработав этот проект на запись и внедрить в него пару редакторов и что то типа редактора биос, может можно будет подумать и о своей операционной системе.
Далее к микроконтроллеру подключить по абсолютно 100% совместимой шине адреса и данных все дополнительные корпуса микросхем, а это порты, доп озу, доп пзу, контроллер видео.... Тем самым лично мне это будет гораздо проще. живя программно в инфраструктуре 32х битника, имея в отладке всю память как на ладони. и изменяя чуть ли не онлайн код монитора..... Думаю это будет гораздо приятнее.
Уже потом, когда все будет пыхтеть и работать в плане программного обеспечения. пересадить все железяки под управление монстра типа z80 8080 8085 не важно

А чем Вам отладка ROM-BIOS в эмуляторах не угодила? Это на два порядка проще и удобнее. Вместо сотни часов электротраха с железом, а потом ещё и с программированием, достаточно пары минут на редактирование конфига эмулятора под желаемую архитектуру и пожалуйста - отлаживай ROM-BIOS, не припаяв ни проводка.

И чего там в ROM-BIOS-е надо менять? В режиме 32К в ПЗУ д.быть тот же базовый ROM-BIOS 1986 года (или 100% совместимый, у меня как раз есть такой с сотнями свободных ячеек и курсором меняющим форму в зависимости от включённого регистра).

А в режиме 48К по идее в ПЗУ удобно поиметь точно тот же ROM-BIOS, но с экраном не на 76D0, а с экраном на B6D0 (и соответственно перенесёнными раб.ячейками с 7600 на B600), а исходник такого монитора получается просто изменением одного символа в исходнике для оригинальной архитектуры. Откуда тут какие-то проблемы, что надо городить какую-то кошмарную STM32 и её помощью отлаживать ROM-BIOS?

Но даже для режима 48К иметь отдельное ПЗУ не обязательно. Ну, во-первых, достаточно ввести одну переменную (раб.ячейку) в которой должен храниться старший байт экрана. Да даже и это не надо, если ввести возможность читать состояние флага 32/48 из сист.регистра (под который Вы хотите применить ТМ9).

Разработка универсального (к адресу экрана) кода ROM-BIOS конечно потребует переделать п/п F82D, ролик, позиционирование, да и много других п/п-мм. Но для этого вполне хватит 285 свободных байтов, что я освободил оптимизацией кода ПЗУ РК, а при применении Z80 свободных байтов станет на полсотни больше.

А во-вторых, кто заставляет менять ПЗУ в режиме 48К. Пусть оно остаётся базовым оригинальным кодом из 1986 года. Ведь 48К нужны в основном для игр полученнных из под ЯВУ, ну и для DOS, которой нужно много сплошного ОЗУ. В DOS это не создаёт проблем, т.к там свой DOS-BIOS, а для игр достаточно иметь в одностраничном ПЗУ 8 Кб (E000...FFFF) код ROM-BIOS для ОЗУ 48 Кб странслированный для работы из ОЗУ (где-то ниже C000). Когда нужно работать в режиме 48К, то код этого ROM-BIOS-а для ОЗУ копируется в ОЗУ (там всё то же самое, только стандартные входы находятся не на F800, а на B800).

Для ROM-BIOS в ОЗУ даже можно сохранить входы в ПЗУ F800. Для этого достаточно все п/п-ммы (кроме RDBYTE, SVBYTE, CHKSUM) снабдить векторами (т.е каждому входу даются 2 ячейки, где хранится исполнительный адрес подпрограммы), по типу как это было в грамотных 8-ми разрядках - на вектора ПЗУ грузятся драйвера вывода символов (разных размеров шрифтов).

А менять/переключать ROM-BIOS удобно тем же самым сигналом 32/48, которым переключается архитектура. При этом ПЗУ E000...FFFF уже должно стать двухстраничным, т.е потребуется не 2764, а 27128 (или 27256 при 4-х страницах).

как быть с подгружаемым знакогенератором на оперативке, который на кп11 зеркалится в основное адресное пространство...

Во-первых, если нужно окно памяти (через которое заливается фонт), то можно 1 Кб отдать из области C000...FFFF, уменьшив шаг разбиения до 512 байт. Как раз для ВГ75, кажется этого хватит, т.к там вроде используются всего 2 адреса (очень могу ошибаться, т.к память стала дырявая, - даже пару месяцев знания не держит, в частности, если несколько месяцев не программирую и не изучаю Паскаль, то забываю всё почти до нуля и приходится потом ещё час-другой смотреть свои-же исходники и вспоминать).

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

В том то и дело, сам сок программирования практически на аппаратом уровне повышает эффективность выхода продукта в разы. Я хочу отладить железо в живую, что даст мне эмулятор на пк? Как я к примеру влезу в область выше 76d0 в эмуляторе? Как я посмотрю в нем состояние триггера защёлки при обращении по этому адресу? Микроконтроллер всё это позволит. Можно на 100% отладить железо и свободно выводить печатную плату для заказа прототипов. Это же хобби, у каждого это проявляется по разному. Взять например Виктора, он на отрез отказывается от второго этажа и пары мгтф проводов, зато блестящая, вымытая от флюса свежесобранная плата, источающая пары несмытого бензина нагревом корпуса процессора и созерцания заветной надписи на экране.... Не согласитесь ли, тоже своего рода удовольствие? Конечно же отладка микроконтроллером не панацея, но все же очень наглядно. Это для вас перелопатить 2 КБ кода копаясь в хексе несколько часов, дабы переобозначить видео область в верхние адреса, может и не составит труда, но для меня гораздо быстрее будет полностью погрузиться в процесс и от транслировать исходник заново, при этом найти пару ненужных функций, либо добавить что то необходимое для новшеств.

ведущий_специалист пишет:сок программирования практически на аппаратом уровне в разы повышает эффективность выхода продукта в разы.

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

ведущий_специалист пишет:Как я к примеру влезу в область выше 76D0 в эмуляторе?

В плохом эмуляторе (это обычно все он-лайн эмуляторы, чтоб им провалиться!), где как класс отсутствует встроенный отладчик, - это чуть-чуть сложнее, - просто в конфиге ставите программный отладчик (это 4 Кб, могу дать исходник) в ПЗУ на свободном месте архитектуры. А все оффлайновые эмуляторы для IBM PC имеют отладчик.

ведущий_специалист пишет:Как я посмотрю в нем состояние триггера защёлки при обращении по этому адресу?

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

ведущий_специалист пишет:Это для вас перелопатить 2 КБ кода копаясь в хексе несколько часов, дабы переобозначить видео область в верхние адреса, может и не составит труда

Я общался на форуме nedoPC.org с одним фанатом РК86, который тащится от модификаций прямо в HEX-кодах. А я вообще никогда не ковырялся с HEX-кодами. Это же идиотизм. Уж в крайнем случае поможет отладчик с встроенным мини-дизассемблером. А я когда интересуюсь чужим кодом, тем более таким крошечным, как 2 Кб, беру IDA и дизассемблирую. Я не использую неудобные современные ID-ы. Для 8-ми разрядок лучше IDA из 1995 года, потому у меня дизассемблированные исходники такие же понятные и удобные, как и написанные.

Спойлер:

ведущий_специалист пишет: всю процессорную часть с основной памятью 32 кб DMA контроллером и ПЗУ E000...FFFF поручить 32-х битному микроконтроллеру с крутящимся внутри эмулятором. Благо этот момент отработан у меня ещё в далеком 2012 году

Значит ли эта фраза, что Вы эмулировали сам процессор КР580 (или м.быть использовали чужую реализацию такой разработки) ? И теперь внутри мощного скоростного микроконтроллера можете сделать весь РК86 целиком. И хотите сделав такое изделие отладить ПО для такой архитектуры в нём? Когда железо эмулируется программно внутри кристалла, это тоже эмулятор, только не чисто программный, а аппаратно-программный.

Согласен, что когда паять ничего не надо, т.е обжигать пальцы и дышать парами свинца, а нужное железо с резидентным ПО реализуется мгновенной заливкой кода по последовательному интерфейсу, то это может быть и не намного хуже. И имеет плюсом, что нет зависимости от чужого эмулятора на PC, где Вы можете менять конфиг только в тех пределах, что заложил автор эмулятора (например, при эмуляции РК86 Вы никак не сможете заменить процессор на 6803 и добавить в архитектуру РК86 видеоконтроллер EF9345P ).

Для сохранения совместимости при модификациях архитектуры нельзя переносить адреса ВГ75 и ВТ57 ! При КР580 области выделяемые в адресном пространстве для всех 4-х БИС в РК86 по хорошему не должны иметь размер менее 1 Кб. Так как есть программы, что обращаются в порты командами IN/OUT.

А для РК-КНГМД дело обстоит ещё хуже, - для РК-КНГМД нужно 2 кб, т.к туда некоторые программы Е.Седова лезут командой IN A,(F4). Программ использующих команды IN/OUT немного, это в основном программы Е.Седова (точнее сама RK-DOS, её SYS-модули и утилиты типа нортон, диск-доктор, и возможно одиско-воженные текстов редактор и бейсик-плюс).

Работоспособность команд IN/OUT на РК86 основана на каком-то странном свойстве КР580, которым не обладает процессор Z80, HD64180ZP8 и другие клоны Z80. Про то, есть ли это странное свойство у 8085 не имею достоверных данных, а англоязычная Вика ничего об этом не пишет, но чётко намекает, что отличия возможны (цитата: "Конечно, возможно, что конкретные 8080 и 8085 отличаются от опубликованных спецификаций, особенно в тонких деталях").

Кстати, в плохом машинном переводе статьи из англоязычной Вики можно читать на её копии (ru.qaz.wiki), в данном случае https://ru.qaz.wiki/wiki/Intel_8085 (что удобно для тех, кто не зная английский язык, для удовлетворения своего ЧСВ хочет заниматься переводами в русской Вике, т.к прямая вставка в русскую Вику машинного перевода запрещена). Я, например, чтобы на напрягать лишний раз мозг, всегда сначала читаю маш.перевод на ru.qaz-Вике, и лишь встретив коряво и непонятно переведённое предложение смотрю оригинал.

Применение IN/OUT экономит в размере кода один байт на команду (по сравнению с LD), но по сути это вредительство, такое же как применение переходов по флагу Parity после арифметических команд. Если в применённом процессоре команды IN/OUT не работают точно так же, как в КР580, то нет смысла тратить на адресацию БИС 1 Кб.

Так что, если применён процессор КР580, а выборка В/У сделана с шагом в 1 Кб, то на РК-КНГМД придётся занять сразу две выборки (область в 2 Кб и лучше кратную x000). При процессорах Z80  и это не поможет, придётся переделывать программы (по счастью для Z80 это уже сделано, т.к я использовал RK-DOS на ОРИОНЕ). Но если это потребуется делать для 8085, то сделать это будет сложнее, т.к очищенный от IN/OUT код для 8085 не уместится в ПЗУ 4 Кб и выиграть место за счёт JR не получится, т.к в 8085 они не работают).

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

Биты D0...D3 разумно отдать на коммутацию фонта и их даже не хватит для их коммутации в 32-х фонтовом ПЗУ 27256 (или в ОЗУ фонта, если оно не 1 Кб, а более). 2 бита надо потратить на коммутацию страниц ПЗУ (чтобы можно было ставить 27256) и 1 бит необходим для включения прерываний (разрешение прохождения импульсов на вход INT процессора). В итоге остаётся всего один бит на коммутацию банок ОЗУ и т.о максимальное ОЗУ улучшенного совместимого РК будет 48*2= 96 Кб. Если банок ОЗУ больше 2-х, то на коммутацию банок надо выделять отдельный системный регистр. Хотя при двух банках 565РУ5 можно достичь полного использования всех 128 Кб, если применить коммутацию ОЗУ в окне размером 32 Кб 0...7FFF. А если в машине есть цвет, то может потребоваться ещё и бит включающий цвет.

А если применять ТМ9, где всего 6 битов, то 4 бита уйдут на коммутацию 2-х банок ОЗУ, прерывания и 4 стараницы ПЗУ и коммутацию всего 2-х фонтов.

При процессоре Z80 шаг разбиения В/У можно сократить, аж всего до 256 байт на устройство. Программы использующие IN/OUT придётся переделать (это уже частично сделано) и как раз Z80 позволяет это делать удобно - выигрываем байты заменой JP на JR и выигранные байты тратим на замену команд IN/OUT на LD. Тогда в области C000...DFFF останется много незадействованных адресов, что можно отдать на окна ОЗУ или ПЗУ (например приятно поиметь сплошное ПЗУ в 14 Кб в области C800...FFFF).

Да, полноценная эмуляция кр580вм80а. Я как то даже пытался на форуме это дело продвинуть, но не на том... Никто короче не оценил. Так и забросил. А тут вспомнил, что это очень удобно. Мне тогда немного не хватило ума в эмуляции дисплейной части, сам рк в одном кристале у меня заработал, со входом клавиатуры и с видеовыходом, но из за неправильной эмуляции видеоадаптера все жутко тормозило.

Вырисовал тут схему. Собираюсь внедрить ее в новодел. Если у кого есть время, гляньте краем глаза, может совсем бред, а может и будет работать. За скошенные элементы извиняйте, работаю в пкаде, а схему для конвертацию в пдф поручил альтиуму, а альтиум все скривил, но думаю основной смысл понятен.
https://cloud.mail.ru/public/3NXz/3XpThuM6a
Готов выслушать всю критику и дельные предложения.