А что, есть проблемы чтения трека с включенным ПДП?Сообщение от cy6
- - - Добавлено - - -
И еще по поводу достоверности чтения, опять боюсь ошибиться, но насколько я помню, синхробайт это байт со сбитой структурой и его численное значение лишь условность. Ну и после записи сектора (не целиком трека) образуются области с условными данными.
По-моему, программа форматирования, которую надо запускать из "Монитора", выводила прогресс. Что-то такое помню, когда загружал форматтеры с ленты.
Т.к по темам РК86 никто ничего не пишет и почитать нечего, то начал читать эту тему сначала.
И уже на первом десятке страниц обнаружил, что поисковики археологи раскопали версию RK-DOS 1.0 (2 кб) и схему оригинального КНГМД для МИКРОШИ. Что подтверждает моё предположение, что сначала RK-DOS была разработана для МИКРОШИ.
Интересно было бы узнать, как соотносятся завод по выпуску МИКРОШ из Лианозово, разработчик RK-DOS для РК86 Е.Седов и промышленно выпускаемые наборы КНГМД для МИКРОШИ и РК86. Насколько я понял, только первая версия КНГМД для МИКРОШИ и, соответственно, ДОС для него (RK-DOS 1.0) была другой, но коммерческая версия КНГМД для МИКРОШИ, промышленно выпускаемая этим же заводом и одновременно в виде набора (плата, документация, дискеты) продаваемая через ТОО "Лианозово", была той же самой, что КНГМД для РК86 опубликованный в ж.РАДИО.
Интересно какое отношение Е.Седов и, соответственно, его ДОС имеют отношение к заводу. Можно было бы предположить что он программист в КБ завода в Лианозово, но в статье в ж.РАДИО указано, что он из Москвы. Тогда вопрос - как его разработки попали на завод в Лианозово. Кто у кого заимствовал?
Узнал, что формат дискет RK-DOS совместим с каким то из ранних КНГМД АГАТА. Это означает, что системная межсекторная информация заимствована именно оттуда, т.к АГАТ появился ещё в 1984. Узнал, что первая версия RK-DOS была рассчитана на дисковод 5088, которым также комплектовался АГАТ в первые годы выпуска. А если к этому добавить, что структура диска и идеология ОС в основном совпадает с Apple-DOS V3.3 (автор Стив Возняк, 1978), отличаясь только мелочами (причём, изменения не в лучшую сторону), то становится ясным, что в качестве прототипа использовался АГАТ.
В КНГМД для RK-DOS версии 1.0 для МИКРОШИ объём кода составлял всего 2 кб. Теперь стало ясно почему на РК-КНГМД всего одна панелька, отчего вторую РФ2 приходится напаивать вторым этажом. Интересно, что использовалось дополнительное ОЗУ в 2 кб на статике в области E800...EFFF, да и сама RK-DOS стояла в адресах F000...F7FF. Очевидно в ПЗУ прошивался только BDOS в 2 кб, а CCP грузился в ОЗУ на статике. И впоследствии для версии RK-DOS 2.xx сочли более выгодным заменить статичекое ОЗУ в 2 кб на второе ПЗУ РФ2.
Если появится новодел РК86 имеющий доп.ОЗУ в области A000...BFFF, то RK-DOS версии 1.0 непроблемно перетранслировать для использования этого ОЗУ (вместо E800), т.к без разницы где установлено 2 кб доп.ОЗУ. В 8 кб ОЗУ как раз влезет весь код RK-DOS V1.0. Естественно в RK-DOS 1.0 совсем другой программный интерфейс (много входов в подпрограммы, а не один вход в BDOS) и совместимости быть не может. Таким образом тут интерес только исторический.
Это меня заинтересовало потому, что у меня есть схема совсем другого РК-КНГМД для РК86 из 1989 года, который судя по всему не имеет никакой связи с разработками из Лианозово. Эту схему и кассету с CP/M и основными программами (FORMAT, ASM, LOAD, DDT...) когда то привезли из Саратова (вместе с макро-ассемблером РК, Паскалем и BEST-C). По слухам КНГМД был заимствован от "Электроники-60". Он тоже имеет ВВ55, но не просто в качестве буфера, как в РК-КНГМД Е.Седова, а использует её в режиме параллельного интерфейса. К сожалению, программы не сохранились. А это была реально первая в стране адаптация CP/M на РК86. Кто нибудь имеет информацию о этой разработке?
Кстати, ещё для РК86 была CP/M с КНГМД на базе ВГ93 (формат 800 кб с ПДП). Это продавал один КООП в 1989. Ко мне попал только ДОК на бумаге: схема, чертёж печ.платы, схема расположения, листинг CP/M-BIOS и больше ничего. Для знатока этого достаточно, но для некомпетэ без дискеты или дампов CP/M-программ - это абсолютно бесполезное ИНФО.
Где про такое написано? Если судить по исходникам, то в РК-КНГМД есть какой-то режим формирования синхробайтов. И для синхронизации схемы после длительной паузы, выдаётся цепочка из 5-ти синхробайтов 006, затем цепочка из 5-ти обычных нулевых байтов и схема как-то по ним настраивается.
А в той схеме КНГМД о которой я упомянул выше, принцип другой (более простой сепаратор данных). Там в качестве синхробайта используется обычный байт F3, найденный первым после индексной дырки. Считанные биты вдвигаются в регистр. И как только там оказывается байт F3, то считается, что синхронизация достигнута и далее каждые 8 последующих битов считываются как байты. Т.е принцип, как в магнитофонном формате РК86. Надёжность при такой синхронизации ниже, но схема проще. А в РК-КНГМД какая-то более сложная аппаратная синхронизация.
Вот эта версия для запуска из монитора не выводит никакого "прогресса", даже номера текущего трека не выводит. Т.к железа нет, то пришлось её дизассемблировать, снабдить комментариями и изучить (во вложении). Оказалось, что это тот же форматёр Е.Седова, но с удалённым анализом командной строки (т.е не анализируется дисковод для формата, и ключи для задания числа секторов в каталоге и для отмены теста).
Мне тоже для дистрибутива RK-DOS для ОРИОНА пришлось сделать форматер для запуска из монитора, т.к COM-версия для запуска из RK-DOS анализирует командную строку и если её не находит, то делает выход в ДОС. Но я поступил проще - вставил в начало форматёра код для загрузки в ОЗУ нужной командной строки.
Необходимость в такой версии возникает, когда нет ни одной дискеты в формате RK-DOS. Но если RK-DOS не в ПЗУ, а в ОЗУ, то в форматёр надо перенести все нужные подпрограммы RK-DOS, чтобы форматёр действительно мог работать в среде монитора, не завися от наличия или отутствия в адресном пространстве кода ДОС.
Последний раз редактировалось barsik; 11.07.2017 в 02:54.
В журнале Радио. Там было более менее подробное описание.
Лианозово это Москва. И еще интересно, кто автор игры Удав, Седов Е.А. или Попов С.Н.?
Время дисководов и дискет проходит. Уже не каждый может себе позволить иметь дисковод. Винчестер вполне заменяет дисковод, хотя для этого ДОС для дисковода не годится, требуется несложное изменение в её коде. В качестве носителя READ ONLY удобнее всего эмуляция дискового привода на базе 'microSD'. А в качестве износоустойчивого привода ДОС удобно использовать электронный диск на базе ОЗУ.
Если нет НГМД или винчестера и требуется использовать ДОС, то можно иметь эл.диск из большого ОЗУ самого компьютера (например при установке в РК86 SIMM 1 мб). Однако, если требуется альтернатива НГМД не на одной ЭВМ, а сразу на многих, в частности, РК86, СПЕЦИАЛИСТ, ОРИОН и ИРИША, то оказывается невыгодным в каждой из этих ЭВМ иметь много ОЗУ - столько SIMM не напасёшься, трудов по монтажу много. К тому же схемы расширения ОЗУ разные и возникает неоходимость делать кучу версий ДОС. Возникает и другой вопрос, как программы попадут в компьютер. Т.к грузить в эл.диск из IBM PC по проводной линии долго и утомительно, то возникает необходимость расширять в каждом из этих компьютеров резидентное ПЗУ. А это ещё более увеличивает трудоёмкость и возникает неизбежный долгострой. Таким образом в каждом из компьютеров надо иметь скоростной интерфейс по проводной линии, привод READ ONLY для архива на базе ПЗУ и оперативный привод на базе ОЗУ.
В этом случае разумно сделать одно универсальное внешнее устройство, которое решит все проблемы. Естественно, напрашивается идея простого контроллера на Z80, т.к он выполняет регенерацию динамического ОЗУ. Кроме того в такой контроллер легко загружается новая программа изменяющая свойства контроллера, что недоступно МК с жёсткой прошивкой. Схемотехника м.быть следующая. Z80B на такте 7-8 МГЦ, ППА для интерфейса, 256 кб ОЗУ на статике и 1 мб ОЗУ на SIMM. Контроллер может точно имитировать ATA-интерфейс IDE-винчестера, эмулируя два привода (один из которых энергонезависимый на статике), а также выполнять скоростные пересылки по проводной линии. Благодаря такту в 8 МГЦ программная передача оказывается быстрее, чем аппаратная при использовании ВВ51, к тому же без расхода деталей. При последовательном интерфейсе скорость передачи до 8 кб в секунду (при паралельном ещё в 8 раз быстрее). Заметим, что сам сам РК86 без ВВ51 может передавать не более 1 кб в секунду.
Вот и дилемма. Ставить ли в РК86 SIMM 1 мб или сделать простейший внешний контроллер на Z80, втыкаемый в разъём ППА D14, на котором стоит та же SIMM 1 мб.
В минимуме схема контроллера состоит лишь из Z80, РФ2, 4-6 корпусов обрамления и SIMM 1 мб (без буферов). По сути это внешний эл.диск. Но контроллер на Z80 оказывается намного проще, чем плата внешнего электронного диска со своим узлом регенерации (30 корпусов). Преимущество в том, что не требуется вторжение на основную плату ЭВМ и шины никак не грузятся. И контроллер получается многофункциональным, т.к программа в него загружается. Например, одновременно эта крошечная платка мультиконтроллера может эмулировать или обслуживать флоп, винт, клавиатуру, AY-8912 и 512ВИ1. Т.о при развитии эта идея вырождается в двухпроцессорный компьютер, где второй процессор занимается только периферией. Но мне важно, что это даёт расширение железа без вторжений в основной плате компьютера и универсальность.
Последний раз редактировалось barsik; 14.06.2017 в 22:14.
Изобрел очередной велосипед - команда LS выводит список файлов в четыре колонки.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Можно модернизировать исполняемый код команды DIR в коде ПЗУ 4К так, чтобы при вводе команды DIR<ВК> на диске 'A' искался бы файл DIR.COM и, только если его нет, то исполнялся бы резидентный в ПЗУ DIR, выдающий список файлов в одну колонку. Иначе стартует внешний DIR в виде файла. Но лучше выводить список файлов в 3 колонки, тогда не требуется откидывать размеры в секторах (и даже удобнее выводить размеры файлов в байтах). В моих версиях RK-DOS для ОРИОНА каталог выводится сразу в 3 колонки.
Интересно, Ваша команда LS игнорирует файлы с атрибутом "системный" и поддерживает вывод списка файлов по шаблону, как это делает резидентный DIR ?
Думаю, что Ваш код LS.COM небольшой, отчего им можно заменить встроенный DIR. А можно встроить и как новую резидентную команду. Причём лучше ввести это, не как новую команду LS, а чтобы такой каталог выводился по <ВК> на пустой строке. Это удобнее, как подтвердят пользователи ОРИОНА. Проблема в том, чтобы найти место в ПЗУ.
Заменив подпрограмму PRNOUT на RET, выигрывается 27 байт. Всё-равно мало у кого сохранились посимвольные принтеры, а если и есть, то всё-равно печатать удобнее из IBM PC, а не из РК86, где только КОИ-7. 11 байтов выигрываете забив в конце кода строку копи-райт автора. Ещё до 70 байт можно выиграть посокращав текстовые строки сообщений об ошибках и другие текстовые строки. Например, вместо осмысленных сообщений об ошибках выводите строки вида 'ERR N', где N код ошибки, что даёт экономию в 54 байта. Заменив имя стартового файла 'AUTOEXEC' на 'A' выигрываете ещё 7 байт. На работу ДОС это не повлияет.
В выигранные таким образом ~100 байт можно уместить много чего полезного. Я, в частности, подумываю о введении в RK-DOS юзеров. Речь о юзерах в смысле CP/M. Юзером называют не самого пользователя, а область пользователя. В CP/M имеется 16 юзеров. Юзеры это примитивный вариант подкаталогов и хоть как-то помогают разделять файлы на больших дисках. И все накладные расходы на их введение в CP/M составили - 1 байт в каталоговой записи и проверка на текущий юзер в процедурах поиска и открытия.
Ввести в RK-DOS юзеры совместимым образом несложно. Увы, Е.Седов не позаботился зарезервировать свободный байт в каталоговой записи. Потому для введения юзеров есть две возможности. Во первых, можно использовать неиспользованные биты байта атрибутов. Во-вторых, можно сократить длину имени с 10 символов до 9-ти (всё равно все привыкли к имени в 8 символов, как в CP/M и MSDOS). Т.к для простоты вывода строк, после имени длиной в 10 или менее байт в каталоговой записи ставится 0, то фактически на имя тратится 11 байтов. И если этот 11-тый байт использовать как номер юзера, то совместимость не нарушится. Тогда у файлов с длиной имени в полные 10 байт записанных базовой RK-DOS, 11-тым байтом стоит 0, что значит, что этот файл из юзера 0.
Таким образом сохраняется совместимость в обе стороны и даже можно иметь юзеры с вложенностью, что полностью эквивалентно подкаталогам. Тогда младший ниббл байта это номер юзера, а старший ниббл это номер юзера, куда данный юзер вложен. Имена юзеров тоже можно ввести. Я так уже делал в Нортоне для CP/M, храня список имён юзеров в BOOT-секторе диска (внешне всё выглядит как работата с подкаталогами). Впрочем, и ранее в CP/M имена для юзеров уже сделали в ZCPR.
Хотя думаю, что ~100 байт достаточно, чтобы ввести юзеры в RK-DOS, но использовать такие юзеры будет неудобно. Потому что, при юзерах поиск файлов происходит только в текущем юзере, что для RK-DOS в которой большинство ДОС-команд внешние (в виде SYS-файлов) потребует иметь копии SYS-файлов в каждом из юзеров. Что неэкономично. Потому вводить юзеры в RK-DOS разумно только для версии RK-DOS рассчитанной на ПЗУ с размером более 4 кб (например 8 кб) или же для RK-DOS работающей из верхнего ОЗУ в 8К (в области A000...BFFF).
Есть возможность ввести в RK-DOS и даты файлов. Опять-таки совместимо с старыми программами. Для этого на юзер тратим байт атрибутов, а для хранения даты файлов сокращаем длину имени файла с 10-ти символов до 8-ми. И в освобождённых 2-х байтах (с офсетом 10 и 11 от начала каталоговой записи) храним упакованную (как в MSDOS) дату файла. Правда это имеет смысл только, если в РК86 установлен 512ВИ1, как описано в книге "Радиоежегодник 1989", Москва, изд-во Досааф, 1989.
К сожалению строители новоделов РК86 упорно не желают, ни расширять ПЗУ, ни даже расширять ОЗУ в области A000 (что вообще просто, если ОЗУ на РУ5). Так что RK-DOS с юзерами пока нет. Всё что можно сделать при ПЗУ в 4 кб - это за счёт фатального усечения сообщений об ошибках ввести команду DEL, чтобы избавиться хотя бы от одного файла - внешней команды ERASE.SYS.
Для тех, кто не ждёт милостей от строителей новоделов РК86, и имея РУ5 самостоятельно с помощью проволоки МГТФ "открыл" дополнительное ОЗУ A000...BFFF (перенеся D14 на адрес F200), а также имеет внешний ROM-диск (совместимый с ROM-диском ОРИОНА) могу предложить использовать более удобный вариант RK-DOS. Вариант 100% совместимый со всем старым ПО, работающий с КНГМД не имеющими сигнала READY, но требующий наличия расширений "железа" и основанный на использовании ОЗУ вместо ПЗУ, хотя добавочное ПЗУ всё-равно иметь необходимо (но уже в виде внешнего модуля, а не в самом РК86).
Для этого в ПЗУ E000...E7FF прошивается не код RK-DOS, а только вход в BDOS (E001) и стартёр RK-DOS. Тогда по вызовам BDOS из программ (по CALL E001) происходит переход на A000, где загружен собственно весь основной код RK-DOS. А по холодному старту RK-DOS, т.е по JMP E000 выполняется следующее. В ROM-диске осуществляется поиск ORDOS-файла с именем RKDOS@, и если этот файл найден то весь код этого файла грузится на адрес A000, что позволяет иметь объём RK-DOS объёмом до 8 кб.
Для некоторых удобно, что при этом ROM-диск остаётся универсальным, одновременно пригодным для хранения файлов ORDOS для ОРИОНА. Для отличия в ROM-диске программ RK86 от программ ОРИОНА, я использую, как и для дисковых ORD-файлов, символ '@' вместо '$', что используется в файлах ОРИОНА. Планирую вскоре сделать версию ПЗУ F800 для РК86 рассчитанную на ROM-диск ОРИОНА. По сбросу РК86 на ROM-диске будет искаться и автоматически запускаться определённый файл. Такая программа разработана ещё в начале 90-тых (для СПЕЦИАЛИСТА) и называет ROM SERVICE. Она выводит список файлов в ROM-диске и позволяет удобным способом выбрать и запустить файл, прошитый в ROM-диск.
PS. Утомительно каждый раз набирать команду GE000<ВК>. Лучше использвать ПЗУ F800, где встроена доп.команда 'B', по которой и выполняется JMP E000. В середине 90-тых я использовал ПЗУ РК86, где, если при нажатии кнопки СБРОС удерживать клавишу CONTROL, то происходит загрузка CP/M с дискеты. Для RK-DOS это сделать ещё проще, т.к она резидентна и не требуется иметь в ПЗУ F800 дискетный загрузчик с системных треков дискеты, а достаточно сделать JMP E000.
Последний раз редактировалось barsik; 18.06.2017 в 17:23.
Ну это кому как удобнее. Для меня важнее было по LS выводить максимально плотный список файлов, а размеры как раз неинтересны. А если интересны, есть же DIR.
Нет, LS крайне примитивна, и пока даже не обращает на имя диска в виде параметра (LS B. Если интерес к ней не остынет, попробую это все добавить, а пока утешает, что размер её менее 256 байт.
По поводу ROM-диска как-то все это пока очень мимо. Мне не нужен ROM-диск (при наличии нормальной дисковой системы-то зачем?), лучше позаниматься вопросом переноса данных с РК на "большие" компьютеры.
Вопрос этот решен Алексеем Морозовым. Что то лучше и проще, придумать сложно, имхо. Да и компоненты все современные, без устаревших и раритетных SIMM, IDE (жесткий диск - расходный материал, маловероятно найти на помойке что-то долговечное).
Я бы сказала, что нужен софт типа коммандера, который бы позволял работать с FDD и SD-картой одновременно. А в идеале, еще и эмулятор контроллера FDD на современном железе, или хотя бы эмулятор самого FDD.
И любой "базовый" РК или Апогей, должен моментально расширяться с помощью подключения такого устройства.
wtf
В чем-то да, решение на SD подходит. Но мне бы хотелось "добить" вопрос с локальной сетью "Микроши" в соседнем топике, это у меня традиционное пристрастие к использованию встроенных в ретрокомпьютеры технических средств. (К тому же к "Микроше" SD-контроллер без внешнего питания не подключить, но это мелочи)
По поводу эмулятора контроллера FDD - лучше бы просто контроллер, цепляющийся к PC через USB одним концом и к внешнему флопику 3.5" другим концом. И простой софт, читающий треки с реального флопа.
Последний раз редактировалось tnt23; 18.06.2017 в 19:12.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
