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

[Conan]

Вот я тоже сейчас сижу весенними вечерами и сочиняю очередной клон и понимаю, что нет смысла ради двух игр сохранять фирменные баги. Даже в потактовости смысла особого нет. Тем более там неудобная "потактовость", но это дело, конечно, Рам скана.

Тут вот какое дело: когда разрабатывается клон, возникает вопрос "зачем?". Это не вопрос в духе: "А зачем это вообще надо?". Смысл ответа, который ожидается: какие задачи клон решает. Понятно, что разработка ретро-компьютера на ретро-элементной базе делается скорее как хобби. И это отличное хобби, ибо в процессе творения человек приобретает навыки и учится. А это всегда плюс.
Но вопрос остается: для конкретных целей нужны конкретные функции.

Например: клон должен эмулировать времянки всех фирменных моделей переключаясь между конфигурациями (через порт, прошивку, и т.д.). Задача - получить универсальный набор конфигураций под софт для [список] моделей. Эту задачу решают авторы программных эмуляторов. Но в железе это усложнение. И чем больше "фич" (или багов) фирменных и прочих моделей требуется воспроизвести, тем сложнее будет железо. На рассыпухе или ранних ПЛМ это усложнит схему весьма значительно. Нужно ли это кому-то кроме разработчика? Вряд ли.

Более того, это не слишком нужно было и двадцать лет назад. Когда я занимался разработкой ZX-Next одна из особенностей использования второго Z80 как раз позволяла гибко формировать времянки (кадровые). Хотите "Пентагон" - переключаемся на 320 строчек, фирменную модель 312 и так далее. Или регулировка положения картинки на экране (положением строчных и кадровых импульсов). Потому что экранные режимы формировались программно. Но у каждой реализации была оборотная сторона. Базовый режим (чересстрочная развертка) улучшал качество изображения, но... как оказалось позже в случае мультиколора - ухудшал. И так далее. Или режим 640*200 для набора текстов. После чего приходили письма от пользователей, которые сильно грустили от того, что только два цвета на экран. Хотя все понимали, что большой экран будет тяжело обрабатывать ресурсами Z80 даже в турбо.

[Shofer]

с чего вдруг? может с верхним, или вообще в пзу крутиться

Это да, может. Но в любом случае регенерация осуществляется, как я описал выше. Даже, когда ВК не обращается.

[Lethargeek]

Это да, может. Но в любом случае регенерация осуществляется, как я описал выше. Даже, когда ВК не обращается.

Не осуществляется: нету чтений = нету регенерации. Другое дело, что на практике даже при полном отсутствии регенерации память "утекает" намного медленней, чем указано в даташите (что легко продемонстрировать простым опытом с перезаписью значения в регистр R).

[ivagor]

Не осуществляется: нету чтений = нету регенерации.

Если речь про 4000-7FFF, то в первых машинах (где RFSH соединен через резистор с /RAS ULA) регенерация на бордюре все же была, но с нюансами. У Криса Смита написано, что при адресации в область пзу и наличии MREQ на бордюре будет разрешено прохождение RFSH в качестве RAS на 4116. Но при старте пзу инициализирует I=3F, а значит при RFSH как раз получаем желаемую регенерацию (Крис Смит про это не написал). В машинах 16К она будет железобетонной, т.к. I нельзя никуда переставить (I=40-7F - снег). А в 48К она будет до тех пор, пока программа не изменит I в район 80-FF.

[Lethargeek]

это всё же на "работу с нижним полем проца" не тянет

[Conan]

в первых машинах (где RFSH соединен через резистор с /RAS ULA) регенерация на бордюре все же была, но с нюансами... ...А в 48К она будет до тех пор, пока программа не изменит I в район 80-FF.

В любой ULA (с резистором для RFSH или без) работает логика: /RAS = RAM16 || VidRAS

RAM16 = /MREQ && /A15 && A14. В цикле RFSH всегда активируется /MREQ и этого достаточно в случае 3F < I < 80 для формирования RAM16 и /RAS для регенерации (и "снега").

В сдучае I >= 80 VidRAS продолжает формироваться. Он асинхронен по отношению к RFSH, но цикличен и не блокируется ничем. В случае "промаха" вместо R в адрес строки 4116 попадает младшая часть PC или адреса порта.

[Advertiser]

[ivagor]

В сдучае I >= 80 VidRAS продолжает формироваться. Он асинхронен по отношению к RFSH, но цикличен и не блокируется ничем. В случае "промаха" вместо R в адрес строки 4116 попадает младшая часть PC или адреса порта.

А что происходит в таком случае: бордюр, процессор не тормозится, активизировался /VidRAS, и в следующем такте начался цикл чтения или записи проца в область 4000-7FFF с /MREQ. К спаду /VidRAS на шине адреса еще не было правильного адреса от проца, а к моменту спада /MREQ продолжается активный /VidRAS (он же долгий) и в 4116 уже должен был зафиксироваться адрес, который был к моменту начала /VidRAS. Как в этом случае обеспечивается доступ проца к 4116 по правильному адресу?

[Conan]

продолжается активный /VidRAS (он же долгий)

Уточните сколько тактов CPU занимает VidRAS (без инверсии, ибо 2ИЛИ-НЕ). Если сомневаетесь у Криса осциллограмма приложена. После этого сравните его с продолжительностью, только не "записи/чтения ОЗУ", а выборки кода инструкции (ибо он короче). И не забывайте о том, что хотя циклы CPU и VidRAS асинхронны, но у CPU CLCK и VidRAS фазы фронтов/спадов - одинаковы.

[ivagor]

Осциллограммы я смотрел до того как написать. Нарисовал вышеописанный случай

[Shofer]

Не осуществляется: нету чтений = нету регенерации. Другое дело, что на практике даже при полном отсутствии регенерации память "утекает" намного медленней, чем указано в даташите (что легко продемонстрировать простым опытом с перезаписью значения в регистр R).

Как не осуществляется, если там MREQ используется в качестве RAS, а CAS появляется лишь при выбраном адресе, находящимся в этом поле, в выборке также участвует RD, а это значит, что когда нет RD, нет WR, но есть MREQ, то это цикл регенерации.