На счёт образов я только за. К скорпу же нельзя подключить DivMMC, поэтому надо своё. И остальная поддержка фат чем больше, тем лучше ). Но если будет ОС, то как бы двойная работа.
А какая? Какое окно ему надобно?
Вид для печати
autoexec.cod! ;)
Так он и сейчас не работает - даже сейчас рестарты профпзу только на нем и работают. НО и софт для nemoide не работает на smuc и так далее и так далее.
ATM развивается (вместе с Эвой), другие клоны тоже эволюционируют, и нам надо! FAT32 для образов - это уже очень классно, но если можно еще дать толчок для развития - почему бы и нет?)
В Эве и АТМ - не одна, да и на фирменных +2/+3 не одна, но все равно нет SymbOS.
но можно портировать (хотя бы в теории) ESXDos к SMUC и ПрофПЗУ.
А тут мы привязываемся жёстко к фат. Может на диске и не будет разделов таких у человека.
Надо подумать.
Так на скорпе то 1.5 окна. А на ГМХ аж 2.5. Это я окно ПЗУ называю как неполноценное 0.5.
- - - Добавлено - - -
Богатая мысль. Но сложно.
Возможно проще, чем SymbOS. А в разрезе Спектрума скорее и полезнее - удобная поддержка legacy-форматов и новые фичи.
А Symbos - красиво, конечно... но.. не знаю - оконный интерфейс, ради оконного интерфейса, ну такое.
А смысл будет оставаться только на MFS? Образы дискет (а на FAT, глядишь, можно будет и не только .trd, но и .scl поддержать, и чем черт не шутит - .fdi) уже можно хранить на FAT'e - и самое главное удобнее! с именами нормальными, с папками! А вдруг и LFN-имена удастаться поддержать?
Музыку для WP/Z-Player уже есть смысл хранить на FAT'e. Проигрыватель видео для GMX не будет ограничен рамками дискеты.
Что еще остается - IsDos и CP/M - ну так им много и не надо. В общем я бы скорее уходил со скоростью паровоза от MFS в сторону FAT32 - это реально такой скачок в удобстве. Да, возможно в скорости мы теряем немного, из-за сегментированности файлов.. но так ли это критично в данном случае?
.scl, по крайней мере, в режиме чтения поддержать можно, а вот .fdi зачем? Перехват идет только точки #3D13, это означает работа с .fdi только стандартного tr-dos формата. Перехват же чтения/записи в порты ВГ, учитывая зоопарк нестандартных загрузчиков, для таких дисков представляется мало возможным, если вообще возможным. И конечно это потребует правок tr-dos, что неминуемо приведет к неработоспособности некоторых программ.
С поддержкой длинных имен в принципе сложностей нет. Вот только в рамках интерфеса монитора во-первых: при ширине строки 40 символов, выводить такие имена не слишком удобно; во-вторых: 8я страница и так достаточно плотно забита, и найти место под обработку таких имен будет тот еще квест.
Черный Ворон пойдет?)
я не вдавался в подробности как на Эве эмулируется/перехватываются обращения к тр-дос, но насколько знаю, там fdi возможен. НО, повторюcь, я краем глаза что-то видел про это. Ну не будет поддержки - значит, не все сразу)
Обрезать имена. но уже, например, 20 символов - это уже более информативно, чем 8.3. Всяко лучше хранить минимальную информацию о релизе в названии, чем пытаться запомнить, чем B.COBRA.TRD отличается от BL.COBRA.TRD :)
но это, опять же, сервисная хотелка, для улучшения user expirience.
- - - Добавлено - - -
да там и многое другое сложно будет перенести - там же активно через nmi идет работа - там свое меню, у нас свое - аж целый монитор. плюс там все рестарты тоже через rst8.
тут, мне кажется, только если что-то интересное "по мотивам" (или подглядывая в исходник) к нам тащить - работу с виртуальными тапками на чтение и запись, например. что-то по тр-дос подсмотреть, еще что-то.
с `ломанного` TRD - да.
я вообще удивлён почему скорпионщики за 20лет не адаптировали его под-себя
(используя собственные процедуры загрузки)
- - - Добавлено - - -
начал смотреть TRDверсию от VirtualBrothers, а там оказывается есть чит меню
https://pic.maxiol.com/thumbs2/16705...5248197.br.png
Пофиксил некоторые ошибки.
Оптимизировал по скорости работу с FAT
Вложение 78183
Потестил немного в эмуле. Вроде и пишет и читает в образы и fat и mfs, и на мастер и на слейв.
Только логика выбора мастер/слейв немного не та при монтировании. Надо бы, чтобы оба диска были доступны постоянно. А когда монтируешь образ, выбираешь сначала диск из списка, а потом как обычно. А не переключатель мастер/не мастер.
Как на винде, все диски какие есть всегда же доступны.
А кто знает, как вообще появилась аббревиатура MFS (для разделов "жесткого" диска)? Само ее предназначение? Как говориться, откуда "ноги выросли"?
https://zxpress.ru/article.php?id=8665Цитата:
MOA FileSystem?
гоняю пока. сразу вопрос (ответ на который я возможно пропустил ранее): одновременное монтирование из разных HDD не возможно?
т.е. на диск D со slave монтируем IsDos, а на A и B с мастера обычные диски.
P.S. честно говоря, чем дальше, тем меньше вообще вижу необходимости в таких заморочках, ибо работа с FAT32 все больше радует, и остальное уже кажется костылями.
ну кроме поддержания MFS в качестве раздела для IsDos
LW, сейчас в "соседней" ветке тестируется будущая версия TRDN :) и у меня есть идея сделать в ней (тестовой) временную поддержку ПрофПЗУ с кодом версии 98. В связи с этим вопрос: поменялось ли/будет меняться в тестируемой здесь версии Монитора, по сравнению с V4.01, что-нибудь в ROM7 (ROM3 (TR-DOS) во второй плоскости) и в частности местоположение процедуры подсчета CRC для сектора примонтированных псевдодисков?
В теории, какая-нибудь из будущих версий TRDN, может быть, если в новом Мониторе появятся соответствующие функции RST 8.Цитата:
Сообщение от Xela
Это мера защиты, поскольку сейчас в TRDN есть вызовы подпрограммы по абсолютным адресам из ROM7.Цитата:
Сообщение от Xela
Конечно поменялось, ведь именно в ROM7 находятся процедуры работы с HDD.
Да адрес другой.
В качестве временной меры, только для тестирования, могу предложить такой вариант. В ROM7 по адресу #0000, поставлю команду перехода на адрес п/п подсчета CRC.
Вложение 78185
- - - Добавлено - - -
Grand, Если хотите поэксперементировать с экспериментальным ПрофПЗУ, то вот еще некоторые данные:
Сектор настроек с примонтированными образами всегда на одном месте, вне зависимости от режима LBA/CHS. LBA адрес 3
Формат записей для примонтированного образа .trd
+#00 =#05 - примонтирован образ .trd с FAT раздела
+#01 - 4 байта номер первого кластера файла
+#05 - биты 0-1 для любого образа номер раздела HDD, остальные биты не используются
+#06 - 4 байта для образа .trd не используется
+#0A - 11 байт имя файла 8+3
+#0C - не используется
- - - Добавлено - - -
Нет. И честно говоря не вижу большой необходимости в этом.
@LW, несколько вопросов/предложений:
1. Предложение: хотелки/планы на внедрение, которые мы озвучиваем, и они находят у Вас отклик где-то собирать, например, в первом посте (хотя я помню, что эту тему вынесли из непосредственно обсуждения новой версии ПрофПЗУ, и тут только было про Master и Slave :v2_dizzy_botan: ) и вычеркивать их по мере внедрения/отказа от них
2. сейчас у нас на диске может быть раздел MFS и FAT32 - с которыми нынешняя версия ПрофПЗУ работает, и какие-то еще - с которыми не может.
И в разделе MFS подразделы TRDOS (в котором, как мне кажется, чем дальше, тем больше отпадает необходимость), ISDOS и MicroDos (который, как я понимаю, структуры-то и не имеет).
Что если пойти по пути упрощения: создавать в мониторе сразу нужные разделы - FAT32, ISDOS, и в будущем может еще что-то для CP/M? Если работаем только на Скорпионе, то вопросов вообще нет. Если подключаем к ПК, то Windows/Linux/Mac видят только FAT32, остальное не опознают, и хорошо.
3. ROM-диск - сейчас это нетривиальное хранилище снэпшотов. Да, есть утилита под Windows от Игоря azx987sa для удобного создания РОМ-дисков, но эти снэпшоты нужно создать, и еще в удачное время, особенно это касается бутов - что б инициализация прошла, но диск не прочитался и т.д.
Что если и тут немного упростить и хранить в РОМ-диске кодовые блоки, которые загружаются по определенному адресу, и туда передается управление? Помню был например Consul Comander с кучей оверлеев - кодовые блоки, запустил, поработал в них, вышел обратно в командер.
Создать кодовую версию того же TRDN, мне кажется, проще, чем создавать "правильный" снэпшот.
Просто вопрос: давно меня мучает - почему Сервис-Монитор такой... неспешный? из-за процедуры печати нестандартного шрифта? или там в принципе код очень неоптимизированный?
Ну, это-то как раз уже сделано, - и кодовая версия TRDN, и его правильный снэпшот.
1. Можно, конечно, и в первом посте. Так то в архиве приложен файл со всеми изменениями.
2. Ни раздел IsDos, ни MicroDos структуры не имеют, отличаются только номером в дескрипторе подраздела
создание раздела FAT32 реализую, а остальное пусть остается в рамках MFS. CP/M все равно нет. В плане работы IsDos с винчестером тоже не все ясно. Насколько помню из документации по SMUC она вообще работает с разделами не более 16 мегабайт. И зачем такой маленький раздел на винте.
3. теже самые кодовые блоки можно упаковать в формат снапа скорпионовского и залить в ROM.
Возможно тут поможет другое решение. Мне тут подкинули идею "Запилить поддержку загрузки SPG напрямую с FAT32 раздела." Попробую реализовать.
Реализация печати это боль. Стоит в планах на переделку.
Тормоза в основном из-за того, что п/п печати символа находится в rom2, а все менюшки в rom5. и при печати каждого символа вызывается процедура из rom2. В итоге на каждый символ дополнительно тратится вагон тактов на переключение плоскостей и страниц.
я не про уже сделанные изменения, а про то, что планируется. Например, вот рассказали Вы про печать и SPG, пишем в первом посте планируемые изменения:
1. Переделать п/п печати - приоритет средний.
2. Добавить загрузку SPG с FAT32 - высокий.
3. Пункт загрузки HDD BOOT в главном меню - может быть. приоритет низкий.
4. Рестарты для монтирования образов с FAT32 - да, скорее всего. приоритет низкий.
5. Поддержка .scl - да, может быть. когда-нибудь.
6. Перехват процедур чтение сектора и позиционирование головки - подумаю.
7. LFN - да, ограниченно до ~20 символов и то, если найду место.
8. Поддержка .tap "как в esxdos" - нет, не интересно, идите вы со своим ESXDos
НАПРИМЕР
ну т.д. и вычеркивать по мере внедрения
с одной стороны и мы понимаем что наши предложения услышаны, и возможно вызвали интерес, и кто-то новый приходит и видит что уже обсудили, и не будет предлагать то, что уже было.
в итоге у меня, например, будет большой раздел fat32 для "всего" и небольшой раздел MFS на 17Mb, внутри которого ISDOS на 16Mb)
Повторю пункт в хотелки: работа одновременно двух винтов. Чтобы можно было перекидывать между ними инфу.
А на счёт загрузки с HDD можно сделать и из файлика на фат, так, конечно, проще всего. Закинул файл в корень, и диск стал загрузочным. Красота. Но без фата уже никуда.
izzx, Обещать не буду. В список изменений добавил, если будет возможность сделаю.
По просьбам трудящихся обновил первый пост.
*раскатав губу* вот бы .szx поддержать...
нет, это вряд ли
и туда же добавить поддержку .pok файлов - загрузил тапку, выбрал лежащий рядом .pok файл.
в идеале еще и выбрать какой из входящих в него pokes использовать:
WEC Le Mans (1988)(Imagine).pok
N[48K]Infinite Time
Z 8 33249 195 0
N[48K]Invincible
Z 8 37549 201 0
N[128K]Infinite Time
Z 8 33261 195 0
N[128K]Invincible
Z 8 38169 201 0
Y
Ну и запросы у вас :)
Есть же отладчик, зашли в него и выставили что надо
А версия ГМХ в хотелки?
- Чтобы была одна прошивка (для Скорпиона 256 и Скорпиона 1024), а не две
- В 1024 Скорпионе есть перемычка, отвечающая за стандарт расширения памяти. https://zx-pk.ru/threads/16280-tekh-...l=1#post509458 При ее отключении остается только 256 Кб.
На фото над разъемом питания
https://retropc.org/images/134.jpg
А если предусмотреть в сетапе теневого монитора, настройку что запускать по кнопке HDD Boot, файл autoexec из корня fat32 или какой-нибудь загрузочный сектор из разделов находящихся в MFS.
И так же предусмотреть в меню теневого монитора где настройка автозапуска при старте, пункт HDD Boot, который как раз и будет автоматически при включении запускать нужную ОС.
LW, Какой максимальный HDD можно использовать? Какой максимальный раздел FAT32, оптимально использовать, наверное есть ведь ограничение по размеру файловой системы?
Надо теперь винт подбирать другой, чтобы и FAT32 влез :-)
Отвечу за LW - любой, но работать можно будет только с первыми 128 Гб.