Не, вы не поняли. "Параллельное" ПЗУ нужно для загрузки самого драйвера работы с I2C. Без параллельного ПЗУ компьютер/контроллер вообще никакой программы не получит. По той причине, что без драйвера прочитать АТ24 просто не сможет.Сообщение от pvlad
Вот и получается, что нужно обычное ПЗУ с драйвером (и набором системных программ) и I2C-ПЗУ типа АТ24 для самой исполняемой программы, которую можно будет править прямо на Орионе и сохранять в том же АТ24.
ScorpEvo ZS 1024 turbo+ CF-HDD/FDD/Mouse/SMUC 3.1/ProfROMse/NeoGS/ZC
Сайт с документацией к "Scorpion ZS 256"
С любовью к вам, Yandex.Direct
Фактически, тогда получается что ПЗУ F800 (условно назовем его так) придется оставить как оно есть (параллельным), а все прочее что грузится по I2C - это получается фактически ROM-DISK (просто сейчас он параллельный и находится в том же ПЗУ, что и начальный загрузчик). Т.е. навыходе мы получим тоже что и было + еще одна ПЗУ?
Последний раз редактировалось Error404; 09.10.2009 в 22:17.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Фактически да. Но будет один плюс - "последовательное" ПЗУ прошивается не только внешним программатором, но и средствами самого Ориона. Запись на него производится не сложней чем чтение. И в этом плане Орион будет удобнее и круче всех остальных контроллеров которым требуется ПЦ для разработки/отладки/прошивания софта. Ориону достаточно подключить клавиатуру и запустить ассемблер
Сайт с документацией к "Scorpion ZS 256"
Тогда это уже "огород"! Это не профессиональное и лобовое решение. Я думаю надо придумать, чтобы исполняемый код загрузчика находился в ресурсах самой Альтеры. Альтера переносит код в ОЗУ контроллера (можно с адреса 0000Н) и выдает RESET. Запустится загрузчик, и уже он сам решит решит откуда и кого грузить.
Если окажется, что параллельное ПЗУ неизбежно, тогда бессмысленно дополнительно вешать еще последовательное. Давайте думать.
Я с пониманием отношусь к Вашему пристрастию, но это субъективность. Вам, просто, нравится находиться в орионовской среде. И не более. Печально, но таких преданных поклонников не так много. Боюсь, что программисты, которые решатся что-то написать для Ориона, а вернее написать под контроллер, без сомнения захотят это делать на РС. Увы!
Если не сложно, то расскажите об этом проекте. Мне очень интересно.
Нет! Ее трогать бессмысленно. Она хорошая/плохая такая какая есть - маленькая, примитивная. У нее была своя ниша. Любое добавление к ней будет согласно армейской поговорке: кто такой ефрейтор? Это недое... сержант или перее... солдат! Так будет и здесь. ОРДОС никогда не станет даже тенью СР/М, и не нужно к этому стремиться. Поэтому если возникает ситуация когда она применима, и это лучшее решение - стоит применять. Например при работе контроллера с небольшим РОМ-диском. Здесь глупо запрягать СР/М. А вот если необходимо манипулировать с большим количеством файлом, или сохранять большое количество информации - тут СР/М к месту. Единственное: не уверен, что "хард", на сегодняшний день, актуальное решение. Считаю флеши - более перспективно. Во всех отношениях: малые габариты, енергопотребление, доступность.
Ну, я в-общем то тоже редко беру в руки реал, PC, как ни крути, - удобнее. Всю разработку делаю в эмуляторе. Другое дело, если на РС вообще не пользоваться эмулятором, а вести полный цикл разработки какими-то третьими средствами. Вот это проблематично, т.к. любую IDE-среду (а безоболочечные врядли интересны), генерящую код для Z80 (типа IAR, SDCC и подобных) довольно утомительно настраивать под Орион (чтобы реально было удобно отлаживать код, в экранном отладчике). Именно отлаживать (чтобы в модели Ориона), т.к. скомпилировать - это не проблема ни на PC, ни на реале, но это меньшая часть разработки. А аппаратная отладка на РС с участием реала (типа как jtag) c Z80 вряд ли возможна. "А раз нет разницы, то зачем платить больше?" (с)
Это 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; 11.10.2009 в 15:53.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Кстати, вот подумалось: раз уж пришли к необходимости последовательного ПЗУ, которое тем паче обрабатывается Z80 программно (т.е. на пару порядков медленнее параллельного), то почему не рассмотреть решение с MMC/SD картой вместо мсх ПЗУ? Раз один хрен из альтеры забрасывать в ОЗУ код "читалки", то можно будет воспользоваться готовым решением (а для Z80 есть CPM в исходниках, работающая как раз с MMC/SD - можно тупо взять отлаженные подпрограммы SPI оттуда). По-моему, получится красиво, т.к. имеем во-первых сменный носитель, во вторых - несравнимой с ПЗУ емкости, в-третьих его легко в любом кардридере можно подготовить на PC без всяких программаторов, в-четвертых - если рассматривать плату как абстрактную девборду, то иметь на девборде SD/MMC приятнее чем только ПЗУ, пускай даже и flash.
---------- Post added at 15:37 ---------- Previous post was at 15:29 ----------
Это вполне можно было бы сделать. Кроме того, тут присутствуют более продвинутые эмуляторщики. У b2m вообще эмулируется множество машин, не только Орионы. В-общем, когда появится что-то близкое к финальному варианту (желательно хотя бы что-то в железе, на чем можно проверить соответствие эмуляции), думаю, за эмулятором тоже не заржавеет.
Последний раз редактировалось Error404; 11.10.2009 в 15:51.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Телепатически.
Конечно, в том проекте есть ПЗУ.
И тут тоже будет эмулятор "небольшого параллельного ПЗУ" в Альтере. Речь, как я понимаю, о другом - что в отдельном от ПЛИС корпусе (т.е. "в железе") никакого параллельного ПЗУ не будет.
Последний раз редактировалось Error404; 11.10.2009 в 15:58.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
У svofski тоже загрузчик непосредственно в Альтере живёт, целых 512 байт.
В общем то да. В Альтере находится только код загрузчика, который знает как считать, посадить в ОЗУ код второго загрузчика из последовательного ПЗУ. Такая двух-этажная загрузочная структура уже применяется при загрузке СР/М и на Орионе-128 из под ОРДОС и в Орион-ПРО. Что же здесь нового? Второй загрузчик из последовательного ПЗУ может быть чем угодно. Мудрите с ним как хотите. Последовательное ПЗУ можно просто прицепить к ножкам порта ПС и прошить любой загрузчик "своей системы". С параллельными EPROM или Flash это так просто не сделать. Да и старье все это! Необходимо применять современные чипы.
Думаю в Альтере это можно сделать следующим образом (уже эта идея высказывалась на форуме): аппаратный счетчик перебирает адреса и читается из Альтеры (не знаю конкретно откуда!) и записывается байты в ОЗУ. Далее аппаратный ресет. Но последнее слово за Евгением. Структуру "шапки" загрузчика в последовательном ПЗУ можно взять из ОРДОС и не выдумывать что-то еще. "Альтеровский" загрузчик прочитав "шапку" уже будет знать сколько байт и куда перенести, и по какому адресу передать управление.
Последний раз редактировалось pvlad; 11.10.2009 в 19:51.
Если ты чего-то не знаешь, то это не значит, что этого не может быть.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
