Просмотр полной версии : Новый Орион. Давайте обсудим!
Я уже несколько дней обдумываю, как донести те соображения по Ориону, которые формировались у меня не один год. Вначале я хотел спорить с Error404 по поводу его взглядов на Орион-128. Его концепция just for fun (только для развлечений) не сможет возродить Орион. Под этим лозунгом из музейной вещи не сделать шлягер. К сожалению, тут и светлая и талантливая голова ewgeny7 не выручит. Что мы имеет в этом случае? Ну, с десяток фанатов Ориона повторят его в новом железе! Дальше что? Ну, собрали, поигрались - утолили жажду познания на тех программках, которым 10-15 лет тому назад написали их отцы! По современным меркам, примитивное убожество! Дальше что? А дальше положили на полку! Про себя гордо подумали: я это смог, я его повторил и увидел над, чем корпело предыдущее поколение. А мне, куда свои руки и мозги приложить, да еще, чтобы это перекликалось с тем прошлым!
К сожалению, это не то. Я, лично, никогда не был бы удовлетворен этим. Ну, может быть потому, что не люблю возиться с музейными вещами: реставрировать их, восстанавливать, лелеять. Я предпочитаю изобретать и творить новое.
Что я предлагаю!
Орион-128 должен продолжать жить в двух направлениях:
1. Это - just for fun, как определил Error404. Кому-то Орион интересен как сам факт истории, к которой можно прикоснуться своими руками. Конечно, ewgeny7 здорово упростит жизнь тем, кто будет собирать "новый" Орион. В наше время надо было попыхтеть, чтобы запустить плату с более чем полусотней рассыпухи. Думаю, сейчас и не нужно это пыхтение. Мы ведь в свое время пыхтели не потому, что в этом был кайф (а вообще, кто его знает)! Просто другого выбора не было.
2. Второй вариант всецело зависит от ewgeny7.
Мы упрощаем его проект и удаляем "навороты", т.е. делаем классический Орион-128. Это позволит использовать более дешевую ПЛИС. Главная идея - превратить Орион в УНИВЕРСАЛЬНЫЙ КОНТРОЛЛЕР, который можно встраивать в радиолюбительские задачи управления.
Каким он мне видится?
- использовать CPU Z80. Может быть учесть совместимость с Card II.
- сделать два видеовыхода: VGA для подключения стандартного ЖКИ-монитора, и подключение телевизора через кодер PAL. Это позволит использовать в качестве средств отображения маленькие VGA мониторы с RGB экраном 5-7" или маленький телевизор. Если учесть, что VGA мониторы зачастую имеют сенсорные экраны, то это открывает совершенно новые возможности в радиолюбительских интерфейсах программ.
- динамическую память заменить (просто ее уже не найти) на два корпуса статики по 64К. В адресном пространстве никаких ПЗУ. Только ОЗУ и загрузка всех исполняемых блоков. Если применить КМОП-память+батарейка, то несложно сделать "спящий режим" по примеру Windows.
- процессорное ядро запустить на максимальной частоте (это условно, потому что надо учитывать видео), а медленные периферийные МС согласовывать через WAIT. Это позволит увеличить производительность вычислений внутри CPU, что крайне важно для арифметики с плавающей запятой.
- разместить на плате MMC(SD)-флеш, в ПЛИС - только загрузчик. СР/М как встроенная базовая ОС. Возможность флешку втыкать в РС решит проблемы переноса файлов.
- СР/М можно разместить в I2C-флеш и загружать на исполнение в ОЗУ. Тогда ММС-флешка будет иметь стандартную файловую структуру по отношению РС. Кроме того, раз у нас появится I2C то можно использовать часы DS1307, а секундные (можно и более частые - меняется программно) импульсы завести на прерывание. Это уже работа в реальном масштабе времени.
- канал RS-232 + MAX232 как драйвер согласования уровней. Нужен обязательно.
- на плате разместить два 82С55 порта. Больше не надо. Для остальных - вывести CS.
- на плате разъем системной шины и два разъема портов. Вся остальная самодеятельность на платах расширения.
- можно на плате разместить порт клавиатуры (может быть и мыши) PS/2. Совместимость с игрушками ни к чему, а работать на РК-шной клавиатуре уже стремно.
Ну, вот концептуально собственно и все, что касается железа. Остальное можно обсудить и дополнить.
Какое преимущество такого контроллера по сравнению с однокристаллками (PIC, AVR)? Во-первых, фон-неймановская архитектура CPU более универсальная, чем гарвардская. Последняя не позволяет выполнять программу подгружаемыми блоками, иметь возможность саму себя модифицировать, кардинально менять решаемую задачу путем оперативной замены программы. Контроллеры гардварской архитектуры имеют очень мало оперативной памяти (внешняя память не в счет - потеря 2-х портов), что в некоторых случаях просто не позволяет решить задачу. Например, работа с FAT. Где размещать буферы секторов? А если одновременно открыть несколько файлов?
Какие направления в применении этого контроллера уже сейчас можно обозначить?
Взять хотя бы "Умный дом", где широчайшее поле для радиолюбительства. Что самое интересное, что узко направленные задачи (измерение температуры, контроль за отопительным котлом, охрана здания и т.д.) можно решать с помощью однокристаллок, а "главный компьютер" в этой системе - Орион. Если в качестве дисплея использовать телевизор, то что мешает переключать его оперативно на видеокамеры охраны. И еще много чего!
Автотюнинг. Вот только два предложения. В иномарках (в большинстве своем) на центральной консоль имеется ЖКИ-экран мультимедийной системы. Там выводится информация бортового компьютера, часы, управление отопителем, мультимедиа и т.д. Скажите мне: это когда-нибудь в обозримом будущем будет на отечественных автомобилях? Вряд-ли! Что мешает это сделать, в том числе воспроизводить WAV-файлы?
А электронная панель приборов, как у Мерседеса, где шкалы приборов рисуются на экране ЖКИ, при этом он может переключаться на просмотр видеокамеры заднего обзора.
Я рассказал своему приятелю (он схемотехник Орион-ПРО) об использовании Орион-128 в новом качестве. Он тут же заявил: мне чем-то надо заменить старые перфоратор и перфосчитыватель на станках ЧПУ! Лучше не придумаешь!
А сколько еще можно найти областей и тем для применения контроллера на базе Орион-128? Непочатый край! Конечно, это становится возможным благодаря работам ewgeny7. Без его поддержки, без отработки простой технологии программирования микросхемы ПЛИС - это не осуществить.
И последнее. Этот проект необходимо объявить открытым, т.е. если кто-то написал программу и хочет сделать свой вклад (естественно, за это должно воздаваться какое-то моральное вознаграждение. Может быть создать своего рода "доску почета"!) в общее дело, он выкладывает в свободный доступ схемы, исходные тексты программы и т.д. - по примеру Линукс! Думаю, здесь уже нужна будет помощь хозяина сайта.
И еще. Наверное, новому Ориону необходимо дать новое отличительное имя.
И самое, самое последнее. Я переговорил с Пушковым Владимиром (системное прог.обеспечение Ориона-ПРО) и Евсеевым Борисом (схемотехника Ориона-ПРО) Это могиканы Ориона-ПРО. Они согласны подключиться к этому проекту и помочь создать аппаратно-программный базис.
Что скажете, коллеги?
Это позволит использовать более дешевую ПЛИС.
У него и так самая дешевая FPGA...
У него и так самая дешевая FPGA...
Ты меня опередил :)
Стоимость этой ПЛИС 170руб.
Выносить Z80 за пределы ПЛИСки нет смысла. Так и дешевле и быстрее.
СР/М вполне можно разместить вместе с запускающим монитором во флешке PLCC, работать с ней просто, стоит около 100руб.
ОЗУ и сейчас стоИт CMOS. Сохранение программы "под батарейкой" работает уже сейчас. Пользуюсь этим за неимением дисковода :)
СР/М вполне можно разместить вместе с запускающим монитором во флешке PLCC, работать с ней просто, стоит около 100руб.
Можно проще, хранить прошивки в конфигураторе
Можно проще, хранить прошивки в конфигураторе
А нафик? Места займет много. Кроме того, для апдейта можно просто перешить флешатинку. Это к тому, что конфигуратор делать на МК я не буду. Проще поставить обычное конфПЗУ под этот циклон - EPCS1 стоимостью 2,5$, а не заморачиваться с МК+ПЗУ.
Black_Cat
21.09.2009, 21:07
Главная идея - превратить Орион в УНИВЕРСАЛЬНЫЙ КОНТРОЛЛЕР, который можно встраивать в радиолюбительские задачи управления.
Взять хотя бы "Умный дом"...
Этот проект необходимо объявить открытымpvlad, поздравляю к присоединению к местному клубу концептологов (т.е. людей, которые считают, что любое развитие надо начиать с разработки идеологии, потом концепции реализации этой идеологии и т.д. ..) :)
Поздравляю так же орионщиков с открытием местного филиала "Концепций".. - думаю всёж что орионщикам на чужом форуме жить будет свободней, чем спектрумистам на своём :) .
Успехов вам в ваших начинаниях!
конфПЗУ под этот циклон - EPCS1 стоимостью 2,5$
Ну я и имел в виду КонфПЗУ, сколько прошивка циклона занимает его не целиком? Просто его можно после запуска FGPA юзать как SPI флешку и в свободном месте хранить CP/M если влезет. Хотя если что EPCS4 стоит не намного больше. Апдейтить прошивку можно опять же средствами самого циклона с той же флеш карты, но тут необходимо утилиту писать...
EPCS1 имеет емкость 1Мбит. Циклон съдает это полностью.
EPCS4 соответственно 4 мегабита. Итого свободного места - 384 килобайта. Но стоимость... 16$
И сама альтера рекомендует хранить в "свободном месте" что-нить полезное (подразумевает свой NIOS :) ). Но как сие использовать?
---------- Post added at 21:39 ---------- Previous post was at 21:33 ----------
думаю всёж что орионщикам на чужом форуме жить будет свободней
Форум не чужой. Просто вывеску менять никто не позволит :)
Через мегафунукцию Serial Flash Loader, ставиш галку предоставить ASMI интерфейс, и ты фактически подключился к ногам конфигуратора. Дальше протокол работы с ним описан в большой библии по конфигурированию FPGA. Если будет интересно можно будет над этой темой повоевать...
Если будет интересно можно будет над этой темой повоевать...
Но стоимость... 16$
Если только с теоретической точки зрения. :(
И спортивной...
Цитата:
Сообщение от ewgeny7
Но стоимость... 16$
Если только с теоретической точки зрения.
И спортивной...
Это мед не правильный, тут (http://kosmodrom.com.ua/product.php?page=0&name=EPCS4&okbutton=%CF%EE%E8%F1%EA) к примеру 2,7$
Это мед не правильный, тут к примеру 2,7$
Хорошо. Значит, будем расчитывать на тебя :)
---------- Post added at 22:18 ---------- Previous post was at 22:15 ----------
На I/O периферии что фтыкать будем? Я, честно говоря, кроме 245, 374 и 82С55 ничего пока не представлял. Что-то посовременнее ведь есть?
Хорошо. Значит, будем расчитывать на тебя
Это в харькове :)
Error404
21.09.2009, 23:20
Я вцелом за, концепция "применимости" может придать импульс. Дело за энергичностью реализации - именно из-за ее отсутствия и имеем just for fun :) , т.к. большинство участников пассивны. Я уже жаловался в соседней ветке - сотни скачиваний того, что напрограммил я, и почти никто не размещает своё, хотя я неоднократно призывал к этому (даже раздел был на страничке специальный).
--
Несколько комментариев по ходу изложения
- использовать CPU Z80. Может быть учесть совместимость с Card II.
двумя руками за CARDII, т.к. решается на аппаратном уровне примитивно, и кроме совместимости со старым ПО (кому-то ведь интересно и поиграть) в числе прочих дает режим:
В адресном пространстве никаких ПЗУ
Орион-ПРО был частично (за исключением диспетчера 16к совместим с CARDII)
- сделать два видеовыхода: VGA для подключения стандартного ЖКИ-монитора, и подключение телевизора через кодер PAL.
Также особенно я бы выделил насущную необходимость в вводе/выводе по порту RS232, что безусловно необходимо если планируется использовать комп в качестве контроллера, а решается сугубо программно - в драйвере консоли CP/M. Тем более на плате мы уже будем иметь :
- канал RS-232 + MAX232 как драйвер согласования уровней. Нужен обязательно.
- динамическую память заменить (просто ее уже не найти) на два корпуса статики по 64К.
Мало. Особенно для CP/M. Как программирующий пользователь уверяю - минимум 512к. Тем более, что при современных недорогих и малокушающих МСХ памяти это не помешает
применить КМОП-память+батарейка, то несложно сделать "спящий режим" по примеру Windows.
- процессорное ядро запустить на максимальной частоте (это условно, потому что надо учитывать видео), а медленные периферийные МС согласовывать через WAIT.
Полностью согласен. Полезно также иметь режим отключения "завязок на видеовыход" если используется вывод на TTY (RS232)
- разместить на плате MMC(SD)-флеш, в ПЛИС - только загрузчик. СР/М как встроенная базовая ОС. Возможность флешку втыкать в РС решит проблемы переноса файлов.
- СР/М можно разместить в I2C-флеш и загружать на исполнение в ОЗУ. Тогда ММС-флешка будет иметь стандартную файловую структуру по отношению РС.
Вот тут очень много ньюансов. Во первых, даже параллельный ввод-вывод работает не шустро (примерно со скоростью дисковода), а последовательный с SD/MMC уж точно надо будет строго передоверять дополнительному контроллеру (чтобы Z80 читал сразу байт). Во-вторых, FAT c CPM подружить сложно. Тогда надо сразу смотреть в сторону MSX-DOS (а она совместима только по BDOS, впрочем и этого не мало). Но это уже детали, и проблемы программиста. :) Пока проговорим аппаратную часть.
Далее полностью одобрямс.
- на плате разместить два 82С55 порта. Больше не надо. Для остальных - вывести CS.
- на плате разъем системной шины и два разъема портов. Вся остальная самодеятельность на платах расширения.
- можно на плате разместить порт клавиатуры (может быть и мыши) PS/2. Совместимость с игрушками ни к чему, а работать на РК-шной клавиатуре уже стремно.
Клавиатуру вроде побороли адаптером PS2. Ну, для тех кому дороги игрушки. :)
Если говорить сильно забегая вперед, то самым большим "ЕСЛИ" мне видится проблема программного обеспечения. Она всегда была тормозом в предыдущие годы, а сейчас программирующих любителей в наших рядах стало сильно меньше. Поэтому же считаю надо продумать совместимость со старым ПО (если это не сильно исказит концепцию).
EPCS1 имеет емкость 1Мбит. Циклон съдает это полностью.
EPCS4 соответственно 4 мегабита. Итого свободного места - 384 килобайта. Но стоимость... 16$
В "Элитане" EPCS4SI8N; SO8 стоит 101 руб.
А для EP2C5Q208C8N какую кофпзу надо?
"Элитане" EPCS4SI8N; SO8 стоит 101 руб.
А для EP2C5Q208C8N какую кофпзу надо?
Да
Да
Я тут читаю по Циклонам 1 и 2. Оба не поддерживают 5 В сигналы. Как это сделано в Орионе ?
По поводу применения (это там где окупаемость), - есть ниша всяких интерактивных/презентационных устройств по типу терминалов пополнения счета, систем помощи клиентам (например описание услуг).
Я тут читаю по Циклонам 1 и 2. Оба не поддерживают 5 В сигналы. Как это сделано в Орионе ?
Резюк защитный ставишь последовательно с ногой, если на другой стороне CMOS то еще подтягиваешь к 5v, вроде так было в Cyclone II Handbook, я по крайней мере Z80 так подрубал к DE1
Оба не поддерживают 5 В сигналы. Как это сделано в Орионе ?
Не поддерживают. Но толерантны.
ТТЛ без ограничений (ну, можно резюки ом так 200-1000 в разрыв поставить), КМОП пятивольтовый "может не понять 3-х вольтового сигнала с ПЛИС. В обратном направлении - без проблем". Как оказалось кмопикам 3,3в хватает для счастья.
Так что, питание ядра - 1,5в, портов ПЛИСы - 3,3, всё остальное - 5 вольт.
http://www.altera.com/literature/hb/cyc2/cyc2_cii5v1.pdf вот тут начиная с 316 страницы написано про 5в логику
Извиняюсь, я со свиным рылом да в калашный ряд...
А почему бы не взять плату Altera DE1 ?
Ну одно дело когда к примеру 50$ будет стоить Орион, а другое дело когда DE1 будет 250$
heroy, 50$ готовый спаянный ? В какой комплектации ?
heroy, 50$ готовый спаянный ? В какой комплектации ?
Ну я примерно сказал +-200% :) Если тот вариант что делается на первом циклоне, в любом случае будет дешевле DE1, хотя я лично за то что бы все пересели на DE1, ну или DE0
Ну одно дело когда к примеру 50$ будет стоить Орион, а другое дело когда DE1 будет 250$
Ну, я бы предложил делать проект совместимым с DE1. То есть кому just for fun, используют DE1. Кому нужна дешевая железка, паяют железку, навесив на нее блоки, встроенные в DE1, или подключаемые к ней через ее разъемы. Я понимаю, что распиновка ПЛИС будет другая, но сами блоки хотелось бы видеть совместимыми (RAM, ROM, SD, VGA, PS/2 и т.д.).
Так и отлаживать проще, и для переноса в железку в проекте останется только распиновку ПЛИС переделать.
DE1 у меня есть, в вот железяку паять мне как-то ни к чему. К тому же, если принять набор модулей DE1 за стандарт, можно организовать проект создания мультиэмулятора, и перенести под этот стандарт все имеющиеся наработки (что там у нас есть - Орион, Вектор, Агат, Специалист?)
То есть кому just for fun, используют DE1.
Эта категория может и на эмуле посидеть.
Так и отлаживать проще, и для переноса в железку в проекте останется только распиновку ПЛИС переделать.
Отлаживать как раз сложнее, поскольку кроме ПЛИС мы имеем дело и с реальными микросхемами. 82С55 на DE1 нету.
вот железяку паять мне как-то ни к чему.
Ну, тут всё просто. Кому нужен именно Орион, а не "картридж для Денди", тот спаяет. Мы всё-таки обсуждаем реальную железку, которой можно найти применение именно как функционально законченному устройству.
---------- Post added at 15:40 ---------- Previous post was at 15:37 ----------
heroy, 50$ готовый спаянный ? В какой комплектации ?
Ага, heroy, я тоже присоединяюсь! Когда продавать будешь? :)
Эта категория может и на эмуле посидеть.
Не хочу быть Кассандрой, но как реалист настоятельно рекомендую все-таки подумать о совместимости со стандартными решениями. :)
рекомендую все-таки подумать о совместимости со стандартными решениями.
На Ори по любому будут порты 8255. Если переносить на DE, то они соответственно исключаются. Распиновка альтер различается. ПЗУ сделано как внешнее, на DE вроде используется загрузка при конфигурировании. В общем, проще переделать полностью под DE чем париться с совместимыми вариантами. А переделывать никто и не будет, ибо вариант под DE1 делает igor_t. Правда, пока светить проект он не хочет. На форуме Игоря не ищи, в отличие от Блэк Кэта он даже один раз зарегиться не смог :(
На Ори по любому будут порты 8255
А почему их в Альтеру не запихнуть? (Если это уже обсуждалось, прошу прощения, что пропустил).
Black_Cat
23.09.2009, 16:47
Если переносить на DE, то они соответственно исключаются.почему? все внешние устройства цепляй через внешнюю шину, туда же при желании можно подумать и как ПЗУ привесить, если не нравится то, что есть в DE.. А борду лучше конечно DE0.. всего-то 130$
Давайте еще VGA-конвертер засунем в девборду.
Просто так, чтоб было.
Вы будете привинчивать девборду к терминалу или еще куда как предлагалось здесь? Или будете снаружи DE1 вешать на соплях ВВшки? А если их эмулировать, то сравните нагрузочную способность портов альтеры и дубового ВВ.
А борду лучше конечно DE0.. всего-то 130$
Кот, подари девборду, да? ;) Тогда точно перенесу, чисто по дружбе :)
---------- Post added at 17:35 ---------- Previous post was at 17:33 ----------
А почему их в Альтеру не запихнуть? (Если это уже обсуждалось, прошу прощения, что пропустил).
Эээ... Ответил чуть выше :)
Black_Cat
23.09.2009, 17:39
будете снаружи DE1 вешать на соплях ВВшкиесть два разъёма IDC40 на котороых можно организовать внешнюю шину по типу NemoBus, и вешай на неё всё что хочешь
есть два разъёма IDC40 на котороых можно организовать внешнюю шину по типу NemoBus, и вешай на неё всё что хочешь
И какой вывод? Будем использовать в конечных устройствах DE1 за 250$ с воткнутыми платами расширения?
Black_Cat
23.09.2009, 18:24
Будем использовать в конечных устройствах DE1 за 250$ с воткнутыми платами расширения?
Будем использовать в конечных устройствах DE1 за 250$ с воткнутыми платами расширения?DE0 - 130$, а для студентов и вовсе 90$.. Периферия на платах - общепринятая практика. Хочешь сделать самопальную плату вместо DE - делай, архитектура-то та же останется, или ты видишь какие преграды?
---------- Post added at 18:24 ---------- Previous post was at 18:07 ----------
форуме Игоря не ищи, в отличие от Блэк Кэта он даже один раз зарегиться не смогужос какие у вас там в Питере страсти.. этот Блэк Кэт небось всю вашу питерскую квоту регистраций выбирет.. толи дело у нас, на периферии.. природа, и никаких Блэк Кэтов :)
и никаких Блэк Кэтов
Нууу блиин! Как я вам завидую! :)
Он нам уже всю плешь проел!
Хочешь сделать самопальную плату вместо DE - делай, архитектура-то та же останется, или ты видишь какие преграды?
Кто-то из нас тормозит. И вроде бы не я. Я с самого начала говорю о том что буду делать на самопальной плате именно в той конфигурации, которая мне нравится (или какие детали имею). Будет кто повторять конструкцию или нет - не мои проблемы.
Доведется до ума нормальная концепция - будем всем миром лепить новое. Я приму активное участие, ибо Орион мне нравится :)
90% уже сделано у svofsky в проекте Вектор-06ЦЦ. Звук и контроллер флопа (SD карта) - там же. Ви таки будете смеяться, ВВ55 там тоже есть. Как понимаю - отличие только в организации клоков и (видео)памяти.
http://code.google.com/p/vector06cc/
Да, я заглядывал туда, подчерпнул маленько полезных идей :)
---------- Post added at 19:29 ---------- Previous post was at 19:23 ----------
Разницы на самом деле поболее. Таких выкрутасов с памятью как на Орионе нет больше нигде, наверное :)
Про флоп последнее время даже никто и не заикался, для этого есть винчестер (CF). Работа со звуком - это да, собираюсь "перенять дружественные технологии" :)
Вдогонку к моему "ну её наф, девборду!" - комплект деталей для сборки Ориона :)
DE0 - 130$, а для студентов и вовсе 90$.. Периферия на платах - общепринятая практика. Хочешь сделать самопальную плату вместо DE - делай, архитектура-то та же останется, или ты видишь какие преграды?
---------- Post added at 18:24 ---------- Previous post was at 18:07 ----------
ужос какие у вас там в Питере страсти.. этот Блэк Кэт небось всю вашу питерскую квоту регистраций выбирет.. толи дело у нас, на периферии.. природа, и никаких Блэк Кэтов :)
идея компа Жени - плата размером с пачку сигарет, законченое устройство. а не "макетная плата". сделал, запихал в корпус. счастлив. :v2_laugh:
идея компа Жени - плата размером с пачку сигарет, законченое устройство. а не "макетная плата". сделал, запихал в корпус. счастлив.
Идея понятна. Но если бы тот же проект с минимальными переделками ложился на "макетную плату", на которую ложатся и другие компьютеры, круг способных оценить (или принять участие) намного бы расширился.
Идея понятна. Но если бы тот же проект с минимальными переделками ложился на "макетную плату", на которую ложатся и другие компьютеры, круг способных оценить (или принять участие) намного бы расширился.
а я больше чем уверен что пилотный экземпляр женя соберет именно на макетке.
что мешает?
распаял планар на отдельных макетка, сделал штыревые разъемы, чтобы их можно было использовать не только под этот проект - и вперед - паяло и мгтф решают! :v2_thumb: :v2_clap2:
а уж поссле пилота можно и попробовать платку в производство пустить...
так , евген? :v2_wink2:
Black_Cat
30.09.2009, 17:11
идея компа Жени - плата размером с пачку сигарет, законченое устройство. а не "макетная плата"какая разница размер с пачку сигарет будет или папирос :) , зато девборды уже есть у многих
какая разница размер с пачку сигарет будет или папирос :) , зато девборды уже есть у многих
у мну нет.....:v2_frown:
и мне интереснее будет собрать маленький корпус, чем вталькивать это даже в микро-атх:v2_wink:
Да! Не "густо" коллеги с идеями! Если б не ERROR404 и ewgeny7, то мой "глас остался бы воем в пустыне". В основном - наблюдатели. Я понимаю желающих "посадить" Орион на DE1. Для них этот проект скорее тренировка ума в упражнении с Альтерой, чем потребность в конкретном "железе". Мне приятно, что моя позиция и ewgeny7 совпадают: сделать законченное и повторяемое! устройство для конкретных дел. А уже потом игрушка для just for fun. Согласен с ERROR404, что нет программистов для Ориона. Ну, что ж! Орион, как Орион - остался в прошлом. Этим все объясняется. А вот если будут писать программы для самих себя под контроллер на базе Ориона, решая какие-то свои проблемы, а не всего "человечества" - уже не плохо. Не зря, значит, трепыхаемся.
Я решил привести (естественно, с разрешения) наши частные дискуссии с ewgeny7. Думаю это будет интересно всем.
...мне нужно время довести проект до логического конца. К сожалению я не могу всё свободное время быть орионщиком.
Я с этим согласен. Но может быть не следует все взваливать только на свои плечи. К примеру, утряску элементной базы, оптимизацию схемотехники, платами, да и конструктивом в целом, мог бы я заняться. Это здорово бы разгрузило Вас. Мне представляется, что в настоящее время необходимо сделать относительно законченный вариант основной платы контроллера. Далее, сделать печатную плату контроллера и к ней можно будет (на первом этапе) подключить макетную плату для доводки "потрохов" Ориона. Это позволило бы распараллелить работу и начать работу программистов над ПО контроллера.
Кроме того, Вы юзаете проект в одном экземпляре, а значит всех "блох" не отловите. Надо, чтобы кто-то еще "юзал" Ваш проект. Разработчик всегда "нажимает кнопки" правильно.
Поскольку всё уперлось в тотальную переделку Ориона под новый чип и вывод системной шины, могу предположить, что ЭТОТ вариант будет уже реальным прототипом готового устройства.
Надо четче определиться со схемотехникой и разводить "предсерийную" плату. И уже на этой плате доводить проект до ума. Мне представляется проблематичным применение 29С010. Это старье уже исчезает, да и программатор надо городить. Думаю следует ориентироваться на шину SPI или I2C. С программированием этого добра нет проблем. Считаю целесообразным из Альтеры вывести отдельные шины SPI и I2C и их буфферировать. В настоящее время очень много разных и вкусных
чипов на этих шинах. А что интересного на паралельной шине? - уже ничего! Это утилитарный атавизм? Ведь обкатывая программу в контроллере, приходится многие десятки раз перепрограммировывать внутреннюю флеш. Представляете сколько раз необходимо будет вытащить 29С010 из панельки, перепрошить и вновь вставить. Или придумывать какой-нибудь "огород". В Альтере должен быть загрузчик, который знает, как и что считать из ПЗУ (смотря с какого!) и посадить в ОЗУ (куда надо!). И передать управление. Обратите внимание, в ПЗУ контроллера может быть (и скорее всего!) не Монитор-2 от Ориона, а другая управляющая программа под конкретное изделие! А вот старое ПЗУ (можно и 29с010 - она прошивается один раз!), орионовское, разместить на доп.плате Ориона. Не сложно у Альтеры задействовать один вывод, чтобы определить: подключена плата расширения - грузиться с ПЗУ платы расширения. Нет - грузиться с внутренней I2C(SPI)-флеш. Чтобы прошить SPI или I2C флеш, достаточно подключиться (плату контроллера) к LPT или COM-порту. Программаторов - навалом!
Я постараюсь сделать мощную библиотеку для контроллера (как в Орион-ПРО), где будет полный набор всех драйверов (в том числе и для шины SPI и I2C), а так же мощные графические функции, которые позволят легко создавать оконный интерфейс. Это значительно упростит написание прикладных программ. Может быть стоит их прошить в загрузочном ПЗУ контроллера и уже сразу пользоваться как и функциями Монитора в Орионе?
На основной плате непосредственно сам "контроллер", оснащенный видеовыходом, всеми внутренними портами, РОМ-диском и интерфейсом с клавиатурой ПЦ. О структуре можно судить по выложенной мною блок-схеме. Все необязательные компоненты типа инчестера или CF будут подключаться к шине расширения. Это придаст устройству универсальность в применении.
Не совсем согласен. Сам контроллер должен иметь минимум внешней обвязки. Не следует в контроллер запихивать весь Орион-128. Кому будет нужен Орион - пусть подключают дополнительную плату, где будут все его остальные "потрохи". Я уже говорил, что необходим VGA-выход (60гц) на ЖКИ-монитор. А TV-виход для телевизора - 50гц. А кто-то на них плюнет, и подключит LCD-индикатор. RS-232. И максимальная тактовая частота процессора. Сомневаюсь, что на основной плате следует ставить "сундуки" 82С55 в DIP-корпусах. Я что-то нигде не могу найти их в корпусах PLCC, а значит - это дифцит. Да и вообще, это тоже старые исчезающие микросхемы. Может быть на основной плате стоит поставить несколько двунаправленных портов (структуру этих портов можно обсудить отдельно) по примеру PIC или AVR? Можно эти порты разместить на других ("левых"!) адресах и сделать к ним обращение только по IN/OUT. А вот на дополнительной плате, которая и превращает контроллер в Орион-128, и разместить ВВ55! Да хоть 5шт.! На этой же плате можно разместить IDE и все остальное, что на изобретали для Ориона. Как Вы на это смотрите?
Да, я все-таки рискнул применить другой чип памяти, организации 256кб х 16бит. Эти чипы по небольшой цене можно легко найти в Петербурге и Москве.
Организация памяти примененного чипа - это не столь важно. У Вас на схеме 61c1024, а это - древние микросхемы! Я попробовал в einfo.ru искать 61c1024 - и ничего нет. Только одна фирма под заказ, и то в С.Петербурге. А вот 61c256 - навалом. Это очень плохо! Реплики на форуме о том, что можно с видеокарт выпаивать - не серьезно. Я посмотрел каталог московских фирм. Есть куча новых SRAM 128х8 чипов разных фирм. Вот только цоколевка у них с 61С1024 не совпадает. Но может быть применить один чип 128х16? Я поискал чип (к примеру) CY7C1011DV33 (128х16, 10ns, 120-150руб.), так его продает (по einfo.ru) - 17 фирм! Считаю необходимо хорошо продумать элементную базу, прежде чем ставить "точку", а пару штук CY7C1011DV33 я могу Вам выслать. Определитесь: они Вам подходят в проект?
И еще. to ERROR404:
Очень хорошо было бы сделать вариант Вашего эмулятора под этот контроллер (именно контроллер!). При этом сделать общую оболочку и объединить какой-нибудь редактор и транслятор кросс-ассемблера. Получилась бы среда разработки, где можно было бы программу писать и обкатывать на РС, а затем "запихивать" ее в контроллер через LPT или COM. Это было бы уже достаточно серьезное начало с инструментальной поддержкой контроллера!
Конечно, можно запустить имеющийся эмулятор, под ним орионовский редактор и ассемблер и т.д., но это уже не тот уровень для сегодняшнего дня. Что скажете по этому поводу, уважаемый коллега?
Парочка вопросов:
1. Банальное :) Нужно ли вводить доп. порт для цвета бордюра? Я сделал ради эксперимента, забавно получается. Как на спектруме, целиком белый экран с черными буковками. Использовал биты D0-D2 порта FE. Траурно-черный квадрат как-то некошерно смотрится с цветом на основном поле.
2. pvlad предложил использовать I2C-интерфейс. Вывести три-четыре ноги альтеры на поддержку нетрудно. Обслюживать интерфейс за неимением МК на борту придется процессору Ориона. Я вижу сие так - ПЗУ БИОС на плате Ориона, содержащий стартовый драйвер I2C. Загружает рабочую программу (монитор или что там будет) из I2C-ПЗУ в ОЗУ и передает ей управление. В общемто я уже начал претворять это дело в жизнь, ибо интересно самому. Но здесь все равно не обойтись без базового ПЗУ на параллельной шине. Если удастся разобраться как сделать доступной для процессора содержимое конфигурационного ПЗУ альтеры, то надобность в нем отпадет.
Ведь обкатывая программу в контроллере, приходится многие десятки раз перепрограммировывать внутреннюю флеш.
Зачем? Эмулятор на что? Да и электронный CMOS-диск еще никто не отменял.
Кстати, а кто нам мешает программировать флешь прямо на Орионе? Но это уже к программистам.
Я уже говорил, что необходим VGA-выход (60гц) на ЖКИ-монитор. А TV-виход для телевизора - 50гц.
Тут уже может будет проще договориться ТОЛЬКО о VGA?
Сомневаюсь, что на основной плате следует ставить "сундуки" 82С55 в DIP-корпусах.
А зачем на основной плате 82С55? Контроллер клавиатуры находится внутри альтеры, снаружи только два диода и два резистора.
РОМ-диск также не добавил на плате ни одной детали. Стоит одна ПЗУшка, прошитая в старших адресах Монитором, в остальных - РОМ-диск. Здесь 82С55 также не нужна.
Еще раз повторю на всякий случай, что есть на плате:
1. ПЛИС
2. Конфиг-ПЗУ для запуска ПЛИСы.
3. RAM организацией 16бит
4. flash-ROM с Монитором и РОМ-диском.
5. Генератор на 74ALS04 с кварцем 20Мгц.
Вроде совсем немного :)
Бонусом может подключаться 82С55 + 74ALS04 для винчестера/CF.
Я попробовал в einfo.ru искать 61c1024
Это обобщающая маркировка. Они могут обозначаться и как 7С1024, например.
Вообще, современные чипы весьма легко заменяют друг дружку. На каждый чип можно найти вагон аналогов. Учитывая, что и цоколевка является стандартной...
Но может быть применить один чип 128х16? Я поискал чип (к примеру) CY7C1011DV33 (128х16, 10ns, 120-150руб.), так его продает (по einfo.ru) - 17 фирм!
Да как хотите. Я пользуюсь тем, что есть под рукой. Тот, кто будет разводить плату, тот и будет определять какой чип ставить ;)
Определитесь: CY7C1011DV33 они Вам подходят в проект?
Да, у меня вначале стояла именно этой конторы ОЗУшка, но только 64кб/16бит. Работает до сих пор прекрасно.
К примеру, утряску элементной базы, оптимизацию схемотехники, платами, да и конструктивом в целом, мог бы я заняться.
Я подготовлю Вам наборчик документации, на основе которых можно будет начать "раскидывать" элементы по печатной плате и начинать разводку.
Художник из меня от слова "худо", поэтому извиняйте :)
Вот два файлика в архиве. Так сказать, две первые страницы к схеме Ориона на ПЛИС. Если такой формат годится, то продолжу.
pvlad, это, собственно, для Вас :)
ewgeny7, может сделаете загрузку "BIOS" из 24С16 по I2C?, т.е. при включении проц останавливается, а альтера вычитывает содержимое еепром в озу, а потом разрешает работу проца, правда тогда прийдеться откусить 2Кб памяти от озу чтоб в режиме FullRAM содержимое не затерлось. Даташыт прилагаю, см. 10 и 12 стр. режим SEQUENTIAL READ.
ewgeny7, может сделаете загрузку "BIOS" из 24С16 по I2C?,
А чем читать I2C? Для этого нужен или проц с ПЗУ, или микроконтроллер. Т.е. с чего начали, тем и закончили :)
Конечно, наверное можно сваять спецконтроллер прямо в альтере, но это будет сложно и ресурсоемко, по сути дела специализированный микроконтроллер. Может, кто-нибудь предложит путь попроще (я просто не знаю всех вариантов), я обещаю попробовать :)
А в Альтере счётчик разве нельзя организовать? После ресета установить его в определённое значение, младшие несколько битов использовать для "программы", а остальные - как адрес.
Я это предложил именно потому что это не сложно... Надо поискать уже готовый код под это дело...
b2m, поясни, чет я не понял :(
Счетчики можно любые, насколько извращенной фантазии хватит :)
---------- Post added at 21:47 ---------- Previous post was at 20:50 ----------
Мдя, посмотрел на opencores ядра I2C. Застрелиться... И особенно "прожорливость" порадовала - около 1000 ячеек. У нас свободных осталось около 300.
Ну это нафик. Параллельная шина итак выведена, ПЗУшки в ДИП трудновато найти, но в PLCC вполне себе продаются и производятся. Мож ими и ограничимся?
Error404
08.10.2009, 22:02
Ну это нафик. Параллельная шина итак выведена, ПЗУшки в ДИП трудновато найти, но в PLCC вполне себе продаются и производятся. Мож ими и ограничимся?
Думаю, пока да, все же ПЗУ - не самая главная задача. Да и в дипе полно этого продается. Хоть EPROM, хоть flash 5v.
Еще одна просьба к железячникам - кто-нибудь пользовался стабилизаторами на 1.5 вольта? какой чип лучше использовать?
b2m, поясни, чет я не понял
Допустим операция загрузки байта имеет 8 операций
0. выдать адрес источника на шину адреса
1. выдать сигнал чтения (например из ПЗУ)
2. скопировать шину данных в регистр
3. снять сигнал чтения
4. выдать адрес приёмника на шину адреса
5. выдать на шину данных значение регистра
6. выдать сигнал записи (например в ОЗУ)
7. снять сигнал записи
Можно использовать counter[0:2] как шаг вышеприведённой программы, а counter[3:15] как адрес (ну или его часть). Т.е. сигнал чтения из ПЗУ будет активным, когда counter[0:2] равен 1 или 2, и т.п.
---------- Post added at 23:37 ---------- Previous post was at 23:27 ----------
На практике, при использовании I2C выдача адреса может растянуться и на 32 шага...
sergey2b
08.10.2009, 22:38
если будет орион на de1 я обязательно попробую его
помоему с программами вопрос решаеться использованием cp/m
в чем будет приимущество ориона мирконотролерра перед avr+внешний sram+sd card (этот комплект можно собрать сейчас вместе с psb примерно за 20$ + ,будет нормальный asm+C+нормальный отладчик с PC на jatag). уже сейчас можно avr использовать с ps2 клавиатурой и TV выходом
в чем будет приимущество ориона мирконотролерра перед avr+внешний sram+sd card (этот комплект можно собрать сейчас вместе с psb примерно за 20$
Это мне тоже не совсем понятно. Но это будет именно Орион :)
Error404
09.10.2009, 12:02
в чем будет приимущество ориона мирконотролерра перед avr+внешний sram+sd card (этот комплект можно собрать сейчас вместе с psb примерно за 20$ + ,будет нормальный asm+C+нормальный отладчик с PC на jatag). уже сейчас можно avr использовать с ps2 клавиатурой и TV выходом
Он и не будет иметь никаких преимуществ, кроме "привычности" для бывших Орионщиков, за что собственно и ведется вся борьба, как я понимаю. Z80, CPM, общие архитектурные решения - все это знакомо и привычно.
Плюс, если это ПЛИС, то это фактически - еще и девборда для широкого спектра прочих конфигураций.
с программами вопрос решаеться использованием cp/m
Да, других вариантов вряд ли может быть для z80.
Банальное :) Нужно ли вводить доп. порт для цвета бордюра? Я сделал ради эксперимента, забавно получается. Как на спектруме, целиком белый экран с черными буковками. Использовал биты D0-D2 порта FE. Траурно-черный квадрат как-то некошерно смотрится с цветом на основном поле.
Банально, но если честно, то не знаю. Можно сделать.
pvlad предложил использовать I2C-интерфейс. Вывести три-четыре ноги альтеры на поддержку нетрудно. Обслуживать интерфейс за неимением МК на борту придется процессору Ориона. Я вижу сие так - ПЗУ БИОС на плате Ориона, содержащий стартовый драйвер I2C. Загружает рабочую программу (монитор или что там будет) из I2C-ПЗУ в ОЗУ и передает ей управление. В общемто я уже начал претворять это дело в жизнь, ибо интересно самому.
Очень приятно, что Вы поняли идею! Для этого не нужно использовать в Альтере ядро I2C. Это может делать сам Z80 + 2 однобитных порта. Конечно, реализовать I2C интерфейс будет немного проблемней, чем на однокристаллке - нет битовых операций у Z80, но можно. Мне тоже не терпится попробовать это без битовых операций.
Но здесь все равно не обойтись без базового ПЗУ на параллельной шине. Если удастся разобраться как сделать доступной для процессора содержимое конфигурационного ПЗУ альтеры, то надобность в нем отпадет.
Параллельное ПЗУ можно разместить на дополнительной плате. Если она подключена (флаговый вывод на системной шине) - грузитесь с параллельного ПЗУ. Нет - загрузка с AT24C16B, которая на основной плате контроллера. Мне кажется, это компромисс для "ваших" и "наших".
Я хочу еще раз подчеркнуть: не нужно из основной платы контроллера делать Орион! Это должна быть универсальная плата. Уверен, она будет стоить значительно дешевле DE0 или DE1. Возможно, кто-то вообще выкинет оттуда Орион и сделает что-то свое. Думаю, Вы тоже свой следующий проект уже будете городить не на макетке, а используете этот контроллер за основу.
Зачем? Эмулятор на что? Да и электронный CMOS-диск еще никто не отменял. Кстати, а кто нам мешает программировать флешь прямо на Орионе? Но это уже к программистам.
Понятно. Видно сразу, что вы не занимались на контроллерах управлением в реальном времени да и с разношерстной периферией. Какой же эмулятор с эмулирует всю эту периферию, которая в каждом конкретном случае разная? Да и вообще уместней, в данном случае, говорить об отладчике. Эмулятор для Ориона стало возможным создать только потому, что "железо" имело четкий, единообразный стандарт. И пока была возможность, авторы жестко это контролировали. Вектористам (и подобно им!) можно позавидовать, что туда не вмешались "Орион-Сервис" и "SP-Club". Для контроллера это не получится. Конечно, ту часть, которая будет стандартно находиться на основной плате и не будет меняться - ее можно эмулировать. А вот увидеть, как контроллер работает с периферийными устройствами, можно только прогоном программы на реальном контроллере.
Тут уже может будет проще договориться ТОЛЬКО о VGA?
Не согласен. Если исторически имеется TV-выход, то почему его надо блокировать. Наоборот! А если с Орионом захочется на даче посидеть? Там никаких мониторов нет, кроме телевизора. Да и зачем в цех тащить монитор (малогабаритные стоят достаточно прилично!), когда можно купить маленький китайский телевизор (гроши стоит!) и посмотреть.
Вот два файлика в архиве. Так сказать, две первые страницы к схеме Ориона на ПЛИС. Если такой формат годится, то продолжу. pvlad, это, собственно, для Вас
Спасибо, посмотрел. Не буду врать, но за более чем десятилетие, я здорово выпал из орионовской темы. Много чего забыл, и если честно, то временами чувствую себя не очень комфортно. Доставать с чулана свои Орионы мне уже не хочется. Думаю, было бы не плохо повторить Ваш проект на макетке, как и у Вас и повозится, "почувствовать руками". Может тогда мозги "оттают" и снова буду свободно оперировать "портами", "битами" и т.д.
Еще одна просьба к железячникам - кто-нибудь пользовался стабилизаторами на 1.5 вольта? какой чип лучше использовать?
Можно особо не мудрить и поставить LM317. Стабилизируют, начиная с 1,25в. В Инете есть калькуляторы для расчета. Там, собственно надо рассчитать делитель (2 сопротивления), в остальном как 7805. Их следует поставить две штуки - вторую для 3.3в.
Он и не будет иметь никаких преимуществ, кроме "привычности" для бывших Орионщиков....
Согласен, но частично. Коллега sergey2b невнимательно читал мой первый пост. Главное - это фоннеймановская архитектура процессора, а уже потом привычная среда для определенной части программистов. Если архитектура процессора не главный вопрос при решении задачи, то можно использовать PIC или AVR. Так и делается.
с программами вопрос решается использованием cp/m
Да, других вариантов вряд ли может быть для z80.
А что СР/М? Что она решает в плане появления нового программного обеспечения для Ориона? Или консольное наследие СР/М станет на Орионе красочным с менюшками, или программы от других компьютеров подойдут только потому, что их объединяет СР/М? Это всего-лишь файловая среда и не более. Windows, к примеру, кроме файловой среды имеет мощное графическое ядро (API), которое позволяет упростить создание интерфейса программ. Чем поможет СР/М? В этом плане я не вижу принципиальной разницы между СР/М и ORDOS.
Error404
09.10.2009, 17:37
А что СР/М? Что она решает в плане появления нового программного обеспечения для Ориона? Или консольное наследие СР/М станет на Орионе красочным с менюшками, или программы от других компьютеров подойдут только потому, что их объединяет СР/М? Это всего-лишь файловая среда и не более. Windows, к примеру, кроме файловой среды имеет мощное графическое ядро (API), которое позволяет упростить создание интерфейса программ. Чем поможет СР/М? В этом плане я не вижу принципиальной разницы между СР/М и ORDOS.
Мне CP/M интересна в первую очередь из-за средств разработки. Я прикипел к М80\L80 - другого ассемблера не хочу. :) А компилятор С из нативно работающих на Орионе, а не на РС? Тут вообще единственный нормальный для всего Z80 семейства это HiTech C для CP/M. А Турбо-Паскаль! [тут я вспомнил молодость]. Опять же, текстовые редакторы, позволяющие править файлы любого размера. Не, я уверен - такого уже никто не напишет.
-
Как сама система, CPM - ничего особенного. UZIX куда как интереснее (ну, на мой взгляд). :) Давайте портировать UZIX! Это может стать первым true-open-source для нового (и для старого тоже) Ориона. :v2_finge:
-
Ордос, если по хорошему, надо дорабатывать. Делать что-то подобное питерской RAMFOS. Чтобы можно было иметь файловую систему с файлами не ограниченными 60к.
Параллельное ПЗУ можно разместить на дополнительной плате. Если она подключена (флаговый вывод на системной шине) - грузитесь с параллельного ПЗУ. Нет - загрузка с AT24C16B,
Не, вы не поняли. "Параллельное" ПЗУ нужно для загрузки самого драйвера работы с I2C. Без параллельного ПЗУ компьютер/контроллер вообще никакой программы не получит. По той причине, что без драйвера прочитать АТ24 просто не сможет.
Вот и получается, что нужно обычное ПЗУ с драйвером (и набором системных программ) и I2C-ПЗУ типа АТ24 для самой исполняемой программы, которую можно будет править прямо на Орионе и сохранять в том же АТ24.
Error404
09.10.2009, 22:10
Не, вы не поняли. "Параллельное" ПЗУ нужно для загрузки самого драйвера работы с I2C. Без параллельного ПЗУ компьютер/контроллер вообще никакой программы не получит. По той причине, что без драйвера прочитать АТ24 просто не сможет.
Вот и получается, что нужно обычное ПЗУ с драйвером (и набором системных программ) и I2C-ПЗУ типа АТ24 для самой исполняемой программы, которую можно будет править прямо на Орионе и сохранять в том же АТ24.
Фактически, тогда получается что ПЗУ F800 (условно назовем его так) придется оставить как оно есть (параллельным), а все прочее что грузится по I2C - это получается фактически ROM-DISK (просто сейчас он параллельный и находится в том же ПЗУ, что и начальный загрузчик). Т.е. навыходе мы получим тоже что и было + еще одна ПЗУ?
Т.е. навыходе мы получим тоже что и было + еще одна ПЗУ?
Фактически да. Но будет один плюс - "последовательное" ПЗУ прошивается не только внешним программатором, но и средствами самого Ориона. Запись на него производится не сложней чем чтение. И в этом плане Орион будет удобнее и круче всех остальных контроллеров которым требуется ПЦ для разработки/отладки/прошивания софта. Ориону достаточно подключить клавиатуру и запустить ассемблер :)
Не, вы не поняли. "Параллельное" ПЗУ нужно для загрузки самого драйвера работы с I2C.
Тогда это уже "огород"! Это не профессиональное и лобовое решение. Я думаю надо придумать, чтобы исполняемый код загрузчика находился в ресурсах самой Альтеры. Альтера переносит код в ОЗУ контроллера (можно с адреса 0000Н) и выдает RESET. Запустится загрузчик, и уже он сам решит решит откуда и кого грузить.
Если окажется, что параллельное ПЗУ неизбежно, тогда бессмысленно дополнительно вешать еще последовательное. Давайте думать.
Мне CP/M интересна в первую очередь из-за....
Я с пониманием отношусь к Вашему пристрастию, но это субъективность. Вам, просто, нравится находиться в орионовской среде. И не более. Печально, но таких преданных поклонников не так много. Боюсь, что программисты, которые решатся что-то написать для Ориона, а вернее написать под контроллер, без сомнения захотят это делать на РС. Увы!
UZIX куда как интереснее....
Если не сложно, то расскажите об этом проекте. Мне очень интересно.
Ордос, если по хорошему, надо дорабатывать...
Нет! Ее трогать бессмысленно. Она хорошая/плохая такая какая есть - маленькая, примитивная. У нее была своя ниша. Любое добавление к ней будет согласно армейской поговорке: кто такой ефрейтор? Это недое... сержант или перее... солдат! Так будет и здесь. ОРДОС никогда не станет даже тенью СР/М, и не нужно к этому стремиться. Поэтому если возникает ситуация когда она применима, и это лучшее решение - стоит применять. Например при работе контроллера с небольшим РОМ-диском. Здесь глупо запрягать СР/М. А вот если необходимо манипулировать с большим количеством файлом, или сохранять большое количество информации - тут СР/М к месту. Единственное: не уверен, что "хард", на сегодняшний день, актуальное решение. Считаю флеши - более перспективно. Во всех отношениях: малые габариты, енергопотребление, доступность.
Error404
10.10.2009, 18:14
Боюсь, что программисты, которые решатся что-то написать для Ориона, а вернее написать под контроллер, без сомнения захотят это делать на РС. Увы!
Ну, я в-общем то тоже редко беру в руки реал, 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
11.10.2009, 15:37
Я думаю надо придумать, чтобы исполняемый код загрузчика находился в ресурсах самой Альтеры. Альтера переносит код в ОЗУ контроллера (можно с адреса 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 вообще эмулируется множество машин, не только Орионы. В-общем, когда появится что-то близкое к финальному варианту (желательно хотя бы что-то в железе, на чем можно проверить соответствие эмуляции), думаю, за эмулятором тоже не заржавеет.
Black_Cat
11.10.2009, 15:39
для Z80 есть CPM в исходниках, работающая как раз с MMC/SD:) и что Z80 так вот совсем без ПЗУ общается с MMC/SD? ..а программный интерфейс откуда он берёт? :)
Error404
11.10.2009, 15:55
:) и что Z80 так вот совсем без ПЗУ общается с MMC/SD? ..а программный интерфейс откуда он берёт? :)
Телепатически. :)
Конечно, в том проекте есть ПЗУ.
И тут тоже будет эмулятор "небольшого параллельного ПЗУ" в Альтере. Речь, как я понимаю, о другом - что в отдельном от ПЛИС корпусе (т.е. "в железе") никакого параллельного ПЗУ не будет.
У svofski тоже загрузчик непосредственно в Альтере живёт, целых 512 байт.
И тут тоже будет эмулятор "небольшого параллельного ПЗУ" в Альтере. Речь, как я понимаю, о другом - что в отдельном от ПЛИС корпусе (т.е. "в железе") никакого параллельного ПЗУ не будет.
В общем то да. В Альтере находится только код загрузчика, который знает как считать, посадить в ОЗУ код второго загрузчика из последовательного ПЗУ. Такая двух-этажная загрузочная структура уже применяется при загрузке СР/М и на Орионе-128 из под ОРДОС и в Орион-ПРО. Что же здесь нового? Второй загрузчик из последовательного ПЗУ может быть чем угодно. Мудрите с ним как хотите. Последовательное ПЗУ можно просто прицепить к ножкам порта ПС и прошить любой загрузчик "своей системы". С параллельными EPROM или Flash это так просто не сделать. Да и старье все это! Необходимо применять современные чипы.
Думаю в Альтере это можно сделать следующим образом (уже эта идея высказывалась на форуме): аппаратный счетчик перебирает адреса и читается из Альтеры (не знаю конкретно откуда!) и записывается байты в ОЗУ. Далее аппаратный ресет. Но последнее слово за Евгением. Структуру "шапки" загрузчика в последовательном ПЗУ можно взять из ОРДОС и не выдумывать что-то еще. "Альтеровский" загрузчик прочитав "шапку" уже будет знать сколько байт и куда перенести, и по какому адресу передать управление.
Думаю в Альтере это можно сделать следующим образом (уже эта идея высказывалась на форуме): аппаратный счетчик перебирает адреса и читается из Альтеры (не знаю конкретно откуда!) и записывается байты в ОЗУ. Далее аппаратный ресет.
Не надо никаких счётчиков, ПЗУ загрузчика учитывается при проектировании маппера памяти и включается только после сброса по нулевым адресам, а выключается при доступе к определённому порту, одновременно происходит повторный "программный" сброс. При этом можно сделать как в Векторе, чтение из ПЗУ, а запись в ОЗУ, находящимся под этим ПЗУ.
это типо 512 макроячеек, или как-то менее расточительно можно?
Это svofski может сказать.
Я делал это в самом начале проектирования Ориона. имею ввиду некоторое количество байт прямо в альтере. Это делается просто, но отжирает реально примерно байт на ячейку. Вначале я вообще хотел Монитор в альтеру запихнуть, но всего три тысячи ячеек в ПЛИС охладили мой пыл. В общемто, ячеек 200 могу дать вам на растерзание. Уложитесь?
Error404
11.10.2009, 18:59
В общемто, ячеек 200 могу дать вам на растерзание. Уложитесь?
Наврядли
Можно попробовать скомбинировать код загрузки для процессора и сдвиговые регистры для преобразования последовательного кода в параллельный, чтобы на уровне программы осталось лишь считать байт из порта или записать адрес в порты.
... ячеек 200 могу дать вам на растерзание. Уложитесь?
Я думаю, можно проанализировать написанное и попробовать оптимизировать. Далее. Выкинуть все лишнее, что относится чисто к Ориону. Зачем внутри Альтеры эмулировать что-то для чтения РОМ-диска, порты IDE и т.д. Мы же договаривались, что все орионовское выносим на дополнительную плату. Там можно в оригинале поставить всякие ВВ55, а можно все сделать на отдельной, второй Альтере. Думаю, на Альтере даже дешевле будет, чем на россыпухе. Более того, можно по серьезному заняться отдельно периферией. Ячеек будет навалом на всякие эксперименты. А здесь мы оставляем сам контроллер, делаем порты, как я писал выше и остальное, что задумывалось для контроллера. При этом поместится загрузчик и останутся ячейки на исправление просчетов и ошибок.
Что еще важно. Если весь Орион мудрить на одной Альтере, то "совершенствованию" и возне не будет конца. Я с Орион-ПРО на этом погорел, но это отдельный разговор. Должны быть какие-то законченные, промежуточные этапы, опираясь на которые можно двигаться дальше.
В крайнем случае, когда проект подойдет к финалу (будем надеяться!) вот в таком варианте, как я предлагаю, можно подобрать "большую" Альтеру и все туда запихнуть, если без этого "орионовци" не смогут жить!
Наврядли
Можно даже не гадать. А взять готовые исходники чтения/записи 24С16 на Скорпионе.
Я пытаюсь найти их у себя, но нуно потрясти spensor'a и savelij.
Если склероз мне не изменяет, то там даже меньше 200 байт...
Там выполняется переброска из 24С16 в ОЗУ и обратно.
Error404
11.10.2009, 21:46
Можно даже не гадать. А взять готовые исходники чтения/записи 24С16 на Скорпионе.
Я пытаюсь найти их у себя, но нуно потрясти spensor'a и savelij.
Если склероз мне не изменяет, то там даже меньше 200 байт...
Там выполняется переброска из 24С16 в ОЗУ и обратно.
Вот что нужно для чтения с SD/MMC. На взгляд, тут поболее 200 байт будет:
sd_select:
call sd_fini
or SD_CS ; select, still idle data
out (RTC), a
ret ; af b trashed
sd_fini:
ld b, 17 ; clock low high low high ... low, 8 pulses
sd_wiggle:
ld a, SD_DOUT ; unselected, idle data
L1:
out (RTC), a
xor SD_CLK
djnz L1
ret ; af b trashed
sd_put: ; byte from a
ld c, a
ld b, 8
L3:
ld a, SD_CS >> 1 ; 7 msbits
rl c
rla ; SD_DOUT is RTC.0
out (RTC), a ; clock is low
or SD_CLK
out (RTC), a ; rising clock edge
djnz L3
and ~SD_CLK
out (RTC), a ; leave with clock low
ret ; af bc trashed
sd_get: ; byte to a
ld b, 8
L2:
in a, (RTC)
rla ; SD_DIN is RTC.7
rl c
ld a, SD_CS | SD_DOUT | SD_CLK
out (RTC), a
and ~SD_CLK
out (RTC), a
djnz L2
ld a, c
ret ; af bc trashed
; command in a, includes fixed msbits
; arg32 in dehl
; z return, if R1 (in a) is 0
sd_command_no_arg:
ld hl, 0
sd_command_word_arg: ; fits in HL
ld de, 0
sd_command: ; command in a, dword arg in dehl
call sd_put ; command includes fixed 01 startbits
ld a, d ; arg
call sd_put
ld a, e
call sd_put
ld a, h
call sd_put
ld a, l
call sd_put
ld a, 095h ; crc7 only valid for initial CMD0
call sd_put ; DOUT ends up idle because of the stopbit
ld hl, 20000 ; XXX timeout XTAL dependent
L4:
call sd_get ; R1 response, when msbit is clear
or a ; zero and sign valid
ret p ; R1 in a. z if ok
dec hl
bit 7, h ; until HL wraps negative
jr z, L4
ret ; 0x80 | ? in a, nz
; command response R1
; 0x00 ok
; or bitfield
; 0x01 idle state
; 0x02 erase reset
; 0x04 illegal command
; 0x08 command crc error
; 0x10 erase sequence error
; 0x20 address error
; 0x40 parameter error
; 0x80 timeout (other bits meaningless)
;
; packet token
; 0xFF none yet
; 0xFE ok
; or bitfield
; 0x01 error
; 0x02 controller error
; 0x04 media ecc failed
; 0x08 out of range
; 0x10 card is locked
sd_wait_token:
ld hl, 20000 ; XXX timeout XTAL dependent
L5:
call sd_get ; token is first non-FF
cp 0FFh
ret nz ; token in a
dec hl
bit 7, h ; until HL wraps negative
jr z, L5
ret ; FF in a
sd_wait_busy:
ld hl, 20000 ; XXX timeout XTAL dependent
L6:
call sd_get ; 8 clocks. data output activates after 1 clock
inc a ; FF is not busy
ret z ; z, ok. a=0
dec hl ; else busy or something
bit 7, h ; until HL wraps negative
jr z, L6
ret ; nz, timeout
CMD0 equ 040h | 0 ; resets the card
CMD9 equ 040h | 9 ; read CSD
CMD10 equ 040h | 10 ; read CID
CMD16 equ 040h | 16 ; set R/W block
CMD17 equ 040h | 17 ; read block
CMD24 equ 040h | 24 ; write block
CMD55 equ 040h | 55 ; next command is ACMDxx
ACMD41 equ 040h | 41 ; send host capacity support, init card
; byte offset in dehl
; z return if ok
sd_read_block:
ld a, CMD17 ; READ_SINGLE_BLOCK
call sd_command ; dehl byteaddress
ret nz ; not "ok"
call sd_wait_token ; packet start or FF if timed out
cp 0FEh
ret nz ; or error
ld hl, (rwaddr)
ld e, 128 ; loop counter
L9:
call sd_get ; data
ld (hl), a
inc hl
dec e
jr nz, L9 ; do the sector
call sd_get ; crc16
ld h, a
call sd_get ; in HL
ld l, a ; crcs are not used
xor a ; zero, no carry
ret
sd_setup:
call sd_select
call sd_wait_busy ; nz if timed out, z a=0 if ok
ret nz
; A is 0 from sd_wait_busy.
; byte address to dehl from TRACK, SECTOR
; when spt 256 and sector 128
ld hl, (sectorx) ; sector to h, zero to l
ld de, (track) ; adehl (TRACK << 16) | (SECTOR << 8) | 0
IF 0
srl d
rr e
rr h
rr l ; dehl sector * 128
xor a ; z, ok. cannot overflow
ELSE
; XXX XXX XXX XXX easy way out
add hl, hl
rl e
rl d ; dehl sector * 512
adc a, a ; z, if ok
ENDIF
ret
sd_read:
call sd_setup
call z, sd_read_block
sd_done:
push af
call sd_fini
call rtc_unselect ; /CS high, clock and dout low
pop af
jp nz, rw_fail
xor a
ret
Black_Cat
11.10.2009, 22:04
На взгляд, тут поболее 200 байт будетнасамделе вы по-моему зря упёрлись в эти 200 байт.. Всё можно сделать по другому:
1) из конфПЗУ грузится временная конфигурация с загрузочным ПЗУ хоть на все 3к ячеек
2) Z80 стартует с загрузочным ПЗУ и грузит с флеши в ОЗУ системное ПЗУ компа
3) в конфПЗУ загружается с флеши новая конфигурация уже реального компа
4) производится рестарт FPGA с загрузкой окончательной конфигурации при уже загруженном в ОЗУ системном ПЗУ
5) Z80 стартует с системным ПЗУ и загружает с флеши в конфПЗУ опять временную конфигурацию
6) подготовка закончена - комп начинает работать
БК-0010, Z80 также содержится в прошивке конфПЗУ и сжирает более 2000 ячеек.
Грузить в конфПЗУ с флеши - яким таким макаром? А как насчет ограниченного всё-таки числа записей в конфПЗУ?
В общем, вот исходы работы с 24С16 в Скорпионе. Размеров не пугайтесь, там реально нужен небольшой кусок.
Для справки - NVRAM - это и есть 24С16, работа с ней идет через системный порт FFBA. Бит D4 - SDA OUT, D5 - WP, D6 - SCL OUT и SDA IN.
Кстати, 24С16 я уже прикошачил на плату Ориона... :)
Я делал это в самом начале проектирования Ориона. имею ввиду некоторое количество байт прямо в альтере. Это делается просто, но отжирает реально примерно байт на ячейку.
А можно код посмотреть, в смысле как это делалось, т.к. альтеровцы пишут что в EP1C3 примерно 7,5Кб озу и оно не должно отжирать макроячейки...
http://www.altera.com/products/devices/cyclone/overview/cyc-overview.html
Total RAM Bits 59,904
ОЗУ альтеры не причем.
Организуется массив внутри самих LE, типа std_logic_vector большой длинны с предустановленным содержимым. Из этой длинной цепочки и читаются данные.
В архивчике два моих примера реализации прошивок 554РТ11 Скорпиона на VHDL. Посмотреть можно в "блокноте".
http://www.zx.pk.ru/attachment.php?attachmentid=12003&d=1242507375
Black_Cat
11.10.2009, 23:03
Грузить в конфПЗУ с флеши - яким таким макаром? А как насчет ограниченного всё-таки числа записей в конфПЗУ?тоды поставить пару конфПЗУ и переключать загрузку с одной на другую.. если конечно нельзя как-то обойтись одной, но с выбором половинок..
А svofski делал по другому, и по-моему, он как раз использовал внутреннее ОЗУ. Это ОЗУ можно проинициализировать при загрузке конфигурации, так вроде.
Это ОЗУ можно проинициализировать при загрузке
Если это так, то проблема решена. Но я не слышал, чтобы ОЗУ ПЛИС можно было предустановить. Перенести в него данные с 24С16 и использовать как ПЗУ - это понятно. Буду курить доки.
to ewgeny7:,
to b2m:,
to БК-0010:
Коллеги! Вы молодцы! Похоже, что-то и получится!
to Erroe404:
Использование SD/MMC очень важно в этом проекте, но только не для начальных загрузчиков. SD/MMC - это достаточно не однозначная вещь, разная по емкости, иногда есть отклонения от протокола в зависимости от производителя и т.д. Я думаю, что SD/MMC надо применить вместо IDE для работы СР/М. Вы не хотели бы довести до ума этот вопрос, как самый действенный и опытный системный орионовский программист? Собственно, кроме Вас , в этом вопросе, "страну защитить некому"!
Но я не слышал, чтобы ОЗУ ПЛИС можно было предустановить. Перенести в него данные с 24С16 и использовать как ПЗУ - это понятно.
Это уже "заднепроходный" метод, я просто забыл о внутреннем озу альтеры, оно инициализируется из конфиг ПЗУ, т.к. что во внешнем пзу необходимость отпадает (правда ром диск тогда тоже отпадает)
---------- Post added at 23:27 ---------- Previous post was at 23:03 ----------
Сейчас смотрел в квартусе: megafunctions -> storage -> lpm_rom Дальше с визардом думаю будет понятно...
Это уже "заднепроходный" метод, я просто забыл о внутреннем озу альтеры, оно инициализируется из конфиг ПЗУ, т.к. что во внешнем пзу необходимость отпадает (правда ром диск тогда тоже отпадает)
Нет, нет! Внешнее последовательное ПЗУ мы оставляем! Иначе у простых смертных программистов не будет "пространства для маневра". Кто же полезет в Альтеру каждый раз переделывать загрузчик? А так, во внешнем ПЗУ (функционально оно ничем не отличается от паралельного) вы можете творить все, что угодно. Главное записать в первых ячейках параметры вашего "творчества"! И грузите что хотите и куда хотите, в том числе, и то, что касается РОМ-диска. Кстати, РОМ-диск, Вы можете устроить и в загрузочном последовательном ПЗУ, если у него достаточный объем. Что мешает? Можете там разместить СР/М, а на SD/MMC (IDE) будут размещаться только файлы.
Какое Ваше мнение Error404 по поводу такого размещения СР/М?
Error404
12.10.2009, 00:44
Я думаю, что SD/MMC надо применить вместо IDE для работы СР/М. Вы не хотели бы довести до ума этот вопрос
Можно сделать чтобы было и IDE и SD/MMC (SD повесить на какой-то другой порт, например). Собственно надо в саму CP/M встроить готовые подпрограммы для еще одного устройства, и написать загрузчик, работающий из ОРДОС. Проблема в том, что мне не на чем это отлаживать (у меня, фактически, только эмулятор), в котором сначала надо сделать эмуляцию SPI. :)
Начну думать на эту тему, а там уж как пойдет... Опять же, надо знать как оно будет "в железе".
---------- Post added at 00:44 ---------- Previous post was at 00:34 ----------
Кстати, РОМ-диск, Вы можете устроить и в загрузочном последовательном ПЗУ, если у него достаточный объем. Что мешает? Можете там разместить СР/М, а на SD/MMC (IDE) будут размещаться только файлы.
Какое Ваше мнение Error404 по поводу такого размещения СР/М?
CP/M это 17к кода, которые начальным загрузчиком загружаются в память, а затем уже как-то работают с "дисковыми" устройствами. В принципе, совершенно все равно откуда ее грузить, можно и из ROM-DISK. С другой стороны, 17к на системной дорожке тоже не жалко (при нынешних емкостях носителей). Тут надо смотреть кому как удобнее. Мне, т.к. у меня код ОС меняется по 10 раз на дню, удобнее обновлять код на HDD, чем перепрошивать ROM. В-общем, не скажу ни "за" ни "против" сходу.
....С другой стороны, 17к на системной дорожке тоже не жалко (при нынешних емкостях носителей)...
...Тут надо смотреть кому как удобнее. Мне, т.к. у меня код ОС меняется по 10 раз на дню, удобнее обновлять код на HDD, чем перепрошивать ROM...
1. Совершенно верно. Просто я имел ввиду, что если на SD/MMC не размещать системные дорожки, то это упростит совместимость с ПС.
2. Не спорю, но это частный случай. В готовом "изделии" (не для разработчика) такой проблемы не будет.
Error404
12.10.2009, 11:13
1. Совершенно верно. Просто я имел ввиду, что если на SD/MMC не размещать системные дорожки, то это упростит совместимость с ПС.
Совместимость с РС и так никуда не денется, ведь CPM грузится и далее файлово работает с отдельной "не-FAT" партицией (в партиции создается файловая система CPM). В то же время на том же носителе могут быть рядом размечены и другие партиции (FAT) с которыми работает РС. Конечно, для копирования из CPM-партиции в FAT-партицию нужны дополнительные утилиты (как на РС, так и на Орионе). На Орионе такая утилита мной написана - fat.com (частично портирована, частично написана). На РС пока возможно пофайлово работать только с образом CPM-партиции, а образ партиции считывать и записывать целиком (но это от лени - можно сделать чтобы и писало напрямую в носитель).
Нет, нет! Внешнее последовательное ПЗУ мы оставляем! Иначе у простых смертных программистов не будет "пространства для маневра". Кто же полезет в Альтеру каждый раз переделывать загрузчик?
В Альтеру лазить не надо, конфиг-ПЗУ достаточно большое, чтобы разместить там и конфигурацию Альтеры и свои данные. Другое дело, что запись в конфиг-ПЗУ со стороны контроллера в случае глюка может повредить конфигурацию Альтеры, но это вопрос вкуса - можно и второе последовательное ПЗУ поставить.
можно и второе последовательное ПЗУ поставить.
Это не есть гуд. Расточительно получается.
Надо в конфПЗУ хранить только начинку альтеры и загрузчик из последовательного ПЗУ в ОЗУ. И всё. Это придаст устройству необходимую универсальность.
Подключил сегодня для экспериментов I2C-ROM АТ24С16.
Выделил ему порт FFBAh, как и на Скорпионе.
Запись в порт:
D6 - SCL
D5 - WP
D4 - SDAOut
Чтение из порта:
D7 - 1
D6 - SDAIn
D5-D0 - 1.
Запись пока сделана и по IORQ и по MREQ. Чтение (по понятной причине) только IORQ.
Пробую писать простенький драйвер.
Подключил сегодня для экспериментов I2C-ROM АТ24С16.
Выделил ему порт FFBAh, как и на Скорпионе.
Запись в порт:
D6 - SCL
D5 - WP
D4 - SDAOut
Заводит защиту от записи на порт нет смысла. Нужна механическая блокировка на плате.
Заводит защиту от записи на порт нет смысла. Нужна механическая блокировка на плате
Мне тоже так кажется. Или вообще нафик убрать это разрешив запись постоянно.
Просто я банально скопировал подключение со Скорпиона.
---------- Post added at 17:10 ---------- Previous post was at 16:46 ----------
Да, кажется вопрос с предустановленной ОЗУ (ПЗУ) в массиве памяти ПЛИС решен.
Это дает возможность разместить драйвер чтения I2C-ПЗУ объемом до 7 килобайт на нашем чипе.
Семи килобайт вам хватит, в конце концов? ;)
---------- Post added at 17:14 ---------- Previous post was at 17:10 ----------
Тааак... А кто-нибудь знает как файл формата .bin или .rom переконвертировать в .hex?
Формат .hex очень простой. Каждая строка состоит из следующих байт (после двоеточия, каждый байт 2 символа):
1 байт - длина данных в строке, обычно 32, т.е. в hex - 20
2 байта - адрес/смещение от начала
1 байт - 00 для обычной строки, 01 для последней
xx байт - данные, обычно 32 байта
1 байт - контрольная сумма, сумма всех байт вместе с этим должна быть равна нулю
Последняя строка обычно выглядит так:
:00000001FF
.bin или .rom переконвертировать в .hex?
http://www.keil.com/download/docs/113.asp
Error404
12.10.2009, 17:49
Да, кажется вопрос с предустановленной ОЗУ (ПЗУ) в массиве памяти ПЛИС решен.
Это дает возможность разместить драйвер чтения I2C-ПЗУ объемом до 7 килобайт на нашем чипе.
Семи килобайт вам хватит, в конце концов? ;)
Может, тогда прямо в Альтере просто эмулировать 2к ПЗУ F800? ПЗУ F800 меняется редко - можно и КонфПЗУ задействовать под это. Прописать 3 варианта (если всего 7к, то Монитор 2к + Монитор 2к + Test-Ram 1к) и вывести из Альтеры 2 ножки где перемычками двоично выбирать какое ПЗУ из этих трех видно в F800...FFFF.
И в ПЗУ Монитора поправить загрузчик ORDOS, (чтобы оно грузило Ордос по I2C). ORDOS кстати тоже надо будет править чтобы оно работало по I2C.
А 24с16 будет сугубо ROM-DISK-ом в первых 64к и "чем угодно дополнительным" выше 64к. Это как оно могло бы быть при воссоздании архитектуры стандартного Ориона-128 (+Z Card)
Кстати, 24с16 какой емкости?
Кстати, 24с16 какой емкости?
2Кб, но есть и более емкие: http://atmel.com/dyn/products/devices.asp?family_id=647#1573
Error404
12.10.2009, 19:50
2Кб, но есть и более емкие: http://atmel.com/dyn/products/devices.asp?family_id=647#1573
Оказывается, микросхемки то недешевые. Если смотреть емкостью 64K и более, то среднестатистически, параллельные EEPROM/FLASH дешевле. Не ожидал, все же ножек у последовательных меньше... :)
Вопрос - а к чему тогда весь этот сыр-бор с преодолеванием трудностей подключения по I2C, если оно еще в итоге и дороже получается?
Вопрос - а к чему тогда весь этот сыр-бор с преодолеванием трудностей подключения по I2C, если оно еще в итоге и дороже получается?
Изза доставаемости. сейчас трудновато, а в будущем... В Петербурге флешек параллельных не найти, я их выдергиваю из старинных материнок.
Последовательные ПЗУ сейчас много кто делает. Искать можно по ключам 24С и 24LC. Скорость работы вот только... :(
Error404
12.10.2009, 21:29
Изза доставаемости. сейчас трудновато, а в будущем... В Петербурге флешек параллельных не найти, я их выдергиваю из старинных материнок.
Последовательные ПЗУ сейчас много кто делает. Искать можно по ключам 24С и 24LC. Скорость работы вот только... :(
В магазинах пока что есть. А потом... это же ведь тенденция - пройдет пять лет и с 24С-24LC будет такая же история.
Попробовал games2.ohi? Не портит при записи?
пройдет пять лет и с 24С-24LC будет такая же история
История последовательных ПЗУ только развивается. Кончатся 24 - пересядем на новые 45 с тем же I2C.
В магазинах пока что есть.
Уже отвечал. ПрофПЗУ не могу народу продавать, ибо нету подходящих флешек.
Попробовал games2.ohi? Не портит при записи?
Хорошо, что напомнил. Заберу образ на работу :)
ибо нету подходящих флешек.
Странно, т.к. даже в моей деревне их есть: http://kosmodrom.com.ua/product.php?name=at29
Мне тоже так кажется. Или вообще нафик убрать это разрешив запись постоянно. Просто я банально скопировал подключение со Скорпиона.
На плате поставим JMPер. Блокировать нужно, если это готовое изделие.
Да, кажется вопрос с предустановленной ОЗУ (ПЗУ) в массиве памяти ПЛИС решен. Это дает возможность разместить драйвер чтения I2C-ПЗУ объемом до 7 килобайт на нашем чипе. Семи килобайт вам хватит, в конце концов? ;)
Конечно хватит. Там надо, всего лишь, разместить универсальный загрузчик, который "знает" как загрузить что-то из последовательного ПЗУ (вторичный загрузчик) основной платы, или произвести загрузку из ПЗУ дополнительной платы, если она подключена. На дополнительной плате может стоять параллельное ПЗУ, или тоже последовательное. Как решит разработчик. Проверить программно какое ПЗУ на дополнительной плате не сложно.
---------- Post added at 14:18 ---------- Previous post was at 14:16 ----------
Может, тогда прямо в Альтере просто эмулировать 2к ПЗУ F800?
Ну, вот! Идем по второму кругу!
---------- Post added at 14:20 ---------- Previous post was at 14:18 ----------
Странно, т.к. даже в моей деревне их есть: http://kosmodrom.com.ua/product.php?name=at29
Что же здесь странного? Распродаются советские остатки.
---------- Post added at 14:23 ---------- Previous post was at 14:20 ----------
Последовательные ПЗУ сейчас много кто делает. Искать можно по ключам 24С и 24LC. Скорость работы вот только...
Эта скорость влияет только на время загрузки программы в ОЗУ. А что ПС загружается мгновенно?
Ну, вот! Идем по второму кругу!
Но согласитесь, даже начальный загрузчик должен был бы иметь возможность выдать какое-либо сообщение (об ошибке), что-либо спросить у пользователя. Т.е. иметь базовые процедуры ввода-вывода. Или просто "висеть" в случае непредвиденной ситуации?
Я безусловно буду заниматься,т.к. пока это вроде бы интересно, но я склонен к "неполучилось-фыркнул-бросил", как это уже к примеру получилось с попыткой портирования UZIX. Поэтому я никакие обязательства, или даже просто планы, не берусь выполнять. Тут ведь как выходит: получится - хорошо, не получается - "ну не смогла".
Давайте будем считать, что Вы были "один в поле воин" и этим определялась "склонность". Теперь уже образовалась конкретная группа. Пусть она не многочисленная, но в ней профессионалы. Самое главное - есть четкая специализация по направлениям. Кроме того, четко прорисовалось ТЗ того, что мы хотим. Проект, который мы делаем настолько универсален, что должен быть интересен специалистам далеким от Ориона. Делая универсальное "железо", мы помним, что нас в данной ситуации интересует Орион-128. Поэтому, все что Вы наработали подойдет в наш проект. Кроме того, хороший стимул довести до ума свой отладчик. Думаю в данный момент не следует распыляться и оставить до лучших времен UZIX. А вот SD - это актуально и если удастся ее "объездить", то в дополнительную плату можно было бы включить как штатную принадлежность.
Кстати. Мы знаем, как архитектурно будет устроена плата контроллера. Уже понятно, что Евгений это сможет сделать - профессионализма у него выше крыши. Давайте совместно утрясать ТЗ на дополнительную плату. Здесь может быть два варианта: узкоспециализированная плата чисто под Орион-128, или так же универсальная плата, позволяющая кому-то решать и другие задачи. И еще: надо утрясти шину!
И последнее. Почему бы Вам не открыть новую тему, где обсуждать программную сторону этого проекта, ну скажем, Орион-2, а не общие вопросы всего Ориона-128. Думаю, b2m, имея большой опыт в написании эмулятора, не остался бы в стороне.
---------- Post added at 15:05 ---------- Previous post was at 15:02 ----------
Но согласитесь, даже начальный загрузчик должен был бы иметь возможность выдать какое-либо сообщение (об ошибке), что-либо спросить у пользователя. Т.е. иметь базовые процедуры ввода-вывода. Или просто "висеть" в случае непредвиденной ситуации?
Соглашусь! Вы абсолютно правы, коллега! Вот только куда выводить, если драйвера дисплея еще нет в данный момент! Может помигать светодиодиком?
Вот только куда выводить, если драйвера дисплея еще нет в данный момент! Может помигать светодиодиком?
Ну, если мы делаем Орион, то в экранную область Ориона. А если это будет универсальный контроллер, то можно и светодиодиком :)
Может помигать светодиодиком?
У нас бипер на борту есть. Меняет состояние по FE бит 4 или любой бит FF.
Сделаем как на ПЦ :)
ПЗУ внутри альтеры получилось. Полдня убил, но разобрался. Проверил в работе с ним Мониторы М1 и М34. Этот вопрос закрыт, можем ехать дальше. :)
У нас бипер на борту есть. Меняет состояние по FE бит 4 или любой бит FF. Сделаем как на ПЦ :)
Это хорошо, но как узнать код ошибки? Азбука морзе?
ПЗУ внутри альтеры получилось. Полдня убил, но разобрался. Проверил в работе с ним Мониторы М1 и М34. Этот вопрос закрыт, можем ехать дальше. :)
Ну, прошивать в Альтеру Мониторы будут только "истинные орионщики", т.к. это резко сужает рамки возможного. Я считаю, в Альтере должен быть мощный и универсальный загрузчик + пост-тестирование контроллера. может быть разместить еще упрощенный драйвер дисплея для вывода ошибок на дисплей. Все! Тогда это будет универсальный Орион-контроллер. О! Вот и термин придумался!
Ну, прошивать в Альтеру Мониторы будут только "истинные орионщики", т.к. это резко сужает рамки возможного. Я считаю, в Альтере должен быть мощный и универсальный загрузчик + пост-тестирование контроллера.
Это уже обсуждалось. Вроде как решили что в альтере будет только системный загрузчик с I2C или CF? Мне, собственно, все равно что там будет. Лишь бы удовлетворить всех. :)
В альтере - загрузчик, далее I2C-ПЗУ объемом от 2 кб (для М36ZRKH, например) и далее по запросам пользователя. Можно оставить и просто загрузчик СР/М, можно как было сделано у меня до сегодняшнего дня - РОМ-диск + Монитор в старших адресах. Можно просто свой код безо всяких стандартов запихнуть.
Лично мне нужен РОМ-диск + СР/М. Парочка 24С512 у меня где-то пылятся без дела.
Дело в адаптации ORDOS для последовательного кода.
А для Error404 я с удовольствием залью в альтеру "безПЗУшный" вариант. После того, как он доработает ORDOS :) Кстати, эта платка на фото - практически твоя :)
Error404
13.10.2009, 18:06
Лишь бы удовлетворить всех. :)
Можно пионерский вопрос? Чем программируются КонфПЗУ Альтер?
И насколько сложно программить их и I2C-ПЗУ в отсутствии программатора (т.е. есть ли какие-то варианты как с Атмеловскими контроллерами - программировать кинув пять проводов с LPT). Это я задумался о народе, который будет повторять проект.
Кстати, эта платка на фото - практически твоя :)
Ах вот это что за плата... :)
Но все равно интересно, эта какая-то свободнопродаваемая макетная пп?
Что же здесь странного? Распродаются советские остатки.
Это не советские остатки, :) это Atmel Parallel Flash (http://atmel.com/dyn/products/devices.asp?family_id=624)
ewgeny7, так что, от макетки уже лишнее можно отпиливать? ;)
Чем программируются КонфПЗУ Альтер?
БайтБластером. http://www.altera.ru/cgi-bin/go?35
Говорят, можно и проводками обойтись, но Циклон дороже чем АП5.
И насколько сложно программить их и I2C-ПЗУ в отсутствии программатора (т.е. есть ли какие-то варианты как с Атмеловскими контроллерами - программировать кинув пять проводов с LPT)
Программировать не сложно. Есть программы из серии "для чайников". Но программатор придется сделать. Я могу прошивать I2C-ПЗУ на "флешере" от skyther'а, но может быть есть пути попроще? Это вопрос к уважаемому all.
---------- Post added at 18:26 ---------- Previous post was at 18:25 ----------
так что, от макетки уже лишнее можно отпиливать?
От какой?
От какой?
от этой
Это фабричная печатка-макетка. Распространяется Spensor'ом из Харькова
Ну, если только микроконтроллер туды припаять. Или ОЗУ, если найдется в корпусе "квадратный QFP" :)
Можно пионерский вопрос? Чем программируются КонфПЗУ Альтер?
И насколько сложно программить их и I2C-ПЗУ в отсутствии программатора (т.е. есть ли какие-то варианты как с Атмеловскими контроллерами - программировать кинув пять проводов с LPT). Это я задумался о народе, который будет повторять проект.
А давайте обойдемся только одним программатором - ByteBlaster MV, чтобы проще было. Им можно программировать ALTERA и AVR. Поэтому, образ ПЗУ можно будет загружать из этих двух, а также с SD.
У меня так будет.
Извиняйте что встреваю в ваш разговор (это Igor_t , говорю от учетки Алексея)
Можно пионерский вопрос? Чем программируются КонфПЗУ Альтер?
http://www.speccyland.net/forum/viewtopic.php?f=13&t=9
эта коряга програмит не только саму альтеру , но и конфпзу запаянную в плату , причем определяется квартусом как родной програмер.
Извиняйте что встреваю в ваш разговор (это Igor_t , говорю от учетки Алексея)
Привет, Игорь :)
Коряга хороша. Только чтоб ее (ЮСББластер) сделать нужен БайтБластер? Или ПИКкит?
Я заинтересовался, а остальные? ;)
AlexBel off Igor_t on
Только чтоб ее (ЮСББластер) сделать нужен БайтБластер? Или ПИКкит?
желательно пиккит , но возможно и jdm подойдет , в крайнем случае там я на Ц писал , можно под любой процик переделать ;)
Error404
13.10.2009, 20:59
Я заинтересовался, а остальные? ;)
А я как обычно ничего не понял. :cool:
Этот программатор по отношению к схемке на АП5 каков?
AlexBel off , Igor_t on
Все очень просто ...
А я как обычно ничего не понял.
Этот программатор по отношению к схемке на АП5 каков?
есть такая штука называется JTAG , она придумана давно и с ее помощью возможно заливать прошивки в разные микрухи его поддерживающие, в том числе и в плисы от альтеры . Раньше когда лпт и компорты были само собой разумеещееся на борту любого компа , для житага пользовали лпт порт подключая к нему "шинник" для согласования уровней , а вот когда усб узаконился и вытеснил собой остальные порты , встала великая трабла и каждый производитель микрух стал изобретать свои схемы усб-житага и естественно в своих IDE поддерживать свое железо .. то что ты наблюдал это усб житаг для альтеры и он видится квартусом (IDE от альтеры) как родная железяка.
желательно пиккит , но возможно и jdm подойдет , в крайнем случае там я на Ц писал , можно под любой процик переделать
Не, Игорь, тут народ мучается чем бы им попроще паршивки заливать, а ты им мегамонстра предлагаешь :)
все тот же Igor_t
Не, Игорь, тут народ мучается чем бы им попроще паршивки заливать, а ты им мегамонстра предлагаешь
дык я как бы ненавязываю :) тем более что я указал свой первоисточник который сделан на атмеле , так что выбор есть . :)
Это уже обсуждалось. Вроде как решили что в альтере будет.... Лишь бы удовлетворить всех...
...Можно просто свой код безо всяких стандартов запихнуть.
Лично мне нужен...
А для .... я с удовольствием залью в альтеру "безПЗУшный"...
Печально коллеги! Повторяется ситуация двадцатилетней давности, когда каждый хотел иметь обязательно свой стандарт и свой Монитор. В итоге их десятка два. С десяток разных СР/М и каждый оплевывал чужую и считал, что его лучше. А ведь они все "2.2", и разница в BIOSe. И это такое уж геройство? А что в итоге? Три орионщика и just for fun... Вот и весь Орион! Весь кайф - это вспоминать, что работает при каком Мониторе, и какая при этом должна быть клавиатура? А теперь будем гордится, как кто грузится и какая должна быть ОРДОС. И ты должен принять мой "стандарт", иначе у тебя хрен что получится!
Печально коллеги! Думал уж при таком мизере пользователей сможем удержать какой-то единый стандарт, и всем подстроиться под него. Увы...just for fun!
Всегда завидовал вектористам. Там никогда не было такого балагана.
Error404
14.10.2009, 00:23
Печально коллеги! Повторяется ситуация двадцатилетней давности, когда каждый хотел иметь обязательно свой стандарт и свой Монитор. В итоге их десятка два. С десяток разных СР/М и каждый оплевывал чужую и считал, что его лучше. А ведь они все "2.2", и разница в BIOSe. И это такое уж геройство? А что в итоге? Три орионщика и just for fun... Вот и весь Орион! Весь кайф - это вспоминать, что работает при каком Мониторе, и какая при этом должна быть клавиатура? А теперь будем гордится, как кто грузится и какая должна быть ОРДОС. И ты должен принять мой "стандарт", иначе у тебя хрен что получится!
Печально коллеги! Думал уж при таком мизере пользователей сможем удержать какой-то единый стандарт, и всем подстроиться под него. Увы...just for fun!
Всегда завидовал вектористам. Там никогда не было такого балагана.
О чем это вы? :)
И на Векторе огого какой балаган был (там где за дело брались любители), судя даже по здешнему форуму. Одна CPM у них без внешнего ром(или рам?)диска не работает, другая работает, но не так как первая, третья - работает по третьему, BIOS T34 T56 T80 и прочие модели танков. :)
И схем установки Z80 на Векторе даже больше было, чем на Орионе.
--
Разные люди разными частями интересуются. Я могу сделать какой-то кусок, а какой-то делать не буду, потому что неинтересно или с позиции моего опыта считаю что надо по-другому. Но аппаратно кусок то этот от этого никуда не денется - пусть живет, раз есть такая идея, кому-то пригодится и будет использован и поддержан. Главное чтобы не было условия "вместо", "так и никак иначе". Это нормально, по-моему, и всегда так было у "народных моделей", тем более у нас практически девборда. И в итоге что-то непременно получится, и даже не одно.
А Мониторы-3 лениградские лучше Мониторов-2, ИМХО. Они - развитие, а не альтернатива. Там больше возможностей и идей в том же объеме кода. Но это уже оффтопик, пожалуй.
Black_Cat
14.10.2009, 00:55
Печально коллеги! Думал уж при таком мизере пользователей сможем удержать какой-то единый стандарт, и всем подстроиться под него. Увы...just for fun!
Всегда завидовал вектористам. Там никогда не было такого балагана...я молчу про Спектрум.. Из опыта стандартизации Спектрума могу сказать следующее - лучший способ выбора стандарта, это его авторская защита, точно так же как это принято в научных кругах. Смог защититься перед оппонентами и доказать что именно так надо делать - предложение принимается в качестве текущего стандарта, а нет - значит не судьба.
Не понял, в чем суть паники? ;)
Ковыряясь с ИДЕ я обнаружил изрядную дыру в реализации записи в системные порты. Чем это плохо? Чем разносторонней задачи на стадии отладки, тем меньше глюков останется в конечном итоге. И не надо забывать, что специализация людей, здесь собравшихся, слишком разная. Чтобы работать в коллективе, нужно учитывать мнение всех собравшихся под ёлкой.
Насчет печатной платы - я отдал всем "на откуп" ресурсы альтеры. Разводите шины, как вам удобней. Подключайте ОЗУ как удобней для "разводящего". Подключение конфПЗУ жестко завязано на ноги альтеры - я дал схему. Раз добавляем последовательное ПЗУ - добавлю фрагментик схемы подключения оного. Больше мне нечем помочь, чесслово. Как я соберу на макетке и как это ЛУЧШЕ развести на ПП - это две большие разницы. И не стоит забывать, что кувыркание с макеткой и полкило МГТФа не позволит оценить работу готового устройства на ПП, куча наводок между проводами может погубить на корню все усилия.
Есть идея! Давайте обсудим!
Напомню. Я уже не однократно говорил, что на плате Орион-контроллера не нужно устанавливать или эмулировать порты ВВ55. Они не интересны в плане универсального использования и нужны, собственно для совместимости с программным наследием Ориона. Поэтому их стоит размещать на дополнительной плате, которая превращает Орион-контроллер в Орион-128. Логично?
Кроме того, следует подчеркнуть, что использование Z80, имеющего фоннеймановскую архитектуру очень интересно, т.к. имеются свои плюсы, особенно если нет потребности "в тупую управлять двигателем". Тоже объяснял! Но с точки зрения программ управления, Z80 имеет один существенный недостаток - нет команд и структуры битового управления. Чтобы изменить состояние бита в порту, необходима куча возни! Так легко, как это можно сделать на AVR, PIC или 8051, "подергать выводом порта" на Z80 не удастся. Отсюда и возникают проблемы с применением последовательный протоколов - I2C, SPI и т.д.
Что я предлагаю:
Я уже упоминал об универсальных двунаправленных портах. Попробую описать все словами, так как несколько подзабыл структуру логических элементов.
Разберем один восьмиразрядный порт. В нем делается каждый разряд шины данных отдельным портом ввода/вывода. Например. Port0: 30h->D0, 31h->D1, 32h->D2, 33h->D3, 34h->D4, 35h->D5, 36h->D6, 37h->D7. Со стороны Альтеры это, к примеру, для всех одна шина D0. Т.е. записывая OUT 30h мы одной командой меняем уровень сигнала на одной ноге порта - D0. Чтобы записать весь байт одним махом, делаем порт 38Н. Он выставляет свое значение на всех выводах порта, изменяя не совпадающие значения портов 30-37. Если выводы портов будут с "открытым коллектором", то отпадает потребность переключать порты на ввод/вывод. Входы порта для чтения подключаются на те же ножки, что и выходы. Единица выхода может быть легко задавлена нулем входного сигнала и это состояние на ножке читается командой IN. Все точно также как и при записи - можем считать состояние любого вывода порта, или весь порт сразу. Если нам нужен порт только для чтения, мы записываем в порт 38Н FFh. Теперь выходы не будут мешать входным сигналам выставлять низкий уровень.
В ассемблере, к примеру, можно сделать макрос "SET P0.0" "CLR P0.0" (установить/сбросить D0 порта 0), а можно ввести новые мнемоники в ассемблер, который при трансляции будет вставлять несколько комад в транслируемый блок.
Самым идеальным было бы добавить новые команды в сам Z80 - это все бы упростило!
Что скажете?
В Z80 есть команды для работы с битами, но работают они только с регистрами и памятью, но не с портами. Так что ввод/вывод через ячейки памяти - не такая уж и плохая идея.
AlexBel off Igor_t on
Кроме того, следует подчеркнуть, что использование Z80, имеющего фоннеймановскую архитектуру очень интересно, т.к. имеются свои плюсы, особенно если нет потребности "в тупую управлять двигателем". Тоже объяснял! Но с точки зрения программ управления, Z80 имеет один существенный недостаток - нет команд и структуры битового управления. Чтобы изменить состояние бита в порту, необходима куча возни! Так легко, как это можно сделать на AVR, PIC или 8051, "подергать выводом порта" на Z80 не удастся. Отсюда и возникают проблемы с применением последовательный протоколов - I2C, SPI и т.д.
Ну насколько я понимаю гарвард или фоннейман неиграет никакой рояли , и ошибочно утверждать что гарвард для того что бы тупо управлять двиглом и примеров тому масса . Проблемы с применением последовательных портов возникают от других факторов как то
-отсутствие хардовых модулей
-различия в архитектуре портов
а тормознутость софтовой реализации обусловленна скорее тем что зету требуется очень многа ))) времени на выполнение одной команды , а для того что бы скинуть/установить один бит в порту ему потребуются 3 команды вместо одной в том же пике младших или средних серий , хотя команда пика сделает теже самы действия .... про проблему чтение - модификация-запись у младших семейств пиков думаю нестоит расказывать .
Igor_t off
Ну насколько я понимаю гарвард или фоннейман неиграет никакой рояли , и ошибочно утверждать
В чем не играет никакой роли? Думаю, Вы не правильно "понимаете", поэтому и считаете, что опонент "ошибочно утверждает"! Z80, как и 8086 - это универсальные процессоры, где ПЗУ и ОЗУ расположены в одном адресном пространстве, и хотите Вы или не хотите, а придется соблюдать последовательность: выставить указатель (РС) и прочитать команду из ПЗУ, затем дешифровать ее и уже обращаться к данным ОЗУ по другому указателю в это же адресное пространство. В Пентиумах пытаются ускорить этот процесс за счет конвееров.
Гарвард этот недостаток не имеет. Шины для считывания комманд и данных раздельные, как и адресное пространство, а значит можно совмещать операции. Но здесь свои недостатки. Я о них говорил в своем первом посте. Персоналку, в том числе и Орион-128, на гарварде, в принципе, не сделать!
А вот если б в Z80 добавить битовые команды работы с портом, то можно было бы убить двух зайцев.
AlexBel off Igor_t on
В чем не играет никакой роли? Думаю, Вы не правильно "понимаете", поэтому и считаете, что опонент "ошибочно утверждает"!
я понял Вас так что вы считаете что битовые операции есть прерогатива камней имеющих гарвардскую архитектуру иначе зачем было вообще вспоминать про гарвард и дедушку фоннеймана ? или я Вас неправильно понял ?
Z80, как и 8086 - это универсальные процессоры, где ПЗУ и ОЗУ расположены в одном адресном пространстве, и хотите Вы или не хотите, а придется соблюдать последовательность: выставить указатель (РС) и прочитать команду из ПЗУ, затем дешифровать ее и уже обращаться к данным ОЗУ по другому указателю в это же адресное пространство. В Пентиумах пытаются ускорить этот процесс за счет конвееров.
Ну несовсем так все упрощенно , но тем не менее ... ПЗУ или ОЗУ неиграет никакой роли , да и по какому указателю адресуется ядро тоже неимеет роли в фоннеймане ибо команды типа MVI читают данные через инкрементированный указатель PC , но и это все ерунда ... То что пентиумы внутри имеют конвееры это прекрасно , только вот незадача , конвееры имели еще такие контроллеры как 6805 от мотороллы (тоже CISC кстати и PIC16C84 это уже RISC) и казалось бы в чем тут разница ? а разница в том что Пентиумы формально внутри гарварды потому как имеют различные конвееры для команд и данных , НО ко всему еще они внутри RISC , хотя для пользователя снаружи они класические CISC с фоннейманом.
Но на самом деле все это фигня полная потому как на наличие/отсутствие битовых операций модель памяти используемой процом невлияет. (Кстати небуду утверждать ибо z80 програмил последний раз лет 10 - 15 назад в таки есть битовые команды таблица с доп опкодом CB, не оно ?)
Гарвард этот недостаток не имеет. Шины для считывания комманд и данных раздельные, как и адресное пространство, а значит можно совмещать операции. Но здесь свои недостатки. Я о них говорил в своем первом посте. Персоналку, в том числе и Орион-128, на гарварде, в принципе, не сделать!
А вот если б в Z80 добавить битовые команды работы с портом, то можно было бы убить двух зайцев.
Дался Вам этот гарвард , суть не в нем , а в том что ИМХО вы попутали его с понятием RISC и CISC потому как все камушки которые Вы перечислили есть RISC и самая главная фишка в них то что команда-1 маш. цикл и там нет такого понятия как порт , там порты отображаются в память ;) и потому с ними легко работать , да еще к тому же быстрые команды .....
Igor_t off
я понял Вас так что вы считаете что битовые операции есть прерогатива камней имеющих гарвардскую архитектуру...
Все, коллега! Извините, но более не хочу вести дискуссию на эту тему. У нас разное понимание архитектур процессоров. Давайте останемся каждый при своем мнении и будем решать чисто технические вопросы!
Я дико извиняюсь, но вставлю свои 5 копеек.
Когда я к своему "железному" Ориону-128 подключал датчики и внешнее оборудование (а именно АЦП и дискретные входы), то первое что я сделал - контроллер прерываний на К580ВН59, аппаратные часы (Dallas Semiconductor, энергонезависимые, выдрал микруху с батарейкой внутри из старого Acer'а) и программируемый таймер К580ВИ53.
В общем так. Новый "Орион" просто обязан иметь нормальную схему обработки прерываний. А если Вы хотите что-то многозадачное, то и интервальный таймер. Ну а часы - это просто у меня в протоколировании использовалось.
Вот. Иначе этот паровоз быстро не поедет, а использование его как универсального контроллера в системах типа умного дома будет проблематичным.
Error404
20.10.2009, 11:38
Я дико извиняюсь, но вставлю свои 5 копеек.
Когда я к своему "железному" Ориону-128 подключал датчики и внешнее оборудование (а именно АЦП и дискретные входы), то первое что я сделал - контроллер прерываний на К580ВН59, аппаратные часы (Dallas Semiconductor, энергонезависимые, выдрал микруху с батарейкой внутри из старого Acer'а) и программируемый таймер К580ВИ53.
В общем так. Новый "Орион" просто обязан иметь нормальную схему обработки прерываний. А если Вы хотите что-то многозадачное, то и интервальный таймер. Ну а часы - это просто у меня в протоколировании использовалось.
Вот. Иначе этот паровоз быстро не поедет, а использование его как универсального контроллера в системах типа умного дома будет проблематичным.
К580ВИ53 полюбому ставить придется, т.к. оно нужно для 580вв51 (RS-232), а 512Ви1 (которая и часы и программируемый таймер, и могла бы заменить ВИ53) народ применять, прямо скажем, не горит желанием.
С прерываниями как-то можно выкручиваться уже и на голом Z80 за счет IM2 ИМХО. А вот для CPU ВМ80 К580ВН59 - это да, необходим.
К580ВИ53 полюбому ставить придется, т.к. оно нужно для 580вв51 (RS-232), а 512Ви1 (которая и часы и программируемый таймер, и могла бы заменить ВИ53) народ применять, прямо скажем, не горит желанием.
Да я применял то, что под рукой было. ВИ1 или подобную ей тоже можно применять. А если хотим получить многозадачность, то прерывания аппаратного таймера ой как нужны...
С прерываниями как-то можно выкручиваться уже и на голом Z80 за счет IM2 ИМХО. А вот для CPU ВМ80 К580ВН59 - это да, необходим.
(Их еще можно каскадировать и приоритет выставлять)
По большому счету и для Z80 необходим. Мы ж рассчитываем на большое количество периферии. Да и вместо постоянного опроса внешних устройств в цикле логично сделать работу по прерываниям (как во всех цивилизованных системах), а процессор занять более полезными вещами.
То, что натворил Сугоняко с прерываниями - у меня на это слов нет, буквы одни.
P.S. Жаббер есть, или на худой конец аська?
То, что натворил Сугоняко с прерываниями - у меня на это слов нет, буквы одни.
Это было лишь в самом первом Орион-128, последующие модификации такого безобразия не имели. Видимо, поддался стадному чувству, в РК86 такая-же бяка была :)
Error404
20.10.2009, 12:42
Это было лишь в самом первом Орион-128, последующие модификации такого безобразия не имели. Видимо, поддался стадному чувству, в РК86 такая-же бяка была :)
Я слышал (опять из третьих рук, если что - тапками не кидаться :v2_devil:), что там еще и журнал Радио поддавал жару. В частности, как пререквизит для публикации 1990 года, требовал некой совместимости Ориона с Радио РК-86. Хотя конечно прерывания можно было и не перекрывать - вполне хватило бы и совместимости по подпрограммам Монитора.
---------- Post added at 12:40 ---------- Previous post was at 12:34 ----------
В копилку общих хотелок: мне шибко нравится решение Ethernet+TCP/IP на чипах Wiznet типа 5100 и подобных. В свое время даже хотел подключить к Ориону, но отпугнула цена на единичный образец девборды под это дело (чего не будет если W5100+трансформатор развести прямо на плате).
--
Это прямо в тему контроллеров на базе Ориона или чего то еще - сейчас RS232 для связи с внешним миром уже не модно. Модно Ethernet. :)
---------- Post added at 12:42 ---------- Previous post was at 12:40 ----------
P.S. Жаббер есть, или на худой конец аська?
С аськами я завязал когда перестал работать QIP. :(
Это прямо в тему контроллеров на базе Ориона или чего то еще - сейчас RS232 для связи с внешним миром уже не модно. Модно Ethernet. :)[COLOR="Silver"]
Я делал RS485 :) А вообще, даже для таких ПК набор USB и Ethernet будет весьма не лишним...
С аськами я завязал когда перестал работать QIP. :(
Дружи с дядей Жаббером. Его не задушишь и не убьешь :)
LeBohdan
27.10.2009, 23:17
pvlad, извините, что не в тему... Но есть много желающих сделать оригинальный Орион-128, который публиковался в журнале. Причины - ностальгия, для удовольствия и другие (у каждого свои). Но оригинальной платы в PCAD - нет. А потому заказать - трудно. Может у вас есть ? Поделитесь со страждущими ;)
pvlad, извините, что не в тему... Но есть много желающих сделать оригинальный Орион-128, который публиковался в журнале. Причины - ностальгия, для удовольствия и другие (у каждого свои). Но оригинальной платы в PCAD - нет. А потому заказать - трудно. Может у вас есть ? Поделитесь со страждущими ;)
Сожалею, но авторы разводили плату Орион-128 вручную. Это генеально сделал Константин Коненков. Серийно, как для Ориона-ПРО, авторы платы не изготавливали. В PCAD плату переводили (без перетрассировки! PCAD не смог ее оптимизировать лучше человека!) на Ливенском заводе, где Орион-128 выпускался серийно. Но плата была несколько упрощена - отсутствовал разъем системной шины, и были не все порты (ВВ55). Плата была заточена под компьютерный класс. Еще знаю - для Казахстана (то ли для какого-то вуза, то ли предприятия - уже не помню!) разводилась плата под корпус УКНЦ (клавиатуру и всю "бижутерию") в Зеленограде. Я собирал и налаживал, затем, опытный экземпляр на этой плате. Но какой либо-документации на эти платы у авторов не было. В те времена с авторскими правами радиолюбителей никто особо не считался.
LeBohdan
29.10.2009, 23:00
pvlad, спасибо за подробный ответ! А как на счет качественных (и правильных) фотошаблонов или рисунков платы?
pvlad, спасибо за подробный ответ! А как на счет качественных (и правильных) фотошаблонов или рисунков платы?
Думаю, Вы не очень внимательно прочитали предыдущий пост.
LeBohdan
30.10.2009, 19:23
Очень внимательно. Но людей интересует журнальный вариант. В свое время фотошаблоны были в сотне коопреативов. Были они, вероятно, и у авторов. А под корпус УКНЦ - есть в сети.
Очень внимательно. Но людей интересует журнальный вариант. В свое время фотошаблоны были в сотне коопреативов. Были они, вероятно, и у авторов. А под корпус УКНЦ - есть в сети.
Вы что, по русски плохо понимаете (могу ответить и по украински!): у меня нет никаких фотошаблонов и рисунков печатных плат! С тех времен прошло уже 20 лет! Если Вы считаете, что они были "в сотне коопреативов" - попробуйте поискать там.
Если Вы знаете где лежат шаблоны под УКНЦ - дайте мне ссылку. Буду признателен!
У Вас еще есть вопросы ко мне на эту тему?
Ссылки публиковал Panther вот тут (http://www.nedopc.org/forum/viewtopic.php?p=83983#83983) буквально перед Вашим сообщением. Насколько я понял, там не только Ваши архивы.
LeBohdan
31.10.2009, 23:18
Вы что, по русски плохо понимаете (могу ответить и по украински!): у меня нет никаких фотошаблонов и рисунков печатных плат! С тех времен прошло уже 20 лет! Если Вы считаете, что они были "в сотне коопреативов" - попробуйте поискать там.
Если Вы знаете где лежат шаблоны под УКНЦ - дайте мне ссылку. Буду признателен!
У Вас еще есть вопросы ко мне на эту тему?
Спасибо за ответы. Вопросы были на другие темы. Но вижу вы не умеете отвечать. Задам другим людям.
Про УКНЦ - вам ответили.
Ссылки публиковал Panther вот тут (http://www.nedopc.org/forum/viewtopic.php?p=83983#83983) буквально перед Вашим сообщением. Насколько я понял, там не только Ваши архивы.
Спасибо за подсказку. Вроде бы шерстил я эти архивы и ничего не нашел. Надо повторить.
---------- Post added at 01:54 ---------- Previous post was at 01:51 ----------
Спасибо за ответы. Вопросы были на другие темы. Но вижу вы не умеете отвечать. Задам другим людям.
Про УКНЦ - вам ответили.
Видимо, я не понял Ваши вопросы - приношу извинения, если не умышленно обидел!
Вроде бы шерстил я эти архивы и ничего не нашел. Надо повторить.
Чего там шерстить: Orion-Tech.rar\PCAD\@128\PCB
ЗАХОД НА ПОСАДКУ НОМЕР ДВА.
Давайте уже определим, что мы хотим. pvlad посоветовал вначале самому определиться, что я сам хочу видеть в этом проекте.
Вот кусочек размышлений:
1. Сейчас мы имеем на борту ПЛИС процессор, видеогенератор, порты внутренней конфигурации F8, F9, FA, FB. Есть порт клавиатуры F4xx, порт РОМ-диска F5xx.
Реализованы прерывания 50Гц, wide-screen, маппер (диспетчер) памяти по 16кб.
Ничего из этого убираться/меняться не будет, для сохранения совместимости с последними "навороченными" Орион-256. Ибо терять совместимость с итак небогатым набором софта совсем не хочется.
2. РОМ-диск реализован в параллельном флеш-ПЗУ. Это позволяет использовать для его работы шины адреса/данных основного ОЗУ в мультиплексированном виде.
Для управления РОМ-диском задействована всего одна нога ПЛИС - RDROM.
Шины переключаются на три потока: видеогенератор-ОЗУ, процессор-ОЗУ, процессор-РОМдиск. Исходя их этого, использование этих шин несколько затруднительно для внешних дополнительных устройств. Поэтому я решил применить более "ногастый" циклон и вывести разъем расширения для ВУ с "чистыми" сигналами процессора. Для этого варианта я буду использовать ПЛИС EP1C3T144 (104 ноги I/O). Хотя, по совести, лучше ставить EP2C5T208... Но она будет дороже и 208 ног паять - не все справятся.
3. Базовое "стартовое" ПЗУ в проекте - внутри ПЛИС. Оно соответствует "стандартному" ПЗУ Ориона 2кб. Те, кто for fun, заливают туда Монитор и не парятся. Для прочих - разместим там драйвер загрузки из I2C-ПЗУ. Я выбрал этот вариант, поскольку это не потребует утрамбовывать в ПЛИС (итак уже забитую почти под завязку) модулей "железного" контроллера SPI. Работа с I2C-ПЗУ будет вестись программно, используя всего два порта по два бита. Исходники реально работающей системы Z80 <-> I2C-ROM у нас есть, это используется на "Скорпионе".
4. Музпроцессора и часов реального времени на основной плате не будет. Музпроц на этой платформе и так не особо нужен, а с часами всегда будет неопределенка, ставить параллельные DALLAS (512ВИ1) или I2C PCF8583. Или ещё какие-нибудь.
Плюс, пихать часы в ПЛИС бессмысленно. Догадайтесь, почему? ;)
Я поеду в понедельник по магазинам, буду помимо прочего искать макетку TQFP-0.5x208 для нового циклона. Без нее работа не сдвинется... Прям хоть Error404 просить выслать :)
Error404
02.11.2009, 13:07
В целом вроде красиво выглядит, и особенно не ограничивает для развития в любую сторону.
Плюс, пихать часы в ПЛИС бессмысленно. Догадайтесь, почему? ;)
"Это элементарно, Ватсон". (с) :cool:
Я поеду в понедельник по магазинам, буду помимо прочего искать макетку TQFP-0.5x208 для нового циклона. Без нее работа не сдвинется... Прям хоть Error404 просить выслать :)
Если в платке возникнет затык - вышлю, не проблема.
SeniorAndre
25.03.2010, 12:07
Орион-128 должен продолжать жить в двух направлениях:
1. Это - just for fun, как определил Error404.
2. Второй вариант всецело зависит от ewgeny7.
Мы упрощаем его проект и удаляем "навороты", т.е. делаем классический Орион-128. Это позволит использовать более дешевую ПЛИС. Главная идея - превратить Орион в УНИВЕРСАЛЬНЫЙ КОНТРОЛЛЕР, который можно встраивать в радиолюбительские задачи управления.
Что скажете, коллеги?
Господа, честно говоря целиком и полностью согласен с данным тезисом. Два варианта имеют права на жизнь и (just for fun) и радиолюбителям не хватает своего нормального Контроллера. Но:
1. Зачем городить огород и идти против течения. Есть linux, который работает как на embedded устройствах, так и на обычных компах.
2. Есть куча программ под линух;
3. Есть куча специалистов;
4. Огромное количество наработок;
5. Огромное количество драйверов для устройств, которые позволяют делать любую модульность и расширяемось.
Надо нормально влиться в этот процесс и не зачем создавать морально устаревший продукт.
Вот ссылки:
www.elinux.org
http://www.xakep.ru/magazine/xa/124/084/1.asp
Есть еще один аргумент - повышение профессионального уровня, который можно применить на реальном производстве.
У меня также есть Орион собранный в 91 году и я с удовольствием понастальгирую, но на расширении классики и ни как на создании детища, которое имеет мало шансов на выживаемость.
Есть linux, который работает
... на устройствах, имеющих объем памяти на пару порядков больше.
Nikola887643
25.03.2010, 21:53
Вот мое предложение. Во первых чтоб его могли повторить все надо переработать печатку и схему. Неохото собирать комп на 59 микрухах, когда на оперативке можно убавить на 14 микросхем (микросхем там по моему 16, чтоб была сохраость выполнения программ надо помоему 2 озу, 16-2=14). Во вторых такие некритичные микрухи как счетчики мультиплексоры? тригеры можно их засунуть в плис. Работоспособность по моему от этого не изменится. Примерно на 20 микрух минус. Итог на 27 микросхем уже можно собрать.
Неохото собирать комп на 59 микрухах, когда...
Вчерась крутил платку в руках (оригинал) ... такая маленькая...
понятно, что Иривер с Иподом меньше, но зачем?
Nikola887643
25.03.2010, 22:09
Большую плату в домашних условиях не вытравить.
У меня вопрос ВВ55А на какие частоты расчитан, и его по моему можно заменить на 8055А, аналог интел, где то попадался на форуме. Мне нужно цены за сколько можно взять.
Nikola887643
25.03.2010, 22:43
У кого нибуть хотябы блок схема подробная есть, и с нормальным качеством. А то у меня качество хре***ое
http://www.google.com/search?client=opera&rls=ru&q=8255a&sourceid=opera&ie=utf-8&oe=utf-8
...Зачем городить огород и идти против течения. Есть linux...
Уважаемый Сеньёр!
Вы профи в Линуксе? У Вас есть конкретное предложение, как это сделать? Вы можете это сделать и нам показать? Или это заявили для красного словца в своем первом посте на этом форуме?
SeniorAndre
01.04.2010, 14:11
... на устройствах, имеющих объем памяти на пару порядков больше.
для eLinux (в eLinux нет работы с DMA) надо для работы устройства с основными сетевыми интерфейсами (ethernet, usb, com) 400kb RAM and 800k ROM, это без всяких дисплеев, игровых портов и т.п. Но ведь речь идёт про расширяемость. Поэтому на пару порядков это вы загнули... Если говорить о функционале который обсуждается в этой ветке, то ресурсов надо в 2-5 раз больше. А если хотя бы на один порядок больше (в 10 раз от Ориона), то вообще будет супер.
У меня в роутере D-Link внутри 16mb RAM (в основном для буферов данных) and 4mb FLASH и это всё работает, но в нем внутри стандартный полнофункциональный linux.
Есть у этого направления только один минус :( - Контроллеров, которые удовлетворяют этим требованиям просто море и делать ещё один ни какого смысла.
400kb RAM and 800k ROM
Это будет как виндовс на калькуляторе запускать... Не, это не наш метод :) СР/М для этих целей больше подходит.
Это будет как виндовс на калькуляторе запускать...
А чо? Давайте объявим конкурс на лучший логотип Микрософт на семисегментниках... :v2_smile:
А чо? Давайте объявим конкурс на лучший логотип Микрософт на семисегментниках...
nECrOSOFt dOOrS :)
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot