SD карта для Cпециалиста на дискретах

[jdigreze]

 злостный оффтоп от склеротика

Извини, но ты, видимо, уже склеротик... )

Не! Нифига! Сейчас ведь специально полез читать про модель памяти и системы адресации, всё как я говорил, даже размер параграфа помню - 16 байт.

А в 580ВМ80 относительной адресации нет в принципе, как факт.

Это я уже для себя прояснил, больше можно не напоминать. Увы, но так уж случилось, что 8080 я не видел, ну и соответственно не работал с ним.

может таки расширить формат RKX, и добавить в его описание расширение и монитор(ы)? что бы получилось

Если уж расширять, то расширять расширяемо. Суть в том, чтобы уйти от жёстко заданной структуры дескриптора. А предложение такое:
1. Дескриптор внутри имеет поля с записями;
2. Все поля можно условно считать не обязательными;
3. Поле может иметь произвольную длину и структуру.

Поле начинается с байта, который определяет тип поля. Следом за байтом типа идёт длина поля. Следом байтом длины идут сами данные поля.

Например:

Code: Select all

DB 05h,08h,"FILENAME" ;05h - тип "имя файла", 08h - длина поля
DB 06h,03h,"EXT" ;06h - тип "расширение файла", 03h - длина поля

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

Честно говоря, связка файл данных/файл описатель - мысль довольно неплохая, на мой взгляд.

Это да, только нужно быть аккуратным, чтоб случайно описатель не удалить.

[PVV]

Мне самому больше импонирует вариант связки файла данных и файла описателя, это очень удобно для работы на 'больших' ПК но! это очень неудобно для работы на наших 'маленьких' ПК, а этот RKX формат придумывается для работы то на 'маленьких' ПК! (Для кого это делается для маленького или большого? ) Вот и получается, что лучше иметь все в одном файле с начальным 'хеадером'. Опять же, делать структурирование записей полей, это хорошо и удобно с точки зрения обработки на 'большом' ПК и в эмуляторах, а на ВМ80 это совершенно избыточный, лишний оверхеад, который будет лишь съедать место в коде обработчика, а места то у нас очень мало, почти что нет! Если и смотреть в сторону структурирования, то тогда это применимо только к связке файл данных+описатель. Далее, вот я вывожу список файлов в sddos, а у меня на экране всего то 25 строчек... и из этих 25 строчек каждая 2 избыточна при печати, тк это то же имя файла, но с другим расширением( его описатель)... делать фильтр на вывод - тоже плохо- если нет этого описателя, а я и не знаю об этом,

Это да, только нужно быть аккуратным, чтоб случайно описатель не удалить.

вот-вот...
то, что касается расширяемости, то предложенный ранее вариант не имеет фиксированного размера, его конец определяется по 0xE6, и любой файл с 'расширенным' дескриптором обработается 'старым' обработчиком, просто пропустив новые, неизвестные ему поля...
я бы только пункты 5) и 7) расширил, не только имя, но и расширение добавил бы... например, загружать фонты, или патчи на имеющийся в памяти код, те не обязательно 'монитор' это файл монитора с расширением MON, но и любой другой двоичный файл, главное, чтоб его имя содержало адрес загрузки как в мониторе. Или это некий блок переменных и стека в ОЗУ, которые монитор при своем старте инициализирует, тогда не нужно будет передавать управление монитору, для этих операций, только тогда нужно и позицию стека внести в дескриптор... но это, наверное, излишне.

[Lavr]

 злостный оффтоп для склеротика

Извини, но ты, видимо, уже склеротик... )

Не! Нифига! Сейчас ведь специально полез читать про модель памяти и системы адресации, всё как я говорил, даже размер параграфа помню - 16 байт.

Ты как в анекдоте:"Нет у меня склероза! Вот - пошел... посрал... смыл... Забыл снять штаны!"
Я к тому что не размер параграфа - 16 байт, и не сегментная модель памяти обеспечивают независимость
программы от размещения её в памяти, а именно - относительная адресация.
А в ЕХЕ-файлах там никакой независимости нет. Там тупо при загрузке сама ДОС правит т.н. "таблицу
релокейшнов" - суть абсолютных адресов дальних вызовов.
Так что твой восторг по поводу размера параграфа в 16 байт совершенно не при делах по сабжу...

По поводу файловой системы - здесь варианты какие: либо используем готовый формат и без натуги пользуем все наработки...
Либо придумываем оригинальный формат и тогда всё придется привести к этому формату...

А вобще - полноценную файловую ОС для маленького компьютера написать проблематично,
как раз из-за нехватки памяти.
Я смотрел как дорабатывали дисковую ОС для "Специалиста", так из-за нехватки памяти часть
подпрограмм ОС запускали из экранного ОЗУ - но всё-равно тема завяла только из-за нехватки ОЗУ.

[PVV]

так для МХ применительно к SD нет формата и наработок нет! таким образом мы сейчас и придумываем этот формат! и из-за катастрофической нехватки памяти я и хочу такой формат сделать, с которым будет удобнее работать на ВМ80, который легко может быть интегрирован к существующим наработкам.

[fifan]

Меня никто не слушает. Вы что хотите поддержать? Продолжение века эмуляторов? Зачем мы тогда последние 15 лет делаем реальные железки специалистосовместимые. Вот перечислю их всех скопом:
1. Специалист МХ2;
2. Специалист 48 SRAM;
3. Специалист/Специалист МХ на ПЛИС;
4. Сябр;
5. Специалист МХ2 на ПЛИС (проект не опубликован);
6. Специалист SRAM (проект не опубликован);
Это не считая двух реплик Специалиста М.
Мы тупо их делаем чтоб что? Опять переписывать ПО с эмулятора в железку и обратно? Мне для этого дела вполне достаточно cpu/i80 и odi. Последний обладает большой вместимостью (800 кБайт), просто не у кого нет контроллера дисковода (или его эмулятора) чтоб с серьёзно с ним работать. Я например в своём SpetsCommander'е сделаю cpu/i80 только на чтение.

RKX формат хороший формат. Достоинства: один файл, задаваемое расположение файла в памяти, лёгкость запуска. Зачем из этого формата файла делать монстра? Писать плюс к нему ещё и монитор в этот же директорий SD карты? Зачем? Один раз запустить? Может нужно уяснить что "стандартный" Специалист - это Специалист мониторный с командной строкой, а МХ - тупо стандартизированный BIOS - RAMFOS, да и нет в нём командной строки по большому счёту. Все кто писал программы на МХ делал их применимо с псевдографической оболочке MX-DOSа или просто писал красивые (16-ти цветные!) игры. Никто не работал с подгружаемыми мониторами.

Я не против формата RKX как такового, я против поддержки в нём кучи подгружаемых мониторов. Lavr прав, сейчас писать под Специалист МХ туго - тупа нет памяти. А куда мы будем подгружать монитор? Из перечисленных мною выше Специалистов только Специалист МХ2 имеет теневое ОЗУ. Хотя как с ним работать знает только автор.

[PVV]

Есть стандартный 'Специалист'- STD. Для него файлы RKS простым копированием переносятся с\на SD. Расширений у файлов, как и самой файловой системы на STD нет. Здесь все четко и понятно.

далее
Есть 'СпециалистМХ(2)', его ОС РАМФОС, файловая система РАМФОС, и файлы имеющие расширение (не только, но пока остановимся на этом).

У нас задача\вопрос - как нам из ОС РАМФОС работать с SD картой?
граничные условия - формат файловой системы на SD карте FAT16.
возможная реализация - простой перенос файлов из SD карты с FAT16 на RAM диск РАМФОСа и обратный перенос из RAM диска на SD. Как в этом переносе учитывать расширение из файловой системы РАМФОС, если на SD карте у нас фиксированное расширение RKX? - отказываемся от RKX и оставляем расширение как в РАМФОСе? а что тогда делаем с адресом загрузки? делаем 4 байта добавку как в RKS?

я вижу 2 варианта решения этой задачи - связка файл данных+описатель и некий 'расширенный вариант RKS' который называем RKX. Возможную структуру расширения я описал выше. Монитор в этом расширенном описателе опционален, если он не нужен, его там указывать не надо и места в описателе он не занимает. Просто закладываем себе возможность, зачем сразу связывать себя по рукам и ногам? думать на опережение надо... что бы потом не придумывать новые стандарты и расширения.
Касательно 'монитора', надо его рассматривать шире, а не только 'монитор' в понятии дампа ПЗУ. Это может быть новый шрифт, а может patch того же РАМФОСа. - Вот Lavr как-то писал, что у него на МХе ПЗУ запаяны и он не хочет их перешивать и работает со старой прошивкой РАМФОС. Загрузит он с магнитофона sddos (вот где мои стремления к уменьшению размера кода пригодятся), и запустит программку, которая и РАМФОС обновит и загрузит все что надо одним заходом, без лишних движений, и это все лишь ценой 'опциональной закладки' в описатель такого 'монитора', плохо разве?
И еще, ну почему мы сразу отрезаем себе возможность загрузки из МХа программ от STD? Отсекая сразу внушительный процент от и так не слишком большого объема наработок для 'Специалиста'.
В МХ2 да, мы можем загрузить Loader_ом нужный монитор и работать в нем, хотя, а кто к этому монитору работу с SD картой добавит, как программы в этом мониторе грузить будем? опять получается ценой 'опциональной закладки' в описатель эта проблема спокойно решается...

Связку cpu\i80 использовать на реале нельзя, нужно ее изменять, те придумать новый формат надо - вот же этим и занимаемся...

[Lavr]

Вся сложности, как я вижу, заключается в том, что одним и тем же словом "Специалист" обозначаются
по сути весьма разные компьютеры...

И ставится цель всё это как-то аппаратно "скрестить", а это трудно, на мой взгляд, поскольку
"Специалист МХ" и был апаратной попыткой объединить в одном железе все ранее существующие
модификации "Специалистов".

А теперь - снова стартует попытка "замесить" его в общей куче других "особей"...

[aav8]

Я как-то давненько делал ОС для Партнера 01.01.
С самодельной платой для связи с PC через RS-232.
PC в качестве файлового хранилища, еще потом туда приделал
терминал.
Насчет формата файловой системы вообще не задумывался:
при открытии файла ВСЕ имя файла (кроме устройства)
передается в РС - а там он сам все разруливает...

[fifan]

Я как-то в разговоре с Александром Шевцовым (один из Специалист МХ строителей, автор эмулятора) услышал, что зачем сделали этот Специалист МХ2 многорежимным и так просто МХ достаточен. И Lavr чуть выше это подтвердил. Всё что когда-то было на Специалисте ("стандарт") перенесли на Специалист МХ давным давно.

Зачем думать что на SD карту перенесётся файл без адресов посадки в памяти. Мы для чего это делаем? Опять в эмуляторе файл юзать или просто на писишке использовать? В последнем случае не пох.. адреса? Простой пример. Я несколько раз пересылал тестовые файлы на писишку, чтобы описание программы (я брал Layout) можно было в ворде хорошо оформить. На Специалисте МХ уже есть операционная система RAMFOS/MX-DOS и достаточно. Зачем нужна какая-то псевдо SD система? Здесь нужно думать в другом направлении. Как поменять что-то в RAMFOS/MX-DOS чтоб он стал понимать SD карту. Делать такой софтовый эмулятор зашитый в пзушку.
Далеко не надо ходить за примерами. Был такой Константин Юденцов, который на платформе Специалиста МХ изобрёл свою ОС в виде "Commander'а" - http://www.spetsialist-mx.ru/index19.html. Там общение с устройствами сделано через драйвера. Я написал драйвер для дисковода (автор не успел наверное, не дожил до MX-DOS). С усилием можно написать драйвер и для работы с SD картой.

[Lavr]

...зачем сделали этот Специалист МХ2 многорежимным и так просто МХ достаточен.

Ну это автор "Специалиста МХ2" так захотел, а поскольку он был сам себе режиссер и никого
не слушал, то так оно и вышло.

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

Не всегда наши желания совпадают с 8-битными возможностям...

[PVV]

Обнаружил одну весьма существенную недоработку в описателе файла - как будут файлы с одинаковыми именами и разными расширениями на ФС РАМФОС сохраняться на SD карту (и обратно) при использовании фиксированного расширения файла RKX (для cpx\i80 все аналогично)? - надо в описатель добавить полное имя файла с расширением, а не только одно расширение. Это даст возможность на SD иметь разные имена RKX файлов при такой необходимости, а в описателе имена, как они на ФС РАМФОСа. С учетом этого, директива sddos S преобразуется в такой вид:
S ИМЯфайла.РАСШИРЕНИЕфайлаНаRAMдиске,ИМЯфайлаНаSD. При этом, я думаю, можно сделать ИМЯфайлаНаSD опциональным параметром, и указывать его только для варианта файлов с одинаковыми именами но разными расширениями.

Зачем думать что на SD карту перенесётся файл без адресов посадки в памяти. Мы для чего это делаем? Опять в эмуляторе файл юзать или просто на писишке использовать?

Я рассматриваю свой вариант-отладил я какой то код в эмуляторе на PC и хочу его проверить на реале, как я этот код на реал скину, если у меня магнитофонный интерфейс в 'Специалист'_е даже не предусмотрен? Затем этот код как то подкорректировал, или дополнительно, какой то кусок памяти захотел на PC перекинуть, что мне делать? Вот я и хочу сделать удобный для себя инструмент...и возможно, этот инструмент пригодится кому-то еще...

На Специалисте МХ уже есть операционная система RAMFOS/MX-DOS и достаточно. Зачем нужна какая-то псевдо SD система? Здесь нужно думать в другом направлении. Как поменять что-то в RAMFOS/MX-DOS чтоб он стал понимать SD карту. Делать такой софтовый эмулятор зашитый в пзушку.

То, что sddos так называется, еще не значит, что это 'Дисковая Операционная Система', это некая программа, которая может перекидывать файлы с SD в ОЗУ и обратно, и имеющая некий набор дополнительных функций.
На счет другого направления - мы начинали обсуждать тему эмулятора ВГ93, но как-то все притормозилось хотя задумка интересная, а сейчас я вижу, что можно сделать совсем иначе, сложнее программно, но не прибегая к аппаратным доработкам -
внести программные доработки в, фактически, три программы - RAMFOS, MX-DOS и CPM следующего плана. Запуская из sddos некий аналог ODImounter, выбираем ODI файлы для диска А и В. Запоминаем в ОЗУ в каком секторе и в какой позиции этого сектора находится запись FAT с первым сектором ODI файла(это первый указатель на кластер с данными из последовательной цепочки кластеров с этим ODI файлом) для А и В дисков. Возвращаемся в РАМФОС. Запускаем MX-DOS, как? Нам sddos уже не нужен, знать как устроен FAT16 тоже не нужно, просто читаем данные, используя последовательные указатели из FAT на кластеры с нашим ODI. Если выбрать размер раздела на SD в 1-2ГБайт, что бы размер кластера получился в 32КБ, то на один odi файл в 800КБ будет 800/32=25 записей в FAT. Математика здесь простая, нужно будет иметь функцию, которая может читать сектор с SD, и вторую для записи сектора. Места эти функции займут не слишком много. Вот в этом направлении можно покопать... Если б надо было много программ адаптировать, то альтернативы аппаратному эмулятору нет, а с таким скромным числом, вполне можно и заморочиться. Для РАМФОСа, там вообще все очень просто будет.

[Lavr]

Джентельмены, не забывайте еще такую вещь: в системе RAMFOS был еще и ROM-диск, диск из ПЗУ-шек.
И хотя у меня и был старый RAMFOS, намертво впаянный двумя этажами РФ4, я отлично всем пользовался
безо всякой подгрузки с магнитофона.
У меня стояла одна ПЗУ-шка в ROM-диске с программой LOADER, и этот LOADER просто корректно
стартовал MX-DOS.
А дальше у меня на дисках и RAMFOS был новый и собственноручно переписанный MX-DOS, который
был модифицирован так, что удачно прочитывал сбойные дискеты (но это сейчас неактуально).

Следует помнить, что RAMFOS при работе находится в ОЗУ и очень легко модифицируется умеючи.

У меня лично было 2 "горячих" патча RAMFOS - по сути это были аналоги PRINTSCREEN на диск экрана
в текстовом виде и экрана в графическом виде.

Насчет формата .odi - это всё же не формат, а посекторный образ диска, с которым либо эмулятор работает,
либо специальная утилита Афанасьева.
На карту всё же лучше переносить отдельные файлы из ххх.odi .

Далее: карта это всё же аналог диска, но огромный. Целиком работать с ней не выйдет из-за размеров FAT.
Как показывает опыт MX-DOS, FAT дискеты в 800К - уже занимает прилично места в ОЗУ.
Так что придется пользовать карточку участками по 800К используя опцию USER как в CP/M.
Можно USER по названию "квазидиска", а не по номеру.

Теперь - как автоматом цеплять мониторы: я думаю "автоматику" надо уменьшить - все файлы RKX
для одного монитора держать в одной папке и там же держать один монитор с фиксированным именем,
предположим, MONITOR.
Тогда с каждым файлом из этой папки он единственный и загружается, а файлы - как были формата RKX,
так и остались: Адр.начала, Адр.конца, КС.
Сам MONITOR в таком же формате.

[Akatla]

Всем, Привет!

Ну что ж, почитаю это все и попробую разобраться! Может тов. Лавр в чем то поможет!

[Lavr]

...почитаю это все и попробую разобраться! Может тов. Лавр в чем то поможет!

По этому вопросу тов. PVV основной держатель акций. Я себе SD карту не подключал,
у меня реальный дисковод с флоппи-дисками подключался...