dmtr, они хотят уменьшить количество прерываний, их там достаточно, а дальнейшее увеличение может привести к уменьшению производительности
dmtr, они хотят уменьшить количество прерываний, их там достаточно, а дальнейшее увеличение может привести к уменьшению производительности
Владислав, подумай еще разСообщение от pvlad
У нас есть кнопки 14 и E014, 72 и E072 и так далее. Для контроля отпускания мы не можем обойтись только двумя байтами.
Извини, очепятка
Т.е. думать в этом направлении - сигнализировать битами в комплекте с основным сканкодом, одно прерывание?
Я описывал работу контроллера парой постов выше. Мне проще упростить жизнь драйверу, чем гнать ему побайтово все данные.
---------- Post added at 13:13 ---------- Previous post was at 13:12 ----------
ага. Я вообще прерываний побаиваюсь, оставил бы только INT50 для игрушек и часов
---------- Post added at 13:30 ---------- Previous post was at 13:13 ----------
Ээээ.... Лучше сделать так:
F8 - переключение "мониторов" с одновременным сбросом.
F9 - переключение страниц РОМдиска
F10 - режим 2.5Мгц
F11 - режим турбо 5Мгц (по умолчанию)
F12 - режим супертурбо 10Мгц
Scroll Lock - сброс
ScorpEvo ZS 1024 turbo+ CF-HDD/FDD/Mouse/SMUC 3.1/ProfROMse/NeoGS/ZC
Сайт с документацией к "Scorpion ZS 256"
С точки зрения построения алгоритма драйвера, проблем, вроде бы, не вижу. Действо будет происходить по нажатию клавиши. Контроль за F0 нам нужен только для того, чтобы это прерывание пропустить (а что обрабатывать? Пока не представляю!) - отпустили клавишу, ну и черт с ней! А вот Е0 - это очень важный флаг: 14 - это левый CTRL, а Е0+14 - это правый CTRL.Владислав, подумай еще раз
У нас есть кнопки 14 и E014, 72 и E072 и так далее. Для контроля отпускания мы не можем обойтись только двумя байтами.
Структурно, драйверная система будет выглядеть так: п/п KBRD (F803) проверяет всего-лишь ячейку. Если в ней 00(или FF?) - значит нет нажатой клавиши. Тоже относится и к п/п INKEY. А вся "кухня" с прерыванием будет вариться внутри и раскладывать результат по ячейкам.
Старые драйвера Ориона обрабатывали ситуацию одновременного нажатия нескольких клавиш, как защиту, а не полезную последовательность. С новым драйвером мы можем (если это будет актуальным - дождемся реакции Сергея!) сделать "новый" вектор, где все нажатия будут заноситься в буфер, а уж программа должна сама разгребать ситуацию.
Да! Иначе утонем в прерываниях. Z80 - это не AVR, где мощный и хорошо продуманный механизм прерываний. Только все равно придется сделать еще один порт, где можно будет читать эти флаги. И еще, грамотно расставить флаги на биты, чтобы было проще программно анализировать. Может быть на D7 и D0 - тогда можно анализировать через перенос. Что скажет Сергей? Я плохо владею командами Z80 - так уж исторически получилось.
К примеру, в микроконтроллерах без них нечего делать. Поэтому, в нашем случае, все зависит от того, как сделан сам контроллер прерываний, насколько грамотно расставлены приоритеты прерываний. Не исключено, что еще придется выуживать его прорехи и недостатки. А сами по себе прерывания - это прекрасный механизм!. Кроме того, одновременно работать, практически постоянно, будут два прерывания: INT50 и PS/2. Понятно, что INT50 будет бесцеремонно вмешиваться (будут вложения и совпадения) в PS/2. Здесь надо проанализировать (кроме тебя, Евгений, - никто!) "схемотехнику" контроллера, чтобы не пропадали прерывания PS/2 при совпадении с INT50. Конечно, INT50 должен иметь самый высокий приоритет - иначе грош ему цена, как датчику реального времени.Я вообще прерываний побаиваюсь, оставил бы только INT50 для игрушек и часов
---------- Post added at 14:27 ---------- Previous post was at 14:17 ----------
Это можно дублировать в порту 4F!
Если ты чего-то не знаешь, то это не значит, что этого не может быть.
Приоритеты -
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 вообще недопустима.
Это уже ваше дело. Только ИМХО команда BIT N,a куда как проще чем возиться со сдвигами, а какой бит проверять - ей все равно.
Т.е. факт отпускания клавиши вам вообще не интересен? Странный подход...
Я так думал, что вы будете вести в драйвере что-то вроде таблички на 6 байт, где прописаны нажатые в данный момент клавиши. И факт отпускания кнопки нужен для удаления символа из таблицы. А как вы мыслите это?
---------- Post added at 14:37 ---------- Previous post was at 14:36 ----------
Можно. А зачем???
Сайт с документацией к "Scorpion ZS 256"
хм... тогда может так случиться что часы будут отставать очень сильно(500-200 раз по 1/50с это 10-4с.)
Думаю, ты прав только отчасти, со своей "колокольни".
Смотрим М.Гук "Аппаратные средства IBM PC" 2-е изд., стр. 240. В порядке последовательной очередности: INT02-немаск.прерывание, INT08-таймер, INT09-клавиатура и т.д. USART - вообще не имеет своего собственного прерывания и внесен в общую таблицу распределения прерываний.
Что у нас? Если рассматривать работу в реальном масштабе времени, то INT50 - самый важный вектор. Кроме того, по этому вектору можно обрабатывать много чего, в том числе и клавиатуру, если не срастется с PS/2. Далее, должна идти клавиатура PS/2 - естественно необходима возможность безоговорочно вмешиваться в ситуацию. А вот при работе USART можно все остальное отключить, если будут глюки. И то, если будет использоваться синхронная передача. При асинхронной, пакетной с подтверждением (а еще как для надежности!?), то это уже не имеет большого значения. Можно повторить передачу последнего сбойного пакета. То, что придумано в настоящий момент для передачи файлов по USART - это временное явление по бедности, но не предел необходимого. Думаю у кого-то дойдут руки и будут сделаны нормальные программы для передачи файлов.
Кроме того, еще раз подчеркиваю: потеряно/не потеряно прерывание всецело зависит от схемотехники контроллера прерываний. От приоритета - только очередность обработки. И не более! Так что, Евгений, все в твоих руках!
Вести, конечно будем. Но даже в ПС, если ты нажал клавишу, то отменить на нее реакцию уже не возможно - даже если ты ее и отпустил! Она все равно будет записана в буфер, и программа, анализируя, выполнит то что эта клавиша предписала. Поэтому для системных п/п работы с клавиатурой, факт отпускания клавиши мало значим, и необходим, чтобы сортировать прерывания. А вот прикладные программы могут изгаляться с фактом отпускания клавиши, как им заблагорассудится!
Не "можно", а нужно!
1. Вот здесь http://zx.pk.ru/showpost.php?p=300150&postcount=279 в последнем абзаце "P.S. Порты..." я это объяснил.
2. Сергей мечтал (а ты ему это обещал!) уходя в СРМ включать максимальную "скорость". Он что, тоже обязан будет нажимать только клавишу F12? Автоматически (по своему желанию выбирать частоту) это сделать будет не возможно?
3. Это так сложно сделать, чтобы нажимая клавиши "Fx" автоматически менялись флаги в 4F? А при включении питания устанавливалась в РОМ-диске страница 00 и частота 2,5 Мгц. Думаю нет!
Делать часы на этом прерывании - это бутафория. Для часов применяют спец.микросхемы.
---------- Post added at 16:17 ---------- Previous post was at 16:03 ----------
Кроме всего прочего, не забывайте, что программы написанные для Ориона по своей логике не учитывают наличие прерываний. Они чисто программно обращаются (когда им нужно!) к клавиатуре. Поэтому, применение клавиатуры с прерыванием, при вводе символов, ничего внешне не изменит в поведении того же редактора текста. Поэтому можно будет нажать несколько клавиш (в это время редактор что выполняет свое!), а используемой окажется последняя клавиша, которую он заметил, обратившись к п/п клавиатуры.
Реальный эффект (со старыми программами) можно будет увидеть только при нажатии управляющих комбинаций клавиш. Например CTRL+ALT+DEL (будем надеяться, что удастся воплотить!) и... Орион, плюнув на все, ушел на перезагрузку, даже если он при этом и "висел"!
Если ты чего-то не знаешь, то это не значит, что этого не может быть.
С любовью к вам, Yandex.Direct
Ну, то что сейчас сделано в плане пакетной передачи - ахтунг полнейший. Повторов много, бывало даже что файл не проходил. При обычной побайтовой передаче все идет без ошибок
Дык пожалуйста. Давали бы изначально четкие инструкции...
Прерывания будут теряться при одновременной активности сигналов. Лепить настоящий мегаконтроллер я не буду.
Хорошо, сделаю.
Не особо он и мечтал. А сделать это можно за полминуты. У меня изначально так и было, потом убрал перед релизом.
Не забываем, что большая и лучшая часть ПО - со спектрума. Прерывания им необходимы. Софт СР/М-й также подразумеваю что был бы не прочь попользоваться прерываниями.
Владислав, вы как-то упускаете из виду что программам (особенно игровым) требуется знать - нажата кнопка или уже отпущена. Сколько кнопок нажато, в какой последовательности они отпущены... В РК-клавиатуре это прекрасно видно по состоянию матрицы, здесь же матрицы не будет. Поэтому с PS2 нужно иметь хотя бы табличку на несколько кнопок и в реалтайме держать там сведения о клавиатуре.
Последний раз редактировалось Ewgeny7; 18.07.2010 в 20:07.
Сайт с документацией к "Scorpion ZS 256"
Версия 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; 18.07.2010 в 22:14.
Сайт с документацией к "Scorpion ZS 256"
Значит есть проблема. Надо будет разруливать. Просто все сразу не осилить - придет время и дойдут руки. А сейчас, пока, пусть будет так.
Ну, в какой-то момент ты все переделаешь то, что сейчас планируем. Потом тебе станет скучно от "безделья", и ... зачешутся руки сделать что-то "мега". Просто надо подождать твое вдохновение! И не более!
Давай, пока, оставим как есть с прерываниями и приоритетами, а там посмотрим. Еще ничего руками не потрогали.
Разве мы убираем порт F40х, где реализована матрица? Собственно, игрушкам она и нужна, а не п/п обработки клавиатуры. Кроме того, что мешает подгрузить "старый" Монитор для "любимой" игрушки?
---------- Post added at 23:16 ---------- Previous post was at 22:49 ----------
Ну, наконец! Бандероль уже в Москве. День-два и будет у меня! До твоего возвращения что-либо перепрошивать не буду - повожусь с тем что есть, по соображаю!
Если ты чего-то не знаешь, то это не значит, что этого не может быть.
Ну слава Ктулху!
Думаю, что лучше будет как раз прошить 1,08. И для тренировки, и заодно прошивка поинтересней (и в теории - надежней, видеогенератор переделан). Только учти, что в ней вместо монитора М37 стоит М34.
Кстати, негласный тест на косяки в железе (я обязательно делаю) - в М256 делаем DUMP F600. На всём поле дампа должно быть FF. Если иначе - конфликтуют сигналы на шинах. Залив новую версию прошивки, лучше не полениться и проверить дамп.
Ну ладно, мои контраргументы закончились. Тогда подтверждай:
1. Сигнал прерывания возникает ТОЛЬКО при нажатии кнопки на клавиатуре.
2. Контроллер отправляет драйверу сканкод кнопки + префикс E0 если он есть.
3. Отпускание кнопки никак не передается драйверу.
4. префикс Е0 передается как байт в новом порту (или "1" в старшем разряде сканкода, для экономии?).
Выносите вердикт. И в будущем желательно получать такие же четкие инструкции от вас с Сергеем
Мммм... маловероятно, конечно... За последние два года я напрочь забыл слово "скука"
Только из текущих проектов у меня помимо Ориона еще и ScorpEvo. И поддержка еще парочки готовых, модезверствование на половине форума и помощь в чужих проблемах24 часов в сутках не хватает
Но всё может быть.
---------- Post added 19.07.2010 at 00:06 ---------- Previous post was 18.07.2010 at 23:58 ----------
Тонко так намекну, что существующие модели USART на ПЛИС должны иметь ошибки в работе если не принять специальных мер (типа специального кварца на 11.0592 Мгц). На скорости 20Мгц разумеется, делается коррекция, но при пакетной передаче вероятность ошибки должна накапливаться и "прорываться". При побайтовой передаче приемник и передатчик каждый раз синхронизируются заново, потому ошибки и не возникают. Я не спец в этом, но вроде это так.
Сайт с документацией к "Scorpion ZS 256"
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
