Просмотр полной версии : Проект ОС
NovaStorm
06.09.2011, 10:31
И да, если я когда-нибудь соберусь что-то подобное делать, то попытаюсь сделать под пень-128. ТЕ часть кода в 128м ПЗУ, возможно TRDOS ПЗУ тоже займу, одна банка, и бетадиск, другие СХД тоже впрочем вполне приемлемы. SD - будущее схд спека.
NovaStorm, вообще на Си.это просто одназначно, частично на асме, но
тогда возникает вопрос, на сколько быстра она будет и сколько займет памяти?
Сколько это все займет вместе с драйверами? что останется приложению?
Мы всегда будем упираться в ограничение памяти на приложение.
Vadim, и сколько мне понадобится время и сил, что бы мой пентагон подошел под "спецЫфикацию"? , мой 48 и +2 ужт точно нет.
О них никто изначально и не говорит. Какой пентагон? Какой +2??? Конечно нет. Я говоря о некой ОСИ представляю новый гипотетический клон, на типа Спринтера, избавленного от недостатков. ОЗУ не менее метра, лучше 4 или 16. На +2 надо игры грузить с кассеты, ну или бетадиск к нему подключить. Какие там ещё ОСи? В 128К можно поместить только ЦПМ (при условии отключения ПЗУ), + ещё свободными останутся 16-32К, какая многозадачность???
Vadim, Т.е делаем нового монстра под новую ось?
Я точно делаю:)
Можно и не делать монстра (пока), а ограничиться новой прошивкой для пентевы.
DimkaM, На чистом асме смотрится просто ужасно.
Это ужос окуда?:)Мои дилетантские попытки юзать FatFs на ПентЕве. Впрочем на 100% удачные попытки, практически всё работает, кроме LFN.
Vadim, ну мне рыпаться поздно :) мой монстер уже оброс 1мб памяти учится работать на 50мц:)
а зачем пентево? Speccy 2010 изначально привлекательней.
---------- Post added at 10:56 ---------- Previous post was at 10:55 ----------
Vadim, а понятне она у тебя есть:)
---------- Post added at 10:56 ---------- Previous post was at 10:56 ----------
с фатом уж точно там все впорядке:)
Макроассемблер конечно лучше голого кода, а для ОС писать скорее всего нужно будет вообще на Си.Тогда вообще проблем с АПИ не вижу, ни для издоси, ни для симбоси.
DimkaM, проблема токо в ттх железяки где это запуститься:)
DimkaM, проблема токо в ттх железяки где это запуститься:)Если ты про производительность, то согласен. Хотя ИАР вполне так ничего компилит. По сравнению с z88dk код получается в 1.5раза компактней и красивей в 1килораз.
---------- Post added at 11:16 ---------- Previous post was at 11:04 ----------
А отношение такое, что софт спектрума будет запускаться, с любых носителей. С переключением может даже нескольких программ. На обычных профях и недоэвах это невозможно.Ну да.
Это ты Savelij'ю расскажи. Он уже, между прочим, ProfROM от скорпа к Еве прикрутил. Глядишь скоро и до MagOS дело дойдёт.
На Скорпионе всё это реализовано ещё в 90х.
DimkaM, Сие многие подмечали, поставил 1.33а сравню с ZDS
alone, и? написать то сам знаешь не проблема, кому оно зачем оно?
Действительно, 240 сообщений флуда в уютненьком - это полезно, а написать тому, кто ждёт, чтобы ему написали - это "зачем?".
деньги кстати за день работы не смешные, смешон мотив.
Написать аналог MenuetOS за день работы?
---------- Post added at 13:12 ---------- Previous post was at 13:08 ----------
что там писать этому автору? только если поздравления что на амстрадах и мсх робит его ось? система закрытая. исходников нет, автор под дулом пистолета их никому не даёт, даже глазком посмотреть.
А они тебе, извиняюсь, зачем? Я вон сколько своих исходников выложил, ты использовал? Для того, чтобы писать программы под ось, исходники оси не нужны.
---------- Post added at 13:15 ---------- Previous post was at 13:13 ----------
смотрим и видим - gs, ngs, tsfm, 1M, 512kb... что из указанного является исключительно железом недоэвы (пентэво)?
Факты показывают, что под железо NedoPC пишут софт. Или, если вам угодно, новый софт с наворотами работает на железе NedoPC.
За отмотку треда с тебя стандартная такса - $30.
На Скорпионе всё это реализовано ещё в 90х.
MagOS это как бы не то совсем. Выхов по NMI ПЗУ в которой сдит определнная программа сделать несложно, но NMI не даёт 100%-й надёжности. Стек сидит гшде нить в экране или в ПЗУ в момент прихода NMI и всё, приехали. МагОС это переключалка содержимого ОЗУ по требованию, и уж никак не ОСь.
Vadim, а понятне она у тебя есть
Да, и экспериментировать есть на чем.
alone, Что ты за какой день
это оплата в день программера не плохого. Да ну бред это все, ттх и то согласовать не могут хоть вроде приняли, что к большинству клонов сие не применимо.
И нужен некий гипотетический новый клон:)
Я бы добавил, что еще и с прошивкой евы играются фички добавляют.
На вопрос
Зачем оно нужно если- ни какой пользы кроме самоутверждения и опыта ?
Игры писать демы -ну бросте их и так напишут.
У совьетского клона нету сетки, нету мало мальских этих ваших интернетиков,
да и с ним он бесполезен по сути, кроме развлекалово.
Даже те кто за ось, кто в лес кто по дрова и между собой договориться не могут. В качестве теоретической темы, если выкинуть флуд тема была бы полезна.
И нужен некий гипотетический новый клон
Да новый клон не нужен! Автор SymbOS написал требования к компу, и ATM им вполне удовлетворяет. Если учесть, что их на руках больше 200 штук плюс 100 потенциально совместимых (Pentagon 2.666, Speccy2010), то тут даже думать не надо над новым железом.
alone, ммм, тогда эту ветку нужно просто закрыть или перенести, в раздел атм и ос для атм? как владельцу, класики пентагона ,ленина 1,48,+2, это сугубо не интересно. Над железом как раз думать и надо упорно и долго, что бы потом вопросов меньше было. Ваши 300 спартанцев, все одно требуют доработок так или иначе, это весчь сама в себе и этого уже не поправишь.
Я какбэ вообще не понимаю, что такое ПЗУ с граф.интерфейсом. Интерфейс к чему? К бейсику что-ли? Нет ни ОСи ничего, зачем интерфейс? Если интересует многозадачность - надо читать про MP/M, изучать исходники. Делать порт, или как вот у меня в мечтах - сделать новую версию своей ОС, добавив многозадачность. И когда это будет, тогда можно будет делать GUI. А так, без ОСи получится boot в ПЗУ, понимающий мышь. Зачем оно надо?
Ясно. Пример с ПЦ понятен, но ведь там в ПЗУ сидит setup для настройки параметров BIOS (ну EFI сейчас, хотя внешне отличий не видно). Оно нам надо? Надо. Но не обязательно графическое. Я уже давным давно думаю, декомпилить ПЗУ тестов Профи, выкинуть оттуда ненужное и добавить setup. Кроме того, заюзать ПЗУ бейсика 128, разместив в нем БИОС. Но я никоим образом не думал делать в ПЗУ GUI. Зачем? К чему? В ПЗУ должен быть базовый софт, тот который написан раз и надолго. Конечно, и api GUI можно в нём разместить, но пока я не вижу в этом смысла. Тем более что пока нет для этого и возможности. Нет у нас нормального rom-paging. Во всяком случае я этого не знаю. Переключается пзу средствами спектрум портов. Т.е. выход в trdos - перехват управления, basic48/128 битом в 7FFD, остальное кто в лес кто по дрова. Нужна нормальная, не кривая поддержка страниц ПЗУ, что бы в любой момент можно было бы подключить любую страницу. А для GUI надо вообще делать так, что бы или 2 окна по 16К подключать или окно 16К делать пополам и подключать туда разные страницы по желанию. В обычных 16К мало что хорошего поместится.
NovaStorm
07.09.2011, 11:45
А как обычно подключается 4я банка в 64кб ПЗУхах?
Да и 16+16(128+tr) это уже достаточно для BIOS. Остальное уже в оперативке можно держать.
>или окно 16К делать пополам
На спеке хоть размер окна был стандартным в 16к, не надо портить хоть что-то общее =)
На спеке хоть размер окна был стандартным в 16к, не надо портить хоть что-то общее =)
Вообще, окно для подключения ПЗУ - да, 16К, но были внешние устройства для спектрума, которые его использовали по своему. Например интерфейс Disciple и +D, DevIDE наконец. А насчет 4-й банки я точно сказать не могу. В профи туда выход только аппаратно, это отслеживается по схеме (хотя изменив немного схему, можно туда и программно залезти, ставить ПЗУ бейсик 128 и вызывать trdos, подключится ПЗУ тестов. но в бетадиске изначально, доступ в его ПЗУ только если включено ПЗУ бейсик48). В Пентагоне изначально - никак. В скорпионе по reset/nmi и вроде программно можно, про остальные не скажу.:confused:
Надо менять схему компов, для еще не написаной ОС и даже ни как не выработаной концепции.
достаточно для BIOS. Все пипец.
Залог успеха это простота. с DivIDE ничего изменть не надо, есть проблема с совместимости с GS, но ее можно решить как говорит VELESOFT..
лично я уже давно и неоднократно писал про концепции и всё такое..перечитайте внимательно - решение у вас под носом, вы сами его в мусорку толкаете. никто и никогда для вас не создаст систему с новыми прикалюхами и при этом будет совместимой с трдос. это не возможно. в DivIDE нет никаких осей, есть набор эмуляторов и перехватчиков. для каждой манипуляции тыкать сидеть на магик ради резидоса, фатваре и чё там ещё у них... я даже не знаю как оно работает на наших клонах и сюдя по логам на сайте велесофта, с трд и некоторым нашим корявым софтом там проблем немерянно. и кстати вадим тоже много много раз уже писал про варианты..кароче уже всё давно было сказано...
...которая без "глюков" будет поддерживать существующее программное обеспечение...
Зачем делать поддержку tr-dos? Надо ОС запустить, кликнул boot hdd, и работаешь в удобном gui окружении (мечты :-)). Захотелось в чёрного ворона побегать, перезагрузился, вставил дискету, клик по tr-dos.
которая без "глюков" будет поддерживать существующее программное обеспечение и тем более игры хватит:) может?
Totem, если тебе нужна такая пзу, то она уже как бэ есть - gluk и ne gluk...
Sayman,
в DivIDE нет никаких осей, есть набор эмуляторов и перехватчиков.
ух ты ! гыгы
http://zx.pk.ru/showpost.php?p=376138&postcount=113
Если там нет ОС которую хочешь ты- напиши.
войти 1 раз и работать в нужной оси гораздо просче, чем переделывать туеву хучу компов.
---------- Post added at 16:47 ---------- Previous post was at 16:39 ----------
Sayman, Лично мне нет
Ты собери свои посты, о реализации вкучу и приклейте сверху.
в бардаке этой ветки черт ногу сломит
Научитесь наконец планировать
Totem, всего лишь пару страниц назад была речь про варианты реальные, работающие на z80. Но я могу повторить:
- cpm
- mpm
- uzi(x)
Либо их аналоги и "клоны". В чём проблема? Старые системы? Юзикс так вообще написан так, что почти все вызовы bsd4.2 совместимы с оригиналом. Даже библиотека ncurses есть (слегка обрезана правда). Есть желание создать велосипед и засунуть его в пзу - вперёд. У меня есть профи и спринтер. Я какбы не обделён. Есть планы и они потихоньку делаюца. И обсуждать их тут я не буду.
Alex Clap
14.09.2011, 20:36
Насчет GUI
http://www.youtube.com/watch?v=uEaTiVDaU2E&feature=player_embedded
Alex Clap
22.09.2011, 15:22
Кстати что с DOORS/AQUA?
NEO SPECTRUMAN
14.10.2011, 18:44
ПЗУ с поддержкой графического интерфейса
http://forum.vrcp.ru/viewtopic.php?f=14&t=33
похожего на "MenuetOS", "KolibriOS"
Правда оно не сильно похожее на "MenuetOS", "KolibriOS".
Повторно предлагаю:
С 01.01.2012, тому, кто разработает ПЗУ с поддержкой графического интерфейса, похожего на "MenuetOS", "KolibriOS" Каким образом это затолкать в 16кб или даже в 32кб имеющиеся на спеке? Если имеется ввиду только графический интерфейс, то у Vitamin'а на сайте лежат исходники превосходного оконного интерфейса.
Можно открывать голосование кому отдавать тыщу Vitamin'у или NEO SPECTRUMAN'у. Пересылка как обычно за твой счёт?!
тому, кто разработает ПЗУ...
...разработка операционной системы, с поддержкой FAT, и прочего, что есть в современном мире.
Один только фат(с драйверами ZSD,NEMO и RTC) съедает 15.5кб.
Куда пихать пихать всё остальное?
Твоё техзадание изначально не выполнимо.
Да и тех.задания невидно, что значит - "ПЗУ с поддержкой графического интерфейсам". Файл-коммандер чтоли?
NEO SPECTRUMAN
15.10.2011, 12:57
Один только фат(с драйверами ZSD,NEMO и RTC) съедает 15.5кб.
Куда пихать пихать всё остальное?
А остальное грузить в оперативку как раз с ФАТавскеих устройств. А ПЗУшку превратить в Биос с набором драйверов.
Файл-коммандер чтоли?
Видимо ему нужен именно Виндаподобный файл командер.
Каким образом это затолкать в 16кб или даже в 32кб имеющиеся на спеке?
Напомню, что myth - history of the making собрана именно в 48 кб, а там обработать надо ого-го сколько. И ещё были замечательные panzadrome, dan-dare, ikari warriors и т.д.
Ищущий находит, сомневающийся - нет.
---------- Post added at 21:20 ---------- Previous post was at 20:30 ----------
2 ZX-fanat> присоединяюсь к твоей копилке оплатой в размере 5000 руб. Предлагаю сформировать ТТХ. Для этого предлагаю отдельную тему.
Всем остальным (=спорящим, сомневающимся, ищущим) просьба посмотреть следующие темы:
- http://zx.pk.ru/showthread.php?t=546
- http://zx.pk.ru/showthread.php?t=312
- http://zx.pk.ru/showthread.php?t=525
- http://zx.pk.ru/showthread.php?t=507
- http://zx.pk.ru/showthread.php?t=759
- http://zx.pk.ru/showthread.php?t=568
- http://zx.pk.ru/showthread.php?t=610
- http://zx.pk.ru/showthread.php?t=578
- http://zx.pk.ru/showthread.php?t=4420
- http://zx.pk.ru/showthread.php?t=3973
- http://zx.pk.ru/showthread.php?t=3925
- http://zx.pk.ru/showthread.php?t=1811
- http://zx.pk.ru/showthread.php?t=1952
Читайте их внимательно, много из того, о чём тут есть посты было не раз обсуждено.
Радует отсуствие флуда и флейма, но не радует отсуствие реакции... Т.е. конструктивно работать никто не готов?
NovaStorm
26.10.2011, 15:57
>никто не готов?
Пока нет. Тем более не ясна даже платформа. А менеджеры памяти 128к и эвы, сам понимаешь, кардинально отличаются возможностями.
Надо сделать примерный фичлист и по нему уже обсуждать.
---------- Post added at 15:57 ---------- Previous post was at 15:46 ----------
+ К списку тем надо бы добавить Таненбаума =)
Читаю читаю, так и не пойму что ты хочешь... Выше тебе правильно сказали, т.з. на это дело надо а не так что "а давайте сделаем ось в ПЗУ с оконным интерфейсом" -
это ваще непонятная абстракция...
я вот считаю что сейчас максимум что надо это bios для работы с устройствами в рамках zx-evo... с переменными окружения, чтоб например запуская игру программер не думал откуда она загрузилась, а вызывал скажем чтение файла по имени через bios а он(bios) сам грузил откуда было запущено и т.п.
2psb> удалил твои сообщения, т.к. смысла в них не вижу. От тебя идёт только предложение ничего не делать, я с такой позицией не согласен. Если хочешь просто пообщаться - либо используй личку/флейм/почту/аську/скайп/итд, либо пиши в других форумах, где модераторы мягче.
2all> все предложения категорий "нафиг надо" буду безжалостно резать. Не нравится - не пишите.
---------- Post added at 18:02 ---------- Previous post was at 18:01 ----------
Читаю читаю, так и не пойму что ты хочешь... Выше тебе правильно сказали, т.з. на это дело надо а не так что "а давайте сделаем ось в ПЗУ с оконным интерфейсом" -
это ваще непонятная абстракция...
я вот считаю что сейчас максимум что надо это bios для работы с устройствами в рамках zx-evo... с переменными окружения, чтоб например запуская игру программер не думал откуда она загрузилась, а вызывал скажем чтение файла по имени через bios а он(bios) сам грузил откуда было запущено и т.п.
Пусть любой, кто хочет поучаствовать в проекте выдаст своё видение реализации, сейчас есть полная свобода в выборе средств.
---------- Post added at 18:04 ---------- Previous post was at 18:02 ----------
>никто не готов?
Пока нет. Тем более не ясна даже платформа. А менеджеры памяти 128к и эвы, сам понимаешь, кардинально отличаются возможностями.
Надо сделать примерный фичлист и по нему уже обсуждать.
Сделай, ещё раз повторюсь - сейчас тебя никто не ограничивает.
по сабжу. несколько раз говорил я, вадим, да и вон тмк тоже верно утверждает - в пзу гуя нетребуются, требуются необходимые базовые функции - читать биос. а собственно ОС это уже другое дело. так всё таки, где ТЗ? zxfanat, тебе что, просто гуя в пзу нужна или всётаки вменяемая ось? определись уже. биос и операционная система это разные вещи...что точнее тебе хочется?
NovaStorm
31.10.2011, 11:17
Ну ёпрст, "ПЗУ с поддержкой графического интерфейса" УЖЕ есть, ибо текста на спеке же нетути. =)
NovaStorm
31.10.2011, 13:31
Ну стандартный бейсик же. Твоим требованиям удовлетворяет. Так что уточняй ТЗ.
NovaStorm
31.10.2011, 15:01
>>как, через 48-й BASIC, будут вызываться определенные программные процедуры
call #xxxx
>>FDD, HDD, дополнительным экранам?
Вооот! К чему ещё? Какой уровень абстракции(и над какими устройствами) нужен от биоса(нужен ли вообще)?
Можно ли принять, что у нас как минимум 128к? Можно ли тогда предположить, что юзеру надо будет перепрошивать оба 16к банка под нашу ось? Должен ли быть обязательно ТРДОС? Можно ли тогда использовать и его банк? (Про ПЗУхи возможность и готовность пользователей реалов их прошить мне действительно важна, чтобы составить хоть какое-то мнение, как может выглядеть ОС)
Моё видение начала разработки ОС - это ПЗУ, содержащее набор функций для работы со современным (но учитывающее и скромные возможности младших братьев) железом. Т.е. винт, карты памяти, флоп, звук и т.д. Предлагайте что можете. Все расширения этой ОСИ идут через драйверы, который могут быть дополнительно подгружены с внешних носителей. Т.е. фактически это ядро + некоторые функции ввода/вывода.
Ещё раз предупреждаю, бред и болтовню буду резать.
Моё видение начала разработки ОС - это ПЗУ, содержащее набор функций для работы со современным (но учитывающее и скромные возможности младших братьев) железом. Т.е. винт, карты памяти, флоп, звук и т.д. Предлагайте что можете. Все расширения этой ОСИ идут через драйверы, который могут быть дополнительно подгружены с внешних носителей. Т.е. фактически это ядро + некоторые функции ввода/вывода.Может я что-то пропустил, но по моему такой вариант ОС под названием NeOS уже пытались создать и довольно много чего уже наделали:
NeOS версия 1.0:
http://opensourcezx.untergrund.net/files/neos/neos10.zip
Мне кажется, что ПЗУ ATM Turbo+ более логично использовать, в части его интерфейса и размещения меню этого ПЗУ. Кроме того, в самом ПЗУ уже есть часть функций, которые можно применять в других ZX. Принцип, как в других компьютерах: есть аппаратная часть, определяется, нет аппаратной части, не определяется. Но с небольшим уточнением. Часть функций, (по возможности), использовать из ПЗУ Scorpion ZS256,таких как создание разделов HDD, обращение к "внутреннему" RAM-диску. Наверно для начала это много. Мое мнение, что надо делать первый, пусть даже "сырой" образ прошивки ПЗУ, в котором, (СНАЧАЛА и ВПЕРВЫЕ), сделать определение "железа" ZX. Даже если "железо" не может определиться, сделать ото на уровне определения FDD, HDD, RAM. Для начала, думаю достаточно сделать эти функции, потом перейти на разработку, то есть дополнение создания разделов HDD, но именно тот, который заложен в Scorpion ZS256.
Сразу хочется ответить. Мне кажется идея абсурдной. Нет, конечно её можно пытаться реализовать и положить много времени и сил на это, но результат будет мизерный и никчемный. Спрашиваю в 15-й раз, зачем всё это в ПЗУ??? Даже во флэш. Какие создания разделов на винте? Во всех нормальных ОС это делает внешняя утилита. Т.к. требуется эта операция очень редко. Зачем интерфейс для работы с графикой в ПЗУ? Ну для чего? Нет видимости того, что действительно нужно. Нужны драйверы (простейшие) для всех имеющихся устройств на текущий момент. Что бы драйвер выполнял все возможные функции, что бы не было необходимости работать без него. А в ОС уже будут низкоуровневые драйверы (драйверы логических устройств) которые будут использовать функционал драйверов в ПЗУ. В ПЗУ кроме драйверов (вернее rom-bios) будет ессно располагаться процедура инициализации и тестирования оборудования и процедура начальной загрузки. А т.к. у нас спектрум, то оканчивается всё "ветвлителем". Программкой которая переводит в той или иной режим работы или загружает ОС с внешнего носителя и передаёт ей управление.
Мной рассматривается вариант портирования Q-DOS на другие платформы. Так вот, для реализации этой идеи не нужны никакие форматилки в ПЗУ, не нужны окошки сделанные там же. А нужно другое, гораздо более важное. А именно: система управления памятью, что бы мы (и ОС) видела набор логических страниц, что бы не задумывались какие порты и как использовать. Нам нужен символьный ввод вывод, драйверы дискеты, винта (или карты памяти). Имея такой функционал - не проблема запустить ОСь, которая пускает софт cp/m, видит винт с FAT, и уже под ней пишите графические среды (одна уже кстати есть), а под графические среды делайте софт. Все моменты касаемо различия платформ я уже продумал и в будущем реализую. Система будет работать на ZX-Evo, ATM (новом) и Профи.
---------- Post added at 13:59 ---------- Previous post was at 13:55 ----------
В моем понимании, экран пора делать на ВСЮ область экрана, которую занимает и "BORDER". А сам экран ZX уместить в этом экране.
И как это связано с поддержкой графики в ПЗУ? Это собственно изменение схемы компа, создание нового видеоконтроллера. С ПЗУ и биос это связано мало.
Это собственно изменение схемы компаКак минимум нужно отключаемое пзу.
Спрашиваю в 15-й раз, зачем всё это в ПЗУ??? +1
В пзу достаточно хранить только редактор цмос и загрузчик ОСи. Это можно слепить в кратчайшие сроки.
Присоединяюсь! Дайте мне полномочия модератора, и вы увидите, что в теме останется только то, что относится к теме: "Проект ОС".Коммерческие предложения перенеси плиз в барахолку. Лично я немогу увязать Спек и коммерцию.
Валера, предлагаю за основу взять ПЗУ ATM Turbo+
честно говоря архитектура ATM турбо - это кошмар, ну кто додумался использовать адресные линии как данные? :v2_dizzy_facepalm:
Может я что-то пропустил, но по моему такой вариант ОС под названием NeOS уже пытались создать и довольно много чего уже наделали:
NeOS версия 1.0:
http://opensourcezx.untergrund.net/f...eos/neos10.zip
Камиль, а где можно её описание от автора посмотреть?
---------- Post added at 09:50 ---------- Previous post was at 09:42 ----------
+1
В пзу достаточно хранить только редактор цмос и загрузчик ОСи. Это можно слепить в кратчайшие сроки.
Не согласен с таким подходом. Слепить - это про продукты от MS. Вот и рождаются монструозные инсталляторы драйвера флешки на 16 мегабайт - абсурд.
Хочу напомнить, что в 1981 году, когда писался код ПЗУ SOS, тогда не было мегакомпиляторов и удобных эмуляторов не было, всё тестировалось на живом железе со всеми ошибками и т.п., и всё равно ЭТО было положено в 16К. Ничего мешающего создать ядро, определяющее все компоненты железа спекка и предоставляющее удобную работу пользовательским приложениям - не вижу.
---------- Post added at 09:55 ---------- Previous post was at 09:50 ----------
Коммерческие предложения перенеси плиз в барахолку. Лично я немогу увязать Спек и коммерцию.
Это не коммерция. Коммерция - это извлечение прибыли, никакого извлечения прибыли ни я ни ZX-Fanat из этого не получаем. Это скорее дотация или стимулирование.
Камиль, а где можно её описание от автора посмотреть?
А скачать и посмотреть что в архиве не судьба? Там понаписано от авторов чуть ли не больше чем в этой теме.
Не согласен с таким подходом. Слепить - это про продукты от MS. Вот и рождаются монструозные инсталляторы драйвера флешки на 16 мегабайт - абсурд.
Хочу напомнить, что в 1981 году, когда писался код ПЗУ SOS, тогда не было мегакомпиляторов и удобных эмуляторов не было, всё тестировалось на живом железе со всеми ошибками и т.п., и всё равно ЭТО было положено в 16К. Ничего мешающего создать ядро, определяющее все компоненты железа спекка и предоставляющее удобную работу пользовательским приложениям - не вижу.
Судя по вашим хотелкам это и есть абсурд и должно вылится в некий монтруозный инсталятор или очень толстое пзу от 512к и выше по объему.
И не надо ничего напоминать, раньше не было а сейчас есть и отладчики и всяческие компиляторы. Или по твоему программирование должно производиться в генсе? Или сразу в хекс кодах? Так при таком подходе вы вообще не то что ось не напишите, но так и останетесь на уровне флуда который сами же и будете вырезать. Теме 6 лет, а "воз и ныне там"
Потом уже применять кодовую часть, привязывать к адресным линиям ZX (для начала для: Leningrad, Pentagon-128, далее по нарастающей).Это предложение ни капли не понял.
оболочку самого ПЗУ, его меню, (то есть, как некое визуальный образ, может считать и как устройство) и дополнительно применить часть меню Scorpion ZS256.Оказывается нужна не ОСь, а всего лишь некий оконный коммандер аля ЕвоРесетСервисРОМ/ПрофПЗУ/ и т.п.
И чем не нравится держать эту ОСь в ОЗУ, а не в ПЗУ?!
Плюс ОЗУ: переменные и код лежат в одной банке, обновление ядра без программатора.
Он просто создал ZX OS, при том создал ее без помощи извне.
Во первых создал не он, а фирма (как там? забыл название (Nine Tiles?)), а во вторых был создан интерпретатор бейсика, как в большинстве домашних компьютеров того времени. Ну уж никак не ОС. От Оси, в бейсик лишь несколько функций на уровне пользователя - считать файл, записать файл, запустить программу. Всё.
На данном то этапе существует предложение сделать тоже самое, но с учетом современных условий, с учетом современного компьютерного оборудования, которое способно работать на ZX!
На данном этапе понятно, что надо делать то, что я написал выше. И делается это не под классический спектрум, а под машинки типа профи или атм. Т.е. есть возможность отключения ПЗУ, экран убирается из прямого адресного пространства в другие сегменты. Имеем маппер памяти, с окнами проецирования. Когда вот это есть, тогда можно уже думать об осях и об ПЗУ. Но под каждый клон будет свой вариант bios который будет поддерживать своё железо.
Действительно нужно разрабатывать операционную систему, в формате прошивки ПЗУ,
Извини, но это бред сивой кобылы. Какая ОСь в ПЗУ? Это нонсенс! Зачем? В ПЗУ располагают самые важные и основополагающие вещи. В бытовых ПЭВМ начала 80-х там был бейсик. Почему? Да потому, что они не имели дисковода, а работать как-то надо было, грузить его с кассеты каждый раз было очень и очень неудобно. Вот и разместили его в ПЗУ. Бейсик имеет некоторые функции, которые выполняет ОСь, но он осью никоим образом не является и не являлся! Пора бы это уяснить!
ZXFanat, я понимаю, что тебе нужны процедуры работы с графикой в ПЗУ. Зачем? Нет, их можно сделать, наравне с bios (который гораздо важнее), но зачем? А если после написания через год-два выяснится, что надо было писать не так? Да и вообще, зачем их располагать в ПЗУ? Зачем? Если у нас есть дискеты, винты, карты памяти? Не лучше ли их грузить при старте машины в ОЗУ и использовать? В чем идеология твоя? Что ты предлагаешь? Я просто не понимаю, не вижу никакого смысла. И все, кто тут присутствуют тебе это пытаются объяснить.[COLOR="Silver"]
просьба для Димы принять участиеТы на форуме общаешься а не в личке, юзай ники, а то слишком много на себя береш.
в части его разработки, связанной с FDD. И посылать никто никого не будет. Но не отдельной разработки, а включения ее части в ПЗУ, а части как подгружаемого модуля (драйвера)
, причем тут электроника контролера дисковода к прошивке пзу, ты хоть пойми о чем речь идет, а потом указывай что и кому делать.
ZXFanat, зачем изобретать велосипед? NeOS во многом удовлетворяет твоим требованиям, также и расположением в ПЗУ. Под неё можно написать оболочку с GUI интерфейсом, но вряд ли она увидит свет.:(
http://speccy.info:8080/NeOS
impressed
25.12.2011, 13:29
Еле-еле осилил ветку.
Но после прочтения, сложилось мнение,что все чего-то хотят и и кто не знает чего именно.
Мое видение архитектуры, таково:
1. BIOS -- содержит базовый набор процедур необходимых для начального запуска машины:
A.Утилиту настройки параметров оборудования ( при это абсолютно не важно где будет храниться инфа о конфигурации машины в NVRAM или например в инженерном цилиндре на диске или дискете).
B. Процедуру POST ( Power-On Self Test) для тестирования имеющегося оборудования.
C. Базовый(!!) набор вызовов по работе с оборудованием машины ( терминальный ввод/вывод, дисковые накопители, управление менеджером памяти на машинах с объемом RAM > 48k, видео сервис ( аналог писюкового int 10h))
D. Процедуру начальной загрузки машины ( аналог int 19h с фиксированной точкой входа)
E. По желанию стартовые меню, для тех кто без них жить не может.
F. Совсем забыл про системный таймер ( сервис времени, sysuptime), работающий как с RTC, так и счетчик инкрементирующийся например раз в секунду (похоже на UnixTime ( количество секунд прошедших с 1-го января 6.00 утра 1970 года)). Сервис должен обеспечивать как получение текущей даты/времени/системного uptime так и его установку.
При всем при этом, нет необходимости держать в ROM универсальный BIOS который бы подходил ко всем машинам сразу, даже на PC такого нет, т.к для каждой модели мат.платы делают свою версию BIOS. Тут уж пусть каждый под себя собирает из исходников BIOS или например скачивает уже готовый для своего типа машины.
BIOS также будет являться HAL (Hardware Abstraction Layer) для самой ОС, чтобы не обременять ОС лишним для нее функционалом, кроме того такой подход предоставляет единое низкоуровневое API для работы с оборудованием, что должно облегчить перенос программ с одного клона на другой и портирование нового софта на ZX.
Это пока по BIOS по самой OS напишу несколько позже, если ни кто не против =)
С Уважением, I'm!Pressed.
impressed
29.12.2011, 19:09
И так продолжение темы про Speccy OS NG =)
Теперь про ОС.
Что из себя представляют современные ОС в минимальном варианте:
1. Ядро системы
2. Набор системных библиотек для приложений ( таких как например libc/GNU Libc в *NIX)
3. Командный интерпретатор
4. User-land приложения
Как оно все работает и зачем нужно, я думаю описывать не надо, тут все и так понимают как различные компоненты ОС взаимосвязаны и взаимодействуют между собой.
На мой взгляд, для Speccy наиболее подходит микроядерная архитектура ОС, монолитные, модульные и гибридные схемы тут не к селу ни к городу из-за их запросов по ресурсам.
NovaStorm
30.12.2011, 19:19
На мой взгляд, для Speccy наиболее подходит микроядерная архитектура ОС, монолитные, модульные и гибридные схемы тут не к селу ни к городу из-за их запросов по ресурсам.
#$%!!! Ну при чём тут микроядро? Нахрена оно без MMU и защиты памяти?
:v2_lol: ну вы к 2015 году-то определитесь? :v2_lol:
Нахрена оно без MMU и защиты памяти? Нахрена ММУ и защита памяти?
NovaStorm
31.12.2011, 14:33
Дык одна из основных пальцегнутых фич микроядра это выполнение сервисов в своих, изолированных адресных пространствах, а общение между ними только через сообщения. А на спеке, как ты понимаешь, насрать в чужую память никто не помешает. Из-за чего и идея микро-/экзо- и прочих ядер с сообщениями для спека - оверкилл.
любая ос на наших железках это жесть. в любой цпм или юзиксе или издос или дна и прочих, любая прога может нагадить в систему и грохнуть её. и что теперь? учитесь нормально програмить, чтобы ваша прога не гадила.
NovaStorm, ага понял, это относительно к микрофеням.
NovaStorm
31.12.2011, 19:21
Sayman, конечно можно писать нормально, и всё будет прекрасно работать, речь шла просто о том, что городить неоправданные концепты, не подходящие для нашего железа не стоит. Передача сообщений сожрёт как лишнюю память для реализации и буферов, так и время на переключение контекстов, а преимуществ практически не даст.
Ну и если уж зашла об этом речь, имхо нужен монолит, возможно что и с модулями, но загружаться они уж точно должны внешним кодом.
про какие сообщения идёт речь? тут уже была какая то тема про якобы ос с почтовыми ящиками и горой сообщений. про это чтоли речь? если же смотреть в сторону мпм или юзи то никаких сообщений нет, есть сигналы. системы при этом многопользовательские/многозадачные. работа мпм на z80 давно известна, исходники есть. аналогично и про юзи. велосипед изобретён, в нашем случае, больше 20 лет назад.
NovaStorm
31.12.2011, 22:40
>про какие сообщения идёт речь?
Про эти:
http://ru.wikipedia.org/wiki/Обмен_сообщениями
подозреваю, что текст по ссылке или неверный перевод или вольная трактовка.
читаем лучше это
http://ru.wikipedia.org/wiki/%D1%E8%E3%ED%E0%EB%FB_(UNIX)
NovaStorm
01.01.2012, 13:03
Сигналы тут почти и не причём, с помощью сообщений обмениваются данными, используется для IPC и RPC. Message passing оно на буржуйском.
значит, если быть немного чуть внимательнее, то можно заметить, что Message passing, а точнее Message Passing Interface (MPI) не является неким стандартом дефакто для целого ряда систем, в том числе и для винды и позикса (тот же юникс). каждая система сама идёт по своему пути и использует свою систему "сообщений" везде они именуются по разному но смысл примерно у всех одинаков. будем называть вещи своими именами - для позикса (юникса) это именно сигналы, которые являются частью взаимодействия между процессами (IPC, inter-process communication). если внимательно поизучать исходники той же фриБСД, то кроме сигналов есть ещё сокеты. в винде же есть свой интерфейс - WMI который чуть более широк в применении, чем сигналы и сокеты у юникса. сам же MPI является сторонней разработкой и например для винды существует отдельная реализация.
более детально об этом тут (http://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D 1%81%D1%81%D0%BD%D0%BE%D0%B5_%D0%B2%D0%B7%D0%B0%D0 %B8%D0%BC%D0%BE%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B 2%D0%B8%D0%B5)
касательно применения в спекрумах, то невижу никаких особых проблем в реализации и применении любого из способов. о5-таки - uzix прекрасно работает с сигналами, т.е. часть интерфейса IPC реализована. другое дело что не навсех клонах такое реализуемо. например, на пнях и других 128х моделях видимо ждёт облом. а вот такие модели как профи, атм, недоэва, феникс, спринтер и им подобные, думаю без проблем потянут такое. особенно если турбированные модели.
NovaStorm
01.01.2012, 17:43
>для позикса (юникса) это именно сигналы
Передавать данные через сигналы конечно можно, но не нужно =)
>не навсех клонах такое реализуемо
Почему же? С сигналами как раз проблем я не вижу.
impressed
01.01.2012, 18:10
#$%!!! Ну при чём тут микроядро? Нахрена оно без MMU и защиты памяти?
Все прекрасно будет и без защиты памяти работать. Защита памяти это лишь дополнительная плюшка, облегчающая жизнь программисту, не давая ему заморачиваться на дополнительные примудрости в коде.
Для не веруюших -- Linux работает и на процах без аппаратного MMU. Кто не верит, может почитать исходники. Да, сегодня проц без MMU это архаизм, но бывают моменты, когда оно и не надо вовсе.
В принципе, на клонах с объемом RAM > 128k механизм переключения банков RAM как раз и является тем самым MMU, реализованным вне CPU.
Вижу я все это так:
Нужно уменьшить гранулярность при переключении и отображении банков с 16/64k до 4k. И отображать по 4k в пространство проца. Кажому процессу будет принадлежать свой набор страниц по 4k, и у других процессов не будет доступа к чужой памяти. Чем вам не MMU? Да конечно, это вариант не делит области памяти по уровням доступа и типу содержимого ( код,данные, стек). Но свою работу по изоляции процессов он делает. Или я не прав?
NovaStorm
02.01.2012, 11:43
>Все прекрасно будет и без защиты памяти работать.
С тем, что работать будет, никто не спорит, речь о целесообразности. Представь себе сервис часов, которому будут слаться сообщения о прерываниях, и как будут при этом щелкаться контексты.
>Linux работает и на процах без аппаратного MMU
Ага, работает, пока не вспомним о динамической линковке, нормальном выделении памяти в тч на стеке, форках, свопе... у спека с его одной банкой и то возможностей больше.
>уменьшить гранулярность
И выкинуть Z80 сразу уж, чё ограничиваться мелочами? =)
Можно сделать выделение памяти в банках с возможностью перемещения процессов из банки в банку, чтобы дефрагментировать память и дать процессу максимально возможный объём в 16к.
>Кажому процессу будет принадлежать свой набор страниц
Да конечно, но выделать память процессу придётся в пределах одной страницы в 16к, можно конечно давать доступ и в #8000-#BFFF, но там места мало, процессам там придётся делать какую-то свою переключалку, или пользоваться общесистемным RPC, к чему я пока и склоняюсь.
>Но свою работу по изоляции процессов он делает.
Это при условии использования только системного кода переключения страниц, культура программирования сегодня конечно выше, но кулхацеры с OUT (#FD),A всегда найдутся =)
свопы, форки, часики (и аппаратные и эмуляция) всё прекрасно работает. надоело уже читать всю эту фигню...
NovaStorm
02.01.2012, 12:11
свопы, форки, часики (и аппаратные и эмуляция) всё прекрасно работает
Работает в ucLinux? Может конечно у меня старая инфа, но свопа там по ней нету, а форк только vfork(), от которого даже BSDшники хотели бы избавиться.
impressed
02.01.2012, 13:57
Работает в ucLinux? Может конечно у меня старая инфа, но свопа там по ней нету, а форк только vfork(), от которого даже BSDшники хотели бы избавиться.
Если уж есть target для сборки ARMv11 nommu то чем тут еще можно говорить-то? Я сам системный программер ( да и дровишки под ARM/MIPS для Linux пописываю и сам нет-нет велосипеды изобретаю феерические для запихивания в Embedded серьезных вещей). Есть ARMv7 без MMU и даже без MPU ( memory protection unit) И на них все без проблем пашет, даже не заикаясь о том, что *ВНЕЗАПНО* нужен MMU.
MMU фича для облегчения жизни кодера, чтобы он себе мозг не морочил с организацией страничной адресации и защиты выделенных областей памяти. Если кто помнит, то на x86_32 был такой Big Real Mode ( он же Unreal Mode) в котором память адресовалась одной толстой колбасой в 4 гига без битов защиты и лимитов на секции ( просто одна огромная линейная секция в 4Gb).
Я не предлагаю ломать старые стандарты по доступу к расширенной памяти у спека, я за реализацию нового механизма работы с верхней памятью с постраничным отображением областей в адресное пространство Z80 (4k на страницу оптимальный вариант, как мне кажется) и эмуляцией старых стандартов для Legacy-систем, чтобы те не ломались видя новый механизм. =)
Прошу не обвинять в костылестроении, весь X86 это вообще один большой костыль, где костыль на костыле сидит и костылем погоняет.
NovaStorm
02.01.2012, 14:28
>и эмуляцией старых стандартов для Legacy-систем
У пентэвы, которая и есть наверное самый раскрученный и актуальный стандарт, ведь уже есть 4 банка по 16к, мельчить до 4к наверное уже не стоит. Да и другие машины тоже 16к банками пользуются. Меньшие страницы только в менеджере памяти нужны будут.
Работает в ucLinux?
причём тут ucLinux? сколько раз ещё нужно повторить прежде чем нужный текст будет прочитан?
UZIX implements almost all of the 7th Edition AT&T UNIX
functionality. All file I/O, directories, mountable file systems, user and
group IDs, pipes, and applicable device I/O are supported. Process control
(fork(), execve(), signal(), kill(), pause(), alarm(), and wait()) are
fully supported. The number of processes is limited only by the swap space
available, with a maximum of 31 processes (total of 1024k memory).
даже ncurses и тот портирован...
NovaStorm
02.01.2012, 15:28
>причём тут ucLinux?
При том, что там речь о нём шла.
А uzix... что, просранные исходники второй версии нашлись?
При том, что там речь о нём шла.
про ucLinux речи небыло. изначально речь была несколько о другом, но вы продолжаете мерица размерами отдельно взятых органов.
исходников второй версии нет и не будет. но есть исходники первой версии. чем они не устраивают?
NovaStorm
02.01.2012, 16:24
про ucLinux речи небыло
Linux работает и на процах без аппаратного MMU
чем они не устраивают?
Ну, например, тормозами даже на 20МГц R800. Собрать их sdcc тоже думаю проблематично будет, правда я копался только в сорцах uzi, который был написан на древнем, и даже ещё кажется не ANSI, С.
исходники юзи (как собсвтенно и сам именно uzi) сами по себе не представляют систему, а только лиш ядро и то не полное. при создании юзикса было взято именно ядро юзи и дополнено. юзикс это оконченный продукт готовый к употреблению и исходники компилируемы. есть полный набор исходников не только самой системы и некоторого стандартного софта, но и библиотек. кроме того, написан на ANSI совместимом С. например, юзикс был писан непосредственно на hi-tech c который как раз ansi совестимый. другое дело юзи, само ядро, вот оно было писано на несовсем совместимом Code Works QC. причём такой верси которой в природе же не существует. все стандартные фишки юниксов/линуксов, такие как форк, exec, сигналы, даже файловая система индекс-ориентированная. на мсх2 работает более менее. на мсх2 турбоР, с чипом R800 летает. изучите для начала суть вопроса... спросить можно например у того же error404, если моё мнение не важно.
NovaStorm
02.01.2012, 16:58
>с чипом R800 летает. изучите для начала суть вопроса...
Я пробовал в blueMSX ставить 20МГц R800, тормозил даже вывод в консоль. Может конечно, я её готовить не умею, за реальной MSX только раз сидел.
в blueMSX даже при эмуляции MSX2+ с частотой 10мгц достаточно быстро работает. при эмуляции турбоР на тех же частотах летает. естественно, что я ставил юзикс на винт. с дискеты ясно понятно тормоз...
а вапще ваше дело..продолжайте спорить.
impressed
02.01.2012, 19:14
>и эмуляцией старых стандартов для Legacy-систем
У пентэвы, которая и есть наверное самый раскрученный и актуальный стандарт, ведь уже есть 4 банка по 16к, мельчить до 4к наверное уже не стоит. Да и другие машины тоже 16к банками пользуются. Меньшие страницы только в менеджере памяти нужны будут.
16k многовато, или надо строить дополнительный слой абстракции на уровне самой ОС, т.е городить аллокатор памяти, запоминающий текущее состояние распределения памяти ( в принципе почему бы и нет, не такой уж и плохой вариант кстати).
Был у меня проект, там пришлось несколько модифицировать компилятор C, чтобы тот вместо непосредственного обращения к RAM дергал функцию из самопальной RTL которая и работала с блоками выделенной памяти. В этом случае, максимально адресуемый объем памяти ( под данные, а возможно и под код) ограничивается только полетом фантазии разработчика. Физически, мы работаем с куском памяти 4-16kB отображенным диспетчером памяти в адресное пространство CPU, движение этого окна прозрачно для программы ( в обе стороны, как вверх так и вниз, т.к она использует относительную адресацию в пределах -32768 + 32767 байт от текущей точки исполнения), правда нужно запоминать несколько предыдущих положений окна отображения, но на это я отводил место в системном контексте ( где и сохранял регистры, положение указателя стека и программного счетчика) который обслуживается ядром ОС.
impressed, как примерно выглядел код a[i] и код вызова функции?
impressed
25.02.2014, 21:48
impressed, как примерно выглядел код a[i] и код вызова функции?
надо глянуть в моих архивах...
это был GCC я модифицировал RTL-представление, в той частии где генерируется код для адресации через База[Смещение].
1. Загрузка из памяти в регистр-назначения (mov REG, word ptr VAR[OFFS] в нотации для x86) заменяло на( примерный код, пишу по памяти)
push bx
push si
push ax
mov bx,<segaddr>
mov si,<offset>
mov ax,<val16>
call getData16 ; На выходе в AX наше слово из памяти
mov REG,ax
pop ax
pop si
pop bx
У функции записи слова в память по адресу X сигнатура аналогична только название другое :D
Сами функции я положил в crtbegin.o который GCC при линковке автоматом добавляет в бинарник.
impressed, как примерно выглядел код a[i] и код вызова функции?
Могу сказать что я видел подобную реализацию в Watcom C для модели HUGE, было года 4 назад, я брал openwatcom и генерил в asm простую прогу типа:
int main() {
int i[500000];
for (long j=0; j<500000; j++) {i[j] = 0xff;}
return 0;
}
выяснилось что все указатели компилер держит 32bit-ные и в теории он вообще бы мог адресовать аж 4GB таким способом (физически там будь бы у него EMS до 32Mb мог бы поддержать, а если применить HDD swap!!! :) ) но логика работы с указателями точно как у самого контроллера шины i8086 (т.е. к старшему 16bit слову дописывается справа 4bit-а нулей, полученное число складывается с младшим словом формируя 20bit-ный адрес)
Для Спектрума тормозновато получится. Надо чтобы компилятор находил случаи перебора элементов массива (как?) и генерил что-то вроде INC L:CALL Z,nextseg
Где nextseg делает INC H и по необходимости переключает странички.
impressed
26.02.2014, 18:53
Для Спектрума тормозновато получится. Надо чтобы компилятор находил случаи перебора элементов массива (как?) и генерил что-то вроде INC L:CALL Z,nextseg
Где nextseg делает INC H и по необходимости переключает странички.
C перебором по идее тоже проблем нет. Можно использовать 32-битные смещения, а расчеты возложить на getData. Также можно на стадии работы с AST определять с чем мы имеем дело ( типы токенов хранятся в AST) и если это массив то менять поведение.
alone, ей богу интересовался этим вопросом последние лет 10 (в более широком смысле - как компилировать "современные исходники" рассчитанные на мегабайты памяти для систем с ограниченным в 64кб адресным пространством) и пришел к выводу что есть некие подходы которые впрочем все трудоемкие:
Радикальный (требующий от программиста переписать 32bit исходник): отказаться от идеи работы с 32bit виртуальным пространством и переделать все алгоритмы на работу с куском памяти который гарантированно есть, использовать внешнюю память для временного хранения обработанных данных если они сильно большие. Так работает hitech c в CP/M, результат хороший он в процессе компиляции пишет на диск много временных файлов и может обрабатывать очень длинные исходники. Так работает немецкая MODULA2 для pdp11 систем, которая зная что размер страницы у pdp11 максимум 4kW никогда не дает обьявлять массивы большей длинны и никогда не генерит код более 4kW длинны. Передача параметров между вызовами функций как я понимаю идет тоже блоками с максимальной длинной 4kW. У pdp11 MMU есть 8 окон по 4 kW так что если все алгоритмы подогнать под работу с кусками в 4kW то можно легко довольно использовать все адресуемые 2mW. Обязательно использовать оверлеи суть которых не поменялась со времен первых mainframe-ов IBM у которых тоже было маленькое адресное, т.е. link-ер exe-шника вставляет код диспечера вызовов(этот код естественно может использовать MMU на полную катушку и внешний swap-file) и использует файл-overlay-map который ему показывает на какое место какой obj помещается и кто кого перекрывает в каких адресах\страницах. Все эти оверлейные технологии достигли вершины на pdp11 в тех же 2.9BSD 2.11BSD ну и Демос (среди разработчиков которого считалось что "нормальная" программа должна превышать в 5...6 раз виртуальное адресное пространство pdp11 а иначе это так себе, слабенькая утилитка а не программа).
Традиционный: подключение наружных 32bit risc сопроцессоров (пример - интерфейс TUBE на Acorn BBC model B к которому можно вешать "second processor option"), при этом естественно основной комп используется уже как terminal и I/O co-processor :) или расширение основного процессора другим с большим виртуальным адресом (пример - vax-11/780, appleIIGS, amd64 и т.д.)
---------- Post added at 17:29 ---------- Previous post was at 17:19 ----------
Для Спектрума тормозновато получится. Надо чтобы компилятор находил случаи перебора элементов массива (как?) и генерил что-то вроде INC L:CALL Z,nextseg
Где nextseg делает INC H и по необходимости переключает странички.
Оно и для i8086 у них тормознуто вышло, так как все операции с указателями в модели HUGE требуют пересчета через "целую функцию", для сравнения работа с near указателями это обычные inc, dec, add команды или смещения с иcпользованием index-ных регистров.
shurik-ua
02.07.2014, 05:40
по теме интересное чтиво - http://habrahabr.ru/post/228049/
кто в теме, в чём новизна статьи?
"Диспетчер переключает исполнение с одного потока на другой таким образом, чтобы по возможности все потоки исполнили столько кода, сколько желают"..."Его код исполняется процессором до тех пор, пока поток не перейдет в состояние ожидания, либо пока не произойдет вытеснение, т. е. диспетчер по собственной инициативе не передаст управление другому потоку"
Чего-то он напутал, вроде про кооперативную рассказывает не?
(сорри, поднял древний тред))
либо пока не произойдет вытеснение
Какая же это кооперативная. Вытесняющая.
flydream
27.08.2020, 15:31
Hi, i write here because i don't want to open another topic. I think is possible to port these OSes for ZX:
Fuzix (an Unix for z80) https://hackaday.com/2017/04/16/z80-fuzix-is-like-old-fashioned-unix/
Uzix (a Linux for MSX) http://uzix.sourceforge.net/uzix2.0/index.php?page=scrsht&lang=us
Symbos (for Amstrad CPC, MSX etc.) https://en.wikipedia.org/wiki/SymbOS
Contiki (for Amstrad CPC) http://www.cpcwiki.eu/index.php/Contiki
shurik-ua
27.08.2020, 15:52
as i know the author of SymbOs dont want to share sources of his OS - so porting this OS to ZX is a pretty hard task.
Hi, i write here because i don't want to open another topic. I think is possible to port these OSes for ZX:
Fuzix (an Unix for z80) https://hackaday.com/2017/04/16/z80-fuzix-is-like-old-fashioned-unix/
It already has been ported. Alan mostly targets some not quite a popular (in Russia) architecture things like +3 or DivMMC, but he also has drafts for Scorpion and ZX Evolution.
I ported it to Spectrum-128 and as a toy with two 16K tasks it worked good.
Main thread on FUZIX is here - https://zx-pk.ru/threads/24194-alan-koks-predstavil-unix-podobnuyu-os-fuzix-yadro-kotoroj-potreblyaet-okolo-40-kb-ozu.html
Uzix (a Linux for MSX) http://uzix.sourceforge.net/uzix2.0/index.php?page=scrsht&lang=us
This is not a Linux. Actually, Fuzix was build around Uzix, so it does not seem any reasonable to port Uzix itself.
Error404
29.08.2020, 16:23
Actually, Fuzix was build around Uzix, so it does not seem any reasonable to port Uzix itself.
Actually, Uzix is much much better for understanding and have some key features which Fuzix (as a successor of original simplest Uzi - not Uzix) have not in a 2020 (ex. AFAIK no symlinks in Fuzix and Uzi, but Uzix have, and so on).
Больше проектов хороших и разных, чтоб осей было больше чем софта для каждой из них )
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot