nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 13 Nov 2018 10:29



Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3
Программирование на компиляторах ЯВУ для ретро ЭВМ 
Author Message
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 246
Location: Россия
Reply with quote
 
Вот какая тема у текущего диспута. Я упомянул, что Е.Седов изобрёл метод писать безадресные программы. А Вы на основании того, что когда-то обсуждали что-то на отчасти касающуюся тему, стали утверждать, что метод негодный. Из-за того, что в неизвестных условиях, якобы, не работает. И вот теперь мы успешно (т.к пока без особого хамства) пререкаемся, придираясь к каждой неточности или неверно понятому слову. Уже пошли на третий круг. Это весело, но бесполезно.

Lavr wrote:
В неизвестной системе ОЗУ...

Что Вы всё-время приплетаете "неизвестную систему"? Не бывает неизвестных систем. Есть конкретные компьютеры про которые всё известно от и до. И даже в Вашем "абстрактно-вакуумном" случае, кто мешает проверить, что с 0 есть ОЗУ. Это усложнит, но всё-равно будет на порядок проще, чем городить огород с поиском сигнатур и последующей коррекцией.

И для каждого случая можно в начале кода вставить одну команду загрузки в HL адреса, где в данной системе есть ОЗУ. Вот и получится универсальная программа, без всяких извратов. Суть-то вовсе не в том, чтобы узнать адрес загрузки, а чтобы без всяких сложностей и быстро писать позиционно независимые программы. И я это делал, а Вы хоть одну программу с табличной коррекцией написали? Это же морока.

Было бы почётнее, если бы вы в качестве упражнения решили другую задачу - можно ли без поиска сигнатур и используя только стек, узнать адрес размещения кода?

Lavr wrote:
дЕбил пишется через "Е"

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

Учёные всегда с опозданием фиксируют установившиеся нормы правописания и произношения. Через сколько-то лет признАют, что писать дибил тоже правильно. Ученые языковеды придумывают как правильно писать, вместо того, чтобы вовремя отслеживать и фиксировать нормами развитие языка и бороться с англиканизмами.

Кстати, из-за того, что с искажением заимствовали, программа пишется с двумя М. Я безуспешно пытался с этим бороться в 90-тые. Как правильно писать программирование, программный...

Lavr wrote:
Перемещаемые программы придуманы задолго до Е.Седова, году так в 1977... Но я нигде не видел, чтобы была решена явно проблема нахождения абсолютного адреса для коррекции таблицы переходов.

CP/M грузит и запускает всегда с адреса 100, потому адрес загрузки всегда ясен. Адрес куда перемещать тоже ясен, высчитывается так: адрес BDOS из ячейки 6 минус размер кода. А задачи вычисления адреса загрузки в вакууме просто не возникало.

Lavr wrote:
Нам в любом случае достаточно одного известного адреса с кодом RET.

Вы уже утверждали, что RET лучше (наверно потому, что RET есть в любом ROM-BIOS). Приведите фрагмент кода, как Вы будете с помощью одного RET получать в HL адрес загрузки и учтите, что эту процедуру надо делать для каждой команды перехода.

Lavr wrote:
И экономия в пару байт по сравнению с изменением ПЗУ - это мелочь.

Опять игнорируете, что Вам отвечают. Разве кто-то ради этого вопроса менял ПЗУ?

Хотя в РК86 ПЗУ стОит изменить. Хотя бы убрать ошибки. Я выиграл там оптимизацией 100 байт, и вставил туда, что было надо. В 4 кб ПЗУ Специалиста оптимизацией выигрывается до пол-килобайта. В 2 кб ПЗУ ОРИОНА - до 200 байт.

Я несколько раз написал, что для абстрактного случая достаточно двух команд "создающих" подрограмму возвращающую текущий адрес. Кроме того позиционно независимый оверлей подгружается не в вакуум, а конкретной программой, в которой может быть хоть десяток нужных подпрограмм. Никому не нужно отдельную независимую программу стартовать где угодно? Так что даже вопрос о отсутствии нужных подпрограмм или отсутствии ОЗУ где-то вообще не стоит.

Lavr wrote:
Этот самый отладчик SID разработан под CP/M, но также без проблем работал на Микроше, РК-86 и Специалисте - меня тогда и заинтересовало, а как ему обойтись без ручного ввода адресов подпрограмм?

На перечисленных Вами компьютерах SID и DDT были уже в перемещённом на конкретные адреса формате (и адаптированные на вызовы ПЗУ). Причём интересно, что все SID-ы и DDT, что мне попадались были с дефектами. Потому пришлось самому адаптировать DDT. Причём получил исходник, а не просто коды, так что могу транслировать на любые адреса.

А те кто делали это до меня, просто подставляли по адресу 6 значение RAMTOP конкретной машины, подставив по адресу RAMTOP код 'JMP F800' и после команды G100, получали код DDT перемещённый под вершину ОЗУ. После чего оставалось найти вызовы BDOS функций для опроса клавиатуры и вывода на экран, и заменить их на CALL F803 и F809.

Кстати тот, кто адаптировал SID не был знающим человеком. SID отличается от DDT отладкой с символическими именами для чего загружается получаемая после трансляции CP/M-ассемблером таблица с адресами меток и констант. Если CP/M нет, то и SYM-файла нет. Какой же смысл без всякой пользы вдвое увеличивать объём отладчика, ведь в РК ОЗУ и без того не хватает.

Lavr wrote:
Ещё раз отладчик SID написан в 1977, он перемещаемый, но не умел сам находить нужный абсолютный адрес. RK-DOS, Специалист и ОРИОН - эти слова никто не знал в то время, но SID вполне может работать на этих машинах.

О чём Вы всё время пишете, - не нужно SID-у находить адрес. В CP/M все программы стартуют с 100. А на упомянутых машинах SID уже перемещённый, не содержащий таблиц коррекции и программ перемещения кода.

Lavr wrote:
barsik wrote:
... Вы пошли уже по второму кругу.

... Вы с одного раза не поняли, хотя и долго думали, пришлось объяснить вам повторно.

Я ещё на первое уточнение о цели определения местоположения кода ответил, что это сразу ясно. Да и как это можно было не понять? Вы не заметили первый ответ, во второй раз утверждая, что я ничего не понял, потому я вынужден был второй раз привести ту же цитату и свой ответ.

Lavr wrote:
barsik wrote:
Lavr wrote:
Ну и раз вы такой умный - покажите, как найти...

Не надо так писать. Зачем тролить?

Я тоже не пойму - зачем вы дурака включаете?

Фраза "раз вы такой умный" это явная издёвка. Я не стал в ответ грубить, а вежливо попросил так не делать. Объясните из чего тут следует, что я "включил дурака"? Цитаты приводят, чтобы отвечать на них. Здесь нет ответа на эту цитату? И зачем вообще переходить на личности?

Lavr wrote:
CP/M, и Мониторы РК-86, Микроши и Специалиста - весьма разные ОС, карты памяти тоже разные у них - но SID работал на всех этих системах. А мы нашли метод как бы он мог найти абсолютный адрес для своей коррекции переходов сам.

У Вас тут полный нонсенс.

В CP/M требовалось перемещать код, т.к заранее не известен размер TPA, т.к было ~400 CP/M-машин, версий CP/M ещё больше и у каждой другая вершина BDOS.

А про РК, Микрошу и Специалист известно всё, от и до. И даже если бы надо было сделать универсальный SID сразу для всех 3-х ЭВМ, пришлось бы писать программу идентификации конкретной машины, чтобы узнать как корректировать код и куда его перемещать. Но главное, непонятно зачем кому-то грузить SID на разные случайные адреса. А если это SID оригинальный, то он может стартовать только с адреса 100.

Объясните кому нечего делать и он изуродовал этот SID так, чтобы он мог грузиться на любой произвольный адрес, затем по поиску сигнатур вычислял где он, затем определял тип машины, в соответствии с этим перенастраивал подпрограммы под ROM-BIOS конкретного компьютера, и уже затем перемещался под вершину ОЗУ. Зачем вообще грузить SID на случайный адрес?

Так не бывает. Используются уже готовые перемещённые коды, адаптированные для конкретной ЭВМ. И опять-таки, повторю, SID - это глупость, если не используется SYM-файл. Адаптированный DDT делает тО же и имеет размер всего 3.5 кб вместо 7-ми килобайт.


03 May 2018 03:51
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
barsik wrote:
Что Вы всё-время приплетаете "неизвестную систему"? Не бывает неизвестных систем. Есть конкретные компьютеры про которые всё известно от и до.

"Приплетаете" это в общем-то вы. В частности Е.Седова, который абсолютный адрес смог получить
только из подпрограммы в ПЗУ, что, собственно, самый простой способ, но программы Седова не переносятся
даже на полностью идентичный компьютер, где в ПЗУ такой подпрограммы нет.

Если вы сели за незнакомый вам тот-же РК-86 вам никак не известно об нем "всё от и до".
Это вы просто огульно врёте. Вам неизвестен ни объём ОЗУ, ни версия ПЗУ, и даже карта УВВ
может отличаться. Я не говорю уже про "Микрошу" и др. - на незнакомом компьютере всё
может отличаться.
barsik wrote:
И даже в Вашем "абстрактно-вакуумном" случае, кто мешает проверить, что с 0 есть ОЗУ. Это усложнит, но всё-равно будет на порядок проще, чем городить огород с поиском сигнатур и последующей коррекцией.
Случай у нас был конкретный, условия его прописаны четко, в рамках заданных условий мы нашли
реально работающее решение
, которое действительно не требует никаких особых сведений о системе.

А вот по каким Вашим "абстрактно-вакуумным" соображениям Вы решили наше успешное решение обхезать:
barsik wrote:
Нет, вы вовсе не решили задачу как делать перемещаемые программы для КР580,
а вот Е.Седов действительно её решил, причём ещё в начале 90-тых
.
вот этот Ваш "абстрактно-вакуумный" вброс сюда мне совершенно не понятен... :osad:

И чтобы прекратить непонятное мне многословие, затеянное barsik-ом, расставлю точки над i .

1. Поскольку 8080 не имеет относительной адресации, и команды передачи управления в своём большинстве
используют абсолютный адрес, - программы 8080 непереносимы, и чтобы стать переносимыми требуют специальных решений.

2. Каким бы ни было решение по формированию переносимой программ под 8080, оно требует получения
хотя бы один раз абсолютного адреса, указывающего в известную точку в коде этой программы
.
Других вариантов не предложил пока никто.

3. Большинство компьютеров под управлением 8080 могут выполнить код одной и той же программы,
но в каждом отдельном компьютере может отличаться карта памяти, прошивка ПЗУ, карта УВВ и т.п.
Если нет описания на конкретный компьютер - все эти данные конкретному пользователю недоступны,
а в большинстве случаев такие подробности и не нужны.

В топике ЗОДАЧА для 580ВМ80:) мы нашли способ, позволяющий получить необходимый абсолютный адрес
без привязок к конкретике системы на 8080
, которая в общем случае может быть неизвестна.
Это решение абсолютно работоспособно, но мы никому не отказали в праве сделать лучше.

Конкретные способы формирования переносимых программ, когда абсолютный адрес известен,
мы не обсуждали. В 2011 году эти способы были известны и без нашего участия.

Так что, если г-н barsik хочет предложить что-то выдающееся своё, - никто не запрещает.
Только я что-то ничего конкретного не заметил, кроме постоянных отсылок на Е.Седова,
который получает искомое значение абсолютного адреса из подпрограммы в ПЗУ.
Ну а наш метод нахождения абсолютного адреса - успешно обходится без этого.

_________________
iLavr


07 May 2018 15:40
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 246
Location: Россия
Reply with quote
Post 
Появился небольшой опыт в написании программ для КР580 для систем без DOS CP/M на Паскале МТ+. Этот Паскаль написан в 1978...1980 году, причём не одним человеком (как было с Си Aztec и BDS, которые написали частники), а фирмой, т.е сразу многими программистами. Потому уровень этого Паскаля высокий. К сожалению, разработчики стремились совместиться со стандартом Паскаля того времени, потому на 95% реализован классический Паскаль, описанный в документах Н.Вирта.

Для сравнения Турбо-Паскаль появившийся 5 лет спустя, ввёл много мелких полезных доработок, нестандартных, но упрощающих программирование (и впоследствии ставших стандартом). Например, в МТ+ нельзя ввести в символьную строку управляющие символы, что без труда делается в TP (например, #13#10'Привет' или ^]^Y#32#32), метки для переходов - только цифровые (как в бейсике), а не символьные, как в TP и других развитых ЯВУ, узнать адрес можно только для переменной или процедуры расположенной в том же самом файле (для других модулей это уже не работает). Встроенные инлайн-ассемблер (понимающий HEX-дампы и мнемонику КР580) не допускает меток, что существенно снижает его ценность. Объём и, соответственно, скорость генерируемого кода, как общепризнано, хуже, чем у TP. Есть ещё много других мелких неприятностей. Компиляция длится на порядок дольше, чем в TP. Вообще программирование на этом Паскале очень сильно отличается от программирования в борландовских продуктах на PC и GNU Pascal Compiler в Linux. Но у МТ+ есть неоспоримое преимущество перед Турбо-Паскалем, это линковка модулей и процессор КР580. TP очень хорош, но из-за нелинкующего принципа для медленных ЭВМ он имеет низкую полезность и по сути может считаться игрушкой.

Мне и ранее было известно, что МТ+ генерит менее эффективный код, чем BDS Си, AZtec Си и Турбо-Паскаль. Например, Турбо-Паскаль даёт объём кода примерно в 4 раза больший чем полный аналог написанный на ассемблере. Но тут я специально сравнил МТ+ с асссемблером и объём кода на МТ+ на программах в 300-400 строк Паскаля получился в 7-10 раз больший, чем у аналогов написанных на ассемблере.

Вопреки ожиданиям, при трансляции в эмуляторе эффективность разработки на этом компиляторе не стала на порядок быстрее, чем на ассемблере. Тормозит медленная трансляция в эмуляторе 8-ми разрядки.

Если при программировании на ассемблере при каждой перетрансляции технические потери составляют всего секунду (хлоп по кнопке и можно проверять прогон в эмуляторе), то трансляция в эмуляторе CP/M-компилятором 1000 строк длится 6-8 минут, хотя потерь времени на запуск эмуляторов ОРИОНА или РК86 для проверки нет, т.к и транслируется в эмуляторе ОРИОНА. С реальным дисководом время трансляции - вдвое выше. А для проверки программ для РК86 запускается эмулятор РК86 в эмуляторе ОРИОНА (т.е происходит двойная эмуляция: PC эмулирует ОРИОН, ОРИОН эмулирует РК). А ещё одной причиной тормознутости является то, что за одну итерацию находится и исправляется только одна ошибка, т.к встретив ошибку компилятор останавливается. А ассемблер сразу выдаёт кучу ошибок и их все можно исправить зараз, за одну итерацию.

Улучшить свойства программы на Паскале можно заменив в РК86 процессор на Z80. Это устраняет проблему отсутствия меток в инлайн-ассемблере, т.к у Z80 есть JR-команды. И хотя встроенный в МТ+ инлайн-ассемблер не понимает мнемоники Z80, но можно совместимые команды писать в мнемониках КР580, вставляя вместо JR-команд просто байты. Чтобы не трахаться с набором ассемблерных текстов, удобнее транслировать ассемблерные вставки на Z80 в обычном ассемблере, генерировать дамп и в ассемблерные функции и процедуры в Паскаль-программе вставлять странслированные дампы, а не набирать текст в мнемониках.

К сожалению, похоже Microsoft не написала компилятор Паскаля для КР580/Z80, а только компилятор фортрана. Можно попробовать компилятор фортрана. На нём удобно написать программу рассчёта траектории полёта на Марс, но для написания игр для РК86 он вряд-ли будет удобен, т.к в нём нет указателей, ассемблера и невозможно работать по железу.

Интересно есть-ли кросс-компилятор Паскаля работающий в MSDOS или Windows на PC, выдающий на выходе код для процессора КР580/Z80 ?

Для компьютера Полдин-601 болгары написали компилятор Паскаля в двух версиях - одна в кодах CPU 6800 работает на реале, а вторая в кодах 8086 работает на PC в MSDOS. Если такого компилятора нет, то остаётся только заменять КР580 на 6802 в РК86 или же использовать конвертор Паскаль-программ в программу на Си, а далее транслировать в коды КР580 с помощью кросс-компилятора Си.

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

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

Но в CP/M кроме Си, Паскаля и фортрана есть ещё несколько старых и несколько более новых ЯВУ, являющихся производными от Паскаля. Кстати, от Си ничего производного нет, т.к С++ возник позже, да и похоже мощности 8-ми разрядки для ООП не хватило.

В качестве старых ЯВУ надо упомянуть ЯВУ PL/M и PL/1. Первый очень близок к ассемблеру и считается, что как ЯВУ он не очень мощный (хотя до появления компиляторов Паскаля в конце 70-тых, был популярен). Более древний PL/1 немного похож и на PL/M и на Паскаль и скорее всего вполне подойдёт для разработки ПО для РК86. Его компилятор для КР580 выглядит солиднее, чем компилятор PL/M. Есть ещё несколько CP/M-компиляторов АДА для КР580. Это язык производный от Паскаля и, очень похоже, что его тоже вполне можно использовать, т.к он имеет встроенный ассемблер. Есть и кросс-компиляторы языков АДА и ОБЕРОН, но они тоже, увы, лишь для Z80.


Last edited by barsik on 06 Nov 2018 23:03, edited 2 times in total.



27 Oct 2018 08:15
Profile
Admin
User avatar

Joined: 09 Jan 2003 00:22
Posts: 17116
Location: Colorado
Reply with quote
Давайте без наездов...

_________________
:eugeek: https://twitter.com/Shaos1973


29 Oct 2018 21:47
Profile WWW
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Post Re:
barsik wrote:
Интересно есть-ли кросс-компилятор Паскаля работающий в MSDOS или Windows на PC, выдающий на выходе код для процессора КР580/Z80 ?

Есть такой, и похоже, что даже не один, если хорошо поискать...
Скачал чисто для проверки, не битая ли ссылка:
Attachment:
Pascal.gif
Pascal.gif [ 7.8 KiB | Viewed 463 times ]

Но поскольку мне он не нужен, то удалю...

_________________
iLavr


31 Oct 2018 06:05
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 246
Location: Россия
Reply with quote
Post 
Lavr wrote:
есть под Микрошей отладчик DDT - он запускался с адреса 100Н, что тогда было странно, т.к. в основном программы грузились с 0. Я поковырял DDT и выяснил, что ниже 100Н, он формирует при старте некую структуру, где есть переходы на системные подпрограммы ПЗУ. Интересно, что этот отладчик DDT понимал коды Z80, хотя и был в софте для Микроши.
Если бы программисты для Микроши читали журнал МПСС, то им бы не потребовалось адаптировать DDT CP/M. Это сделали задолго до этого разработчики ИРИШИ и очистив DDT от ненужных дисковых функций, доработали его и опубликовали в журнале МПСС в 1986 году. Насчёт кодов Z80 в DDT. Видимо речь о ZDDT, это универсальная версия DDT, что работает на КР580.

Раз этот DDT был с адреса 100, значит это вообще неадаптированный DDT. Мне среди ПО РК попадались лишь уже адаптированные версии DDT (уже перемещённые под вершину ОЗУ). В оригинальном DDT в его начале стоит процедура переноса кода под вершину TPA по таблице коррекции. Для получения кода DDT работающего в вершине ОЗУ ставят стоп точку (или JMP F86C) в конце процедуры переноса и подставив в адрес 6 значение из ячейки RAMTOP, чтобы задать TPA, делают запуск с адреса 100. После чего код DDT настроенный на адреса берётся из вершины ОЗУ, а для завершения адаптации остаётся в полученном коде, уже настроенном на верхние адреса, найти все CALL 5 для консольных вызовов, и заменить их на CALL F803/F809.

Но можно этого не делать, а использовать код CP/M-программы в оригинале, добавив к ней частичный эмулятор BDOS CP/M. Причём для недисковой программы эмулировать требуется только консольные функции - 1, 2, 6, 9 и 10.

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

Эмулятор функций BDOS перехватывает вызовы из программ командой CALL 5. Для этого на адрес 5 ставится или JMP в эмулятор BDOS размещённый в вершине ОЗУ или размещённый здесь же (если он умещается в адресах 5...FF). Такой программе достаточно эмулировать лишь недисковые функции BDOS CP/M, что позволяет использовать программы CP/M до тех пор пока они не лезут к диску.

Программы полученные из под компиляторов ЯВУ, например Паскаля, являются полноценными CP/M-программами, в которых стандартные фунции READ и WRITE для ввода/вывода на консоль выполняют вызов BDOS по адресу 5. Потому для написания на ЯВУ программ для РК86 работающих без CP/M операторы READ/WRITE непригодны для ввода/вывода и можно использовать только специально созданные процедуры написанные на встроенном ассемблере. Которые очень просты, т.к они делают только вызов стандартных подпрограмм ПЗУ F803 и F809.

Хотя использование собственных процедур ввода/вывода быстрее и удобнее, но начинающему изучение Паскаля всё-же желательно, чтобы все операторы работали как в учебнике, чтобы ввод/вывод, по крайней мере на консоль, делался стандартными операторами READ и WRITE.

Чтобы без модификации кода компилятора или переопределения некоторых процедур низкого уровня RUN-тайм библиотеки, работали стандартные операторы READ и WRITE как раз годится эмулятор консольных BDOS-функций. Это простейшая программка размером всего в 256 байт и я ещё в начале 90-тых написал такой эмулятор для адаптации отладчиков. Только я грузил его не в Zero-Page, а под вершину ОЗУ, чтобы можно было отлаживать программы с адреса 0. И этот же код годится для того, чтобы на без-CP/M-ном РК86 или ОРИОНЕ можно было использовать программы написанные на ЯВУ.

Для использования на РК программ созданных для CP/M, в том числе и написанных на Паскале, удобно в свободный участок ПЗУ, например, в адреса F000...F7FF прошить эмулятор консольных функций CP/M (естественно, перетранслировав на соответствующие адреса).

Нижеприведённый простой эмулятор консольных функций BDOS имеет размер всего в 256 байт и позволяет без модификаций использовать все недисковые (и нелезущие в CP/M-BIOS) программы CP/M. Перед стартом CP/M-программ, написанных самостоятельно на ЯВУ или взятых из архивных сайтов CP/M достаточно выполнить инициализацию (при которой формируются JMP-ы в адресах 0000, 0005 и JMP на вход в BDOS в вершине ОЗУ).

Кстати, не все CP/M-программы работают только через BDOS. Есть CP/M-программы, что для ускорения или по иным причинам делают вызовы консольных функций BIOS. Полноценный эмулятор CP/M должен это учитывать. Впрочем, подобный эмулятор полезен только для прогона новых программ написанных на ЯВУ. К сожалению почти все игры CP/M (кроме убогих диалогово-текстовых) рассчитаны на экран шириной в 80 символов, а остальные программы дисковые.

 эмулятор консольных функций BDOS CP/M
Code:

;  Эмулятор консольных функций BDOS CP/M. Может располагаться в Zero-
;  Page CP/M (т.к имеет размер всего в 255 байтов). Этот код в 256 байт
;  просто подставляется в начало бездисководной CP/M-программы, после
;  чего программа должна стартовать с адреса 0 и сможет работать без
;  CP/M. Если Zero-Page нужна для RST, то можно грузить этот BDOS под
;  вершину ОЗУ (на 7500), а удобнее всего прошить в ПЗУ в области F000.
 
       .Z80
       aseg
       ORG     100H
       
MYBDOS  EQU     75F6H

       public  MYBDOS

MCONIN  EQU     0F803H
MCOUT   EQU     0F809H
MSTAT   EQU     0F812H
XF81B   EQU     0F81BH
WBOOT   EQU     0F86CH

STACK   EQU     076D0H

; ----------------------------------------------

LOOP    MACRO   ADDR
       DEC     BC
       LD      A,B
       OR      C
       JP      NZ,ADDR
       ENDM

; ----------------------------------------------

       .phase  0
       JP      OOO
       DS      2
       JP      MYBDOS

OOO:    LD      HL,WBOOT
       LD      (1),HL

       LD      A,0C3H
       LD      (MYBDOS),A
       LD      HL,XBDOS
       LD      (MYBDOS+1),HL

.comment \
       LD      HL,DATA
       LD      DE,MYBDOS
       LD      BC,@LENGTH
@LDIR:  LD      A,(HL)
       LD      (DE),A
       INC     HL
       INC     DE
       LOOP    @LDIR
\
       JP      100H
DATA:

; ----------------------------------------------

;       .dephase
;       .phase  MYBDOS

XBDOS:  LD      HL,0
       ADD     HL,SP
       LD      (TMPSTK),HL

       LD      SP,STACK
       LD      A,C
       OR      A
       JP      Z,0             ; WBOOT ; функция 0 (WARM BOOT)

       CP      12              ; ф.12 номер версии
       JP      NZ,JJJ_01
       LD      A,22H
RETURN:
       defb    21H             ; LD HL,(TMPSTK)
TMPSTK: DS      2
       LD      SP,HL
       LD      L,A
       LD      H,0
       RET

JJJ_01: LD      HL,RETURN
       PUSH    HL

       LD      C,E
       CP      1
       JP      Z,FCONIN        ; F.1 CONIN
       CP      2
       JP      Z,MCOUT         ; F.2 CONOUT
       CP      6
       JP      Z,FUNC_6        ; F.6 direct I/O
       CP      9
       JP      Z,MSGCPM        ; F.9 MSSG
       CP      10
       JP      Z,FRDBUF        ; F.10 RD_BUFF
       CP      11
       JP      NZ,WBOOT
NSTAT:
       PUSH    HL              ; F.11 STATUS
       LD      HL,COUNT
       LD      A,(HL)
       OR      A
       JP      Z,NSTA_2
       DEC     A
       LD      (HL),A
       XOR     A
;       JP      NSTA_3
       POP     HL
       RET

NSTA_2: INC     HL
       LD      A,(HL)
       OR      A
       JP      NZ,NSTA_1
       CALL    XF81B
       INC     A
       JP      Z,NSTA_3
       DEC     A
       LD      (KBDBUF),A
NSTA_1:
       LD      A,255
NSTA_3: POP     HL
       RET

; -------------------------------------------------

MSGCPM:
;       PUSH    HL              ; надо, если MCOUT в компьютере портит регистры
;       PUSH    BC
       EX      DE,HL
MSGLOO: LD      C,(HL)
       LD      A,'$'
       CP      C
;       JP      Z,POP_BH
       RET     Z
       CALL    MCOUT
       INC     HL
       JP      MSGLOO

POP_BH:
;       POP     BC
;       POP     HL
;       RET

; -------------------------------------------------

COUNT:  defb    255
KBDBUF: defb    0               ; должны идти подряд

; -------------------------------------------------

FUNC_6: INC     E
       JP      NZ,MCOUT
       CALL    MSTAT
       RET     Z
       JP      MCONIN

; -------------------------------------------------

FCONIN:
;       PUSH    HL              ; надо, если MCONIN в компьютере портит регистры
;       PUSH    BC
       LD      HL,COUNT
       LD      (HL),255
       INC     HL              ; KBDBUF
       LD      A,(HL)
       OR      A
       JP      NZ,CONI_2
       CALL    MCONIN
CONI_2: CP      3
       JP      Z,0             ; WBOOT
       LD      C,A
       PUSH    AF
       CALL    MCOUT
       POP     AF
;       POP     BC
;       POP     HL
       RET

; -------------------------------------------------

FRDBUF:
       EX      DE,HL
       LD      C,(HL)          ; BUFF SIZE
       LD      B,0
       INC     HL
RDBLOO:
       CALL    MCONIN
       CP      8
       JP      Z,ZABOJ
       PUSH    BC
       LD      C,A
       CALL    MCOUT
       POP     BC
       CP      13
       JP      Z,RDDONE
       CP      10
       JP      Z,RDDONE
       CP      3
       JP      Z,0             ; WBOOT ; CNTRL-C
       INC     HL
       LD      (HL),A
       INC     B
       LD      A,C
       CP      B               ; конец буфера ?
       JP      NZ,RDBLOO
       LD      B,C
RDDONE:
       INC     DE
       EX      DE,HL
       LD      (HL),B
       RET

; -------------------------------------------------

ZABOJ:  LD      A,B
       OR      A
       JP      Z,RDBLOO
       DEC     B
       DEC     HL
       PUSH    BC
       LD      C,8
       CALL    MCOUT
       LD      C,20H
       CALL    MCOUT
       LD      C,8
       CALL    MCOUT
       POP     BC
       JP      RDBLOO

; -------------------------------------------------

@ENDBDOS        EQU     $

BDSIZE  EQU     $-MYBDOS
@LENGTH EQU     $-MYBDOS

@FREE   EQU     7600H-$
       
       .dephase

if      low $ and 7FH
       rept    80H-(low $ and 7FH)
       defb    255
       ENDM
endif

       END



06 Nov 2018 03:42
Profile
Maniac
User avatar

Joined: 19 Feb 2017 04:46
Posts: 246
Location: Россия
Reply with quote
Post 
Lavr wrote:
barsik wrote:
Интересно есть-ли кросс-компилятор Паскаля работающий в MSDOS или Windows на PC, выдающий на выходе код для процессора КР580/Z80 ?
Есть такой, и похоже, что даже не один, если хорошо поискать...
Сомневаюсь. Для КР580 нет, т.к похоже, что КР580 вне России мало популярен. И даже для Z80 изображённое на картинке IDE скорее всего полуфабрикатное демо или монтаж. Возможно для Z80 пригодные кросс-Паскаль-IDE всё-же есть, но платные (есть кросс-компиляторы Паскаля для AVR и ПЛИС, а изменить целевую платформу разработчику нетрудно). Иначе на всех подобных форумах не было бы таких же вопросов и попыток сделать их самому.

Конечно интегрированная среда ускоряет разработку. А пока, если используется Win XP (что позволяет запуск MSDOS программ), то используя MSDOS TSR-эмулятор CP/M и Паскаль МТ+, потери времени на компиляцию снижаются почти до нуля, а имеющийся в нём отладчик, хотя и не так удобен как встроенный в IDE, но тоже упрощает отладку. Так что эффективность разработки, относительно разработки в среде кросс-IDE, страдает не существенно.
barsik wrote:
не могу разобраться как в ассемблерных вставках задавать адреса в командах переходов (а ассемблер без переходов почти бесполезен)
Наконец-то и эта неприятная проблема успешно разрешилась. Совсем идеально с ассемблером было бы, если бы встроенный инлайн-ассемблер использовал мнемоники Z80 вместо устаревших мнемоник КР580... но всё идеально бывает только в мечтах.

Освоение Паскаля начинающим, особенно после бейсика, по сравнению с освоением Си, происходит намного легче и быстрее. Сужу по себе, в начале 90-тых пытался освоить Си, но не преуспел за много месяцев. Тогда как бейсик-компилятор был освоен мгновенно. После чего и Турбо-Паскаль был освоен всего за две недели. Позднее, я больше имел дело с Си, но как раз потому, что Паскаль (но не МТ) был моим первым ЯВУ, отношусь к нему с симпатией.

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

Классический Си ближе к железу, в нём удобнее работа с указателями, тогда как в классическом Паскале из 70-тых указатели используются в основном для работы с динамическим объектами (позже в TP работу указателей улучшили). В Си нет строгой несовместимости похожих типов, как в Паскале, что защищает от ошибок, но снижает гибкость. Правда указатели в режиме ослабленного контроля, а тем более встроенный ассемблер позволяют обойти все строгости Паскаля, но это "химия".

Особенно утомляет несовместимость числовых типов с boolean (и true это не любое, отличное от 0, число, а именно 1). Потому нельзя, как в BDS C, в качестве условия в условных операторах написать числовое выражение или даже просто переменную. Вопреки нижеследующей цитате, где написано, что МТ+ лучше, чем BDS С, в отличие от МТ+, с BDS у меня вообще не было проблем, даже ассемблер для трюков был не нужен (хотя возможно мне просто не встретились упомянутые ниже глюки BDS C).
Quote:
Although by now largely forgotten, Pascal/MT+ was in its day a highly influential product... By 1983 there were more books available on Pascal/MT+ than on all the other Pascal compilers combined... if you wanted to program your CP/M system in C in the late 70's, you had a choice of either wasting your life on endless disk swaps, opening and closing editors, compilers and linkers or other utilities or you wasting your life writing around the seemingly endless incompatibilities and bugs the BDS C system offered. This was one of the things that drove people from C and to... compilers such as Pascal on small microcomputer systems...

Initially a Pascal subset, Pascal/MT leveraged the fact that it was much easier to write a compiler for the highly structured Pascal language than it was for the unstructured C or classic languages like Fortran, in addition to the fact that Pascal is a much smaller language. Written in assembly language it performed the same trick as BDS C of actually performing the compilation inside available memory and unlike the BDS product, the Pascal/MT system was relatively bug free, the documentation was clear and concise, and the company did actively develop upgrades and bug fixes. The compiler also had a built in linker that automatically linked the object code when you compiled, a novelty at the time, had a symbolic debugger, editor and offered overlay support, whereby the compiled executable only loaded into memory the portion of the code that was needed at as each segment of the program runs.
Паскаль господствовал в программировании почти до конца 80-тых, но как пишут, не столько из-за превосходства Си, сколько из-за того, что Unix и Си поставлялись в университеты бесплатно, проиграл в конкуренции с Си. Как только в промышленность пришли бывшие студенты обучавшиеся на Unix и Си, Паскаль был обречён и даже незаслуженно стал презираемым, почти как бейсик.


09 Nov 2018 01:09
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 37 posts ]  Go to page Previous  1, 2, 3

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.