Исходники ПЗУ Микроши и их модернизация

[petrenko]

... легко* доработать ПЗУ так, чтобы консольный буфер был не односимвольным, а .. 16-ти символьным ...

*_Ну ежели "легко" так дело за желанием ?

А ежели Вы умудритесь ещё больше освободить - например 80байтиков - так Вам выразим кило-благодарность.

( Уверен, что "выбрасыванием" магнетофона можно влёгкую даже и поболее.. ; кстати, сколько именно даст "выбрасыванием" магнетофона ??? )

[barsik]

... легко доработать ПЗУ так, чтобы консольный буфер был не односимвольным, а .. 16-ти символьным ...

Ну, ежели "легко" так дело за желанием ?

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

Ежели Вы умудритесь ещё больше освободить, например, 80 байтов, так Вам выразим благодарность. (Уверен, что "выбрасыванием" магнитофона можно влёгкую даже и поболее...)

Я удалил из исходника все МГ-процедуры и, чтобы точно узнать размер МГ-процедур, странслировал их отдельным модулем. Можете видеть "вес" МГ-процедур, посмотрев в листинге трансляции чему равно @SIZE в файле MG.PRN. А оно равно 01C8, что значит, что МГ-процедуры занимают 456 байтов. Сами можете убедиться (файлы во вложении).

А монитор с удалёнными МГ-процедурами и некоторой оптимизацией даёт свободными 489 ячеек. Это также во вложении. Раз (видимо, из-за нелюбви к DosBox и отсутствия Win XP) Вы не любите транслировать, сразу приложил и дамп такого ПЗУ со свободными ячейками, но совсем без магнитофона. Можете прошивать. Кстати, если не надо так много своб.ячеек, то можно было бы удалить только вывод на ленту, т.е директиву O, оставив дирекиву I.

Кстати, в предыдущем дампе происходит завис, если пытаться отлаживать программу директивой G задавая стоп-точку (исправляется заменой одного байта FA49: байт F4 заменить на 9B, можно посмотреть в листинге, что выложен неделю назад в форуме "полигона призраков")

Но магнитофонные подпрограммы нужны, если и не в реале, то в эмуляторах EMU / EMU80, т.к иначе придётся грузить программы в эмулятор через DOS, запуская файлы с образа диска. Лучше выигрывать байты на ненужных вещах. А именно. В мониторе РК есть ненужная директива X, вывод содержимого регистров, позволяющая смотреть регистры при останове в стоп точке. А сама директива G, помимо запуска программ нагружена функцией отладки. На загрузку/сохранение регистров и подготовку стоп-точки в DIR-G впустую тратится много байтов.

Это средство отладки - наследство от МИКРО-80, из времён когда нормального отладчика ещё не было. Директива G имеет загрузку регистров и возможность задать одну стоп точку (для чего перед запуском с заданного адреса в стоп точку подставляется RST-код).

Сейчас уже никто так не отлаживает программы РК (да и даже нормальным отладчиком в реале никто не отлаживает, в эмуляторе удобнее). Потому полезнее в директиве G иметь не задание стоп-точки, а возможность передавать параметры в программу в регистрах, как это сделано в DIR_G применённых в Орионе и Специалисте.

Потому в ПЗУ РК я 40...50 байтов выигрываю на оптимизации (убрав глупости типа LD A,0, ненужные JMP за счёт перестановки фрагментов, заменяю повторяющиеся куски на CALL и т.п), а больше всего байтов выигрываю исправив директиву G и удалив ненужную директиву X. Всё вместе это освобождает более 200 байтов и даёт возможность добавить директивы R, H, K и программные переходы по CC+Fn для запуска резидентных программ и автостарт ОС с ROM-диска.

Таким образом, если из ПЗУ убрать DIR_X и магнитофонные подпрограммы, то свободно будет ~600 байтов. А если вообще убрать все директивы, то оставшийся чистый ROM-BIOS влезет в менее, чем 1 кб и его можно будет прошить в 2708 (573 РФ1). Тогда монитор будет грузиться в ОЗУ по сбросу из ROM-диска.

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

Убрал директиву X, добавил директивы H и K и удалил вектор принтера. Также здесь адреса внутренних нестандартных точек совмещены. Общее число свободных ячеек достигло 628.

Убрал вообще все директивы, хотя и оставив некоторые подпрограммы, что не входят в ROM-BIOS. По сбросу грузится и запускается первый файл ROM-диска в формате ORDOS. Стартовый адрес этого запускаемого файла д.быть 7000.

[petrenko]

... из-за нелюбви к DosBox .. не любите транслировать ...

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

Еле осилил всё написанное, кое что даже понял .. ( )
В практическом смысле вот это :

влезет в менее, чем 1 кб и ... монитор будет грузиться в ОЗУ .. из ROM-диска

- близкое к идеальному решение !



( Поелику есть, что добавить к 1кб , то переходить на рф1 не будем .. .. , но вот получить ~62кб сполошного адр.пространства это просто замечательно )




P.S. К сожалению на реальной микроше "R" хотя и заработала, но как то неправильно - грузятся только нечётные 256-и-байтовые блоки, такое впечатление, что адрес A8 внеш.п.з.у.( то есть линия порта PDC0 ) принудительно "висит" в "1" . Подозреваюмую в нерабочести вв55 поменяли, платочку ROM-disk-а проверили, всё равно такая странность. Изследуем дальше, пока причины не найдены. Аппаратные они или программные тоже не ясно.

[barsik]

... DosBox-ом не занимаюсь... Просто у нас в наличии машинка с "линуксом" и "Win 7" и ничего не получается

Вот потому-то, что Win 7 не позволяет прогонять программы MSDOS и требуется запускать компиляторы (и BAT-файлы) под DosBox-ом (а Win XP позволяет запускать MSDOS-программы без напрягов). Для Линуксов есть эмуляторы MSDOS и ранних Windows (тех в которых MSDOS-программы ешё работают).

В практическом смысле, если ROM-BIOS влезет в менее, чем 1 кб и ... монитор будет грузиться в ОЗУ из ROM-диска - это близкое к идеальному решению! ... получить ~62 кб сплошного адр.пространства - это просто замечательно

Не понял как сокращение объёма кода ПЗУ увеличит доступное ОЗУ с 32 кб (или 48 кб при плате доп.ОЗУ) до 62 кб. Речь о том, чтобы грузить монитор в ОЗУ (причём в основное ОЗУ 32К) из ROM-диска, что экономит объём ПЗУ и даёт гибкость, т.к код в ОЗУ можно быстро изменять. Экономия на стоимости ПЗУ была актуальна в начале 80-тых.

Были отечественные компьютеры в которых в ПЗУ был прошит только загрузчик с ленты (всего 512 байт в 556 РТ5), а основной ROM-BIOS грузился с ленты. В самых первых бытовых микро-компьютерах ПЗУ вообще не было (оно стоило слишком дорого: $100 за полкило), потому даже стартовый загрузчик вводили тумблерами (речь об "Альтаир-8800" в версии 01.1975).

Получить сплошные 62 кб ОЗУ несложно (если стоят 565 РУ5), например, перенеся все порты в область FC00...FFFF, оставив ПЗУ размером в 1 кб только в области F800...FBFF. Экран при этом можно поставить в вершине ОЗУ на адрес 0F800H-78*30. Но пользы от этого почти никакой, а хлопот много. Т.к нет программ, которым это было бы надо, а совместимость с половиной игр потеряется, т.к перестанут работать все программы, что лезут в порты и экран, т.е не только игры с прямым доступом в матрицу клавиш, но и все псевдо графические игры (т.к они лезут к ВГ75). А чтобы работали игры не лезущие в порты, а только лишь лезущие в экран, при старте игры экран придётся программно перемещать на его базовое место 76D0...7FF3, т.е к каждой игре придётся прицепить стартёр, что устанавливает режим ВГ75 как в оригинале.

Убрать из исходника встроенный RAM-монитор и добавить вместо него загрузку блока из ROM-диска - это дело одной минуты. Но надо ещё странслировать RAM-монитор в виде внешнего файла для ОЗУ. Это несложно сделать и это проверяется в эмуляторе. Сделаю это вскоре. Ещё можно сделать просто загрузчик. Есть шанс, что такой загрузчик даже уместится в 256 байт (и его можно уместить в две 556 РТ4). Т.к в 512 байт умещались загрузчики графических машин (для граф.экрана бОльший расход кода на вывод символа).

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

Интересно, что возможность грузить драйвер принтера и включать эхо печать на принтер заменой байта C9 (RET), на 00 (NOP) есть в ПЗУ Микроши из ж.Радио 12.1989, а в заводском оригинале этого нет. Выяснением назначения служебных ячеек (т.е доскональным изучением алгоритма) я не занимался, переименовав в говорящие имена только те служебные ячейки назначение которых ясно при сравнении с ПЗУ РК86. Но главное полноценный исходник есть и можно его модифицировать как понадобится.

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

С целью освободить место, убрал директиву X, добавил директивы H и K и удалил вектор принтера. Также здесь адреса внутренних нестандартных точек совмещены. Общее число свободных ячеек достигло 628. download/file.php?id=4111

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

В реале и в эмуляторе не проверялось. Попозже разберусь с ROM-диском в эмуляторах и странслирую загружаемый на 7000 RAM-монитор (не "эр-кашный), предназначенный для такого ПЗУ в 1 кб. Если убрать нестандартные входы, то возможно удастся сделать загрузку с МГ и всё-равно уместиться в 1 кб. Т.е в ПЗУ будет ROM-BIOS и загрузка по сбросу, как в "загрузчике" Специалиста. download/file.php?id=4112

[Shaos]

Администрация таки перенесла посты в новую тему

[petrenko]

.. в новую тему ..

Вот и хорошо.

Микроши .. ПЗУ написано на более слабом уровне, чем ПЗУ РК86, которое явно получено оптимизацией и существенной доработки этого же исходника

Что на более слабом - это давно известно.
Уважаемые Горшков Д. , Зеленко Г.В. , Озеров Ю.В. , Панов В.В. , Попов С.Н.
сделали насколько могли хорошо
, изходя из возможностей
, а вот лианозовские потом , делая "по мотивам рк" ,ухудшали насколько получалось
, не внимая замечаниям создателей оригинала.
Это печальный исторический факт.

А вот каким образом, коллега, по Вашему п.з.у.РК ( какой год ? ) получено ИЗ п.з.у.Микроши( какой год ? ) ? ? ?
( off: Ладно, не буду дальше придираться, я ж не ядовитый пенсионер, так чутка посмеялись и ладно. )



Вам очередная благодарность за конструктивные действия с практической пользой для ретро-сообщества !

Будем изучать закачаные материалы, "есличё" неясное, будем уточнять, далеко не убегайте.

[petrenko]

К сожалению директива "R" добавлена не один-в-один как она в рк ,а через call ,внутри call ,что не учитывет временн`ые задержки в реальном железе.
В результате в оп.память грузится нечто рандомное.
Также есть небольшой "снежок" на дисплее по неясным причинам.

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

Печалька. Будем надеяться , что "на горизонте" появится что-нибудь, что поможет с данными затруднениями.
( ну или придётся самостоятельно изучить всё досконально и "допилить" )

[barsik]

К сожалению, директива "R" добавлена не один в один, как она в РК86, а через CALL (внутри CALL), что не учитывает временн`ые задержки в реальном железе. В результате в оп.память грузится нечто случайное.

Разберёмся. Чудес не бывает.

Не знаю о какой конкретной версии речь, но я посмотрел ПЗУ МИКРОШИ, которое положил себе в архив и увидел, что там я вставил именно один в один код директивы R из ПЗУ РК86. Вот такой код:

Code: Select all

DIR_R:  LD      A,90H
        LD      (PU),A            ; PA на ввод, PB и PC на вывод
DIRR1:  LD      (PB),HL
        LD      A,(PA)
        LD      (BC),A
        INC     BC
        CALL    CHKEND
        JP      DIRR1

CHKEND: CALL    CMPDH
        JP      NZ,INC_HL
POPAF:  INC     SP                ; лучше POP AF
        INC     SP
        RET

INC_HL: INC     HL
        RET

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

Дополнительные CALL-ли, даже, если бы они были, могут вредить только если программа работает с неправильным стеком. Задержки на CALL никак не могут повредить, ведь это несинхронное устройство.

Для случая скоростных машин с ROM-диском можно упомянуть один нюанс. Адрес ячейки ROM-диска выкидывается в ППА (в PB и PC) одной командой записи слова - LD (PB),HL. Это приводит к тому, что между двумя записями в ППА маленький интервал. А, как показывает опыт, ППА довольно долго выполняет запись (более 1 МКС). Потому, если между двумя записями в ППА маленький интервал, то вторая запись не проходит, отчего занесённый в ROM-диск адрес оказывается неверным.

Потому в турбированном ОРИОНЕ иногда ROM-диск в режиме Турбо не читается (иногда помогает подбор ППА, но более грамотно завести чип-селект ППА на схему WAIT в КНГМД, что вдвое удлиняет доступ). Но на тактах до 3 МГЦ никаких проблем даже с 580ИК55 быть не должно. Попробуйте на всякий случай поставить более современный ВВ55.

Если же занесение адреса в ROM-диск делать двумя по-байтовыми командами ассемблера, т.е LD A,L : LD (PB),A : LD A,H : LD (PC),A то интервал между двумя записями в ВВ55 получается очень большим и работает даже при такте в 12 МГЦ.

Ещё сообщите подробности о схеме ROM-диска. Схема из ж.Радио 03.1987 или от ОРИОНА? Может какие-то выходы порта C используются как чип-селект ПЗУ или ИД7?

Также есть небольшой "снежок" на дисплее по неясным причинам.

А вот это уже может иметь причиной конфликт на шине.