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