User Tag List

Показано с 1 по 10 из 217

Тема: Эволюция ZX в XXI веке

Древовидный режим

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #11

    Регистрация
    15.01.2010
    Адрес
    Челябинская обл., Карталы
    Сообщений
    60
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от МИВ Посмотреть сообщение
    Лично у меня труп-дос и все, даже пока ая нету. А что такое рт 11? А путь самурая, как я понял, у каждого свой. Тут уж кто во что горазд. Как вами уже говорилось на разных клонах по разному все организовано.
    RT-11 это ОС реального времени, разработчик DEC, да вот ниже про нее уже написали. Сейчас популярной некогда на постсоветском пространстве DEC с нами уже нет Под "самураем" я подразумевал ZX как платформу. Т.е. видение платформы у каждого свое и консолидировать усилия в этом направлении не удалось? Конечно здоровая конкуренция это хорошо, но... в разумных пределах. Так обстоят дела только в России или Европа и Запад не исключения? Про клоны я понял. Я не имел ввиду, да и не думал, что "самурай" у каждого свой настолько - что общих точек соприкосновения никто ни нашел. Плачевно...

    ---------- Post added at 10:44 ---------- Previous post was at 09:21 ----------

    Цитата Сообщение от andrews Посмотреть сообщение
    такие, где требуется 32-разрядный процессор от 100MHz для видео-обработки.
    Необходимость в таких режимах есть? Как я понимаю беспокоит в таких случаях скорость перерисовки? И требования в этом случае - отрисовка полного экрана за 1 кадр или не такие жесткие? А не будет ли в таком случае ограничением не ядро для обработки операций на содержимым, а возможности ЗУ по доступу? Фактически решить задачу не увеличивая производительности могут специализированные блоки ядер такие как например SIMD, но они требуют в итоге наличие очень быстрой памяти так операции загрузки/выгрузки имеют небольшие временные окна при схеме доступа к ЗУ экрана как 1 ядро - 1 растр. Адресное поле команд в Z80 имеют свободные участки оп-кодов? В реализация Z80 на базе ПЛИС были ли кем нибудь предприняты шаги к расширению архитектуры CPU например за счет блоков SIMD?
    Честно говоря когда в начале поста я завел речь о транспьютерной архитектуре, то в первую очередь подразумевал именно возможность формирования любого сложного растра - в каждой ячейке присутствует собственная локальная память и она отождествлять N-ый элемент растра. Задача формирования растра, так же как и задача его обработки - на 100% параллельная задача. Конечно будет временной лаг на межкоммуникацию, но он должен быть незначительным.

    Цитата Сообщение от andrews Посмотреть сообщение
    есть готовые интегрированные решения. Задача дать интерфейс к софту, исполняемому ЦП, то есть управлять плеером или отдельными саундтреками. Выбираете нужные интерфейсные микросхемы и соединяете по I2S или еще какому-нибудь современному стандарту с основной плисиной.
    Да это возможно. Но если говорить например о звуке то видимо Вы предлагаете использовать для таких целей DSP, однако DSP это не универсальный процессор, конечно наверняка такие монстры как AD предлагают к своим DSP и appnote и библиотеки на реализацию MP3. Но MP3 требует лицензионных отчислений, да и не соответствует духу GPL/GNU. И ,кстати, в этом случае пользователь платформы ZX будет поставлен перед необходимостью знать нескольких архитектур ЦПУ и DSP. Считаете что это приемлемо?
    Если говорить о декодерах таких как например VS1011b, то платформа ограничивается только стандартом MP3, как быть с другими стандартами например с открытым OGG? Конвертировать в MP3? Сужается круг возможностей для пользователей платформы.
    Шина I2C конечно решение правильное, в связи с чем вопрос шина до периферийных устройств в Спектруме так и осталась параллельной? Последовательную шину на PCB развести легче и частоты совсем другие. I2C все таки низкоскоростная шина и на роль магистрали, думаю, что не подходит.

    Цитата Сообщение от andrews Посмотреть сообщение
    За принципиально новую операционку я бы пока не брался, пока не станет понятной сама архитектура. На первых порах ее может заменить расширенный бейсик.
    Как промежуточный шаг - вполне!
    Однако вопрос что значит "принципиально новая операционка" не совсем ясен, что бы вы назвали новой?
    1. *nix (без страничной/виртуальной памяти)
    2. микроядерные ОС
    3. ОС реального времени (в том числе и 2.)
    4. CP/M (тем более что CP/M уже существует на ZX)
    5. Free DOS

    Многозадачные/однозадачные? Динамическое связывание?

    Цитата Сообщение от andrews Посмотреть сообщение
    А trdos это не операционка в современном понимании, это скорее расширенный биос. Его можно расширять и далее. GUI-шка необходима, но под легкие экраны с учетом новых возможностей ядер в плисах.
    GUI Вы имеете ввиду графическое API? Или подсистему BIOS видео-режимов (как скажем расширение VBE под x86)? Расширения 3D (opengl)? Если API то для ZX Вы его видите вне ЯВУ? Каким образом?


    Цитата Сообщение от andrews Посмотреть сообщение
    Насчет ЯВУ под z80. На форуме было много обсуждений на эту тему и все пришли к тому, что компилятора С, оптимизированного под z80 в Спектруме в природе не существует.
    т.е. вот этот тулчейн http://sourceforge.net/projects/z80gcc/ или вот этот компилятор http://sourceforge.net/projects/sdcc/files/ не оптимизирует под 8080 или Z80?
    ADC-Z80? Кроме того у самого Zillog должен быть KIT да и Hi-Tech вроде бы выпускала компилятор под Z80. Hi-tech C как я понял умеет работать на CP/M. Кстати Z88dk это Zilog-овский SDK?
    Вы говорите про компилятор под "хост" или под "таргет"?

    Цитата Сообщение от andrews Посмотреть сообщение
    Создать нечто паскалеподобное с регистровой оптимизацией или макроассемблер более мощный, чем существующие? Не знаю сколько на это уйдет времени. Возможно месяцы и годы.
    Если уж о Виртовских языках, то куда более быстрым в реализации будет Oberon но увы писать на нем будет очень не привычно. Простой компилятор написать дело времени (кстати именно такого, о котором Вы говорили выше - человеко-месяц), но оптимизирующий компилятор для регистровой архитектуры это годы работы. Если уж и говорить о некой оптимизации то уж лучше C-- где вся оптимизация дело рук исключительно программиста и язык Си.

    Цитата Сообщение от andrews Посмотреть сообщение
    Java и её производные лучше использовать в модулях-расширителях на основе ARM-процессоров, а к ним придумать удобный и интуитивно понятный интерфейс.
    Jazzel как технология динамического исполнения у многих вызывает нарекания, отчасти потом что умный JIT способен с небольшими потерями дать те же возможности. А интерфейс к ядру JVM только все испортит фактически периферийному ядру придется стать ЦПУ в случае запуска на нем байт-кода. ИМХО , но реализовывать JVM надо на ЦПУ, коль скоро архитектура предусматривает центральное ядро. Не хватает производительности - расширять ядро частотно и архитектурно или не меняя ничего писать под JVM более оптимальный код.

    ---------- Post added at 10:46 ---------- Previous post was at 10:44 ----------

    Цитата Сообщение от Zet9 Посмотреть сообщение
    Микроядерных ОС по Таненбауму на Спектруме нет. Существует проект MATRIX призванный это исправить (в случае его успешного завершения )
    Можно url? А лучше в рамках дискуссии описать что за проект и какие цели преследует? Или проект проприетарный?
    Последний раз редактировалось AlexeyAS; 17.01.2010 в 07:29.

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

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

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

Ваши права

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