так проверяли же по соседству в теме specemu - быстрая память утекает, но ооооочень медленноСообщение от reddie
и согласно сервисмануалу, медленную проц не рефрешит - и юла на бордюре не рефрешит, иначе тормозила бы проц
так проверяли же по соседству в теме specemu - быстрая память утекает, но ооооочень медленно
и согласно сервисмануалу, медленную проц не рефрешит - и юла на бордюре не рефрешит, иначе тормозила бы проц
Прихожу без разрешения, сею смерть и разрушение...
Ну, это логично (и первое, и второе): к медленной обращается Юла, но только во время экрана, заодно и регенит ее.
Отсюда вытекает следствие: торможение проца в "медленной" памяти неравномерное. Да и вообще там Wait, по идее, только в медленной должен случаться.
А вот что мне совсем непонятно - жуткое падение производительности, когда регистр I помещен в медленную. Прерывание раз в кадр, с чего тормоза-то?
Если речь про невидео dram, то проверить сравнительно легко, а вот четко проверить отсутствие рефреша видеоdram процом в неактивной области фиксируя R вряд ли получится, тут нужен логический анализатор. Проблема (для проверки, а для работы это как раз здорово), что официальный период регенерации устанавливается по неудачным ячейкам, сейчас, к сожалению, забыл точную цитату из книжки, как они называются. Подавляющее большинство ячеек dram могут обходиться без регенерации сравнительно долго, но встречаются неудачные, которые утекают в разы и даже на порядки быстрее, и официально период регенерации ориентирован именно на них с некоторым запасом. Это приведет к тому, что даже если видеоdram не регенерируется на бордюре, то регенерации в активной области хватит, чтобы исключить гарантированное утекание, если в конкретном экземпляре dram не попались очень неудачные ячейки.
Там есть пара упоминаний:
1) The CPU incorporates built-in dynamic RAM refresh circuitry. As part of the instruction OP code fetch cycle,
the CPU performs a memory request after first placing the refresh address on the lower eight bits of the
address bus. At the end of the cycle the address is incremented so that over 255 fetch cycles, each row of
the dynamic RAM is refreshed. This mechanism only applies to the optional 32k expansion RAM in the 48k
Spectrum. An alternative refresh method is adapted for the standard 16k RAM.
Эта цитата со странностями, почему 255, когда на самом деле 128 (и нужно для этих dram и период R). Вероятно это все же писал не разработчик, а отдельный человек, нанятый писать service manual.
2) Refresh for the standard 16k dynamic RAM is accomplished during normal read cycles, ie most rows are
refreshed each time the ULA accesses the memory mapped displayed area during picture compilation;
the remaining rows are refreshed as a result of other read cycles also known to occur at regular intervals
within the refresh period.
Тут основной вопрос - как конкретно формируется ras при обращениях проца к озу. Если формировать этот ras только на основании mreq (а A14/A15 учитывать при формировании cas), то это позволяет регенерировать на бордюре процом. Ну и после некоторого размышления я склонился к тому, что в issue1 и 2 прилепленный rfsh даст возможность регенерировать видеоdram при неактивности ras от ula, т.е. под вопросом рефреш в issue3-6.
слышал или сам наблюдал? например, тут пишут, только снег от этого бывает, без тормозов:
- - - Добавлено - - -Finally, there is an interesting bug in the ULA which also has to do with this split bus. After each instruction fetch cycle of the processor, the processor puts the I-R register "pair" (not the 8 bit internal Instruction Register, but the Interrupt and R registers) on the address bus. The lowest 7 bits, the R register, are used for memory refresh. However, the ULA gets confused if I is in the range 64-127, because it thinks the processor wants to read from lower 16K RAM very, very often. The ULA can't cope with this read-frequency, and regularly misses a screen byte. Instead of the actual byte, the byte previously read is used to build up the video signal. The screen seems to be filled with 'snow'; however, the Spectrum won't crash, and program will continue to run normally. One program which uses this to generate a nice effect is Vectron.
ну, то есть фактически выполнять чтение из двух линеек одновременно, а потом отбрасывать один результат?
крайне маловероятное усложнение, особенно с учётом скупердяйства дядюшки Клайва
Прихожу без разрешения, сею смерть и разрушение...
Более употребимо слово "читал", но в данном контексте - да, лично сам не наблюдал. Так что исправляю недосказанность: "по версии некоторых источников, ..."
Да даже если речь про "снег" - откуда он берется? Что это, глюки проца или остального железа? В клонах в общим полем такого нет, вывод: проц ни при чем.
Читать или писать память не обязательно, в цикле регенерации mreq активируется (формируем ras и стробируем R на шине адреса), rd и wr не активируются (не формируем cas), не вижу препятствий (в неактивной области изображения) для одновременной регенерации обоих линеек.
дык по ссылке так и сказано, что глюк юлы
кстати, на амстрадовских моделях его исправили
ну всё равно как минимум нужно муксить mreq на выводе растра, мб и еще что-нибудь, за что жаба задушила бы крохобора
Прихожу без разрешения, сею смерть и разрушение...
> кстати, на амстрадовских моделях его исправили
Только на чёрных. На серых снег в каждой второй русской программе.
Почитал про снег и похоже, что ras для видеоdram при обращениях проца формируется юлой не только по mreq, но и с учетом A14-A15, что печально. Вдвойне печальна причина снега, недоделан арбитраж между ula и процом. С учетом всего этого в issue3-6 почти наверняка на бордюре нет регенерации процом в цикле рефреша, только если он обратится на чтение или запись. Т.е. сделать рефреш на бордюре было можно, но скорее всего не сделали, или времени не хватило или ресурсов ula.
Насколько хорошо работал rfsh в issue1-2 тоже не совсем очевидно. Идея вроде понятна, если ras от ula неактивен, то стробируем адрес регенерации R по rfsh. Но тут тоже возникают вопросы. Рефреш входит в цикл выборки команды, т.е. перед этим было чтение, значит был активен ras. RAS формируется с задержкой из mreq, и надо смотреть анализатором наличие фронта ras (или там нечто иголкоподобное). Плюс к моменту начала активности сигнала rfsh на шине адреса еще не обязан быть полностью правильный R, он стабилизируется к моменту активизации mreq при активном rfsh.
Если поменять биты как вы советуете в младшем байте так H3H4H5H6H7V0V1V2 в старшем так V3V4V5V6V7 смотрим какие адреса будут регенерировать видео контроллер.
первыми отработают H3H4H5H6H7 Это 32 байта первой строки
следующим перейдёт из 0 в 1 отработает V0 он задаст адрес первого байта второй теле строки, моделируем это число
A15 A16 V7 V6 V5 V4 V3 V2 V1 V0 H7 H6 H5 H4 H3
0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0
переводим в другие системы и получаем
16416 #4020 b01000000 00100000
о горе! это первый байт девятой теле строки, а должен быть
первый байт второй теле строки
16640 #4100 b01000001 00000000
На экране будут спутаны все строки, но регенерация то работает. Только кому она нужна без нормального расположения строк.
Не думаю, что он согласится.
Последний раз редактировалось апро; 20.02.2022 в 22:30.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием