Новый принцип устранения клешинга

[Spectramine]

Вы бы сначала почитали, что такое авторское право, что такое патентное право, и чем они отличаются.

[FSound]

Блин, столько разговоров, два года из пустого в порожнее, а результат на месте. Вы бы хоть скрины показали бы результата вашей разработки, ато чет как-то все пустое...

[CLR]

Так может быть, все это устранение клэшинга на самом деле действительно нафиг никому не нужно?

[Raydac]

Так может быть, все это устранение клэшинга на самом деле действительно нафиг никому не нужно?

так как теперь zx не является рынком, то логично что "устранение клэшинга", работающих рецептов которого уже несколько - чисто умозрительное действие не приводящее ни к каким реальным последствиям, посмотрим может нас "новый подход" удивит каким то новым инженерным решением, автор что то правда затянул интригу и уже есть сомнения что у него есть вообще какое то решение
p.s.
ниже видео устранения клэшинга по технологии zx-poly (технология предложена в апреле 1994го) из существующей игры, напомню что в отличии от spec256, zx-poly предполагалось к реализации на реально существующем железе и не требует виртуальных несуществующих в природе реализаций z80, так же подход позволяет поднять разрешение экрана до 512 на 384 с сохранением обратной совместимости что очень удобно для текстовых редакторов и утилит
в принципе подход продложенный в ZX-POLY может быть портирован на любую бытовую платформу 80-х и раскрасить игры у ЧБ платформ (вроде РК-86) и увеличить глубину цвета у платформ без клэшинга (вроде БК-0010)


пример увеличения разрешения дл 512 на 384 с клэшингом в ZX-WORD

[Raydac]

насколько я понимаю у SPEC256 организация чем то напоминает ZX-Poly - ряд параллельных процессоров, в случае SPEC256 их 8, но при этом реальная логика приложения выполняется по неизмененной программе игнорируя и синхронизируя каждый шаг состояние регистров остальных процессоров отвечающих за цвета с главным, что сильно облегчает адаптацию , но в природе на реальных ЦПУ малореально, и мне поэтому не получается перегнать адаптированные для SPEC256 игры под ZX-Poly хотя очень бы хотелось

[Raydac]

Проблема в другом, нет команды разработчиков, даже такой как у ZX Spectrum Next... Создавайте команду, и всё будет, наработки уже рабочие есть.

какой смысл тратить силы на реализацию в железе того для чего хватает эмулятора в современном мире? к тому же в принципе всё что на FPGA делается это тот же самый эмулятор только "более специализированный", программный много дешевле
аппаратной реализации нет потому что еще в 96м что Зонов что Немо что прочие киты производства, сказали что "поезд ушел" (ну Немо не так сказал, тот просто всё что не расширение памяти предавал анафеме)

[Raydac]

vlad, кстати а где можно найти информацию по EZX формату?

[Raydac]

насчет SPEC256 достаточно четко написано в доке

Each time a z80 instruction is emulated, the same instruction is simulated with data always supposed to be graphics. I´ve named this parallel processor Z80_GFX. Z80_GFX modifies its memory zone accordig to the instructions and doesn´t do anything with Z80´s memory zone. What have we archieved? A faithful emulation of Z80 and a memory zone from which we can obtain 256 colour graphics.

поэтому как я ни пытался заюзать "адаптированную" игру в ZX-POLY в котором все 4 процессора и зоны памяти идентичны, ничего не получалось, это не просто раскрашенные игры и как понимаю поэтому неизмененный SNA идет в комплекте с GFX у SPEC256, так как там разделение именно на ЦПУ и "графические ЦПУ" (когда то кто то уже обсуждал https://zxpress.ru/zxnet/zxnet.pc/5949 на тему сферичности), "ЦПУ" в контексте как понимаю исполняет SNA в то время как "графические процессора" исполняют GFX программу, но GFX ведомые и их состояние не может разъехаться с выполняющим SNA даже если случайно при "раскраске" "закрасить" исполняемые области в GFX, решение очень имхо хорошее, но если взять 8 реальных процессоров, то так засинхронизировать врядли получится без создания кастомного чипа

[Spectramine]

"ЦПУ" в контексте как понимаю исполняет SNA в то время как "графические процессора" исполняют GFX программу, но GFX ведомые и их состояние не может разъехаться с выполняющим SNA даже если случайно при "раскраске" "закрасить" исполняемые области в GFX, решение очень имхо хорошее, но если взять 8 реальных процессоров, то так засинхронизировать врядли получится без создания кастомного чипа

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

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

кстати а где можно найти информацию по EZX формату?

В архиве файла EmuZWin_Addons.zip есть описание формата EZX на английском.

[Raydac]

Но суть в том, что команды управления (переходы, вызовы и возвраты) оба процессора выполняют один и те же, из памяти Z80, поэтому "разъехаться" у них не получится.

ну в принципе правильно значит понял, так как читать команды из одной памяти или синхронизировать состояние по тому кто читает команды из SNA это будет в принципе идентично
и как такое организовать в аппаратном виде на обычных процах, есть идеи?