Глючит память

[tnt23]

Что такое "авторегенерация по RAS" я не знаю, зато помню, что в РУ7, в отличие от РУ5 есть регенерация CAS-Before-RAS. Если ты готов организовать эту штуку в океане, то это круто, но имхо это потребует неслабых изменений и доработок.

Авторегенерация по RAS похожа на CBR, смысл ее в автоинкременте внутреннего счетчика регенерации по одиночному активному RAS при неактивных CAS и WE.

(даже если CBR там и есть, все равно он не будет работать с РУ5, да и не готов я к столь глубокой океаноевгенике)

[ivagor]

Авторегенерация по RAS похожа на CBR, смысл ее в автоинкременте внутреннего счетчика регенерации по одиночному активному RAS при неактивных CAS и WE

Микропроцессорные средства и системы 1989/4, с.91:
" ОЗУ К565РУ7 работает в следующих режимах: чтения, записи (ранней записи), чтения-модификации-записи, записи полубайта (слоговом), чтения полубайта (слоговом), регенерации сигналом /RAS, регенерации при "/CAS раньше /RAS" ".
И там подробнее дальше описано.
Думаю, что в интернетах зачем-то изобрели новую сущность и переобозвали "авторегенерацией по RAS" обычный "/CAS раньше /RAS", в котором как раз внутренний счетчик меняется по RASу.

[tnt23]

Думаю, что в интернетах зачем-то изобрели новую сущность и переобозвали "авторегенерацией по RAS" обычный "/CAS раньше /RAS", в котором как раз внутренний счетчик меняется по RASу.

Не совсем так. Если посмотреть на "Справочный листок" (http://www.155la3.ru/datafiles/k565ru7.pdf), непонятно откуда взявшийся, то видим там табличку:

[ivagor]

видим там табличку

Практически такая табличка есть и в упомянутом номере МПСиС, но она противоречит описанию и картинке cas-перед-ras, которые есть в этой же статье, поэтому я склонен считать не вполне корректной именно таблицу.

[tnt23]

Микропроцессорные средства и системы 1989/4, с.91

Можешь прицепить сюда? тот djvu МПСиС 4/89, что я нашел, обрывается на странице 85.

[ivagor]

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

[tnt23]

Там странно написано:

Наиболее целесообразно выполнять регенерацию сигналом RAS при высоком уровне сигнала CAS, когда CAS приходит раньше RAS.
При этом за время, равное периоду регенерации, тактируются сигналы RAS и перебираются все строчные адреса (рис. 7).

И то, что я принимал за регенерацию одним-единственным RAS, оказалось обычной регенерацией, когда на ША нужно вручную перебирать адреса.

И да, заявлена CBR, хотя все равно толку от нее в "Океане" нет.

Регенерация в режиме "CAS раньше RAS" выполняется при низком уровне сигнала CAS (рис. 8). В этом режиме работает внутренний счетчик, отсчитывающий регенерируемые строки и срабатывающий от сигнала RAS. Содержимое счетчика увеличивается на единицу в каждом такте регенерации.

[ivagor]

Прикинул - биперной процедуры для ожидания скисания памяти будет маловато.
А процедура ожидания нажатия клавиши долбит (стеком) 2 ячейки. Это можно попытаться использовать, если подменить адрес стека. Но продумывание экспериментов с этой штукой нагнало на меня такую тоску, что я решил лучше написать свое видение доработки регенерации.
Сугубый as is, никаких гарантий. Можно считать это вариантом, предложением для обсуждения.
Это вариант с адресацией только до 128 Кб озу, для больше надо еще доделывать (а надо ли?).
1. Режем связь DD32\7 с A8 DRAM. ОЗУ больше 128 Кб теперь недоступно.
2. Режем связь DD31\9 с A7 DRAM и перекидывем сигнал с DD31\9 на A8 DRAM. Регулярно этот сигнал не меняется, но для регенерации A8 и не нужен.
3. Теперь нужно организовать дополнительный бит регенерации. На DD32\11 нужно подать SK3 (параллельно с DD28\3, где он уже был). На DD32\10 нужно подать A2 с проца (параллельно с DD28\4, где он уже был). И выход DD32\9 нужно соединить с A7 DRAM, от которого отрезали выход DD31\9 в п.2

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

Часть озу можно малой кровью вернуть - для 256 Кб можно подать A17 проца на DD32\12. А для 512 Кб надо переделывать то, что уже есть, думать про это большого желания нет.

[tnt23]

Прикинул - биперной процедуры для ожидания скисания памяти будет маловато.
А процедура ожидания нажатия клавиши долбит (стеком) 2 ячейки. Это можно попытаться использовать, если подменить адрес стека.

Дак сейчас память скисает как раз от простого ожидания ввода Монитора. Думаю, не киснет 256-байтный блок, куда относятся бомбардируемые ячейки стека.

Это вариант с адресацией только до 128 Кб озу, для больше надо еще доделывать (а надо ли?).

128Kбайт и так штатный объем. Ты имел в виду 128К 16-разрядных слов? Большее имеет смысл, потому что можем получить квазидиск на четыреста с лишним килобайт, что для компиляции на таргете совсем даже нелишне.

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

Резать много не хотелось бы. Вот если б что-нибудь подать на подтянутые к лог.1 входы D31.

[ivagor]

Дак сейчас память скисает как раз от простого ожидания ввода Монитора. Думаю, не киснет 256-байтный блок, куда относятся бомбардируемые ячейки стека.

По моей прикидке получается, что долбятся те ячейки, которые не прибавляют ни строки к той регенерации, которую обеспечивает вывод видео.

Ты имел в виду 128К 16-разрядных слов?

В "первой части" речь про 128 Кбайт. А потом понял, что одним проводком легко до 256 Кбайт.

Резать много не хотелось бы. Вот если б что-нибудь подать на подтянутые к лог.1 входы D31.

Если тебе все равно, что будет показывать на экране, то можно подать туда SK3 Но, конечно, так делать не нужно.