Техраздел UZIX

[Error404]

Добавил в плагине OHI.WCX возможность инициализации образа (создать запись MBR), а также создание и удаление primary MBR партиций типа CPM и UZIX (создаются вместе с файловой системой). Работа как с подкаталогами (создать-F7, удалить F8), при создании в качестве "имени каталога" указывается тип и размер партиции, например "UZIX 20M" или "CPM 1500K". Т.е. не нужен fdisk - взяли любой подходящий файл (лучше зануленый - чтобы архивировался хорошо), переименовали в OHI, проинитили (просто войдя в этот образ), создали партиции, в них создали структуру каталогов (в случае UZIX), накидали файлы. Всё.

Всё залил на github.

[Advertiser]

[Sayman]

Добавил в плагине OHI.WCX возможность инициализации образа (создать запись MBR), а также создание и удаление primary MBR партиций типа CPM и UZIX (создаются вместе с файловой системой). Работа как с подкаталогами (создать-F7, удалить F8), при создании в качестве "имени каталога" указывается тип и размер партиции, например "UZIX 20M" или "CPM 1500K". Т.е. не нужен fdisk - взяли любой подходящий файл (лучше зануленый - чтобы архивировался хорошо), переименовали в OHI, проинитили (просто войдя в этот образ), создали партиции, в них создали структуру каталогов (в случае UZIX), накидали файлы. Всё.

Всё залил на github.

тогда уже надо сразу добавлять поддержку разделов fat. Заодно - в чём различие между форматами ohi и img/dd? Надо бы их тоже поддержать. полезная тогда тулза для развёртывания разделов в образах будет.
однако, утилиту mkfs нужно сильно переделывать. сильно багованная она. файловая система сломанная выходит после неё.

[Error404]

тогда уже надо сразу добавлять поддержку разделов fat. Заодно - в чём различие между форматами ohi и img/dd? Надо бы их тоже поддержать. полезная тогда тулза для развёртывания разделов в образах будет.

Да, планирую и FAT доделать.Например используя FATfs от Чена. В принципе, нет никаких отличий от образов, сделанных dd, там тоже простая посекторная копия.

однако, утилиту mkfs нужно сильно переделывать. сильно багованная она. файловая система сломанная выходит после неё.

А что именно не отрабатывает? Все образы UZIX, что мы пробовали на реале, сделаны этими консольными Win32 утилитами mkfs.exe и ucp.exe (кроме разметки партиций, в то время я это сделал в образе орионовским fdisk который только размечает разделы, fs UZIX-a не делает).

- - - Добавлено - - -

CPM-овские версии mkfs.exe и ucp.exe кстати тоже были работоспособны. Хотя понятно что длительно их никто не проверял.

[Sayman]

А что именно не отрабатывает? Все образы UZIX, что мы пробовали на реале, сделаны этими консольными Win32 утилитами mkfs.exe и ucp.exe (кроме разметки партиций, в то время я это сделал в образе орионовским fdisk который только размечает разделы, fs UZIX-a не делает).

дело не в том, что они не работают, а в том, что в ФС возникают ошибки сразу после создания. Во1х, есть мусор в блоках с инодами. Во2х, но это скорее не ошибка, а не доработка - свободные блоки почему то в таблицу пишутся с конца, а не
с начала. (имеется в виду, их номера, filesys_t, там 2 таблицы - s_free[FSFREEBLOCKS] и s_inode[FSFREEINODES]. хотя их назначение я так и не понял). Вообще, с этой структурой непонятка какая-то. при создании дискеты 720кб, туда влезает 200 инодов, а в эту табличку только 50. зачем она нужна, я не понял. в оригинальной UFS таких табличек нет. при чём при просмотре образа под winhex я заметил, что эти две таблички не заполняются самой mkfs в полном объёме. если сделать fsck, то они сразу исправляются, мусора по образу становится меньше, хотя утилита явно не весь мусор убирает. и этот баг есть как в оригинале, так и под виндой.

[Error404]

дело не в том, что они не работают, а в том, что в ФС возникают ошибки сразу после создания. Во1х, есть мусор в блоках с инодами. Во2х, но это скорее не ошибка, а не доработка - свободные блоки почему то в таблицу пишутся с конца, а не
с начала. (имеется в виду, их номера, filesys_t, там 2 таблицы - s_free[FSFREEBLOCKS] и s_inode[FSFREEINODES]. хотя их назначение я так и не понял). Вообще, с этой структурой непонятка какая-то. при создании дискеты 720кб, туда влезает 200 инодов, а в эту табличку только 50. зачем она нужна, я не понял. в оригинальной UFS таких табличек нет. при чём при просмотре образа под winhex я заметил, что эти две таблички не заполняются самой mkfs в полном объёме. если сделать fsck, то они сразу исправляются, мусора по образу становится меньше, хотя утилита явно не весь мусор убирает. и этот баг есть как в оригинале, так и под виндой.

В детали инициализируемых ею структур я не углублялся. Если разберешься и поправишь - тебе будет жирный плюс в карму.

[Error404]

тогда уже надо сразу добавлять поддержку разделов fat.

Добавил поддержку FAT в образах (на базе FATfs от Чена), теперь плагинами равнозначно обрабатываются (в т.ч. и создаются) разделы/файловые системы CPM, FAT, UZIX.
Описание в этом посте (т.к. на него ссылка с первого поста): https://zx-pk.ru/threads/24501-tekhr...=1#post1013490
Исходники на GIT (впрочем как и бинарники), одним архивом бинарники в пост по ссылке выше прикреплю позже, чего-то пока не получается прицепить вложение (матерюсь).

[Sayman]

Error404, а можешь перевыложить актуальные исходники виндовых утилит?
посидел над исходниками mkfs и утилиты по запиливанию бутлоадера. не получается запиливать совместимость с оригиналом. суперблок у оригинала расположен не с 0го сектора, а с 1го. это если про дискету говорить. у Спринтера наоборот - бутлоадер на 1м секторе должен быть у дискеты. уже не совместимо. и биос при попытке грузить с дискеты лоадер будет искать свою сигнатуру. без неё дискета не загружаемая. это или просто формат фс поменять чутка или залезать в исходники биоса. пока снова отложил эту идею...

[Vasil]

у Спринтера наоборот - бутлоадер на 1м секторе должен быть у дискеты.

.... это или просто формат фс поменять чутка или залезать в исходники биоса

И эта странная фраза (применительно к данному случаю) - "залезть в исходники биоса".... Что, не терпится наплодить туеву кучу сущностей ?.
В Спринтере всё сделано правильно - с одной и той же дискеты можно одновременно грузиться на ПК (ms-dos) и на Спринтере (его дос), одно другому не мешает. Креативные манагеры, мля.....

[Sayman]

И эта странная фраза (применительно к данному случаю) - "залезть в исходники биоса".... Что, не терпится наплодить туеву кучу сущностей ?.
В Спринтере всё сделано правильно - с одной и той же дискеты можно одновременно грузиться на ПК (ms-dos) и на Спринтере (его дос), одно другому не мешает. Креативные манагеры, мля.....

строго говоря, не та тема (не профильная по Спринтеру), но моё мнение таково, что если винт/карта стоит в Спринтере в качестве загружаемой или если речь о дискете загружаемой, то плевать на загрузку на ПЦ. главное, чтобы под вендой дискета читалась и был доступ к разделам на винте.
но в целом, изначлаьно рассматривал вариант именно смены формата фс у юзикса, а не пложения сущностей в биосе. так что не pantin pro vi.

[Error404]

И эта странная фраза (применительно к данному случаю) - "залезть в исходники биоса".... Что, не терпится наплодить туеву кучу сущностей ?.
В Спринтере всё сделано правильно - с одной и той же дискеты можно одновременно грузиться на ПК (ms-dos) и на Спринтере (его дос), одно другому не мешает. Креативные манагеры, мля.....

Т.е. получается что на одной и той же дискетке лежит сначала код загрузчика в опкодах x86, а затем код загрузчика в опкодах z80? Вот это действительно креатив.
Типа у тех у кого хватало денех на Спринтер (который и сейчас стОит неадекватно) не было денег на две разные системные дискетки - одну в РС пользовать (кто-то вообще работал в 98году на РС c загрузочной дискетки кроме как с repairdisk раз в пятилетку?), другую в Спринтере? При том что писать/читать для переноса данных можно любую и там и там.
Как по мне, очень спорное решение.