Да эти t72hp и t72hp2 работают.Сообщение от ivagor
А почему "fdir *.*" не во всех версиях работает (в hp и hp2 тоже не работает) ?
И ещё странный момент, в этих t72*, после старта, по команде "9" сообщается, что "B: 0005" - что за 5-ая дискета? при переключении на диск B: - начинают сыпаться ошибки диска.
ivagor(17.04.2020)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Они как раз не LBAшные, значит все же в ve27 LBA не поддерживается.
Не работает во всех мдосах, в т.ч. РДС, кроме mdos31h и 30h, если не ошибаюсь. И проблема с Т72 не в драйвере жёсткого диска, а в небольшой несовместимости с выводом информации, как я понимаю. Я начал копать fdir, он заработал, но пока стабильного результатов нет. Почемуто часто выводит одно содержимое на все дискеты...
Это моя подстава... Для разнообразия я там задал в начальных установках системы, чтобы на В: подключалась пятая дискета, можно изменить. А что за ошибки сыпятся? А в других досах на пятой дискете всё нормально показывается?
Последний раз редактировалось Improver; 17.04.2020 в 19:56.
Не, просто этой дискеты в образе физически нет. Я ж грю, образ экскриментальный, на одну дискету.
Ни чего страшного, просто обычно В: не определён, а тут номер за пределами размеров образа...
- - - Добавлено - - -
Да меня собственно emu - устраивает, экраном не дёргает, запускается в окне.
Единственно, в ve27 активность всех дисков видно - удобно для контроля при отладке программ с доступом к дискам.
- - - Добавлено - - -
Что-то припоминаю... когда разбирался с утилитами для работы с HDD, копался в исходниках, там попадались какие-то странные (с точки зрения обычного МДоса) вызовы функции для вывода текста на экран. Специфические они были какие-то.
Доброго времени друзья!
Поделюсь немного затыком по mdos31h, читаю в буфер два сектора, все отлично. Решил читать именно два сектора как в оригинале, потому что чтобы сказать системе, что прочитан только один сектор - нужно дизассемблировать и разбирать остальной код, или его часть. В итоге, читаю в буфер с EB00 по EEFF - все отлично читается, и выводится на экран (если например чтение вызвано командой D) в виде названий файлов. Все четко. после этого читаются следующие два сектора, но читаются они с адреса второго сектора, который уже был прочитан, и выведен на экран, все что было в буфере в адреса ED00 - EF00 (второй сектор) повторно читается уже по адресу EB00 - ECFF, и следующий сектор с адреса ED00 по EEFF свежий... В итоге половина информации на экране задвоенная, и естественно, ничего не работает. Точнее, маленькие текстовые файлы удается выводить на экран, которые в один сектор помещаются, читается initial.sub - но в лучшем случае он ничего не запускает, в худьшем - уносит куда то ..
Может у кого то есть мысли по этому поводу? От куда формируются переменные XE86D и XE86F? В тексте не нашел что либо, что могло бы сертезно влиять на эти переменные, однако же в переменной XE86F, в младшем разряде как раз и есть отличие на 1 от того, что приходит в непатченной оси..
Если кому то любопытно будет взглянуть на имеющийся код, или куски или сам mDos31 c текущими изменениями - все тут!
На этом, пока остановился, будет время продолжу поиски.
И еще, засунул в ПЗУ загрузчика FH51LBA - и обновил тут. Микросхемы уже в Москве, скоро потестирую на реальном векторе. При загрузке из ПЗУ система ищет INITIAL.SUB на A:, а вот после записи ее на системную область С: ищет на С:... по этому пришлось прописать у себя инит, который копирует слегка измененный инит на C. Не очень красиво, но работает. Если будет возможность исправить этот баг, пожалуйста, сделайте, если система инит будет только на А: искать, или не найдя на С: таки искать на A: - будет супер просто, потому что на реале заморочено стартовать с подгруженным из файла квазидиском ))
Последний раз редактировалось electroscat; 18.04.2020 в 20:41.
Не вижу проблемы.
С моей точки зрения логичный вариант.
При первом старте инит запускается с А: - записывает OS.COM, копирует на C: "рабочий" инит, в котором нет копирования OS на С:, а предусмотрен запуск рабочих программ, если это надо.
При повторном запуске, система грузится уже с Кваза, и инит исполняется уже "рабочий".
Или в что не в тему?
Вот я именно так и сделал сейчас.. Но это лишнее, ведь скорость загрузки инита и всех программ с квазидиска и с HDD - одинакова, а иногда мне кажется что с HDD все грузится даже быстрее. Ну а тут еще расход времени на копирование, и прочее, при первом старте. Ну и... есть у меня INITIAL.SUB на A: и проблем никаких, для всех систем кроме РДС исчерпывающий. А тут получается, что все системы, старшующие с таким инитом будут копировать на C версию инита и что либо еще, а зачем ?
Если бы зто было стандартом для всех систем, то да, но если это в одной системе так, а в остальных ненужные действия - то увы, не айс... В целом, решение Improver в T 72 наверное самое оптимальное - есть инит на C: - от туда, если нет - то с А:... Вариант с инитом на C: удобен на виртуалке возможно, а на реальном векторе, ну так ...
При использовании виртуалки, EDD уже забит нужным софтом, и при первом запуске его (нужный софт) не нужно дополнительно копировать с FDD(HDD).
А на реальном, при первом запуске - рутина... копирование нужного с FDD(HDD) на EDD, эту задачу и решает инит на А:. При последующих запусках, инит с С: делает только необходимое (уже без перезаписи софта).
Значит по идее, система с двумя инитами более полезна как раз на реале, а не на виртуалке.
Но это лишь догадки, т.к. этой фичей не пользуюсь
Возможно, нужно выслушать автора этой идеи. И тогда будет ясен замысел творца
А то получается как в том анекдоте:
- Вы не любите ... ? Да Вы просто не умеете их готовить!
На реале с HDD квазидиск вообще нужен исключительно для системных нужд, у меня даже была идея, если бы я решил создать свой ДОС, я бы квазидиск полностью отвел под ОЗУ и системные нужды, потому что HDD работает на мой взгляд быстрее чем квазидиск, и места на нем гораздо больше и т.д. А с квазидиском системе проще работать, по моим ощущениям. Ещё, образ HDD легко переносится в эмулятор и обратно, и тут тоже нужно чтобы все было совместимо, по этому и в эмуляторе у меня квазидиск пустой и не используется никак, кроме записи на него оси на системные дорожки. В целом, это мое мнение, а так, на вкус и цвет фломастеры разные. Ну и я не утверждаю, что так или иначе правильно, просто делюсь мнением, вот.
Combodevice, если я не путаю, поддерживает доработку Баркаря. Во всех современных эмуляторах в качестве кваза (если не брать экзотические конфиги) именно Баркарь и все работает. Про FPH51 я забыл, надо будет доработать (LBA и прочее), это лучший дос для дискового бейсика.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
