Одна ремарка: "3..4 раза" это коэфициент для расчетов ресурсов для реальной комерческой задачи портирования существуещего кода (например игры exolon на ZX) на другую платформу для большенства (99%) случаев. Ясное дело что этот коэфициент имеет "запас" на случай непредвиденного расхода быстродействия и\или памяти. Говорить об коэфициенте в 1.5...2 раза тоже иногда можно, но гораздо в меньшем количестве случаев.
это кем она планируется?Сообщение от Eltaron
я так понимаю,я буду выкладывать примеры, а остальные будут их изучать и высказывать пожелания, типа "вот здесь надо вот так, а вот это вообще убрать " и т.д.
как показывает практика, желающие покритиковать всегда найдутся
---------- Post added at 16:47 ---------- Previous post was at 16:40 ----------
Подобрал...
Ну шо, сразу насыпать их сюда или всё-таки есть надежда, что уважаемые "ученички" сами
попробуют чё-нить сделать?
---------- Post added at 16:56 ---------- Previous post was at 16:47 ----------
Тут есть два варианта - ждать и не возвращаться в задачу, пока пользователь не нажмёт любую кнопку, или же при отсутствии нажатой кнопки сразу возврат в задачу.
Мы остановимся на втором варианте - при не нажатой клавише - установлен флаг NZ, а при нажатой клавише - установлен флаг Z, и в рег. A - будет ASCII-код нажатой клавиши
В этой функции задача дополнительно будет устанавливать 2 флага:
1-й флаг - сброшен - продолжать печатать по текущим координатам,установлен - печатать по новым координатам
2-й флаг - установлен - очистить экран перед печатью, сброшен - не очищать
---------- Post added at 17:08 ---------- Previous post was at 16:56 ----------
Еще нужны функции:
bread - прочить блоки в память из файла (при этом указатель будет перемещаться внутри файла)
bwrite - записать блоки из памяти в файл - аналогично bread
Вот этих функций уже хватит, чтобы загружать длинный текст (длиной больше, чем может поместиться в памяти).
bwrite - понадобиться , чтобы сохранять настройки - и задачи и ядра.
Последний раз редактировалось Zet9; 14.02.2010 в 17:43.
Сорри что вмешиваюсь, возможно упустив нить рассуждения. Какова цель данного "курса" по написанию оси? Поделиться/обменяться знаниями? Написать ось?
Вмешиваюсь как модератор:
1. Тема находится в разделе программирование - пишите сюда код и критикуйте код; если не увижу далее в теме кода, тема уедет в другой раздел;
2. Много подобных рассуждений уже было и на этом форуме: читаем и ищем в http://zx.pk.ru/forumdisplay.php?f=23 - там рассказывается и про ММУ, и про ядро, и про драйверы, и про файловую систему в т.ч.;
3. Прежде чем продолжать дискуссию не поленитесь заняться ликбезом, например прочитать книгу про то, как создаются ОСи. В качестве рекомендуемого издания: "Сетевые Операционные Системы" В.Г. Олифер, Н.А. Олифер.
Пока ни одного примера который можно изучить я не увидел. Как от создателя темы требую перевести дискуссию в более соответствующее разделу русло.
Операционная система Микроб
Версия 0.00.
Пока только ядро в составе рассмотренных выше драйверов клавиатуры и экрана, плюс исходники этих драйверов и драйвера: файловой системы тр-дос и дисковода (последний в двух вариантах - непосредственно работающий с ВГ93 и работающий через #3D13 - этот будет нужен для ускорения отладки(на винте, на рам-диске и т.д.), плюс лицензия
Загружается ядро и пишет на экран приветствие.
---------- Post added at 21:33 ---------- Previous post was at 21:23 ----------
Исходники в формате ассемблера Alasm
Файлы исходников:
DEVKBD - драйвер клавиатуры
DEVSCR32 - драйвер экрана - выводит 32 символа в строке
Материалы для драйверов - требуется "доработка напильником" для превращения в драйвера, пока не входят в состав ядра.
TRD - материал для драйвера файловой системы тр-дос
FDD_3D13 - "ненастоящий" драйвер дисковода, обращается к 3D13
FDD_VG93 - драйвер дисковода, для доступа к ВГ93 использует один из мини-драйверов
FDD_RAM - мини-драйвер ВГ93 - использует точку доступа 3D2F и часть процедур пзу трдос
FDD_CASH - мини-дайвер ВГ93 - напрямую обращается к ВГ93 - должен располагаться в кеше или в свободной области пзу тр-дос.
Изучаем, задаём вопросы,
быстрые ответы не обещаю[COLOR="Silver"]
---------- Post added at 21:53 ---------- Previous post was at 21:33 ----------
Вроде ж в первых постах этой темы и "Теории" говорил о целях
Ну попробую ещё раз
Просто хочу поделиться своим видением вопроса.
Предлагаю сделать ось home use only, так сказать чисто для домашнего применения, которая не будет пытаться затмить уже существующее, и не должна распространяться, словно чума, на всё сообщество, а наоборот, призвана решать конкретные задачи её автора - это с одной стороны. А с другой стороны - сделать её достаточно простой и такой, чтобы любой желающий мог,изменив одну или несколько её частей, использовать в своих конкретных целях, без оглядки на "авторитеты", на "концепции и идеологии", так сказать "для себя любимого", ведь платформа Спектрум - это в первую очередь - свобода творчества, здесь можно делать то, что нужно именно тебе,и именно таким образом,которым удобно тебе, И над нами не довлеет человек,указывающий нам единствено верный, с его точки зрения, путь, и свернувший с этого пути У НАС, не будет тут же убит упавшим на него окном "Программа выполнила недопустимую операцию и будет закрыта".
А значит, можно делать что угодно в этом направлении, и в этой теме я хочу осветить некоторые возможности,доступные только на нашей платформе,[COLOR="Silver"]
Последний раз редактировалось Zet9; 17.02.2010 в 22:58.
Моя программка на С для AT8535 (память команд - 8К, т.е. 4096 команд) была не "Эхолон".. Это да..
В реалтайме обрабатывала информацию с 30 датчиков и управляла 15 двигателями. Плюс к этому - держала интерфейс пользователя на 7-сегментных индикаторах.
Как думаешь - что сложнее - обработать 5 кнопок ввода пользователем в эхолоне или 30 датчиков? Я уж не говорю про то, что зависание эхолона - никакого вреда, кроме мата пользователя не принесёт.. Чего не скажешь о зависании программы управления очисткой воды, которую я писал...
В принципе вся "сложность" в игре типа эхолон - это скорость перестроения экрана. А никак не логика.
---------- Post added at 01:00 ---------- Previous post was at 00:47 ----------
По-моему вы не с того начали.Операционная система Микроб
Версия 0.00.
Драйвера - это всё хорошо, но! Есоли пишите ОС, то, ИМХО, вначале ответьте на такие вопросы:
1. Как ОС будет взаимодействовать с ПО пользователя. То есть "механизм системных вызовов". Механизм должен быть единым для всех программ, пригодным для любого клона, на котором планируется запуск ОС.
2. Как будет происходить переключение задач. Тип многозадачности, события, переключающие задачи, механизм переключения задач.
3. Как будет органиована совместимость с ПО, не поддерживающим данную ОС (старые программы, игрухи и проч.)
4. Как будет выделяться память. Скажем, учитывая архитектуру спека, можно ограничить максимальный объём памяти, выделяемой за раз - 16К.
5. Список основных системных вызовов. Их функции.
ИМХО, когда ответите на все эти вопросы - только тогда можно браться за написание программы. Иначе - получится нечто кривонесовместимое и непонятноработающее.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Т.е. всё по-прежнему
модератора не слышим?
Неужели так трудно отвечать на оффтоп в теме "Пишем свою ОС.Теория" (если уж очень хочеться на него отвечать) ?
"Восходящий" метод пользуется популярностью даже у таких ГУРУ,как Кен Томпсон.
Мне тож нравиться
Почти на все уже отвечал, можете полистать тему, если повезёт - в куче флэйма найдёте ответы - или ждите пока модератор очистит тему от мусора
Микроб однозадачный. Переключение задач и многозадачность будем изучать на следующих курсах.Это учебная ОС, поэтому вопрос совместимости в данном слуяае не важен. Впрочем никто не запрещает сделать запускалку для Бэйсиков,кодовых файлов,всяких там TRF-фов.
---------- Post added at 17:23 ---------- Previous post was at 17:14 ----------
Пришло время добавить нашему микробу какие-нибудь конечности, которыми он сможет грести к "светлому будущему"(уши,например).
Сегодня мы займемся файловой системой,ведь пока она не подключена к ядру, мы не можем загрузить ни задачу, ни конфигурационные файлы системы.
Брукс в своей книге "Мифический человеко-месяц" предлагает понаделать заменителей и заглушек, собрать всё в один главный цикл и как можно быстрее получить "Работающую версию программы".А в дальнейшем переделывать заменители на нужные функции, вместо заглушек добавлять модули, и при этом на каждом шаге разработки по-прежнему будет РАБОТАЮЩАЯ версия программы.
Для файловой системы в качестве предлагаемого заменителя будем использовать драйвер дисковода FDD_3D13,который в дальнейшем заменим на FDD_VG93.
Диспетчера виртуальной файловой системы пока у нас не будет, будем сразу обращаться к драйверу TRD,а тот будет вызывать FDD_3D13.
Но сделаем заготовки - обращаться к ним будем не напрямую, а через дополнительные JP XX, в которых сначала лежат адреса ЭТИХ драйверов, а позже будет подставляться диспетчером адреса драйверов для конкретных логических устройств.
Распределим память ядра следующим образом (впрочем это не обязательно окончательное решение):
Стэк пока будет общий для ядра и задачи - длиной 256 байт по адресам #5b00-#5c00.
Шрифт у нас длиной 2 Кб будет по адресу #7800 (это #8000-2Кб).
Буфер файловой системы для каталога длиной 2,25 Кб будет по адресу #6F00 (это #8000-2Кб-2.25Кб).
С адреса #6000 по #6A00 (примерно) сейчас расположен код ядра.
Свободным на данный момент 1,25 Кб после кода ядра и .5 КБ до кода ядра по адресу #5e00.
Драйвер FDD_3D13 принимает номер функции в рег. A,содержит 3 функции:
0-выбрать диск , в рег.C - номер дисковода 0,1,2 или 3
1-прочитать несколько(в рег.B) блоков по 256 байт в буфер по адресу HL',номер блока в рег. DE (младшие байты номера) и в рег. DE' (старшие байты)
2-записать блоки - входные параметры такие же ,как для функции 1
TRD - драйвер файловой системы TR-DOS принимает номер функции в рег. А и пока обрабатывает только функцию 4, это функция чтение части файла в буфер по адресу HL',длина части в блоках по 256 байт в рег.B, а в рег. HL адрес таблицы параметров вызова длиной 32+11. Первые 32 байта будут использоваться для хранения различных данных,необходимых для работы с этим файлом, рассмотрим их позже.Последние 11 байт это имя файла 8 байт+3 байта расширение. В дальнейшем длину имени и расширения можно будет увеличить.
Сделаю отступление насчет функций файловой системы.Мы сейчас не будем использовать OPEN,CLOSE, поскольку во-первых, у нас однозадачная,однопользова� �ельская система и нет необходимости в захвате файлов одной задачей,для прекращения доступа к этому файлу другими задачами. Во-вторых,у нас чтение и запись будут по блокам напрямую с/на диск, а не по байтам,и не будет системного буфера, в котором могут быть несохранённые данные, и которые надо сохранить, используя CLOSE.
И ещё,если бы мы их использовали, то вот те 32+11 байта должны были бы располагаться в памяти ядра(хотя это можно конечно и обойти), что неминуемо привело бы к ограничению на количество одновременно открытых файлов,в необходимости создания механизма для обработки этих операций - а это не есть очень просто.
Впрочем в будущем можно будет их использовать, а пока наш микроб обойдется без них
Теперь рассмотрим способы вызова функций ядра из задачи.
Будем использовать передачу параметров вызова в регистрах для тех функций,в которых параметры помещаються в регистры - сейчас это у нас функции 0 - "вывод строки символов на экран" и 1 - "получить символ с клавиатуры".
И второй способ для тех функций, параметры которой не помещаются в регистры, в котором будем оставшиеся параметры передавать в таблице,а в регистровой паре HL (или в другой) будет адрес этой таблицы. Этот способ используем для рассмотренной выше функции 2 - "чтение части файла".
Номер функции (пока что одной из этих 3-х) будем передавать в рег. A.
Ну и остается определиться,откуда задача узнает адрес точки входа в ядро, на который необходимо передавать управления при вызове функций.
Просто при запуске задачи будем передавать ей этот адрес в рег.HL и задача сохранит его в памяти и будет использовать.
Это даст нам возможность не привязывать точку входа в ядро, и даже в дальнейшем менять его перед запуском программы (например при большой её длине).
Для проверки этих функций будем использовать простейшую программу показа текста AUTOLOAD.MIC.Эту программу ядро загружает и запускает после печати приветствия.Запущенная программа (уже задача) печатает своё название и строку "загружаем текст" - вызывая функцию 0 (вывод строки символов).
Далее с помощью вызова функции 2 (чтение части файла) - задача загружает
текст в память задачи.В случае ошибки - выводит сообщение и ждет нажатие любой клавиши с помощью вызова функции 1 (получить символ с клавиатуры).
После успешной загрузки текста выводит его на экран постранично (функция 0).
(Уже заметна не высокая скорость заполнения экрана).
После каждой страницы ждёт нажатия любой клавиши и выводит следующую страницу.
По окончании текста возврат в ядро с помошью простой команды RET. (В дальнейшем мы добавим функций EXIT и задача будет завершаться,вызывая эту функцию).
И далее ядро перезапускает TR-DOS.
Поскольку книженции в стиле "криминального чтива" сразу не нашлось,на первое время закинул на дискету 1-ю главу книги У.Гибсона "Перегруженная Мона Лиза".
Пример с программой показа текста
Добавились файлы FS.H - это заменитель диспетчера вирт.файл.системы
и AUTOLOAD.H - исходник программы показа
А не хочешь в приложении сразу реализовать упрощенное "SAVE 16384,6912" , а потом заниматься уже драйверами? То есть:
LD HL, data;адрес данных
LD DE, lenght; длина
CALL save1;save1-TR-DOS, save2-RAMDISK, save3-MsDOS...
И "шапка" драйвера сама уже все разложит по полочкам, избавляя кодера от расчетов. Мне бы хотелось сделать именно так, разгрузив само приложение.
У меня чуть по-другому - Положим этот адрес в системные переменные самой задачи, сократив тем самым код приложения и драгоценные такты. Это оптимально, другого способа пока не вижу.
Это нормально, у тебя же не оживленная игра, а операционка. Что-то все равно будет теряться.
Spectrum Basic
Этот способ ограничивает свободу приложения в плане того , что обязательно должен быть заголовок определенной длины в определенном месте программы - например в начале файла заголовок 100 байт - в результате - этот заголовок нарушает все планы - если код упакован упаковщиком - драгоценной памяти в моем варианте тратиться на 3 байта больше:
LD (OS+1),hl
---------- Post added at 13:42 ---------- Previous post was at 13:34 ----------
В чем упрощение? Надо смотреть в будущее
трдос-дисков и мс-дос-дисков у нас может быть по 4 штуки, рам-дисков до 6 штук (на 4-х метровой Пентеве) - итого уже 14 адресов функций только для записи, потом мы захотим добавить 2 сдрома, 2 сд-карты, 2 винта по 8 разделов - и уже получаем 34 адреса только для save - save1...save34
А ведь нам ещё надо по столько же для функций load,create,delete,rename,cat - сам умножь 34*6 - и ужаснись
а если в новой версии ядра адреса изменяться?
Надо делать табличку из двух сотен JP XX - сколько она займет - около 610 байт
а если мы захотим при каждом вызове ядра выполнять одинаковое действие - например ставить свой указатель стэка - перед этим запоминать стэк задачи в ячейке памяти?
простым CALL NEW_STACK - уже не отделаешься!
Предлагаю ученику Vovoi - аргументировать своё предложение
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
