barsik,
Нет, ПДП в РК-ДОС не мешает, его там специально из-за этого перестраивают. Если принять за емкость дорожки 2,8Кб, то на запись байта у процессора будет 16000000/9/5/2800 = 126 тактов. ВГ75 там настроена на 2 байта (8 тактов процессора) каждые 8 символов (10-11 тактов процессора). То есть в худшем случае у процессора равномерно заберут половину тактов, оставшихся вполне хватит. Но, конечно, без перестройки режима ПДП будут проблемы...
А вот для 38400/8N1 у процессора будет уже 462 такта.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Считал иначе. И на практике наблюдал, что если для ускорения отменить VERIFY после записи сектора (тогда думал, что на хорошем НГМД это лишнее), то не работает.Сообщение от uart
Таинственная фраза.
Предполагаю, что 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.
Скриншот из даташита, мы ж в любом случае используем асинхронный режим. В синхронном - 64К, но это не наш вариант.
Спасибо за разъяснение. К сожалению, CP/M работает секторами по 128 байт, из-за чего читает не сразу на место загрузки (DMA), как это делает RK-DOS, а сначала читает в дисковый буфер, равный, в минимуме, размеру физ.сектора, а в оптимуме, равный размеру CP/M-блока в 2 кб. А затем выполняет море пересылок лог.секторов по 128 байт, что дико тормозит.
Поэтому первая версия CP/M что я странслировал на базе подпрограмм Е.Седова (в 1994) работала примерно в 50 раз медленнее, чем RK-DOS. Т.е потребительная ценность была нулевой. Спустя год усовершенствований удалось довести скорость обмена в CP/M до скорости примерно в 10 раз медленнее, чем RK-DOS. Это довольно быстро, с учётом того, что в RK-DOS дискетная загрузка происходит мгновенно, что никаким версиям CP/M для 8-ми разрядок и не снилась. Скорость обмена такая же как при SD-формате (400К) с КНГМД на базе ВГ93.
Однако, чтобы выиграть скорость использовались сектора не 512 байт, как у Е.Седова, а сектора с размером CP/M-блока (отпадают лишние поиски секторов, а также расчёты позиций в буфере). Сектора размером в блок не позволяют максимально использовать полезный объём трека, хотя существенно ускоряют. Максимально выгодны сектора размером целиком во весь трек. Формат - один сектор на трек. Что не только даёт максимальную ёмкость диска (отпадают межсекторные гапы, куча служебной информации, а кратность размера сектора допустима в 128 байт, - т.е всё пространство трека используется максимально, т.е на форматную ёмкость), но и существенно ускоряет.
Недостаток такого формата в том, что если есть дохлота в треке, то дохлым помечается не только один CP/M-блок, а сразу несколько, т.е при плохих дисках быстро растут потери полезного объёма. Кстати формат один сектор на весь трек применяется в первом Apple MAC (880К на DD-диск). Второй, более существенный недостаток, - это большой размер дискового буфера, что сокращает TPA, поэтому, когда я стал использовать DOS ОРИОНА в банке 0 (где свободного ОЗУ совсем мало), то вынужден был вновь вернуться к формату с секторами по 512 байт и найти другие способы повышения скорости обмена.
Кроме того, при использовании даже самОй RK-DOS на хорошем дисководе приходится менять размер сектора, т.к во VTOC на информацию о занятых секторах трека отведён только один байт, тем самым число секторов в треке не может превышать 8 (для сравнения в DOS Агата на это отведено 4 байта, отчего макс.число секторов 32). Таким образом при 8 секторах на трек мы имеем только 8*512= 4 кб на трек, т.е лишь 640 кб на диск. Поэтому приходится размер сектора в RK-DOS увеличивать до 1 кб, что позволяет иметь диски размером до 1280К. Обычно я использовал RK-DOS в формате 800К (с секторами в 1 кб), а CP/M в формате 880 и 960 кб. Для обоих случаев предложенная оптимизация - не вариант.
Это я пояснил, почему данный трюк для CP/M не очень-то удачен. Если надо читать блок в 1 кб или в 3 кб, как это поможет? Кстати, в RK-DOS имеется возможность поднять скорость обмена, используя формат с интерливингом. Впрочем, RK-DOS и без того самая быстрая ДОС для 8-ми разрядок. Хотя для винчестера, где важна скорость, толку от этого мало, т.к концепция изначально не поддерживает большие диски.
Мне времени не всегда хватало. В ранних вариантах CP/M на базе РК-КНГМД, где я ещё не модифицировал константы (в процедурах Е.Седова для РК-КНГМД, почти всё на задержках, привязано к скорости CPU) приходилось работать на низких скоростях CPU в формате 880 кб и выше. И скоростей не хватало (при отказе от извращений Е.Седова, что пригодны только для КР580, времена петель увеличись в 1.5 раза) и хотя аппаратно увеличить скорость прогона можно, но код не позволяет. Вот тут и нужен был дополнительный ресурс ускорения процедур.
Последний раз редактировалось barsik; 16.04.2017 в 12:50.
barsik, для 3К ничего принципиально не меняется, только циклов не 2, а 12. Но вопрос в другом. У РК производительность с ПДП больше, чем требуется для последовательного порта 115200. У Специалиста тем более, ограничивает тут только микросхема контроллера.
Ещё мыслю спрошу, опять же про стандартную схему. Адресация УВВ как ячеек памяти - это удобно и привычно (особенно для любителей 6502, типа меня). Ставим дополнительно ИД3 - и получаем ещё 15 дополнительных чипселектов. НО: а почему бы, для личного пользования, не сделать поверх основной схемы ещё и "нормальное" адресное поле для УВВ? Монитор переделывать не надо, ибо новые устройства поначалу будут использоваться исключительно автором доделки, а там как получится. Никаких подводных камней не видно? ВК28/38 использовать необязательно, дюже они жрущие питалово, а вот ТМ7+ЛА3 вполне достаточно будет... Вроде бы как бы команды IN/OUT в стандартной схеме не используются и ни на что не влияют (или я плохо смотрел)...
А зачем нам "нормальное" адресное поле для УВВ? Что хотите подключать?
Нет, не дюже. Они тёпленькие, но отнюдь не такие раскалённые, как АП16. Они не горячее процессора и даже некоторых 155-той серии (например, 155ИЕ7 жрёт больше). Пальцем держать ВК28 вполне можно. Если уж так заботит экономия электроэнергии, то в первую очередь надо заменить АП16 на 1533АП6 и ИР12 на 1533ИР22 (у меня так и сделано).
ВК28 очень полезны, т.к заменяют контроллер прерываний (дают одно прерывание без затрат деталей) и главное, позволяют разогнать КР580 до 3.5 МГЦ. У меня ВК28 стоял на 3-х платах ЭКСПРЕСС. Их установка обходится в 2 вентиля из 555ЛА3. Однако, если Вы фанат бейсика, то Вам нельзя связываться с ВК28. После установки ВК28 у меня почему-то перестал работать бейсик (также как и после установки Z80, а как это связано даже не понял). ВК28 на плате ЭКСПРЕСС удобно ставить вместо крайней панельки ПЗУ.
А действительно, зачем Вам вводить IN/OUT, если в базовом СПЕЦИАЛИСТЕ есть аж 2 кб пространства для введения дополнительных портов. Обычно область F800...FFFF делят дешифратором ИД7 на 8 участков. Причём стандартизован только участок FF00...FFFF для порта клавиатуры. Ну ещё во всех расширениях, что я видел, почему-то все ставили доп.ППА для подключения УФ-ПЗУ прошивателя и параллельного принтера на FE00 (но это не догма, т.к приличные УФ-прошиватели имеют в меню пункт выбора адреса порта). Разве Вам не хватит 6-ти чип селектов на Ваши нужды?
Ну, а связываться с 155ИД3 просто неразумно. Во-первых её нет в отечественных сериях 555 и 1533. Т.е придётся или применять 155-ю серию, что глупо, т.к это сильно нагрузит шины, или же мучиться с поиском вражеского аналога в маложрущем исполнении. Но я её не люблю не поэтому. А потому, что она слишком большая по конструктиву и не напаивается вторым этажом на ИМС уже стоящие на плате.
В качестве дешифратора, я предпочитаю применять ИД14 (74LS139), т.к это сразу два дешифратора, а это всегда даёт бОльшую гибкость (а более 4-х устройств никогда было иметь не надо). Первым дешифратором делим грубо, а вторым дешифратором из одного из участков получаем нужные 4 чип-селекта. Раньше, я не знал про ИД14, но когда увидел их в схеме Apple-II, то сразу оценил.
А вы не хотите поставить в СПЕЦИАЛИСТ 6502? На такте 1/1.25 МГЦ синхронно, а на такте 1.5 МГЦ несинхронно. В Apple-II используется свойство 6502, что весь доступ к ОЗУ он делает при низком уровне Ф1, таким образом вторая половина периода Ф1 свободна для доступа к ОЗУ видео-части. Это же свойство может помочь сделать прозрачный доступ и в СПЕЦИАЛИСТЕ на такте 1 или (при замене кварца 8 на 10) 1.25 МГЦ.
Последний раз редактировалось barsik; 24.04.2017 в 10:24.
Я тоже так думал некоторое время. Однако 1533ИД3 ну просто валом
...а мало ли,...
Я их рассматривал только как дешифраторы работы с памятью/с УВВ. С прерываниями в Спеце косяк, ибо изначально не предусмотрено. "Кто будет переписывать монитор?" (Цэ)
200 - 250 мА потребления. ТМ7+ЛА3 жрут 50 мА максимум. Про АП16/ИР12 согласен полностью, но заменять не буду...
Уже есть аппарат на 6502, он мне нравится. И, кстати, прекрасно эмулирующий 8080. А Спец - это первая любовь, собранная своими руками. Вот, достался от добрых людей клон "Дон" за батл коньяку (а не за пять тыр, как некоторые продают в Барахолке), нафаршированный жирными и сочными КМками, непаяный, практически девственный, прекрасно рабочий. Вот и думаю, как совсем немного его пошурудить для более удобного использования. Вариант с допОЗУ вместо ПЗУ уже готов, доделаю SD-карту и остановлюсь. Возможно...
Последний раз редактировалось rw6hrm; 24.04.2017 в 09:54.
нам бы схемку иль чертеж
как РК ДОС контроллер подключить к Специалисту?
и саму дос адаптированную к спецу и ее утилиты
barsik, может быть у Вас все это есть?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием