Важная информация

User Tag List

Страница 1 из 2 12 ПоследняяПоследняя
Показано с 1 по 10 из 19

Тема: FUZIX для Ориона (ПРО)

  1. #1
    Guru
    Регистрация
    24.01.2008
    Адрес
    Уфа
    Сообщений
    3,207
    Благодарностей: 927
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию FUZIX для Ориона (ПРО)

    Помнится, мы тут пытались портировать FUZIX на ZX, но потом тема заглохла. Да и работало это всё как-то нестабильно. Мне показалось интересным портировать это ещё и на Орион-Про, тем более что раскладка памяти практически идеально подходит под версию для 16Кб диспетчера. Жаль только, что в последнее окно (а оно самое важное), можно мапить только одну четвёртую всей памяти (хотя, при желании можно допилить схему, чтобы использовать, например, старшие 2 бита порта 08 в качестве адресов A14,A15 ОЗУ).

    И вот что получилось:


    Однако работает это всё также нестабильно, где-то есть косяк с прерываниями. При удачном стечении обстоятельств можно видеть результат, подобный картинке, т.е. вроде бы как всё хорошо

    Загрузочный диск тут, формат диска 720Кб, т.е. 80x2x9x512, выкладываю в надежде, что кто-то заморочится попробовать это на реале. Вряд-ли заработает, но чем чёрт не шутит...

  2. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #2
    Activist
    Регистрация
    10.02.2014
    Адрес
    г. Тула
    Сообщений
    476
    Благодарностей: 307
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от b2m Посмотреть сообщение
    выкладываю в надежде, что кто-то заморочится попробовать это на реале. Вряд-ли заработает, но чем чёрт не шутит...
    Попробовал запустить на реале, вроде грузится, но после подачи любой команды комп зависает, и через некоторое время сбрасывается.

    Дополнение 13.03.2016
    После исправления найденных ошибок на новодельной печатной плате Орион-Про, FUZIX теперь грузится и не зависает.
    Последний раз редактировалось Дмитрий2012; 25.07.2016 в 18:12. Причина: Дополнение

  4. Этот пользователь поблагодарил Дмитрий2012 за это полезное сообщение:
    b2m (02.01.2016)

  5. #3
    Guru
    Регистрация
    24.01.2008
    Адрес
    Уфа
    Сообщений
    3,207
    Благодарностей: 927
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Я кое-что поправил, теперь вроде постабильнее.

  6. #4
    Moderator Аватар для Error404
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    3,807
    Благодарностей: 1025
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от b2m Посмотреть сообщение
    Я кое-что поправил, теперь вроде постабильнее.
    Так какая используется модель памяти?
    Я не понял что там с 16-к диспетчером.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  7. #5
    Guru
    Регистрация
    24.01.2008
    Адрес
    Уфа
    Сообщений
    3,207
    Благодарностей: 927
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Error404 Посмотреть сообщение
    Так какая используется модель памяти?
    Я не понял что там с 16-к диспетчером.
    На данный момент используются первые три окна по 16Кб, последнее фиксировано (не считая, что через него производится доступ к экрану). К сожалению, общую область F000-F2FF, которая теоретически тоже должна переключаться, приходится постоянно (вместе со стеком в адресах EB00-EFFF) перекидывать в область задачи B800-BFFF и обратно. Аналогично мы делали и для ZX.

    Основные проблемы:
    - в окно C000-FFFF нельзя включить произвольную 16Кб страницу
    - ядро вместе с данными примерно 44Кб (плюс 2Кб общая область), пока помещается в три страницы, но на область кучи остаётся очень мало места (хотя я не знаю, используется ли она сейчас)

    Что можно сделать. Можно было бы перенести общую область в первое окно 0000-3FFF, тогда не надо было бы копировать её туда-обратно при переключении процессов, но тогда придётся располагать ядро с адреса 4000, т.е. ему достанется максимум 48Кб. Хватит ли?

    Алан вроде бы предусмотрел расположение ядра в разных страницах (есть модифицированный линковщик и обработчик собранного модуля, который делит код на страницы), но я пока не смотрел, как там всё делается.

  8. #6
    Moderator Аватар для Error404
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    3,807
    Благодарностей: 1025
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Думаю надо делать так, как у Алана было сделано в самой первой реализации, до того как он стал пытаться объять необъятное, и как сделано у меня в UZIX - используется диспетчер целых страниц по 64к (порт F9), в одной странице ядро, в остальных - процессы (по странице на процесс). В общей области (F000 и выше) - только UDATA, межстраничный стек и подпрограммы межстраничного вызова. UDATA+стек (всего полторы сотни байт) копируется в пространство процесса ниже F000 при каждом переключении контекста. Это дает более быстрое переключение, и что самое главное - нормальное количество места под процесс. С меньшим местом нечего и затевать, опять все упрется в то что ничего не влезает, особенно если пользовать SDCC.

    Диспетчер 16к тоже можно использовать - например сделать libc c оверлеем в области 0000...4000 для тяжелых приложений.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  9. #7
    Guru
    Регистрация
    24.01.2008
    Адрес
    Уфа
    Сообщений
    3,207
    Благодарностей: 927
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Error404 Посмотреть сообщение
    диспетчер целых страниц по 64к (порт F9), в одной странице ядро, в остальных - процессы (по странице на процесс).
    Тогда даже на Орионе-Про - максимум 7 процессов (и то, если совместить экран и пространство ядра, опять максимум 48Кб).

    Цитата Сообщение от Error404 Посмотреть сообщение
    UDATA+стек (всего полторы сотни байт) копируется в пространство процесса ниже F000 при каждом переключении контекста.
    Там вроде не полторы сотни, а все четыре. Хотя, на мой взгляд, можно было бы совместить стек ядра и стек прерываний. Просто, если мы уже в ядре, прерывание не должно переключать стек, а если нет, то использовать стек ядра. Я вот всё думаю, как перенести общую область в начало адресного пространства, чтобы использовать возможность включать любую страницу в эту область. Пока всё упирается в размер самого ядра. Если удастся, то можно сделать так, что процессы до 16Кб используют только 16Кб, а остальные - 64Кб.


    Цитата Сообщение от Error404 Посмотреть сообщение
    С меньшим местом нечего и затевать, опять все упрется в то что ничего не влезает, особенно если пользовать SDCC.

    Диспетчер 16к тоже можно использовать - например сделать libc c оверлеем в области 0000...4000 для тяжелых приложений.
    Я уже думал про разделяемые библиотеки (типа как .so в линуксе). Вот только вся libc (syslib.lib) даже в 64Кб не полезет.


    Кстати, раз уж мы затеяли дискуссию о Fuzix на Орионе, может отделишь начиная с моего сообщения со скриншотом в отдельную тему?

  10. #8
    Moderator Аватар для Error404
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    3,807
    Благодарностей: 1025
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Да, пожалуй, копируется сотни 3-4 байт. Ну как бы там ни было, это меньше чем если копировать 16к, и делается это не так часто. Просто без этого никак, т.к. доступ к UDATA процесса должен быть и из процесса и из ядра, а значит либо держать UDATA в общей области (самый лучший вариант), либо ядру UDATA процесса подключать диспетчером (что наплодит глюков, т.к. надо развести еще с прерываниями, которые могут возникнуть в любом месте).

    А вообще мне FUZIX не нравится. Кокс из простого и понятного кода UZI Брауна выродил нечто нечитаемое со своими дефайнами. Да еще этот SDCC

    - - - Добавлено - - -

    И что характерно, не сделал ничего принципиально нового.
    Где TCPIP? Где модульные ФС? Ничего интересного не добавлено, только констант новых налепили и теперь чтобы бэкпортить что-нибудь из того проекта в UZIX, надо чистить от мусора: разбираться что к чему.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  11. #9
    Guru
    Регистрация
    24.01.2008
    Адрес
    Уфа
    Сообщений
    3,207
    Благодарностей: 927
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Error404 Посмотреть сообщение
    доступ к UDATA процесса должен быть и из процесса и из ядра
    На самом деле доступ к UDATA процессу не нужен, более того, вообще должен быть запрещён, т.к. там хранятся данные ядра, которые относятся к этому процессу. На мой взгляд, сделано это для компактности обращения к этим данным. Ядро обращается к ним как к статическим переменным, а не через указатель на данные текущего процесса. Ну и стек ядра, в принципе тоже относится к самому процессу, но процесс волен размещать его где угодно, а ядру нужно в определённом месте.

    Цитата Сообщение от Error404 Посмотреть сообщение
    что наплодит глюков, т.к. надо развести еще с прерываниями, которые могут возникнуть в любом месте.
    Мест там собственно два: в программе и после вызова функции ядра. А ядро там само по себе никогда не работает.

    Цитата Сообщение от Error404 Посмотреть сообщение
    А вообще мне FUZIX не нравится.
    О вкусах не спорят. Мне, например, FUZIX больше понравился, чем UZIX. Например, явно выделенной железо-зависимой частью, что позволяет проще портировать его.

    Цитата Сообщение от Error404 Посмотреть сообщение
    Да еще этот SDCC


    Цитата Сообщение от Error404 Посмотреть сообщение
    И что характерно, не сделал ничего принципиально нового.
    Где TCPIP? Где модульные ФС?
    Я думаю, всё будет, если проект не заглохнет.

    Цитата Сообщение от Error404 Посмотреть сообщение
    только констант новых налепили и теперь чтобы бэкпортить что-нибудь из того проекта в UZIX, надо чистить от мусора: разбираться что к чему.
    Ну констант и в UZIX хватает. Просто с ними ты уже разобрался. А я, например, нет.

  12. #10
    Moderator Аватар для Error404
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    3,807
    Благодарностей: 1025
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    И в UZI и в UZIX аппаратнозависимая часть изолирована. Вынесена в отдельные файлы, собирается с минимумом дефайнов. Причем, UZIX куда ближе к исходному материалу, чем FUZIX. То, что сделано с исходниками UZI, отвратительно: разобраться в той каше может только программист (да и то как видим - не сразу), а в исходниках UZI/UZIX - любой с базовыми познаниями в С. Раз Кокс такой любитель накуевертить на дефайнах, пускай брал бы да делал с нуля. А то неспортивно как то. Браун вот помер, не видит.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

Страница 1 из 2 12 ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Ответов: 438
    Последнее: 14.09.2017, 01:43
  2. Новый IDE-контроллер для Ориона
    от alx32 в разделе Орион
    Ответов: 24
    Последнее: 26.01.2015, 23:14
  3. Игры для Ориона 128
    от Dota в разделе Орион
    Ответов: 1
    Последнее: 08.10.2012, 13:17
  4. cp/m для Ориона-128
    от sergey2b в разделе Орион
    Ответов: 7
    Последнее: 11.02.2011, 17:52
  5. Схема ОРИОНА-128(НУЖНА)!!!!
    от Nordic в разделе Барахолка (архив)
    Ответов: 1
    Последнее: 02.12.2008, 14:45

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •