Специалист. Ваши мысли?

[barsik]

Ну например DCX D/MOV A,D/ORA E заменить на DCR E, что даст цикл до 256 байт. Повторив процедуру чтения еще раз в коде - получим до 512 байт. Экономия 9 тактов.

Это называется линейный участок. Так в драйвере вывода символов ОРИОНА или СПЕЦИАЛИСТА, чтобы ускорить вывод применяют не петлю DJNZ с загрузкой в рег.B числа 10 (высота знакоместа), а без петли вставляют 10 повторяющихся участков пересылки 1-го байта (из фонта в экран). Ускорение на время в 10 команд DJNZ, но расход в 40 байтов.

Эта идея поможет в CP/M, где все секторы одного размера. Но в RK-DOS нет. Т.к в RK-DOS секторы переменной длины (от 1 байта до 512). Чтобы это учесть с такими двумя последовательными циклами надо всякий раз модифицировать код. Так что этим кто-то стал бы заниматься только в самом крайнем случае, когда другого спасения, чтобы выиграть скорость, нет. Т.е надо нужное число читаемых или записываемых байт раскидывать в два регистра E - в первом цикле и во втором. И убирать второй цикл, если число менее 256.

[uart]

Т.к в RK-DOS секторы переменной длины (от 1 байта до 512). Чтобы это учесть с такими двумя последовательными циклами надо всякий раз модифицировать код

Не надо ничего модифицировать. Длина в DE, поэтому при DE от 0x101 до 0x200 все работает сходу. При меньших значениях на вторую часть кода надо переходить, тем самым выполнив цикл только один раз.

[barsik]

Повторив процедуру чтения еще раз ... получим чтение сектора до 512 байт

Не надо ничего модифицировать. Длина в DE, поэтому при DE от 0x101 до 0x200 все работает сходу. При меньших значениях на вторую часть кода надо переходить

Опять подводит Ваша лаконичность, т.е плохое разъяснение материала. Дана только идея, оставляя все детали на домыслие читателя.

Приведите пожалуйста исходный код петель чтения и записи, реализующих обсуждаемую идею и работающий в ПЗУ (что и имеет место для RK-DOS на РК86 и СПЕЦИАЛИСТЕ).

[uart]

barsik, к примеру заходим с длиной сектора 0x156 в DE. В E соответнно 0x56, первый цикл столько и отработает. В E станет 0 и второй цикл выполнится 256 раз. Итого 0x156. Так что для длин секторов от 0x101 до 0x200 все работает.
А вот если длина меньше и цикл надо выполнить один раз, то нужен первоначальный переход на второй цикл. Но знаем мы это ещё до чтения данных сектора, после чтения его заголовка, у нас ещё куча времени.
Но поскольку времени и так хватает, такая оптимизация необязательна, даже вредна, объём ПЗУ у нас ограничен.

[barsik]

для длин секторов до 200H все работает

Спасибо за разъяснение. К сожалению, 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 раза) и хотя аппаратно увеличить скорость прогона можно, но код не позволяет. Вот тут и нужен был дополнительный ресурс ускорения процедур.

[uart]

barsik, для 3К ничего принципиально не меняется, только циклов не 2, а 12. Но вопрос в другом. У РК производительность с ПДП больше, чем требуется для последовательного порта 115200. У Специалиста тем более, ограничивает тут только микросхема контроллера.

[rw6hrm]

Ещё мыслю спрошу, опять же про стандартную схему. Адресация УВВ как ячеек памяти - это удобно и привычно (особенно для любителей 6502, типа меня ). Ставим дополнительно ИД3 - и получаем ещё 15 дополнительных чипселектов. НО: а почему бы, для личного пользования, не сделать поверх основной схемы ещё и "нормальное" адресное поле для УВВ? Монитор переделывать не надо, ибо новые устройства поначалу будут использоваться исключительно автором доделки, а там как получится. Никаких подводных камней не видно? ВК28/38 использовать необязательно, дюже они жрущие питалово, а вот ТМ7+ЛА3 вполне достаточно будет... Вроде бы как бы команды IN/OUT в стандартной схеме не используются и ни на что не влияют (или я плохо смотрел)...

[fifan]

А зачем нам "нормальное" адресное поле для УВВ? Что хотите подключать?

[barsik]

ВК28/38 использовать необязательно, дюже они жрущие питание

Нет, не дюже. Они тёпленькие, но отнюдь не такие раскалённые, как АП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, типа меня

А вы не хотите поставить в СПЕЦИАЛИСТ 6502? На такте 1/1.25 МГЦ синхронно, а на такте 1.5 МГЦ несинхронно. В Apple-II используется свойство 6502, что весь доступ к ОЗУ он делает при низком уровне Ф1, таким образом вторая половина периода Ф1 свободна для доступа к ОЗУ видео-части. Это же свойство может помочь сделать прозрачный доступ и в СПЕЦИАЛИСТЕ на такте 1 или (при замене кварца 8 на 10) 1.25 МГЦ.

[rw6hrm]

связываться с 155ИД3 просто неразумно. Во-первых её нет в отечественных сериях 555 и 1533.

Я тоже так думал некоторое время. Однако 1533ИД3 ну просто валом на все скусы, http://zx-pk.ru/attachment.php?attac...2&d=1398092029

А зачем нам "нормальное" адресное поле для УВВ?

...а мало ли,...

ВК28 очень полезны, т.к заменяют контроллер прерываний

Я их рассматривал только как дешифраторы работы с памятью/с УВВ. С прерываниями в Спеце косяк, ибо изначально не предусмотрено. "Кто будет переписывать монитор?" (Цэ)

Они тёпленькие

200 - 250 мА потребления. ТМ7+ЛА3 жрут 50 мА максимум. Про АП16/ИР12 согласен полностью, но заменять не буду...

А вы не хотите поставить в СПЕЦИАЛИСТ 6502?

Уже есть аппарат на 6502, он мне нравится. И, кстати, прекрасно эмулирующий 8080. А Спец - это первая любовь, собранная своими руками. Вот, достался от добрых людей клон "Дон" за батл коньяку (а не за пять тыр, как некоторые продают в Барахолке), нафаршированный жирными и сочными КМками, непаяный, практически девственный, прекрасно рабочий. Вот и думаю, как совсем немного его пошурудить для более удобного использования. Вариант с допОЗУ вместо ПЗУ уже готов, доделаю SD-карту и остановлюсь. Возможно...