Просмотр полной версии : Глючит память
Работая над "Тетрисом" (хаха, какая же это работа), обратил внимание на странную штуку.
Если загрузить "Тетрис", запустить его, поиграть продолжительное время, все работает нормально и никаких странностей нет.
Но если из него выйти и через некоторое время попытаться запуститься, то с большой долей вероятности получим зависание или сбой системы.
То же самое наблюлось, если загрузить программу, но не запускать ее сразу, а выждать пару минут.
Вроде бы достаточно симптоматично?
Такое впечатление, что "скисает" память, к которой отсутствует обращение. Заполнил кусок 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)
Попробовал разобраться, как регенерируется память океана. И как-то странно. То, что 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, но если бы они регулярно не менялись, то по изображению это можно было бы заметить.
Регенерация может быть не только перебором 256 адресов, но еще скрытая (CAS удерживается в последнем цикле обращения в низком уровне), и еще бывает CBR, хотя в "Океане" ее вроде нет.
Еще соображение, что РУ7 вроде бы (опять "вроде") имеет не квадратную, а прямоугольную матрицу, в отличие от импортных 41256.
Регенерация может быть не только перебором 256 адресов, но еще скрытая (CAS удерживается в последнем цикле обращения в низком уровне), и еще бывает CBR, хотя в "Океане" ее вроде нет.
Скрытая это фактически тоже CAS-Before-RAS, так в некоторых даташитах и пишут. Насчет наличия CBR в океане - это было бы фантастикой.
- - - Добавлено - - -
И, насколько помню, у РУ5 cas-before-ras регенерации нет
у РУ5 cas-before-ras регенерации нет
еще ее нет и в 41256. у NEC если не ошибаюсь.
В 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 и подождать, то паттерн скисания изменится.
- - - Добавлено - - -
паттерн скисания изменится.
Если он изменится на противоположный, то становится очевидно, как "лечить" проблему.
Думаю, что если переключить экран, записать в память FF и подождать, то паттерн скисания изменится.
Попробую.
В продолжении журнальной статьи описывались некоторые доработки, вроде бы они уже внесены в реплику. Надо посмотреть, может, недостающий сигнал A7 тоже можно пробросить.
- - - Добавлено - - -
68215
- - - Добавлено - - -
что приходит на 11й вход DD31
На 11 DD31 ничего не приходит, она подтянута к + питания резистором.
В продолжении журнальной статьи описывались некоторые доработки, вроде бы они уже внесены в реплику.
В том, что касается формирования адресов DRAM увидел отличие только в упоминавшемся DD31\11 - в журнале (смотрю по сайту AZmastera) сюда приходит сигнал переключения экранов, а у тебя этот сигнал приходит на 13й вход. Но тогда у тебя второй экран вроде как перемещается из 4000h основного банка в C000h дополнительного.
может, недостающий сигнал A7 тоже можно пробросить.
Сигнал есть, но он не участвует в регенерации.
В том, что касается формирования адресов DRAM увидел отличие только в упоминавшемся DD31\11 - в журнале (смотрю по сайту AZmastera) сюда приходит сигнал переключения экранов, а у тебя этот сигнал приходит на 13й вход. Но тогда у тебя второй экран вроде как перемещается из 4000h основного банка в C000h дополнительного.
http://sensi.org/~tnt23/ok240/vsu.png
Второй экран и должен размещаться в дополнительной памяти, если верить статье:
http://sensi.org/~tnt23/ok240/videoRAM.png
Тогда вопрос с видео стал ясен, пометки в скане схемы из журнала на сайте AZmastera неправильные. b2m скорее всего по тем же сканам схемы делал, в emu тоже надо исправить.
- - - Добавлено - - -
Учитывая, насколько неудобный доступ к дополнительной банке, размещение там допстраницы видео выглядит завуалированным издевательством. С другой стороны вроде примеров использования этой страницы в имеющемся ПО и нет, если бы были b2m уже давно исправил бы.
Учитывая, насколько неудобный доступ к дополнительной банке, размещение там допстраницы видео выглядит завуалированным издевательством.
Доступ процессора к видеопамяти и так довольно неудобный: либо отключай ПЗУ и работай из первых 32К, либо мапь вторые 32К на первые. И то, и другое записью в порт управления банками ОЗУ. Так что смена экрана на этом фоне не создает каких-то неудобств.
(Вот разве что код Монитора, работающий с экраном, не сохраняет биты доступа к дополнительному ОЗУ и бит расположения экрана, что некрасиво)
Вопрос по регенерации микросхем памяти 256Кx1 остается открытым. Мультиплексор для MA7 есть (DD31 выход 9), его входы для регенерации заведены на лог.1, то есть в теории достаточно завести туда какой-нибудь подходящий клок?
Доступ процессора к видеопамяти и так довольно неудобный: либо отключай ПЗУ и работай из первых 32К, либо мапь вторые 32К на первые.
Извини, моя занудность прорывается наружу. Все же если отключить ПЗУ, то работать с видеоОЗУ можно из первых 48 Кб.
А работать с допстраницей видеоОЗУ можно или через подпрограммы обмена с рамдиском (я этот геморрой как раз подразумевал) или как то исхитриться и запустить исполнение кода из рамдиска. Эту тему я не исследовал, есть ли такая возможность или нет.
Что касается моего предложения переключить видеостраницу и посмотреть, не изменится ли паттерн протухания ОЗУ, то при подключении сигнала VSU к 13, а не к 11 входу DD31 смысла в это скорее всего (с очень большой вероятностью) нет.
У меня вчера были идеи, как добавить разряд регенерации, но я их лучше подержу при себе, сначала надо проверить, что изменение разряда A7 DRAM повлияет на паттерн скисания.
Тут возможны варианты, например сделать как в журнале, т.е. временно подать VSU на 11й вход, а 13й - на землю. Хотя VSU на 13 можно оставить, если до переделки проверить и убедиться, что переключение видеостраницы не влияет на регенерацию.
Все же если отключить ПЗУ, то работать с видеоОЗУ можно из первых 48 Кб.
Верно, я просто думал о другом :) редактор ZNG так и поступает, ну и Тетрис слямзил этот подход с ZNG.
Как работать с экранной областью в дополнительной памяти, я тоже не исследовал еще. Было бы логичным (с точки зрения удобства) оставлять первые 48К основной памяти как есть, с работающим в них кодом, и по сигналу VSU только подменять старшие 16К с экраном на дополнительные. Но как оно в реальности, не знаю пока.
сначала надо проверить, что изменение разряда A7 DRAM повлияет на паттерн скисания
Я попробую это проделать в ближайшее время, только не знаю, как увидеть результаты, если Монитор не умеет работать с экраном в дополнительной памяти.
Было бы логичным (с точки зрения удобства) оставлять первые 48К основной памяти как есть, с работающим в них кодом, и по сигналу VSU только подменять старшие 16К с экраном на дополнительные.
Да, это было бы удобно, но если по схеме, которую ты привел, то там увы не так.
Я попробую это проделать в ближайшее время, только не знаю, как увидеть результаты, если Монитор не умеет работать с экраном в дополнительной памяти.
У меня появилась идея, что можно попробовать для проверки обойтись без резни и пайки. Но возникли вопросы, ответы на которые сообразить не могу.
дал настояться
Можешь подробнее написать, как конкретно ждал, что процессор выполнял в это время?
Можешь подробнее написать, как конкретно ждал, что процессор выполнял в это время?
Заполнял в Мониторе память от 0 до 7FFFh единичками:
.F 0 7fff ff
.
И больше ничего не делал на протяжении нескольких минут. Монитор крутится в процедуре опроса клавиатуры и теребит кусок памяти со стеком (подозреваю, где-то в районе адресов Bxxxh).
- - - Добавлено - - -
Но возникли вопросы, ответы на которые сообразить не могу.
В эфире рубрика "Спрашивайте - отвечаем".
В эфире рубрика "Спрашивайте - отвечаем".
Про ожидание был вопрос как раз в эту рубрику. А какой монитор, этот (http://azmaster.narod.ru/Ocean-240/Soft/TM.ZIP)?
Не совсем в тему, но занятное совпадение (про "Специалист" отсюда: 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) у меня не получается работать из-за несовместимости контроллера клавиатуры.
монитор другой, с сигнатурой 240/7.
Понял, встроенный в пзу. Я его запускал отключением cpm-ного пзу, а есть штатный способ (сам я не искал)?
Понял, встроенный в пзу. Я его запускал отключением cpm-ного пзу, а есть штатный способ (сам я не искал)?
Из CP/M дать команду EXIT.
- - - Добавлено - - -
По поводу регенерации: в интернетах пишутъ, что в РУ7 впервые появилась авторегенерация по RAS.
в интернетах пишутъ, что в РУ7 впервые появилась авторегенерация по RAS.
Что такое "авторегенерация по RAS" я не знаю, зато помню, что в РУ7, в отличие от РУ5 есть регенерация CAS-Before-RAS. Если ты готов организовать эту штуку в океане, то это круто, но имхо это потребует неслабых изменений и доработок.
Что такое "авторегенерация по RAS" я не знаю, зато помню, что в РУ7, в отличие от РУ5 есть регенерация CAS-Before-RAS. Если ты готов организовать эту штуку в океане, то это круто, но имхо это потребует неслабых изменений и доработок.
Авторегенерация по RAS похожа на CBR, смысл ее в автоинкременте внутреннего счетчика регенерации по одиночному активному RAS при неактивных CAS и WE.
(даже если CBR там и есть, все равно он не будет работать с РУ5, да и не готов я к столь глубокой океаноевгенике)
Авторегенерация по RAS похожа на CBR, смысл ее в автоинкременте внутреннего счетчика регенерации по одиночному активному RAS при неактивных CAS и WE
Микропроцессорные средства и системы 1989/4, с.91:
" ОЗУ К565РУ7 работает в следующих режимах: чтения, записи (ранней записи), чтения-модификации-записи, записи полубайта (слоговом), чтения полубайта (слоговом), регенерации сигналом /RAS, регенерации при "/CAS раньше /RAS" ".
И там подробнее дальше описано.
Думаю, что в интернетах зачем-то изобрели новую сущность и переобозвали "авторегенерацией по RAS" обычный "/CAS раньше /RAS", в котором как раз внутренний счетчик меняется по RASу.
Думаю, что в интернетах зачем-то изобрели новую сущность и переобозвали "авторегенерацией по RAS" обычный "/CAS раньше /RAS", в котором как раз внутренний счетчик меняется по RASу.
Не совсем так. Если посмотреть на "Справочный листок" (http://www.155la3.ru/datafiles/k565ru7.pdf), непонятно откуда взявшийся, то видим там табличку:
68223
видим там табличку
Практически такая табличка есть и в упомянутом номере МПСиС, но она противоречит описанию и картинке cas-перед-ras, которые есть в этой же статье, поэтому я склонен считать не вполне корректной именно таблицу.
Микропроцессорные средства и системы 1989/4, с.91
Можешь прицепить сюда? тот djvu МПСиС 4/89, что я нашел, обрывается на странице 85.
Есть вот такой вариант (http://www.wdigest.ru/mpss_pdf/1989/mpss-1989-04.pdf), он полный, но части страниц размыты. Если этот не устроит, то я выложу куда-нибудь "свой" вариант.
Там странно написано:
Наиболее целесообразно выполнять регенерацию сигналом RAS при высоком уровне сигнала CAS, когда CAS приходит раньше RAS.
При этом за время, равное периоду регенерации, тактируются сигналы RAS и перебираются все строчные адреса (рис. 7).
И то, что я принимал за регенерацию одним-единственным RAS, оказалось обычной регенерацией, когда на ША нужно вручную перебирать адреса.
И да, заявлена CBR, хотя все равно толку от нее в "Океане" нет.
Регенерация в режиме "CAS раньше RAS" выполняется при низком уровне сигнала CAS (рис. 8). В этом режиме работает внутренний счетчик, отсчитывающий регенерируемые строки и срабатывающий от сигнала RAS. Содержимое счетчика увеличивается на единицу в каждом такте регенерации.
Прикинул - биперной процедуры для ожидания скисания памяти будет маловато.
А процедура ожидания нажатия клавиши долбит (стеком) 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 Кб надо переделывать то, что уже есть, думать про это большого желания нет.
Прикинул - биперной процедуры для ожидания скисания памяти будет маловато.
А процедура ожидания нажатия клавиши долбит (стеком) 2 ячейки. Это можно попытаться использовать, если подменить адрес стека.
Дак сейчас память скисает как раз от простого ожидания ввода Монитора. Думаю, не киснет 256-байтный блок, куда относятся бомбардируемые ячейки стека.
Это вариант с адресацией только до 128 Кб озу, для больше надо еще доделывать (а надо ли?).
128Kбайт и так штатный объем. Ты имел в виду 128К 16-разрядных слов? Большее имеет смысл, потому что можем получить квазидиск на четыреста с лишним килобайт, что для компиляции на таргете совсем даже нелишне.
- - - Добавлено - - -
Резать много не хотелось бы. Вот если б что-нибудь подать на подтянутые к лог.1 входы D31.
Дак сейчас память скисает как раз от простого ожидания ввода Монитора. Думаю, не киснет 256-байтный блок, куда относятся бомбардируемые ячейки стека.
По моей прикидке получается, что долбятся те ячейки, которые не прибавляют ни строки к той регенерации, которую обеспечивает вывод видео.
Ты имел в виду 128К 16-разрядных слов?
В "первой части" речь про 128 Кбайт. А потом понял, что одним проводком легко до 256 Кбайт.
Резать много не хотелось бы. Вот если б что-нибудь подать на подтянутые к лог.1 входы D31.
Если тебе все равно, что будет показывать на экране, то можно подать туда SK3 :) Но, конечно, так делать не нужно.
По моей прикидке получается, что долбятся те ячейки, которые не прибавляют ни строки к той регенерации, которую обеспечивает вывод видео.
Сейчас обнаружил интересную вещь. Скисают ячейки во вторых 4 байтах (адреса xxx4-xxx7, xxxC-xxxF) или первых 4 байтах (адреса xxx0-xxx3, xxx8-xxxB), чередуясь каждые 0200h - и все это только в младших 32К, т.е. до адреса 7FFFh. Начиная с 8000h и выше память не киснет. Может, это как-то связано с Монитором, перекидывающим видео-ОЗУ в младшие 32К для записи.
сли тебе все равно, что будет показывать на экране, то можно подать туда SK3 Но, конечно, так делать не нужно.
SK3 на мультиплексоры уже приходит. Там не хватает чего-нибудь ниже SK8 - например, отсутствующего в системе SK9. Можно попробовать GK.
Альтернативный, более щадящий вариант, при котором еще и остаются 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 сейчас приходит туда, куда он приходит по моему пониманию ничего хорошего для регенерации не делает.
1. Перекидываем SK3 с DD28\3 на DD31\11, A2 проца с DD28\4 на DD31\10
2. И в другую сторону перекидываем (A15) с DD31\10 на DD28\4, и сигнал +B (который, в частности, приходил на DD31\11) на DD28\3.
Это правильные сигналы? смотрю на табличку с оригинальными, и не вырисовывается:
Это правильные сигналы? смотрю на табличку с оригинальными, и не вырисовывается:
Сдаюсь, что именно не вырисовывается?
Сдаюсь, что именно не вырисовывается?
Ну если я не наврал в табличке (а я мог запросто, перепутав S1 и S2, например), то переброс SK3 с DD28-3 на DD31-11 затрет A16.
Могу в твоей таблице обвести сигналы, которые меняются местами
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
справа по твоему рецепту
да
- - - Добавлено - - -
Кстати, по твоей таблице/картинке наглядно видно, куда я клоню. Насколько я понял, в оригинале регенерация сигналами
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
Кстати, по твоей таблице/картинке наглядно видно, куда я клоню. Насколько я понял, в оригинале регенерация сигналами
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
Поправил, спасибо.
А для чего тогда нужен третий столбец, где на MAx подаются остальные сигналы с делителей счетчиков - {SK3, SK4, SK5, SK6, SK7, SK8, 1, vsu} ?
На данный момент считаю, что это часть адреса, которая защелкивается DRAMом по /CAS. 6 и 5 - по /RAS, 4 и 3 - по /CAS.
Могу в твоей таблице обвести сигналы, которые меняются местами
Отлично, попробую порезать.
Для полного счастья перед резанием стоит посмотреть логическим анализатором (наверняка ведь у тебя есть) S1 S2 /RAS и /CAS
Для полного счастья перед резанием стоит посмотреть логическим анализатором (наверняка ведь у тебя есть) S1 S2 /RAS и /CAS
Есть, как не быть.
https://zx-pk.ru/attachment.php?attachmentid=65551&d=1529313578
Сигналы снизу вверх: S1 (красный, помечен как D0), S2, RAS, CAS1, CAS2.
6824768248
Просто красота! Видно, что S2=0 действительно соответствует части адреса для /RAS, а S2=1 - для /CAS.
И на картинки попали и момент, когда доступ проца задерживает доступ видеоконтроллера, и когда доступ проца и видеоконтроллера не помешали друг-другу, к регенерации это отношения не имеет, но прикольно.
Пока резать не стал, размышляю. Поменять местами SK3 и лог.1 - это понятно, нужно для такта регенерации RAS. А вот зачем менять A2 и (A15)?
зачем менять A2 и (A15)?
Чтобы сохранить организацию видеопамяти.
Можно подумать об оптимизации переделки, чтобы было удобнее. Вместо SK3 (и его пары от проца) без превышения периода регенерации 4 мс можно взять SK5 или SK6 (тоже с их парами от проца).
Чтобы сохранить организацию видеопамяти.
Ок.
Остановил процессор по команде HLT, но пока не вижу "чистого" такта регенерации, т.е. отдельно стоящего RAS без обоих CAS:
68250
не вижу "чистого" такта регенерации, т.е. отдельно стоящего RAS без обоих CAS
Насколько помню, в журнале написано, что регенерация осуществляется видеоконтроллером при выборке видеоданных, и /RAS без /CAS ты вряд ли увидишь. Если бы регенерация была отдельно, то не нужно было бы заморачиваться с парными линиями проца.
А я еще пропустил в списке замены (случайно, не специально) SK4.
tnt23, если ты еще не закруглил регенерацию, то можешь побаловаться предлагаемой "программной регенерилкой". Перед запуском в мониторе нужно заполнить память 4000-7FFF (или больше, но смысла нет) FFами. Запускаем "регенерилку", ждем несколько минут, жмем любую клавишу, например Enter и проверяем ранее заполненную память. Нечетные колонки 4100-41FF, 4300-43FF, ... 7F00-7FFF должны выжить, а четные - скиснуть.
Исходник прилагается. Это в некотором смысле программная имитация переделки, которую я предлагал.
ivagor, регенерацию еще не закруглил, был в отъезде. Регенерилку успел попробовать один раз, минут пять, странным образом вся память 4000-7FFF не прокисла вообще. Сейчас сделаю еще пару прогонов.
Сделал несколько заходов, один на полчаса - не киснет память вообще.
Уточняющие вопросы
1. Запускал регенерилку по G100?
2. Выходит из регенерилки в монитор по нажатию клавиши?
Уточняющие вопросы
1. Запускал регенерилку по G100?
2. Выходит из регенерилки в монитор по нажатию клавиши?
1. Да, запускал по G100.
2. Выходил по нажатию клавиши, быстро проверял память (чтобы не скисла сама регенерилка), и снова запускал по G100.
Есть предположение, что регенерируется блок больше чем 512 байт.
У меня, скажем так, фундаментальное недоумение. Оно связано с неожиданной регенерацией двух линеек ОЗУ вместо одной. Пока крутится цикл четные колонки, т.е. одна из линеек озу в области A15=0 совсем не трогается.
- - - Добавлено - - -
Сообразил - casы раздельные, а ras то общий, т.е. даже при чтении (или записи) одной линейки озу регенерируются обе. Т.е. результат теста вполне нормальный.
- - - Добавлено - - -
/RAS без /CAS ты вряд ли увидишь
Если убрать из контекста того вопроса, то ras без cas видим здесь (https://zx-pk.ru/threads/30156-glyuchit-pamyat.html?p=1001186&viewfull=1#post1001186)
Если убрать из контекста того вопроса, то ras без cas видим здесь
Видимо, там, где чтение процессором, т.е. активны RAS и CAS2? для первой линейки (с неактивным CAS1) это вряд ли будет полноценной регенерацией, т.к. на ША присутствует адрес обращения процессора.
? Это нормальная регенерация того row, который там на ША.
Вот если бы адреса не было, тогда регенерация только при CBR, но в океанских временных диаграммах такого не видно.
? Это нормальная регенерация того row, который там на ША.
Вот если бы адреса не было, тогда регенерация только при CBR, но в океанских временных диаграммах такого не видно.
Можешь обвести на картинке точное место, где активен RAS и неактивен CAS? такое там вроде есть, но это определенно не чтение видеопроцессором (тот активирует оба CAS). Я полагал это обращением процессора к памяти, т.к. один из CAS активен в этот момент.
Обвел желтым. Несомненно это обращения именно процессора к памяти.
Что-то такое вспоминается про РК86, там для работы с лентой отключалась пара ВГ75+ВТ57, как следствие софту приходилось софтверно же рефрешить память. И если не ошибаюсь, именно обращениям к ячейкам в 256-байтовом блоке, что рефрешило всю память.
ivagor, перебросил пары A2 <--> (A15) и SK3 <--> B+, результат не очень:
68397
Бип при старте компа есть? Картинка не меняется при нажатиях клавиш? Если много раз нажать, чтобы скролл начался, все равно не меняется?
Если комп все же работает (по крайней мере бип есть), то можно попробовать вслепую выйти в монитор и заполнить память 100-B3FF чем-нибудь характерным, например 55h/AAh или на твой выбор. Изменится ли при этом картинка?
Бип есть, но на клавиатуру реакции никакой. Слепая попытка выйти в монитор и сделать теплый сброс тоже не выходит (EXIT, GE000).
Можно еще попробовать Esc61 (режим 512) или Esc60 (режим 256)
На всякий случай - ты перепроверял, что (A15) сейчас приходит на DD28\4, +B на DD28\3, A2 на DD31\10 и SK3 на DD31\11?
На всякий случай - ты перепроверял, что (A15) сейчас приходит на DD28\4, +B на DD28\3, A2 на DD31\10 и SK3 на DD31\11?
Бинго! Вместо A2 припаялся к D2. Перепроверил, сейчас комп стартует нормально. Заполнил память 0-B7FF единицами и оставил настаиваться.
- - - Добавлено - - -
Двадцать минут, полет нормальный :)
Двадцать минут, полет нормальный
Поздравляю! Теперь можно дальше двигаться.
Попробовал примерно прикинуть (из чистого любопытства) длительности сигналов /CAS и /RAS. Получилось tRAS=333 нс, tCAS=250 нс, tRP=83 нс. C tRAS и tCAS все отлично, а вот tRP (RAS precharge) очень короткий, даже для РУ5Б д.б. >=100 нс. Но все же работало, получается это не критичный параметр в данном случае. Смотрел корвет, специалист, орион, океан - везде есть несоблюдение тех или иных параметров сигналов обращения к озу. Но, повторюсь, все же работало :)
Практика - критерий истины, как говаривал мой хороший знакомый.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot