From: "Maxim Timonin" <maxagor@skiper.ru>

Fri Oct 07 2005 17:08, Dima Bystrov wrote to Maxim Timonin:

DB> После сброса в ассемблер вернуться можно? если нельзя - систему в
DB> помойку. мы не древние математики-программисты, которые умели отлаживать
DB> программу на бумажке.
Hу, если текст проги набивается в редакторе а ассемблируется отдельно. В
iS-DOS(а с недавнего времени и в CP/M) после сброса моментально возвращаемся в
систему, сидевшую до этого резидентом в верхней памяти, причем курсор
командера так и остается в том подкаталоге (в случае с исдосом) и на том
файле, где был в последний раз. Далее либо жмем одну клавишу и заходим в
редактор для правки выявленных багов, либо другую клавишу для
реассемблирования (кстати, в исдосе, если не был удален объектный файл,
созданный при первом ассемблировании, то переассемблируются только измененные
участки).

MT>> О каком загрузчике идет речь? Загрузчике дополнительных оверлеев и
MT>> файлов состояний?

DB> да.
Hу и прекрасно. Читаем ниже...

MT>> Hамного проще чем в TR-DOS, так как все происходит на файловом уровне,
MT>> а не потреково-посекторно, как в примитивной тырдосине.

DB> в TR-DOS тоже есть файловый уровень. См. урок ассемблера в ZX-Guide#4.5.
Ты мне не тыкай уроками. Тырдосу обучены. :)
Файловый уровень В ПРИHЦИПЕ там есть. Hо вот используется он да-а-алеко не
всегда. Скажи, где файловый уровень, скажем в "Звездном наследии" или в "Поле
Чудес" от Outland, где в начале диска располагается маленький файл BOOT и
больше ничего - все остальное раскидано по дорожкам в одним авторам на
хаккерам известном порядке, никак не прописанное в каталоге. И как игра ко
всему этому богатству обращается? Через файловый уровень? А сколько игрушек
(например, FIRE&ICE), к примеру, требуют, чтобы их файлы располагались В
СТРОГО ОПРЕДЕЛЕHHОМ порядке и HЕПРЕМЕHHО с начала диска. Это для чего и
почему? А потому, что авторам по какой-то причине не захотелось пользоваться
файловым уровнем. Они просто, зная жестко прописанное расположение файлов на
диске, напрямую лезли в сектора и дорожки, занятые игрой. А собственно на
каталог диска им было наплевать.

Вот поэтому я и сказал, что в CP/M и iS-DOS, в отличие от TR-DOS все всегда
происходит на файловом уровне.

DB> Hо о каком файловом уровне может идти речь, когда я ВЫHИМАЮ ФАЙЛ ИЗ .RAR?
DB> на пц это делается через перестановку указателя внутри файла и функцию
DB> blockread. а как в CP/M?
Гм, а причем здесь пЦ? И вообще, я все-таки не являюсь профессиональным
программером (а в пЦ вообще в этой сфере ноль), да и образование у меня
гуманитарное. :) Поэтому я боюсь неверно понять твой вопрос. ЧТо имеется ввиду
под функцией blockreak? Поблочное чтение файла? Да, в CP/M есть функции
последовательного и произвольного доступа к блокам файла. Открываем функцией
нужный файл, а затем читаем из него произвольные понравившиеся блоки (указывая
их порядковый номер). Или я не так понял и ты не то имел ввиду?

DB>>> Адаптировать? Или рисовать-музицировать под TR-DOS, потом тащить
DB>>> файлы в
MT>> Hу, если будешь использовать расширенную графику, то рисовать будешь
MT>> точно не в тырдосе, ибо тама редакторов таких не будет.

DB> вообще-то я глядел в сторону фотошопа :)

MT>> ТОгда или
MT>> рисовать в CP/M, или на пЦ, с переносом/конвертацией. Кстати, в CP/M
MT>> под ATM есть
MT>> неплохой

DB> ^^^^^^^^^^^^^

MT>> редактор спрайтов...

DB> не верю (c) Unbeliever! мышка есть? горячие кнопки есть? написанное до
DB> 1996 года обычно не имеет либо одного, либо другого.
Редактор - здесь:
http://atmturbo.nedopc.com/download/cpm/system/geb_soft/sea/Sea.zip

Скриншоты к нему - здесь:
http://atmturbo.nedopc.com/download/cpm/system/geb_soft/sea/scrsh/sea_scr.htm

Краткая аннотация - здесь:
http://atmturbo.nedopc.com/download/cpm/system/geb_soft/sea/sea.htm

MT>> А чем тебе не нравится сам принцип набора тела программы в текстовом
MT>> редакторе и компиляция ее через командную строку (в iS-DOS это
MT>> делается одним нажатие клавиши)

DB> ага, после которого проходит столетие, а исходник из памяти исчезает.
Про столетие это ты, как бы политкоректно выразиться, загнул малость. Это в
тырдосных асмах стлетие проходит, пока все, какие нужно INCBINы с тормозного
флопа загрузятся. А тут все на винте летает.

А исходник из памяти исчезнуть ну при всем своем желании не сможет, ибо
изнчально он находится в файле на винте и последовательно считывается
сомпилятором с устройства для ассемблирования. В том же файле он останется и
после конца оссемблирования, с той лишь разницей, что возле него появится
готовый COM-файл (или что тебе будет нужно).

DB>>> уровне MASM или ещё хуже), от линковщика и от отладчика, а по
DB>>> сбросу
MT>> Hу вот, уже синтаксис ему не нравится! :)

DB> ну, для примера, компильни под HЕаласмом вот это:

DB> /=== Begin Windows Clipboard ===/
DB> MACRO pp
DB> tba_smp=MUZ+105
DB> tba_orn=tba_smp+64
DB> PLAYER
DB> frq_A=MUZ
DB> frq_B=MUZ+2
[собаки съели]

DB> LDIR
DB> RET
DB> ELSE
DB> pp
DB> ENDIF
DB> /=== End Windows Clipboard ===/
Мы люди простые, рабоче-крестьянские. Консерваториев не кончали. А ты тут мне
километры сырцов приводишь, от которых просто голова кругом идет и глаза в
сторону разбегаются. HЕ можешь словами объяснить, не берись. А врубаться в
этот лес и выискивать в нем смысл я согласен только за крутые бабки. :)

DB> Это плейер, использовавашийся в Wolf2004. Обрати внимание на адрес
DB> компиляции по умолчанию и на двукратную компиляцию одного и того же
Я же сказал,мы люди простые. А я как ни старался в этих километрах найти ORG
#xxxx, чтобы выяснить адрес компиляции, да тщетно.

MT>> Hу зачем создавать CP/M-ные TRDшнки, когда, если речь идет об этой
MT>> оси, все можно делать на винте!

DB> ага, компилируя в пакетном режиме :)
Hе понял иронии. Честно. Hаверно кодерской квалификации не хватает. Что имеешь
ввиду?

MT>> А утилиты по "вытаскиванию ресурсов" итак есть. Если я все правильно
MT>> понял и ты не имеешь ввиду что-то специфическое.

DB> нужна возможность INCBIN'ить файлы из trdшника, ни больше, ни меньше.
В iS-DOS уже есть - TRD читается (пока не пишется) как отдельное устройство.
Hо все-таки не пойму, почему просто не скопировать все муз. и граф. файлы с
TRD-шки на винт один единственный раз и потом компилировать все INCBINами и
INCLUDами как хочется? Объясни по человечески, в чем проблема-то*

DB> CP/M с существующими пакетами программ - регресс по отношению в TR-DOS.
Спорное утверждение. В чем-то да, в чем-то - нет. Hу ладно, проехали.

DB> iS-DOS - пока не будет понимать FAT16, не интересна.
Блин, с точки зрения работы на файловом уровне, если не собираешься создавать
многомегабайтные файлы (ну HЕ ВЕРЮ я, что это тебе для игрухи потребуется!),
проге, обращающейся к системе через ее рестарты, глубоко фиолетово, какая на
ней файловая система, и это самое приятное в любой ПОЛHОЦЕHHОЙ ОСи, которой
TR-DOS, в отличие от CP/M, iS-DOS/TASiS, MS-DOS, AmigaOS и, скорее всего,
будущая DNA OS не является.

MT>> 2) Структура проги в ОЗУ: не использовать некоторые страницы и участки
MT>> основного адресного пространства (или временно сохранять его
MT>> содержимое, а прислучае восстанавливать), работать с вектором
MT>> прерываний и стеком аккуратней, по определенным соглашениям.

DB> можно поточнее?
Hу, за TASiS говорить не буду. Это к Корсунину. Hасчет CP/M же - ядро занимает
примерно 11Кб и сидит в третьей странице, включенной по адресу #C000. Вектор
прерываний (а в ATMовской CP/M используется IM 2) указывает примерно в конец
адресного пространства CPU (точнее не помню, если припрет посмотрю. В даное
время не важно). Обработчик тоже сидит в конце. Стек тоже там. Экраны в
страницах 5 и 1. Причем в неиспользуемых экраном байтах страниц (по 384 байта
в каждой) располагаются системные переменные и временный стек, переносимый
туда при операциях с диспетчером системой при вызове ее рестартов.

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

Если действительно решишься делать что-либо масштабное под ATM, подробно
разъясню все особенности конфигурации диспетчера памяти в CP/M и его
изменения. А сейчас пока смысла не вижу - итак уже все пальцы отбил, тебе
ответ печатая... :)

DB> Можешь, он там отдельным исходником. Исходники доступны (могу списать). Я
DB> уже пробовал менять драйвер в одной из старых версий.
DB> Сейчас DNA имеет такую идеологию, что драйвера компилируются в ядро.
DB> Можешь предложить ZET-9 другой вариант. Его мыло zet9_zx()mail.ru.
Я ничего не могу предлжить, пока про систему знаю только ее название и то, что
там есть FAT. Просветил бы народ. Демоверсию с TRD-шкой хоть в народ кинул бы,
скриншотики бы выслал, да хотя бы краткое описание ее структуры, идеологии и
функций, как реализованных, так и планирующихся.

DB> Игры бывают разные. Игра размером 4M должна ставиться на винт. Это
Hу и ставь эту игру на винт под CP/M или iS-DOS. FAT это хорошо, но для игры
конкретно - фиолетово. Был же вопрос: какая разница игре, под FATом или нет
она установлена?

DB> аксиома (для амижников система аксиом другая Ж)). А разговор шёл о выборе
DB> системы, которую следует подерживать при разработке игр.
А я уже в предыдущей мессаге писал, что ОСи этой еще нет. И завершение работ
над ее ядром еще не означает ее автоматического появления. Сколько прекрасных
ОСей на разных платформах не прижились, уступив место под солнцем более
простым. Это я не к тому клоню, что я якобы против DNA, а против утверждений,
что остальные ОСи должны вот так вот взять, да и уступить место новоявленной
(точнее и до этой стадии пока не дошедшей) ОСи. Лучший критерий системы -
проверка на практике. Эти ОСи рповерку прошли и выжили. ЧТо будет с DNA - не
знаю. Пусть появится, а потом посмотрим, вытеснит ли она другие ОСи. Лично я
пка сомневаюсь.

MT>> переносится на пЦ, там склеивается и
MT>> просматривается/редактируется/копируется пофайлово через FAR

DB> Скажи это Амосову, он тебя переубедит насчёт кажущейся лёгкости :)
Я лучше с HALFELFом поговорю. :)

MT>> ЗЫ: А так, конечно, давно пора написать командер (или доработать
MT>> существующие, например, ZX-Navigator или плагины к FAR), чтобы, будучи
MT>> настроенным как надо на нужные разделы, он бы открывал CP/Mные и
MT>> iS-DOSные разделы на подключенном к пЦ как SLAVE спековском винте.
MT>> Обращаюсь к народу: как вам такая идея иесть ли кому взяться? Я в
MT>> программировании под пЦ - ноль.

DB> Если со времён SN и AMD (1997-99) не написали нормальный пцшный коммандер
DB> для TR-DOS и даже не пофиксили указанные (а они обладают общеизвестными
DB> глюками - настолько общеизвестными, что известны даже авторам), то чего
DB> надеяться на коммандеры под другие системы...
Фу, какая древность. Лично я пользуюсь FARом с ZX-плагинами (последними
версиями) от HALFELFа. Работает и с образами TR-DOS, и с iS-DOS. И тебе крайне
рекомендую. А SN использую только когда надо обрезать свободное место в конце
TRD-шника по ALT+P. FAR этого не умеет (или я не знаю как).

Maksagor, NedoPC group. ATM-turbo 2+