APU для Spectrum -арифметический сопроцессор

[andrews]

Можно на STM32 сделать

А на ESP32 можно? Его с Алика можно привезти и дешевле 500руб.

Короме того, возникает вопрос, а зачем в качестве ускорителя использовать машинку, которая как минимум в100 раз быстрее спектрума

Да хоть в миллион раз, если бы стоила дешево. Это ассимитричная архитектура процедурного процессора. Программы пишутся для z80, а процедуры и функции или на нем же медленно, или для ускорения "тяжелых вычислений" аппаратно на сопроцессоре. Тогда то, что на z80 выполняется десятки секунд, на сопроцессоре милисекунды. Не имеет смысл вычислять за доли мкс, если перемещение входных/выходных данных занимает сотни мксек. Пользователь ускорения не ощутит.

[Smalovsky]

Идея сделать сопроцессор на мк stm или esp очень хорошая. У этих мк уже есть операции с вещественной арифметикой, поэтому производительность будет максимальной. Только интерфейс нужен как у 8231/9511.
При быстром арифметическом процессоре хоббисты начнут придумывать новые или ускорять старые 3d игры.

[Sandro]

А на ESP32 можно? Его с Алика можно привезти и дешевле 500руб.

Технически возможно. Прицепить как двунаправленный восьмибитный порт, например, и через него обмениваться даннными и засылать команды. Обвязки .. ну не более десятка корпусов, это точно. Думаю, реально уложиться в 5..6 мелочи. Не, в теории можно и на самом ESP эмулировать шину, но это изрядно пожрёт его производительность.

Да хоть в миллион раз, если бы стоила дешево. Это ассимитричная архитектура процедурного процессора.

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

[Smalovsky]

Не надо усложнять. Железный интерфейс как у 8231/9511, скорость вычислений stm/esp. Очень быстрый нужен сопроцессор.

[Sandro]

Я как раз упрощаю. 9511 именно что и работает в описанной мной модели. А GPGPUшная ещё проще и удобнее -- меньше мороки с синхронизацией и перекидкой данных.

[Dexus]

Интереснее было бы решение с перехватом исполнения участков ПЗУ, отвечающих за калькуляции по RST #28.

[Advertiser]

[andrews]

Давайте хоть с чего-то начнем. ESP32 без проблем возится и будет возится, если Китай нас не сольет, с Алика. Хотя stm32 привычней конечно для многих.

- - - Добавлено - - -

Интереснее было бы решение с перехватом исполнения участков ПЗУ, отвечающих за калькуляции по RST #28.

это выродится в аппаратный эмулятор z80 имхо. Или уже будет разделение памяти между двумя процами, что тоже усложнит задачу.

- - - Добавлено - - -

При быстром арифметическом процессоре хоббисты начнут придумывать новые или ускорять старые 3d игры

и не только игры. Модельки можно делать. Это сейчас модно.

[Dexus]

Эмулировать z80 ни к чему. Достаточно иметь доступ к тому же ОЗУ (чтобы и перехватывать, и читать байткод, и работать со стеком калькулятора), и wait. И такое решение ускорит все бейсиковские программы помимо прочего.

[andrews]

А как разделять при этом память и ввод/вывод? В системе будут два параллельных процессора и при этом z80 об этом ничего знать не будет( не должен), чтобы правильно выполнялся на нем весь старый софт. Когда операции выполняет "процедурник" (PROCOP ) он должен принудительно выполнять возврат из подпрограмм и выводить z80 из HALT(WAIT), а перед этим вводить его или в это состояние или как-то еще "замораживать" z80 на всё время своей работы. Ибо какой смысл давать z80 что-то делать в это время? Как быть с флагами, которые должны установиться в z80 во время ( точнее в результате) исполнения кода процедур? А если в них содержится код обращения к портам и внутренним регистрам? Можно это все проделать подменой кода исполнения z80, потеряв на это некоторое время и похоже все эти проблемы удобнее отладить, эмулируя z80 на процедурнике, а для "рабочего" режима уже все это убрав.

[Sandro]

Интереснее было бы решение с перехватом исполнения участков ПЗУ, отвечающих за калькуляции по RST #28.

А не проще пропатчить само ПЗУ?