Просмотр полной версии : Конструктор (ZX SDK)
CityAceE
30.11.2005, 08:33
Раньше на Спектруме я сталкивался с такой проблемой, что когда в голову приходила какая-то идея, то основную часть времени для её проверки тратилась на обвязку программы, интерфейс и т.д. У каждого автора нарабатывалась какая-то библиотека процедур, алгоритмов, заготовок и т.д., которыми автор пользовался при написании своих программ. На память сразу приходят программы Сергея Ханциса (кстати, не так давно Сергей зарегистрировался на этом форуме) Screen Manager и другие, названия которых я запамятовал. Программы Сергея были полезны, удобны и при этом внешне похожи между собой (как собственно и подавляющее большинство программ, написанных под Windows) из-за того, что в каждой своей программе автор использовал свои библиотеки процедур. Вспоминая график выхода программ Сергея, я предполагаю, что на написание каждой последующей программы у её автора уходило меньше времени, так как процедуры интерфейса были написаны и отлажены, а автор бросал свои главные усилия не на организацию интерфейса, а на логику работы самой программы. Помню потом в электронных изданиях были призывы делиться своими процедурами и создать некий банк таких процедур. Как я понимаю, эта идея по ряду причин так и не получила большого развития и заглохла. Позже я попробовал программировать на ассемблере под PalmOS. Это был мой первый опыт программирования не на Спектруме и под настоящую операционную систему. На Палме я увидел, что мне нет надобности самому рисовать окна, отслеживать нажатия на кнопки и т.д. - всё это делает за меня операционная система, а мне необходимо лишь вовремя вызвать нужные процедуры с требуемыми параметрами. Что и говорить - удобно! Как я понимаю, именно такой подход к программированию осуществляется в любой полноценной операционной системе. Похожую идеологию я увидел и в Aqua/Doors на Спектруме. Мне очень понравилось грамотное описание самой системы и её элементов на домашней страничке Aqua/Doors. Подозреваю, что и другие операционные системы, которые писались, пишутся или ещё только будут писаться используют аналогичные методы. Но так уж получается, что как и прежде у нас TR-DOS является тем стандартом, который уже вряд ли удастся свергнуть. И поэтому, как и прежде, каждый автор продолжает заново изобретать велосипед, начиная писать ту или иную программу. Многие идеи так и не воплощаются в законченную программу, оседая на дискетах в виде исходников, так как их авторы не желают связываться с написанием интерфейса и другими трудностями программирования оболочки. С другой стороны есть и такая категория людей, которые может быть и хотели что-то написать под Спектрум, но их пугает ассемблер и тот факт, что всё придётся делать самому и с нуля...
А теперь я помечтаю...
"Я включаю свой Скорпион и вставляю в него дискету подписанную как ZX_SDK, а рядом с собой кладу стопку отпечатанных листов, имеющих аналогичный заголовок. Так-с... Ну что ж, сегодня пожалуй для разминки напишу текстовый вьювер... Итак, приступим... Грузим с дискетки ALASM... Так, готово.. Ну-ка, где тут у нас файлик MAIN.H? Есть, загрузили... Ага, вот в файлике и список инклудов... Так, в нашей программе клавиатуру опрашивать будем, так что INCLUDE "KEYS.H", оставляем, а вот работа со спрайтами сегодня не предвидится, так что строчку INCLUDE "SPRITES.H" прячем точкой с запятой, или нет, лучше сотрём, сэкономив место в исходнике. А для вывода текста мы будем использовать 64 и 40 символов в строке, так что INCLUDE "TEXT64" и INCLUDE "TEXT40" оставляем... Смотрим дальше... [ПРОШЛО НЕСКОЛЬКО МИНУТ] Ну вот, вроде бы все нужные процедуры отобраны... Перемещаемся ниже по MAIN.H... Ага, стоп, вот он главный цикл программы! Стек, пожалуй, поднимем чуть повыше... Так, с IM2 сегодня не работаем, так что этот блок отделяем точками с запятой... Эти несколько строк тоже удалим, так как в этом проекте они нам не потребуются... А сюда мы вставим вывод окна... Как там у нас называется эта процедура? Ну-ка откроем нашу распечатку... Ага, вот они процедуры отвечающие за вывод окон, а вот и нужная процедура WIN_DRAW с описанием вводных данных... Так, загружаем регистры, вставляем WIN_DRAW... [ПРОШЛО НЕСКОЛЬКО ЧАСОВ] Уф, ну что ж, отладка программы закончена... Идем на начало листинга MAIN.H и меняем кое-какие флаги, чтобы получить готовый проект. Жмём "А", ждём минуточку, пока программа откомпилируется, скомпрессируется и к ней будет добавлен BASIC-загрузчик. Ну вот, у нас на диске программа, готовая к распространению..."
Наверное примерно так мог бы выглядеть процесс создания программы, если бы в распоряжении программиста был бы пакет необходимых процедур и заготовок, с подробным описанием и примеры готовых проектов. Безусловно, с таким подходом не добиться оптимальности (фреймовости, компактности и т.д.), но тем не менее такой подход в большинстве случаем оказался бы вполне приемлемым. Возвращаясь к PalmOS, при более мощном процессоре, тем не менее многие популярные программы не стесняются перерисовывать окна и выводить надписи прямо на глазах пользователя. Конечно, для спектрумиста это выглядит несколько непривычно, но я бы лично предпочёл видеть вот такую новую программу на нашей платформе, чем никакую! Кто знает, может быть если бы было создано такое средство разработки, то и программ стало бы выходить больше? А?
Мне кажется, что этот форум - хорошее место для рождения и поддержки подобного проекта. Здесь на форуме присутствует достаточное количество людей, которые написали не одну добротную программу и каждый их них решал множество задач по созданию оболочки программы и т.д. и т.п. Этот опыт очень ценен!
Здесь можно было бы создать список самых востребованных процедур по работе с клавиатурой, мышью, дисководом, жестким диском, памятью, часами, выводом текста, символов, спрайтов, всякого рода окон, кнопочек, чек-боксов и т.д. и т.п. Определиться с наиболее универсальными и удобными методами вызова этих процедур и хорошо их задокументировать. Нужно сделать несколько демонстрационных проектов начиная с "Hello, World!" и заканчивая какой-нибудь простенькой игрушкой типа "Сапёра". Кто-то один будет координатором этого проекта, аккумулировать все процедуры и регулярно обновлять образ диска на этом форуме. Нужно пытаться делать так, чтобы этот конструктор был совместим снизу вверх, то есть чтобы программа написанная под такой "конструктор" версии 1.00, прекрасно компилировалась и работала скажем в версии 1.50. И т.д. и т.п.
Основная идея: Создать здесь на форуме некий конструктор, состоящий из процедур, заготовок и документации, который поможет быстро создавать качественные программы.
Вот мои мысли.
Или моя идея, как обычно будет задушена?
P.S. Если эта идея будет поддержана то можно подумать об организации специального раздела на форуме для удобства ведения этого проекта.
фз.
у меня пока есть чутка времени, поэтому смогу помочь.
однако моё чистое имхо по поводу полезности оставлю при себе.
Поддерживаю идею.
Думаю, что первым шагом в создании подобного банка будет очерчивание границ применимости, как то:
1. Конфигурация компьютера (ZX48; ZX128; S256;...),
2. Модель памяти (SOLID; CODE_IN_LOW_MEMORY_DATA_IN_BANK; CODE_AND_DATA_IN_BANK;...),
3. Доступные внешние устройства (DOESNT_USE_EXTERNAL; FDD; HDD_SCRP; HDD_NEMO; KEMP_MOUSE;...),
4. Зависимости от системных библиотек (DOESNT_USE_SYSTEM; ...),
5. Режимы работы прерываний (INT_MUST_BE_DISABLED; INT_CAN_BE_ANY; HAVE_ISR;...).
Список, естественно, примерный.
Каждая единица (модуль, процедура, библиотека), снабжается метками, указывающими на границы применимости.
Например:
ZX48 SOLID DOESNT_USE_EXTERNAL DOESNT_USE_SYSTEM INT_CAN_BE_ANY - Процедура удовлетворяет требованиям ZX-Spectrum 48, при этом не требует ни внешних устройств, не использует процедуры из ПЗУ, не зависит от режима прерываний.
Это позволит тщательнее подходить к вопросу совместимости различных модулей, и выбору "платформы" для программы.
IMHO...
Основная идея: Создать здесь на форуме некий конструктор, состоящий из процедур, заготовок и документации, который поможешь быстро создавать качественные программы.
У любого програмера кто не первый год кодит на спектруме процес создания новой проги происходит на 50-90% так же как ты описал.
Причем зависит это от организованости кодера, мне например всегда было лень создавать бибилиотеку процедур. Я их всегда копировал из старых проектов.
А по началу и вовсе переписывал каждый раз с 0.
А с чужой библиотекой скорее всего не стал бы связываться, пока с ней разберешся можно свою успеть написать. Да и отлаживать всегда проще свое.
и получиться очередной велосипед под названием Язык высокого уровня плюс компилятор на базе асма! :)
и получиться очередной велосипед под названием Язык высокого уровня плюс компилятор на базе асма! :)
Ну зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.
CityAceE
30.11.2005, 13:56
А с чужой библиотекой скорее всего не стал бы связываться, пока с ней разберешся можно свою успеть написать. Да и отлаживать всегда проще свое.
Тут нужно отталкиваться от того, что все библиотеки уже будут хорошо оптимизированы, отлажены и протестированы, а кроме того будут не менее хорошо описаны. Эти бибилиотеки будут призваны облегчить труд программиста, а не усложнить его! Нужно стермиться к тому, чтобы программисту было проще освоить требуемую библиотеку, чем написать свою процедуру с нуля.
и получиться очередной велосипед под названием Язык высокого уровня плюс компилятор на базе асма!
А пусть так! Но что в этом плохого, если это повысит скорость программирования и явится неким катализатором для выхода нового софта?
Ну зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.
Никто и не рубит. Соберитесь и напишите нормальный С компилятор и будет вам описаное счастье. Кодить описаным образом на языке низкого уровня самоубийство. Моё ХО, на последнюю инстанцию не претендую :)
А пусть так! Но что в этом плохого, если это повысит скорость программирования и явится неким катализатором для выхода нового софта?
Я бы просто не стал тратить время на изучение исходников. Новички может и стали бы узать.
CityAceE
30.11.2005, 14:45
Я бы просто не стал тратить время на изучение исходников.
А и не нужно изучать исходники! Нужно знать основные процедруры и уметь ими грамотно пользоваться, как при программировани под какую-то ОС... К тому же я не призываю всех всё срочно бросать и начинать писать опираясь на предложенную систему. Но я не исключаю, что кому-то будет удобно писать именно так, как предлагаю я. Почему нет? Так же я отдаю отчёт в том, что какую-то аркадную игрушку с помощью предложенного метода написать не удасться, а вот головоломку пожалуйста.
К тому же от всех автором проекта потребуется не так много времени. Самое главное выработать общую концепцию и определиться со стандартами.
Поддерживаю идею.
Думаю, что первым шагом в создании подобного банка будет очерчивание границ применимости, как то:
Вторым. Первым -- определённые соглашения о вызове и загрузке.
Иначе две программы из банка не подружишь. Если они в ассемблере,
конечно немного проще. Лишь немного. Потому как любой программный продукт имеет срок жизни до тех пор пока он
сопровождается и поддерживается. Что невозможно без динамической компоновки практически. На FreeBSD до 5.0 посмотрите -- у них на всё make world. У нас world на дискетку
не поместится...
Позарез как нужна ДИНАМИЧЕСКАЯ КОМПОНОВКА. Ибо те
же драйвера cmos, hdd, модема -- у всех свои и несовместимые.
Несовместимые по интерфейсу. Функции одни и те же практически.
Нужен некий стандарт как на "дизайн интерфейса", не знаю как
это назвать, вроде соглашения о передаче параметров, техники
собственно вызова и т.п. Нужен унифицированный способ
динамической загрузки и статической компоновки расширений.
И наконец нужен какой-то способ идентификации интерфейсов,
что-то вроде COM и виндов.
1. Конфигурация компьютера (ZX48; ZX128; S256;...),
2. Модель памяти (SOLID; CODE_IN_LOW_MEMORY_DATA_IN_BANK; CODE_AND_DATA_IN_BANK;...),
3. Доступные внешние устройства (DOESNT_USE_EXTERNAL; FDD; HDD_SCRP; HDD_NEMO; KEMP_MOUSE;...),
4. Зависимости от системных библиотек (DOESNT_USE_SYSTEM; ...),
5. Режимы работы прерываний (INT_MUST_BE_DISABLED; INT_CAN_BE_ANY; HAVE_ISR;...).
Список, естественно, примерный.
Каждая единица (модуль, процедура, библиотека), снабжается метками, указывающими на границы применимости.
Например:
ZX48 SOLID DOESNT_USE_EXTERNAL DOESNT_USE_SYSTEM INT_CAN_BE_ANY - Процедура удовлетворяет требованиям ZX-Spectrum 48, при этом не требует ни внешних устройств, не использует процедуры из ПЗУ, не зависит от режима прерываний.
Это позволит тщательнее подходить к вопросу совместимости различных модулей, и выбору "платформы" для программы.
IMHO...
Да. Но возможно и немного наоборот, когда выбирается
версия процедуры применимой в указанных условиях.
Или выбирается ошибка.
Нет, народ, ну, правда ведь, как всегда, не в ногах, а где-то между... Но, действительно, идея неплохая и даааавняя. И NewArt, никого не заставляют сие юзать. Но вот еще пример: надо быстренько конвертор какой забацать... и начинается: из асма с геморойчиком...
Давайте хотя бы попробуем оттолкнуться от такого уровня что-ли...
(mac_lib библиотечка+txt описание. остальное - примеры использования)
Брать пример с BGE! там именно так плуги делать: окно задал, открыл - всё ОК (что там при этом - особо не ебб...) onkey проверил - меню выбрали/нет и т.п. Уж если я там раздуплился - так вы уж, люди добрые извольте. Сомневаюсь, что тут есть кто-то, хуже меня втыкающий в чужие СОРЦЫ. Единственное, в BGE всё этак глобально... Но можно дойти и до такого глобализма.
А с чужой библиотекой скорее всего не стал бы связываться, пока с ней разберешся можно свою успеть написать. Да и отлаживать всегда проще свое.
"Я мог бы выпить всю грязь Ганга и даже мне ничего не было бы, просто на это нужно больше чем одна человеческая жизнь." (C) Немо.
Это первая проблема -- тебя попросту на всё не хватит. Вторая
заключается в том, что кто-то может делать что-то похожее, но
почему-то несовместимое. А потом бегать и искать, например,
драйвер "винчестера" к двум разным программам. А зачем?
Раньше на Спектруме я сталкивался с такой проблемой, что когда в голову приходила какая-то идея, то основную часть времени для её проверки тратилась на обвязку программы,
Текстовая консоль, немного математики и строковых функций.
Собрано с миру по нитке.
Текстовая консоль, немного математики и строковых функций.
Собрано с миру по нитке.
Ещё одна текстовая консоль для режима 85 символов в строке,
выдрано из биоса CP/M.
Только мне её нихрена не вложить (недопустимый, блин,
тип файла, потом недопустимый размер ). Как и следующее за ней оконный интерфейс +
в качестве примера программа для установки времени в CMOS.
Интерфейс оконный (C) MAS (выдрано давно было из BBS 3.15).
Вставляю как есть:
БЛ$! И так не вставляется -- слишком длинный. Ну я не знаю как ещё можно!
Итак, как я понимаю суть проблемы: надо создать банк полезных процедур (именно, просто статически линкуемых процедур, а на плагинов или COM объектов).
Перед этим надо оговорить две вещи- стандарты вызовов (чтоб можно было пользоваться процедурами, не заглядывая каждый раз в толстенный талмуд под названием мануал) и второе- области применения (т.е. ZX48, ZX128, HDD_ANY, HDD_NEMO, что использует, что портит).
после этого можно начинать работу.
по посоду областей применения - меня вполне устроит вариант перед процедурой по одному в строке комментария писать ключевые слова (чтоб можно было как-нибудь автоматом прогнать).
; Print Char
; ZX48
; DOESNT_USE_EXTERNAL
; SOLID
; DOESNT_USE_SYSTEM
; INT_CAN_BE_ANY
PrintChar ....
А по поводу динамической загрузки- есть моменты когда она позарез нужна (CMOS, HDD) и ещё больше моментов когда она нафиг не нужна.
по этому предлагаю:
; LoadModule
; ZX128
; CODE_IN_LOW_MEMORY_DATA_IN_BANK
; FDD
; USE_TRDOS
; INT_CAN_BE_ANY
LoadModule ....
^_~ - думаю идея всем доступна.
по посоду областей применения - меня вполне устроит вариант перед процедурой по одному в строке комментария писать ключевые слова (чтоб можно было как-нибудь автоматом прогнать).
Проще метку определить. Только спектрумовскому ассемблеру позарез
как нехватает модульности или namespaces.
А по поводу динамической загрузки- есть моменты когда она позарез нужна (CMOS, HDD) и ещё больше моментов когда она нафиг не нужна.
Это кажется, что не нужна. А потом окажется, что Вася Пупкин
где-то баг пофиксил и всё (make world) пересобирать -- замучаешься.
по этому предлагаю:
; LoadModule
; ZX128
Не обязательно,
; CODE_IN_LOW_MEMORY_DATA_IN_BANK
Модулезависимо.
; FDD
; USE_TRDOS
Рамдиски, исдос...
А по поводу динамической загрузки- есть моменты когда она позарез нужна (CMOS, HDD) и ещё больше моментов когда она нафиг не нужна.
Это кажется, что не нужна. А потом окажется, что Вася Пупкин где-то баг пофиксил и всё (make world) пересобирать -- замучаешься.
Если моя программа работает, пусть даже с этим багом, значит он на неё не влияет. И пересобирать ничего не нужно.
А то что из-за бага не работает, ну так по любому фиксить надо.
; LoadModule
; ZX128
Не обязательно
; CODE_IN_LOW_MEMORY_DATA_IN_BANK
Модулезависимо.
; FDD
; USE_TRDOS
Рамдиски, исдос...
Не надо придираться к словам.
Фишка была в том, чтоб оформить динамичезкую загрузку как процедуру.
а как быть с разными версиями одних и тех же кусочков кода? например, васе пупкину нужны самые быстрые процедуры а его корешу вове тяпкину нужны самые маленькие?
динамическая линковка подразумевает возможность подгрузить эти недостающие кусочки мозаики.для системного диска с кучей программ можно позволить себе хранить на нем с десяток разных драйверов, а как быть с одной программой? статическая линковка только...
имхо реализация предложенного варианта может быть более-менее прилично выполнена только на ЯВУ (тот же С). отметается вопрос о формате вызова (все юзают один и тот же компилер естесно) и о приоритете (размер/скорость) - все решается опциями компилятора
а для ассемблера- оставить как есть, но расширить и углубить %) зачем писать с нуля драйвер чего-то там, если можно полистать кодерские разделы в прессе и взять что тебе надо? я начал собирать некотрую информацию по этому поводу, но пока нет времени пополнить сборник.
А пусть так! Но что в этом плохого, если это повысит скорость программирования и явится неким катализатором для выхода нового софта?Скорость чего? ты вспомни тех кто ещё что-то делает...
а так... конечно неплохо, но ведь на "серьёзных" системах ты пользуешь то что уже есть, и это будет выглядеть так как этого захотели создатели, а на спеке полюбому захочется что-то переделать под себя, что-то не понравится, а про разбирательство в чужих прогах писал славка калинин чуть выше.
НО, идея как всегда неплохая. лучше не создавать общую SDK? а пускай создатели того что уже создано выкладывают сюда с полным описанием. Но сколько раз уже были попытки создания сборников сырцов. как и здесь, так и отдельно в сети... и что из этого получилось?
Текстовая консоль, немного математики и строковых функций.
Собрано с миру по нитке.
Респект за либу. Очень дельная штука. Самодокументирующийся код %) Много чего интересного!
CityAceE
01.12.2005, 08:14
Вторым. Первым -- определённые соглашения о вызове и загрузке.
Приятно, Кирилл, что ты не охаял идею, как обычно, а высказал ряд полезных идей и приложил полезные исходники!!! Спасибо за поддержку!
Брать пример с BGE! там именно так плуги делать:
Замечательно, почему бы для начала и не взять пример с BGE??? Нужно же от чего-то отталкиваться!
а как быть с разными версиями одних и тех же кусочков кода? например, васе пупкину нужны самые быстрые процедуры а его корешу вове тяпкину нужны самые маленькие?
А почему бы не иметь две версии "контструктора": одна там, где процедуры оптимизированы по объёму, а другая - по скорости?
а на спеке полюбому захочется что-то переделать под себя, что-то не понравится
И какие проблемы? Пожалуйста, переделывай! У тебя просто будет в руках инструмент для того, чтобы стартовать и быстро сделать работающую программу.
а пускай создатели того что уже создано выкладывают сюда с полным описанием.
И кто будет разбираться в этом? Для многих, как обычно, будет проще писать всё самому с нуля...
Но сколько раз уже были попытки создания сборников сырцов. как и здесь, так и отдельно в сети... и что из этого получилось?
А когда я запустил этот форум, в сети было уже полно форумов затрагивающих спектрумовскую тематику... "и что из этого получилось?" :)
Вот, что ещё подумалось:
1. Для начала нужно найти компетентного человека, который возглавит этот проект. Если всё пустить на самотёк, то дальше разговоров это дело не пойдёт.
2. Предлагаю создать на форуме раздел, посвященный разного рода проектам (это я предлагал уже давно, сразу после открытия этого форума), а в нем подраздел посвященный конкретному проекту - ZX SDK. В подразделе создать ветки для обсуждения конкретных вопросов (организационные вопросы, обсуждение способов вызова, обсуждение конкретных подпрограмм и т.д.). Всё это должно упростить обсуждение, так как в одной ветке, как сейчас, многие мысли теряются, да и вообще получается каша...
James DiGreze
01.12.2005, 10:21
Идея классная! И не стоит здесь разводить критику, преждевременно убивая идею... Библиотеки нужны, это действительно подстегнуло бы развитие софта. Причем у этой идеи есть еще одна положительная черта - когда проги собираются подобным образом, появляется некий стандартный вид, интерфейс, что положительно скажется на юзабельности софта. Возьмите к примеру Windows, там ведь на освоение новой проги, построенной из стандартных модулей, уходит очень мало времени, т.е. новую программу начинаешь использовать практически с первого запуска... Это была точка зрения Юзера ;)
А с программёрской точки зрения, программирование, построенное на использовании готовых библиотек, позволяет максимально эффективно распределить и сократить время разработки на порядки. (Это мое нескромное мнение, так как работаю разработчиком харда, и софта для этого харда)
На самом деле эту проблему поднимали еще, если не ошибаюсь, в первом ZX-FORUM'е году этак в 1994, но тогда все заглохло, так как была представлена только концепция. Рекомендую перечитать этот материал. Более точную ссылку выложу позже...
CityAceE
01.12.2005, 10:30
На самом деле эту проблему поднимали еще, если не ошибаюсь, в первом ZX-FORUM'е году этак в 1994, но тогда все заглохло
Сейчас у этой идеи есть шанс воплотиться в жизнь благодаря современным средствам коммуникации, я имею ввиду этот форум.
И ещё раз по поводу динамической подгрузки: народ путает серьёзные ОС с заменителем кассетного магнитофона TR-DOS.
Динамическая загрузка нужна когда? Когда есть толпа либ, которую пользует ещё большая толпа программ, когда есть ОС которая всё это регулирует.
А у нас ничего этого нет!
Для начала надо создать просто тучу процедур, с помощью которых вышеупомянутый тов. Вася Пупкин сможет быстро добавить в свою прогу нужный ему интерфейс, поддуржку HDD и CD и ещё что нибудь.
А если долго рассуждать о динамической подгрузке, то 100% придём к разговорам об ОС, а это надолго ;)
И ещё, по поводу make world- это может на FreeBSD программы распространяются в виде sources+automake, а в мире спектрума программы обычно распространяются бинарниками, по-этому ни о каком make речи и быть не может.
Многи просто не захотят изучать и запоминать названия готовых процедур и запоминать входные и выходные данные! (это тоже что изучить очередной язык программирования). Проще свою сбацать!
CityAceE
02.12.2005, 11:00
Многи просто не захотят изучать и запоминать названия готовых процедур и запоминать входные и выходные данные!
А вот для этого нужно написать очень хорошую и удобную документацию!
Вы ещё с нами? ;)
Тогда давайте быстренько прийдём к соглашению о вызовах (что и куда пихать, и откуда резалт забирать) и к описаниям (ZX48, ZX128, etc)
по поводу описания области применимости я уже высказал своё мнение.
по соглашениям о вызовах пока мыслей нет.
CityAceE
02.12.2005, 16:19
К сожалению, у меня нет мыслей по поводу всякого рода вызовов, так как мой опыт программирования слишком небольшой. Но у меня есть другая мысль...
Наверное слишком мало интереса в отдельных процедурах. Чтобы быстрее начать создавать ZX SDK я предлагаю сделать программу, например, игру "Сапёр". Игра достаточно проста в реализации и вместе с тем она может использовать много полезных процедур: вывод окон, вывод текста, работа с мышью/джойстиком, работа с клавиатурой, работа со звуком и др. Итак, берём эту игру и раскладываем её на процедуры. Большинство из этих процедур уже давным давно написаны и наверняка подборка таких присутствует на дисках многих спектрумовских программистов... Определившись со списком нужных процедур мы раздаём реализацию этих процедур разным людям. В конце концов, я думаю, мы придём к общему знаменателю. Если таким образом мы коллективно сделаем программу, то это будет неким началом. У нас будет какой-то набор процедур, который уже можно будет смело расширять. Кроме того, на этой программе можно поэксперементировать сделав управление от мыши, клавиатуры или джойстика, вывод звука на бипер, AY или GS, вывод графической информации на стандартный экран, расширенный экран ATM и т.д. То есть можно обкатать технологию. По ходу написания обязательно будут возникать какие-то проблемы, которые мы будем коллективно решать. То есть я предлагаю начать реализовывать конкретную задачу! Почему нет?
CityAceE
02.12.2005, 16:58
Что касается вызова процедур, я всё же подумал и мне кажется, что наиболее универсально будет передавать данные в процедуры таким образом:
CALL PROC
DB VAR1
DW VAR2
Это медленнее, но за то не привязываемся к регистрам!
Сейчас у этой идеи есть шанс воплотиться в жизнь благодаря современным средствам коммуникации, я имею ввиду этот форум.
Догадайся сколько стоит в у.е. почитать форум через GPRS? А по-другому
как-то не получается (ну кроме как с работы). Фидо в том же виде карман
не сильно оттягивает...
Вы ещё с нами? ;)
Тогда давайте быстренько прийдём к соглашению о вызовах (что и куда пихать, и откуда резалт забирать) и к описаниям (ZX48, ZX128, etc)
по поводу описания области применимости я уже высказал своё мнение.
по соглашениям о вызовах пока мыслей нет.
http://spbzxnet.org.ru/cdwalk/ide-driver.html#hitech-c:
Интерфейс с компилятором языка C
В этом разделе описывается интерфейс компилятора языка C фирмы HiTech Software (http://www.htsoft.com) с программой на языке ассемблера.
Передача аргументов
Функция может принимать некоторое число аргументов передаваемых вызывающей программой. Аргументами функции могут быть переменные (значения) любых типов.
Для функций, объявленных в стиле K&R, когда аргументы функции не входят в её прототип, все аргументы передаются через стек как описано ниже. Для функций объявленных в стиле ANSI-C, когда в прототип функции входит информация о аргументах функции, передача аргументов осуществляется через регистры микропроцессора DE, BC и через стек. В любом случае, все 8-разрядные значения предварительно расширяются до 16-и разрядов, старшие разряды при этом никак не используются.
Если функция объявлена в стиле ANSI-C, первый аргумент функции, в том случае, если он является 8-и или 16-разрядным значением, передаётся в регистре DE микропроцессора. В регистре E передаётся 8-разрядный аргумент. В противном случае, первый аргумент передаётся через стек.
Если функция объявлена в стиле ANSI-C, второй аргумент функции, в том случае, если он является 8-и или 16-разрядным значением, передаётся в регистре BC микропроцессора. В регистре E передаётся 8-разрядный аргумент. В противном случае, второй аргумент передаётся через стек.
Третий и остальные аргументы функции всегда передаются через стек. Аргументы функции размещаются на стеке в обратном порядке, то-есть последний аргумент помещается на стек в первую очередь, а третий аргумент, в случае если оба первых аргумента передаются через регистры DE и BC, помещается на стек в последнюю очередь. Аргументы, занимающие в памяти один байт (8-разрядные), как уже говорилось, обязательно всегда расширяются до 16-и разрядов и следовательно на стеке занимают по два байта. Аргументы, занимающие в памяти 3 байта, расширяются до 32-х разрядов и помещаются на стек в 4 байта. Аргументы большей разрядности занимают на стеке ровно столько байт, сколько требуется для их сохранения, то-есть, например, если есть некий тип данных занимающий в памяти ровно 5 байт то он и на стеке займёт 5 байт если будет передан аргументом функции.
В случае, если функция объявлена в стиле ANSI-C и хоть один аргумент был передан через стек, то вызываемая функция обязана снять со стека все аргументы перед возвратом, а вызывающая программа может об этом не беспокоиться. В случае, когда функция объявлена в стиле K&R, вызывающая программа обязана извлечь из стека все аргументы переданные через стек.
Возврат результата
Функция может возвращать результат. Результатом может быть одна переменная (значение) любого типа. Способ, каким результат возвращается в вызываемую функцию определяется типом переменной результата. Все 8-разрядные значения предварительно расширяются до 16-разрядов, старшие разряды при этом не используются и могут содержать произвольное значение. Если результат умещается в 16 разрядов, то он возвращается в регистре HL. Если результат умещается в 32 разряда, то он возвращается в регистрах HL и DE: в регистре DE младшие разряды, а в регистре HL старшие. Результат большей разрядности (например массив или структура) помещается в статическую временную переменную, и в регистре HL возвращается указатель на эту переменную (нетрудно заметить, что в данном случае функция не может быть «реентрантной»).
Регистры микропроцессора
Функция может изменить содержимое любых регистров микропроцессора кроме SP и IX. Регистр SP всегда увеличивается на 2 при возврате из функции за счёт извлечения со стека адреса возврата. Дополнительно он может быть изменён в случае, если функция обязана извлечь аргументы из стека («Передача аргументов»). В регистре IX хранится указатель кадра стека вызывающей функции, поэтому вызываемая функция перед возвратом обязана восстановить содержимое регистра IX.
Прототипы на C вот так просто и можно записывать. Можно из
C и из асма пользовать. Отступать, с моей точки зрения, можно
лишь в случае:
* когда использование из языка C не имеет смысла
(например, для функции быстрого умножения --
в библиотеке C есть собственная);
* при работе с ОО-функциями, которые из C не вызовешь --
всё равно обёртку писать, хотя тут желательно слишком
сильно не отходить;
* когда ОЧЕНЬ ВАЖНА СКОРОСТЬ. _ОЧЕНЬ_ -- это не означает
экономию 10 тактов из 1000. Даже не 10 из 100. Даже 100 из 10,
если время выполнения совершенно некритично.
Почему это важно -- это позволяет использовать C-компилятор
без оборачивания абсолютно каждой функции ассемблера. Только
имена нужно давать начиная с '_'. И прототип приложит.
Может возникнуть вопрос почему HiTech. Ну... пусть будет потому,
что он и на спектруме (в CP/M) запускается и в интернете CP/M версия
(ей как раз UZIX собирают) свободно лежит. SDCC и Z88DK по-моему
ещё не доросли. Остальное за деньги и под Windows -- не интересно.
Другие альтернативы?
По-умолчанию модель памяти плоская, без переключаемых банок.
С прерываниями никак ничего не взаимодействует, доступны порты
режима "Бейсик". В случае переключения банок, видимо, следует
завести макрос сигнализирующий фактом своего наличия о возможных конфликтах. Равно как при использовании прерываний,
переключения в TR-DOS и т.п.
Что касается выбора ZX48/128/etc то тут можно поступить как это
обычно делается при компиляции на несколько платформ: завидится
платформенно-зависимый макрос, которым (ifdef) и определяется
участвующий в компиляции код и прототипы. Библиотеки (двоичные)
изначально делятся по платфромам, каждой своя.
В догонку: для OO функций принимается, что указатель на объект передаётся обязательно в регистре HL, остальное как описано выше. Первые два байта в области памяти, на которую указывает регистр HL -- таблица JP xxx виртуальных функций, далее собственно данные.
Что касается вызова процедур, я всё же подумал и мне кажется, что наиболее универсально будет передавать данные в процедуры таким образом:
CALL PROC
DB VAR1
DW VAR2
Это медленнее, но за то не привязываемся к регистрам!
Ага. А все аргументы: исключительно константы... Или там где DW -- это ссылка? По сложности проще будет машину тьюринга запрограммировать...
Если не привязываться: стек, как компилятор умеет.
push argument
push argument
call function ; -> hl=result
pop xx
pop xx
Только опыт подсказывает: через регистры заметно быстрей.
(а что HL из использования выпадает, так это исправляется в
4 такта ex hl, de -- зато сразу есть свободный 16-разрядный
регистр который может использоваться для арифметики. С
регистром A -- аналогично, не сохраняется и нигде не
используется для передачи ничего, кроме как для вычислений)
А не громоздко ?
Ну вот надо мне символ печатнуть
Что мне для этого надо
адр шрифта, xy pix, код символа.
Т.е. через регистры. Многим вещам надо 1-2 регистра на входе и 1-2 значения на выходе.
Насчет изучения чужого и "нового языка": а где там разбираться ?
Вот берем MAC lib (см. выше)
-------------------
PR_ATTR (-) (call pr_attr)
- fill окна атрибутами (40 b)
LD HL,tabl
CALL pr_attrs
...
tabl DB x,y,w>,h^,цвет
если "-" то
CALL pr_attrs
DB x,y,w>,h^,цвет
Требует at_attr DE,HL
-----------------------
Ну вот что тут не ясно/сложно ?
Проблемы могут быть с запряганием глобальных вещей типа интерфейса оконного с мышой и прибамбасами. Ну и то...
В случае, если функция объявлена в стиле ANSI-C и хоть один аргумент был передан через стек, то вызываемая функция обязана снять со стека все аргументы перед возвратом, а вызывающая программа может об этом не беспокоиться. В случае, когда функция объявлена в стиле K&R, вызывающая программа обязана извлечь из стека все аргументы переданные через стек
имхо первый вариант очень уж опасен. лучше остановиться на втором (когда стек очищает вызывающая процедура).иначе такой вот вызов:
printf("%i %i %i", param1, param2);
рискует похерить стек- процедура будет определять число параметров по форматирующей строке...
а если очистку стека будет выполнять вызывающая процедура, то вызываемая напечатает фигню, но вернется правильно и стек будет в правильном состоянии.
Alexander Bondarenko (500:3432/3)
05.12.2005, 00:16
*Здравствуй, Даниил!*
Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.
и получиться очередной велосипед под названием Язык высокого уровня
плюс компилятор на базе асма! :)
А вот ты зpя этy штyкy велосиподем обзываешь. Я себе нечто подобное давно ещё оpганизовал, когда аласм появился 4.44... Очень yпpощает пpоцесс написания пpогpамм. Только я давно yже не кодил, эта штyка y меня лежит где-то и пылится.
А пpедставляет оно из себя следyющее:
1. MAIN_H - вставляется в начало пpоги, там нyжные макpосы и константы.
2. MAIN_L - ядpо библиотек.
х. ... - дальше пошли сами библиотеки.
Такая система делает то, что считает, кyда сколько какой памяти yшло. Это необходимо, чтобы SAVE делать одним макpосом. Hy и ещё пpоцедypки динамически пpилинковываются.
А в самом издохнике пpогpаммы я телько макpосами игpаюсь, да пpоцедypки нyжные мне вызываю обычным CALL'ом. Кстати, макpосы использyются очень-очень активно.
Hо только я этy идею закопал давно yже. Hе очень-то комфоpтно кодить под омyлем, да ещё и в алясме. Лyчше yж на пэцее замyтить пyтёвый асм спеpва. А потом под него и сyпеp-пyпеp библиотеки мyтить.
Хотя, опять же, если только кодить на pеале... %)
/Вот и всё, Даниил, можешь листать дальше.../
... C миру по исходничку - и готова программка.
Alexander Bondarenko (500:3432/3)
05.12.2005, 00:16
*Здравствуй, Александр!*
Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.
Hу зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.
Идея не пpосто стоящая, а гиговская! Если замyтить такyю библy - можно Спёк бyдет спасти. Считай - каждый ламок бyдет кодить!!! %) И завалят землю-матyшкy спёковским софтняком!.. :D
/Вот и всё, Александр, можешь листать дальше.../
... Кто взывает к сплочению, тот забыл что люди разные.
Alexander Bondarenko (500:3432/3)
05.12.2005, 00:16
*Здравствуй, Stanislav!*
Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.
Тут нужно отталкиваться от того, что все библиотеки уже будут хорошо
оптимизированы, отлажены и протестированы, а кроме того будут не
менее хорошо описаны.
Вот это самое сложное, обычно докy-то и лень писать...
Эти бибилиотеки будут призваны облегчить труд
программиста, а не усложнить его!
Hадо спеpва тогда выдyмать и yтвеpдить стандаpт написания этих библиотек. Потом, надо ещё вдобавок набpать гpyппочкy молодых и инициативных людёв, котоpые бyдyт y нас заниматься тем, что тестиpовать новые библиотеки. И pелизить новые веpсии этого сбоpничка библиотек. Коpоче, если всё центpализованно оpганизовать - выйдет пyтёвенько.
Hужно стермиться к тому, чтобы программисту было проще освоить
требуемую библиотеку, чем написать свою процедуру с нуля.
Да ваще, пpогpаммист не должен пpогpаммиpовать! Пpога на основе его идеи должна мyтиться сама!
А пусть так! Hо что в этом плохого, если это повысит скорость
программирования и явится неким катализатором для выхода нового софта?
Жжоте, гpажданин начальник, ой жжоте!!! ;)
Там вообще pеально бyдет такое - двyмя пальцами щёлкнешь и готов софт, pелизь - нехочy!
Hо спеpва-то всё pавно пpидётся потpyдиться.
/Вот и всё, Stanislav, можешь листать дальше.../
... Гнилое не спрячешь - запах выдаст.
Alexander Bondarenko (500:3432/3)
05.12.2005, 00:16
*Здравствуй, Andreas!*
Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.
Hикто и не рубит. Соберитесь и напишите нормальный С компилятор и
будет вам описаное счастье. Кодить описаным образом на языке низкого
уровня самоубийство.
Да ваще - под алясмом кодить так, да ещё и под омyлем - садомазохизическое самоyбийство!
Моё ХО, на последнюю инстанцию не претендую :)
/Вот и всё, Andreas, можешь листать дальше.../
... Пофигистов и в масле жарят - им же всё пофиг.
Alexander Bondarenko (500:3432/3)
05.12.2005, 00:16
*Здравствуй, Вячеслав!*
Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в 30 Nov 2005 твоя портянка к тов. All.
Я бы просто не стал тратить время на изучение исходников. Hовички
может и стали бы узать.
Да кpyт ты, Славка, кpyт. %)
С дpyгой стоpоны, сам-то небось библиотеками собственной ваpки пользyешься? А чё бы с дpyгими не поделиться - это-то yже дpyгой вопpос!
/Вот и всё, Вячеслав, можешь листать дальше.../
... Чувство меры есть у меньшинства. Иначе в нём нет смысла.
Hадо спеpва тогда выдyмать и yтвеpдить стандаpт написания этих библиотек. Потом, надо ещё вдобавок набpать гpyппочкy молодых и инициативных людёв, котоpые бyдyт y нас заниматься тем, что
Вот заниматься больше нечем. Сейчас всё брошу водку пить и пойду
библиотеки писать...
Да ваще, пpогpаммист не должен пpогpаммиpовать! Пpога на основе его идеи должна мyтиться сама!
"Оставьте программирование программатору" (C)
имхо первый вариант очень уж опасен. лучше остановиться на втором (когда стек очищает вызывающая процедура).иначе такой вот вызов:
printf("%i %i %i", param1, param2);
рискует похерить стек- процедура будет определять число параметров по форматирующей строке...
Описание подготовлено негодно. Конечно prinft который с переменным числом аргументов вызывается так, что аргументы
со стека снимает вызывающая процедура. Но, например, в случае
puts() аргументы снимает сама функция puts.
итак, поехали.
делать вызовы вида
CALL sub
DB xxx
DW yyy
или
PUSH xx
PUSH yy
CALL sub
POP zz
POP zz
или даже пользуясь соглашениями HiTech C не стоит, ибо это тормозно и долго писать.
надо упростить труд программиста, а не усложнять его.
использовать C поголовно никто не будет (100%), спек для асма.
а на асме ничего лучше передачи через регистры никто не придумал.
надо понимать, что идея и концепция это хорошо, но когда они идут вразрез с удобством, то такие идеи надо выкинуть.
итак, передача аргументов:
один байт - A
одно слово, адрес - HL
строка - указатель в HL
структура - указатель в IX
счетчик - B или BC
остальные регистры по вкусу.
и надо конечно понимать, что если от передачи адреса на в HL а в DE процедура выиграет допустим 10 байт в размере и 100 тактов, то надо передавать адрес в DE.
....
однако я не вижу прогресса. давайте завязывать с пустой болтовнёй, определятся наконец с вызовами и описаниями, открывать тему и прогрессировать.
....
и ещё,
Но, например, в случае puts() аргументы снимает сама функция puts.
тогда такой C компилер надо выкинуть как не соответствующий ANSI.
итак, поехали.
делать вызовы вида
CALL sub
DB xxx
DW yyy
или
PUSH xx
PUSH yy
CALL sub
POP zz
POP zz
или даже пользуясь соглашениями HiTech C не стоит, ибо это тормозно и долго писать.
Ни разу не долго. Если у тебя на входе пара 8-битовых аргумента
и на выходе 8-битный результат, то пользуясь соглашениями hitech-c писать можно. Вот если возвращается структура и передаётся полсотни аргументов... да, сложно. Но "классический спектрумовский" метод, статическое выделение памяти, и такого не даёт.
надо упростить труд программиста, а не усложнять его.
Рецепт называется perl. И вообще, "оставьте программмирование программатиру".
использовать C поголовно никто не будет (100%), спек для асма.
Никто может и не будет. А я был, есть и буду использовать.
Ибо считаю, инструментик нужно по размеру выбирать, всё одним
не очень получается.
а на асме ничего лучше передачи через регистры никто не придумал.
Никто не против передачи через регистры. Все двумя руками за.
Проблема:
* регистров мало и на все аргументы может не хватить;
* есть разные типы данных -- нужны определённые соглашения
по их передаче через регистры;
* если вы не фанат паскаля то должны слышать о фунциях с
переменным числом аргументов;
* нужно как-то возвращать значения, как-то определённым
образом;
* передача данных через статически выделенную область
памяти чревата неприятностями при использовании
рекурсивных и, как это сказать, повторно вызываемых,
функций...
HiTech-C решает эти проблемы как может. Самое главное -- он даёт возможность записав прототип функции на языке C однозначно определить порядок её вызова. Для любой функции можно сказать,
не роясь в документации, какие регистры нужно сохранять, а какие нет. И наконец -- появляется возможность благодаря перечисленному выше генерировать код из программы на языке C. Уже даже не важно каким компилятором.
надо понимать, что идея и концепция это хорошо, но когда они идут вразрез с удобством, то такие идеи надо выкинуть.
Они идут вразрез может быть в твоём конкретном случае. Не более того.
итак, передача аргументов:
один байт - A
одно слово, адрес - HL
строка - указатель в HL
структура - указатель в IX
счетчик - B или BC
Так B или BC? Это уже вопрос. А далее можно покритиковать. Практически любая функция подразумевает какие-либо вычисления, аргументом которых выступает собственно аргумент функции. Микропроцессор выполняет арифметические и логические операции над одним из регистров -- аккумулятором. Только над ним. И использовать этот регистр для передачи аргумента значит обязательно заставлять каждую функцию первым делом куда-то сохранять значение аккумулятора-аргумента до выполнения любых вычислений. Только если содержимое аккумулятора не является
одним из операндом самой первой операции. Кроме того, вызов может доходить до функции-назначения через некоторые промежуточные функции. Где тоже производятся вычисления. Со всеми вытекающими последствиями...
Структура в IX. Большая, если не большая часть структур обрабатывается по большей части последовательно. При условии последовательного доступа на каждый байт структуры тратится
10 тактов (LD A, (HL); INC HL). При доступе через регистр IX в несколько раз больше. И тактов и байт. В целом набегает много.
По указанной же выше причине использование регистра HL -- единственного, кроме индексных регистров, 16-разрядного регистра над которым возможны арифметические операции, в качестве аргумента функции нежелательно. Ровно по той же, описанной выше причине. Я делаю исполючение только для OO-подпрограмм. При вызове виртуальной функции всё равно вычислять адреса функции нужно из таблицы функций, потому там указатель на объект и хранится.
остальные регистры по вкусу.
и надо конечно понимать, что если от передачи адреса на в HL а в DE процедура выиграет допустим 10 байт в размере и 100 тактов, то надо передавать адрес в DE.
Понимать это как раз не нужно. Ибо ex de, hl занимает 4 такта и один байт.
однако я не вижу прогресса. давайте завязывать с пустой болтовнёй, определятся наконец с вызовами и описаниями, открывать тему и прогрессировать.
Я предложил вариант. Ещё несколько лет назад (hitech-c).
Предполагаю, функции должны обязательно сопровождаться
прототипом для языка C, кроме случая когда их использование
из языка C не имеет смысла. Отходить от C в сторону голого
ассемблера я никакого смысла не вижу. Равно как и не вижу
смысла эконимить, да и экономии не вижу, в более других,
не совемстимых с C решениями. ДОЛЖЕН БЫТЬ ДОСТУПЕН
ИНТЕРФЕЙС С ЛЮБОЙ СРЕДОЙ ПРОГРАММИРОВАНИЯ. И точка.
Поэтому извраты вокруг ассемблера и ALASM в частности не
поддерживаю. C-интерфейс доступен из любого ассемблера,
и из C. Он, может быть, недоступен из других компиляторов.
Впрочем я уже писал, реальной конкуренции там нет, там вообще
чего-то работоспособного -- один IAR. Он или сам настраивается,
или писать обёртку на каждую функцию.
тогда такой C компилер надо выкинуть как не соответствующий ANSI.
С чего бы это вдруг? Он совместимый и соответствующий, в писишной версии. В CP/M-овской нет. Так она и была ещё до ANSI.
Офттоп пошёл! ;(
Станислав правильно поднял тему, если такая бурная реакция!
С самого начала, что хочется сказать - тема готового набора процедур не на нулевой точке (хотя и не очень далека от неё) - тот же пример с BGE - там почти весь GUI был в виде библиотек зарелизен.
Другой вопрос - достаточно серьёзный - что подавляющее большинство библиотек слабо или вообще не документируется (например: идёт библиотека с функцией call_addr_2_file - что бы это значило???). Если вы откроете открытый код Linux, Unix и т.п., то увидите, что там половина или даже две трети исходников расходуется на комментарии. К сожалению я ни разу такого не видел в исходниках, выложенных для общего пользования на ZX (хотя я не отрицаю что они возможно есть). Это достаточно серьёзное забивание на описание команд и их роли внутри процедуры/функции приводит к собственно малопонятному способу запуска, который, автор, конечно же, неплохо знает, однако я (не автор) разбираться с этим не хочу и как правильно уже подметили форумчане и не буду. И как закономерный результат - то что такой набор библиотек поддерживается/развивается только автором.
Поэтому я считаю очень важным вопрос правильного документирования и объяснения кода - и внутри самого кода - и в виде дополнительной документации ОБЯЗАТЕЛЬНО с примерами. С такими библиотеками будет очень просто работать - с одной стороны - кодеры, которые захотят как либо улучшить код - могу без проблем разобраться с ним - и добавить что либо там где надо будет очень просто. С другой стороны - программист которые не собирается вмешиваться в код - просто берёт библиотеки - печатает пример их использования - и пользует их на полную катушку.
Если смотреть как обычно организованы функции/процедуры - и их наборы - в других программно/аппаратных системах, то можно увидеть что их названия вообще то достаточно хорошо коррелируют (я бы даже больше сказал :D) с теми функциями которые они собственно и выполняют. Т.о. предлагается например для работы с памятью (кстати ведь есть вроде универсальный драйвер для всех типов памяти - однако где его взять в виде готового тулкита?) называть все процедуры mem_*
Для работы с файлами - дисковая подсистема - iofile_*
И т.п.
Т.о. я хочу с самого при разработке такого набора универсальных утилит (которых кстати я никогда не использовал :D) с самого начала сделать упор именно на ФОРМУ, а не на содержание, которое как мне кажется при хорошей форме - оформлении кодов и примеров пользования - будет так или иначе развиваться - охочие найдутся, даже я ;))).
Насчёт руководителя. Я согласен с CityAceE что без руководителя проект встрянет. Прежде всего по "непринципиальным" вопросам - вот хотя бы посмотреть чуток выше как люди чуть не в драку готовы идти по в принципе не важным вопросам. Роль лидера в этом смысле в том, что он будет брать на себя тяжесть выбора того или иного решения/подхода, а все остальные будут тянуться за ним - и реализовывать предложенный им подход. И вполне естественно, что какой то части этот выбор будет не нравится. В коммерческом проекте есть принцип - "тебе платят - ты работаешь", здесь же такой принцип малоприменим (? совсем не применим), потому человек, который будет руководить этим проектом должен уметь с одной стороны внятно и доступно объяснить для чего было выбрано то или иное решение и с другой стороны, люди, которые работают в команде, должны значительно уважать его авторитет, чтобы при первом же такого рода конфликте интересов не убежать сказав "здесь работаюти кодят одни ...ки, мне с ними не по пути."
P.S. Мне кажется экономить на исходниках глупо... одного диска TR-DOS хватит на очень большой набор библиотек, если же использовать псевдообъектный код, то на ещё большее. Подавляющее большинство более менее современных компиляторов поддерживают компиляцию/сборку с диска (даже мой любимый GENS). В крайнем можно ведь и на несколько дисков раскидать, потому размер файлов-исходников я считаю параметр, важность которого я оцениваю как "1" только от конца ;)
ДОЛЖЕН БЫТЬ ДОСТУПЕН
ИНТЕРФЕЙС С ЛЮБОЙ СРЕДОЙ ПРОГРАММИРОВАНИЯ. И точка.
Поэтому извраты вокруг ассемблера и ALASM в частности не
поддерживаю.
каки таки извраты? если про треп из соседней ветки, то там вообще по банану как передаются параметры (раз разговор зашел про них). и к чему тут упоминаются извраты с аласмом не понимаю...
зы. а я хочу интерфейс с аласмом для начала! (как вот заявлено) почему он отвергается? ;) лозунги нарушаем-с %)
каки таки извраты? если про треп из соседней ветки, то там вообще по банану как передаются параметры (раз разговор зашел про них).
Нет. Почему -- в соседней ветке и пишется же.
и к чему тут упоминаются извраты с аласмом не понимаю...
зы. а я хочу интерфейс с аласмом для начала! (как вот заявлено) почему он отвергается? ;) лозунги нарушаем-с %)
[/quote]
Речь не про то, чтобы с аласмом было несовместимо.
Речь про то, чтобы НЕ БЫЛО СОВМЕСТИМО ТОЛЬКО С АЛАСМОМ.
Вот и Griv про BGE вспомнил. Это радует. Поэтому предлагаю без фанатизма - начать с аналогии системы аля BGE. просто процедура и описание: что на входе, что на выходе, можно ли из ПЗУ юзать/нет, сколько регистров херит. И всё. Без прибамбасов. А каменты может не надо прям в исходнике ? Рядом, в текстовичке.
Речь не про то, чтобы с аласмом было несовместимо.
Речь про то, чтобы НЕ БЫЛО СОВМЕСТИМО ТОЛЬКО С АЛАСМОМ.
имхо вопрос надо ставить не так. то, что в других компиляторах приходится делать вручную или через >|<опу, в аласме можно сделать автоматически. вот и все.
гдето писалось про траблы создания плагинов к RC- создание таблиц релокации. это можно упростить!
имхо вопрос надо ставить не так. то, что в других компиляторах приходится делать вручную или через >|<опу, в аласме можно сделать автоматически. вот и все.
гдето писалось про траблы создания плагинов к RC- создание таблиц релокации. это можно упростить!
В данном случае, вручную -- это значит НИКАК!.
Таблицы релокации можно создать путём сравнения версий программ
откомпилированных по разным адресам. Кроме того, некоторые
компоновщики штатно умеют (тот же hitech-c). А вот таблицы патчей
для CALL -- это никто не умеет, ALASM+макросы == свой собственный,
ни с чем не совместимый, ассемблер.
... А вот таблицы патчей
для CALL -- это никто не умеет...MA80 (МОА) и M80 (CP/M) прекрасно умеют макросами создавать таблицы патчей.
Как пример см. драйвер электронного диска под ISDOS by MOA.
хех, вспомнил - в древнючем zx-review была софтинка, которая строила такие таблицы на базе двух скомпиленых под разные адреса блоков одного и того же исходника и присобачивала настройщик. вот только блоки должны умещаться в 48к памяти, да и все равно это полуручная работа
Таблицы релокации можно создать путём сравнения версий программ откомпилированных по разным адресам.
org #6000
<код>
org ($+255)&#FF00
label ds 256
и
org #789A
<такой же код>
org ($+255)&#FF00
label ds 256
Вот и сравнивай...
нормальные люди больше одного org'a в одной проге не юзают (object save не работает как минимум). я делаю так:
defs $-(($-1)&ff00) (мож накосячил - не помню =) у меня макрос сто лет назад написан)
а чаще так:
;macros lib
_ORGA equ 0
defmac _ORGG
\0 equ _ORGA
_ORGA equ (_ORGA+\1)
endmac
;end maclib
;prog:
_ORGA=$
_ORGG buf1,#0100
_ORGG buf2,#0300
округление до ровных адресов в макросе добавить по вкусу...
org #6000
<код>
org ($+255)&#FF00
label ds 256
и
org #789A
<такой же код>
org ($+255)&#FF00
label ds 256
Вот и сравнивай...
а ты правильно под релокатор пиши!
таблицы такие - генерить на месте или двигать :)
адрес программы тоже легко узнать
нормальные люди больше одного org'a в одной проге не юзают (object save не работает как минимум). я делаю так:
defs $-(($-1)&ff00) (мож накосячил - не помню =) у меня макрос сто лет назад написан)
Нормальные люди вообще DEFS для кода отписываемого на
диск не юзают. Я конечно понимаю, что hrust есть великий
рулез, но тем не менее, ещё с тех времён когда кроме mpack
ничего приличного не было, существовало нормальное решение,
когда все эти DEFS и извраты вокруг ORG затрагивали часть
области данных не отписываемую на диск. Для инициализации
писался код. И кроме того, вместо статического распределения
НИЧЕМ НЕ ХУЖЕ тривиальный аллокатор типа "стек", который
растёт вверх от конца программы. Или даже стек обыкновенный,
для чего он размещается не под телом кодового блока,
а в самом конце памяти. Делается просто: кодовый блок
размещается в REM-строке бейсик программы. А CLEAR ставится
на самый верх памяти. Суть в том, что в двух разных состояниях
программы отдельные статически выделенные блоки памяти
НЕ ИСПОЛЬЗУЮТСЯ и память тратится впустую. (Вот чего вечно
от спектрумистов слышно, что им памяти не хватает). Нормальный
аллокатор решает эту проблему. Её решает даже выделение
памяти на стеке. И выравнивание можно динамически, на ходу
любое выбирать.
адрес программы тоже легко узнать
ld hl, NNNN ; push hl, pop hl
ld (XX), hl
ld hl, XX+2
ld (hl), NN ; ret
call XX
...
ORG XX
XX: DS 3
Надо иметь три байта памяти. Ворос -- где их взять?
MA80 (МОА) и M80 (CP/M) прекрасно умеют макросами создавать таблицы патчей.
Как пример см. драйвер электронного диска под ISDOS by MOA.
Речь про то, как отличить АБСОЛЮТНО ВСЕ ВЫЗОВЫ, от нужных.
Вот как здесь, вручную, да можно. Но можно элементарно ошибиться
и записать код по-старому. Со всеми вытекающими последствиями.
Другое дело, можно создать макросы вида CALL, JP, LD и т.п...
Но это не всякий ассемблер позволит и сложность всей этой
макрообвязки получится сопостовимой с написанием собственного
ассемблера...
Так... :) :( Я уже загруз по уши... Ну, можно доходчиво мне объяснить так, чтоб я сказал: да моя прога, что пишу без этого всего не может - завтра же беру релокации и навороты, вставляю - и благодаря этому архиБыстро и легко доделываю свое произведение...
В данном случае, вручную -- это значит НИКАК!.
согласен. но аласм+макросы=hitech-c=ma80=m80=СРЕДСТВО РАЗРАБОТКИ
дающее на выходе одно и то же.
а создавать таблицу релокации по двум разным кодам- это еще больший изврат!
гм. интересно, какое из двух слов связки ALASM+macro вызывает приступ аллергии? щаз выясним...
как насчет предложения TASM+macro?
согласен. но аласм+макросы=hitech-c=ma80=m80=СРЕДСТВО РАЗРАБОТКИ
дающее на выходе одно и то же.
За ma80 не скажу, но вроде там специально ничего не предусмотрено. А с макросами -- тот же ALASM получается.
У hitech-c возможности ограничены только созданием таблицы релокации, для настройки кода на адрес, не более того.
А вот у ZASM -- нет ничего. Макросы есть, но ограниченные,
такого не позволяют.
а создавать таблицу релокации по двум разным кодам- это еще больший изврат!
Тем не менее -- оно работает, и оно доступно. Я беру любой
ассемблер и элементарно это делаю. Хоть в GENS, хоть в ZASM.
Вот в ZASM и делал, пока на Hitech не перешёл. Но hitech -- это
в писюке (или CP/M). А ZASM -- на спектруме.
гм. интересно, какое из двух слов связки ALASM+macro вызывает приступ аллергии? щаз выясним...
ALASM. ИБО ЗАСТАВИТЬ ПИСАТЬ СЕБЯ ТЕКСТ ИСКЛЮЧИТЕЛЬНО
ЗАГЛАВНЫМИ БУКВАМИ, В ИСКЛЮЧИТЕЛЬНО НЕВОЗМОЖНОМ, В ПЛАНЕ "ЮЗАБИЛИТИ" РЕДАКТОРЕ Я СЕБЯ НЕ МОГУ. Потому, что на рядом стоящем писюке есть нормальный редактор. И есть более-менее терпимый в ZASM.
И вопрос отнюдь не в GUI-интерфейса ZASM'a -- в писюке Vim в
xterm.
как насчет предложения TASM+macro?
TASM последний раз видел в 1997 году. Как раз ZASM 3.0 тогда
появился.
У hitech-c возможности ограничены только созданием таблицы релокации, для настройки кода на адрес, не более того.
а большее разве нужно? какая стоит цель?
на входе: исходный текст программы
на выходе: объектный код, который в идеале можно грузить по любому адресу (с предварительной настройкой соотвецно)
метод реализации: ЛЮБОЙ!!! в том числе и макросы, кросскомпилеры, ручная обработка, сравнение бинарников.
ALASM. ИБО ЗАСТАВИТЬ ПИСАТЬ СЕБЯ ТЕКСТ ИСКЛЮЧИТЕЛЬНО
ЗАГЛАВНЫМИ БУКВАМИ, В ИСКЛЮЧИТЕЛЬНО НЕВОЗМОЖНОМ, В ПЛАНЕ "ЮЗАБИЛИТИ" РЕДАКТОРЕ Я СЕБЯ НЕ МОГУ.
ну уж таким его создал автор изначально. можно попросить алко чтоб сделал поддержку маленьких букв редактором и компилятором (он различает регистр мнемоник).
а большее разве нужно? какая стоит цель?
на входе: исходный текст программы
на выходе: объектный код, который в идеале можно грузить по любому адресу (с предварительной настройкой соотвецно)
метод реализации: ЛЮБОЙ!!! в том числе и макросы, кросскомпилеры, ручная обработка, сравнение бинарников.
Цель такова, что вот есть N релоцируемых программ. Мы их загружаем
в память, настраиваем, и они каким-то образом начинают вызывать функции друг друга (из других программ, модулей, библиотек). При
том, что до загрузки ничего не известно, что по каким адресам располагается. Существует три, уже 100 раз тут писалось, метода:
1) используя функцию диспетчер, аргументом которой является
"идентификатор функции" в "чужом" программном модуле.
Это так называемый вызов через RST в том числе. Хотя можно
и через CALL, как, например, в CP/M -- CALL 0x05, а в регистре
C -- номер функции. Детали реализации скрываются за
функцией-диспетчером -- поэтому, возможно, это слишком
общий метод и его сравнивать с остальными не совсем
корректно. Но вот тормозной он -- это точно.
2) Прямой вызов. Для этого все CALL, JP, и даже LD HL, xxx и т.п.
должны быть пропатчены в вызывающей программе после
загрузки всех модулей. Требует формирования сложных
таблиц для патчей создаваемых сложной системой макросов
поверх ассемблера, или специальным ассебмлером. Требует
дисковой памяти порядка sum(Ki)+sum(Mi), где Ki -- число
вызовов внешних функций в i-том модуле, а Mj -- общее
число экспортирующихся функций в j-том модуле. Памяти
ОЗУ после настройки не требует. Но Ki -- достаточно велико.
3) Вызов через функцию-перенаправитель. Для каждой функции
из вызываемого модуля в вызывающий модуль ещё на этапе
компиляции включается специальная функция, состоящая
из одной команды JP xxx. Все вызовы к функциям "чужого"
модуля адресуются к этим функциям-перенаправителям.
А сами функции-перенаправители патчатся, после загрузки,
так, чтобы инструкция JP xxx указвала на действительный адрес
функции из вызываемого модуля. Данный способ отличается
от предыдущего тем, что вызов тормозней на 10 тактов и
памяти ОЗУ требует порядка sum(Mi)+sum(Nj), где Mi -- общее
число экспортируемых функций в каждом i-том вызываемом
модуле, Nj -- число внешних вызываемых функций в каждом
j-том вызывающем модуле.
Считаю, способ N3 наиболее перспективный. Он позволяет относительно легко в любом ассемблере получить нужный код,
он не накладывает чрезмерных накладных расходов на совершения
вызова функций, не требует много памяти как дисковой, так и ОЗУ.
Хотя по использованию ОЗУ он, проигрывает остальным методам.
Со способом N2 сравнивать бесполезно (0 байт), против способа
N1 проигрыш составляет порядка трёх байт на каждую вызываемую
внешнюю функцию в каждом модуле. При общем числе функций
порядка десятков, максимум сотни-другой, это вполне допустимый,
с моей точки зрения, расход памяти.
Способ N2 исключительно сложен в реализации, и требует
специальной поддержки от ассемблера, поэтому, с моей точки
зрения, в общем случае не применим и имеет смысл в каких-то
специфических случаях, например, когда исключительно критично
время вызова функции.
Способ N1 даёт слишком большие накладные расходы на вызов
функий и поэтому, аналогично, имеет смысл, опять же с моей точки
зрения, исключительно в специфических ситуациях. Например,
где время некритично, но очень критичен объём занимаемой
программной памяти.
Короче что-то мы отвлеклись от темы и полезли в дебри.
Надо уже что-то начинать.
Давайте откроем отдельную тему и назначим координатора, который прислушиваясь к мнению остальных будет выбирать из множества решений некоторое одно.
И остальные будут руководствоваться решениями координатора (иначе не будет никакой коллективной работы).
Если вы ещё с нами, тогда вперёд, иначе не вперёд ^_~
Для начала выберем координатора. Предлагайте кандидатуры, а CityAceE пескай выберет кого- нибудь одного.
1) Я. Много писал (и сейчас пишу ^_~) на спектруме. Наиболее известное - TargeT. Шарю в написании больших проектов (правда не на спеке, но думаю опыт пригодится).
CityAceE
12.12.2005, 02:58
1) Я.
Я за твою кандидатуру. Ведь дело даже не в опыте, хотя он безусловно очень важен, а ещё и в заинтересованности (увлеченности)...
Короче что-то мы отвлеклись от темы и полезли в дебри.
Надо уже что-то начинать.
Тебе начинать хоть прямо сейчас никто не мешает, не думал?
Для этого не нужно ровно ничего.
Давайте откроем отдельную тему и назначим координатора, который прислушиваясь к мнению остальных будет выбирать
Иными словами давайте поиграем в коммунизм. Я против коммунизма. Он даёт исключительно советские решения на выходе.
из множества решений некоторое одно.
Вот этого я и боюсь. Одно, исключительно советское в худшем
смысле этого слова: ни с чем не совместимое, и исключительно горбатое. И избавиться от него потом ну никак нельзя будет.
Ключевое слово *ОДНО*. Я бы предоставил свободу выбора
авторам программ. По крайней мере можно было бы посмотреть
какое решение приживётся эволюционным путём, а не посредством
насаживания свыше. Другое дело -- совместимость. Хотелось бы
иметь некий базовый уровень, от которого могли бы происходить
вариации по разным направлениям, но так чтобы тем или иным способом была возможность преобразования интерфейса к нужному
виду. Хотелось бы отделить интерфейс вообще от деталей его
реализации.
1) Я. Много писал (и сейчас пишу ^_~) на спектруме. Наиболее известное - TargeT. Шарю в написании больших проектов (правда не на спеке, но думаю опыт пригодится).
Вот возьми и напиши. Не в ассемблере, а свое видение проблемы организации программных интерфейсив, их несовместимости и возможности преобразования из несовместимых в совместимые,
и наконец проблемы идентификации интерфейсов.
Тебе начинать хоть прямо сейчас никто не мешает, не думал?
Для этого не нужно ровно ничего.
свои проекты я делаю и никого не спрашиваю.
сам по себе ZX SDK мне не нужен. для работы я использую свои наработки, и мне их достаточно.
мне интересен сам процесс.
Иными словами давайте поиграем в коммунизм. Я против коммунизма. Он даёт исключительно советские решения на выходе.
никто не заставляет.
Вот этого я и боюсь. Одно, исключительно советское в худшем
смысле этого слова: ни с чем не совместимое, и исключительно горбатое. И избавиться от него потом ну никак нельзя будет.
Ключевое слово *ОДНО*. Я бы предоставил свободу выбора
авторам программ.
тогда ничего не получится. если предоставить свободу выбора, то можно смело закрывать проект прямо сейчас, ибо результата не будет.
По крайней мере можно было бы посмотреть
какое решение приживётся эволюционным путём, а не посредством
насаживания свыше.
у меня нет лишних 20-ти лет на эксперименты.
Другое дело -- совместимость. Хотелось бы
иметь некий базовый уровень, от которого могли бы происходить
вариации по разным направлениям, но так чтобы тем или иным способом была возможность преобразования интерфейса к нужному
виду.
если будут всякие преобразования, это значит мниго лишней писанины. а если с ZX SDK писать придётся ещё больше чем без него, то значит он не нужен.
Хотелось бы отделить интерфейс вообще от деталей его
реализации.
да... ООП и другие умные слова.
это всё тормоза. если надо тормозоть, то возьми себе пэцэ. и gcc. и g++. и отделяй интерфейсы в абстрактных классах от реализации. и никого не спрашивай.
Вот возьми и напиши. Не в ассемблере, а свое видение проблемы организации программных интерфейсив, их несовместимости и возможности преобразования из несовместимых в совместимые,
и наконец проблемы идентификации интерфейсов.
Описывать проблемы можно 8 лет. А надо делом заниматься.
свои проекты я делаю и никого не спрашиваю.
сам по себе ZX SDK мне не нужен. для работы я использую свои наработки, и мне их достаточно.
[quote]
мне интересен сам процесс.
То-есть конечный результат не важен.
никто не заставляет.
Всем (пионерам) известно -- в колхозы никого не заставляли.
тогда ничего не получится. если предоставить свободу выбора, то можно смело закрывать проект прямо сейчас, ибо результата не будет.
Отсутствие результата -- тоже результат. А будет он или не ещё
вопрос. Мы имеем примеры как и в случае наличия таковой свободы
и при её отсутствии результаты получались самые разные. Есть
шанс, что будет. И это ещё зависит от того, что именно считать результатом. В конечном счёте это зависит от конкретных людей
(тебе -- никто не мешает...)
у меня нет лишних 20-ти лет на эксперименты.
А лишнее время на бессмысленный "процесс" стало быть есть?
если будут всякие преобразования, это значит мниго лишней писанины. а если с ZX SDK писать придётся ещё больше чем без него, то значит он не нужен.
Это неизвестно больше или нет. Возможно больше, но не факт
что намного. Нужно хотя бы иметь возможность оценить насколько.
Можно взять, например, модульную систему (C) Vitamin и мою, и
посмотреть, больше будет или нет.
да... ООП и другие умные слова.
это всё тормоза. если надо тормозоть, то возьми себе пэцэ. и gcc. и g++. и отделяй интерфейсы в абстрактных классах от реализации. и никого не спрашивай.
Описывать проблемы можно 8 лет. А надо делом заниматься.
Я так думаю, это тебе взять что-ли пэцэ, g++, позаниматься делом...
А когда энтузиазма поубавится, уже за что-то браться. Просто иначе
получается -- тут говорят делом надо заниматься, а каким именно делом никто не может толком определиться. Каков результат-то должен быть? Ответь хоть бы для себя на этот вопрос, сформулируй задачу себе. Я вот за себя могу сказать: Я ОТВЕТА НА ЭТОТ ВОПРОС
НЕ ЗНАЮ. И ПОИСК ОТВЕТА НА ЭТОТ ВОПРОС -- ЭТО ЛИШЬ ПЕРВЫЙ
МАЛЮСЕНЬКИЙ ШАЖОК В ОЧЕНЬ ДЛИННОЙ ДОРОГЕ, где писать какой-код -- самый последний, завершающий шаг.
Ну и в итоге ? Поругались ? А результаты?
Ну и в итоге ? Поругались ? А результаты?
А результаты несколькими страницами выше. Рассмотрены самые разные варианты, их плюсы и минусы, личные предпочтения.
Имхо, zx sdk должно существовать в виде исходников, причем в текстовом виде и безо всяких специфичных для каждого ассемблера штук. Плюс документация. А уж обертку для вызова каждый напишет сам...
Всем (пионерам) известно -- в колхозы никого не заставляли.
т.е. когда нечего сказать, надо переходить на личности и нести бред не по теме.
А лишнее время на бессмысленный "процесс" стало быть есть?
на бессмысленный нет. если будет результат (на что я надеюсь) то есть.
Это неизвестно больше или нет. Возможно больше, но не факт
что намного. Нужно хотя бы иметь возможность оценить насколько.
Можно взять, например, модульную систему (C) Vitamin и мою, и
посмотреть, больше будет или нет.
модульная система это несколько не в тему. модули нужны тогда когда они нужны. допустим драйвера для HDD, CD-ROM и т.д.
а в данном случае динамически загружаемые модули не нужны.
Я так думаю, это тебе взять что-ли пэцэ, g++, позаниматься делом...
да я вроде как бы работаю. правда опенсорсовой фигнёй в линухе не страдаю и пишем мы под нормальные оси (виндовс)
А когда энтузиазма поубавится, уже за что-то браться.
когда энтузиазма поубавится, бесплатно я делать ничего не буду ^_~
Просто иначе получается -- тут говорят делом надо заниматься, а каким именно делом никто не может толком определиться. Каков результат-то должен быть? Ответь хоть бы для себя на этот вопрос, сформулируй задачу себе.
я уже писал (на первых страницах), каким я хочу видеть ZX SDK.
могу сформулировать ещё раз.
Ну и в итоге ? Поругались ? А результаты?
Как уже говорил Витамин, результаты вроде как есть.
Но они такие... Как бы никакие. С чем пришли с тем и ушли.
Т.е. отсутствие результата - тоже результат ???
По словам Витамина: каждый желающий выкладывает свою процедурку с подробным описанием и всё. А координатор смотрит - куда ее пристроить / была / не была и тп. Я правильно понял ?
Что ж выходит по словам Синуса ? Не то же ?
Т.е. отсутствие результата - тоже результат ???
Выходит что так.
По словам Витамина: каждый желающий выкладывает свою процедурку с подробным описанием и всё. А координатор смотрит - куда ее пристроить / была / не была и тп. Я правильно понял ?
вроде как так. только по моему мнению координатор в таком случае не нужен, ибо была / не была чел в состоянии и сам посмотреть, а куда пристраивать если нет системы? тоже некуда. лучше уж на opensource.zx или как там он называется в таком случае сорс выложить.
Что ж выходит по словам Синуса ? Не то же ?
почти. только нужно в начале определить систему. ну а потом вперёд.
Да, но на openSource нет детальных доков к исходникам :( Да вообще доков нет. А тут и начинается "мне проще/быстрее самому написать, чем в чужом разбираться"... поэтому давайте "определять систему", что-ли ???
только нужно в начале определить систему.
Предлагаю составить иерархическую структуру исходников с процедурами (думаю именно они будут востребованы, исходники прог целиком лежат на opensource)
... таблицы патчей для CALL -- это никто не умеетХочу еще раз коснуться вопроса создания релоцируемых программ.
Как известно ассемблеры M80, RMAC (CP/M-80) и кросс ассемблер
MA80 в результате копиляции исходника создают файл с расшире-
нием REL - перемещаемый обьектный код, формат которого разра-
ботан фирмой Microsoft.
Для создания исполняемого обьектного кода производится сборка
(линковка) отдельных модулей программы с помощью линковщика
L80 (CP/M-80) или кросс-линковщика MLINK.
Эти линковщики расчитаны на создание исполняемых модулей для
запуска программ под управлением CP/M-80, тоесть по умолчанию
расчитанных на их загрузку и запуск с адреса 100h (начало TPA).
Начиная с 1979 года фирма Digital Reserch начала поставки
операционной системы MP/M - Multi-Programming Monitor Control
Program.
В этой системе, в отличии от CP/M-80, предполагалась возможность
запуска программ с произвольного адреса и поэтому наряду с
файлами COM, которые загружались и запускались с адреса 100h,
были добавлены файлы PRL - Page Relocatable Programs.
В структуре этих файлов присутствует заголовок длиной в два
логических сектора (256 байт), исполняемый код и третий блок,
который содержит битовую таблицу признаков смещения - таблица релокации.
Для создания файла с такой структурой, фирма Digital Research
разработала линковщик LINK80. Эта программа из REL-файлов
создает PRL-файл, который можно загрузить в произвольный
адрес памяти Z80 (с дискретом в 100h), настроить все адреса
в соответствии с таблицей смещений и запустить на исполнение.
В MP/M использовались такие PRL файлы нескольких модификаций:
1) PRL - Page Relocatable Program.
2) SPR - System PRL.
3) RSP - Resident System Process.
4) RSX - Resident System Extensions.
LINK80 также позволяет создавать OVL (оверлейные) файлы,
которые имеют PRL заголовок, но являются не перемещаемыми.
Этот линковщик очень часто присутствовал на системных дисках
CP/M-80, но поскольку синтаксис его командной строки сильно
отличался от L80, то он практически не использовался.
Кому интересно, описание этого линковщика есть на:
http://www.retroarchive.org/cpm/archive/unofficial/
captain cobalt
22.12.2005, 08:56
да... ООП и другие умные слова.
это всё тормоза. если надо тормозоть, то возьми себе пэцэ. и gcc. и g++. и отделяй интерфейсы в абстрактных классах от реализации. и никого не спрашивай. Рассмотрим "драйверы расширенной памяти" (сверх 128К)
Это пример отделения интерфейса (например, "установить страницу") от реализации (действительно устанавливающей страницу через порты конкретного клона).
Такие "драйверы" используются, например, в ассемблере alasm, который показывает довольно неплохую производительность. Поэтому утверждение о пц неверно. А эти "драйверы" радикально повышают гибкость alasm.
как обычно следует выдирание куска текста из контекста, не взирая на отсутствие смысла.
если captain cobalt соблагоизволит прочитать страницы 1-8 из этой темы, то где- то там, в недрах символов и байтов кроется истина, что ДРАЙВЕРЫ НУЖНЫ но не всегда и не везде.
и перед принятием некого паттерна программирования надо немного пораскинуть мозгами, и подумать о областях его применения.
и что есть задачи где применение данного паттерна ведёт к уменьшению стоимости разработки (стоимость = потраченное время + сложность) а есть задачи, где применение тех же концепций наоборот, ведёт к дикому возрастанию стоимости.
captain cobalt
22.12.2005, 13:54
Коль скоро "драйверы нужны", то нужен и поддерживающий механизм.
Механизм отделения интерфейса от реализации.
Коль скоро "драйверы нужны", то нужен и поддерживающий механизм.
Механизм отделения интерфейса от реализации.
Наконец-то. Прогресс налицо.
Нужен механизм отделения собственно интерфейса от его (интерфейса) реализации. То есть для представления одного интерфейса могут использоваться разные реализации этого самого интерфейса, за которыми
уже, в свою очередь, может сидеть один и тот же код драйвера. Вот так лучше?
интерфейс-1 интерфейс-2 интерфейс-3
| | |
| | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
преобразователь интерфейсов
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | |
интерфейс-1 интерфейс-2 интерфейс-3 интерфейс-4
| | | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
драйвер
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
То-есть что имеем. Имеем интерфйес A. Имеем драйвер
реализующий этот интерфейс. Но собственно интерфейс к
драйверу может быть реализован различными способами.
Равно как и интерфейс использующей его прикладной программе.
Нужна прокладка между ними. "Преобразователь интерфейса".
Который может преобразовать как интерфейс между программой
и драйвером, так, возможно, при необходимости, интерфейс
самого драйвера. Вот в чём суть.
captain cobalt:
опять двадцать пять.
итак, я говорил
ДРАЙВЕРЫ НУЖНЫ
однако!, я говорил так же
но не всегда и не везде
как я уже говорил
как обычно следует выдирание куска текста из контекста
CityAceE
13.01.2006, 15:49
Похоже никто идею не поддержал. Sinus, ну ты же хотел возглавить проект! Обсуждать что-то бесполезно. Проверено неоднократно - нужно действовать!
Похоже никто идею не поддержал. Sinus, ну ты же хотел возглавить проект! Обсуждать что-то бесполезно. Проверено неоднократно - нужно действовать!
Действуй. Никому конкретному никто конкретный не мешает.
Только вот мне, например, есть занятия и по-интересней во-первых,
во-вторых сиди пиши целый день (не в форумы ;-), а потом придя
домой ещё писать что-то (кроме как в форумы) -- ну никакого желания.
Я думаю, у многих так.
правильно. так оно и есть.
как поговаривал товарищь breeze - "PIздеть - не мешки ворочать" ;)
Surfin_Bird
14.01.2006, 23:47
Жаль. Идея была рульная. Можно бы было делать DevKit-ы. Например, а бы купил AdventureGamesDevKit и т.д. Эх...
Идея была рульная, но никто (и я в том числе ^_~) кроме 3.14 здежа ничем её не поддержал.
captain cobalt
17.01.2006, 00:17
captain cobalt:
опять двадцать пять. Чтобы это утверждение было осмысленным, а обсуждение конструктивным, неплохо бы вкратце объяснить, когда драйверы нужны, а когда не нужны, и почему.
captain cobalt
17.01.2006, 00:18
Наконец-то. Прогресс налицо.
Нужен механизм отделения собственно интерфейса от его (интерфейса) реализации. То есть для представления одного интерфейса могут использоваться разные реализации этого самого интерфейса, за которыми
уже, в свою очередь, может сидеть один и тот же код драйвера. Вот так лучше?
интерфейс-1 интерфейс-2 интерфейс-3
| | |
| | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
преобразователь интерфейсов
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | |
интерфейс-1 интерфейс-2 интерфейс-3 интерфейс-4
| | | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
драйвер
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
То-есть что имеем. Имеем интерфйес A. Имеем драйвер
реализующий этот интерфейс. Но собственно интерфейс к
драйверу может быть реализован различными способами.
Равно как и интерфейс использующей его прикладной программе.
Нужна прокладка между ними. "Преобразователь интерфейса".
Который может преобразовать как интерфейс между программой
и драйвером, так, возможно, при необходимости, интерфейс
самого драйвера. Вот в чём суть. Нет не так.
Подобные "преобразователи интерфейсов" могут быть реализованы в виде отдельных модулей и динамически загружаться и компоноваться при необходимости.
То есть ситуация "много интерфейсов - одна реализация" особо ничего не даёт, и приводит лишь к избыточному коду.
Гораздо важнее ситуация "один интерфейсов - много реализаций", при котором через один интерфейс могут вызываься разные реализации, причём конкретная реализация определяется динамически во время исполнения. В ООП это называется "полиморфизм". Лучше всего если реализации можно подключать и отключать во время исполнения.
Для реализации полиморфизма обычно используются "виртуальные функции". К сожалению, понадобится компилятор, который умеет автоматически строить таблицы виртуальных функций. А такого нет.
Потому предлагается упрощённый вариант: процедурные переменные aka казатели на процедуры. Это не обязательно адреса. Скорее даже наоборот не адреса, учитывая страничную модель памяти. Просто некоторый хэндл. Вероятно, двухбайтового числа будет достаточно. Этот идентификатор выдаётся во время загрузки и динамической компоновки модуля, содержащего реализацию интерфейса. И будет специальная процедура для вызова процедуры через хэндл. Программист будет передавать хэндл в качестве аргумента и по нему будет вызываться нужная реализация.
К вопросу о динамических библиотеках для спектрума:
http://www.nedopc.org/nedopc/shaos/libman_r.shtml
В-кратце - это менеджер библиотек, который был создан мною в 2002 году для компьютера Спринтер (под голимый Спектрум переделать - дело пары вечеров). Библиотеки для такого менеджера представляют из себя куски перемещаемого (с шагом 256 байт) кода размером менее 16К, которые грузятся менеджером в фоновую память и по хендлу можно вызывать отдельные функции этих библиотек, причем программист может и не знать в какой конкретно странице памяти и по каким адресам сидит та или иная библиотека. Если интересно - сделаю универсальную реализацию, покрывающую самые популярные клоны.
я тут долго отчего то в тему не заглядывал, она тут мирно катилась
Вот у меня есть следующие соображения:
Касательно способов вызова - было сказано в http://zx.pk.ru/showpost.php?p=32310&postcount=67
и много копий было сломано в http://zx.pk.ru/showthread.php?t=1811
Потому я так понимаю способ вызова через RST отклоняется и остаётся два способа - кернальный (начинается цепочкой JP) и модульный (начинается таблицей релокации).
Бесполезно здесь спорить об их нужности, потому будем принимать их вместе.
Касательно интерфейса вызовов - использовать можно регистры, стек, указатели. Каждый из методов имеет как достоинства так и недостатки. А потому каждый из них имеет право на жизнь - в силу специфики. Я так понял что невозможно осуществить передачу данных указателем согласно интерфейсу Hitech-C, если это так то его (возможно) нужно дорабатывать. Вообще моё личное мнение, что способ передачи информации (стек или указатель) в конечном итоге мало скажется на производительности(больше/меньше). Это связано с тем, что придётся работать в принципе с теми же данными которые реализуются (читаются/пишутся) вообще то теми же системами команд, потому спор касательно передачи параметров - через стек или через указатель - так же считаю не существенным.
Теперь касательно библиотек - они В ЛЮБОМ СЛУЧАЕ нужны, Станислав уже предлагал метод - просто пробовать написать что нибудь совсем примитивное - на чём собственно будет отлаживатся вся система SDK.
Ставим цель - написание SDK
Ставим задачу - отлаживание SDK на примере игры "Сапёр"
Необходимо создать следующие процедуры:
- Процедура пиликания - при удачном отгадывании мины при взрыве
- Процедура обработки курсора - курсор ложится поверх имеющейся картинки, запоминает что он собой затирает и потом (второй вызов или вызов в заданную точку этой же процедуры) восстанавливает фон
- Процедура рисование окон - не атрибутное рисование а полноценное, допущение - нет необходимости запоминать фон под окном
- Процедура печати текста - печать текста в заданном окне, параметрами являются ширина окна и высота впечатываемого текста - т.е. предложения текст автоматически разбиваются на слова и если слова не помещается то оно переносится
- Процедура опроса клавиатуры и манипуляторов - мышки и джойстиков
Принимаются варианты каждой из дискретных указанных выше процедур - просьба не выкладывать готовое всё-в-одном.
Соглашения: каждая процедура должна быть документирована. Обязательно наличие примеров использования (для реализации указанной задачи).
Aleksey Senilov (500:8332/1)
03.02.2006, 16:35
Привет тебе, _/Alexander/_!
02 декабря 2005 19:37, Alexander Bondarenko писал(а) Stanislav Yudin:
Вот это самое сложное, обычно докy-то и лень писать...
Если определен стандартный шаблон описания функции/процедуры, то в общем-то не так и трудно доку написать. Какая информация нам нужна?
1. Hазвание модуля.
2. Hазвание функции/процедуры.
3. Входные (аргументы) и выходные (результат) параметры.
4. Возможные ошибки и исключения.
5. Требования к другим модулям.
6. Примерные размер и время выполнения.
7. Подробное описание действия функции.
8. Ссылки на описания используемых функции и структур.
9. Автор(ы). :)
Вроде бы этого достаточно.
До новых встреч! С уважением, Тхэнн.
... Nereal was created for us
а где продолжение? Друзья мои - подтягиваемся!
Rubts0FF
05.03.2006, 06:46
Х-м, на нашем форуме любая, даже хорошая, идея превращяется во флейм. Х-м.:(
Раньше на Спектруме я сталкивался с такой проблемой, что когда в голову приходила какая-то идея, то основную часть времени для её проверки тратилась на обвязку программы, интерфейс и т.д. У каждого автора нарабатывалась какая-то библиотека процедур, алгоритмов, заготовок и т.д., которыми автор пользовался при написании своих программ. На память сразу приходят программы Сергея Ханциса (кстати, не так давно Сергей зарегистрировался на этом форуме) Screen Manager и другие, названия которых я запамятовал. Программы Сергея были полезны, удобны и при этом внешне похожи между собой (как собственно и подавляющее большинство программ, написанных под Windows) из-за того, что в каждой своей программе автор использовал свои библиотеки процедур. Вспоминая график выхода программ Сергея, я предполагаю, что на написание каждой последующей программы у её автора уходило меньше времени, так как процедуры интерфейса были написаны и отлажены, а автор бросал свои главные усилия не на организацию интерфейса, а на логику работы самой программы. Помню потом в электронных изданиях были призывы делиться своими процедурами и создать некий банк таких процедур. Как я понимаю, эта идея по ряду причин так и не получила большого развития и заглохла. Позже я попробовал программировать на ассемблере под PalmOS. Это был мой первый опыт программирования не на Спектруме и под настоящую операционную систему. На Палме я увидел, что мне нет надобности самому рисовать окна, отслеживать нажатия на кнопки и т.д. - всё это делает за меня операционная система, а мне необходимо лишь вовремя вызвать нужные процедуры с требуемыми параметрами. Что и говорить - удобно! С другой стороны есть и такая категория людей, которые может быть и хотели что-то написать под Спектрум, но их пугает ассемблер и тот факт, что всё придётся делать самому и с нуля...
Откуда взялся этот стереотип "велосипеда" ? Если пишется !!!нормальная!!! программа одного и того же автора, то в ней повторяется лишь стиль, а не процедуры. Конечно, есть одинаковые процедуры, но их можно пересчитать по пальцам. Как правило ZX'ер пытается максимально ускорить свой код, а это значит, что лишний раз он не будет делать CALL, и простая процедура умножения может уменьшиться на один-два цикла, ради скорости. Если всё строить на готовых библиотеках, то в итоге код обростает торможением. После чего библиотека пригодна для написания "карт" или "минёров", и да же в них карты будут дёргаться или вообще просто появляться.
Может я в чём-то заблуждаюсь ? Сколько не писал программы на СИ, ПАС, ВАСИКе, - я постоянно сталкиваюсь, что все эти библиотеки не работают как нужно. То на другой версии винды чего-то не поддерживается, то через час что-то перекосится и процесс виснет. Одно дело, когда делаешь какой-нибудь конвертер, он в процессе переглючит, пользователь как всегда плюнет в экран, и перезапустит, а с вас никакого спроса, как и с автора библиотеки. А представьте себе, - делаешь прибор, пишешь софт, и всего-то соединяешь прибор по простому COM'у. Его ставят на завод, запускают бумагоделательную машину, и через час вдруг завис "дрюйвер" COM-PORT'а. И, соответственно завод больше не приобретёт прибор нашей компании. Вот так было, когда на нашей фирме работали программисты, закончившие институты и имеющие учёные степени. Сколько я не писал проектов, всегда всю обвязку делал сам, начиная от COM-PORT'а, кончая USB, ETHERNET, VIDEO, KEY и всё остальное ... Не было ни одного отказа ... И главное, не нужен лицензионный виндовс, не нужно платить всем подряд за использование !!!очень!!! не качественных компонентов и тех же SDK. И после этого вы говорите, что не нужно изобретать велосипед. Конечно, если делать "мышки(манипулятор)" или писать "смотрелку картинок" этого хватит. А более серьёзное ? Хотя каждую программу нужно писать на 100%, не смотря на то, что она делает.
А теперь я помечтаю...
"Я включаю свой Скорпион и вставляю в него дискету подписанную как ZX_SDK, а рядом с собой кладу стопку отпечатанных листов, имеющих аналогичный заголовок. Так-с... Ну что ж, сегодня пожалуй для разминки напишу текстовый вьювер... Итак, приступим... Грузим с дискетки ALASM... Так, готово.. Ну-ка, где тут у нас файлик MAIN.H? Есть, загрузили... Ага, вот в файлике и список инклудов... Так, в нашей программе клавиатуру опрашивать будем, так что INCLUDE "KEYS.H", оставляем, а вот работа со спрайтами сегодня не предвидится, так что строчку INCLUDE "SPRITES.H" прячем точкой с запятой, или нет, лучше сотрём, сэкономив место в исходнике. А для вывода текста мы будем использовать 64 и 40 символов в строке, так что INCLUDE "TEXT64" и INCLUDE "TEXT40" оставляем... Смотрим дальше... [ПРОШЛО НЕСКОЛЬКО МИНУТ] Ну вот, вроде бы все нужные процедуры отобраны... Перемещаемся ниже по MAIN.H... Ага, стоп, вот он главный цикл программы! Стек, пожалуй, поднимем чуть повыше... Так, с IM2 сегодня не работаем, так что этот блок отделяем точками с запятой... Эти несколько строк тоже удалим, так как в этом проекте они нам не потребуются... А сюда мы вставим вывод окна... Как там у нас называется эта процедура? Ну-ка откроем нашу распечатку... Ага, вот они процедуры отвечающие за вывод окон, а вот и нужная процедура WIN_DRAW с описанием вводных данных... Так, загружаем регистры, вставляем WIN_DRAW... [ПРОШЛО НЕСКОЛЬКО ЧАСОВ] Уф, ну что ж, отладка программы закончена... ждём минуточку, пока программа откомпилируется, скомпрессируется и к ней будет добавлен BASIC-загрузчик. Ну вот, у нас на диске программа, готовая к распространению..."
А для чего я писал свой компилятор? Он именно это и делает! Всё, что сверху описано, уже реализовано. Наработку библиотек - за вами. Но не нужно отбирать, можно описать процедуры так, что использовав любую из них в тексте, она автоматом добавится в код. Ну, про компрессию и готовый загрузчик я уже устал писать ... Правда компиляция происходит на ПиЦи, а не ZX’е, поскольку я уже устал на ZX’е писать прогу по кускам, каждый раз думая как бы для отладки сделать так, что бы не убить в памяти ассемблер. На своём языке я написал игру Wanderlust, занявшая вообще всю 128-ую память и потратил на это две недели. Сейчас пишу игру Surgical Fantasy. Если бы был удобный графический редактор, редактор фонтов, соответственно редактор текстовки под этот фонт, то уже давно бы закончил и этот проект. А так приходится писать самому, благо уже заканчиваю, а то руки чешутся от того, как хочется закончить игру.
Мне кажется, что этот форум - хорошее место для рождения и поддержки подобного проекта. Здесь на форуме присутствует достаточное количество людей, которые написали не одну добротную программу и каждый их них решал множество задач по созданию оболочки программы и т.д. и т.п. Этот опыт очень ценен!
Но, этот опыт привёл к разделению на тех, кто пишет в основном на библиотеках, и тех, кто пишет в основном на “велосипедах”. Я отношусь к тем, кто любит прилеплять реактивный двигатель к велосипеду. И мне для разработки нужно:
+ 1.00 Асм с:
+ 1.01 Пакером.
+ 1.02 Loader-Creator.
+ 1.03 Возможность работы с метками, которые будут в будущем.
+ 1.04 Возможностью запаковывать части кода, используя один из другого.
+ 1.05 Иметь плейер PT3 с возвратом на каком POS/LINE мы находимся.
- 2.00 Графический редактор с:
- 2.01 Редактирование изображения до 65536х512 пикселей.
- 2.02 Редактирование фонта до 256х256 пикселей каждый символ.
- 2.03 Редактирование спрайтов и возможность их разукрасить.
- 2.04 ГЛАВНОЕ – Редактирование двух экранных изображений.
- 3.00 Музыкальный редактор.
+ 4.00 Редактор текста для ASM’а
(+ Есть)
(- Нет)
Я знаю, что есть графический редактор, но я в них не могу получить нормальный, готовый к употреблению файл. А сидеть и придумывать способы как вырезать кусок изображения, превратить его в спрайты, а если ещё нужно сделать двух экранную, то вообще - один Бог в помощь. Поэтому в последней моей игре WanderLust, для спрайтов написан один конвертор, который настраивается и выдаёт полностью готовые спрайты, да ещё их запаковывает, и делает отдельным куском, который подгружается в страницу и автоматически используется в игре.
Музыкальный редактор, близкий к употребляемому - я видел только у Alone Coder’а (PT3) и BACA&LAVE (DMM). Остальное очень не удобное.
Здесь можно было бы создать список самых востребованных процедур по работе с клавиатурой, мышью, дисководом, жестким диском, памятью, часами, выводом текста, символов, спрайтов, всякого рода окон, кнопочек, чек-боксов и т.д. и т.п. Определиться с наиболее универсальными и удобными методами вызова этих процедур и хорошо их Основная идея: Создать здесь на форуме некий конструктор, состоящий из процедур, заготовок и документации, который поможет быстро создавать качественные программы.
Всяческие процедуры с мышками, FDD, HDD – хорошая идея. Хотя, например FDD. Тянет за собой обработку системных переменных. Так же менеджер памяти, а вдруг и это очень вероятно, что я захочу его поместить начиная с 23296, да бы была возможность выделять всю память до байтика. Ну и после всё это соединю, думаю, что библиотеки начнут ссориться. А вот если разбить каждую библиотеку на самые важные элементы, например FDD:
- Init System Vars
- Read TR
- Write TR
- и т. д.
Это дело, но всякие печати символов, часы, отображение курсоров, наложение спрайтов лично мной бы вряд ли использовалось. Разве что посмотреть как делают другие.
У меня есть библиотека, которую я использую, но она почти не пополняется, там лежит два десятка процедур, остальное не повторяется от программы к программе.
Я знаю, что далёк от стиля программирования, которым следуют большинство из тех, кто обсуждает эту тему, поэтому извиняюсь, что влез в разговор.
А представьте себе, - делаешь прибор, пишешь софт, и всего-то соединяешь прибор по простому COM'у. Его ставят на завод, запускают бумагоделательную машину, и через час вдруг завис "дрюйвер" COM-PORT'а. И, соответственно завод больше не приобретёт прибор нашей компании.
Во первых: неизвестно, почему у Вас там всё через час зависло. Может Ваша же вина, в Вашем "софте".
Во вторых: только ОЧЕНЬ недалёкие люди могут строить АСУ ТП под управлением виндовс. Виндовс - для офиса, а в такие места - UNIX, QNX.
Вот так было, когда на нашей фирме работали программисты, закончившие институты и имеющие учёные степени. Сколько я не писал проектов, всегда всю обвязку делал сам, начиная от COM-PORT'а, кончая USB, ETHERNET, VIDEO, KEY и всё остальное ... Не было ни одного отказа ... И главное, не нужен лицензионный виндовс, не нужно платить всем подряд за использование !!!очень!!! не качественных компонентов и тех же SDK.
Как я понимаю, Вы написали свой собственный "виндовс", со всеми драйверами-библиотеками. Что же, браво!! :v2_clapp:
ЗЫЖ не зря, не зря Вас в своё время некто Andrew W Miheev из фидошной эхи ZX.Spectrum отправлял в ВУЗ...
Во первых: неизвестно, почему у Вас там всё через час зависло. Может Ваша же вина, в Вашем "софте".
Винда не наша, а БлинаГейтса. И в моём софте не виснет, ибо он у меня начинается с команды ASM ... Проверено временем, я же писал, что отказов небыло ...
Во вторых: только ОЧЕНЬ недалёкие люди могут строить АСУ ТП под управлением виндовс. Виндовс - для офиса, а в такие места - UNIX, QNX.
За 10 лет работы в этой сфере о "UNIX"ах, как и о Виндовсах я слышу в большинстве случаях от отечественных коллег. Все эти ОСи зарубежники редко используют для серьёзных управлений. В остальных случаях никто не хочет рисковать и делает полностью автономные системы. Есть микроконтроллер, есть датчики и нет ни КВУНИКСОВ ни ВИНДОВСОВ.
Как я понимаю, Вы написали свой собственный "виндовс", со всеми драйверами-библиотеками. Что же, браво!! :v2_clapp:
Я писал о качественном программировании. У всех виндовсах, как и у досах, так и у квуниксах есть проблема с COM-портом. Почему я и вспомнил. И всё что в оправдание придумывают программисты - глюк материнки, системы или ещё чего-нибудь. Однако я смело использую два ком-порта на том же одном IQR, и нет проблем, потому что не пользуюсь библиотеками.
Вот и всё что я хотел сказать ... А виндовс и вправду писали, только не сам видовс, а оконное оформление, однако - так можно сказать, что написал я не винду а WORK BENCH ...
ЗЫЖ не зря, не зря Вас в своё время некто Andrew W Miheev из фидошной эхи ZX.Spectrum отправлял в ВУЗ...
Какой ВУЗ ? Если Вы, вместе с Andrew W Miheev, хотите показать свой IQ, то просто делайте. Лишь слабо интеллектуальный человек пытается кому-то указать на интеллект да ещё отправить в ВУЗ. Каждый делает так, как умеет, и писать можно хоть на ВАСИКЕ, только отточить нужно на 100%, а не ссылаться на чи-то глюки.
Вот и пошли споры ... Нет, что бы объедениться и что-то сделать ... Судя по всему Вы и Andrew W Miheev закончили ВУЗ, добавим в эту тему ПО ТЕМЕ удобные и работающие процедуры для создания библиотек.
Винда не наша, а БлинаГейтса. И в моём софте не виснет, ибо он у меня начинается с команды ASM ... Проверено временем, я же писал, что отказов небыло ....
Вообще то я писал не "винда Ваша", а "вина Ваша". Читайте внимательнее!
За 10 лет работы в этой сфере о "UNIX"ах, как и о Виндовсах я слышу в большинстве случаях от отечественных коллег. Все эти ОСи зарубежники редко используют для серьёзных управлений. В остальных случаях никто не хочет рисковать и делает полностью автономные системы. Есть микроконтроллер, есть датчики и нет ни КВУНИКСОВ ни ВИНДОВСОВ
Давайте определимся для начала, что Вы подразумеваете под "серьёзными управлениями"? Если градусник/часы на панели ценника бензоколонки, то соглашусь - рисковать здесь не стоит, и просто необходимо сделать автономную систему. Если же речь идет об управлении/навигации хотябы легкомоторным самолетом, не говоря уж об авианосце, например, то "зарубежники" во всю используют и виндовс и QNX.
Я писал о качественном программировании. У всех виндовсах, как и у досах, так и у квуниксах есть проблема с COM-портом. Почему я и вспомнил. И всё что в оправдание придумывают программисты - глюк материнки, системы или ещё чего-нибудь. Однако я смело использую два ком-порта на том же одном IQR, и нет проблем, потому что не пользуюсь библиотеками.
Что за проблема?
Вы это смело делаете потому что знаете, что ОДНОВРЕМЕННО ничего у вас на обеих портах не произойдет, а не потому, что Вы не пользуетесь библиотеками.
Какой ВУЗ ? Если Вы, вместе с Andrew W Miheev, хотите показать свой IQ, то просто делайте. Лишь слабо интеллектуальный человек пытается кому-то указать на интеллект да ещё отправить в ВУЗ. Каждый делает так, как умеет, и писать можно хоть на ВАСИКЕ, только отточить нужно на 100%, а не ссылаться на чи-то глюки.
Не знаю, что хочет показать Andrew W Miheev, а у меня конкретно нет никакого желания и времени что то доказывать Вам, тем более показывать IQ. Все сказано и доказано Вам ДО меня и в этом треде и ранее в более других местах. Кроме того, на Ваш интеллект лично я никоим разом не указывал, наоборот, судя по тому, что Вы самостоятельно пишете "обвязку" COM, ethernet, USB я просто восхищен Вашими интеллектуальными способностями!
Вот и пошли споры ... Нет, что бы объедениться и что-то сделать ... Судя по всему Вы и Andrew W Miheev закончили ВУЗ, добавим в эту тему ПО ТЕМЕ удобные и работающие процедуры для создания библиотек.
[/QUOTE]
Да кудыж нам серым - убогим... Давайте уж лучше Вы, у Вас этих процедур ажно 20 штук накопилось. Видимо по 3 на COM, ethernet, USB, а остальные 11 - WORKBENCH!
На Вашу игру Wanderlust можно посмотреть?
Вообще то я писал не "винда Ваша", а "вина Ваша". Читайте внимательнее!
Изначально именно Вы прочитали не внимательно я сказал - "РАБОТА БЕЗОТКАЗНА"
Давайте определимся для начала, что Вы подразумеваете под "серьёзными управлениями"? Если градусник/часы на панели ценника бензоколонки, то соглашусь - рисковать здесь не стоит, и просто необходимо сделать автономную систему. Если же речь идет об управлении/навигации хотябы легкомоторным самолетом, не говоря уж об авианосце, например, то "зарубежники" во всю используют и виндовс и QNX.
О градусниках никто не говорил, градусники и есть развлечение. Я сомневаюсь, что авианосцы плавают на QNX. Знаю, что навигационная система для яхт это точно чёрная коробка с аккумуляторами. Например компании QUME, никаких осей нет вообще, всередине стоит микроконтроллер MITSUBISHI c LCD-индикатором. Мой отчим занимается конструированием яхт, никогда не слышал о вообще каких-нибудь ОСьях. Ну, конечно, если где-то, в каком-то центре, наблюдая за расположением объектов в море через спутник и стоит QNX, это возможно.
Что за проблема?
Вы это смело делаете потому что знаете, что ОДНОВРЕМЕННО ничего у вас на обеих портах не произойдет, а не потому, что Вы не пользуетесь библиотеками.
Ну как можно вообще так думать ... Надеяться на авось, что на портах ничего не произойдёт ... Если Serial контроллер имеет два полностью независимых порта, то это значит, что и программа использует оба порта не взирая на то есть ли там что-то одновременно. Конечно - одновременно, другого варианта и быть не может. В ХР винде использование COM-портов на одном IRQ вообще блокируется, если через библиотеку. На 98-ой, как и в OS/2 так и в UNIX/LINUX при появлении байта на втором COM-порте в момент считывания в прерывании с первого COM'а, INT теряется. Мало того, современные Serial'ы, стоящие в одном чипе со звуком вообще повисают до RESET'а.
Не знаю, что хочет показать Andrew W Miheev, а у меня конкретно нет никакого желания и времени что то доказывать Вам, тем более показывать IQ. Все сказано и доказано Вам ДО меня и в этом треде и ранее в более других местах. Кроме того, на Ваш интеллект лично я никоим разом не указывал, наоборот, судя по тому, что Вы самостоятельно пишете "обвязку" COM, ethernet, USB я просто восхищен Вашими интеллектуальными способностями!
Для обвязки COM'ов не нужно иметь интеллек, нужен просто опыт.
Да кудыж нам серым - убогим... Давайте уж лучше Вы, у Вас этих процедур ажно 20 штук накопилось. Видимо по 3 на COM, ethernet, USB, а остальные 11 - WORKBENCH!
COM, ethernet, USB - речь шла о IBM-PC ... А если так уж хочется поиздеваться, показав что 20-3*3=11, - для этого есть зеркало.
Я не понимаю, чем я Вас обидел ? Это что так плохо - сесть и написать процедуры максимально качественно или создать их на АСМе ? Ну вот люблю я сделать так, что бы мой продукт запускался везде ... Я по этой причине и эмулятор свой не распротстроняю, потому что он не работает качественно на ХР. Я не хочу позориться ... Это для меня и есть программирование - "сделать программу максимально гибкой и быстрой".
Я конечно понимаю, сейчас посыпится - "надо было библиотеки использовать, тогда бы работало везде" или что-нибудь в этом роде. ZX кишит программами, в которых глюков минимум, PC кишит программами в которых глюки один за другим. Моё мнение, что это от черезмерного использования чих-то библиотек.
На Вашу игру Wanderlust можно посмотреть?
Можно посмотреть ... Наверное, хочется поискать в ней что-нибудь, над чем можно поиздеваться ? Так ?
Откуда взялся этот стереотип "велосипеда" ? Если пишется !!!нормальная!!! программа одного и того же автора, то в ней повторяется лишь стиль, а не процедуры.
Конечно, есть одинаковые процедуры, но их можно пересчитать по пальцам. Как правило ZX'ер пытается максимально ускорить свой код, а это значит, что лишний раз он не будет делать CALL, и простая процедура умножения может уменьшиться на один-два цикла, ради скорости.
Я знаю одну процедуру быстрого умножения. Родившуюся путём
объединения кода от нескольких разных людей. Уверен, никто такое
из головы запросто так вот сразу не выдумывает. И процедур таких
немало. А кроме вопроса оптимального кодирования ещё есть
АЛГОРИТМЫ. Оптимизация алгоритма зачастую даёт выгрыш
не сравнимый с выжимкой жалких тактов. И это тоже не из головы
за 5 минут выдумывается.
А что касаетя CALL -- это вообще сильно притянуто за уши. Для
этого существуют (я знаю, что на спектруме, по сути, это только ALASM) существуют МАКРОАССЕМБЛЕРЫ. Хочешь call, хочешь
"inline" функция. НЕТ тут проблемы. НЕТ.
Другое дело, что процедуры вида "расчёт адреса в экране" и т.п.
действительно бессмысленны. Нужна математика, строки, ввод-вывод...
Вот ещё пример: печаталка 64 символа в строке без развёрнутых
шрифтов ужатая Михаилом Жаровым до каких-то смехотворных
тактов и байтов. Аналогов не существует. Оптимизировалось несколькими людьми в течении достаточно длительного времени.
Хрен сам ты её за 5 минут напишешь.
Если всё строить на готовых библиотеках, то в итоге код обростает торможением. После чего библиотека пригодна для написания "карт" или "минёров", и да же в них карты будут дёргаться или вообще просто появляться.
Бред.
а с вас никакого спроса, как и с автора библиотеки. А представьте себе, - делаешь прибор, пишешь софт, и всего-то соединяешь прибор по простому COM'у. Его ставят на завод, запускают бумагоделательную машину, и через час вдруг завис "дрюйвер" COM-PORT'а.
Да бывает. Нужно использовать правильные библиотеки.
К которым даётся исходный код. Именно на этот случай.
День ковыряний в коде выявляет, что ioctl(TIOCSBRK) не
поддерживается драйвером moxa, но поддерживается
обычным писишным портом. После чего в библиотеке
вписывается нормальный tcsendbreak() и всё сразу работает.
Ибо поддержка юнихов доисторических версий нафиг не нужна
и можно смело требовать соответствие современному IEEE-1003.
Хотя в целом я согласен. Минимум лишнего и разумная простота конструкции в целом только добавляет надёжности.
И, соответственно завод больше не приобретёт прибор нашей компании. Вот так было, когда на нашей фирме работали программисты, закончившие институты и имеющие учёные степени.
Программный продукт -- технически исключительно сложное изделие. Со всеми вытекающими последствиями.
Сколько я не писал проектов, всегда всю обвязку делал сам, начиная от COM-PORT'а, кончая USB, ETHERNET, VIDEO, KEY и всё остальное
Да, да. Не имея документации ты напишешь USB и ethernet драйвера,
напишешь свой tcp/ip стек, свою графическую подсистему, отладишь
это всё, нигде не наделаешь ошибок... Фантастика научная.
... Не было ни одного отказа ... И главное, не нужен лицензионный виндовс, не нужно платить всем подряд за использование !!!очень!!! не качественных компонентов и тех же SDK. И после этого вы
Есть полно не очень качественных компонентов, но абсолютно
нахаляву и со всеми исходными текстами. В условиях, когда абсолютно качественных компонентов нет, а очень качественные --
это $$$$$ -- это не так уж плохо.
И писать даже не на ассемблере (вдруг он глючит), а исключительно
в машинных кодах.
[quote]
А для чего я писал свой компилятор? Он именно это и делает! Всё,
Компилятор чего? И уверен ли ты, что не облажался больше,
чем профессионалы занимающиеся этим второй десяток лет?
По-моему ты перегибаешь.
Но, этот опыт привёл к разделению на тех, кто пишет в основном на библиотеках, и тех, кто пишет в основном на “велосипедах”. Я отношусь к тем, кто любит прилеплять реактивный двигатель к велосипеду. И мне для разработки нужно:
Мой опыт показывает -- сам всего не прилепишь, банально времени
сил, энтузиазма, времени и опыта не хватит. А у самодельного велосипеда никакого запаса прочности и потенциальных возможностей для дальнейшего развития. Ну их нафиг, велосипеды.
Всяческие процедуры с мышками, FDD, HDD – хорошая идея. Хотя, например FDD. Тянет за собой обработку системных переменных. Так же менеджер памяти, а вдруг и это очень вероятно, что я захочу его поместить начиная с 23296, да бы была возможность выделять всю память до байтика. Ну и после всё это соединю, думаю, что библиотеки начнут ссориться.
Нужен унифицированный интерфейс.
А работу с HDD ты вообще не напишешь. Потому что их много и
разных. Ты просто протестировать на всех вариантах для всех
программ не сможешь. Тут именно тот случай, когда позарез как
необходим сторонний код. Который протестирован и отлажен.
И позарез как нужна динамическая компоновка. Потому как
протестировать и отладить до конца невозможно, хотя бы поэтому.
А автору каждый раз пересобирать софт тоже невозможно.
Это дело, но всякие печати символов, часы, отображение курсоров, наложение спрайтов лично мной бы вряд ли использовалось. Разве что посмотреть как делают другие.
Если тебе нужно что-то уникальное -- ты прав. Для демо не сойдёт.
Если тебе нужно не важно с какой скоростью, но выводить текст
и иметь приличный редактор в окошке -- лучше взять готовый.
Винда не наша, а БлинаГейтса. И в моём софте не виснет, ибо он у меня начинается с команды ASM ...
Да хоть с команды VBA. Какая разница? VBA даже лучше.
ОБлажаться сложней.
За 10 лет работы в этой сфере о "UNIX"ах, как и о Виндовсах я слышу в большинстве случаях от отечественных коллег. Все эти ОСи зарубежники редко используют для серьёзных управлений.
Тем не менее используют. Типичный пример на каждом
углу -- автоматы продажи билетов, оплаты мобильников,
банкоматы -- windows NT 5.0. В оплате мобильников -- точно.
И unix встречается в более чем критичных применениях.
Возможно даже более критичных, потому как разбор полётов
в системе windows до уровня исходного кода не произвести.
В остальных случаях никто не хочет рисковать и делает полностью автономные системы. Есть микроконтроллер, есть датчики и нет ни КВУНИКСОВ ни ВИНДОВСОВ.
Да. Когда говорят QNX, я никак не могу понять чем оно принципиально отличается от той же NT. Кроме реалтайма.
Ширпотребный контроллер готов на гораздо более жёсткий
реалтайм безо всяких осей. А на "мягкий реалтайм" вполне
готов тот же линух или винда. (не 98 ;-)
Я писал о качественном программировании. У всех виндовсах, как и у досах, так и у квуниксах есть проблема с COM-портом. Почему я и вспомнил. И всё что в оправдание придумывают программисты - глюк материнки, системы или ещё чего-нибудь. Однако я смело использую два ком-порта на том же одном IQR, и нет проблем, потому что не пользуюсь библиотеками.
Ага. А подсистема win32 -- это, конечно, не библиотеки. И глюков там нет.
Это что так плохо - сесть и написать процедуры максимально качественно или создать их на АСМе ?
не плохо. но долго и довольно трудно для отладки.я вот тоже, памятуя о спеке, ломанулся писать на асме под микроконтроллеры. и понял что на них писать нужно только биос/загрузчик и специфичные процедурки.
Ну вот люблю я сделать так, что бы мой продукт запускался везде ...
даже на разных платформах? в таком случае начинать каждую программу с асм равнозначно переписанию ее заново при изменении целевой платформы.что не лучшим образом сказывается на времени разработки и надежности конечного продукта (вследствие недостатка времени на отладку)
Шо-то я не понял... а как у меня 4 usb и 2com заняты - и ничего. 2 мобилы разом перешивал + сканировал + возил комовским дигитайзером по опере в нете через модем (комовский) - работало прекрасно...
Ну а собсвенно SDK где ? с чего начинали, помним ?
РОБ, давай лучше процедуры выкладывай. сколько есть/сколько не жалко - все ж лучше чем НИЧЕГО...
Изначально именно Вы прочитали не внимательно я сказал - "РАБОТА БЕЗОТКАЗНА"
где именно?
О градусниках никто не говорил, градусники и есть развлечение. Я сомневаюсь, что авианосцы плавают на QNX. Знаю, что навигационная система для яхт это точно чёрная коробка с аккумуляторами. Например компании QUME, никаких осей нет вообще, всередине стоит микроконтроллер MITSUBISHI c LCD-индикатором. Мой отчим занимается конструированием яхт, никогда не слышал о вообще каких-нибудь ОСьях. Ну, конечно, если где-то, в каком-то центре, наблюдая за расположением объектов в море через спутник и стоит QNX, это возможно.
Нет, авианосцы плавают под WindowsNT, газоперекачивающие агрегаты (в прошлом просто авиационные турбины) работают под Linux, бензоколонки, супермаркеты - опять же Виндовс, банкомат у меня на работе - под OS/2.
Для обвязки COM'ов не нужно иметь интеллек, нужен просто опыт.
Молодец, мощно задвинули!! :v2_clapp:
COM, ethernet, USB - речь шла о IBM-PC ... А если так уж хочется поиздеваться, показав что 20-3*3=11, - для этого есть зеркало.
Я не понимаю, чем я Вас обидел ? Это что так плохо - сесть и написать процедуры максимально качественно или создать их на АСМе ? Ну вот люблю я сделать так, что бы мой продукт запускался везде ... Я по этой причине и эмулятор свой не распротстроняю, потому что он не работает качественно на ХР. Я не хочу позориться ... Это для меня и есть программирование - "сделать программу максимально гибкой и быстрой".
Вы меня обидели? :) ... Кто над Вами издевается, я что ли? Извините, если где то перегнул с флеймом...
По моему - так программирование без использования чьих то наработок (можете назвать это библиотеками) - вот самое настоящее издевательство над здравым смыслом! :)
Я конечно понимаю, сейчас посыпится - "надо было библиотеки использовать, тогда бы работало везде" или что-нибудь в этом роде. ZX кишит программами, в которых глюков минимум, PC кишит программами в которых глюки один за другим. Моё мнение, что это от черезмерного использования чих-то библиотек.
ZX "кишит" ИГРАМИ бородатых лет, причем сугубо КОММЕРЧЕСКОГО происхождения и по этому "вылизанных" вдоль и поперек благодаря своей относительной незатейливости и однородности платформы. С РС аналогию сможете провести сами...
Можно посмотреть ... Наверное, хочется поискать в ней что-нибудь, над чем можно поиздеваться ? Так ?
Нет, не угадали. Просто хотелось посмотреть, и всё. Издеваться над кем бы то нибыло - не в моих правилах. Если покажете Вашу программу, могу Вам гарантировать - не пророню о ней ни слова - ни плохого, ну может быть только хорошее (если оно там есть) :)
Вот ещё пример: печаталка 64 символа в строке без развёрнутых
шрифтов ужатая Михаилом Жаровым до каких-то смехотворных
тактов и байтов. Аналогов не существует. Оптимизировалось несколькими людьми в течении достаточно длительного времени.
Хрен сам ты её за 5 минут напишешь.
С хреном не писал, но пока кушал после работы - написал ... Конечно это не 5 минут, но 30 есть ... За три прерывания полностью перепечатывается весь экран текстом. Шрифт, какой был, такой влепил. Полностью вся печаталка 129 байт с расписыванием на восемь повторений, без расписывания 62 байта. Вот код:
STARTC EQU 32768
ORG STARTC-256
IncBIN "f8x8-cs.fnn"
BUBLIK EQU $
ORG STARTC
DS 256-1
DW INT
ORG STARTC
HALT
LD HL,22528
LD DE,22529
LD BC,767
LD (HL),5*8+0
LD A,5
OUT (254),A
LDIR
DI
LD HL,M1xS
LD DE,M1xE
LD BC,(M1xE-M1xS)*7-3
LDIR
JP START
ORG BUBLIK
START:
LD B,30
LD HL,TEXT
M0 PUSH BC
PUSH HL
LD (MSP+1),SP
LD SP,HL
LD DE,16384
LD A,D
M2 LD (M1xA+1),A
M1 POP HL
LD C,H
LD B,HIGH (STARTC)+1
LD H,B
M1xA LD D,0
M1xS LD A,(BC) ;7 7+4*4+7+7+4+4+4=49
RLCA ;4
RLCA ;4
RLCA ;4
RLCA ;4
OR (HL) ;7
LD (DE),A ;7
INC H ;4
INC B ;4
INC D ;4
M1xE DS (M1xE-M1xS)*7-3
INC E
JP NZ,M1
INC D
LD A,D
CP 88
JR NZ,M2
LD HL,0
ADD HL,SP
EX DE,HL
MSP LD SP,0
POP HL
POP BC
DJNZ M0
INC B
EX DE,HL
JR M0
INT: RETI
TEXT DUP 32
DB "Super Puper Text ... Так быстро, что тормозит ... "
EDUP
ORG TEXT+64*24
; DW INT-START
SaveBIN "less-001.c",STARTC,$-STARTC
SaveTRD 'less-001.trd','1.C',STARTC,$-STARTC
Ну и ссылочка:
Нет, не угадали. Просто хотелось посмотреть, и всё. Издеваться над кем бы то нибыло - не в моих правилах. Если покажете Вашу программу, могу Вам гарантировать - не пророню о ней ни слова - ни плохого, ну может быть только хорошее (если оно там есть) :)
Я никогда не был против критики ... Я не о том говорил ...
Выкладываю игру ... Правда это не по теме ...
Желательно запускать на реальном Speccy, а то эмуляторы мерцают и дискрируют. Мультиколоры пофиксены под пентагон. Вся игра построена на RND, да же мелочи, при перезапуске постоянно что-то меняется. В игре не доделана картинка на прохождение, поэтому ориентируйтесь по радару. В текстах встречаются ошибки, ссори ...
Я никогда не был против критики ... Я не о том говорил ...
Выкладываю игру ... Правда это не по теме ...
Желательно запускать на реальном Speccy, а то эмуляторы мерцают и дискрируют. Мультиколоры пофиксены под пентагон. Вся игра построена на RND, да же мелочи, при перезапуске постоянно что-то меняется. В игре не доделана картинка на прохождение, поэтому ориентируйтесь по радару. В текстах встречаются ошибки, ссори ...
Слушайте, отличная игра! :)
Честно говоря, такого достойного уровня не ожидал увидеть! Неужели за 2 недели всего написано?
И все таки, думаю, на счет библиотек Вы неправы. Вашим же трудом моглибы воспользоваться другие, а когда то может быть и Вы чьим-то.
Слушайте, отличная игра! :)
Честно говоря, такого достойного уровня не ожидал увидеть! Неужели за 2 недели всего написано?
Вообще-то не 2 недели а три дня. За три дня был полностью написан генератор лабиринта. Кстати, он в игре очень упрощён, если поставить 100% заполнение уровня, то игра становится не проходимая. Так же в игре нет анимации графики, хотя программно всё предусмотренно. Так же в игре уровень раскрывается 6-тью видами графики, хотя отображается только один из шести на текущий момент. А за две недели была написана вся обвязка с мультиколорами и графикой. А вот текстовка набивалась долго. Сложно делать вдвоём. Вдвоём с графиком. Музыку подправить, текст подправить, графику порезать, сделать графику удобный конвертер под мультиколорные цвета т т.д. вместе с т.п... Всех этих инструментов нет.
Спасибо за отзывы. Приятно знать, что делал это не в пустую.
А вот с профессиональной точки зрения в моей игре сть большая лажа - она плохо работает на Original Speccy, поскольку INT занят почти на 100% ну или 99.99%.
И все таки, думаю, на счет библиотек Вы неправы. Вашим же трудом моглибы воспользоваться другие, а когда то может быть и Вы чьим-то.
Я не говорил, что против библиотек ... Я против библиотек где есть процедуры печати символов, спрайтов, музыки и подобных вещей. Я совсем не против коллекции процедур, например чтение с FDD или HDD или паковщики с депакерами. То есть системные процедуры. Я так же смотрю, как делают другие люди, например я учился у Michail Batty. Мне очень нравится стиль программирование Wakson'а или Raider'а, простите, уже не помню, кто весь код у них писал. Например: у них в плеере под SounDrive есть супер микшер четырёх каналов в один - цифровой микшер на трёх командах. Мне нравится как кодит RST-7, хотя как человека я его не переношу. А строить прогу на печати символов меня пугает, разве что делать паковщик, - я понимаю. Например: моя игра WanderLust, там врядли подошли бы стандартные печати, ведь там на ходу происходит печать то в теневой экран, то в оба, то только в 48-ой, поскольку кусок демы лежит в виде кода в теневой странице. Было бы просто бессмыленно использовать что-то стандартное.
А поделиться я всегда рад. Мне совсем не жаль, и готов рассказать о любой части программы. Могу, например, выложить WanderLust, в виде всех исходников, да же кртинки в BMP виде - можно подрисовать и тут же сконвертировать в игру.
Игруха супер! И вопросики в тему!!! (-;
(-;
LD Hl,#4000
LD DE,16384
LD BC,6911
LDIR
(-;
Ах что же это - ну конечно очистка экрана :-D
а вот и нет! правильный ответ - пауза (там был вариант, сколько тактов)
ещё мне кажется, что часто бывает несколько правильных вариантов, либо вопросы вообще без правильного ответа ;-( (это про бит теневого экрана)
Игруха супер! И вопросики в тему!!! (-;
Ах что же это - ну конечно очистка экрана :-D
Спасибо, очень приятно ... =)
Самое противное, что в жизни прикольных вопросов встречается очень много. Как-то один наш общий друг задал вопрос - "Лёша, вот если Spectrum 48k, а Dendi всего 16-бит, то как они умудряются в 16-ть бит влепить столько графики ?". А когда садишься за редактор набивать вопросы, какбуд-то кто-то решил опустошить голову, и начинаешь что-то из себя выдавливать. Чуть стоит сесть в транспорт или попадаешь на совещание у дирректора, так сразу куча приколов вспоминается.
а вот и нет! правильный ответ - пауза (там был вариант, сколько тактов)
Это он с издёвкой говорил. Но вариантов с паузой там то же два, за один два очка прибавляется за другой одно снимается =)
ещё мне кажется, что часто бывает несколько правильных вариантов, либо вопросы вообще без правильного ответа ;-( (это про бит теневого экрана)
Это точно, есть вопросы издевательские. Всё равно в игре нет GAME OVER'а, а на показатели это не повлияет, покрайней мере сильно не повлияет. Но и садизма нет, поэтому есть по два и да же по четыре правильных ответа. Но советую выбирать какой более кодерский, например:
Сколько уровней в игре Earth Shaker ?
1-30
2-32
3-Столько же, сколько бит в четырёх байтах
4-Я дальше заставки не проходил, трудно очень
Правильно [2], за него 1-но очко, за [3] 1 очко геймерства и 2 кодерства. Если отвечать совершенно неправильно, к примеру создатель Speccy - Филипп Киркоров, то будет минус десять.
Кстати, сверху, вправом углу есть бегунки, чем больше вправо от мерцания, тем больше правильных ответов, соответственно влево плоховато(ТА). Конечно же, я хотел сделать влияние правильности ответов на скорость движения персонажа и другие подобные вещи, но не успел, поскольку уселся делать Surgical Fantasy. Жаль что на Speccy нет нашего Jungar'а, он был бы в екстазе от Surgical Fantasy. В отличии от WanderLust'а - Surgical Fantasy почти полноценная стратегическо-экономическая игра, но приколов будет не меньше и занимать будет весь диск. Возможно что и два диска, но я считаю, что это уже будет заморочка заставлять игрока менять диски.
Спасибо за отзывы, они вдохновляют на скорострельную работу. Вот только затыки с музыкой, но надеюсь, что ZNAHAR поможет.
Кстати, у меня такой вопрос ко всем, кто играл ... Вопросы в игре пишутся чёрным с тенью на синем ... На реальном Speccy велеколепно смотрится, на эмуляторе на разных мониторах по разному, на некоторых - почти ничего не видно. Это сильно раздражает ? Может стоит заменить цвет ? Хотя мне больше всего понравилось именно такое сочитание ...
Кстати, у меня такой вопрос ко всем, кто играл ... Вопросы в игре пишутся чёрным с тенью на синем ... На реальном Speccy велеколепно смотрится, на эмуляторе на разных мониторах по разному, на некоторых - почти ничего не видно. Это сильно раздражает ? Может стоит заменить цвет ? Хотя мне больше всего понравилось именно такое сочитание ...
В эмуляторе действительно, смотрится не очень, приходится всматриваться. Но думаю, что надо ориентироваться на реальный ZX,
или например выбирать цвета чернил/бумаги из приемлемых сочетаний по RND. Или в настройку вынести можно.
И еще - нельзя ли приделать выгрузку/загрузку текущего состояния?
а вот и нет! правильный ответ - пауза (там был вариант, сколько тактов)
С паузой можно было пролететь по кол-ву тактов :)
Я отвеил - бесполезное действие (??) - прокатило:)
Хотя, наверняка за паузу очков дали бы больше
Я не говорил, что против библиотек ... Я против библиотек где есть процедуры печати символов, спрайтов, музыки и подобных вещей. Я совсем не против коллекции процедур, например чтение с FDD или HDD или паковщики с депакерами. То есть системные процедуры. Я так же смотрю, как делают другие люди, например я учился у Michail Batty. Мне очень нравится стиль программирование Wakson'а или Raider'а, простите, уже не помню, кто весь код у них писал. Например: у них в плеере под SounDrive есть супер микшер четырёх каналов в один - цифровой микшер на трёх командах. Мне нравится как кодит RST-7, хотя как человека я его не переношу. А строить прогу на печати символов меня пугает, разве что делать паковщик, - я понимаю. Например: моя игра WanderLust, там врядли подошли бы стандартные печати, ведь там на ходу происходит печать то в теневой экран, то в оба, то только в 48-ой, поскольку кусок демы лежит в виде кода в теневой странице. Было бы просто бессмыленно использовать что-то стандартное.
Понятно, что игре, на 100%% использующей ресурсы компьютера библиотеки могут и навредить т.к. их использование практически всегда связано с некоторыми накладными расходами. И коллекции процедур (исходников) здесь самое то, что надо.
Но ведь есть и системные программы, и сама ОС, про которую много говорят и которой пока нет. Там библиотеки (именно библиотеки откомпилированного кода в СОМ-образной обертке или как еще) были бы очень кстати потому что и различия в схемотехнике скрывают, и время на разработку экономят. В общем, "плюсов" достаточно много...
А поделиться я всегда рад. Мне совсем не жаль, и готов рассказать о любой части программы. Могу, например, выложить WanderLust, в виде всех исходников, да же кртинки в BMP виде - можно подрисовать и тут же сконвертировать в игру.
Лично мне было бы очень интересно на исходники посмотреть! :)
Нужен всё-таки не набор процедур, а окружение. Ставя настройки типа "выбрать быстрый вариант", "выбрать такую-то модель памяти", мы уже создаём окружение. В окружение можно добавить и загрузчик, и автосборщик, вплоть до "insert your code here".
Наборы процедур разные для разных задач. Если мы пишем утилиту, то нам нужна хитрая работа с диском и клавиатурой. Если пишем игру, то нужна работа со спрайтами (не повредил бы и их редактор/конвертор тут же), картами, списками объектов.
Процедуры по 10 строчек в библиотеках не имеют смысла - их проще заново написать, чем найти в библиотеках. Разве что если это процедуры переключения каких-то скрытых флажков в окружении. Например, если у нас нефреймовое обновление экрана, то после отрисовки всей графики мы вызовем процедуру EndDraw, она установит флаг, что на следующем прерывании можно переключать экран. А мы можем заниматься интеллектом. А на следующем входе в отрисовку мы вызовем процедуру BeginDraw, она будет ждать факта переключения экрана. Эти две процедуры простые, но для библиотеки годятся.
---------- Post added at 18:17 ---------- Previous post was at 17:02 ----------
Вообще хотелось бы найти хотя бы две реальных практических задачи, где требуются какие-то одинаковые процедуры.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot