Эпопею с чемоданом хотелось завершить красивой демкой, с бегущей строкой и всякими графическими эффектами на дисплее. Всё это вшить в ПЗУ, и наслаждаться этим в любой удобный момент.
На этапе пока я не научился шить ПЗУ, заготовки демки были реализованы ещё в оперативной памяти. И казалось бы, смени адреса, залей в ПЗУ и будет счастье. Но при попытке прошить это в постоянную память, ничего не работало. Попробовал проверить свою программу в эмуляторе и она без проблем выполнила всё именно так, как я от неё ожидал. Код даже работал при записи его частями в УМК, но целиком, со всеми прелестями, вылетал с ошибкой.
И всё никак в толк не мог взять: это лыжи не едут, либо у меня проблемы с ассемблером.
Пробегался по каждой инструкции, стал сам линкером, уже как процессор начал всё исполнять, но ошибку в коде никак не мог найти. И вот тут начинается квест жёсткого аппаратного дебага и трёх недель бессонных ночей.
Предыстория
Ещё к самой первой моей статье «Волшебный чемодан» я написал небольшую демку с бегущей строкой, которая была в оперативной памяти. Как оказалось, бегущая строка не так проста, как кажется на первый взгляд. И у меня не было понимания, как её реализовать. Изначально, для осознания как она должна работать, сделал реализацию её на си.
#include <stdio.h>
#include <string.h>
#include <unistd.h>
int main () {
char array[] = "hello habr ";
int len = strlen(array);
int position = 0;
while (1) {
for (int i = 0; i < 6; i ++) {
if ((i + position) < len) {
putchar(array[i + position]);
} else {
putchar(array[i + position - len]);
}
}
if (++position == len) {
position = 0;
}
usleep(10000);
putchar('\n');
}
return 0;
}
Далее начал переносить код в ассемблер, попутно вводя его в чемодан. Самое сложное было его отлаживать, поскольку программа занимала примерно 120 байт, то ввод каждый раз занимал примерно 10 минут. Дошло у меня до того, что я разбил программу на куски, раскидал их по адресам, и перебивал только те места, которые заменил. Это вообще суровая отладка, которой я никогда не занимался. Весьма интересный опыт.
Вот пример промежуточного результата (музыка ютуб).
Ещё видны артефакты, тогда не понимал, как зациклить бегущую строку. Но в результате разобрался, после всех многократных итераций, нескольких недель бессонных ночей, у меня получился следующий код. Он максимально оптимизирован (в рамках моего понимания), и он работает в ОЗУ.
len equ 0x15
counter_sh equ 0x0618; 0x618 если буду делать 1 раз 6 0x2492
ORG 0800h
start:
lxi h, counter_sh
m1:
mvi b, 0x01
mvi c, 00 ; i
lxi d, data
m2:
lda position_a
add c; i+position
cpi len ;вычитаем длину из а
jp else ; если больше, то переходим
;Если больше нуля putchar(array[i + position]);
mov e, a; array_l
jmp putchar
else:
;если меньше нуля putchar(array[i + position - len]);
sui len;mvi a, len 2
mov e, a; array_l
putchar:
call out_p;вывод символа
;проверка количества циклов выполнения
dcx h
mov a, h
ora l
jz increment_pos; типа всё, цикл закончен!
;проверка сдвига по выводу на экран
mov a, b
cpi 0x20
jz m1; если 20, то перейти на m1
adi 1;rlc ; сдвинуть влево
mov b, a
inr c; i++
; inx d
jmp m2
increment_pos:
lda position_a
inr a;
cpi len; достигли ли мы конца?
jnz load_pos;ещё пока не достигли дна
sub a ;дно пробито, очищаем позицию на нуль
load_pos:
sta position_a; загружаем её
jmp start; топаем на старт
out_p:
;F8 - рег сегментных
;F9 - настр
mvi a, 0; Погасим все сегменты
out 0F8h; зажигаем соответствующий сегмент
ldax d ;загружаем в А содержимое по адресу ячейки D+E
out 0xF9
mov a, l; регистр В хранит порядковый бит сегмента
out 0F8h; зажигаем соответствующий сегмент
ret
data:
DB 76h, 3Fh, 7Fh, 7Ch, 30h, 00, 31h, 3Fh, 5Eh, 00h, 5Bh, 3Fh, 5Bh, 5Bh, 00h, 39h, 73h, 6Eh, 7Fh, 5Eh, 39h, 00h, 00hТогда я записал чисто для себя видео, потому что в дальнейшем предполагал прошить всё в ПЗУ и сделать красиво. И работающее видео бегущей строки есть только вот в таком качестве.
Как видно на видео, ещё не решена проблема «размазывания» символов на два сегмента. На тот момент я ещё не понимал, в чём кроется проблема, хотя впоследствии оказалась, что это программная ошибка.
Ну вот, у меня есть код, я умею шить ПЗУ, осталось только взять
ORG 0800h заменить ORG 0400h, пересобрать и прошить в ПЗУ. Делаю, и-и-и-и, ничего не работает! Вообще, совсем, никак.И вот тут начинается совершенно необычная магия, которая неведома обычным программистам. Не буду спойлерить, обо всём по порядку.
На старт, внимание, DEBUG!
Ну что же, настало время выловить всех жуков в чемодане. Как я уже сказал, первое что я попробовал сделать — это перенести программу в "Симулятор УМПК-80". Да, там есть архитектурные отличия, в частности, дисплей работает совершенно по-другому. Поэтому я просто смотрел, что же происходит в портах. Также сделал подпрограмму симуляции вывода в память, вместо дисплея. С точки зрения логики, всё работало как часы. Но в чемодане не работало. Значит пойду по пути декомпозиции и проверю что да как.
Одно из подозрений было, может ПЗУ вообще не работает? Хотя такого быть не может, потому что я уже делал мигалку в посте "Что с памятью моею стало" и она успешно работала. Поэтому решил взять программу, чуть посложнее, ту самую, которая выводит RuVDS и проверить её. Программа простая, и приведу её тут целиком.
ORG 0400h
start:
mvi l, 01 ; Стартовый бит дисплея
lxi b, data
m2:
call out_p
mov a, l
cpi 20h
jz start; если подошли к концу, то перейти на m1
rlc ; сдвинуть влево
mov l, a
inx b ;инкрементируем указатель на данные
jmp m2
out_p: ;подпрограмма вывода
mov a, l; регистр В хранит порядковый бит сегмента
out 0F8h; зажигаем соответствующий сегмент
ldax b ;загружаем в А содержимое по адресу ячейки D+E
out 0F9h
ret
data:
DB 73h, 6Eh, 7Fh, 5Eh, 39h, 00h, 00hПрошиваю её в ПЗУ, и пробую. Всё корректно работает, заодно разобрался с проблемой артефактов. Оказалось всё просто, при переходе к следующему сегменту не гашу вывод, поэтому окрашиваю следующий сегмент предыдущим значением, и именно из-за этого идёт смазанное изображение. Лучше один раз увидеть, чем десять раз прочитать, сразу всё станет понятно.
Там я обмолвился с проблемами артефактов, но ещё непонятно что же это такое.
Казалось бы, решение простое, чтобы избавится послесвечения — это добавить пару строк кода в функцию
out_p:out_p: ;подпрограмма вывода
mvi a, 0; Погасим все сегменты
out 0F8h; зажигаем соответствующий сегмент
ldax b ;загружаем в А содержимое по адресу ячейки D+E
out 0F9h
mov a, l; регистр l хранит порядковый бит сегмента
out 0F8h; зажигаем соответствующий сегмент
retДобавлено всего лишь:
-
mvi a, 0— гашение сегментов -
out 0F8h— вывод в порт нуля
То есть никаких криминальных изменений нет, загружаю и… Ничерта не работает, всё падает с ошибкой!
В режиме отладки вместо RuVDS выводятся какие-то артефакты, а при полноценной работе не работает вообще. Просто мистика какая-то!
При этом если взять, забить ПЗУ нулями (операция nop), а в ОЗУ расположить код, то код в ПЗУ корректно выполняется. Чтобы было понятнее, лучше посмотреть на видео.
Надо понимать, что это уже шла третья или четвёртая бессонная ночь, когда я сидел с этим чемоданом до 6 утра.
Когда ничего не работает, приходит время читать документацию.
Все лгут, никому нельзя верить
Как говорил герой одного знаменитого сериала: «все врут». Поэтому я не верил никому: ни себе, что я пишу хороший код, ни программатору, что он корректно записывает, ни транслятору, его писали люди и он может ошибаться, ни чемодану, который может работать не так. И требовалось проверить всё.
Проще говоря, источником ошибок могли быть:
- Программист.
- Транслятор.
- Программатор.
- Чемодан.
- Работа с дисплеем.
С кодом всё просто, смотрим, что даёт транслятор, смотрим документацию на процессор и сверяем каждый байт. После 20 раз, документация уже не нужна, и ты можешь это делать, не подглядывая в справочник. В этой области я был уверен. Плюс код погонял в эмуляторе, и там он работает корректно. Следовательно в первых двух пунктах я более-менее уверен, тем более что не так всё сложно.
▍ Проверка программатора
Следующим этапом надо было проверить программатор. Поскольку программатора у меня два, то разумно будет одним программатором записать ПЗУ, а другим считать её. И сравнить содержимое, одно и то же ли туда пишется?
Подключаю программатор, и в хекс редакторе bless открываю код, и смотрю что же считывает программатор.
Содержимое файла прошивки.
Результат чтения микросхемы.
Содержимое идентично, значит проблема не в программаторе, всё записывается корректно.
▍ Обратимся к документации
Когда отпадают все возможные варианты, приходит грустная пора чтения документации.
И вот что выяснилось, что оказывается на странице 27 даётся такая фраза, которая ничего не проясняет, а только ещё больше запутывает.
Секундочку,
0xF9 это же как раз регистр для работы с дисплеем? То есть запись в этот регистр может как-то отключать память? Самое забавное, что больше нигде этот момент не проясняется. Окей, пойдём другим путём, есть процедура вывода на дисплей в документации, может просто возьмём её и реализуем. К сожалению в силу её реализации в УМК, не получится её так просто использовать в своих программах, вызывая её, поэтому просто переписал её, выкинув «лишние» моменты опроса клавиатуры. В документации она начинается на 71 странице, называется CIBEG. Кстати, в моей прошивке она эквивалентна, только используются другие адреса памяти (у меня 1кБ ОЗУ, а документация на 2-х килобайтную версию УМК).
Изначально, я сделал реализацию с nop, так чтобы по тактам процедура полностью соответствовала и точно располагалась в памяти, но ничего не работало.
И тут меня начало осенять, что если программа очень большая, то ничего не работает? Убрал все nop и сделал её максимально короткой, и, о чудо!, всё заработало!
PORTA equ 0F8h ;Порт адреса
PORTB equ 0F9h ;Порт данных
ERASE equ 0 ;Сброс индикации
NMBIND equ 00100000b ;N индикат №5
ORG 0400h
start:
lxi h, BUFCO
mvi b, NMBIND
ciloop:
;Цикл регенерации
mov a, b
out PORTA
mov a, m
out PORTB
;in 10
;ani 7
;cpi 7
mvi a, ERASE
out PORTB
;jnz 10
inx h
mov a,b
rrc
mov b,a
jnc ciloop
jmp start
BUFCO:
DB 00h, 39h, 5Eh, 7Fh, 6Eh, 73h, 00h
Корректный результат работы с гашением сегментов.
Таким образом, эмпирическим путём я установил, что если программу сделать меньше 32 байт, то всё работает корректно.
В работе это выглядит вот так:
Осталось проанализировать, что же произошло, почему не работает программа более чем 32 байта?
Анализ проблемы
Как оказалось проблема аппаратная, почему-то мой волшебный чемодан не подаёт сигнал на 5 адрес пин микросхемы ПЗУ (как раз 0x20h). Поэтому вместо того, чтобы считывать данные с 0x20, чтение идёт с нулевого адреса микросхемы ПЗУ. Это и объясняет все вылезающие артефакты, которые были при выводе. Фактически это данные нулевых адресов моей ПЗУ, или точнее 0x400 в памяти чемодана.
Как говорится, электроника — это наука о контактах, и надо проверить, может где-то имеет место непропай, либо плохой контакт. Вооружившись мультиметром, начал прозванивать все ножки.
Микросхема ПЗУ программы монитор и пользовательская ПЗУ.
Тыльная сторона установки микросхем.
Все адреса успешно звонились у обоих микросхем, отличие было только в сигнале CЕ (инвертирован), который и определяет “адресность” микросхем. То есть, сигналы корректны, и сигналы на монитор приходят успешно. Пробовал всё покачать, притереть, но работоспособности так и не добился.
В любом случае, проблема аппаратная. Можно было разбросать код по микросхеме, минуя адрес 0x20, ещё уменьшив размер микросхемы, для моей демки этого бы уже хватило, но моральных сил на этот эксперимент уже не хватило.
Что же дальше?
После указанных проблем, как-то подостыл к чемодану, потому что для дальнейшей работы нужно полное ПЗУ. Напоследок вывел habr, чтобы не было обидно. А далее зашил нейтральное слово «HELLO», без бегущей строки и решил собрать чемодан до лучших времён.
Взглянем в последний раз на процессорную плату с ПЗУ, перед сборкой.
Фух, это было круто. Никогда бы не подумал, что буду ловить вот таких аппаратных жуков, хотя хотел просто написать программу.
Заключение
К сожалению, в рамках статьи невозможно описать все варианты экспериментов, которые я провёл, покуда выловил этот баг. Вариантов кода было множество. Изначально я сетовал на обращение не в те области памяти, потом сетовал на вывод в порт
0F9h, а потом когда понял, стало совсем грустно. Но всё ещё искал варианты, как же разрешить эту проблему. Все ветвления путей решений заняло недели три, при этом обычно я засиживался до 4-6 утра, и зелёным овощем на следующий день шёл на работу, а вечером всё повторялось. Конечно, это привело к некоторому выгоранию по данному устройству, но остановиться было нельзя — очень интересно!Могу честно сказать, что наигрался с чемоданом от души. Может не так эпично вышло, чем если бы собрал всё сам, но тем не менее, разобрался, как шить ПЗУ. Попробовал разные программаторы. Поймал аппаратный глюк, который по неопытности сразу не понял.
Из любопытного, ПЗУ КР573РФ5 мне зашить так и не удалось, хотя я надеялся больше всего. При отладке у меня постоянно “запекались” ПЗУ в стиралке, пока я тестировал программу на оставшихся. В процессе экспериментов у меня скопилось несколько мёртвых микросхем.
Микросхемы, павшие в боях.
В любом случае, это было очень интересное развлечение. Ещё порывался поработать с платой расширения, но мне удалось только снять с неё лишние детали, а вот с портом ввода-вывода так и не удалось договориться.
Думаю на этой интересной ноте, я таки завершу свои эксперименты с волшебным чемоданом, это крайне интересное устройство. Но я устал, я мухожук.
Предыдущие публикации по теме:
Комментарии (44)
Javian
18.02.2022 12:34+2Похоже на неисправность микросхемы логики. Помню в каком-то журнале типа Моделист-конструктар попадалась статья о тестере микросхем мелкой логики перед использованием в сборке компьютера. Запомнилось, что автор пишет о том, что неисправные микросхемы встречаются часто и затрудняют сборку и диагностику компьютера.
forthuser
18.02.2022 13:41+3Используемый автором статьи программатор TL866 (TLL866+) имеет режим тестирования и многих микросхем TTL логики (возможно с клипсой можно проверить какие то из них не выпаивая из схемы и не разрезая дорожки)
P.S. Может помочь, в каких то случаях, добавления фильтрующих конденсаторов на ножки питания проблемных микросхем.
dlinyj Автор
18.02.2022 13:51+2Спасибо за идею! Возможно если найду ещё вдохновения, сделаю. Потому, что сейчас прогорел насквозь с этим проектом.
Int_13h
18.02.2022 15:30+1О, лет 10 а то и больше назад меня просил сделать такой тестер чувак с какого-то винрарного олд-писишного форума. Собрал прототип, написал софт под винду на бейсике, а заказчик и пропал с концами.
ioccy
19.02.2022 10:35Все украдено до нас. Определяет тип микросхемы автоматически.
Int_13h
19.02.2022 19:55+1Да у них функцыонал скудненький. Просто показать, микросхема ОК или нет. А таблицу истинности? А руками (мышкой) поджечь входы по очереди и отмониторить выходы? Можно триггеры и более сложную логику тестировать. А подать на входы последовательности 01011010101 и получить с выходов другие 10101001 и построить график? Опампы вообще можно было бы погонять с обратной связью с разными входными напряжениями и построить график на выходе. Хорошая идея кстати.
vlad_bravo
18.02.2022 14:19+1Раз вывод в порт блокирует ПЗУшку, то копируем код в ОЗУ и запускаем оттуда.
dlinyj Автор
18.02.2022 14:22Я это попробовал. Не работает. Как уже сказал, опытов было очень много.
И этот вывод в порт, блокирует ПЗУ, какая-то странная штука, которая даже по схемотехнике никак не работает. Либо опечатка, либо имелось в виду что-то другое.
Там именно проблема в том, что где-то не выставляется адрес 0x20 (бит не выставляется на микросхеме ПЗУ). И поэтому чтение идёт снова с нулевого адреса.
REPISOT
18.02.2022 14:53постоянно “запекались” ПЗУ в стиралке
А вы их ножки фольгой закорачивали во время стирания?dlinyj Автор
18.02.2022 14:55Для того чтобы стереть микросхему нужно ножки микросхемы объединить между собой. Делается это для того, чтобы убрать потенциал при воздействии УФ излучения, поскольку в момент стирания микросхема работает как солнечная батарея, и напряжение, вырабатываемое на ней, может привести к пробою кристалла и выходу устройства из строя.
Подробнее в моей статье.
ru_vlad
18.02.2022 15:39+1Увы РФ долго не живут, у самого штук 5 покойных осталось (некоторые частично) еще когда Специалистом баловался. Вот фирменные 27 живут дольше.
По Багу с микросхемой, правильно советовали, попробовать заменить (что бы не выпаивать можно сверху прицепить) и посмотреть осциллографом что приходит.
Питание тоже лучше проверить на помехи.
dlinyj Автор
18.02.2022 15:42Вот фирменные 27 живут дольше.
У меня померли примерно в одинаковой пропорции: две 27 на одну рф :)ru_vlad
18.02.2022 15:48+1У меня померли примерно в одинаковой пропорции: две 27 на одну рф :)
Значит повезло :)
У нас РФ5 (в пластмассовом корпусе ) были так из 3 коробок (в каждой около 30 шт) две выкинули, а то что осталось только для проверок.
TrexREXX
19.02.2022 18:10+4Почитал ужастиков по поводу ПОВАЛЬНОГО убийства микросхем с УФ стиранием, и с трудом в это верится.....
В стародавние времена матричных принтеров(поддержка кириллицы), и АОН'ов было СТЕРТО и ЗАПИСАНО ~200-300 (кто ж их считал).
Не могу вспомнить убитых СТИРАНИЕМ! Ноги ничем не замыкали, в каких-то стиралках был лоток металлический, и все! Да и сегодня тру вот такой лампой.
Ни одна не отлетела. А их есть у меня.
Все они не по разу стерты и записаны!
Тестовая с АОНА
.Немного хоббию иностранную(древнюю)измериловку, там как правило стоят ПЗУ с УФ стиранием. Их сразу копирую, и что-бы проверит пишу в другие.
ПЗУ с Advantest R6871E.
Это уже копии для проверки, оригиналы в родном приборе!
Естественно ТРУ и ПИШУ,ТРУ и ПИШУ,ТРУ и ПИШУ.
Увы РФ долго не живут .....
У меня с ~ 20 иностранных приборов не было ни ОДНОЙ битой УФ ПЗУ, может повезло...
Int_13h
19.02.2022 20:06+1А вот интересно, в качестве бредовой идеи, если стирать РФ-ки во включенном состоянии и в процессе облучения проверять ячейки чтением содержимого?
dlinyj Автор
20.02.2022 02:04Почитал ужастиков по поводу ПОВАЛЬНОГО убийства микросхем с УФ стиранием, и с трудом в это верится.....
Где о таком почитать? То что потанцевал появляется — это стопудово, что может пробить, не исключено, что можно стирать не замыкая, без сомнения :).TrexREXX
20.02.2022 07:44Увы РФ долго не живут, у самого штук 5 покойных осталось (некоторые частично) еще когда Специалистом баловался. Вот фирменные 27 живут дольше.
У меня померли примерно в одинаковой пропорции: две 27 на одну рф :)
У нас РФ5 (в пластмассовом корпусе ) были так из 3 коробок (в каждой около 30 шт) две выкинули, а то что осталось только для проверок.
РФ5 не заработала ни одна.
То что потанцевал появляется = То что ПОТЕНЦИАЛ? появляется
Вы сами измеряли? Измерять какие ноги? Адреса? Данных? На наших или фирменных? Давайте попробую. Чем измерять?
steanlab
18.02.2022 16:04+2Спасибо за статью! Возник только один вопрос, а не родится ли из всего этого что-нибудь для участия в Chaos Construction например? У меня wild demo на старом «непрофильном» железе — одна из самых любимых номинаций *вспомнил CC19 и демку на осциллографе С1-86 (+STM32+Rust).
dlinyj Автор
18.02.2022 16:23Посмотрим. Не уверен, что хочу участвовать в CC в настоящее время. Из моих любимых демок, это демка на телефоне youtu.be/3db3HIQuGds
Но подумаю над вашим предложением.steanlab
18.02.2022 17:31+1СС просто как пример самой «на слуху» demo party. Демка на УМК мило бы смотрелась везде :) (правда не помню есть ли в вашем агрегате бипер для музыкального сопровождения). И да, AONDEMO классная :)
dlinyj Автор
18.02.2022 22:29+1Бипер припаять не проблема. Посмотрим, в последний раз на СС был в 2018 году, всё как-то стало сильно грустнее 2007.
steanlab
18.02.2022 22:42+1Ну таки думал и я, что СС — уже давно не торт. Но пересилил себя, пошел в 2019 с докладом про cвои хабрамикророутеры в свете «PirateBox+локальное зеркало Wikipedia». Отчитал, начал осматриваться. И таки ж дух демосцены учуял. Подробнее в отчете Строительство хаоса #21. Он может и наивный, но зато искренний :)
dlinyj Автор
18.02.2022 22:59+1Пост ваш помню. Да, я перепутал даты, был в 2018 и 2019. Помню, это тот CC с плётками, которая моя бывшая коллега раздавала :).
Значит там условно пересекались. Всё равно, у меня осталось ощущение «не то». Понимаю, что я может слишком много хочу.steanlab
19.02.2022 01:44+1Я думаю ламповости нулевых годов хотят многие. Но времена меняются, вместе с ними меняемся и мы. Для меня кстати отчасти CC-19 «сделала» встреча с Столлманом. «маленький шаг для человечества, большой для человека» :)
Telmah
18.02.2022 18:07+2во времена учебы в Рижском Авиационном Университете (он был тогда уже не РКИИГА, но до конца его ещё не раздербанили) с такими "чемоданчиками" мы работали на лабах на курсах по микроэлектронике... в основном с платами расширения с индикаторами и светодиодами. а ещё у такого чемодана была своя наприятная "фишка" - провод питания находится внутри и для подключения его к розетке его надо тащить наружу... одно неловкое движение - и разболтаные поколенями студентов фиксаторы не удерживают крышку, она падает вниз и острой окантовкой перерубает провод питания
smart_pic
18.02.2022 18:08В свое время часто зависал с подобными уччебными комплетами. Сам собирал Радио86РК, потом Синклера , Орион128, Аоны.
Сейчас у меня лежит УЦИ Ф5246 (устройство цифровой индикации , применяется в станках с ЧПУ) - это полный комплект К580. Хорошая корзина , все добротно сделано . Не ремонтировался , со склада взяли , но он оказался не рабочий, поэтому и придарили. Вот думаю для чего приспособить. Хотя сейчас на 32 битном МК можно сделать более компактно и по функционалу шире.
dlinyj Автор
18.02.2022 18:21А есть фотографии УЦИ? Лично я смотрю на современные УЦИ, на Али они не так дорого стоят.
smart_pic
18.02.2022 18:55Есть схемы , описание - это легко гуглится. Вот пара ссылок. Фото могу сделать. Интересуют внутренности? Все в идеальном состоянии. Был опломбирован . Я вскрыл корпус , но дальше ничего не делал.
dlinyj Автор
18.02.2022 22:27Потрясающий аппарат, но как я понял работает не с линейками, а с сельсинами.
Никогда не сталкивался ни с тем, ни другим.
SignallerK
18.02.2022 22:11Всегда интересно читать такие детективные истории. Спасибо.
Когда-то сам присоеденял SRAM к ПЛИС.
Естественно она сразу не завелась и я долго думал почему считываемые данные "кривые". Пока не допер что это банальный непропай :).
dlinyj Автор
18.02.2022 22:21+1Непропай — слишком частая причина багов, но благо ловится легко, хотя бы под микроскопом.
smart_pic
19.02.2022 10:17+5Непропай выходов микросхем ТТЛ ловится очень легко. Если отпал выход -то напряжение в цепи будет 2.5 Вольт. Для этого делали простенький тестер на основе компараторов. Если напряжение больше 4Вольт - горит зеленый светодиод , если меньше 0.5Вольт горит красный, если от 0.5 до 4 Вольт - то оба светодиода потушены.
Или при помощи осциллографа легко определяется. При помощи осциллографа легко увидеть замыкание цепей - появляются трехступенчатые импульсы. Трех(и более ) ступенчатые импульсы появляются при пробое входов ТТЛ микросхем. При определенном опыте ремонта 580 комплекта и схем на основе 155, 555 логики все относительно легко восстанавливается.
Примечание. Лучше использовать простой аналговый осциллограф с полосой пропускания до 10МГц. в режиме непрерывной развертки.
TrexREXX
20.02.2022 07:48Да, логический пробник здорово помогал! А если в нем был и генератор, в том числе одиночных , коротких импульсов, то вообще песня..... На простой логике на вход подал, стрельнул - на выходе посмотрел реакцию.
VT100
19.02.2022 14:15Секундочку, 0xF9 это же как раз регистр для работы с дисплеем? То есть запись в этот регистр может как-то отключать память? Самое забавное, что больше нигде этот момент не проясняется.
Схема чемодана есть? Можно там посмотреть.
dlinyj Автор
20.02.2022 02:06Схема в предыдущем посте была. Ничего там особенного не нашёл, да и причина не в этом.
VT100
20.02.2022 14:59Вот такая хтонь у меня получилась, если я правильно интерпретировал работу не глядя в мануал процессора. При записи по младшему адресу (в память или в I/O) 0111 xxxx — микросхемы ПЗУ и ОЗУ отключаются от шины. До сброса или до записи по другому адресу (D16 -> D14 -> D23 -> D15).
Также — они отключаются при выставлении старших адресов 11хх хххх (D12 -> D23 -> D15).
forthuser
Прoпаять паяльником контакты микросхем проблемной дорожки не пробовали?
(может присутствовать окисление места онтакта)
P.S. Когда то тоже развлекался выводом на индикатор бегущей строки из текста русских букв на 580-м ассемблере и оперaторы приборов могли, к примеру, прочитать во время работы какой нибудь анекдот пока отлаживал основной функционал программы. ????
dlinyj Автор
Не пробовал, потому что обрыва нет. Там проблема в другом явно.
На счёт анекдота — однозначный плюсец :)