ОРИОН - Флейм. "Бойцы вспоминают минувшие дни..."

[barsik]

Из CP/M можно просто сделать RET. При этом программа попадет на подпрограмму WARM START CP/M

Нет, не так. Всё зависит откуда программу запустили. Если её запустили из CCP CP/M, то программа и вернётся в CCP CP/M (без переподкачки кода BDOS, и это свойство используется). CCP CP/M перед запуском программы, загруженной на 100H, делает PUSH 'адреса возврата в себя' и затем делает JP 100H. Поэтому программы, которые затирают CCP обязательно должны выходить по RST 0.

Все фирменные оболочки запускающие другие программы, в стек загоняют адрес 0000, т.к при них в ОЗУ обычно уже нет CCP, он затёрт дисковыми буферами или самой программой. Поэтому вернуться в CCP CP/M из программы, запущенной из оболочки, уже нельзя. Поэтому и имитируется CALL из 0000, где стоит JP WBOOT. Однако есть программы отечественных дилетантов, которые при старте программ в стек ничего не загоняют. Отчего по RET возвращаться нельзя.

Обычно RET делают только фирменные программы из 70-х, которые знают, как долго грузить BDOS с перфоленты. А сложные программы, т.к они обычно затирают CCP, чтобы использовать всё TPA, при выходе делают JP 0000 (более грамотные делают RST 0).

некрасивые вызовы в середину кода Монитора в EXT-Z

Это же Ваше изобретение - перетранслировать M3-EXT так чтобы вызовы в нём совпадали с конкретной не придерживающейся стандарта перетрансляцией М3 для Z80. Впрочем, и до вас в 1992 находились такие же лентяи. Кому трудно было переставить куски кода внутри транслируемого ими ПЗУ М3, чтобы обеспечить совместимость со стандартным М3-EXT образца 1991 года.

Я-же, делая М3-EXT для Z80 (хотя EXT-Z-ом это не называется, просто очередная версия M3-EXT) просто перенёс 3 десятка байтов кода из М3 в версию M3-EXT для Z80, что сделало M3-EXT независимым от версий M3. Но тем не менее и много лет после этого во всех версиях М3 сохранял все внутренние точки M3.1, на которые опирается M3-EXT для КР580 из 1991 года.

И "залезание" из М3 внутрь M3-EXT это вовсе не "атавизм", а всё сделано правильно. Т.к М3 и его EXT - это одна программа и "залезание" происходит не в стороннюю программу, а программа "лезет сама в себя". Ведь EXT без M3 не работает. И перед тем как "залезать" он проверяет М3. Отказ от бесполезного дублирования 6-ти подпрограмм и позволил ввести в М3-EXT так много (например он заменяет CH$ и CH-RK$ одновременно и позволяет грузить блоки по произвольным адресам с автонастройкой на скорость, а с дополнительным блоком грузит форматы ZX-Spectrum, MSX и СПЕЦИАЛИСТ, с именем и без).

Перетранслировать M3-EXT для каждой нестандартной версии M3 - это чушь. У меня 50 версий М3, - мне что же, - надо иметь 50 штук разных M3-EXT? Перетранслировать - дело секунд, но это же идиотизм. Поэтому-то я и придерживаюсь один раз принятой концепции и совмещаю входы в М3, хотя использую М3-EXT независимый от кода М3. Но, если я возьму древний M3-EXT 1.0 для КР580, то он сработает на любом моём М3, причём даже на таком, который и так содержит в себе полный M3-EXT (4-х килобайтный ROM), т.е и он позволяет иметь внешние директивы.

Совмещать внутренние точки М3 несложно потому что в коде много маленьких подпрограмм. Достаточно подписать длину каждой подпрограммы, переместив сначала все короткие подпрограммы в конец. После чего за 2-3 итерации, выполняемой для каждой неперемещаемой внутренней точки, достигается версия М3, совместимая с М3.1 1991 года. Если надо в ПЗУ, что-то изменить, отчего последующий код сдвигается, то настройку по совмещению точек приходится повторять. Это отнимает время, но это плата за совместимость. Поэтому, кто видел листинги М3 знает, что там полно вот таких кусков для отслеживания сдвигов.

...
	JR	@WARMST      ; обходной JMP

	JP	INILOC       ; вот он - на 3 байта раньше, полюбуйтесь !
@WARMST:
if	@WARMST ne 0F86CH
	if1
	.printx '.     WARM START address shifted !'
	endif
endif
	LD      SP, STACK

Этот кусок я привёл специально, чтобы показать не только, как отслеживаются внутренние точки, но и с целью показать ещё одно свойство М3. А именно вход инициализации. Этого очень на хватало в мониторах. Например, запуская игру из CP/M нам надо иметь чистые вектора ROM-BIOS (куда часто загружают драйвера, хотя в ACP/M есть свои векторы для загрузки). Вектора ROM-BIOS для загрузки драйверов используют иногда потому, что тогда драйвер становится универсальным - годится как для ORDOS, так и для всех версий ДОС (это куча вариантов CP/M и 3-4 других ДОС) ). Но при попытке стартануть программу (например игру) на ОРИОНЕ с "нечистыми" векторами происходит улёт.

В ROM-BIOS нет средства освободить вектора, сделав инициализацию. Грамотные программы ОРИОНА, если их запустить с "нечистыми" векторами, сами восстанавливают вектора ROM-BIOS. Для этого используется EXT$-трюк ORDOS.

Программа желающая очистить вектора, делает следующее. Она кидает в квазидиск ORDOS маленький ORDOS-файл с именем EXT$, и делает JP F800. Отчего вектора ПЗУ инициализируются, а при старте ORDOS происходит автозапуск файла EXT$, который состоит из команды перехода (возврата) в исходную программу загруженную в банку 0. После чего эта программа может спокойно начинать работу и пользоваться стандартными входами ПЗУ.

Поэтому в большинстве М3 (но не во всех) после 1995 есть вход инициализации ROM-BIOS. Для чего вводится подпрограмма INILOC. Она ничего особо умного не делает, а лишь копирует блок начальных констант на адрес F3C3. Чтобы адрес этой подпрограммы был фиксирован, используется адрес за 3 байта до горячего старта (раз уж его надо фиксировать при перетрансляциях, то автоматически фиксируется и вход INILOC). Это ещё одно свойство (не фича) МОНИТОРА-3, - ценой в 3 байта мы устранили фатальный недостаток М2. Кстати, номера меток начинаются с "собаки" (@) специально, т.к такие метки выводятся в списке меток в листинге трансляции первыми (искать одну метку среди тысячи - долго).

А, что касается пригодности для программиста M128/256$, то пока в нём что-то сделаешь, с командной строки можно исполнить 10 команд. И я с интересом посмотрю, как Вы Denn с помощью M128$ будете перекидывать "пол банки 3 в пол банки 2", ведь на практике подобные задачи требуются очень часто.

Фактически по коду всех ПЗУ вход WARM BOOT есть, а в документации ОРИОНА - нет

Значит это "тайный вход", только для посвящённых... А серъёзно, думаю что авторы могли забыть, но скорее всего, хотели сознательно скрыть от народа правду (чтоб затруднить разработку конкурирующего ПО). А вообще такой вход очень нужен.

Представьте, что я загрузил драйвер, а затем вынужден был удалить его с квазидиска (не хватало места). Если я сделаю COLD START, как советует HardWareMan, то я потеряю драйвер и мне придётся его снова грузить с МГ-ленты. Да, даже, если драйвер прошит в ROM-диске, то меня всё-равно сильно утомит всякий раз, закончив редактирование или трансляцию, снова загружать драйвер (например больших букв, чтобы экономить зрение). Именно для этих целей и вводят в системы подобные входы.

Другая ситуация. Используя EXT-Z изготовленный error404 и его же ROM-BIOS на базе подпрограмм из M3, я "с увлечением" работаю в ORDOS (интересно, что я там делаю?). И если выход из какой-либо используемой мной программы будет неверным, - не на стандартный WARM BOOT монитора, то по выходе стартанёт встроенный в ROM F800 загрузчик с НГМД и затрёт все мои квазидиски ORDOS и навсегда погибнут 100 кило исходников, которые я разрабатывал 2 месяца.

Именно поэтому, выходить всегда надо на WARM BOOT, а не на COLD START. А лучше делать, как делаю я. Проверяем стоит ли в ПЗУ М3. Если есть, то уходим на CCP M3 (F8B6), что сохраняет экран. Если нет, т.е когда это М1, М2 или М4, то уходим на WARM BOOT.

На СПЕЦИАЛИСТЕ у меня не было забот с выходом из программ - JMP C800 и всё!

Так это Вы обидели меня, бедного сельского жителя из глубинки России. Правильно было бы - JMP C000, что не обижает тех, у кого всего одно ПЗУ в панельке СПЕЦИАЛИСТА.

На Орионе если брать авторский софт, близко нет ни нормального ассемблера, сравнимого с М80, (куда уж там до линковщика)

Технически согласен, но факты "упрямая вещь". Вы забыли про пакет "Oberon Assembler Kit" - ORDOS макро ассемблер с линковщиком, библиотекарем и экранным (!) отладчиком (А.Вакуленко, Киев, 1995). А так же графическая библитека OWL 2.0 (Oberon Windows Library) для всего этого. Что позволяет просто и быстро делать не только красивые, но и даже самые большие по объёму программы. К сожалению, у меня ничего от А.Вакуленко не сохранилось после "краха винта 2000", кроме его MSX-бейсика для Z80 с описанием и демо-программами.

Кстати, именно А.Вакуленко написал первый в стране эмулятор ОРИОНА на КР580 (1996) на СИ. Я написал свой эмулятор ОРИОНА на КР580 только в 1998 (в 1999 для Z80), причём не на СИ, а на ассемблере.