Sinclair Club #05 31 декабря 2001

Софт

Софт - Странности системных программ: STS 5.1, ALASM 4.1.

   ┌──────────────────────────────────┐
   │  Странности системных программ!  │
   └──────────────────────────────────┘

──────────────────────────────────────────

	 (с) Alone Coder/Any

──────────────────────────────────────────

	    STS 5.1 by STALKER

   STS 5.1 имеет весьма  странный редактор
строки в режиме Hex Dump.
   Если в этой строке стоял символ "▒", то
после нажатия Enter,когда строка скопируе-
тся в память,этот байт будет пропущен. По-
следние  байты  строки в этом случае будут
взяты из предыдущего варианта (который су-
ществовал до редактирования),а,проще гово-
ря, с потолка.
   На этот глюк уже ссылался кто-то где-то
(пойди,  найди  теперь!), приводился  даже
способ исправления,уменьшающий длину буфе-
ра пользователя. Приведу другой способ:

Copy from #DE10 to #DE1B -> #DE0F
#DE1B: JR Z,#DE22
       DEC DE

   После такого исправления байт, помечен-
ный символом "▒", меняться не будет.
   Исправления нужно делать не на работаю-
щем STS'е, а на загруженном в другую стра-
ничку файле sts5.1a!

   Неправильное  позиционирование  на  0-ю
дорожку после смены дисковода - это хрони-
ческая болезнь всех версий STS. Версию 6.2
фиксил Иван Рощин,а по поводу 5.1 вроде бы
пока ничего не известно...

	  ALASM 4.1 6x7 by ALEM

   ALASM  имеет  глюк при ассемблировании,
связанный с пересечением  командой  адреса
#8000. В большинстве  случаев это приводит
к тому, что кусок  команды до адреса #7FFF
включительно компилируется нормально,а ос-
тальная часть затирает начало ALASM'а.
   Этот глюк уже  описывался MAX'ом в жур-
нале "Чёрная Ворона" #3. Объясняется  глюк
тем, что во время своей работы ALASM (как,
впрочем, и другие ассемблеры) перемещается
во  2-ю  страничку, а старое её содержимое
в это время хранится в так называемой Sys-
tem page (обычно 4-я страничка). После вы-
хода из ассемблера(а также после RUN,DEBUG
и т.д.) странички,естественно,переставляю-
тся обратно.
   Префиксированные  команды этим не стра-
дают. Если  предыдущая команда закончилась
на #7FFF,а следующая идёт по адресу #8000,
то проблем тоже не возникнет. Да и вообще,
если ты знаешь про этот глюк, то его можно
проконтролировать. Например,процедура ини-
циализации у меня в AC Edit спокойно пере-
секает #8000. Другое дело, что я её ни не
меняю :)).
   А лучше,конечно,сразу писать свои прог-
раммы в быстрой памяти.
   При переходе  через адрес #C000 глюк не
возникает.

   Есть  ещё  один глючок в ALASM, который
исправить невозможно.Он связан со специфи-
чным однопроходным методом компиляции.Пра-
вда, сначала нужно объяснить, как работает
однопроходный компилятор.
   Компилятор просматривает текст програм-
мы сверху вниз,ассемблируя команды,опреде-
ляя  метки и проставляя определённые пара-
метры команд в их адресную часть.Если ком-
пилятор  встречает  выражение с не опреде-
лённой выше меткой, то он выдаёт сообщение
об  ошибке. Если же он встречает просто не
определённую ранее метку,то он заносит имя
этой  метки и адрес адресной части команды
(сорри,каламбур) в таблицу.Когда метка бу-
дет определена, все незаполненные адресные
части команд, долженствующие содержать ад-
рес этой метки, заполняются,и их вхождения
удаляются из таблицы.
   Теперь внимание! Как же откомпилируется
такой фрагмент?
      DUP 7
       LD A,(BC)
       XOR (HL)
       AND 240
       XOR (HL)
       LD (DE),A
       INC B       ;+0
       INC H       ;+1
       INC D       ;+2
       LD A,D      ;+3
       AND 7       ;+4
       CALL Z,DDEU ;+6
      EDUP
       ORG $-9
       JP PRRQ     ;+0

PR1ST  PUSH BC     ;+3
       PUSH DE     ;+4
       PUSH HL     ;+5
       BIT 0,C     ;+6
       JR Z,PR1STL ;+8
       ...

DDEU   LD A,E
       ADD A,32
       LD E,A
       RET C
       LD A,D
       SUB 8
       LD D,A
       RET
   Внутренности DUP'а откомпилятся 7 раз,
потом текущий адрес переместится на коман-
ду INC B (для удобства я указал для команд
смещение относительно этого адреса), и...
   А ведь метка DDEU ещё  не определена! И
после того,как она определится,её значение
будет записано по относительному адресу +7
в параметр команды CALL, которая в тот мо-
мент уже  не будет существовать! В резуль-
тате будут испорчены  ни в чём не повинные
команды BIT и JR !
   Поэтому такие куски нужно писать следу-
ющим образом:
      DUP 6
       LD A,(BC)
       XOR (HL)
       AND 240
       XOR (HL)
       LD (DE),A
       INC B
       INC H
       INC D
       LD A,D
       AND 7
       CALL Z,DDEU
      EDUP
       LD A,(BC)
       XOR (HL)
       AND 240
       XOR (HL)
       LD (DE),A
       ...
   А ещё лучше сделать мэйкер.

   Глюк с 11-символьным именем диска в ре-
жиме  каталога  в  ALASM'е: если имя диска
имеет все 11 символов, то дальше могут по-
казываться  совершенно случайные символы в
произвольном количестве. Правильная же пе-
чать 11-символьного имени должна учитывать
в качестве  окончания имени: 1) конец сек-
тора; 2) байт #0; 3) установленный 7-й бит
(который, кстати, при печати нужно сбрасы-
вать).
   Наверное,многих достаёт Help при запус-
ке аласма.Его можно убить так(сама команда
Help от этого,разумеется,не пострадает):

#B77E: JP #8B8F

   При  этом  даже освобождаются следующие
15 байт. Хотя,собственно,их можно выиграть
и в другом месте:кодинг у мэтров настолько
оригинальный, что их программы ещё оптими-
зировать и оптимизировать...
   В этих 15 байтах (точнее, нам нужно то-
лько 13) мы и размещаем нашу программу пе-
чати имени диска:

#B781: LD A,(HL)
       AND 127
       RET Z
       CALL #8C96
       OR (HL)
       RET M
       INC L
       JR NZ,#B781
       RET

   И меняем ссылку:

#99D1: CALL #B781

   Естественно,всё это нужно делать опять-
таки  не на работающем аласме, а на загру-
женном по адресу #8000 файле alasm67.