Проектирование идеального "советского" компьютера

[bigral]

Т.е., всё упирается в производительность 6502 и такое поведение флага переполнения оправдано, хоть и не удобно программистам.

ну вопервых никакой в зравом уме человек и не планировал что 6502 будет менять список спрайтов на каждой строке (это он мог делать в atari2700 но там спрайтов далеко не 64), если бы он это мог то вероятно мог бы и сам рисовать спрайты сразу в строку, предпологалось что этот самый флаг должен потом будет гдето записан в атрибуты спрайта чтобы в конце кадра когда 6502 обновлял список спрайтов он понимал какие из спрайтов должны были высветиться но не смогли изза ограничения в 8шт на строку

как я понимаю в tms9918 именно так оно и работает

посмотрел описание бага - https://wiki.nesdev.com/w/index.php/...ite_evaluation тут говориться что этот флаг правильно ставиться только 9-му по счету спрайту и потом всем спрайтам "по диагонали" таблички спрайтов... изза того что вместо нормального "inc(x) и если переполнение inc(y)" всегда срабатывает "inc(x)inc(y)" + еще шото мутное написанно про копию таблички с отобранными для отображения спрайтами и сигналом write disable...

а к стати откуда схема твоя? можно ее пощупать?

[HardWareMan]

ну вопервых никакой в зравом уме человек и не планировал что 6502 будет менять список спрайтов на каждой строке (это он мог делать в atari2700 но там спрайтов далеко не 64), если бы он это мог то вероятно мог бы и сам рисовать спрайты сразу в строку, предпологалось что этот самый флаг должен потом будет гдето записан в атрибуты спрайта чтобы в конце кадра когда 6502 обновлял список спрайтов он понимал какие из спрайтов должны были высветиться но не смогли изза ограничения в 8шт на строку

Это всё пустые домыслы писателей мумуляторов. Вот все свойства спрайтов PPU OAM и в них нет места флагу переполнения. Ну и так как свойства спрайтов находятся внутри PPU, куда их записывает 6502 через DMA, то считывать их обратно чтобы анализировать какие-то флаги такой же бред, т.к. занимать оно будет столько же времени как и запись.

посмотрел описание бага - https://wiki.nesdev.com/w/index.php/...ite_evaluation тут говориться что этот флаг правильно ставиться только 9-му по счету спрайту и потом всем спрайтам "по диагонали" таблички спрайтов... изза того что вместо нормального "inc(x) и если переполнение inc(y)" всегда срабатывает "inc(x)inc(y)" + еще шото мутное написанно про копию таблички с отобранными для отображения спрайтами и сигналом write disable...

Вот именно, флаг у PPU глобальный, а не на каждый спрайт отдельно. Что касается запрета записи, то да, вот этот триггер запрещает это делать после переполнения счётчика:

Но как я и говорил, он не сбрасывается каждую строку, чтобы повторить процесс анализа переполнения спрайтов в строке, а сохраняется до конца кадра. Если точнее - то т.н. "пререндера". А нужно это для того, чтобы обработчик VBlank'а его точно не упустил и отреагировал. Так что это вовсе и не баг, это нормальное поведение конкретного PPU. Всё остальное, что кажется некоторым программистам как неправильное, им только таким кажется. Не исключаю, что это из-за сравнения с другими PPU, в том числе и вышеупомянутым TMS9918.

а к стати откуда схема твоя? можно ее пощупать?

Сам сделал. Всё, что для этого нужно есть на BreakNES, так же ты можешь посетить тот самый Visual2C02 или эту мою тему. Только я её больше продолжать не намерен, т.к. сначала кончилось моё время, а потом и желание. Вот пост с вопросами про судьбу той темы и мой с ответами на них.

[Радио-86РК]

У Вас есть прототип (эмульгатор) с демонстрацией? ЫЫЫ. Конечно с безобидной игрой или демкой?

Пожалуйста!

1. Эмулятор
2. Отладчик
3. Ассемблер
4. Заготовка к игре «ТЕТРИС»: После того, как кубик построит рамку, запустится режим Тетриса с управлением стрелками клавиатуры

Verilog-модель процессора делаю который год.

[bigral]

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

а техническая возможность есть вычитать регистры PPU через dma? просто может никто не читает потому что там нету смыслу этого делать (изза бага), а изначально предпологалось это делать

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

можно вообще без флага жить конечно и анализировать все 64шт и искать у каких же из них одинаковый Y и какие стоят на каком месте по счету а потом 9 и последующие отмечать как непоказанные, и значит на следующем кадре нужно решить какие из 8 показанных в этот раз не покажутся чтоб показать те что пропущенны в прошлый раз, к тому же наверно иммет смысл непоказать не отдельно стоящий спрайт а тот что наложился на другой спрайт или находится под тайловым уровнем чтоб минимизировать заметность мигания... но наверно если этим заниматься то времени на просчет логики самой игры уже не останется

[HardWareMan]

а техническая возможность есть вычитать регистры PPU через dma? просто может никто не читает потому что там нету смыслу этого делать (изза бага), а изначально предпологалось это делать

PPU не запрещает считывать. Но что тебе это даст, если в свойствах спрайта нет флага "не отображается"? Что касается 2A03, то OAM DMA работает только в одном направлении: ОЗУ => PPU.

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

можно вообще без флага жить конечно и анализировать все 64шт и искать у каких же из них одинаковый Y и какие стоят на каком месте по счету а потом 9 и последующие отмечать как непоказанные, и значит на следующем кадре нужно решить какие из 8 показанных в этот раз не покажутся чтоб показать те что пропущенны в прошлый раз, к тому же наверно иммет смысл непоказать не отдельно стоящий спрайт а тот что наложился на другой спрайт или находится под тайловым уровнем чтоб минимизировать заметность мигания... но наверно если этим заниматься то времени на просчет логики самой игры уже не останется

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

Что касается пайплайна спрайтов, то 8 блоков по 2 сдвиговых регистра + 2 мультиплексора (для реализации отражения по X) занимают приличное место на кристалле, соизмеримое с самой памятью OAM.

Здесь я мультиплексор по X сделал общий, на кристалле он индивидуальный для каждого канала

[свернуть]

Но, допустим, ничто не мешает сделать в FPGA версии PPU их не 8 а, например, 16, добавив бит контроля отображаемости в памяти OAM. Ну и дополнительный бит в регистр управления для отключения всех улучшений во имя совместимости со старыми играми. Вот и будет тебе простой PPU на стероидах.

[Радио-86РК]

Идеaльный компьютер из 17 микросхем

Кстати, почему бы три канала ПДП не задействовать под матричное вычисление без участия процессора?
Один канал считывает из памяти операнд «A», второй - считывает «B», а третий канал записывает в память результат АЛУ-операции.
За АЛУ можно использовать две ИП3 + две ИР23.

Кстати, по поводу спрайтов…
Почему бы спрайты не выводить прямо в буфер памяти?
Тогда и мерцание не возникнет.

[Advertiser]

[zx-kit]

При использовании Z80 такой имитатор компьютера можно на восьми микросхемах сделать: Z80, RAM, ROM, генератор, дешифратор памяти, дешифратор портов, порт клавиатуры, регистр на LCD и BEEPER.

Только это будет далеко не идеальный.

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

[bigral]

так не делали потому что:
1 процедура вывода спрайта в буфер памяти сложная, схема получится жирной
2 будет жраться время видеошины не только на считывание спрайта но и на запись что 2 раза больше
3 при выводе будет clashing... т.е. нельзя просто вывести квадратик затерши им все что попало под него, наложение нужно делать по маске и для этого надо опять сначала считать те данные которые уже туда выведены, еще моск вынесет реализация высвечивания спрайта ПОД background-ом
4 вывести то можно а шо потом? как убрать? еще и стирать надо уметь...
5 как сделать collision detection между пикселами спрайтов и спрайтов и между background-ом?

[Радио-86РК]

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

Кстати, по поводу спрайтов…
Почему бы спрайты не выводить прямо в буфер памяти?
Тогда и мерцание не возникнет.

Утoчню - я не зря заикнулся про ПДП с АЛУ.
По идее, слой с фоном и слой со спрайтами можно хранить в операционном ОЗУ (не видео-ОЗУ).

То есть, берём классический ZX и добавляем туда ВТ57, ИП3, три ИР23 и чуток логики.
Тогда, если фон хранится в регионе C000…D7FF, а «юниты» - в D800…EFFF, то программируем у ПДП три канала:

1. C000 на 17FF циклов чтения
2. D8000 на 17FF циклов чтения
3. 4000 на 17FF циклов записи

Настраиваем регистр функции АЛУ на XOR-операцию, запускаем ПДП циклы и ждём.

P.S.: Дёшево, сердито, но продуктивно!

[Reistlin]

Товарищи добрый день.
Скептически отношусь к этой теме... " Каким бы мог быть... Если приложить ум...." ?! Ребят, история не терпит сослогательных наклонений! Советские инженеры явно были не глупее нас. И понятно, что еслиб тогда как сейчас, то ого-го! Но нет, всему своё время. А вообще ZX Evoplution, по лично моему мнению, идеальный аппарат! Но еще раз говорю, всему своё время. Соответственно АТМ Турбо в своё время был, а чего ещё?