makbar, в сабже WAIT дёргает АГ3 с RC-цепочкой на 190 нс.
(Т [мкс] = 0,28 * 6,8 ком * 0,1 нф = 0,1904)
makbar, в сабже WAIT дёргает АГ3 с RC-цепочкой на 190 нс.
(Т [мкс] = 0,28 * 6,8 ком * 0,1 нф = 0,1904)
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
Denn, я не считаю правильным использовать "RC-девайсы" в таких строгих местах.
Разработчик КНГМД для Специалиста и Ориона128, автор SPDOS (журнал "Радио" 12/1992, 1-2/1993). Манускрипт, датированный 1993-94гг: Отладка контроллера SPDOS SPDOS v4.3
Подскажите люди добрые, а что правда, что сабжевый КНГМД, извините, гадит аж в ВОСЕМЬ мест драгоценного адресного пространства F7xx?!
То, что оно из-за простоты дешифрации дублируется в F708..F70F и в F718..F71F - это я понимаю, но что оно делает в F780..F79F ?!!
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
Думаю, поскольку ранее не известно, никому до этого пока что дела не было.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
По ходу пьесы возник ещё вопрос по сабжевому КНГМД. Кому-нибудь удалось на нём нормально работать в связке с процессором ВМ80А в Орионе-128 ?
Проблему потери данных в случайный момент при форматировании никак не могу победить!
Изначале вроде как решилось блокировкой WAIT'а, но впоследствии в ходе многочисленных экспериментов выяснилось, что это лишь уменьшает частоту появления проблемы, но полностью не убирает.
В итоге, начал делать всё по авторской методике настройки, как в учебнике. Программа TESTD$ вообще не может что-либо записать на дискету
Тест записи выдаёт "ХОРОШО !!", а тест чтения - "ОШИБКА !!". По факту на дискете вообще ничего не записано. Раскопка кода программы теста показала, что она не обрабатывает ситуацию потери данных, из-за этого "думает", что запись прошла ок, а по факту из-за длинного цикла записи там случается сразу потеря данных и вываливаемся из цикла
Т.е. резюмирую, родной тест с сабжевым КНГМД у меня не проходит! Причина - ВГ93 не успевает вовремя получить записываемые данные.
Помимо отключения/включения прерываний, пробовал делать "растягивание" сигнала чтения/записи процессора по схеме М.Короткина (на ЛА8), результат тот же самый. Склоняюсь к версии неработоспособности связки ВМ80+ВГ93 ((
П.С. все доработки КНГМД сделал, "стрёмную" дорожку CLK отрезал и пробросил отдельным проводом, питание отличное, блокировочные ёмкости на каждой микросхеме, дисководы и дискеты менял. Запись/чтение секторов работает на ура, проблема только с записью трека целиком.
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
что за "сабжевый" контроллер?.... разве указанная связка не штатная для Ориона?! Или речь о какомто другом уже орионе...
- - - Добавлено - - -
Еще раз!!
Это доработка не от потери данных, а для валидности данных выставляемых ВГшкой на шине при чтении из неё.
если во время записи трека случается прерывание (они есть в новой версии ориона?, я не в курсах), то естественно будет потеря данных.
Разработчик КНГМД для Специалиста и Ориона128, автор SPDOS (журнал "Радио" 12/1992, 1-2/1993). Манускрипт, датированный 1993-94гг: Отладка контроллера SPDOS SPDOS v4.3
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Здесь вся тема по сборке авторского КНГМД. "Сабжевый" - обсуждаемый в этой теме.
У меня складывается ощущение, что с КНГМД работали только на Орионах с Z80-card, т.е. с процессором Z80.
На Орионе-ПРО Z80 стоит штатно и КНГМД там фактически один-в-один, и таких проблем там нету в принципе.
Те же самые алгоритмы работают в режиме процессора "2,5 МГц", потери данных не бывает.
Прошу прощения, это у меня описка, не прерываний конечно же, а WAIT.
- - - Добавлено - - -
Немного конкретики. Упёрся рогом, сделал максимально короткий цикл:
Смысловой нагрузки в нём никакой, он записывает весь трек байтом 03h. Отслеживаем запрос данных, максимально быстро их отдаём ВГ93-ей, а также отслеживаем окончание исполнения команды. Всё! Короче сделать невозможно.Код:LXI B,RG_DAT; F713h LXI D,RG_CMD; F710h MVI A,0F4H STAX D FmtWT: ; ОЖИДАНИЕ ПРИНЯТИЯ КОМАНДЫ LDAX D ANA C JZ FmtWT FmtCYC: ; ЦИКЛ ЗАПИСИ ДОРОЖКИ LDAX D ANA C; =ANI 3 JPO FmtCYC STAX B JNZ FmtCYC RET
И всё равно периодически цикл зависает, т.к. ВГ93-я выплёвывает в регистр статуса (в [DE]) значение 06h (запрос данных + потеря данных). Иногда успевает записаться 40 треков, иногда 20, но рано или поздно это случается.
ПРобовал в цикл вводить счётчик кол-ва записанных байтов и проверку условия потери данных. Это конечно удлинняет цикл, но позволяет понять примерно в какой момент случается проблема. При вылете счётчик показывает значения больше 4864, т.е. проблема случается буквально под самый конец, т.е. уже почти весь трек записан!
Последний раз редактировалось Denn; 11.06.2016 в 20:41.
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
Тактовый генератор в контроллере на какой серии сделан?
Какой кварц используется? Б-1 или НС-49?
alx32, вся логика 1533-ей серии. Кварц - рк 379м
Критиковать - значит объяснять автору, что он делает не так, как делал бы я, если бы умел
Я тоже долго воевал с этим контроллером, пока не нашёл микротрещину в районе тактового генератора, причём рядом с выводом ЛН1, тестер показывал сопротивление 200..300 Ом. Полного обрыва не было, и генератор работал, но частота плавала в районе +-2..3 кГц. Я думал что у меня частотомер глючит...
Причём при форматировании диска всегда был сбойный последний сектор на всех дорожках... Пока не нашёл такую подлянку...
После восстановления дорожки контроллер стал работать без сбоев.
И ещё, у меня стоит Z80-Card.
Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)