Просмотр полной версии : Вектор-06Ц: Операционные системы
NAME MEM BDOS BIOS FDD EDD HDD +
--------------------------------------------------------------------------------
mdos20 (http://www.sensi.org/~svo/scalar/ware/754/) 48K MicroDOS v(3.1) v(2.0) - A -
mdos20a (http://www.sensi.org/~svo/scalar/ware/755/) 48K MicroDOS v(3.1) v(2.0a) - A -
mdos28 (http://www.sensi.org/~svo/scalar/ware/669/) 28K MicroDOS v(3.1) YANUS BIOS 021290 A,B - -
mdos30 (http://www.sensi.org/~svo/scalar/ware/758/) 46K MicroDOS v(3.1) v(3.0) A,B C -
mdos30ha (http://www.sensi.org/~svo/scalar/ware/761/) 45K MicroDOS v(3.1) v(3.0) B C A
mdos31 (http://www.sensi.org/~svo/scalar/ware/762/) 46K MicroDOS v(3.1) v(3.1) A,B C -
mdos31a (http://www.sensi.org/~svo/scalar/ware/759/) 46K MicroDOS v(3.1) v(3.1) - A -
mdos31n (http://www.sensi.org/~svo/scalar/ware/760/) 48K MicroDOS v(3.1) November 1987 - A -
mdos311 (http://www.sensi.org/~svo/scalar/ware/757/) 46K MicroDOS v(3.1) v(3.11.F.11) A,B C -
mdos31h (http://www.sensi.org/~svo/scalar/ware/756/) 45K MicroDOS v(3.1) v(3.1H) D,E(B) C A
mdos34 (http://www.sensi.org/~svo/scalar/ware/763/) 48K MicroDOS v(3.1) v(t-34) A,B C -
mdos72 (http://www.sensi.org/~svo/scalar/ware/630/) 48K MicroDOS v(3.1) v(t-72) A,B C -
dosf142 (http://www.sensi.org/~svo/scalar/ware/697/) 46K MicroDOS v(3.1) c(F.14.2) A,B C -
dosf143 (http://www.sensi.org/~svo/scalar/ware/697/) 46K MicroDOS v(3.1) c(F.14.3) A,B C -
cpm39 (http://www.sensi.org/~svo/scalar/ware/667/) 39K CP/M v(2.2) v(2.5) A,B,C,D - -
cpm59 (http://www.sensi.org/~svo/scalar/ware/671/) 59K CP/M v(2.2) - A - ERAM,ROM
dos201 (http://www.sensi.org/~svo/scalar/ware/668/) 46K MicroDOS v(3.1) v(3.01) A,B C - RTC
В картотеке очередное пополнение (из недавних гостинцев от S.E.S.) - операционная система Т-72 (http://sensi.org/~svo/scalar/ware/630). Выпущена Центром "Тень" (Харьков), который славен очень добротным качественным софтом. В карточке архив с загрузочными образами EDD, FDD.
Вроде как система все та же МикроДОС, но альтернативная версия BIOS, «T-72»? А известно, чем она отличается от всех остальных? Может быть совместима esc-последовательностями с каким-то определенным терминалом, или в нем оптимизированы операции с диском?
Вроде как система все та же МикроДОС, но альтернативная версия BIOS, «T-72»?
Ты намекаешь, что в карточке стоит писать полностью "Операционная система МикроДОС 3.1М с БСВВ версии Т-72"? Я вот подумал, что в основе всех ОС лежит БДОС МикроДОС (RDS - это особый разговор) и легче ссылаться на ОС по ее БСВВ. Но может я и не прав. Можно поменять, пока я не выложил их два десятка.
А известно, чем она отличается от всех остальных? Может быть совместима esc-последовательностями с каким-то определенным терминалом, или в нем оптимизированы операции с диском?
О Т-72 нет информации. Кажется, где-то видел упоминание в одном из электронных журналов, но может это мне приснилось. Есть описание на его предка Т-34. По нему в какой-то степени можно судить об отличиях Т-34 и Т-72 от всех остальных ОС. Выложу позже.
Нет, я не против, что это называется ОС. Может быть потом просто надо тексты тоже проапдейтить, а то даже мне не очень понятно, чем они все отличаются. Чего уж говорить про человека совсем со стороны.
Я вот посмотрел на скриншот и меня посетила догадка, что может быть она поддерживает русские кодировки koi-8 и alt, а то зачем бы они это писали. Вопрос только, как именно она это делает.
Я вот посмотрел на скриншот и меня посетила догадка, что может быть она поддерживает русские кодировки koi-8 и alt, а то зачем бы они это писали. Вопрос только, как именно она это делает.
Некоторые программы в Т-72 стали корректно писать по-русски (не в транслитерации), но не все (sysgen), поэтому я пока не стал ничего выдумывать в карточке про КОИ-8, может найдется описание Т-72 и все станет ясно.
Tim0xA, а эти программы ты в T34 проверял? Некоторые харьковские программы рассчитывали на нее, выводя на экран сообщения в КОИ8 (пример - waveay).
Добавлено через 11 часов 45 минут
Нашел, где было упоминание про систему(ы) серии TXX, отличные от T34
http://sensi.org/%7Esvo/scalar/ware/437/
Цитата:
...
Системые требования
...
4. Операционная система ДОС Т-34 или ДОС Т-62 (и выше).
...
Очень похоже, что T72 попадает в разряд "(и выше)"
Tim0xA, а эти программы ты в T34 проверял? Некоторые харьковские программы рассчитывали на нее, выводя на экран сообщения в КОИ8 (пример - waveay).
Я бегло ознакомился с системой, специально с Т-34 ничего не сравнивал, так что больше ничего конкретного сказать не могу.
подскажите пожалуста, есть ли на Вектор операционка работающая с жёстким диском, но не требующая квазидиск?
Два слова по ОС T72 и T34. Если судить по стартовой надписи в T72 и по описанию T34, то есть как минимум одно отличие - поддержка альтернативной кодировки в T72 в дополнение к КОИ8, которая была единственной восьмибитной кодировкой в T34.
Vadik, есть МикроДОС, который работает с дисководами (диски А,В) и винтом (диск С). Использует ли он квазидиск каким-либо образом - я не знаю. Может тебе будет проще каким-либо образом аппаратно эмулировать дисковод с чистой дискетой, чтобы обмануть ОС, тогда ты получишь доступ к винту.
MDOS30HA использует КД.
A - HDD
B - FDD
C - KD
MDOS30HA использует КД.
A - HDD
B - FDD
C - KD
Хм, чтож, это получается, эмулятор b2m считает, что квазидиск есть, даже если образ не подключен? Это ввело меня в заблуждение.
ОС для FDD без КД
http://sensi.org/%7Esvo/scalar/ware/667/
Как запустить ее в эмуляторе не знаю (пробовал b2m, VV, ve27). Обращается к портам стандартного контроллера (не Coman), в описании указано, что по формату дисков совместима с микродос.
CPM39.COM - вариант из моего архива
CPM39.ROM - из архива Tim0xи
Образ у меня используется лишь для инициализации квазидиска, а если его нет, то квазидиск просто содержит случайные данные.
Судя по всему, этот файл записывается на системные дорожки самым обыкновенным sysgen, абсолютно так же как и mdos34.rom. Я, правда, сделал образ вручную :)
В картотеке переделал. Попробовал генерировать CPM на системные дорожки POWERом, как рекомендуется в описании - работает. Не получилось запустить игрушку длиной 35 Кб (пробовал rockford), хотя обещано до 39. Получилось 32 Кб и меньше (промежуточных от 32 до 35 не проверял).
b2m, ты выбрал для генерации на системные дорожки cpm39.rom - почему? Я попробовал cpm39.com - тоже работает.
ivagor, потому что последовательность
DI
PUSH H
...
POP H
EI
RET
мне показалась более корректной.
Добавлено через 10 минут
Не получилось запустить игрушку длиной 35 Кб (пробовал rockford), хотя обещано до 39
Код загрузки файла располагается в командном процессоре, который лежит в области памяти, доступной программам, т.к. после выхода в систему он снова грузится с диска в память. Т.е. программа может быть длинной только до CCP, но использовать она может все 39 Кб.
потому что последовательность
Код:
DI
PUSH H
...
POP H
EI
RET
мне показалась более корректной.
Поленился я посмотреть, куда попадает различающийся байт, как оказалось зря. Дефектную версию из картотеки изъял.
программа может быть длинной только до CCP
В данном случае это вроде до 8000h?
но использовать она может все 39 Кб.
Т.е. если сначала загрузить программу приемлемого размера (до 8000h), то она сама уже может загрузить что-то и в область 8000h-9600h с использованием процедур ДОС?
Дефектную версию из картотеки изъял.
Ну, я глубже не смотрел, может кому-то понадобилось не запрещать прерывания в этой процедуре :)
Т.е. если сначала загрузить программу приемлемого размера (до 8000h), то она сама уже может загрузить что-то и в область 8000h-9600h с использованием процедур ДОС?
Верхняя граница памяти определяется обычно по вектору перехода к системным функциям ДОС по адресу 0005h, т.е. слово по адресу 0006h. В данной версии это 8806h, что соответствует 34 Кб. Если программа не работает с диском, то она может использовать память вплоть до БИОСа системы, т.е. 9600h = 37,5 Кб. Так что про 39 Кб, по моему, наврали.
Верхняя граница памяти определяется обычно по вектору перехода к системным функциям ДОС по адресу 0005h, т.е. слово по адресу 0006h. В данной версии это 8806h, что соответствует 34 Кб.
В данном конкретном случае это, похоже, не так.
1. Установил в отладчике начальный адрес для просмотра памяти 8000h. Загрузил cpm, посмотрел память, потом сделал DIR и опять посмотрел память, еще я POWER смотрел. Название программы записывается с адреса 8008h.
2. Интереснее с SID. Когда он запущен, в районе 8000 и выше, как я понимаю, часть кода SID. Выходим - и с адреса 8000h у нас снова то же, что было при старте системы.
3. Максимальная длина игрушки, которую удалось загрузить как раз примерно 31,75 Кб, больше не грузит, пишет BAD LOAD.
Т.е. с 8000h в CPM-39 начинается если не сам CCP, то его служебная область памяти.
ССР грузится по адресу 8000h, а с адреса 8806h начинаются обработчики ДОС-функций, а с адреса 9600h идёт уже БИОС системы (обычно драйвер флоппи и вектора обращения к БИОСу терминала). БИОС системы грузит область 8000h-9600h при горячем рестарте (JMP 0h) с диска заново.
b2m
Завершая тему с cpm39 (хочется четко, насколько это возможно, зафиксировать ее характеристики):
1.Позволяет загрузить с диска и запустить программу длиной до 31,75 Кб (с 100h до 7FFFh).
2.Программа при работе может использовать максимально 37,25 Кб (от 100h до 95FFh).
3.Если программа должна работать с диском, то она может использовать максимально 33,75 Кб (от 100h до 8805h). Пример, если я правильно понимаю - SID.
В картотеке ОС DOS201 (http://sensi.org/~svo/scalar/ware/668/) от Гепард (Омск). "Изюминка" DOS201 в том, что она поддерживает часы реального времени и умеет гасить экран, если определенное время никто не трогает клавиатуру (щадящий режим для монитора/телевизора).
В архиве исполняемый файл ОС, а также загрузочные системные образы дисков в форматах EDD и FDD.
В картотеке ОС CP/M-59 (http://sensi.org/~svo/scalar/ware/671) (стандартная CP/M 2.2). Работает с КНГМД Coman и квазидиском (или ERAM). Интересная особенность: имеется возможность создания ПЗУ-диска емкостью до 128кБ. Диск подключается к разъему ПУ по стандарту подключения внешнего ПЗУ (порты 5 и 7 - адрес, 6 - чтение).
А как у ПЗУ-диска переключаться между банками по 64Кб?
А как у ПЗУ-диска переключаться между банками по 64Кб?
Под ПЗУ-диск можно использовать любые виды внешних ПЗУ для Вектора
соответствующие указанному выше стандарту. Например ROM-диски Coman.
Лучше всего использовать м/с ПЗУ 27512 объемом 64кБ.
ROM-диски расчитаны на установку двух таких ПЗУ.
Как бы это смешно ни звучало, переключение банков осуществляется вручную с помощью переключателя (см. Coman-info №14).
Существует омский "картридж", не нуждающийся в ручном переключении ПЗУ и для которого озвучено очень смелое решение достижения емкости в 4Гб:
В картридж можно установить до 3-х сменных м/с ПЗУ. Но это -
далеко не предел. Добавив всего одну м/с, можно устанавливать в кар-
тридж целых 8 сменных ПЗУ. Вообще же схема позволяет иметь 65536
сменных м/с. Это - более 4 гигабайт!
Но о поддержке этого картриджа в СР/M-59 мне не известно.
Видимо, можно считать объявленную емкость диска ПЗУ в 128кб недобросовестной рекламой, т.к. с таким же успехом можно сделать ROM-диск с N-микросхемами 27512, кучей переключателей и объявить емкость ПЗУ-диска в Nx64кб.
Обратил внимание, что Т-72 с загрузочного FDD не запускается, если была выполнена очистка RAM-диска (в VV -> File -> Ram Drive -> Clear RAM Drive). Если в RAM-диск вставить неважно какой образ, то T-72 с FDD запускается. Интересно, это особенность ОС или ошибки в эмуляции? С T-34 такого эффекта не наблюдается.
Добавлено через 1 минуту
Если открыть T-72 через "File -> Open" при очищенном RAM-диске, то эффект тот же.
Добавлено через 16 минут
Если следовать рекомендации
Запуск ДОС не по F12 а по (левый Ctrl+F12)
то Т-72 стартует нормально, но с некоторой задержкой.
ivagor, какова функция клавиши УС при старте Т-72?
Вроде это форматирование КД, причем не только в T-72, хотя в каких еще не помню и сейчас не проверял.
Tim0xA, Я при очистке RAM диска заполняю его память константой $E5, если такой образ сохранить и загрузить в b2m то будет тоже самое.
Незнаю правильно ли я делаю, что заполняю константой, может лучше случайными числами?
Tim0xA, Я при очистке RAM диска заполняю его память константой $E5, если такой образ сохранить и загрузить в b2m то будет тоже самое.
Незнаю правильно ли я делаю, что заполняю константой, может лучше случайными числами?
IMHO, правильнее заполнить его нулями при очистке и при старте, если образ не подключен. Хотя мне трудно предположить, во что это выльется в итоге. Может в настройки добавить параметр, чем заполнять RAM-диск?
Добавлено через 1 час 18 минут
При старте и очистке образ нужно делать таким: c адреса 0x3F000 по 0x3FDFF записать 0x80, остальное пространство 0xE5. Именно такой образ создается плагином к FAR и этот образ не глючит с загрузочной дискетой T-72.
С одного из битых образов FDD удалось восстановить файл mdos28.com - версия МикроДОС для работы без квазидиска. Работоспособность проверена в эмуляторе VV (с опцией "Without RAM drive") http://www.sensi.org/~svo/scalar/ware/669/
Добавлено через 36 минут
В первое сообщение данной темы добавил таблицу существующих ОС для Вектора со ссылками на картотеку. Это еще не все, таблица постепенно будет дополняться, обновляться.
В картотеку добавлены еще две версии ОС Микро-ДОС (BIOS F14.2),(BIOS F14.3) (http://www.sensi.org/~svo/scalar/ware/697/)
Я вот посмотрел на скриншот и меня посетила догадка, что может быть она поддерживает русские кодировки koi-8 и alt, а то зачем бы они это писали. Вопрос только, как именно она это делает.
Насколько я помню, почти все Микродос с БСВВ 3.1 и выше знают про koi-8, но по-умолчанию в них включена koi-7, переключение производилось при помощи esc-последовательностей. На тех дискетах, что есть у меня данная операция производилась из файла initial.sub (вроде так) при загрузке с дискеты.
Перечень Esc последовательностей для T-34 (скорее всего и для 72 подходит, только альтернативная в 34 не поддерживалась) есть в описании этой ОС. Со временем, наверное, Tim0xа дойдет и до нее.
Добавлено через 2 минуты
Есть у кого нибудь DOS FP 14.3 для модифицированного КД? Эмуляторы поддерживают, бейсик модифицированный есть, а запускать его не в чем.
Выложил в картотеку все ОС из первого сообщения данной темы.
Нужна системная дискета для Вектор-06Ц
с набором утилит (sysgen,format,pip и т.д.).
Кишиневский контроллер.
А умеет ли какая-нибудь OS с поддержкой FDD загрузиться не с FDD (например, с магнитофона) и не полезть сразу к дисководу А ?
Получается что если диска нет или неформатирован, то ОС виснет и не выходит на приглашение, хотя КД есть.
В эмуляторах точно также, если КД пустой....
А если попробовать в Линухе записать какой-нибудь образ диска .fdd? Если, конечно, есть PC c 5-тидюймовым дисководом. Утилитой dd, только нужно правильное устройство выбрать: 5 секторов 2 стороны 80 дорожек, размер сектора 1024.
Насколько я понимаю, систему нужно было сначала с магнитофона грузить, а она форматировала КД и записывала себя на него. А уже потом, после сброса, происходило так, как сейчас в эмуляторах.
Вопрос не том как записать, а где взять то, что записать.
Хотя мне уже дали архив с утилитами, но там всё скопом в кучу навалено.
Интересно, существуют "оригинальные" комплекты ОС+утилиты под неё?
Вот я совсем не уверен что ос при загрузке будет что-то с КД делать.
Я тут кучу разных ос перепробовал с магнитофона грузить - либо сразу лезут к дисководу и тупик (не находят себя на вставленной дискете), либо нет поддержки дисковода и дальше непонятно как файлы на КД подгружать....
А уж чтобы загрузить ос с ленты и сделать загрузочную дискету - вообще, похоже, фантастика.
Видимо, был какой-то специальный загрузчик. Эй, вектористы, которые без дисковода работали, отзовитесь! :)
---------- Post added at 00:16 ---------- Previous post was at 00:08 ----------
Гы :) RTFM!
2.1. Загрузка МикроДОС с магнитной ленты.
Успешное завершение загрузки определяется миганием индикатора
РУС/ЛАТ. По окончании загрузки передачу управления МикроДОС производят од-
новременным нажатием клавиши СБР и БЛК. Для передачи управления ОС Микро-
ДОС с автоматическим форматированием электронного диска необходимо удержи-
вая клавишу УС нажать и отпустить клавиши СБР и БЛК, затем отпустить УС.
---------- Post added at 00:19 ---------- Previous post was at 00:16 ----------
Попробовал у себя в эмуляторе, действительно, нужно просто Ctrl удерживать :) Но на КД ничего не записывается, странно.
---------- Post added at 00:50 ---------- Previous post was at 00:19 ----------
Только к дисководу она всё равно лезет, зараза. В эмуляторе просто висит, у меня маркер начала дорожки не "мигает" без диска, может если на реале засунуть диск она как-то отреагирует...
Да никак не отреагирует.
Обратится к диску и повиснет.
А про форматирование КД понятно. А дальше вот что-то никак у меня.
Даже по команде 2 микродоса (копирование с ленты на диск не получается ничего).
Точнее, в эмуляторе висит, потому что контроллер дисковода без образа диска готовность не выдаёт, а реальный контроллер, в принципе, должен готовность выдавать даже если в дисководе диска нет.
---------- Post added at 01:00 ---------- Previous post was at 00:57 ----------
Даже по команде 2 микродоса (копирование с ленты на диск не получается ничего).
Т.е. в микродос она всё-таки выходит? Тогда попробуй без очистки памяти загрузить с магнитофона format.com, по идее должен заработать...
---------- Post added at 01:01 ---------- Previous post was at 01:00 ----------
Т.е. опять-же, удерживая клавишу УС.
Точнее, в эмуляторе висит, потому что контроллер дисковода без образа диска готовность не выдаёт, а реальный контроллер, в принципе, должен готовность выдавать даже если в дисководе диска нет
Да в том-то и дело что дальше идет попытка чего-то читать и всё.....
Т.е. в микродос она всё-таки выходит? Тогда попробуй без очистки памяти загрузить с магнитофона format.com, по идее должен заработать...
Выходят в дос версии без поддержки FDD, а зачем там формат грузить?
---------- Post added at 23:10 ---------- Previous post was at 23:04 ----------
Идея была до безобразия простая и наивная:
1) Загрузить ОС с ленты
2) Директивой 2 ОС скопировать файлы ОС, формат и сисген на КД
3) отфоматировать дискету
4) сделать дискету системной
НО, все оси либо не умеют грузится с ленты (лезут к диску с фатальным исходом), либо не работают с дисководом вообще.
Такой вот тупик...
Да в том-то и дело что дальше идет попытка чего-то читать и всё.....
Ну пытается считать INITIAL.SUB. А можно-же вроде "пропустить" его при загрузке как-то?
Выходят в дос версии без поддержки FDD, а зачем там формат грузить?
Ну, чтобы получить форматированную дискету, чтобы нормальный ДОС с поддержкой флоппи при загрузке с мафона не завис...
Ну, чтобы получить форматированную дискету, чтобы нормальный ДОС с поддержкой флоппи при загрузке с мафона не завис...
Об том и речь......
Я думаю, формат работает с диском напрямую, ему от системы нужен лишь консольный ввод-вывод. Я бы попробовал так:
1. грузим квазидисковую ОС с магнитофона
2. грузим на КД format.com
3. форматируем дискету
4. грузим нормальную ОС с магнитофона
5. грузим на КД sysgen.com и файл с нормальной ОС, например mdos34.com
6. записываем ОС на дискету sysgen-ом
Как сделать пункт номер 2?
Я пробовал пропускать format.com через rom2wav, а потом из-под ос использовать директиву 2.
Но не получается - не видит ос звука....
Как сделать пункт номер 2?
Я пробовал пропускать format.com через rom2wav, а потом из-под ос использовать директиву 2.
Но не получается - не видит ос звука....
Нужно записать файл format.com в магнитофонном формате МикроДОС, rom2wav тут не годится. Это можно сделать через эмулятор. Загрузить в образ квазидиска файл format.com, открыть его в квазидисковом МикроДОС (т.к. процедуры чтения/записи с МЛ в более новых версиях часто выкошены) и "сохранить на ленту" командой 3 FORMAT.COM, включив предварительно запись звука в эмуляторе.
dk_spb, я тоже сначала попробовал rom2wav, который Игорь Титарь написал, и тоже не получилось. Потом покопался в отладчике, и выяснил, что квазидисковый ДОС прежде чем начать читать файл, ожидает преамбулу, минимум 256 байтов 00 или FF. Как-же так подумал я, и сохранил в эмуляторе файл format.com при помощи программы savedos.com из архива http://www.sensi.org/%7Esvo/scalar/ware/693/, после чего в квазидисковом ДОСе файл считался на ура (все действия я делал в своём эмуляторе).
Залить формат получилось.
Работает он и в безфлоповой дос.
Но, как я и боялся, у меня FDC походу битый.
Замена ВГ не помогает.
Какой-то странный ноль у него =1,8V. Причем такой уровень чудесно снимается с выхода инвертора и идет на OE ВА86. И, что не менее интересно, на всех выходах ВА86 такой же уровень, даже когда выходные ноги в воздухе. Если бы там пульсации 0/1 были - пробник бы сказал. Чудеса...
Придётся к осцилографу тащить всё это дело.
dk_spb, Извиняюсь, у Вас на ВГ93, +12 вольт подаётся? Дело в том, что в Кишинёвском варианте они беруться с БП дисковода, т.е. если дисковод не подключен, то 12 вольт не подаються, и ВГ не заводиться.
С уважением.
У меня переходник 5v->12V стоит.
Вчера взял 5V не с компа, а с внешнего БП, от которого флоп запитан.
Проблема с логическими уровнями ушла, но счастья всё-равно нет.
format.com пишет что начинает форматирование, флоп начинает работать и все.
Пробником вижу что идёт активное чтение !!! с дискеты. Сигналы записи с ВГ не идут.
Комп при этом "висит", похоже не получает битик готовности в регистре статуса.
Вот думаю может ВАшку махнуть....
А нет ли у кого описания системных вызовов BDOS ?
(полный список вызовов для всех версий cp/m не предлагать ;-)
Включают доступ к квазидиску нормальным образом (не через стек) в областях:
бит 7 - E000-FFFF
бит 6 - 8000-9FFF
бит 5 - A000-DFFF (это вроде стандарт)
бит 4 - вся область посредством стековых команд
биты 2 и 3 - номер 64Кб-страницы для доступа посредством стековых команд
биты 0 и 1 - номер 64Кб-страницы для нормального доступа
бит 7 - E000-FFFF
бит 6 - 8000-9FFF
Спасибо.
Как я понимаю этого нет в стандартных кишиневском и омском КД?
А какие ОС это понимают и какие без этого не могут?
Есть у кого нибудь DOS FP 14.3 для модифицированного КД? Эмуляторы поддерживают, бейсик модифицированный есть, а запускать его не в чем.
Все еще очень ищется ДОС FP14.3 под улучшенный квазидиск. Бейсик под нее и редактор спрайтов есть, а системы нет.
Еще я конверснул jetset, для цвета требующий модифицированный КД, но для z80.
Тряхнул стариной, немножко поколдовал с фонтами и релизаю обе операционки на 47 и 56K с описаниями и тулкитом.
Вроде теперь любой символ можно отличить визуально (русские А от английских например).
При запуске 56К переформат квазидиска обязателен!
В общем, наслаждайтесь. SysGen.com прилагается в тулах.
Поглядел внимательно на наши МикроДОСы, и обнаружил, что Серёга пропустил один инкремент при определении типа процессора в POST.
И с тех пор, с 94 года POST "определял" любой проц как i8080.
Такого позора я стерпеть больше не смог и пофиксил определялку заодно добавив определение КР580ВМ1 до кучи.
Ну а разогнавшись, дописал определение Омского RTC, так что POST теперь при входе показывает текущее время или ругается что RTC не найдена.
Обе операционки прилагаются. POST запускается удерживанием клавиши УС при нажатии БЛК + ВВД после загрузки системы с диска.
Форматы квазидисков у МикроДОС 56К и 47К несовместимы, при переходе с одной на другую, форматите квазидиск (вот POST и увидите ;) )
Летом 2011 протестировал несколько ДОСов на предмет скорости вывода символов:
Вывод 960 символов
mdos311 - 10106800 тактов=3.3689 секунд=284.9567 символов в секунду
f51 - 9942280 тактов=3.3141 секунд=289.6720 символов в секунду
fph511 - 9939296 тактов=3.3131 секунд=289.7590 символов в секунду
mdosf143 - 9939128 тактов=3.3130 секунд=289.7639 символов в секунду
cpm59 - 9653424 тактов=3.2178 секунд=298.3397 символов в секунду
mdos30 - 9361568 тактов=3.1205 секунд=307.6408 символов в секунду
mdos23 - 9361116 тактов=3.1204 секунд=307.6556 символов в секунду
mdos28 - 9357644 тактов=3.1192 секунд=307.7698 символов в секунду
mdos31 - 9082188 тактов=3.0274 секунд=317.1042 символов в секунду
cpm39 - 7131864 тактов=2.3773 секунд=403.8215 символов в секунду
mdbold56 - 6871404 тактов=2.2905 секунд=419.1283 символов в секунду
mdbold47 - 6191992 тактов=2.0640 секунд=465.1169 символов в секунду
mdos34 - 4059448 тактов=1.3531 секунд=709.4561 символов в секунду
t72 - 3856532 тактов=1.2855 секунд=746.7849 символов в секунду
rds2.01 - 3708984 тактов=1.2363 секунд=776.4930 символов в секунду
Запускал программку в EMU, ставил бряки на начало вывода и конец, получал число тактов (точность эмуляции вектора очень хорошая, думаю тут вопросов нет). Абсолютные цифры IMHO не особо важны, т.к. зависят от конкретной программы, интереснее сравнить относительную скорость вывода символов в разных ОСах.
Несколько сомнительные штуки, но решил все же выложить, в EMU работает.
Пока нет общедоступных копий оригинальных загрузочных дискет для CPM59 (http://sensi.org/~svo/scalar/ware/671/) можно воспользоваться такими самопальными образами:
39493
Используется поддержка этой системой формата диска МикроДОС и то что "дискета любого формата может быть системной"
Стартуем конфиг vector06c-coman, выбираем один из образов для правого (второго) дисковода (можно и в первый вставить, но возникнут кое-какие проблемы), жмем F12.
После старта системы будут доступны 2 диска - A: (ERAM) и F: (второй дисковод с дискетой МикроДОС). Очень рекомендую почитать описание этого ОСа, т.к. названия дисков не очевидны. На образы записан STAT, им можно посмотреть параметры дисков (написал примеры вызова STAT - форум преобразовал их в смайлы, RTFM, короче).
Момент не отмеченный в документации - cpm256 и cpm512/cpm768 ожидают увидеть каталог на МикроДОСовском диске F: на разных дорожках. К счастью в МикроДОС есть команда О.
Можно "сделать" дискету в "родном" формате - создаем файл 655360 байт заполненный E5, даем ему расширение .trd, после вставляем в первый дисковод (обратите внимание, в данном случае это будет буква C: ) и переписываем с F: (или через отладчик в память, потом SAVE на диск) что нужно. Сделать диск "родного" формата системным у меня не получилось, но я в этом не специалист.
Можно сделать ROM-диск и грузить ДОС с него.
Интересная штука (http://zx-pk.ru/showthread.php?t=24194)
Интересная штука (http://zx-pk.ru/showthread.php?t=24194)
Kernel code в main RAM до 0xF000
На практике, без существенных перетолмачиваний для 6128 бы сгодилось, но там только ещё один банк и 8085, а не z80.
В принципе, при определённом количестве свободного времени и наличии исходников, возможно можно портировать с C на 80й ассемблер и завести под Вектор-06ц/02 с квазидиском Баркаря. Но имхо усилий стоит таких же как и написание proprietary многозадачного микрокернела для стандарных Векторов. Я думал на эту тему, взяв за основу что-либо подобное FreeRTOS или Nucleus в смысле планировщика задач, но пришёл к выводу, что в одиночку потребует слишком много лет и усилий.
Если говорить про классические железки, то ERAM вроде почти подходит. Переписывать с C имхо абсолютно не реально, тут лучше супервектор (быстрый z80 + подходящий менеджер памяти) бы подошел.
Если говорить про классические железки, то ERAM вроде почти подходит.
Ну я об этом и написал. Там проблема без переделок выполнение кода возможно только в 16k окнах. Без переделок будет необходим динамический runtime linker (есть статьи, как это сделать для 8080/z80) и своп, а если брать во внимание хотя-бы "старые" задачи под CP/M, то их исполнение даже в режиме "эмуляции" становится цирковым представлением, причём всё равно в однозадачном режиме, ибо.
Проще подумать о простой переделке ERAM маппера и буткода чтобы дома с паяльником можно было повторить, обеспечив возможность мапить любые 16К страницы. Тогда и что либо юниксоподобное становится реальностью и MP/M можно портануть и native задачи (игрушки) можно пускать в монопольном режиме, но обеспечив возврат в систему.
Переписывать с C имхо абсолютно не реально, тут лучше супервектор (быстрый z80 + подходящий менеджер памяти) бы подошел.
Согласен. Я поэтому и писал, что портировать фузикс на асм практически нереально. Проще-по шагам: написать на асме минималистическое мультизадачное ядро, взяв за основу планировщик из какой-нибудь компактной RTOS, а файловые системы, командный язык, консоли и гуи наворотить уже поверх, драйверами. В общем типичный миникернел-наше всё. Но и в этом случае-годы.
Наворотить-то можно что угодно, но супервектор не особо интересует. Он будет ничем не лучше сонма существующих уже "супер" платформ на основе FPGA. ПМСМ будет очередной сфероконь с очень узкой группой потребителей. Ну а как есть (с минимальными переделками буткода и memory маппера), годится только ассемблер. Код на C, даже если брать самый быстрый код, генерируемый C компилятором WhiteSmith от Плаугера (раза в полтора быстрее чем код, генерируемый K&R-нестандартным BDS), всё равно будет раз в 5 менее эффективным по быстродействию, чем то, чего можно добиться асмом.
Совершенно не пытаюсь демотивировать. Просто мои 5c.
Спасибо за наводку на whitesmith, нагуглил пару интересных текстов
ERAM я имел в виду comanовский, КД баркаря и 6128 имхо все же меньше подходят
Полезная вещь (http://zx-pk.ru/showpost.php?p=751217&postcount=5)
ivagor, а тебе никогда не хотелось радикально оптимизировать вывод текста в МикроДОС-е? Мне кажется, что если сделать буферизацию и рисовать по нескольку символов пачками (кратно 4-м, чтобы выравнивать по границам байтов), либо по переполнению буфера, либо по прерыванию, можно ускорить вывод в разы. По крайней мере для наиболее типичных ситуаций, когда выводится много символов подряд один за другим. Или это все уже проверено и существенных выгод не дает?
Не думаю, что смогу заметно обогнать текущих чемпионов (rds и t72), но если оптимизировать какую-нибудь старую версию, то эффект будет заметен, только мне это не особо интересно. А так присоединяюсь, я только за, если кто-нибудь резко ускорит вывод символов в досе.
- - - Добавлено - - -
Имхо главный недостаток векторовских досов - нет "нормальных" версий для hdd или sd. Версии Фролова для hdd, насколько я понял из отзывов реальщиков, работают, но с современным compact flash ведут себя неоднозначно. Версия с поддержкой sd и fat32 была бы очень полезна, в т.ч. для вариантов на плис.
Вчера попробовал разобраться, чем отличаются версии RDS "просто" и для РУ7. В версии для РУ7 2 отличия:
1. Команды обмена информацией с квазидиском вынесены из области A000-DFFF
2. Разделено обращение адресностью и стеком. Во всех других ОСах (использующих КД) это совмещают.
В вектор-user 18 в комментарии к схеме КД на РУ7 написано: "Отзывается на версии ДОС с BIOS 5.1 и подобные".
После этого посмотрел и другие ДОСы. Оказалось, что процедуры обмена информацией с КД расположены в области A000-DFFF только у "базовых" кишиневских версий и "РДС не для РУ7", во всех остальных - за пределами этого участка. ИМХО автор РДС Вьюнов перестраховался, достаточно было п.1 (и, кстати, версия для РУ7 универсальнее, она и на РУ5 и на РУ7 должна работать.
Отмечу, что ограничения скорее всего есть не у всех КД на РУ7, а только у омского и московского (ЦК). У КД Чеботарева (Радиолюбитель) и ERAM с большой вероятностью ограничений нет, но они требуют перепрошивки D36 (в связи с этим интересно, как их использовать с .02). Омский, кстати, требует пару проводков на ВУ вывести, а московский обходится без доработок вектора.
Во флейме про элиту писал, что для программирования палитры хватит двух out, если между ними будет достаточная задержка. Оказалось, что в большинстве ДОСов (кроме кировской версии, РДС и COMANовских для ERAM) так и делают.
Я думал, что достаточно одного, если он аккуратно прицелен в обход сигнала HVSYNCn?
Та ещё "Засада" с программированием палитры...
Напомните, "стандартный" софт типа ОСей, Бейсика, Драйверов, игр, и.т.п. программируют палитру каждое прерывание или только когда это нужно (при старте и изменениях пользователем) ?
Просто если каждое, то сколько это ресурсов тратится на обход сигнала HVSYNCn...
Я думал, что достаточно одного, если он аккуратно прицелен в обход сигнала HVSYNCn?
Там дискуссия протекала примерно так (по памяти):
1. "Вектор, этот комп, в котором на цвет палитры нужно десяток out".
2. Мой ответ был, что хватит двух, если между ними достаточный промежуток. А если тщательно выбрать моменты программирования, то хватит и одного. Вот быстрого варианта (один out/цвет) я нигде не встречал, кроме своего fastpalprog. На этом месте я выпрямляюсь, надуваюсь и гордо гляжу по сторонам.
софт типа ОСей, Бейсика
Справедливости ради - с ОСами не все так плохо. В харьковских (t34, t72), РДС и комановских палитру не долбят постоянно. За что авторам респект.
Ну и я сделал пару (или даже тройку) модификаций бейсика 2.5 без долбежки палитры. Правда они все экзотические и, в отличие от ОСей, относятся к "новому времени".
Еще вчера смотрел двух чемпионов по скорости вывода символов t72 и РДС. В принципе можно еще немного ускорить. Например развернуть циклы. Но если поставить цель сохранить размер TPA, то нужно использовать навороченные квазидиски (Баркаря, Кировский, ERAM) для хранения развернутых процедур. Там 8 процедур (на 8 позиций по горизонтали), при разворачивании в 7/10 раз они неслабо разбухнут. Если уж совсем ничем себя не ограничивать, то можно и фонты предсдвинуть. Это уже где-то на грани или за гранью демомейкерства.
Это уже где-то на грани или за гранью демомейкерства.
Это вполне в рамках игрописательства, если игра текстовая. Но и в 64 колонки немало текста помещается, так что я тоже скептически к такому настроен.
Несколько странно, что в свое время не сделали ни одного варианта ДОСа с числом символов в строке 40 или 32. Для ДОСов без КД это дало бы +8 Кб TPA. Может частью CP/Mовских программ было бы неудобно пользоваться, но для запуска игрушек было бы нормально.
Я хорошо понимаю желание иметь как можно больше текста на одной странице, особенно когда страница такая маленькая, а прокрутка такая медленная.
Для "как можно больше текста на одной странице" с НГМД без КД есть МикроДОС-28 и CP/M-39, а вот для запуска в таких условиях игрушек >=32 Кб ДОСов нет. С другой стороны для запуска игрушек хватило бы какого-нибудь (бездосового) boota, может они даже были, просто я не в курсе.
Для меня было всегда загадкой, как люди с дисководом загружали кассетные игрушки. Мое предположение — разжившись дисководом, векторист все свое время посвящал развитию дисководства и на игры времени просто не оставалось.
А какая процедура бута с дискеты? Как определяется ее бутабельность и можно ли просто посекторно записать на нее .rom ? Это жирновато конечно, особенно для начала 90-х, вряд ли кто бы стал так делать, но все же.
Расширение .com и вперед. Для r0m была отдельная запускалка.
Насколько я понимаю, на системные дорожки можно записать любую программу. В стандартных векторовских ДОСах (для кишиневского КНГМД) каталог на 8й дорожке, т.е. на прогу на системных дорожках остается 40960-128 байт. Стартовый файл SKYNET, например, 32 Кб.
Точно, SKYNET же тому живой пример.
А в чем тогда смысл иметь какой-то другой ДОС для запуска игр?
Думаю, что размещать большие игрушки на системных дорожках неудобно и расточительно (для того времени). Под каждую большую игрушку - отдельная дискета (хотя таких игрушек и мало было). Для CP/M-39 была какая-то утилита для загрузки, но я ее не нашел (возможно она загружает не то, что я предполагаю).
- - - Добавлено - - -
Нашел утилиты cpmgo и cpmload для cp/m-39. К сожалению, они большие файлы не переваривают. CPMGO просто загружает и запускает указанный файл, т.е. единственная польза - можно запускать файлы с любым расширением, хоть .com, хоть .rom.
Думаю, что размещать большие игрушки на системных дорожках неудобно и расточительно (для того времени). Под каждую большую игрушку - отдельная дискета (хотя таких игрушек и мало было). ...
Ну при этом на дискете ведь могли быть и другие игрушки, а не только большая игрушка на системных и всё. У некоторых на системных дорожках вообще ничего не было. А "системными" были только специально выделенные для этой цели дискеты.
Я вот вообще не помню такой проблемы, что большую игру не возможно запустить... как-то это обходили видимо... Ну и "больших" программ действительно было не так много...
Нашел в архиве В.Фиронова (чего там только нет) запускалку больших файлов для микродос-28. Называется zbfil28.com
Работает нормально (пробовал 2 игрушки: 34 и 40 Кб). Т.е. запускать большие игрушки (для голого вектора) с дискеты можно было и без КД.
Смотрел архив своих дискет (с них были файлы скопированы), на многих дискетах есть программы, размером более 32К (в основном видимо разновидности "реверси"). Дискеты были помечены как "рабочие". Попробую найти образы этих дискет и выяснить/вспомнить как эти "большие" программы запускались...
KTSerg, повторюсь, "проблема" запуска больших программ актуальна только при отсутствии квазидиска. С КД то проблем нет, в РДС, например, TPA аж 62 Кб.
Вот для 6128 оригинальная ОС так до сих пор и не доступна, т.ч. всякие безквазидисковые штуки актуальны и для этого компа.
ivagor, тогда понятно, почему не запомнил проблему... Я сначала Квазидиск купил, а потом контроллер дисковода собрал. Дисководом без Квазидиска и не пользовался наверное никогда.
Сэкономлю немного времени тем, кому интересен архив В.Фиронова.
Архив в основном соответствует каталогу (http://sensi.org/scalar/ware/677/). А в каталоге есть неточности.
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.
Дополнение к таблице (http://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=568511&viewfull=1#post568511) скорости вывода символов в ДОСах
rds2.04 - 3640400 тактов=1.2135 секунд=791.1219 символов в секунду
Чуть-чуть ускорил вывод символов без увеличения размера процедур.
- - - Добавлено - - -
После выкладывания предыдущего варианта сообразил, как можно еще ускорить, опять же без увеличения размера (очень оригинальным способом). С запасом преодолел 800 символов/секунду.
rds2.05 - 3557280 тактов=1.1858 секунд=809.6073 символов в секунду
Вот для 6128 оригинальная ОС так до сих пор и не доступна
А о какой ОС речь? Та что шла в комплекте поставки? Так она доступна.
А о какой ОС речь? Та что шла в комплекте поставки? Так она доступна.
Я про ДОС, который в руководстве по эксплуатации ПК6128Ц называется ОС6128Ц, а в руководстве программиста ОСа - ОС6128.
Там (http://retropc.org/Vektor_PK-6128c_s_5.html), где я качал доки, образов дисков нет. Интересно посмотреть, поделитесь ссылкой или выложите, если есть возможность.
В 2013 выкладывал (http://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=570337&viewfull=1#post570337) системные образы COMANовского CP/M-59 в виде микродосовском формате (fdd 800 Кб).
Теперь собрался и сделал системные образы этого доса в родном формате (https://yadi.sk/d/WCpsTJle3SeYH6) (trd 640 Кб). На самом деле это не совсем trd, спековские плагины для коммандеров его не понимают, но в emu все работает (возможно он определяет размер сектора по расширению, но это не точно).
После загрузки c "левого" дисковода ( A: ) образ будет доступен как диск C:, с "правого" ( B: ) - как диск B: (очень рекомендую почитать описание CP/M-59)
Чтобы копировать файлы записал в образы POWER.COM. PIP в этом ДОСе капризничает, а POWER копирует нормально.
В "старые" образы тоже добавил POWER.
Improver
01.03.2019, 09:06
Для общего понимания, а также для возможности дальнейшей доработки, дизассемблировал МДОСы Т-34 и Т-72, если кому понадобится, выкладываю тут получившиеся исходники с моими скудными и часто неуместными комментариями:
68283
68286
В каждом архиве есть файлик MAKE.BAT, который компилирует и собирает исходники при помощи TASM, надо только в нём предварительно поправить пути до компилятора.
В исходниках, конечно, есть много мест, которые у меня просто чесались руки поправить/изменить/улучшить, но я оставил всё как есть, так, чтобы при компиляции можно было получить 100% совпадение с исходным бинарным файлом. В случае Т-34 за образец взят файл t34.zip\T34\35\os.com (http://www.sensi.org/scalar/ware/763/), а для Т-72, соответственно, единственный вариант os-t72.com (http://www.sensi.org/scalar/ware/630/).
Очень полезное усилие! Открываются возможности написания драйверов, например, можно поддержать нативно SD карту.
Поддерживаю, что усилие очень полезное.
Насчет SD у меня такое видение: поддержка на уровне доса - это хорошо, но для полного счастья, чтобы работали и программы, напрямую лезущие к контроллеру диска, надо и аппаратную поддержку. Как вариант с использованием чего-то вроде лешадока - обращения к контроллеру диска транслируются в обращение к дополнительной памяти на 1-2 Мб. А загрузку образа в эту память с SD делает отдельная утилита. Самую главную часть утилиты - поддержку SD и FAT (16) уже написал b2m в своем xsd. Не хватает собственно аппаратной поддержки по трансляции обращений к ВГ93 в обращения к допОЗУ.
Improver, «меня просто чесались руки» - чесоточный вариант зело интересен
Поддерживаю, что усилие очень полезное.
Насчет SD у меня такое видение: поддержка на уровне доса - это хорошо, но для полного счастья, чтобы работали и программы, напрямую лезущие к контроллеру диска, надо и аппаратную поддержку. Как вариант с использованием чего-то вроде лешадока - обращения к контроллеру диска транслируются в обращение к дополнительной памяти на 1-2 Мб. А загрузку образа в эту память с SD делает отдельная утилита. Самую главную часть утилиты - поддержку SD и FAT (16) уже написал b2m в своем xsd. Не хватает собственно аппаратной поддержки по трансляции обращений к ВГ93 в обращения к допОЗУ.
как бы оффтоп:
вставлю свои 5 копеек, здесь (https://zx-pk.ru/threads/29690-sd-karta-dlya-zx-spectrum.html), я уже озвучивал эту идею, но повторюсь.
Я как то задался вопросом, зачем образ с носителя(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 карте. Это можно обеспечить или штатными средствами (отформатировать карточку и потом только записывать, не стирать файлы) или, в крайнем случае, написать соответствующую утилиту.
зачем образ с носителя(SD, IDE) загружать в некую дополнительную память, выполняя таким образом монтирование, потом еще и размонтирование с обратной 'выгрузкой' этого образа на носитель, если была запись?
Я присоединяюсь к этому вопросу, только я бы его расширил еще дальше.
Если я правильно понимаю, речь идет все еще о работе с образами FDD. Но по-моему основной кайф поддержки SD нативно состоит в том, что можно будет сделать поддержку FAT и не надо будет делать никаких образов. Я не знаю кому как, а лично я все эти образы терпеть не могу.
Какие теоретические пределы адресации у файловой системы в МикроДОС?
Софт, который хочет дисковод напрямую, это отдельная категория. Понятно, что к нему все это неприменимо. Ну и ладно.
о по-моему основной кайф поддержки SD нативно состоит в том, что можно будет сделать поддержку FAT и не надо будет делать никаких образов.
Примерно как у msx dos с современными патчами. Там с sd можно работать без образов, прямо с файлами. Пробовал только на плисовых девбордах, но думаю на реале должно быть примерно так же.
Какие теоретические пределы адресации у файловой системы в МикроДОС?
Я так понимаю, твоя идея в том, чтобы полностью переписать МикроДОС? Чтобы это нечто новое работало с FAT и предоставляло API МикроДОС? Это-ж сколько человеко-дней потратить надо! Одно дело - читалка, типа моей xsd, и другое дело полная поддержка файловой системы... Алло, мы ищем таланты! :)
- - - Добавлено - - -
Или ты предлагаешь что-то типа контроллера Морозова?
b2m, я скорее о том, что сказал ivagor - МикроДОС с современными патчами. Человекочасы меня в таких проектах не пугают, никто не торопится и доделывать до конца совсем необязательно ;) Ну что такого страшного в поддержке FAT, или в проекции ее на старые CP/M-ные вызовы? Они все довольно абстрактные, кроме пары особо дурацких, которые надеюсь нечасто используются.
Но это правда большой проект. Для начала можно было бы сделать что-то минимальное -- заменить процедуры работы с дисководом в БДОС на работу с SD картой через, например, xsd (BTW, прости, я не знаю, где быстро посмотреть на xsd, схему и код?). Можно добавлять смещения и разбивать карту на много дискет. Насколько я понимаю поддержка твердых дисков примерно так и работает. Или такое для SD уже сделано?
(Я совсем не имею ввиду, что я сам собираюсь это делать. То есть не надо сидеть, сложа руки и думая, что а, ну это svofski уже все равно что сделал, поддержку FAT и SD карт делать не буду ;) )
Если я правильно понимаю, речь идет все еще о работе с образами FDD.
да. Суть в том, что если уж менять код на поддержку работы с образами в неком стороннем ОЗУ, то это вариант сделать аналогичный функционал, но без этого стороннего ОЗУ(меньше требуется аппаратных доработок - ~1МБ ОЗУ сделать не совсем тривиальная задача).
Для начала можно было бы сделать что-то минимальное -- заменить процедуры работы с дисководом в БДОС на работу с SD картой через, например, xsd (BTW, прости, я не знаю, где быстро посмотреть на xsd, схему и код?).
посмотреть схемы и код можно здесь (https://zx-pk.ru/threads/29892-sd-karta-i-sdos-dlya-8i-bitnykh-pk.html), все, что отвечает за работу с FAT взято из xsd на 100%.
- - - Добавлено - - -
Примерно как у msx dos с современными патчами. Там с sd можно работать без образов, прямо с файлами. Пробовал только на плисовых девбордах, но думаю на реале должно быть примерно так же.
Именно таким образом, заменив функции обращения к IDE на SD из кода SDOS(xsd), получил поддержку SD (http://www.nedopc.org/forum/viewtopic.php?f=96&t=18820&start=30#p143964). На своей 'железной' макетке(реале) проверил, работает... Однако там FAT12 была изначально, а это разделы до 32МБ, и переделать такое на FAT16 существенно проще.
Однако там FAT12 была изначально, а это разделы до 32МБ, и переделать такое на FAT16 существенно проще.
Да уж, если бы сразу в микродосе был FAT, то было бы намного проще. А сейчас вероятность внедрения FAT16 в микродос ненамного выше вероятности адаптации msx dos 2 с fat16 для вектора.
Improver
04.03.2019, 10:43
После публикации исходников Т-34, тут уже на две страницы сообщений, к этому добавлю немного, что я думаю по возможному развитию МДОСа...
Ну во-первых, хорошо бы сделать "модульную" операционку, т.е. иметь возможность собрать её для своего железа, по факту наличия различных флоповодов, квазидисков, жестких дисков, необходимости обращения к магнитофону, принтеру, часов и т.д., на первом этапе хотя бы только для известного железа. Возможно это будет некий конфигуратор на ПК, который будет собирать из нужных модулей файл с операционкой.
Во-вторых, развивая её дальше, на основе этих модулей хорошо бы построить некую систему драйверов, хранимых в виде отдельных файлов на КД, выделить так обращение к внешнему оборудованию и развивать их отдельно от операционки. Такая система заметно облегчит создание платы обращения к SD-карте и FAT-драйвера, о чём все уже давно мечтают.
Ещё, кстати, будут актуальны модули-драйвера на PC-клавиатуру (подключаемую к разъёму ПУ), сетевую карту, драйвер для доступа к ROM-картриджу с обращением по букве диска и т.п. В общем, универсальная единая МДОС имеет кучу плюсов при ограниченных на разработку человеко-часах, но только её надо ещё сделать.
А кто как вообще решает проблему создания "адресно не зависимых" программ/драйверов для Вектора, запускаемых с любого адреса?
Я решал через создание таблица адресов, в которых нужно исправить "адреса перехода" или "переменной"... и соответствующего загрузчика...
Может есть более простой путь?
Я не могу у себя найти доки, в которых расписано значение инфы, которую ОС помещает в первые 128 байт памяти Вектора.
Там вроде где-то хранится адрес верхушки свободной памяти и ещё какая-то инфа.
Подкиньте пожалуйста.
Я не могу у себя найти доки, в которых расписано значение инфы, которую ОС помещает в первые 128 байт памяти Вектора.
Там вроде где-то хранится адрес верхушки свободной памяти и ещё какая-то инфа.
Подкиньте пожалуйста.
Слово по адресу 6 хранит самый младший адрес, используемый операционной системой (или максимальный размер TPA)
PPC, спасибо. Нагуглил упомянутый pdf-ник.
Что-то там была ещё какая-то заморочка, что какие-то ДОС-овские программы сами этим пользовались...
Что-то там была ещё какая-то заморочка, что какие-то ДОС-овские программы сами этим пользовались...
Ну, вообще, если совсем по-чесноку, то любая прога, которая хочет работать с памятью и претендует называться CP/M-совместимой, обязана начинать своё исполнение с выяснения, сколько этой памяти есть в наличии. Вот, скажем, релокируемый отладчик SID (или DDT) перед тем, как переместиться в старшие адреса, где он работает, читает значение слова по адресу 6 чтобы выяснить, куда перемещаться.
А вот 99% "нативных" Векторовских програм игнорируют среду исполнения и прибивают при запуске BIOS, будучи запущены из МикроДОС. А ведь могли бы определять, что запущены из операционной системы и сохранять его для того, чтобы назад вернуться по окончании программы. Я всегда стараюсь по возможности такой код в прогу вставить.
Кстати, отвечая на ваш вопрос, про relocation table чуть выше в этой ветке: да, все примерно так и делают: либо - битовая таблица, где каждый корректируемый адрес представлен одним, скажем, единичным битом, а остальные адреса - нулевыми, либо - заголовок со словами смещениями в тело программы, где надо править. Первый подход, использует SID, L80 при линковки REL файлов. Второй подход - линкер пакета BDS C (ясно, что линковка это не исполнение программы, но разница в общем невеликая: до динамического редактирования связей - один шаг всего).
Кстати, у меня где-то есть забавный документ, объясняющий как с помощью пальца и палки автоматизировать создание таблиц релокации (там вроде речь про M80/L80, но подойдёт любой ассемблер с макросами и модульной линковкой).
...
Кстати, отвечая на ваш вопрос, про relocation table чуть выше в этой ветке: да, все примерно так и делают: либо - битовая таблица, где каждый корректируемый адрес представлен одним, скажем, единичным битом, а остальные адреса - нулевыми,...
Вот до битовой таблицы я не додумался, когда в 90-ых драйвер мыши писал...
Но там настройщик, загрузчик и сам драйвер занимают чуть больше 1КБ, а сам драйвер от 130 до 160 Байт. Можно было не экономить... :)
Нашел у себя в архиве исходник одной из версий настройщика/загрузчика драйвера мыши, и пару вариантов готового (собранного) драйвера. Но это тестовые варианты, т.к. настроены на "ПУ", а родная мышь была на адресах D5h и D6h, тоже тестовый (работающий с адреса 100) исходник есть.
Вот и пытаюсь в них разобраться, т.к. комментариев в коде практически не делал :( А умные люди говорили: не ленись, делай комменты...
KTSerg, а поделитесь исходником?
KTSerg, а поделитесь исходником?
В принципе не жалко. Было бы чем делиться. Рабочая дискета с последними рабочими версиями драйвера утеряна. Остались только не понятные, пробные, разрозненные исходники, которые даже друг к другу не подходят.
Да и Мышь у меня специфическая, с контроллером внутри. Её фото и название я на этом форуме кидал в другой ветке.
Драйвер мыши не работал (в привычном понимании) в чистом ДикроДосе,т.к. в командной строке сильно не поелозишь. Мышка работала в текстовых редакторах работающих под МикроДосом.
При запуске установщика драйвера, запрашивалось коды нажатия каких клавиш генерировать при нажатии кнопок мыши и перемещениях. Введённые коды сохранялись в драйвер и он устанавливался в верхушку свободной памяти. При перемещениях мыши, драйвер подкидывал прямо в буфер МикроДоса коды, как будто были нажаты соответствующие клавиши. По этой причине драйвер работал ещё и с определёнными версиями МикроДоса.
Вот кусок кода установщика драйвера:
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-портовой мыши.
KTSerg, ясно. Я думал, это драйвер обычной COM-портовой мыши.
А смысл цеплять к Вектору СОМ-портовую мышь? Она слишком наглая, ей "до лампочки" приняли от неё инфу о перемещениях или нет... для неё контроллер нужен, аппаратные прерывания, и скорость...
Покопался в ps/2, комп может инициировать отправку данных в клаву или мышь, но синхрой занимается не комп (в отличии от протокола i2c), и нигде не говорится о возможности "притормозить" зажимая синхру...
Значит опять нужен контроллер посредник... :(
А смысл цеплять к Вектору СОМ-портовую мышь?
(краснея) да я не совсем к Вектору, а вовсе даже к Океану-240, у него RS-232 честный есть с прерываниями.
(краснея) да я не совсем к Вектору, а вовсе даже к Океану-240, у него RS-232 честный есть с прерываниями.
И при таких-то "плюшках" нет софта?
И при таких-то "плюшках" нет софта?
Может, и был, но до наших дней почти ничего не дошло.
Improver
11.03.2019, 08:23
Покопался в ps/2, комп может инициировать отправку данных в клаву или мышь, но синхрой занимается не комп (в отличии от протокола i2c), и нигде не говорится о возможности "притормозить" зажимая синхру...
Значит опять нужен контроллер посредник...Тем не менее, клавиатуру PS/2 подключали к Вектору без посредников, прямо в порт ПУ, вся обработка была программная. Может и мышь получится также?
клавиатуру PS/2 подключали к Вектору без посредников, прямо в порт ПУ, вся обработка была программная.
В Волгограде? Просто я читал только про подключение XT-клавиатуры через ПУ (требуется программная поддержка, Платонов, Омск) и подключение AT-клавиатуры через ВУ (вроде подмена векторовской клавиатуры, Саттаров, Киров).
Improver
11.03.2019, 08:44
В Волгограде? Просто я читал только про подключение XT-клавиатуры через ПУ (требуется программная поддержка, Платонов, Омск)Не, в живую не видел, только про это читал и хотел попробовать...
подключение AT-клавиатуры через ВУ (вроде подмена векторовской клавиатуры, Саттаров, Киров).А это как было сделано? Можно ссылку на схемку или описание?
А это как было сделано? Можно ссылку на схемку или описание?
Меня самого очень интересует, как это было сделано, т.к. требуется подмена внутренних портов. Тут или какое-то know how или модификация вектора. Про контроллер AT-клавиатуры я читал в кировской рекламе, эти бумажки я искал, но, к сожалению, не нашел и скорее всего они давно на помойке. В вектор-user 23 есть упоминание контроллера XT-клавиатуры Саттарова, то ли это первый вариант, то ли Фиронов ошибся, а может и я.
только про это читал
А где про это писали?
Improver
11.03.2019, 10:45
В вектор-user 23 есть упоминание контроллера XT-клавиатуры Саттарова, то ли это первый вариант, то ли Фиронов ошибся, а может и я.Да, нашёл, но там только упоминание на три строчки... :(
И ещё нашёл, в номере 30 есть упоминание некоего контроллера на КР1816ВЕ31 (типа ардуино того времени) для мыши от Брескина М.Ю., но схема не приводится, т.к. она "малодоступна", из статьи известно только, что мышь через этот контроллер подключалась к порту джойстика и использовалось стандартное ПО. Не очень удачное решение, думаю.
А где про это писали?Так в том же ВЕКТОР-USER, в №19 почти полторы страницы этому отведено, со схемой подключения и программами на ассемблере.
Так в том же ВЕКТОР-USER, в №19 почти полторы страницы этому отведено, со схемой подключения и программами на ассемблере.
Это вариант Платонова (Омск), я про него упоминал, он рассчитан на XT, не на PS2.
Improver
11.03.2019, 10:58
рассчитан на XT, не на PS2.Ну тогда ой -- спутал разъём со стандартом... :confused:
Ви таки будити смеяться, но похоже, что Вектор таки может работать и с клавой и с мышью по PS/2 подключенными к ПУ.
Сейчас протестировал логгером алгоритм из ВекторЮзера №19. Алгоритм позволяет читать байты поступающие с частотой 22КГц, а клава и мышь работают с часотой 11-13КГц.
Буду тестить дальше.
Только замыкать выводы ВВ55 как указано в схеме, не хочется... буду пробовать подключать через диод.
Ви таки будити смеяться, но похоже, что Вектор таки может работать и с клавой и с мышью по PS/2 подключенными к ПУ.
Ну как бы не Вектор, а программа на Векторе.
Сейчас протестировал логгером алгоритм из ВекторЮзера №19. Алгоритм позволяет читать байты поступающие с частотой 22КГц, а клава и мышь работают с часотой 11-13КГц.
Почему 22 кГц?
Ну как бы не Вектор, а программа на Векторе.
Скажу по другому: быстродействие Вектора должно позволить драйверу, справится с приёмом данных с клавы или мыши.
Почему 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 Гц
Если поделить частоту вектора на длительность команд основного цикла процедуры IBMKey (в тактах), то как раз получится примерно 22 кГц: 3e6/(12+8+12+8+12+12+4+4+8+4+8+12+8+12+12)=приме� �но 22059 Гц
Именно 22059 мне логер показал.
Improver
05.04.2019, 12:27
Продолжаю ковыряться в исходниках МДОС Т-34... Сделал новую версию, теперь уже с изменениями, назвал её Т-34m02 (версию m01 не вижу смысла выкладывать), вот готовый бинарник + исходники в архиве: 68695
Изменения по сравнению со стандартной версией Т-34:
- МДОС откомпилировал на адрес BF00h (так же, как в Т-72), это сократило бинарник, как минимум, на 2Кб и заметно сократило время старта системы. При тестировании после компиляции, кстати, выявились новые моменты, не замеченные в предыдущем варианте исходников (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=1001545&viewfull=1#post1001545).
- Отделил шрифты в свой файл, чтобы не мешали.
- Удалил ненужные (не используемые) блоки данных.
- Исправил и немного сократил некоторые подпрограммы, потасовал их для лучшего заполнения после удаления ненужных блоков.
- Много изменений сделано в программе запуска и размещения в памяти блоков "os~m.asm", в основном из-за перекомпиляции МДОСа.
То, что в итоге получилось погонял в эмуляторе -- всё, вроде, работает, в том числе и коммандер CO.COM. На живом железе проверить не смогу в виду отсутствия флоповодов... Ещё заметил, возможно всем известную, багу в Т-34 и Т-72: при смене дискеты в А: по команде D продолжает показываться содержимое исходной дискеты, на В: такое не наблюдается.
Заметил, что The Lyra II MD (http://www.sensi.org/scalar/ware/272/), которая почему-то не на загрузочном диске, не запускается из под
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
Improver
09.07.2019, 15:58
Improver,шелл типа SamaruX под т34 пойдет?Не могу знать... :v2_dizzy_stupid: Только эксперимент даст ответ на этот вопрос.
Improver
01.10.2019, 11:03
Обновлённая версия операционки Т-72, вместе с исходниками: 70157
Изменения по отношению к оригиналу:
- Убрал все упоминания запуска коммандера CO.COM, т.к. он из Т-72 не работает. Причина его неработоспособности явно в том, что СО.СОМ обращается напрямую к подпрограммам и данным в БСВВ, а в Т-72 там много изменений, легче будет дизассемблировать и поправить СО.СОМ, чем поддерживать эту совместимость.
- Убрал дублирующуюся таблицу параметров флоповода в DPH, т.к. в МДОС допускается совместное использование одной и той же таблицы разными DPH. Возможно это приведёт к проблемам при использовании разных приводов, но, я посмотрел, в других МДОСах такое совмещение тоже встречается, да и по нынешним временам это, думаю, уже не принципиально.
- Убрал таблицу трансляции логических секторов в физические, т.к. в ней особой необходимости, по сути, нет, номера логических и физических секторов всегда совпадают.
- В оригинальной МДОС в Т-72 был интерестный патч: при старте системы производится инициализация дисков, так этот патч заворачивал все обращения к флоповодам на квази-диск, а после инициализации самоликвидировался. Возможно это было сделано для запуска СО.СОМ без дискет, но я решил пойти дальше и теперь обращений к дискам при первой инициализации нет вообще.
- Предыдущий пункт позволил полностью отвязать систему от флоповодов, теперь система стартует даже на моём железном Векторе, где флоповоды отсутствуют физически. При загрузке теперь проверяется квазидиск С: и с него запускается INITIALC.SUB, если будет там найден.
- Ещё одно исправление: теперь при обращении к флоповоду при отсутствии дискеты система не виснет, а задаёт всем известный вопрос "нафик/нефик/пофик" "Пропустить/повторить/отменить". Там хватило бы и последних двух вариантов, но я решил не отходить от традиций.
- Ну и по мелочам, небольшие непринципиальные исправления в алгоритмах всей системы. Файлы "_EF00h.asm" и "_F600h.asm" по отношению к оригиналу изменениям не подвергались, но в архив я их вложил, для комплекта.
А теперь то, ради чего это всё затевалось, первая операционная система для двух квази-дисков, Т-72kd2, вместе с исходниками: 70158
К ней относятся также и все перечисленные выше изменения, плюс сделан диск D:, который показывает содержимое второго КД. Формат второго квази-диска ничем не отличается от первого, стандартного формата. Единственный ньюанс: новая операционка пока не умеет его форматировать и проверять, все другие функции (копирования, запуска программ) работают. Для тестирования этой ОС можно использовать эмулятор "Башкирия-2М (http://bashkiria-2m.narod.ru/index/emul/0-8)", конфигурацию для двух КД можно взять тут (https://zx-pk.ru/threads/8399-f-a-q-po-emulyatoru-bashkiriya-2m.html?p=1028293&viewfull=1#post1028293), за что отдельная благодарность b2m.
Improver
02.10.2019, 16:20
Багфиксинг операционки Т-72, исправленная версия с исходниками: 70169
При тестировании выявилась такая проблемка: в прошлой версии буфер для флоповодов перекрывал буфер для чтения директории, в результате чего содержимое дискеты могло быть испорчено. :(
В версии для двух КД до конца эту багу исправить пока не удалось (ещё надо ужать БСВВ примерно на сотню байт), но пока сделал так, чтобы буфер перекрывал первые символы экранного шрифта. Но есть и положительные моменты: новая версия теперь умеет форматировать и проверять второй КД. Вот архив с исходниками, для тестирования: 70170
Для форматирования второго КД дополнил функционал команды "8" МДОС, теперь можно её использовать так:
8 [<диск> [F]]
где <диск> -- буква диска "С:" или "D:",
"F" -- команда форматирования
Запуск без параметров запускает тестирование первого КД, как и ранее.
Например:
8 C: -- тестирование первого КД
8 D: -- тестирование второго КД
8 C: F -- форматирование первого КД
8 D: F -- форматирование второго КД
Improver
04.10.2019, 09:27
Свежая версия МДОС Т-72 для двух квазидисков, с исходниками: 70228
Для полного исправления проблемы с буферами пришлось пожертвовать следующими функциями:
- Убрал команду "0 хххх M", которая устанавливала режим печати, размер листа и расстояние между строк. Это кому-нибудь актуально?
- Убрал некие добавленные в Т-72 команды "0 хххх S" и "0 хххх V", которые как-то патчили подпрограммы обращения к дискетам. Причём во втором случае была бага в оригинальной Т-72, там повторно использовался ключ "W", в своей версии я его заменил на "V", а теперь убрал вообще. Эти функции были где-то задокументированы? В Т-34 их не было...
- Ну и оптимизировал код БСВВ, в основном свои дополнения и изменения. :)
З.Ы. Заметил интересный глюк, если запустить программу DIR.COM при текущем диске D:, то его содержимое показывается нормально, а если текущим будет любой другой диск (A:, B:, C: ), то по "DIR D:" показывается что-то не то... Но команда МДОС "D" отрабатывает во всех вариантах без ошибок.
Improver
09.10.2019, 13:29
Новая версия Т-72, как всегда с исходниками: 70276
Изменения по отношению к предыдущим версиям:
- Добавил автодетект наличия второго квази-диска, что привело к объединению версий просто "m" и "kd2", и при старте доступные диски показываются корректно, слева скриншот из эмулятора с одним КД, справа -- с двумя (найдите одно отличие ;) ):
70274 70275
- Немного порихтовал область F600-FFFF в БСВВ, за счёт удаления неиспользуемых блоков освободилось чуть больше ста байт для будущих доработок.
- Пропатчил МДОС по рекомендации Виктора Саттарова (см. журнал "Байт-20", стр.129 в pdf (http://www.sensi.org/scalar/ware/553/)), теперь при нажатии БЛК-СБРОС система не виснет.
electroscat
23.03.2020, 00:18
Доброго времени уважаемые !
Вопрос не в тему последних сообщений, но очень интересно, может кто то знает, у оси РДС 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, загружая ось, и нажимая "СБР"+"БЛК" - результат отрицательный...
Поможите чем сумеете ?!? :)
Improver
24.03.2020, 12:47
может кто то знает, у оси РДС 3.02, ну или вообще в целом у РДС есть что то, что она запускает после старта, какой то аналог INITIAL.SUB в МикроДОС? В РДС есть поддержка .BAT с параметрами, неужели нет автозапуска при старте чего либо ?Скорее всего нет, это же подтверждает беглый просмотр файла хекс-редактором.
И еще, прочитал тут про командер СО.СОМ, что это, где можно его скачать и посмотреть? Работет ли он под MicroDOS 3.1H?Не работает. Более того, СО не работает даже под "приемником" Т-34, системой Т-72. В СО просто сделана жёсткая привязка к некоторым адресам БСВВ и прямой вызов подпрограмм...
Киньте ссылочку на программу пожалуйста ?На "базисе (http://www.sensi.org/scalar/ware/791/)" всё есть. :)
Огромный интерес на данный момент есть к РДС 3.02, может быть есть место, где можно разжиться исходниками этой системы, некоторые моменты очень интересны....К сожалению, их нет в доступе, но при наличии дебагера и знаний ассемблера получить можно.
И еще по ходу один вопрос возник.. В "Байт" № 20 на странице 129 описывается доработка, которую Improver воспроизвел в Т-72kd2. Так вот, то же самое я пытался сделать непосредственно в бинарнике mdos31H..Не, такой фокус не пройдёт, при похожести сигнатур там у них может быть совсем другое назначение... Нужно смотреть не бинарники, а исходники. Я начинал копаться в mdos31h (http://www.sensi.org/scalar/ware/756/) (не до конца дизассемблил), но там есть такой код:
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.02 отличие от 3.00 только в организации доступа к квазидиску, причем 3.02 чуть медленнее для совместимости с одним из вариантов кваза на РУ7. Т.е. если 3.00 работает с имеющимся квазом, то у 3.02 нет преимуществ.
Improver
24.03.2020, 13:34
Насколько помню у 3.02 отличие от 3.00 только в организации доступа к квазидиску, причем 3.02 чуть медленнее для совместимости с одним из вариантов кваза на РУ7. Т.е. если 3.00 работает с имеющимся квазом, то у 3.02 нет преимуществ.
Не, судя по приложенным текстовым файлам, были два варианта РДС (n -- номер версии): Rn.COM для квазов на РУ5 и Rn-RU7.COM для РУ7, соответственно. Вот там и были отличия по работе с квазидиском. А третья версия РДС существовала в вариантах 3.00, 3.01 и 3.02 (других не видел), и текстах было упоминание, что исправлялись некие ошибки, так что преимущества должны быть.
Не, судя по приложенным текстовым файлам, были два варианта РДС (n -- номер версии): Rn.COM для квазов на РУ5 и Rn-RU7.COM для РУ7, соответственно. Вот там и были отличия по работе с квазидиском. А третья версия РДС существовала в вариантах 3.00, 3.01 и 3.02 (других не видел), и текстах было упоминание, что исправлялись некие ошибки, так что преимущества должны быть.
r3.com - 3.00
r3-ru7.com - 3.02
При исправление неких ошибок в 3.01 и 3.02 не читал или не помню. Про РУ7 писал здесь (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=949365&viewfull=1#post949365)
electroscat
24.03.2020, 14:28
Огромное спасибо за ответы, исчерпывающе !!!
На "базисе (http://www.sensi.org/scalar/ware/791/)" всё есть. :)
... таким образом система уже пропатчена по рекомендациям из "Байта", запуск её в эмуляторе и нажатия "БЛК-СБР" это подтверждают, патчить там не чего.
Я в эмуляторе не додумался, а на реале, виснет после "БЛК-СБР" ... возможно из за того, что схема моего квазидиска и не на ру 5 и не на ру 7 а на K6T4008C1B, а может и из за чего то еще...
Виснет кстати только голая система, а например при рестарте с ASC.COM - все ок, ASC продолжает работать. В целом, эта проблема не существенна, потому как голой MDOS31H у меня не бывает, следом грузится ASC.COM всегда. Но для понимания машинных кодов и логики хотел это проделать, для саморазвития как бы ....
Попробовал в эмуляторе, EMU V1.01 - результат почти тот же, голая система после нажатия "БЛК-СБР" заливает экрат разными полосками в ряд... На реале это происходит по другому.. Тем не менее...
Improver
24.03.2020, 14:41
r3.com - 3.00
r3-ru7.com - 3.02
При исправление неких ошибок в 3.01 и 3.02 не читал или не помню. Про РУ7 писал здесь (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=949365&viewfull=1#post949365)Может оно и так... Я же исходил из текста письма автора РДС Вьюнова некоему Виктору, которое нашлось на одной из дискет:
Здравствуй, Виктор !
Высылаю тебе всё что ты просил, - все РДС и 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-х, поэтому удали сначала со всех своих дисков старые версии
вышеуказанных программ,а потом с этой дискеты скопируй.
(Далее приводить письмо нет смысла).Из текста письма можно подумать, что варианты для РУ5 и РУ7 существовали и развивались параллельно, но сейчас пересмотрел то, что нашлось у меня из РДС третьей версии:
- R3.COM -- версия 3.00
- R3-RU7.COM -- версия 3.01
- R3-RU7.COM -- версия 3.02
Так что не факт, что они когда-то были, и Вы правы насчёт отличий, но только, думаю, относить их всё же следует к версиям R3 и R3-RU7.
Виктор - это наверняка Виктор Фиронов (https://macrobloger.com/pro-avtora) (Vector-user).
Improver
24.03.2020, 14:49
Я в эмуляторе не додумался, а на реале, виснет после "БЛК-СБР" ... возможно из за того, что схема моего квазидиска и не на ру 5 и не на ру 7 а на K6T4008C1B, а может и из за чего то еще...Это точно не из-за памяти на КД, но, кажется, я догадываюсь, почему она виснет. Было два варианта системы mdos31h, одна из базиса, а вторую я нашёл на образе жёсткого диска для эмулятора, так вот первая пропатчена, а вторая -- нет. :) Попробуйте взять mdos31h с базиса (http://www.sensi.org/scalar/ware/756/).
electroscat
24.03.2020, 15:19
Было два варианта системы mdos31h, одна из базиса, а вторую я нашёл на образе жёсткого диска для эмулятора, так вот первая пропатчена, а вторая -- нет. :) Попробуйте взять mdos31h с базиса (http://www.sensi.org/scalar/ware/756/).
Да, вполне возможно что и не с базиса у меня MDOS31H. Ну и в целом, при сравнении версий в HEX редакторе возможно удастся понять, где таки находится байт, который нужно изменять в массиве настройки.. Благодарю!
Р.С. Попробовал OC.COM - очень продвинутый файловый менеджер, жаль исключительно для T34... Очень качественная оболочка.
Когда у меня был вектор 25 лет назад, я пользовался NC.COM.. Тогда больше ничего не знал,... Сейчас понимаю, что NC.COM пожалуй самая глючная из всез файловых оболочек для вектора.. Но тогда она казалась весьма неплохой )))
electroscat
24.03.2020, 17:52
P.C. попробовал mdos31h с базиса в эмуляторе, виснет при нажатии "сбр-блк"... Может наоборот, патченная в образе была?
Сравниваю mdos31h который у меня везде, и взятый с базиса - HEX редактр заявляет - файлы идентичны.
Можете скинуть ссылку на образ, или ваш вариант mdos31h, который не виснет при нажатии "сбр-блк" ? Пожалуйста _/|\_
Improver
25.03.2020, 12:46
P.C. попробовал mdos31h с базиса в эмуляторе, виснет при нажатии "сбр-блк"... Может наоборот, патченная в образе была?
Сравниваю mdos31h который у меня везде, и взятый с базиса - HEX редактр заявляет - файлы идентичны.
Можете скинуть ссылку на образ, или ваш вариант mdos31h, который не виснет при нажатии "сбр-блк" ? Пожалуйста _/|\_
Интересное дело... Скачал mdos31h с базиса по своей же ссылке выше, смотрю файл в редакторе:
0000016B 3E F7 32 00 00
...
0000019E 3E 23 D3 10 2A 01 00 E9Вот же в нём тот самый патч, о котором я писал ранее (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=1053128&viewfull=1#post1053128). Может файлики попутали? Или я что-то глючу... Проверьте по контрольной сумме MD5:
e11c4fa917b8a16cf11771801285175a *mdos31h.com
Ну и если уж совсем не везёт с ним, вот, продублирую тут: 71936
electroscat
25.03.2020, 13:30
Да, контрольная сумма совпадает, именно этот файл.. Но при нажатии "сбр-блк" виснет, в эмуляторе и в реале %)
Причем абсолютно одинаково и там и там... Странное дело...
https://yadi.sk/i/Cf6HLQhFyhJfZA
Improver
25.03.2020, 16:09
Да, контрольная сумма совпадает, именно этот файл.. Но при нажатии "сбр-блк" виснет, в эмуляторе и в реале %)
Причем абсолютно одинаково и там и там... Странное дело...
https://yadi.sk/i/Cf6HLQhFyhJfZAИ правда что-то не то... Судя по видео, запускаете из эмулятора EMU (он же "Башкирия")? После старта МДОС запустите там отладчик ("View" -> "Start debugger") и посмотрите, что в памяти в ячейке 0000, если там "C3", то МДОС не патченый. Надо обновить системную область диска или заменить на КД файл "OS.COM" новым.
Как вариант, попробуйте открыть правильный файл "mdos31h.com" через меню эмулятора "File" -> "Open...", тип фалов -- все файлы, должно получиться.
У этой проблемы есть простое, но не полное решение. Нужно заменить в файле по смещению 1D67h байт 32h на 00, тогда C3h не будет затирать F7h.
В чем неполнота:
RST гадит на экран, но нельзя просто заменить его на переход в 0030h, т.к. в адреса 1 и 2 лезут очень умные программы типа power. В идеале надо чтобы у доса адреса области переходов на подпрограммы были в районе 0E000-FFFF, как, например, у РДС.
Еще надо бы запрещать прерывания, но тут можно обойтись малой кровью, чуть модифицировав подпрограммку с адреса 0030h.
electroscat
25.03.2020, 16:53
И правда что-то не то... Судя по видео, запускаете из эмулятора EMU (он же "Башкирия")? После старта МДОС запустите там отладчик ("View" -> "Start debugger") и посмотрите, что в памяти в ячейке 0000, если там "C3", то МДОС не патченый. Надо обновить системную область диска или заменить на КД файл "OS.COM" новым.
Как вариант, попробуйте открыть правильный файл "mdos31h.com" через меню эмулятора "File" -> "Open...", тип фалов -- все файлы, должно получиться.
Проблема в том, что я беру ваш файл, или файл с базиса, при помощи 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?
А может система как то варьировать эти вещи при старте сама, при определенных параметрах писать в ячейку с адресом 0 - разные строки кода ?
Кстати, файл который грузится в память и на реале и из эмулятора соответствует файлу с базиса по контрольной сумме...
Improver
25.03.2020, 17:20
У этой проблемы есть простое, но не полное решение. Нужно заменить в файле по смещению 1D67h байт 32h на 00, тогда C3h не будет затирать F7h.Похоже, что да, тут в МДОС затирается адрес 0000, выходит, mdos31h недопатчили... (В Т-72 я этот момент поправлял :) ) Ну один-то байтик ещё заменить -- не проблема же.
RST гадит на экранЭто, наверно, на реале заметно? В эмуляторе я что-то не замечал...
- - - Добавлено - - -
electroscat, замени в файле mdos31h.com (с базиса который) по смещению 1D67h байт 32h на 00h, как посоветовал ivagor и все заработает. :)
Я могу проверить только в эмуляторе, но на реале должно быть аналогично. На скриншоте паразитная точка справа, если еще порестартить, то еще добавятся.
electroscat
25.03.2020, 17:47
electroscat, замени в файле mdos31h.com (с базиса который) по смещению 1D67h байт 32h на 00h, как посоветовал ivagor и все заработает. :)
К сожалению, после замены результат тот же 1 в 1... %)
контрольная сумма MD-5 файла с замененным байтом 2E2E69C64E91C0923358486DC1084146 ...
В эмуляторе все получилось, в точности с точечкой как на скриншоте..
Пойду перепроверю, что я на дискете отнес вектору ))))
Ок, все заработало и на реале... ))) Спасибо ! :v2_dizzy_heart:
Контрольная сумма правильная. Этот вариант должен работать и на реале, стоит проверить например SIDом, что по адресу 0000 байт F7.
А вот насчет запрета прерывания я стормозил, после ресета проц их и так запретит.
electroscat
25.03.2020, 18:03
Я могу проверить только в эмуляторе, но на реале должно быть аналогично. На скриншоте паразитная точка справа, если еще порестартить, то еще добавятся.
Кстати, на реальном компе такая же штука на экране, один в один...
Improver - а у вас нет этих точек на экране после рестарта системы по "ввод+блк"?
Точки обязаны быть и в эмуляторе и на реале. Стек в районе D7xx, после RST там будет адрес возврата 1, а это одинокая точка. Т.к. дос работает со стеком, указатель немного изменяется и точки при нескольких рестартах образуют группу, но строго в одной колонке и все примерно рядом. При скролле они уедут, но если еще рестарить, то обязательно вернуться.
Improver
26.03.2020, 09:01
Точки обязаны быть и в эмуляторе и на реале. Стек в районе D7xx, после RST там будет адрес возврата 1, а это одинокая точка.А, тогда понятно, почему я их не видел. В Т-72 стек находится по адресам от 0E200h и меньше, что находится за границей экранной области, поэтому точки и не появляются. :)
Альтернативный патч mdos31h без мусорения на экране (без rst), на первый взгляд работает.
Improver
27.03.2020, 08:09
Альтернативный патч mdos31h без мусорения на экране (без rst), на первый взгляд работает.Оригинально, но можно ещё немного улучшить, например так:
0000: LXI H, 0B603h
0003: LXI B, 0C300h
0006: NOP
0007: ORA M
0008: MVI A, 023h
000A: OUT 010h
000C: PCHL
electroscat
27.03.2020, 11:51
Альтернативный патч mdos31h без мусорения на экране (без rst), на первый взгляд работает.
Патч работает, в целом, если учитывать то, что нажимать "ввод+блк" если и нужно будет - то совсем не часто - то это 100% работает.
Эксперимента ради я понажимал "ввод+блк" с пристрастием, и в эмуляторе и на реале, и это дало разные результаты. В эмуляторе мусор на экране я так и не увидел, полосок не было. Изредка мигала "карта памяти" на экране, зеленая на черном фоне, при зеленом цвете шрифта, белая - при белом... примерно раз в двадцать нажатий, но на долю секунды. А вот на реальном векторе "полоски" все же иногда вылезали на экран, так же где то раз в двадцать - тридцать нажатий, так же прокручивались, и исчезали в верху экрана. Причем, на этот раз это были не точки а именно полоски, одна максимум две, в одну строку друг от друга. И так же артифакт "карта памяти" иногда на экране мелькал на доли секунды. Все это крайне не существенно, и в целом не требует внимания, потому как такие действия с системой проводятся достаточно редко, и то в виде однократного нажатия "ввод+блк"...
Благодарю !!!
- - - Добавлено - - -
Оригинально, но можно ещё немного улучшить, например так:
0000: LXI H, 0B603h
0003: LXI B, 0C300h
0006: NOP
0007: ORA M
0008: MVI A, 023h
000A: OUT 010h
000C: PCHL
Доброго времени ! Спасибо за патч!
На сколько я понимаю, это первые строки кода оси ? То есть они должны быть такими 21 03 B6 01 00 C3 00 B6 3E 23 D3 10 E9 ? Я не достаточно еще в коде ориентируюсь, вставил приведенный вами код с адреса 00H и получил в целом не совсем работающюю систему. Загрузка ее из ком. строки системы показывает сразу приглашение системы "A>" и в целом все работает, заголовка в левом верхнем углу "микроДОС 3.1 Р ...." нету, и точки иногда таки выскакивают. А вот записав систему в загрузочную область загрузку не получил... Наверняка я что то не понял, куда нужно этот код встраивать ? Судя по адресам - 000H - 000С... или я ошибаюсь ?
- - - Добавлено - - -
У меня есть вопрос такого содержания. Я делал в своей программе выход в МДОС, алгоритм такой, выключаю КД, для освобождения экранной области копирую все с адреса E000H до FFFFH на адресс 5000H - 7FFFH (адресс установил опытно-наблюдательным путем), счетчик стека ставлю на 4FFFH, копирую код из адресов 0001H, 0002H, 0039H, 0040H в переменные и заменяю адресами старта приложения и обработчика прерывания, и потом при выходе все это возвращаю на место, включаю КД и делаю CALL 0005H с 00H в регистре С. Вчера доработал программу, для работы в РДС - она читает адресс системы из 0006Н, 0007H и дальше считает по этим цифрам сколько и куда копировать, и в соответствии с этим же ставит адресс указателя стека. В итоге - в РДС все отлично, огромное количество свободной памяти, а в других системах обратная реакция, для приложения остается совсем не много. В итоге, написал, чтобы если в 0006Н, 0007Н цифра меньше E000H то как предел принимается E000H. Потому что после отключения КД - c адреса, лежащего в 0006H, 0007H - нули и изредка какой то мусор, типа куски символов из консоли, которые уже были на экране, до адреса E000H, и только с этого адреса находится то, что при утере не дает вернуться систему. Пока во всех системах адресс E000H одинаково актуален, кроме РДС, там гораздо меньше, тем не менее очень интересно, есть ли в микродосе и CP/M универсальное место, где можно получить адресс того куска, который нужно скопировать из ОЗУ для того чтобы освободить экранную область, а потом восстановить работоспособность системы ? Ну или, может есть какие то альтернативные алгоритмы выхода в систему для приложений ?
Improver
27.03.2020, 12:13
На сколько я понимаю, это первые строки кода оси ?Это строки, которые должны получится в памяти Вектора после старта МДОС по адресам 0000h и далее. Немного поясню, что это и как работает:
21 03 B6 01 00 C3 00 B6 3E 23 D3 10 E9
^^ -- стандартно тут JMP, в первом патче менялось на RST 6, а в этом варианте меняем на LXI
^^^^^ -- это адрес перехода на МДОС, используется программами
^^ -- тут свободный байт, меняем его на LXI, чтобы отключить JMP в адресе 00005h
^^ -- а вот сюда МДОС пишет номер текущего диска, менять этот байт нельзя
^^^^^^^^ -- на самом деле тут JMP 0B600h, который вызывается по CALL 5
И далее идут команды на включение КД и переход в МДОС.Это всего двумя командами отличается от того, что сделал ivagor в своём патче и принципиальных отличий в работе не имеет, но наложить это на файл mdos31h.com просто так не получится, надо править исходники так, чтобы при старте МДОС в память заносились эти значения.
- - - Добавлено - - -
Я делал в своей программе выход в МДОС ...Что-то как-то всё сложно... Для выхода в МДОС достаточно сделать JMP (или RET) на нулевой адрес. Ну и не трогать в программе память от 0000h до 0100h, а также выше адреса, записанного в ячейках 0001-0002, считается, что это нижняя граница МДОС.
Эксперимента ради я понажимал "ввод+блк" с пристрастием, и в эмуляторе и на реале, и это дало разные результаты. В эмуляторе мусор на экране я так и не увидел, полосок не было. Изредка мигала "карта памяти" на экране, зеленая на черном фоне, при зеленом цвете шрифта, белая - при белом... примерно раз в двадцать нажатий, но на долю секунды. А вот на реальном векторе "полоски" все же иногда вылезали на экран, так же где то раз в двадцать - тридцать нажатий, так же прокручивались, и исчезали в верху экрана. Причем, на этот раз это были не точки а именно полоски, одна максимум две, в одну строку друг от друга. И так же артифакт "карта памяти" иногда на экране мелькал на доли секунды.
И при оригинальном патче (с rst) и при модифицированном видел такую штуку - иногда мигал зеленым бордюр, насчет "карты памяти" не уверен, может это были видеоэффекты залезающие не только на бордюр, но и в активную область. Вероятность таких видеоэффектов вроде была больше при скролле экрана, т.е. при многократном рестарте когда курсор уже внизу и бывает скролл. Детально не разбирался, но предполагаю, что это случается, если рестартовать во время прерывания, поправить это малой кровью вряд ли возможно. Насчет полосок на экране могу тоже предположить, что это связано с прерываниями, но с механизмом возникновения надо разбираться.
- - - Добавлено - - -
Ну и отличия реала от эмуляторов в данном вопросе вряд ли есть, тут я сомневаюсь. Скорее чуть различаются условия запуска и использования.
electroscat
27.03.2020, 12:28
Что-то как-то всё сложно... Для выхода в МДОС достаточно сделать JMP (или RET) на нулевой адрес. Ну и не трогать в программе память от 0000h до 0100h, а также выше адреса, записанного в ячейках 0001-0002, считается, что это нижняя граница МДОС.
Программа работает со всеми четырьмя плоскостями, то есть с 8000 до FFFFH все стирается и меняется. Хотелось бы еще добавить, что программе нужен максимально прямой доступ к ОЗУ, чтобы не тормозить, по этому отключается КД чтобы избежать переадресации части озу на КД.
Так же меняются адреса в 002H, 003H и 039H, 040H чтобы при нажатии "сбр+блк" и наличии прерывания управление передавалось функциям программы. Изначально я пробовал никуда ничего не копирывать (имею в виду с E000H до FFFFH), но система после такого вмешательства не работает.
- - - Добавлено - - -
Это строки, которые должны получится в памяти Вектора после старта МДОС по адресам 0000h и далее. Немного поясню, что это и как работает:
21 03 B6 01 00 C3 00 B6 3E 23 D3 10 E9
^^ -- стандартно тут JMP, в первом патче менялось на RST 6, а в этом варианте меняем на LXI
^^^^^ -- это адрес перехода на МДОС, используется программами
^^ -- тут свободный байт, меняем его на LXI, чтобы отключить JMP в адресе 00005h
^^ -- а вот сюда МДОС пишет номер текущего диска, менять этот байт нельзя
^^^^^^^^ -- на самом деле тут JMP 0B600h, который вызывается по CALL 5
И далее идут команды на включение КД и переход в МДОС.Это всего двумя командами отличается от того, что сделал ivagor в своём патче и принципиальных отличий в работе не имеет, но наложить это на файл mdos31h.com просто так не получится, надо править исходники так, чтобы при старте МДОС в память заносились эти значения.
С этим вообще ничего не понятно пока, простите мне мою глупость, но вы ведь написали код,
Код:
0000: LXI H, 0B603h
0003: LXI B, 0C300h
0006: NOP
0007: ORA M
0008: MVI A, 023h
000A: OUT 010h
000C: PCH
Вот этот код как раз и есть 21 03 B6 01 00 C3 00 B6 3E 23 D3 10 E9 ...
Прошу прощения, не могли бы вы пояснить этот момент ?!?
electroscat, Improver написал то, что должно быть в работающем досе, чтобы так получилось надо поменять несколько байт в разных местах инициализатора mdos31hp2
electroscat
27.03.2020, 12:40
electroscat, Improver написал то, что должно быть в работающем досе, чтобы так получилось надо поменять несколько байт в разных местах инициализатора mdos31hp2
А чтобы их найти, нужно дизасемблировать код и понимать, как он работает, что вообще такое инициализатор, и т.д. правильно я понимаю ? Есть куда расти в общем :D
Improver
27.03.2020, 12:51
Программа работает со всеми четырьмя плоскостями, то есть с 8000 до FFFFH все стирается и меняется.В таком случае проще будет перезапустить МДОС через БЛК-ВВОД, например с КД, чем всё сохранять и восстанавливать. Или использовать КД с доработкой Баркаря, который позволяет подменять квазидиском все верхние 32кб памяти.
Вот этот код как раз и есть 21 03 B6 01 00 C3 00 B6 3E 23 D3 10 E9 ...
Прошу прощения, не могли бы вы пояснить этот момент ?!?Да, это он и есть. Я написал этот код для ivagor, в его варианте сделано так: 01 03 B6 01 00 C3 00 B6 3E 23 D3 10 2A 00 01 E9.
Возможно он примет эти исправления и внесёт их в свой патч, но даже если он этого не сделает -- не страшно, на функционал mdos31hp2.com он не влияет.
- - - Добавлено - - -
А чтобы их найти, нужно дизасемблировать код и понимать, как он работает, что вообще такое инициализатор, и т.д. правильно я понимаю ? Есть куда расти в общем :DДля сведения... МДОС (и РДС тоже) состоит из нескольких модулей, а именно из двух частей БСВВ (базовая система ввода-вывода) и собственно ДОС. И есть инициализатор, который раскидывает эти части в нужные участки памяти и настраивает их. И всё это собрано в один файл, который грузится и запускается с адреса 0100h. И если захотите дизассеблировать ДОС, то инициализатор -- это первое, с чем придётся столкнуться, всё остальное будет в виде массивов данных. :)
electroscat
27.03.2020, 12:53
В таком случае проще будет перезапустить МДОС через БЛК-ВВОД, например с КД, чем всё сохранять и восстанавливать. Или использовать КД с доработкой Баркаря, который позволяет подменять квазидиском все верхние 32кб памяти.
У меня это реализовано в CM.COM. В целом, добавляется пара килобайт кода, но зато и все видео озу доступно, и дос на 100% работает, правда после возврата всего на место и включения КД..... У меня есть идея написать просмотрщик картинок. На данный момент я только один нашел адекватный, но он работает только под Т34, Т35 и Е72, а хотелось бы более универсальный... В итоге, принцип такой же, при желании использовать все видео озу (для просмотрщика графики это актуально)
По другому ничего и не получится наверное. Но не понятно, как одновременно использовать и все экранное озу и возможности mDOS, такие как подгрузка файлов в озу и т.д. В общем, у меня в вязи с этим пока много пробелов. Но интересно..
Наверное нужно начинать с дизасемблирования адекватного просмотрщика и анализа его в дебагере на ос, на которых он не работает.
Насчет борьбы с иногда мелькающим при рестарте зеленым бордюром. Это явно связано с попаданием момента рестарта на программирование палитры. В патч можно добавить зануление бордюра. В более новых досах большинства этих проблем нет, там и палитру постоянно не долбят, и стек за пределами экранной области и область переходов на подпрограммы доса.
electroscat, если разрабатывается новая программа, требующая доступа ко всем экранным плоскостям или просто ко всей основной памяти, то возможно есть смысл ориентироваться на РДС, там же есть для этого специальный режим.
electroscat
27.03.2020, 12:55
Для сведения... МДОС (и РДС тоже) состоит из нескольких модулей, а именно из двух частей БСВВ (базовая система ввода-вывода) и собственно ДОС. И есть инициализатор, который раскидывает эти части в нужные участки памяти и настраивает их. И всё это собрано в один файл, который грузится и запускается с адреса 0100h. И если захотите дизассеблировать ДОС, то инициализатор -- это первое, с чем придётся столкнуться, всё остальное будет в виде массивов данных. :)
Да, как раз это сейчас изучаю, спасибо за ссылки которые присылали мне пол года назад. Очень помогают в изучении !
И вспомнил, вроде в каком-то номере байта был пример освобождения памяти от (более-менее классического, не РДС) доса с последующим восстановлением.
electroscat
27.03.2020, 13:04
Насчет борьбы с иногда мелькающим при рестарте зеленым бордюром. Это явно связано с попаданием момента рестарта на программирование палитры. В патч можно добавить зануление бордюра. В более новых досах большинства этих проблем нет, там и палитру постоянно не долбят, и стек за пределами экранной области и область переходов на подпрограммы доса.
Да это на самом деле не имеет значения, я же писал, не в упрек, так, ради чистоты эксперимента. Даже первый патч - уже очень круто. Все работает, и если учитывать, что важен просто перезапуск системы, то результат 100% удовлетворителен, а полоски и зеленый бордюр - не значительные дополнения.
electroscat, если разрабатывается новая программа, требующая доступа ко всем экранным плоскостям или просто ко всей основной памяти, то возможно есть смысл ориентироваться на РДС, там же есть для этого специальный режим.
В целом, да, у меня была такая идея, но хотелось бы какой то универсальности, либо систему которая впитает в себя все самое лучшее из всех остальных, либо код, работающий на всех системах одинаково. Пока хорошо получилось второе.
- - - Добавлено - - -
И вспомнил, вроде в каком-то номере байта был пример освобождения памяти от (более-менее классического, не РДС) доса с последующим восстановлением.
Поищу, спасибо, может что то дополню еще !
electroscat, похоже я ошибался, отличия в отношении рестарта между некоторыми эмуляторами и реалом есть, хотя пока не ясно, влияет ли это на визуальные эффекты или хотя бы некоторые из них.
electroscat
28.03.2020, 15:08
Да, это он и есть. Я написал этот код для ivagor, в его варианте сделано так: 01 03 B6 01 00 C3 00 B6 3E 23 D3 10 2A 00 01 E9.
Возможно он примет эти исправления и внесёт их в свой патч, но даже если он этого не сделает -- не страшно, на функционал mdos31hp2.com он не влияет.
Прошу простить мне мою назойливость, но очень хочется понять.... Помогите пожалуйста...
Я сравнил код системы mdos31h.com с базиса и патченной системы mdos31hp2.rom от ivagor, изменения внес в таблицу:
Код:
адрес______базис_______патч
16C_________F7_________01
16E_________00_________03
174_________30_________08
19C_________03_________B1
19D_________01_________02
1B1_________00_________3E
1B2_________00_________01
1B3_________00_________32
1B6_________00_________C3
1B7_________00_________03
1B8_________00_________01
1D67________23_________00
И не могу понять вообще соответствия... Изменены байты которых нету в опубликованном вами коде, количество измененных байт разное... В общем, мне хочется верить что вы не колдуны какие то, но разум такая штука, он все что по полкам не может разложить, считает каким то колдовством :D Помогите разобраться хоть немного....
electroscat, упоминавшийся инициализатор доса распихивает байты в нужные места.
1. Базисная версия записывала F7 по адресу 0000, я заменил записываемый байт на 01 и адрес на 0003, отсюда две первые строки сравнения.
2. Раньше фрагмент кода обработки rst пересылался по адресу 0030, теперь с адреса 0008, отсюда третья строка.
3. После пересылки патча был переход по адресу 0103, теперь нужно еще кое-что сделать, поэтому переход на 02B1, отсюда 4 и 5 строки.
4. Строки 6-8 для записи байта 01 по адресу 0000.
5. Строки 9-12 для перехода по адресу 0103.
6. Последняя строка пропатчена, чтобы байт C3 не переписал 01 по адресу 0000.
Чтобы было понятнее надо трассировать в отладчике.
electroscat
28.03.2020, 16:24
Спасибо за ответ !!!
То есть есть часть кода, которая формирует из загруженного массива операционную систему, так ?
И это конфигуратор, вы патчите его, чтобы он формировал систему в памяти так как нужно...
Полегчало ))) А конфигуратор, судя по всему находится с адреса 110H по 1B0H (в базисной версии) или по 1B8H в патченой, по крайней мере конфигуратор области с 0000H по 0100H.... ?
В целом, если разобрать его код, наверняка станет понятнее, буду пробовать. Благодарю за пояснение !!!
То есть есть часть кода, которая формирует из загруженного массива операционную систему, так ?
Можно и так сказать. Что касается адресов, то сам дос (в "перемещаемом" виде) начинается со смещения 200h в файле или с адреса 300h в памяти, все что до этого можно считать относящимся к инициализатору.
Improver
30.03.2020, 09:09
electroscat, для большего понимания (или запутывания) работы инициализатора могу привести его дизассемблированный код:
ORG 00100h
L_0100: JMP L_0210
;---------------------
L_0103: LHLD L_0201 ; загрузить в HL данные с адреса L_0201 (= 2000h)
MOV B, H
MOV C, L ; в BC -- сколько
LDA 00002h ; в А из памяти с адр.00002h
SUB B ; вычесть B из А
MOV D, A
MVI E, 000h ; в DE -- куда
PUSH D
PUSH B
PUSH D
LXI H, L_0300 ; откуда
L_0115: MOV A, B
ORA C
JZ L_0122
DCX B
MOV A, M ; считать по адресу в HL
STAX D ; записать по адресу в DE
INX D
INX H
JMP L_0115
;
L_0122: POP D
POP B
PUSH H
MOV H, D
DCR H
L_0127: MOV A, B
ORA C
JZ L_0145 ; ---------->>>>>>>>
DCX B
MOV A, E
ANI 007h
JNZ L_0138
XTHL
MOV A, M ; ?????? (02300h...026FFh)
INX H
XTHL
MOV L, A
L_0138: MOV A, L
RAL
MOV L, A
JNC L_0141
LDAX D
ADD H
STAX D
L_0141: INX D
JMP L_0127
;
L_0145: POP H
RET ; ==============>>>>>>>>>>>>>>> запуск (0B500h)
; --- вырезано цензурой --------------------------------------------
L_0200: db 000h ; <_> - | | (offset 0100h)
L_0201: db 000h ; <_> - | | (offset 0101h)
db 020h ; < > - | ■ | (offset 0102h)
; --- вырезано цензурой --------------------------------------------
;
L_0210: DI
LXI SP,0100h ; стек == 0100h
LXI H, 0D00h ; сколько
LXI D, L_2700 ; откуда
LXI B, 0F300h ; куда
CALL L_02A6 ; переброска данных
CALL 0F800h ; вызов START BIOS (в т.ч. включение КД)
PUSH H ; ??? -- он и так сохранится...
MVI A, 0C0h
LXI B, 0A020h
MVI B, 0A0h ; почему не LXI B,0A020h ???
MVI C, 020h
;;; LXI B, 0A020h
L_022A: MVI D, 008h ; от HL=0EF00h до HL=0F100h
L_022C: MOV M, A ; заполняем "C0 A0...", "C1 A1...", ...
INX H
MOV M, B
INX H
DCR D
JNZ L_022C
INR A
INR B
DCR C
JNZ L_022A
POP H ; восстанавливаем HL (0EF00h)
LXI B, 00200h
DAD B ; HL = HL+DE = 0F100h
MVI A, 080h
MVI C, 000h
L_0243: MOV M, A ; от HL=0F100h до HL=0F300h
INX H ; заполняем строки "80 80 40 40 ... 01 01"
MOV M, A
INX H
RRC
DCR C
JNZ L_0243
MVI C, 01Bh ; символ очистки экрана
CALL 0F809h ;-BIOS-(вывод символа)----->>>>>>>>>>
MVI C, 045h ; установка латинской клавиатуры
CALL 0F809h ;-BIOS-(вывод символа)----->>>>>>>>>>
LXI H, 128Eh ; сколько
LXI D, L_3400 ; откуда
LXI B, 0D800h ; куда
CALL L_02A6 ; переброска данных (часть 2)
CALL L_468E ; инициализация НЖМД
LXI H, 0D500h ;
SHLD 00001h ; заносим 00 по адресу 0001 и 0D5h по адресу 0002
MVI A, 0F7h
STA 00000h ; заносим RST 6 по адресу 0000
LXI D, L_029E ; откуда
LXI B, 00030h ; куда
LXI H, 00008h ; сколько
CALL L_02A6 ; переброска данных (для RST 6)
IN 001h
ANI 040h ; нажата клавиша УС?
CZ 0D81Bh ; форматнуть КД
MVI A, 081h
OUT 004h
MVI A, 0FFh
OUT 005h
OUT 006h
MVI A, 00Dh
OUT 007h
MVI A, 0EFh
OUT 005h
MVI A, 0FFh
OUT 005h
OUT 007h
JMP L_0103
;
L_029E: db 03Eh ; <>> - | ■■■■■ | (offset 019Eh) (для RST)
db 023h ; <#> - | ■ ■■| (offset 019Fh)
db 0D3h ; <╙> - |■■ ■ ■■| (offset 01A0h)
db 010h ; <_> - | ■ | (offset 01A1h)
db 02Ah ; <*> - | ■ ■ ■ | (offset 01A2h)
db 001h ; <_> - | ■| (offset 01A3h)
db 000h ; <_> - | | (offset 01A4h)
db 0E9h ; <щ> - |■■■ ■ ■| (offset 01A5h)
;
L_02A6: LDAX D ; ПП переброски данных
STAX B
INX D
INX B
DCX H
MOV A, L
ORA H
JNZ L_02A6
RET
;
; --- вырезано цензурой --------------------------------------------
L_0300: db 021h ; <!> - | ■ ■| (offset 0200h)
; --- вырезано цензурой --------------------------------------------
L_0D00: db 00Dh ; <_> - | ■■ ■| (offset 0C00h)
db 03Ah ; <:> - | ■■■ ■ | (offset 0C01h)
; --- вырезано цензурой --------------------------------------------
db 000h ; <_> - | | (offset 21FFh)
;
db 020h ; < > - | ■ | (offset 2200h)
db 002h ; <_> - | ■ | (offset 2201h)
; --- вырезано цензурой --------------------------------------------
db 000h ; <_> - | | (offset 25FEh)
db 000h ; <_> - | | (offset 25FFh)
;
L_2700: db 000h ;(offset 2600h) BIOS >>> F300h
;==== вырезано цензурой =============================================
;
L_3400: db 0C3h ;(offset 3300h) часть 2 >>> D800h
;==== вырезано цензурой =============================================
;
L_468E: XRA A
STA 0E86Fh ; дорожка, =0
MVI A, 0FFh
STA 0E86Dh ; сектор, =-1 (FFh)
CALL 0D82Dh ; ---------->>>>>>>>>>>> грузит сектор в EB00-ED00
JNZ L_468E
LDA 0EB80h ; читает из буфера EB00-ED00 количество секторов
MOV L, A
MVI H, 000h
PUSH H ; (в стек сектора)
SHLD 0D88Dh ; -- сохр. количество секторов НЖМД
CALL L_46CD ; HL = -(HL * 10h) + 1
SHLD 0D887h ; -- патч драйвера НЖМД
POP D ; (сектора из стека)
LXI H, 00000h
LDA 0EB81h ; читает из буфера EB00-ED00 количество головок
L_46B4: DAD D
DCR A
JNZ L_46B4 ; HL = секторов * головок
SHLD 0D8FAh ; -- патч драйвера НЖМД
CALL L_46CD ; HL = -(HL * 10h) + 1
SHLD 0D8F4h ; -- патч драйвера НЖМД
LHLD 0EB84h ; читает из буфера EB00-ED00 количество дискет на НЖМД
CALL L_46D8 ; инверсия HL
DCX H
SHLD 0D920h ; -- патч на максимальное количество дискет НЖМД
RET
;
L_46CD: MVI B, 010h
XCHG
LXI H, 00000h
L_46D3: DAD D
DCR B
JNZ L_46D3
L_46D8: MOV A, H
CMA
MOV H, A
MOV A, L
CMA
MOV L, A
INX H
RET
;
ENDЭто всё получено из файла с Базиса, большие части файла, состоящие из наборов данных (DB...) из текста я просто вырезал, их я дизассемблирвал только частично, в отличие от Т-34 и Т-72, приведённых тут ранее (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=1001545&viewfull=1#post1001545). При необходимости можете посмотреть и восстановить их из исходного файла mdos31h.com...
Можно еще добавить, что фрагмент с L_0122 до L_0145 адаптирует дос на рабочие адреса из "перемещаемого" формата.
Improver
06.04.2020, 13:25
Решил я поизучать тему "заворота" на жёстких дисках начиная с дискеты №42 (2Bh), на примере MDOS31H. В кратце, никаких новых результатов не было найдено, всё, что обнаружил уже обсуждалось тут в форуме, поэтому прячу под спойлер:
1. На количество секторов и количество головок НЖМД отводится по 8 бит, но в расчётах используется формула 1 - (сектора * головки)*10h с сохранением результата в 16 бит, поэтому (сектора * головки) <= 1000h (= 4096), и, соответственно, может быть, например, не больше 16 секторов Х 256 головок, 32х128, 63х65... (По стандарту НЖМД может иметь до 256 головок и до 63 секторов, головки считаются с нулевой, а сектора с первого). По последним данным, есть ограничение (секторов*головок)<256.
2. Количество цилиндров на НЖМД сохраняется в 16 битах (при положенных для стандарта CHS десяти битах), но оно особого значения не имеет и не учитывается, при обращении расчёты ведутся по количеству дискет, секторам и головкам.
3. В БДОС применяется сквозная нумерация секторов (почти как LBA), для этого используется 24 бита, и это даёт максимальный размер диска 8 Гб (при размере сектора 512 байт), после этой границы будет "заворот".
4. Размер дискеты равен 622h (= 1570) секторов, смещение первой на +2 сектора. Первые 8 дорожек дискеты НЖМД системные (8*10 секторов * 512байт = 40960 байт), эта область одна для всех дискет на НЖМД.
5. Максимальное количество целых дискет исходя из п.3 и 4 равно 29BEh = 10686, что укладывается в отведённые 16 бит для хранения их числа, нераспределённый остаток в конце диска до границы в 8 Гб равен 57 секторов или 29184 байта.
6. Обращение к диску в МДОС осуществляется по номеру дорожки и номеру сектора, на оба значения отводится по 8 бит, отсюда ограничение теоретического максимального размера дискеты будет 256*256*128 (размер сектора в МДОС) и равно 8Мб, практически же МДОС видит дискету 164 дорожки * 40 секторов * 128 байт = 839 680 байт.
7. При обращении к НЖМД в БДОС читаются/пишутся по два сектора диска (2*512=1024 байта), что соответствует восьми секторам МДОС (МДОС понимает один размер сектора, 128 байт). БДОС при последовательном чтении копирует данные из буфера в 1кБайт в буфер дисковых операций. При изменении на НЖМД запись данных производится также в размере двух секторов, даже если один из секторов не изменялся.
8. БСВВ (БДОС) выполняется перерасчёт данных полученных от МДОС: лог.номер сектора = 10 * дорожка + 2 * (сектор - 1)/8, что соответствует дискете на 820 кб. Результат сохраняется в 16 бит и потом суммируется с начальным номером сектора дискеты в 24 бит.
9. Максимальное значение дорожки, получаемое БДОС от МикроДОС равно 164 (A4h), при большем значении БДОС возвращает ошибку. Исключение -- можно считать с НЖМД дорожку 0FFh (это нулевой цилиндр с записанной при инициализации конфигурацией).
В общем, могу резюмировать, что никаких особых багов на эту тему в MDOS31H не выявил, диски до 8Гб включительно должны там работать без "заворотов". Есть только предположение, что глюк с "заворотом" может возникать, если прерывание прилетит точно в момент расчёта и передачи на НЖМД номера цилиндра по "OUT 055h" - "OUT 054h", из-за чего там будет большой разрыв по времени и старшие биты обнулятся. Либо, как предполагал ранее, некоторые программы обращаются к функциям БДОС напрямую, при этом сами имеют такой баг. -- Баг найден. (https://zx-pk.ru/threads/9488-vektor-06ts-operatsionnye-sistemy.html?p=1055312&viewfull=1#post1055312)
Но есть и положительные моменты, в ходе разборок с НЖМД собрал версию МикроДОС Т-72 с драйвером жёсткого диска, вот архив с новой версией и исходниками, Т-72h: 72071
Отличия от предыдущей версии:
- Добавлена команда "9" -- выбор дискеты жёсткого диска (работает аналогично mdos31h).
- Из-за нехватки памяти убран драйвер для флоповодов (думаю, его следует вернуть, но для этого понадобится немного подвинуть МДОС, да и сам драйвер надо будет немного переделать). Сейчас при обращении к флопикам просто выдаётся ошибка.
Добавленный драйвер НЖМД, по сравнению с mdos31h, существенно переработан, а именно:
- Добавил запрет прерываний на время записи конфигурации НЖМД, посмотрим, как устранит это глюк с заворотом...
- Размер буфера драйвера уменьшил до одного физического сектора НЖМД, т.е. до 512 Байт.
- Исправил проблему с линией "RESET" на IDE, из-за чего приходилось отключать вывод 1 у жёсткого диска. Теперь тормозов нет, даже если он подключён.
Погонял новую версию МДОСа на эмуляторе и на своём реальном Векторе, работает хорошо и с одним, и с двумя квази-дисками. :-) В новой версии по тестам копирование файлов с одной дискеты НЖМД на другую выполняется раза в полтора быстрее, замерял и по тактам (в эмуляторе), и по времени. Единственный ньюанс: программа FDIR не работает, подвисает до сброса. Надо будет как-нибудь сделать ей замену, уж больно глючна...
Improver, это здорово, но пока проблема с заворотом осталась, по крайней мере у меня. До дискеты 2A включительно все нормально, начиная с 2B - заворот.
Может что-то с параметрами hdd, вот строка из конфига emu
drive[0].geometry=255C16H18S
Или проблема с командой 1 доса, которой я пишу файл
Improver
06.04.2020, 14:04
Improver, это здорово, но пока проблема с заворотом осталась, по крайней мере у меня. До дискеты 2A включительно все нормально, начиная с 2B - заворот.
Может что-то с параметрами hdd, вот строка из конфига emu
drive[0].geometry=255C16H18S
Или проблема с командой 1 доса, которой я пишу файлТак... Команду "1" я ещё не проверял, надо глянуть... Спасибо.
Еще попробовал скопировать файл POWERом - тоже заворот
В кратце, никаких новых результатов не было найдено
Напомни: после получения логического номера сектора там используется LBA, или делается пересчёт в CHS?
Improver
06.04.2020, 15:38
И всё-таки проблема с геометрией, конкретно с головками-секторами, т.к. на моих дисках глюка нет. Копаем дальше. :)
- - - Добавлено - - -
Напомни: после получения логического номера сектора там используется LBA, или делается пересчёт в CHS?Обращение к диску идёт по CHS, просто расчёты ведутся по методу, похожему на LBA. Основное отличие от последнего в битности, LBA использует 28 бит, а Вектор -- 24.
- - - Добавлено - - -
Еще попробовал скопировать файл POWERом - тоже заворотС такой геометрией даже команда "D" даёт заворот.
Насколько я понял код "патча", количество секторов/головок читается из загрузочного сектора (по смещению 80h/81h). То есть параметр в конфиге должен соответствовать образу, т.к. используется CHS. Максимальный номер флоппи-образа должен зависеть от количества дорожек в параметре конфига. Однако природа "заворота" мне до сих пор не ясна.
количество секторов/головок читается из загрузочного сектора (по смещению 80h/81h)
У меня там 18 и 16 (дальше 255), т.е. все соответствует конфигу
- - - Добавлено - - -
С такой геометрией даже команда "D" даёт заворот
А с какой геометрией и близким размером образа нет заворота?
Заинтересовал код расчёта номера сектора:
LXI H, 0F3BEh ; = 2 - 0622h * 2
MVI A, 0FFh
INX B
LaD96A: LXI D, 00622h ; суммарное количество секторов на одной дискете
DAD D
ACI 000h
DCX B
MOV D, A
MOV A, B
ORA C
MOV A, D
JNZ LaD96A
Он везде такой или только у Improver-а?
- - - Добавлено - - -
Вот выкинуть бы всё похожее и сделать нормальные процедуры умножения/деления.
- - - Добавлено - - -
Я так полагаю, кто-то захотел больше 255 образов на винте, но сделал это криво.
Он везде такой или только у Improver-а?
В mdos31h так, в rds не так (как в rds - надо искать)
- - - Добавлено - - -
В РДС3 с моей геометрией тоже заворот на дискете 2B (копировал файл POWERом, на 2A заворота нет).
- - - Добавлено - - -
Оказывается в РДС3 практически аналогичный фрагмент, только поменяли ролями DE и BC, поэтому по сигнатуре я сразу не нашел
А если сделать DCR C и выкинуть модификацию D, то заворот останется?
Но указанный фрагмент вроде работает правильно, проблема где-то еще
Improver
06.04.2020, 17:09
В общем, пробемка с расчётом номера цилиндра, на дискете 2B вместо "00E4h" получаем "0001h". Возможно есть ограничение (головок*секторов)<256, но это не точно, завтра продолжу поиски...
А если сделать DCR C и выкинуть модификацию D, то заворот останется?
Вряд ли в этом есть необходимость, похоже этот фрагмент работает правильно
Блин, опять поднял волну зазря :)
- - - Добавлено - - -
Вот не хотел я в вашем мдосе копаться, но раз уж назвался груздем...
Проблема тут:
MOV H, A ; (HL,E) = (A,HL)
POP B ; для подчистки стека, загружаем временно в BC
CALL L_D9D9 ; проверка готовности НЖМД, получение кода ошибки и RET
PUSH B ; возвращаем BC в стек
ANI 0C0h ; 1110 0000
CPI 040h ; 0100 0000 устройство готово к операции
RNZ ; выход, если не готово
DI ; запрет прерываний на время установки параметров
PUSH D
CALL L_D8F3 ; расчёт номера цилиндра = 00h
OUT 055h ; Цилиндр, младшие биты номера цилиндра
POP D
MOV H, L
MOV L, E
CALL L_D8F3 ; расчёт номера цилиндра = 00h
OUT 054h ; Цилиндр, старшие биты номера цилиндра
Задаём диск 2В. Исходный номер сектора 0101E6h, делим на 120h (18*16 секторов на дорожке). Процедура L_D8F3 делит 16-битное на 16-битное с остатком. Потом двигаем остаток на 8-бит и берём младшие 8 бит, и снова делим на 16-бит.
Проблема только в том, что остаток 16-битный.
О способе деления я умолчу, он тут работает как задумывалось. Но это тоже мрак.
- - - Добавлено - - -
Получается, выражение "секторов*головок" должно быть <256
Не успел. Только я все же хотел впихнуть нормальную процедуру деления 24/16 (быстро нашлась 32/16, поэтому ее), т.к. сейчас эта комбинация делит неправильно. Просто так впихнуть не получается, надо разбираться, где свободное место, уверен, что Improver легко поправит, он знает где там запас.
Я думаю, если выкинуть все эти "патчи" для старой процедуры деления, то место появится.
- - - Добавлено - - -
По-моему, можно даже обойтись процедурой 24/8, первый раз делим на кол-во секторов (остаток - номер сектора-1), второй раз на количество головок (остаток номер головки). Частное (16-битное) - номер цилиндра.
- - - Добавлено - - -
Тогда будет ограничение "цилиндров*головок"<65536 (это если частное 16-битное).
- - - Добавлено - - -
Деление 24/8
MVI C,16 ; HL=AHL/B, A=AHL%B
L1: DAD H
ADC A
JC L2
CMP B
JC L3
L2: SUB B
INR L
L3: DCR C
JNZ L1
RET
По-моему - оптимально.
Сегодня котелок уже не варит, сделал тупо (с делением 24/16 через процедуру 32/16), ну и там еще потупил. Исходник этого сна разума не выкладываю, но бинарник вроде заработал правильно, пусть будет.
Improver
07.04.2020, 08:24
ivagor поскромничал выложить исходники... ;) Попробую сам поправить в Т-72 драйвер на основе кода 24/8 от b2m. Но, с другой стороны, общественный разум опять победил! На этот раз многолетнюю проблему глюка с жёсткими дисками.
P.S. Кстати, появилась идея перевести обращение к диску на LBA, для этого, по сути, будет достаточно дополнить номер сектора с 24 до 28 бит нулями. Это избавит от всех вычислений, привязки к количеству цилиндров/головок/секторов диска и т.п., но только пока не известно, как поведут себя разнообразные CF-карты, комбодевайсы и поддерживают ли эмуляторы Вектора режим LBA для жёстких дисков...
Сделал по заветам b2ma, убрал много лишнего. К этому варианту уже не стыдно приложить исходники, вернее только измененные файлы. Improver, b2m, спасибо!
- - - Добавлено - - -
Забыл спросить один момент. Регистры 55h и 54h - в досах в 54h пишут младший байт, в 55 - старший, в памятке Tim0xи написано наоборот. Если бы оба были по 8 бит, то без разницы, но разрядность старшего меньше, или это только для старых hdd важно а в новых и старший 8 бит?
Improver
07.04.2020, 09:24
Забыл спросить один момент. Регистры 55h и 54h - в досах в 54h пишут младший байт, в 55 - старший, в памятке Tim0xи написано наоборот.Я сначала опирался на инфу с базиса из HDD.TXT (http://www.sensi.org/scalar/ware/537/), и свои комментарии в исходниках ставил по ней, но там скорее всего опечатка, в порт 055h пишутся старшие биты, а в 054h -- младшие.
Сделал по заветам b2m
Можно я поворчу. Процедуру деления я бы на место старой поместил (у тебя лишний jmp), столь короткие метки не стал бы использовать.
А так - да, всё как я и полагал.
- - - Добавлено - - -
И да, цикл чтения/записи сектора я бы разделил. Какой смысл каждые 2 байта анализировать чтение нужно или запись? Ускорение будет 5-10%.
jmp несомненно лишний, я даже убирал оттуда процедуру, но в процессе поиска ошибки (надо было раскомментить mvi d,0) грешил на размещение процедуры, вернул ее под jmp и забыл вернуть обратно. Метки короткие, да нехорошо. Можно даже внутри процедуры все сделать без меток, c $+-. Больше я трогать не буду, лучше Improver доработает (если захочет). Но если еще есть загадки/ошибки, то я всегда готов (если только не очень сложные :) ).
Насчет 55 и 54 похоже действительно опечатка в описании. C ВУ приходит инверсный адрес, они его инвертируют и подают на IDE.
Improver
07.04.2020, 10:44
Я исполнил то, о чём ворчал b2m, удалил лишнее, плюс ещё развернул ненужный уже вызов подпрограммы и собрал все исходники в один архив: 72087
В остальном это вариант ivagor-а.
И не стоит забывать, что в этой версии есть ограничение:
"цилиндров*головок"<65536
- - - Добавлено - - -
И да, цикл чтения/записи сектора я бы разделил. Какой смысл каждые 2 байта анализировать чтение нужно или запись? Ускорение будет 5-10%.В последней версии разделил, для проверки. Прирост в скорости копирования файлов с одной дискеты НЖМД на другую примерно 5%, но это с учётом того, что сейчас расчёт цилиндра/головки/сектора выполняется по новому алгоритму.
Насчет ограничения (цилиндров*головок)<65536. Как я понимаю, максимальный возможный размер в этом случае 4095*16*63*512=2113413120 байт, т.е. >2 Гб. Если понадобится 8 гигов, то можно процедуру деления и апгрейдить, вопрос в востребованности.
Improver
07.04.2020, 12:09
Не останавливаемся на достигнутом. :)
Новая версия, Т-72hl, теперь обращение к диску выполняется в режиме LBA: 72088
Ограничение по размеру диска составляет 8Гб (используются 24 бита, 25..28 -- нули), все остальные ограничения снялись сами собой, единственное, что читается из конфигурации НЖМД -- это максимальное количество дискет. Проверил в эмуляторе, работает с разными дисками корректно, причём скорость возросла ещё примерно на 5%, но вот только на реале проверить не успел, поэтому пока пользуйтесь с долей осторожности...
Запись сектора сейчас требует 92 такта/каждые 2 байта, можно сократить до 84, признак чтения/записи в E вроде не нужно сохранять
L_D8CF:
mov e,m
inx h
mov a,m
out 58h
mov a,e
out 50h
inx h
dcr d
jnz L_D8CF
- - - Добавлено - - -
Познавательный вопрос - винты и CF могут читать по 255 секторов или только по 1?
Improver
07.04.2020, 14:11
Познавательный вопрос - винты и CF могут читать по 255 секторов или только по 1?Ну... Два сектора подряд читают (и пишут) без проблем, больше не пробовал. Подозреваю, что есть желание читать сразу весь файл в память? ;)
- - - Добавлено - - -
Ограничение по размеру диска составляет 8Гб (используются 24 бита, 25..28 -- нули)Кстати, а что если в 25..28 битах использовать не нули? Тогда же можно будет разбивать физический диск на логические, до 16 штук, и переключать их, граница будет в 120Гб, если не ошибаюсь... Или подвинуть используемую Вектором область в конец жёсткого диска, а в начале сделать стандартный раздел для ПК... В общем, тут тоже есть скрытые возможности.
Если максимально развернуть чтение сектора, то чтение байта с записью в память стремится к 28 тактам, пусть с минимальными накладными расходами (раз уж LBA) будет 32. Тогда можно стримить видео без компрессии с винта. При 25 кадрах/секунду успеваем прочитать до 3744 байт, если использовать двойную буферизацию и читать прямо в видеопамять, то это и будет доступный размер кадра. Как использовать - возможны варианты, например при 8 цветах (или оттенках) можно играть в окошке 112x88, при 2 цветах - 192x152. Минута такого видео - примерно 5 Мб.
- - - Добавлено - - -
Чтение, конечно, мимо доса, сугубо "свое".
...
Кстати, а что если в 25..28 битах использовать не нули? Тогда же можно будет разбивать физический диск на логические, до 16 штук, и переключать их, граница будет в 120Гб, если не ошибаюсь... Или подвинуть используемую Вектором область в конец жёсткого диска, а в начале сделать стандартный раздел для ПК... В общем, тут тоже есть скрытые возможности.
Вот сдвинуть образ на CF-карте было бы очень полезно.
Сначала рассчитать размер, и записать на CF-карту "пустой" файл, а за ним всегда будет образ диска для Вектора.
Тогда без заморочек образ можно писать/читать на ПК и без плясок с бубном.
Кстати смещение, может быть заложено в ДОС установкой нужного (25...28) бита в "1".
Упс... CF-карточки обычно не больше 8Г. У меня самая крутая 256М :(
Использовать старшие биты LBA для смещения можно, но как показывает пример KTSerg неудобно. Но это не помеха введению смещения, сейчас оно "жесткое", а можно сделать настраиваемым (пусть даже в рамках 24 бит).
Improver
07.04.2020, 15:43
Ещё один вариант использования смещения: при должном умении, на диске или карте, отформатированной в FAT, можно создать файл, а МДОС с Вектора будет писать точно в эту область. А на ПК этот файл можно использовать, как образ в эмуляторе, единственное, нужно будет следить, чтобы файл физически оставался на тех же секторах диска/карты.
А вот смещение не кратное 8Гб сделать будет немного сложнее, но вполне осуществимо -- нужно просто поправить константы в подпрограмме команды "9", и она будет выдавать увеличенные на нужный размер значения. Ну ещё и доступ к конфигурации диска в нулевой сектор тоже как-то сместить...
- - - Добавлено - - -
Сначала рассчитать размер, и записать на CF-карту "пустой" файл, а за ним всегда будет образ диска для Вектора.Упс... Это та же идея, что и у меня, или "за ним" обозначает немного другой метод?
Но это не помеха введению смещения, сейчас оно "жесткое", а можно сделать настраиваемым (пусть даже в рамках 24 бит).
А смещение пусть загрузчик рассчитывает, с учётом того, что карта/винт отформатирована FAT. Этот код может быть каким угодно большим, он же не будет перемещаться по нужным адресам. Можно даже имя файла запросить/выбрать, если таких образов на карте/винте несколько (в корневой директории). Можно даже наличие таблицы разделов учесть. Часть такого кода можно взять из моей читалки SDOS, которую PVV развивает. Сначала устанавливаем смещение 0, затем вычисляем и устанавливаем смещение нужного раздела (если есть таблица разделов), и под конец - смещение нужного файла.
- - - Добавлено - - -
А вот смещение не кратное 8Гб сделать будет немного сложнее
Просто добавь воды:
LXI D,xxxx
DAD D
ACI yy
после получения 24-битного номера в A,HL
А смещение пусть загрузчик рассчитывает
Хороший вариант, если не для современного винта, а для старого (сравнительно небольшого) или для CF, то твоя реализация FAT16 хорошо подходит. Ну и надо, чтобы фрагментации образа hdd не было.
Improver
07.04.2020, 16:07
Просто добавь воды:
LXI D,xxxx
DAD D
ACI yy
после получения 24-битного номера в A,HL
Я предлагаю проще, изменять константу тут:
LaD954: MOV A, E ; восстанавливаем номер диска
CALL LaD9B2 ; получаем ссылку на нужную таблицу
MOV M, C
INX H
MOV M, B
INX H ; запись в таблицу номера дискеты НЖМД
PUSH H ; сохр.в стек
LXI H, 0F3BEh ; = 2 - 0622h * 2
MVI A, 0FFh
INX B
LaD96A: LXI D, 00622h ; суммарное количество секторов на одной дискете
И тогда не потребуется даже менять подпрограмму чтения/записи сектора... :)
Чуть занудства - FFh в следующей строке тоже надо выделить
нужно будет следить, чтобы файл физически оставался на тех же секторах диска/карты.
А также, чтобы он не был фрагментирован.
- - - Добавлено - - -
Я предлагаю проще, изменять константу тут
От первых 2-х секторов тоже можно отказаться (если останется доступ LBA), количество флоппи-образов рассчитывается исходя из размера файла.
На всякий случай ссылка (https://zx-pk.ru/threads/29892-sd-karta-i-sdos-dlya-8i-bitnykh-pk.html) на тему с текущими реинкарнациями FAT b2mа в развитом PVV виде. Работа с SD оттуда вряд ли понадобится, а FATную часть можно подсмотреть/позаимствовать.
- - - Добавлено - - -
Кстати, а как станет работать такая система с суперзагрузчиком в эмуляторе? Меня больше всего смущает фрагментация. Разве что позиционировать такую систему только для реала.
Меня больше всего смущает фрагментация
Поясни
Improver
07.04.2020, 16:27
Кстати, а как станет работать такая система с суперзагрузчиком в эмуляторе?Правильный вопрос. Загрузчик не будет догадываться обо всех этих смещениях, либо его тоже надо будет обновлять...
Поясни
Я пока не очень представляю, как это может быть организовано, но если внутрь эмулятора дать реальные параметры физического ПКшного диска, то может получиться нехорошо. И образ hdd наверняка будет фрагментирован (у меня точно) и вектор может накуролесить в ПКшном разделе и раздел современного диска вряд ли будет в FAT16. Как вариант - отдельный образ ПКшного диска с FAT16 и файлом с образом hdd внутри.
- - - Добавлено - - -
Ну или компромисс - отдельный раздел FAT16, но это не очень удобно.
И тогда не потребуется даже менять подпрограмму чтения/записи сектора
Не забудь про доступ к дорожкам 0-7 и псевдо-дорожке 255.
- - - Добавлено - - -
если внутрь эмулятора дать реальные параметры физического ПКшного диска
Эмулятор не работает с физическими носителями, только файлы. Придётся копировать образ CF на ПК и обратно.
Либо учитывать в суперзагрузчике, что CF-карта не отформатирована под FAT и тогда в эмуляторе мдос будет работать по-старинке, без смещения. С указанием в конфиге образа (в старом формате) на CF-карте.
Improver
07.04.2020, 17:00
Не забудь про доступ к дорожкам 0-7 и псевдо-дорожке 255.Хорошо, хотя к дорожкам 0-7 доступ нужен крайне редко, но можно это тоже поправить, изменив константу тут:
LDA L_E86D ; дорожка, = FFh при инициализации НЖМД (чтении 1-го сектора)
CPI 008h
JNC L_D85F ; переход если дорожка >= 08h (несистемная область)
LXI D, 00002h
XRA A
JMP L_D86C
А к 255 (или нулевому сектору) вообще доступ будет не обязателен, если задать максимальное количество дискет на диске каким-либо другим способом. Хотя и его расположение тоже правится изменением константы.
к дорожкам 0-7 доступ нужен крайне редко
А он вообще используется? Или мдос грузится из rom-диска?
Если в ДОСе сделать смещение на размер FAT(выяснить, какой он максимальный для CF-карт большого размера) + не большой зазор. То к сожалению и загрузчики подправить нужно будет.
Хотя у меня например, загрузчик с HDD - не большая отдельная программка (адаптированный кусок загрузчика), т.к. на 02-ом до сих пор впаянный заводской загрузчик, в котором есссно нет загрузки с HDD.
А для работы с образом диска в эмуляторе, просто в начало образа нужно будет добавить пустой кусок (вместо FATа), компенсирующий смещение.
- - - Добавлено - - -
...
Упс... Это та же идея, что и у меня, или "за ним" обозначает немного другой метод?
Имелось в виду, что если смещение по размеру больше FAT, то нужно сначала пустым файлом компенсировать размер смещения, и только потом записывать на CF-карту образ HDD.
А фрагментация не возникнет, если карта исправна и на ней нет больше файлов.
Кстати в 90-ых пустыми файлами заполняли битые места на дискетах, при появлении на них не читаемых дорожек. Обзывали файлы типа "err001.err" и продолжали пользоваться дискетой.
svofski, у тебя в картотеке в разделе "розыск" есть mdos3.com (кваз 64Кб). Спасибо что добавил.
mdos3.com (кваз 64Кб)
Это первый вариант доса, использующий только 64 Кб кваза, который я увидел. Скорее всего это тот самый mdos3 (http://www.sensi.org/scalar/ware/672/). Файл из архива Фиронова?
- - - Добавлено - - -
В эмуляторах теперь можно сделать настройку размера кваза 64/256.
- - - Добавлено - - -
Для любителей квазной экзотики дос CP/M 53 (из архива Фиронова). В архиве сам дос и сделал с ним загрузочный диск. Этот дос из серии CP/M 39 (http://www.sensi.org/scalar/ware/667/), отличие в том, что использует всего 16 Кб из кваза, чтобы подменить часть видеопамяти и увеличить TPA (в описании CP/M 39 упомниается CP/M 57, это явно он с измененным названием, т.к. по адресам 1-2 значение E003h). Этот дос, как я понимаю, единственный, который мог работать с этим вариантом (http://www.sensi.org/scalar/ware/746/) КНГМД (+миникваз) при установке в нем РУ6.
В эмуляторах можно сделать настройку размера кваза 16/64/256 Кб.
Improver
08.04.2020, 08:52
А он вообще используется? Или мдос грузится из rom-диска?Дорожки 0-7 используются только загрузчиком в момент загрузки ОС из этой системной области, ну и ещё, например, sysgen-ом, если пользователь захочет обновить систему, в дальнейшей работе МДОС они значения не имеют. Тут ещё есть вариант, если делать сдвиг содержимого НЖМД, то можно оставить их и нулевой сектор на месте, для совместимости с загрузчиками, а перенести в файл только "область дискет".
- - - Добавлено - - -
Запись сектора сейчас требует 92 такта/каждые 2 байта, можно сократить до 84, признак чтения/записи в E вроде не нужно сохранять
L_D8CF:
mov e,m
inx h
mov a,m
out 58h
mov a,e
out 50h
inx h
dcr d
jnz L_D8CF
МДОС Т-72hl с этой поправкой: 72100
Протестил на Векторе, вроде проблем с диском нет (CF-карты тоже, говорят, нормально поддерживают режим LBA). Насколько возросла скорость записи не проверял, но с учётом того, что МДОС больше читает, чем пишет, не думаю, что эта доработка сильно увеличит работу с диском, но пусть лучше будет.
То, что LBAшный дос работает на реале - очень приятное известие.
Самая востребованная операция с записью в досе - вероятно копирование, но чтение, конечно, используется намного чаще. Ускорить чтение можно дозированным разворачиванием цикла. Текущий вариант - 38 тактов/байт, если развернуть в 2 раза, то будет 33 такта/байт, в 4 - 30.5 тактов/байт. Стоит ли ускорение небольшого разбухания кода - затрудняюсь сказать, в 2 раза наверно можно попробовать.
Improver
08.04.2020, 10:37
svofski, у тебя в картотеке в разделе "розыск" есть mdos3.com (кваз 64Кб). Это не оно 72095?Внутри этого МДОСа есть такие строки:
* VECTOR-06C *
* BIOS V(3.1) *
ABC - DISK DRIVE
??K MicroDOS Vers. 3.1
20.12.83
Edition by Shagalin O.A.
Volgograd - 1991
poslednqq korrekciq 03.08.91g. - Shagalin O.A.
Похоже, тут автор известен. :)
- - - Добавлено - - -
То, что LBAшный дос работает на реале - очень приятное известие.
Самая востребованная операция с записью в досе - вероятно копирование, но чтение, конечно, используется намного чаще. Ускорить чтение можно дозированным разворачиванием цикла. Текущий вариант - 38 тактов/байт, если развернуть в 2 раза, то будет 33 такта/байт, в 4 - 30.5 тактов/байт. Стоит ли ускорение небольшого разбухания кода - затрудняюсь сказать, в 2 раза наверно можно попробовать.Может быть и стоит попробовать... Сейчас для этих экспериментов в БДОС есть свободных примерно 600 байт, но надо сначала вернуть работу с флопиками, чтобы было понятно, сколько там места остаётся для разворота.
Этот дос, как я понимаю, единственный, который мог работать с этим вариантом КНГМД (+миникваз) при установке в нем РУ6.
Выразился не совсем корректно. Этот дос единственный известный, которому хватит кваза на РУ6 на том астраханском КНГМД. ДОСы не использующие кваз (МикроДОС 28 и CP/M 39) конечно тоже должны работать с тем КНГМД.
svofski, у тебя в картотеке в разделе "розыск" есть mdos3.com (кваз 64Кб). Это не оно 72095?
Я добавил http://sensi.org/scalar/ware/672/
NB Вообще я совершенно запутался в этой теме. Количество микродосов и их вариантов мне не дано охватить. Даже старых многовато, а текущие разработки, которые оседают в аттачах и проваливаются на минус десятую страницу форума за два дня, и подавно. Принимаю корректировки, можно в личку.
Количество микродосов и их вариантов
Собственно МикроДОС везде один, версии 3.1, но у него разные БИОСы и адрес посадки (зависит от размера БИОСа). Это как ядро CP/M 2.0 - оно везде одинаковое, а БИОС (драйвер диска) адаптируется под конкретную платформу.
У Вектора разные БИОСы поддерживают (в зависимости от версии):
- квазидиск (почти все), разные варианты квазидиска
- дисковод (большинство), 1 или 2 устройства
- винчестер, есть разные варианты с разным количеством логических дисков для монтирования флоппи-образа, например ABC (три) или ABCDE (пять)
- поддержка каких-то шрифтов (bold вариант)
- улучшенные драйверы вывода символа или клавиатуры
- - - Добавлено - - -
Есть ещё Т-72, там версия МикроДОСа 3.1М - вроде какую-то ошибку в самом микродосе исправили.
Improver
08.04.2020, 16:11
Количество микродосов и их вариантов мне не дано охватить. Даже старых многоватоИз старых ОС в Базисе почему-то полностью отсутствует РДС, хотя он имеет несколько версий, да и в "Вектор User" ему были посвящены целые статьи... Хорошо бы собрать и упорядочить по нему инфу, да добавить в каталог.
В T34 и T72 судя по описанию еще и драйверы fdd переработаны (сам не сравнивал). Насчет версии микродоса - кроме 3.1 есть еще 3.0. Кое-где поддержка разных принтеров.
b2m, открой тайну, откуда mdos3.com?
- - - Добавлено - - -
РДС в базисе есть в неявном виде (http://www.sensi.org/scalar/ware/480/), но вроде не все версии и не все доки (сейчас не проверял).
electroscat
08.04.2020, 16:19
Доброго времени дорогие товарищи ! ))
Великое дело делаете, спасибо огромное !
Потестировал последнюю версию, как пользователь обязан сказать, что пока в плане бытовом от совершенства далеко, тем не менее, я понимаю, что это пока что только экспериментальный код, и в целом, самое главное в этом коде - работат с диском. И она на высоте реально. На эмуляторе я не тестил эту систему, не очень интересно, а вот реал показал полную работоспособность на 256 мб CF карте. Читал и писал на 50 и 100 дискеты, до полного заполнения, все читается, пишется, скорость возрасла в разы, это заметно даже по миганию светодиода HDD контроллера, он почти не тухнет. В общем, очень круто, вы просто гениальные, господа !!! Благодарен !
Опять же скажу, что понимаю, что код экспериментальный, но тем не менее, хочу поделиться тем, что вызвало у меня трудности в новой системе,. Понимаю, что это не так важно, но думаю, в будущем, когда система станет работать максимально хорошо по части HDD - то и эти небольшие баги будут устраняться. Я попытался тестить копирование под ASC.COM, и - при выходе из ASC.COM палитра остается от нее, и в консоли разные части букв разных цветов. Еще, как тут и писалось, не работает FDIR и DELETE - после запуска DELETE система переходит на указанный диск, но ничего не происходит, в консоли рисуется галочка ">" без буквы диска и за ней мигает курсор. Выходит из этого по нажатию "СБР+БЛК". То же после запуска FDIR - разница только в том, что диск не меняется. В целом, с ASC работает немного по другому, в версии ASC которую я использовал, в mdos31h - команда 9 A:X меняла диск и снова в ASC все возвращалось, под этой осью такого нет, команда 9 - выкидывает из ASC. Есть очень положительный момент, работает DESIGNER - редактор графики, причем, с любого диска. Это предел мечтаний, использую программу для правки и создания кусочков графики, спрайтов, для программ. Приходилось ее с дискеты использовать, максимум с квазидиска но при отсутствии HDD. Теперь все изменится !!!
В общем, я прошу меня простить, если я чего то ненужное пишу, или не в тему вообще, если вы не против, я буду тестить новый код, и изредка выкладывать подобные отчеты, но если этого не нужно делать, скажите пожалуйста об этом.
В целом, спасибо Вам огромное что вы этим занимаетесь !!!
И еще кое что забыл. Не работает INITIAL.SUB. В плане использования оси - очень на мой взгляд важная штука. Может она работает от куда нибудь из другого места, у меня она на первой дискете HDD лежит, и она уже сразу пишет дос на сист. дорожки квазидиска, задает цвет, копирует все нужное на квазидиск и запускает ASC.COM... А в этой оси эффекта не было.
Я продолжу тестирование, если что от еще найду интересного, допишу...
У меня давно есть маленький вопрос (багрепорт?) по t72. Все версии, в т.ч. оригинальная, странно реагируют на ввод B (только одна буква, как диск, но без двоеточия).
Improver
08.04.2020, 16:43
У меня давно есть маленький вопрос (багрепорт?) по t72. Все версии, в т.ч. оригинальная, странно реагируют на ввод B (только одна буква, как диск, но без двоеточия).Эта странная реакция есть почти во всех МДОСах, это т.н. недокументированная команда "B", слышал, что она предназначена для вывода каких-то спрайтов на экран, но реально не знаю, где она используется. И эта программа имеет глюк при запуске без параметров, я хотел как-то разобраться и исправить, или вообще её удалить, но пока до неё руки не дошли.
Запускается "В" в МДОС вот от сюда:
P_C2DE: LDA M_E117 ; вызов из PCHL (2) -- команда "B"
CPI 001h
RNZ
LXI H, L_DF94
CALL L_C134
LDA L_DF95
CPI 020h
JNZ L_C2F8 ; переход, если есть параметры
CALL L_CB01 ; вот оттуда сыпется мусор...
JMP L_DAAA ; а до этой команды вообще не доходит.
electroscat
08.04.2020, 16:45
У меня давно есть маленький вопрос (багрепорт?) по t72. Все версии, в т.ч. оригинальная, странно реагируют на ввод B (только одна буква, как диск, но без двоеточия).
Да, этот же глюк есть и в mdos31h - выдает россыпь случайных символов, и виснет... В этой оси происходит то же самое, но в конце все же курсор, работоспособность не теряет.. А что выдается в консоль в момент выполнения этой команды, тоже хотелось бы узнать )))
открой тайну, откуда mdos3.com?
Ну не помню я, откуда у меня архив soft_viknik.rar 13.07.2011
Внутри 24 образа дисков с именами VECnn.fdd, все файлы имеют одну и ту-же дату 04.07.2011 23:46
Смутно припоминаю, что вроде бы сконвертил их из .td0
mdos3.com я нашёл на VEC2.fdd
- - - Добавлено - - -
Изучай. (http://bashkiria-2m.narod.ru/files/disk/soft_viknik.rar)
Спасибо, у меня такого нет. В архиве Фиронова mdos3.com не нашел. Насчет микродоса 3.0 я ошибся, все 3.1 (или 3.1М).
Попробовал корветовский микродос 2.6 - он команду B не знает. Возможно есть более поздний микродос, но из более поздних корветовских я видел только cp/m.
Команда B не во всех досах гонит пургу на экран, в поздней версии "только кваз" dos31k.rom (из архива Фиронова) виснет.
²²²²²²²²²²²²²²²²²²²²²² НОВОСТИ МикроДОС ²²²²²²²²²²²²²²²²²²²²²²²²
Наверное каждому пользователю МикроДОС приходилось наблюдать
странную реакцию системы на команду B<ВК>. При этом компьютер
пытается напечатать сообщение находящееся где-то между
4000h-5000h; естественно, никакого сообщения там нет, а есть
только всяческий "мусор" от предидущей программы или, в лучшем
случае, нули. В результате система печатает (или, в случае
нулей, "висит") какой-то психогенный летучий бред, пока не
встретит ограничитель последовательности '$', т.е. достаточно
долго. При этом имеют место такие неприятные явления как
переключение драйвера вывода на славянский алфавит, что в
конечном итоге заставляет нетерпеливого user'а нажимать
волшебные кнопки в верхнем правом углу клавиатуры...
Отчего же всё это происходит? задают себе вопрос user'ы,- и
тутже сами себе и отвечают: "видимо авторы МикроДОСа мало-мало
напортачили!" И действительно напортачили. И не так уж и мало.
Насколько удалось выяснить, копаясь в ДОСе, команда B это не что
иное как "замаскированная" команда S. В куцем руководстве по
ОС, каким пользуется большинство пользователей, сказано, что она
назначает системное дисковое устройство. Действительно, в более
поздних версиях МикроДОС (например в Корветовской) эта команда
работает именно так, но в версии 3.1 83-го года команда S
предназначена для загрузки файлов с расширением .SPR (видимо от
System PRogramm). Формат этой команды: S <имя файла>.
Расширение .SPR указывать не надо. В нашей же "неправильной"
ДОС вместо S необходимо ставить B, т.е. так: B <имя файла>.
Если же имя файла не указано, то теоретически ДОС должна
выдавать сообщение "NO FILES", но "CALL в никуда", к сожалению
не даёт ей такой возможности, отчего и происходят штуки
описанные в самом начале.
Естественно, после обнаружения всех этих фактов, у автора этой
статьи зачесались руки и он устранил все обнаруженные ошибки.
Попутно ему удалось разобраться в структуре .SPR-файла, который,
как известно загружается не в начало, а в конец Области
Транзитных Программ. Структура эта оказалась довольно сложной.
Пользователи могут получить представление о работе с .SPR
файлами если переименуют SID.COM в SID.SPR и попробуют загрузить
его.
А что касается исправленной версии МикроДОС, то автор рискнул
изменить её версию с 3.1 на 3.11 и планирует выпустить в
ближайшее время с несколькими программами, написанными
специально для неё. Кстати BIOS3.11.F.11 Е.В. Филиппова делает
исправленную версию ОС самой лучшей из всех существующих.
29.08.93.Усков И.М. (Волгоград)
Прикольно, действительно Филипповские досы не виснут по команде B и SID.SPR загрузился. А я не докопался, что надо грузить SPR и не знал, что за SPR (не картинки же) и где взять. Пробовал делать B имя_файла и дос (по крайней мере t72) выдавал "имя_файла?" как и в ответ на другие неправильные для команды аргументы. Что там за "структура файлов SPR" у меня нет желания разбираться и вряд ли команда B нужна. В t72 есть еще команды неизвестного (мне) назначения, хорошо бы прояснить их назначение и способ использования или убрать.
- - - Добавлено - - -
Стало интересно, может в FH51 (модифицированный автором контроллера hdd Фроловым ДОС Филиппова) и заворота нет? Все же заворот и в этом "классическом" досе есть.
- - - Добавлено - - -
Оффтоп, но тоже интересно, о каких более поздних корветовских версиях МикроДОС речь, если 2.6 (что на первый взгляд меньше 3.1) датирована 85 и 87.
- - - Добавлено - - -
Нашел корветовский Big Dos (юмор такой) ver 3.9 (16.04.96), но вряд ли о нем писал Усков в 93.
- - - Добавлено - - -
И есть модифицированный корветовский микродос 2.6 1990 года, совместимый с ОПТС 2.0. Заканчиваю оффтоп про корветовские микродосы.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot