Идея была рульная, но никто (и я в том числе ^_~) кроме 3.14 здежа ничем её не поддержал.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Чтобы это утверждение было осмысленным, а обсуждение конструктивным, неплохо бы вкратце объяснить, когда драйверы нужны, а когда не нужны, и почему.Сообщение от Sinus
Нет не так.
Подобные "преобразователи интерфейсов" могут быть реализованы в виде отдельных модулей и динамически загружаться и компоноваться при необходимости.
То есть ситуация "много интерфейсов - одна реализация" особо ничего не даёт, и приводит лишь к избыточному коду.
Гораздо важнее ситуация "один интерфейсов - много реализаций", при котором через один интерфейс могут вызываься разные реализации, причём конкретная реализация определяется динамически во время исполнения. В ООП это называется "полиморфизм". Лучше всего если реализации можно подключать и отключать во время исполнения.
Для реализации полиморфизма обычно используются "виртуальные функции". К сожалению, понадобится компилятор, который умеет автоматически строить таблицы виртуальных функций. А такого нет.
Потому предлагается упрощённый вариант: процедурные переменные aka казатели на процедуры. Это не обязательно адреса. Скорее даже наоборот не адреса, учитывая страничную модель памяти. Просто некоторый хэндл. Вероятно, двухбайтового числа будет достаточно. Этот идентификатор выдаётся во время загрузки и динамической компоновки модуля, содержащего реализацию интерфейса. И будет специальная процедура для вызова процедуры через хэндл. Программист будет передавать хэндл в качестве аргумента и по нему будет вызываться нужная реализация.
К вопросу о динамических библиотеках для спектрума:
http://www.nedopc.org/nedopc/shaos/libman_r.shtml
В-кратце - это менеджер библиотек, который был создан мною в 2002 году для компьютера Спринтер (под голимый Спектрум переделать - дело пары вечеров). Библиотеки для такого менеджера представляют из себя куски перемещаемого (с шагом 256 байт) кода размером менее 16К, которые грузятся менеджером в фоновую память и по хендлу можно вызывать отдельные функции этих библиотек, причем программист может и не знать в какой конкретно странице памяти и по каким адресам сидит та или иная библиотека. Если интересно - сделаю универсальную реализацию, покрывающую самые популярные клоны.
Администратор сетевого сообщества nedoPC.org
Урал 8/64К, Sp2000, ZX48K+, ZX16K (спалил), TS1000 (американский ZX81), TS2068, Дельта-С, 20 лет собираю ATM Turbo 2+
Неспектрумы: Электроника МК-85 и МК-85М, ПК-01 Львов, БК-0011, Вектор-06Ц, Лик (спец), Апогеи, Radio-86RK SRAM 32K & 128K (всё ещё собираю)
Итак
я тут долго отчего то в тему не заглядывал, она тут мирно катилась
Вот у меня есть следующие соображения:
Касательно способов вызова - было сказано в http://zx.pk.ru/showpost.php?p=32310&postcount=67
и много копий было сломано в http://zx.pk.ru/showthread.php?t=1811
Потому я так понимаю способ вызова через RST отклоняется и остаётся два способа - кернальный (начинается цепочкой JP) и модульный (начинается таблицей релокации).
Бесполезно здесь спорить об их нужности, потому будем принимать их вместе.
Касательно интерфейса вызовов - использовать можно регистры, стек, указатели. Каждый из методов имеет как достоинства так и недостатки. А потому каждый из них имеет право на жизнь - в силу специфики. Я так понял что невозможно осуществить передачу данных указателем согласно интерфейсу Hitech-C, если это так то его (возможно) нужно дорабатывать. Вообще моё личное мнение, что способ передачи информации (стек или указатель) в конечном итоге мало скажется на производительности(больше/меньше). Это связано с тем, что придётся работать в принципе с теми же данными которые реализуются (читаются/пишутся) вообще то теми же системами команд, потому спор касательно передачи параметров - через стек или через указатель - так же считаю не существенным.
Теперь касательно библиотек - они В ЛЮБОМ СЛУЧАЕ нужны, Станислав уже предлагал метод - просто пробовать написать что нибудь совсем примитивное - на чём собственно будет отлаживатся вся система SDK.
Ставим цель - написание SDK
Ставим задачу - отлаживание SDK на примере игры "Сапёр"
Необходимо создать следующие процедуры:
- Процедура пиликания - при удачном отгадывании мины при взрыве
- Процедура обработки курсора - курсор ложится поверх имеющейся картинки, запоминает что он собой затирает и потом (второй вызов или вызов в заданную точку этой же процедуры) восстанавливает фон
- Процедура рисование окон - не атрибутное рисование а полноценное, допущение - нет необходимости запоминать фон под окном
- Процедура печати текста - печать текста в заданном окне, параметрами являются ширина окна и высота впечатываемого текста - т.е. предложения текст автоматически разбиваются на слова и если слова не помещается то оно переносится
- Процедура опроса клавиатуры и манипуляторов - мышки и джойстиков
Принимаются варианты каждой из дискретных указанных выше процедур - просьба не выкладывать готовое всё-в-одном.
Соглашения: каждая процедура должна быть документирована. Обязательно наличие примеров использования (для реализации указанной задачи).
Конструктор (ZX SDK)
Привет тебе, _/Alexander/_!
02 декабря 2005 19:37, Alexander Bondarenko писал(а) Stanislav Yudin:
Если определен стандартный шаблон описания функции/процедуры, то в общем-то не так и трудно доку написать. Какая информация нам нужна?Вот это самое сложное, обычно докy-то и лень писать...
1. Hазвание модуля.
2. Hазвание функции/процедуры.
3. Входные (аргументы) и выходные (результат) параметры.
4. Возможные ошибки и исключения.
5. Требования к другим модулям.
6. Примерные размер и время выполнения.
7. Подробное описание действия функции.
8. Ссылки на описания используемых функции и структур.
9. Автор(ы).
Вроде бы этого достаточно.
До новых встреч! С уважением, Тхэнн.
... Nereal was created for us
ZX SDK
Х-м, на нашем форуме любая, даже хорошая, идея превращяется во флейм. Х-м.
Откуда взялся этот стереотип "велосипеда" ? Если пишется !!!нормальная!!! программа одного и того же автора, то в ней повторяется лишь стиль, а не процедуры. Конечно, есть одинаковые процедуры, но их можно пересчитать по пальцам. Как правило ZX'ер пытается максимально ускорить свой код, а это значит, что лишний раз он не будет делать CALL, и простая процедура умножения может уменьшиться на один-два цикла, ради скорости. Если всё строить на готовых библиотеках, то в итоге код обростает торможением. После чего библиотека пригодна для написания "карт" или "минёров", и да же в них карты будут дёргаться или вообще просто появляться.
Может я в чём-то заблуждаюсь ? Сколько не писал программы на СИ, ПАС, ВАСИКе, - я постоянно сталкиваюсь, что все эти библиотеки не работают как нужно. То на другой версии винды чего-то не поддерживается, то через час что-то перекосится и процесс виснет. Одно дело, когда делаешь какой-нибудь конвертер, он в процессе переглючит, пользователь как всегда плюнет в экран, и перезапустит, а с вас никакого спроса, как и с автора библиотеки. А представьте себе, - делаешь прибор, пишешь софт, и всего-то соединяешь прибор по простому COM'у. Его ставят на завод, запускают бумагоделательную машину, и через час вдруг завис "дрюйвер" COM-PORT'а. И, соответственно завод больше не приобретёт прибор нашей компании. Вот так было, когда на нашей фирме работали программисты, закончившие институты и имеющие учёные степени. Сколько я не писал проектов, всегда всю обвязку делал сам, начиная от COM-PORT'а, кончая USB, ETHERNET, VIDEO, KEY и всё остальное ... Не было ни одного отказа ... И главное, не нужен лицензионный виндовс, не нужно платить всем подряд за использование !!!очень!!! не качественных компонентов и тех же SDK. И после этого вы говорите, что не нужно изобретать велосипед. Конечно, если делать "мышки(манипулятор)" или писать "смотрелку картинок" этого хватит. А более серьёзное ? Хотя каждую программу нужно писать на 100%, не смотря на то, что она делает.
А для чего я писал свой компилятор? Он именно это и делает! Всё, что сверху описано, уже реализовано. Наработку библиотек - за вами. Но не нужно отбирать, можно описать процедуры так, что использовав любую из них в тексте, она автоматом добавится в код. Ну, про компрессию и готовый загрузчик я уже устал писать ... Правда компиляция происходит на ПиЦи, а не ZX’е, поскольку я уже устал на ZX’е писать прогу по кускам, каждый раз думая как бы для отладки сделать так, что бы не убить в памяти ассемблер. На своём языке я написал игру Wanderlust, занявшая вообще всю 128-ую память и потратил на это две недели. Сейчас пишу игру Surgical Fantasy. Если бы был удобный графический редактор, редактор фонтов, соответственно редактор текстовки под этот фонт, то уже давно бы закончил и этот проект. А так приходится писать самому, благо уже заканчиваю, а то руки чешутся от того, как хочется закончить игру.
Но, этот опыт привёл к разделению на тех, кто пишет в основном на библиотеках, и тех, кто пишет в основном на “велосипедах”. Я отношусь к тем, кто любит прилеплять реактивный двигатель к велосипеду. И мне для разработки нужно:
+ 1.00 Асм с:
+ 1.01 Пакером.
+ 1.02 Loader-Creator.
+ 1.03 Возможность работы с метками, которые будут в будущем.
+ 1.04 Возможностью запаковывать части кода, используя один из другого.
+ 1.05 Иметь плейер PT3 с возвратом на каком POS/LINE мы находимся.
- 2.00 Графический редактор с:
- 2.01 Редактирование изображения до 65536х512 пикселей.
- 2.02 Редактирование фонта до 256х256 пикселей каждый символ.
- 2.03 Редактирование спрайтов и возможность их разукрасить.
- 2.04 ГЛАВНОЕ – Редактирование двух экранных изображений.
- 3.00 Музыкальный редактор.
+ 4.00 Редактор текста для ASM’а
(+ Есть)
(- Нет)
Я знаю, что есть графический редактор, но я в них не могу получить нормальный, готовый к употреблению файл. А сидеть и придумывать способы как вырезать кусок изображения, превратить его в спрайты, а если ещё нужно сделать двух экранную, то вообще - один Бог в помощь. Поэтому в последней моей игре WanderLust, для спрайтов написан один конвертор, который настраивается и выдаёт полностью готовые спрайты, да ещё их запаковывает, и делает отдельным куском, который подгружается в страницу и автоматически используется в игре.
Музыкальный редактор, близкий к употребляемому - я видел только у Alone Coder’а (PT3) и BACA&LAVE (DMM). Остальное очень не удобное.
Всяческие процедуры с мышками, FDD, HDD – хорошая идея. Хотя, например FDD. Тянет за собой обработку системных переменных. Так же менеджер памяти, а вдруг и это очень вероятно, что я захочу его поместить начиная с 23296, да бы была возможность выделять всю память до байтика. Ну и после всё это соединю, думаю, что библиотеки начнут ссориться. А вот если разбить каждую библиотеку на самые важные элементы, например FDD:
- Init System Vars
- Read TR
- Write TR
- и т. д.
Это дело, но всякие печати символов, часы, отображение курсоров, наложение спрайтов лично мной бы вряд ли использовалось. Разве что посмотреть как делают другие.
У меня есть библиотека, которую я использую, но она почти не пополняется, там лежит два десятка процедур, остальное не повторяется от программы к программе.
Я знаю, что далёк от стиля программирования, которым следуют большинство из тех, кто обсуждает эту тему, поэтому извиняюсь, что влез в разговор.
AAA когда меня режут, я терплю, но когда дополняют, становится нестерпимо.
Во первых: неизвестно, почему у Вас там всё через час зависло. Может Ваша же вина, в Вашем "софте".
Во вторых: только ОЧЕНЬ недалёкие люди могут строить АСУ ТП под управлением виндовс. Виндовс - для офиса, а в такие места - UNIX, QNX.
Как я понимаю, Вы написали свой собственный "виндовс", со всеми драйверами-библиотеками. Что же, браво!!
ЗЫЖ не зря, не зря Вас в своё время некто Andrew W Miheev из фидошной эхи ZX.Spectrum отправлял в ВУЗ...
Turbo 2+; Scorpion ZS 256 turbo+
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
[
Ответить с цитированием
