[jcxz 224]

1 час назад, repstosw сказал:

Борландовские программы очень часто любили релокейшены в EXE-хедеры размещать. При переводе в COM была проблема с адресами данных.   Помню, нашёл какой-то сильно сложный exe2com, который мог разматывать релокейшены и генерил успешный комок.

Не очень понятно - о каких "релокейшенах" речь? DOS-овский EXE-файл, насколько помню - мог содержать описания нескольких сегментов (в отличие от COM). Которые ОС грузила в память как ей удобно. И настройку (релокацию) ОС проводила только сегментных адресов. И описаны все эти сегменты были конечно в заголовке EXE. А где же иначе?

И в COM думаю можно было преобразовать только такой EXE, общий размер сегментов которого не превышал 64КБ.

 

PS: И кстати - не вижу никакой проблемы преобразовать EXE-файл DOS-формата в .bin для МК. Просто нужно выполнить ту работу, которую делает DOS при старте EXE. Скорее всего существововали готовые инструменты для МК на ядре x86, которые умели прожёвывать EXE-формат: или транслировать в что-то своё и потом прошивать в МК; или напрямую - выполнять работу ОС для EXE-файла при каждом старте МК.

[mantech 48]

1 минуту назад, jcxz сказал:

И в COM думаю можно было преобразовать только такой EXE, общий размер сегментов которого не превышал 64КБ.

Так и было всегда, на сколь помню.

[khach 40]

24 минуты назад, jcxz сказал:

Не очень понятно - о каких "релокейшенах" речь? DOS-овский EXE-файл, насколько помню - мог содержать описания нескольких сегментов (в отличие от COM). Которые ОС грузила в память как ей удобно. И настройку (релокацию) ОС проводила только сегментных адресов. И описаны все эти сегменты были конечно в заголовке EXE.

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

Ну и например в дизасме встречаешь вызовы 21 прерывания, которого понятное дело нет в системе, т.к нет и БИОСа, но при разработке похоже использовалась отладка под ДОС и эти рудименты видны  в коде, т.к условную компиляцию никто не настраивал.

[repstosw 18]

25 minutes ago, mantech said:

О как, и каким образом потом к ФС из этой проги обращаться?)))

1. Не всегда нужна ФС

2. Также, как и в микроконтроллерарах. например:  FatFs, PetitFs.  И другие.   За чтение/запись сектора диска и форматирование - отвечает прерывание BIOS.   ДОС здесь не при делах.

25 minutes ago, jcxz said:

Не очень понятно - о каких "релокейшенах" речь? DOS-овский EXE-файл, насколько помню - мог содержать описания нескольких сегментов (в отличие от COM). Которые ОС грузила в память как ей удобно. И настройку (релокацию) ОС проводила только сегментных адресов. И описаны все эти сегменты были конечно в заголовке EXE. А где же иначе?

https://cosmodoc.org/topics/exe-file-format/#relocation-table

 

25 minutes ago, jcxz said:

PS: И кстати - не вижу никакой проблемы преобразовать EXE-файл DOS-формата в .bin для МК. Просто нужно выполнить ту работу, которую делает DOS при старте EXE. Скорее всего существововали готовые инструменты для МК на ядре x86, которые умели прожёвывать EXE-формат: или транслировать в что-то своё и потом прошивать в МК; или напрямую - выполнять работу ОС для EXE-файла при каждом старте МК.

Бесплатно это никто не сделает.

Изменено 1 августа пользователем repstosw

[x893 51]

1 hour ago, mantech said:

Думаете решил задачу или забил болт?))))))

Решил и забил.

[repstosw 18]

12 hours ago, mantech said:

Ага и еще оверлеи делать, чтоб их)))

Оверлеи хороши там, где шина с ограниченным адресным пространством.

В приставках NES и SNES использовался такой приём - как переключение страниц памяти.   Тоесть адресная шина на 64K,  а память на 256K к примеру.  В нижних 32К лежал непереключаемый системный код (ядро игры), а в верхних 32К - одна из страниц (для 256К их будет 8). Номер страницы выбирался портом (привет мэпперам) или по кнопке Reset (двоичный счётчик, выбор игры).

 

Что касается "эмуляции VS. реверс", не всегда годится эмуляция. Например тот же DOSBox, не на всех платформах он сносно пойдёт. Точнее игры в полную скорость не пойдут на слабых платформах.  Поэтому иногда лучше реверс.

Вот несколько лет назад отреверсил:  https://github.com/rep-stosw/tube-game-dos

 

Вначале реверс под DOSBox с Watcom, затем добился суверенитета приложения в ДОС, затем перетащил  в Винду, затем на свои консоли. 

Попутно есть вёб версия на итче https://clobberasm.itch.io/tube

Изменено 2 августа пользователем repstosw

[x893 51]

5 hours ago, repstosw said:

Попутно есть вёб версия на итче https://clobberasm.itch.io/tube

Edited 5 hours ago by repstosw

https://html-classic.itch.zone/html/4287284/index.html

Лучше прямую

[jcxz 224]

9 часов назад, repstosw сказал:

Что касается "эмуляции VS. реверс", не всегда годится эмуляция. Например тот же DOSBox, не на всех платформах он сносно пойдёт. Точнее игры в полную скорость не пойдут на слабых платформах.  Поэтому иногда лучше реверс.

...

Вначале реверс под DOSBox с Watcom, затем добился суверенитета приложения в ДОС, затем перетащил  в Винду, затем на свои консоли.

К чему эта сентенция? Ваша исходная игрушка работала на 80188? (посмотрите на заголовок темы)

Если да, то почти 100%-но не составит труда запустить её в режиме эмуляции на современном, достаточно мощном CPU. Потому как эмуляция графики - это будет (скорее всего) как раз самая простая из задач эмуляции периферии. Проще только эмуляция собственно выполнения команд CPU.

Если она работала не на 80188 (или чём-то подобном), то тогда какое она имеет отношение к обсуждаемой теме?

 

Я могу привести ссылки на ресурсы с сотнями игрушек для старых ПК, которые прекрасно работают на современных ПК в режиме эмуляции. Код которых выполняется в режиме интерпретатора на современном CPU.

Вот например: http://caglrc.cc/scalar/categories/all/

Это - достаточное доказательство реализуемости задачи в режиме эмуляции?

[repstosw 18]

55 minutes ago, jcxz said:

Ваша исходная игрушка

Это не моя игрушка.

55 minutes ago, jcxz said:

работала на 80188? (посмотрите на заголовок темы)

Посмотрел.  Архитектура x86.

56 minutes ago, jcxz said:

почти 100%-но не составит труда запустить её в режиме эмуляции на современном, достаточно мощном CPU.

Мощным для кого? Насколько мощным?  Какой критерий мощности? Кто его установил?

57 minutes ago, jcxz said:

Потому как эмуляция графики - это будет (скорее всего) как раз самая простая из задач эмуляции периферии.

Pixel buffer - не, не слышал...

57 minutes ago, jcxz said:

Я могу привести ссылки на ресурсы с сотнями игрушек для старых ПК, которые прекрасно работают на современных ПК в режиме эмуляции.

Если они работали не на 80188 (или чём-то подобном), то тогда какое они имеют отношение к обсуждаемой теме?

58 minutes ago, jcxz said:

Это - достаточное доказательство реализуемости задачи в режиме эмуляции?

Нет. Попробуйте это сделать на STM32 в режиме эмуляции.

[jcxz 224]

29 минут назад, repstosw сказал:

Мощным для кого? Насколько мощным?  Какой критерий мощности? Кто его установил?

Мощным относительно исходного 80188. Вроде как очевидно, не?

29 минут назад, repstosw сказал:

Pixel buffer - не, не слышал...

Приведите пожалуйста ссылку на этот самый "Pixel buffer" в 80188. Или причём он здесь?

Под "эмуляцией графики", я имел в виду эмуляцию графики рисуемой исходно 80188.

29 минут назад, repstosw сказал:

Если они работали не на 80188 (или чём-то подобном), то тогда какое они имеют отношение к обсуждаемой теме?

Точно такое же, как приведённая вами игрушка к этой теме. Я их привёл как раз для демонстрации бессмысленности вашей ссылки на игрушки никак не относящиеся к 80188.

29 минут назад, repstosw сказал:

Нет. Попробуйте это сделать на STM32 в режиме эмуляции.

Я это уже давно сделал. Попробуйте прочитать тему несколько сообщений выше. Я уже ранее приводил код эмуляции одной из самых тяжёлых для эмуляции команд 80188 на Cortex-M. Попробуйте посчитать сколько она занимает тактов на 80188 и сколько - её эмуляция на Cortex-M4/M7. И подумать.