Просмотр полной версии : MATRIX
MATRIX - многозадачная система с моделью вытесняющей многозадачности.
Назначение системы:
возможность разработки ПО,независимого от используемого вида дисковых накопителей
(т.е. другими словами попытка создать такую среду разработки,чтобы "отвязать" вновь разрабатываемое ПО от дискет TR-DOS и от использования ПЗУ TR-DOS).
Описание системы(версия 1.01 от 29.08.2009).
В этой системе программа представляет собой исполняемый файл, состоящий в общем случае из трёх частей.
1-я часть - это заголовок, 2-я часть - основной код, 3-я часть - все остальное (дополнительный код,данные,графика,музыка,т ексты и пр). В частных случаях 3-я часть отсутствует и располагается в других файлах.
Ядро системы предоставляет минимум функций,разделенных на 5 групп (засорение ядра системы дополнительными функциями "на всякий случай, вдруг кому-нибудь понадобится" не имеет смысла и катагорически запрещено).
Группы функций:
1-работа с памятью
2-работа с распределением процессорного временеми
3-работа с файловой системой (использование дисковых устройств)
4-работа с графической подсистемой (вывод на экран)
5-работа с периферийными устройствами
Для вызова функций используется такой метод.Программа имеет так называемые почтовые ящики -
для входящих сообщений и для исходящих сообщений.
Чтобы вызвать функцию программа размещает номер функции в ящике для исходящих сообщений и там же указывается дополнительная информация: адрес памяти с таблицей параметров и тип вызова - с ожиданием или без ожидания.
В случае вызова с ожиданием, система приостанавливает работу программы до момента окончания выполнения функции.В случае вызова без ожидания,программа продолжает работать, при этом она САМА
периодически (когда захочет) проверяет почтовый ящик на предмет,а выполнена ли функция.
Почтовых ящиков 2 пары - одна пара для общения программы с ядром системы и ещё одна пара специально выделена для общения программы с графической подсистемой.
Во время работы программа периодически просматривает почтовый ящик для входящих сообщений
как от графической подсистемы,так и от ядра системы, и по своему(как ей захочется) реагирует,если есть сообщения.
Это метод позволяет не усложнять ядро процедурами создания очередей запросов,процедурами обработки и оптимизации очередей запросов, а также снизить расход памяти и ресурсы процессора на обработку вызовов от программ.
1. О памяти, которую использует программа.
1-я область памяти - это та память,куда будет загружен основной код.Это определяется самим
кодером и указывается в заголовке программы специальным битом mem, а именно 0-код в нижней памяти,1-код в странице памяти,начиная с адреса #C000. В первом случае длина кода не должна
быть слишком большой (например не более 8 кБ, а лучше не более 4-х), чтобы не заставлять
систему освобождать нижнюю память от других программ,так как в этом случае другие программы должны быть приостановлены.
После загрузки кода в память система настраивает код на адрес загрузки, при этом используется информация из заголовка программы.
Во втором случае (код в странице) - длина кода не превышает 16 кБ, но может быть и меньше.
Система загружает код в страницу без дополнительной настройки.
>
Основной код имеет свой заголовок, в котором
расположены почтовые ящики (4 шт по 8 байт), стэк,место для сохранения контекста программы при переключении (туда сохраняются регистры и номер последней включенной страницы )
>
2-я область памяти - это дополнительные куски в нижней памяти - о том будет ли программа их использовать, указано в заголовке отдельным битом lowmem (0- не будет, 1- будет)
3-я область памяти - это дополнительные страницы в верхней памяти -аналогично,- о том будет ли программа их использовать, указано в заголовке отдельным битом himem(0- не будет, 1- будет)
Для работы с памятью необходим следующий минимум функций(названия функций условны):
-Запросить область для использования в нижней памяти или странице:
getmem (in-кол-во блоков по 256 байт; out - адрес или сообщение об ошибке)
getpage (in-ничего; out - номер страницы или сообщение об ошибке)
-Освободить область в нижней области или странице
freemem (in-адрес; out - ок или сообщение об ошибке)
freepage (in - номер страницы,ранееполученный этой программой; out - ок или сообщение об ошибке).
-Отобразить в адресное пространство в адрес #C000 страницу с указанным номером
onpage (out - ок или ошибка)
В результате программа может использует все три области (или меньше).
2. О распределении процессорного времени.
exit - завершает программу.
sleep N - приостанавливает программу на N - периодов (длительностью по 1/50 сек).
wait - функция позволяет приостановить выполнение программы до прихода следующего прерывания.(оставшееся время до прерывания будет использовано системой по своему усмотрению).
waitmes - функция позволяет приостановить выполнение программы до прихода любого сообщения.
fork NN - запустить программу с именем по адресу NN (будет создан новый процесс),(out:- PID процесса запускаемой программы или ошибка)
kill PID - уничтожить процесс с номером PID,ранее созданный этой программой
onback - включить вызов фоновой задачи для этой программы
offback - выключить вызов фоновой задачи для этой программы
Количество времени,в течение которого программе будет предоставлено процессорное время для её работы частично определяется кодером, пожелание об этом указывается в заголовке исполняемого файла в виде приоритетов от 1 до 7, при этом 7 - самый высокий приоритет.
Оценить время работы программы в единицу времени можно приблизительно,так, если работает несколько программ, то при прочих равных условиях программе с приоритетом 7 процессорное время
будет предоставляться в 7 раз чаще, чем для программы с приоритетом 1.
Если в данное время выполняются программы с одинаковым приоритетом - то можно условно считать, что они получают примерно одинаковое количество единиц процессорного времени
По умолчания предлагаеться указывать приоритет 2.
3. Работа с файловой системой(использование дисковых устройств).
open NN,M - открыть файл с именем по адресу NN в памяти.(out: ID - открытого файла или код ошибки)
opendir NN,M - открыть каталог с именем по адресу NN в памяти.(out: ID - открытого каталога или код ошибки)
в этих функциях M-это флаг,значением битов которого определяется режим открытия файла (для чтения, для записи,или для создания нового файла или каталога)
chdir NN - установить текущим каталог с именем по адресу NN
close ID - закрыть файл или каталог (определяется системой по ID),(out: - ок или ошибка)
read ID,NN,MM - читать из файла с номером ID последующие MM байт в адрес памяти NN
bread ID,NN,MM - то же самое, но MM - это количество блоков по 2048 байт
write ID,NN,MM - записать в файл с номером ID последующие MM байт из адреса памяти NN
bwrite ID,NN,MM -то же самое, но MM - это количество блоков по 2048 байт
lseek ID,MMMM - передвинуть указатель внутри файла на позицию MMMM байт
blseek ID,MMMM - то же самое, но MMMM - это количество блоков по 2048 байт
readdir ID,NN,MM - читать последующие елементы каталога в буфер по адресу NN, длина буфера MM
rename ID,NN - переименовать файл или каталог с номером ID - новое имя по адресу NN (out: - ок или ошибка)
erase ID - удалить файл или пустой каталог с номером ID (out: - ок или ошибка)
getattr ID,NN - получить атрибуты файла или каталога с номером ID в буфер по адресу NN
setattr ID,NN - установить новые атрибуты файла или каталога с номером ID из буфера по адресу NN
Примечание: - как уже было сказано выше, никаких очередей запросов нет, поэтому если например 3 программы запросят чтение блока данных из 3-х файлов (каждая из своего) - то сначала будет прочитан блок для 1-й программы (при этом система до окончания этой операции не будет отвлекаться на просмотр почтовых ящиков других программ и не узнает о том, что другие программы запрашивают чтение блока данных), далее система обработает вызов второй программы и уже потом вызов третьей программы.
Соответсвенно рекомендуется читать/записывать байты или блоки данных небольшого размера.
4. Работа с графической подсистемой (вывод на экран)
Программа может создавать и использовать несколько окон для отображения в них текста или спрайтов.
Перед началом работы с графической подсистемой программа должна выполнить вызов определенной функции ядра системы,
в процессе выполнения которой ядро даст запрос графической подсистеме и она зарегистирирует эту программу в списке программ,сообщения от которых ею (графсистемой)обрабатывают ся.
Функции.
newin - создать новое окно (in: NN- адрес заголовка окна(в нём координаты, размеры, цвет)out: ID - нового окна)
viewin ID- показать на экране окно с номером ID
minwin ID - убрать с экрана окно с номером ID
killwin ID - уничтожить окно с номером
clswin ID - очистить окно с номером ID
txtwin ID - напечать текст в окне по текущим координатам
koorwin ID - координаты печати в окне
printwin ID - напечатать заголовок окна
sprwin ID - напечатать спрайт в окне по указанным координатам
attrdwin ID - изменить различные аттрибуты окна (размеры, координаты, цвет окна и заголовка)
Также есть возможность захватывать устройство типа основной экран и дополнительный экран в монопольное использование программой,в этом случае программа может напрямую работать с байтами на экранах
Функции:
getscr - занять основной экран
getscr2 - занять дополнительный экран
freescr - освободить
freescr2 - освободить
pagescr2 - Отобразить в адресное пространство в адрес #C000 страницу с экраном 2
pagescr - Отобразить в адресное пространство в адрес #C000 страницу с экраном 1
onscr,onscr2 - сделать видимым экран 1 или экран 2 (после вызова этой функции переключение экранов будет выполнено
после прихода прерывания).
Если с экраном работает какая-нибудь программа, то другой программе будет отказано в захвате экрана при вызове её функции getscr(getscr2)
Вышеуказанные функции являются сообщениями от программы для графической подсистемы, а сама графическая подсистема посылает программе сообщения в том случае если на окно произодиться воздействие устройством управления (клавиатурой и мышью,джойстиком) - в виде -координаты воздействия от левого верхнего угла окна в знакоместах, тип воздействия (левая, правая, средняя кнопка мыши или клавиша (в этом случае дополнительно передается код клавиши) и способ (нажата или отжата)).
Программа периодически просматривает почтовый ящик на предмет сообщений от графической подсистемы и САМА реагирует на них - т.е. сама определяет куда попало нажатие внутри окна - на какие пункты меню, кнопки или иконки и выполняет какое либо действие - например нажатие на правом верхнем углу окна может трактоваться программой как команда от пользователя - завершить работу программы (при условии, что программа вывела туда крестик),а нажатие на правый нижний угол окна программы она воспримет как команды к изменению размеров окна и т.д.
Такое упрощение процесса работы графсистемы необходимо, чтобы минимизировать затраты памяти и процессорного времени на обработку команд от устройств управления.
5. Работа с периферийными устройствами
Под периферийными устройствами понимается музыкальные устройства типа муз.процессора,TS,TSFM,GS а также принтер,модем.
Для них необходимы функции, аналогичные функциям работы с экраном, т.е. программа дает вызов на захват устройства (getay) и в случае согласия системы работает с ним, а по завершении работы освобождает устройство (freeay).
6.Заключение.
Данная система не позволяет выполнение программ,которым единолично требуются все ресурсы компьютера (например "тяжелым" играм с динамической графикой или программам для обслуживания дисков(форматирование, восстановление данных)),но она на
это и не претендует, так как для таких программ и игр необходима другая система (проект SHMATRIX - система с переключением задач),разработка программ под SHMATRIX почти аналогична разработке под систему TR-DOS, за исключением того, что в программу добавляются драйвера не только дисководов, но и драйвера других дисковых накопителей(hdd,cd/dvd/sd/ram) и сама программа оформляется в виде кодового блокас набором дополнительных файлов,который можно запускать с любых дисковых накопителей.
///////////////////////////////////////////
ОЧЕНЬ интересует мнение КОДЕРОВ с точки зрения удобства разработки программ для системы MATRIX.
Проект как проект.
Для полноценной многозадачности нужно 2 окна проецирования. Нижняя память имеет обыкновение кончаться, особенно если её выделять по N сегментов подряд (эффект решета).
Окна должны быть вложенными (про это писал Vitamin).
Если страницы памяти, с которыми работают приложения, физические, а не виртуальные, то невозможен своп.
Непонятно, как организованы очереди сообщений. Их составляет сама задача? Она это делает, находясь в своём стеке? или в стеке ядра?
Где вообще располагаются стеки задач?
Для полноценной многозадачности нужно 2 окна проецирования.
Согласен,но их нет в железе пользователей (хотя на бумаге схемка для подключения второго окна имеется)
Окна должны быть вложенными (про это писал Vitamin).
Вложенными в адресное пространство программы?
чето не припоминаю, в каком номере журнала
Если страницы памяти, с которыми работают приложения, физические, а не виртуальные, то невозможен своп.
Своп вообще НЕ НУЖЕН, иначе будет ТОРМОЗ , так как программа при переключении страниц не будет знать прошло 1000 тактов или 10 000 000 тактов, а она должна это знать!!!(из-за этого всё нереально тормозит сам знаешь где... )
Каждая программа может создать себе свой собственный файл подкачки любого размера (до 4-х Гигабайт) и сама будет туда скидывать те страницы, которые ей ДЕЙСТВИТЕЛЬНО не нужны(а не те которые системе мешают а программе нужны в 1-ю очередь).Система не знает и не может определить нужность/ненужность страниц для программы (а всякие там счетчики обращений к страницах и алгоритмы планирования, которые должны определять якобы ненужные программе страницы для выкидывания в своп - свою задачу не решают и только тормозят систему и программы, а также расходуют лишнюю память )
Непонятно, как организованы очереди сообщений. Их составляет сама задача? Она это делает, находясь в своём стеке? или в стеке ядра?
Где вообще располагаются стеки задач?
Про стэк добавил в первом сообщении(и ещё про несколько функций).
Стэк расположен в заголовке основного кода (там вроде около 220 байт не помню точно).
Очередей сообщений нет!
(По причине, чтобы не тратить на них память и не усложнять каждую функцию проверкой и выборкой их этих очередей)
Забыл? Я же тебе по телефону рассказывал!
Сама програма не делает новый вызов пока не будет выполнен старый - единственное, что программа может одновременно давать два вызова - один вызов для функций графической подсистемы и один вызов для функций ядра системы.
Согласен,но их нет в железе пользователей (хотя на бумаге схемка для подключения второго окна имеется)
Второе окно есть на АТМ, на одной из прошивок Pentagon 1024SL 2.x, на NGS.
Цитата:
Сообщение от alone
Окна должны быть вложенными (про это писал Vitamin).
Вложенными в адресное пространство программы?
чето не припоминаю, в каком номере журнала
Вложенными друг в друга геометрически. Где писал, не помню.
Про стэк добавил в первом сообщении(и ещё про несколько функций).
Стэк расположен в заголовке основного кода (там вроде около 220 байт не помню точно).
Программа со стеком в странице не может переключать страницы. Она не может даже вызывать функции ядра, которые лазят в другие страницы.
Очередей сообщений нет!
(По причине, чтобы не тратить на них память и не усложнять каждую функцию проверкой и выборкой их этих очередей)
Представь, что задаче пришло сообщение и по нему надо что-то сделать с ресурсом. А ресурс занят. Что она будет делать? Если она будет ждать освобождения ресурса, то пропустит следующие сообщения.
Error404
31.08.2009, 01:49
Можно посторонний взгляд?
1. По-моему, вы делаете Uzix, только хуже (к вопросу об очередях, планировщике задач и т.п.).
2. На имеющихся железках (ZX128 с одним окном диспетчера в 16к) можно сделать приемлимую по скорости многозадачность (не более сотни-двух сотен тактов на переключение контекста) только для прог размером не более 16к (а с учетом того что проге нужно еще и "кучу" для переменных - то и менее 16к).
3. Ни одно из подключаемых к ZX устройств не располагает скоростью достаточной для организации общесистемного SWAP-а (виртуальной памяти). Даже LDIR на кусках в десятки килобайт будет медленно. Разве что блиттер/DMA решают, но их нет. Т.е. надо расчитывать на то, что на несколько задач, памяти будет хотя бы несколько сот килобайт (с потолка, 1:100) - чтобы на смену контекста работать только диспетчером страниц ОЗУ (если он есть и удовлетворяет размером окна).
только для прог размером не более 16к (а с учетом того что проге нужно еще и "кучу" для переменных - то и менее 16к).
ну как бы не совсем. ничто не мешает проге занять 2 или 3 банка. стек для такой задачи пусть будет не в банке, а в нижней памяти. очень просто.
да простит меня автор темы - но ИМХО - система баян.
Error404
01.09.2009, 10:12
ну как бы не совсем. ничто не мешает проге занять 2 или 3 банка. стек для такой задачи пусть будет не в банке, а в нижней памяти. очень просто.
Но тогда только ассемблер. Либо делать собственный компилятор с поддержкой железа и непростой модели памяти приложений, что осилить еще сложнее, чем систему. А стек - да, в нижней памяти для обоих вариантов.
В варианте когда "только ассемблер" - это под систему будет рождено три с половиной программы, как к примеру в SymbOS (построенной фактически по этому же ТЗ):
http://zx.pk.ru/showthread.php?t=3196
Программа может создавать и использовать несколько окон для отображения в них текста или спрайтов.
Зачем так сложно? для генерации полноценного интерфейса надо загнать кучу вызовов для заголовка, текста, спрайтов, стандартных элементов управления, а потом каким-то образом еще обрабатывать данные манипулятора? Имхо, это не оптимально. Может упростить? Организовать вектор-описатель окна, где будут присутствовать объекты текста, графики и стандартные элементы управления с точками вызова определенных процедур, типа onrightclick/onleftclick/ondblclick. А так что придется для каждой проги писать свой интерфейс? Это не ведет к минимизации использования памяти и процессорного времени, наоборот в каждой программе будет свой обработчик сообщений от окна и не всегда оптимальный, что будет затормаживать реакцию на действие пользователя.
Данная система не позволяет выполнение программ,которым единолично требуются все ресурсы компьютера
это не есть гуд, надо реализовать возможность передачи всех рессурсов и возможность выгрузки оси или резидентного ее использования... а то надо диск отформатить - "перезагрузитесь плиз в другую ось...", надо игру запустить с винта - те же грабли. в таком случае ось имеет тупик в своем развитии. Т.к. даже адаптировать имеющийся софт для временного (пока не напишут софт, поддерживающий эту ось) использования, нет возможности. Даже ИС-ДОС каким-то чудом позволяла это делать и были адаптированные проги и игры единолично юзающие рессурсы компа.
Но тогда только ассемблер. Либо делать собственный компилятор с поддержкой железа и непростой модели памяти приложений, что осилить еще сложнее, чем систему.
да нет, вполне можно обычный си, просто при "готовке" должна быть определенная технология (по страницам разбиваешь сам, это не сложно).
в таком случае ось имеет тупик в своем развитии.
внимательно читаем:
(т.е. другими словами попытка создать такую среду разработки,чтобы "отвязать" вновь разрабатываемое ПО от дискет TR-DOS и от использования ПЗУ TR-DOS).
чтобы "отвязать" вновь разрабатываемое ПО от дискет TR-DOS и от использования ПЗУ
да, но в замен система ровно ничего не предоставляет. потому , что все функции по сути возоагаются на разраба. если кому то хочется писать всё самому, то собственно в чём олтличие от трдоса, в котором все и так всё пишут сами? многозадачность? так извините, если система запрещает использование полных ресурсов для одной только задачи (как уже писал Дмитрий напримере игр), то зачем она воолбще нужна? сидеть тыкать тупо на кнопочки в окошках да бегать по консоли взад вперёд? лучше всю жизнь в трдосе сидеть)))
psb, невозможность использовать все руссурсы ПК и работа с ТР-ДОС не связаны между собой... к примеру ты пишешь граф-редактор с мультиколором и тебе нужны рессурсы для отрисовки экрана - система тебе их не дает... уже такой софт мы не будем писать под матрикс... Примеров программ с приоритетным использованием рессурсов компа масса и необходимо учитывать это при создании ОС.
---------- Post added at 13:31 ---------- Previous post was at 13:25 ----------
а форматирование и многозадачность в принципе могут друг с другом ужиться, я еще в далеком 98м году для экспериментов писал менеджер прерываний (менеджер задач, как угодно), который позволяет работать параллельно 2м задачам (легко переделывалось и под большее количество, главное придумать где стеки хранить), каждой задаче отводилось по инту, ну или если задача не нуждалась в расчетах - могла пожертвовать свое время другой с помощью системного вызова. На тот момент задачи были не мудреные - форматирование диска и игра питончик. и все прекрасно уживалось :)
че вы прицепились к тр-дос? это, я думаю, одна из функций.
главное тут: среда разработки многозадачных приложений. всё.
естественно, для мелких автономных прог (в т.ч. мультиколора) это мало подходит (хотя, никто тебе не запретит сделать DI или перенастроить прерывания, главное с памятью корректно обойтись).
но зато сделать хороший текстовый редактор гораздо веселее. сделать плеер музыки (ay, gs). сделать инет-приложения. и это всё можно запускать одновременно в каких угодно сочетаниях. старый софт в принципе не возможно сделать многозадачным, поэтому не говорите ерунды. но можно его переделать так, что он будет запускаться практически с любого устройства.
---------- Post added at 16:41 ---------- Previous post was at 16:39 ----------
каждой задаче отводилось по инту,
и как же у тебя форматирование работало? оно жрет примерно 10 интов подряд, прерывать нельзя.
и как же у тебя форматирование работало? оно жрет примерно 10 интов подряд, прерывать нельзя.
а это уже другой сложный вопрос.
че вы прицепились к тр-дос?
мы к нему не цеплялись - это афтор, а позднее ты заострил внимание на вытеснении ТР-ДОС.
но можно его переделать так, что он будет запускаться практически с любого устройства.
но для этого надо реализовывать возможность переводить систему в резидентный режим, для других подзадач необходимо сделать чтоб задача могла отбирать и возвращать рессурсы при необходимости и не просто по DI/EI, а корректным способом - системными вызовами.
так, минуточку, псб. использовать прерывания собственно ручно в какой-то осе, несколько неверно. это задача самой ос. обработчики прерываний, дииспечер памяти и прочего, это всё задачи системы, а никак не кодера который пишет по. иначе. если мы начинаем писать собственные обрабочики прерываний, собственные драва памяти, собственные ...и т.д. то скажи, чем тогда эта ос отличается от программирования под трдос? что тогда эта система вообще предлагает? это получается, что одна програ написанная на пентагоне, будет идти только на пентагоне. а вот если быц система предоставляла ряд возможностей и если работать именно через функции системы, то твоя прога будет работать не только на пентагоне, смекаеш? а так в итоге, что 10 лет назад, что сейчас, что с приходом матрицы - кто в лес кто подрова... и при таком раскладе, не может быть речи ни про какую многозадачность! да и потом. она кому то тут нужна шибко? понты это всё на данной платформе. хочу заметить, что попытки реализовать многозадачность на спектруме были и ранее: домен ос пинк флойд, профивижн, ревос, реалтайм какая то ос, мифос..ещё была какая то, название забыл. и везде суть была одна и таже - глюки, тормоза, конфликты между по! матрица будет стоять рядом с ними. не надо делать упор на создание многозадачной системы - спектруму не подсилу такое при текущем развитие железа!
но для этого надо реализовывать возможность переводить систему в резидентный режим,
вот взять игру или дему, которой надо юзать все ресурсы. ну никто в здравом уме не будет переделывать такой софт, чтоб он мог работать в этой ос. загрузчик переделать и хватит. на то это и автономное приложение. выход в ос - через ресет (а дальше зависит от ос, может она до этого сделала hibernate).
не просто по DI/EI, а корректным способом - системными вызовами.
это, конечно, вопрос реализации. само собой вызовами - это хороший тон. НО произвольное старое приложение никогда не будет работать параллельно с чем-то под какой-либо ос на стандартном спеке. это просто невозможно. а новое заточить можно.
а это уже другой сложный вопрос.
ну расскажи, а то интересно:) это уже не просто многозадачность, это шаманство.
---------- Post added at 17:32 ---------- Previous post was at 17:24 ----------
п****ь, Sayman, ну че ты гонишь... че ты зацепился за прерывания? вы вообще читать умеете, нет? сделать предлагают среду разработки многозадачных приложений. до сих пор непонятно, что ли??? чем это отличается от автономок под тр-дос - читайте в 1 посте. тут и предлагается все через драйвера, единые точки входа, а не писать все самому. вы первые начали ныть, "а что если надо все ресурсы". вам предложили вариант, и больше ничего.
если конкретно вы не видите преимуществ написания хотя бы одной единственной программы под многопоточное ядро - проходите мимо, эта штука не для вас, пишите постаринке.
---------- Post added at 17:41 ---------- Previous post was at 17:32 ----------
и везде суть была одна и таже - глюки, тормоза, конфликты между по! матрица будет стоять рядом с ними. не надо делать упор на создание многозадачной системы - спектруму не подсилу такое при текущем развитие железа!
лол:)
все под силу, если здраво рассуждать и не пытаться сделать невозможное.
я вот тоже как и многие, делал многозадачное ядро, довольно неплохое. оно работает без глюков! а если тот, кто делает корявый софт, сделает как всегда, то это НЕ проблемы этого ядра. так?
psb во-первых, не стоит кипятица.
во-вторых, в первом посте что сказано? правильно
т.е. другими словами попытка создать такую среду разработки
речь идёт не про ось. а всего лиш про среду разработки.
далее по тексту четаем:
Ядро системы предоставляет минимум функций
если читать совсем внимательно, то увидиш, что
Данная система не позволяет выполнение программ,которым единолично требуются все ресурсы компьютера
т.е иными словами ЧТО ТЫ БУДЕШ там писать? текстовую гляделку? уж извини, таких прог гора, солить и мариновать уже можно! граф редакторы? тоже самое.и в итоге что? в системе ничего толкового нельзхя написать. вэб броузер? ау, где вы, браузеры?!?!? нету..ниодной штуки. и в ближайшие год, два, три и до бесконечности не придвидецо. аська? туда же. сетевого интерфейса на данный момент у спека нет (есть но не в россии). диалапом сам пользуйся!
едем далее по постам автора:
речь про почтовые ящики. а автор в курсе что через регистры нескорлько быстрее передавать инфу, в том числе на нужные адреса, в которых указаны нужныве таблицы, логи, сообщения и прочее? коды отработки функций так вообще вне конкуренции - тратить столько времени на формирование сообщение, да потом ещё и опрашивать "а не было ли чего там при выполнении функии" - кащунство. это на пц может сканать. а тут извините, не так много железок.
и так далее снова по текстам аффтара:
Своп вообще НЕ НУЖЕН, иначе будет ТОРМОЗ
нормлаьная ос с многозадачностью не может пренебрегать наличием свопа! это очень сильный козырь, даже у венды, у ленукса, у юникса и у многих других. даже извините у доса есть надстройка, позволяющая делать свап.
так о чём это я?! я уже привёл спико "многозадачных" поделок. не поленись, взгляни на них. а то сидиш на том конце провода и стучиш пяткой в грудь, мол это крута, это надо, это реально. а я тебе по опыту эксплуатации говорю - ацтой! причём именно по спектрумау, т.к. пробовал и мифос и пинкфлойда и профивижн. как минимум три оси из вышеперечисленного списка. но в отличиие от матрицы, профивижн обладает ещё и почти полноценным ООП и такие понятия как класс и объекты там были введены ещё в 93м году! и при этом на спектруме, точнее на профи! а матрица пока что кроме возможностей просматривать текст с одновременным проигрыванием музыки. нифига толком преждложить не способна.
да чё тут спорить.
---------- Post added at 18:57 ---------- Previous post was at 18:54 ----------
добавлю ещё пару строк:
по поводу портирования староо софта. это без проблем. на цпм под профи помница несколько старых спековых игрух было портировано, в том числе эксолон.
игрухи с мсх и других клонов. а собственно при наличии сорцов,..да хоть Чёрного Ворона!
---------- Post added at 18:58 ---------- Previous post was at 18:57 ----------
делал многозадачное ядро, довольно неплохое. оно работает без глюков!
пример реализации в студию! иначе это всё трёп.
Второе окно есть на АТМ, на одной из прошивок Pentagon 1024SL 2.x, на NGS.
Ещё на Профи есть, но включать туда вроде можно только одну фиксированную страницу (пусть владельцы Профи уточнят)
Ты предлагаешь делать проги так, чтобы прога могла пользоваться 2-м окном проецирования и включать туда страницы? - тогда они не будут работать на всех остальных Спектрумах,это не годится.
Или чтобы проги ничего про 2-е окно не знали, а сама система его использовала,когда прогам не хватает нижней памяти? Тогда можно в ядре это указывать и при отсутствии 2-го окна когда начинает не хватать нижней памяти, то куски нижней переносяться в верхнюю (это конечно долго, но процессы будут работать и не надо будет предыдущие усыплять)
Вложенными друг в друга геометрически.
Ну так там передаётся номер окна на которое воздействие (забыл об это указать , исправлю)
и соответственно, если у проги 3 окна - одно большое, а два других маленькие расположенные внутри большого,то по номеру определяется на какое окно произошло воздействие.
Ты это имел ввиду?
Программа со стеком в странице не может переключать страницы. Она не может даже вызывать функции ядра, которые лазят в другие страницы.
Не вижу проблемы!
В программе нет конструкций типа call куда-то в ядро , поэтому спокойно ядро включает страницу,когда прога кладет номер страницы в специальную ячейку памяти(за исключением функции wait (прога должна сделать call adr1),но её надо ещё продумать и ещё хотел все-таки прямое переключение страниц через call adr2добавить, чтобы не ждать прерывания(после которого произойдет переключение страницы), но тоже нужно придумать, как передавать adr1,2 от ядру проге(например при запуске в виде сообщения) )
так что поясни
---------- Post added at 16:44 ---------- Previous post was at 16:28 ----------
Представь, что задаче пришло сообщение и по нему надо что-то сделать с ресурсом. А ресурс занят. Что она будет делать? Если она будет ждать освобождения ресурса, то пропустит следующие сообщения.
Ну, значит. если для программы критичен пропуск сообщения, тогда она пусть сама создаёт очередь входящих сообщений
Приведи конкретный пример, вот я могу придумать,например прога проигрывания музыки на GS, прога ждёт готовности GS - а он не отвечает, а юзер тыкает кнопку отмена, а прога должна проверять сообщения между опросом GS
речь идёт не про ось. а всего лиш про среду разработки.
лол:) это ты мне говоришь? это я тебе уже несколько постов об этом твержу:)
и в итоге что? в системе ничего толкового нельзхя написать.
ну так и не пиши, если не знаешь что писать. делов-то... уже сказал, проходи мимо. только странно, что у меня такая же идея была. наверное мы дураки, а ты умный:)
сетевого интерфейса на данный момент у спека нет (есть но не в россии). диалапом сам пользуйся!
строго говоря, не важно, какой интерфейс. при диалапе добавится тока модуль РРР, и добавить его в многозадачной среде гораздо проще.
речь про почтовые ящики. а автор в курсе что через регистры нескорлько быстрее передавать инфу
а вот ты в курсе, что это абстракция? и что есть разные подходы к построению ос? (а это ос, хоть и в пределах одной проги). каким, извините, раком ты через регистры будет передавать информацию в другой поток???
а я тебе по опыту эксплуатации говорю - ацтой!
по опыту эксплуатации систем-недоделок? ты обоснуй, с чего невозможно сделать нормально? я не знаю таких причин.
по поводу портирования староо софта. это без проблем. на цпм под профи помница несколько старых спековых игрух было портировано, в том числе эксолон.
да ё-моё, кто спорит-то, все можно сделать, особенно, если памяти много. если нет выхода из игры - сделать. но это большая работа - переделывать все игры, поэтому этого не будет. а если это всего 128к, то извините...
пример реализации в студию! иначе это всё трёп.
этто чо? ты меня на слабо что ли берешь? или ты сомневаешься, что это возможно? или сомневаешься, что я это написал? или что я могу такое написать? я не понял...
там к ядру недописаны разные модули (работа с памятью и т.п., хотя мутексы работали). ты предлагаешь выложить недоделанный проект? зачем? чтоб ты убедился, что я не вру? да нафиг надо. ну либо на спор давай, на новый ZX-Evo:):):) тогда выложу, убедишься:)
Можно посторонний взгляд?
Канэшна!
. По-моему, вы делаете Uzix, только хуже (к вопросу об очередях, планировщике задач и т.п.).
Не угадали, больше ориентируюсь на книжки Э.Таненбаума и М.Баха, хотя UZIX и его предшественника UZI изучал маленько 2-3 года назад, а про то, что хуже - могу предложить создать отдельную тему с названием типа "Использование UZIX/UZI на Спектруме" и там обсудим (и про ограничение разделов в 32 Мегабайта со своей файловой системой ufs при том что вот у спектрумистов винты на 40/80/160 Гб c FAT32 подключены и про не "реактивную" скорость работы UZI(X)- так как на Си они написаны и т.д.)
2. На имеющихся железках (ZX128 с одним окном диспетчера в 16к) можно сделать приемлимую по скорости многозадачность (не более сотни-двух сотен тактов на переключение контекста) только для прог размером не более 16к (а с учетом того что проге нужно еще и "кучу" для переменных - то и менее 16к).
Ну почему же, вот можно например для Спектрум-128 иметь две полноценных программы по 40 Кб каждая (при это одна прога занимает 8Кб в нижней памяти и две страницы по 16 Кб), Полноценные я имею ввиду в том смысле, что вот игрушки под Спектрум-48 занимали столько же (ну максимум 41.25 Кб, если не использовали сисперем бэйсика), и при переключении LDIR'ами ничего не переноситься - только страницы переключаються,
или например 2 программы по 26 Кб и одну 42 Кб(опять для Спектрум-128) - каждая будет занимать по 10 Кб в нижней памяти и по одной странице 16 Кб, а третья из них две страницы по 16 Кб, ну а на 256,512,1024 можно больше таких штук запускать (так как у них есть возможность подключения страницы0 в адрес 0, а у других кэш на 32 Кб)
---------- Post added at 17:41 ---------- Previous post was at 17:11 ----------
ну как бы не совсем. ничто не мешает проге занять 2 или 3 банка. стек для такой задачи пусть будет не в банке, а в нижней памяти. очень просто.
Ну именно так, вот в примере вышеупомянутых прог кусок в нижней памяти в 8-10Кб - это основной код и в нём располагается стэк
да простит меня автор темы - но ИМХО - система баян
На первый раз прощаю(ща истчо вникну,что Вы там дальше наговорили), а то что Вы не будете делать проги для этой системы, это и так понятно, так как каждый разработчик считает свою систему лучшей, и поскольку Вы разрабатываете собственный клон CP/M (на базе Q-DOS/Профи-Дос) - то и проги будете делать только для неё
---------- Post added at 17:57 ---------- Previous post was at 17:41 ----------
Но тогда только ассемблер. Либо делать собственный компилятор с поддержкой железа и непростой модели памяти приложений, что осилить еще сложнее, чем систему. А стек - да, в нижней памяти для обоих вариантов.
В варианте когда "только ассемблер" - это под систему будет рождено три с половиной программы, как к примеру в SymbOS (построенной фактически по этому же ТЗ):
Теперь сравниваете MATRIX с SymbOS, а вначале сравнивали с UZIX - Вы уж определитесь, что такое MATRIX :)
да нет, вполне можно обычный си, просто при "готовке" должна быть определенная технология (по страницам разбиваешь сам, это не сложно).
Полностью согласен, просто сделать в разных страницах разные процедуры и включать ту или иную страницу перед их вызовом из основного кода, расположенного в нижней памяти (вместо того,чтобы ,как в старых прогах загружать очередной оверлей с диска)
---------- Post added at 18:13 ---------- Previous post was at 17:57 ----------
Зачем так сложно? для генерации полноценного интерфейса надо загнать кучу вызовов для заголовка, текста, спрайтов, стандартных элементов управления, а потом каким-то образом еще обрабатывать данные манипулятора? Имхо, это не оптимально. Может упростить? Организовать вектор-описатель окна, где будут присутствовать объекты текста, графики и стандартные элементы управления с точками вызова определенных процедур, типа onrightclick/onleftclick/ondblclick.
Так как Вы предлагаете, уже было (например, в минивиндовс98 из Черной Вороны 2, в ChaOS), как раз наоборот , упрощаем систему,чтобы шустрее работала
А печать заголовка нужна , чтобы можно было обновлять заголовок, например показывать там сколько процентов выполнено (при какой-либо операции), а вариант с описателем не позволяет динамически изменять заголовок
Это не ведет к минимизации использования памяти и процессорного времени, наоборот в каждой программе будет свой обработчик сообщений от окна и не всегда оптимальный, что будет затормаживать реакцию на действие пользователя.
Это ведёт к минимизации использования памяти системой (и как следствие, больше памяти доступно программам) и ещё это ведёт к минимизации затрат процессорного времени графической подсистемой, так как при нажатии на кнопки она всего лишь проверяет координаты окон и определяет какой программе принадлежит окно и передаёт её сообщение, а в предлагаемом Вами варианте граф.система должна постоянно "перелопачивать" описатели всех окон и всех стандарных элементов управления в каждом окне, что и будет затормаживать реакцию программы на действия пользователя (и тормозить работу программ в целом, так как окон может быть много у каждой программы, даже если фактически запущено, например 3 программы)
Error404
01.09.2009, 20:23
Канэшна!
Не угадали, больше ориентируюсь на книжки Э.Таненбаума и М.Баха, хотя UZIX и его предшественника UZI изучал маленько 2-3 года назад,
Теперь сравниваете MATRIX с SymbOS, а вначале сравнивали с UZIX - Вы уж определитесь, что такое MATRIX :)
Нет, уж это Вы определяйтесь, коллега, что такое Матрикс. Пока что видно только нечто размытое, конкретизированное только в части интерфейса с прикладняком (и написанное с позиции прикладного программиста). Какие там функции будут в Матриксе для графики или файловой системы - дело десятое, тем более похоже совместимостью по вызовам с *nix-ами, CPM или VNC тут и не пахнет.
Главное, совершенно не понятно - "за чей счет банкет", т.е. за счет чего вообще что-то будет работать (как будет работать ядро), как все будет увязано в общую систему, а не набор программ, которые работают как хотят (хотят - пишут/читают в/из "ящик", хотят - нет, хотят - сами инициируют переключение диспетчера для работы с другими страницами памяти)
а про то, что хуже - могу предложить создать отдельную тему с названием типа "Использование UZIX/UZI на Спектруме" и там обсудим (и про ограничение разделов в 32 Мегабайта со своей файловой системой ufs при том что вот у спектрумистов винты на 40/80/160 Гб c FAT32 подключены и про не "реактивную" скорость работы UZI(X)- так как на Си они написаны и т.д.)
Да было уже. Года три наза в этом же разделе перетирали, и в теме про SymbOS тоже. И опять повторение распространенной ошибки (я бы даже сказал, ярлыка) - "все тормоза из-за C". Ничуть не бывало, 50% разницы - это не разница, не та цена за кросплатформенную совместимость на уровне исходников, чтобы так просто от нее отказаться ради ассемблерной самодеятельности. Все тормоза из-за больших накладных расходов, алгоритмических, которые как раз в ядре. Я и SymbOS привел в пример исключительно как образец колоссального квалифицированного труда автора, и в целом симпатичную систему, но программ в которой будет ровно столько, сколько успеет написать сам автор. Т.е. катастрофически мало, "поставил-посмотрел-снёс".
32М ограничение на размер FS в юзиксе оттого, что это 16-битная FS - у разработчика UZI в мхомпоросших 80-х годах прошлого века компилятор не умел 32 бит int, а при переводе на Hitech C (т.е. в UZIX) ничего кардинально не переписывалось. Но можно монтировать несколько FS, а еще лучше - переписать в 32 бита. Зато это СИСТЕМА. Мне вот не нужена еще одна прога-запускалка игр, таких уже имеется в наличии - запускают и с винта в сотню гигов (насчет 160 - этого конечно нет, а у вас что, и LBA48 в планах?), и с CD-привода.
Нет, уж это Вы определяйтесь, коллега, что такое Матрикс.
Это шутка, я ж там смайлик поставил
Пока что видно только нечто размытое, конкретизированное только в части интерфейса с прикладняком (и написанное с позиции прикладного программиста). Какие там функции будут в Матриксе для графики или файловой системы - дело десятое, тем более похоже совместимостью по вызовам с *nix-ами, CPM или VNC тут и не пахнет.
Вообще-то я специально не стал сразу рассказывать про внутреннеё устройство собственно самого ядра системы, чтобы кодеры, которые захотят делать проги для этой системы, увидели перед собой некую "виртуальную машину", у которой можно в ответ на вызов функции получить определённый результат, так как я уже вижу, что при обнародовании всей внутренней "кухни", сразу появятся желающие её покритиковать/дать полезные советы, как сделать лучше :)
а также кодеры сразу начнут придумывать недокументированные способы использования особенностей реализации ядра и просьбы,добавить ещё одну мааленькую такую фичу, чтобы было удобнее разрабатывать их собственные проекты (так называемыое явление "фичедемон")
а про совместимость с *nix, и др. - это дело поправимое,хотя делать POSIX-совместимое ядро очень скучно (не говорю, что невозможно)
Главное, совершенно не понятно - "за чей счет банкет", т.е. за счет чего вообще что-то будет работать (как будет работать ядро), как все будет увязано в общую систему, а не набор программ, которые работают как хотят (хотят - пишут/читают в/из "ящик", хотят - нет, хотят - сами инициируют переключение диспетчера для работы с другими страницами памяти)
Ну что тут не понятного -ладно, нарушаю правило не рассказывать про внутреннюю "кухню":
только Вы никому не рассказывайте :)
правит балом один из процессов, запускаемый самым первым, типа, процесс INIT :) , вот он и является ядром системы,он организовывает таблицу процессов, в нём переключалка и планировщик процессов,
он загружает процесс с названием ... нет не LOGIN, а с названием XWIND - это типа графическая подсистема (со встроенным драйвером мыши,джойстика и клавиатуры), а потом уже он загружает ... опять не LOGIN, а сразу процесс DESKTOP и регистрирует его в граф.систему(с помощью сообщения в своем почтовом ящике,которое берет XWIND),а DESKTOP кладет в свои почтовые ящики сообщения для граф.системы - создать, показать окна и для ядра системы - загрузить там- чё-нить, типа следующий процесс, который уже является программой пользователя, и а дальше весь свистопляс...
а про страницы памяти, вообще-то официальный способ, положить номер страницы в ячейку, и потом ядро включит это страницу, а насчёт самостоятельного (для скорости) прямого переключения страниц - пока ещё не определено, будет/нужно ли.
ну вот так ,типа того, но как-то невнятно получилось рассказать,
токмо смотрите - никому...... :)
Но можно монтировать несколько FS, а еще лучше - переписать в 32 бита. Зато это СИСТЕМА. Мне вот не нужена еще одна прога-запускалка игр, таких уже имеется в наличии - запускают и с винта в сотню гигов (насчет 160 - этого конечно нет, а у вас что, и LBA48 в планах?), и с CD-привода.
Ну монтировать несколько разных файловых систем не только UZIX умеет :)
P.S.Винты у меня на 40Гб и на 160 Гб, но конечно же используется LBA28 - только первые 128 Гб,а LBA48 -пока не планируется
Так как Вы предлагаете, уже было (например, в минивиндовс98 из Черной Вороны 2, в ChaOS)
возможно и было. это удобно, поэтому не мудрено, что было. Да, такой подход не позволяет в онлайн выводить инфу в окно, но кто мешает объявить процедуры прорисовки в системных вызовах? если тебе удобно рисовать окно и содержимое динамически посредством API - рисуй, мне больше нравится статический вывод, если что-то надо будет - обращусь по API и поменяю заголовок. Просто статический описатель окна будет компактнее, чем код, вызывающий те же апи-функции для генерации аналогичного окна. А с учетом малого количества непрерывной памяти расточительно ее использовать не хорошо. Кстати идея - принять манеру pc-шных моделей с сегментами кода и данных и размещать код программы в непрерывной памяти, а тексты, графику и прочее - в страницы :)
а в предлагаемом Вами варианте граф.система должна постоянно "перелопачивать" описатели всех окон и всех стандарных элементов управления в каждом окне, что и будет затормаживать реакцию программы на действия пользователя (и тормозить работу программ в целом, так как окон может быть много у каждой программы, даже если фактически запущено, например 3 программы)
В том то и дело, что в каждой программе (читай в каждом окне) придется делать обработку сообщений от манипулятора - это увеличит код (бесполезный) программы, а если сделать это средствами граф подсистемы - будет один кодовый блок. Ведь все равно все программы будут "перелопачивать" свои окна. Причем если каждый программист сделает эту обработку по своему и некорректно - то это утянет на дно всю систему.
И что сложного в обработке описателей всех окон? выяснить каким окнам принадлежит указанная координата и какое из этих окон находится на вершине.
---------- Post added at 20:51 ---------- Previous post was at 20:35 ----------
а про страницы памяти, вообще-то официальный способ, положить номер страницы в ячейку, и потом ядро включит это страницу, а насчёт самостоятельного (для скорости) прямого переключения страниц - пока ещё не определено, будет/нужно ли.
Я понял, что для того чтобы включить страницу - нужно в почтовый ящик положить номер нужной страницы и "подождать"? подождать чего? пока менеджер задач не отберет у программы время работы? а если программа будет часто щелкать страничками? Скоростной режим не нужен, а просто необходим! Нужен системный вызов (API-функция называй как хочешь) для переключения страниц, а то получится, что программа будет состоять лишь из извечных циклов ожидания - запросил вывести рамку окна - ждем, запросил вывести текст - ждем, запросил открыть страничку - ждем... в виду тормознутости самого спека - метод "ожидания" имхо не выход из положения. для многозадачной оси надо провести черту между двумя разными типами системных вызовов, которые работают через очереди сообщений - почтовые ящики (действия, которые требуют освобождения рессурсов, типа чтение данных с устройства), и вызовы, которые работают напрямую (типа рисование окон, текста, переключение страниц и пр...).
Error404
01.09.2009, 22:10
Это шутка, я ж там смайлик поставил
:)
Вообще-то я специально не стал сразу рассказывать про внутреннеё устройство собственно самого ядра системы, чтобы кодеры, которые захотят делать проги для этой системы, увидели перед собой некую "виртуальную машину", у которой можно в ответ на вызов функции получить определённый результат, так как я уже вижу, что при обнародовании всей внутренней "кухни", сразу появятся желающие её покритиковать/дать полезные советы, как сделать лучше :)
а также кодеры сразу начнут придумывать недокументированные способы использования особенностей реализации ядра и просьбы,добавить ещё одну мааленькую такую фичу, чтобы было удобнее разрабатывать их собственные проекты (так называемыое явление "фичедемон")
а про совместимость с *nix, и др. - это дело поправимое,хотя делать POSIX-совместимое ядро очень скучно (не говорю, что невозможно)
и сложно, все-таки. Но какой-то уровень совместимости, хотя бы с ранними типа "Систем 5" или подобными был бы крайне полезен.
Опять же, "С" не догма, никто не мешает писать на ASM (если на примере того же UZIX, в диспетчере, через который ходят все либы при обращении к ядру, всё одно сначала приводится к размещению параметров в регистрах)
Ну что тут не понятного -ладно, нарушаю правило не рассказывать про внутреннюю "кухню":
только Вы никому не рассказывайте :)
правит балом один из процессов, запускаемый самым первым, типа, процесс INIT :) , вот он и является ядром системы,он организовывает таблицу процессов, в нём переключалка и планировщик процессов,
он загружает процесс с названием ... нет не LOGIN, а с названием XWIND - это типа графическая подсистема (со встроенным драйвером мыши,джойстика и клавиатуры), а потом уже он загружает ... опять не LOGIN, а сразу процесс DESKTOP и регистрирует его в граф.систему(с помощью сообщения в своем почтовом ящике,которое берет XWIND),а DESKTOP кладет в свои почтовые ящики сообщения для граф.системы - создать, показать окна и для ядра системы - загрузить там- чё-нить, типа следующий процесс, который уже является программой пользователя, и а дальше весь свистопляс...
а про страницы памяти, вообще-то официальный способ, положить номер страницы в ячейку, и потом ядро включит это страницу, а насчёт самостоятельного (для скорости) прямого переключения страниц - пока ещё не определено, будет/нужно ли.
ну вот так ,типа того, но как-то невнятно получилось рассказать,
токмо смотрите - никому...... :)
Не, ну это понятно. Просто дьявол в деталях. Вот, к примеру, в заглавном посте упоминался FORK (т.е. в понятиях UNIX - дублирование процесса со всем окружением и переменными - как системными, так и стеком и "кучей" процесса и продолжение выполнения с точки fork), а здесь судя по логике, уже EXEC, а не fork. Кстати, как будет с окружением процессов (системными переменным), что наследуется, а что нет, где хранится, как передается.
В-общем, проработка деталей займет много времени.
Ну монтировать несколько разных файловых систем не только UZIX умеет :)
P.S.Винты у меня на 40Гб и на 160 Гб, но конечно же используется LBA28 - только первые 128 Гб,а LBA48 -пока не планируется
Думаю, нужно как-то заложить (на уровне условной компиляции или еще как) генерацию системы в две версии - одну из них под продвинутое железо. Т.к. никуда не деться - нужно будет работать с диспетчером окном большего размера, только тогда получится достаточное быстродействие при "приемлимо большой" сплошной памяти процесса. Ну и\или закладываться на существующие дополнительные фичи управления памятью какого-то из клонов, например ATM или еще чего из продвинутых. В конце концов даже на стандартный ZX припаять бутербродом две микрухи и кинуть пяток проводов МГТФ эту куда как более реально и доступно в современных реалиях, чем написать систему, пытаясь впихнуть ее в невпихуемое.
Также независимо от того что получится за система, желательно оставить возможность выполняться пользовательскому коду с адреса 0 и выше - это в перспективе даст возможность запускать без переделки как бинарники CPM, так и UZIX. Все же таких системных программ, какие есть в CPM, на 8-битной платформе уже не будет никогда.
James DiGreze
02.09.2009, 08:15
Зря вы сразу на окна накинулись. Ни к чему это. По крайней мере пока. Делайте так, чтобы окно программы(не процесса) всегда было на весь экран, если конечно программе требуется отрисовка диалога, в противном случае stdin/stdout.
Такой подход более прагматичен т.к. у нас не 1600х900, а всего лишь 256х192. И заметьте, в большинстве случаев программы на ПЦ под "окошки" всегда раскрыты на полный экран. Я считаю что полноценными окнами можно пренебречь.
предлагаю. аффтару выпустить для обозрения какой то релиз (бета или фул) и там пасмотрим кто есть ху)))
Делайте так, чтобы окно программы(не процесса) всегда было на весь экран, если конечно программе требуется отрисовка диалога, в противном случае stdin/stdout.
как вариант экономии памяти и процессорного времени - да, согласен.
Данная система не позволяет выполнение программ,которым единолично требуются все ресурсы компьютера (например "тяжелым" играм с динамической графикой или программам для обслуживания дисков(форматирование, восстановление данных))
это не есть гуд, надо реализовать возможность передачи всех рессурсов и возможность выгрузки оси или резидентного ее использования... а то надо диск отформатить - "перезагрузитесь плиз в другую ось...", надо игру запустить с винта - те же грабли. в таком случае ось имеет тупик в своем развитии. Т.к. даже адаптировать имеющийся софт для временного (пока не напишут софт, поддерживающий эту ось) использования, нет возможности. Даже ИС-ДОС каким-то чудом позволяла это делать и были адаптированные проги и игры единолично юзающие рессурсы компа.
Там же сказано - ВЫПОЛНЕНИЕ программ в многозадачной системе, а Вы говорите про возможность ЗАПУСКА таких программ
Запускать конечно же можно
загрузчик переделать и хватит. на то это и автономное приложение. выход в ос - через ресет (а дальше зависит от ос, может она до этого сделала hibernate).
Ну да, система уходит в киберночь и оставляет в памяти маленькую программку-запускалку,которая уже и запускает такое автономное приложение
А вот что имелось ввиду про ВЫПОЛНЕНИЕ таких ресурсоемких программ:
вот предположим у нас минимальная конфигурация Спектрум -128 , а такай программа хочет использовать ВСЕ ресурсы компьютера, ну и как, спрашивается система сможет ресурсы программе предоставить? Что касается процессорного времени, тут всё проще, система усыпляет все уже запущенные процессы и сохраняет их во внешней памяти,программа сама будет выводить на экран - она вызывает функцию getscr1,2 и в результате графическая подсистема не нужна, она туже усыпляется и убирается из памяти,итого работают только два процесса - т.е. эта программа и ядро системы,теперь программа допустим вызывает функцию getcpu и система отключает переключение процессов по приходу прерывания и программа сама рулит, и её ничто не прерывает и так до момента пока программе понадобиться выполнить операции с файлами, тогда она вызывает ядро, оно выполняет дисковую операцию и возвращает управление программе.
Всё бы хорошо, но вот программе надо использовать все 128 Кб памяти, а часть памяти (ну как минимум 16 Кб) занимает ядро системы, вот и получается, что не может система обеспечить ВЫПОЛНЕНИЕ таких программ.
P.S. конечно эта задача легко решается при наличии бОльшего количества памяти, чем 128 Кб.
Ну могу изменить эту фразу, добавить там слова "В минимальной конфигурации (Спектрум-128) система не позволяет выполнение программ,которым единолично требуются все ресурсы компьютера"
---------- Post added at 10:18 ---------- Previous post was at 10:02 ----------
да, но в замен система ровно ничего не предоставляет. потому , что все функции по сути возоагаются на разраба
Ну как же ничего не предоставляет, вон в первом посте указаны три десятка функций - берите, пользуйтесь на здоровье
так извините, если система запрещает использование полных ресурсов для одной только задачи (как уже писал Дмитрий напримере игр)
Про это рассказал подробно
лучше всю жизнь в трдосе сидеть)))
Ну,у нас свободная страна, Конституция гарантирует всем гражданам свободу выбора - так что решать Вам
Примеров программ с приоритетным использованием рессурсов компа масса и необходимо учитывать это при создании ОС.
Ну вот же мы их и учитываем, и функции заготавливаем типа getscr и подобные
че вы прицепились к тр-дос? это, я думаю, одна из функций.
ну да,хочешь - обращаешься из своей программы к дискетам,а хочешь - к винчестеру и dvd
мы к нему не цеплялись - это афтор, а позднее ты заострил внимание на вытеснении ТР-ДОС.
Ну не надо придумывать - никто и не говорит о вытеснении.
Предлагается "отвязаться" от дискет ТР-ДОС, чтобы они перестали быть единственными носителями информации, а стали просто одними из многих (fdd,hdd,cd,dvd,SD,CF IDE), причем на равных правах - т.е. чтобы вновь разрабатываемые программы могли использовать их все одновременно или в любых сочетаниях и запускаться с них, с любых носителей (а не так, что принес новую прогу на cd-rom-диске,а запустить её не можешь - так как сначала надо прогу скопировать на дискету)
---------- Post added at 10:33 ---------- Previous post was at 10:18 ----------
не надо делать упор на создание многозадачной системы
Ну я уже сказал, у нас свободная страна: каждый делает, что хочет :)
спектруму не подсилу такое при текущем развитие железа!
Ага, щас - вот помню в 2000-году купил винт на 210 Мб и собрался подключать к Спеку, - рассказал знакомому писишнику (в принципе,не надо было этого делать) - он сделал умное лицо и начал "обьяснять", что Спектрум не потянет и т.д. А позже предлагал подешевке свой винт на 540 метров (я не взял) - и что мы в результате имеем? Спокойно юзаем на Спеке винты на 40, 80 и 160 Гб и радуемся (и не вспоминаем, что кто-то говорил, что Спек "не потянет")
James DiGreze
03.09.2009, 12:42
про запуск в минимальной конфигурации монопольных программ: решается через своп. т.е. перед запуском система свой образ скидывает во внешнюю память, потом тупо запускает прог. в качестве свопа может быть заюзан даже флопоглот, с этим согласен даже великий и могучий, страшный волшебник, который изрек "640Кб хватит всем". ;)
ну и тем более, если есть больше памяти и рам-диск.
Своп вообще НЕ НУЖЕН, иначе будет ТОРМОЗ
нормлаьная ос с многозадачностью не может пренебрегать наличием свопа! это очень сильный козырь, даже у венды, у ленукса, у юникса и у многих других. даже извините у доса есть надстройка, позволяющая делать свап.
Ай, молодца.! Sayman не разобравшись,выхватил строчку из контекста сообщения и перевёл в недостаток.
Так вот обьясняю - о чем там шла речь, Alone говорил, что если программе по запросу предоставляется физические номера страниц, то не возможно организовать виртуальную память, то есть давать программе левые номера страниц (вместо настоящих), и потом, когда программа вызывает функцию включить страницу, то система смотрит - ага , нет сободных страниц, выбирает "жертву", у которой можно страницу забрать, сохраняет странцу в своп-файл, и отдаёт эту страницу проге,сделавшей запрос, а дальше мы имеем ТОРМОЗ,а именно, та другая прога , у которой была забрана страница, грит,типа, а ну подайте мене мою страницу , ща печатать картинки буду (или следующий кусок архива распаковывать), и начинается, система сохраняет страницу 2-й проги в своп-файл,загружает оттуда страницу для первой проги,первая прога начинает обрабатывать данные, а потом переключаются процессы и переключалка должна включить страницу второй проги,и опять всё по новой - сохранили загрузили - переключили
Вот про энто безобразие я и говорил, что его НЕТ, и НЕ БУДЕТ!!!
Специально повторяю, читайте внимательно!
Своп вообще НЕ НУЖЕН, иначе будет ТОРМОЗ , так как программа при переключении страниц не будет знать прошло 1000 тактов или 10 000 000 тактов, а она должна это знать!!!(из-за этого всё нереально тормозит сам знаешь где... )
Каждая программа может создать себе свой собственный файл подкачки любого размера (до 4-х Гигабайт) и сама будет туда скидывать те страницы, которые ей ДЕЙСТВИТЕЛЬНО не нужны(а не те которые системе мешают а программе нужны в 1-ю очередь).Система не знает и не может определить нужность/ненужность страниц для программы (а всякие там счетчики обращений к страницах и алгоритмы планирования, которые должны определять якобы ненужные программе страницы для выкидывания в своп - свою задачу не решают и только тормозят систему и программы, а также расходуют лишнюю память )
Прога будет создавать свой файл, если система по запросу на выделение страниц скажет, мол, нет свободных страниц.
Ну а сама система будет использовать своп для того чтобы сохранять туда спящие процессы (кусками или полностью ) и тем самым она будет освобождать память для вновь запущенных прог
---------- Post added at 11:25 ---------- Previous post was at 10:55 ----------
Да, такой подход не позволяет в онлайн выводить инфу в окно, но кто мешает объявить процедуры прорисовки в системных вызовах? если тебе удобно рисовать окно и содержимое динамически посредством API - рисуй, мне больше нравится статический вывод, если что-то надо будет - обращусь по API и поменяю заголовок.
Ну я бы назвал это так:
Вы говорите про меню - прямоугольник или квадрат со строчками текста, заголовком и возможно с маленькой картинкой(пиктограммой), а я говорю про окно (тот же прямоугольник) - в которое постоянно выводиться информация - даже если это просто листалка, посточно листаем текст и он в окне должен снизу вверх перемещаться - и как это в Вашем варианте осуществить? для вывода окна с тестком смещенным на одну строку вверх формировать новый описатель окна? - я пробовал в делать нечто подобное в минивиндовс98 - впечатление, что текст на бэйсике выводиться (в смысле очень медленно)
Просто статический описатель окна будет компактнее, чем код, вызывающий те же апи-функции для генерации аналогичного окна. А с учетом малого количества непрерывной памяти расточительно ее использовать не хорошо.
Ну, этот код спокойно располагается в страницах, а непрерывная память на него не раходуется
Кстати идея - принять манеру pc-шных моделей с сегментами кода и данных и размещать код программы в непрерывной памяти, а тексты, графику и прочее - в страницы
Ужасная идея! она не годится!!!
НИ В КОЕМ СЛУЧАЕ нельзя связывать кодера по рукам и ногам и указывать ему, что и где хранить - при такой схеме даже вьюевер 3-колорных картинок нельзя сделать!!!
В том то и дело, что в каждой программе (читай в каждом окне) придется делать обработку сообщений от манипулятора - это увеличит код (бесполезный) программы, а если сделать это средствами граф подсистемы - будет один кодовый блок. Ведь все равно все программы будут "перелопачивать" свои окна. Причем если каждый программист сделает эту обработку по своему и некорректно - то это утянет на дно всю систему.
Перелопачивать свои окна будут не все программы а только одна - которой придет сообщение - воздействие на её окно - в результате имеем немерянный выигрыш по скорости
а единый кодовый блок графсистемы займет немеряно памяти (он будет занимать не менен 8 кб (со 2 шрифтами) и 5.5 Кб с одним шрифтом) и теперь в Вашем варианте сюда надо добавить ещё кучу описателей каждого окна - Вы об этом подумали?
даже если описатель займет 200 байт - 10 окон это уже 2 Кб - и где их хранить? в странице с граф.подсистемой ещё место для процедур ядра нужно, или предлагаете сделать полноценный менеджмент памяти, который будет использоваться граф.подсистемой для манипулирования областями памяти с кучей описателей? или сильно усложнит код, увеличит занимаемую им память - и в результате стоит ли овчинка выделки?
И что сложного в обработке описателей всех окон? выяснить каким окнам принадлежит указанная координата и какое из этих окон находится на вершине.
Ничего сложного нет, кроме больших затрат памяти и процессорного времени
---------- Post added at 11:45 ---------- Previous post was at 11:25 ----------
Я понял, что для того чтобы включить страницу - нужно в почтовый ящик положить номер нужной страницы и "подождать"? подождать чего? пока менеджер задач не отберет у программы время работы? а если программа будет часто щелкать страничками? Скоростной режим не нужен, а просто необходим! Нужен системный вызов (API-функция называй как хочешь) для переключения страниц,
Ну я же сказал - будет такая возможность - специальный вызов, для переключения страниц напрямую: типа прога делает call adr2 и страница сразу переключается без всяких "входов в режим ядра, поиск нужной функции , перевода номера логической в физический", только пока не определился с параметрами - вот склоняюсь к тому, что предлагает Alone - при заказе страниц система даёт проге два байта , прога не вникает в их смысл - а это байты,засылаемые в порты,тогда страница переключается максимально быстро
пример для Профи,проге надо две страницы и ей даётся 4 байта(#01,#10,#01,#11), она берет первые 2 байта и вызывает:
ld hl,#0110
call adr2
итого включается страница 8, а прога по барабану, она знаёт что теперь включена ПЕРВАЯ страница этой проги
а потом она берет вторые 2 байта и делает так
ld hl,#0111
call adr2
включается страница 9
и теперь прога знает что включена ВТОРАЯ страница этой проги
но это только для прога, которым нужна скоростное переключение страниц
а для остальных прог эти же 2 байта прога кладёт в ячейку памяти и после переключения процессов при приходе прерывания будет включена нужная страница.
32М ограничение на размер FS в юзиксе оттого, что это 16-битная FS - у разработчика UZI в мхомпоросших 80-х годах прошлого века компилятор не умел 32 бит int, а при переводе на Hitech C (т.е. в UZIX) ничего кардинально не переписывалось. Но можно монтировать несколько FS, а еще лучше - переписать в 32 бита. Зато это СИСТЕМА.
Вот когда кто-нибудь перепишет драйвер винта для Nemo IDE на 32 бит, добывит в UZIX драйвер FAT16/32 (причем можно взять готовый), а потом обеспечит возможность запускать UZIX на Спеке - ну хотя бы таким образом - вот Вам набор файлов на винте - загрузите первый их них на адрес #6000 (например) и сделайте JP туда же и система UZIX дальше сама загрузиться и вот она готова к использованию - показывает приглашение на вход,
вот тогда мы (Спектрумисты) начнём изучать эту СИСТЕМУ,
а пока для больших винтов с FAT32 и cd/dvd приходиться использовать ту систему, которая есть, и УЖЕ запускаеться практически на любом Спектруме-128 b , и более
а то получится, что программа будет состоять лишь из извечных циклов ожидания - запросил вывести рамку окна - ждем, запросил вывести текст - ждем, запросил открыть страничку - ждем... в виду тормознутости самого спека - метод "ожидания" имхо не выход из положения. для многозадачной оси надо провести черту между двумя разными типами системных вызовов, которые работают через очереди сообщений - почтовые ящики (действия, которые требуют освобождения рессурсов, типа чтение данных с устройства), и вызовы, которые работают напрямую (типа рисование окон, текста, переключение страниц и пр...).
А я смотрю на это с другой стороны и вижу массу достоинств - вместо того чтобы сделать вызов функции call sys и управление от моей проги уходит ядро на неизвестно долгий период времени, в течение которого моя прога может сделать МАССУ полезных дел, я наоборот,даю системе сообщение, мол загрузи файл, а сам ПРОДОЛЖАЮ делать то, что мне нужно, ну вот хотя бы пример - показывалка слайдов из компресированных экранов,
пока система грузит следующую картинку, прога РАСПАКОВЫВАЕТ уже загруженную на 2-й экран,а пользователь видит на 1-м экране предыдущую картинку,раскпаковалась картинка на 2-й экран, прога включает его (ну естественно перед этим сделав getscr1,2)
пользователь видит картинку на 2-м экране, прога проверяет сообщение от системы и видит что уже следующая картинка загружена, дает собщение загружай очередную картинку, а сама начинает её только что заруженную распаковывать на 1-й экран
вот КОНКРЕТНЫЙ ПРИМЕР использования вызовов функции системы БЕЗ ОЖИДАНИЯ выполнения этого вызова
и сложно, все-таки. Но какой-то уровень совместимости, хотя бы с ранними типа "Систем 5" или подобными был бы крайне полезен.
а какие там отличия от Систем 7, например,выложите плз,желательно на русском
Думаю, нужно как-то заложить (на уровне условной компиляции или еще как) генерацию системы в две версии - одну из них под продвинутое железо.
конечно будет в виде условной компиляции - разные сборки ядра - например,ядро использует возможность подключать ОЗУ (кэш или страницу памяти) на адрес 0, или там для АТМ2- своя версия ядра и т.д.
---------- Post added at 12:19 ---------- Previous post was at 12:08 ----------
Зря вы сразу на окна накинулись. Ни к чему это. По крайней мере пока. Делайте так, чтобы окно программы(не процесса) всегда было на весь экран, если конечно программе требуется отрисовка диалога, в противном случае stdin/stdout.
Согласен, на начальном этапе этогобудет достаточно
Ну,на том и порешили :)
Да будет ТАК!
И заметьте, в большинстве случаев программы на ПЦ под "окошки" всегда раскрыты на полный экран.
и ещё обычно панель задач убирают с экрана
Как переключаться между окнами программ если на экране только видно только одно окно
Alone предлагает нажимать Caps Shift и Symbol Shift
Или дать возможность настраивать 2 варианта-
1) панель задач всё время торчит на экране в самой верхней строке
2) как в журналах (Deja Vu, Adventure) панель задач появляется вверху только тогда, когда подводишь стрелку в самый верх экрана
---------- Post added at 12:25 ---------- Previous post was at 12:19 ----------
что программа будет состоять лишь из извечных циклов ожидания - запросил вывести рамку окна - ждем, запросил вывести текст - ждем,
планируется вызов wait - про него сказано на первой странице
чтобы не ждать прихода прерывания, прога размещает сообщение в почтовом ящике
и делает
call addr1 и тем самым ДОСРОЧНО прерывается её процесс и проиходит переключение на системный процесс, причем это процесс сначала доделает то, то он делал, и потом он выполняет вызов этой проги - таким образом НЕТ времени ожидания (до прихода прерывания), которое тратиться в пустую.
Цитата:
Сообщение от Дмитрий
И что сложного в обработке описателей всех окон? выяснить каким окнам принадлежит указанная координата и какое из этих окон находится на вершине.
Ничего сложного нет, кроме больших затрат памяти и процессорного времени
По сути ты будешь делать то же самое - система узнает какой проге принадлежит окно и отдаст ей управление, программа будет уже по своим описателям искать что это за координата, что там - кнопка или чекбокс и будет уже обслуживать его...
А теперь умнож объем кода обработчика каждой программы на количество окон... что мы имеем? для 10 окон у нас будет 10 блоков обработки, у каждого окна все равно будет табличка с координатами элементов - тот же самый описатель... и тут уже 2кб, как ты говорил - не отделаешься. Так зачем же изобретать очередное колесо?
но это только для прога, которым нужна скоростное переключение страниц
а для остальных прог эти же 2 байта прога кладёт в ячейку памяти и после переключения процессов при приходе прерывания будет включена нужная страница.
Если будет скоростной режим переключения страниц, как ты думаешь - кто будет использовать "тормозной"? Стоит ли на него заморачиваться при его несостоятельности?
а единый кодовый блок графсистемы займет немеряно памяти (он будет занимать не менен 8 кб (со 2 шрифтами) и 5.5 Кб с одним шрифтом) и теперь в Вашем варианте сюда надо добавить ещё кучу описателей каждого окна - Вы об этом подумали? даже если описатель займет 200 байт - 10 окон это уже 2 Кб - и где их хранить?
там же где будут хранить программы свои обработчики вызовов от графподсистемы. Да, я думал, я подумал, еще лет 10 назад, когда графическую либу с подобными возможностями делал.
Описатели будут храниться в коде программы или в сегменте данных - как угодно, зачем его хранить с графподсистемой вместе?
только ты не забывай, то при динамическом построении окна ты тратишься еще и на код прорисовки, а при взаимодействии с окном - еще и на код опроса. т.е. уже дважды не экономно используешь память.
И поддержка элементов управления со стороны программы усложнит и увеличит по времени написание программ, когда проще было бы создать описатель со свойствами нужных элементов и адресами обработчиков. И еще - мы теряем унификацию интерфейса - все будут делать как им проще и удобнее, не факт, что быстрее и оптимальнее. И представь - в памяти 3 программы и каждая будет содержать в себе по полноценной библиотеке интерфейса - зачем такие накладные расходы?
А полноценная графическая либа с выводом окон, текста в них, спрайтов, поддержкой мыши, с парой шрифтов и пр. у тебя все равно займет порядка 5-7 кб, не меньше... обработчик описателей - по сравнению с этой либой не много займет, т.к. во всю использует имеющуюся либу, и состоит всего лишь из цикла выборки кода объекта и передачи данных соответствующей процедуре прорисовки из графлибы.
---------- Post added at 13:49 ---------- Previous post was at 13:36 ----------
А я смотрю на это с другой стороны и вижу массу достоинств - вместо того чтобы сделать вызов функции call sys и управление от моей проги уходит ядро на неизвестно долгий период времени, в течение которого моя прога может сделать МАССУ полезных дел, я наоборот,даю системе сообщение, мол загрузи файл, а сам ПРОДОЛЖАЮ делать то, что мне нужно, ну вот хотя бы пример - показывалка слайдов из компресированных экранов,
Я тебе за здравие - ты за упокой...
для многозадачной оси надо провести черту между двумя разными типами системных вызовов, которые работают через очереди сообщений - почтовые ящики (действия, которые требуют освобождения рессурсов, типа чтение данных с устройства), и вызовы, которые работают напрямую (типа рисование окон, текста, переключение страниц и пр...).
Т.е. если надо прочитать файл - то это надолго и можно положить в долгий ящик, что касается реализации интерфейса - то при почтовых ящиках и циклах ожидания мы получим дикий тормоз при рисовании окон и текста, выполнении каких-либо действий через системные библиотеки... тем более что почтовый ящик всего на одно сообщение...
Как я понимаю, менеджер задач будет раздавать задачам время кратное 1 период инта (на стандартной машине иного не придумать наверное :)), соответственно, если прога положила в почтовый ящик запрос на действие (любое) и ушла в цикл ожидания, то система обработает сообщение по приходу прерывания? или будет какой-то вызов для передачи управления?
прога делает call adr2 и страница сразу переключается без всяких "входов в режим ядра
я еще предлагаю сделать системный вызов для вызова подпрограммы, находящейся в другой странице.
т.е. допустим в 1й странице работает код и там:
ld hl,param1
ld de,param2
ld bc,param3
ld a,param4
call sys_long_call:db page3,address
sys_long_call включит 3ю страницу и вызовет прогу address, затем включит обратно старую страницу (1ю) и выйдет.
А я смотрю на это с другой стороны и вижу массу достоинств - вместо того чтобы сделать вызов функции call sys и управление от моей проги уходит ядро на неизвестно долгий период времени, в течение которого моя прога может сделать МАССУ полезных дел, я наоборот,даю системе сообщение, мол загрузи файл, а сам ПРОДОЛЖАЮ делать то, что мне нужно, ну вот хотя бы пример - показывалка слайдов из компресированных экранов,
пока система грузит следующую картинку, прога РАСПАКОВЫВАЕТ уже загруженную на 2-й экран,а пользователь видит на 1-м экране предыдущую картинку,раскпаковалась картинка на 2-й экран, прога включает его (ну естественно перед этим сделав getscr1,2)
Зет, вот чес слово, ты сделай сначала. я не буду щас что-то говорить, ни хвалить, ни критиковать. ты сделай. попарь моск себе и людям)))) а то рассказываеш про возможности системы так. словно она пишется не для ZX-Spectrum, а как минимум для i486)))
про запуск в минимальной конфигурации монопольных программ: решается через своп. т.е. перед запуском система свой образ скидывает во внешнюю память, потом тупо запускает прог
так я же так и сказал на несколько постов раньше
в качестве свопа может быть заюзан даже флопоглот, с этим согласен даже великий и могучий, страшный волшебник, который изрек "640Кб хватит всем".
ну и тем более, если есть больше памяти и рам-диск.
Ну уж нет,ТАКИЕ ТОРМОЗА нам ни чему, для этого есть оффтопик,
а своп в память/рам-диск - только в случае отсутствия винчестера, ибо мало чего там
монопольгая прога натворит (вдруг зависнет и запортит верхнюю память)
Как я понимаю, менеджер задач будет раздавать задачам время кратное 1 период инта (на стандартной машине иного не придумать наверное ), соответственно, если прога положила в почтовый ящик запрос на действие (любое) и ушла в цикл ожидания, то система обработает сообщение по приходу прерывания? или будет какой-то вызов для передачи управления?
да только же про это сказал:
планируется вызов wait - про него сказано на первой странице
чтобы не ждать прихода прерывания, прога размещает сообщение в почтовом ящике
и делает
call addr1 и тем самым ДОСРОЧНО прерывается её процесс и проиходит переключение на системный процесс, причем это процесс сначала доделает то, то он делал, и потом он выполняет вызов этой проги - таким образом НЕТ времени ожидания (до прихода прерывания), которое тратиться в пустую.
Значится для второго типа вызовов, т.е. для вызовов функций граф.подсистемы прога будет
класть сообщение в ящик и передавать управление на адрес adr1 и произойдет переключение процесса на процесс граф.подсистемы, но он в этот момент может быть занят, поэтому он сначала доделает то, что делал (дорисует окно или допечатает текст), и после этого будет обрабатывать вызов.
Вот так годится?
Или придется делать реентерабельные графические процедуры и прога вызывает одну из них и процедура выполняется в то время, предназначенное для этой проги(типа печатает текст), а потом другая прога вызывает эту же функцию с этого же адреса (но процедура реентерабельная, так что она позволяет повторной вход в неё) и в то время, когда должна выполняться вторая прога, работает эта процедура и допустим она печатает спрайт.
Так можно , но это гораздо сложнее в реализации,
---------- Post added at 12:00 ---------- Previous post was at 11:45 ----------
я еще предлагаю сделать системный вызов для вызова подпрограммы, находящейся в другой странице.
т.е. допустим в 1й странице работает код и там:
ld hl,param1
ld de,param2
ld bc,param3
ld a,param4
call sys_long_call:db page3,address
sys_long_call включит 3ю страницу и вызовет прогу address, затем включит обратно старую страницу (1ю) и выйдет.
Это легко добавить при условии, что основной код программы находится в нижней памяти,
только ещё надо придумать,как этот адрес sys_long_call передавать от системы проге (а то это уже третий адрес получается, 1-й - досрочное переключение с проги на граф.систему,2-й - скоростное переключение страниц)
Зет, вот чес слово, ты сделай сначала.
Не боись! Сделаю! Но не сразу, за неделю такие вещи не делаются, надеюсь, ты это впиливаешь?
я не буду щас что-то говорить, ни хвалить, ни критиковать.
ВНИМАНИЕ,все свидетели, Sayman даёт честное пионерское слово, что не будет критиковать систему MATRIX.
Ну что ж, хочется в это верить
---------- Post added at 12:08 ---------- Previous post was at 12:00 ----------
а здесь судя по логике, уже EXEC, а не fork. Кстати, как будет с окружением процессов (системными переменным), что наследуется, а что нет, где хранится, как передается.
ну вроде получается EXEC, а разве EXEC бывает отдельно от fork? или то execv вызывается после fork?ладно,буду курить матчасть
пока ничего не наследуется и не передаётся, лично я так и не понял, в чём прелесть этого
желательно оставить возможность выполняться пользовательскому коду с адреса 0 и выше - это в перспективе даст возможность запускать без переделки как бинарники CPM, так и UZIX.
попробую, только на стандартном 128-м это не получиться, надо как минимум кэш цеплять,
ну а на остальных - да, (там только переделать надо, чтобы в таблице процессов удалённый отмечался не нулём(в поле старший байт адреса он отмечается), а например байтом #FF,но тогдп нельзя будет добавить процесс находящийся в странице по адресу #FF - вызовет ли это в будущем проблемы? пока не понятно)
---------- Post added at 12:25 ---------- Previous post was at 12:08 ----------
ты сделай. попарь моск себе и людям))))
Зачем ты так гуворишь?
Проект MATRIX разрабатывается исключительно Just for fun
По сути ты будешь делать то же самое - система узнает какой проге принадлежит окно и отдаст ей управление, программа будет уже по своим описателям искать что это за координата, что там - кнопка или чекбокс и будет уже обслуживать его...
А теперь умнож объем кода обработчика каждой программы на количество окон... что мы имеем? для 10 окон у нас будет 10 блоков обработки, у каждого окна все равно будет табличка с координатами элементов - тот же самый описатель... и тут уже 2кб, как ты говорил - не отделаешься. Так зачем же изобретать очередное колесо?
Вообще-то я думаю , что в окнах почти не будет таких стандарных элементов управления, или вообщен не будет, так как кодеры - существа ленивые (по своему опыту грю), и скорее всего никто из них не будет изучать, все эти радиогруппы, полосы прокрутки, ползунки, и переключатели,вот в Черной Вороне и в CHaOS - там я вникал - это всё так скучно, кодер скажет типа , да за то время, что я потрачу на изучение того, как всём этим набором пользоваться, я мог бы нарисовать 3 спрайтика (например кнопки для плэйера плэй.пауза.стоп) и десяток строк кода, который по полученным координатам от системы сравнит - в какую кнопку ткнул юзер и всё - вызовет процедуру
Я думаю, что если бы все кодеры хотели насытить окна массой стандарных элементов управления, то в большинстве прог так-бы и делали, но на самом деле этого за столько лет нет - не рисуют и не используют и не потому, что нет, как ты говоришь ,графлибы с подобными возможностями - а просто не радует,каждый хочет проявить индивидуальность.
Описатели будут храниться в коде программы или в сегменте данных - как угодно, зачем его хранить с графподсистемой вместе?
Вместе хранить для скорости, так как поведение стрелки обрабатывается на прерываниях и если нажаты кнопки, то тут же начинается проверка заголовков окно, которые лежат в таблице рядом, а так как ты говоришь, надо будет пройтись по процессам, попереключать страницы для части их них и на всё это будет тратися время, забираемое после начала прерывания,
или другой вариант - тогда класть просто воздействие вовнутрь себя, а когда очередь дойдет до процесса граф.подсистемы, тогда она в течение фрейма будет проходить по памяти процессов (по их таблицам описателей-векторов окна) и сравнивать - но в этом случае будет запаздывание на несколько интов после момента воздействия - насколько это критично? - обнаружиться опытным путём?
Хотя как я уже сказал выше, по моему мнению - эти элементы не нужны, делать их "на всякий случай" - в первом посте сказал про это
ну даже вот полоса прокрутки - вертикальная - не нужна, она занимает знакоместо справа и не видно всю строчку текста, который отформатирован на 42 или 64 символа, значит строка переносится - не красиво,
горизонтальная - ну может только для схем и клавишами гораздо удобнее прокручивать, чем тянуться стрелкой, тем более в том же ворде, если сразу тыкаеш в самый низ полосы прокрутки, то ты не оказываешься в конце текста, текст листается постранично
всякие чекбоксы в которых надо галки ставить?
так просто у тебя строчка текста с пробелом вначале - по того как ты ткнул в неё вместо пробела напечатал галочку - типа включил опцию, еще раз ткнул, вместо галки напечатал пробел, типа выключил,
и там можно пройтись по всем элементам - НЕ НУЖНЫ ОНИ
тем более что их не будет ибо спектрумисты за все эти годы привыкли к системам меню и горячим клавишам
Вот предлагаю на первом этапе не заморачиваться с этим всем(набором описателей-векторов) ,а потом может быть на следующих этапах ,если будут кодеры жаловаться на их отсутствие, попробовать добавить их в отдельной граф.подсистеме (типа как в линухе GNOME,KDE и т.д.)
И еще - мы теряем унификацию интерфейса - все будут делать как им проще и удобнее, не факт, что быстрее и оптимальнее.
Меня уже тошнит от этих абсолютно одинаковых окон виндовс, то ли дело на Спеке,
загрузил журнал - одно оформление,загрузил, асм, коммандер, - другое , третье и т.д - всё такое пестрое, разноцветное- глаз радуется!
и потом я уже говорил про проявление индивидуальности
про быстрее и оптимальнее - кодер скажет - у вас там всё тормозит, я сделаю быстрее!
не буду пользоваться вашими процедурами!
А исходники данной ОС открыты? Если да, то дайте плиз глянуть на них.
Шутка.
Моё предложение по данному вопросу: Перенести тему в "Концепции" или во флейм, пока не появится хоть один бинарник.
Прочитал все четыре страницы и не увидел ни одной строчки кода(кроме неких расплывчатых примеров).
Это легко добавить при условии, что основной код программы находится в нижней памяти,
только ещё надо придумать,как этот адрес sys_long_call передавать от системы проге (а то это уже третий адрес получается
ну, я думаю эта фича должна быть именно в ядре (из-за работы со страницами, хотя хз, сделать можно всегда по-разному. я считаю, что открытая страница - часть контекста задачи, а по сему не важно, где находится основная прога, лишь бы стек у такой задачи был не в странице). пусть это будет 3й адрес, не думаю, что это страшно, сделать таблицу с адресами функций ядра и усё:)
да простит меня автор темы - но ИМХО - система баян
Мне вот не нужена еще одна прога-запускалка игр, таких уже имеется в наличии - запускают и с винта в сотню гигов
Дык, что Вы сюда пришли, раз не нужна? Пускай делает, нормальная система. В конце-концов кое-что и подправить можно будет попозжа.
Sayman:
Зет, вот чес слово, ты сделай сначала.
Zet9:
Не боись! Сделаю! Но не сразу, за неделю такие вещи не делаются, надеюсь, ты это впиливаешь?
Уппс, такого бы я не рискнул говорить.
Alone предлагает нажимать Caps Shift и Symbol Shift
Или дать возможность настраивать 2 варианта-
1) панель задач всё время торчит на экране в самой верхней строке
2) как в журналах (Deja Vu, Adventure) панель задач появляется вверху только тогда, когда подводишь стрелку в самый верх экрана
Ты можешь сделать как у меня. Давишь комбинацию клавиш аля [Ctrl]+[Alt]+[Del] и вываливаешься в диспетчер. А там уже в списке окон переходишь к нужному (см.скриншот).
Вообще ты зря поступил, что выложил инфу в таком виде :)))))
Надо было разбить на темы и эти главы обсосать (как сделал Breeze). И в тексте не сообщать, что можно так или сяк. А пишешь, что реализовано таким-то образом. Кто хочет, пусть лезет в исходники.
И тему действительно пока лучше во флейм перенести. Я как раз там и собираюсь о своем диспетчере начать. Потом, при готовом релизе с исходниками открываешь похожую тему здесь и банишь всех, кто "плохо высказывается", отсылая в одноименную во флейме.
=)))
Слушай, ты ведь на реальнике юзаешь винт с Fat32. А сколько кбайт на каталог уходит?
А исходники данной ОС открыты? Если да, то дайте плиз глянуть на них.
Не дадим :)
Моё предложение по данному вопросу: Перенести тему в "Концепции" или во флейм, пока не появится хоть один бинарник..
Уже поздно,бинарники появились,( на каждую страницу по бинарнику)
Прочитал все четыре страницы и не увидел ни одной строчки кода(кроме неких расплывчатых примеров).
И не увидите.По крайней мере пока. Бинарники рассылаются по почте зарегистрированным бета-тестерам
---------- Post added at 20:42 ---------- Previous post was at 20:18 ----------
нормальная система. В конце-концов кое-что и подправить можно будет попозжа.
Золотые слова
Уппс, такого бы я не рискнул говорить.
Ты про "сделаю" или про "впиливаешь"?
Слушай, ты ведь на реальнике юзаешь винт с Fat32. А сколько кбайт на каталог уходит?
ядро использует 2 Кб на буфер и грузит/пишет кусками
---------- Post added at 20:46 ---------- Previous post was at 20:42 ----------
Давишь комбинацию клавиш аля [Ctrl]+[Alt]+[Del] и вываливаешься в диспетчер. А там уже в списке окон переходишь к нужному (см.скриншот).
слишком долго, пока прицелишься на нужное окно, а так нажал CS+SS и следующее окно и вообще вопрос был, как переключаться с окна на окно когда нет панели задач и окно на весь экран, а диспетчер задач нужен, чтобы смотреть сколько ресурсов каздый процес и ядро юзает
---------- Post added at 20:51 ---------- Previous post was at 20:46 ----------
[/COLOR]
Вообще ты зря поступил, что выложил инфу в таком виде ))))
Надо было разбить на темы и эти главы обсосать (как сделал Breeze).
поздно,батенька,поздно...
А пишешь, что реализовано таким-то образом. Кто хочет, пусть лезет в исходники.
Может, в следующий раз расскажу...
И тему действительно пока лучше во флейм перенести. Я как раз там и собираюсь о своем диспетчере начать.
Не вижу смысла это делать при наличии рабочей версии системы, ты собираешься начать,можешь начинать в теме "Флэйм", а я уже начал и продолжаю процесс, так сказать...
---------- Post added at 21:11 ---------- Previous post was at 20:51 ----------
Потом, при готовом релизе с исходниками открываешь похожую тему здесь и банишь всех, кто "плохо высказывается", отсылая в одноименную во флейме.
=)))
Что ты имеешь ввиду под словами "готовый релиз", кто будет определять степень готовности ?, что туда должно войти, по твоему мнению?
P.S.зачем отсылать? и так каждый идет туда куда хочет
---------- Post added at 21:11 ---------- Previous post was at 21:11 ----------
Потом, при готовом релизе с исходниками открываешь похожую тему здесь и банишь всех, кто "плохо высказывается", отсылая в одноименную во флейме.
=)))
Что ты имеешь ввиду под словами "готовый релиз", кто будет определять степень готовности ?, что туда должно войти, по твоему мнению?
P.S.зачем отсылать? и так каждый идет туда куда хочет
И не увидите.По крайней мере пока. Бинарники рассылаются по почте зарегистрированным бета-тестерам
Можно и мне?
Предстоит один небольшой релиз, думаю под сабж будет его реально замутить (паралельно с обычной версией).
[email protected]
>Ты про "сделаю" или про "впиливаешь"?
Да неее, конечно про "сделаю". Но, вижу, ты никак не настроен сдаваться.
=))))))))))
>Что ты имеешь ввиду под словами "готовый релиз", кто будет определять степень готовности?
Считаю, автор, как правило и определяет. Если ты реализовал все задумки для "этапа №1" и они работают как надо, значит готово. И выкладываешь -> "Бэта-1, умеет делать то да сё и делает это как задумывалось, согласно мануалу". Потом идешь далее.
>ядро использует 2 Кб на буфер и грузит/пишет кусками
То есть, ты по кускам системный фат-сектор читаешь и в несколько заходов выводишь список файлов?
А можно у тебя потом этот драйвер надыбать? Сколько вообще занимает вся эта кухня обработки + 2048?
James DiGreze
10.09.2009, 06:07
Реально на работу с фат16 у меня юзалось 1,5кб, в разбивке: 512 кусок данных, 512 кусок фат, 512 кусок каталога. Ну и еще около 100 байт на разные переменные, сейчас точно уже не помню. Делал не по спек, но портировать можно. С фат32 не работал, потому как не нужно было, но алгоритм там один в один, только процедуры расчета смещений другие.
......Делал не по спек, но портировать можно.....
Пасибы, хоть какое-то представление.
То есть, ты по кускам системный фат-сектор читаешь и в несколько заходов выводишь список файлов?
конечно нет, твой вариант подходит для чено-нить простого (типа бута),
а там все по-взрослому:
на самом нижнем уровне драйвера блочного ввода-вывода (в данном случае драйвер винта,сд/двд-привода или дисковода), на уровень выше располагаются драйвера файловых систем (в данном случае драйвера FAT16/32, CDFS/ISO9660,TRDOS),ещё выше элемент DOS - типа менеджер логических устройств , он использует таблицу , в кот указано соответствие каждому устройству своего драйвера файловой системы и драйвера блочного ввода вывода.
И самый верхний уровень - это прогармма пользователя - в данном случае оболочка .она вызывает DOS и просит загрузить каталог в в буфер по указанному адресу. а потом, когда каталог загружен, тогда разбивает его на страницы и показывает порциями
А можно у тебя потом этот драйвер надыбать? Сколько вообще занимает вся эта кухня обработки + 2048?
Ну система открытая - ты же скачал архив - бери пользуйся, только в хелпе к своей проге укажи, что драйвера hdd и FAT16/32 из системы DNA
драйвер FAT занимает около 4600 байт и еще около 1 Кб драйвер винта, плюс к этому 512 байт буфер для куска таблицы фат, и еще 2 Кб под каталог (про кот я уже говорил) и еще около 512 байт переменные (ну тебе может понадобиться меньше)
Сообщение от James DiGreze Посмотреть сообщение
Зря вы сразу на окна накинулись. Ни к чему это. По крайней мере пока. Делайте так, чтобы окно программы(не процесса) всегда было на весь экран, если конечно программе требуется отрисовка диалога, в противном случае stdin/stdout.
Согласен, на начальном этапе этогобудет достаточно
Ну,на том и порешили
Да будет ТАК!
На словах конечно хорошо, а когда начинаешь делать, вопросы появляются
Если делать как Вы предлагаете окно на весь экран то графическая подсистема останется точно такой же - с обработкой нескольких окон, ведь одной программе одним окном не обойтись, нужны всякие меню и вспомогательные окна - типа для открытия/сохранения файлов, окно настроек и т.д.
т.е. графподсистема точно так же будет держать в таблицах несколько окон и опрашивать их,
или тогда сделать, чтобы действительно на одну прогу одно окно, а меню и вспомог. окна выводить спрайтами? и фон под ними сохранять, а потом восстанавливать
типа при вызове функции печать спрайта флаг устанавливать -- сохранять или нет фон
Если второй вариант - то тогда можно вообще от графсистемы отказатся (и оставить токо stdin/stdout) и тогда основная прога сразу будет получать весь экран в своё распоряжение (и 2-й тоже) и самостоятельно своими силами выводить всё изображение на экран
этот подход позволит значительно ускорить вывод графики а также поспособствует адаптации существующих тр-дос -программ
---------- Post added at 22:57 ---------- Previous post was at 22:45 ----------
и в этом случае сама прога будет и стрелкой рулить и через стэк спрайты печатать,как в Черном Вороне сделано
а для скоростного переключения между запущенными прогами вот придумал надо просто
нажимать CapsShift+SymShiFt+цифры 1-9 и 0 и переключаемся на одну из 10 прог,
а если их больше ну тогда после десятой просто CS+SS - для перехода на след. т.е на 11-ю
или ещё в дополнение предусмотреть функцию "получить имена и PID запущенных прог"
а потом основная прога сможет их сама выводить где угодно или как в журнале - при подведении стрелки к верхнему или нижнему краю экрана
и потом при нажатии на одну из них переключаться на указанную
ведь одной программе одним окном не обойтись, нужны всякие меню и вспомогательные окна - типа для открытия/сохранения файлов, окно настроек и т.д.
эти окна надо делать тоже на весь экран (как на кпк сделано), исключение - MessageBox, который если открыт, то кроме него ничего тыкнуть нельзя. и под ним фон должен сохраняться, да.
и самостоятельно своими силами выводить всё изображение на экран
это не вариант вообще, я так понимал, что ради готового фреймворка все и делается. пусть не супер гибко, но чтобы быстро можно было делать проги, т.е. все функции для окон, меню и т.п. должны быть.
а для скоростного переключения между запущенными прогами вот придумал надо просто
нажимать CapsShift+SymShiFt+цифры 1-9 и 0 и переключаемся на одну из 10 прог
я тоже примерно так думал в свое время:) правда было бы лучше по образу и подобию alt+tab делать, т.е. жмем cs+ss, появляется окошко со списком прог, затем, если держать ss ИЛИ cs, то окно будет висеть, а нажимая вторую кнопку (cs или ss) - будет перемещение по списку на следующую прогу. или по нажатию ss+cs вылезет окно с прогами, а потом курсорными кнопками выбрать нужную прогу и нажать ентер.
афтар, я приложу (http://files.mail.ru/R3P7OA) тут к посту архивчик профинского profiVision. файлики простые текстовые, посматри в качестве примера как это всё было сделано. напомню, что разработка 93 - 94годов. настоятельно рекомендую в качестве учебного пособия ;)
архив будет висеть до 3го февраля.
афтар, я приложу (http://files.mail.ru/R3P7OA) тут к посту архивчик профинского profiVision. файлики простые текстовые, посматри в качестве примера как это всё было сделано. напомню, что разработка 93 - 94годов. настоятельно рекомендую в качестве учебного пособия ;)
архив будет висеть до 3го февраля.
скачал - почитаю
---------- Post added at 16:30 ---------- Previous post was at 15:56 ----------
эти окна надо делать тоже на весь экран (как на кпк сделано), исключение - MessageBox, который если открыт, то кроме него ничего тыкнуть нельзя. и под ним фон должен сохраняться, да.
это не вариант вообще, я так понимал, что ради готового фреймворка все и делается. пусть не супер гибко, но чтобы быстро можно было делать проги, т.е. все функции для окон, меню и т.п. должны быть.
я тоже примерно так думал в свое время:) правда было бы лучше по образу и подобию alt+tab делать, т.е. жмем cs+ss, появляется окошко со списком прог, затем, если держать ss ИЛИ cs, то окно будет висеть, а нажимая вторую кнопку (cs или ss) - будет перемещение по списку на следующую прогу. или по нажатию ss+cs вылезет окно с прогами, а потом курсорными кнопками выбрать нужную прогу и нажать ентер.
насчет быстро делать проги - это получится для тех, которые с фиксированного адреса будут грузиться и запускаться (т.е. с #C000 и 0) - а для тех, которые с флагом основной код в нижней памяти - надо таблицу адресов составлять и потом метки по всему исходнику - тяжко вручную - и исходник становиться нечитаемый - хотя вот AlCo - вроде говорил, что можно автоматизировать
вот ещё подумал, функции создать окно и удалить окно не нужны
пусть при вызове "показать окно на экране" графсистема сама создает себе окно, а при вызове "убрать окно с экрана" она сама и будет удалять его из своих таблиц
ну ладно, если прога захочет сама сыпать байты на экран - то будет использовать функцию getscr - и дальше сама
---------- Post added at 16:40 ---------- Previous post was at 16:30 ----------
а для варианта,который мы рассматриваем, что окно на весь экран, функция убрать с экрана тоже не нужна, прога показала свое основное окно, потом показала дополнительное окно настроек,
а когда его надо закрыть, она просто вызывает функцию показать основное окно (при этом во всех 3-х операциях фон под окном не сохраняется, граф система тратит минимум ресурсов - похоже это и имел ввиду дигриз)
А насчет CS+SS+цифры - то его вместе с CS+SS использовать, типа
если нажал CS+SS и секунду не жмешь цифру - тогда появляется окно выбора
Еще вот может стоит оставить верхнюю строку под импровизированную панель задач совмещенную с заголовком - типа как в Ubuntu 9.04 NetBook Remix - там тоже каждое окно на весь экран и вверху строка типа того что я сказал - слева кнопка выхода на рабочий стол - она сворачивает текущее окно а правее вместо имен задач только их иконки маленькие и еще правее заголовок окна но не до конца строки а в правом углу часы и EN/RU
---------- Post added at 16:48 ---------- Previous post was at 16:40 ----------
и еще можно можно в таблицу окна,в заголовок добавить 3 бита, а функция показать окно на экране будет их проверять и если они установлены будет дополнительно
1бит=1 сразу печатать текст в заголовке - который там же и будет лежать
2бит=1 сразу печатать дополнительный текст внутри окна (адрес текста тут же в таблице)
3 бит=1 сразу печатать один или несколько спрайтов из таблицы спрайтов, её адрес прилагается, в ней кол-во спрайта, и координаты для каждого, и его номер из набора, и адрес набора
Ну и в конце сделать финт ушами и в заголовке самой прораммы указать спец бит - если установлен, то ядро перед запуском программы проверяет заголовок проги и передаёт графсистеме адрес окна и графсистема сразу показывает это окно на экране - а прога при это не делает ни одного лишнего телодвижения,
ну а потом уже прога будет выводить в окно что-то дополнительно и тогда конечно будет вызывать эти функции по отдельности (печать текста в заголовке, внутри окна, печать спрайта)
Для запуска CPM-прог uzix-прог (это ERROR404 предлагал) надо наверно организовать отдельный формат исполняемых файлов(можно с расширением .NIX) - ядро будет перед их запуском сначала освобождать нижнюю память, оставляя там только некоторые свои компоненты (например не более 4К) и далее подключать страницу озу или кэш в с адреса 0 и туда уже загружать такую прогу
ей будет предлагаться 44 кБ и позже она сможет получить ещё 16 кБ (или меньше) в отдельной странице памяти - токо она про страницы ничего не будет знать - просто сделает запрос получить память
при этом паралленльно с ней смогут работать те проги, которые сидят в страницах
(а те которые били в нижней памяти - конечно буду остановлены)
---------- Post added at 17:17 ---------- Previous post was at 16:48 ----------
Способ удаленного использования страниц - чтобы прога их не переключала, можно во всех функциях добавить аргумент номер страницы,
и тогда прога загружает из файла по адресу/номеру страницы,потом вызывает функцию печатать текст/спрайты и номер страницы и графсистема печатает ихз другой страницы
удаленный вызов подпрограмм из другой страницы
надо спец вызов но попроще, указать номер страницы (абстрактное число полученное от системы) а система сама установить стэк внутри той страницы например на адрес 0 т.е. в конце
и запустит код с адреса #C000 (не надо передавать лишний аргумент ввиде 2-х байтного адреса), и тот код возьмет номер функции и параметры из всех регистров
Не для всех программ такой способ подойдет, но для достаточно большого количества (навскидку для половины прог)
а для тех, которые с флагом основной код в нижней памяти - надо таблицу адресов составлять и потом метки по всему исходнику - тяжко вручную
не совсем понял о чем речь. это когда проги каждый раз с разных адресов могут располагаться? ну это делается очень просто, без особых проблем.
А насчет CS+SS+цифры - то его вместе с CS+SS использовать, типа
если нажал CS+SS и секунду не жмешь цифру - тогда появляется окно выбора
Еще вот может стоит оставить верхнюю строку под импровизированную панель задач совмещенную с заголовком
с этим согласен:)
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot