Вопрос: а зачем качать быстро? 9600 хватит всегда и всем. По крайней мере производители промышленного оборудования так и считают, кмк. Везде 9600 - стандарт. У меня вон вообще терминал работал на 300 бит/сек, и нормально было (хотя, если бы не совместимость с магнитной лентой, я б тоже поставил 9600).
Вообще-то ответ ясен. Затем же, зачем Вы пользуетесь модемом 100 мбит/сек, а не 2400 байт в секунду? Чтобы было быстрее.Сообщение от rw6hrm
Не знаю для чего другим нужен последовательный интерфейс, а для меня это связь между PC и 8-ми разрядками. При скорости ~150 байт в секунду я передавал 16-ти кило-байтовую программу 2 минуты. Это не фатально, если делается редко. Но когда нужен интенсивный обмен это раздражает. При скорости обмена 1 кб в секунду уже как-то лучше. Но тоже не особо быстро, если надо загрузить много файлов. Впрочем, даже такой скорости достаточно для загрузки энергонезависимого эл.диска 256 кб (если это автоматизировано, т.е если все программы передаются сами по списку из BAT-файла), - 5 минут загрузки можно подождать.
Ну, а если IBM PC должна работать в качестве контроллера собственного винчестера, т.е имитировать привод DOS, то и скорость обмена должна быть не ниже скорости обмена с реальной дискетой. Т.е примерно 15 кб в секунду, что в килобитах 120 кбит в секунду. Т.е только при скорости ~100 кбит в секунду это будет работать со скоростью реального дисковода.
Промышленность ориентировалась на 9600, т.к последовательный интерфейс служил только для подключения принтера и мыши, где такой скорости хватает.
Последний раз редактировалось barsik; 15.04.2017 в 15:59.
barsik,
Нет, ПДП в РК-ДОС не мешает, его там специально из-за этого перестраивают. Если принять за емкость дорожки 2,8Кб, то на запись байта у процессора будет 16000000/9/5/2800 = 126 тактов. ВГ75 там настроена на 2 байта (8 тактов процессора) каждые 8 символов (10-11 тактов процессора). То есть в худшем случае у процессора равномерно заберут половину тактов, оставшихся вполне хватит. Но, конечно, без перестройки режима ПДП будут проблемы...
А вот для 38400/8N1 у процессора будет уже 462 такта.
Считал иначе. И на практике наблюдал, что если для ускорения отменить VERIFY после записи сектора (тогда думал, что на хорошем НГМД это лишнее), то не работает.
Таинственная фраза.
Предполагаю, что 2 байта это число байт в пакете ПДП. А почему 2 байта пересылаемые ПДП отнимают у CPU 8 машинных тактов? Я в этом не разбирался (зачем?), но как дилетанту мне казалось, что ПДП тратит 2 такта на пересылку одного байта. На первом такте читает из ОЗУ, а на втором пишет в порт. Если Вы знаете точно, что ПДП тратит на пересылку байта 4 такта, то приму к сведению.
Этого не понял, потому что Ваш рассчёт не разъяснён, не "разжёван".
Командой "разрешение отображения" число тактов между посылками ПДП делают равным 7 периодам знакоместа. Сколько это машинных тактов? Период знакоместа - это период частоты 16 МГЦ:12= 1.333 МГц. Т.е 750 НСЕК. 7 периодов это - 5.25 МСЕК. Машинный такт длится 1:1.777= 0.563 МКСЕК. Итого в паузу между ПДП уложится: 5.25:0.563=9.3 машинных такта. Понятно, что начатый такт, цикл, а может быть и вообще всю процесорную команду КР580 закончит (этого я не знаю, но цикл доступа к ОЗУ он явно закончит). Это получается, что в паузах КР580 успевает сделать примерно 2 команды процессора (средняя длина команды считается 8 тактов), а затем стопорится на 8 тактов. Итого, грубо, - 10 тактов КР580 работает 8 тактов стоит.
Откуда фраза "каждые 8 символов"? А насчёт упомянутых 10-11 тактов возможно речь о 9-10, что я посчитал выше.
Тоже не разжёвано, ничего не понял. Считаю сам.
Считать надо не так, а по работе контроллера. Надо смотреть как происходит запись в формате FM. А именно каждый бит пишется 4 МКСЕК. Итого байт пишется за 32 МКСЕК. А это не 126 машинных тактов, а 32:0.563= 56 машинных тактов. Делим на 18 и умножаем на 10. Итого, остаётся 31 машинный такт, чтобы дождаться готовности, считать/записать байт из порта, сдвинуть HL, уменьшить счётчик цикла и проверить его на 0. 31 такт это ~4 команды КР580. Этого явно не хватает даже на анализ флага в цикле, даже если делать его так извращённо, как делал Е.Седов (INC (HL) адресуясь в ППА). Так вот, по этим прикидкам получается, что ресурса нет. Похоже, что ПДП мешает! -- КР580 нормально считывает и записывает сектор, только когда его не рвёт ПДП. А это, как показал анализатор ~2/3 времени кадра. Может быть смена режима командой "разрешение отображения" что-то улучшает в работе, но ПДП явно вредит.
Для последовательного интерфейса на скорости 38400 быстродействия РК86 действительно хватит, хотя у меня получилось не 462 такта, а только 416:18*10=231 машинный такт. Но и этого явно хватит. Может быть даже хватит и на скорость 56К.
Последний раз редактировалось barsik; 15.04.2017 в 20:31.
ВТ57 так работает, в даташит есть.
Да, точно, не 8, а 7, соответственно от 10 тактов процессора.Откуда фраза "каждые 8 символов"? А насчёт упомянутых 10-11 тактов возможно речь о 9-10, что я посчитал выше.
Это 31250 байт в секунду. 300 оборотов/минуту = 5 оборотов/секунду -> 6250 байт неформатируемой емкости на дорожку. Перебор в два раза для РКДОС. 3125 больше похоже на правду. У меня в эмуляторе как раз столько. SPEED.COM показывает 200 мсек - похоже на правду.Итого байт пишется за 32 МКСЕК
16000000(кварц)/9(делитель процессора)/5(оборотов диска в секунду)/3125(емкость трека в байтах) = 113,(7) тактов.
- - - Добавлено - - -
Вот операция чтения:
Если не ошибаюсь, то 66 тактов - вполне хватает с ПДПКод:EE8C: 34 4 INR M EE8D: F2 8C EE ... JP EE8C EE90: DB F4 .. IN F4 EE92: 02 ▝ STAX B EE93: 03 ▀ INX B EE94: 1B . DCX D EE95: 7A З MOV A,D EE96: B3 . ORA E EE97: C2 8C EE ... JNZ EE8C
Так написано в МПСС 03.1986. Ошибается журнал МПСС или формат РК-КНГМД использует не FM, а какой-то иной формат? Или применяется побайтовая синхронизация на которой теряется неучтённое время. Нет смысла тратить время и разбираться в этом. Теоретически ничего нельзя выяснить не имея проверенных фактов, выяснить можно только экспериментами в реале. Работает и слава Богу. Я лично пользовался РК-КНГМД более 20 лет и вполне был доволен его работой.
Мне больше интересно сам-ли Е.Седов написал процедуры чтения/записи сектора и выбрал формат или заимствовал и где? Межсекторная информация выбрана очень грамотно, потому логично думать, что был прототип. Схему подобного КНГМД я видел за 5 лет до публикации в ж.РАДИО. Это схема РК-КНГМД от саратовской CP/M 1989 года и она сохранилась (хотя сама CP/M утеряна). Отличия есть, но не существенные, в основном в сепараторе данных и значении отлавливаемого синхробайта (там F3). Известно, что схема заимствована от КНГМД "Электроники-60" или ДВК. Нет смысла упоминать, что концепция RKDOS с T/S-List заимствована от ДОС Агата, которая есть копия APPLE-DOS 3.3 1978 года. Если концепция ДОС заимствована, то и остальные идеи возможно тоже.
Что за эмулятор, где работает RKDOS и где его можно скачать?
- - - Добавлено - - -
Допустим, как Вы посчитали, 113 машинных тактов. Чтобы учесть влияние ПДП разделим на 24 и умножим на 12, остаётся 56 тактов. Вот процедура записи в расчёте на Z80 (извиняюсь, ни исходников, ни таблиц для КР580 не имею). В ней 85 тактов. Т.е времени уже не хватает. А ведь ещё надо учесть, что цикл готовности может наступить не сразу, а прокрутится пару циклов без готовности. И таким образом процессор никак не успевает обслужить КНГМД, когда этому мешает ПДП. Потому запись сектора и требуется обязательно проверять.
Код:AEF43: INC (HL) ; 11 JP P,AEF43 ; 17/10 LD A,(BC) ; 7 LD (PORT),A ; 13 INC BC ; 6 DEC DE ; 6 LD A,D ; 4 OR E ; 4 JP NZ,AEF43 ; 17 Итого: 85 машинных тактов.
Последний раз редактировалось barsik; 16.04.2017 в 13:07.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Это если MFM, т.е. когда ВГ93 используется.
А вот это больше на FM похоже.
barsik, на РК не Z80, смысла смотреть на его растактовку нет, она другая. И не 10 тактов, а от 10, причём всегда будет больше. Через 10 тактов даже ВГ75 не гарантирует того, что выставит запрос на ВТ57. А потом ВТ57 должна заметить этот запрос и выдать на ВМ80, а тот его только на втором такте цикла проанализирует и тоже сразу не подтвердит. И я уже говорил, что на РК не Z80? ПДП тут начинает работать параллельно с последними тактами цикла. Правда нам это не поможет, просто в связи с вышеизложенным я затрудняюсь назвать точные тайминги. Видно только, что скорости хватает. И есть ещё резерв по программной оптимизации, но видать не потребовалась.
И вообще откуда возникла мысль, что РК-ДОС работает так криво? Если бы была проблема с ПДП, то проще было его отключить на время чтения/записи. Тем более за время чтения одного трека ПДП 10 раз целиком прогоняет весь экран, чтение либо работало, либо нет. Вот если режим ВГ75 не поменять, то сразу видно, что ничего не работает.
По поводу 4мксек. Насколько я помню, на запись одного логического бита расходуются два физических. Думаю время к физической записи относится. Тогда все сходится.
Мой эмулятор не подойдет, он только под macOS. Но новый emu80 тоже умеет РК-ДОС.
- - - Добавлено - - -
Плюс вот ещё какой резерв есть. Мы не должны выдерживать точно 113 тактов. Это лишь время, сколько считаный контролером байт доступен для чтения процессором. Если даже мы будем терять по 10 тактов на байт, то проблему мы почуствуем, когда пропустим 12-ый байт. Но ПДП на строчку делает 39 запросов. При 5-6 запросах на байт он уже гораздо раньше угомонится и даст процессору наверстать потерянное.
uart, Вы победили. Убедили, что работе RK-DOS на КР580 ПДП не особо мешает. Но это на пределе. Запаса нет, отчего при записи при определённых обстоятельствах возникают сбои. Но проблем нет, потому что есть проверка правильности записи.
Кстати, в теме "Секреты и трюки программирования РК" определили, что при входе и выходе из ПДП теряются ещё 4 такта, т.е получается, что на пересылку 2-х байтов тратится не 8 тактов, а 12 тактов и делить надо не на 18, а на 24 (10+2 + 12). Т.е сокращение числа рабочих тактов равно 12/24, т.е потери даже больше, чем при расчёте 10/18, как считалось в предыдущих постах. Но опять таки, эти расчёты основаны на умозрительных заключениях и потому бесполезны.
А вот это любопытно. Мне казалось, что Е.Седов использовал все резервы ускорения, о которых до него никто даже не подозревал. Не поделитесь сведениями, как ускорить работу процедур чтения/записи сектора.
Большая часть последнего Вашего поста непонятна, но это не важно.
Последний раз редактировалось barsik; 16.04.2017 в 13:05.
Ну например DCX D/MOV A,D/ORA E заменить на DCR E, что даст цикл до 256 байт. Повторив процедуру чтения еще раз в коде - получим до 512 байт. Экономия 9 тактов.
Не знаю что там выяснилось, но ВГ75 заполняет буфер 78 символов (в нашем случае), поскольку запрашивает по 2 байта, то ему надо 39 запросов. Если не брать накладные расходы, то это 39x8=312 тактов процессора из 78x10x4/3=1040 требуемых для её отображения.Но в недавнем обсуждении в теме "Секреты и трюки программирования РК" выясгилось, что ВГ75 не запоминает в буфере экранной строки
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
