Пишем свою ОС. Практика

[DimkaM]

И на чём её можно поиспользовать, в каких спектрумах она реализована?

[Black_Cat]

И на чём её можно поиспользовать, в каких спектрумах она реализована?

для начала я бы рекомендовал реализовать архитектуру в эмуляторе, т.к. как понимаю это самая удобная среда для отладки, а в конце можно перенести и на клоны с FPGA

[bigral]

У меня сейчас возникла необходимость в "длинных"(между страницами) переходах. Может у кого уже есть концепция-алгоритм как это организовать. И как передавать данные в процедуру, причём часто надо передавать указатели на данные.

хе-хе... это самая ЖЕСТКАЯ проблема - 64kb limit. Пока функционал прог можно влепить в этот limit все как бы нормально. Как токо прога начинает быть хоть немного полезной (отвечать современным требованиям) так она уже никак не влазит в 64кб адресного. Многие платформы типа БЭСМ и PDP-11 погибли в основном по причине наличия этого лимита.

Так что выхода тут токо 2:

0. (обычный путь которым прошли все выжившие платформы) переход на процессор с большим лимитом адресного пространства и портирование нужного софта. В случае Химеры это установка ez80 + 16MB RAM.

1. (СЛОЖНЫЙ ДО УЖАСА, реализован в некоторых реальных прогах) разбить функционал проги на куски так чтобы места в памяти хватало! Алгоритм такой:

а) написать всю прогу на платформе где нет ограничения памяти;(при этом экран спека можно просто обьявить как массив на 6912 байтов и рисовать в него, при необходимости конвертировать изображение на экран реальной системы 50 раз в секунду).

b) разбить МАССИВ ДАННЫХ написанной проги на куски которые не зависят друг от друга (т.е. сгрупировать куски ДАННЫХ которые используются кодом только ВМЕСТЕ в отдельные группы, тут главное чтобы эти куски ДАННЫХ помещались потом в свободный RAM, (свободный RAM для спекки это = ВЕСЬ RAM(49152байт) - минимальный сегмент кода (16384байта) - экран (6912байт) - STACK (2000 байт???) - KERNEL (856 байт???) и ТОГО ~23000 байт) ). Если вдруг длинна куска ДАННЫХ больше свободной RAM то пытаться переписать прогу так чтоб кусок ДАННЫХ влез!

с) разбить весь код на куски длинной с минимальный сегмент кода (для спекки 16384байта);

d) все межсегментные JMP-ы\CALL-ы, обработку прерываний, проводить через KERNEL - маленький кусочек кода; При этом нужно учесть что этот кусочек должен уметь "включать" нужный массив данных для нужного сегмента кода перед тем как сделать реальный JMP/CALL.

e) если скорость будет все еще приемлемая то все должно получиться.

[Black_Cat]

Речь в теме идет о создании новой операционной системы для всех моделей ZX, где основным фактором, (поправьте меня, если я ошибаюсь!), будет наличие ядра системы, к которой будут подгружаться (или иным способом будут внедрены) конфигурации (можно их называть драйверами, кому как нравиться) для каждой модели отдельно.

Ты себе это очень смутно представляешь, т.к. не знаешь основного постулата - на Спектруме невозожно создать ОС, под которой будет нормально работать спековский софт.
Архитектура Хiмеra базируется на этом постулате, и позволяет его обойти путём аппаратного создания виртуальных машин для спековского софта, управляемых ОС.
Поэтому ни о какой "новой операционной системы для всех моделей ZX" и речи быть не может. Многозадачная, и даже реалтайм ОС исполняющая нормально спековскй софт возможна только на архитектуре Хiмеra. Другое дело, что сама архитектура позволяет существовать виртуальным машинам (ВМ) четырёх базовых конфигураций, которые можно выбрать при создании ВМ:
- SKAY (Scorpion+KAY)
- Pentagon
- Profi
- +3.

[Black_Cat]

Я внимательно прочел всю тему: "ХИМЕРА" - реальная концепция в ZX-строении

это не то , топик Концепция "ХИМЕРА" и аппаратная архитектура Хiмеra не связаны практически никак. Лучше посмотри десяток-два последних страниц этого топика http://www.zx.pk.ru/showthread.php?p=360130#post360130

[DimkaM]

разбить МАССИВ ДАННЫХ написанной проги на куски которые не зависят друг от друга

Спасибо. Десять слов которые наверно смогут мне помочь. LVD мне уже говорил об этом, но я его не понял.
Независимого кода очень мало, скорей всего придётся дублировать код в страницах. FATFS весит 24кило с драйверами ZSD+NEMOIDE+RTC, без учёта кешей(1.2кило) плюс активно юзается стек (~100-150 байт). По моим прикидкам чисто FATFS займёт 3-4 страницы памяти(с учётом дублирования кода). Опять же нужно место и для читаемого/записываемого файла, а с этим все намного сложнее, особенно при адаптации старых программ под FAT, очень много LDIRить придётся.
Нда гемор ещё тот, скорей всего отложу до лучших времён(реализации Химеры). А пока буду допиливать свой проект под ZX-Евой, там немного по проще с памятью, и всё прекрасно работает. Почаще щёлкаю страничками в трех банках, в четвертой обёртка лежит.

---------- Post added at 09:26 ---------- Previous post was at 09:09 ----------

Как вариант, брать за основу: "KalibriOS" и "MenuetOS".

Там исходники на асме под х86, автоматом никак не переделаешь. Нужно всё руками переписывать, а для этого нужно очень хорошо знать архитектуру и ассемблер одновременно Спекки и РС.
Причём таких людей нужно минимум десяток, что бы распараллелить конвертацию. Что бы понять трудоёмкость процесса, возьми 50 строк кода и попробуй их переписать под Z80.

[Error404]

FATFS весит 24кило с драйверами ZSD+NEMOIDE+RTC, без учёта кешей(1.2кило) плюс активно юзается стек (~100-150 байт).

Интересно про FATFS. Какой используешь компилятор чтобы получать Z80-код? Ведь нужна нативная поддержка 32-битных типов. И какую версию FATFS? Я в свое время дошел только до 6-й (последней без длинных имен), остальные показались слишком сложными.

[NovaStorm]

если Спектрум доработан до стандарта NemoBus v.1.2, то легким движением может быть вставлена плата расширения, расширяющая возможности до архитектуры Хiмеra

И что из спековского железа в получившемся Франкенштейне будет использоваться? При том, что хочется и eZ80 и много памяти, остаётся клавиатура что ли?

ZXFanat, Колибри - форк Менуэта, писана на 386 асме, внутри полнейший бардак из наслоений потоков мыслей целой толпы, для спека бесполезна.

---------- Post added at 10:23 ---------- Previous post was at 10:15 ----------

плюс активно юзается стек (~100-150 байт)

Как оценивал?

Почаще щёлкаю страничками в трех банках, в четвертой обёртка лежит.

Как вариант - RPC, но накладные расходы конечно вырастут.

[Black_Cat]

И что из спековского железа в получившемся Франкенштейне будет использоваться? При том, что хочется и eZ80 и много памяти, остаётся клавиатура что ли?

задай вопрос по другому. Из спековского железа будет использоваться абсолютно всё, т.к. архитектура Хiмеra - это абсолютный Спектрум

[DimkaM]

Интересно про FATFS. Какой используешь компилятор чтобы получать Z80-код? Ведь нужна нативная поддержка 32-битных типов. И какую версию FATFS? Я в свое время дошел только до 6-й (последней без длинных имен), остальные показались слишком сложными.

z88dk
Компилил самую последнюю версию(весной) R0.08b (revision ID 8237),LFN отключил, пока не нужно. Весь функционал проверил, работает на сто процентов.


---------- Post added at 12:01 ---------- Previous post was at 11:56 ----------

Как оценивал?

чисто субъективная оценка. Анализировал код после компиляции, т.к. были баги. FATFS писался под GCC, некоторые вещи z88dk неправильно компилились, преобразования типов в нескольких местах подправил и ещё что то, непомню что.