У кого-нибудь есть опыт использования кросс-ассемблера для этого процессора (или совместимого) под unix-подобной системой? Можете что-нибудь посоветовать?
Вид для печати
У кого-нибудь есть опыт использования кросс-ассемблера для этого процессора (или совместимого) под unix-подобной системой? Можете что-нибудь посоветовать?
hdc, а в чем простите проблема ?
http://alec-v.livejournal.com/12981.html
НО!
а) Синтаксис там AT&T
б) binutils все показывает в HEX
Вывод: Лучше запускать родной MACRO-11 в эмуляторе (IMHO).
Вроде бы нашлось что надо:
http://www.dbit.com/pub/linux/macro11/
Я хочу к эмулятору БК прикрутить тоже самое, что уже почти
доделано для эмулятора Специалиста:
Редактируем исходник в любимом редакторе с подсветкой синтаксиса
и автоподстановками:
http://www.asvcorp.ru/darch/tools/emustudio/editor.png
Потом компилируем ассемблером, который может формировать
отладочную информацию.
Загружаем бинарник в эмулятор, включаем отладчик и смотрим
что к чему:
http://www.asvcorp.ru/darch/tools/em...o/debugger.png
"И пусть спектрумисты завидуют!" :v2_wink2:
Расскажите в каком формате у вас отладочная информация, чем разбираете?
---------- Post added at 18:23 ---------- Previous post was at 18:19 ----------
Кстати, набрёл вот на это:
MACRO11 cross assembler for Win32
http://www.j-hoppe.de/PDP-11/MACRO11/macro11.html
Исходники присутствуют.
Коллеги, IMHO самый лучший - это родной MACRO11 под RT-11 на эмуляторе (например SIMH).
Появилась необходимость в автономном тесте, зашиваемом в ПЗУ, который смог бы диагностировать БК-0011М без полностью исправного ОЗУ и без наличия клавиатуры. Для этого хотелось бы портировать тест от Океана-240 на БК.
Эмуляторов БК для отладки такого теста предостаточно. А вот кросс-ассемблеров и кросс-дизассемблеров, работающих на платформе x86, я не обнаружил.
Может я плохо искал? Ссылками на такие проекты не поделитесь?
Нашел вот этот проект http://www.retrocmp.com/tools/macro-11-on-windows по наводке из темы http://zx.pk.ru/showthread.php?t=10533
В проекте bkunix есть порт Portable C Compiler-а. Там же ассемблер:
http://sourceforge.net/projects/bkun...0.1%20sources/
Я им пользовался в своей bk0010-fpga.
http://code.google.com/p/bk0010/
Си там слегка глючный, но не совсем бесполезный. Получилось перетащить в него Tiny FatFs и написать всю обвязку. Ассемблер валидный, хоть и синтаксис в нем не совсем традиционный. Эти тулы надо собирать под 32-битный таргет если хост 64-битный.
Кроме того, есть заточенный трудами felix-a порт gcc-aout для pdp11. Вот скрипт, который поможет его собрать с нуля:
http://code.google.com/p/svofski/sou...h?name=default
Компилировать что-то практическое я им пока не пробовал. Да и само оно может быть уже не соберется так просто без напильника, хороший повод провести эксперимент.
Тема по прежнему актуальна http://zx.pk.ru/showthread.php?t=20626
В качестве кросс-ассемблера 1801ВМ1 для Windows меня полностью устраивает "эмулятор ДВК" с родным компилятором DEC MACRO-11. Можно писать программы в блокноте Windows и тут же компилировать их в MACRO-11 в эмуляторе. Именно так я уже написал около сотни ассемблерных тестов различной аппаратуры на базе PDP-11.
К сожалению, исходники MACRO-11 до сих пор никем не выложены.
В качестве дизассемблера я использую IDA Pro 32 с модулем модели процессора собственной разработки ( подробнее здесь ).
Также я использую, встроенный в "Эмулятор ДВК" потоковый дизассемблер, показывающий ход выполнения программы, но к сожалению, для этого эмулятор приходится каждый раз перекомпилировать в зависимости от интересующей отладочной информации.
В модуле дизассемблера для IDA Pro 5.2 обнаружился баг с неправильным дизассемблированием команды XOR - исправленный вариант здесь: 1801VM1.w32.rar
в проекте pdp-2011 используется некий аналог, качаем отсюда http://pdp2011.sytse.net/wordpress/download/ там в исходниках проекта в каталоге /tools лежит рабочая версия под linux
Был вроде как штатный дизассемблер в RT-11 - сам в конце 80-х им пользовался. Может называться "DES" - но за давностью лет точно не помню.
А так практически единственный вариант - это DESS.SAV . По команде "Т" он
пишет исходник на устройство ( по умолчанию - "LP:" - принтер ). Начать вывод
на устройство - команда "О" (?) - короче, OUT. Назначить дисковое устройство -
MOUNT LD0: 123456.DSK , затем ASS LD0: LP: - данные для принтера пойдут в файл
123456.DSK . Помнится, я этот DESS ковырял в 1991 г., что бы он сразу в файл
писал макроассемблер, но, видимо, потерял его . (Вообще, конечно, это весьма
кривой способ вывода текста, но зато радикально правильный. Файл "123456.DSK"
не забываем предварительно забить пробелами или 000000, а так же создать его,
емкостью от 9 блоков ).( Пишет по-блокам, от 512 байт текста макроассемблера)
В MESS тоже есть дизассемблер (прилагается к каждому эмулируемому процессору, кстати) -- unidasm.
Тема не утратила актуальности - очередному ностальгирующему нужно компилировать тесты для ПЗУ bare system :). Не расскажете подробнее как процесс компиляции в эмуляторе организовать? У меня задача классическая - есть исходники в каталоге под Windows, надо каким-то образом запускать процесс сборки из скрипта (предпочтительнее makefile) и на выходе в том же каталоге получать двоичный образ (далее оно идет в mif и в FPGA или в ремулятор).
Пока помучал упоминаемый MACRO-11 под Win32, но у него непонятный объектный формат, линкер пока не подобрал. Еще собрал GCC для PDP-11 под MinGW, вроде работает, но у него синтаксис не нативный.
Если речь идет о программе ОС RT-11 MACRO.SAV , то к нему штатный линковщик - LINK.SAV . Скажу сразу - за несколько часов с интеллектом IQ=100 там делать нечего - надо въезжать неделями, что значит определенные знаки и команды и т.п. синтакис.
Написание софта на MACRO/LINK - лучше всего не вылазить за пределы RT-11, и использовать заглавные КОИ-7 . Текстовый редактор для этих целей - SCREEN.SAV,
на худой конец EDIK.SAV ( не путать с монстром от "Консула" - EDIT/K52 ).
Если не удается найти EDIK.SAV - можно использовать EDIKM.SAV от комплекта поставки БК11М - но надо переправить ключевую клавишу ( в DESS.SAV ) на какую-нибуть от ДВК ( в БК11М - вроде как "ШАГ" ).
Полное ТО на комплект среды разработки давалось с каждым ДВК3 и ДВК4 - но их блондины сразу ставили в сортир как главный папирус.
Написал автору порта MACRO-11, посмотрим что расскажет как он линковал.
На самый крайний вариант напишу свой простенький конвертор выходного объектника MACRO-11 Win32, там формат вроде достаточно простой, но не хочется время тратить.
Это все понятно, но я хотел бы собирать весь проект целиком одним кликом из своей любимой IDE, а не что-то копировать ТС, потом еще что-то набирать в эмуляторе, потом копировать ТС обратно. Тут важна скорость и удобство, бывает до нескольких десятков пересборок в час, утомительно скакать по окнам и что-то вбивать. А так - одну кнюпочку нажал, по makefile пересобрался .mif, потом .sof, автоматом ушло в FPGA и само перезапустилось.
Вот, например, некоторые эмуляторы CP/M-80 позволяют запускать себя, потом указанное приложение с указанными параметрами (передается как командная строка приложения эмулятора) и все файловые операции транслируются автоматически в каталог DOS/Windows. Запускать там m80/l80 вполне прикольно и можно приспособить в свой общий makefile.
PS. Автор порта MACRO-11 Win32 ответил что формат выходного объектника там RT-11 (доку я нашел на него), но линкера под Win32 он не знает. Ну и ладно, своя сборка GCC устроит пока, тем более потом все равно С будет нужен.
Я правильно понимаю?
Своя сборка GCC
Хост-платформа: Linux
Таргет: 1801 (совместим с системой команд PDP-11)
Язык: Си
Выходной формат? (.sav)?
Можно ли делать в Си-коде асмовые вставки?
Можно ли делать/использовать библиотеки стандартными утилитами GCC типа ar?
Есть ли возможность скачать и опробовать эту сборку для человека, который плоховато дружит с Linux?
Нет, я под MinGW собрал для Win32
Да. Только там нет тагета именно 1801, придется что-то из дековских подбирать.
Формат объектнков a.out.
Насчет .sav не знаю, это проприетарный формат DEC RT-11. Я сейчас просмотрел - линкер ld формат .sav не поддерживает. Но если не злоупотреблять оверлеями то .sav примитивный, можно конвертор написать.
Собрано на базе GCC 4.6.2, полагаю что стандартный способ ассемблерных вставок для GCC должен работать.
Да.
Выложил архив 17МБ
Только сам C/C++ я еще не пробовал. И там у меня пара ран-тайм библиотек со сбоем собралась, но с собственно сишными все ОК. Для программирования на С для bare-metall систем не собранные либы не нужны.
Vslav, спасибо за ответы и за сборку.
Собираюсь попробовать сделать подсистему Pdp11Dev (или как лучше назвать?) для разработки на паскалеподобном языке Оберон-2. Таргеты - БК-0010/0011(M), УКНЦ, возможно, ДВК. Интерес чисто теоретический. Формат .sav не самоцель, просто полезно было бы иметь - видел его поддержку в интерактивном дизассемблере IDA Pro, значит формат достаточно известный.
Сама подсистема устроена так: среда разработки транслирует своими средствами модуль на Обероне в его сишный эквивалент, потом запускает батник, в котором можно прописать всю логику работы по компиляции сишных файлов в бинари и конвертировании a.out в нужный выходной формат - образ кассеты, образ диска и т.п. Такой принцип обкатан на подсистемах ZXDev и MsxDev и хорошо работает. Почему именно Оберон, а не чистый Си - разговор отдельный и наверное не очень тематический.
За счёт единообразного по стилю набора библиотек для различных платформ возможна (со многими ограничениями конечно, но возможна) разработка, например, игры с одного исходника для нескольких целевых платформ, различных по архитектуре, вплоть до разрядности. Библиотеки конечно нужно писать с нуля, знания данного асма у меня вообще нет, так что, вероятно, придётся задавать много глупых вопросов по низкоуровневому кодингу. :)
Несколько подобных игр находятся у меня в разработке. Целевые платформы - ZX Spectrum, Windows (32/64 bit), Linux (SDL), MSX, Java micro edition, MS-DOS, возможно в скором будущем - Nintendo/NES (6502). Почему бы не прибавить к ним и БК/УК-НЦ. :)
---------- Post added at 02:52 ---------- Previous post was at 01:40 ----------
Цель разработки такой подсистемы - не только делать игру сразу для нескольких ретро-платформ. Мне всегда не хватало чего-то для быстрого старта. Ну вот, допустим, захотелось покодить для БК. Асма не знаю. Слова "MACRO 11" меня пугают. Зато когда-то работал на Fast/Pascal. Т.е. не хватает чего-то такого: скачал, набрал простенькую программку на пару строк и запустил одним нажатием кнопки, притом не внутри эмулятора. Вот что-то подобное и нужно разработать, чтобы начинающим, кто захочет попробовать кодить под ретро, не пришлось делать рутинную работу по написанию вывода буквочек в текстовую консоль на асме.
Опишу возникшие трудности со сборкой. Пробую собирать простейший исходник:
1. Затребовала ряд .dll:Код:int main(int argc, char **argv)
{
return 0;
}
libgcc_s_dw2-1.dll
libgmp-10.dll
libiconv-2.dll
libmpc-2.dll
libmpfr-1.dll
Взял их с MINGW и поместил в /bin. Пришлось прописать SET path=..\Bin\gcc\bin
2. Не увиделись файлы в путях для инклюдов. Вызываю так:
pdp11-aout-gcc.exe -I ../Lib/C -I ../Lib
Пока пришлось разместить все файлы в одной текущей папке.
3. Вроде собралось. Но выдало такое:
h:\Archive\Projects\XDev\Pdp11Dev\Obj>SET path=..\Bin\gcc\bin
h:\Archive\Projects\XDev\Pdp11Dev\Obj>SET gcc=..\Bin\gcc\bin\pdp11-aout-gcc.exe
-I ../Lib/C -I ../Lib
h:\Archive\Projects\XDev\Pdp11Dev\Obj>..\Bin\gcc\b in\pdp11-aout-gcc.exe -I ../Li
b/C -I ../Lib Empty.c
h:/archive/projects/xdev/pdp11dev/bin/gcc/bin/../lib/gcc/pdp11-aout/4.6.2/../../
../../pdp11-aout/bin/ld.exe: cannot find crt0.o: No such file or directory
h:/archive/projects/xdev/pdp11dev/bin/gcc/bin/../lib/gcc/pdp11-aout/4.6.2/../../
../../pdp11-aout/bin/ld.exe: cannot find -lc
collect2: ld returned 1 exit status
Файла crt0.o в архиве нет. Наверное нужно вызывать как-то не так, да?
Хотелось бы собрать хотя бы helloworld хотя бы для какой-то из платформ - БК, УК-НЦ или ДВК. Если есть идеи, благодарю за них заранее.
Увы, это то о чем я говорил - библиотека ран-тайм для C у меня не собралась. Дело в том, что у меня есть своя модульная система на основе RTOS TNKernel, и все самописное, включая нужные процедуры crt для разных платформ. Поэтому я не разбирался почему оно не собралось - мне эти библиотеки не нужны.
Варианты решения - или попробовать самому собрать эту библиотеку отдельно, или попробовать взять готовую из какой другой сборки. Или посмотреть какие модули оно хочет из этой библиотеки - если программа пустая то скорее всего стартовый модуль, написать его самому и библиотеку не пользовать.
Есть ли интерес к подобной подсистеме для разработки под БК и УК-НЦ? Потому что если нет, то, боюсь, на этом мои исследования и закончены. Не чувствую достаточной уверенности в деле написания собственного линкера или даже конвертера из бинарника в образы ленты/диска. Есть желающие помочь? Получим не только среду разработки на Обероне, но и можно будет скомпоновать свою среду для разработки на Си. Притом по кодогенерации она будет явно мощнее, чем нативные. А библиотеки можно подтянуть да хоть с Fast/Pascal.
Итак. Задача №1. Как-то получить на выходе бинарный файл, скомпилированный под нужный нам адрес.
Задача №2. Уже непосредственно конвертировать в образы. Начать можно не с .sav, а, например, с образа ленты БК. Посмотрел, в эмуляторе БК-0010.01 Андрея Грабовца для хранения игр используется непосредственно формат .bin. Он чем-то отличается от бинарника, который наверное способен выдать модифицированный GCC?
Vslav, я был бы рад примеру подобной библиотеки с процедурами crt и стартовым модулем, которую можно собрать данным GCC.
Я бы немного поправил (хотя возможно зря я вообще встреваю, я ведь вовсе не программер), но тут надо ориентироваться на ОС RT-11 и её форматы и как самый честный по отношению к PDP-11 в плане железок - это ДВК конечно, но ДВК были(есть) на разных процессорах и на ВМ1 и на ВМ2 и на ВМ3 (???), то есть если собранный sav работает под RT-11 он будет(должен) работать везде и на УК-НЦ(ВМ2) и на БК11М(строго ВМ1) и на ДВК(ВМх). Как-то так.
Спецификой у этих родственных машинок является только графика !!!
Поэтому графику пока отложить в сторону (по мере изучения ОС и платформы нюансы с ней связанные станут понятнее - везде графика на уровне железа по разному сделана, такие дела. И если брать какой-то ориентир в плане графики - это наверное либо что то новое к ДВК прикручивать (желательно поддержку Glide - досовский или виндовый) или ориентироваться на КЦГД,
как самый продвинутый отечественный видео-адаптер, который, кстати говоря, на ВМ2)
ИМХО - на БК10 УНИКС-системы и их варианты не жизнеспособны. Тоже и о "Си" можно сказать. Причина - мало ОЗУ. 15.5 кбайт при фактически враждебном ПЗУ - это все, что там имеется. Не стоит забывать и о быстродействии - 250 т. рег-рег в ДОЗУ, 400 т. в ПЗУ.
А вот на БК11/М есть шанс - там можно и скрытые библиотечки разместить в скрытых страницах ДОЗУ, и вообще организовать подкачку оверлеев с диска.
Главная проблема БК11/М - быстродействие. Оно примерно 300 т. рег-рег в ДОЗУ.
Не следует так же забывать, что для эффективного фукционирования компилированного кода ( с языка высокого уровня ) его надо днями-неделями править ручками, иначе - тороза 2-3 крат и раздутый код - на 20-200% по сравнению с предельно оптимизированным.
А вообще есть старая идея - прикрутить ДЕМОС ( следует читать "Уникс" ) к БК11М - да хотя бы с оверлеями на диске. Если там проблема в ДП - в так в варианте с блоком "ВМ3А" с 2-мя метрами - но скажу сразу, оплатить по ставкам кодера этот процесс в данный момент у меня нет возможности, даже частично ( бухло - не в счет... ).
Вот тот же fast\pascal - код там может и не раздутый (не знаю), но вот SAV файлы еле еле в память влазят, по этой причинеЦитата:
и раздутый код
эта среда разработки и не стала ничем более как ознакомительной для школьников\студентов, что бы подготовить их к
Борланд(Турбо) Паскалю под ДОС в ВУЗах. (это я про 90-е конечно пишу).
Есть надежда и на двух процессорность ВМ1 - двухпроцессорность может сделать "nextgen" ДВК\БК (УК-НЦ по любому в сторонке - как машинка принципиально апгрейду не подлежащая - по понятным причинам).
Принимается.
hobot, так я - ещё меньше программер, если брать PDP-11. :) Поэтому не справлюсь без помощи энтузиастов, даже непрограммеров. :)
А ничего, что .sav - проприетарный и закрытый формат? А то ведь, вероятно, придётся писать линкер в этот формат. Или, по крайней мере, конвертер bin2sav.
Принимается. Хотя я как-то краем уха слышал о компиляторе Паскаля именно на БК-0010 (не 0011).
Эхехе. :) Но тоже принимается, куда ж деваться. :)
Может GCC, собранный Vslav'ом, даст лучшего качества код?
В принципе, Спектрум да и проц Z80 тоже не особо ахти какая подходящая вещь для разработки на ЯВУ, однако мы сейчас отбросим в сторону асмовский кодинг как идеальный способ разработки игр для ретро-платформ, потому что он медленно, но верно сходит на убыль, и сконцентрируемся на попытке получить хотя бы хелловород и хотя бы сверхбольшого размера, но рабочий и на GCC-PDP11 (со вставками асма). Это будет первый очень грамотный шаг в сторону от асма. Конечно при патронаже и прикрытии асма.
А если удастся писать на таком Си исключительно на вставках асма - то получится уже вполне себе эффективная вещь для разработки под PDP-11, можно будет такой код даже сдабривать вставками на Си и, авось, получится что-то неплохое в духе подсистемы ZXDev (ссылка в подписи), однако я не настаиваю, вам как специалистам виднее.
gcc не является грамотным шагом, но и делать еще один ужасм ни к чему. Выгоднеее детально разобрать референсный компилятор и/или довести до желаемого состояния кросс macro11, и лишь затем замахиваться на разбор рудиментов оставшихся в gcc под архитектуру pdp11.
вот тут в родной документации что то сказано про формат SAV. В целом это скорее к проф.системщикам вопрос, дождёмся их комментария ? )
И (я сейчас поиск по форуму не гонял) формат SAV уже обсуждали ЕМНИП и даже не 1 раз возможно. Не такой он в RT-11 и сложный и не такой уж и закрытый. Подозреваю на NEXTGEN машинках наличие более продвинутых ОС чем RT-11 там и вовсе всё по другому, поэтому тут консультации опять же только с проф. системщиками будут нужны и не один раз возможно.
:wink:
Тут вот какая штука, есть естественная среда, большинство профи (и я их именно в этом поддерживаю на все 100) склонны отправлять людей писать и компилировать в ней, поскольку это 100% гарантия оптимально рабочей программы на выходе. И ничего не надо выдумывать, под любую ось (RT-11, RSX, TSX, ДЕМОС) уже есть компиляторы и линкер (в том числе и компилятор для Фортрана, Паскаля и Си, правда пока провисон "по прежнему" с Модулой2, но физически она есть, просто
её никто не использовал никогда, т.е. нет человека с практикой кто бы
сказал - вот так надо делать и книга4 ПО ДВК где описание модулы2
всё ещё разыскивается для возможности сделать скан!).
Однако в рамках Оберон-Технологий :wink: ничего удивительного если
что то действительно с нуля надо создавать. В своё время и БК и УК-НЦ и
ДВК пришли студентам и школьникам только с ОС и компиляторами, по
сути весь дополнительный софт писался пользователями по необходимости или личному желанию (обучающий, драйвера для доп.устройств и сети, игры). Конечно были профессиональные пакеты (это в частности софт для локальной сети. В общем чем и ценны (помимо ностальгии) все наработки на базе отечественных КУВТ - каждый мог и вносил свою лепту (если хотел\мог\желал) написанием своей версии программ форматирования или улучшенным драйверов печати для принтеров и т.д. и т.п. - ничего не напоминает? (я про ОС не виндовые :wink:).
Формат .SAV в DEC - машинках - вообще-то базовый, и конкретно разжеван в комплектных доках по ДВК.
Если имеется необходимость быстрого переноса с ИБМ на БК11М программ на языках высокого уровня - лучше воспользоваться Паскаль-программами - написать 1 шт. строку кодов они умеют ( и килобайт 10 библиотек воткнуть в исполняемый файл .SAV ).
Насчет Си - вроде как был в составе последних ДВК4 такой компилятор - он же пойдет и на БК11М с RT-11.
*
Насчет скорости процесса создания софта на MACRO-11 для ДВК/БК - ничего лучше использования эмуля ДВК со штатными средствами RT-11 в принципе не может быть - т.к. все остальные среды - это всего лишь паразитные надстройки над этим процессом кодинга. А вот написание кода для не поддерживающих RT-11 машинок - это нетривиальная задача для MACRO-11, но вполне решаемая - ручками, под DESS.SAV ( править код , полученный из LINK.SAV )
*
И вопрос на засыпку - кто-нибуть знает ковырялку для W7 - по типу Винхекса, но с поддержкой восьмеричных чисел ?
- был и есть и шёл с машинками с самого начала в виде отдельного пакета с огромной толстой книгой. В архиве представлен в несколькихЦитата:
Насчет Си
вариантах.
Про родную среду полностью согласен, НО(!) народ боится и обижается когда отправляешь в RT-11 компилировать, говорит не хочу (почему не ведомо мне), хочу кнопку у себя в системе удобную, телепатов нет, какую кнопку? где?
Делайте сами - совет прозвучал - ещё больше обижаются )))
ИМХО: программирование под RT-11 = МАCRO-11 ))) Никуда не денешься ! )))
Поэтому максимум что тут можно пожелать - писать с нуля транслятор который на выходе будет давать оптимальнейший
код на макро-11, который затем легко будет штатными средствами довести до исполняемого файла типа SAV.
Литература
http://archive.pdp-11.org.ru/BIBLIOTEKA/dwkbooks/
http://archive.pdp-11.org.ru/BIBLIOT...KTXT/RAFOS_II/
Я не хочу пользоваться "родными" компиляторами и средами, которые работают под RT-11, по нескольким причинам.
1. Они порождают довольно мерзкий по качеству код. Это не окончательный приговор, есть и приятно удивляющие находки, но это типично - слишком мало памяти и быстродействия для порождения высокооптимизированного кода.
2. Если с первым ещё как-то можно мириться, то второе неизбежно приводит в тупик. Я о моменте когда упираешься в глюк или в конкретные ограничения выбранного транслятора. Доработать его как правило невозможно - он "нативный", исходников нет, приходится изобретать патчи. О развитии, доработке и внесении новых возможностей и речи нет.
3. Жирные рантаймы, которые обязательно пристегнёт наша любимая среда, которая умеет штатными средствами генерировать .sav.
Так что я настаиваю на gcc-pdp11. Вы версию посмотрите. Он должен такой код выдавать, что пальчики оближете. Игры для БК-10 можно будет писать. Несложные конечно, чудеса бывают, но редко. Но можно. И, наконец, я уверен что можно будет минимизировать размер рантаймов под самый минимум.
У меня просьба к специалистам. Соберите минимальный EMPTY.SAV, который будет запускаться под RT-11 и выходить в ОС. Всего лишь, ничего больше. В средствах не ограничиваю, на Fast/Pascal смог бы написать и сам, но Паскаль пристегнёт большой рантайм, и придётся разбираться чего там лишнего.
Вопрос. В RT-11 есть такое понятие как код возврата из ОС? Ну, тот самый, который main() { return EXIT_CODE; }
Если покажете код на MACRO-11, который будет всего лишь возвращаться в RT-11 (с нормальным кодом возврата), у нас уже будет от чего плясать. Потом мы зациклим программу и посмотрим как она завесит RT-11. Нет предела совершенству, для платформы Java micro edition я именно с этого и начинал. :) А теперь пишу для неё игру на Обероне, хотя до меня никто этого не делал.
Конкретно в моём случае я объяснил почему чураюсь "нативных" средств разработки для ретро-платформ. Потому что это технологический тупик. А вовсе не потому что в эмуляторе кнопки непривычно нажимать, хотя и это тоже.
А вот кнопку какую я хочу. Да простую. Которая соберёт мой исходник для RT-11, запулит в образ диска и откроет в эмуляторе с автозапуском. Для разработки под Спектрум пользуюсь такой волшебной кнопкой, очень пользительно.
И писали они транслятор год, и писали два... ;)
Не, ну чо, нормальный вариант если кому-то хочется потратить на это лет пять. А чем это лучше ассемблера, встроенного в gcc-pdp11?