PDA

Просмотр полной версии : Глючит память



tnt23
23.02.2019, 23:19
Работая над "Тетрисом" (хаха, какая же это работа), обратил внимание на странную штуку.

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

Вроде бы достаточно симптоматично?

Такое впечатление, что "скисает" память, к которой отсутствует обращение. Заполнил кусок 1000h-1FFFh всеми единичками, дал настояться, через пару минут смотрю дамп:


1000: FF FF FF FF xx xx xx xx FF FF FF FF xx xx xx xx
...
11F0: FF FF FF FF xx xx xx xx FF FF FF FF xx xx xx xx

1200: xx xx xx xx FF FF FF FF xx xx xx xx FF FF FF FF
...
13F0: xx xx xx xx FF FF FF FF xx xx xx xx FF FF FF FF

, где xx - скисшая ячейка (от одного до трех сбросившихся в 0 разрядов)
(Тут еще полезно вспомнить, что памяти 2 линейки)

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

Память MN41256-08 в обеих линейках.

UPDATE 10.03.2019
Для правильной регенерации всех 8 разрядов адреса нужно перекинуть между собой две пары сигналов на мультиплексорах DD28 и DD31:


DD28-4 (A2) поменять с DD31-10 (~A15)
DD28-3 (SK3) поменять с DD31-11 (+B)


Автор идеи Иван Городецкий (ivagor)

ivagor
24.02.2019, 12:46
Попробовал разобраться, как регенерируется память океана. И как-то странно. То, что A8 DRAMа (DD32\7) точно не меняется регулярно (не участвует в формировании адреса регенерации) - ну и ладно, для регенерации 41256 достаточно 256 адресов перебирать. Но я не вижу, откуда появятся регулярные изменения A7 DRAMа (DD31\9). Создается впечатление, что перебираются 128 комбинаций A0-A6, что достаточно для регенерации только РУ5. В журнале написано, что "предусмотрено использование БИС динамического ОЗУ емкостью 256 Кбит", но за счет чего - я не понял. Надеюсь, это просто моя низкая железная грамотность.

Насчет того, какие адреса пострадали, судя по "паттерну скисания". Если относительно процессора, то это комбинации A9=0 A2=1 и A9=1 A2=0, которые приходят на A0 DRAMа.

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

Соответствующие адреса от видеоконтроллера SC1 и SK3, но если бы они регулярно не менялись, то по изображению это можно было бы заметить.

tnt23
24.02.2019, 13:26
Регенерация может быть не только перебором 256 адресов, но еще скрытая (CAS удерживается в последнем цикле обращения в низком уровне), и еще бывает CBR, хотя в "Океане" ее вроде нет.

Еще соображение, что РУ7 вроде бы (опять "вроде") имеет не квадратную, а прямоугольную матрицу, в отличие от импортных 41256.

ivagor
24.02.2019, 13:35
Регенерация может быть не только перебором 256 адресов, но еще скрытая (CAS удерживается в последнем цикле обращения в низком уровне), и еще бывает CBR, хотя в "Океане" ее вроде нет.
Скрытая это фактически тоже CAS-Before-RAS, так в некоторых даташитах и пишут. Насчет наличия CBR в океане - это было бы фантастикой.

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

И, насколько помню, у РУ5 cas-before-ras регенерации нет

Totem
24.02.2019, 14:54
у РУ5 cas-before-ras регенерации нет
еще ее нет и в 41256. у NEC если не ошибаюсь.

ivagor
24.02.2019, 15:54
В NEC CAS-before-RAS есть (http://www.citylan.it/wiki/images/8/82/Upd41256.pdf), а вот в MN41256 нет (https://www.datasheetarchive.com/pdf/download.php?id=812eb7386b31741d7c8cd10a1875449c92 4503&type=M&term=MN41256).
Сравнивая эти два pdf можно заметить, что у NEC скрытая регенерация CBR, а в MN - обычная, т.ч. я был неправ, насчет того, что скрытая всегда CBR.

Возвращаясь к океану. tnt23, можешь уточнить, что приходит на 11й вход DD31 (555КП12)? По схеме вроде с пользовательской ВВ55 (что странно)?

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


что приходит на 11й вход DD31 (555КП12)?
Увидел, это собственно переключение экранов. Получается A7 DRAMа в океане точно не вовлекается в регенерацию, пробегаются только A0-A6.

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

Думаю, что если переключить экран, записать в память FF и подождать, то паттерн скисания изменится.

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


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

tnt23
24.02.2019, 23:50
Думаю, что если переключить экран, записать в память FF и подождать, то паттерн скисания изменится.

Попробую.

В продолжении журнальной статьи описывались некоторые доработки, вроде бы они уже внесены в реплику. Надо посмотреть, может, недостающий сигнал A7 тоже можно пробросить.

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

68215

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


что приходит на 11й вход DD31

На 11 DD31 ничего не приходит, она подтянута к + питания резистором.

ivagor
25.02.2019, 07:25
В продолжении журнальной статьи описывались некоторые доработки, вроде бы они уже внесены в реплику.
В том, что касается формирования адресов DRAM увидел отличие только в упоминавшемся DD31\11 - в журнале (смотрю по сайту AZmastera) сюда приходит сигнал переключения экранов, а у тебя этот сигнал приходит на 13й вход. Но тогда у тебя второй экран вроде как перемещается из 4000h основного банка в C000h дополнительного.


может, недостающий сигнал A7 тоже можно пробросить.
Сигнал есть, но он не участвует в регенерации.

tnt23
25.02.2019, 10:34
В том, что касается формирования адресов DRAM увидел отличие только в упоминавшемся DD31\11 - в журнале (смотрю по сайту AZmastera) сюда приходит сигнал переключения экранов, а у тебя этот сигнал приходит на 13й вход. Но тогда у тебя второй экран вроде как перемещается из 4000h основного банка в C000h дополнительного.

http://sensi.org/~tnt23/ok240/vsu.png

Второй экран и должен размещаться в дополнительной памяти, если верить статье:

http://sensi.org/~tnt23/ok240/videoRAM.png

ivagor
25.02.2019, 10:42
Тогда вопрос с видео стал ясен, пометки в скане схемы из журнала на сайте AZmastera неправильные. b2m скорее всего по тем же сканам схемы делал, в emu тоже надо исправить.

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

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

tnt23
25.02.2019, 10:57
Учитывая, насколько неудобный доступ к дополнительной банке, размещение там допстраницы видео выглядит завуалированным издевательством.

Доступ процессора к видеопамяти и так довольно неудобный: либо отключай ПЗУ и работай из первых 32К, либо мапь вторые 32К на первые. И то, и другое записью в порт управления банками ОЗУ. Так что смена экрана на этом фоне не создает каких-то неудобств.

(Вот разве что код Монитора, работающий с экраном, не сохраняет биты доступа к дополнительному ОЗУ и бит расположения экрана, что некрасиво)

Вопрос по регенерации микросхем памяти 256Кx1 остается открытым. Мультиплексор для MA7 есть (DD31 выход 9), его входы для регенерации заведены на лог.1, то есть в теории достаточно завести туда какой-нибудь подходящий клок?

ivagor
25.02.2019, 11:16
Доступ процессора к видеопамяти и так довольно неудобный: либо отключай ПЗУ и работай из первых 32К, либо мапь вторые 32К на первые.
Извини, моя занудность прорывается наружу. Все же если отключить ПЗУ, то работать с видеоОЗУ можно из первых 48 Кб.
А работать с допстраницей видеоОЗУ можно или через подпрограммы обмена с рамдиском (я этот геморрой как раз подразумевал) или как то исхитриться и запустить исполнение кода из рамдиска. Эту тему я не исследовал, есть ли такая возможность или нет.

Что касается моего предложения переключить видеостраницу и посмотреть, не изменится ли паттерн протухания ОЗУ, то при подключении сигнала VSU к 13, а не к 11 входу DD31 смысла в это скорее всего (с очень большой вероятностью) нет.
У меня вчера были идеи, как добавить разряд регенерации, но я их лучше подержу при себе, сначала надо проверить, что изменение разряда A7 DRAM повлияет на паттерн скисания.
Тут возможны варианты, например сделать как в журнале, т.е. временно подать VSU на 11й вход, а 13й - на землю. Хотя VSU на 13 можно оставить, если до переделки проверить и убедиться, что переключение видеостраницы не влияет на регенерацию.

tnt23
25.02.2019, 12:01
Все же если отключить ПЗУ, то работать с видеоОЗУ можно из первых 48 Кб.

Верно, я просто думал о другом :) редактор ZNG так и поступает, ну и Тетрис слямзил этот подход с ZNG.

Как работать с экранной областью в дополнительной памяти, я тоже не исследовал еще. Было бы логичным (с точки зрения удобства) оставлять первые 48К основной памяти как есть, с работающим в них кодом, и по сигналу VSU только подменять старшие 16К с экраном на дополнительные. Но как оно в реальности, не знаю пока.


сначала надо проверить, что изменение разряда A7 DRAM повлияет на паттерн скисания

Я попробую это проделать в ближайшее время, только не знаю, как увидеть результаты, если Монитор не умеет работать с экраном в дополнительной памяти.

ivagor
25.02.2019, 12:08
Было бы логичным (с точки зрения удобства) оставлять первые 48К основной памяти как есть, с работающим в них кодом, и по сигналу VSU только подменять старшие 16К с экраном на дополнительные.
Да, это было бы удобно, но если по схеме, которую ты привел, то там увы не так.


Я попробую это проделать в ближайшее время, только не знаю, как увидеть результаты, если Монитор не умеет работать с экраном в дополнительной памяти.
У меня появилась идея, что можно попробовать для проверки обойтись без резни и пайки. Но возникли вопросы, ответы на которые сообразить не могу.


дал настояться
Можешь подробнее написать, как конкретно ждал, что процессор выполнял в это время?

tnt23
25.02.2019, 12:16
Можешь подробнее написать, как конкретно ждал, что процессор выполнял в это время?

Заполнял в Мониторе память от 0 до 7FFFh единичками:


.F 0 7fff ff
.

И больше ничего не делал на протяжении нескольких минут. Монитор крутится в процедуре опроса клавиатуры и теребит кусок памяти со стеком (подозреваю, где-то в районе адресов Bxxxh).

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


Но возникли вопросы, ответы на которые сообразить не могу.

В эфире рубрика "Спрашивайте - отвечаем".

ivagor
25.02.2019, 12:23
В эфире рубрика "Спрашивайте - отвечаем".
Про ожидание был вопрос как раз в эту рубрику. А какой монитор, этот (http://azmaster.narod.ru/Ocean-240/Soft/TM.ZIP)?

tnt23
25.02.2019, 12:38
Не совсем в тему, но занятное совпадение (про "Специалист" отсюда: http://www.asvcorp.ru/darch/asv/specialist/index.html):

У микросхем РУ7 была очень интересная особенность - длинный цикл регенерации. Доходило до того, что после выключения компьютера и последующего его включения - данные не успевали исчезнуть. Это натолкнуло на мысль о том, что можно сделать небольшой хак с графической подсистемой.
На специалисте выборка данных из видео-ОЗУ одновременно являлась механизмом регенерации памяти. Структура видеопамяти и вертикальное разрешение в 256 точек позволяло получить аппаратный вертикальный скроллинг экрана, если между формирователем адреса и адресной шиной поставить восьмиразрядный сумматор. Одно значение сумматор брал от формирователя адреса, другой - от регистра вывода, содержащего смещение экрана.
Сначала боялись, что такой хак с регенерацией будет приводить к потере данных, но на практике всё оказалось просто замечательно. Медленный скроллинг экрана был побеждён. В BIOS была введена поддержка этого скроллинга и был добавлен знакогенератор 8*8 символов. Это уменьшило количество символов в строке, но зато значительно ускорило вывод символов. Этот режим вывода символов стал основным.

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


А какой монитор, этот (http://azmaster.narod.ru/Ocean-240/Soft/TM.ZIP)?

Нет, монитор другой, с сигнатурой 240/7. С этим (в который вшита утилита TurboMonitor) у меня не получается работать из-за несовместимости контроллера клавиатуры.

ivagor
25.02.2019, 12:46
монитор другой, с сигнатурой 240/7.
Понял, встроенный в пзу. Я его запускал отключением cpm-ного пзу, а есть штатный способ (сам я не искал)?

tnt23
25.02.2019, 13:04
Понял, встроенный в пзу. Я его запускал отключением cpm-ного пзу, а есть штатный способ (сам я не искал)?

Из CP/M дать команду EXIT.

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

По поводу регенерации: в интернетах пишутъ, что в РУ7 впервые появилась авторегенерация по RAS.

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

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

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

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

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

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

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

68223

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

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

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

ivagor
25.02.2019, 14:49
Есть вот такой вариант (http://www.wdigest.ru/mpss_pdf/1989/mpss-1989-04.pdf), он полный, но части страниц размыты. Если этот не устроит, то я выложу куда-нибудь "свой" вариант.

tnt23
25.02.2019, 16:07
Там странно написано:


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

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

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


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

ivagor
25.02.2019, 20:19
Прикинул - биперной процедуры для ожидания скисания памяти будет маловато.
А процедура ожидания нажатия клавиши долбит (стеком) 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
25.02.2019, 21:19
Прикинул - биперной процедуры для ожидания скисания памяти будет маловато.
А процедура ожидания нажатия клавиши долбит (стеком) 2 ячейки. Это можно попытаться использовать, если подменить адрес стека.

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


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

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

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

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

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


Ты имел в виду 128К 16-разрядных слов?
В "первой части" речь про 128 Кбайт. А потом понял, что одним проводком легко до 256 Кбайт.


Резать много не хотелось бы. Вот если б что-нибудь подать на подтянутые к лог.1 входы D31.
Если тебе все равно, что будет показывать на экране, то можно подать туда SK3 :) Но, конечно, так делать не нужно.

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

Сейчас обнаружил интересную вещь. Скисают ячейки во вторых 4 байтах (адреса xxx4-xxx7, xxxC-xxxF) или первых 4 байтах (адреса xxx0-xxx3, xxx8-xxxB), чередуясь каждые 0200h - и все это только в младших 32К, т.е. до адреса 7FFFh. Начиная с 8000h и выше память не киснет. Может, это как-то связано с Монитором, перекидывающим видео-ОЗУ в младшие 32К для записи.


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

SK3 на мультиплексоры уже приходит. Там не хватает чего-нибудь ниже SK8 - например, отсутствующего в системе SK9. Можно попробовать GK.

ivagor
25.02.2019, 21:42
Альтернативный, более щадящий вариант, при котором еще и остаются 512 Кб озу:
1. Перекидываем SK3 с DD28\3 на DD31\11, A2 проца с DD28\4 на DD31\10
2. И в другую сторону перекидываем (A15) с DD31\10 на DD28\4, и сигнал +B (который, в частности, приходил на DD31\11) на DD28\3.

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


SK3 на мультиплексоры уже приходит.
Нужны 2 вещи:
1. Перебор правильных адресов
2. Допустимый период регенерации
То, что SK3 сейчас приходит туда, куда он приходит по моему пониманию ничего хорошего для регенерации не делает.

tnt23
25.02.2019, 22:59
1. Перекидываем SK3 с DD28\3 на DD31\11, A2 проца с DD28\4 на DD31\10
2. И в другую сторону перекидываем (A15) с DD31\10 на DD28\4, и сигнал +B (который, в частности, приходил на DD31\11) на DD28\3.

Это правильные сигналы? смотрю на табличку с оригинальными, и не вырисовывается:

ivagor
26.02.2019, 08:43
Это правильные сигналы? смотрю на табличку с оригинальными, и не вырисовывается:
Сдаюсь, что именно не вырисовывается?

tnt23
26.02.2019, 10:31
Сдаюсь, что именно не вырисовывается?

Ну если я не наврал в табличке (а я мог запросто, перепутав S1 и S2, например), то переброс SK3 с DD28-3 на DD31-11 затрет A16.

ivagor
26.02.2019, 10:48
Могу в твоей таблице обвести сигналы, которые меняются местами

tnt23
26.02.2019, 10:50
ivagor, вроде так выходит (слева оригинальные сигналы, справа по твоему рецепту)






6
5
4
3





6
5
4
3





10
11
12
13





10
11
12
13


DD28

MA0
A9
SC1
A2
SK3


DD28

MA0
A9
SC1
(A15)
1




MA1
A10
SC2
A3
SK4




MA1
A10
SC2
A3
SK4


DD29

MA2
A11
SC3
A4
SK5


DD29

MA2
A11
SC3
A4
SK5




MA3
A12
SC4
A5
SK6




MA3
A12
SC4
A5
SK6


DD30

MA4
A13
SC5
A6
SK7


DD30

MA4
A13
SC5
A6
SK7




MA5
A0
SK1
A7
SK8




MA5
A0
SK1
A7
SK8


DD31

MA6
A1
SK2
A14
1


DD31

MA6
A1
SK2
A14
1




MA7
(A15)
1
A16
vsu




MA7
A2
SK3
A16
vsu


DD32

MA8
A17
0
A18
0


DD32

MA8
A17
0
A18
0

ivagor
26.02.2019, 11:22
справа по твоему рецепту
да

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

Кстати, по твоей таблице/картинке наглядно видно, куда я клоню. Насколько я понял, в оригинале регенерация сигналами
SK2 SK1 SC5 SC4 SC3 SC2 SC1 - 7 разрядов, за 4 строки пробегает 128 адресов
А я предлагаю добавить сюда 8й сигнал SK3 и за 8 строк будет пробегать 256 адресов

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

заметил ошибку в таблице (в части, которую я не предлагаю трогать)

DD31 MA6 A10 SK2 A14 1 DD31 MA6 A10 SK2 A14 1
должно быть
DD31 MA6 A1 SK2 A14 1 DD31 MA6 A1 SK2 A14 1

tnt23
26.02.2019, 11:53
Кстати, по твоей таблице/картинке наглядно видно, куда я клоню. Насколько я понял, в оригинале регенерация сигналами
SK2 SK1 SC5 SC4 SC3 SC2 SC1 - 7 разрядов, за 4 строки пробегает 128 адресов

А для чего тогда нужен третий столбец, где на MAx подаются остальные сигналы с делителей счетчиков - {SK3, SK4, SK5, SK6, SK7, SK8, 1, vsu} ?


должно быть
DD31 MA6 A1 SK2 A14 1 DD31 MA6 A1 SK2 A14 1

Поправил, спасибо.

ivagor
26.02.2019, 12:06
А для чего тогда нужен третий столбец, где на MAx подаются остальные сигналы с делителей счетчиков - {SK3, SK4, SK5, SK6, SK7, SK8, 1, vsu} ?
На данный момент считаю, что это часть адреса, которая защелкивается DRAMом по /CAS. 6 и 5 - по /RAS, 4 и 3 - по /CAS.

tnt23
26.02.2019, 16:12
Могу в твоей таблице обвести сигналы, которые меняются местами

Отлично, попробую порезать.

ivagor
26.02.2019, 16:19
Для полного счастья перед резанием стоит посмотреть логическим анализатором (наверняка ведь у тебя есть) S1 S2 /RAS и /CAS

tnt23
26.02.2019, 16:22
Для полного счастья перед резанием стоит посмотреть логическим анализатором (наверняка ведь у тебя есть) S1 S2 /RAS и /CAS

Есть, как не быть.

https://zx-pk.ru/attachment.php?attachmentid=65551&d=1529313578

tnt23
26.02.2019, 20:19
Сигналы снизу вверх: S1 (красный, помечен как D0), S2, RAS, CAS1, CAS2.

6824768248

ivagor
26.02.2019, 20:33
Просто красота! Видно, что S2=0 действительно соответствует части адреса для /RAS, а S2=1 - для /CAS.
И на картинки попали и момент, когда доступ проца задерживает доступ видеоконтроллера, и когда доступ проца и видеоконтроллера не помешали друг-другу, к регенерации это отношения не имеет, но прикольно.

tnt23
27.02.2019, 09:07
Пока резать не стал, размышляю. Поменять местами SK3 и лог.1 - это понятно, нужно для такта регенерации RAS. А вот зачем менять A2 и (A15)?

ivagor
27.02.2019, 09:19
зачем менять A2 и (A15)?
Чтобы сохранить организацию видеопамяти.

ivagor
27.02.2019, 11:36
Можно подумать об оптимизации переделки, чтобы было удобнее. Вместо SK3 (и его пары от проца) без превышения периода регенерации 4 мс можно взять SK5 или SK6 (тоже с их парами от проца).

tnt23
27.02.2019, 11:45
Чтобы сохранить организацию видеопамяти.

Ок.

Остановил процессор по команде HLT, но пока не вижу "чистого" такта регенерации, т.е. отдельно стоящего RAS без обоих CAS:

68250

ivagor
27.02.2019, 11:50
не вижу "чистого" такта регенерации, т.е. отдельно стоящего RAS без обоих CAS
Насколько помню, в журнале написано, что регенерация осуществляется видеоконтроллером при выборке видеоданных, и /RAS без /CAS ты вряд ли увидишь. Если бы регенерация была отдельно, то не нужно было бы заморачиваться с парными линиями проца.
А я еще пропустил в списке замены (случайно, не специально) SK4.

ivagor
04.03.2019, 19:33
tnt23, если ты еще не закруглил регенерацию, то можешь побаловаться предлагаемой "программной регенерилкой". Перед запуском в мониторе нужно заполнить память 4000-7FFF (или больше, но смысла нет) FFами. Запускаем "регенерилку", ждем несколько минут, жмем любую клавишу, например Enter и проверяем ранее заполненную память. Нечетные колонки 4100-41FF, 4300-43FF, ... 7F00-7FFF должны выжить, а четные - скиснуть.
Исходник прилагается. Это в некотором смысле программная имитация переделки, которую я предлагал.

tnt23
04.03.2019, 21:36
ivagor, регенерацию еще не закруглил, был в отъезде. Регенерилку успел попробовать один раз, минут пять, странным образом вся память 4000-7FFF не прокисла вообще. Сейчас сделаю еще пару прогонов.

tnt23
05.03.2019, 10:22
Сделал несколько заходов, один на полчаса - не киснет память вообще.

ivagor
05.03.2019, 10:26
Уточняющие вопросы
1. Запускал регенерилку по G100?
2. Выходит из регенерилки в монитор по нажатию клавиши?

tnt23
05.03.2019, 12:00
Уточняющие вопросы
1. Запускал регенерилку по G100?
2. Выходит из регенерилки в монитор по нажатию клавиши?

1. Да, запускал по G100.
2. Выходил по нажатию клавиши, быстро проверял память (чтобы не скисла сама регенерилка), и снова запускал по G100.

Есть предположение, что регенерируется блок больше чем 512 байт.

ivagor
05.03.2019, 14:09
У меня, скажем так, фундаментальное недоумение. Оно связано с неожиданной регенерацией двух линеек ОЗУ вместо одной. Пока крутится цикл четные колонки, т.е. одна из линеек озу в области A15=0 совсем не трогается.

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

Сообразил - casы раздельные, а ras то общий, т.е. даже при чтении (или записи) одной линейки озу регенерируются обе. Т.е. результат теста вполне нормальный.

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


/RAS без /CAS ты вряд ли увидишь
Если убрать из контекста того вопроса, то ras без cas видим здесь (https://zx-pk.ru/threads/30156-glyuchit-pamyat.html?p=1001186&viewfull=1#post1001186)

tnt23
05.03.2019, 15:50
Если убрать из контекста того вопроса, то ras без cas видим здесь

Видимо, там, где чтение процессором, т.е. активны RAS и CAS2? для первой линейки (с неактивным CAS1) это вряд ли будет полноценной регенерацией, т.к. на ША присутствует адрес обращения процессора.

ivagor
05.03.2019, 16:20
? Это нормальная регенерация того row, который там на ША.
Вот если бы адреса не было, тогда регенерация только при CBR, но в океанских временных диаграммах такого не видно.

tnt23
05.03.2019, 16:58
? Это нормальная регенерация того row, который там на ША.
Вот если бы адреса не было, тогда регенерация только при CBR, но в океанских временных диаграммах такого не видно.

Можешь обвести на картинке точное место, где активен RAS и неактивен CAS? такое там вроде есть, но это определенно не чтение видеопроцессором (тот активирует оба CAS). Я полагал это обращением процессора к памяти, т.к. один из CAS активен в этот момент.

ivagor
05.03.2019, 17:08
Обвел желтым. Несомненно это обращения именно процессора к памяти.

tnt23
05.03.2019, 22:45
Что-то такое вспоминается про РК86, там для работы с лентой отключалась пара ВГ75+ВТ57, как следствие софту приходилось софтверно же рефрешить память. И если не ошибаюсь, именно обращениям к ячейкам в 256-байтовом блоке, что рефрешило всю память.

tnt23
10.03.2019, 13:15
ivagor, перебросил пары A2 <--> (A15) и SK3 <--> B+, результат не очень:

68397

ivagor
10.03.2019, 13:33
Бип при старте компа есть? Картинка не меняется при нажатиях клавиш? Если много раз нажать, чтобы скролл начался, все равно не меняется?
Если комп все же работает (по крайней мере бип есть), то можно попробовать вслепую выйти в монитор и заполнить память 100-B3FF чем-нибудь характерным, например 55h/AAh или на твой выбор. Изменится ли при этом картинка?

tnt23
10.03.2019, 13:50
Бип есть, но на клавиатуру реакции никакой. Слепая попытка выйти в монитор и сделать теплый сброс тоже не выходит (EXIT, GE000).

ivagor
10.03.2019, 14:20
Можно еще попробовать Esc61 (режим 512) или Esc60 (режим 256)
На всякий случай - ты перепроверял, что (A15) сейчас приходит на DD28\4, +B на DD28\3, A2 на DD31\10 и SK3 на DD31\11?

tnt23
10.03.2019, 18:26
На всякий случай - ты перепроверял, что (A15) сейчас приходит на DD28\4, +B на DD28\3, A2 на DD31\10 и SK3 на DD31\11?

Бинго! Вместо A2 припаялся к D2. Перепроверил, сейчас комп стартует нормально. Заполнил память 0-B7FF единицами и оставил настаиваться.

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

Двадцать минут, полет нормальный :)

ivagor
10.03.2019, 18:31
Двадцать минут, полет нормальный
Поздравляю! Теперь можно дальше двигаться.