Он же написал как собирается обойти этот подводный и очевидный камень.. Z80 с тактовой частотой 500 кГц спасет отца русской демократии

да это неинтересно :)
А на 3,5 уже туго будет без отладки про 7МГц нереально

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

Просмотри ещё разок тему "ARM - процессор Speccy 21 века". Там есть пара убедительных доводов как "за", так и "против". А вообще можно посчитать, сколько у тебя например на один машинный цикл Z80 на определённой частоте уходит тактов АРМа и попробовать по коду влезть в этот промежуток так, что бы АРМ успел обработать состояние Z80.

Все присутствующие здесь инженеры с опытом( я работаю в области Embedded System c 1983 года, начинал на i8080 Intellec MDS Series-II) понимают, что ни за день, ни за неделю новыми для себя технологиями не овладеть. У меня с полгода назад были некоторые эксперименты на ARM7 Philips LPC, купил книжку, установил IDE c GCC Keil, попускал примеры), опыт начальный. Сейчас скачал IAR Embedded Workbench for ARM версию для быстрого старта с ограничением 32K кода. Почему надо каждый день муссировать тему, что "зная Андрея"...Игорь знал меня не в самые лучшие для меня времена и продолжает экстраполировать в будущее. Игорь, это в конце концов дурно, публично заявляю. Я в твой проект не лезу, и желаю тебе всяческих успехов в его реализации. Отчего же ты те же самые методы, которые не нравятся по отношению к твоему проекту со стороны других людей, вовсю используешь здесь? Ты считаешь это честной конкуренцией?

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

Потому что дешевле и удобнее на ПЛИС такое делать. В тобой поставленой задачи ты получается используешь АРМ "не по назначению". Право естественно твоё, но слежение за шиной и делегация событии от/к Z80 можно легко сделать простой FSM, которая просто кричит о ПЛИС :) При том, зачем тебе 256К в этом случае? Ты как-то собираешься манипулировать данными с шины до доставки их к Z80?

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

Конечно! Простой пример: повороты на плоскости объектов перед выводом на видеоконтроллер. Кто быстрее их сделает: z80 без уменожения или arm7? В том то и дело, что поскольку у них память общая, и к тому же z80 работает только тогда, когда ARM7 ему это позволяет ( просто за счет асинхронности работы z80 с внешней памяти), то просто не стоит проблема разделения этой общей памяти.

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

Из 256К - 128К (по крайней мере) это обычная память ZX Spectrum 128K!

ПЛИС. Ибо в современных ПЛИС есть уже мультипликаторы, которые работают внутри на очень больших скоростях.

О! Т.е. половину от АРМового кода уже оттяпана :) Теперь подумай о том, что раз вся память Спектрума у тебя в АРМе сидит, то выходит АРМу надо как-то либо видеосигнал генерировать, либо по прерыванию отрываться от основной работы и выдавать данные текущей отображаемой строки внешнему видеоконтроллеру. И всё это посреди обработки машинного цикла Z80.

Сколько бы инструкций пришлось выбрать z80 ИЗ ПАМЯТИ, программно выполняя умножение. ВСЕ это время он теперь отдыхает, поскольку ARM7 делает это достаточно быстро, чтобы не пропустить обновление кадра. Но замечание существенно, согласен, видеоконтроллер не должен быть еще одним активным устройством системы при такой системной памяти. ARM7 должен сбрасывать в него внутреннюю видеопамять на очередной кадр быстро и целиком.

этого недостаточно! такой умножитель необходимо еще имплантировать в набор команд z80-core и поддержать компилятором. GCC перебирать?

при размере стандартной видеопамяти ZX Spectrum это не должно занять много времени, если есть КПДП тем более

Ага, т.е. появляется ещё и буфер кадра, который надо заполнять по какому-либо событию (например по деактивации сигнала гашения, ака начало активной области). Теперь берём размер экрана - 6912 байт тебе надо перебросить из внутренней памяти во внешнюю. Железного ДМА у R40008 нет, можно сделать только софтовое на FIQ, т.е. у тебя в лучшем случае понадобится 6912 тактов АРМа для переброски (все подготовки обработчика FIQ здесь опущены). Сколько инструкций Z80 ты пропустишь при этом? Или Z80 будет висеть на /WAIT? Тогда это тормознутый клон будет из всех, который ещё и АРМ имеет на борту. Плюс ты собрался делать манипуляции с содержимым памяти, поворачивать и т.п. , я так понимаю имелась в виду видеопамять? Успеешь? А вот в ПЛИС можно это всё дело действительно распараллелить, что одно другому мешать не будет. И скорость выжать оптимизацией в два раза выше чем у предлагаемого АРМа.

Что значит имплантировать? Расширить систему комманд Z80? Тогда скорость Z80 как такового упадёт. К чему такой изврат? На ПЛИС быстрее получится кстати всё-равно. И опять же, GCC для новых команд тебе придётся "перебирать" и так и так.

если экран не обновлялся - то не надо пересылать...в случае тормозного z80 все равно на время преобразований экран пришлось бы гасить? что мешает поступить так и здесь, но погасить его на значительно меньшее время...
>Что значит имплантировать?
у z80 нет кода инструкции для аппаратного умножения, его необходимо в вашем случае ввести, в моем нет...так как при компиляции в этом месте просто будет код для arm7, а при выполнении, поскольку весь поток команд идет через arm, он будет знать, что эта команда для него и выдавать ее через параллельный порт ее не нужно, перебирать gcc не потребуется...нужен просто хитрый линковщик и компоновщик объектных модулей, вот его придется написать для получения результирующего mixed-code.

Я так понимаю, что всё определяется достаточно простой вещью, а в частности количеством выполненных команд ARM за один такт Z80 (3.5 мГц). Ктонибудь может сказать сколько в текущий момент развития ARM7 (максимально производительный камень) может выдать производительности за такт Z80го? а то я не в курсе ARM процов..

Ты уже написал тут и для ARM9 на 200MIPS будет не скучно

ARM7 в FIQ входит тока за 24 такта ядра (1,5 такта процессора Z80) а еще пересылка то есть в секунду уходит тока 8 милионов тактов ядра тока на вход в прерывания

И еще не забывай что у ARM каждый переход это 3 штрафных такта, а код того что ты описываеш линейностью не пахнет

а они унифицированы (ядра CPU) так что дели MHZ и умножай на 2...но это бессмысленное сравнение, т.к. ARM7 не PIC, у него не все команды выполняются за 1 такт

То есть для 66MHz и 3,5MHZ самая быстрая команда ARM выполняется в 37,7 быстрее...это типа 486DX66

Оттого и событие (прерывание, если так удобнее). При этом придётся так же

Почему гасить? Что ты имеешь в виду под гасить?

Ага! Осталось только весь gcc научить понимать дополнительно Z80 асемблер + научить отличать его от ARM кода. Стоит овчинка выделки?

С коих пор PIC выполняет команды за один такт?

ну пропускать кадры...так здесь аналогично, только полюбому меньше затормозит
а это зачем?
исходник пропускаешь сперва с ключом -arm7,
затем с ключом -z80
А остальное на условной компиляции, а можно автоматизировать, пропуская через анализатор кода, который знает, какие операции у z80 тормозные.
Я ж говорю, линковщик хитрый нужен.
ну за два...кроме команд перехода и еще чего-то там...подразумевалось, что у ARM команды отличаются большим различием по времени выполнения

"Хитрость" линковщика заключается именно в организации mixed-потока кода инструкций...по несуществующим командам у ARM7 произойдет "исключение" а там вступит в силу кусок кода, поддерживающий выполнение на z80. Туманно, потому как это я еще не совсем придумал как сделать, здесь много вариантов.

Вот, быть может один из вариантов mixed code stream:

код ARM7...код несуществующей команды ARM7,код Z80...RST ?, код ARM7... и т.д.

Если бы у z80 была обработка несуществующих команд, или есть, че то я не помню.

Демомейкеры и сочуствующие порвут :)

? Чего-то фигня какая-то. У тебя после всех компиляций прошивка получается, бинарная, которую ты скармливаешь АРМу. О каком смешаном коде речь идёт? Как ты в рантайм скажешь АРМу "а вот теперь это не твой код, а твоего подопечного, посему отдавай просто так как есть и не исполняй его"?

За два, не за четыре? Что имеется в виду под большим различием по времени выполнения? Как раз у АРМа можно все команды считать однотактными.

Т.е. это по-моему софтовые прерывания АРМа будут юзатся (исключительная ситуация). Быстро не получится.

У Z180 есть например, но как-то сложно. Вроде в eZ80 было что-то более продвинутое в Z80-линейке.

"Обычная обработка данных 1s;
Обработка данных с числом сдвигов, указанных в регистре 1s+1i;
Обработка данных с записью в регистр PC 2s+1n;
Обработка данных с числом сдвигов, указанных в регистре, и с записью в регистр PC 2s+1N+1i;"
цитируется по "Обзор системы команд ARM7"

В общем сравнение производительности с z80 это отдельная проблема.

зато геймеры одобрят :)

Кстати, исходники эмулятора ARM7 в инете нигде не лежат?

Все кроме N иогут быть 0, зависит от операндов

Есть такой пакет под названием Proteus, он тебе зело должен понравится. Там есть симулятор под названием VSim, почитай вот здесь http://www.labcenter.co.uk/index_uk.htm

Sourceforge.net

Нашлись в исходниках:
Simlt-ARM, Generator ARM, The Amsterdam Compiler Kit.
Но пока до эмулятора ZX Yellow Lines Spectrum еще далеко, больше интересовал готовы инструментарий для
разработки. Хотел было юзать IAR Embedded Workbench for ARM, но спецы с Телесисов уговорили перебраться на Keil, благо я с ним баловался на LPC, откомпилял вчера на ночь глядя моргалку битом порта...железа нет...симулятор моргает :)

я вообще теперь хотел бы инициировать здесь обсуждение схемы включения...чтобы был предметный разговор, скачайте себе файл doc1354.pdf с www.atmel.com или какой-то другой, где есть "раскопытка" чипа AT91R40008

это нужно для программирования...хотелось бы обсудить
1) межсоединения z80 - AT91R40008(ясно что шину данных можно включить непосредственно, со всеми другими соединениями возможны варианты);
2) выбор внешних устройств для EBI (может быть до 8 внешн.
устройств, поскольку чип обеспечивает до 8 Chip Select-ов, включая внешнюю память, видеоконтроллер, A26...ЧТО еще?) и размера страниц Programmable Page Size 1,4,16,64 MBytes.