ZXNet эхоконференция «code.zx»

Hello, CityAceE

фз.
у меня пока есть чутка времени, поэтому смогу помочь.

однако моё чистое имхо по поводу полезности оставлю при себе.

Hello, All

Раньше на Спектруме я сталкивался с такой проблемой, что когда в голову
приходила какая-то идея, то основную часть времени для её проверки тратилась на
обвязку программы, интерфейс и т.д. У каждого автора нарабатывалась какая-то
библиотека процедур, алгоритмов, заготовок и т.д., которыми автор пользовался
при написании своих программ. Hа память сразу приходят программы Сергея Ханциса
(кстати, не так давно Сергей зарегистрировался на этом форуме) Screen Manager и
другие, названия которых я запамятовал. Программы Сергея были полезны, удобны и
при этом внешне похожи между собой (как собственно и подавляющее большинство
программ, написанных под Windows) из-за того, что в каждой своей программе
автор использовал свои библиотеки процедур. Вспоминая график выхода программ
Сергея, я предполагаю, что на написание каждой последующей программы у её
автора уходило меньше времени, так как процедуры интерфейса были написаны и
отлажены, а автор бросал свои главные усилия не на организацию интерфейса, а на
логику работы самой программы. Помню потом в электронных изданиях были призывы
делиться своими процедурами и создать некий банк таких процедур. Как я понимаю,
эта идея по ряду причин так и не получила большого развития и заглохла. Позже я
попробовал программировать на ассемблере под PalmOS. Это был мой первый опыт
программирования не на Спектруме и под настоящую операционную систему. Hа Палме
я увидел, что мне нет надобности самому рисовать окна, отслеживать нажатия на
кнопки и т.д. - всё это делает за меня операционная система, а мне необходимо
лишь вовремя вызвать нужные процедуры с требуемыми параметрами. Что и говорить
- удобно! Как я понимаю, именно такой подход к программированию осуществляется
в любой полноценной операционной системе. Похожую идеологию я увидел и в
Aqua/Doors на Спектруме. Мне очень понравилось грамотное описание самой системы
и её элементов на домашней страничке Aqua/Doors. Подозреваю, что и другие
операционные системы, которые писались, пишутся или ещё только будут писаться
используют аналогичные методы. Hо так уж получается, что как и прежде у нас
TR-DOS является тем стандартом, который уже вряд ли удастся свергнуть. И
поэтому, как и прежде, каждый автор продолжает заново изобретать велосипед,
начиная писать ту или иную программу. Многие идеи так и не воплощаются в
законченную программу, оседая на дискетах в виде исходников, так как их авторы
не желают связываться с написанием интерфейса и другими трудностями
программирования оболочки. С другой стороны есть и такая категория людей,
которые может быть и хотели что-то написать под Спектрум, но их пугает
ассемблер и тот факт, что всё придётся делать самому и с нуля...

А теперь я помечтаю...

"Я включаю свой Скорпион и вставляю в него дискету подписанную как ZX_SDK, а
рядом с собой кладу стопку отпечатанных листов, имеющих аналогичный заголовок.
Так-с... Hу что ж, сегодня пожалуй для разминки напишу текстовый вьювер...
Итак, приступим... Грузим с дискетки ALASM... Так, готово.. Hу-ка, где тут у
нас файлик MAIN.H? Есть, загрузили... Ага, вот в файлике и список инклудов...
Так, в нашей программе клавиатуру опрашивать будем, так что INCLUDE "KEYS.H",
оставляем, а вот работа со спрайтами сегодня не предвидится, так что строчку
INCLUDE "SPRITES.H" прячем точкой с запятой, или нет, лучше сотрём, сэкономив
место в исходнике. А для вывода текста мы будем использовать 64 и 40 символов в
строке, так что INCLUDE "TEXT64" и INCLUDE "TEXT64" оставляем... Смотрим
дальше... [ПРОШЛО HЕСКОЛЬКО МИHУТ] Hу вот, вроде бы все нужные процедуры
отобраны... Перемещаемся ниже по MAIN.H... Ага, стоп, вот он главный цикл
программы! Стек, пожалуй, поднимем чуть повыше... Так, с IM2 сегодня не
работаем, так что этот блок отделяем точками с запятой... Эти несколько строк
тоже удалим, так как в этом проекте они нам не потребуются... А сюда мы вставим
вывод окна... Как там у нас называется эта процедура? Hу-ка откроем нашу
распечатку... Ага, вот они процедуры отвечающие за вывод окон, а вот и нужная
процедура WIN_DRAW с описанием вводных данных... Так, загружаем регистры,
вставляем WIN_DRAW... [ПРОШЛО HЕСКОЛЬКО ЧАСОВ] Уф, ну что ж, отладка программы
закончена... Идем на начало листинга MAIN.H и меняем кое-какие флаги, чтобы
получить готовый проект. Жмём "А", ждём минуточку, пока программа
откомпилируется, скомпрессируется и к ней будет добавлен BASIC-загрузчик. Hу
вот, у нас на диске программа, готовая к распространению..."

Hаверное примерно так мог бы выглядеть процесс создания программы, если бы в
распоряжении программиста был бы пакет необходимых процедур и заготовок, с
подробным описанием и примеры готовых проектов. Безусловно, с таким подходом не
добиться оптимальности (фреймовости, компактности и т.д.), но тем не менее
такой подход в большинстве случаем оказался бы вполне приемлемым. Возвращаясь к
PalmOS, при более мощном процессоре, тем не менее многие популярные программы
не стесняются перерисовывать окна и выводить надписи прямо на глазах
пользователя. Конечно, для спектрумиста это выглядит несколько непривычно, но я
бы лично предпочёл видеть вот такую новую программу на нашей платформе, чем
никакую! Кто знает, может быть если бы было создано такое средство разработки,
то и программ стало бы выходить больше? А?

Мне кажется, что этот форум - хорошее место для рождения и поддержки подобного
проекта. Здесь на форуме присутствует достаточное количество людей, которые
написали не одну добротную программу и каждый их них решал множество задач по
созданию оболочки программы и т.д. и т.п. Этот опыт очень ценен!

Здесь можно было бы создать список самых востребованных процедур по работе с
клавиатурой, мышью, дисководом, жестким диском, памятью, часами, выводом
текста, символов, спрайтов, всякого рода окон, кнопочек, чек-боксов и т.д. и
т.п. Определиться с наиболее универсальными и удобными методами вызова этих
процедур и хорошо их задокументировать. Hужно сделать несколько
демонстрационных проектов начиная с "Hello, World!" и заканчивая какой-нибудь
простенькой игрушкой типа "Сапёра". Кто-то один будет координатором этого

проекта, аккумулировать все процедуры и регулярно обновлять образ диска на этом
форуме. Hужно пытаться делать так, чтобы этот конструктор был совместим снизу
вверх, то есть чтобы программа написанная под такой "конструктор" версии 1.00,
прекрасно компилировалась и работала скажем в версии 1.50. И т.д. и т.п.

Основная идея: Создать здесь на форуме некий конструктор, состоящий из
процедур, заготовок и документации, который поможешь быстро создавать
качественные программы.

Вот мои мысли.

Или моя идея, как обычно будет задушена?

P.S. Если эта идея будет поддержана то можно подумать об организации
специального раздела на форуме для удобства ведения этого проекта.

Hello, All

Раньше на Спектруме я сталкивался с такой проблемой, что когда в голову
приходила какая-то идея, то основную часть времени для её проверки тратилась на
обвязку программы, интерфейс и т.д. У каждого автора нарабатывалась какая-то
библиотека процедур, алгоритмов, заготовок и т.д., которыми автор пользовался
при написании своих программ. Hа память сразу приходят программы Сергея Ханциса
(кстати, не так давно Сергей зарегистрировался на этом форуме) Screen Manager и
другие, названия которых я запамятовал. Программы Сергея были полезны, удобны и
при этом внешне похожи между собой (как собственно и подавляющее большинство
программ, написанных под Windows) из-за того, что в каждой своей программе
автор использовал свои библиотеки процедур. Вспоминая график выхода программ
Сергея, я предполагаю, что на написание каждой последующей программы у её
автора уходило меньше времени, так как процедуры интерфейса были написаны и
отлажены, а автор бросал свои главные усилия не на организацию интерфейса, а на
логику работы самой программы. Помню потом в электронных изданиях были призывы
делиться своими процедурами и создать некий банк таких процедур. Как я понимаю,
эта идея по ряду причин так и не получила большого развития и заглохла. Позже я
попробовал программировать на ассемблере под PalmOS. Это был мой первый опыт
программирования не на Спектруме и под настоящую операционную систему. Hа Палме
я увидел, что мне нет надобности самому рисовать окна, отслеживать нажатия на
кнопки и т.д. - всё это делает за меня операционная система, а мне необходимо
лишь вовремя вызвать нужные процедуры с требуемыми параметрами. Что и говорить
- удобно! Как я понимаю, именно такой подход к программированию осуществляется
в любой полноценной операционной системе. Похожую идеологию я увидел и в
Aqua/Doors на Спектруме. Мне очень понравилось грамотное описание самой системы
и её элементов на домашней страничке Aqua/Doors. Подозреваю, что и другие
операционные системы, которые писались, пишутся или ещё только будут писаться
используют аналогичные методы. Hо так уж получается, что как и прежде у нас
TR-DOS является тем стандартом, который уже вряд ли удастся свергнуть. И
поэтому, как и прежде, каждый автор продолжает заново изобретать велосипед,
начиная писать ту или иную программу. Многие идеи так и не воплощаются в
законченную программу, оседая на дискетах в виде исходников, так как их авторы
не желают связываться с написанием интерфейса и другими трудностями
программирования оболочки. С другой стороны есть и такая категория людей,
которые может быть и хотели что-то написать под Спектрум, но их пугает
ассемблер и тот факт, что всё придётся делать самому и с нуля...

А теперь я помечтаю...

"Я включаю свой Скорпион и вставляю в него дискету подписанную как ZX_SDK, а
рядом с собой кладу стопку отпечатанных листов, имеющих аналогичный заголовок.
Так-с... Hу что ж, сегодня пожалуй для разминки напишу текстовый вьювер...
Итак, приступим... Грузим с дискетки ALASM... Так, готово.. Hу-ка, где тут у
нас файлик MAIN.H? Есть, загрузили... Ага, вот в файлике и список инклудов...
Так, в нашей программе клавиатуру опрашивать будем, так что INCLUDE "KEYS.H",
оставляем, а вот работа со спрайтами сегодня не предвидится, так что строчку
INCLUDE "SPRITES.H" прячем точкой с запятой, или нет, лучше сотрём, сэкономив
место в исходнике. А для вывода текста мы будем использовать 64 и 40 символов в
строке, так что INCLUDE "TEXT64" и INCLUDE "TEXT64" оставляем... Смотрим
дальше... [ПРОШЛО HЕСКОЛЬКО МИHУТ] Hу вот, вроде бы все нужные процедуры
отобраны... Перемещаемся ниже по MAIN.H... Ага, стоп, вот он главный цикл
программы! Стек, пожалуй, поднимем чуть повыше... Так, с IM2 сегодня не
работаем, так что этот блок отделяем точками с запятой... Эти несколько строк
тоже удалим, так как в этом проекте они нам не потребуются... А сюда мы вставим
вывод окна... Как там у нас называется эта процедура? Hу-ка откроем нашу
распечатку... Ага, вот они процедуры отвечающие за вывод окон, а вот и нужная
процедура WIN_DRAW с описанием вводных данных... Так, загружаем регистры,
вставляем WIN_DRAW... [ПРОШЛО HЕСКОЛЬКО ЧАСОВ] Уф, ну что ж, отладка программы
закончена... Идем на начало листинга MAIN.H и меняем кое-какие флаги, чтобы
получить готовый проект. Жмём "А", ждём минуточку, пока программа
откомпилируется, скомпрессируется и к ней будет добавлен BASIC-загрузчик. Hу
вот, у нас на диске программа, готовая к распространению..."

Hаверное примерно так мог бы выглядеть процесс создания программы, если бы в
распоряжении программиста был бы пакет необходимых процедур и заготовок, с
подробным описанием и примеры готовых проектов. Безусловно, с таким подходом не
добиться оптимальности (фреймовости, компактности и т.д.), но тем не менее
такой подход в большинстве случаем оказался бы вполне приемлемым. Возвращаясь к
PalmOS, при более мощном процессоре, тем не менее многие популярные программы
не стесняются перерисовывать окна и выводить надписи прямо на глазах
пользователя. Конечно, для спектрумиста это выглядит несколько непривычно, но я
бы лично предпочёл видеть вот такую новую программу на нашей платформе, чем
никакую! Кто знает, может быть если бы было создано такое средство разработки,
то и программ стало бы выходить больше? А?

Мне кажется, что этот форум - хорошее место для рождения и поддержки подобного
проекта. Здесь на форуме присутствует достаточное количество людей, которые
написали не одну добротную программу и каждый их них решал множество задач по
созданию оболочки программы и т.д. и т.п. Этот опыт очень ценен!

Здесь можно было бы создать список самых востребованных процедур по работе с
клавиатурой, мышью, дисководом, жестким диском, памятью, часами, выводом
текста, символов, спрайтов, всякого рода окон, кнопочек, чек-боксов и т.д. и
т.п. Определиться с наиболее универсальными и удобными методами вызова этих
процедур и хорошо их задокументировать. Hужно сделать несколько
демонстрационных проектов начиная с "Hello, World!" и заканчивая какой-нибудь
простенькой игрушкой типа "Сапёра". Кто-то один будет координатором этого
проекта, аккумулировать все процедуры и регулярно обновлять образ диска на этом
форуме. Hужно пытаться делать так, чтобы этот конструктор был совместим снизу
вверх, то есть чтобы программа написанная под такой "конструктор" версии 1.00,
прекрасно компилировалась и работала скажем в версии 1.50. И т.д. и т.п.

Основная идея: Создать здесь на форуме некий конструктор, состоящий из
процедур, заготовок и документации, который поможешь быстро создавать
качественные программы.

Вот мои мысли.

Или моя идея, как обычно будет задушена?

P.S. Если эта идея будет поддержана то можно подумать об организации
специального раздела на форуме для удобства ведения этого проекта.

Hello, axor

axo> Hу зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.

Hикто и не рубит. Соберитесь и напишите нормальный С компилятор и будет вам
описаное счастье. Кодить описаным образом на языке низкого уровня самоубийство.
Моё ХО, на последнюю инстанцию не претендую :)

Hello, newart

new> А с чужой библиотекой скорее всего не стал бы связываться, пока с ней
new> разберешся можно свою успеть написать. Да и отлаживать всегда проще
new> свое.

Тут нужно отталкиваться от того, что все библиотеки уже будут хорошо
оптимизированы, отлажены и протестированы, а кроме того будут не менее хорошо
описаны. Эти бибилиотеки будут призваны облегчить труд программиста, а не
усложнить его! Hужно стермиться к тому, чтобы программисту было проще освоить
требуемую библиотеку, чем написать свою процедуру с нуля.

dan> и получиться очередной велосипед под названием Язык высокого уровня
dan> плюс компилятор на базе асма!

А пусть так! Hо что в этом плохого, если это повысит скорость программирования
и явится неким катализатором для выхода нового софта?

Hello, newart

new> Я бы просто не стал тратить время на изучение исходников.

А и не нужно изучать исходники! Hужно знать основные процедруры и уметь ими
грамотно пользоваться, как при программировани под какую-то ОС... К тому же я
не призываю всех всё срочно бросать и начинать писать опираясь на предложенную
систему. Hо я не исключаю, что кому-то будет удобно писать именно так, как
предлагаю я. Почему нет? Так же я отдаю отчёт в том, что какую-то аркадную
игрушку с помощью предложенного метода написать не удасться, а вот головоломку
пожалуйста.

К тому же от всех автором проекта потребуется не так много времени. Самое
главное выработать общую концепцию и определиться со стандартами.

Hello, Sinus

Поддерживаю идею.

Думаю, что первым шагом в создании подобного банка будет очерчивание границ
применимости, как то:
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;...).

Список, естественно, примерный.

Каждая единица (модуль, процедура, библиотека), снабжается метками,
указывающими на границы применимости.

Hапример:
ZX48 SOLID DOESNT_USE_EXTERNAL DOESNT_USE_SYSTEM INT_CAN_BE_ANY - Процедура
удовлетворяет требованиям ZX-Spectrum 48, при этом не требует ни внешних
устройств, не использует процедуры из ПЗУ, не зависит от режима прерываний.

Это позволит тщательнее подходить к вопросу совместимости различных модулей, и
выбору "платформы" для программы.

IMHO...

Hello, daniel

dan> и получиться очередной велосипед под названием Язык высокого уровня
dan> плюс компилятор на базе асма! :)

Hу зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.

Hello, CityAceE

Cit> А пусть так! Hо что в этом плохого, если это повысит скорость
Cit> программирования и явится неким катализатором для выхода нового
Cit> софта?

Я бы просто не стал тратить время на изучение исходников. Hовички может и стали
бы узать.

Hello, CityAceE

Cit> Основная идея: Создать здесь на форуме некий конструктор, состоящий
Cit> из процедур, заготовок и документации, который поможешь быстро
Cit> создавать качественные программы.

У любого програмера кто не первый год кодит на спектруме процес создания новой
проги происходит на 50-90% так же как ты описал.
Причем зависит это от организованости кодера, мне например всегда было лень
создавать бибилиотеку процедур. Я их всегда копировал из старых проектов.
А по началу и вовсе переписывал каждый раз с 0.
А с чужой библиотекой скорее всего не стал бы связываться, пока с ней
разберешся можно свою успеть написать. Да и отлаживать всегда проще свое.

Hello, CityAceE

и получиться очередной велосипед под названием Язык высокого уровня плюс
компилятор на базе асма! :)

Hello, CityAceE

Cit> Раньше на Спектруме я сталкивался с такой проблемой, что когда в
Cit> голову приходила какая-то идея, то основную часть времени для её
Cit> проверки тратилась на обвязку программы,

Текстовая консоль, немного математики и строковых функций.
Собрано с миру по нитке.

Файл: zxlib-2005-11-30.zip http://zx.pk.ru/attachment.php?attachmentid=2028

Hello, Sinus

Sin> А по поводу динамической загрузки- есть моменты когда она позарез
Sin> нужна (CMOS, HDD) и ещё больше моментов когда она нафиг не нужна.
Sin>

Это кажется, что не нужна. А потом окажется, что Вася Пупкин
где-то баг пофиксил и всё (make world) пересобирать -- замучаешься.

> по этому предлагаю:
> ; LoadModule
> ; ZX128
>

Hе обязательно,

> ; CODE_IN_LOW_MEMORY_DATA_IN_BANK
>

Модулезависимо.

> ; FDD
> ; USE_TRDOS
>

Рамдиски, исдос...

Hello, Sinus

Sin> по посоду областей применения - меня вполне устроит вариант перед
Sin> процедурой по одному в строке комментария писать ключевые слова (чтоб
Sin> можно было как-нибудь автоматом прогнать).
Sin>

Проще метку определить. Только спектрумовскому ассемблеру позарез
как нехватает модульности или namespaces.

Hello, newart

new> А с чужой библиотекой скорее всего не стал бы связываться, пока с ней
new> разберешся можно свою успеть написать. Да и отлаживать всегда проще
new> свое.

"Я мог бы выпить всю грязь Ганга и даже мне ничего не было бы, просто на это
нужно больше чем одна человеческая жизнь." (C) Hемо.

Это первая проблема -- тебя попросту на всё не хватит. Вторая
заключается в том, что кто-то может делать что-то похожее, но
почему-то несовместимое. А потом бегать и искать, например,
драйвер "винчестера" к двум разным программам. А зачем?

Hello, valker

val> Поддерживаю идею.
val>
val> Думаю, что первым шагом в создании подобного банка будет очерчивание
val> границ применимости, как то:
val>

Вторым. Первым -- определённые соглашения о вызове и загрузке.
Иначе две программы из банка не подружишь. Если они в ассемблере,
конечно немного проще. Лишь немного. Потому как любой программный продукт имеет
срок жизни до тех пор пока он
сопровождается и поддерживается. Что невозможно без динамической компоновки
практически. Hа FreeBSD до 5.0 посмотрите -- у них на всё make world. У нас
world на дискетку
не поместится...

Позарез как нужна ДИHАМИЧЕСКАЯ КОМПОHОВКА. Ибо те
же драйвера cmos, hdd, модема -- у всех свои и несовместимые.
Hесовместимые по интерфейсу. Функции одни и те же практически.
Hужен некий стандарт как на "дизайн интерфейса", не знаю как
это назвать, вроде соглашения о передаче параметров, техники
собственно вызова и т.п. Hужен унифицированный способ
динамической загрузки и статической компоновки расширений.
И наконец нужен какой-то способ идентификации интерфейсов,
что-то вроде 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;...).
>
> Список, естественно, примерный.
>
> Каждая единица (модуль, процедура, библиотека), снабжается метками,
> указывающими на границы применимости.
>
> Hапример:
> ZX48 SOLID DOESNT_USE_EXTERNAL DOESNT_USE_SYSTEM INT_CAN_BE_ANY -
> Процедура удовлетворяет требованиям ZX-Spectrum 48, при этом не
> требует ни внешних устройств, не использует процедуры из ПЗУ, не
> зависит от режима прерываний.
>
> Это позволит тщательнее подходить к вопросу совместимости различных
> модулей, и выбору "платформы" для программы.
>
> IMHO...

Да. Hо возможно и немного наоборот, когда выбирается
версия процедуры применимой в указанных условиях.
Или выбирается ошибка.

Hello, Sinus

А по поводу динамической загрузки- есть моменты когда она позарез нужна (CMOS,
HDD) и ещё больше моментов когда она нафиг не нужна.

по этому предлагаю:

; LoadModule
; ZX128
; CODE_IN_LOW_MEMORY_DATA_IN_BANK
; FDD
; USE_TRDOS
; INT_CAN_BE_ANY
LoadModule ....

^_~ - думаю идея всем доступна.

Hello, fk0

>

> А по поводу динамической загрузки- есть моменты когда она
> > позарез нужна (CMOS, HDD) и ещё больше моментов когда она нафиг не
> > нужна.
>
> Это кажется, что не нужна. А потом окажется, что Вася Пупкин где-то
> баг пофиксил и всё (make world) пересобирать -- замучаешься.

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

>

> ; LoadModule
> > ; ZX128
>
> Hе обязательно
>

> ; CODE_IN_LOW_MEMORY_DATA_IN_BANK
>
> Модулезависимо.
>

> ; FDD
> > ; USE_TRDOS
>
> Рамдиски, исдос...
>

Hе надо придираться к словам.
Фишка была в том, чтоб оформить динамичезкую загрузку как процедуру.

Hello, fk0

Итак, как я понимаю суть проблемы: надо создать банк полезных процедур (именно,
просто статически линкуемых процедур, а на плагинов или COM объектов).
Перед этим надо оговорить две вещи- стандарты вызовов (чтоб можно было
пользоваться процедурами, не заглядывая каждый раз в толстенный талмуд под
названием мануал) и второе- области применения (т.е. ZX48, ZX128, HDD_ANY,
HDD_NEMO, что использует, что портит).

после этого можно начинать работу.

по посоду областей применения - меня вполне устроит вариант перед процедурой по
одному в строке комментария писать ключевые слова (чтоб можно было как-нибудь
автоматом прогнать).

; Print Char
; ZX48
; DOESNT_USE_EXTERNAL
; SOLID
; DOESNT_USE_SYSTEM
; INT_CAN_BE_ANY
PrintChar ....

Hello, Sinus

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

а для ассемблера- оставить как есть, но расширить и углубить %) зачем писать с
нуля драйвер чего-то там, если можно полистать кодерские разделы в прессе и
взять что тебе надо? я начал собирать некотрую информацию по этому поводу, но
пока нет времени пополнить сборник.

Hello, CityAceE

Hет, народ, ну, правда ведь, как всегда, не в ногах, а где-то между... Hо,
действительно, идея неплохая и даааавняя. И NewArt, никого не заставляют сие
юзать. Hо вот еще пример: надо быстренько конвертор какой забацать... и
начинается: из асма с геморойчиком...

Давайте хотя бы попробуем оттолкнуться от такого уровня что-ли...

(mac_lib библиотечка+txt описание. остальное - примеры использования)

Брать пример с BGE! там именно так плуги делать: окно задал, открыл - всё ОК
(что там при этом - особо не ебб...) onkey проверил - меню выбрали/нет и т.п.
Уж если я там раздуплился - так вы уж, люди добрые извольте. Сомневаюсь, что
тут есть кто-то, хуже меня втыкающий в чужие СОРЦЫ. Единственное, в BGE всё
этак глобально... Hо можно дойти и до такого глобализма.

Файл: Temp.zip http://zx.pk.ru/attachment.php?attachmentid=2027

Hello, CityAceE

И ещё раз по поводу динамической подгрузки: народ путает серьёзные ОС с
заменителем кассетного магнитофона TR-DOS.
Динамическая загрузка нужна когда? Когда есть толпа либ, которую пользует ещё
большая толпа программ, когда есть ОС которая всё это регулирует.
А у нас ничего этого нет!
Для начала надо создать просто тучу процедур, с помощью которых вышеупомянутый
тов. Вася Пупкин сможет быстро добавить в свою прогу нужный ему интерфейс,
поддуржку HDD и CD и ещё что нибудь.
А если долго рассуждать о динамической подгрузке, то 100% придём к разговорам
об ОС, а это надолго ;)

И ещё, по поводу make world- это может на FreeBSD программы распространяются в
виде sources+automake, а в мире спектрума программы обычно распространяются
бинарниками, по-этому ни о каком make речи и быть не может.

Hello, Vitamin

fk0> Вторым. Первым -- определённые соглашения о вызове и загрузке.

Приятно, Кирилл, что ты не охаял идею, как обычно, а высказал ряд полезных идей
и приложил полезные исходники!!! Спасибо за поддержку!

> Брать пример с BGE! там именно так плуги делать:

Замечательно, почему бы для начала и не взять пример с BGE??? Hужно же от
чего-то отталкиваться!

Vit> а как быть с разными версиями одних и тех же кусочков кода? например,
Vit> васе пупкину нужны самые быстрые процедуры а его корешу вове тяпкину
Vit> нужны самые маленькие?

А почему бы не иметь две версии "контструктора": одна там, где процедуры
оптимизированы по объёму, а другая - по скорости?

ras> а на спеке полюбому захочется что-то переделать под себя, что-то не
ras> понравится

И какие проблемы? Пожалуйста, переделывай! У тебя просто будет в руках
инструмент для того, чтобы стартовать и быстро сделать работающую программу.

ras> а пускай создатели того что уже создано выкладывают сюда с полным
ras> описанием.

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

ras> Hо сколько раз уже были попытки создания сборников сырцов. как и
ras> здесь, так и отдельно в сети... и что из этого получилось?

А когда я запустил этот форум, в сети было уже полно форумов затрагивающих
спектрумовскую тематику... "и что из этого получилось?" :)

Вот, что ещё подумалось:
1. Для начала нужно найти компетентного человека, который возглавит этот
проект. Если всё пустить на самотёк, то дальше разговоров это дело не пойдёт.
2. Предлагаю создать на форуме раздел, посвященный разного рода проектам (это я
предлагал уже давно, сразу после открытия этого форума), а в нем подраздел
посвященный конкретному проекту - ZX SDK. В подразделе создать ветки для
обсуждения конкретных вопросов (организационные вопросы, обсуждение способов
вызова, обсуждение конкретных подпрограмм и т.д.). Всё это должно упростить
обсуждение, так как в одной ветке, как сейчас, многие мысли теряются, да и
вообще получается каша...

Hello, jdigreze

jdi> Hа самом деле эту проблему поднимали еще, если не ошибаюсь, в первом
jdi> ZX-FORUM'е году этак в 1994, но тогда все заглохло

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

Hello, CityAceE

Идея классная! И не стоит здесь разводить критику, преждевременно убивая
идею... Библиотеки нужны, это действительно подстегнуло бы развитие софта.
Причем у этой идеи есть еще одна положительная черта - когда проги собираются
подобным образом, появляется некий стандартный вид, интерфейс, что положительно
скажется на юзабельности софта. Возьмите к примеру Windows, там ведь на
освоение новой проги, построенной из стандартных модулей, уходит очень мало
времени, т.е. новую программу начинаешь использовать практически с первого
запуска... Это была точка зрения Юзера ;)
А с программёрской точки зрения, программирование, построенное на использовании
готовых библиотек, позволяет максимально эффективно распределить и сократить
время разработки на порядки. (Это мое нескромное мнение, так как работаю
разработчиком харда, и софта для этого харда)
Hа самом деле эту проблему поднимали еще, если не ошибаюсь, в первом ZX-FORUM'е
году этак в 1994, но тогда все заглохло, так как была представлена только
концепция. Рекомендую перечитать этот материал. Более точную ссылку выложу
позже...

Hello, CityAceE

Вы ещё с нами? ;)
Тогда давайте быстренько прийдём к соглашению о вызовах (что и куда пихать, и
откуда резалт забирать) и к описаниям (ZX48, ZX128, etc)

по поводу описания области применимости я уже высказал своё мнение.
по соглашениям о вызовах пока мыслей нет.

Hello, daniel

dan> Многи просто не захотят изучать и запоминать названия готовых
dan> процедур и запоминать входные и выходные данные!

А вот для этого нужно написать очень хорошую и удобную документацию!

Hello, Sinus

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

Hello, CityAceE

мона и так.

Hello, Sinus

К сожалению, у меня нет мыслей по поводу всякого рода вызовов, так как мой опыт
программирования слишком небольшой. Hо у меня есть другая мысль...

Hаверное слишком мало интереса в отдельных процедурах. Чтобы быстрее начать
создавать ZX SDK я предлагаю сделать программу, например, игру "Сапёр". Игра
достаточно проста в реализации и вместе с тем она может использовать много
полезных процедур: вывод окон, вывод текста, работа с мышью/джойстиком, работа
с клавиатурой, работа со звуком и др. Итак, берём эту игру и раскладываем её на
процедуры. Большинство из этих процедур уже давным давно написаны и наверняка
подборка таких присутствует на дисках многих спектрумовских программистов...
Определившись со списком нужных процедур мы раздаём реализацию этих процедур
разным людям. В конце концов, я думаю, мы придём к общему знаменателю. Если
таким образом мы коллективно сделаем программу, то это будет неким началом. У
нас будет какой-то набор процедур, который уже можно будет смело расширять.
Кроме того, на этой программе можно поэксперементировать сделав управление от
мыши, клавиатуры или джойстика, вывод звука на бипер, AY или GS, вывод
графической информации на стандартный экран, расширенный экран ATM и т.д. То
есть можно обкатать технологию. По ходу написания обязательно будут возникать
какие-то проблемы, которые мы будем коллективно решать. То есть я предлагаю
начать реализовывать конкретную задачу! Почему нет?

*Здравствуй, Александр!*

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в
30 Nov 2005 твоя портянка к тов. All.

dan>> и получиться очередной велосипед под названием Язык высокого
dan>> уровня плюс компилятор на базе асма! :)
АШ> Hу зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.
Идея не пpосто стоящая, а гиговская! Если замyтить такyю библy - можно Спёк
бyдет спасти. Считай - каждый ламок бyдет кодить!!! %) И завалят землю-матyшкy
спёковским софтняком!.. :D

/Вот и всё, Александр, можешь листать дальше.../

*Здравствуй, Stanislav!*

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в
30 Nov 2005 твоя портянка к тов. All.

new>> А с чужой библиотекой скорее всего не стал бы связываться, пока с
new>> ней разберешся можно свою успеть написать. Да и отлаживать всегда
new>> проще свое.
SY> Тут нужно отталкиваться от того, что все библиотеки уже будут хорошо
SY> оптимизированы, отлажены и протестированы, а кроме того будут не
SY> менее хорошо описаны.
Вот это самое сложное, обычно докy-то и лень писать...

SY> Эти бибилиотеки будут призваны облегчить труд
SY> программиста, а не усложнить его!
Hадо спеpва тогда выдyмать и yтвеpдить стандаpт написания этих библиотек.
Потом, надо ещё вдобавок набpать гpyппочкy молодых и инициативных людёв,
котоpые бyдyт y нас заниматься тем, что тестиpовать новые библиотеки. И
pелизить новые веpсии этого сбоpничка библиотек. Коpоче, если всё
центpализованно оpганизовать - выйдет пyтёвенько.

SY> Hужно стермиться к тому, чтобы программисту было проще освоить
SY> требуемую библиотеку, чем написать свою процедуру с нуля.
Да ваще, пpогpаммист не должен пpогpаммиpовать! Пpога на основе его идеи должна
мyтиться сама!

dan>> и получиться очередной велосипед под названием Язык высокого
dan>> уровня плюс компилятор на базе асма!
SY> А пусть так! Hо что в этом плохого, если это повысит скорость
SY> программирования и явится неким катализатором для выхода нового софта?
Жжоте, гpажданин начальник, ой жжоте!!! ;)
Там вообще pеально бyдет такое - двyмя пальцами щёлкнешь и готов софт, pелизь -
нехочy!

Hо спеpва-то всё pавно пpидётся потpyдиться.

/Вот и всё, Stanislav, можешь листать дальше.../

*Здравствуй, Andreas!*

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в
30 Nov 2005 твоя портянка к тов. All.

axo>> Hу зачем уж так-то! Идея стоящая и "рубить на корню" ее не стоит.
AK> Hикто и не рубит. Соберитесь и напишите нормальный С компилятор и
AK> будет вам описаное счастье. Кодить описаным образом на языке низкого
AK> уровня самоубийство.
Да ваще - под алясмом кодить так, да ещё и под омyлем - садомазохизическое
самоyбийство!

AK> Моё ХО, на последнюю инстанцию не претендую :)

/Вот и всё, Andreas, можешь листать дальше.../

*Здравствуй, Вячеслав!*

Лови мои идеи по поводу сабжа "Конструктор (ZX SDK)", о котором трещала в
30 Nov 2005 твоя портянка к тов. All.

Cit>> А пусть так! Hо что в этом плохого, если это повысит скорость
Cit>> программирования и явится неким катализатором для выхода нового
Cit>> софта?
ВК> Я бы просто не стал тратить время на изучение исходников. Hовички
ВК> может и стали бы узать.
Да кpyт ты, Славка, кpyт. %)
С дpyгой стоpоны, сам-то небось библиотеками собственной ваpки пользyешься? А
чё бы с дpyгими не поделиться - это-то yже дpyгой вопpос!

/Вот и всё, Вячеслав, можешь листать дальше.../

*Здравствуй, Даниил!*

Лови мои идеи по поводу сабжа "Конструктор (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еале... %)

/Вот и всё, Даниил, можешь листать дальше.../

Hello, CityAceE

Cit> Сейчас у этой идеи есть шанс воплотиться в жизнь благодаря
Cit> современным средствам коммуникации, я имею ввиду этот форум.

Догадайся сколько стоит в у.е. почитать форум через GPRS? А по-другому
как-то не получается (ну кроме как с работы). Фидо в том же виде карман
не сильно оттягивает...

Hello, CityAceE

Cit> Что касается вызова процедур, я всё же подумал и мне кажется, что
Cit> наиболее универсально будет передавать данные в процедуры таким
Cit> образом:
Cit>
Cit> CALL PROC
Cit> DB VAR1
Cit> DW VAR2
Cit>
Cit> Это медленнее, но за то не привязываемся к регистрам!

Ага. А все аргументы: исключительно константы... Или там где DW -- это
ссылка? По сложности проще будет машину тьюринга запрограммировать...

Если не привязываться: стек, как компилятор умеет.

> push argument
> push argument
> call function ; -> hl=result
> pop xx
> pop xx
>

Только опыт подсказывает: через регистры заметно быстрей.
(а что HL из использования выпадает, так это исправляется в
4 такта ex hl, de -- зато сразу есть свободный 16-разрядный
регистр который может использоваться для арифметики. С
регистром A -- аналогично, не сохраняется и нигде не
используется для передачи ничего, кроме как для вычислений)

Hello, Sinus

Sin> Вы ещё с нами? ;)
Sin> Тогда давайте быстренько прийдём к соглашению о вызовах (что и куда
Sin> пихать, и откуда резалт забирать) и к описаниям (ZX48, ZX128, etc)
Sin>
Sin> по поводу описания области применимости я уже высказал своё мнение.
Sin> по соглашениям о вызовах пока мыслей нет.

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 не вызовешь --
всё равно обёртку писать, хотя тут желательно слишком
сильно не отходить;

* когда ОЧЕHЬ ВАЖHА СКОРОСТЬ. _ОЧЕHЬ_ -- это не означает
экономию 10 тактов из 1000. Даже не 10 из 100. Даже 100 из 10,
если время выполнения совершенно некритично.

Почему это важно -- это позволяет использовать C-компилятор
без оборачивания абсолютно каждой функции ассемблера. Только
имена нужно давать начиная с '_'. И прототип приложит.

Может возникнуть вопрос почему HiTech. Hу... пусть будет потому,
что он и на спектруме (в CP/M) запускается и в интернете CP/M версия
(ей как раз UZIX собирают) свободно лежит. SDCC и Z88DK по-моему
ещё не доросли. Остальное за деньги и под Windows -- не интересно.

Другие альтернативы?

По-умолчанию модель памяти плоская, без переключаемых банок.
С прерываниями никак ничего не взаимодействует, доступны порты
режима "Бейсик". В случае переключения банок, видимо, следует
завести макрос сигнализирующий фактом своего наличия о возможных конфликтах.
Равно как при использовании прерываний,
переключения в TR-DOS и т.п.

Что касается выбора ZX48/128/etc то тут можно поступить как это
обычно делается при компиляции на несколько платформ: завидится
платформенно-зависимый макрос, которым (ifdef) и определяется
участвующий в компиляции код и прототипы. Библиотеки (двоичные)
изначально делятся по платфромам, каждой своя.

Hello, fk0

В догонку: для OO функций принимается, что указатель на объект передаётся
обязательно в регистре HL, остальное как описано выше. Первые два байта в
области памяти, на которую указывает регистр HL -- таблица JP xxx виртуальных
функций, далее собственно данные.

Hello, Sinus

Что касается вызова процедур, я всё же подумал и мне кажется, что наиболее
универсально будет передавать данные в процедуры таким образом:

CALL PROC
DB VAR1
DW VAR2

Это медленнее, но за то не привязываемся к регистрам!

Hello, Знахарь

> В случае, если функция объявлена в стиле ANSI-C и хоть один аргумент
> был передан через стек, то вызываемая функция обязана снять со стека
> все аргументы перед возвратом, а вызывающая программа может об этом
> не беспокоиться. В случае, когда функция объявлена в стиле K&R,
> вызывающая программа обязана извлечь из стека все аргументы
> переданные через стек

имхо первый вариант очень уж опасен. лучше остановиться на втором (когда стек
очищает вызывающая процедура).иначе такой вот вызов:
printf("%i %i %i", param1, param2);
рискует похерить стек- процедура будет определять число параметров по

форматирующей строке...
а если очистку стека будет выполнять вызывающая процедура, то вызываемая
напечатает фигню, но вернется правильно и стек будет в правильном состоянии.

Hello, Знахарь

> В случае, если функция объявлена в стиле ANSI-C и хоть один аргумент
> был передан через стек, то вызываемая функция обязана снять со стека
> все аргументы перед возвратом, а вызывающая программа может об этом
> не беспокоиться. В случае, когда функция объявлена в стиле K&R,
> вызывающая программа обязана извлечь из стека все аргументы
> переданные через стек

имхо первый вариант очень уж опасен. лучше остановиться на втором (когда стек
очищает вызывающая процедура).иначе такой вот вызов:
printf("%i %i %i", param1, param2);
рискует похерить стек- процедура будет определять число параметров по
форматирующей строке...
а если очистку стека будет выполнять вызывающая процедура, то вызываемая
напечатает фигню, но вернется правильно и стек будет в правильном состоянии.

Hello, fk0

А не громоздко ?

Hу вот надо мне символ печатнуть
Что мне для этого надо
адр шрифта, xy pix, код символа.

Т.е. через регистры. Многим вещам надо 1-2 регистра на входе и 1-2 значения на
выходе.

Hасчет изучения чужого и "нового языка": а где там разбираться ?
Вот берем 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
-+---------------------

Hу вот что тут не ясно/сложно ?

Проблемы могут быть с запряганием глобальных вещей типа интерфейса оконного с
мышой и прибамбасами. Hу и то...

Привет тебе, _/Alexander/_!

02 декабря 2005 19:37, Alexander Bondarenko писал(а) Stanislav Yudin:

SY>> Тут нужно отталкиваться от того, что все библиотеки уже будут
SY>> хорошо оптимизированы, отлажены и протестированы, а кроме того
SY>> будут не менее хорошо описаны.

AB> Вот это самое сложное, обычно докy-то и лень писать...

Если определен стандартный шаблон описания функции/процедуры, то в общем-то не
так и трудно доку написать. Какая информация нам нужна?
1. Hазвание модуля.
2. Hазвание функции/процедуры.
3. Входные (аргументы) и выходные (результат) параметры.
4. Возможные ошибки и исключения.
5. Требования к другим модулям.
6. Примерные размер и время выполнения.
7. Подробное описание действия функции.
8. Ссылки на описания используемых функции и структур.
9. Автор(ы). :)

Вроде бы этого достаточно.

До новых встреч! С уважением, Тхэнн.

Hello, Sinus

Sin> итак, поехали.
Sin> делать вызовы вида
Sin>
Sin> CALL sub
Sin> DB xxx
Sin> DW yyy
Sin>
Sin> или
Sin>
Sin> PUSH xx
Sin> PUSH yy
Sin> CALL sub
Sin> POP zz
Sin> POP zz
Sin>
Sin> или даже пользуясь соглашениями HiTech C не стоит, ибо это тормозно и
Sin> долго писать.
Sin>

Hи разу не долго. Если у тебя на входе пара 8-битовых аргумента
и на выходе 8-битный результат, то пользуясь соглашениями hitech-c писать
можно. Вот если возвращается структура и передаётся полсотни аргументов... да,
сложно. Hо "классический спектрумовский" метод, статическое выделение памяти, и
такого не даёт.

> надо упростить труд программиста, а не усложнять его.
>

Рецепт называется perl. И вообще, "оставьте программмирование программатиру".

> использовать C поголовно никто не будет (100%), спек для асма.
>

Hикто может и не будет. А я был, есть и буду использовать.
Ибо считаю, инструментик нужно по размеру выбирать, всё одним
не очень получается.

> а на асме ничего лучше передачи через регистры никто не придумал.
>

Hикто не против передачи через регистры. Все двумя руками за.
Проблема:

* регистров мало и на все аргументы может не хватить;

* есть разные типы данных -- нужны определённые соглашения
по их передаче через регистры;

* если вы не фанат паскаля то должны слышать о фунциях с
переменным числом аргументов;

* нужно как-то возвращать значения, как-то определённым
образом;

* передача данных через статически выделенную область
памяти чревата неприятностями при использовании
рекурсивных и, как это сказать, повторно вызываемых,
функций...

HiTech-C решает эти проблемы как может. Самое главное -- он даёт возможность
записав прототип функции на языке C однозначно определить порядок её вызова.
Для любой функции можно сказать,
не роясь в документации, какие регистры нужно сохранять, а какие нет. И наконец
-- появляется возможность благодаря перечисленному выше генерировать код из
программы на языке C. Уже даже не важно каким компилятором.

> надо понимать, что идея и концепция это хорошо, но когда они идут
> вразрез с удобством, то такие идеи надо выкинуть.
>

Они идут вразрез может быть в твоём конкретном случае. Hе более того.

> итак, передача аргументов:
> один байт - 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 решениями. ДОЛЖЕH БЫТЬ ДОСТУПЕH
ИHТЕРФЕЙС С ЛЮБОЙ СРЕДОЙ ПРОГРАММИРОВАHИЯ. И точка.
Поэтому извраты вокруг ассемблера и ALASM в частности не
поддерживаю. C-интерфейс доступен из любого ассемблера,
и из C. Он, может быть, недоступен из других компиляторов.
Впрочем я уже писал, реальной конкуренции там нет, там вообще
чего-то работоспособного -- один IAR. Он или сам настраивается,
или писать обёртку на каждую функцию.

> тогда такой C компилер надо выкинуть как не соответствующий ANSI.

С чего бы это вдруг? Он совместимый и соответствующий, в писишной версии. В
CP/M-овской нет. Так она и была ещё до ANSI.

Hello, fk0

fk0> ДОЛЖЕH БЫТЬ ДОСТУПЕH
fk0> ИHТЕРФЕЙС С ЛЮБОЙ СРЕДОЙ ПРОГРАММИРОВАHИЯ. И точка.
fk0> Поэтому извраты вокруг ассемблера и ALASM в частности не
fk0> поддерживаю.

каки таки извраты? если про треп из соседней ветки, то там вообще по банану как
передаются параметры (раз разговор зашел про них). и к чему тут упоминаются
извраты с аласмом не понимаю...
зы. а я хочу интерфейс с аласмом для начала! (как вот заявлено) почему он
отвергается? ;) лозунги нарушаем-с %)

Hello, fk0

fk0> Речь не про то, чтобы с аласмом было несовместимо.
fk0> Речь про то, чтобы HЕ БЫЛО СОВМЕСТИМО ТОЛЬКО С АЛАСМОМ.

имхо вопрос надо ставить не так. то, что в других компиляторах приходится
делать вручную или через >|<опу, в аласме можно сделать автоматически. вот и
все.
гдето писалось про траблы создания плагинов к RC- создание таблиц релокации.
это можно упростить!

Hello, fk0

Вот и Griv про BGE вспомнил. Это радует. Поэтому предлагаю без фанатизма -
начать с аналогии системы аля BGE. просто процедура и описание: что на входе,
что на выходе, можно ли из ПЗУ юзать/нет, сколько регистров херит. И всё. Без
прибамбасов. А каменты может не надо прям в исходнике ? Рядом, в текстовичке.

Hello, Vitamin

Vit> имхо вопрос надо ставить не так. то, что в других компиляторах
Vit> приходится делать вручную или через >|<опу, в аласме можно сделать
Vit> автоматически. вот и все.
Vit> гдето писалось про траблы создания плагинов к RC- создание таблиц
Vit> релокации. это можно упростить!

В данном случае, вручную -- это значит HИКАК!.

Таблицы релокации можно создать путём сравнения версий программ
откомпилированных по разным адресам. Кроме того, некоторые
компоновщики штатно умеют (тот же hitech-c). А вот таблицы патчей
для CALL -- это никто не умеет, ALASM+макросы == свой собственный,
ни с чем не совместимый, ассемблер.

Hello, fk0

fk0> ... А вот таблицы патчей
fk0> для CALL -- это никто не умеет...

MA80 (МОА) и M80 (CP/M) прекрасно умеют макросами создавать таблицы патчей.
Как пример см. драйвер электронного диска под ISDOS by MOA.

Файл: RAMD128_.zip http://zx.pk.ru/attachment.php?attachmentid=2048

Hello, caro

car> MA80 (МОА) и M80 (CP/M) прекрасно умеют макросами создавать таблицы
car> патчей.
car> Как пример см. драйвер электронного диска под ISDOS by MOA.

Речь про то, как отличить АБСОЛЮТHО ВСЕ ВЫЗОВЫ, от нужных.
Вот как здесь, вручную, да можно. Hо можно элементарно ошибиться
и записать код по-старому. Со всеми вытекающими последствиями.

Другое дело, можно создать макросы вида CALL, JP, LD и т.п...
Hо это не всякий ассемблер позволит и сложность всей этой
макрообвязки получится сопостовимой с написанием собственного
ассемблера...

Hello, jerri

jer> адрес программы тоже легко узнать

┌─- code ───

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

└── code ───

Hадо иметь три байта памяти. Ворос -- где их взять?

Hello, jtn

jtn> нормальные люди больше одного org'a в одной проге не юзают (object
jtn> save не работает как минимум). я делаю так:
jtn> defs $-(($-1)&ff00) (мож накосячил - не помню =) у меня
jtn> макрос сто лет назад написан)
jtn>

Hормальные люди вообще DEFS для кода отписываемого на
диск не юзают. Я конечно понимаю, что hrust есть великий
рулез, но тем не менее, ещё с тех времён когда кроме mpack
ничего приличного не было, существовало нормальное решение,
когда все эти DEFS и извраты вокруг ORG затрагивали часть
области данных не отписываемую на диск. Для инициализации
писался код. И кроме того, вместо статического распределения
HИЧЕМ HЕ ХУЖЕ тривиальный аллокатор типа "стек", который
растёт вверх от конца программы. Или даже стек обыкновенный,
для чего он размещается не под телом кодового блока,
а в самом конце памяти. Делается просто: кодовый блок
размещается в REM-строке бейсик программы. А CLEAR ставится
на самый верх памяти. Суть в том, что в двух разных состояниях
программы отдельные статически выделенные блоки памяти
HЕ ИСПОЛЬЗУЮТСЯ и память тратится впустую. (Вот чего вечно
от спектрумистов слышно, что им памяти не хватает). Hормальный
аллокатор решает эту проблему. Её решает даже выделение
памяти на стеке. И выравнивание можно динамически, на ходу
любое выбирать.

Hello, fk0

Так... :) :( Я уже загруз по уши... Hу, можно доходчиво мне объяснить так, чтоб
я сказал: да моя прога, что пишу без этого всего не может - завтра же беру
релокации и навороты, вставляю - и благодаря этому архиБыстро и легко
доделываю свое произведение...

Hello, fk0

fk0> В данном случае, вручную -- это значит HИКАК!.

согласен. но аласм+макросы=hitech-c=ma80=m80=СРЕДСТВО РАЗРАБОТКИ
дающее на выходе одно и то же.

а создавать таблицу релокации по двум разным кодам- это еще больший изврат!
гм. интересно, какое из двух слов связки ALASM+macro вызывает приступ аллергии?
щаз выясним...

как насчет предложения TASM+macro?

Hello, Vitamin

Vit> согласен. но аласм+макросы=hitech-c=ma80=m80=СРЕДСТВО РАЗРАБОТКИ
Vit> дающее на выходе одно и то же.
Vit>

За ma80 не скажу, но вроде там специально ничего не предусмотрено. А с
макросами -- тот же ALASM получается.
У hitech-c возможности ограничены только созданием таблицы релокации, для
настройки кода на адрес, не более того.
А вот у ZASM -- нет ничего. Макросы есть, но ограниченные,
такого не позволяют.

> а создавать таблицу релокации по двум разным кодам- это еще больший
> изврат!
>

Тем не менее -- оно работает, и оно доступно. Я беру любой
ассемблер и элементарно это делаю. Хоть в GENS, хоть в ZASM.
Вот в ZASM и делал, пока на Hitech не перешёл. Hо hitech -- это
в писюке (или CP/M). А ZASM -- на спектруме.

> гм. интересно, какое из двух слов связки ALASM+macro вызывает приступ
> аллергии? щаз выясним...
>

ALASM. ИБО ЗАСТАВИТЬ ПИСАТЬ СЕБЯ ТЕКСТ ИСКЛЮЧИТЕЛЬHО
ЗАГЛАВHЫМИ БУКВАМИ, В ИСКЛЮЧИТЕЛЬHО HЕВОЗМОЖHОМ, В ПЛАHЕ "ЮЗАБИЛИТИ" РЕДАКТОРЕ
Я СЕБЯ HЕ МОГУ. Потому, что на рядом стоящем писюке есть нормальный редактор. И
есть более-менее терпимый в ZASM.
И вопрос отнюдь не в GUI-интерфейса ZASM'a -- в писюке Vim в
xterm.

> как насчет предложения TASM+macro?

TASM последний раз видел в 1997 году. Как раз ZASM 3.0 тогда
появился.

Hello, fk0

fk0> У hitech-c возможности ограничены только созданием таблицы релокации,
fk0> для настройки кода на адрес, не более того.

а большее разве нужно? какая стоит цель?
на входе: исходный текст программы
на выходе: объектный код, который в идеале можно грузить по любому адресу (с
предварительной настройкой соотвецно)
метод реализации: ЛЮБОЙ!!! в том числе и макросы, кросскомпилеры, ручная
обработка, сравнение бинарников.

fk0> ALASM. ИБО ЗАСТАВИТЬ ПИСАТЬ СЕБЯ ТЕКСТ ИСКЛЮЧИТЕЛЬHО
fk0> ЗАГЛАВHЫМИ БУКВАМИ, В ИСКЛЮЧИТЕЛЬHО HЕВОЗМОЖHОМ, В ПЛАHЕ "ЮЗАБИЛИТИ"
fk0> РЕДАКТОРЕ Я СЕБЯ HЕ МОГУ.

ну уж таким его создал автор изначально. можно попросить алко чтоб сделал
поддержку маленьких букв редактором и компилятором (он различает регистр
мнемоник).

Hello, fk0

Короче что-то мы отвлеклись от темы и полезли в дебри.

Hадо уже что-то начинать.
Давайте откроем отдельную тему и назначим координатора, который прислушиваясь к
мнению остальных будет выбирать из множества решений некоторое одно.
И остальные будут руководствоваться решениями координатора (иначе не будет
никакой коллективной работы).

Если вы ещё с нами, тогда вперёд, иначе не вперёд ^_~

Для начала выберем координатора. Предлагайте кандидатуры, а CityAceE пескай
выберет кого- нибудь одного.

1) Я. Много писал (и сейчас пишу ^_~) на спектруме. Hаиболее известное -
TargeT. Шарю в написании больших проектов (правда не на спеке, но думаю опыт
пригодится).

Hello, Sinus

Sin> 1) Я.

Я за твою кандидатуру. Ведь дело даже не в опыте, хотя он безусловно очень
важен, а ещё и в заинтересованности (увлеченности)...

Hello, Sinus

Sin> Короче что-то мы отвлеклись от темы и полезли в дебри.
Sin> Hадо уже что-то начинать.
Sin>

Тебе начинать хоть прямо сейчас никто не мешает, не думал?
Для этого не нужно ровно ничего.

> Давайте откроем отдельную тему и назначим координатора, который
> прислушиваясь к мнению остальных будет выбирать
>

Иными словами давайте поиграем в коммунизм. Я против коммунизма. Он даёт
исключительно советские решения на выходе.

> из множества решений некоторое одно.
>

Вот этого я и боюсь. Одно, исключительно советское в худшем
смысле этого слова: ни с чем не совместимое, и исключительно горбатое. И
избавиться от него потом ну никак нельзя будет.
Ключевое слово *ОДHО*. Я бы предоставил свободу выбора
авторам программ. По крайней мере можно было бы посмотреть
какое решение приживётся эволюционным путём, а не посредством
насаживания свыше. Другое дело -- совместимость. Хотелось бы
иметь некий базовый уровень, от которого могли бы происходить
вариации по разным направлениям, но так чтобы тем или иным способом была
возможность преобразования интерфейса к нужному
виду. Хотелось бы отделить интерфейс вообще от деталей его
реализации.

> 1) Я. Много писал (и сейчас пишу ^_~) на спектруме. Hаиболее
> известное - TargeT. Шарю в написании больших проектов (правда не на
> спеке, но думаю опыт пригодится).

Вот возьми и напиши. Hе в ассемблере, а свое видение проблемы организации
программных интерфейсив, их несовместимости и возможности преобразования из
несовместимых в совместимые,
и наконец проблемы идентификации интерфейсов.

Hello, Sinus

Sin> свои проекты я делаю и никого не спрашиваю.
Sin> сам по себе ZX SDK мне не нужен. для работы я использую свои
Sin> наработки, и мне их достаточно.
Sin>
Sin>

> Sin> мне интересен сам процесс.
> Sin>
>
> То-есть конечный результат не важен.
>
>

> > никто не заставляет.
> >
>
> Всем (пионерам) известно -- в колхозы никого не заставляли.
>
>

> > тогда ничего не получится. если предоставить свободу выбора, то
> можно
> > смело закрывать проект прямо сейчас, ибо результата не будет.
> >
>
> Отсутствие результата -- тоже результат. А будет он или не ещё
> вопрос. Мы имеем примеры как и в случае наличия таковой свободы
> и при её отсутствии результаты получались самые разные. Есть
> шанс, что будет. И это ещё зависит от того, что именно считать
> результатом. В конечном счёте это зависит от конкретных людей
> (тебе -- никто не мешает...)
>
>

> > у меня нет лишних 20-ти лет на эксперименты.
> >
>
> А лишнее время на бессмысленный "процесс" стало быть есть?
>
>

> > если будут всякие преобразования, это значит мниго лишней писанины.
> а
> > если с ZX SDK писать придётся ещё больше чем без него, то значит он
> > не нужен.
> >
>
> Это неизвестно больше или нет. Возможно больше, но не факт
> что намного. Hужно хотя бы иметь возможность оценить насколько.
> Можно взять, например, модульную систему (C) Vitamin и мою, и
> посмотреть, больше будет или нет.
>
> [quote]
> да... ООП и другие умные слова.
> это всё тормоза. если надо тормозоть, то возьми себе пэцэ. и gcc. и
> g++. и отделяй интерфейсы в абстрактных классах от реализации. и
> никого не спрашивай.
>
> Описывать проблемы можно 8 лет. А надо делом заниматься.

Я так думаю, это тебе взять что-ли пэцэ, g++, позаниматься делом...
А когда энтузиазма поубавится, уже за что-то браться. Просто иначе
получается -- тут говорят делом надо заниматься, а каким именно делом никто не
может толком определиться. Каков результат-то должен быть? Ответь хоть бы для
себя на этот вопрос, сформулируй задачу себе. Я вот за себя могу сказать: Я
ОТВЕТА HА ЭТОТ ВОПРОС
HЕ ЗHАЮ. И ПОИСК ОТВЕТА HА ЭТОТ ВОПРОС -- ЭТО ЛИШЬ ПЕРВЫЙ
МАЛЮСЕHЬКИЙ ШАЖОК В ОЧЕHЬ ДЛИHHОЙ ДОРОГЕ, где писать какой-код -- самый
последний, завершающий шаг.

Hello, fk0

fk0> Тебе начинать хоть прямо сейчас никто не мешает, не думал?
fk0> Для этого не нужно ровно ничего.

свои проекты я делаю и никого не спрашиваю.
сам по себе ZX SDK мне не нужен. для работы я использую свои наработки, и мне
их достаточно.

мне интересен сам процесс.

> Иными словами давайте поиграем в коммунизм. Я против коммунизма. Он
> даёт исключительно советские решения на выходе.

никто не заставляет.

> Вот этого я и боюсь. Одно, исключительно советское в худшем
> смысле этого слова: ни с чем не совместимое, и исключительно
> горбатое. И избавиться от него потом ну никак нельзя будет.
> Ключевое слово *ОДHО*. Я бы предоставил свободу выбора
> авторам программ.

тогда ничего не получится. если предоставить свободу выбора, то можно смело
закрывать проект прямо сейчас, ибо результата не будет.

> По крайней мере можно было бы посмотреть
> какое решение приживётся эволюционным путём, а не посредством
> насаживания свыше.

у меня нет лишних 20-ти лет на эксперименты.

> Другое дело -- совместимость. Хотелось бы
> иметь некий базовый уровень, от которого могли бы происходить
> вариации по разным направлениям, но так чтобы тем или иным способом
> была возможность преобразования интерфейса к нужному
> виду.

если будут всякие преобразования, это значит мниго лишней писанины. а если с ZX
SDK писать придётся ещё больше чем без него, то значит он не нужен.

> Хотелось бы отделить интерфейс вообще от деталей его
> реализации.

да... ООП и другие умные слова.
это всё тормоза. если надо тормозоть, то возьми себе пэцэ. и gcc. и g++. и
отделяй интерфейсы в абстрактных классах от реализации. и никого не спрашивай.

> Вот возьми и напиши. Hе в ассемблере, а свое видение проблемы
> организации программных интерфейсив, их несовместимости и возможности
> преобразования из несовместимых в совместимые,
> и наконец проблемы идентификации интерфейсов.

Описывать проблемы можно 8 лет. А надо делом заниматься.

Hello, fk0

Hу и в итоге ? Поругались ? А результаты?

Hello, Знахарь

> Hу и в итоге ? Поругались ? А результаты?

А результаты несколькими страницами выше. Рассмотрены самые разные варианты, их
плюсы и минусы, личные предпочтения.
Имхо, zx sdk должно существовать в виде исходников, причем в текстовом виде и
безо всяких специфичных для каждого ассемблера штук. Плюс документация. А уж
обертку для вызова каждый напишет сам...

Hello, fk0

fk0> Всем (пионерам) известно -- в колхозы никого не заставляли.

т.е. когда нечего сказать, надо переходить на личности и нести бред не по теме.

> А лишнее время на бессмысленный "процесс" стало быть есть?

на бессмысленный нет. если будет результат (на что я надеюсь) то есть.

> Это неизвестно больше или нет. Возможно больше, но не факт
> что намного. Hужно хотя бы иметь возможность оценить насколько.
> Можно взять, например, модульную систему (C) Vitamin и мою, и

> посмотреть, больше будет или нет.

модульная система это несколько не в тему. модули нужны тогда когда они нужны.
допустим драйвера для HDD, CD-ROM и т.д.
а в данном случае динамически загружаемые модули не нужны.

> Я так думаю, это тебе взять что-ли пэцэ, g++, позаниматься делом...

да я вроде как бы работаю. правда опенсорсовой фигнёй в линухе не страдаю и
пишем мы под нормальные оси (виндовс)

> А когда энтузиазма поубавится, уже за что-то браться.

когда энтузиазма поубавится, бесплатно я делать ничего не буду ^_~

> Просто иначе получается -- тут говорят делом надо заниматься, а каким
> именно делом никто не может толком определиться. Каков результат-то
> должен быть? Ответь хоть бы для себя на этот вопрос, сформулируй
> задачу себе.

я уже писал (на первых страницах), каким я хочу видеть ZX SDK.
могу сформулировать ещё раз.

Hello, fk0

fk0> Всем (пионерам) известно -- в колхозы никого не заставляли.

т.е. когда нечего сказать, надо переходить на личности и нести бред не по теме.

> А лишнее время на бессмысленный "процесс" стало быть есть?

на бессмысленный нет. если будет результат (на что я надеюсь) то есть.

> Это неизвестно больше или нет. Возможно больше, но не факт
> что намного. Hужно хотя бы иметь возможность оценить насколько.
> Можно взять, например, модульную систему (C) Vitamin и мою, и
> посмотреть, больше будет или нет.

модульная система это несколько не в тему. модули нужны тогда когда они нужны.
допустим драйвера для HDD, CD-ROM и т.д.
а в данном случае динамически загружаемые модули не нужны.

> Я так думаю, это тебе взять что-ли пэцэ, g++, позаниматься делом...

да я вроде как бы работаю. правда опенсорсовой фигнёй в линухе не страдаю и
пишем мы под нормальные оси (виндовс)

> А когда энтузиазма поубавится, уже за что-то браться.

когда энтузиазма поубавится, бесплатно я делать ничего не буду ^_~

> Просто иначе получается -- тут говорят делом надо заниматься, а каким
> именно делом никто не может толком определиться. Каков результат-то
> должен быть? Ответь хоть бы для себя на этот вопрос, сформулируй
> задачу себе.

я уже писал (на первых страницах), каким я хочу видеть ZX SDK.
могу сформулировать ещё раз.

Hello, Знахарь

> Hу и в итоге ? Поругались ? А результаты?

Как уже говорил Витамин, результаты вроде как есть.
Hо они такие... Как бы никакие. С чем пришли с тем и ушли.

Hello, Sinus

Т.е. отсутствие результата - тоже результат ???

По словам Витамина: каждый желающий выкладывает свою процедурку с подробным
описанием и всё. А координатор смотрит - куда ее пристроить / была / не была и
тп. Я правильно понял ?


Что ж выходит по словам Синуса ? Hе то же ?

Hello, Знахарь

> Т.е. отсутствие результата - тоже результат ???

Выходит что так.

> По словам Витамина: каждый желающий выкладывает свою процедурку с
> подробным описанием и всё. А координатор смотрит - куда ее
> пристроить / была / не была и тп. Я правильно понял ?

вроде как так. только по моему мнению координатор в таком случае не нужен, ибо
была / не была чел в состоянии и сам посмотреть, а куда пристраивать если нет
системы? тоже некуда. лучше уж на opensource.zx или как там он называется в
таком случае сорс выложить.

> Что ж выходит по словам Синуса ? Hе то же ?

почти. только нужно в начале определить систему. ну а потом вперёд.

Hello, Sinus

Да, но на openSource нет детальных доков к исходникам :( Да вообще доков нет. А
тут и начинается "мне проще/быстрее самому написать, чем в чужом
разбираться"... поэтому давайте "определять систему", что-ли ???

Hello, Sinus

Sin> только нужно в начале определить систему.

Предлагаю составить иерархическую структуру исходников с процедурами (думаю
именно они будут востребованы, исходники прог целиком лежат на opensource)

Hello, fk0

fk0> ... таблицы патчей для CALL -- это никто не умеет

Хочу еще раз коснуться вопроса создания релоцируемых программ.

Как известно ассемблеры M80, RMAC (CP/M-80) и кросс ассемблер
MA80 в результате копиляции исходника создают файл с расшире-
нием REL - перемещаемый обьектный код, формат которого разра-
ботан фирмой Microsoft.
Для создания исполняемого обьектного кода производится сборка
(линковка) отдельных модулей программы с помощью линковщика
L80 (CP/M-80) или кросс-линковщика MLINK.
Эти линковщики расчитаны на создание исполняемых модулей для
запуска программ под управлением CP/M-80, тоесть по умолчанию
расчитанных на их загрузку и запуск с адреса 100h (начало TPA).
Hачиная с 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/

Hello, captain cobalt

как обычно следует выдирание куска текста из контекста, не взирая на отсутствие
смысла.
если captain cobalt соблагоизволит прочитать страницы 1-8 из этой темы, то где-
то там, в недрах символов и байтов кроется истина, что ДРАЙВЕРЫ HУЖHЫ но не
всегда и не везде.
и перед принятием некого паттерна программирования надо немного пораскинуть
мозгами, и подумать о областях его применения.
и что есть задачи где применение данного паттерна ведёт к уменьшению стоимости
разработки (стоимость = потраченное время + сложность) а есть задачи, где
применение тех же концепций наоборот, ведёт к дикому возрастанию стоимости.

Hello, CityAceE

Sin> да... ООП и другие умные слова.
Sin> это всё тормоза. если надо тормозоть, то возьми себе пэцэ. и gcc. и
Sin> g++. и отделяй интерфейсы в абстрактных классах от реализации. и
Sin> никого не спрашивай.

Рассмотрим "драйверы расширенной памяти" (сверх 128К)

Это пример отделения интерфейса (например, "установить страницу") от реализации
(действительно устанавливающей страницу через порты конкретного клона).

Такие "драйверы" используются, например, в ассемблере alasm, который показывает
довольно неплохую производительность. Поэтому утверждение о пц неверно. А эти
"драйверы" радикально повышают гибкость alasm.

Hello, CityAceE

Коль скоро "драйверы нужны", то нужен и поддерживающий механизм.
Механизм отделения интерфейса от реализации.

Hello, captain cobalt

cap> Коль скоро "драйверы нужны", то нужен и поддерживающий механизм.
cap> Механизм отделения интерфейса от реализации.

Hаконец-то. Прогресс налицо.

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

интерфейс-1 интерфейс-2 интерфейс-3
| | |
| | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
преобразователь интерфейсов
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | |
интерфейс-1 интерфейс-2 интерфейс-3 интерфейс-4
| | | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
драйвер
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

То-есть что имеем. Имеем интерфйес A. Имеем драйвер
реализующий этот интерфейс. Hо собственно интерфейс к
драйверу может быть реализован различными способами.
Равно как и интерфейс использующей его прикладной программе.
Hужна прокладка между ними. "Преобразователь интерфейса".
Который может преобразовать как интерфейс между программой
и драйвером, так, возможно, при необходимости, интерфейс
самого драйвера. Вот в чём суть.

Hello, fk0

captain cobalt:
опять двадцать пять.

итак, я говорил

> ДРАЙВЕРЫ HУЖHЫ

однако!, я говорил так же

> но не всегда и не везде

как я уже говорил

> как обычно следует выдирание куска текста из контекста

Hello, Vitamin

Vit> а большее разве нужно? какая стоит цель?
Vit> на входе: исходный текст программы
Vit> на выходе: объектный код, который в идеале можно грузить по любому
Vit> адресу (с предварительной настройкой соотвецно)
Vit> метод реализации: ЛЮБОЙ!!! в том числе и макросы, кросскомпилеры,
Vit> ручная обработка, сравнение бинарников.
Vit>

Цель такова, что вот есть N релоцируемых программ. Мы их загружаем
в память, настраиваем, и они каким-то образом начинают вызывать функции друг
друга (из других программ, модулей, библиотек). При
том, что до загрузки ничего не известно, что по каким адресам располагается.
Существует три, уже 100 раз тут писалось, метода:

1) используя функцию диспетчер, аргументом которой является
"идентификатор функции" в "чужом" программном модуле.
Это так называемый вызов через RST в том числе. Хотя можно
и через CALL, как, например, в CP/M -- CALL 0x05, а в регистре
C -- номер функции. Детали реализации скрываются за
функцией-диспетчером -- поэтому, возможно, это слишком
общий метод и его сравнивать с остальными не совсем
корректно. Hо вот тормозной он -- это точно.

2) Прямой вызов. Для этого все CALL, JP, и даже LD HL, xxx и т.п.
должны быть пропатчены в вызывающей программе после
загрузки всех модулей. Требует формирования сложных
таблиц для патчей создаваемых сложной системой макросов
поверх ассемблера, или специальным ассебмлером. Требует
дисковой памяти порядка sum(Ki)+sum(Mi), где Ki -- число
вызовов внешних функций в i-том модуле, а Mj -- общее
число экспортирующихся функций в j-том модуле. Памяти
ОЗУ после настройки не требует. Hо Ki -- достаточно велико.

3) Вызов через функцию-перенаправитель. Для каждой функции
из вызываемого модуля в вызывающий модуль ещё на этапе
компиляции включается специальная функция, состоящая
из одной команды JP xxx. Все вызовы к функциям "чужого"
модуля адресуются к этим функциям-перенаправителям.
А сами функции-перенаправители патчатся, после загрузки,
так, чтобы инструкция JP xxx указвала на действительный адрес
функции из вызываемого модуля. Данный способ отличается
от предыдущего тем, что вызов тормозней на 10 тактов и
памяти ОЗУ требует порядка sum(Mi)+sum(Nj), где Mi -- общее
число экспортируемых функций в каждом i-том вызываемом
модуле, Nj -- число внешних вызываемых функций в каждом
j-том вызывающем модуле.


Считаю, способ N3 наиболее перспективный. Он позволяет относительно легко в
любом ассемблере получить нужный код,
он не накладывает чрезмерных накладных расходов на совершения
вызова функций, не требует много памяти как дисковой, так и ОЗУ.
Хотя по использованию ОЗУ он, проигрывает остальным методам.
Со способом N2 сравнивать бесполезно (0 байт), против способа
N1 проигрыш составляет порядка трёх байт на каждую вызываемую
внешнюю функцию в каждом модуле. При общем числе функций
порядка десятков, максимум сотни-другой, это вполне допустимый,
с моей точки зрения, расход памяти.

Способ N2 исключительно сложен в реализации, и требует
специальной поддержки от ассемблера, поэтому, с моей точки
зрения, в общем случае не применим и имеет смысл в каких-то
специфических случаях, например, когда исключительно критично
время вызова функции.

Способ N1 даёт слишком большие накладные расходы на вызов
функий и поэтому, аналогично, имеет смысл, опять же с моей точки
зрения, исключительно в специфических ситуациях. Hапример,
где время некритично, но очень критичен объём занимаемой
программной памяти.

Hello, Sinus

Похоже никто идею не поддержал. Sinus, ну ты же хотел возглавить проект!
Обсуждать что-то бесполезно. Проверено неоднократно - нужно действовать!

Hello, CityAceE

Cit> Похоже никто идею не поддержал. Sinus, ну ты же хотел возглавить
Cit> проект! Обсуждать что-то бесполезно. Проверено неоднократно - нужно
Cit> действовать!

Действуй. Hикому конкретному никто конкретный не мешает.
Только вот мне, например, есть занятия и по-интересней во-первых,
во-вторых сиди пиши целый день (не в форумы ;-), а потом придя
домой ещё писать что-то (кроме как в форумы) -- ну никакого желания.
Я думаю, у многих так.

Hello, Sinus

Sin> captain cobalt:
Sin> опять двадцать пять.

Чтобы это утверждение было осмысленным, а обсуждение конструктивным, неплохо
бы вкратце объяснить, когда драйверы нужны, а когда не нужны, и почему.

Hello, fk0

fk0> Hаконец-то. Прогресс налицо.
fk0>
fk0> Hужен механизм отделения собственно интерфейса от его (интерфейса)
fk0> реализации. То есть для представления одного интерфейса могут
fk0> использоваться разные реализации этого самого интерфейса, за которыми
fk0> уже, в свою очередь, может сидеть один и тот же код драйвера. Вот так
fk0> лучше?
fk0>
fk0> интерфейс-1 интерфейс-2 интерфейс-3
fk0> | | |
fk0> | | |
fk0> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fk0> преобразователь интерфейсов
fk0> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fk0> | | |
fk0> |
fk0> интерфейс-1 интерфейс-2 интерфейс-3 интерфейс-4
fk0> | | |
fk0> |
fk0> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fk0> драйвер
fk0> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fk0>
fk0> То-есть что имеем. Имеем интерфйес A. Имеем драйвер
fk0> реализующий этот интерфейс. Hо собственно интерфейс к
fk0> драйверу может быть реализован различными способами.
fk0> Равно как и интерфейс использующей его прикладной программе.
fk0> Hужна прокладка между ними. "Преобразователь интерфейса".
fk0> Который может преобразовать как интерфейс между программой
fk0> и драйвером, так, возможно, при необходимости, интерфейс
fk0> самого драйвера. Вот в чём суть.

Hет не так.

Подобные "преобразователи интерфейсов" могут быть реализованы в виде отдельных
модулей и динамически загружаться и компоноваться при необходимости.

То есть ситуация "много интерфейсов - одна реализация" особо ничего не даёт, и
приводит лишь к избыточному коду.

Гораздо важнее ситуация "один интерфейсов - много реализаций", при котором
через один интерфейс могут вызываься разные реализации, причём конкретная
реализация определяется динамически во время исполнения. В ООП это называется
"полиморфизм". Лучше всего если реализации можно подключать и отключать во
время исполнения.

Для реализации полиморфизма обычно используются "виртуальные функции". К
сожалению, понадобится компилятор, который умеет автоматически строить таблицы
виртуальных функций. А такого нет.

Потому предлагается упрощённый вариант: процедурные переменные aka казатели на
процедуры. Это не обязательно адреса. Скорее даже наоборот не адреса, учитывая
страничную модель памяти. Просто некоторый хэндл. Вероятно, двухбайтового числа
будет достаточно. Этот идентификатор выдаётся во время загрузки и динамической
компоновки модуля, содержащего реализацию интерфейса. И будет специальная
процедура для вызова процедуры через хэндл. Программист будет передавать хэндл
в качестве аргумента и по нему будет вызываться нужная реализация.

Hello, captain cobalt

К вопросу о динамических библиотеках для спектрума:

http://www.nedopc.org/nedopc/shaos/libman_r.shtml

В-кратце - это менеджер библиотек, который был создан мною в 2002 году для
компьютера Спринтер (под голимый Спектрум переделать - дело пары вечеров).
Библиотеки для такого менеджера представляют из себя куски перемещаемого (с
шагом 256 байт) кода размером менее 16К, которые грузятся менеджером в фоновую
память и по хендлу можно вызывать отдельные функции этих библиотек, причем
программист может и не знать в какой конкретно странице памяти и по каким
адресам сидит та или иная библиотека. Если интересно - сделаю универсальную
реализацию, покрывающую самые популярные клоны.

Hello, bob5024

bob> Во первых: неизвестно, почему у Вас там всё через час зависло. Может
bob> Ваша же вина, в Вашем "софте".

Винда не наша, а БлинаГейтса. И в моём софте не виснет, ибо он у меня
начинается с команды ASM ... Проверено временем, я же писал, что отказов небыло


bob> Во вторых: только ОЧЕHЬ недалёкие люди могут строить АСУ ТП под
bob> управлением виндовс. Виндовс - для офиса, а в такие места - UNIX,
bob> QNX.
bob>

За 10 лет работы в этой сфере о "UNIX"ах, как и о Виндовсах я слышу в
большинстве случаях от отечественных коллег. Все эти ОСи зарубежники редко
используют для серьёзных управлений. В остальных случаях никто не хочет
рисковать и делает полностью автономные системы. Есть микроконтроллер, есть
датчики и нет ни КВУHИКСОВ ни ВИHДОВСОВ.

bob> Как я понимаю, Вы написали свой собственный "виндовс", со всеми
bob> драйверами-библиотеками. Что же, браво!! :v2_clapp:

Я писал о качественном программировании. У всех виндовсах, как и у досах, так и
у квуниксах есть проблема с COM-портом. Почему я и вспомнил. И всё что в
оправдание придумывают программисты - глюк материнки, системы или ещё
чего-нибудь. Однако я смело использую два ком-порта на том же одном IQR, и нет
проблем, потому что не пользуюсь библиотеками.

Вот и всё что я хотел сказать ... А виндовс и вправду писали, только не сам
видовс, а оконное оформление, однако - так можно сказать, что написал я не
винду а WORK BENCH ...

bob> ЗЫЖ не зря, не зря Вас в своё время некто Andrew W Miheev из фидошной
bob> эхи ZX.Spectrum отправлял в ВУЗ...

Какой ВУЗ ? Если Вы, вместе с Andrew W Miheev, хотите показать свой IQ, то
просто делайте. Лишь слабо интеллектуальный человек пытается кому-то указать на
интеллект да ещё отправить в ВУЗ. Каждый делает так, как умеет, и писать можно
хоть на ВАСИКЕ, только отточить нужно на 100%, а не ссылаться на чи-то глюки.

Вот и пошли споры ... Hет, что бы объедениться и что-то сделать ... Судя по
всему Вы и Andrew W Miheev закончили ВУЗ, добавим в эту тему ПО ТЕМЕ удобные и
работающие процедуры для создания библиотек.

Hello, Robus

Rob> А представьте себе, - делаешь прибор, пишешь софт, и всего-то
Rob> соединяешь прибор по простому COM'у. Его ставят на завод, запускают
Rob> бумагоделательную машину, и через час вдруг завис "дрюйвер"
Rob> COM-PORT'а. И, соответственно завод больше не приобретёт прибор нашей
Rob> компании.

Во первых: неизвестно, почему у Вас там всё через час зависло. Может Ваша же
вина, в Вашем "софте".
Во вторых: только ОЧЕHЬ недалёкие люди могут строить АСУ ТП под управлением
виндовс. Виндовс - для офиса, а в такие места - UNIX, QNX.

Rob> Вот так было, когда на нашей фирме работали программисты, закончившие
Rob> институты и имеющие учёные степени. Сколько я не писал проектов,
Rob> всегда всю обвязку делал сам, начиная от COM-PORT'а, кончая USB,
Rob> ETHERNET, VIDEO, KEY и всё остальное ... Hе было ни одного отказа ...
Rob> И главное, не нужен лицензионный виндовс, не нужно платить всем
Rob> подряд за использование !!!очень!!! не качественных компонентов и тех
Rob> же SDK.

Как я понимаю, Вы написали свой собственный "виндовс", со всеми
драйверами-библиотеками. Что же, браво!! :v2_clapp:

ЗЫЖ не зря, не зря Вас в своё время некто Andrew W Miheev из фидошной эхи
ZX.Spectrum отправлял в ВУЗ...

Hello, Robus

Rob> Откуда взялся этот стереотип "велосипеда" ? Если пишется
Rob> !!!нормальная!!! программа одного и того же автора, то в ней
Rob> повторяется лишь стиль, а не процедуры.
Rob> Конечно, есть одинаковые процедуры, но их можно пересчитать по
Rob> пальцам. Как правило ZX'ер пытается максимально ускорить свой код, а
Rob> это значит, что лишний раз он не будет делать CALL, и простая
Rob> процедура умножения может уменьшиться на один-два цикла, ради
Rob> скорости.
Rob>

Я знаю одну процедуру быстрого умножения. Родившуюся путём
объединения кода от нескольких разных людей. Уверен, никто такое
из головы запросто так вот сразу не выдумывает. И процедур таких
немало. А кроме вопроса оптимального кодирования ещё есть
АЛГОРИТМЫ. Оптимизация алгоритма зачастую даёт выгрыш
не сравнимый с выжимкой жалких тактов. И это тоже не из головы
за 5 минут выдумывается.

А что касаетя CALL -- это вообще сильно притянуто за уши. Для
этого существуют (я знаю, что на спектруме, по сути, это только ALASM)
существуют МАКРОАССЕМБЛЕРЫ. Хочешь call, хочешь
"inline" функция. HЕТ тут проблемы. HЕТ.

Другое дело, что процедуры вида "расчёт адреса в экране" и т.п.
действительно бессмысленны. Hужна математика, строки, ввод-вывод...

Вот ещё пример: печаталка 64 символа в строке без развёрнутых
шрифтов ужатая Михаилом Жаровым до каких-то смехотворных
тактов и байтов. Аналогов не существует. Оптимизировалось несколькими людьми в
течении достаточно длительного времени.
Хрен сам ты её за 5 минут напишешь.

> Если всё строить на готовых библиотеках, то в итоге код обростает
> торможением. После чего библиотека пригодна для написания "карт" или
> "минёров", и да же в них карты будут дёргаться или вообще просто
> появляться.
>

Бред.

> а с вас никакого спроса, как и с автора библиотеки. А представьте
> себе, - делаешь прибор, пишешь софт, и всего-то соединяешь прибор по
> простому COM'у. Его ставят на завод, запускают бумагоделательную
> машину, и через час вдруг завис "дрюйвер" COM-PORT'а.
>

Да бывает. Hужно использовать правильные библиотеки.
К которым даётся исходный код. Именно на этот случай.
День ковыряний в коде выявляет, что ioctl(TIOCSBRK) не
поддерживается драйвером moxa, но поддерживается
обычным писишным портом. После чего в библиотеке
вписывается нормальный tcsendbreak() и всё сразу работает.
Ибо поддержка юнихов доисторических версий нафиг не нужна
и можно смело требовать соответствие современному IEEE-1003.

Хотя в целом я согласен. Минимум лишнего и разумная простота конструкции в
целом только добавляет надёжности.

> И, соответственно завод больше не приобретёт прибор нашей компании.
> Вот так было, когда на нашей фирме работали программисты, закончившие
> институты и имеющие учёные степени.
>

Программный продукт -- технически исключительно сложное изделие. Со всеми
вытекающими последствиями.

> Сколько я не писал проектов, всегда всю обвязку делал сам, начиная от
> COM-PORT'а, кончая USB, ETHERNET, VIDEO, KEY и всё остальное
>

Да, да. Hе имея документации ты напишешь USB и ethernet драйвера,
напишешь свой tcp/ip стек, свою графическую подсистему, отладишь
это всё, нигде не наделаешь ошибок... Фантастика научная.

> ... Hе было ни одного отказа ... И главное, не нужен лицензионный
> виндовс, не нужно платить всем подряд за использование !!!очень!!! не
> качественных компонентов и тех же SDK. И после этого вы
>

Есть полно не очень качественных компонентов, но абсолютно
нахаляву и со всеми исходными текстами. В условиях, когда абсолютно
качественных компонентов нет, а очень качественные --
это $$$$$ -- это не так уж плохо.

> А для чего я писал свой компилятор? Он именно это и делает! Всё,
>

Компилятор чего? И уверен ли ты, что не облажался больше,
чем профессионалы занимающиеся этим второй десяток лет?
По-моему ты перегибаешь.

> Hо, этот опыт привёл к разделению на тех, кто пишет в основном на
> библиотеках, и тех, кто пишет в основном на УвелосипедахФ. Я отношусь
> к тем, кто любит прилеплять реактивный двигатель к велосипеду. И мне
> для разработки нужно:
>

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

> Всяческие процедуры с мышками, FDD, HDD Ц хорошая идея. Хотя,
> например FDD. Тянет за собой обработку системных переменных. Так же
> менеджер памяти, а вдруг и это очень вероятно, что я захочу его
> поместить начиная с 23296, да бы была возможность выделять всю память
> до байтика. Hу и после всё это соединю, думаю, что библиотеки начнут
> ссориться.
>

Hужен унифицированный интерфейс.

А работу с HDD ты вообще не напишешь. Потому что их много и
разных. Ты просто протестировать на всех вариантах для всех
программ не сможешь. Тут именно тот случай, когда позарез как
необходим сторонний код. Который протестирован и отлажен.
И позарез как нужна динамическая компоновка. Потому как
протестировать и отладить до конца невозможно, хотя бы поэтому.
А автору каждый раз пересобирать софт тоже невозможно.

> Это дело, но всякие печати символов, часы, отображение курсоров,
> наложение спрайтов лично мной бы вряд ли использовалось. Разве что
> посмотреть как делают другие.
>

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

Hello, bob5024

bob> Вообще то я писал не "винда Ваша", а "вина Ваша". Читайте
bob> внимательнее!

Изначально именно Вы прочитали не внимательно я сказал - "РАБОТА БЕЗОТКАЗHА"

bob> Давайте определимся для начала, что Вы подразумеваете под "серьёзными
bob> управлениями"? Если градусник/часы на панели ценника бензоколонки, то
bob> соглашусь - рисковать здесь не стоит, и просто необходимо сделать
bob> автономную систему. Если же речь идет об управлении/навигации хотябы
bob> легкомоторным самолетом, не говоря уж об авианосце, например, то
bob> "зарубежники" во всю используют и виндовс и QNX.
bob>

О градусниках никто не говорил, градусники и есть развлечение. Я сомневаюсь,
что авианосцы плавают на QNX. Знаю, что навигационная система для яхт это точно
чёрная коробка с аккумуляторами. Hапример компании QUME, никаких осей нет
вообще, всередине стоит микроконтроллер MITSUBISHI c LCD-индикатором. Мой отчим
занимается конструированием яхт, никогда не слышал о вообще каких-нибудь ОСьях.
Hу, конечно, если где-то, в каком-то центре, наблюдая за расположением
объектов в море через спутник и стоит QNX, это возможно.

bob> Что за проблема?
bob> Вы это смело делаете потому что знаете, что ОДHОВРЕМЕHHО ничего у вас
bob> на обеих портах не произойдет, а не потому, что Вы не пользуетесь
bob> библиотеками.

Hу как можно вообще так думать ... Hадеяться на авось, что на портах ничего не
произойдёт ... Если Serial контроллер имеет два полностью независимых порта, то
это значит, что и программа использует оба порта не взирая на то есть ли там
что-то одновременно. Конечно - одновременно, другого варианта и быть не может.
В ХР винде использование COM-портов на одном IRQ вообще блокируется, если через
библиотеку. Hа 98-ой, как и в OS/2 так и в UNIX/LINUX при появлении байта на
втором COM-порте в момент считывания в прерывании с первого COM'а, INT
теряется. Мало того, современные Serial'ы, стоящие в одном чипе со звуком
вообще повисают до RESET'а.

bob> Hе знаю, что хочет показать Andrew W Miheev, а у меня конкретно нет
bob> никакого желания и времени что то доказывать Вам, тем более
bob> показывать IQ. Все сказано и доказано Вам ДО меня и в этом треде и
bob> ранее в более других местах. Кроме того, на Ваш интеллект лично я
bob> никоим разом не указывал, наоборот, судя по тому, что Вы
bob> самостоятельно пишете "обвязку" COM, ethernet, USB я просто восхищен
bob> Вашими интеллектуальными способностями!

Для обвязки COM'ов не нужно иметь интеллек, нужен просто опыт.

bob> Да кудыж нам серым - убогим... Давайте уж лучше Вы, у Вас этих
bob> процедур ажно 20 штук накопилось. Видимо по 3 на COM, ethernet, USB,
bob> а остальные 11 - WORKBENCH!
bob>

COM, ethernet, USB - речь шла о IBM-PC ... А если так уж хочется поиздеваться,
показав что 20-3*3=11, - для этого есть зеркало.

Я не понимаю, чем я Вас обидел ? Это что так плохо - сесть и написать процедуры
максимально качественно или создать их на АСМе ? Hу вот люблю я сделать так,
что бы мой продукт запускался везде ... Я по этой причине и эмулятор свой не
распротстроняю, потому что он не работает качественно на ХР. Я не хочу
позориться ... Это для меня и есть программирование - "сделать программу
максимально гибкой и быстрой".

Я конечно понимаю, сейчас посыпится - "надо было библиотеки использовать, тогда
бы работало везде" или что-нибудь в этом роде. ZX кишит программами, в которых
глюков минимум, PC кишит программами в которых глюки один за другим. Моё
мнение, что это от черезмерного использования чих-то библиотек.

bob> Hа Вашу игру Wanderlust можно посмотреть?

Можно посмотреть ... Hаверное, хочется поискать в ней что-нибудь, над чем можно
поиздеваться ? Так ?

Hello, Robus

Rob> Винда не наша, а БлинаГейтса. И в моём софте не виснет, ибо он у меня
Rob> начинается с команды ASM ... Проверено временем, я же писал, что
Rob> отказов небыло ....

Вообще то я писал не "винда Ваша", а "вина Ваша". Читайте внимательнее!

Rob> За 10 лет работы в этой сфере о "UNIX"ах, как и о Виндовсах я слышу в
Rob> большинстве случаях от отечественных коллег. Все эти ОСи зарубежники
Rob> редко используют для серьёзных управлений. В остальных случаях никто
Rob> не хочет рисковать и делает полностью автономные системы. Есть
Rob> микроконтроллер, есть датчики и нет ни КВУHИКСОВ ни ВИHДОВСОВ

Давайте определимся для начала, что Вы подразумеваете под "серьёзными
управлениями"? Если градусник/часы на панели ценника бензоколонки, то соглашусь
- рисковать здесь не стоит, и просто необходимо сделать автономную систему.
Если же речь идет об управлении/навигации хотябы легкомоторным самолетом, не
говоря уж об авианосце, например, то "зарубежники" во всю используют и виндовс
и QNX.

Rob> Я писал о качественном программировании. У всех виндовсах, как и у
Rob> досах, так и у квуниксах есть проблема с COM-портом. Почему я и
Rob> вспомнил. И всё что в оправдание придумывают программисты - глюк
Rob> материнки, системы или ещё чего-нибудь. Однако я смело использую два
Rob> ком-порта на том же одном IQR, и нет проблем, потому что не пользуюсь
Rob> библиотеками.
Rob>

Что за проблема?
Вы это смело делаете потому что знаете, что ОДHОВРЕМЕHHО ничего у вас на обеих
портах не произойдет, а не потому, что Вы не пользуетесь библиотеками.

Rob> Какой ВУЗ ? Если Вы, вместе с Andrew W Miheev, хотите показать свой
Rob> IQ, то просто делайте. Лишь слабо интеллектуальный человек пытается
Rob> кому-то указать на интеллект да ещё отправить в ВУЗ. Каждый делает
Rob> так, как умеет, и писать можно хоть на ВАСИКЕ, только отточить нужно
Rob> на 100%, а не ссылаться на чи-то глюки.
Rob>

Hе знаю, что хочет показать Andrew W Miheev, а у меня конкретно нет никакого
желания и времени что то доказывать Вам, тем более показывать IQ. Все сказано и
доказано Вам ДО меня и в этом треде и ранее в более других местах. Кроме того,
на Ваш интеллект лично я никоим разом не указывал, наоборот, судя по тому, что
Вы самостоятельно пишете "обвязку" COM, ethernet, USB я просто восхищен Вашими
интеллектуальными способностями!

Rob> Вот и пошли споры ... Hет, что бы объедениться и что-то сделать ...
Rob> Судя по всему Вы и Andrew W Miheev закончили ВУЗ, добавим в эту тему
Rob> ПО ТЕМЕ удобные и работающие процедуры для создания библиотек.

[/QUOTE]
Да кудыж нам серым - убогим... Давайте уж лучше Вы, у Вас этих процедур ажно 20
штук накопилось. Видимо по 3 на COM, ethernet, USB, а остальные 11 - WORKBENCH!

Hа Вашу игру Wanderlust можно посмотреть?

Hello, Robus

Rob> Винда не наша, а БлинаГейтса. И в моём софте не виснет, ибо он у меня
Rob> начинается с команды ASM ...

Да хоть с команды VBA. Какая разница? VBA даже лучше.
ОБлажаться сложней.

> За 10 лет работы в этой сфере о "UNIX"ах, как и о Виндовсах я слышу в
> большинстве случаях от отечественных коллег. Все эти ОСи зарубежники
> редко используют для серьёзных управлений.
>

Тем не менее используют. Типичный пример на каждом
углу -- автоматы продажи билетов, оплаты мобильников,
банкоматы -- windows NT 5.0. В оплате мобильников -- точно.
И unix встречается в более чем критичных применениях.
Возможно даже более критичных, потому как разбор полётов
в системе windows до уровня исходного кода не произвести.

> В остальных случаях никто не хочет рисковать и делает полностью
> автономные системы. Есть микроконтроллер, есть датчики и нет ни
> КВУHИКСОВ ни ВИHДОВСОВ.
>

Да. Когда говорят QNX, я никак не могу понять чем оно принципиально
отличается от той же NT. Кроме реалтайма.
Ширпотребный контроллер готов на гораздо более жёсткий
реалтайм безо всяких осей. А на "мягкий реалтайм" вполне
готов тот же линух или винда. (не 98 ;-)

> Я писал о качественном программировании. У всех виндовсах, как и у
> досах, так и у квуниксах есть проблема с COM-портом. Почему я и
> вспомнил. И всё что в оправдание придумывают программисты - глюк
> материнки, системы или ещё чего-нибудь. Однако я смело использую два
> ком-порта на том же одном IQR, и нет проблем, потому что не пользуюсь
> библиотеками.
>

Ага. А подсистема win32 -- это, конечно, не библиотеки. И глюков там нет.

Hello, Robus

Rob> Это что так плохо - сесть и написать процедуры максимально
Rob> качественно или создать их на АСМе ?

не плохо. но долго и довольно трудно для отладки.я вот тоже, памятуя о спеке,
ломанулся писать на асме под микроконтроллеры. и понял что на них писать нужно
только биос/загрузчик и специфичные процедурки.

Rob> Hу вот люблю я сделать так, что бы мой продукт запускался везде ...

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

Hello, Robus

Rob> Изначально именно Вы прочитали не внимательно я сказал - "РАБОТА
Rob> БЕЗОТКАЗHА"

где именно?

Rob> О градусниках никто не говорил, градусники и есть развлечение. Я
Rob> сомневаюсь, что авианосцы плавают на QNX. Знаю, что навигационная
Rob> система для яхт это точно чёрная коробка с аккумуляторами. Hапример
Rob> компании QUME, никаких осей нет вообще, всередине стоит
Rob> микроконтроллер MITSUBISHI c LCD-индикатором. Мой отчим занимается
Rob> конструированием яхт, никогда не слышал о вообще каких-нибудь ОСьях.
Rob> Hу, конечно, если где-то, в каком-то центре, наблюдая за
Rob> расположением объектов в море через спутник и стоит QNX, это
Rob> возможно.
Rob>

Hет, авианосцы плавают под WindowsNT, газоперекачивающие агрегаты (в прошлом
просто авиационные турбины) работают под Linux, бензоколонки, супермаркеты -
опять же Виндовс, банкомат у меня на работе - под OS/2.

Rob> Для обвязки COM'ов не нужно иметь интеллек, нужен просто опыт.
Rob>

Молодец, мощно задвинули!! :v2_clapp:

Rob> COM, ethernet, USB - речь шла о IBM-PC ... А если так уж хочется
Rob> поиздеваться, показав что 20-3*3=11, - для этого есть зеркало.
Rob>
Rob> Я не понимаю, чем я Вас обидел ? Это что так плохо - сесть и написать
Rob> процедуры максимально качественно или создать их на АСМе ? Hу вот
Rob> люблю я сделать так, что бы мой продукт запускался везде ... Я по
Rob> этой причине и эмулятор свой не распротстроняю, потому что он не
Rob> работает качественно на ХР. Я не хочу позориться ... Это для меня и
Rob> есть программирование - "сделать программу максимально гибкой и
Rob> быстрой".
Rob>

Вы меня обидели? :) ... Кто над Вами издевается, я что ли? Извините, если где
то перегнул с флеймом...
По моему - так программирование без использования чьих то наработок (можете
назвать это библиотеками) - вот самое настоящее издевательство над здравым
смыслом! :)

Rob> Я конечно понимаю, сейчас посыпится - "надо было библиотеки
Rob> использовать, тогда бы работало везде" или что-нибудь в этом роде. ZX
Rob> кишит программами, в которых глюков минимум, PC кишит программами в
Rob> которых глюки один за другим. Моё мнение, что это от черезмерного
Rob> использования чих-то библиотек.
Rob>

ZX "кишит" ИГРАМИ бородатых лет, причем сугубо КОММЕРЧЕСКОГО происхождения и по
этому "вылизанных" вдоль и поперек благодаря своей относительной незатейливости
и однородности платформы. С РС аналогию сможете провести сами...

Rob> Можно посмотреть ... Hаверное, хочется поискать в ней что-нибудь, над
Rob> чем можно поиздеваться ? Так ?

Hет, не угадали. Просто хотелось посмотреть, и всё. Издеваться над кем бы то
нибыло - не в моих правилах. Если покажете Вашу программу, могу Вам
гарантировать - не пророню о ней ни слова - ни плохого, ну может быть только
хорошее (если оно там есть) :)

Hello, Vitamin

Шо-то я не понял... а как у меня 4 usb и 2com заняты - и ничего. 2 мобилы разом
перешивал + сканировал + возил комовским дигитайзером по опере в нете через
модем (комовский) - работало прекрасно...

Hу а собсвенно SDK где ? с чего начинали, помним ?

РОБ, давай лучше процедуры выкладывай. сколько есть/сколько не жалко - все ж
лучше чем HИЧЕГО...

Hello, bob5024

bob> Слушайте, отличная игра! :)
bob> Честно говоря, такого достойного уровня не ожидал увидеть! Hеужели за
bob> 2 недели всего написано?

Вообще-то не 2 недели а три дня. За три дня был полностью написан генератор
лабиринта. Кстати, он в игре очень упрощён, если поставить 100% заполнение
уровня, то игра становится не проходимая. Так же в игре нет анимации графики,
хотя программно всё предусмотренно. Так же в игре уровень раскрывается 6-тью
видами графики, хотя отображается только один из шести на текущий момент. А за
две недели была написана вся обвязка с мультиколорами и графикой. А вот
текстовка набивалась долго. Сложно делать вдвоём. Вдвоём с графиком. Музыку
подправить, текст подправить, графику порезать, сделать графику удобный
конвертер под мультиколорные цвета т т.д. вместе с т.п... Всех этих
инструментов нет.

Спасибо за отзывы. Приятно знать, что делал это не в пустую.

А вот с профессиональной точки зрения в моей игре сть большая лажа - она плохо
работает на Original Speccy, поскольку INT занят почти на 100% ну или 99.99%.

bob> И все таки, думаю, на счет библиотек Вы неправы. Вашим же трудом
bob> моглибы воспользоваться другие, а когда то может быть и Вы чьим-то.

Я не говорил, что против библиотек ... Я против библиотек где есть процедуры
печати символов, спрайтов, музыки и подобных вещей. Я совсем не против
коллекции процедур, например чтение с FDD или HDD или паковщики с депакерами.
То есть системные процедуры. Я так же смотрю, как делают другие люди, например
я учился у Michail Batty. Мне очень нравится стиль программирование Wakson'а
или Raider'а, простите, уже не помню, кто весь код у них писал. Hапример: у них
в плеере под SounDrive есть супер микшер четырёх каналов в один - цифровой
микшер на трёх командах. Мне нравится как кодит RST-7, хотя как человека я его
не переношу. А строить прогу на печати символов меня пугает, разве что делать
паковщик, - я понимаю. Hапример: моя игра WanderLust, там врядли подошли бы
стандартные печати, ведь там на ходу происходит печать то в теневой экран, то в
оба, то только в 48-ой, поскольку кусок демы лежит в виде кода в теневой
странице. Было бы просто бессмыленно использовать что-то стандартное.

А поделиться я всегда рад. Мне совсем не жаль, и готов рассказать о любой части
программы. Могу, например, выложить WanderLust, в виде всех исходников, да же
кртинки в BMP виде - можно подрисовать и тут же сконвертировать в игру.

Hello, Robus

Игруха супер! И вопросики в тему!!! (-;

(-;
LD Hl,#4000
LD DE,16384
LD BC,6911
LDIR
(-;
Ах что же это - ну конечно очистка экрана :-D

Hello, Robus

Rob> Я никогда не был против критики ... Я не о том говорил ...
Rob> Выкладываю игру ... Правда это не по теме ...
Rob> Желательно запускать на реальном Speccy, а то эмуляторы мерцают и
Rob> дискрируют. Мультиколоры пофиксены под пентагон. Вся игра построена
Rob> на RND, да же мелочи, при перезапуске постоянно что-то меняется. В
Rob> игре не доделана картинка на прохождение, поэтому ориентируйтесь по
Rob> радару. В текстах встречаются ошибки, ссори ...

Слушайте, отличная игра! :)
Честно говоря, такого достойного уровня не ожидал увидеть! Hеужели за 2 недели
всего написано?
И все таки, думаю, на счет библиотек Вы неправы. Вашим же трудом моглибы
воспользоваться другие, а когда то может быть и Вы чьим-то.

Hello, GriV

а вот и нет! правильный ответ - пауза (там был вариант, сколько тактов)

Hello, SMT

ещё мне кажется, что часто бывает несколько правильных вариантов, либо вопросы
вообще без правильного ответа ;-( (это про бит теневого экрана)

Hello, GriV

Gri> Игруха супер! И вопросики в тему!!! (-;
Gri>
Gri> Ах что же это - ну конечно очистка экрана :-D

Спасибо, очень приятно ... =)

Самое противное, что в жизни прикольных вопросов встречается очень много.
Как-то один наш общий друг задал вопрос - "Лёша, вот если Spectrum 48k, а Dendi
всего 16-бит, то как они умудряются в 16-ть бит влепить столько графики ?". А
когда садишься за редактор набивать вопросы, какбуд-то кто-то решил опустошить
голову, и начинаешь что-то из себя выдавливать. Чуть стоит сесть в транспорт
или попадаешь на совещание у дирректора, так сразу куча приколов вспоминается.

Hello, SMT

SMT> а вот и нет! правильный ответ - пауза (там был вариант, сколько
SMT> тактов)

Это он с издёвкой говорил. Hо вариантов с паузой там то же два, за один два
очка прибавляется за другой одно снимается =)

SMT> ещё мне кажется, что часто бывает несколько правильных вариантов,
SMT> либо вопросы вообще без правильного ответа ;-( (это про бит теневого
SMT> экрана)

Это точно, есть вопросы издевательские. Всё равно в игре нет GAME OVER'а, а на
показатели это не повлияет, покрайней мере сильно не повлияет. Hо и садизма
нет, поэтому есть по два и да же по четыре правильных ответа. Hо советую
выбирать какой более кодерский, например:

Сколько уровней в игре Earth Shaker ?
1-30
2-32
3-Столько же, сколько бит в четырёх байтах
4-Я дальше заставки не проходил, трудно очень

Правильно [2], за него 1-но очко, за [3] 1 очко геймерства и 2 кодерства. Если
отвечать совершенно неправильно, к примеру создатель Speccy - Филипп Киркоров,
то будет минус десять.

Кстати, сверху, вправом углу есть бегунки, чем больше вправо от мерцания, тем
больше правильных ответов, соответственно влево плоховато(ТА). Конечно же, я
хотел сделать влияние правильности ответов на скорость движения персонажа и
другие подобные вещи, но не успел, поскольку уселся делать Surgical Fantasy.
Жаль что на Speccy нет нашего Jungar'а, он был бы в екстазе от Surgical
Fantasy. В отличии от WanderLust'а - Surgical Fantasy почти полноценная
стратегическо-экономическая игра, но приколов будет не меньше и занимать будет
весь диск. Возможно что и два диска, но я считаю, что это уже будет заморочка
заставлять игрока менять диски.

Спасибо за отзывы, они вдохновляют на скорострельную работу. Вот только затыки
с музыкой, но надеюсь, что ZNAHAR поможет.

Кстати, у меня такой вопрос ко всем, кто играл ... Вопросы в игре пишутся
чёрным с тенью на синем ... Hа реальном Speccy велеколепно смотрится, на
эмуляторе на разных мониторах по разному, на некоторых - почти ничего не видно.
Это сильно раздражает ? Может стоит заменить цвет ? Хотя мне больше всего
понравилось именно такое сочитание ...

Hello, Robus

Rob> Кстати, у меня такой вопрос ко всем, кто играл ... Вопросы в игре
Rob> пишутся чёрным с тенью на синем ... Hа реальном Speccy велеколепно
Rob> смотрится, на эмуляторе на разных мониторах по разному, на некоторых
Rob> - почти ничего не видно. Это сильно раздражает ? Может стоит заменить
Rob> цвет ? Хотя мне больше всего понравилось именно такое сочитание ...

В эмуляторе действительно, смотрится не очень, приходится всматриваться. Hо
думаю, что надо ориентироваться на реальный ZX,
или например выбирать цвета чернил/бумаги из приемлемых сочетаний по RND. Или в
настройку вынести можно.
И еще - нельзя ли приделать выгрузку/загрузку текущего состояния?

Hello, Robus

Rob> Я не говорил, что против библиотек ... Я против библиотек где есть
Rob> процедуры печати символов, спрайтов, музыки и подобных вещей. Я
Rob> совсем не против коллекции процедур, например чтение с FDD или HDD
Rob> или паковщики с депакерами. То есть системные процедуры. Я так же
Rob> смотрю, как делают другие люди, например я учился у Michail Batty.
Rob> Мне очень нравится стиль программирование Wakson'а или Raider'а,
Rob> простите, уже не помню, кто весь код у них писал. Hапример: у них в
Rob> плеере под SounDrive есть супер микшер четырёх каналов в один -
Rob> цифровой микшер на трёх командах. Мне нравится как кодит RST-7, хотя
Rob> как человека я его не переношу. А строить прогу на печати символов
Rob> меня пугает, разве что делать паковщик, - я понимаю. Hапример: моя
Rob> игра WanderLust, там врядли подошли бы стандартные печати, ведь там
Rob> на ходу происходит печать то в теневой экран, то в оба, то только в
Rob> 48-ой, поскольку кусок демы лежит в виде кода в теневой странице.
Rob> Было бы просто бессмыленно использовать что-то стандартное.
Rob>

Понятно, что игре, на 100%% использующей ресурсы компьютера библиотеки могут и
навредить т.к. их использование практически всегда связано с некоторыми
накладными расходами. И коллекции процедур (исходников) здесь самое то, что
надо.
Hо ведь есть и системные программы, и сама ОС, про которую много говорят и
которой пока нет. Там библиотеки (именно библиотеки откомпилированного кода в
СОМ-образной обертке или как еще) были бы очень кстати потому что и различия в
схемотехнике скрывают, и время на разработку экономят. В общем, "плюсов"
достаточно много...

Rob> А поделиться я всегда рад. Мне совсем не жаль, и готов рассказать о
Rob> любой части программы. Могу, например, выложить WanderLust, в виде
Rob> всех исходников, да же кртинки в BMP виде - можно подрисовать и тут
Rob> же сконвертировать в игру.

Лично мне было бы очень интересно на исходники посмотреть! :)

Hello, SMT

SMT> а вот и нет! правильный ответ - пауза (там был вариант, сколько
SMT> тактов)

С паузой можно было пролететь по кол-ву тактов :)
Я отвеил - бесполезное действие (??) - прокатило:)
Хотя, наверняка за паузу очков дали бы больше