Все же кнопочная клавиатура, это так аутентично, как бы по настоящему, на контроллере с ПС, может оно и практичней, но уже не то. Жаль что подходящих кнопок практически не найти, а кнопки пробел, их и небыло никогда.
Вид для печати
Все же кнопочная клавиатура, это так аутентично, как бы по настоящему, на контроллере с ПС, может оно и практичней, но уже не то. Жаль что подходящих кнопок практически не найти, а кнопки пробел, их и небыло никогда.
А что эта мультикарта из себя представляет? Картинку хоть глянуть можно? :)
Мультикарта-2, как я понял, исходя из выложенной схемы, это СОМ-порт и контроллер IDE с часами.
А есть там ROM-диск?
Перевел плату Мультикарта-2 в формат Altium Designer и перерисовал ее в Sprint Layout.
Пусть будет для истории.
Есть такая плата- у меня.Мне ее Смирнов еще в 2003г посылал,пока лежит.Вот фотки платы с монтажкой и фото схем.На плате все:IDE+RTC+COM+AY/Можно собирать не все сразу,а поблочно. Вложение 60568Вложение 60569Вложение 60570Вложение 60571
Вот как и обещал,получите,как говорится и распишитесь.Получил сие в мае 2003,до сих пор лежит,думаю когда нибудь соберу(после того,как "сваяю" Орион 512).
В письме Смирнов пишет уточнения по сборка Мультикарты.Вложение 60612Вложение 60613Вложение 60614Вложение 60615Вложение 60616Вложение 60617Вложение 60618Вложение 60619Вложение 60620Вложение 60621Вложение 60622Вложение 60623
С этой парты не видно! (с)
А с этой видно? https://yadi.sk/d/_9nnSLCv3Gs9Cz
Выложить все файлы в виде архива. Так ничего не разобрать.
Выложил на Яндекс диск,ссылка в предыдущем посте.
- - - Добавлено - - -
Можете посмотреть https://yadi.sk/d/_9nnSLCv3Gs9Cz
- - - Добавлено - - -
Выложил по просьбе DIMKA55
Схема и ПО (ORDOS) разрабатывалась и с возможностью применения и адаптации для Ориона-128
Просто у меня на ходу был ПРО который почти все время работал в режиме 128 на 10 Mhz (оно же быстрее чем ВМ80 на 2,5)
при компиляции указываешь ключ для чего собирать и всё
Правда для 128 предполагалось использовать монитор версии 4.10
Вопрос к знатокам устройства часиков (512ВИ1) на плате IDE-RTC. Дошли руки пописать под них ПО, всё прекрасно работает, но есть большой и неприятный глюк! Если после любого обращения к часам выключить питание компа, то комп не стартует (на экране хаотично мигающий мусор). Аппаратный сброс не помогает. Помогает только выключить и подождать 20+ секунд. После (видимо глубокой разрядки кондёров по питанию) комп стартует и работает нормально. Глюк стабильный. Если не обращаться к ВИ1, то комп выключается-включается нормально. Пробником в железку пока не лазил, но по симптомам полное ощущение, что эта самая ВИ1 при старте "светит в ШД" и т.о. мешает работе ЦПУ. Вероятно, после обращения к ВИ1, её нужно как-то специально переводить в сон, но как?
Я перерисовал с "китайского" на "русский" причинный участок схемы:
https://pp.userapi.com/c637424/v6374...l5HufL7yvo.jpg
Вижу некий "рассыпной" триггер на рулёжку чипселектом ВИ1, активируется он похоже стробом адреса ВИ1 (AS), а вот с деактивацией я не понимаю что там наворочено...
Никакой документации по программированию нет (или у кого-то есть?). Есть чужая утилита работы с этими часами, там никаких откровений, и с ней глюк тот же самый. Как понять задумку авторов?
В 90-х я запускал ВИ1 по инструкции из Радиоежегодника-89 (легко прогугливается в djvu), в т.ч. и начальную программу использовал сначала именно ту что публиковалась там, только перевел в мнемоники Z80, она потом "обросла мясом", перетекла в драйвер для CP/M и т.п. Но инициализация и режимы скорее всего остались "как в учебнике", и описываемой проблемы я не припоминаю. Кстати, режимы используются другие чем например в VC Ориона-ПРО (например режим BCD-счета, возможно и другие). А проблема на всех экземплярах ВИ1 воспроизводится?
Вот как оно в коде инициализируется:
Скрытый текст
Код:ADDRVI EQU 0F760H ;
; инициализация апп. часов
LD BC,270AH ; ПИШЕМ В РЕГ. А Q=32768 Гц SQW=512 Гц
call VIset
LD BC,860BH ; ЗАПРЕТИТЬ СЧЕТ, ДВОИЧНЫЙ ФОРМАТ
call VIset
LD C,0 ; УСТАНОВИТЬ СЧЕТЧИКИ:
LD A,(SEC)
LD B,A ; СЕКУНД
call VIset
LD C,2
LD A,(MIN)
LD B,A ; МИНУТ
call VIset
LD C,4
LD A,(HOUR)
LD B,a ; ЧАСОВ
call VIset
LD BC,060Bh ; РАЗРЕШИТЬ СЧЕТ
;
; Set byte to 512VI1 CMOS. Inp: C=register(address), B=value
;
VIset:
SetVI128:
ld (ADDRVI),bc
ret
[свернуть]
И далее так используется:
Скрытый текст
Код:; получить дату в формате ДД:ММ:ГГ
IGETDT: ld hl,BUFFER+17
ld de,BUFFER+20
ld bc,17
lddr
CALL GETDAT0
ld hl,DAY
ld de,BUFFER
ld bc,3
ldir
ld a,3
jp ADDNBF
GETDAT0:LD A,(VI1) ; 0 - программ., 1 - 512ВИ1
OR A
RET Z ; выход, если прогр. часы
GETDAT1:LD C,0Ah
call VIget
RLCA
JR C,GETDAT1 ; цикл, если идет обновление
LD C,7
call VIget
ld (DAY),a
ld C,8
call VIget
ld (MON),a
ld C,9
call VIget
ld (YEAR),a
ret
; установить дату в формате ДД:ММ:ГГ
ISETDT: ld hl,PARBUF
ld de,DAY
ld bc,3
ldir
LD A,(VI1) ; 0 - програм., 1 - 512ВИ1
OR A
RET Z
; установка даты апп. часов
SETDAT1:LD C,0Ah
call VIget
RLCA
JR C,SETDAT1 ; цикл, если идет обновление
LD C,7 ; УСТАНОВИТЬ СЧЕТЧИКИ:
LD A,(DAY)
LD B,A ; дней месяца
call VIset
LD C,8
LD A,(MON)
LD B,A ; месяцев
call VIset
LD C,9
LD A,(YEAR)
LD B,a ; лет
jp VIset
;
; Get byte from 512VI1 CMOS. Inp: C=register(address), Out:A=value
;
VIget:
GetVI128:
ld a,c
ld (ADDRVI),a
ld a,(ADDRVI+1)
ret
[свернуть]
Из того что еще вспоминается: никак не работало тогда корректное определение сбоя регистров часов по пропаданию питания (в ВИ1 есть спец бит в каком-то регистре). Не работало как описано: то нормально определит, то глюк, так и не понял почему. И в итоге стали тупо писать в некоторые ячейки пользовательского ОЗУ ВИ1 некий хеш, и при старте ОС проверять его как флаг того что данные валидны. Т.е. в реальной ВИ1 не всё может быть как оно в теории в даташите.
Что забавно: работы с ВИ1 начал только потому, что случайно купил этот Радиоежегодник (в 89г. у меня еще не было Ориона, я тогда тупо скупал в книжном все интересные журналы по радиотехнике, и должен заметить, во Владимире их было очень мало, даже приходилось посидеть в библиотеке в охотку) и также случайно году в 93-94 когда Орион у меня уже был, в магазе что-то очень задешево продавались сами ВИ1.
Error404, если не считать адресации, то всё остальное аналогично.
Вместо:
я использую раздельные команды выставления адреса и данных:Код:ld (ADDRVI),bc
иКод:SV_RTC:
; Вход: [B]-адрес, [C]-данные
MOV A,B
OUT 51H
MOV A,C
OUT 50H
RET
Но сути это не меняет. Часы работают прекрасно, но загрузке компа мешают. Чую, дело в недостаточной глубине сна ВИ1, и чую требуется какая-то команда усыпления после сеанса связи с ВИ1.Код:LD_RTC:
; Вход: [B]-адрес
; Выход: [A]-данные
MOV A,B
OUT 51H
IN 50H
RET
П.С. или какая-то аппаратная недоработка? Может требуется подтяжка /CE резистором к питанию? Что-то идёт не так в момент включения компа.
b2m, там скорее всего резистор об землю на верхнем входе как раз и стоит для определённости триггера при включении. И у меня явно не случайное состояние, а вполне одинаковое каждый раз - глюк стабильный.
b2m, тогда почему через 20 секунд после выключения питания, при включении триггер себя по-другому ведёт?
На начальное положение триггера много что влияет, в том числе и остаточный заряд на разных элементах. Чтобы исключить неопределённость, в схеме нужно использовать сигнал сброса.
Я исхожу из того, что схема выпущена в свет в чистовом виде, т.е. отлажена и проверена (у меня карта на заказной плате), и разумеется собрана у многих владельцев Ориона-ПРО (платы в "барахолке" покупал не только я) и прекрасно работает с каким-то "родным" авторским ПО. А я тут со своим методом научного тыка пытаюсь понять, как она устроена :)
История получила неожиданное продолжение.
Ткнулся я пробником на /CE ВИ1, а там вот что: при включении питания всегда стабильно "0", т.е. чип часов выбран (и это неправильно!). При любом обращении к ВИ1 сигнал переключается в "1" и остаётся в таком состоянии до выключения питания. Разумеется, в момент обращения к ВИ1 чипселект коротко моргает. Т.е. состояние /CE ВИ1 не зависит от режима включения: с глюком или без.
Заметил ещё интересный момент! Иногда при включении в состояние глюка, на экране отображается покоцаное содержимое, которое было на момент выключения. Т.е. РУ7-ые каким-то чудом "помнят" инфу даже при выключении питания (мультиметром видно, что при выключении напряжение на шинах моментально падает до нуля).
Резюме. Предустановка триггера защиты часов от переходных процессов включения ПРК работает некорректно. Но причина глюка в чём-то другом!
Вот что осталось на экране после 10 секунд обесточивания ПРК:
https://pp.userapi.com/c639117/v6391...Yaqx7GiXX8.jpg
а это ещё раз выключил и включил примерно через 10 сек:
https://pp.userapi.com/c639117/v6391...pMv4QR6abY.jpg
Если не обращаться к ВИ1, то можно хоть моментально выкл-вкл питание, и комп корректно резетится и загружается. Что же за мистика такая?!
П.С. перемычкой J3 отключил прерывания от ВИ1 в схему ПРК - картина не изменилась никак.
У памяти DRAM от старости начался склероз (наоборот):D Проходили на MSX. На работу не влияет.
Проблема в чем-то другом. А подгаживать часы и обвязка могут только на шину данных. Инициализация триггера на рассыпухе стремная.
- - - Добавлено - - -
Там хак программный был. Пять минут не мог компьютер сбросить. Залипло 2 байта. И эти 2 байта не давали машинке стартануть. Больше я ту программу не запускал, хотя похожими пользовался. Со временем видимо отпустило динамическое озу.
Получается, что в момент старта ВИ1 выбрана. Остаётся переходному процессу моргнуть сигналом DS, и часики светанут в ШД компа. Видимо, это и происходит. В итоге старт ПРК идёт под откос (даже заглавная менюшка не появляется).
Мне только странно вот что... допустим оно всё так, но тогда бы часы мешали только в момент старта, а потом бы они "отлипали". Но нет, нажатия на резет не помогают запустить комп. Только выключение питания и ожидание 20+ секунд.
- - - Добавлено - - -
Всё, вопрос решён!
Резистор 1 ком с выв."2" D7.1 на землю. В итоге, при старте ПРК часы во сне (/CE="1") и вышеописанного глюка больше нет.
Что получилось. Триггер на элементах D7.1 и D7.2 при подаче питания находится в неустойчивом состоянии, в итоге куда он "сваливается" - это как карта ляжет (скорость нарастания напряжения на шинах питания, серия микросхемы, паразитные ёмкости платы, фаза Луны... и т.д.). Принудительное притягивание обоих входов (они складываются по "ИЛИ") верхнего плеча перетягивает одеяло в нужную сторону, и вместо неопределённости появляется нужное устойчивое состояние.
Исправленная схема:
http://denn.ru/8bit/orion/pro/rtc_safe_mode.jpg
Полная схема IDE-RTC тут - http://denn.ru/8bit/orion/pro/ide-rtc.jpg
- - - Добавлено - - -
b2m, ну а что, костыли поверх колхоза - вполне вариант ))
Камрады, кому удалось разобраться с интерфейсом IDE на карте IDE-RTC ?
У меня есть в хозяйстве флэшовый 1-гиговый винчестер-затычка в форм-факторе IDE-разъёма:
https://pp.userapi.com/c639618/v6396...c33gBZMyWs.jpg
Он "почти" работает. А именно, утилита "из интернетов" HDDR$ успешно читает в буфер 80 секторов, и считанное похоже на правду:
https://pp.userapi.com/c840130/v8401...hSAXIuNdmM.jpg
Другая утилита HDTST$ успешно отрабатывает все пункты тестов, кроме последнего - "тест поверхности", в процессе которого стабильно происходит затык на секторе #72 и всех последующих:
https://pp.userapi.com/c841230/v8412...2hy81G8Vqk.jpg
Но это не основная беда.
Теперь о грустном. Решил также попробовать подключить "обычный" винчестер, т.е. механический 3,5". Благо в хозяйстве их много всяких, совершенно разной степени свежести (но все исправные и 100% рабочие на писи). Ни один с картой IDE-RTC не работает вообще ("Ошибка IDE = 59")! Утилита HDDR$ виснет наглухо, в тесте HDTST$ затык сразу на первом пункте, который судя по описанию вообще не обращается к диску, а только тестирует регистры самой платы IDE-RTC.
Заметил вот что странное. Картина с неработоспособностью интерфейса полностью аналогичная при воткнутом голом шлейфе в гнездо IDE на плате IDE-RTC! Т.е. совершенно не играет роли есть винчестер на том конце провода или нет, ошибка та же самая. Шлейфов пробовал три штуки: два 40-пиновых и один 80-пиновый, со всеми картина одинаковая, и все они на писи работают прекрасно.
Как я понял, ошибку вызывает сам шлейф, до диска никакие команды не доходят. Диск при подаче питания раскручивается и через некоторое время из-за отсутствия обращений со стороны интерфейса паркует головки и торомзит двигло, на этом всё,с вами был Василий Уткин.
Если бы не работал флэш-вариант диска, то можно было бы предположить какие-то неисправности в плате и что-то искать... но тем не менее, интерфейс вроде как рабочий. Но что не так с механикой?
Дальше ещё интереснее! По аналогичной схемотехнике мой коллега собрал IDE-интерфейс для ПРК "Орион-128" и у него... ровно всё тоже самое! Т.е. фактически аппаратно у него всё другое: разводка платы, дешифрация портов, процессор ВМ80 vs. Z80 (т.е. клок МПС, времянки сигналов и т.п.). Однако точно также: флэшовый "винт" прекрасно работает (читается), а "классика" вообще "не алё".
Предвосхищая вопросы:
1) На всех дисках джамперами выставлено "мастер". Модели и эпохи механических "винтов" разные.
2) Кабель втыкаю правильно (но пробовал и наоборот :) - без разницы). Без воткнутого в гнездо карты шлейфа ошибок нет, они появляются только с этим грёбаным куском провода.
3) Регистры ИР23 серии 1533, буфер АП6 - быстрая КМОП 74HCT245. У коллеги микросхемы на кроватках, он пробовал другие серии микросхем.
Вот даже вообще не представляю куда копать ((
для эксперимента можно попробовать максимально короткий кабель. Ещё, пару лет назад кто-то из форумчан анализировал времянки этой версии ИДЕ, и там было не все хорошо, он же рекомендовал что-то поправить на схеме, но помогало хреново. А полгода или чуть более назад тут появлялся автор схемы (он же автор Ордос6), и во вложении поста клал поправленную схему, обещал прочую отладку схемы и ПО, но пропал
Кабель стандартный, более коротких я не встречал в природе. А у 80-пинового вообще перемежение всех жил земляными, там наводки исключены.
Схемотехника чуть менее, чем полностью взята с ZX-Spectrum, емнип. Стало быть автор должен быть не совсем русский :)
А можно "тыц" на тот пост, плз?
Начинается вот с этого:
http://zx-pk.ru/threads/27178-orion-...l=1#post908920
Я несколько раз списывался с Михаловским. Он отвечал, что подготовил много дискет для размещения на форуме, что у него есть более свежая, по тому времени, версия Ордос-6. Но потом он с форума пропал, а напоминать о себе я больше не стал, чтобы не надоедать.
У меня из десятка жестких дисков нормально определился только один. Я его смог отформатировать, установил на нем Ордос-6. Нормально проходят операции чтения, записи, переименования файлов и т.п.
С остальными дисками тест работает так же.
А вот с установкой Альтаира все проходит на УРА, и именно с этим же контроллером.
Из "механики" я попробовал только три штуки. На десяток меня бы не хватило :)
Вероятно проблема в согласовании линии, которого со стороны карты IDE-RTC попросту нет. Скорее всего нужно ставить в интерфейс микросхемы серии 74ACTxxx плюс резисторы-подтяжки (330..470 ом) с каждой линии на питание.
Я использую кабель 10 см, не помню где взял. На более длинных не пробовал. Но я в-основном с CF работаю.
Вот:
http://zx-pk.ru/threads/25327-perife...l=1#post897811
За эту схему не скажу, но на подобной (Sunrise IDE) схеме косяки определения винтов правили путем установки на линию IOR (IDE интерфейс) конденсатора порядка 100…800 пФ.
После доработки "строб TRD сигналом RD" появился намёк на чтение данных с механики:
https://pp.userapi.com/c639328/v6393...R8ptBB-U4g.jpg
Но голый кабель по-прежнему продолжает портить запись в регистры.
Уже написали прицельный тест, который показывает, что в регистр записано FFh, а по факту тут же считано E7h.
Соответственно, порча также накладывается и на читаемые данные ((
Похоже, нужен всё таки нормальный лайн-драйвер, чтобы прокачать кабель.
П.С. доработку сделал коллега на своём О-128, я доберусь с паяльником до своей ПРОшки не раньше выходных.