Я знаю про проблемы eZ80, поэтому и предлагаю Альтеру. А Z180 так легко вмпесто старого процессора не установишь.

Почему легко не установишь? Там вся проблема сводится к его правильной инициализации, ибо Z180 подразумевает "совместимость" с двумя процессорами - Z80 и HD[не помню индекс]. Дык вот если я правильно понял описание Z180, приоритетная "совместимость" у него именно с этим HD. Посему при ресете прежде чем вываливаться в SOS Спектрума надо инициализировать сам Z180 для работы в режиме Z80.

1. z180 - передвинуть то можно, но проблема останется, т.к. передвигается сразу блоком размера 64 в одно их 4х окон.
2. ez80 - как тут обходить. ez80-50мгц будет раз в 40-50 быстрее z80-3.5мгц - так что оходится просто перехватом. идея вообще в том, что построить некий интерпретатор (не говорю эмулятор ;) ) который "узкие" места совместимости z80 будет обходиить своими макросами. Тут возможны и более высокоуровневые "подстройки" типа фикса под разные времянки Скорпиона/Пентагона/итп.
3. уживется с помощью собственной памяти. на данный момент думается самый простой, недорогой и быстрый вариант (правда малого объема) - sram 512kb, безвайтовая для ez80.

есть еще вариант, возможно при опытах я так и сделаю - z80 сидит где сидит, а eZ80 когда его просят, перехватывает шину по BUSRQ. т.о. совместимость с Z80 обеспечивает он сам. но такая идея мне не нравится - разве что для отладки.

В дополнение используются новые инструкции для работы с этими портами. Сами порты занимают всегда пространство в 64 байта, от #00 до #3F, но конечный адресс каждого порта определяется значением двух старших битов в IСR. По дефолту(сбросу) они в 0, т.е. все внутренние порты располагаются в пространстве #00-#3F (порт #FE допустим при этом свободен, клава работает :), зато не работают джойстик и пол-ВГ). Но можно перенести эти порты в участок #40-#7F, он вроде в Спектруме при упрощёной адрессации не используется. Что ещё важно, при доступе к внутренним портам линии А8-А15 должны быть в нуле, что при жсёткой дешифрации портов не есть случай (#7FFD например). Поэтому понадобится какой-нить StartupROM, который внутренние порты релоцирует.

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

А ну ка, поделись подробностями. Каким образом тебе помогут 512 кил SRAM? Я думал над похожим вопросом для расширение граф. возможностей. Пока надумал, что хватит экранчика 640х480х8, из которых 512х384 видимы, а остальное - бордюр. Спектрум в этом случае работает с карточкой через набор команд (в качестве исполнителя второй Z80, но уже на карте), т.е. напрямую писать в эту память не выйдет. Размер выбран потому что каждый пиксель старого режиме 256х192 может быть отображен 4-мя пикселями при 512х384, т.е. можно будет использовать и старый и новый экран одновременно. Запись в область стандартного экрана "прослушиваются" и здесь есть две возможности записать эти данные в новую область: 1 - программно высчитывать позицию и цвет пикселя под данным, записаным в стандартный экран 2-делать тоже самое, но аппаратно. В первом случае повесить это дело можно на второй Z80 на NMI. А можно сделать на PIC.

Врядли получится с BUSRQ. Как ты будешь делить шину с видеоконтроллером в этот момент? Он, в отличии от Z80, ничего не знает о том, кто хозяин шины :)

Сделать это реально, но во первых в маленькую альтеру Z80 не влезет, а цена маленького циклона около $25 + еще нужна конфигурационная микросхема ПЗУ (которая стоит еще $10) кроме того все современные альтеры работают с напряжениями 3.3В и неже (5.0В не поддерживается).

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

Делать же проц на альтере, который вставляется в сокет обычного процессора смысла нет, поскольку можно купить уже готовый контроллер (как был в спринтере), который работает на более высокой частоте. К тому же использовать альтеру с памятью типа РУ5 или РУ7 это вообще глупость (там внутри есть статическая память, которая может работать на частотах >100МГц).

Есть тут маленькая деталька, которая портит весь такой особый интерес.

1. Хорошие PLIS в розницу и мелким оптом в россии стоят дорого. Для контор наподобие тех в которых я работал конечно доступно ($100 на микруху это тьфу, при том что один комплекс стоит $50 000)
2. Производство многослойной печатной платы и монтаж на нее стоят также дорого, порядка тех же $40.

У меня есть мненьице - PLIS хороши только в производственном дизайне (когда нужно какой-либо контроллер засунуть в PLIS`ину)
для любительства они и для промышеленного дизайна пока дороговаты.

Я считал где-то года 4 назад. Мне дизайн самодельного спектрума выходил что-то порядка $500 долларов на всё про всё. Это впритык. Одна микруха. Одна плата.

Я вот просто выскажу свое мнение, ок?

Меня самодельынй спектрум на плисине интересует только потому что хотелось бы иметь реальный живой спектрум в виде устройства размером с игральную карту. Чтобы сначала подоткнуть его к своему PC, слить туда на флэшку софта, затем подоткнуть его к телевизору, прямо в video+audio, подрубить джойстик, PC-шную клаву и поиграть в Zynaps :-)

Зачем наворачивать все эти супермегамонстры на 300Mhz и модифицировать систему команд?
Да можно конечно, для хэппиненга. Но в практическом плане это абсолютно useless. Просто тупиковый путь. Если мне захочется супермегаэксперементаторства, то я лучше прошью в плисину ARM ядро и буду писать проги на GCC.
Просто все эти "усовершенствованные z80" - их еще запрограммировать нужно. А кто это будет делать? Кому нужно писать программы для этого супер-z80? Меня спектрум интересует потому что там есть наследие в виде программ. Тысяч программ наших ex-USSR любителей. А зачем мне нужен будет девайс запускающий полторы программы?

Кстати, а как в "Спринтере" обошли несовместимости тамошнего пнроца с обычным Z80? Потому что если всё это решаемо, тогда зачем сабж? 21 МГц это и так немало.

в режиме "i'm original z80" ez80 не исполняет, а просматривает (интерпретирует) код.

таким что для ez80 нужна быстрая память - спектрумовская шибко тормозить будет :) спековская будет юзаться только как "медленная" и как "экран".

говорят както через альтеру, но я сам непонимаю как. попытаюсь разузнать у спринтерщиков.

Т.е. попросту эмулирует "Z80 на Спектруме"? Например встречает команду OUT(#FE),A и знает, какой #FE действительно подразумевается? А ресурсов хватит? А смысл в чём?

А почему именно 512? Цена?

Общий вопрос: а что при таком построении останется от Спектрума? Не будет ли это "компьютер на eZ80, эмулирующий Спектрум"? Я всегда думал, что расширение любых возможностей Спектрума подразумевает работу всего старого софта без всяких переключателей и нативных и расширеных модусов. :)

да
меньше - мало. а больше доступных/дешевых одночиповых нет. цена ~3-4$ (12нс)
это невозможно по определнию. часть стандартного софта начинает глючить/неверно работать уже при 7мгц.

только эмуляция z80 на ez80 - занятие гораздо более простое чем на АРМах или x86, т.к. большинство команд пойдут "как есть".

Фига. ВГ93/ВВ55: #1F, #3F, #5F, #7F. Так что фига. :(
ИМХО прав тот, кто утверждает, что надо как на Амиге, два процессора. При необходимости включаем старый Z80. Интересно, можно ли кстати параллельную работу двух CPU организовать? ;) На Амиге между прочим PPC и 68k работают параллельно, ничего, живут...
В качестве обкаточного решения можно предложить монстр-проект. На www.vintage.org предлагалось построить "клеточную" систему на базе C64. А что если на базе ZX сделать? :)))

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

Ну хорошо, можно передвинуть в участок #80-#BF. Там что-нибудь есть?

У нас - вроде нет (если не брать в расчет Profi, GMX и ATM - там портов разных немерянно).
У "них" - контроллеры дисководов и винтов сидят где-то там.

у GS порты #BB/#B3
потому что память работает на прежней частоте - удваивается только CPU CLOCK

У кого у "них"?

Переделать софт и саму GS под другие порты нереально? Мда, о каком eZ80 может идти речь в этом случае???? :)

Хм, если память могёт работать на этой частоте, означает ли это безWAITовость турбы?

железке уже 7 лет, даже если и софта не так много - смысла делать другие порты никакого.ну во всех клонах турборежимы привязаны к основному кварцу - 14мгц, а также к видеоконтроллеру. поэтому сделать безвайтовость не просто. чего не скажешь о профях плат v5.x (но и то - должна быть синхронность с ВК, но там ее в общем случае нет). о спринтере отдельный разговор...

Ну весь смысл есть в ответе на вопрос "на кой в Спектруме Z180?"

Я именно этого ответа и ждал. Основной кварц - это не помеха совсем, а вот с видеоконтроллером - это проблема. Из-за него имхо нельзя брать процессора с тактовой не кратной 3,5Мгц, либо делать хитрый счётчик машинных циклов, который в нужные моменты "тактирует" видеоконтроллер частотой 3,5МГц согласно старой схемы. Задача решаема, но нужно ли это? Ведь столько софта, считающего такты. Кстати, где можно достать нормальную схему Профи 5.х?

=)) они должны быть всегда, более того 7мгц - частота тактирования пикселов. вообще при достаточно большой (в 3-4 раза) частоты работы памяти и проца вайтов быть не должно при правильной переделки схемы - на том же пентагоне например.
из софта считающего такты я знаю только несколько тестов. просто есть программы не привязанные к прерываниям - опрос клавы/игровой цикл/демки где функции считаются независимо от интов, есть еще игры преимущественно старые которые чистят игровое поле в нижнем бордере, а рисуют в верхнем и перед лучом (собственно отсюда и пропадание ракетки в арканоиде на некоторых клонах), есть еще и мультиколоры.
нагугли, да и вообще она где то на форуме была - в отеч. железе или в теме про регенерацию

Вот этой твоей мысли я не понял. Кто "они"? При чём здесь пикселклок вообще? Я имел в виду, что при любой скорости процессора времянки видеоконтроллера изменятся не должны.

Ну вот для первого типа турба даст только прирост скорости, а для второго даже не могу представить последствия. Кстати, сколько есть схем турбы и на чём вообще основывается её работа?

для 1го типа будет прирост скорости, но очень жуткий, т.е. плавность объектов нисколько не улучшится - будет сплошное мелькание перед глазами. очень яркий пример - посмотри invitation dentro от eternity industry на CC000 (забыл название) в unreal'е с нормальным кол-вом тактов (69888-71680) и раза в 3-4 большем (хотя и 175% хватит)
основной принцип трубы - на Z80 подается 7мгц, но в случае, когда CPU запрашивает данные из озу, а в данный момент оттуда читает ВК - на проц. выдается wait пока не освободится озу

Это действительно для всего ОЗУ или первых 16К ОЗУ?

естественно для всего, ведь физически эти 16к не отделены от остальных. вообще в соседнем топике обсуждается регенерация - глянь туда

Ну можно было бы отлавливать обращения в первые 16К (/MREQ, /RD || /WR и A15 в ноле), зато верхние 32К были бы действительно турбированы всегда.

ну е-мое - я же написал _физически_. т.е. если память занята кем-то, то для другого недоступно. на 7мгц высший приоритет всегда у ВК, поэтому z80 ждет

Это всё понятно. Никто не говорил, что при таком решении схема будет простая. Зато правильная. А так - нафига такая полу-турба?

наиболее просто приделывается и эффективность приемлемая