Вид для печати
Для меня было всегда загадкой, как люди с дисководом загружали кассетные игрушки. Мое предположение — разжившись дисководом, векторист все свое время посвящал развитию дисководства и на игры времени просто не оставалось.
А какая процедура бута с дискеты? Как определяется ее бутабельность и можно ли просто посекторно записать на нее .rom ? Это жирновато конечно, особенно для начала 90-х, вряд ли кто бы стал так делать, но все же.
Расширение .com и вперед. Для r0m была отдельная запускалка.
Насколько я понимаю, на системные дорожки можно записать любую программу. В стандартных векторовских ДОСах (для кишиневского КНГМД) каталог на 8й дорожке, т.е. на прогу на системных дорожках остается 40960-128 байт. Стартовый файл SKYNET, например, 32 Кб.
Точно, SKYNET же тому живой пример.
А в чем тогда смысл иметь какой-то другой ДОС для запуска игр?
Думаю, что размещать большие игрушки на системных дорожках неудобно и расточительно (для того времени). Под каждую большую игрушку - отдельная дискета (хотя таких игрушек и мало было). Для CP/M-39 была какая-то утилита для загрузки, но я ее не нашел (возможно она загружает не то, что я предполагаю).
- - - Добавлено - - -
Нашел утилиты cpmgo и cpmload для cp/m-39. К сожалению, они большие файлы не переваривают. CPMGO просто загружает и запускает указанный файл, т.е. единственная польза - можно запускать файлы с любым расширением, хоть .com, хоть .rom.
Ну при этом на дискете ведь могли быть и другие игрушки, а не только большая игрушка на системных и всё. У некоторых на системных дорожках вообще ничего не было. А "системными" были только специально выделенные для этой цели дискеты.Цитата:
Сообщение от ivagor
Я вот вообще не помню такой проблемы, что большую игру не возможно запустить... как-то это обходили видимо... Ну и "больших" программ действительно было не так много...
Нашел в архиве В.Фиронова (чего там только нет) запускалку больших файлов для микродос-28. Называется zbfil28.com
Работает нормально (пробовал 2 игрушки: 34 и 40 Кб). Т.е. запускать большие игрушки (для голого вектора) с дискеты можно было и без КД.
Смотрел архив своих дискет (с них были файлы скопированы), на многих дискетах есть программы, размером более 32К (в основном видимо разновидности "реверси"). Дискеты были помечены как "рабочие". Попробую найти образы этих дискет и выяснить/вспомнить как эти "большие" программы запускались...
KTSerg, повторюсь, "проблема" запуска больших программ актуальна только при отсутствии квазидиска. С КД то проблем нет, в РДС, например, TPA аж 62 Кб.
Вот для 6128 оригинальная ОС так до сих пор и не доступна, т.ч. всякие безквазидисковые штуки актуальны и для этого компа.
ivagor, тогда понятно, почему не запомнил проблему... Я сначала Квазидиск купил, а потом контроллер дисковода собрал. Дисководом без Квазидиска и не пользовался наверное никогда.
Сэкономлю немного времени тем, кому интересен архив В.Фиронова.
Архив в основном соответствует каталогу. А в каталоге есть неточности.
CP/M-53 на первом диске: в каталоге написано, что это COMANовский ДОС, но фактически там наследник CP/M-39. Данный CP/M-53 - это вариант CP/M-39 использующий квазидиск для подмены части ОЗУ (а как диск не используется). Это дос для кишиневского КНГМД, не COMANовского.
Путаница связана с совпадением названий - у COMANа тоже был CP/M-53. Только он не требует КД и использует COMANовский КНГМД. Этот дос утерян.
Также проблема с другим COMANовским досом - CP/M-34. На том же диске есть cpm34.com, но это какой то огрызок, на системные дорожки его не запишешь и там части не хватает. CPMZAGR - нечто более законченное, но там надо разбираться.
Похоже COMAN как раз реализовал то, о чем я писал - ДОС без КД в режиме 256 точек с большим TPA. Еще бы они свой несовместимый контроллер не придумывали. Ну и найти бы рабочие варианты их CP/M-34 и CP/M-53.
Дополнение к таблице скорости вывода символов в ДОСах
Чуть-чуть ускорил вывод символов без увеличения размера процедур.Код:rds2.04 - 3640400 тактов=1.2135 секунд=791.1219 символов в секунду
- - - Добавлено - - -
После выкладывания предыдущего варианта сообразил, как можно еще ускорить, опять же без увеличения размера (очень оригинальным способом). С запасом преодолел 800 символов/секунду.
Код:rds2.05 - 3557280 тактов=1.1858 секунд=809.6073 символов в секунду
А о какой ОС речь? Та что шла в комплекте поставки? Так она доступна.Цитата:
Сообщение от ivagor
Я про ДОС, который в руководстве по эксплуатации ПК6128Ц называется ОС6128Ц, а в руководстве программиста ОСа - ОС6128.Цитата:
Сообщение от dk_spb
Там, где я качал доки, образов дисков нет. Интересно посмотреть, поделитесь ссылкой или выложите, если есть возможность.
В 2013 выкладывал системные образы COMANовского CP/M-59 в виде микродосовском формате (fdd 800 Кб).
Теперь собрался и сделал системные образы этого доса в родном формате (trd 640 Кб). На самом деле это не совсем trd, спековские плагины для коммандеров его не понимают, но в emu все работает (возможно он определяет размер сектора по расширению, но это не точно).
После загрузки c "левого" дисковода ( A: ) образ будет доступен как диск C:, с "правого" ( B: ) - как диск B: (очень рекомендую почитать описание CP/M-59)
Чтобы копировать файлы записал в образы POWER.COM. PIP в этом ДОСе капризничает, а POWER копирует нормально.
В "старые" образы тоже добавил POWER.
Для общего понимания, а также для возможности дальнейшей доработки, дизассемблировал МДОСы Т-34 и Т-72, если кому понадобится, выкладываю тут получившиеся исходники с моими скудными и часто неуместными комментариями:
Вложение 68283
Вложение 68286
В каждом архиве есть файлик MAKE.BAT, который компилирует и собирает исходники при помощи TASM, надо только в нём предварительно поправить пути до компилятора.
В исходниках, конечно, есть много мест, которые у меня просто чесались руки поправить/изменить/улучшить, но я оставил всё как есть, так, чтобы при компиляции можно было получить 100% совпадение с исходным бинарным файлом. В случае Т-34 за образец взят файл t34.zip\T34\35\os.com, а для Т-72, соответственно, единственный вариант os-t72.com.
Очень полезное усилие! Открываются возможности написания драйверов, например, можно поддержать нативно SD карту.
Поддерживаю, что усилие очень полезное.
Насчет SD у меня такое видение: поддержка на уровне доса - это хорошо, но для полного счастья, чтобы работали и программы, напрямую лезущие к контроллеру диска, надо и аппаратную поддержку. Как вариант с использованием чего-то вроде лешадока - обращения к контроллеру диска транслируются в обращение к дополнительной памяти на 1-2 Мб. А загрузку образа в эту память с SD делает отдельная утилита. Самую главную часть утилиты - поддержку SD и FAT (16) уже написал b2m в своем xsd. Не хватает собственно аппаратной поддержки по трансляции обращений к ВГ93 в обращения к допОЗУ.
Improver, «меня просто чесались руки» - чесоточный вариант зело интересен
как бы оффтоп:Цитата:
Сообщение от ivagor
вставлю свои 5 копеек, здесь, я уже озвучивал эту идею, но повторюсь.
Я как то задался вопросом, зачем образ с носителя(SD, IDE) загружать в некую дополнительную память, выполняя таким образом монтирование, потом еще и размонтирование с обратной 'выгрузкой' этого образа на носитель, если была запись? Можно же сделать так - использовать список указателей на сектора носителя с нужным образом, и при монтировании этот список указателей просто актуализировать. Объем данных, которые надо обработать существенно меньше, запись выполняется автоматически в правильном месте на носителе и никакое размонтирование не требуется.
Что SD, что IDE имеют размер сектора 512 байт, если используется файловая система FAT16, то для раздела больше 256МБ размер кластера 8КБ, и это нам дает такой расклад - получив один номер сектора - указатель( а это 4 байта), можно адресовать непрерывных 8КБ данных (не нужно заботиться о фрагментированных файлах образов). В одном 512и байтном секторе можно записать 128 четырехбайтных указателя на образ, где один указатель это 8КБ данных, те получится 8кб*128=1024кб - это максимальный размер образа в таком раскладе. Почему только 128 указателей и к чему тут один сектор?! - просто удобно работать с одним сектором и этот сектор будет храниться в простом бинарном файле - базе_указателей - на файловой системе рядом с образами! При монтировании образа будет определяться номер сектора с данными файла базы_указателей и сохраняться куда то на носитель. Вот куда эти четыре байта сохранять это вопрос, пока я думаю о нулевом секторе и смещении 0xF0.
Итог, как все должно работать - при монтировании, программа монтировщик ищет файл базы_указателей, вычисляет номер сектора с данными указателей и сверяет со значением в нулевом секторе по оговоренному смещению, при не совпадении актуализирует. После чего выполняет запись набора указателей на монтируемый образ с шагом в 8КБ в файл базы_указателей. Все монтирование выполнено!
В системе ПК, работа с образом выглядит так - устанавливается номер сектора, сторона, трек диска, вычисляется по этим данным позиция этого сектора в образе, (это выполняется не зависимо от того, как этот образ примонтирован - в неком ОЗУ, или продолжает спокойно размещаться на носителе) и дальше используя лишь функцию чтения сектора носителя, читается нулевой сектор, вычитывается 4 байта указателя для файл базы_указателей, читается сектор с базой_указателей, по базе находится место с запрошенным сектором данных в образе, читается(пишется) запрошенный сектор, все!
Таким образом на чтение(или запись) требуемых данных для ПК выполнится - чтение нулевого сектора, сектора с базой и сектора с требуемых данных для ПК. Чтение нулевого сектора можно опустить, запомнив эти 4 байта, да и сектор с базой можно запомнить, при наличии свободных 512 байт...
Программу монтирования(на базе xsd) по алгоритму описанному выше я уже сделал на 95%, и вычитку данных по сектору базы_указателей на Специалисте уже отладил... Но со Спциалистом проще, там один сектор 1024 байта, а вот со Спектрумовским TRDOS в 256 байт сектором проблема, однако.
Стоит написать, что я поддерживаю любые варианты работы с SD для вектора, не обязательно "полностью совместимые".
Что касается варианта без хранения образа в допОЗУ - можно, конечно и так, особенно если допОЗУ нет. Но я бы в таком случае скорее проголосовал за простейший вариант, который сделал b2m для Башкирии-2М - образ непрерывным файлом на SD карте. Это можно обеспечить или штатными средствами (отформатировать карточку и потом только записывать, не стирать файлы) или, в крайнем случае, написать соответствующую утилиту.
Я присоединяюсь к этому вопросу, только я бы его расширил еще дальше.Цитата:
Сообщение от PVV
Если я правильно понимаю, речь идет все еще о работе с образами FDD. Но по-моему основной кайф поддержки SD нативно состоит в том, что можно будет сделать поддержку FAT и не надо будет делать никаких образов. Я не знаю кому как, а лично я все эти образы терпеть не могу.
Какие теоретические пределы адресации у файловой системы в МикроДОС?
Софт, который хочет дисковод напрямую, это отдельная категория. Понятно, что к нему все это неприменимо. Ну и ладно.
Примерно как у msx dos с современными патчами. Там с sd можно работать без образов, прямо с файлами. Пробовал только на плисовых девбордах, но думаю на реале должно быть примерно так же.Цитата:
Сообщение от svofski
Я так понимаю, твоя идея в том, чтобы полностью переписать МикроДОС? Чтобы это нечто новое работало с FAT и предоставляло API МикроДОС? Это-ж сколько человеко-дней потратить надо! Одно дело - читалка, типа моей xsd, и другое дело полная поддержка файловой системы... Алло, мы ищем таланты! :)Цитата:
Сообщение от svofski
- - - Добавлено - - -
Или ты предлагаешь что-то типа контроллера Морозова?
b2m, я скорее о том, что сказал ivagor - МикроДОС с современными патчами. Человекочасы меня в таких проектах не пугают, никто не торопится и доделывать до конца совсем необязательно ;) Ну что такого страшного в поддержке FAT, или в проекции ее на старые CP/M-ные вызовы? Они все довольно абстрактные, кроме пары особо дурацких, которые надеюсь нечасто используются.
Но это правда большой проект. Для начала можно было бы сделать что-то минимальное -- заменить процедуры работы с дисководом в БДОС на работу с SD картой через, например, xsd (BTW, прости, я не знаю, где быстро посмотреть на xsd, схему и код?). Можно добавлять смещения и разбивать карту на много дискет. Насколько я понимаю поддержка твердых дисков примерно так и работает. Или такое для SD уже сделано?
(Я совсем не имею ввиду, что я сам собираюсь это делать. То есть не надо сидеть, сложа руки и думая, что а, ну это svofski уже все равно что сделал, поддержку FAT и SD карт делать не буду ;) )
да. Суть в том, что если уж менять код на поддержку работы с образами в неком стороннем ОЗУ, то это вариант сделать аналогичный функционал, но без этого стороннего ОЗУ(меньше требуется аппаратных доработок - ~1МБ ОЗУ сделать не совсем тривиальная задача).Цитата:
Сообщение от svofski
посмотреть схемы и код можно здесь, все, что отвечает за работу с FAT взято из xsd на 100%.Цитата:
Сообщение от svofski
- - - Добавлено - - -
Именно таким образом, заменив функции обращения к IDE на SD из кода SDOS(xsd), получил поддержку SD. На своей 'железной' макетке(реале) проверил, работает... Однако там FAT12 была изначально, а это разделы до 32МБ, и переделать такое на FAT16 существенно проще.Цитата:
Сообщение от ivagor
Да уж, если бы сразу в микродосе был FAT, то было бы намного проще. А сейчас вероятность внедрения FAT16 в микродос ненамного выше вероятности адаптации msx dos 2 с fat16 для вектора.Цитата:
Сообщение от PVV
После публикации исходников Т-34, тут уже на две страницы сообщений, к этому добавлю немного, что я думаю по возможному развитию МДОСа...
Ну во-первых, хорошо бы сделать "модульную" операционку, т.е. иметь возможность собрать её для своего железа, по факту наличия различных флоповодов, квазидисков, жестких дисков, необходимости обращения к магнитофону, принтеру, часов и т.д., на первом этапе хотя бы только для известного железа. Возможно это будет некий конфигуратор на ПК, который будет собирать из нужных модулей файл с операционкой.
Во-вторых, развивая её дальше, на основе этих модулей хорошо бы построить некую систему драйверов, хранимых в виде отдельных файлов на КД, выделить так обращение к внешнему оборудованию и развивать их отдельно от операционки. Такая система заметно облегчит создание платы обращения к SD-карте и FAT-драйвера, о чём все уже давно мечтают.
Ещё, кстати, будут актуальны модули-драйвера на PC-клавиатуру (подключаемую к разъёму ПУ), сетевую карту, драйвер для доступа к ROM-картриджу с обращением по букве диска и т.п. В общем, универсальная единая МДОС имеет кучу плюсов при ограниченных на разработку человеко-часах, но только её надо ещё сделать.
А кто как вообще решает проблему создания "адресно не зависимых" программ/драйверов для Вектора, запускаемых с любого адреса?
Я решал через создание таблица адресов, в которых нужно исправить "адреса перехода" или "переменной"... и соответствующего загрузчика...
Может есть более простой путь?
Я не могу у себя найти доки, в которых расписано значение инфы, которую ОС помещает в первые 128 байт памяти Вектора.
Там вроде где-то хранится адрес верхушки свободной памяти и ещё какая-то инфа.
Подкиньте пожалуйста.
Слово по адресу 6 хранит самый младший адрес, используемый операционной системой (или максимальный размер TPA)Цитата:
Сообщение от KTSerg
PPC, спасибо. Нагуглил упомянутый pdf-ник.
Что-то там была ещё какая-то заморочка, что какие-то ДОС-овские программы сами этим пользовались...
Ну, вообще, если совсем по-чесноку, то любая прога, которая хочет работать с памятью и претендует называться CP/M-совместимой, обязана начинать своё исполнение с выяснения, сколько этой памяти есть в наличии. Вот, скажем, релокируемый отладчик SID (или DDT) перед тем, как переместиться в старшие адреса, где он работает, читает значение слова по адресу 6 чтобы выяснить, куда перемещаться.Цитата:
Сообщение от KTSerg
А вот 99% "нативных" Векторовских програм игнорируют среду исполнения и прибивают при запуске BIOS, будучи запущены из МикроДОС. А ведь могли бы определять, что запущены из операционной системы и сохранять его для того, чтобы назад вернуться по окончании программы. Я всегда стараюсь по возможности такой код в прогу вставить.
Кстати, отвечая на ваш вопрос, про relocation table чуть выше в этой ветке: да, все примерно так и делают: либо - битовая таблица, где каждый корректируемый адрес представлен одним, скажем, единичным битом, а остальные адреса - нулевыми, либо - заголовок со словами смещениями в тело программы, где надо править. Первый подход, использует SID, L80 при линковки REL файлов. Второй подход - линкер пакета BDS C (ясно, что линковка это не исполнение программы, но разница в общем невеликая: до динамического редактирования связей - один шаг всего).
Кстати, у меня где-то есть забавный документ, объясняющий как с помощью пальца и палки автоматизировать создание таблиц релокации (там вроде речь про M80/L80, но подойдёт любой ассемблер с макросами и модульной линковкой).
Вот до битовой таблицы я не додумался, когда в 90-ых драйвер мыши писал...Цитата:
Сообщение от PPC
Но там настройщик, загрузчик и сам драйвер занимают чуть больше 1КБ, а сам драйвер от 130 до 160 Байт. Можно было не экономить... :)
Нашел у себя в архиве исходник одной из версий настройщика/загрузчика драйвера мыши, и пару вариантов готового (собранного) драйвера. Но это тестовые варианты, т.к. настроены на "ПУ", а родная мышь была на адресах D5h и D6h, тоже тестовый (работающий с адреса 100) исходник есть.
Вот и пытаюсь в них разобраться, т.к. комментариев в коде практически не делал :( А умные люди говорили: не ленись, делай комменты...
KTSerg, а поделитесь исходником?
В принципе не жалко. Было бы чем делиться. Рабочая дискета с последними рабочими версиями драйвера утеряна. Остались только не понятные, пробные, разрозненные исходники, которые даже друг к другу не подходят.Цитата:
Сообщение от tnt23
Да и Мышь у меня специфическая, с контроллером внутри. Её фото и название я на этом форуме кидал в другой ветке.
Драйвер мыши не работал (в привычном понимании) в чистом ДикроДосе,т.к. в командной строке сильно не поелозишь. Мышка работала в текстовых редакторах работающих под МикроДосом.
При запуске установщика драйвера, запрашивалось коды нажатия каких клавиш генерировать при нажатии кнопок мыши и перемещениях. Введённые коды сохранялись в драйвер и он устанавливался в верхушку свободной памяти. При перемещениях мыши, драйвер подкидывал прямо в буфер МикроДоса коды, как будто были нажаты соответствующие клавиши. По этой причине драйвер работал ещё и с определёнными версиями МикроДоса.
Вот кусок кода установщика драйвера:
А вот такой текст есть в собранном в один файл установщике драйвера.Цитата:
DB ' APRaprапрАПР"Мышь"',0DH,0AH,0AH
DB ' Программирование:',0DH,0AH,0AH
DB ' "Мышь" "Клавиатура"',0DH,0AH,0AH,00H
INF: DB ' Вверх ',00H
DB 0DH,0AH,' Вправо ',00H
DB 0DH,0AH,' Вниз ',00H
DB 0DH,0AH,' Влево ',00H
DB 0DH,0AH,' Левая кн. ',00H
DB 0DH,0AH,' Правая кн. ',00H
INF2: DB 0AH,0AH,' Вы согасны? (Д/Н) ',00H
INF3: DB 0AH,0AH,0DH,' Повторить? (Д/Н) ',00H
INFF1: DB '"F1"',00H
INFF2: DB '"F2"',00H
INFF3: DB '"F3"',00H
INFF4: DB '"F4"',00H
INFTAB: DB '"Таб"',00H
INFR: DB '"Пробел"',00H
INFPS: DB '"Пс"',00H
INFZB: DB '"Зб"',00H
INFWK: DB '"Вк"',00H
INFSTR: DB '"Стр"',00H
INFAR2: DB '"Ар2"',00H
INFLE: DB '"Кур. влево"',00H
INFPR: DB '"Кур. вправо"',00H
INFWE: DB '"Кур. вверх"',00H
INFNI: DB '"Кур. вниз"',00H
INFUS: DB '^'
INFUS1: DB 24H,00H
Цитата:
q ne zna` takoj DOS. izwinite.
KTSerg, ясно. Я думал, это драйвер обычной COM-портовой мыши.
А смысл цеплять к Вектору СОМ-портовую мышь? Она слишком наглая, ей "до лампочки" приняли от неё инфу о перемещениях или нет... для неё контроллер нужен, аппаратные прерывания, и скорость...Цитата:
Сообщение от tnt23
Покопался в ps/2, комп может инициировать отправку данных в клаву или мышь, но синхрой занимается не комп (в отличии от протокола i2c), и нигде не говорится о возможности "притормозить" зажимая синхру...
Значит опять нужен контроллер посредник... :(
(краснея) да я не совсем к Вектору, а вовсе даже к Океану-240, у него RS-232 честный есть с прерываниями.Цитата:
Сообщение от KTSerg
И при таких-то "плюшках" нет софта?Цитата:
Сообщение от tnt23
Может, и был, но до наших дней почти ничего не дошло.Цитата:
Сообщение от KTSerg