nedoPC.org

Загрузку можно и с SD сделать, если портировать SDOS , еще 2КБ кода перетранслировать, зато будет FAT16 с разделом до 4ГБ.
Разницу между 8086 и 8088 я знаю и сложности с обращением к старшему байту слова понимаю...ясно, что 8088 именно сюда и вписывается.
Забыл о РОМдиске в РК-86, обращение к нему в мониторе же есть! вот и способ простой загрузки программ на этом этапе...

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

Обнаружил одно интересное свойство программы EXE2ROM.EXE. Эта программа не зря ограничивает размер кода ПЗУ на единицу меньше, чем реальный размер ПЗУ. Оказывается EXE2ROM подставляет инвертированную сумму всех байтов ПЗУ (кроме последнего) в ячейку FFFF, так что арифметическое сложение всех байтов ПЗУ даёт 0. Потому не занятые кодом участки ПЗУ заполняются нулями (тогда они на сумму байтов не влияют).

Обнаружилось это при проверке работы новой директивы К. Заметил, что контрольная сумма любых вариантов ПЗУ подсчитанная командой: K F800, FFFF всегда имеет младшим байтом 0.

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

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

Потому что чуть изменив конфиг EMU, можно в окне 8400...BFFF получить 15 кб ПЗУ, что оказываются удобно доступны. Т.е можно транслировать любые программы в файл ROM2.DAT, который будет автоматически грузиться на 8400 при старте эмулятора.

ROM-диск имеет смысл как стартовая система загрузки ОС (какая-бы ОС ни была, хоть для 'microSD', электронного диска из доп.ОЗУ, флоповода или винчестера). Для автостарта из ROM-диска надо всего ~50 байт места. Тогда по сбросу будет проверяться подключен ли ROM-диск и, если да, то из него будет грузиться и запускаться первый файл в формате ORDOS (так у меня в реале сделано в ПЗУ для РК86).

Но где взять эти 50 ячеек ? Имею ввиду для реала, где ПЗУ всего 2 кб. Для эмулятора это не проблема, т.к конфиг сделан для 8 кб ПЗУ. Завтра увеличу ПЗУ до 4 кб (F000...FFFF) и сделаю автозагрузку и автостарт файла из ROM-диска.

Кстати, в дополнительные 2 кб влезет не только автостартёр, но и нортоно-подобная оболочка выводящая список файлов ROM-диска. Увы, очень печально, что эмулятор EMU от b2m не поддерживает коммутацию фонтов. Без рамочек и инверсии знакомест - паршиво, возможен только убогий интерфейс как в нортоне SE.COM Е.Седова для RK-DOS.

Кстати в ПЗУ 8 кб, сейчас свободно 6 кб из 8-ми. Для начала уже сейчас можно тестируемые программы вставлять в файл прошивки ПЗУ, откуда они могут стартовать (сами перекидываясь в ОЗУ на место их запуска).

Но надо чтобы кто-нибудь разработал конфиг для EMU, чтобы в нём был ROM-диск. В принципе, как это делается, вероятно, можно посмотреть в конфиге для ОРИОНА.

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

А дальше полностью обломился. Как получить коды программы работающей без MSDOS в ОЗУ ? Т.е как из EXE-файла получить чистый файл программы настроенный на рабочий адрес, без загрузчика MSDOS ?

Я надеялся использовать ту же программку EXE2ROM вот с таким трюком. Задать размер ПЗУ в 64 кб (судя по тексту подсказки это предусмотрено) и вставить в конце программы резервированное место, например, 48 кб. Тогда эти 48 кб расположатся на 4000...FFFF, а полезный код программы настроенный на адреса размещения кода окажется ниже, - примерно где-то на 3C00 (если программка в 1 кб). Затем из конца полученного блока кодов можно удалить ненужные 48 кб и получится код игры пригодный для запуска с адреса 3C00.

Но обломился. Судя по подсказке в EXE2ROM можно задавать размер выходного ROM-файла 8, 16, 32 или 64 кб. Если задать ключ /64, т.е чтобы формировался файл в 64 кб, то пишет, что всё "complete", но размер выходного файла - ноль. Т.е не работает.

Если задать ключ /32, чтобы ROM имел размер в 32 кб то выдаётся сообщение "Illegal function call in module EXE2ROM at address 0DE9:0246". Возможно, это из-за Windows XP, а программа рассчитана на оригинал MSDOS. MSDOS 6.2 мне не загрузить (нет дисковода на PC). Могу попробовать загрузиться только в DOS-режиме Windows 98, загрузившись с системного CD.

Итого, я выяснил, что не имею нужного инструментария и не умею получать программы для 8086-го процессора работающие без DOS. В дистрибутиве MSDOS 3.30 есть программка EXE2BIN (в дистрибутиве MSDOS 6.22 её уже нет). Я в 90-тые использовал EXE2BIN, чтобы получать COM-файлы. Но COM-файл это не то что надо. Надо поискать документацию по EXE2BIN, т.к судя по названию она должна как раз давать чистый код.

В общем нужна помощь знатоков. Решение, естественно, есть и оно простое. Ведь как-то программисты транслировали программы для контроллеров на 80188.

Добавить в конфиг РОМдиск и переключаемый фонт проблем нет вообще, только вот в нашем мониторе нет директивы R, для чтения РОМдиска ... во вложении конфигурация с РОМдиском и переключаемым фонтом по ножке ППА- port_c[3].

Покопавшись у себя в архивах, нашел исходник этого EXE2ROM, возможно он поможет понять что и как там сделано.
Не совсем понял, в чем сложность со сборкой и преобразованием в bin 'Охоты на уток'? можно исходник?

Директива R простейшая и маленькая. Вот её исходник в кодах КР580.
А вот то же самое в кодах 8088:
А вот так для 8088 эффективнее:
Я специально убрал директиву R, когда освобождал 200 байт в ПЗУ, т.к она бесполезна. Процедура автозапуска из ROM-диска не намного больше, а гораздо полезнее. Кстати, я непрерывно меняю код исходника ПЗУ, сокращая объём кода и добавляя что-то (последний раз изменил исходник ПЗУ в архиве минуту назад).
Отлично. Думал, что фонт можно переключать только, как в Микроше выводом INTE процессора. Но ещё надо понять куда вставить альтернативный фонт.

ROM-диск позволит обойтись в эмуляторе без магнитофона. Но пока неизвестно как получать коды, толку от этого нет, ни одной программы для ОЗУ не сделать.
Добавил в тот же архив. Не отлаживалось, просто конвертирована.

Исходник EXE2ROM оказался на бейсике. Видимо компилировали Quick-Basic-ом или Power-Basic-ом (Power-Basic лучше, меньше код и скоростнее). Интересно компоновали версией для Windows или для MSDOS. Версию Power-basic для Windows можно найти. Тогда, возможно, не будет вылетать в Windows. Вообще и бейсик позволяет делать обрабоку ошибок.

Скачал с этой страницы EXE2BIN и с ним получился обычный бинарник, теперь, действительно вопрос, как этот бинарник закинуть в нашу машинку

сделал в конфиге вставки:



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

Поправил работу директивы G и слегка поразбирался с 'Охотой', теперь она даже показывает что-то , но нормально не работает...

В ОЗУ нормально работает. Загружать в отладчике Ctrl+L
Правда количество подстрелянных уток неправильно выводит. И после этого не подтирает за собой, флаг направления неправильно установлен что-ли...

Я о такой возможности и не знал хотя часто хочется или сдампить ОЗУ из заполнить чем то... Спасибо за подсказку!
А случайно нет такого ключа при запуске emu, что бы break ставить на нужный адрес?, типа emu -B 03fch ?

emu /brk 1234
emu /brk 1234,5678,ffff0
emu /brk @file_to_save_breakpoints

Адреса всегда 16-ичные, для x86 можно из 5 цифр, в последнем примере точки сохраняются в файле.

Круто! спросил вообще на удачу... Спасибо!

Прочитав новые посты узнал, что вы тут похоже разобрались как получать коды программ для машины без MSDOS. Т.о достаточно использовать EXE2BIN и сразу получается нужный код для загрузки в ОЗУ.

PVV в Вашем исходнике ПЗУ ошибка, потому что Вы использовали второй ORG, а объём кода увеличился на 1 байт. Потому те строки, что стоят после ORG 0FFF0H затёрли последний байт предыдущего кода. Потому, я ORG и не использую, а заполняю пустоту DB.

Также при каждой перетрансляции ПЗУ надо смотреть в листинге адреса LDBYTE, WRBYTE и MG_RET и подставлять эти адреса в секцию точек перехвата МГ-ввода (cas : tape-recorder) конфига эмулятора. Хотя пока это не особо надо, т.к МГ-ввод почему-то не работает.

Вообще очень неудобно, что в MASM и TASM арифметика не работает для адресов. Нельзя не только узнать сколько ячеек между двумя адресами, но и, например, при трансляции заголовка RKR или GAM файла я не могу вставить такую конструкцию:
или такую:
Это может делать любой, самый убогий ассемблер для Z80/КР580, а крутой макро ассемблер для 8086 не может. Это получается, что мне надо всё делать вручную, смотреть в листинге трансляции адрес конца программы и вручную подставлять старший и младший байт в строки DB при каждой перетрансляции.

Подскажите кто-нибудь как использовать арифметику с адресами. Или хотя бы как выводить сообщения при трансляции. В 8-ми разрядных ассемблерах есть псевдо оператор '.PRINTX', который позволяет при трансляции выдать себе предупреждение, например, что происходит выход за допустимый размер кода или перехлёст фрагментов кода. А как сделать то же самое в ассемблере 8086 ? Видимо, придётся читать документацию на TASM и MASM.

Чтобы убедиться, что предыдущий код не залезает на адрес FFF0 и не будет затёрт из-за второго ORG, ставьте ключ USEORG на 0 и в листинге смотрите какой адрес получается у метки YFFF0. Если он отличается от FFF0, то надо изменить константу FREE, это число байтов FF, что заполняет пустоту до FFF0. И только потом можно вернуть ORG FFF0, да и то нежелательно, т.к тогда пустоты в ПЗУ заполняются нулями, а не FF-ами, что вызывает при прошивке ненужный износ УФ-РПЗУ.

Для проверки работы директивы G удобно использовать команду: G F815 или G на любую другую стандартную подпрограмму ПЗУ, что что-то выводит на экран. Вот правильный и оптимизированый код директивы G:


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

Почитал документацию про TASM 3.0 и узнал почему в строке ROR AX,4 при ключе .8086 не возникает ошибки, в то время как в TASM 2.0 ошибка возникает. Такая команда аппаратно есть только в 80186 и выше, а в 8086 есть только одинарные сдвиги. Оказывается сообщение об ошибке не выводится не потому, что ассемблер ошибочный, а потому, что с ключом .8086 ассемблер автоматически заменяет отсутствующую команду многократного сдвига на соответствующее число одинарных сдвигов.


Это изменение конфига никуда не годится. Оно просто погубило начало памяти, точнее эта память стала недоступна процессору, отчего перестали работать директивы T и M.

Что касается игры "Охота на уток", то попытка её трансляции выявила ещё кучу вопросов. Не понял как из программ делать вызовы ПЗУ F800. Команды CALL и JMP 8088-го процессора в отличие от КР580 не могут делать переход дальше чем на 32767, т.к вторым и третьим параметром команды у них не абсолютный адрес, как у КР580, а смещение от текущего адреса в диапазоне +/- 32767. Потому, хотя ПЗУ F800 и программа в начале ОЗУ находятся в общем сегменте кода, но внутрисегментный переход невозможен и команда CALL CS:F809 не работает.

Понятно, что нужно использовать FAR-вызов подпрограммы ПЗУ. Но не понял как в ассемблере задать такой вызов. До того не приходилось видеть исходников где бы ПЗУ вызывалось по CALL, только по INT. Похоже надо создать и объявить сегмент содержащий ПЗУ и объявить в нём FAR метку. Тогда CALL будет транслироваться в дальний вызов. Но как это сделать ?

Из предыдущих постов узнал, что из отладчика эмулятора EMU командой ^L можно в ОЗУ по любому адресу загрузить любой файл, так что для отладки это удобнее, чем компоновать ROM-диск. Но удивлён как "Охота на уток" могла у кого-то хоть частично работать. В таком виде её можно странслировать только в ОЗУ 8400...BFFF или в ПЗУ E000. Тогда оттуда программа будет "доставать" до ПЗУ F800 и внутрисегментные CALL F8xx будут работать, т.к расстояние меньше 32767. Вот исходник игры. Как его переделать, чтобы правильно транслировалось?

Вот более оптимизированный ROM-BIOS. Исправил DIR_G (были забыты скобки, так XLT86 конвертирует). Ужал ещё на два десятка байтов и встроил сообщение об ошибке, а то в базовом ПЗУ ошибка (символ '?') выводилась сразу в строке с промптом.

Меня интересует отладка определенного куска кода, а не всего монитора, а по тому мне не охота следить за изменением размера 'хвоста' монитора, вот я и использую второй ORG. На данном этапе следить за кодом МГ-ввода и уж тем более за забитием FF_ом не использованных ячеек ПЗУ не имеет смысла вообще, все поменяется сотни раз еще, зачем на это терять время.
По использованию компиляторов нового ничего не могу добавить, сам пока на все грабли наступаю и ругаюсь...

Это был не очень удачный пример, как закинуть код в машинку, b2m подсказал, как это сделать правильно.

я заменил вызоы на константный адрес конструкцией типа загрузки AX этой константой, а дальше уже делаю CALL AX, так все собирается и работает. Я же выложил правленный исходник 'Уток', там это все видно. Только я не контролировал, а не затираю ли я содержимое АХ, возможно в этом часть проблем с отображением, а так утки летают, в них можно стрелять и иногда попадать ...

для затравки :
модель 8086.dll в протеусе очень глючная, но и это уже кое что.
Схему почищу и выложу всю инфо вечерком...

Да, метод CALL AX сработал, посмотрел игру. Константу тормозилки заменил с 2 на 8, чтобы скорость была как на обычном РК. Конструкция CALL reg работает и с другими регистрами, в частности и с неиспользуемыми при конверсии кодов от КР580 регистрами BP, DI и SI. Но всё-равно это извращение.

Надо делать обычный CALL FAR, но пока не знаю как это сделать. Не знаю как организовать сегмент, код которого не прилинковывается к программе и объявить дальней меткой нужный в этом сегменте адрес.

Обнаружил, что директива G работает только, если указывать адрес выше ~7C00. Это из-за того, что внутрисегментные переходы работают не дальше, чем 32767, а если параметр команд CALL/JMP больше 8000, то переходит неизвестно куда. Пока временно (не зная как сделать CALL FAR) сделал извращённую "химию", чтобы директива G работала и для ОЗУ ниже 8000. Для этого поставил промежуточный JMP в неиспользумой области выше стандартного экрана 7FF4...7FFF. Вот такое применил извращение:

Вот здесь более оптимизированная версия РК-ПЗУ конвертированного для 8088.