форум - О сокращении времени форматирования. О записи секторов одновременно с форматированием. Перестроение экрана за одно прерывание.

<b>форум</b> - О сокращении времени форматирования. О записи секторов одновременно с форматированием. Перестроение экрана за одно
прерывание.

(c) М.Кузьмин, Моск.обл.

   В РЕВЮ была статья  Рощина  о
сокращении времени  форматирова-
ния. Приведенный там способ  те-
оретически  неплох, с  практикой
хуже: на разных дисководах  вре-
мя форматирования одной  дорожки
разное, поэтому привязку ко вре-
мени  ну  никак  нельзя  осущес-
твить. А вообще, как можно  осу-
ществить  прерывание  во   время
форматирования,  если  программа
будет висеть в DOS'е на  блочной
записи ???
   Запись секторов  одновременно
с форматированием - только поте-
ря времени. Оно теряется на про-
верку  секторов  перед  форматом
(на обнаружение  #F5, #F6, #F7).
Да, конечно, если  таких  секто-
ров нет на треке, то выигрыш бу-
дет, но если  хоть  один  сектор
"нечист" (особенно из  последних
на треке), то все равно  теряет-
ся оборот диска на его запись  -
проигрыш явно больше.

   Прим. ред.:  Действительно, если форма-
тирование дорожки осуществляется средства-
ми TR-DOS, прервать  его  нельзя.  Значит,
нужно непосредственно управлять ВГ93. При-
мер алгоритма форматирования:

 - записать в регистр команд ВГ93  код ко-
   манды форматирования;
 - выдавать  на  ВГ байты, соответствующие
   выбранному формату, до тех пор, пока не
   будет отформатирован последний сектор;
 - использовать  команду   принудительного
   прерывания;

   Как видно, время  форматирования  одной
дорожки здесь не играет роли, т.к. оно во-
обще не используется. Но  выясняется  одно
неприятное обстоятельство: не хватает быс-
тродействия  Z80  для того, чтобы выдавать
на  ВГ  байты для форматирования. Действи-
тельно, диск вращается  со  скоростью  300
об/мин, на 1 оборот тратится 0,2 сек., или
700000 тактов Z80.  Так как на дорожку за-
писывается  около  7000  байтов, на запись
каждого из них должно  быть  затрачено  не
более 100 тактов Z80. Между  тем  фрагмент
программы, который записывает на диск один
байт, будет выполняться не менее 120  так-
тов:
140.
;Пусть регистры имеют следующие значения:
;C  - #7F (адрес регистра данных)
;HL - #20AF (адрес п/п записи байта)
;IX - адрес следующей команды, на которую
;будет  передано  управление после записи
;байта.

        LD      D,байт  3;7 тактов
        PUSH    IX      3;15
        PUSH    HL      3;11
        JP      #3D30   3;10
#3D30:  RET             3;10
#20AF:  LD      B,1     3;7
#20B1:  IN      A,(255) 3;11
        AND     #C0     3;7
        JR      Z,#20B1 3;7/12
        RET     M       3;5/11
        OUT     (C),D   3;12
        DJNZ    #20B1   3;8
        RET             3;10
2
   А все потому, что регистры ВГ появляют-
ся в адресном пространстве только в момент
работы TR-DOS. Если бы был свободный  дос-
туп  к  регистрам, без  участия TR-DOS, то
сверхбыстрое  форматирование  стало бы ре-
альностью!
   Все вышесказанное относится и к  записи
секторов  одновременно  с форматированием.
При этом проверка сектора на наличие  бай-
тов  #F5, #F6 и #F7  должна  производиться
непосредственно  при  форматировании,  так
что лишнего времени она не займет. Да, ес-
ли такие байты будут обнаружены, потеряет-
ся  еще один оборот диска на запись секто-
ра.  Но не так часто они встречаются - на-
пример, на диске с текстовыми  файлами  их
вообще может не быть.

   Корр.:  Теперь про перестрое-
ние экрана за  одно  прерывание:
как было сказано в разных источ-
никах, это невозможно, но в кон-
кретных случаях это  очень  даже
реально.  Возьмем, допустим, AC-
TION, LIFE SUX  -  демо.  Там не
только  перестраивается весь эк-
ран, но и в одном под сетку  вы-
водится довольно большой спрайт,
во втором бежит строка. Делается
это элементарно:  как можно было
заметить, эти экраны состоят  из
одинаковых сегментов (к примеру,
в LIFE SUX 2*2 знакоместа). Про-
грамма для вывода  одной  строки
будет такая:

     LD SP,scradr+1
     LD HL,BYTE
     PUSH HL ;16 РАЗ (16*2=32)

   Как видно, вывод одной строки
занимает 11*16+10+10=191 такт, а
так как  одну  строку  видеокон-
троллер проходит  за  224 такта,
остается еще куча времени  (если
учесть еще  и  BORDER  сверху  и
снизу).

   HELP  ME!  Делал  я   недавно
скроллер (хобби  у  меня  такое:
делать разные  VIEWER'ы, тексто-
вые скроллеры, help'ы и т.д.), и
столкнулся  с  одной  проблемой:
стек был  переставлен  на  экран
(чтение/запись  строк), но  были
включены IM 2, и хотя  программа
обработки прерываний переставля-
ла стек в буфер, экран все  рав-
но портился, т.к. Z80 при вызове
IM 2 все равно заносит на стек 2
байта... В ZX-FORMAT'е  Медноно-
гов сказал, что совместил  вывод
музыки и спрайтов через  стек  -
может  ли  кто-нибудь  помочь  в
этом вопросе - буду очень благо-
дарен...

   Прим. ред.: Если используется переброс-
ка данных с помощью стека и разрешены пре-
рывания, необходимо тщательно  планировать
распределение времени Z80.  Пусть промежу-
ток между двумя прерываниями 70000 тактов,
процедура  обработки  прерываний  занимает
10000 тактов, а процедура  SCR, с  помощью
стека сдвигающая содержимое  экрана, зани-
мает 100000 тактов.  Тогда  лучше  разбить
эту процедуру на несколько частей, скажем,
на 5 по 20000 тактов  каждая, и  программа
будет выглядеть следующим образом:

    HALT  ;выполняется процедура обработки
          ;прерывания - 10000 тактов
    CALL    SCR1  ;20000
    CALL    SCR2  ;20000
    CALL    SCR3  ;20000

    HALT          ;10000
    CALL    SCR4  ;20000
    CALL    SCR5  ;20000
    CALL    SCR1  ;20000 (следующий сдвиг)
    ...