nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 05:01



Reply to topic  [ 29 posts ]  Go to page 1, 2  Next
SD карта для Cпециалиста на дискретах 
Author Message
Doomed

Joined: 12 Feb 2016 13:39
Posts: 463
Reply with quote
Решил собрать информацию по реализации SD интерфейса на дискретных элементах в одном месте и здесь же продолжить дальнейшее обсуждение перспектив использования SD, тк сейчас информация по подключению SD карты к 8и битным ПК разбросана по разным местам. Пишу в теме по 'Специалист'_у тк основные проверки на реальном железе буду делать на нем.

'Ноги' SD интерфейса растут из схемы реализованой на плис ХардвареМаном для 'СпециалистаМХ2'. На данный момент я сделал отработку этого интерфейса в Протеусе, собрал его в реале на макетной плате и подключил к 'Специалисту'. После всех доводок, последняя версия схемы выглядит так. Кроме того, я сделал модификацию этой схемы для RK-86, вот здесь, проверенная на реальной РКшке версия.

Однако железо без ПО будет лишь грудой металлолома, и по этому в сети был найден SD_DOS, написанный, как в последствии выяснилось, b2m_ом, для интерфейса реализованного по схеме 'msx'. Этот SD_DOS я, в начале, адаптировал под текущий SD интерфейс, а затем и доработал новыми 'фишками'. Отступление - вариант схемы для 'msx' существенно медленнее в работе(я не проверял, но думаю, что на порядок) и гораздо неудобнее при программировании чем новая схема.

Вот, что у меня получилось.
Дефайнами можно настроить размещение этого кода в памяти ПК и область для хранения переменных в процессе работы. Удалил поддержку FAT12, оставил только FAT16 - для экономии места.
Организовал пока 3 предустановленных конфигурации, это STD, MX2 и RK86. STD и MX2 - это для 'Специалиста' стандартного и варианта МХ2, а RK86 сотв для РК-86. Разделение сделано для удобства, тк некоторые используемые в коде подпрограммы 'мониторов' этих ПК имеют сходство, но разные точки входа.
Для РК-86 есть возможность выбрать поддержку интерфейса через дефайн RK86_WW55, но никто не запрещает сделать аналогично и в других конфигурациях. Отступление - вариант с подключением через ППА 580ВВ55 получается медленнее в 3-4 раза. Хотя все это быстрее-медленнее - при имеющихся размерах файлов речь идет о единицах секунд, что почти не соизмеримо с минутами загрузки с магнитофона.
Для STD варианта я сделал такое распределение памяти - с 0хС000-стандартный монитор, 4КБ, а с 0хD000 уже sddos, переход на sddos по команде монитора GD000. В моем 'железном' 'Специалисте' область с 0xE000 по 0xEFFF отдана под ОЗУ и я переменные, используемые для работы sddos_ом выделил с 0xE000, там надо 2КБ, но, опять же, никто не запрещает эту область выделить в 0х8000, например. Однако это уже наложит ограничение на загрузку в, и использование этой области стандартными программами.
Для MX2 я sddos в виде запускаемого файла записал в ROM диск, и его можно запустить из RAMFOS_а. sddos размещается с 0xD400, а переменные с 0хЕ000. Такое размещение не машает RAMFOS и позволяет из RAMFOS работать с SD картой.
Для RK-86 sddos с подключением интерфейса через ВВ55 размещается с 0х6000 и запускается директивами монитора R0,7FF,6000 затем G6000. Я уменьшал код, что бы уложиться в 2КБ, а переменные разместил с 0х6800. Если же sddos записать в ПЗУ, то можно его разместить с 0xF004, и запускать его по GF004, а переменные, так же, с 0х6800. Для варианта РК ограничение на размещение программ в области sddos и его переменных есть всегда(для стандартного RK-86 на 32КБ).

================================================================================
sddos поддерживает следующие директивы:
- CD ИМЯкаталога - перейти в каталог с указанным именем;
- DIR - вывести список файлов и каталогов;
- ИМЯфайла.RKX(RKS для std и RKR для RK-86) - запустить файл, при этом
расширение можно не набирать, будет произведена автоподстановка расширения;
- R ИМЯфайла.РАСШИРЕНИЕфайла,АДРЕСкуда,СКОЛЬКОбайт - прочитать в память не
запуская данные файла, начиная с указанного адреса и сколько байт
(пример: R TEST.BIN,0ACD,5FE0 - читает файл TEST.BIN в память
начиная с адреса 0х0ACD и до адреса 0х0ACD+0х5FE0=0х6AAD). Ограничение -
нет проверки на фактическую длину файла и запрошенную на чтение, те
можно запросить прочитать больше чем размер файла, поведение не
определено;

- W ИМЯфайла.РАСШИРЕНИЕфайла,АДРЕСоткуда,СКОЛЬКОбайт - записать в файл
данные из памяти, начиная с указанного адреса в памяти и сколько байт
(пример: W TEST.BIN,0ACD,5FE0 - пишет в файл TEST.BIN из памяти начиная
с адреса 0х0ACD и до адреса 0х0ACD+0х5FE0=0х6AAD). Ограничение - нет
проверки на фактическую длину файла и запрошенную на запись, те можно
запросить записать больше чем размер файла, поведение не определено.
Записать больше чем существующий размер файла нельзя. Если записать
данных меньше чем размер файла, то размер файла не меняется и остается
прежний;

- X - перейти в монитор, из которого был запущен sddos.

Для версии МХ2 добавил новые директивы:

- L ИМЯфайла.РАСШИРЕНИЕфайла,НАЧАЛЬНЫЙадрес_в_RAMдиске - прочитать данные файла с SD в RAM диск МХа
(пример: L TEST.BIN - читает файл TEST.BIN в память начиная с адреса 0х0000 и до адреса его длины,
создает в RAM диске файл TEST.BIN с стартовым адресом 0х0000 и размером как TEST.BIN на карте. Или:
L TEST.BIN,1FA0 - читает файл TEST.BIN в память начиная с адреса 0х0000(не 0х1FA0) и до адреса его длины,
создает в RAM диске файл TEST.BIN с стартовым адресом 0х1FA0 и размером как TEST.BIN).

- S ИМЯфайла.РАСШИРЕНИЕфайла - записать данные файла из RAM диска МХа на SD
(пример: S TEST.BIN - читает файл TEST.BIN из RAM диска в память начиная с адреса
0х0000(не зависит от стартового адреса!) и до адреса его длины, после записывает
его на SD карту в существующий файл с таким же именем TEST.BIN, размер не изменяется!).
================================================================================

При выводе каталога по DIR печатается имя, расширение файла и его
размер(что бы можно было использовать директивы R и W), а на директории
в поле размера файла пишется DIR.
При выводе списка файлов по DIR нажатие любой клавиши приостанавливает вывод на экран.
При запуске файла пишется стартовый и конечный адреса куда будет считан
файл с карты.
Для МХ2 сделал возможность запуска RKS файлов из RAMFOS, а не только RKX.
Загружается файл (автоподстановка расширения работает) и загружается монитор M2_C000.MON(имя жестко вбито в код),
который должен находиться в том же каталоге, что и запускаемый файл, и передается управление на монитор(jmp 0xC000).
Адрес запуска программы сохраняется в стеке. Монитор взят из файлов vinxru в его 'перекомпилированном' RAMFOS.
Этот монитор переключает режим МХ2 на STD и запускает файл по адресу из стека.

Один из приятных моментов этого SD интерфейса (как, впрочем, и 'msx' варианта), это поддержка этих интерфейсов в эмуляторе b2m,
что дает возможность отлаживать код и оперативно его проверять.

Во вложении файлы для эмулятора b2m, а так же исходники sddos_v7, с функционалом описанным выше.
После запуска активен Монитор-4, в нем:
- можно по Х попасть в РАМФОС, по F6 перейти на ROM диск и запустить SDDOSMX2.COM. Далее тонкость - мне 'лень' пересобирать ROM диск
каждый раз при изменении sddos, по тому текущий SDDOSMX2.COM на диске старый, новый же хранится на SD, нужно набрать и запустить DOS1, а затем DOS2,
вот DOS2.RKX это и есть последняя версия sddos. При желании его можно записать на ROM диск, но тк sddos еще в работе, то я его пока не записываю,
а на 'реале',при проверке, запускаю так же DOS1 -> DOS2... тк перешивать ПЗУ желания вообще нет :).
- можно по U запустить LoaderV5, который загрузит файл BIOS.BIN (это любой монитор для стандартного специалиста) из корня SD карты и передаст на него управление. Из монитора можно выполнить GD000, запустится файловый менеджер fifan_a для SD (так собран этот BIOS.BIN :) ). Если же сделать файл монитор+sddos, то получим доступ к SD карте в стандартном 'Специалисте'.
Еще момент, для работы с образом SD3.IMG из linux образ в каталог sd монтировать так: sudo mount ./SD3.IMG ./sd -t vfat -o loop,offset=32256 .


Attachments:
SpecialistMX2.zip [674.34 KiB]
Downloaded 508 times
sd_dos_v7.zip [73.77 KiB]
Downloaded 491 times
25 Apr 2017 06:18
Profile
Doomed

Joined: 12 Feb 2016 13:39
Posts: 463
Reply with quote
Теперь о проблемах.
Хотел реализовать загрузку cpu\i80 файлов, идея хорошая, все логично, но столкнулся с таким моментом - файлы монитора MON это не просто дамп ПЗУшки, а полноценный запускаемый файл, что для меня было открытием... в эмуляторах идет загрузка этого монитора, его запуск (монитор переносит себя в нужные ему адреса), а затем, через секунду идет загрузка требуемого файла i80 (спасибо Pyk за разъяснения этого момента!), реализовать такой механизм на реале не получится. Я решил, не беда, кто мешает загрузить и файл программы и монитор, и передать управление на монитор, а уже из монитора руками выполнить директиву Gххх на программу, сделал это, работает..., НО столкнулся с монитором r6_0000.MON ! этот монитор загружается с адреса 0х0000 и программы к нему загружаются с 0х0000 ! :(
Понял, что нужен другой подход. Первое, что приходит на ум - сделать аналог cpu файла, например, cpx (как RKS - RKX), в котором будут указаны реальные адреса для загрузки монитора, и сами мониторы модифицировать так, что бы их можно было таким образом подгружать и запускать, а они уже адрес старта программы будут брать из известного им адреса (тут тоже момент есть, как я понял, монитор может быть 'разбит' на две части). Именно так, например, сделано с монитором M2_C000.MON от vinxru, который я использую для загрузки RKS файлов в МХ режиме из РАМФОСа. Есть у кого какие идеи на этот счет?
Далее как быть с переносом файлов из SD в RAM диск и обратно. Сейчас у условного бинарного фойла на SD нет информации о его стартовом адресе, который нужен для правильного заполнения заголовка 'хеадера' файла на RAM диске, я этот адрес задаю руками, и при обратном переносе эта информация у меня выкидывается... как мне видится нужно или весь 'хеадер' записывать перед файлом при копировании его на карту и, аналогично его считывать, или, как по формату RKX только 4 байта записывать... вообщем, аналогично у кого какие идеи на этот счет?

Что касается создания, удаления, переименования и тд файлов на SD, то это можно делать как на большом ПК, так и при помощи сторонних программ, вызываемых с карты, для которых передавать, например, через стек адрес на строку с параметрами, что нужно делать.


25 Apr 2017 06:27
Profile
Devil

Joined: 30 Nov 2013 11:08
Posts: 706
Location: WWW
Reply with quote
Кстати, в моем PC1-88 я тоже делал интерфейс с SD картой на дискретных элементах, причем вроде у меня получилось немного проще... Правда, у меня интерфейс простейший - чтение/запись одного байта, все остальное - программно.


25 Apr 2017 06:44
Profile
Devil

Joined: 06 Oct 2006 03:17
Posts: 856
Location: г.Лянтор,Сургутского р-на,ХМАО
Reply with quote
Я уже писал автору и всем сообщаю, что реально SDDOS на самой железке (Специалист МХ2) не работает. Главное в эмуляторе (b2m) всё чётко - и каталог читается и файлы запускаются, а вот в реале нет. Самому даже жалко. Напомню, что для SD интерфейса на Специалисте МХ2 нет почти ничего. Почти - это только Loader V5. Печальки. :cry:


25 Apr 2017 08:49
Profile
Doomed

Joined: 12 Feb 2016 13:39
Posts: 463
Reply with quote
newold86 wrote:
Кстати, в моем PC1-88 я тоже делал интерфейс с SD картой на дискретных элементах, причем вроде у меня получилось немного проще... Правда, у меня интерфейс простейший - чтение/запись одного байта, все остальное - программно.

Так это вообще один в один со схемой для РК-86 и подключением через ВВ55, разница минимальна, только счетчик 8 тактов на байт и его отсечка реализован на одном элементе ТМ2, в отличии от 2х у меня, иначе, по протеусу у меня шел то ли по приему, то ли по передаче пропуск одного бита при сдвиге... все остальное упрощение сделано применительно к конкретной схеме и не принципиально.

fifan wrote:
Я уже писал автору и всем сообщаю, что реально SDDOS на самой железке (Специалист МХ2) не работает. Главное в эмуляторе (b2m) всё чётко - и каталог читается и файлы запускаются, а вот в реале нет. Самому даже жалко. Напомню, что для SD интерфейса на Специалисте МХ2 нет почти ничего. Почти - это только Loader V5. Печальки. :cry:


Эта схема собрана у меня на дискретах, а не на плис, и у меня она спаяна, подключена и проверена на реальных платах стандартного 'Специалиста' с тактом 2Мгц, так и на моем варианте схемы 'СпециалистМХ2' на DRAM, а не SRAM, так же с тактом 2.5Мгц и VGA выходом. Однако, я не думаю что это принципиально для SD интерфейса. Кроме 'Специалиста' эта схема запущена и реально работает на РК-86 в варианте через ВВ55. Вопрос запуска sddos на первоначальном варианте SD интерфейса с реализацией на плис - лишь желание и время его запустить, все исходники есть. Плис очень скоростная, и такт в 10Мгц на SD, применительно к нашему ВМ80 очень много, что там творится внутри плис, я сказать не могу. На дискретах ВСЕ работает.
Все же я хотел услышать предложения по организации форматов файлов применительно к файлам на SD.


25 Apr 2017 10:09
Profile
Devil

Joined: 06 Oct 2006 03:17
Posts: 856
Location: г.Лянтор,Сургутского р-на,ХМАО
Reply with quote
На счёт файловой системы на SD карте моё мнение таково.
cpu/i80 - это файлы только эмулятора, изначально от Шевцова, потом и b2m. SD интерфейс будет работать на реальном Специалисте МХ. Эти файлы можно сделать только для чтения, запись не нужна.
rkx - интересный формат, но не надо зацикливаться на применении множества подгружаемых мониторов. Зачем? В 90-е года это была необходимость, а сейчас давайте остановимся на RAMFOSе, как де факто BIOS Специалиста МХ. Я за rkx формат и надо обязать писателей ПО его поддерживать.

На счёт записи/чтения в/из RAM-диска. PVV, если я помню rkx формат, там есть и начальный адрес и конечный. Этого вроде же достаточно для дескриптора RAM-диска. Зачем утруждать себя загрузкой каких-то бинарных файлов? Для чего? Нужно определиться что мы вставляем SD карту в стандартный Специалист/Специалист МХ - так будьте любезны оперировать только с rks и rkx файлами. Мне допустим лишний раз не лень зайти в хек редактор и понаставлять лишних десяток байтов ручками и потом уже использовать готовый специалистовский файл на SD карте по назначению. Ты ж сам пишешь: Что касается создания, удаления, переименования и тд файлов на SD, то это можно делать как на большом ПК, так и при помощи сторонних программ, вызываемых с карты, для которых передавать, например, через стек адрес на строку с параметрами, что нужно делать. Так и давай всё делать на писишке.

В MX-DOS, например, есть десяток применяемых расширений и все нормально уживаются на дискетах потому, что у них всех стандартный дескриптор. Например программатор и хек редакторы используют расширение HEX, редактор - TXT и т.д.


25 Apr 2017 11:11
Profile
Doomed

Joined: 12 Feb 2016 13:39
Posts: 463
Reply with quote
так ведь как получается, хочу я прочитать с SD карты TXT файл, а куда его читать в память то?, и аналогично, хочу с RAM диска записать этот TXT на карту. Когда этот файл на RAM диске, то в его дескрипторе информация по размещению имеется, а если просто записать на SD, то эта информация потеряется... вот я и думаю, что на карте все файлы хранить с заголовком (хеадером), в 4 байта, как у RKS. Это может и BIN, и ASM, и BAS, и что угодно, но первые 4 байта , это заголовок, старт и длина... во всем этом один БОЛЬШОЙ МИНУС - редактировать на наших 'больших' ПК такие файлы несколько неудобно... а вот что-то типа cpx/i80, в таком варианте был бы правильней и логичнее- в cpx файле всю сопроводительную информацию описал, а с файлом i80 без каких либо изменений можно работать где угодно, при этом в cpx можно хранить расширение файла, его действительный размер, а не использовать физически занимаемый на SD карте размер файла, как я это сейчас сделал... вот по чему я и хочу этот вопрос по обсуждать.
Касательно загрузки других мониторов - я не знаю, сколько имеется наработок для таких мониторов, но при использовании конструкции cpx/i80 это становится совершенно естественно и прозрачно, минус этого подхода - усложнение программирования и увеличение кода sddos, который я, изначально, хотел уложить в 2КБ ПЗУ РФ2(зачем? - ну так хотелось...).


Last edited by PVV on 21 May 2017 23:18, edited 1 time in total.



25 Apr 2017 11:37
Profile
God

Joined: 02 Jan 2006 02:28
Posts: 1390
Location: Abakan
Reply with quote
Я совсем не специалист по Специалистам, но зачем для текстовых файлов сохранять адрес загрузки понять не могу.
Адрес загрузки должен определяться текстовым редактором. А длина файла имеется в дескрипторе FAT.

Это у машинного кода нужна привязка к адресам, но для этих целей та же MS-DOS в EXE-файлах хранит адреса коррекции и много чего ещё, в том числе точки входа, и там не подразумевается какая-то ручная корректировка, хотя она и возможна специальными средствами.


25 Apr 2017 19:39
Profile
Devil

Joined: 06 Oct 2006 03:17
Posts: 856
Location: г.Лянтор,Сургутского р-на,ХМАО
Reply with quote
Вот именно не специалист. Для записи в RAM-диск любого файла необходимо знать начальный и конечный адрес блока памяти. Вот тут почитайте odi формат - http://www.nedopc.org/forum/viewtopic.php?f=90&t=9406.

хочу я прочитать с SD карты TXT файл, а куда его читать в память то?, и аналогично, хочу с RAM диска записать этот TXT на карту.
А ты не хоти. Я же сказал давайте всё делать на писишке. Вот эту программу от автора Специалиста МХ вам в помощь - http://www.spetsialist-mx.ru/Soft/Lodi_3.rar. Я вообще хотел сделать поддержку только odi формата, но это сложно.


25 Apr 2017 20:28
Profile
God

Joined: 02 Jan 2006 02:28
Posts: 1390
Location: Abakan
Reply with quote
Молчу-молчу...

P.S. Как всё запущено :roll:


26 Apr 2017 01:12
Profile
Doomed

Joined: 12 Feb 2016 13:39
Posts: 463
Reply with quote
jdigreze wrote:
Я совсем не специалист по Специалистам, но зачем для текстовых файлов сохранять адрес загрузки понять не могу.
Адрес загрузки должен определяться текстовым редактором. А длина файла имеется в дескрипторе FAT.

для текстовых оно может и не нужно, это так.
А вот теперь пример из архива soft_mx_i80.rar с сайта fifan_а,
содержимое файла MUS_EDM0.CPU:
15EA
0000
*for mus_ed*

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

jdigreze wrote:
Это у машинного кода нужна привязка к адресам, но для этих целей та же MS-DOS в EXE-файлах хранит адреса коррекции и много чего ещё, в том числе точки входа, и там не подразумевается какая-то ручная корректировка, хотя она и возможна специальными средствами.

для ВМ80 программы жестко к адресам привязаны, в отличии от х86, а у нас есть и COM и EXE форматы в RAMFOS_е (хотя зачем это разделение? это ж, опять таки, не х86 с сегментом в 64КБ для COM...) так вот как наши COM и EXE сохранять на SD? в виде RKX? а куда девать это расширение и какое расширение ставить для файла RKX, переписываемого с SD на RAM диск?

fifan wrote:
хочу я прочитать с SD карты TXT файл, а куда его читать в память то?, и аналогично, хочу с RAM диска записать этот TXT на карту.
А ты не хоти.

Не могу не хотеть! Я ХОЧУ набрать basic программку на 'Специалисте' и ее записать на SD, а потом эту программку обратно прочитать с SD через год... иначе зачем вообще иметь возможность записывать что-то на карту?
fifan wrote:
Я же сказал давайте всё делать на писишке.

а тогда вообще смысл нашими ретро компами заниматься?...
fifan wrote:
Вот эту программу от автора Специалиста МХ вам в помощь - http://www.spetsialist-mx.ru/Soft/Lodi_3.rar. Я вообще хотел сделать поддержку только odi формата, но это сложно.

запустил, посмотрел.... что бы какой то файл с odi вытащить надо указать правильный формат, что хотим получить bin, rks, txt, и на выходе имеем файл с двойным расширением(TEST.COM.RKS , например для rks) те длинное имя... на SD так сразу не запишешь, нужно vfat делать...


Last edited by PVV on 18 May 2017 11:35, edited 1 time in total.



26 Apr 2017 02:03
Profile
Devil

Joined: 06 Oct 2006 03:17
Posts: 856
Location: г.Лянтор,Сургутского р-на,ХМАО
Reply with quote
В Специалисте МХ все файлы пишутся/читаются в/из RAM-диска. Значит нужно только организовать запись из RAM-диска файла с расширением BAS (в случае с Бейсиком) на SD карту. Всё. Только нужно как-то организовать пинок SD контроллеру типа "записать всё/выбор файла с RAM-диска".


26 Apr 2017 03:14
Profile
God

Joined: 02 Jan 2006 02:28
Posts: 1390
Location: Abakan
Reply with quote
PVV wrote:
для текстовых оно может и не нужно, это так
Вооот! То же самое с любыми текстовыми сырцами, типа BAS и прочих ASM, ежели они конечно именно текстовые, а не токенизированные али с прочими извратами. ;)

PVV wrote:
для ВМ80 программы жестко к адресам привязаны, в отличии от х86
В x86 тоже всё жёстко к адресам привязано, только что сама модель сегментации позволяет сдвигать 64К область в любую часть физической памяти с определённой кратностью (16 байт вроде как? или я уже склеротик? ;))

PVV wrote:
содержимое файла MUS_EDM0.CPU:
15EA
0000
*for mus_ed*
те это некий файл для музыкального редактора, и он загружается с определенного адреса. Если его перекинуть на SD, то вся эта сотпроводительная информация потеряется... повторюсь, может она и не нужна, но раз это кто-то придумал, значит просто так это терять нельзя...
Ежели это кто-то когда-то придумал, это не значит ровным счётом ничего. Есть определённые стандарты на дескрипторы файлов. Если нельзя дескриптор одной файловой системы (ФС) сохранить достоверно в дескриптор другой ФС, то, IMHO, можно применить обёртку, которая будет обрамлять файл его начальным дескриптором. В самом простом случае - так поступают архиваторы с нулевой компрессией, типа TAR. Нечто подобное реализуется форматом HOBETA для файлов ZX-Spectrum при работе на PC. Т.е. фактически остаётся открытым вопрос о том, что из дескриптора файла на Специалисте нужно сохранять, и для каких файлов. Уж точно не для файлов данных, типа текста.

P.S. Всё вышесказанное - IMHO, разрешается пинать ногами по лицу, но без серьёзных увечий, т.е. не ломами ;)


26 Apr 2017 06:48
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
jdigreze wrote:
В x86 тоже всё жёстко к адресам привязано, только что сама модель сегментации позволяет сдвигать 64К область в любую часть физической памяти с определённой кратностью (16 байт вроде как? или я уже склеротик? ;))

Извини, но ты, видимо, уже склеротик... ;))
В x86 жёстко к адресам привязаны переходы по абсолютному адресу.
Но в x86 есть и относительная адресация, как, впрочем, и в z80 она есть.
А в 580ВМ80 относительной адресации нет в принципе, как факт.

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

_________________
iLavr


26 Apr 2017 08:32
Profile
Doomed

Joined: 12 Feb 2016 13:39
Posts: 463
Reply with quote
jdigreze wrote:
Если нельзя дескриптор одной файловой системы (ФС) сохранить достоверно в дескриптор другой ФС, то, IMHO, можно применить обёртку, которая будет обрамлять файл его начальным дескриптором.

Вот именно это я и хочу получить! RKS уже и так файл данных в обёртке, 4 байта в начале и 2 байт в конце файла. На текущий момент RKX это один в один RKS, просто по расширению я определяю, что это файл для МХ. Вот здесь я как раз и предложил этот формат, процитирую себя:
PVV wrote:
Давайте, может, новое расширение придумаем, rkm, rkx, rk2, который будет тем же rks, но для MX/MX2 на SD карте. Или же еще расширим его, первые 4 байта как в rks, а следующие 11(8+3) байт, место для имени монитора если нужен свой монитор. Будет полный аналог связки CPU/I80. Стандарта на формат на SD для МХа ведь нет еще, все в наших руках.

может таки расширить формат RKX, и добавить в его описание расширение и монитор(ы)? что бы получилось:
1) 2 байта стартовый адрес;
2) 2 байта длина данных;
3) опционально(?), обязателен, если есть дальше монитор, 3 байта расширение;
4) обязателен при наличии пункта 3) 1 байт 0х00 или 0xFF автозапуск этого файла с его адреса загрузки 0 - нет, FF - да;
5) опционально, может быть опущен, 8 байт имя монитора;
6) обязателен при наличии пункта 4) 1 байт 0х00 или 0xFF автозапуск этого монитора с его адреса загрузки 0 - нет, FF - да;
7) опционально, может быть опущен, или еще один монитор 8 байт имя монитора;
8 ) обязателен при наличии пункта 7) и имеет приоритет над 5) 1 байт 0х00 или 0xFF автозапуск этого монитора с его адреса загрузки 0 - нет, FF - да;
9) 0хЕ6 - это 'маркер завершения' дескриптора RKX;
10) данные файла;
11) 2 байта CRC, опционально, может отсутствовать(как по мне, она не нужна вовсе).


С таким дескриптором работать достаточно просто, легко алгоритмизируется вычитка, первые 4 байта как у RKS, а дальше читаем 1 байт, проверка на 0хЕ6, да\нет... кусочками все вычитываем, согласно ожидаемому количеству данных из пункта. Имя монитора в формате как у CPU файла, где в имени монитора указан его адрес загрузки. Мониторов может быть два(хотя можно и больше, но пока остановимся на двух). Таким образом дескриптор может быть всего 4+1=5 байт, те 1), 2) и 9)
почти как в RKS ну, а в полном формате может быть 4+3+1+8+1+8+1+1=27 байт. Этой информации будет достаточно для работы. Время файла можно брать из fat16 описателя на карте, если оно нужно.


Last edited by PVV on 28 Apr 2017 01:24, edited 1 time in total.



26 Apr 2017 10:32
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 29 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.