Я думаю ученику Zet9, стоит объяснить для чего он создал тему "Пишем свою ОС. Практика." и когда же будет написана указанная им ОС. или хотя бы ее ядро. Ведь если пошла практика значит концепция уже есть, так? в противном случае имеет место быть миссабж
С уважением,
Jerri / Red Triangle.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Не проги а целые дискеты ) Скажем поменяли прошиву TRDOS совсем чучуть, что бы изменить системный приоритет на диск C (а не на A), и винт или флеш накопитель посадить на него. Диск A может запускаться из под OC прямо как есть (вся ос из памяти отгружается на винт так, что бы после сброса в тр-дос вернуться к текущему состоянию, либо на момент выключения, либо на момент запуска boot'a диска A). А запуск прог организовать например так: закидываем полный scl образ в виртуальный дисковод, скажем Z (опять колупание в теле DOS))) еще бы намудрить что нибудь, что бы и дос и проги на дискете понимали бы привод как A), и запускаем файл boot ))). Писать и адаптировать такие модули будет крайне просто, меняем имя запускаемого бейсик файла на boot. Образы scl свободно портируются на pc к тому же. В общем пути и решения достаточно обширные. Писать под ось не надо. Как писали под trdos, так и писать дальше...Сообщение от IlyaMIV
Вопрос с многозадачностью. Все приложения к ос сохраняют свои текущие состояния на винте, места много же ))).... а при их вызове восстанавливают свое предыдущее значение (даже текст в редакторе, пока не очистим !) ну и тп...
---------- Post added at 16:24 ---------- Previous post was at 16:12 ----------
Привлекает так же возможность использования в os драйверов как существуещих железок, так и возможных расширений в будущем. Например переключение на расширеный видеорежим ) А стандартный в os где нить окошечком в уголке открывается. Еще можно сделать совместимость с каким нибудь pc-шным образом лент. думаю лучше всего tzx. Ось обрабатывает код модуля tzx, и создает где то на винте образ, который просто после окончания "загрузки" надевается на всю требуемую программе оперативную память спектрума с последующей передачей управления....
Все очень интересно, пока речь не заходит о кодинге. У меня тоже все было просто сказка. Сел програмить и недосчитался нескольких килобайт, а еще ведь стек нада куда-то пихать, не одно же приложение будет работать, а, скажем два или три. Если этого не отследить, то система будет слетать "по непонятной причине". Либо следить за стеком, либо "договориться", что стек юзать осторожно (проверяя системные ячейки), а переменные хранить в "своих" участках памяти. Но все это приведет к замедлению работы программ и разрастанию кода.
Идея "жизни" программ "в диске" не нова, а в результате выходит сложный механизм размещения такого приложения в памяти. Подпрограмма размещения и обслуживания такого софта, съест почти всю память, значит потребуется что-то свопировать на электронный диск. Программа свопа, для своего запуска тоже потребует RAM, так что можно подумать и, наверное, от этого отказаться
Может я не прав и все это легко реализовать, но на практике столкнулся с таким вот выбором. Либо одна прога в банке (классика вытеснения), либо сложный механизм и специфическое написание приложений. Вернее, написание приложений через ж...
Spectrum Basic
А вот здесь мы всё-таки приходим к выводу, что нужна ОС. Что программа не может единолично распоряжаться всем ОЗУ, которое ей доступно и т.д. и т.п. Что программа должна исполняться в некотором окружении, что было оговорено в цпм. Позднее в мсдос. Питер Нортон в 80-х, писал, что если бы все программы бы на пц, взаимодействовали с экраном, клавиатурой и мышью через, хотя бы вызовы bios пц, то, проблем с совместимостью бы было мало. Идеально - их бы не было вообще. Но, как в случае с цпм, так и в случае с мсдос программисты обращались напрямую к "железу" компа. ОС служила лишь, как прослойка, для доступа к файлам, не более того. В рамках спектрума, в принципе, нам этого и достаточно, но проблема в том, что пресловутой "ОС" так и нет..... Есть программно-аппаратные эмуляторы существующих систем и не более того..
---------- Post added at 02:47 ---------- Previous post was at 02:40 ----------
А если идея состоит в поддержке (читай в загружаемости и исполнении) ранее созданных программ, то я свои идеи излагал ещё в 1998г. Западные товарищи предложили ещё один вариант - винтовый вариант +3 плюс к нему программно-аппаратное решение DevIDE. Т.е. в рамках нативного доступа к винту мы имеем доступ к ленточнуму софту(конечно только к тому который обращается для загрузки к процедурам ПЗУ). Но и это, согласитесь не решение! Софт трдос я вообще не знаю как классифицировать...
---------- Post added at 02:55 ---------- Previous post was at 02:47 ----------
В MP/M ещё был применён механизм вытеснения, то что ты описываешь может "кооперация"? А при вытеснении мы имеем хоть сколько задач. Каждой дается максимальный квант времени, после чего она прервется. Управление передастся следующей в списке задаче (по приоритету), насколько я знаю, что даже в W95, диспетчер задач вызывался не ранее чем 1/50c.
Скрытый текст
Profi 5.06 1024K 12Mhz (кварц на 24), палитра, COM-порт, часы, hdd, covox, программатор
ZX-Spectrum +3, ZX-Spectrum +2B, ZX-Spectrum +2, ZX Spectrum 48, ZX Spectrum 48+
ZX Evolution Rev B.
Color 48 + Beta Disk Interface +FDD+YM2149F
Орель-08БК
Pentagon-48 (недоссобранный кем-то)
Pentagon-128 (полуубитый)
Кворум-128 (в ремонте)
Магик-05 (в ремонте)
Robotron 1715
Корвет ПК8020 и ПК8010
Amstrad CPC 464
Amstrad CPC 6128[свернуть]
Как только речь заходит об осестроении, начинают собираться всё одни и те же)))))))))))))) так, в скором времени и объединимся.
Не-не, я имел в виду "наше классическое" ZX-вытеснение, например MythOS.
Чтобы тут не возникло ненужных постов с уточнением терминов, скажу, что проги пишутся и потом работают только в окне 49192-65535 (последняя 16к банка) и путем переключателя, находящегося в оперативке "ниже", эти банки меняются с частотой, которую настроит осестроитель или юзер (это мелочи, просто два байтика менять). МифОС четко предупреждает при старте, мол, ребята, на Спеке128 тока 3 проги, по числу свободных банок. Теоретически эту память можно систематизировать и поместить туда даже указатель стека, тогда особые проблемы отпадут. Кое-что из общесистемных, либо буфер обмена можно хранить "внизу". Особых заморочек нет, кроме:
* объем проги всего 16к
* трудности использования доп.памяти (хоть нижнюю забирай)
* придется отслеживать ситуевину, когда обе проги запросили дать оперативки или запросили чтение/запись диска.
* если не использовать регулируемую очередь, то вся работа - это постоянное переключение страниц.
Под кооперативной я понимал простейший, тоже можно сказать, классический для бутов движок. Диспетчер "висит" на прерываниях и поочередно запускает проги + играет музычка. Вероятно здесь придется меньше переключать страницы. Но все, в конечном счете зависит от осеписателя. Вот я думал так, а начал делать приложение и вышло хрен знает как. Но лучше обломиться, чем с пеной у рта доказывать, что, например, такая-то ось должна писаться так, а не по другому
зы:
Думаю, что у меня уже не хватит времени да и знаний тоже, чтобы сделать образец диспетчера (на работе много дел и проектов с отчетами), так что время от времени вечерами сижу, набирая текст документации и примеров, которые выложу на отдельный сайт. Может быть кто-нить и возьмется за кодинг или найдет там интересные решения. А, может, у меня появится реальник и дела пойдут в гору.
Spectrum Basic
http://www.worldofspectrum.org/forum...t=32785&page=6
кто-то что-то пишет, мне правда еще не совсем понятно, мож боян ваще
Надо взять свою железку, сдуть пыль, подключить винт и поэксперементировать )))...
Нет, только один. Многотекстовость никто не просил.
По теме: для истинной многозадачности надо как минимум два окна памяти (программы/стек и их данные). Но при этом будет ограничен размер кода на задачу. Про ограничение на размер стека даже молчу. Для сравнения, в UNIX на PDP-11 было 8 окон, которые делились на код, данные, стек и системные вызовы.
Если пытаться грузить код в нижнюю память, то после нескольких запусков-закрытий программ она превратится в решето, куда уже ничего не влезет.
Короче, если окно одно, то придётся писать с чудовищными ограничениями (например, делить программу на куски по 256 байт и писать данные в стек по 4 байта за раз, т.е. с типом). Или делать Forth-систему.
Только ATM Turbo 2 и ZX Evolution имеют по 4 окна, а NeoGS и Pentagon 1024SL 2.2 с одной из тестовых прошивок - по 2. Впрочем, в NeoGS можно в процессе загрузки системы сменить прошивку на более умную (уже есть прошивка с 4 окнами). Например, она может ловить сегментные префиксы типа ld a,a и включать заданную страницу на время одной команды. Тогда можно хранить данные страницами по 64К даже без дополнительного окна. Правда, для этого нужная страница данных должна быть в физической памяти, а не в свопе - за этим должна следить как процедура задания номера сегмента, так и шедулер.
---------- Post added at 12:43 ---------- Previous post was at 12:32 ----------
ZXUnRar после полного переписывания кода (изначально это была ручная компиляция с С команда в команду) удалось ускорить в 11 раз. Jpeg viewer - в 3.5 раза. Разница в проценты бывает только на процессорах с кэшами и конвейерами, с которыми только компилятор умеет грамотно обращаться.
Последний раз редактировалось alone; 11.06.2013 в 14:31.
>для истинной многозадачности надо как минимум два окна памяти
Да и с одним окном жить можно. Например виртуализуя это окно для процесса, а при переключении задач копируя всю его память из банков в основное адресное пространство. Но разве ж это жизнь?..
>Но при этом будет ограничен размер кода на задачу.
Ну 16кб банки хватить должно на многое, и никто не мешает задаче свитчить банк самой.
>Про ограничение на размер стека даже молчу.
Тут, я думаю, драматизировать не надо, стека нужно скорее всего не так уж много - 6502 же как то жил.
>системные вызовы
Могут идти через RST или вообще напрямую в ПЗУху(которую делать всё равно придётся - не бейсик же оставлять?) а дальше, если вызов в код вне 0000-4000 танцевать с банками. Так же и с библиотеками.
>Или делать Forth-систему.
VM ,конечно, решение, но уж слишком радикальное. Без JIT будет слишком медленной, особенно при работе с памятью.
Мешает то, что стек лежит в основной странице задачи. Если стек размещать в нижней памяти, то получится искусственное ограничение на число задач.
16К - это не так уж много. Писать под ОС будут, естественно, на ЯВУ. А, к примеру, одна только библиотека поддержки FAT32 на C весит 32К. С другой стороны, байт-код оптимальнее по объёму. Вспомним рекордного по размеру Snake на кодах калькулятора. Если взять программы DNA OS, то увидим ряд характерных конструкций:
LD L,(IX+9):LD H,(IX+10)
OR A:SBC HL,DE
LD E,(HL):INC HL:LD D,(HL):INC HL
LD A,(HL):INC HL:LD H,(HL):LD L,A
В байт-коде это весьма неплохо сожмётся.
Только вот ассемблерные вставки в этом случае не сделать никак.
Самостоятельно следить за размером стека программист не может. Компилятор Аласма, например, складирует туда все программные скобки начиная от INCLUDE и кончая макросами. А когда ещё и обращение к TR-DOS...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
