dmtr, они хотят уменьшить количество прерываний, их там достаточно, а дальнейшее увеличение может привести к уменьшению производительности
Вид для печати
dmtr, они хотят уменьшить количество прерываний, их там достаточно, а дальнейшее увеличение может привести к уменьшению производительности
Владислав, подумай еще раз :)Цитата:
Сообщение от pvlad
У нас есть кнопки 14 и E014, 72 и E072 и так далее. Для контроля отпускания мы не можем обойтись только двумя байтами.
Извини, очепятка :)Цитата:
Сообщение от pvlad
Т.е. думать в этом направлении - сигнализировать битами в комплекте с основным сканкодом, одно прерывание?Цитата:
Сообщение от pvlad
Я описывал работу контроллера парой постов выше. Мне проще упростить жизнь драйверу, чем гнать ему побайтово все данные.Цитата:
Сообщение от dmtr
---------- Post added at 13:13 ---------- Previous post was at 13:12 ----------
ага. Я вообще прерываний побаиваюсь, оставил бы только INT50 для игрушек и часов :)Цитата:
Сообщение от osa
---------- Post added at 13:30 ---------- Previous post was at 13:13 ----------
Ээээ.... Лучше сделать так:Цитата:
Сообщение от pvlad
F8 - переключение "мониторов" с одновременным сбросом.
F9 - переключение страниц РОМдиска
F10 - режим 2.5Мгц
F11 - режим турбо 5Мгц (по умолчанию)
F12 - режим супертурбо 10Мгц
Scroll Lock - сброс
С точки зрения построения алгоритма драйвера, проблем, вроде бы, не вижу. Действо будет происходить по нажатию клавиши. Контроль за F0 нам нужен только для того, чтобы это прерывание пропустить (а что обрабатывать? Пока не представляю!) - отпустили клавишу, ну и черт с ней! А вот Е0 - это очень важный флаг: 14 - это левый CTRL, а Е0+14 - это правый CTRL.Цитата:
Сообщение от Ewgeny7
Структурно, драйверная система будет выглядеть так: п/п KBRD (F803) проверяет всего-лишь ячейку. Если в ней 00(или FF?) - значит нет нажатой клавиши. Тоже относится и к п/п INKEY. А вся "кухня" с прерыванием будет вариться внутри и раскладывать результат по ячейкам.
Старые драйвера Ориона обрабатывали ситуацию одновременного нажатия нескольких клавиш, как защиту, а не полезную последовательность. С новым драйвером мы можем (если это будет актуальным - дождемся реакции Сергея!) сделать "новый" вектор, где все нажатия будут заноситься в буфер, а уж программа должна сама разгребать ситуацию.
Да! Иначе утонем в прерываниях. Z80 - это не AVR, где мощный и хорошо продуманный механизм прерываний. Только все равно придется сделать еще один порт, где можно будет читать эти флаги. И еще, грамотно расставить флаги на биты, чтобы было проще программно анализировать. Может быть на D7 и D0 - тогда можно анализировать через перенос. Что скажет Сергей? Я плохо владею командами Z80 - так уж исторически получилось.Цитата:
Сообщение от Ewgeny7
К примеру, в микроконтроллерах без них нечего делать. Поэтому, в нашем случае, все зависит от того, как сделан сам контроллер прерываний, насколько грамотно расставлены приоритеты прерываний. Не исключено, что еще придется выуживать его прорехи и недостатки. А сами по себе прерывания - это прекрасный механизм!. Кроме того, одновременно работать, практически постоянно, будут два прерывания: INT50 и PS/2. Понятно, что INT50 будет бесцеремонно вмешиваться (будут вложения и совпадения) в PS/2. Здесь надо проанализировать (кроме тебя, Евгений, - никто!) "схемотехнику" контроллера, чтобы не пропадали прерывания PS/2 при совпадении с INT50. Конечно, INT50 должен иметь самый высокий приоритет - иначе грош ему цена, как датчику реального времени.Цитата:
Сообщение от Ewgeny7
---------- Post added at 14:27 ---------- Previous post was at 14:17 ----------
Это можно дублировать в порту 4F!Цитата:
Сообщение от Ewgeny7
Приоритеты -
if eoc='1' then //RS-232, высший приоритет
vector<="11111101";
elsif (int_keyb='1' and int_buf='0') then //PS2, средний приоритет
vector<="11111011";
elsif (interr='1' and int_buf='0' and int_keyb='0') then //INT50, низший приоритет.
vector<="11111111";
end if;
У меня абсолютно другое мнение. Потеря прерывания по INT50 совершенно не страшна (1/50 секунды погоды не сделает), потеря нажатия клавиши куда как неприятнее, а потеря байта по USART вообще недопустима.Цитата:
Сообщение от pvlad
Это уже ваше дело. Только ИМХО команда BIT N,a куда как проще чем возиться со сдвигами, а какой бит проверять - ей все равно.Цитата:
Сообщение от pvlad
Т.е. факт отпускания клавиши вам вообще не интересен? Странный подход...Цитата:
Сообщение от pvlad
Я так думал, что вы будете вести в драйвере что-то вроде таблички на 6 байт, где прописаны нажатые в данный момент клавиши. И факт отпускания кнопки нужен для удаления символа из таблицы. А как вы мыслите это?
---------- Post added at 14:37 ---------- Previous post was at 14:36 ----------
Можно. А зачем???Цитата:
Сообщение от pvlad
хм... тогда может так случиться что часы будут отставать очень сильно(500-200 раз по 1/50с это 10-4с.)Цитата:
Сообщение от Ewgeny7
Думаю, ты прав только отчасти, со своей "колокольни".Цитата:
Сообщение от Ewgeny7
Смотрим М.Гук "Аппаратные средства IBM PC" 2-е изд., стр. 240. В порядке последовательной очередности: INT02-немаск.прерывание, INT08-таймер, INT09-клавиатура и т.д. USART - вообще не имеет своего собственного прерывания и внесен в общую таблицу распределения прерываний.
Что у нас? Если рассматривать работу в реальном масштабе времени, то INT50 - самый важный вектор. Кроме того, по этому вектору можно обрабатывать много чего, в том числе и клавиатуру, если не срастется с PS/2. Далее, должна идти клавиатура PS/2 - естественно необходима возможность безоговорочно вмешиваться в ситуацию. А вот при работе USART можно все остальное отключить, если будут глюки. И то, если будет использоваться синхронная передача. При асинхронной, пакетной с подтверждением (а еще как для надежности!?), то это уже не имеет большого значения. Можно повторить передачу последнего сбойного пакета. То, что придумано в настоящий момент для передачи файлов по USART - это временное явление по бедности, но не предел необходимого. Думаю у кого-то дойдут руки и будут сделаны нормальные программы для передачи файлов.
Кроме того, еще раз подчеркиваю: потеряно/не потеряно прерывание всецело зависит от схемотехники контроллера прерываний. От приоритета - только очередность обработки. И не более! Так что, Евгений, все в твоих руках!
Вести, конечно будем. Но даже в ПС, если ты нажал клавишу, то отменить на нее реакцию уже не возможно - даже если ты ее и отпустил! Она все равно будет записана в буфер, и программа, анализируя, выполнит то что эта клавиша предписала. Поэтому для системных п/п работы с клавиатурой, факт отпускания клавиши мало значим, и необходим, чтобы сортировать прерывания. А вот прикладные программы могут изгаляться с фактом отпускания клавиши, как им заблагорассудится!Цитата:
Сообщение от Ewgeny7
Не "можно", а нужно!Цитата:
Сообщение от Ewgeny7
1. Вот здесь http://zx.pk.ru/showpost.php?p=300150&postcount=279 в последнем абзаце "P.S. Порты..." я это объяснил.
2. Сергей мечтал (а ты ему это обещал!) уходя в СРМ включать максимальную "скорость". Он что, тоже обязан будет нажимать только клавишу F12? Автоматически (по своему желанию выбирать частоту) это сделать будет не возможно?
3. Это так сложно сделать, чтобы нажимая клавиши "Fx" автоматически менялись флаги в 4F? А при включении питания устанавливалась в РОМ-диске страница 00 и частота 2,5 Мгц. Думаю нет!
Делать часы на этом прерывании - это бутафория. Для часов применяют спец.микросхемы.Цитата:
Сообщение от osa
---------- Post added at 16:17 ---------- Previous post was at 16:03 ----------
Кроме всего прочего, не забывайте, что программы написанные для Ориона по своей логике не учитывают наличие прерываний. Они чисто программно обращаются (когда им нужно!) к клавиатуре. Поэтому, применение клавиатуры с прерыванием, при вводе символов, ничего внешне не изменит в поведении того же редактора текста. Поэтому можно будет нажать несколько клавиш (в это время редактор что выполняет свое!), а используемой окажется последняя клавиша, которую он заметил, обратившись к п/п клавиатуры.Цитата:
Сообщение от pvlad
Реальный эффект (со старыми программами) можно будет увидеть только при нажатии управляющих комбинаций клавиш. Например CTRL+ALT+DEL (будем надеяться, что удастся воплотить!) и... Орион, плюнув на все, ушел на перезагрузку, даже если он при этом и "висел"!
Ну, то что сейчас сделано в плане пакетной передачи - ахтунг полнейший. Повторов много, бывало даже что файл не проходил. При обычной побайтовой передаче все идет без ошибок :)Цитата:
Сообщение от pvlad
Дык пожалуйста. Давали бы изначально четкие инструкции...Цитата:
Сообщение от pvlad
Прерывания будут теряться при одновременной активности сигналов. Лепить настоящий мегаконтроллер я не буду.Цитата:
Сообщение от pvlad
Хорошо, сделаю.Цитата:
Сообщение от pvlad
Не особо он и мечтал. А сделать это можно за полминуты. У меня изначально так и было, потом убрал перед релизом.Цитата:
Сообщение от pvlad
Не забываем, что большая и лучшая часть ПО - со спектрума. Прерывания им необходимы. Софт СР/М-й также подразумеваю что был бы не прочь попользоваться прерываниями.Цитата:
Сообщение от pvlad
Владислав, вы как-то упускаете из виду что программам (особенно игровым) требуется знать - нажата кнопка или уже отпущена. Сколько кнопок нажато, в какой последовательности они отпущены... В РК-клавиатуре это прекрасно видно по состоянию матрицы, здесь же матрицы не будет. Поэтому с PS2 нужно иметь хотя бы табличку на несколько кнопок и в реалтайме держать там сведения о клавиатуре.Цитата:
Сообщение от pvlad
Версия 1_08.
Порт 4F.
Помимо описанных битов D0-D2 (конфигурация памяти) и D7 (разрешене ROM_WE) добавлено:
D4..D3 - ROM_SEG (страницы ROM-диска)
D6..D5 - скорость процессора. 00 - 5Мгц, 01 - 10Мгц, 10 - 2,5Мгц.
В целях безопасности - биты 0..2 и 7 записываются только как порт 4F, прочие биты записываются и как порт 4F, и как ячейка F767. Забавно рулить скоростью и РОМдиском из Монитора :)
Прочитать содержимое порта можно и как порт 4F, и как ячейка F767.
При этом считываются не записанные когда-то данные, а реальные на данный момент.
Обновлен мануал по Ориону.
Значит есть проблема. Надо будет разруливать. Просто все сразу не осилить - придет время и дойдут руки. А сейчас, пока, пусть будет так.Цитата:
Сообщение от Ewgeny7
Ну, в какой-то момент ты все переделаешь то, что сейчас планируем. Потом тебе станет скучно от "безделья", и ... зачешутся руки сделать что-то "мега". Просто надо подождать твое вдохновение! И не более!Цитата:
Сообщение от Ewgeny7
Давай, пока, оставим как есть с прерываниями и приоритетами, а там посмотрим. Еще ничего руками не потрогали.Цитата:
Сообщение от Ewgeny7
Разве мы убираем порт F40х, где реализована матрица? Собственно, игрушкам она и нужна, а не п/п обработки клавиатуры. Кроме того, что мешает подгрузить "старый" Монитор для "любимой" игрушки?Цитата:
Сообщение от Ewgeny7
---------- Post added at 23:16 ---------- Previous post was at 22:49 ----------
Ну, наконец! Бандероль уже в Москве. День-два и будет у меня! До твоего возвращения что-либо перепрошивать не буду - повожусь с тем что есть, по соображаю!
Ну слава Ктулху! :)Цитата:
Сообщение от pvlad
Думаю, что лучше будет как раз прошить 1,08. И для тренировки, и заодно прошивка поинтересней (и в теории - надежней, видеогенератор переделан) :). Только учти, что в ней вместо монитора М37 стоит М34.Цитата:
Сообщение от pvlad
Кстати, негласный тест на косяки в железе (я обязательно делаю) - в М256 делаем DUMP F600. На всём поле дампа должно быть FF. Если иначе - конфликтуют сигналы на шинах. Залив новую версию прошивки, лучше не полениться и проверить дамп.
Ну ладно, мои контраргументы закончились. Тогда подтверждай:Цитата:
Сообщение от pvlad
1. Сигнал прерывания возникает ТОЛЬКО при нажатии кнопки на клавиатуре.
2. Контроллер отправляет драйверу сканкод кнопки + префикс E0 если он есть.
3. Отпускание кнопки никак не передается драйверу.
4. префикс Е0 передается как байт в новом порту (или "1" в старшем разряде сканкода, для экономии?).
Выносите вердикт. И в будущем желательно получать такие же четкие инструкции от вас с Сергеем :)
Мммм... маловероятно, конечно... За последние два года я напрочь забыл слово "скука" :)Цитата:
Сообщение от pvlad
Только из текущих проектов у меня помимо Ориона еще и ScorpEvo. И поддержка еще парочки готовых, модезверствование на половине форума и помощь в чужих проблемах :v2_devil: 24 часов в сутках не хватает :v2_slee2:
Но всё может быть.
---------- Post added 19.07.2010 at 00:06 ---------- Previous post was 18.07.2010 at 23:58 ----------
Тонко так намекну, что существующие модели USART на ПЛИС должны иметь ошибки в работе если не принять специальных мер (типа специального кварца на 11.0592 Мгц). На скорости 20Мгц разумеется, делается коррекция, но при пакетной передаче вероятность ошибки должна накапливаться и "прорываться". При побайтовой передаче приемник и передатчик каждый раз синхронизируются заново, потому ошибки и не возникают. Я не спец в этом, но вроде это так.Цитата:
Сообщение от pvlad
там передача всегда побайтово, для каждого байта отправляется СТАРТ-ДАННЫЕ-(ЧЕТНОСТЬ)-СТОП. Ошибки возникают из-за того что приемник и передатчик не синхронизированны одним сигналом, для того чтоб небыло ошибок тактовые частоты приемника и передатчика должны быть строго одинаковы, тут "как бы" есть два генератора синхросигналов, у приемника и передатчика свой, но оба они "начинают работать" по выдаче/приему СТАРТ бита, и если их частоты различаются то и появляется вероятность того что какойто бит будет пропущен или защелкнут дважды...Цитата:
Сообщение от Ewgeny7
Keeper, я имею ввиду, что для передачи десятка бит разница в тактовых частотах может быть значительной (относительно). Но при передаче по протоколу это уже недопустимо. Я видел где-то табличку с расчетом процентов на ошибку в зависимости от кварца. Так там 0% давался лишь для упомянутого мною 11.0592.
На 99% уверен что в даташыте на AVRки :) Например для ATmega8515 со страницы 160. Раздел называется USART > Examples of Baud Rate SettingЦитата:
Сообщение от Ewgeny7
Друг ты мой сердешный! Мы, что идем на второй круг?Цитата:
Сообщение от Ewgeny7
Ты уже все сам предложил ранее:
Сообщение от Ewgeny7
Предлагаю все же не лохматить бабушку, а сигнализировать просто битами.
если принять -
00 - 00
E0 - 01
F0 - 10
- то нам понадобится всего два бита для полной передачи информации драйверу.
Т.е. драйвер получит сам сканкод 14, а также два бита установленных в единицу (префикс E0 есть, префикс F0 есть).
Ёжики поймут, что отпущен правый CTRL.
Уточню:
1. прерывание по нажатию и отпусканию.
2. читаем два байта: сканкод+флаги
2.1 при нажатии клавиши получаем сканкод+флаг 00 или 01 (E0)
2.2 при отпускании клавиши получаем сканкод+флаг 10 (F0)
3. с адресами портов ты собирался разобраться сам!
4. у клавиатуры должны быть два порта: один для сканкода, второй - для флагов!
Следующее:
1. расставить приоритеты прерываний:
PS/2 - самый высокий (не уверен, что должен быть самый высокий - посмотрим)
Int50 - средний
USART- низший
2. поправь файл "Arhitektura_Orion-2010". Он изрядно устарел.
P.S. Что вдруг случилось, что ты перешел на "ВЫ"?
Внес исправления!
Думаю, только прерыванием по нажатию (без отображения отпускания клавиши) мы не обойдемся. Даже примитивному CP/M-овскому или Мониторовскому драйверу клавиатуры (на прерываниях, а не на матрице), не возвращающему пользователю статус одновременно нажатых кнопок, для своей внутренней логики отпускание обязательно надо отслеживать. Иначе как он узнает и обработает комбинацию "функциональная кнопка + символьная кнопка". Например, получив статус нажатия "клавиш регистров" (Ctrl, Alt, Shift) при последующем прерывании вида "символьная кнопка" драйверу нужно надежно знать - нажаты "клавиши регистров" до сих пор или уже отпущены. И в зависимости от этого добавлять смещение к коду, возвращаемому драйвером пользователю, или не добавлять.Цитата:
Сообщение от pvlad
Т.е. вариантов два: или делать анализ отпускания, или писать драйвер так чтобы от работал гибридно (т.е. несистемно) - и прерывания обрабатывал бы, и в в порт F402 лазал бы за состоянием Ctrl, Рус\Lat, Shift. С другой стороны, из F402 кроме трех функциональных кнопок нельзя прочитать Alt, и много еще чего.
---------- Post added at 12:07 ---------- Previous post was at 12:04 ----------
Цитата:
Сообщение от pvlad
Я поторопился с ответом (или долго набирал? :) как посмотреть), можно было не набирать вышеприведенное. :)
В целом, выглядит достаточно удобно.
Ага :)Цитата:
Сообщение от pvlad
Просто мне переделывать еще раз не хочется. Я предложил - ты вроде как не против.
Раз не против, уточняю уже детали реализации. тем более, что расхождения снова появились:
Цитата:
Сообщение от pvlad
Цитата:
Сообщение от pvlad
Не понял... Я его вчера редактировал.Цитата:
Сообщение от pvlad
"вы" с Сергеем :)Цитата:
Сообщение от pvlad
Поправил 294.
Обновление 1.09. Клавиатурное.
Изменения в портах.
Ногами сильно не пинайте, после отпуска номера скорректируем.
Сейчас:
10..12 - F400..F402
20..22 - F500..F502
40..4F - F760..F76F
Изменения вызваны необходимостью расширить порты F76x без усложнения дешифраторов.
Порт конфигурации 4F теперь соответственно называется 47.
Порт чтения сканкода - F768 (48) - сканкод клавиши
Порт чтения префикса - F769 (49) - префикс 00, E0, F0.
при нажатии префикс равен соответственно 00 или Е0. При отпускании - F0.
Включение прерывания PS/2 как и ранее, запись в D6 порта F766 (46). Надеюсь, работает.
Извините, что вмешиваюсь, есть предложение по поводу клавиатуры.
Я думаю, что правильнее всего будет сделать FIFO-буфер, в который последовательно записываются генерируемые клавиатурой коды, вместе с префиксами и суффиксами. При поступлении первых данных в буфер генерируем прерывание, а соответствующий вектор должен будет эти скан-коды обработать (конечный автомат с таблицей перекодировки клавиш) и отдать остальным потребителям.
Обработчик прерывания работает до тех пор, пока не извлечет все данные из буфера, т.е. если в процессе обработки скан-кодов поступят новые, то обработчик должен будет дочитать и их, но дополнительного прерывания от клавиатуры естественно не выставится.
В этом случае нам потребуется один 8-разрядный порт в адресном пространстве и биты состояния FIFO - пустой или переполнение.
Конечно, подобный алгоритм имеет право на жизнь. Но это перечеркивает все, что до этого было сделано. Вы беретесь помогать:Цитата:
Сообщение от aviator
1. Переписать значительную часть алгоритма, обрабатывающего PS/2 в Альтере (используется готовая библиотека открытого кода). Кроме того изыскать ресурсы ПЛИС на создание FIFO-буфера и автомата, управляющего им. Не нужно забывать, что ПЛИС - это всего-лишь схемотехника и этот автомат придется собирать на "вентилях и триггерах".
2. Переделать контроллер прерываний (так же используется готовая библиотека открытого кода). Проблемы те же -переделывать схемотехнику, и все это связывать воедино.
Что выигрываем, кардинально?
Один порт в адресном пространстве? (у нас, что катастрофический недостаток адресного пространства для портов?)
Что еще? Только существенного, кроме новой идеи!?
Нет секрета в том, что данный проект держится на опыте и знаниях ПЛИС Ewgeny7. Он очень способный, но не Господь (прости, что в суе)! Проект постепенно улучшается, по мере накопления им знаний и опыта. И с этим приходится считаться. Кроме того, и с его бескорыстием для всех. Возможно придет время, и он согласится воплотить Ваше предложение. Но, кроме этого, надо, чтобы кто-то еще написал драйвер клавиатуры под ваш алгоритм работы PS/2. Вы за это беретесь?
У нас, знаете-ли, существует негласное правило: идеи предлагаются, пока есть не решенная проблема. А когда она решена, то ее замена на новую идею - только с предложением реального собственного участия. А мы будем помогать, если ваша идея лучше. Все исходники выкладываются, поэтому нет проблем с участием и переделкой какого-то узла "Ориона-2010".
И последнее. Я совсем не ставил цель Вас обидеть, и был бы рад (и все мы вместе!), если Вы активно подключитесь к нашему проекту.
Я это понимаю, поэтому ни в коем случае не навязываю и не требую к исполнению.Цитата:
Сообщение от pvlad
Выигрываем всего лишь то, что уменьшаем количество клавиатурных прерываний и можем использовать все сканкоды, генерируемые клавиатурой.Цитата:
Сообщение от pvlad
Вот, ключевое слово "придет время". Ни в коем случае не ломать уже сделанное. А соответствующие вектора монитора и обработчик прерывания написать конечно могу, только надо вспомнить ассемблер 8080, ибо сейчас все x86 да ARM...Цитата:
Сообщение от pvlad
Да я не обидчивый. :) Просто на данном этапе я только могу запустить проект Ориона-2010 разве что в ModelSim-е или в подобном ему. В нашей "деревне на 400 тысяч душ" даже самой завалящей альтеры не найдешь, не говоря уж о специализированных кристаллах. Сам думал заказать печатку по схеме Евгения, но потом понял, что комплектацию я буду ждать еще пол года от наших барыг. :(Цитата:
Сообщение от pvlad
После 2 августа должен появиться Евгений. Поговорите с ним - возможно он согласится, на каких-то условиях, помочь Вам с комплектовкой.Цитата:
Сообщение от aviator
Комплектовка пока отдыхает. Для основных позиций нужен заказ от 3 штук. Будет трое (или более) собирающих, тогда - другой разговор.
-------------------------------------------------------------
Здравствуйте снова! :) Я приплыло в родной Петербург.
Гидэ отчеты от Сергея? Доехала посылка вообще, и что там с ней?
pvlad, спасибо за краткие отзывы :)
Насчет разъема RS-232 - я специально искал именно "папы", ибо так написано было в спецификации с комплектующими. Кроме того, нуль-модемный кабель как раз должен быть с двумя "мамами" на концах.
Насчет сохранения в ОРДОСе ты прав, я как-то относительно недавно пинал Сергея на предмет "сохранялки" на SD.
aviator, делайте на здоровье, исходники открыты :)
Я в отпуске на море до 16-го. :) На момент отъезда посылка еще не доехала :(
Посылко была отправлена первым классом, однако...Цитата:
Сообщение от Error404
Послеотпускной апдейт проекта - версия 1.10. Полноценно задействуется вся клавиатура, цифровое поле работает именно как цифровое поле (а не дублер курсорных кнопок).
Маленький трик проекта - давно заметил, что при подключенном байтбластере содержимое ОЗУ не сбрасывается при выключении питания Ориона. Замерил напряжение на шине питания (3.3в) при этом - 1,05 вольт.
Вот вам и РАМдиск бесплатный :)
Подключаем батарейку-таблетку 1.5 вольта через диодик на шину питания 3.3в. При выключении питания наше статическое ОЗУ прекрасно сохранит свои данные, при этом прочие чипы будут теоретически "заперты" и ток потребления будет малый.
Надо проверить это как следует...
Я очень рад, что ты снова на боевом посту. На форуме была тишина и... тоска.Цитата:
Сообщение от Ewgeny7
А меня только 9-го обещали выписать из больницы. Хорошо, что есть Интернет, а то от тоски можно повеситься. Свои обязательства по посылке помню. О работоспособности платы 001 - докладывал!
Не в обиду. А если на заборе будет написано "..." - тоже верить. Думаю, Алексей не задумываясь поставил элемент, который подходит по посадочному месту и габаритам. И он прав. А что распаивается: "папа" или "мама" - определяет Главный конструктор.Цитата:
Сообщение от Ewgeny7
А вот это, как догму, подтвердить не могу. За свою жизнь, я только один раз (и то в 90-х) видел нуль-модемный кабель, с двумя "мамами" на концах, в комплекте с каким-то модемом. Думаю, фирма сгородила отсебятину. А вообще все СОМ-кабели "папа-мама".Цитата:
Сообщение от Ewgeny7
Это вероятно обычные "СОМ-удлинители". Расчет делался на нуль-модем с "перекрученными" Tx и Rx. Как вариант, можно было сделать и папа-мама с "прямыми" сигналами, но тогда на плате нужно было поменять местами сигналы на контактах 2 и 3. А это уже прерогатива "разводящего". Но все-таки, это "колхоз", ИМХО.Цитата:
Сообщение от pvlad
---------- Post added at 14:29 ---------- Previous post was at 14:27 ----------
Я тоже готовлюсь... Позвоночник задолбал уже, буду пару недель на стационаре. Когда - еще не знаю.Цитата:
Сообщение от pvlad
---------- Post added at 14:35 ---------- Previous post was at 14:29 ----------
Отправил запрос в ЭФО на три комплекта ПЛИС+конфПЗУ+ОЗУ. В наличии нет, заказ - месяц. На всякий случай запросил точную цену. Устроит - буду заказывать.Цитата:
Сообщение от Ewgeny7
Это в замыслах? Или уже есть?Цитата:
Сообщение от Ewgeny7
Это конечно хорошо по бедности, но как ты говоришь: "колхоз ИМХО"!Цитата:
Сообщение от Ewgeny7
Мне это очень знакомо. Собрат по несчастью! Сидишь помногу и малоподвижно. Не исключено, что на табуретке и без спинки. Теперь спасать может только широкий пояс. У меня внутри он еще выложен собачьей шерстью. Конечно дискомфортно и колется, но зато жить можно!Цитата:
Сообщение от Ewgeny7
Уже есть. Не выкладываю, поскольку сейчас кроме меня оно и не нужно никому. Ты в больнице, Сергей по морю заплывы делает, Алексей пропал куда-то...Цитата:
Сообщение от pvlad
Это да... Жду с нетерпением подвига от Сергея :)Цитата:
Сообщение от pvlad
Нет. Как раз наоборот, от физических нагрузок в несколько направильном положении. На работе частенько приходится коробки/бочки таскать, а позвоночник с рождения имеет дефект - некачественное сцепление трех позвонков. Вот и поехало...Цитата:
Сообщение от pvlad
Ладно, еще какие мысли будут по Ориону, пока у меня отпуск?
По-прежнему хочется AY. :) Ты ведь уже делал недавно в плис-спеке?
Искажение частоты устроит? ;) АУке надо 6Мгц, могу предложить только 5 или 10.Цитата:
Сообщение от Error404
to Ewgeny7
1. Ты не мог бы рассказать про методику + инструментарий для загрузки(выгрузки) файлов(блоков) памяти через USART. На РОМ-диске есть твои две программы(!) для этих целей, как я понял.
Я пробовал экспериментировать с перекачкой файлов. Процесс сам по себе получается, но достоверности никакой. Поэтому, пока Сергей не совершит "подвиг" - работа через USART, пока, единственный (как мне видится) надежный способ сохранять информацию под ОРДОС.
2. Мне очень хочется, чтобы ты набрался смелости, и разрисовал реальную времянку (с конкретными цифрами) работы шины с внешними портами I/O. Перед твоим отъездом (в отпуск!) мы этот вопрос уже поднимали.
Кроме того, твое видение дешифрации (внешней) портов и, возможно, даже пример схемотехники этого дешифратора(ов) + какой-то порт. Дело в том, что ты в ходе разработки проекта рассказывал столько страстей о "бешенной шине", что теперь я нахожусь в смятении - как к ней подступиться. Думаю, такой ликбез будет "архи важен"!
Вот временные диаграммы Z80 из книги В.Ф.Королева "Микропроцессор Zilog Z*80". Какие отличия у тебя? Только, если можешь, конкретно.
Тут всё просто как три рубля.Цитата:
Сообщение от pvlad
Программа TRANS(MIT) отправляет 64 килобайта данных с диска С на ПЦ. В качестве приемного терминала используется встроенный терминал программы CodeVision, дистрибутив которой я выкладывал. Скорость передачи не настраивается и равна 38400. В настройках терминала CodeVision выбирается скорость 38400, без контроля, терминал TTY. Запускаем на терминале прием данных кнопочкой RECEIVE, указываем имя файла .BIN, затем запускаем прогу TRANS на Орионе. Принятый терминалкой файл должен быть ровно 65536 байт.
Программа RECEI на Орионе выполняет прием данных с ПЦ и размещает их также на диск С. Размер блока так же равен 65536 байт. Запускаем RECEI на Орионе, затем в терминалке жмем кнопку TRANSMIT и указываем файл .BIN для передачи на Орион. Всё. При успешном приеме Орион вернет управление в ОрДОС/VC.
Я могу нарисовать тайминги применительно к захвату шин видеогенератором и РОМ-Диском. Как реально работает процессор на шинах - неизвестно, поскольку он является софтядром, а значит - работать в точности как реальный Z80 - не обязан. Информации о таймингах его шин нету.Цитата:
Сообщение от pvlad
---------- Post added at 13:25 ---------- Previous post was at 13:11 ----------
Можно только предположить, что тайминги в общем соответствуют реальному процессору.
Поэтому селект внешних устройств должен производиться по адрес+М1_n+IORQ.
Внешние регистры должны защелкивать информацию по заднему фронту WR.
Информацию с шины данных процессор защелкивает по заднему фронту своего же сигнала RD. Вмешательство видеогенератора на процесс чтения не влияет, поскольку этот фронт "отодвигается" путем задержки тактового сигнала.
В общем, надо банально пробовать, диаграммы и рассуждения не помогут.
С мобилки не могу цитировать. :)
5 наверное устроит. А вариант 20/3 (6,6) возможен? Экспер-но выбрать что лучше звучит.
А если частоту помножить, а потом поделить? (20*3/10=6 или 10*3/5=6 или 5*6/5=6)Цитата:
Сообщение от Error404
В Вашей реализации AY в ПЛИС 6 МГц соответствует примерно 1,77 Мгц на реальном AY или как?Цитата:
Сообщение от Ewgeny7
На п/п не предусмотрена обвязка для работы PLL. Можно только попробовать его запустить, результат неизвестен.Цитата:
Сообщение от Tim0xA
Чорд его знает. Я использовал готовый модуль (широко известный) YM2149.Цитата:
Сообщение от ivagor
Возможно это более реальные диаграмыЦитата:
Сообщение от caro
По крайней мере работать над музыкой начал. Ваяю DAC ШИМ 8=>1.
Использую ранее опробованный мною принцип заполнения "строки" из 256 бит "единицами" в соответствии с поданным числом. Есть у кого-нибудь рекомендации по поводу частоты "строк"? Верен ли принцип, что больше - не хуже, а только лучше?
---------- Post added at 17:07 ---------- Previous post was at 16:11 ----------
Заработало...
Частота дискретизации, так сказать, 20 000 000 / 256 = 78кГц.
Вроде как неплохо.
---------- Post added at 17:11 ---------- Previous post was at 17:07 ----------
Заработало в смысле DAC а не АУ :)
Пишем в ячейку F76A число, на выходе ПЛИС замеряем напряжение.
При FF получаем 3,26в, при 4E - 1.0в, при 00 - соответственно 0в.
---------- Post added at 18:15 ---------- Previous post was at 17:11 ----------
Бэмссс...
Превышение лимита на LE 111%, на ячейки RAM - 109%.
По-русски говоря, AY не влез в ПЛИС. Отбой.
Сколько ле занимают крайние доработки пзу и клав-ры? Реально вынести это в модуль и по желанию менять на модуль AY?