Тем не менее, клавиатуру PS/2 подключали к Вектору без посредников, прямо в порт ПУ, вся обработка была программная. Может и мышь получится также?Цитата:
Сообщение от KTSerg
Вид для печати
Тем не менее, клавиатуру PS/2 подключали к Вектору без посредников, прямо в порт ПУ, вся обработка была программная. Может и мышь получится также?Цитата:
Сообщение от KTSerg
В Волгограде? Просто я читал только про подключение XT-клавиатуры через ПУ (требуется программная поддержка, Платонов, Омск) и подключение AT-клавиатуры через ВУ (вроде подмена векторовской клавиатуры, Саттаров, Киров).Цитата:
Сообщение от Improver
Не, в живую не видел, только про это читал и хотел попробовать...Цитата:
Сообщение от ivagor
А это как было сделано? Можно ссылку на схемку или описание?Цитата:
подключение AT-клавиатуры через ВУ (вроде подмена векторовской клавиатуры, Саттаров, Киров).
Меня самого очень интересует, как это было сделано, т.к. требуется подмена внутренних портов. Тут или какое-то know how или модификация вектора. Про контроллер AT-клавиатуры я читал в кировской рекламе, эти бумажки я искал, но, к сожалению, не нашел и скорее всего они давно на помойке. В вектор-user 23 есть упоминание контроллера XT-клавиатуры Саттарова, то ли это первый вариант, то ли Фиронов ошибся, а может и я.Цитата:
Сообщение от Improver
А где про это писали?Цитата:
Сообщение от Improver
Да, нашёл, но там только упоминание на три строчки... :(Цитата:
Сообщение от ivagor
И ещё нашёл, в номере 30 есть упоминание некоего контроллера на КР1816ВЕ31 (типа ардуино того времени) для мыши от Брескина М.Ю., но схема не приводится, т.к. она "малодоступна", из статьи известно только, что мышь через этот контроллер подключалась к порту джойстика и использовалось стандартное ПО. Не очень удачное решение, думаю.
Так в том же ВЕКТОР-USER, в №19 почти полторы страницы этому отведено, со схемой подключения и программами на ассемблере.Цитата:
А где про это писали?
Это вариант Платонова (Омск), я про него упоминал, он рассчитан на XT, не на PS2.Цитата:
Сообщение от Improver
Ну тогда ой -- спутал разъём со стандартом... :confused:Цитата:
Сообщение от ivagor
Ви таки будити смеяться, но похоже, что Вектор таки может работать и с клавой и с мышью по PS/2 подключенными к ПУ.
Сейчас протестировал логгером алгоритм из ВекторЮзера №19. Алгоритм позволяет читать байты поступающие с частотой 22КГц, а клава и мышь работают с часотой 11-13КГц.
Буду тестить дальше.
Только замыкать выводы ВВ55 как указано в схеме, не хочется... буду пробовать подключать через диод.
Ну как бы не Вектор, а программа на Векторе.Цитата:
Сообщение от KTSerg
Почему 22 кГц?Цитата:
Сообщение от KTSerg
Скажу по другому: быстродействие Вектора должно позволить драйверу, справится с приёмом данных с клавы или мыши.Цитата:
Сообщение от Syntal
Не знаю. А должно быть другое число?Цитата:
Почему 22 кГц?
Переписал программу из ВекторЮзер, заменил IN на OUT (и ещё по мелочи, чтобы тайминги программы сохранить).
И получилось, что приведённая в ВекторЮзер программа может принять Байт передаваемый на частоте 22КГц.
Т.е. при приёме данных с клавы или мыши, драйвер ещё и "скучать" будет, т.к. данные поступают в 2 раза медленнее, чем может себе позволить данный алгоритм.
Но это предварительные данные.
Сейчас адаптирую алгоритмы протокола ps/2 от Ардуины. Посмотрим, что получится на самом деле.
Если поделить частоту вектора на длительность команд основного цикла процедуры IBMKey (в тактах), то как раз получится примерно 22 кГц: 3e6/(12+8+12+8+12+12+4+4+8+4+8+12+8+12+12)=приме но 22059 Гц
Именно 22059 мне логер показал.Цитата:
Сообщение от ivagor
Продолжаю ковыряться в исходниках МДОС Т-34... Сделал новую версию, теперь уже с изменениями, назвал её Т-34m02 (версию m01 не вижу смысла выкладывать), вот готовый бинарник + исходники в архиве: Вложение 68695
Изменения по сравнению со стандартной версией Т-34:
- МДОС откомпилировал на адрес BF00h (так же, как в Т-72), это сократило бинарник, как минимум, на 2Кб и заметно сократило время старта системы. При тестировании после компиляции, кстати, выявились новые моменты, не замеченные в предыдущем варианте исходников.
- Отделил шрифты в свой файл, чтобы не мешали.
- Удалил ненужные (не используемые) блоки данных.
- Исправил и немного сократил некоторые подпрограммы, потасовал их для лучшего заполнения после удаления ненужных блоков.
- Много изменений сделано в программе запуска и размещения в памяти блоков "os~m.asm", в основном из-за перекомпиляции МДОСа.
То, что в итоге получилось погонял в эмуляторе -- всё, вроде, работает, в том числе и коммандер CO.COM. На живом железе проверить не смогу в виду отсутствия флоповодов... Ещё заметил, возможно всем известную, багу в Т-34 и Т-72: при смене дискеты в А: по команде D продолжает показываться содержимое исходной дискеты, на В: такое не наблюдается.
Заметил, что The Lyra II MD, которая почему-то не на загрузочном диске, не запускается из под
А из подКод:YANUS BIOS 021290 28K MicroDOS Vers. 3.1 20.12.83
-- запускаетсяКод:BOLD BIOS v3.0ISA/PPC 47K MicroDOS Vers. 3.2 12.04.95
и
wEKTOR-06c Bios vers t-34 48K MicroDOS Vers 3.1 20.12.83
Видимо дело в крохотной TPA, которая остается от YANUS BIOS, который видимо не использует кваз? ivagor, ты наверное поэтому их выбрал для pwm18i2 и других охочих до дополнительной памяти программ?
Для проигрывания звука и видео я выбрал mdos28 чтобы полностью использовать для своих нужд квазидиск (в котором большинство остальных досов хранит себя и диск C: ).
(Нажал воображаемое "Спасибо")
Improver,шелл типа SamaruX под т34 пойдет?
http://www.floppysoftware.es/cpm_projects.html
Не могу знать... :v2_dizzy_stupid: Только эксперимент даст ответ на этот вопрос.Цитата:
Сообщение от zx_
Там z80 нужен
Обновлённая версия операционки Т-72, вместе с исходниками: Вложение 70157
Изменения по отношению к оригиналу:
- Убрал все упоминания запуска коммандера CO.COM, т.к. он из Т-72 не работает. Причина его неработоспособности явно в том, что СО.СОМ обращается напрямую к подпрограммам и данным в БСВВ, а в Т-72 там много изменений, легче будет дизассемблировать и поправить СО.СОМ, чем поддерживать эту совместимость.
- Убрал дублирующуюся таблицу параметров флоповода в DPH, т.к. в МДОС допускается совместное использование одной и той же таблицы разными DPH. Возможно это приведёт к проблемам при использовании разных приводов, но, я посмотрел, в других МДОСах такое совмещение тоже встречается, да и по нынешним временам это, думаю, уже не принципиально.
- Убрал таблицу трансляции логических секторов в физические, т.к. в ней особой необходимости, по сути, нет, номера логических и физических секторов всегда совпадают.
- В оригинальной МДОС в Т-72 был интерестный патч: при старте системы производится инициализация дисков, так этот патч заворачивал все обращения к флоповодам на квази-диск, а после инициализации самоликвидировался. Возможно это было сделано для запуска СО.СОМ без дискет, но я решил пойти дальше и теперь обращений к дискам при первой инициализации нет вообще.
- Предыдущий пункт позволил полностью отвязать систему от флоповодов, теперь система стартует даже на моём железном Векторе, где флоповоды отсутствуют физически. При загрузке теперь проверяется квазидиск С: и с него запускается INITIALC.SUB, если будет там найден.
- Ещё одно исправление: теперь при обращении к флоповоду при отсутствии дискеты система не виснет, а задаёт всем известный вопрос"нафик/нефик/пофик""Пропустить/повторить/отменить". Там хватило бы и последних двух вариантов, но я решил не отходить от традиций.
- Ну и по мелочам, небольшие непринципиальные исправления в алгоритмах всей системы. Файлы "_EF00h.asm" и "_F600h.asm" по отношению к оригиналу изменениям не подвергались, но в архив я их вложил, для комплекта.
А теперь то, ради чего это всё затевалось, первая операционная система для двух квази-дисков, Т-72kd2, вместе с исходниками: Вложение 70158
К ней относятся также и все перечисленные выше изменения, плюс сделан диск D:, который показывает содержимое второго КД. Формат второго квази-диска ничем не отличается от первого, стандартного формата. Единственный ньюанс: новая операционка пока не умеет его форматировать и проверять, все другие функции (копирования, запуска программ) работают. Для тестирования этой ОС можно использовать эмулятор "Башкирия-2М", конфигурацию для двух КД можно взять тут, за что отдельная благодарность b2m.
Багфиксинг операционки Т-72, исправленная версия с исходниками: Вложение 70169
При тестировании выявилась такая проблемка: в прошлой версии буфер для флоповодов перекрывал буфер для чтения директории, в результате чего содержимое дискеты могло быть испорчено. :(
В версии для двух КД до конца эту багу исправить пока не удалось (ещё надо ужать БСВВ примерно на сотню байт), но пока сделал так, чтобы буфер перекрывал первые символы экранного шрифта. Но есть и положительные моменты: новая версия теперь умеет форматировать и проверять второй КД. Вот архив с исходниками, для тестирования: Вложение 70170
Для форматирования второго КД дополнил функционал команды "8" МДОС, теперь можно её использовать так:
где <диск> -- буква диска "С:" или "D:",Код:8 [<диск> [F]]
"F" -- команда форматирования
Запуск без параметров запускает тестирование первого КД, как и ранее.
Например:
8 C: -- тестирование первого КД
8 D: -- тестирование второго КД
8 C: F -- форматирование первого КД
8 D: F -- форматирование второго КД
Свежая версия МДОС Т-72 для двух квазидисков, с исходниками: Вложение 70228
Для полного исправления проблемы с буферами пришлось пожертвовать следующими функциями:
- Убрал команду "0 хххх M", которая устанавливала режим печати, размер листа и расстояние между строк. Это кому-нибудь актуально?
- Убрал некие добавленные в Т-72 команды "0 хххх S" и "0 хххх V", которые как-то патчили подпрограммы обращения к дискетам. Причём во втором случае была бага в оригинальной Т-72, там повторно использовался ключ "W", в своей версии я его заменил на "V", а теперь убрал вообще. Эти функции были где-то задокументированы? В Т-34 их не было...
- Ну и оптимизировал код БСВВ, в основном свои дополнения и изменения. :)
З.Ы. Заметил интересный глюк, если запустить программу DIR.COM при текущем диске D:, то его содержимое показывается нормально, а если текущим будет любой другой диск (A:, B:, C: ), то по "DIR D:" показывается что-то не то... Но команда МДОС "D" отрабатывает во всех вариантах без ошибок.
Новая версия Т-72, как всегда с исходниками: Вложение 70276
Изменения по отношению к предыдущим версиям:
- Добавил автодетект наличия второго квази-диска, что привело к объединению версий просто "m" и "kd2", и при старте доступные диски показываются корректно, слева скриншот из эмулятора с одним КД, справа -- с двумя (найдите одно отличие ;) ):
Вложение 70274 Вложение 70275
- Немного порихтовал область F600-FFFF в БСВВ, за счёт удаления неиспользуемых блоков освободилось чуть больше ста байт для будущих доработок.
- Пропатчил МДОС по рекомендации Виктора Саттарова (см. журнал "Байт-20", стр.129 в pdf), теперь при нажатии БЛК-СБРОС система не виснет.
Доброго времени уважаемые !
Вопрос не в тему последних сообщений, но очень интересно, может кто то знает, у оси РДС 3.02, ну или вообще в целом у РДС есть что то, что она запускает после старта, какой то аналог INITIAL.SUB в МикроДОС? В РДС есть поддержка .BAT с параметрами, неужели нет автозапуска при старте чего либо ?
И еще, прочитал тут про командер СО.СОМ, что это, где можно его скачать и посмотреть? Работет ли он под MicroDOS 3.1H? Киньте ссылочку на программу пожалуйста ?
Огромный интерес на данный момент есть к РДС 3.02, может быть есть место, где можно разжиться исходниками этой системы, некоторые моменты очень интересны....
И еще по ходу один вопрос возник.. В "Байт" № 20 на странице 129 описывается доработка, которую Improver воспроизвел в Т-72kd2. Так вот, то же самое я пытался сделать непосредственно в бинарнике mdos31H..
Участок кода 3E C3 32 00 00 21 03 02 22 01 00 32 05 00 21 00 02 22 06 00 нашелся поиском в HEX редакторе и заменился на 3E C3 32 00 00 21 03 02 22 01 05 21 00 02 22 06 00 65 36 F7, он оказался на 100H выше, адресс 1D65H - 1D68H а не 1E65 - 1E68 ....
А дальше - гейм овер... Бит 04 который должен быть заменен на бит 20H - по адресу 266E не оказался на месте. Математику автор не указывает, как связано то что настраеваемый бит перешел с адреса 1E75 на 1E72 - и в следствии этого в массиве настройки ставится вместо 04 - 20H по адресу 266E .. По указанному адресу бита 04 не оказалось, на сколько я понимаю, массив настройки может быть вообще по другим адресам... То есть, получается, что без исходников задачу не решить ? В целом вопросов много, почему бит 04 изначально, почему 20H, как это посчитал автор, где в mdos31H массив настройки и где там нужный бит ?!? Если кто то может, помогите пожалуйста разобраться ? Или может у кого то исходники есть от mdos31H.
Понимаю глупость решения, но в голову ничего не пришло больше - прошелся по всем битам 04H с адреса 256E по адрес 276E меняя их по одному на 20, загружая ось, и нажимая "СБР"+"БЛК" - результат отрицательный...
Поможите чем сумеете ?!? :)
Скорее всего нет, это же подтверждает беглый просмотр файла хекс-редактором.Цитата:
Сообщение от electroscat
Не работает. Более того, СО не работает даже под "приемником" Т-34, системой Т-72. В СО просто сделана жёсткая привязка к некоторым адресам БСВВ и прямой вызов подпрограмм...Цитата:
Сообщение от electroscat
На "базисе" всё есть. :)Цитата:
Сообщение от electroscat
К сожалению, их нет в доступе, но при наличии дебагера и знаний ассемблера получить можно.Цитата:
Сообщение от electroscat
Не, такой фокус не пройдёт, при похожести сигнатур там у них может быть совсем другое назначение... Нужно смотреть не бинарники, а исходники. Я начинал копаться в mdos31h (не до конца дизассемблил), но там есть такой код:Цитата:
Сообщение от electroscat
Выполняется он при первом запуске, таким образом система уже пропатчена по рекомендациям из "Байта", запуск её в эмуляторе и нажатия "БЛК-СБР" это подтверждают, патчить там не чего.Код:026Bh: MVI A, 0F7h
STA 00000h ; заносим RST 6 по адресу 0000
LXI D, L_029E ; откуда
LXI B, 00030h ; куда
LXI H, 00008h ; сколько
CALL L_02A6 ; переброска данных (для RST 6)
...
L_029E: db 03Eh ; MVI A, ...
db 023h ; ... 023h
db 0D3h ; OUT ...
db 010h ; ... 010h ; включение КД
db 02Ah ; LHLD ...
db 001h ; ...
db 000h ; ... 0001h
db 0E9h ; PCHL
;
Насколько помню у 3.02 отличие от 3.00 только в организации доступа к квазидиску, причем 3.02 чуть медленнее для совместимости с одним из вариантов кваза на РУ7. Т.е. если 3.00 работает с имеющимся квазом, то у 3.02 нет преимуществ.Цитата:
Сообщение от electroscat
Не, судя по приложенным текстовым файлам, были два варианта РДС (n -- номер версии): Rn.COM для квазов на РУ5 и Rn-RU7.COM для РУ7, соответственно. Вот там и были отличия по работе с квазидиском. А третья версия РДС существовала в вариантах 3.00, 3.01 и 3.02 (других не видел), и текстах было упоминание, что исправлялись некие ошибки, так что преимущества должны быть.Цитата:
Сообщение от ivagor
r3.com - 3.00Цитата:
Сообщение от Improver
r3-ru7.com - 3.02
При исправление неких ошибок в 3.01 и 3.02 не читал или не помню. Про РУ7 писал здесь
Огромное спасибо за ответы, исчерпывающе !!!
Цитата:
Сообщение от Improver
Я в эмуляторе не додумался, а на реале, виснет после "БЛК-СБР" ... возможно из за того, что схема моего квазидиска и не на ру 5 и не на ру 7 а на K6T4008C1B, а может и из за чего то еще...Цитата:
Сообщение от Improver
Виснет кстати только голая система, а например при рестарте с ASC.COM - все ок, ASC продолжает работать. В целом, эта проблема не существенна, потому как голой MDOS31H у меня не бывает, следом грузится ASC.COM всегда. Но для понимания машинных кодов и логики хотел это проделать, для саморазвития как бы ....
Попробовал в эмуляторе, EMU V1.01 - результат почти тот же, голая система после нажатия "БЛК-СБР" заливает экрат разными полосками в ряд... На реале это происходит по другому.. Тем не менее...
Может оно и так... Я же исходил из текста письма автора РДС Вьюнова некоему Виктору, которое нашлось на одной из дискет:Цитата:
Сообщение от ivagor
Из текста письма можно подумать, что варианты для РУ5 и РУ7 существовали и развивались параллельно, но сейчас пересмотрел то, что нашлось у меня из РДС третьей версии:Код:Здравствуй, Виктор !
Высылаю тебе всё что ты просил, - все РДС и VC.
R2.COM - вторая версия РДС для ЭД только на РУ5-х (!).
R2-RU7.COM - вторая версия для ЭД на РУ7-х.
R3.COM - версия с поддержкой HDD для ЭД только на РУ5-х (!).
R3-RU7.COM - то же для ЭД на РУ7-х.
VC.COM - вторая версия.
VC3.COM - третья версия, с поддержкой HDD.
С помощью присланной тобой отладочной информации удалось найти ошибку,вер-
нее недоработку в версиях РДС для ЭД на РУ7-х.Так что дело не VC.Однако меня
запутало то, что ты писал,что и в версии для ЭД на РУ5-х есть сбои, текст VC
я перепахал вдоль и поперёк,а видимо ты пытался запустить версии для РУ5 на
ЭД с РУ7, что совершенно недопустимо. Но всё хорошо то, что хорошо кончается,
теперь всё должно работать нормально. Та же недоделка была во второй версии
РДС для ЭД на РУ7-х, поэтому удали сначала со всех своих дисков старые версии
вышеуказанных программ,а потом с этой дискеты скопируй.
(Далее приводить письмо нет смысла).
- R3.COM -- версия 3.00
- R3-RU7.COM -- версия 3.01
- R3-RU7.COM -- версия 3.02
Так что не факт, что они когда-то были, и Вы правы насчёт отличий, но только, думаю, относить их всё же следует к версиям R3 и R3-RU7.
Виктор - это наверняка Виктор Фиронов (Vector-user).
Это точно не из-за памяти на КД, но, кажется, я догадываюсь, почему она виснет. Было два варианта системы mdos31h, одна из базиса, а вторую я нашёл на образе жёсткого диска для эмулятора, так вот первая пропатчена, а вторая -- нет. :) Попробуйте взять mdos31h с базиса.Цитата:
Сообщение от electroscat
Да, вполне возможно что и не с базиса у меня MDOS31H. Ну и в целом, при сравнении версий в HEX редакторе возможно удастся понять, где таки находится байт, который нужно изменять в массиве настройки.. Благодарю!Цитата:
Сообщение от Improver
Р.С. Попробовал OC.COM - очень продвинутый файловый менеджер, жаль исключительно для T34... Очень качественная оболочка.
Когда у меня был вектор 25 лет назад, я пользовался NC.COM.. Тогда больше ничего не знал,... Сейчас понимаю, что NC.COM пожалуй самая глючная из всез файловых оболочек для вектора.. Но тогда она казалась весьма неплохой )))
P.C. попробовал mdos31h с базиса в эмуляторе, виснет при нажатии "сбр-блк"... Может наоборот, патченная в образе была?
Сравниваю mdos31h который у меня везде, и взятый с базиса - HEX редактр заявляет - файлы идентичны.
Можете скинуть ссылку на образ, или ваш вариант mdos31h, который не виснет при нажатии "сбр-блк" ? Пожалуйста _/|\_
Интересное дело... Скачал mdos31h с базиса по своей же ссылке выше, смотрю файл в редакторе:Цитата:
Сообщение от electroscat
Вот же в нём тот самый патч, о котором я писал ранее. Может файлики попутали? Или я что-то глючу... Проверьте по контрольной сумме MD5:Код:0000016B 3E F7 32 00 00
...
0000019E 3E 23 D3 10 2A 01 00 E9
e11c4fa917b8a16cf11771801285175a *mdos31h.com
Ну и если уж совсем не везёт с ним, вот, продублирую тут: Вложение 71936
Да, контрольная сумма совпадает, именно этот файл.. Но при нажатии "сбр-блк" виснет, в эмуляторе и в реале %)
Причем абсолютно одинаково и там и там... Странное дело...
https://yadi.sk/i/Cf6HLQhFyhJfZA
И правда что-то не то... Судя по видео, запускаете из эмулятора EMU (он же "Башкирия")? После старта МДОС запустите там отладчик ("View" -> "Start debugger") и посмотрите, что в памяти в ячейке 0000, если там "C3", то МДОС не патченый. Надо обновить системную область диска или заменить на КД файл "OS.COM" новым.Цитата:
Сообщение от electroscat
Как вариант, попробуйте открыть правильный файл "mdos31h.com" через меню эмулятора "File" -> "Open...", тип фалов -- все файлы, должно получиться.
У этой проблемы есть простое, но не полное решение. Нужно заменить в файле по смещению 1D67h байт 32h на 00, тогда C3h не будет затирать F7h.
В чем неполнота:
RST гадит на экран, но нельзя просто заменить его на переход в 0030h, т.к. в адреса 1 и 2 лезут очень умные программы типа power. В идеале надо чтобы у доса адреса области переходов на подпрограммы были в районе 0E000-FFFF, как, например, у РДС.
Еще надо бы запрещать прерывания, но тут можно обойтись малой кровью, чуть модифицировав подпрограммку с адреса 0030h.
Проблема в том, что я беру ваш файл, или файл с базиса, при помощи VV делаю из папки с ним образ дискеты, подключаю к EMU, пишу файл на системные дорожки, sysgen b:mdos31h.com a:100, запись удачна, далее, запускаюсь с а, то есть с F2+F3+ввод+блк+ус - стартую с форматированием КД, сразу пишу новый mdos на КД: c:[вк]1 48 os.com[вк] и получаю ок... Ну и далее - вызываю дебагер, и там JMP (C3) в ячейке 0000h... На реале то же самое происходит. Файл mdos31H c базиса при помощи MST пишу на дискету, сую в дисковод, пишу на системные дорожки, результат тот же. Пробовал даже записать на системные дорожки R3.COM, и потом, после перезагрузки, опять вернуть MDOS31H при помоши SG.COM и все удалось, то есть запись на системные дорожки работает, но увы, при записи на них mdos31H превращается в непатченный, причем и на EMU и на реальном векторе... в Реальном векторе просматриваю адрес 0000H при помощи SID.COM команда D0... Парадокс... У вас реально не виснет после нажатия "ввод+блк", и по адресу 0000H не С3?Цитата:
Сообщение от Improver
А может система как то варьировать эти вещи при старте сама, при определенных параметрах писать в ячейку с адресом 0 - разные строки кода ?
Кстати, файл который грузится в память и на реале и из эмулятора соответствует файлу с базиса по контрольной сумме...
Похоже, что да, тут в МДОС затирается адрес 0000, выходит, mdos31h недопатчили... (В Т-72 я этот момент поправлял :) ) Ну один-то байтик ещё заменить -- не проблема же.Цитата:
Сообщение от ivagor
Это, наверно, на реале заметно? В эмуляторе я что-то не замечал...Цитата:
Сообщение от ivagor
- - - Добавлено - - -
electroscat, замени в файле mdos31h.com (с базиса который) по смещению 1D67h байт 32h на 00h, как посоветовал ivagor и все заработает. :)