я знаюСообщение от SfS
система же не предоставляла того чего хотелось аффтару
а если и предоставляла то в крайне извращенной и тормозной форме
не пригодной для использования во времена медленных машин
я знаю
система же не предоставляла того чего хотелось аффтару
а если и предоставляла то в крайне извращенной и тормозной форме
не пригодной для использования во времена медленных машин
Это вопрос уже к тому, кто пишет прикладное ПО. Или он будет по одному каждый символ на экран пихать или сразу строками по 768 символов)
И вне зависимости от всего - проблема "сохранить контекст при вызове и восстановить его при выходе" - никуда для многозадачной ОС не денется.
Ну вызовешь ты системный вызов сверхбыстро. А внутри вызова опять - сохранить контекст, вызвать процедуру печати, восстановить контекст... То есть то же самое.
щас тоже опрашивают через Ж
в обход того что настроил под себя пользователь
и рисуют окошки средствами *****х Qt
на которых системные настройки и всякие там Accessibility не распространяются
и пользователь потом вспоминают эти *****е кросплатформенности на которые ему вообще насрать...
То есть проблема в непрдуманности предоставления ресурсов по сути.
В настоящее время, например, уже есть такая продуманность. И по памяти. И по экрану.
Например, предоставление экрана как фреймбуфера определённого формата. Скажем, пользователь говорит - хочу стандартный экран спека. Система - да ради бога, вот тебе страница номер такая-то, пиши в неё. И всё.
ты еще забыл про вставить 5 nop-ов а чтоб было...
- - - Добавлено - - -
а скажем пользователь говорит
хачу экран АТМ
а у него экран профи
и тут начинается
или нужно пользователя послать
или нужно конвертер чужого экрана
а их нужно
ATM 320x200 > 6912
ATM 640x200 > 6912
profi 512xXЗ > 6912
16c > 6912
ATM 320x200 > profi 512xXЗ
ATM 640x200 > profi 512xXЗ
16c > profi 512xXЗ
ATM 320x200 > 16c
ATM 640x200 > 16c
profi 512xXЗ > 16c
итд
А ТУТ ВНЕЗАПНО оказывается что эти экраны местами жестко прибиты к некоторым страницам
а в этих страницах уже что то лежит и нужно перемещать...
а видео режимов гораздо больше
и количество работы овер чем дофига
или нужно полное абстрагирование от железа и тормоза
и тогда пользователь говорит
"хачу экран 6912"
а ему говорят "а нехрена пишите в 32 битный линейный буфер который на 128К занимает 150% всей памяти"
а наша ОС через 7 000 000t возможно отобразит его содержимое на экран...
вот по этому ОС для старых компов и не нужна
а нужен драйвер диска изапускалка программ которые сами пишут в железо
- - - Добавлено - - -
а так я тоже хочу ОС
чтоб одни и те же программы запускались и на спектруме и на специалисте и на *****м мсх-е
и чтоб была адаптация видео буфера под имеющийся видео режим
и чтоб плавающие точки входа (а не только возможность запускать на одном только АТМ)
и чтоб был jit рекомпилер для запуска ненативного кода
и чтоб это работало на минимально конфигурации на РК86 с 32к рамы и матафоном...
...но все хотелки не поместятсо же никуда...
а ну да
никто ж не будет под оно писать
тк оно все будет дико медленно
а люди хотят мультиколоров!
Последний раз редактировалось NEO SPECTRUMAN; 18.11.2020 в 12:08.
на сегодняшний день CP/M и его клоны пока единственные адекватные системы для z80 и рядом стоящих процессоров (вроде 6502 и иже с ними). массовей систем для подобных процессоров пока никто не придумал. будешь первым?
пускалка это tr-dos, которая по сути своей есть расширение для бейсика. про дос:Строго говоря и DOS и CP/M это не ОС, а запускалки прог с драйвером диска.
так что дос умеет управлять памятью (это если про ms-dos говорить). про cp/m: реализаций этой системы вагон и малая телега. среди разных клонов есть и такие, где есть управление памятью. примером является profi-dos/pq-dos для Profi.DOS управляет памятью с помощью блоков MCB (Memory Control Block). Память разбивается на блоки; каждому блоку предшествует MCB, в котором записаны характеристики блока памяти. Для каждой вновь запускаемой программы DOS создает определенное количество блоков MCB. При освобождении памяти или при выполнении запросов на получение дополнительной памяти DOS также использует блоки MCB, проверяя при этом правильность их содержимого.
причём тут константы? я разве про это говорил? почитай мануал на издос. много ли ты там поймёшь? особенно когда "номера" функций гуляют по разным "модулям" и уровням. глаза сразу кровоточат, а в голове возникает каша.Никакой программист не станет писать константы числами.
а что если мне плевать на многозадачную ОС и у меня простая ДОС?Многозадачные ОС по-другому не работают.
я не являюсь поклонником сабжа и меня самого жутко бесит вкаряченный fatfs. он медленный и не поворотливый и сожрал там почти 16кб памяти (байт 500 примерно осталось свободно).но при этом использовать готовые библиотеки той же FAT, которые едят в 1000 раз больше времени
и вот теперь давай считать:
ты предлагаешь всё свалить в одну кучу. как разделять вызовы между bdos (а он 100% должен быть, т.к. отвечает за работу с файлами, каталогами, парсинг строк, переменные окружения, бла бла, много чего там сидит (не конкретно в сабже, я вообще)) и, скажем, логическими драйверами? пишу я fdisk с форматилкой. мне надо делать разбор переданных аргументов (функционал bdos), мне надо прочитать 0й сектор с винта (bios), мне надо делать вывод на экран, мне надо делать ещё 512 разных манипуляций. при этом имей в виду, что вывод на экран тут будет самым прожорливым, т.к. местами придётся буквально побайтно делать вывод некоторых элементов. и вот есть две системы - твоя и ещё какая-то. но в твоей сисстеме ты не стал заморачиваться на производительности и всё свалил в кучу. а в другой наоборот автор озаботился об 1% оптимизации. как думаешь, где будет приятнее работать, в твоей оси или где то ещё? ответ очевиден.
в сабже та же проблемма - рестартов много, но они используются глупо, не рационально. когда начинаешь читать файло с каким-то разбором, парсингом, то приходится часто обращаться к системе за очередной порцией данных. и как всё это будет тупить, когда А - у тебя fatfs, Б - у тебя ничего не оптимизированно, длинные вызова которые не умеют различать куда идёт вызов (точнее умеют, но делают это дольше, чем если бы были на отдельном рестарте). кстати, ты сам там жаловался на монолитность, но сам же за неё топишь.
вот сам под такую систему и программируй, а я буду делать вывод графики на прямую, без всяких посредников в виде буфера. а переключать режим я буду через системный вызов.Например, предоставление экрана как фреймбуфера определённого формата.
Последний раз редактировалось Sayman; 18.11.2020 в 12:13.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Не знаю про нопы, а про то, что никуда от сохранения-восстановления всех регистров при переключении задач не деться - это знаю точно.
Экран спека - есть везде и он стандарт. Экран текстовый есть не везде. Графические экраны разные.
Поэтому экран спека - всегда есть. Остальные экраны - на уровне фреймбуффера. Ты запросил одно, но выдать тебе могут и не то, что ты запросил. Но это уж уровень драйвера экрана.
Сохранение-восстановление экранов тоже вещь от которой никуда не деться.
И это всё проблемы куда более серьёзные и интересные, чем потратил ты 100 или 200 тактов на вызов.
на прошлой неделе шутки ради провёл тест между тремя системами на предмет копирования файлов - Nedoos, pq-dos, Estex (Спринтер). задача довольно тривиальная. частота применения у всех разная.
файл размером в 4096 кб. сабж выполнил копирование дольше всех. более того, в процессе копирования командер не мог обновить информацию о статусе операции. там вообще с этим всё плохо.
при этом все трое находились в одинаковых условиях: 1. тест на эмуляторах, у всех одинаковые настройки "инта" (типа частота проца), файл один и тот же, файловая система fat16 везде.
Это где это? Количество рестартов никакого отношения к модульности не имеет.
Как и качество документации.
Так фреймбуффер это и есть прямой доступ к видеопамяти по сути. Просто ты должен знать какие страницы тебе система выделила. Это могут быть и не страницы реального экрана. При активизации задачи - страницы копируются на реальный экран.
задачи переключаются как раз достаточно редко
а вот системных вызовов происходит тонны
почему он есть везде?
ОС как раз для разных машин
и экран спека есть только на спеке
те экраны еще больше чем экран спектрума
и с ними даже если работать на прямую тежяло не ползать
про серьезность и интересность написания адаптера на случай если такого нет в железе
я написал выше
это для каждого существующего поддерживаемого видеорежима нужен конвертер видео буфера каждого существующего видеорежима
и ОСь должна тянуть тонну драйверов для подобного (не обязательно только для экрана)
которые не то что в память
могут на дискету не влезсть...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
