nedoPC.org

Это-то как раз я имел в виду, когда это писал. Я исходил из того, что надо сложить чип-селект /F800, /RD и ещё 10 адресов. Всего 12 входов и ещё один вход на передачу между вентилями. Итого, одним 4-х входовым И-НЕ плюс одним 8-ми входовым И-НЕ не обойтись, - надо именно два 8-ми входовых. Итого, два 8-ми входовых И-Не плюс инвертор.
Это свободная страна и форум не мой. Хотя я и не понял о чём это. Но вообще-то имеющиеся скрипто-настраиваемые эмуляторы EMU/EMU80 считаются хорошими.


С другой стороны, настроить эти эмуляторы так, чтобы страницы переключались по чтению лучше сделает автор (возможно это не реализовано и нужна новая версия). Хотя я думаю, что у меня, по крайней мере для EMU80, написать конфиг, чтобы переключение страниц было по чтению получится, т.к там в команде для упр.порта указывается, что это на запись. Но это не значит, что эмулятор заведомо поддерживает переключение по чтению, надо экспериментировать. Завтра вечером постараюсь попробовать. СамомУ интересно, управляется ли в эмуляторе запись в управляющий режимом регистр по чтению.
Трудоёмкость написания эмулятора и редактирования конфига соотносятся на ~5 порядков. Одно делается минуты, другое - годы. Значит потратить минуты лень, а трахаться долгие годы не лень.
А Вы напишИте в ассемблере Z80 исходники хотя-бы для пары законченных программ по 2-3 килобайта объектных кодов каждый. Тогда Вы сразу передумаете, что мнемоника 8080/8086 лучшая. Я макрокомандами переделывал мнемонику 8086 под Z80. Всё-равно при разработке на 8086 из-за недалёкости переходов по флагам надо использовать макрокоманды (чтобы не заморачиваться многострочными конструкциями).

Замучaлся с чёрными экранами…

P.S.: Ещё вариант… Сдвиговым регистром…
Защиты логикой нет, только перемычками…
Платкой не так уж плохо смотрится…

Да, в этих эмуляторах, особенно в EMU, нет вывода протокола ошибок конфига. В случае серъёзной ошибки просто чёрный экран, а часто и улёт. В EMU80, если ему не удаётся создать объект или не найден второстепенный файл, то выдаётся ERROR LOG, но тоже не всегда, иногда (когда проблема архитектуры) просто происходит улёт.

Обычно чёрный экран, если эмулятор не нашёл важного файла указанного в одном из конфигов (в EMU80 два или три конфига и инклюдэ). Например, если не найдено файла ПЗУ, одного из файлов фонтов, OPT-файла и других. Или конфликт по адресам устройств. Потому менять конфиг надо очень медленно и постепенно по одной строке. Тогда сразу ясно из-за какой строки завис. Если не прошло, то откатываем и ищем причину проблемы.

Попробовaл набросать универсальную схему…
Надеюсь, маразм ещё не до конца меня одолел и вариант - работоспособный…

• Стандартный режим - удалить JP3, а JP2 позволяет выбрать один из двух МОНИТОРов
• Режим FFFE/FFFF -JP3 перекинуть вправо и JP1 вставить(вариант 1)/удалить(вариант 2)
• Режим FFF0…FFFF -JP3 перекинуть влево JP1 удалить(вариант 1)/вставить(вариант 2)
• JP2 определяет чётные/нечётные страницы 2 Кб внутри 4 Кб

Тем самым, используется 155ИР1 в двух режимах, 155ЛА2 и 155ЛА4…

Схема достаточно компактна для размещения на платке 40×46…
И детали - одни из самых доступных…
Как видно, регистром выбирается один из 16 сегментов по 4 Кб.
А перемычка JP2 выбирает нижние и верхние 2 Кб в выбранных 4 Кб.
Тем самым, мы имеем как программный контроль, так и ручной механический…

Я вижу, что /CS_F800 приходит на регистр. Но без участия сигнала /RD в процессе записи номера страницы схема не вполне корректная и может не работать.

Тaк-с…
Сигнал /CS_F800 идёт от D4.3 (после Сброса) или D11 (в остальной период).
Когда процессор выдаёт HLDA, адрес переходит в Z-состояние и, фактически, D11 выбирает D17 по адресу FFFF…

Хм…
Что ж…
Дурень!

Слишком увлёкся всем этим и упустил из внимания элементарное!

Спасибо!

В таком случае моя схема всегда будет выбирать банк #15 в режиме «Parallel» или шагать по банкам #1-3-7-15 в режиме «Serial».

Короче - мусор!

Надо отвлечься…

Глянул я на схему любимца в очередной раз и вспомнил, что потенциал D11 реализован наполовину, так как Y0…Y3 выбирают ОЗУ.
Если в оригинале дешифрация такая:Если схему легонечко прооперировать, можно добиться более компактной дешифрации:Если же вывод 5 с земли убрать и подать на него A11 (на схеме зелёным), то можно добиться и такого:Это ещё любопытнее, но МОНИТОР отвалился…

P.S.: В публикациях РАДИО было не мало вариантов доработки схем с добавлением дополнительного дешифратора.
Вопрос: Что теперь делать с D5.3 и D10.4?
ОЗУ некуда управлять…

Идею большого ROM-диска, вы воплотили в коды модификации ПЗУ для получения многобанковой директивы R. В ней Вы третий параметр (адрес куда грузить) заменили на номер банки ROM-диска. Сначала я не оценил саму директиву (думал там сделано нормально), обратил внимание лишь сегодня читая другой форум, где Вы продублировали эту идею большого ROM-диска. Кстати, будьте на том форуме осторожнее, там за посты без грамматических ошибок и длиннее 30 строк забанивают навечно.
На такое редактирование директивы R можно ответить только вопросом: Когда Вы прекратите заниматься маразмом? - редактировать ПЗУ в машинных кодах. Естественно, когда программы пишут в машинных кодах, то можно сделать только незначительные модификации. Начните работать с исходниками, используя текстовый редактор и макроассемблер. Иначе Вы и дальше обречены на такие несуразные директивы. Специально для Вас выложил исходник ПЗУ РК со свободным местом. Если нормальная мнемоника не устраивает, так перекодируйте в мнемонику КР580 (я несколько раз выкладывал ссылку на закачку конверторов).

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

Кто мешает ввести четвёртый параметр директивы? Тогда и адрес загрузки останется и N банки будет. В M3-EXT для ОРИОНА есть директивы с 4-мя параметрами, есть директивы с цифровыми параметрами и символьными (именами файлов). И кто заставляет использовать совсем тупой формат ROM-диска, где файлы свалены в кучу, без адресов, опознователей или разделителей, имён и даже каталога?

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

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

А вообще в ПЗУ РК86 CCP (интерпретатор командной строки) не оптимальный. И процедуры директив неоптимальные. Гораздо грамотнее CCP сделан в M3-EXT и коды всех директив там лучше по качеству и меньше по объёму. Например, DIR_D даёт и HEX и ASCII (отпадает дурная директива L), DIR_M позволяет шагать и вверх и вниз, и вводить не только HEX, но и ASCII. DIR_S ищет не только один байт (от чего польза нулевая).

Так, что если переписать в РК86 весь монитор эффективнее (имеется в виду код директив, п/п ввода/вывода трогать нельзя), то можно иметь директиву D без параметров выдающую в 4 столбца список игр вашего Супер-ROM-диска. И директиву "цифра" для запуска игр Супер-ROM-диска. Например, чтобы запустить игру, что в списке под номером 38, вводим командную строку: 38<ВК>.

Ну, а если хочется сделать поддержку Супер-ROM-диска тупо и минимальным трудом, введите директиву P, что будет задавать номер банки ROM-диска. Сначала задаём номер банки, а затем директивой R со старой лексикой читаем оттуда в ОЗУ блок кодов.
На самом деле - лишь вариант дешифратора И.Крыловой, что усердно пропагандировала 580 ВИ53 в дурном варианте использования с всего одним каналом звука (три публикации об одном и том же) и дешифратор Е.Седова, чтобы совместить РК по доп.чип-селектам с Микрошей (что позволяет использовать РК-КНГМД от Микроши).

Вариант Е.Седова оправдан, чтобы совместить RK-DOS с Микрошей. Но с точки зрения расширения ПЗУ он плохой, потому, что мешает использовать всё окно E000...FFFF отведённое для ПЗУ под ПЗУ в 8 кб (или страничное с окном 8 кб).

Правильнее иметь один дешифратор, чем два. Где ставить ВИ53 непринципиально, а адрес РК-КНГМД также не проблема перенести (в адрес КНГМД лезет только сама DOS и форматёр дискет, так что поменять адрес не проблема). Исполняемый код RK-DOS также может размещаться в любом месте памяти.

Но точку входа в RK-DOS E001 менять нельзя, т.к туда лезут все прикладные программы. Пусть их не очень много, но их дизассемблировать и менять в них адрес BDOS - не только утомительно, но и вредно нарушать совместимость. Т.к не исключено, что кто-нибудь из фанатов РК86 завтра сойдёт с ума и начнёт штамповать в огромном количестве и качестве программы для оригинальной RK-DOS или кто-то из Лианозово откопает в лесу сундучок с дискетами полными программ для RK-DOS.

Удобно получается, если область 8000...9FFF делим дешифратором под порты, а ПЗУ увеличиваем до 8 кб в области E000...FFFF. А ещё лучше под доп.порты только 8000...8FFF, а область 9000...9FFF отдаём под ПЗУ для отладчика (точно как сделано в конфиге, которым я пользуюсь).
Вопрос неясен. Вы хотите использовать идею, что использует PVV здесь, в таком варианте эти вентили свободны.

Дa, именно!
Смотрю в сторону Китая и практикуюсь в подделке оригинала…
Замечание приму к сведению. Спасибо!
Однако, с подобной активностью там на проблемы вряд ли нарвусь: Зарегистрирован уж 10 лет (оказывается) и написал 30 сообщений… Хм…
(Хотя, даже тут умудрился набуратинить! )
Блокнотом я накидываю дампы какой-то идеи и смотрю на размер, а потом перевожу в листинг с мнемониками… То есть, я - уже робот!
Спасибо!
А исходник МОНИТОРа я давно переписал (каждую строчку) в стиль x86 (весь вечер потратил), когда испытывал свой ассемблер.
(Если интересно глянуть - прикрепил)
Да, выбирается лишь страница для загрузки дампа адрес к адресу… Можно готовые замороженные Бейсики так грузить, по идее…
В народе шутят, что Internet Explorer нужен лишь для загрузки других браузеров…
Тем самым, в моём случае директива «R» (мой вариант) нужна лишь для загрузки оболочки: «R,F,FF»+«G» - загрузит и запустит некий код в 0000…000F с адреса FF0000…FF000F.
В этих 16 байтах, по идее, нужно лишь разместить следующее:То есть - всего 12 байтов даже требуется!Пространство оригинального ПЗУ МОНИТОРа, которое я своими заплатками уродую…
Оконный вывод символа втиснул со скрипом. Сейчас - до «R» добрался.
Код как бы и на месте, но работает несколько иначе, как видите…
Публикации кода, включая Бейсики и редактор Penx я изучал давно…О чём я и говорю. Можно «R»-директивой самому напрягаться и ботанить. А можно ею просто грузить ту оболочку…
Потому я и прикидывал пародию на DOS-API выше…
Это уже я проходил 15 лет назад, когда познакомился с эмуляторами.
Так можно все «R», «S», «T» и «C» так же переделать на свой лад.
Об этом я думал: Выпилить вообще ссылки на них из «switch»-кучи, чтобы МОНИТОР забыл про них…
Место освободится фрагментарно под многое. В частности, одной директивой оболочку нашу с ROM-диска запускать можно одной лишь буквой…
Но, имеется ли смысл так сильно бомбить МОНИТОР?Это в планах имеется тоже
Руки чешутся аккуратно переписать МОНИТОР на ассемблере целиком на свой лад, но сохранив позиции ключевых подпрограмм. Свой код печати символа я уже сделал - сами знаете…
А вот умный вывод дампа и однострочная «M» - не вмещаются… Выше я снимки экрана эмулятора давал…Были и другие публикации в других журналах (где-то видел), но отцом выписывался лишь РАДИО и «Микропроцессорные средства и системы»…Как-то обрадовался, что в сети нашёл наконец-то тот RK-DOS!
Но изучать, оказалось, было уже утомительно. Да и не покушаюсь я на это всё…
Лишь в пространстве самого МОНИТОРа пинцетиком работаю на Hex-уровне! Значит, это уже было…
Что ж… Сейчас буду изучать…

P.S.: Идеально было бы всю схему компьютера перетряхнуть вот так, чтобы она ровнее стала с тем же набором элементов…
Но я пока лишь ограничусь прошивками ПЗУ…

После замены CALL+RET на JMP будет 11 байтов и можно даже меньше. В общем случае, когда мы видим последовательно стоящие CALL и RET, то возможны лишь четыре вывода, - что это часть большой макрокоманды, что это код из под ЯВУ, что в подпрограмме анализируется адрес возврата или что программист новичок. А в вашем случае зачем сохранять адрес в стеке, а процедуре загрузки быть подпрограммой. Пусть сама сразу и запускает считанный код. Тогда расход кода будет на 5 байтов меньше. Всё равно директива R в таком виде, для считываний не нужна, единственная польза от неё - старт оболочки.

По научному это называется первичный загрузчик. Его задача загрузить и запустить вторичный загрузчик. Это имеет преимуществом то, что вторичный загрузчик может меняться, в случае загрузки DOS - грузить разные варианты DOS (на разные адреса и разного размера). В Вашем случае это даёт сокращение объёма кода истраченного на считывание оболочки, а также при этом можно не перешивая ПЗУ F800 менять адрес загрузки и размер оболочки.

Но вводить директиву R при запуске компьютера утомительно и при перезагрузке оболочки всякий раз вручную набирая строку директивы R по 20 раз в день, в итоге захочется повеситься. Я в 1994 ввёл в ПЗУ РК86 загрузчик с НГМД. Так вот, чтобы грузить с дисковода, я ввёл директиву B без параметров (кстати, место под такой крупный загрузчик в 551 байт было получено выкидыванием МГ-подпрограмм и заменой драйвера матричной клавиатуры на драйвер ASCII-клавиатуры, что на порядок короче, т.к такая клавиатура выдаёт готовый ASCII-код, отчего задача драйвера лишь ждать флаг готовности, а по получению забрать готовый код).

Если и однобуквенную директиву B набирать лениво, то можно обойтись и без команд. Тогда, если при сбросе удерживать кнопку РУС/ЛАТ (что на PC7), то делается JMP BOOT. Расход кода на такую загрузку всего 4 байта.

Вернo подметили про новичка. Ведь преобразование «CALL+RET» в «JMP» - уже наинизший уровень обфускации и может сбить с толку начинающего… Я и так согрешил и вместо «LD C,0FFH» применил «LD C,E»
Если бы посмотрели внимательнее на код вывода символа, то заметили бы, что при скроллинге экрана код не завершается по «RET», а сразу стыкуется с кодом опроса клавиатуры, так как в FE00 не хватило места под RET
У новичка будет ступор, а я подумал, что скроллинг - и так медленный, так что пусть опрашивается клавиатура дважды
Выше я уже сказал, что из-за спортивного интереса в частности я правлю МОНИТОР пинцетиком и жонглирую кодом как фигурками Тетриса: Втискиваю свой функционал в рамки стандартного
МОНИТОР дважды ссылается на адрес F000: При директиве «U» (F88C…F890) и когда директива не опознана (ячейки F8D9…F8DB). Тем самым, ещё 5 ячеек можно отыграть, но весь код придётся двигать. Об этом я давно думаю, но лень пока копаться (ассемблером)…
Пяти ячеек мало? Однако, как нарочно, там (F8D3…F8D8) идёт кейс директивы «R». То есть, в те 5 ячеек можно к «R» добавить ещё чуток функционала.Вуаля! Теперь директива грузит код в произвольную область ОЗУ, но кратную 256.
Так, «RBA98,CDEF,4567» загружает из ПЗУ 0x67BA98…67CDEF в ОЗУ 0x4500…5867. Уже гибкость выше!
Типа, как Windows при загрузке проверяла клавишу «Ctrl» и выдавала аварийное меню…
Можно ещё считывать бит статуса ВГ75 и отсчитать 1 секунду по кадрам. Если пользователь не нажал никакую из клавиш после сброса - начинаем загрузку альтернативной БСВВ.

P.S.: Сброс я тоже хотел бы доработать и сохранять регистры для анализа, если какая-то программа зависла…
Да, адрес инструкции не узнать, но SP тоже немало скажет…

Да не 5 ячеек выигрывается, а 205. И весь код можно и нужно двигать, но соблюдая неизменность нескольких внутренних точек на которые делают вызовы игры идиотов и несколько фатальных внутренних точек, что наложили эмуляторы EMU, EMU80 (сохранять которые важно только для эмуляторов, для реала это не надо).

Но это легко делается, лишь когда программируют нормальными инструментами, а не занимаются мазохизмом, программируя отладчиком. Вы считаете, что это спортивно, но это не советский спорт. Это спорт мазохистов, потому что так программировать это мазохизм. Никто не писал так даже в 1975 году. Тогда не было ни отладчиков, ни ассемблеров. Но писали на бумаге на ассемблере (лишь функцию компилятора выполняли вручную).

По поводу нехватки объёма ПЗУ. Если, как в ОРИОНЕ, объявить обязательным наличие ROM-диска, то легко снимаются все проблемы нехватки объёма ПЗУ F800. ROM-диск позволяет иметь в ПЗУ F800 оверлейные директивы. Резидентными достаточно иметь лишь директивы I и G (как в М3 ОРИОНА). А остальные директивы легко можно сделать оверлейными. Например, после ввода директивы D исполнительный код выполняющий вывод дампа считывается в ОЗУ (основное или дополнительное) из ROM-диска и прогоняется. Для пользователя это без разницы.

Код всех директив умещается в 100 байт, ноничто не мешает изобрести новую директиву с кодом бОльшим (т.к монитор это не отладчик, основное ОЗУ вниз от RAMTOP можно затирать). Т.о за счёт ROM-диска можно одновременно расширить количество и улучшить качество директив, да ещё и освободить в ПЗУ F800 до килобайта свободного места.

Так можно встроить в монитор директивы обслуживания DOS (так было сделано в RK-DOS V1.0). Когда у меня случится очередной припадок для ковыряния в ПЗУ РК86, то возможно на этом принципе встрою в ПЗУ РК86 RAMDOS от Специалиста (там CCP команды RAMDOS являются расширением директив монитора).
Ещё один метод с'экономить один байт. Можно применить, если прижмёт.
Анализа регистров после сброса у Вас не получится, т.к по сбросу во всех процессорах все регистры гибнут и SP в том числе. Регистры можно анализировать, если использовать NMI в Z80. Но программы виснут не в конкретной точке, знание которой даёт информацию, а обычно происходит улёт с гибелью всего или части кода и зацикливанием в совершенно случайной точке.

На эту тему упомяну автостартовый хук введённый в M3 (во все версии кроме стартовой M3.1). Там после изменения 4-х ячеек после сброса происходит принудительный переход. Это было средство для получения слепков памяти, рестарта системы и для защиты от кракеров.
Например, чтобы по нажатию на кнопку СБРОС был переход, допустим, на точку BC00, кладём число BC00 в ячейки F3C1/F3C2, а в ячейки F3BF/F3C0 кладём число BC00 в дополнительном коде минус 1. Тогда по нажатию на кнопку сброс всегда будет переход на BC00. В М3 реализовано на порядок больше идей, чем в М1/М2.

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

Как я и упоминал ранее, даже от таких отвлечённых от реальных потребностей обсуждений бывает польза. И не только в плане моральной поддержки. Во-первых, я вспомнил о забытой на 25 лет идее оверлейного монитора, а во-вторых, вспомнил о резидентных DOS, которые (ради экономии объёма ПЗУ) не имея собственного CCP, в качестве него используют CCP монитора. Так работала RAMDOS для Специалиста и так же работала RK-DOS первой версии.

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

В частности, не очень удачны директивы D, M, T, L и S. Директива М не показывает и не позволяет вводить ASCII и перемещаться по коду вверх-вниз, T не допускает перехлёст областей, а S ищет только один байт. При грамотной директиве D директива L вообще не нужна. А процедура конверсии строки с параметрами неудачна, т.к в качестве разделителя параметров использует запятую и вводит всего 3 параметра. Вместе с тем, стоит заметить, что весь код ПЗУ РК написан на весьма высоком уровне, меньшего объёма кода директив добиться почти невозможно (выигрывается лишь по паре байтов то тут, то там).

Собственно сам монитор неинтересен, его улучшение в виде замены родных директив другими, взятых от других машин не представляет даже спортивного интереса, не требует особого труда и не требует ума. Тем не менее, чтобы использовать CCP монитора для RAMDOS пришлось заменить GETLIN и процедуру конверсии строки с параметрами в HEX-значения, т.к CCP РК не позволяет ввод имён. Родная процедура GETLIN не универсальная (не допускает ввода точки, что необходима для имён файлов). Потому пришлось менять не только код самих директив, но и п/п-мму ввода строки и процедуру её анализа. В итоге на скорую руку скомпилировал новую версию РК-монитора. На этом я потерял более сотни байт, зато теперь можно ввести загрузку из ROM-диска расширения монитора. Это должно делаться автоматически по сбросу, если ROM-диск обнаружен.

Загружать можно любое расширение монитора, т.е можно не только добавить новые директивы, но любую резидентную директиву монитора можно заменить на другую. Например, резидентная директива S ищет один байт (в таком виде она вообще не нужна, отладчики ищут цепочку байт). Но после инсталяции расширения CCP для работы с DOS, директива S в виде:

--> S Имя_файла, Начальный_адрес, Конечный_адрес

записывает файл на дисковый привод (что в зависимости от конкретной DOS м.быть дискетой, винтом или RAM-диском). Если же загрузка DOS из ROM-диска не нужна (когда DOS прошита в ПЗУ, например с E000 или с 9000), то и загрузка директив извне не нужна и экономится ~20 байтов.

Вот пока ради эксперимента странслировал монитор с изменёнными директивами D, M и C. В директиве D теперь можно вводить только нач.адрес. Конечный адрес установится по умолчанию. Т.к достаёт вводить конечный адрес всякий раз когда надо посмотреть дамп. В дампе теперь выдаётся и ASCII представление, как принято в дампах. Директива М позволяет переходить к предыдущей и последующей ячейкам клавишами "курсор-вверх" и "курсор вниз". Для ввода символа ASCII - нажимаем на <АР2>, затем на клавишу символа. Нажимать <ВК> теперь не требуется, ввод автоматически происходит после набора второй цифры (что резко ускоряет ручной ввод дампа и текстов).

Все нестандартные входные точки, кроме одной сохранены. Убрана вх.точка F92C (т.к в применённом теперь CCP логика работы аналогичной п/п-ммы иная). F92C это п/п-мма для преобразования строки с тремя HEX-параметрами в загрузку ячеек PAR_HL, PAR_DE и PAR_BC шестнадцатеричными значениями.

В эту нестандартную вх.точку игры РК никогда не лезут. Из всех программ РК я встретил только одну РК-программу из 1987 года (мини-дизассемблер, 5000...5B18, KS:8DEE), которая нагло лезла в эту точку. Потому эта программа у меня не заработала в эмуляторе РК на ОРИОНЕ (т.к там в ПЗУ F800 только п/п-ммы ввода/вывода, директив монитора за ненадобностью и отсутствия места там нет). А вот в подпрограмму GETLIN (F8EE), также используемую CCP, некоторые РК-игры лезут.

Пoд это дело требуется как минимум 70 символов в строке.
Это достижимо только в моей «Windows'86»… Этo если применять радикально тяжёлую артиллерию и перфоратором всё бомбить…
Как Вы и заметили: Я это и делаю с высокой степенью аккуратности.
Можете заранее предупредить про припадок, чтобы и мой вариант прошить-проверить?
(На реальном железе, разумеется…)
Если верить справочникам по i8080 и z80:
Лет 25 мечтаю это сделать со школы ещё, но понимаю сейчас, что не дорос ещё
Это - не какой-то IBM-PC с Windows и как попало написанным индусами кодом!
Это - РАДИО-86РК
Можно поступить по буржуйски - код точки заменить на Esc/АР2
Про что я и говорю. Я не имею избыточной информации про все программы. Всё нужно трассировать и проверять вызываемые ими подпрограммы из ПЗУ. Потому я иду своим путём с аккуратной правкой…

Кстати, я проснулся и понял, что дамп выше я сделал ошибочным. Вот так надо:Чем удалось и «R» сохранить - работает привычно. И «P» добавить, которая та же «R», но выбирает страницу через ППА клавиатуры…

Вообще-то можно кнопку «Сброс» переделать на разрыв, чтобы сбрасывалось отпусканием. Но более глубоким нажатием должен срабатывать секретный контакт и предустанавливаться бит для активации оригинальной РФ2.
То есть, при холодном старте и при аварии - жмём Сброс глубже, активируя классический режим. А в остальное время - «лёгким движением руки» касаемся Сброса…
Тогда можно на E000…FFFF повесить SRAM на 8 Кб, куда можно залить любую прошивку.
Заливать SRAM через свободные каналы ПДП. Это лучше, чем механическим путём всякими секретными тумблерами включать/отключать защиту банков памяти от записи. Наши программы смогут без нашего механического участия перезаписывать SRAM тогда…
Конечно, ОЗУ можно заменить на РУ5 и переключать две страницы - кажется, это где-то было. Но при этом не использовать биты порта C ППА клавиатуры. Я вообще не понимаю, что за деревянные доработки всюду предлагались, где знакогенератор переключался тумблером или ППА, когда ВГ75 имеет атрибуты и команды «стоп ПДП», что позволяет и атрибут добавить в 76D0 для переключения страницы, и ПДП прервать на 7FF3, чтобы ВГ75 не ожидала лишний символ и экран не поехал. И Emu80 это эмулирует верно, если ввести этот код и запускать его директивами «G0»…«G7» по очереди:P.S.: А с «Супер-РФ2» так и не договорились…
(Идея с заменой одной лишь ПЗУ довольно любопытна…)

А кто заставляет выводить дамп с 16-ю байтами в строке? В Специалисте, ОРИОНЕ и ИРИШЕ выводят в дампе по 8 байтов в строке и никто ещё не жаловался.
На E000...FFFF легко включается большое ПЗУ, т.к оно не создаёт конфликт с ПДП (потому, что из него нет чтения), а вот ОЗУ в этой области можно включить лишь громоздко. Т.к, чтобы поиметь тут ОЗУ, надо коммутировать область F000...F7FF где стоит ПДП, т.е в одной конфигурации тут надо включать ПДП, в другой - ОЗУ. Потому-то, чтобы не иметь мороки с коммутацией, дополнительное ОЗУ и включают обычно на месте запасного ППА на A000...BFFF (перенося это ППА куда-то в другое место).
Да, обслуживание атрибутов EMU80 эмулирует, но атрибуты мы не можем использовать, их уже заняли на цвет. Якобы цветные игры выглядят намного лучше.

Кстaти, можно свитч директив из «CMP+JZ» оформить в цикл с таблицей, примерно вот так:А директиву «P» лучше переработать вот так:Теперь страница ПЗУ для ППА клавиатуры выбирается младшей тетрадой первого аргумента и грузить её можно, соответственно, в любую область ОЗУ.
Например, «R8765,9ABC,1234» загрузит из ПЗУ 0x658700…659ABC в ОЗУ 0x1234…23F0…
Думаю, это удобнее…

P.S.: Как Вы и предлагали, можно уже с лёгкостью использовать и 4 параметра.
Если поставить nop'ы, можно командовать так «R<rom_from>,<rom_last>,<ram_address>,<rom_page>»…

Вы изобрели уникальный метод для пропуска незадействованных в директивах букв с помощью битовой маски. Возможно, это новое слово в разработке компактных мониторов. Может быть попробую эту идею, если она даст реальную экономию (я на днях освободил в ПЗУ еще 5 байтов, теперь 214 свободно, но ещё десяток свободных байт не повредит).

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

Но если все нужные буквы в начале алфавита и таблицу переходов укоротить (лишь для букв C...T), то будет экономия уже при меньшем числе директив.


Вы собираетесь использовать 13 директив: C D F G I L M O P R S T X (к стандартным 12-ти, не считая U, Вы добавили P). Хотя X сразу надо выкинуть, а директива G сокращается до одного байта [ JP (HL) ]. Директива L не нужна, если Вы доработаете D до ASCII (да и без доработки не нужна). Директива S тоже никем не используется. Для реальной жизни достаточно оставить директивы: I, O, D, M, T, F, R. И, может быть, полезно добавить директиву V (Verify) - проверка МГ-записи путём сравнения записи на МГ-ленте с кодом в ОЗУ.

Не освободив место оптимизацией и выкидыванием бесполезных директив, невозможно сделать серъёзных, дающих реальную пользу модификаций ПЗУ. Кстати, освободив место в ПЗУ, можно встроить директивы I/O работающие без гашения экрана (для этого придётся кракнуть коммерческую защиту и выдрать оттуда процедуру чтения работающую без гашения, а вот процедуру записи придётся писать по образцу, т.к инсталляторов многоблочных защищённых от копирования МГ-программ, естественно, не распространялось).

И если всё делается ради ROM-диска, то значит он есть. Что позволяет иметь оверлейные из ROM-диска директивы. В минимуме нужна всего лишь одна директива - I с автозапуском. Ну и для порядка директива G. Если G не надо, то монитор вырождается в загрузку и старт по сбросу, как в Специалисте в минимальном варианте (когда в нём стоит всего одна РФ2 с загрузчиком).

Тогда, если ROM-диска нет, то по сбросу выводится титр и сообщение "НАЖМИ КЛАВИШУ ДЛЯ НАЧАЛА ЗАГРУЗКИ". И пользователь нажимает на клавишу, когда услышит в динамике магнитофона начало пилотона. Но если ROM-диск при сбросе обнаружен, то доступны все нужные директивы (загружаемые при их исполнении оверлейно из ROM-диска).

Кстати, директиву U при наличии расширяющего ПЗУ на F000 полезно заменить на пробел. Тогда все директивы, что должны обрабатываться в ПЗУ F000 можно начинать с пробела и этим директивам доступны те же самые буквы D, S, X... Тогда эти же буквы будут командами не RAM-монитора, а DOS. А вот переход на F000 по ненайденности директивы наоборот надо заменить на JMP WARMST (F86C), т.к иначе, если на F000 стоит РК-КНГМД происходит улёт.