ARM - процессор Speccy 21 века

[Black_Cat]

Юзать eZ80 особого смысла не вижу

Если техпроцесс находится на стадии трассировки платы, то обсуждать есть смысл или нет - бесполезно. Такие вопросы обсуждаются на этапе разработки концепции. Проголосовать за генерацию новой рубрики "Концепции и концепты" можно здесь: http://zx.pk.ru/showthread.php?p=56338#post56338

[captain cobalt]

Дешевле 100 тоже не сделать, т.к. высокая розничная цена,
как на комплектующие, так и на произв. плат.
Кто возмётся разорвать такой замкнутый круг?

Среди прочих, наиболее интересный способ -
заменить хард софтом.

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

Этот способ уже применяется. Примеры:
General Sound - формирование звука универсальным процессором.
Multicolor - отображение через видеопамять объёмом 6912 байт изображения, занимающего в замкнутом виде более 6912 байт.

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

[ZEK]

R4008 = 10-12$
EP1C3 = 15-17$
SRAM 4шт 512x8 = 12-16$
+мелочевки

итого басис по комплектухе около 60$ цены средней взвинчености можно и дешевле.

[Ronin]

S3C4510B (50MHz)
S3C3410X (40MHz)

самсунг уже кидал АРМ-сообщество внезапным прекращением выпуска некоторых кристаллов так что нах. а недорогие нынче скорее Philips-ы

[psb]

вот и я подумал, а че филипсы никто не предлагает? вроде тоже 7 армы есть, дешевые..

хотя, идею я не оч поддерживаю..

[ZEK]

У них слабый выбор контролеров с внешней шиной а так в принципе они вкусней

[icebear]

6. Z80 лучше эмулировать в ARM, чем в ПЛИС.

Почему?

7. ПЛИС, несмотря на возможности, противоречит генеральной линии (пункт 0). Они имеют закрытую архитектуру, а инструментарий разработки будет недоступен для целевой платформы.

Что подразумевается под архитектурой ПЛИС и почему "это" так важно? По поводу средств разработки: ISE или Quartus доступнее, нежели Keil или что-то подобное (про GNU ARM молчу, потому что GNU).

[mungo]

Интересную тему тут подняли...
В данный момент работа моя связана как раз с АРМ. Поэтому некоторые размышления тоже есть.
Во-первых, АРМ на самом деле полностью 32-разрядный, и адресование байта или слова (как в z80) работает не совсем просто.
2. АРМ для самостоятельного изготовления не пригоден в принципе. Корпус на 100 ножек (это минимум необходимого) с шагом 0,5 мм паять в принципе невозможно (по неопытности сразу пробовали). Конечно есть другие корпуса, предназначенные для вставки в колодку. Только 208 ножек колодки с тем же шагом вообще нереально впаять. Промолчу, каково их развести...
3. Готовые платы для разработки на АРМ стоят от 80 баков (галимые). Нормальные вообще от 350.
4. Система команд RISC слишком сложна. Во-первых, команд мало и ими нужно как-то составлять самому сложную команду традиционных процов. Во-вторых, синтаксис достаточно сложен. Конечно Си здесь рулит, но про оптимизацию можно успешно забыть. Только то, что встроено в конкретный компилер.
5. Даже в некоторых АРМ 7-ой серии встроены средства для ускорения выполнения команд - как следствие вычислить время выполнения инструкции становится сложновато.

Вот такие грустные мысли...
Поэтому вывод таков - z80 никто не заменит. Эмуляторов уже и так полно, а полностью правильных нет вообще. И не на арме его делать.
Единственное, для чего его как-то можно попробовать применить, так это заменить всю ту россыпь корпусов, что стоит щаз всюду...

[Black_Cat]

вычислить время выполнения инструкции становится сложновато

Основной идеей в представленных концепциях была работа программной модели Z80 в ARM'e с программной моделью периферии в ПЛИС или программной модели Z80 в ПЛИС с программной моделью периферии в eZ80+ПЛИС. Программные модели без генерации реальной шины, как понимаю, были выбраны именно из-за сложности соблюдения времянок и для упрощения согласования. Считаешь, в случае ARM'a, будут принципиальные трудности с согласованием софтовых моделей? Ведь в таком варианте единственными жёстко завязанными на время сигналами будут внешние сигналы которые можно засинхрить аппаратно.

[ARTi]

Я полностью согласен с тов. mungo , ибо и моя работа на данный момент связана с АРМ, а точнее сейчас это LPC221x (Philips). Его внутренняя шина может достигать 60-80 МГц, а с учетом того, что тут хотят Z80 на 20-40 МГц и т.д., точно сэмулировать Z80 на таких скоростях не удастся. Даже если взять другой АРМ, то вряд ли он будет быстрее на порядок, чем желаемый Z80 40 МГц, за приемлемую цену.
Тут кто-то предлагал, что, мол, можно выдрать из исходников эмулятора Unreal часть, отвечающую за эмуляцию команд Z80 - да, оно конечно можно, только надо себе представлять, что, несмотря на простоту строчек си, после компиляции это превращается в десятки машинных команд на одну эмулируемую инструкцию. Да-да, это и выборка кода инструкции из памяти, и ведение внутренней бухгалтерии (подсчет тактов, циклов и т.д.), и непосредственное выполнение - а еще ведь хочется, чтобы была еще и внешняя аппаратная синхронизация с обычной аппаратурой Spectrum, т.е. АРМ должен реагировать на внешние сигналы и сам выставлять их на шину. А это еще пара-тройка команд, а, скорее всего, и десятков команд.
И пусть многие команды АРМ выполняются за один такт. В результате все равно получается несколько десятков тактов на одну команду Z80, который, хочется, чтобы был максимально близок к оригиналу и имел возможность расширения в сторону быстродействия.
При подсчетах (правда, с некоторым запасом), получается, что нам нужен как минимум полугигагерцовый проц.
Кстати, как там с видеопамятью и вообще памятью? LPC221x, например, не умеет работать с РУ5, ему подавай SDRAM. Значит, либо вручную еще и работу с памятью делать (выставлять адрес, ждать данные), либо..? Что вы... лучше уж использовать SDRAM, одну штучку, на мегабайтик. Но тогда и работу с видеопамятью придется возложить на АРМ. Вывод неусиленного видеосигнала тоже должен будет делать АРМ. А еще он должен будет обрабатывать обращение к портам - не ко всем, но только к некоторым - которые имеют отношение к памяти. А если порт имеет отношение не только к памяти? Beta Interface, например (переключение ПЗУ и пространства портов)... что делать? Как разделять внешнее и внутреннее?
Кстати, насчет ПЗУ Spectrum'а... ой! Может, лучше все-таки сделать действительно вручную работу с РУ5 и ПЗУ, и порты тогда не придется разделять...а? Но тогда - все сигналы должны быть как у оригинала, выставить то, се, подождать там, подождать тут (задержки памяти или вдруг кто -BUSREQ просадит или Reset нажмет?).

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

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

На АРМ все-таки можно, наверное, сделать 3.5, 7-мегагерцовый Z80, но далее вы упретесь в потолок, и еще не факт, что каждый сможет позволить себе такую хреновину
А что хотим? Хотим расширения, если не в архитектуре, то по скорости. Так это вряд ли получится.