FPU

[Viktor2312]

причём тут TS-Conf

А что это?

---------- Post added at 17:56 ---------- Previous post was at 17:55 ----------

нет, не пойдёт ))

Нет, значит нет.

[Ewgeny7]

А мы сможем рулить орбитальной группировкой сразу после установки FPU?
Если нет, то - нафиг.

[Reobne]

Ewgeny7, Сможем!
Сразу же у нас появится эта возможность. Чтобы ей воспользоваться надо будет написать программку-симулятор. И в реальном времени, в виртуальном пространстве, с помощью клавиш OPQASp.

[Alex Rider]

А мы сможем рулить орбитальной группировкой сразу после установки FPU?

Сможем. Надо будет только Elite поправить

[troosh]

Теоретически сделать такой сопроцессор нет проблем. Практический проблем куча. Главная: наперкуа? Вот один товарищ хотел как-то:https://github.com/cheveron/sebasic4...h-Co-processor Да воз ныне там...

---------

Раз тут обсуждаются концепты, то можно рассмотреть такие варианты:

0) Т.к. эмулятор бейсиковского калькулятора всё равно нужно сначала написать хотя бы в виде прототипа, то для начала стоит сделать как доработку какого-либо ZX эмулятора. Причем, для отладки очень удобно делать снапшот системной памяти и регистров Z80 как на входе по адресу 0x38, так и на всех возможных выходах из калькулятора. Там собираем кучу примеров для эмулятора калькулятора и долго и муторно добиваемся, что наша реализация на Си или asm другого процессора будет давать точно такой же результат (такую же разницу в снапшотах)..

1) Замена Z80 своей реализацией на FPGA (пропускаем совсем дорого).

2) Замена Z80 своей реализацией на каком-нибудь ARM микроконтроллере + CPLD для реализации интерфейса с остальной системой (PSoC 4 тут как бы должен хорошо подойти). На ARM крутиться эмулятор Z80, при попадании адрес 0x38 переключаемся встроенный в ARM программный эмулятор спектрумовской плавучки.

3) Тот же ARM+CPLD устанавливаем между системой и реальным Z80, пока не дошли до выборки команды из 0x38 прозрачно работает только Z80, а иначе вместо кода, который считал бы Z80 из ПЗУ, ему подкидывает ARM несколько инструкций которые позволяют считать требуемый контекст Z80 (значения его регистров).
Потом, пока ARM вычитывает калькуляторные инструкции и сам непосредственно работает с системой памятью, а в это время Z80 получает постоянно инструкцию перехода на и инструкцию назад и таким образом дожидается пока калькулятор в ARM отработает (ес-но Z80 при этом не гадит на системной шине). Результаты (значение), которые нужно прописать в регистр Z80, выполняются подсовыванием соответствующих инструкций в Z80 до того, как ему отправят RET, чтоб он вернулся на место где был вызов калькулятора после того как его снова подключат в систему.

4) Вариант предыдущего пункта, но стоим не между процессором Z80 и системой, а сбоку, как ПЗУ (аля TR-DOS) или DMA устройство. Слушаем шину, встретили выборку инструкции по 38h, - начинаем пихать свои инструкции, а не то, что в ПЗУ. Опять же вычитываем контекст, а далее либо отправляем Z80 в короткий сон, а само через DMA получаем, всё что нам нужно, либо периодически отправляем нужные инструкции, что за нас Z80 что-то из памяти прочитал, либо записал. В пределе такой устройство вообще можно подключить вместо ПЗУ без дополнительных проводов (только оно не будет знать, что это именно началась выборка команды, а не простое чтение), кроме того не будет работать в системах, где у шина данных ПЗУ не подключена напрямую к процессору и нет возможности со стороны ПЗУ считать записи в ПЗУ... oops, не без дополнительных проводов не получиться - нужно понимать, что Z80 пишет в память...

[shurik-ua]

Теоретически сделать такой сопроцессор нет проблем. Практический проблем куча. Главная: наперкуа? Вот один товарищ хотел как-то:https://github.com/cheveron/sebasic4...h-Co-processor Да воз ныне там...

Интересная статья - возьму на вооружение.

Раз тут обсуждаются концепты, то можно рассмотреть такие варианты:

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

к тебе встречное предложение - заняться разработкой FPU для uGFX.

да думал об этом, но тот вариант что я задумал займёт около 5к ЛЕ и наверное не влезет.

[shurik-ua]

на opencores.org мне приглянулись несколько проектов:
FPU - http://opencores.com/project,fpu100
Cordic - http://opencores.com/project,cf_cordic или http://opencores.com/project,verilog_cordic_core

На сколько эффективно и оправданно будет работать FPU в сравнении с параллельными вычислениями на трех NextZ80@42MHz и какие операции способно будет выполнять FPU?

думаю это будет работать намного быстрее если реализовать на "Конечном Автомате" - да и для n>1 процессоров писать софты весьма нетривиальная задача )

[troosh]

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

Возможно я не до конца понимаю в чём смысл делать свой FPU в FPGA, когда можно взять заметно более быстрый ARM из младших кортексов и на его асме сделать функции бит в бит по результату совпадающией с оригинальной реализацией на Z80 (когда есть эталон отладка милое дело, иначе ад). Либо взять Cortex-M4 уже с железным FPU, если плевать на точность... Но это я по себе сужу, если б я такое решил делать.

Или тут какая-то блокировка в сознании, что это уже не правильно осквернять z80 каким-то армецом (но avr на клавиатуру это норм)? Или пинов не хватает, - ну так я выше расписывал как их сэкономить...

Улучшать только тригиометрию не имет смысла, тем более такими экзотическими способами, главное чтоб были быстрые плюс и умножение. Разве что под какой-то конкретный алгоритм, например при текстурировании.

Раз зашла речь о NextZ80, то там можно сделать, чтоб на некотрых участках ROM, переставал отслеживаться тайминг как у оригинального Z80 (начинал работать на полной скорости), а далее добавлять инструкции R800, пока это не будет вредить совместимости другим программам (помню были защиты от реверса программ на спектруме, которые использовали множество недокументированных опкодов и безумное число префиксов - они сдохнут от изменения системы команд и ПЗУ).

[shurik-ua]

Возможно я не до конца понимаю в чём смысл делать свой FPU в FPGA, когда можно взять заметно более быстрый ARM из младших кортексов и на его асме сделать функции бит в бит по результату совпадающией с оригинальной реализацией на Z80

Просто платка с FPGA уже есть - под неё и пишу, а ARM ещё спаять надо )

Или тут какая-то блокировка в сознании, что это уже не правильно осквернять z80 каким-то армецом

нету никакой блокировки - с ARMами дела не имел просто - была б у меня платка с ARMом - на ней бы упражнялся ))

тоб на некотрых участках ROM, переставал отслеживаться тайминг как у оригинального Z80

там как бы изначально нет такой привязки - всё заточено на максимум скорости.
Но опять же повторюсь - на процессоре всё равно не сделать быстрее чем на конечном автомате в FPGA - разве что если процессор на 500+ МГц или ядер овердохрена )

[troosh]

там как бы изначально нет такой привязки - всё заточено на максимум скорости.
Но опять же повторюсь - на процессоре всё равно не сделать быстрее чем на конечном автомате в FPGA - разве что если процессор на 500+ МГц или ядер овердохрена )

Я имел ввиду, что для совместимости (с плёнки погрузить, мультиколор насладиться) можно сделать там режим когда тайминг у команд 3.5МГц, но на некоторых участках ПЗУ будет разгоняться...

На сложных проектах прототип на FPGA может быть медленнее раз в 100 того же верилога в кремнии (суже по тому, с чем реально сталкивался).

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