Радио-86РК на 8088 (или 8086)

[Alekcandr]

РАДИО-86РК. А вообще подумалось. Видимо в журнале Радио нам опубликовали обрезок терминала а?

Ребенка не обманешь (а было мне 10 лет) Ну да ладно. Великое надувательство, везде. Чет грустно.

[barsik]

Был бы я фанатом РАДИО-86РК, сделал бы модульный комп

Модульность без сомнения удобна, не зря же авторы компьютера ИРИША (1984) сделали отдельными модулями плату процессора и плату видео адаптера. Именно для того, чтобы в крейтовую конструкцию было удобно не только вставлять периферийные платы, но и было легко заменить процессорную плату на другую с процессором 8088.

Модульность это о другом. Это о конструктиве, если выпускать печатные платы нового компьютера. Думаю до этого дело не дойдёт. Не набрать нужного числа подписчиков на выпуск плат. Только, если кто-то загорится такой идеей и вложится в неё деньгами, которые вернутся только после их продажи и далеко не сразу. Чтобы продать хотя бы пару десятков таких плат на барахолке уйдёт год или даже два.

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

У меня в качестве инструментальной машины используется ОРИОН. На котором я прошиваю УФ-ПЗУ и на который по линии передаю файлы из IBM PC. ОРИОН если надо передать файлы соединяется проводной линией с ИРИШЕЙ, Специалистом и РК86.

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

Почти всегда из графики нужна только возможность рисовать рамки, потому для системных программ доработанный РК будет удобнее, чем ОРИОН. Для разработки игр РК тоже удобнее, т.к для настоящей, а тем более цветной, графики скоростей кода из под ЯВУ недостаточно. Неспроста в Денди применён текстов адаптер выводящий графические тайлы, а не полноценно графический.

Про модульность +1, только 86РК довольно монолитен имхо.

Есть такое. Без ВГ75 и ПДП модуль ЦП с динамическим ОЗУ не работает из-за утраты регенерации. Хотя, конечно, никто модульный РК на 8088 делать не будет. Но если забыть, что на 6845 с десятком корпусов обвязки получится лучший (т.к с КОИ-8 и без тормозов) текстовый адаптер, то порассуждать на эту тему можно.

Если применить статическое ОЗУ, то проблема регенерации снимается. Если разбить схему на модуль ЦП - CPU + ПЗУ + ППА + 32К ОЗУ на 62256 и модуль текстового адаптера - ВГ75 + ВТ57 + 32К ОЗУ на 62256, то модуль видео можно выпускать как отдельный текстов адаптер. Для Синклера, других 8-ми разрядок и в качестве терминала при отладке контроллеров.

Кстати, можно оставить РУ5 на плате ЦП и всё равно иметь регенерацию. В PC XT не было узла регенерации ОЗУ. Там 4164 регенерировались по прерываниям с помощью ПДП. На это не уходит много ресурса процессора. При 4-х тактах на байт ПДП для регенерации читает 128 ячеек за 512 периодов частоты 5 МГЦ, что отнимает ~100 микросекунд из периода в 2 МСЕК, т.е теряется 5% процессорного времени.

Если жалко ставить ПДП, то даже самим процессором можно сделать регенерацию. Регенерация при частоте 5 МГЦ с помощью 64-х команд POP займёт 200 микросекунд. Таким образом потеря скорости составит всего 10%, что меньше, чем 26%, что в РК86 отъедает у процессора его видеоадаптер.

Если на плате видео адаптера будет только экранная память ~ 4 кб, а вся остальная память будет на плате ЦП, то эта память даже на динамическом ОЗУ может быть регенерирована и работать без участия платы видео адаптера. Тогда можно в такой компьютер ставить и другой тип видеоадаптера, например, настоящий текстов адаптер на 30-ти TTL-микросхемах, который хотя и содержит больше деталей, но зато в отличие от ВГ75 даёт КОИ-8, причём с инверсией (9-ти битовое ОЗУ: две 2114/6514 + одна 565 РУ2). Правда в таком текстовом адаптере нельзя программно менять число строк, как в ВГ75.

Кстати, если в РК-видео-адаптере применяется статическое ОЗУ, то не нужны строки программно формирующие вертикальный бордюр (что введены ради регенерации), отчего можно сократить размер экрана на 312 байт и выиграть 5% скорости без потери совместимости с имеющимся ПО.

8086 работает быстрее, чем 8088

Прямо сегодня прочитал мнение специалиста (пост 142), что благодаря конвейру 8088 всего ~5% уступает 8086-му по скорости. Эта информация нуждается в проверке, но если это так, то 8086 неинтересен в применении к РК86.

В журнале РАДИО нам опубликовали обрезок терминала

Вряд-ли. Иначе и Роботрон-1715 - тоже обрезок терминала, а в его документации чётко указано, что это персональный компьютер. Интересно были ли отечественные промышленные (не бытовые) компьютеры с ВГ75? Ведь не ради РК86 и клонов скопировали CRT контроллер 8275, а значит был заказ МЭП-у и для чего-то они предназначались.

[PVV]

Что то мы уходим от темы в сторону. Модульный ПК на i8088(8086) уже есть, он создан четыре десятка лет назад и называется IBM PC, разве нет?
Включить тот или иной ЦП по схеме из его DS, добавив интерфейс для ввода и вывода информации не так сложно, но без ПО это останется мертвым 'железом'. Та-же, часто упоминаемая здесь 'Ириша', сколько для нее существует ПО? или ее модульность, помогла ли ей получить развитие? ПО определяет возможности ПК. Идея РК-8086 живет на ожидании конвертированных программ с РК-86, но без этих программ этот ПК не жизнеспособен. Автоматическая конвертация программ, вероятнее всего, невозможна, что означает только ручную переработку кода .

Из всего этого сказанного вытекает - нужно по пунктам составить некий план работ, конфигурация 'железа', список программ требующих конвертации, список требований к монитору и его командам, и далее планомерно решать поставленные задачи. НО, навязывать какому исполнителю делать тот или иной пункт это будет перебор, тут уже только каждый сам себе выдает задачу и лишь информирует, что взял задачу в работу или отказался от нее без объяснения причин, и не гарантирует ее выполнение ни в какие сроки, иначе хобби превратится в работу .

Если будет произведена переработка программ из кодов 8080 в коды 8086, то это будет означать наличие исходника, а при наличии исходника адаптировать программу под измененную архитектуру проблем не составит, особенно если при конвертации держать в голове такую возможную работу...

Что касается самостоятельного графического адаптера на ВГ75 и ВТ57, то это ж и будет тот недоMDA, о котором я написал чуть выше.

Для того, что бы обсуждать какую ДОС применить нужно решить какой накопитель будет использоваться, вне зависимости от объема имеющегося ПО.

это не план, но прообраз:
1 Вводная часть:
1.1 ОЗУ, ПЗУ, порты ВВ, видео экран - как у РК-86, можно только порты сгруппировать плотнее( это породит несовместимость с п.1.2.1, но возможно в п.1.2.2).
1.2.1 Вариант с установкой платы адаптера с 8088.
1.2.2 Самостоятельный вариант с 8086.
2 Аппаратная часть:
2.1 Лично мне нравится использование SD в качестве накопителя, и сейчас во всех своих конструкциях я использую имеющиеся наработки, тем более, что это поддержано в эмуляторе, что радикально упрощает процесс отладки.
3. Программная часть:
3.1 Из ПО нужен любой ЯВУ, и basic это первый кандидат.
3.2 Надо подумать, что дает CPM-86, и какие у нее требования к аппаратной части.
3.3.1 Игры - нужны для привлечения 'молодых' и для ностальгии у 'бывалых', и они должны быть из лучших для РК-86.
3.4 Монитору нужен функционал:
3.4.1 Чтение внешнего РОМ диска.
3.4.2 Загрузка из внешнего РОМ диска(как в Орионе ОрДос)
3.4.3 Исключить работу с магнитофоном как устаревшую и заменить на другой тип накопителя

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

[barsik]

нужно по пунктам составить некий план работ

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

Вы подходите с взглядами из 80-тых на создание новой платформы. Сейчас всё не так. Есть единицы энтузиастов и какой смысл, ради того чтобы убедить ещё одного или двух людей поставить 8088, разрабатывать системное и прикладное ПО полного цикла. Такую задачу в своё время не могли годами решить при тысячах пользователей и даже финансовой заинтересованности программистов.

Ориентироваться надо на минимум. На разработку документации на платку переходник, позволяющую заменить процессор. Кому надо тот повторит. И независимо есть или нет игры от РК86.

Считается, что для старта платформы необходима только DOS, нортон для неё, текстов редактор, бейсик и ассемблер. Ассемблер не нужен (есть на PC), а DOS, нортон и редактор можно сделать за один день (есть исходники и они корректные). А вот с бейсиком и играми, по крайней мере с половиной игр, - будут проблемы. И проблема не в конверсии, конвертор работает.

Программы от РК я рассматриваю как средство для тестирования железа. Задачу конвертировать все игры РК под 8088 я не ставлю. Зачем это делать, если 8088 поставят полтора человека. А если всё-же хотя бы пять или более владельцев РК поставят 8088, то в итоге пусть и не сразу, но будет конвертировано почти всё полезное ПО от РК.

Автоматическая конвертация программ, вероятнее всего, невозможна

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

Идея РК-8086 живет на ожидании конвертированных программ с РК86

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

без этих программ этот ПК не жизнеспособен

Так не думаю.

Что-то конвертировать просто, а что-то очень сложно. Проблема в наличии исходников. Получить листинг, который правильно транслируется без его изменения легко. А получить полноценный исходник, т.е такой в котором можно делать изменения и код сдвигать, - на порядок сложнее. Трудно отделить адреса от данных. Надо разбираться в алгоритме.

В маленькой игре с простейшей логикой и написанной без программистских извратов разобраться легко. Если программа написана без извратов, размер программы для конверсии не играет роли. Но если они есть, то чем больше размер, тем больше работы.

Если бы были исходники игр (пусть и некорректные), то можно быстро конвертировать их все. А с необходимостью ручного дизассемблирования, в лучшем случае удастся конвертировать только по одной игре в день. Лишь конверсия маленьких по размеру и корректных (пусть и больших) программ легка. Главное получить полноценный исходник, дальше намного проще.

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

Так что легко конвертировать только свои программы или чужие программы, которые сам дизассемблировал и изучил. Без извратов и корректно написаны только программы новичков, т.е очень простые программы. А чем более опытный программист, тем больше у него само модифицируемого кода. А некорректный уже сконвертированный код нельзя даже переделать вручную, т.к нет адресной арифметики и длины команд разные.

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

Я уже завис на нескольких играх, т.к конвертировал их в лоб. А из-за отсутствия адресной арифметики надо смотреть числа в исходнике при каждой перетрансляции. Даже простая подстановка адреса в код команды не работает, т.к у 8088 адреса переходов не абсолютные, а относительные, потому все приёмы модификации адресов недопустимы. Тем более подстановки кодов команд КР580.

Так что обращения к нестандартным точкам и команды OUT, что я раньше считал проблемой, это просто "цветочки", устраняются без хлопот. А вот "ягодки" - это программы с таблицами адресов, смешанными с данными и само модифицирующимся кодом, что заставляет тратить много часов не только на дизассемблирование, но и на анализ алгоритмов и переделку программ.

По счастью извращениями занимались только любители. В фирменных программах ни в одной не видел извращений. Так что CP/M смогу конвертировать за час.

Для того, чтобы обсуждать какую ДОС применить нужно решить какой накопитель будет использоваться

Не так. Настоящей DOS всё-равно какой накопитель используется. Т.к DOS производит обмен секторами (логическими по 128 байт или физическими, обычно 512 байт). Потому для переноса DOS на другое железо, если консольные функции одинаковы, достаточно заменить подпрограммы чтения и записи сектора. Естественно, могут быть неграмотные DOS в которых обмен секторами переменной длины. Вот их адаптировать под другой накопитель сложно. А для нормальной DOS каждый может "прикрутить" любой накопитель.

нужен любой ЯВУ, и basic это первый кандидат

Можно конвертировать TINY-бейсик (1800 байт) и бейсик 1A20 (т.к их исходники у меня есть и для TINY-бейсика есть программы). Это полезно, чтобы использовать игры на бейсике (вообще-то это никому не надо, но создаёт впечатление). Увы, TINY бейсик ради экономии объёма само модифицирующийся. В бейсике РК тоже есть трюки от Билла Гейтса (в частности JMP внутрь команды).

Бейсик от MSDOS адаптировать было бы полезнее, но это сложно, хотя там тот же процессор. Для интереса дизассемблирую BASICA и будет видно.

С ЯВУ хуже. Конвертировать компиляторы CP/M нет смысла, у них выходной код КР580. Компилятор ЯВУ не должен работать на РК на 8088, он нужен для PC. Можно подумать о Pascal-MT+ для MSDOS. Он как раз ранний из начала 80-тых. Надо читать документацию. MT+ для CP/M мог генерировать код под заданный адрес и даже для ПЗУ. Если это возможно, то можно из EXE-файла программой EXE2BIN получить код для запуска. Но это задача отдалённого будущего.

Поддержка ROM-диска не проблема, думал не горит, раз эмулятор грузит по ^L. А магнитофон нужен, т.к только его поддерживает эмулятор EMU. Утомляет помнить и вводить адрес файла при загрузке по ^L.

Если сохранение адресов В/У позволит ставить платку переходник на 8088 без разрезов на основной плате, давайте сохраним оригинальную адресацию. Это не проблема. Причём можно в программах сделать автонастройку, по крайней мере на адрес ППА клавиатуры, т.е при старте проверять, что ППА стоит на 8000 или в ином месте и соответственно корректировать работу программы.

Я хотел конвертировать немного простых игр и тех системных программ, чьи оригинальные исходники есть, чтобы было на чём тестировать. Затем собирался сделать CP/M работающую на RAM-диск из ОЗУ. Есть исходники нортонов, в них надо лишь изменить интерфейс под РК86 (это несложно, и интерфейс для РК есть). Текстов редактор я конвертировал, но пока с глюками (т.к неудобный отладчик).

Собираюсь пока сделать только DOS, нортон, текстов редактор и какой-то бейсик. Попутно буду дизассемблировать игры от РК и искать среди них корректные, которые конвертируются без труда.

[PVV]

Что касается BASIC_ов, то вот здесь есть тема с исходниками разных версий для ВМ80.
Транслировать CPM-80 в коды х86 нет смысла, ведь для х86 уже была написана CPM-86.
Еще пришла шальная мысль по конвертации программ, а может ну ее, эту конвертацию, написать эмулятор процессора ВМ80 и запускать на нашей РК-8086 через него наши РКшные программы, при наличии экрана и портов как у РК-86 это будет не сложно писать на С https://www.digitalmars.com/ - это компилятор из протеуса для х86.

[Lavr]

писать на С https://www.digitalmars.com/ - это компилятор из протеуса для х86.

Этот компилятор сейчас непосредственно включен в пакет Протеус?

[PVV]

Этот компилятор сейчас непосредственно включен в пакет Протеус?

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

[Mixa64]

Еще пришла шальная мысль по конвертации программ, а может ну ее, эту конвертацию, написать эмулятор процессора ВМ80

Если 8088 принять в расширенном виде, включая NEC V20 ( а "или 8086" включая "или NEC V30" ), то у японцев есть режим непосредственного исполнения кодов 8080. Я этот режим не пробовал, поэтому подробностей не знаю.

[barsik]

нужен любой ЯВУ

Есть возможность писать на ЯВУ, например на Си, Паскале и бейсик-компиляторе используя CP/M-компиляторы. Потому что ЯВУ создают корректный код, без извратов. Потому конвертировать выходной код компилятора для КР580 не вызовет больших хлопот, т.к ЯВУ создают код без хитростей, который легко дизассемблируется и без проблем конвертируется.

При этом плюсом то, что компиляторы ЯВУ для CP/M создают вполне компактный код (в отличие от компиляторов для MSDOS). Кроме того, некоторые компиляторы создают промежуточный ASM-текст исходника, который затем транслируется компилятором ассемблера. Такой исходник можно сразу конвертировать. Но отлаживать программу придётся на РК с процессором КР580, т.к конверсия без наличия качественного конвертора отнимает слишком много времени и потому это стОит сделать только один раз для окончательной версии.

Транслировать CPM-80 в коды х86 нет смысла, ведь для х86 уже была написана CPM-86

Не хочу пока заниматься CP/M-86, но интересно узнать какой у неё программный интерфейс. CP/M-86 пока не нужна, т.к она написана для PC и потому интерфейс в ней с помощью INT в ROM-BIOS. Если узнать её интерфейс, то, т.к функции, по крайней мере BDOS, совпадают, то думаю, получится частичная совместимость и некоторые COM-программы из CP/M-86 смогут работать.

В РК ROM-BIOS как раз приближен к BIOS CP/M-80, а не к ROM-BIOS IBM PC. Потому при установке CP/M-80 консольные функции CP/M-BIOS писать не надо, в качестве них служат входы в ПЗУ F800. В CP/M-86 может отличаться DOS BIOS, т.к скорее всего её получали из CP/M 3.0, а не 2.2.

Для CP/M-80 есть проверенные исходники (и они корректные), потому конверсия из имеющейся версии CP/M для ОРИОНА (эл.диск из ОЗУ) отнимет всего 1 час, а чтобы разобраться в чужом исходнике CP/M-86 и ROM-BIOS IBM PC уйдёт 1 месяц.

Версию CP/M для эл.диска из ОЗУ сделать просто потому, что в EMU есть возможность иметь столько ОЗУ, сколько хочется. А РК-КНГМД в EMU не поддерживается. Т.е дисковод и винчестер отладить можно только в реале. Кстати, ОС для РК-КНГМД работает только, если реальное быстродействие не превышает 2.5 МГЦ.

Для игр желательно иметь режим НЕ-ТУРБО, т.к Турбо может быть у каждого своё. Сейчас я константами тормозилок подгоняю скорость игр, чтобы было не быстрее, чем на оригинале. Без подгонки констант при указании в конфиге такта 4.77 МГЦ визуально игра получается в 2...2.5 раза быстрее. Например, в KROK константу тормозилки увеличил в 3 раза.

Увы, без скоростного ОЗУ, скорее всего, без добавки буферов на ОЗУ, не получится разогнать 8088 выше такта 2.5 МГЦ, а если подключать периферию, то и ниже. Т.к шина слабая. Самое слабое звено - ОЗУ (т.к ОЗУ в РК без буферов). У ОЗУ малая нагрузочная способность, хотя по скорости они тянут 5 МГЦ RAS-CAS.

Еще пришла мысль по конвертации программ, а может ну её, эту конвертацию, написать эмулятор процессора ВМ80 и запускать на нашей РК-8086 через него наши РК-шные программы, при наличии экрана и портов как у РК-86 это будет не сложно

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

Если эмулятор иметь резидентно (в ROM-диске или ПЗУ), то при запуске с дискеты программ с расширением 580, будет стартовать эмулятор. Так можно использовать программы CP/M-80. Для системных программ скорость не особо важна. Тогда эмулятор размещается в сегменте с полным 64К ОЗУ в старших адресах. Ниже размещается CP/M-80 и её TPA.

Тут нужно пояснение на что можно рассчитывать. У меня есть эмулятор РК написанный на ассемблере 86-го, потому он самый быстрый, что может быть. Увы, для эмуляции реальной скорости РК86 нужен такт эмулирующего 8088, как минимум, 20 МГЦ. Первые эмуляторы ZX-Spectrum работали на AT с тактом CPU в 8 МГЦ, что из-за более лучшего конвейра в 286-том, примерно соответствует такту 20 МГЦ 8088-го (в ZX скорость большинства игр не зависит от скорости Z80, темп игры задают 50 Гц).

Я обнаружил, что если в эмуляторе подпрограммы F812 и F81B не прогонять кодом КР580, а выполнять эквивалентный код эмулирующим процессором, то эти подпрограммы прогоняются в 15-20 раз быстрее. А т.к все игры построены на задержках, в которых в цикле вызывается F81B (т.е п/п-мма F81B является частью задержки), то оказывается, что некоторые игры опрашивающие клавиатуру стандартно (например, ксоникс и пакмэн), нормально играются уже при скорости эмулируемого КР580 всего в 150 КГЦ, даже без подгона констант тормозилки. А остальным играм достаточно скорости 500 КГЦ.

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

[PVV]

Версию CP/M для эл.диска из ОЗУ сделать просто потому, что в EMU есть возможность иметь столько ОЗУ, сколько хочется. А РК-КНГМД в EMU не поддерживается. Т.е дисковод и винчестер отладить можно только в реале. Кстати, ОС для РК-КНГМД работает только, если реальное быстродействие не превышает 2.5 МГЦ.

Замечу, что в emu винчестер поддерживается! по схеме Ориона, через ВВ55.
Решил попробовать сконвертировать какую нибудь программку, выбрал самую маленькую, piton, и скажу, что далеко не так легко это конвертируется все . Во вложении исходники для 8080, 8086 и бинарник для 8086. Времянки не правил, так что бежает шустро .

[Lavr]

Этот компилятор сейчас непосредственно включен в пакет Протеус?

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

А нет там у вас возможности выложить прямую ссылку, чтобы скачать прямо этот компилятор?
Я давно хотел скачать себе этот Digital Mars C/C++ compiler, но всё как-то не выходило...

[PVV]

В мониторе РК-8086 что то не так с переменной RAMTOP, при вызове функции проверки верхней границы возвращается 0000, надо бы ее или правильно возвращать или вбить константой 75FF. Просто сейчас TETRIS конвертирую, а он делает эту проверку и не стартует... пока выбросил проверку, но с этим надо что то решить.

[barsik]

В мониторе РК-8086 что то не так с переменной RAMTOP, при вызове функции проверки верхней границы возвращается 0000... с этим надо что то решить.

Разобрался с этим. Ранее для экономии, я переставил инициализацию RAMTOP до процедуры очистки всех служ.ячеек (отчего и ячейка RAMTOP обнулялась до начала использования). Сейчас исправил (выложено там же) и даже благодаря системе команд 8088 выиграл один байт.

При переделке программ надо учитывать то, что стек ставится на 7600, а не 75FF. Правильнее не терять впустую 1 ячейку из-за непонимания авторов РК работы стека. Некоторые универсальные игры при старте загружают SP в HL и проверив, что в HL не 75H или не 35H, делают вывод что система на 16К или 32К. При переделках таких игр я убираю эту проверку на объём ОЗУ и все процедуры коррекции кода под 16К (для 8088 модификация кода недопустима).

Это ПЗУ временное, т.к собираюсь ПЗУ РК на 8088 переделать сделав стандартные входы ПЗУ дальними (по CALL FAR). Это лучше, чем иметь два коммутируемых ПЗУ, одно с дальними входами в подпрограммы, другое с ближними. А окончательное ПЗУ будет 8 или 16 кб. В последнем случае будут 2 или 4 страницы ПЗУ в окне 8 кб и в ПЗУ будет содержаться DOS, стартующая по сбросу.

Конфиг сейчас у меня изменён так, что ПЗУ и порты есть как в сегменте 0 (CS=0000), так и в сегменте 15 (CS=F000). Но правильнее, чтобы порты и ПЗУ были только в сегменте 15. А во всех остальных сегментах - сплошное ОЗУ по 64 кб, что позволит CS ставить произвольно, а не только на границы по 64К. Тем самым размер программ может достигать почти мегабайта (за вычетом ПЗУ и портов в сегменте 15).

Особых неудобств CALL FAR ПЗУ не вызывает, т.к косвенный вызов подпрограммы ПЗУ через регистр BP длиннее, чем CALL NEAR и в любом случае в каждой программе выгоднее сделать свои входы в ПЗУ доступные по CALL NEAR, которые уже вызывают ПЗУ (это экономит 2 или 4 байта на каждом вызове). И тогда без разницы вызывается ПЗУ дальним или близким вызовом. Хлопот для интерфейса с ПЗУ не больше, зато дальние входы в ПЗУ дают мегабайт сплошного ОЗУ и позволяют вызывать п/п-ммы ПЗУ из других сегментов напрямую. Если же оставить входы в ПЗУ близкими, то программе работающей в других сегментах будет сложно вызвать ПЗУ (придётся в сегменте 15 размещать вспомогательную программку, которая принимает FAR вызов и переадресует его в ПЗУ как NEAR).

Конвертированные для РК-игры тогда работают в сегменте 15, где есть порты и ПЗУ, а из других сегментов для доступа к портам и служ.ячейкам ПЗУ достаточно использовать адресацию по регистру ES, загрузив в него F000.

[PVV]

Думаю, что ПЗУ РК имеет смысл переделать сделав стандартные входы ПЗУ дальними (по CALL FAR). Или же надо иметь два коммутируемых ПЗУ, одно с дальними входами в подпрограммы, другое с ближними.

Переделать надо и оставить только одно место размещения монитора 'дальнее'. Я тут заглянул в НЕХ коды 8086 на предмет call, jmp, ret и увидел, что там на каждый вызов 3-5 типов кодов и пришла мысль - если переделать макросы вызовов как DB xx, xx, xx, xx, xx тогда получится:

Code: Select all

DB 09Ah, 03h, 0F8h, 00h, 0F0h - call FAR F000:F803 но нужно возврат из функции в мониторе делать RETF (0CBh), иначе CS остается F000 и стек на два байта недовыгрузится...

надо еще проследить в самом мониторе вызовы этих же функций монитора, и близкие call заменить на такие же макросы из DB, иначе стек посыпется...

[barsik]

В мониторе РК-8086 что-то не так с переменной RAMTOP, - при вызове функции проверки верхней границы возвращается 0000... с этим надо что то решить.

Исправил исходник и свой предыдущий пост, добавив туда ссылку. Кстати, обратите внимание, что теперь монитор при старте инициализирует сегментные регистры на F000, так что и конфиг изменён (не только ПЗУ, но и порты теперь адресуются в сегменте 15).

Переделать надо и оставить только одно место размещения монитора 'дальнее'... если переделать макросы вызовов как DB xx, xx, xx, xx, xx тогда получится:

Code: Select all

DB 09Ah, 03h, 0F8h, 00h, 0F0h - call FAR F000:F803

но нужно возврат из функции в мониторе делать RETF (0CBh), иначе при вызовах ПЗУ будет происходить утечка стека и через секунды код программы будет затёрт и произойдёт улёт.

Да, так получится меньше байтов, чем при:

Code: Select all

        MOV BP,0F000H
        PUSH BP
        MOV BP,F8xx
        CALL BP

или (что лучше):

Code: Select all

        MOV BP,F8xx
        CALL ES:[BP]

где в ES заранее загружен F000. Приходится использовать DB потому что мы не знаем как в ассемблере сделать CALL на внешнюю метку. Думаю, что должен быть способ объявить метку EXTRN absolute, к сожалению, нЕкому подсказать, т.к профессиональные программисты сайты по рэтро-ЭВМ не читают. Из-за этого и приходится программировать в маш.кодах, как в начальные годы микропроцессоров.

надо еще проследить в самом мониторе вызовы этих же функций монитора, и близкие call заменить на такие же макросы для RET, иначе стек посыпется...

В этом нет необходимости. Внутри ПЗУ все подпрограммы могут оставаться близкими, только сами входы должны быть FAR. Для этого для каждого из 17 стандартных входов придётся добавить промежуточный CALL NEAR и входы будут иметь такой вид:

Code: Select all

XF809: CALL near YF809
       RETF

Это потеря 4 байтов на каждый из 17 входов (4*17=68). А если все подпрограммы внутри ПЗУ сделать дальними то увеличение объёма кода будет на килобайт.

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