Как же можно сделать столь большое ПЗУ?Сообщение от Vladimir_S
Я признаю только совместимые доработки. А на C000 у нас адресуется ВГ75, потому в РК86 сплошной кусок ПЗУ более 15 кб совместимо никак не сделать. И к тому же, раз речь о монтаже проводочками вторым этажом, то переделки должны быть предельно простыми.
Конечно можно занять под ПЗУ и второе окно 8400...BFFF, но это не даст никаких преимуществ. И если уж требуется поставить много ПЗУ, то окно ПЗУ лучше наоборот сократить, с целью сделать его кратным и более пригодным для страничной коммутации. Окно ПЗУ в 8 кб (E000...FFFF) в общем-то даже выгоднее и с точки зрения расширения ОЗУ.
Для расширения ПЗУ в этом случае идеально подойдёт 27256/27512 с кучей страниц в окне по 8 кб. 8 кб достаточно большой кусок, чтобы разместить здесь какую-нибудь программу, а при использовании ПЗУ лишь в качестве хранилища резидентных программ (которые для прогона всегда копируются в ОЗУ) размер окна, через которое мы имеем доступ к ПЗУ не играет роли.
А ПЗУ ограниченного размера, зато, даёт возможность удобно расширить ОЗУ до 56 кб, хотя и с использованием двухрежимной коммутации. Здесь же идёт речь лишь о случае когда в РК требуется иметь максимально большое сплошное ПЗУ, а не о какой-то иной несовместимой архитектуре.
Xrust прав в том, что участок 8000...BFFF гораздо разумнее, так же как и в МИКРОШЕ, истратить на дополнительнок ОЗУ, а не ПЗУ. Окно 8400 (где в отличие от области E000, допустимо ОЗУ) пригодится при доработке РК86 до полной графики (на базе идей от freddy), а также для CP/M и т.п.
Нескольно слов о том, что удобно прошивать в сплошное ПЗУ 15 кб. Понятно, что 2 кб из этого размера "открызает" базовый ROM-BIOS РК86. Вообще в ПЗУ в первую очередь хранят ROM-BIOS. Например, в ещё 1 кб можно разместить небольшой набор подпрограмм для поддержки оконного интерфейса РК86 имеющего альтернативный фонт (переключаемый PC0). Такой фонт даёт инверсию знакомест и нормальные рамки, что и позволяет открывать на экране инверсные окна. К сожалению неперекрывающиеся, как делают с цветными окнами (т.е с глубиной вложенности 1).
Хотя конечно, никто не мешает добавить цвет и иметь многооконность. Я об этом не пишу, т.к не имел цвета и опыта его использования нет. Потому что бросить один проводок к ПЗУ фонта намного проще, чем сделать схему Толкалина из ж.Радиолюбитель 04.1992 или схему цвета из АПОГЕЯ. Да и программирование без цвета на порядок проще.
Так вот, в 1 кб можно уместить простейшие оконные подпрограммы OPEN и CLOSE. По OPEN в подпрограмму передаются координата верхнего левого угла окна X,Y и размер окна dX,dY. Тогда эта процедура сливает старое содержимое окна в оконный буфер (вот для чего в графических системах надо дохрена ОЗУ). Затем рисует на экране белое окно с рамкой по краю окна и заголовком. К сожалению ROM-BIOS РК86 не оконный (что как раз наличие второй страницы ПЗУ в 8 кб позволяет исправить). А для оконного драйвера вывода при открытии окна и размер экрана вывода устанавливается в это "открытое" окно. Т.е, если ранее координата 0,0 была в левом верхнем углу экрана, то теперь координата 0,0 это правый верхний угол окна. Это к слову (о том как работает нормальный графический BIOS). В РК86 такого нет, да и при однооконности не особо и надо, тут отслеживание, чтобы вывод попадал в открытое окно а не мимо, возлагается на программиста.
Закончив работу с окном, вызывается п/п-мма CLOSE, которая как бы закрывает окно, просто восстанавливая старое содержимое окна из буфера. Можно открыть 2 и более окна, но чтобы они не перекрывались. Понятно, что поддержка неперекрывающихся окон в инверсии проста и имеет малый объём, отчего легко может встраиваться в сами программы. Но наличие стандартных процедур в ПЗУ даёт единообразие и экономит объём кода. Вот иллюстрации
Далее, в ПЗУ обычно хранят драйверы внешних устройств. Так, встроив в ПЗУ подпрограммы чтения, записи сектора и процедуру формат трека мы избавляемся от зависимости от конкретного железа. Тогда DOS (а к железу в нормальных системах лезет только DOS, прикладные программы никогда не лезут к железу на низком уровне) поддерживает все имеющиеся у разных пользователей носители, например, винчестер, дисковод, RAM-диск и различные флэш-накопители с микроконтроллерами. И соответственно все программы для этой DOS без всякого изменения кода будут работать на всех носителях независимо от их физической природы.
В ПЗУ полезно иметь мелкие сервисные программы и драйвера. В частности, программу обслуживания прошивателя УФ-ПЗУ, программу обслуживания ROM-диска (ROM-Service), драйвер принтера, драйвер и программу обмена по проводной линии с IBM PC и т.п.
А в самом простейшем случае, для РК86 без внешних носителей в такое ПЗУ 15 кб можно прошить бейсик и ассемблер, работающие уже непосредственно из старших адресов, а не с 0. Это увеличивает объём исходного текста могущего быть странслированным и максимальный размер бейсик программы (а размер бейсик программы написанной для бейсик-интерпретара с вкраплением ассемблера может быть большим, т.к операторы DATA сжирают много места).
Учтите, что бейсик нельзя просто перетранслировать, указав иной адрес трансляции. Т.к в этом бейсике "уши растут" от бейсика Билла Гейтса из 1975, который активно использует RST-команды, отчего может работать только с 0. Поэтому для перемещения кода на другой адрес Вам придётся все вызовы RST переделать на CALL, отчего объём кода немного разбухнет на 50 байт (но всё равно, думаю, влезет в 8 кб, а если нет, то можно забить какие-то малонужные операторы).
Какой-нибудь РК-Бейсик я собираюсь позднее попробовать перетранслировать на работу без RST, а также странслирую свой текстов редактор для РК86 и макроассемблер для прошивки в ПЗУ C400.
Ответить с цитированием