- RTC
- [+] Старые сообщения (24)
-
? anonymous - 03.06.2009 12:15
Terra, дешифратор в обеих схемах-то одинаково прост, зато у Kisser слишком много обвязки для разнесения циклов установки адреса и обращений к данным, что эти цепи надо выкинуть, я ему уже говорил выше. Однако ваша схема не будет работать ни при установке 10го бейсика, ни с мстд, да и IRQ3 (0270) процессора как правило занят чем-либо еще. В самом начале обсуждения, мы начали тред именно с разбора такой схемы, но отказались от ее реализации из-за ее неоправданной ресурсоемкости, да и неуклюжести, не допускающей апгрейда процессора на старшие модели. Также, кто обладает старой схемой scsi от NCR, напорятся на конфликт, он сидел со 0177000 тоже, дефайны из bshdr.inc:
s$db1 =177000 ;data reg1
s$cmd =177002 ;command
s$ctrl=177004 ;control
s$dst =177006 ;destination
s$stat=177010 ;auxiliary status
s$idn =177012 ;own ID
s$intc=177014 ;interrupt
s$src =177016 ;source
s$db2 =177020 ;data reg2
s$diag=177022 ;diagnostic
s$syr1=177024 ;sync control, reserved by NCR
s$syr2=177026 ;offset control, reserved by NCR
s$cnt3=177030 ;counter 3
s$cnt2=177032 ;counter 2
s$cnt1=177034 ;counter 1
s$ibcm=177036 ;test, reserved by NCR
s$csr =177040 ;csr
s$db3 =177042 ;data reg3
s$apr1=177044 ;address pointer
s$apr2=177046 ;address pointer
-
? Kisser - 03.06.2009 12:42
Собственно я тоже и хотел написать, хотя схему так и не просмотрел (файлы на Бк надо открывать, да?) Но из программ обслуживания вытекает, что адресное пространнство RTC внесено в общее пространство БК, что было раскритиковано anonymous'ом в самом начале. Естественно, что дешифратор на такую версию будет проще, особенно если использовать сигнал ВУ в БК11. И еще прерывание пока никуда не сажал. Оно мне пока не нужно.
Замечания я все понял, схему почти сделал, единственное что я не стал затягивать DOUT для записи адреса, а разнес адрес и данные на 9й и 10й бит соттветственно, чтобы не морочится и не привязываться к таймингам. В выходные постараюсь опробывать.
-
? Terra@ - 03.06.2009 15:02
Да файлы для БК. Да я понимаю, что адреса не совсем удачные, но про scsi вообще 1 раз здесь услышал. А по поводу прерывания, то этот вектор практически ни в каких программах не используеться.
-
? anonymous - 03.06.2009 15:21
Ну, все, что вешают на порт УП в 11й машине использует этот вектор, куча же всяких DAC/ADC, программируемых устройств, которым нужно прерывание. Да и печать по прерыванию гораздо удобнее, не отрывает от работы с текущими программами, печатая в фоне. А с NCRовского scsi я сам на другой, компактный, контроллер на базе 33c93 перешел давно, который всего 4 адреса занимает и работает на более высоком уровне, за счет более умной прошивки в mcu контроллера, драйвер его в разы короче.
-
? Kisser - 04.06.2009 15:55
Не стал ждать выходных, вот, сваял:
http://s53.radikal.ru/i140/0906/7e/78999c764858.gif
А не работает как нужно. А именно запись не происходит. Т.е. если выбирать ячейку, записывать в нее значение, потом сразу без изменения адреса читать - все работает, но стоит адрес поменять или дать тот же, значение остается старым. Что за фигня? Импульсы на WR идут. Думал, может в конце цикла записи нужно все-таки CS поднимать, но, принудетельно подаю "1" на него, никаких изменений.
А ведь работало все...
-
? anonymous - 04.06.2009 20:18
Сложно сказать, должно работать. Попробуйте dout затянуть, ведь когда он выставляется, на шине еще только меняется адрес на данные, а в адресе в обоих служебных разрядах нули. И странно выглядит объединение входа очистки и записи в регистр, там по-хорошему надо задержку между ними ввести на неинвертирующем логическом элементе, чтоб фронт приходил, когда сброс ушел уже.
-
? Kisser - 04.06.2009 21:33
Да выбор адреса то нормально работает, хотя попробую конечно. И по описанию м/с запись и чтение происходят по нарастающему фронту, так же как и в БК. И вообще не менялся же алгоритм, мож сами часы накрылись? Ведь он записывает данные кудато в регистр свой, но почему-то до памяти они не доходят.
Может ему на запись RPLY затянуть, хотя опять же по описанию длительность импульса записи 125 нс, что в 2 раза меньше периода такта при 4 мГц.
-
? anonymous - 04.06.2009 21:41
Я имел в виду то, что пишется не в тот адрес, который указываете.
-
? Kisser - 05.06.2009 16:10
Я понял о чем Вы говорите, не сообразил сразу! Правда тогда записывалось бы одно и то же значение видимо, а тут разные. А тогда такой вопрос - а между установкой "0" адреса и "0" данных есть ли промежуток с "1"? И если нет, то на какое время затягивать ДОУТ? По тактам или просто в нс.
-
? anonymous - 05.06.2009 20:55
У меня домя ОСТ на 1801, приеду - посмотрю времянку, тогда скажу на сколько задерживать. А промежуточных стейтов между адресом и данными нет, насколько мне известно.
-
? anonymous - 06.06.2009 00:52
Из datasheet на ВМ1: SYNC пассивен в течении 200нс, затем выставляются BSY и адрес, через 150нс SYNC падает, но адрес держится еще 100нс, при этом DIN/DOUT выставляются после SYNC через 50-80нс (так указано в таблице - очевидно по готовности микропрограммы, а не по тактовой!), т.е. в течении 20..50нс адрес захватывает DOUT.
-
? anonymous - 06.06.2009 01:59
А, забыл сказать, времена даны для стандартной тактовой - 5МГц, т.е. в БК, с более низкой, 3 для 0010 и 4 для 11й, надо запас брать.
-
? Kisser - 06.06.2009 17:49
Сделал.
http://s56.radikal.ru/i154/0906/45/bea2fc507bd1.gif
Не знаю, как Вы посмотрите на такое решение, но, кажется, оно наиболее оптимально. Во всяком случае, определяет, когда адрес снялся. + дополнительные элементы добавляют задержку. Зато наступила проблема с четнием, тогда я перекинул для RPLY c DINа на RD часов, тоже какая-никакая задержка добавилась.
Теперь правда для записи адреса нужно устанавливать 10й бит, а для данных - 9й, ну да и пофиг. Правда, видимо с отсутствием CSа есть глюк - при частом обращении (написал программку для отображения часов, которая тупо выводит значения регистров часов на экран) значения сбиваются, устранилось установкой 255го несуществующего адреса после каждого обращения к часам.
И есть еще один глюк. примерно раз в 20-30 сек в значениях проскакивает "7". Видимо не всегда чтение успевает, но это, думаю, не будет проблемой, поскольку такие жестокие обращания к часам не планируются. В крайнем случае затянуть DIN.
Но, будем считать, что часы подключились )))
-
? a214 - 29.07.2009 12:34
Наиболее простой вариант (к тому же не требующий лазания внутрь БК) - подключать все дополнительные устроства через порт вв/выв 177714 (для этого он и предназначен). Подключение RTC КР512ВИ1 - RG 8х к мл разряду вых-порта, выходы RG к шине A/D RTC и параллельно к мл разряду вх-порта. Выход прерывания от RTC (если он нужен) - естественно на вход прерывания по таймеру (вектор 100) - вход есть на разъеме. Все управляющие сигналы формируются програмно в соответствии с логикой работы RG(C,CS)+RTC(...) и подаются по ст разряду вых-порта.
Александр - Минск: a214@tut.by
-
? Kisser - 29.07.2009 20:44
А вот нравится лазить внутрь, что поделать...
У порта 177714 и так куча разных устройств висит, от джойстика до музсопроцессора. А так часы входят в адресное пространство БК и никому не мешают.
-
? а214 - 03.08.2009 08:44
Любопытно было почитать о месячной эпопее по подключению RTC - я попал уже на финал.
Конечно личное дело каждого иметь или не иметь кучку д...ополнительных элементов на ''соплях'' внутри БК - наверное это выглядит более круто чем аккуратно распаянные на небольшой макетке доп устройства через порт БК - в данном случае нужен был всего лишь один буферный регистр с третьим сост на выходе и сама RTC.
А еще что-нибуть подключить? Будет вообще красота.
-
? Kisser - 03.08.2009 15:53
Часы и были собраны на макетке, и втыкались в порт. Только не УП а МПИ. И БК не пострадала никоем боком. СОбственно вообще не вижу предмета для спора - хорошо что хоть ктото еще ХОТЬ ЧТОТО делает для БК, посему предлагаю както объединять усилия.
-
? a214 - 03.08.2009 18:46
Да, я тоже за координацию усилий по доработке еще "живых" БК.
При этом считаю, что задачей требующей первоочередного воплощения в железе и ПО является "человеческое" устройство хранения программ - никто уже не будет собирать какие-то навороченные-замороченные контроллеры FDD,HDD - это давно ни к чему.
В нашем случае не вижу реальной альтернативы мс EEPROM I2C, SPI.
Кого это интересует приглашаю в новую тему "БК-0010 + EEPROM"
-
? anonymous - 04.08.2010 18:27
Тут в клубе московском, что в Текстильщиках, часики в ДВК и УКНЦ захотелось народу, потому что каждый раз вводить дату и время при частых перезагрузках утомляет, прицепили DS1302, для работы требуется порт с 3 разрядами на запись и одним на чтение, программка установки системых даты и времени под RT11 v5.7 "на коленке" написанная вот такая вышла простенькая http://narod.ru/disk/23419338000/td3.mac.html
От PC часики цеплять поленились из-за неоправданного усложнения схемы.
-
? Игорь@ - 16.11.2011 11:48
Помогите найти схему динамического ОЗУ на базе мпк к1801. Или микро эвм в целом на этой базе,там уже вырежу DRAM.На мыло если что вышлите. (immitatorcrus@mail.ru) Заранее спасибо.
-
? anonymous - 16.11.2011 12:43
Игорь, вы темой ошиблись, эта ветка про RTC - Real Time Clock.
Касательно ОЗУ - какое динамическое вам надо? Реализаций на/для 1801 довольно много, в самой серии только не менее 4х контроллеров, под каждый из процессоров семейства - свой.
- << Форум
