Есть, я тоже сначала не понял, потом нашел, но не работает у меня на ноуте в эмуляторе, в винде работает. Клавиша при нажатии которой выпадает контекстное меню активного окна.
Вид для печати
Я вас понял) Надо было написать 'Контекстное меню - это АЛФ', а не наоборот)
Запараллелил клавиши ПОМ, УСТ, ИСП, СБРОС, СТОП. Теперь так:
Осталось как-то прикрутить ДКЛ к мини-клавиатурам.Код:ПОМ - F6 или Delete
УСТ - F7 или End
ИСП - F8 или PageDown
СБРОС - F9 или Insert
СТОП - F11 или PageUp
<_>(ЛАТ) <:*>(РУС) - F12 или Home
Убрал в эмуляции флопа проверку на выключение мотора, теперь дискеты все время вращаются, но подвисания пока нет. Код там надо перетряхнуть, бывают моменты, что запись не проходит.
JEK нормально загрузил картинку. Вот только в какой палитре она должна быть?
Еще кстати у картинки верх какой-то попорченный. На реальной машине так же?
В WinXP, ноут Dell.
---------- Post added at 01:12 ---------- Previous post was at 00:52 ----------
По прежнему застревает на второй заливке, желтый фон.:confused:
---------- Post added at 01:41 ---------- Previous post was at 01:12 ----------
Понял почему клавиша АЛФ не работала, в соседней ветке http://zx.pk.ru/showpost.php?p=426276&postcount=83
загрузился с другой дискеты и все.
В ручном тесте раскладок выявилось: в режиме РУС при нажатии "Ъ" срабатывает "забой", "ъ" только в нижнем регистре.
Здесь уже при чтении с дисковода не подвисает. Уже где-то некорректно передает информацию. Задачка однако. Посидеть здесь придется долго, чтобы проанализировать и понять.
Так и должно быть. Система RT-11 обычно обрезает старший бит. Код символа "Ъ" равен 255, после обрезки - 127, а это код клавиши "Забой".
Это у вас на картинке эмулятор КЦГД? Или же это просто картинка с ДВК?
Еще эта картинка есть на обложке журнала МПСиС №3 за 1988, реклама возможностей КЦГД и статья.
Диск этот от разработчиков пакета KUARKO.
Наверное они у меня есть. Это уже где-то обсуждалось, игрушки писались под КЦГД, как и редактор JEK, а потом под УКНЦ.
Жаль что нет эмулятора ДВК-3(4) с КЦГД и КГД, очень много софта на эти машины.
Titus, А на чем их смотреть(проверить)? может они не под КЦГД?
Вот будет эмулятор ДВК с КЦГД и КГД+КСМ тогда и выкладывать можно.
Я сейчас как раз занимаюсь разработкой такого эмулятора, но по ходу возник довольно существенный вопрос.
Разработка осуществляется на базе универсального модульного API эмуляции, разрабатываемого параллельно. Для передачи потоковых данных в этом API используются потоки. С байтовым потоком, который используется для подключения эмулятора терминала к эмулятору последовательного порта, всё просто - в канале данных потока передаются байты.
Но если использовать тот же принцип для передачи видеокадров через "поток видео", то передавать уже нужно что-то вроде указателя на объект "видео кадр".
Т.е. модуль эмуляции КСМ будет создавать объекты "видео кадр", заполнять их своими данными и затем передавать через поток дальше ( на вход модуля эмуляции КГД или модуля эмуляции видео-монитора ).
Отсюда вопрос - какие данные должен содержать объект "видео кадр", чтобы любая программа, понимающая формат "поток видео" могла воспроизводить на экране хост-машины абсолютно точный аналог изображения, формирующегося в оригинале на экране эмулируемого видео-монитора.
Похоже, что основной блок данных видео кадра - это массив цветовых значений RGB точек растра, с заголовком, содержащем сведения о числе строк и столбцов. Частота кадров скорее всего передаваться не должна. С какой скоростью "фабрика кадров" будет их создавать - такая частота кадров и будет.
Яркость, контрастность, линейность, заметность обратного хода луча - полностью определяются настройками эмулятора видео-монитора, поэтому передаваться в кадре не должны.
Получается, что формат данных потока видео (т.е. "кадров видео") - это массив 32-битовых значений цвета точек растра с указанием размерности массива.
Этого достаточно?
Нужно ли для максмально точного воспроизведения видео-потока передавать в объектах "видео кадр" что-то ещё ?
неужели наконец-то появится долгожданный эмулятор ДВК?!
P.S: Ведь я смотрю и реальщиков-то много, и познания у всех более чем позволяют сделать полноценный эмуль, а пока его не было...
Появится точно, но не слишком скоро.
Нет смысла писать новые модули эмуляции, пока не разработан достаточно качественный универсальный модульный API эмуляции.
Вот написал я в тестовых целях (с текущей версией модульного API) несколько модулей для эмуляции ДВК-1 и теперь всё это перестаёт работать при каждом принципиальном изменении API (т.е. почти каждый день). Поэтому почти ежедневно приходится заново отлаживать все уже написанные модули эмуляции ( процессор 1801ВМ1, плата МС1201.00, плата DL11-W, псевдо-контроллер DSK, универсальный терминал ).
Можно создать тему про универсальный модульный API эмуляции, но только в том случае, если среди участников есть желающие такую тему обсуждать.
Вот захочет кто-то ответить на мой вопрос, какие данные должны передаваться в объекте "кадр видео" для максимально точной эмуляции работы видео-контроллеров - тогда можно для этого и тему создать.
Вот этот архив мне прислал anasana, за что ему огромная благодарность! Я пока особо не копался ( разгребаю УК-НЦшный завальчик)
Но с его-же слов там должно быть что-то под КЦГД, в том числе и Land (или какой-то иной вариант на тему Lode Runner-а )
http://www.onlinedisk.ru/file/755228/
Alex_K, по поводу операции copy в эмуляторе - на всех этапах эта команда не всегда выполнялась корректно, вы и сами знаете, я просто озвучу свои наблюдения, система в эмуляторе ведёт себя так, словно операция завершилась успешно, но на самом деле на втором диске (куда копируем) копируемый файл не всегда появляется, то есть после завершения операции, по
команде DIR - каталог без изменений остаётся. Хорошо-бы конечно все дисковые операции внимательно прочесать, но могу сказать что INI/VO, DEL, SQ/NOQ - ни разу сбоев не давали например.
-------- добавлено ! --------------
Alex_K, благодарность за два обновления за 1-одни сутки (ночное и вечернее) и по поводу новой раскладки, я вот на ноуте своём сейчас
эмулятор гоняю, очень удобно - главное косвенно\непосредственный @
теперь удобный, остальное вроде тоже довольно удобно.
Реальный сигнал видео не заносит в поле кадра сведений о частоте кадров и (насколько я понимаю) является последовательностью независимых отдельных сигналов отдельных кадров, поэтому наличие информации о частоте кадров в "эмулируемом сигнале видео" избыточно и (на мой взгляд) контрпродуктивно.
Не знаю, какая система у вас, но если кадровая частота монитора не совпадает (или не кратна) частоте обновления экрана, появляются артефакты, размазывание изображения и/или 'попадание под лучик'.
---------- Post added at 22:43 ---------- Previous post was at 22:21 ----------
Файлов много, но чета игр особо не нашел.
Получение эмулированного потока кадров видео мало чем отличается от получения реального потока реальных кадров видео. После получения каждого очередного кадра открываются "временные ворота", в которые должен успеть попасть следующий кадр. У реального видеомонитора ширина таких ворот определяется (насколько я понимаю) качеством схемы автоподстройки частоты кадров. Если следующий кадр не успевает прийти за указанный промежуток времени - у монитора происходит сбой кадровой развёртки. Для сколь угодно точной эмуляции таких процессов не требуется отдельная информация о среднем количестве приходящих каждую секунду кадров.
Однако, в моей версии универсального API эмуляции - каждый поток имеет отдельный канал передачи команд. Так, например, эмулятор терминала иногда отправляет эмулятору последовательного порта команды "ReportBaudRate" и "ChangeBaudRate". Поэтому, если некоторые передатчики потока видео смогут адекватно отреагировать на команды типа "Report_FPS" и "Change_FPS" - удобство использования потока видео, возможно, повысится.
Но это не принципиальный момент. Принципиальный же момент в том, что наличие в отдельном кадре потока видео информации о частоте кадров (на мой взгляд) - совершенно излишне.
Вам виднее. Я так понял, что эта ваша система состоит из всяческих терминалов, как, например, я видел в СМ1420 на УПК в школе. Когда где-то стоит комп, а у учеников 20 терминалов, и главный комп обрабатывает их по очереди. При таком подходе конечно дикие задержки между нажатой клавишей, реакцией программы, и получением ответа в виде изменения видео или аудио.
Когда Вы говорите про результаты несовпадения частоты обновления экрана с частотой кадров, то это относится к процессам, происходящим ДО контроллера видео, я же говорю о процессах происходящих ПОСЛЕ контроллера видео.
Проще говоря - у компьютера есть разъём "видео" и у монитора есть разъём "видео", а соединяются эти разъёмы мониторным кабелем. Так вот речь и идёт о том, каким должен быть формат данных, передаваемых по "виртуальному мониторному кабелю" при его эмуляции.
Ведь, эмулятор видеоконтроллера может написать один человек, а эмулятор видеомонитора - другой человек. Каким же должен быть набор данных, которые эмулятор видеоконтроллера должен передавать эмулятору видеомонитора, для максимально адекватной эмуляции передачи видеосигнала..
Это и интересно обсудить.
Мнение не профессора, что если никакой отсебятины не пытаться навернуть, тупо "в ноль" сигнал той железки эмулятор которой пишется? Такой подход логичен на мой взгляд, либо я не совсем понял о чём речь (эх.уже пора в отдельную тему с вашим API переезжать!!! А люди подтянутся - тема то интересная, просто тему по УКНЦ эмулятору загрузим сильно если в её рамках продолжать), все посты от первого вашего вопроса можно ведь в новую тему перекинуть - вот будет радости!!!:wink:
Я так или иначе выкладываю все что присылается и не имело повторов в архиве Арсения например, который софт собирать начал задолго до меня и обсуждалось создание общего архива ( я тут нашёл первые разговоры на эту тему) несколько лет
назад. Только вот из большинства, кто заявил "вот у меня вроде есть там где-то что-то" - реальные файлы, архивы или образы - присылают далеко не все. Это в общем очередной призыв выкладывать и делится ко всем!!!
:rolleyes_std:
Спасибо.
Народная мудрость гласит: В большинстве телевизоров кадры показываются с той же частотой, с какой они передаются. Возможно в это трудно поверить, но обычный аналоговый видеосигнал не передаёт В КАДРАХ информацию о частоте кадров. И именно поэтому формат данных эмулированного видеокадра не должен (по моему мнению) содержать информацию о частоте кадров. Такую информацию приёмник эмулируемого потока видео может запрашивать у передатчика по каналу команд, но наличие информации о частоте кадров в каждом кадре (на мой взгляд) совершенно излишне.
Уговорили :)
Поместим в заголовок кадра значение FPS, 32-разрядный порядковый номер кадра, признак дублирования кадра с предыдущим номером (тело дублирующего кадра обязано присутствовать), количество точек растра по горизонтали и количество точек растра по вертикали. После заголовка расположим тело кадра в виде массива 32-разрядных значений RGB точек растра.
Это только всё что было на MY дисках я легко прочел... LAND и другое под КЦГД хранится на дискетах формата МХ у одного чела, на вынос их не отдаёт, я забрал на пробу пару дисков из его комплекта и пробовал у себя прочесть, но пока ничего не получилось.Цитата:
Сообщение от Titus
Коллеги, спасибо огромное за вашу работу!
Сам я, к сожалению, сейчас сижу на проекте который оставляет крайне мало свободного времени, поэтому пришлось отложить работу по эмулятору.
Сегодня появилось немного времени, выкладываю для вас сборку, сделанную по изменениям Алексея за 3-18 октября -- фикс ASH/ASHC, порты ловушки, работа с клавиатурой.