Компьютер "Арго ФВ-6511"

[Mx_Serg]

Выяснил, что CLEAR <32800 значительно увеличивает количество запросов WAIT/ Поэтому загрузка и рвется. Интересно, какая здесь связь...

[Advertiser]

[Mx_Serg]

В общем, тут довольно все хитро... Напомню, что загрузка с магнитофона сделана в этом компе необычно. Связано это с тем, что изначально предполагается софтовое управление магнитофоном. Спекки, понятное дело, о таком не знает, но разработчики предусмотрели "перехват" клавы в обработчике ее сканирования и реакцию на клавиши "стрелки" - управление ЛПМ, Ф10 - перевод из режима загрузки в режим работы. На момент работы в режиме загрузки клавиатура и ее перехват блокируется (кроме, видимо, кратковременного опроса клавиши Ф10). Теперь непонятное.
При CLEAR >32800 наблюдаем небольшой всплеск активности опроса клавиатуры (?), который автоматически через некоторое время прекращается. А вот при CLEAR < 32800 эта активность постоянная и все "растягивания" времянок являются следствием этого факта. Естественно, критичный сигнал формируется РЕ'шками (причем, по монтажному "ИЛИ" там задействованы сразу 4шт), но пока главное подозрение, что за эту часть работы больше отвечает "Memcfg" D42. Теперь немного непонятно, с чем я столкнулся. Либо глюк "by design" т.е. неверная или несоответствующая прошивка, либо в софте перевода в режим спекки, либо в образе ПЗУ спекки, либо в сбойной памяти (как, кстати, протестировать системную память "не спекки" области и корректность ее содержимого"?), либо... В общем подозреваемых пока слишком много.

Напомню, вот линк на схему конфигурации памяти с D42
https://drive.google.com/file/d/15Ye...ew?usp=sharing

Там вовлечены адреса и содержимое регистра конфига памяти.

[b2m]

А граница именно 32800 или всё же 32768 (8000h)?

[Mx_Serg]

Ага, я тоже этим вопросом задался, но... точной границы я не определил - похоже она чуть "плавает" - устойчиво чуть больше 32768, хотя половина памяти все-таки, наверное, не случайно... А можно в эмуле посмотреть - нет там какого-то затыка? Хотя, конечно, если РЕ-шка реагирует на неверную комбинацию - выловить такое в эмуле невозможно. Но хоть какая-то определенность будет.

UPD: Поэкспериментировал с границей. 32782 - практически точный переход. На 32783 уже все более-менее. Но зона не очень четкая и имеет тенденцию к увеличению мусорного трафика по мере сокращения вершины.

UPD2: Глюк сопровождается значительным сокращением трафика по A15 - при глюке циклическое обращение по этой линии значительно сокращается, но возрастает активность на WAIT/

[Mx_Serg]

Еще немного понаблюдал сигналы. Самый главный признак - после CLEAR 32782 появляется стабильный периодический WR/ во второй (ВГ-шный) банк памяти. После CLEAR 32783 он снимается. Поведение постоянно и источником этого WR/ является сам процессор т.е. идет осмысленное выполнение кода.

[b2m]

Знать бы ещё, что делает этот CLEAR. Могу только предположить, что после этого оператора переносится ещё и указатель стека. Если он оказывается в диапазоне 4000-7FFF, то каждый PUSH/POP/CALL/RET будет туда писать/читать. А т.к. эта область является графическим экраном, то арбитр памяти будет тормозить запись/чтение пока не предоставится свободное окно. По-моему, это просто особенность архитектуры.

[Mx_Serg]

По-моему, это просто особенность архитектуры.

Возможно. Тоже смотрел-смотрел на все это, и склоняюсь к версии, что такое поведение у него заложено софтом и архитектурой... Но как он тогда читает с магнитофона в режиме спектрума - непонятно. Оно ж не читается, а только рвется. А, судя по слухам, все-таки как-то с магнитофона чтение работало... Может ему емкости где-то добавить

P.S. А почему эта область - графического экрана? у спекки 16384-23296 (4000...5B00) окно графики... И еще непонятно. Он ведь не тормозит - без CLEAR /WR на том банке вообще не появляется. Ее нет (ну... почти нет ). А появляется она только при CLEAR меньше порога. То, что это как-то завязано с вершиной стека - это однозначно, т.к. при сокращении границы трафик возрастает до определенного значения т.е. в "нехорошую" область попадает все больше данных, но насколько это корректно.
P.S. 2 Можно, кстати, из ASMа вершиной стека поиграться для локализации проблемы :idea:

[Mx_Serg]

Вот сейчас смотрю на схему входа с магнитофона и... Ну это же надо было так наворотить. Кто-то может объяснить как оно работает? Имеем логический элемент ЛА9 (И-НЕ с ОК). На один вход идет сигнал от операционника. На второй - инвертированный атрибут LTen от ВГ75 и все это отправляется по выходу на D6 шины данных напрямую без всяких буферов. При этом импульсы частотой 57,2 kHz появляются на этом выводе ВГ только если запущена команда LOAD"" и дан старт магнитофону кнопкой вверх. Камасутра какая-то Так атрибуты еще никто не использовал ))

[Mx_Serg]

А, я ж схему магнитофона еще не выкладывал... Прилагаю. Еще нет таймера/ВГ/процессора, но все выводы неявно присутствуют в виде адресов на черновиках, поэтому это просто будут прямоугольники с шинами и отсылками к существующим листам.

https://drive.google.com/file/d/1IN3...ew?usp=sharing

Как у записи, так и у чтения есть короткий путь (регистр ИР23->выход и вход->ЛА9->разряд шины данных D6) и длинный через ВВ51 ))

[Mx_Serg]

В общем еще понаблюдал за сигналами. Получается, что младшие байты ОЗУ спекки начиная с 32к размещаются совместно с графическим ОЗУ, а работа в этой области памяти связана с задержками чтения с магнитофона, которая организована напрямую, без применения контроллера прследовательного порта и синхронизируется атрибутом ВГ75. Так оно работать не может в принципе и как только появляется запись в эту младшую часть адресов - чтение не идет. Но как-то и у кого-то оно же работало? Значит, либо образ софта битый/некорректный, либо что-то не так с программированием карты памяти?