Гибрид 8085 и 6502 в FPGA

pvlad · Post by **pvlad** » 05 Dec 2009 04:48

Shaos wrote: ну почему же?

Ну, что же, тогда продолжим.
Мне представляется этот проект схемотехнически и структурно так:
- на плате ПЛИС, мсх. RAM (64/128К), системный разъем - аналог выводов 8085, разъемы портов I/O, разъемы программирования ПЛИС и заливки кода в ОЗУ. Кроме того, необходимо ПЗУ, где будет загрузчик исполняемого кода по RS-232 в ОЗУ. Можно применить какую-нибудь последовательную флешку под загрузчик. Думаю, для начала, достаточно. Получится минимальный по конфигурации контроллер.

Shaos · Post by **Shaos** » 05 Dec 2009 10:00

Наверное лучше начать с универсальной FPGA платы:

viewtopic.php?t=7584&postdays=0&postorder=asc&start=0

pvlad · Post by **pvlad** » 05 Dec 2009 11:56

Shaos wrote:Наверное лучше начать с универсальной FPGA платы:
viewtopic.php?t=7584&postdays=0&postorder=asc&start=0

К сожалению, в указанной теме не работает половина ссылок.

Конечно, Вы можете проверить первые идеи и на этой плате (раз она уже куплена!), но для самого проекта, понятно, это слишком дорого и избыточно. Если у Вас что-то получится, и уже можно будет что-то тестировать, я спаяю для начала макетку, максимально приближенную к Вашей плате (по выводам ПЛИС). В будущем сделаем печатную плату.

Shaos · Post by **Shaos** » 05 Dec 2009 12:06

pvlad wrote:
Shaos wrote:Наверное лучше начать с универсальной FPGA платы:
viewtopic.php?t=7584&postdays=0&postorder=asc&start=0
К сожалению, в указанной теме не работает половина ссылок.

убрал все мёртвые линки, а живые оставил (и перенёс на верх)

pvlad wrote: Конечно, Вы можете проверить первые идеи и на этой плате (раз она уже куплена!), но для самого проекта, понятно, это слишком дорого и избыточно. Если у Вас что-то получится, и уже можно будет что-то тестировать, я спаяю для начала макетку, максимально приближенную к Вашей плате (по выводам ПЛИС). В будущем сделаем печатную плату.

паять такое вручную будет трудновато

pvlad · Post by **pvlad** » 06 Dec 2009 07:58

Shaos wrote:убрал все мёртвые линки...

Спасибо!

Shaos wrote:паять такое вручную будет трудновато

Во-первых, хотелось бы ПЛИС выбрать (в конечном итоге!) минимальную по количеству выводов и на напряжение 5в, а во-вторых - есть макетки для распайки таких корпусов. Радиолюбителям не привыкать - хватило бы терпения и сил довести этот проект до ума!

Shaos · Post by **Shaos** » 12 Dec 2009 06:54

pvlad wrote: Мне представляется этот проект схемотехнически и структурно так:
- на плате ПЛИС, мсх. RAM (64/128К), системный разъем - аналог выводов 8085, разъемы портов I/O, разъемы программирования ПЛИС и заливки кода в ОЗУ. Кроме того, необходимо ПЗУ, где будет загрузчик исполняемого кода по RS-232 в ОЗУ. Можно применить какую-нибудь последовательную флешку под загрузчик. Думаю, для начала, достаточно. Получится минимальный по конфигурации контроллер.

т.е. предполагается, что внутри какая-то память будет, так?

если речь идёт об аналоге выводов 8085, то получается мультиплексированная шина адреса и данных - в таком случае я могу предложить расширить шину данных до 16 бит - можно по идее сделать специальный вывод куда будем подавать 0 для 8-битной шины данных и 1 (или не подключать) для 16-битной - тогда читать из памяти оно будет по 2 байта за раз, что ускорит работу с внешней памятью и максимальный объём физически адресуемой памяти увеличится до 128К (как это программно представить - другой вопрос)

потом можно предположить, что у нас будет несколько (2,3,4) 8-битных портов, которые можно отобразить (программно) на любые из 256 доступных и также иметь возможность работать с отдельными битами этих портов (а также настраивать их независимо друг от друга на ввод или вывод)

Shaos · Post by **Shaos** » 12 Dec 2009 07:11

можно назвать этот гипотетический процессор ND6585

по идее можно спец-вывод завести - начальное состояние процессора после включения: 0 - 6502 или 1 (или неподключено) - 8085

адресное пространство между ними можно поделить так: 6502 в своей "zero page" (0x0000...0x00FF) имеет набор ячеек памяти для "быстрого" доступа, с другой стороны 8085 там должен иметь кучу программных и аппаратных точек входа для прерываний (RST) что требует чтобы "zero page" были физически разными участками памяти для 6502 (будет иметь там данные) и 8085 (будет иметь там программу) - с другой стороны например CP/M также имеет свою "zero page" - все программы CP/M начинаются с адреса 0x0100 (хотя RST оно использует)

Shaos · Post by **Shaos** » 12 Dec 2009 07:24

можно посмтреть в сторону 580ВМ1 - он имел возможность адресовать 128К непосредственно (правда только для данных)

Shaos · Post by **Shaos** » 12 Dec 2009 09:15

Shaos wrote:можно посмтреть в сторону 580ВМ1 - он имел возможность адресовать 128К непосредственно (правда только для данных)

хотя там префиксы использовались - один для использования второй памяти, второй для использования H1L1 вместо HL - не очень интересно

Shaos · Post by **Shaos** » 12 Dec 2009 10:14

Shaos wrote:
Shaos wrote:можно посмтреть в сторону 580ВМ1 - он имел возможность адресовать 128К непосредственно (правда только для данных)
хотя там префиксы использовались - один для использования второй памяти, второй для использования H1L1 вместо HL - не очень интересно

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

вобщем нога отвечающая за разрядность шины данных будет называться XAD и как я уже говорил - при 0 оно будет юзать 8 битную шину данных с физической адресацией 64 Кбайт (мультиплицироваться будет младшая половина выводов AD), при 1 (или не подключено - подтягивающий резистор там будет) оно будет юзать 16 битную шину данных с физической адресацией 128 Кбайт (или 64 Кслов - при этом все 16 ног AD будут мултьтиплицированными адресом и данными)

предположим, что мы завели флаг доступа во второй банк памяти (и даже расположили его там же где и у КР580ВМ1 - D3 регистра F) в случае 16 битной внешней шины данных всё ясно - оно просто устанавливает старшую ногу адреса в 1, а вот в случае 8 битной можно предложить такой фокус - вместо мультиплицирования младшего байта AD будем считать что так оно обращается к старшему байту! как идея?

pvlad · Post by **pvlad** » 12 Dec 2009 15:43

Shaos wrote: т.е. предполагается, что внутри какая-то память будет, так?

Думаю, все адресное пространство должна быть оперативная память и никаких "РФ". Выше уже писал, что можно применить последовательную флеш (для холодного старта), откуда ПЛИС скачивает загрузчик, размещает в адресном пространстве и передает ему управление. После этого, этот загрузчик "решает" откуда и как он будет грузить код на исполнение.
Протокол и логику загрузки мы можем обсудить позже.

Shaos wrote: если речь идёт об аналоге выводов 8085, то получается мультиплексированная шина адреса и данных - в таком случае я могу предложить расширить шину данных до 16 бит...

"об аналоге выводов 8085" я видимо высказался опрометчиво. Дело в том, что мультиплексирование усложняет работу с периферией. Когда делали 8085, то ставка стояла на дополнительные интерфейсные чипы. У нас их нет, и в будущем будет все сложнее найти. Может не стоит мультиплексироваться? Более того, если будут позволять выводы ПЛИС, то можно несколько выводов определить как чип-селекты внешних портов, настройка адресов которых делается через тоже внутренние порты-регистры (загружаемые дешифроторы). Это упростит, и сделает более универсальной дешифрацию внешних портов.

Что касается "шину данных до 16 бит". Сделать можно все, но не хотелось бы получить очередную "советскую рационализацию". Как программно его поддерживать - ваять свою среду разработки? И что, принципиально, нового мы получаем, кроме головной боли? Если мы поставим память 10nc и максимальную тактовую ПЛИС, то производительности будет выше крыши.
Я за совместимую классику для 8085, но не буду возражать против каких-то "изобретений" для 6502.

Shaos wrote: потом можно предположить, что у нас будет несколько (2,3,4) 8-битных портов, которые можно отобразить (программно) на любые из 256 доступных и также иметь возможность работать с отдельными битами этих портов (а также настраивать их независимо друг от друга на ввод или вывод)

Совершенно верно, но кроме этого, хотелось бы иметь несколько внутренних портов для конфигурирования - порт для переключения тактовой частоты, порты (регистры) конфигурирования и адресации портов (извините за каламбур!) и т.д.
Кроме того, следует помнить о системе разработки для такого гибрида. Сомневаюсь, что нам кто-то напишет мощный эмулятор, новый ассемблер и т.д. Следует учитывать технологию загрузки кода и его отладку. Может быть сразу закладывать некий аппаратный "JTAG", который при не сложном внешнем программном обеспечении на РС (через порт LPT, к примеру) будет позволять загружать код, делать по-шаговый режим, 1-2 точки останова и смотреть состояние регистров? Более того, я бы в наш гибрид вмонтировал бы простенький символьный видео-синхронизатор - что-то типа "а ля Микро-80". Монохром, 60гц под ЖКИ монитор. Это позволило бы (как вариант) отказаться от кросс-средств (которых нет!) для разработки, а адаптировать кое-что из "приданного Ориона" (в символьном варианте). В этом случае, средства разработки можно было бы разместить на самом контроллере.
Еще добавил бы (если позволит кол.выводов ПЛИС) порт управления LCD-индикатором. Для контроллеров управления это основное устройство вывода информации.

Shaos wrote: по идее можно спец-вывод завести - начальное состояние процессора после включения: 0 - 6502 или 1 (или не подключено) - 8085.

адресное пространство между ними можно поделить так...

С первым тезисом я согласен, а второй не понял. Зачем нам делить адресное пространство между процессорами, если они одновременно не будут работать? Как распределить адресное пространство для 6502 - я не знаю. Что касается 8085, то уже писал выше: 64К ОЗУ и порты через IN/OUT. Плюс внутренние порты конфигурирования и управления. Сомневаюсь в целесообразности делать ОЗУ 128К - это не Орион, где требуется совместимость. Мы делаем контроллер для управления. Думаю, практичнее на плате такого контроллера разместить ММС/SD-флеш, и подкачивать блоки в память для исполнения. Это более универсально, чем страничная память, которую все равно откуда-то надо "напичкивать кодом". Да и диспетчер памяти не надо городить. Что касается битовых команд, то какой-то префикс придется вводить.

Shaos · Post by **Shaos** » 12 Dec 2009 16:38

pvlad wrote:Когда делали 8085, то ставка стояла на дополнительные интерфейсные чипы. У нас их нет, и в будущем будет все сложнее найти.

Два регистра 74LS573 сложно найти?

Их будут выпускать ВЕЧНО

pvlad wrote: Что касается "шину данных до 16 бит". Сделать можно все, но не хотелось бы получить очередную "советскую рационализацию". Как программно его поддерживать - ваять свою среду разработки?

Программно ничего не изменится - это просто скорости добавит, т.к. из памяти по два байта будет читаться за раз. Из минусов - непредсказуемая скорость работы команд (хотя всё равно времянки другие будут) - например 2-байтовая команда начинающаяся с чётного адреса отработается быстрее, чем таже самая команда начинающаяся с нечётного - из-за двух обращений к памяти в этом случае (хотя с другой стороны если следом идёт 1-байтовая команда, то чтения из памяти уже не будет, т.к. байт уже считан)

pvlad wrote:
Shaos wrote: потом можно предположить, что у нас будет несколько (2,3,4) 8-битных портов, которые можно отобразить (программно) на любые из 256 доступных и также иметь возможность работать с отдельными битами этих портов (а также настраивать их независимо друг от друга на ввод или вывод)
Совершенно верно, но кроме этого, хотелось бы иметь несколько внутренних портов для конфигурирования - порт для переключения тактовой частоты, порты (регистры) конфигурирования и адресации портов (извините за каламбур!) и т.д.
Кроме того, следует помнить о системе разработки для такого гибрида. Сомневаюсь, что нам кто-то напишет мощный эмулятор, новый ассемблер и т.д.

Я напишу - нет проблем

Это я про эмулятор и ассемблер - опыта хоть отбавляй (скормно намекая на свой эмулятор ориона и универсальный ассемблер)
А вот среду разработки - не занимался пока, но очень хочется попробовать (глядя на то как некоторые в GTK быстро ваяют редакторы-отладчики выдуманных архитектур)

pvlad wrote: Следует учитывать технологию загрузки кода и его отладку. Может быть сразу закладывать некий аппаратный "JTAG", который при не сложном внешнем программном обеспечении на РС (через порт LPT, к примеру) будет позволять загружать код, делать по-шаговый режим, 1-2 точки останова и смотреть состояние регистров? Более того, я бы в наш гибрид вмонтировал бы простенький символьный видео-синхронизатор - что-то типа "а ля Микро-80". Монохром, 60гц под ЖКИ монитор. Это позволило бы (как вариант) отказаться от кросс-средств (которых нет!) для разработки, а адаптировать кое-что из "приданного Ориона" (в символьном варианте). В этом случае, средства разработки можно было бы разместить на самом контроллере.

Я подумаю, хотя кросс-средства мне создать много проще

pvlad wrote: Еще добавил бы (если позволит кол.выводов ПЛИС) порт управления LCD-индикатором. Для контроллеров управления это основное устройство вывода информации.

При наличии 8-битного порта и 3 дополнительных сигналов (можно взять из другого 8-битного порта) LCD-индикатор подцепить не проблема - программная поддержка пишется на раз-два-три для ЛЮБОЙ архитектуры

pvlad wrote:
Shaos wrote:адресное пространство между ними можно поделить так...
С первым тезисом я согласен, а второй не понял. Зачем нам делить адресное пространство между процессорами, если они одновременно не будут работать?

в том то и дело, что будут - основной интерес иметь спец-команды переключения типа процессора, чтобы одна и таже программа могла исполнять свои части на разных процах

pvlad wrote:Что касается битовых команд, то какой-то префикс придется вводить.

ну скорее не префикс, а спец-команда (одна) после которой идёт второй байт - детализация битовой операции

pvlad · Post by **pvlad** » 13 Dec 2009 07:11

Shaos wrote:Два регистра 74LS573 сложно найти?
Их будут выпускать ВЕЧНО

А чем хуже, если обходиться без них? Мы делаем не процессор, который вставляется в панельку вместо 8085. Это будет практически законченный контроллер, к которому можно будет подключить дополнительную плату расширения интерфейса. Зачем усложнять дополнительную плату еще двумя регистрами?
На счет "ВЕЧНО" сомневаюсь...

Shaos wrote:Программно ничего не изменится...Из минусов - непредсказуемая скорость работы команд...

Это и будет тот момент, который перечеркнет саму цель - контроллер для управления. Не мне Вам объяснять, что не предсказуемость в задержках перечеркнет весь смысл в использовании такого контроллера.

Shaos wrote: Я напишу - нет проблем
Это я про эмулятор и ассемблер - опыта хоть отбавляй (скормно намекая на свой эмулятор ориона и универсальный ассемблер)
А вот среду разработки - не занимался пока, но очень хочется попробовать (глядя на то как некоторые в GTK быстро ваяют редакторы-отладчики выдуманных архитектур)

Это прекрасно, но основной акцент я ставил на первую часть своего тезиса - программное управление конфигурацией контроллера.

Shaos wrote:
pvlad wrote: ...Более того, я бы в наш гибрид вмонтировал бы простенький символьный видео-синхронизатор - что-то типа "а ля Микро-80".
...В этом случае, средства разработки можно было бы разместить на самом контроллере.
Я подумаю, хотя кросс-средства мне создать много проще

В этом случае, я подразумевал себя, как исполнителя. Думаю, наличие двух вариантов систем разработки - это очень хорошо. Кроме того, в контроллере будет еще один интерфейс вывода информации. "Народ" на AVR-ках делает такой видео контроллер для МК, да и еще за ноу-хау считает. А у нас будет бесплатно, как дополнение!

Shaos wrote:в том то и дело, что будут - основной интерес иметь спец-команды переключения типа процессора, чтобы одна и та же программа могла исполнять свои части на разных процах

Высший замысел этого, пока, плохо себе представляю...

Shaos · Post by **Shaos** » 13 Dec 2009 08:55

pvlad wrote:
Shaos wrote:в том то и дело, что будут - основной интерес иметь спец-команды переключения типа процессора, чтобы одна и та же программа могла исполнять свои части на разных процах
Высший замысел этого, пока, плохо себе представляю...

Замысел в том, чтобы одним и тем же контроллером пользовались и любители 8080, и любители 6502 и экспериментаторы типа меня

По поводу шин адреса и данных - можно конечно всё напрямую вывести, но это будет уже 16+8+2=26 ног (27 если считать M/IO), которые можно было бы отдать под порты ввода-вывода. А что если сделать настраиваемым формат использования портов ввода-вывода (как у многих микроконтроллеров - если цель в итоге получить микроконтроллер в одном корпусе)? Например по умолчанию скажем имеем 4-5 8-битных портов ввода вывода без внешней памяти (с внутренними скажем 2К на бутлоадер и 8К на встроенное озу), но при желании можно настроить порты на мультиплексированную шину адреса и данных или (как ещё одну опцию) отдельные шины адреса и данных, что соответственно уменьшит количество свободных портов ввода-вывода.

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

pvlad · Post by **pvlad** » 13 Dec 2009 13:45

Shaos wrote: Замысел в том, чтобы одним и тем же контроллером пользовались и любители 8080, и любители 6502 и экспериментаторы типа меня

Я о том же - кому что нравится. Но я не представляю ситуации, чтобы часть кода выполнял 8085, потом встречается команда переключения процессора и остальной код выполняет 6502. Это что-то новое. В чем уникальное различие этих процессоров, чтобы в одной задаче необходимо было попеременно использовать два процессора?

Shaos wrote: По поводу шин адреса и данных - можно конечно всё напрямую вывести, но это будет уже 16+8+2=26 ног (27 если считать M/IO), которые можно было бы отдать под порты ввода-вывода.

Будем считать - это первый вариант:
Шина 29 ног (Adr+Data+M/IO+WR+RD), порты 4х8=32ноги. Это уже 61+остальное служебное управление, видео и т.д.=100ног. Внешнюю память (к примеру, CY7C1019D 128К!) вешаем на шину. Внутреннюю память 8К используем на видео синхронизатор. В ПЛИС делаем только первичный загрузчик, который из последовательной памяти вытаскивает основной Bootloader, который и грузит основное программное обеспечение: СРМ или просто программу из ММС-флеш (к примеру). Почему нужна такая двухэтажная система загрузки? Чтобы не лазить в ПЛИС для переделки загрузчика. Последовательную память (I2C или SPI что больше нравится. С SPI проще) можна прошить на чем угодно - это не проблема. В первых ячейках этой последовательной памяти находится служебная информация, как-то: адрес загрузки, количество байт, адрес передачи управления. Загрузчик, который находится в ПЛИС читает эти данные с последовательного ПЗУ и грузит остальной код в ОЗУ, и передает управление. При этом загрузчик в ПЛИС никогда не нужно переделывать, а в последовательном ПЗУ может быть что угодно: загрузчик СРМ, просто программа, если ПЗУ достаточно большое, или Монитор и т.д. Тоесть, за счет "двухэтажности" мы получаем универсальную систему, при этом ПЛИС прошивается один раз, и больше там нечего делать.

Shaos wrote: А что если сделать настраиваемым формат использования портов ввода-вывода (как у многих микроконтроллеров - если цель в итоге получить микроконтроллер в одном корпусе)?

Пусть это будет второй вариант. Давайте прикинем, что мы выиграем, а что проиграем. Плюс: экономим ноги ПЛИС - шина, мсх-ма памяти, чуть меньше печатная плата. Минус: теряем 2-3 порта, мало внутренней памяти под код. При расширении памяти, все равно микросхему придется повесить, да и еще расхлебывать мультиплексирование. Ну и, видимо, дополнительная плата расширения.
Если честно, то первый вариант более логичный. Я бы от второго отказался. Кроме того, можно для первого варианта сделать дополнительный режим: внешняя память не ставится (но место на печатке есть), а используется только внутренняя 8К, т.е 2К видео-ОЗУ+6К под код. Как переключать эти модификации первого варианта - не знаю. Может быть через дополнительную ножку ПЛИС?
Но здесь хотелось бы уточнить, какие варианты ПЛИС по ногам применимы в нашем случае. От чего плясать?

Shaos wrote:По поводу времени выполнения команд - это будет CISC и скорее всего с микрокодом, т.е. времянки в любом случае будут отличаться от оригиналов и расчёт времени выполнения того или иного куска программы уже будет нетривиален...

Согласен, но необходимо чтобы одна и та же команда в любой ситуации выполнялась за одно и тоже количество тактов. Пусть будет другое количество тактов, чем в 8085 и другое время выполнения, но оно должно быть стабильным в любой ситуации для данной команды. Иначе задержки в программе не просчитать. А сделать новую справочную таблицу количества тактов на каждую команду - не сложно. Другое дело, необходимо сделать несколько тактовых частот, переключаемых с помощью внутреннего порта. Например, минимальная, максимальная и 1-2 промежуточные. Частоты должны быть кратны под UART. Если останутся своб.ноги, то можно сделать выход тактовой частоты (после какого-то деления).