Новый Орион. Давайте обсудим!

[Ewgeny7]

Параллельное ПЗУ можно разместить на дополнительной плате. Если она подключена (флаговый вывод на системной шине) - грузитесь с параллельного ПЗУ. Нет - загрузка с AT24C16B,

Не, вы не поняли. "Параллельное" ПЗУ нужно для загрузки самого драйвера работы с I2C. Без параллельного ПЗУ компьютер/контроллер вообще никакой программы не получит. По той причине, что без драйвера прочитать АТ24 просто не сможет.
Вот и получается, что нужно обычное ПЗУ с драйвером (и набором системных программ) и I2C-ПЗУ типа АТ24 для самой исполняемой программы, которую можно будет править прямо на Орионе и сохранять в том же АТ24.

[Advertiser]

[Error404]

Не, вы не поняли. "Параллельное" ПЗУ нужно для загрузки самого драйвера работы с I2C. Без параллельного ПЗУ компьютер/контроллер вообще никакой программы не получит. По той причине, что без драйвера прочитать АТ24 просто не сможет.
Вот и получается, что нужно обычное ПЗУ с драйвером (и набором системных программ) и I2C-ПЗУ типа АТ24 для самой исполняемой программы, которую можно будет править прямо на Орионе и сохранять в том же АТ24.

Фактически, тогда получается что ПЗУ F800 (условно назовем его так) придется оставить как оно есть (параллельным), а все прочее что грузится по I2C - это получается фактически ROM-DISK (просто сейчас он параллельный и находится в том же ПЗУ, что и начальный загрузчик). Т.е. навыходе мы получим тоже что и было + еще одна ПЗУ?

[pvlad]

Не, вы не поняли. "Параллельное" ПЗУ нужно для загрузки самого драйвера работы с I2C.

Тогда это уже "огород"! Это не профессиональное и лобовое решение. Я думаю надо придумать, чтобы исполняемый код загрузчика находился в ресурсах самой Альтеры. Альтера переносит код в ОЗУ контроллера (можно с адреса 0000Н) и выдает RESET. Запустится загрузчик, и уже он сам решит решит откуда и кого грузить.
Если окажется, что параллельное ПЗУ неизбежно, тогда бессмысленно дополнительно вешать еще последовательное. Давайте думать.

Мне CP/M интересна в первую очередь из-за....

Я с пониманием отношусь к Вашему пристрастию, но это субъективность. Вам, просто, нравится находиться в орионовской среде. И не более. Печально, но таких преданных поклонников не так много. Боюсь, что программисты, которые решатся что-то написать для Ориона, а вернее написать под контроллер, без сомнения захотят это делать на РС. Увы!

UZIX куда как интереснее....

Если не сложно, то расскажите об этом проекте. Мне очень интересно.

Ордос, если по хорошему, надо дорабатывать...

Нет! Ее трогать бессмысленно. Она хорошая/плохая такая какая есть - маленькая, примитивная. У нее была своя ниша. Любое добавление к ней будет согласно армейской поговорке: кто такой ефрейтор? Это недое... сержант или перее... солдат! Так будет и здесь. ОРДОС никогда не станет даже тенью СР/М, и не нужно к этому стремиться. Поэтому если возникает ситуация когда она применима, и это лучшее решение - стоит применять. Например при работе контроллера с небольшим РОМ-диском. Здесь глупо запрягать СР/М. А вот если необходимо манипулировать с большим количеством файлом, или сохранять большое количество информации - тут СР/М к месту. Единственное: не уверен, что "хард", на сегодняшний день, актуальное решение. Считаю флеши - более перспективно. Во всех отношениях: малые габариты, енергопотребление, доступность.

[Error404]

Боюсь, что программисты, которые решатся что-то написать для Ориона, а вернее написать под контроллер, без сомнения захотят это делать на РС. Увы!

Ну, я в-общем то тоже редко беру в руки реал, PC, как ни крути, - удобнее. Всю разработку делаю в эмуляторе. Другое дело, если на РС вообще не пользоваться эмулятором, а вести полный цикл разработки какими-то третьими средствами. Вот это проблематично, т.к. любую IDE-среду (а безоболочечные врядли интересны), генерящую код для Z80 (типа IAR, SDCC и подобных) довольно утомительно настраивать под Орион (чтобы реально было удобно отлаживать код, в экранном отладчике). Именно отлаживать (чтобы в модели Ориона), т.к. скомпилировать - это не проблема ни на PC, ни на реале, но это меньшая часть разработки. А аппаратная отладка на РС с участием реала (типа как jtag) c Z80 вряд ли возможна. "А раз нет разницы, то зачем платить больше?" (с)

UZIX куда как интереснее....

Если не сложно, то расскажите об этом проекте. Мне очень интересно.

Это Unix для Z80, совместимый по системному API c Unix класса System7, разработанный для Ямахи MSX в конце 90-х. Разработка на основе еще более старого UZI (конец 80-х), от которого отличается полным набором исходников как ядра, так и библиотек и утилит. Лицензия - свободное ПО, в коде нет заимствований от Bell, At&t, BSD и прочих, так что никто не докопается.
-
Я ковырялся в его коде (портировал утилиты для работы с файловой системой UZIX), все очень понятно и красиво написано, хотя на мой взгляд немного переусложнили с условной компиляцией препроцессора (т.к. из этого же кода еще и х86-версия для PC компилируется).
-
Полностью ANSI C, из-за чего на РС компилировать можно чем угодно, а на Орионе только Hitech C.
-
Главное, что дает UZIX (ну кроме фактора привычности для нас, *nix-истов), это возможность заимствования С-кода с UNIX-платформ. Что гораздо проще, чем городить огород с нуля.
-
Еще подумалось: Если получится портировать UZIX на Орион (набравшись на этом необходимого опыта), то не вижу никаких причин не портировать его [совместимо по коду UZIX-приложений] затем на, к примеру, ATM или его новый продвинутый вариант (забыл как называется). Или на другой продвинутых клон ZX, где есть достаточно быстродействия, памяти и неущербные диспетчеры ОЗУ и экран. Т.е. плюсуя сюда уже имеющийся MSX, имеем мощный объединяющий фактор, который поможет подтянуть, для начала на UZIX, программеров с других платформ (отсутствие программистов может похоронить любой проект, а осталось программирующих любителей старины - считанное количество).

[Error404]

Я думаю надо придумать, чтобы исполняемый код загрузчика находился в ресурсах самой Альтеры. Альтера переносит код в ОЗУ контроллера (можно с адреса 0000Н) и выдает RESET. Запустится загрузчик, и уже он сам решит решит откуда и кого грузить.
Если окажется, что параллельное ПЗУ неизбежно, тогда бессмысленно дополнительно вешать еще последовательное. Давайте думать.

Кстати, вот подумалось: раз уж пришли к необходимости последовательного ПЗУ, которое тем паче обрабатывается Z80 программно (т.е. на пару порядков медленнее параллельного), то почему не рассмотреть решение с MMC/SD картой вместо мсх ПЗУ? Раз один хрен из альтеры забрасывать в ОЗУ код "читалки", то можно будет воспользоваться готовым решением (а для Z80 есть CPM в исходниках, работающая как раз с MMC/SD - можно тупо взять отлаженные подпрограммы SPI оттуда). По-моему, получится красиво, т.к. имеем во-первых сменный носитель, во вторых - несравнимой с ПЗУ емкости, в-третьих его легко в любом кардридере можно подготовить на PC без всяких программаторов, в-четвертых - если рассматривать плату как абстрактную девборду, то иметь на девборде SD/MMC приятнее чем только ПЗУ, пускай даже и flash.


---------- Post added at 15:37 ---------- Previous post was at 15:29 ----------

Очень хорошо было бы сделать вариант Вашего эмулятора под этот контроллер (именно контроллер!). При этом сделать общую оболочку и объединить какой-нибудь редактор и транслятор кросс-ассемблера. Получилась бы среда разработки, где можно было бы программу писать и обкатывать на РС, а затем "запихивать" ее в контроллер через LPT или COM. Это было бы уже достаточно серьезное начало с инструментальной поддержкой контроллера!
Конечно, можно запустить имеющийся эмулятор, под ним орионовский редактор и ассемблер и т.д., но это уже не тот уровень для сегодняшнего дня. Что скажете по этому поводу, уважаемый коллега?

Это вполне можно было бы сделать. Кроме того, тут присутствуют более продвинутые эмуляторщики. У b2m вообще эмулируется множество машин, не только Орионы. В-общем, когда появится что-то близкое к финальному варианту (желательно хотя бы что-то в железе, на чем можно проверить соответствие эмуляции), думаю, за эмулятором тоже не заржавеет.