Реализация и поддержка FAT16/32 на Спектруме с HDD

[fk0]

Про ожидание BUSY:

при можно, конечно, таймаут ввести, но это неоправдано. без прерываний нормальную обработку через драйвер, без проблем с многозадачностью всё равно сделать нельзя, чтобы не вносить кучу кода в программу (тогда высокоуровневый драйвер не нужен)

Что касается прерываний: ничего из сказанного не понял. Могу
только сказать, что прерываний для создания интерактивных
программ с разумно-минимальным временем реакции не нужно.
Достаточно таймера. Нет, в спектруме я понимаю -- прерывания
исполняют роль таймера. Больше ничего не нужно. И не спорь.
Абсолютно любой алгоритм с циклами разбирается до уровня
конечных автоматов, где есть один единственный цикл на всю
программу. Прерывания нужны только там где время реакции
критично. В данном случае -- не критично.

Что касается "высокоуровневого драйвера" -- вы уже определились,
драйвер чего конкретно вы пишете? У меня вот драйвер
самой платы контроллера, например "Немо-IDE". А у вас никто
не знает что это и каковы его функции. Отсюда и остальной бардак.

тут проблемы с централизованной регистрацией интерфейсов (реестро-то нету)

Микрософт предложил свой вариант: генерацию псевдослучайных
UUID'ов. Лично мне не нравится. Но тоже -- решение.

[SMT]

Больше ничего не нужно. И не спорь.

и не пытаюсь. я на автоматах собаку съел. я же писал "чтобы не вносить кучу кода в программу". мысль была такая: в нормальных ос, где есть прерывания, программа написана в вольном стиле. драйвер висит на прерываниях, а программа может опросить состояние, когда захочет. то есть при добавлении нового устройства или смене драйвера программу сильно трогать не надо. а тут придётся разворачивать главный цикл, часть драйвера придётся вносить в программу, возможно, реорганизовывать вызов долго работающих процедур в плоский цикл, это неудобно

вы уже определились, драйвер чего конкретно вы пишете

я предлагал интерфейс к НЖМД с ATA-интерфейсом. а драйвер nemo-ide, то есть в терминологии ms - bus driver - слишком простая абстракция и ещё одним уровнем выше надо будет много кода, каждый раз повторять его не очень хорошо. можно так же сделать интерфейс для atapi, с байт-ориентированными буферами. вроде на IDE кроме ATA и ATAPI ничего не предвидится

>>тут проблемы с централизованной регистрацией интерфейсов
Микрософт предложил свой вариант: генерацию псевдослучайных
UUID'ов

дело не в uuid'ах, а в том, что нет схемы, как по GUID найти код (оси нет, произвольные программы могут использовать озу полностью и вызывать что-то #3d13 нельзя). также нужен стандарт на то, где будет размещён загруженный код и какими сервисами он может пользоваться

[fk0]

и не пытаюсь. я на автоматах собаку съел. я же писал "чтобы не вносить кучу кода в программу".

Не хочешь -- не вноси. Вынеси только тот цикл на уровень выше.
Кому надо тот внесёт. А надо, практически, всем.

мысль была такая: в нормальных ос, где есть прерывания, программа написана в вольном стиле. драйвер висит на прерываниях,

Покажи, где у немы есть прерывания. Нормальные ос -- это
где-то на ПЦ, а у нас тут жуткий спектрум.

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

Какой главный цикл? Речь лишь о том, чтобы не зацикливать
ничего на НЕОПРЕДЕЛЁННОЕ время в драйвере. И вообще на
большое (больше 30000 тактов) -- ибо музыка, таймер, прерывания,
которые могут быть запрещены и т.п.

драйвера придётся вносить в программу, возможно, реорганизовывать вызов долго работающих процедур в плоский цикл, это неудобно

Либо я не понимаю, либо ты. Вот в данном конкретном случае,
чем не устраивает решение, когда драйвер лишь предоставляет
возможность чтения регистра состояния, без цикла. Зацикливай уровнем выше. Хочешь в это время музыку играй, хочешь BREAK
опрашивай, что хочешь, то и делай. Чем плохо, в сравнении с
вариантом, когда сбой накопителя завешивает всё насмерть,
и весь интерфейс перманентно тормозит. Особенно с компакт-дисками.

я предлагал интерфейс к НЖМД с ATA-интерфейсом.

А как быть с CD-Walk?

а драйвер nemo-ide, то есть в терминологии ms - bus driver - слишком простая абстракция и ещё одним уровнем выше надо будет много кода, каждый раз повторять его не очень хорошо.

А как быть в случае, когда контроллеров, вроде NEMO-IDE разных
много, а КОД ДЛЯ ПОДДЕРЖКИ ATA интерфейса -- ОДИНАКОВЫЙ?
С чем боролись на то и напоролись: "каждый раз повторять его не
очень хорошо".

Что-то мешает иметь отдельно:

1) драйвер собственно контроллера (например, Nemo-IDE).

2а) драйвер ATA-2 для НЖМД.

2б) драйвер ATAPI для CD-ROM.

П. 2 надстраивается над п.1 в виде ещё одного загружаемого
драйвера. Только он всегда один и тот же будет. Загружаемый
он лишь только для возможности обновления версий, а то можно
и просто жёстко компоновать с программами.

можно так же сделать интерфейс для atapi, с байт-ориентированными буферами. вроде на IDE кроме ATA и ATAPI ничего не предвидится

Да, но опять "много одинакового кода", который ещё и поддерживать нужно. В том смысле что оное для Nemo-IDE от
ATA его варианте для NEmo-IDE практически никаких различий,
кроме как в интерфейсе и ряде функций, не содержит. Так почему
бы общую часть не вычленить в (см. выше) п.1, а остальное в п.2?

дело не в uuid'ах, а в том, что нет схемы, как по GUID найти код (оси нет,

А как его вообще можно найти на спектруме? Он или лежит на
одном диске с запускаемой программой или не лежит. Надо будет -- пользователь положит. UUID решает проблему идентификации интерфейсов в даннном случае, т.е. для конкретного драйвера можно точно сказать, что он для винчестера, а не для часов, например.

произвольные программы могут использовать озу полностью и вызывать что-то #3d13 нельзя).

3d13 нужно, для тех же скорпионов. У меня битик предусмотрен.
А в целом для драйвера принимается 64-кбайтовое адресное пространство и восстановление конфигурации памяти и иных устройств (в т.ч. прерываний), если драйвер изменяет, то он восстановление на выходе должен брать на себя. С прерываниями
тут сложности конечно могут быть. Но типично прерываний ни
у кого нет, нужно только ПЗУ иногда переключить. На время
переключения просто запрещаются прерывания. ВСЁ.

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

Очевидно, что адрес загрузки фиксированным быть не может.
А как иначе в Vega-Commander скопировать всё со скорповского
винта на немовский? Я понимаю, что Vega-Commander сейчас
такой функции не поддерживает, но не в том-то суть. То-есть и
вопрос-то отпадает -- адрес загрузки какой скажут. Сервисов,
по причине их невостребованности, в данном случае нет никаких.
Если мысль дальше развивать, то сервис достаточен единственный:
поиск модуля кода с таким_то_номером_интерфейс� � и его использование через данный интерфейс.

[SMT]

Покажи, где у немы есть прерывания. Нормальные ос -- это где-то на ПЦ, а у нас тут жуткий спектрум

вот. значит, нужно умерить свои аппетиты. если и делать что-то вместе с чтением (музыка/мышь), то только на прерываниях. никаких разворотов в автоматы. а драйвер сам в те моменты, когда надо, запретит прерывания. в циклах ожидания и чтения их не обязательно запрещать. хотя, проблема может быть в том, что драйвер окажется в другой странице и надо будет это учесть (то есть обработчик im2 тоже надо будет затачивать под такой COM)

Какой главный цикл? Речь лишь о том, чтобы не зацикливать ничего на НЕОПРЕДЕЛЁННОЕ время в драйвере

а если протокол обмена такой, что нельзя заранее определить время чтения? тот же ATAPI: после передачи пакета нужно дождаться BSY=0, проверить DRQ, считать byte count и это самое кол-во байт, опять ждать BSY=0, проверять DRQ, читать byte count. так пока DRQ не сбросится после BSY. получается, всю эту логику нужно тащить в каждую программу, чтобы насувать туда опросов мыши и клавиатуры

Чем плохо, в сравнении с вариантом, когда сбой накопителя завешивает всё насмерть, и весь интерфейс перманентно тормозит

от этого никак не застрахуешься - сбой может вызвать приём блока из FF вместо кода программы и тогда тоже смерть

Что-то мешает иметь отдельно:
1) драйвер собственно контроллера (например, Nemo-IDE).
2а) драйвер ATA-2 для НЖМД.
2б) драйвер ATAPI для CD-ROM

если за каждым байтом идти в драйвер ниже, скорость чтения винта будет ниже скорости дисковода. так даже в windows не делают. хотя в комбинированный драйвер (Nemo+ATA+ATAPI) можно добавить отдельные функции для чтения ATA-регистров, чтобы любители опрашивать клаву в цикле чтения смогли это сделать, жертвуя скоростью обмена

как его вообще можно найти на спектруме? Он или лежит на одном диске с запускаемой программой или не лежит

в принципе, поиск не очень важен. за рабочий вариант можно взять загрузку 1го сектора всех файлов на диске, пока не найдётся с нужным guid'ом. ну или не всех, фильтр по расширению поставить

Если мысль дальше развивать, то сервис достаточен единственный: поиск модуля кода с таким_то_номером_интерфейс� � и его использование через данный интерфейс

использование, как я понимаю, это включение страницы, куда загружен код и вызов этого кода?


нерешаемых проблем не видно. только нужно что-то сделать с im2 и добавить сервисы переключения страниц и распределения памяти. жаль, минимального решения не выходит - ещё немного, и получится ось

[fk0]

вот. значит, нужно умерить свои аппетиты. если и делать что-то вместе с чтением (музыка/мышь), то только на прерываниях.

Оставь это на усмотрение авторов программ. Вот лично я хочу
всё разворачивать в автоматы. А ты меня стало быть ограничиваешь
своим недофункциональным драйвером.

никаких разворотов в автоматы. а драйвер сам в те моменты, когда надо, запретит прерывания. в циклах ожидания и чтения их не обязательно запрещать.

Опять двадцатьпять, пошли по кругу -- ЗАЧЕМ ЦИКЛ?
Нет цикла, нет проблем. Кому очень позарез как надо мёртвый,
потенциально опасный (зависнуть может) цикл -- пусть сам себе
его напишет. Мне цикл не нужен.

хотя, проблема может быть в том, что драйвер окажется в другой странице и надо будет это учесть (то есть обработчик im2 тоже надо будет затачивать под такой COM)а если протокол обмена такой, что

Мне уже кажется, с автоматами было проще...

нельзя заранее определить время чтения? тот же ATAPI: после передачи пакета нужно дождаться BSY=0, проверить DRQ, считать byte count и это самое кол-во байт, опять ждать BSY=0, проверять DRQ, читать byte count. так пока DRQ не сбросится после BSY. получается, всю эту логику нужно тащить в каждую программу,
чтобы насувать туда опросов мыши и клавиатурыот этого никак не

С тем, что вся эта логика в том или ином месте должна наличествовать, надеюсь, спорить никто не будет. Так?
Я повторяю ещё раз:



А ЧТО МЕШАЕТ ИМЕТЬ *ДВА* РАЗДЕЛЬНЫХ ДРАЙВЕРА.



зачем, спрашивается, всё пытаться втиснуть в "bus driver"?
Вот логика будет размещаться, тем более, что для ATA/ATAPI
она разная, во втором драйвере. ЛОГИКА ТАМ БУДЕТ РАЗМЕЩАТЬСЯ,
я ничего не говорю при циклы. Цикл может опять же организован
быть по-разному. Кому надо тот зациклит двума командами.
Кому надо будет иметь отношения с автоматами. Для лентяев
можно написать библиотеку-обёртку /АППАРАТНО НЕЗАВИСИМУЮ/,
которая "обернёт" все функции в их зацикленные версии.
Это чем-то плохо?

если за каждым байтом идти в драйвер ниже, скорость чтения винта будет ниже скорости дисковода. так даже в windows не делают. хотя в

Я уже писал: за каждым блоком.

комбинированный драйвер (Nemo+ATA+ATAPI) можно добавить

Это вообще не имеет смысла, по очевидным причинам.
Достаточно опубликовать номера портов. Но как прав был
Немо... :-(

отдельные функции для чтения ATA-регистров, чтобы любители опрашивать клаву в цикле чтения смогли это сделать, жертвуя скоростью обменав принципе,

НЕТ. Абсолютный. Там жертв скорости никаких практически
нет. Блоки передаются целиком. Суть только в избегании
блокировки при отсутствии/неисправности/неготовности
накопителя. В момент передачи блока никаких тормозов нет,
в данном случае цикл именно в дравере, НО ОН НЕ ВЫЗЫВАЕТ
БЛОКИРОВОК НА НЕОПРЕДЕЛЁННЫЙ ПЕРИОД ВРЕМЕНИ, он
всегда исполняется за конечное и предсказуемое время.

поиск не очень важен. за рабочий вариант можно взять загрузку 1го сектора всех файлов на диске, пока не найдётся с нужным guid'ом. ну или не всех, фильтр по расширению поставитьиспользование,

Примерно так и сделано уже было. Для ускорения процесса предусмотривался создание каталога размещённых на диске
модулей (в отдельном файле, в конце диска).

как я понимаю, это включение страницы, куда загружен код и вызов этого кода?

Я про страницы не думал вообще -- это проблема уровня приложения. Если загрузит в страницу -- пусть её переключает.
Требуется чтение-запись из страницы -- изволь загружать
драйвер в основную память и сам переключай страницы.

Сам же говоришь -- нужно умерить аппетиты. И если с циклами
разобраться можно элементарно, то со страницами никакой
определённости нет. Потому не хочется даже и связываться.

нерешаемых проблем не видно. только нужно что-то сделать с im2 и добавить сервисы переключения страниц и распределения памяти. жаль, минимального решения не выходит - ещё немного, и получится ось

:-(

Минимальный аллокатор памяти -- стек. Реализуется элементарно,
если память только выделяется -- почему бы и нет? Обработку прерываний я бы тоже переложил на приложение, потому как оно
с конфигурацией памяти будет непосредственно связано.

Нет, ты лучше скажи, предложенный вариант (с сайта cdwalk) --
он чем плох? Именно по функциям. По-моему -- оптимален.
Хотелось бы иметь аналогичный вариант уровня ATA и ATAPI,
а также более общий к ним драйвер "блочного устройства".

[breeze]

Ну как я понял, пролистав 11 страниц что воз и ныне там...

А так хотелось праздника

Господа, дыкть может придём к решению какому-нибудь ? или zx.pk.ru место где только хорошо языками чесать ?

[Advertiser]

[James DiGreze]

Воз пока на месте. Работа над поддержкой FAT16 ведется, но, в данный момент, по остаточному принципу. Если с чтением файлов все более или менее понятно, то запись файлов - задачка довольно нетривиальная...
Есть задумка сделать нечто, похожее на CD-WALK, но обнадеживать пока не буду, ибо со свободным временем напряг...

[breeze]

Если с чтением файлов все более или менее понятно, то запись файлов - задачка довольно нетривиальная...

жаль конечно а что-нибудь более менее рабочее или хоть наработки какие-нибудь есть ?

[James DiGreze]

К превеликому сожалению, пока ничего, что можно показать, нет.

[Speccyfan]

Эх. году этак в 2000-м я пробывал работать с IDE устройствами (сейчас даже схему не помню, там набор портов, просто АП6-х кажысь) написал audio player CD и читал/писал по секторам на винт. А вот fat16 так и не раскрутил, заткнулся на умножении/делении 4-х байтных чисел, не помню для чего но надо это. Жалкто что дискеты в свое время не все конвертнул, исходники наверное в большинстве своем пропали