Эту задачу надо сформулировать точнее. Нужно уточнить форматы данных на обоих носителях. Например это может быть CP/M на НГМД и FAT16 на 'microSD', или же RK-DOS на НГМД и файл-слепок дискеты RK-DOS в одном из подкаталогов FAT16. Может быть речь о обмене RK-DOS - отдельный файл FAT16 для каждого файла с дискеты. Но лучше всего диск в формате RK-DOS прямо в 'microSD', например замаскированный под файл FAT16 (для этого нужны подпрограммы чтения/записи байта). Неясно в какой ДОС (или без ДОС) должна работать такая программа ?Сообщение от cy6
Понятно, что оболочка типа Нортон для пофайлового обмена удобна. Но на РК86 программы в стиле коммандер некрасивы, т.к нечем начертить приличные панели, без инверсии с рамками не сделать окон и даже указатель "балка подсветки" невозможен. Для этого необходим хотя бы один альтернативный фонт, хотя бы такой, что использую я, дающий рамки с инверсией и без, и инверсию знакомест. Увы, если не коммутировать фонт атрибутом ВГ75, то за счёт потери русских букв при альтернативном фонте. Один альтернативный фонт обходится в расход одного куска проволоки. Но до сих пор не выработан стандарт каким портом и какими битами переключать фонты.
Контроллер 'microSD' от vinxru освобождает от необходимости работать напрямую с форматом FAT16 (что довольно сложно и требует много кода) предоставляя функции более высокого уровня, чем функции MSDOS. Поэтому, если работать по-файлово (не со слепком диска) думаю, что интерфейс со стороны 'microSD' получится несложный.
Я когда-то написал нортон для RK-DOS на ОРИОНЕ. Хотя "глюкало" не годится для РК86, но готовые подпрограммы (напр, чтение каталога в буфер, его сортировка по критерию, копирование, удаление, переименование файлов) уже имеются. Есть также и "глюкало" для РК86 (но не для RK-DOS, а для другой ОС), Т.е есть готовая панель с управлением "балкой подсветки", работающая с использованием альтернативного фонта. Потому я могу быстро сделать основу такого CHANGER-нортона работающего из RK-DOS или из CP/M (при ОЗУ 48К). Несколько программ для обмена между разными ДОС в виде Нортона я уже когда-то написал (в 90-тые).
Но чтобы сделать обмен с 'microSD' мне нужен готовый программный интерфейс с ним. В минимуме нужны следующие готовые подпрограммы: считать целиком каталог по указанному адресу (с размерами файлов, атрибутами, и м.быть с датами файлов), записать файл умещающийся в дисковый буфер, считать файл с размером не более, чем дисковый буфер, удалить файл, переименовать файл, установить файлу атрибут, установить файлу дату. В максимуме нужны функции нормальной ОС, т.е - создать файл, открыть файл на чтение или запись (APPEND не надо), закрыть файл, считать/записать в открытый файл один байт и логический сектор (128 байт).
Если в наличии только процедуры считать/записать файл целиком, то возникают сложности при копировании гигантских файлов размером до 28 кб. Сам Нортон может делать обмен только небольшими файлами, которые целиком умещаются в дисковый буфер. Считайте сами. В базовом РК доступно ОЗУ только 29 кб. 10 кб занимает сам нортон. 1.5 кб отнимают буфера RK-DOS. Итого, максимальный размер файла, что целиком умещается в память - это менее 18 кб.
Потому более крупные файлы, вплоть до размера в 28 кб между НГМД и 'microSD' из Нортона (и из CCP) можно копировать только отдельной программкой SDCOPY.COM. Нортон при попытке скопировать гигантский файл с размером до 28 кб должен формировать BAT-файл, который запускает копирование с помощью SDCOPY.COM.
Если кто-нибудь заинтересован, то давайте для начала сделаем так. Давайте для начала сделаем кучу маленьких простых программок, что позволит отладить процедуры обмена. Например, начать можно с внешних команд RK-DOS типа DIRSD.COM, CD.COM, RM.COM, LOADSD.COM, SAVESD.COM, RENSD.COM, ATRIBSD.COM, а затем и SDCOPY.COM. Я сделаю часть кода для RK-DOS, а кто-то должен помочь с кодом для 'microSD'. Насколько я понимаю, есть некий SD-BIOS, который и обеспечивает интерфейс с FAT16 очень простым способом.
Попробую в ближайшие дни странслировать дисковый РК-DOS нортон, который будет выводить файлы RK-DOS в левой панели. А в правой панели будет бутафория, т.е придуманный список файлов 'microSD', служащий лишь для проверки перемещения по ним указателя. Так обычно и делается при разработке подобных программ. Но в реале я проверить не смогу. Отладку "глюкала" я сделаю в своём эмуляторе, а работу с РК-КНГМД в эмуляторе от Pyk. Но пока не знаю, как включить в нём альтернативный фонт. А может быть эмулятор от Pyk эмулирует и контроллер 'microSD' от vinxru? Это существенно бы упростило разработку.
Контроллер для интерфейса не был обязателен. Например ДОС для ОРИОНА, разработанная error404 поддерживает 'microSD' с простым интерфейсом (оба варианта) и не нуждается ни в каком контроллере. Обслуживание выполняет CPU компьютера, без всяких контроллеров. Предполагаю, что контроллер использован потому, что для него уже имелать кем-то ранее написанная программа интерфейса с FAT16, и потому что у РК86 слишком мало ОЗУ и слишком низка скорость.
Раз речь об обмене с IBM PC, то тут с РК-КНГМД облом. Если у РК-КНГМД формат действительно FM, то теоретически возможно написать программу обмена, правда только для PC (РК-КНГМД не сможет записать межсекторную информацию, что нужна для 8272). Программа должна считывать всю дорожку целиком, а затем её программно анализировать. Встроенные в BIOS и MSDOS процедуры чтения сектора не помогут. Но увы, работу с 8272 на низком уровне многие современные компьютеры не поддерживают.Сообщение от tnt23
Я использую обмен с ОРИОНОМ по проволоке, но скорость обмена очень низка. Если нужно пересылать большой объём, то это надолго. В качестве альтернативы можно рассмотреть скоростной контроллер на Z80 реализующий скоростной последовательный интерфейс.
Можно применить на РК контроллер НГМД от ПАРТНЁРА на ВГ93, который записывает в формате, что можно считать на IBM PC. Тогда можно даже написать программу для РК86 записывающую прямо в формате MSDOS 720К. Однако такой контроллер нельзя применить для RK-DOS, т.к она использует сектора нестандартного размера. Потому с таким контроллером можно использовать только CP/M.




Ответить с цитированием