commit bd2abb6229813f9b8c54832aa2c50fd24c922c52 Author: Anatoliy Belyanskiy Date: Thu Jun 15 02:20:40 2023 +1000 Initial commit diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 0000000..7355856 --- /dev/null +++ b/.gitmodules @@ -0,0 +1,4 @@ +[submodule "Shared_Includes"] + branch = main + path = Shared_Includes + url = https://github.com/Tolik-Trek/Shared_Includes.git diff --git a/Docs/FORMATS/AZXformat103.txt.zip b/Docs/FORMATS/AZXformat103.txt.zip new file mode 100644 index 0000000..9724403 Binary files /dev/null and b/Docs/FORMATS/AZXformat103.txt.zip differ diff --git a/Docs/FORMATS/HOBETA.MSG b/Docs/FORMATS/HOBETA.MSG new file mode 100644 index 0000000..e66551a --- /dev/null +++ b/Docs/FORMATS/HOBETA.MSG @@ -0,0 +1,74 @@ +─ SPECTRUM RULEZ! (2:5020/993.213) ─────────────────────────────── ZX.SPECTRUM ─ + Msg : 133 of 185 + From : Alexei Bugai 2:461/173.3 Fri 31 Oct 97 23:24 + To : Ilya Zverev Mon 03 Nov 97 17:43 + Subj : Фоpмат файлов хобеты +──────────────────────────────────────────────────────────────────────────────── + Peace unto you, _Ilya_! + +29 Oct 97 Ilya Zverev write to All about "оpмат файлов хобеты": + + IZ> Очень нужен сабж, pls. + +== Cut == +Структура 17-байтного заголовка, добавляемого к TR-DOSным +файлам программой HoBeta.exe: + +00-07 - имя файла +08 - тип файла +09-0A - Start +0B-0C - Length +0D-0E - Length в 256-байтных записях (байт 0E - pазмеp в сектоpах) +0F-10 - Контрольная сумма + +Таким образом, первые 14 байт копируются из TR-DOSовского каталога. + +Вычиление контрольной суммы: S=S+257*Di+i, где + +S начальное=0 +Di - значение байта +i - порядковый номер байта (если не ошибаюсь, начиная с 0, а не с 1) + + +C src: + +union { + struct { + unsigned char tr_filename[8]; + unsigned char tr_filetype; + unsigned int tr_address; + unsigned int tr_length; + unsigned int tr_tr; + unsigned int tr_crc; + } tr_head; + unsigned char head[17]; +} header; + +unsigned int CheckSum; +int i; + +CheckSum=0; +for (i=0; i<=14; CheckSum = CheckSum + (header.head[i] * 257) + i, i++); +header.tr_head.tr_crc = CheckSum; + + +Вот в одной из своих программок нашел такой забавный способ подсчета +контрольной суммы заголовка: + + checksum=0; + for (i=0; i<=14; checksum+=(unsigned char)*(bufptr+i), i++); + checksum*=257; + checksum+=105; + +bufptr, очевидно, поинтер на начало заголовка. +=== Cut === + + + With best wishes, [ZX_Power Team] + Dr.Squizer. [Power_ZX Team] + +... Don't try to understand me... You never will! +--- Powered by Spectrum Mail System. + * Origin: X-Project BBS (2:461/173.3) + + \ No newline at end of file diff --git a/Docs/FORMATS/Hobeta_fmt.txt b/Docs/FORMATS/Hobeta_fmt.txt new file mode 100644 index 0000000..035170d --- /dev/null +++ b/Docs/FORMATS/Hobeta_fmt.txt @@ -0,0 +1,61 @@ +">Q04: Что за файлы с pасшиpением *.$b, *.$c? +A: Хобетный файл. То есть файл, скопиpованный пpогpаммой hobeta из +тp-досной дискетки. Буква чаще всего обозначает пpинадлежность к +какому-либо типу. (.$b - запускаемый файл бейсика, .$w - текст в фоpмате +спектpумовского ZX-Word, .$m - музыка для спектpумовского Pro Tracker'а +и т.д.) Расшиpение в пpинципе может быть любым. Это зависит от автоpов +пpогpаммы, котоpая пользуется этими файлами. +A: Michael Kondratyev (2:5030/362.1) Его (хобетного файла) стpуктуpа: +Пеpвые 13 байт точная копия тpдосного заголовка. Далее два байта длины +в сектоpах; т.к. она кpатна 256, то пеpвый всегда ноль, а втоpой - +число сектоpов. А последние два байта - контpольная сумма. Считается +она пpосто - суммиpуются все пpедыдущие 15 байт, число умножается на +257 и пpибавляется сумма_чисел_от_0_до_14 т.е. 105. +Вот пpоцедуpка на Z80 Asm: +; на вход de = адpес заголовка +ld hl,0 +ld b,15 +m1: ld a,(de) +add a,l +ld l,a +jr nc,m2 +inc h +m2: inc de +djnz m1 +add a,h +ld h,a +ld c,105 +add hl,bc ; hl = Hobeta sum + +>Q05: А pасшиpение .$z? +A: Хобетный файл, упакованный на спектpуме пpогpаммой zxzip (by Michael +Kondratyev), ставший де факто официальным паковщиком пpогpамм для ZX. +Для его pаспаковки необходим zxunzip. Автоp написал zxunzip и zxzip и +для pc тоже. Существует plugin для FAR - xZXZIP. Он позволяет входить +в zxzip аpхивы как в каталоги и извлекать/пpосматpивать файлы из них, +zxunzip пpи этом не тpебуется. + +>Q06: Наpод. Помогите pls как эти хобетные файлы запустить. +A: Самый пpостой ваpиант - запустить Spectrum Navigator (копия Dos Navigator, +но c уклоном под ZX. Автоp - Roman Khroupnin 2:5015/97, +ftp://dimm.ab.nnov.ru/sn/ ) и создать там новый обpаз диска .trd, или войти +в стаpый и пpосто скопиpовать туда по F5 имеющиеся хобетные файлы. После +чего смело использовать .trd в эмулятоpе. Ещё можно подключить plug-in xTRD +к FAR'у, котоpый также позволит копиpовать .$? в тpдшники. Эти же пpогpаммы +позволяют совеpшать обpатное действие. Обpаботать хобетные файлы и .trd +можно очень большим количеством способов. И это уже злостнейший фак (в +смысле FAQ) . Читайте доки к Spectrum Navigator, zcop - это весьма +полезное занятие. +A: Можно использовать утилиту Archive Support (с) Max Piwamoto совместно с +одним из эмулятоpов, поддеpживающим тp-дос: ukv, zx_emul, r80, shalaev... +А: Существует также набор плагинов HalfElf'а (djk@dem.kreml.nnov.ru) для FAR +Manager. Состоит из следующих плагинов: +1. bView v0.3b - позволяет просматривать Basic файлы в формате Hobeta. +2. unSNAP v0.2b - конвертит .SNA и .Z80 в набор файлов Hobeta. +3. xCreate v0.22b - создает диски TR-DOS в форматах trd, fdi, scl. +4. xHRiP v0.1b - распаковывает файлы, созданные ZX-архиватором HRiP. +5. XiSD v0.1b - работает с iS-DOS дисками в форматах .img, .fdi. +6. xSCL v0.1b - работает с .SCL +7. xTRD v0.9b - работает с образами дисков .trd, .td0, .fdi. +8. xZXZIP v0.11b - распаковывает файлы, созданные архиватором ZXZIP. +Есть еще плагин к Windows Commander." diff --git a/Docs/FORMATS/SPGv0_2.INF b/Docs/FORMATS/SPGv0_2.INF new file mode 100644 index 0000000..a1a776f --- /dev/null +++ b/Docs/FORMATS/SPGv0_2.INF @@ -0,0 +1,76 @@ + .SPG Данный формат служит для хранения запускаемых программ на любых носителях (CD/DVD/HDD/SD). Сами файлы могут быть запущены из WDC простым нажатием на ENTER. Отличия от SPGv0.1 в основном не критичны и запускалка версии 0.2 подойдёт и к v0.1/0.0, но всё же в v0.2: блоков загрузки стало 16(!), а длина заголовка каждого блока уменьшилась до 4х байт! Другими словами, чтобы можно было загружать v0.1 и ниже, необходимо увеличивать шаг в области заголовков блоков загрузки с 4 до 8!!! Так же, если запускалке v0.2 скармливается более ранняя версия, то из +66(1) надо читать через AND 7 И самое главное. В данной версии появилась возможность работы с 256к памятью. Для выбора страниц после загрузки нужно вызывать специальную процедуру, которая загружается на указанный в SPG заголовке адрес... [не забываем ПРОВЕРЯТЬ версию формата в +44(1)!!!] в WDCv1.3final есть ограничения: 1.все блоки (кроме первого), нужно грузить в адреса #A000-#FFFF!!! [первый блок можно грузить в #9A00-#FFFF!!!] 2.используется 256к память!!! перед загрузкой SPG, запускается детектилка 256к памяти (на данный момент ищётся память пентагона, затем скорпиона(кая) и затем профи), если 256к память не найдена, то загрузка модулей с номерами страниц выше #07 будет идти в нижние 128к!!! [в зависимости от того, какой клон был найден,] [в память загужается манажер страниц (в адрес] [указанный в +68(2)), к нему надо обращаться] [при выборе страниц... ] !более подробно смотрим в описании смещения +68! 3.недопустимо задавать адреса загрузки менеджера + страниц и блока переменных в диапазоне от #7000 + до #99FF!!! + !*это приведёт к зависанию при запуске.*! "Spectrum Prog" file format v0.2: смещ│длин. ────┼─────────────────────────────────────────────── +0│32 - резерв +32│12 - идентификатор формата ("SpectrumProg") +44│1 - версия формата(#00=0.0, #01=0.1, #02=0.2) +45│2 - CRC всего заголовка (512 байт) +47│2 - обратная CRC (старший байт впереди) │ [CRC=арифметич. сумме всех 512ти байт] │ [заголовка + 512... ] │ !если = 0, то не проверяем CRC! ────┼─[запись_в_порт X]*5───────────────────────── +49│2 - адрес порта Xi +51│1 - значение в него (если адрес <> 0!) ────┼─ параметры_запуска ─────────────────────────── +64│2 - адрес запуска программы +66│1 - номер страницы при запуске │ [в 256к - это номера от 0 до 15] │ +67│1 - флаг │ [=0 - не реагируем] │ [=1 - номер активного дисковода кидается] │ [в соотв. переменные TR-DOS перед самым ] │ [запуском ] │ +68│2 - адрес куда будет загружен манажер страниц │ [если =0, то таковой не загружается] │ сам по себе менеджер представляет простую │ процедуру, имеющую только один входной │ параметр: в регистре A указывается номер │ страницы которую надо включить (нумерация │ совпадает с той, что используется в заго- │ ловках к блокам загрузки). │ допустимый диапазон - от 0 до 15, но надо │ учитывать, что обращение к #7FFD идёт по │ маске #10!] │ !размер менеджера не более 32 байт! │ +70│3 - дата (день,месяц,год) +73│1 - версия сборки программы +74│2 - адрес вершины стека(если=0, то не меняем) │ +76│2 - адрес куда будут загруженны переменные │ [ к примеру, можно хранить переменные] │ [бэйсика и тр-дос'а, указав вдрес #5C00] │ [и длину 320 байт] +78│2 - длина блока переменных │ [если=0, то игнорируем таковые, иначе] │ [кидаем n<321 байт на адрес в +76(2).] │ !если же адрес = 0, то кидаем в #5B00! ────┼─[POKEZ] ───────────────────────────────────── +80│48 - coming soon! ^_^ ────┼─[блок_загрузки]*16────────────────────────── +128│2 - адрес загрузки │ (если <#9A00, то идёт завершение обработки │ блоков загрузки) │1 - длина блока в 2048 байтных секторах │1 - номер страницы в которую грузим блок │ [для 128к они идут от 0 до 7] │ [для 256кб от 0 до 15... ] ────┼────────────────────────────────────────────── +192│320- блок переменных программы или бэйсика ────┼────────────────────────────────────────────── +512│XXX- кодовый блок/блоки ────┴────────────────────────────────────────────── !во время запуска программы включен 1й режим! !прерываний (I=63), но они запрещены. ! +P.S.первый грузимый блок должен распологаться сразу + за заголовком в 512 байт, а все последующие + должны распологаться сразу за предыдущим, но по + адресу кратному 2м Кбайт!!! + (см. PREF.txt и PREFWP.txt) + длина первого грузимого блока = длине указанной + в переменой + (2048-512). Другими словами, если + длина первого блока меньше 1536 байт, то его + длину в 2к блоках надо указывать нулевой!!! + [это вызвано тем, что первые 1536 байт такового + распологаются в 2х килобайтном блоке заголовка] --------------------------------------------------- Приложение + +;менеджер страниц под Pentagon: +MANAG0 ;I:A - num of PAGE (VALID: 0-15) +; Pentagon + PUSH BC + LD C,A + AND %11111000:LD A,C:JR Z,K128 + AND 7:OR %01000000 +K128 OR 16:LD BC,#7FFD:OUT A + POP BC + RET + +;менеджер страниц под Scorpion/KAY: +MANAG1 ;Scorpion/KAY + PUSH BC + PUSH AF + AND %11111000 + LD A,16:JR NZ,$+3:XOR A + LD BC,#1FFD:OUT A + POP AF + AND 7 + OR 16:LD B,#7F:OUT A + POP BC + RET + +;менеджер страниц под Profi: +MANAG2 ;Profi + PUSH BC + PUSH AF + AND %11111000 + LD A,1:JR NZ,$+3:XOR A + LD BC,#DFFD:OUT A + POP AF + AND 7 + OR 16:LD B,#7F:OUT A + POP BC + RET + +;менеджер страниц под ATM 4.5: +MANAG3 ;ATM 4.5 + PUSH BC + PUSH AF + AND %11111000 + LD A,1:JR NZ,$+3:XOR A + LD BC,#FDFD:OUT A + POP AF + AND 7 + OR 16:LD B,#7F:OUT A + POP BC + RET + +;менеджер страниц, если найдено только 128к: +MANAGF ;128k + PUSH BC + AND 7 + OR 16 + BC,#7FFD:OUT A + POP BC + RET +--------------------------------------------------- + Budder/23.12.2006-13.10.2009 \ No newline at end of file diff --git a/Docs/FORMATS/TZXformat113.txt.zip b/Docs/FORMATS/TZXformat113.txt.zip new file mode 100644 index 0000000..4b3a7a8 Binary files /dev/null and b/Docs/FORMATS/TZXformat113.txt.zip differ diff --git a/Docs/FORMATS/csw.html b/Docs/FORMATS/csw.html new file mode 100644 index 0000000..cfaea87 --- /dev/null +++ b/Docs/FORMATS/csw.html @@ -0,0 +1,386 @@ + + + + + + WWR - CSW technical specifications + + + + + +
+ + +
CSW FORMAT
+
+Compressed Square Wave
+Created by Ramsoft ZX Spectrum demogroup +

+Format revision: v2.00 (August 1st 2003) +

+
+

+ +
+ +
    +
  1. Introduction
    2. +
  2. The CSW utility
    3. +
  3. CSW file format
    4. +
  4. Old CSW 1.01 file format
    5. +
  5. Contact information
    6. +
  6. Revision history
    7. +
+


+ + + +

+
+1. + +Introduction +
+
+
+This document describes the CSW file format and the CSW.EXE utility. CSW is strongly based upon the MakeTZX engine and it shares with it various aspects of its behaviour. In the manual of MakeTZX you will find lots of explanations, tips and FAQ that are not reported here, so we recommend you to read it too. + +

+The CSW file format +

+ +CSW files are a way of storing sample data in a compact form, typically taking 1/10th of an ordinary VOC. It is used internally by MakeTZX, but it is also very useful to keep down the disk space taken by your VOC/WAV files. The CSW utility can handle CSW conversion in both ways (see below). Of course, MakeTZX itself accepts CSW files for input. +When converting to the CSW format, the sample file is processed through MakeTZX's internal digital filter which reduces noise and signal distortions very efficiently. Make a backup copy of the original file if you will need the original samples later, but remeber that in most cases the CSW will be a lot better than the original file. +Note that CSWs are intended for use with square waves only (such as computer tapes)! +The compression ratio depends on many factors; in general, the higher the sample rate, the higher the ratio. A clean and regular signal helps too. The ratio for a 44 KHz file will usually be twice the value for a 22 KHz one. The typical gain for a 44 KHz turbo tape is about 93%, which means a 12:1 compression factor! Normal speed tapes should compress even better. +Finally, CSW files are highly compressable with the standard PC archivers such as RAR and ZIP. The packed CSW files are usually smaller than the zipped original VOCs. You will be able to RAR a 40 MB sample file down to a few hundreds KB. +

+ + + + + +

+
+2. + +The CSW utility +
+
+
+This small program is intended to provide a basic support for CSW files. It can compress VOC, WAV, IFF and OUT files to CSW and decompress CSW files back to VOC format (switch -d). Enter CSW -? or simply CSW for help. At the moment, CSW.EXE accepts only uncompressed mono 8-bit sample files. Extensions in filenames can be omitted; in this case, the default extensions will be appended in turn to match an existing file. The search order is VOC, WAV, IFF and OUT for last. If the output filename is left out, the input file name with extension .CSW (or .VOC if decompressing) will be used. If the input filename ends with the extension .CSW, then the switch -d (decompression) is implicitly assumed. +

+CSW can also work in DirectMode (switch -r), in which case the input is taken from your soundcard and conversion is performed on-the-fly in true realtime. You can stop the conversion by pressing any key at any time. To pause the recording press 'P', followed by any key to resume. During the pause, the vu-meter is shown again. +Note that, due to MakeTZX's engine requirements, the samples are written to disk anyway, so the maximum recording time is limited by the available disk space. If you want, you can keep this samples at the end of conversion and save them in a WAV file (switch -k), just in case something goes wrong and you don't want to repeat the sample. In this way, CSW may also act like a sampler! +You can set the sampling frequency with switch -s (e.g. -s44100). You can also do programmed recordings using switch -t and specifying the recording time (in seconds, e.g. -t60.0 for one minute); in this case, CSW will automatically stop when the time has elapsed (or when the disk is full), so you can start it and go away to do better things :) +

+The DirectMode SoundBlaster driver has been written for 100% compatible soundcards. If you are experiencing problems, try option "-c" which will attempt to access the hardware in a different way. The driver also performs a preliminary stability check; if this fails, CSW exits after two seconds with an error message. All this stuff is extensively covered in MakeTZX's manual, DirectMode section; please read it carefully. +Note: In order to run the CSW utility under plain MS-DOS you need a DPMI host (such as CWSDPMI.EXE) +Note: DirectMode, OUT files, digital filter and the other features are extensively described into MakeTZX's manual. Please read it. +Note: Although it is possible to specify fractions of seconds, the effective recording time is subject to DMA buffer size quantums (a few 1/10ths of sec). +Note: Like MakeTZX, CSW supports long filenames under Windows 9x + +

+ + + + +

+
+3. + +CSW-2 file format +
+
+
+ +Here is the CSW implementation chart for anyone who wants to use it in some utility or emulator (if so, please let us know). The file format is very simple and the compression scheme used is somewhat based on the RLE algorithm. +

+ +
+ + + + + + + + + +
Legenda
WORD2 bytes
DWORD4 bytes
BYTE[N]N bytes
ASCII[N]N ASCII characters
ASCIIZ[N]ASCII string with zero-padding to N bytes total
All multi-byte values are stored in Intel byte order (little-endian).
+All reserved or undefined bits must be set to zero. +
+All the headers fields must be filled in; blank values are not allowed.
+ +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CSW-2 Header
CSW global file header - status: required
OffsetValueTypeDescription
0x00(note)ASCII[22]"Compressed Square Wave" signature
0x160x1ABYTETerminator code
0x170x02BYTECSW major revision number
0x180x00BYTECSW minor revision number
0x19-DWORDSample rate
0x1D-DWORDTotal number of pulses (after decompression)
0x21-BYTECompression type (see notes below)
+0x01: RLE
+0x02: Z-RLE +
0x22-BYTEFlags
+b0: initial polarity; if set, the signal starts at logical high
0x23HDRBYTEHeader extension length in bytes (0x00)
+For future expansions only, see note below.
0x24-ASCIIZ[16]Encoding application description
+Information about the tool which created the file (e.g. name and version)
0x34-BYTE[HDR]Header extension data (if present)
0x34+HDR--CSW data.
+ + +
+ +

+Note about Header Extensions: +

+CSW-2 allows to extend the header size by a certain amount of bytes (the current default value is 0). However, this is designed for future revisions of this format and it is not meant to store application-specific data. + +

+Compression types: +

+
    +
  • 0x01: RLE (Run Length Encoding)
    +The data is stored as a sequence of pulse lengths (1 byte per pulse). Consider the following scenario (each dot is a sample): +

    + +

    +The 5 pulses shown will be represented with the following bytes:
    +03 05 01 04 07
    +Pulse lengths greater than 0xFF (255) are represented as byte 0x00 followed by the duration represented on 4 bytes, e.g. 0xCDE9 is stored as 00 E9 CD 00 00. +
    • +

    +
  • 0x02: Z-RLE (CSW v2.xx only)
    +Pulses are encoded exactly as in method 1, but the generated byte-stream is further compressed with the standard deflate() algorithm as defined by the ZLIB library (RFC 1151 and 1152). In fact the compression is equivalent to "gzip -9" (without the magic signature); the source code of the compression routines we used is the same as in our RZX SDK. [more tech details here] +
    • +
+ +
+In format revision 1.01 we have introduced a bit to represent the initial signal polarity, which is not important in the Spectrum world but it is for other platforms such as C64. All the Spectrum TZX converters can safely ignore this bit (like MakeTZX does), so any tool supporting CSW 1.00 will also work fine with CSW 1.01 without modifications. +

+Note that no info about the pulse amplitude is represented because it is not necessary, since we are dealing with discrete 2-values amplitude scales. +

+ + + + + + +

+
+4. + +Old CSW v1.01 file format +
+
+
+This is the format specification for the old CSW v1.01. It is reported here because a lot of existing tools support the original version of the file format. +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CSW-1 Header
CSW global file header - status: required
OffsetValueTypeDescription
0x00(note)ASCII[22]"Compressed Square Wave" signature
0x160x1ABYTETerminator code
0x170x01BYTECSW major revision number
0x180x01BYTECSW minor revision number
0x19-WORDSample rate
0x1B0x01BYTECompression type
+0x01: RLE +
0x1C-BYTEFlags
+b0: initial polarity; if set, the signal starts at logical high
0x1D0x00BYTE[3]Reserved.
0x20--CSW data.
+ + +
+ +

+For information about the RLE compression method (0x01) and the meaning of the polarity flag, please refer to the notes for version 2.xx. +

+ + + + + + +

+
+5. + +Contact information +
+
+
+The latest version of this document can be found at: + +E-mails concerning the CSW specifications should be directed to: + +

+ + + + + +

+
+6. + +Revision history +
+
+
+Revision 2.00 (August 1st 2003) +
    +
  • Introduced CSW revision 2.00.
    • +
  • Cleared up the document a bit.
    • +
+Revision 1.01 (July 13th 1999) +
    +
  • Introduced the polarity bit (b0 in Flags)
    • +
+

+ + + + diff --git a/Docs/FORMATS/fdd.hdr b/Docs/FORMATS/fdd.hdr new file mode 100644 index 0000000..e436311 --- /dev/null +++ b/Docs/FORMATS/fdd.hdr @@ -0,0 +1,43 @@ + + .FDD файлы + ---------- + +/* --------------------------------------*/ +/* эмулятор образа дискеты (image.fdd) */ +/* (c) 1996 MOA */ +/* ------------------------------------- */ + +// параметры "дискеты" +#define versionLength 30 + +#define TRACKMAX (85*2) +#define SECTMAX 30 // число секторов на дорожке + +/* формат файла образа диска */ + +/* заголовок */ +struct diskHEADER { + char head[versionLength]; /* сигнатура */ + byte trkMax; /* число треков, всего без учета головок */ + byte headMax; /* число головок (1 или 2) */ + long diskIndex = 0l; /* unused */ + long trkIdx[TRACKMAX]; /* смещение в файле к структурам заголовков */ + /* треков */ +}; + +/* местоположение остальной информации в файле не фиксировано */ + +/* информация о дорожке */ +struct diskTRACK { + byte trkType = 0; /* unused */ + byte sectNum; /* число секторов на треке */ + struct { + /* заголовок сектора */ + byte trk; /* номер трека */ + byte side; /* номер стороны */ + /* 7 бит этого байта указывает бит a */ + byte sect; /* номер сектора */ + byte size; /* размер сектора (код) */ + long sectPos; /* смещение в файле к данным сектора */ + } sect[SECTMAX]; +}; diff --git a/Docs/FORMATS/fdi.hdr b/Docs/FORMATS/fdi.hdr new file mode 100644 index 0000000..aca1eba --- /dev/null +++ b/Docs/FORMATS/fdi.hdr @@ -0,0 +1,89 @@ + + .FDI файлы + ---------- + + Поскольку по ряду причин существующие форматы файлов-образов дискет +не подходили (отсутствие документации, а главное - невозможность расширения +формата для записи полных образов треков, областей с физическими дефектами +и т.п.), то пришлось создать свой собственный формат. Не могу гарантировать, +что расширение *.FDI не используется еще кем-то для других целей; поэтому +оговорюсь, что данное описание актуально только для файлов, создаваемых +программой MAKEFDI и используемых программой SP_EMU (Spectrum debugger). + + +------------------------------------------------------------------------------ +Смещение Длина поля Описание +------------------------------------------------------------------------------ + +0 3 Ключевая метка 'FDI' +3 1 Флаг защиты записи (0 - write enabled, 1 - write disabled) +4 2 Число цилиндров +6 2 Число поверхностей +8 2 Смещение текста (короткий комментарий к диску) +A 2 Смещение данных +С 2 Длина дополнительной информации в заголовке. В этой версии - 0 + +E "Длина дополнительной информации" + Формат еще не определен (резерв для дальнейшей модернизации) + +E+"длина дополнительной информации" + ??? + Область заголовков треков. Здесь собрана вся информация о + формате дискеты. Эта область должна содержать не меньше + "Число цилиндров"*"Число поверхностей" заголовков. Заголовки + идут в порядке Cyl 0 Head 0, Cyl 0 Head 1, Cyl 1 Head 0 и т.д. + Формат заголовка описан ниже. + +"Смещение текста" + ??? + Комментарий к диску.Конец комментария - нулевой символ. + MAKEFDI при создании нового файла позволяет вводить комментарий + не более 64 символов с завершающим нулем,но при работе с файлом + длина этого поля будет определяться по положению завершающего + нулевого символа + +"Смещение данных" + ??? + Здесь лежат собственно данные из секторов. Сколько здесь будет + секторов, их длина и порядок следования - зависит от формата. + +------------------------------------------------------------------------------- + +Формат FDI-файла допускает пропуски между областями заголовков треков,текстовым +комментарием и областью данных. + + + Формат заголовка трека + +------------------------------------------------------------------------------ +Смещение Длина поля Описание +------------------------------------------------------------------------------ + +0 4 Смещение трека - начало области данных этого трека + относительно "Смещения данных" +4 2 Всегда содержит 0 (резерв для модернизации) +6 1 Число секторов на треке + +7 (Число секторов)*7 + Информация о секторах на треке. Каждый сектор описывается 7 + байтами. Первые 4 байта - стандарные параметры C,H,R,N из + адресного маркера. Следующий байт - флаги: + + bit 7=0 - маркер нормальных данных, 1 - удаленных данных; + bit 0-5: флаги CRC. Единица в одном из разрядов означает, что + при считывании этого сектора на длину 128,256,1024,2048 или + 4096 байт получается правильная контрольная сумма. Если во всех + разрядах 0 - сектор записан с ошибкой контрольной суммы. + bit 6: В данной версии всегда 0. Возможно, 1 в данном разряде + будет обозначать адресный маркер без области данных. + + Последние 2 байта - смещение данных этого сектора относительно + начала области данных трека. Чтобы получить абсолютный адрес + в файле, к этому числу надо добавить "Смещение данных" и + "Смещение трека" +------------------------------------------------------------------------------ +7*(Число секторов+1) длина заголовка трека + + + Заметим, что байт флагов в описании сектора пока никак не используется +эмулятором. diff --git a/Docs/FORMATS/info_guide/1SPRITES b/Docs/FORMATS/info_guide/1SPRITES new file mode 100644 index 0000000..ad34e97 --- /dev/null +++ b/Docs/FORMATS/info_guide/1SPRITES @@ -0,0 +1 @@ + │ / P---\ R'''> O ──┼─── ══── / ! \ : > │ ║ / /___ ! / : > _____ │ ──── / / !___/ :::> ! │ │ /_ / ! : \ ! │ │ / / ! : \ ----- ╘═══ \──── / .TXT Здесь представлена структура и признаки файлов, содержащих графику для различных графических редакторов: спрайтов (где есть хоть какой-то намек на информацию о размерах и числе спрайтов), текстур и заливок, мультиколорные экраны, RGB (BMC 8 colors, 3 bitplanes) экранов. Информация как самолично добытая, так и из хелпов к прогам. Версия от 26.10.2001+08.06.2005 _______________________________ Что тут новенького Добавлены форматы: спрайты для Myth OS - Image LiBrary, Blade Sprite Designer, Generator Sprayts (THD), Sprites Editor v2.31 (Дмитрий Гультяев), Sprite Maker v1.60 (FREE Group), Spriter (STALL), FLN пакет v1.0 (Volgasoft), формат "*.smm", применяемый в XDOS. Всего 34 формата. Alone Coder> Добавлены форматы .888, .mc, .mcx, .S (256x128), .C (128x96, 256x192). Убраны знаки копирайта. Исправлены цифры в некоторых таблицах. -------------------------------- Здесь может быть и ваш графический редактор. -------------------------------- Файл имеет заголовок: *.C start: Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ └────────┴─────┴───────────────────────────────────────────────┘ 11111111111111111111111111111111 Редакторы стандартной графики. 11111111111111111111111111111111 -------------------------------- Sprite Master v 5.xx by XL DESIGN -------------------------------- Файл имеет заголовок: *.F start:#bff7 или (в XDOS) *.smf Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 00 │ 02 │Длина файла-9=длина спрайтов │ │ 02 │ 01 │Номер формата (1..12) │ │ 03 │ 01 │Размер: 0-фиксированный 1-различный │ │ 04 │ 01 │Атрибуты: 00-нет 01-символ 02-линия │ │ 05 │ 01 │Пикселы: 00-символ 01-линия │ │ 06 │ 01 │Высота (1..24) │ │ 07 │ 01 │Ширина (1..32) │ │ 08 │ 01 │Кол-во спрайтов │ └────────┴─────┴───────────────────────────────────────────────┘ далее - сами спрайты. Если размер спрайтов различный, то их структура такая: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 00 │ 02 │Смещение (=xx+4) до следующего спрайта │ │ 02 │ 02 │Высота и ширина │ │ 04 │ xx │Сам спрайт │ └────────┴─────┴───────────────────────────────────────────────┘ и так для всех спрайтов, иначе - сразу сами спрайты,без всяких маркеров. -------------------------------- SPwRITE MAKER v3 by MAYhEM 1997 -------------------------------- Файл имеет заголовок: *.* start:hi - количество спрайтов low - всегда=15 len: hi - высота в пикселах low - ширина в знакоместах Структура файла (Special format): ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 00 │ 33 │Заголовок: 'SPWR SPwRITE EDITOR v3 1996-1997' │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- SPwRITE MAKER v4,v5 by MAYhEM 1998 -------------------------------- Файл имеет заголовок: *.* start=#bef0 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 00 │ 13 │Заголовок: 'SPRWR v4 FILE' │ │ 13 │ 01 │= 0 │ │ 14 │ 01 │Ширина в знакоместах │ │ 15 │ 01 │Высота в пикселах (спрайты все одного размера) │ │ 16 │ 01 │Кол-во спрайтов начиная от 0 до 200 │ │ 17 │ 16 │Полная копия TR-DOS заголовка, │ │ │ │полученного при записи из редактора │ └────────┴─────┴───────────────────────────────────────────────┘ далее идут спрайты+маски, по линиям. -------------------------------- Sprite Cutter for ZXWinword v1.0 A.B.K./stars of Keladan h.g. -------------------------------- Эта программа может записать три типа файла спрайтов: 1) Спрайты без заголовка 2) Стандартные спрайты ZX-Winword'а, файл размером до 32Kb. Файл имеет заголовок: *.C start: hi - 0 low - число спрайтов Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 2 │Длина спрайта с заголовком - NXTSPR │ │ 2 │ 1 │Ширина в знакоместах - X │ │ 3 │ 1 │Высота в пикселах - Y │ │ 4 │X*Y*8│Пикселы │ │ 4+X*Y*8│ 1 │Если спрайт цветной, то #FF │ │ │ │Если спрайт не цветной, то #00 - конец спрайта │ │ 5+X*Y*8│ 1 │Ширина в знакоместах - AX │ │ 6+X*Y*8│ 1 │Высота в знакоместах - AY │ │ 7+X*Y*8│AX*AY│Атрибуты │ │ NXTSPR │ │Следующий спрайт │ └────────┴─────┴───────────────────────────────────────────────┘ 3) Компрессованые спрайты. Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Идентификатор - #aa │ │ 1 │ 1 │Число спрайтов - N │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 2 │ 2 │Смещение до первого спрайта - DS1 │ │ ... │ │ │ │ 2+2*N │ 2 │DSN │ ├────────┼─────┼───────────────────────────────────────────────┤ │ DS1 │ LN1 │Спрайты │ │ ... │ │ │ │ DSN │ LNN │ │ └────────┴─────┴───────────────────────────────────────────────┘ Сами спрайты имеют такую структуру: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │DS │ 1 │Ширина в знакоместах - XP │ │DS+1 │ 1 │Высота в пикселах - YP │ │DS+2 │ xx │RLE упакованные пикселы │ │DS+2+xx │ 1 │Ширина в знакоместах - AX │ │DS+3+xx │ 1 │Высота в знакоместах - AY │ │ │ │Оба - #00, если спрайт монохромный │ │DS+4+xx │ │RLE упакованные атрибуты │ └────────┴─────┴───────────────────────────────────────────────┘ RLE упаковка - берем байт данных: 1) Если его старший бит установлен, то далее идут несжатые данные, в количестве, содержащемся в младших шести битах взятого байта (1 - 127 раз). 2) Если его старший бит сброшен,то идущий далее байт повторяе- тся в количестве, содержащемся в младших шести битах взятого байта (2 - 127 раз). -------------------------------- THE REAL SPRITES TRANSFORMER v1.02 by Ю. Батенко и В. Савенков (FAMOUS FACES FACTORY), Красноярск, 1994 -------------------------------- Файл имеет заголовок: *.C start: 50612 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Размеры спрайта в знакоместах: │ │ │ │биты 0-3 - высота - X │ │ │ │биты 4-7 - ширина - Y │ │ 1 │X*Y*8│Спрайт, по линиям │ ├────────┼─────┼───────────────────────────────────────────────┤ │ X*Y*8+1│ │Следующий спрайт ... │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- SPRITE EDITOR v1.1, v2.1 by FDI, Москва, 1993 -------------------------------- CONVERTER v1.0 by ADS COMPANY -------------------------------- SPRITE TOOLS v2.0 (& v1.0 ???) by К. Афендиков и К. Виноградов, 1995 -------------------------------- Universal Sprites Studio v1.0 by Shov and Fantom Lord (Accept corp/Mafia), 1997 -------------------------------- Три последние программы могут записывать графику в формате первого редактора (v 1.1). Более поздняя версия (v 2.1) имееет усовершенствованый, но совместимый с первым формат. Файл имеет заголовок: *.G start:или 32765=#7FFD - v1.1 или 36861=#8FFD - v2.1 and SpriteTools или 49149=#BFFD - USSv1.0 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Биты 0-4 - ширина в знакоместах (1-11,24) - X │ │ │ │Начиная с версии 2.1: │ │ │ │бит 7 - маска перед спрайтом есть/нет (1/0) │ │ │ │бит 6 - атрибуты после спрайта есть/нет (1/0) │ │ 1 │ 1 │Высота в пикселах (1-128,192) - Y │ │ 2 │ 1 │Количество спрайтов - N │ │ 3 │ │Спрайты с масками и атрибутами, если есть │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- SPRITES GENERATOR V4.x & V5.x by REAL SOFTVARE 1997-1999 -------------------------------- Архивы спрайтов. Файл имеет заголовок: *.s start:38138 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Количество спрайтов - N │ │ 1 │ 3*N │Параметры спрайтов, по 3 байта на спрайт │ │ 1+3*N │ 4 │Свободны │ │ 5+3*N │ XXX │Спрайты │ └────────┴─────┴───────────────────────────────────────────────┘ Параметры спрайтов имеют следующий вид: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Ширина в знакоместах │ │ 1 │ 1 │Высота в знакоместах │ │ 2 │ 1 │Множитель (сколько байт на одно знакоместо) - │ │ │ │определитель формата. Вполне может │ │ │ │рассматриваться как комбинация битов 0,3,4: │ │ │ │бит 0 - атрибуты есть/нет (1/0) │ │ │ │бит 3 - прстой спрайт (1) │ │ │ │бит 4 - спрайт с маской (1) │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- Mega Sprites Generator-Editor v2.02 by Сергеев Дмитрий, Балаково, 1995 -------------------------------- В отличие от других редакторов, в данном - каждое знакоместо описывается со своими координатами относительно верхнего левого левого угла. Т. е., задавшись координатой верхнего левого угла, мы берем описатель каждого знакоместа, в котором записано смещение данного знакоместа относительно этого угла, и печатаем его, сместившись от этого угла вправо-вниз на указанные в описателе значения. Таким образом, можно будет пропустить пустые знакоместа и напечатать цветной спрайт произвольно заданной формы, а не прямоугольный. За детальными пояснениями рекомендую обратиться к книге "Как написать игру на ассемблере" издатель- ства "ПИТЕР". Файл имеет заголовок: *.C start:24500 Спрайты не разделены никакими маркерами, очевидно, их количество определяется по длине файла или по условию: если количество описателей знакомест равно нулю - то это уже конец файла. Структура спрайта: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Количество описателей знакомест - N │ │ 1 │ N*11│Описатели знакомест │ └────────┴─────┴───────────────────────────────────────────────┘ Структура описателя знакоместа: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 2 │Относительные координаты знакоместа │ │ 2 │ 1 │Атрибут знакоместа │ │ 3 │ 8 │Пикселы знакоместа │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- SCRAPS GENERATOR AND EDITOR v4.2 by Мухортов Д.В. и Иванищев Дм., Волгодонск, 1996 -------------------------------- Файл имеет заголовок: *.* start:51210 Спрайты не разделены никакими маркерами,очевидно,их количество определяется по длине файла. Структура спрайта: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Ширина в знакоместах - X │ │ 1 │ 1 │Высота в знакоместах - Y │ │ 3 │X*Y*8│Пикселы │ │3+X*Y*8 │ X*Y │Атрибуты │ └────────┴─────┴───────────────────────────────────────────────┘ При этом пикселы спрайта могут быть в одном из четырех форматов. Приведено расположение байтов спрайта. 1) Основной - рядами символов: ┌─────┬─────┐ │1 │9 │ │8 │16 │ ├─────┼─────┤ │17 │25 │ │24 │32 │ └─────┴─────┘ 2) Стандартно - по строчкам: ┌─────┬─────┐ │1 │2 │ │15 │16 │ ├─────┼─────┤ │17 │18 │ │31 │32 │ └─────┴─────┘ 3) По столбикам: ┌─────┬─────┐ │1 │17 │ │8 │24 │ ├─────┼─────┤ │9 │25 │ │16 │32 │ └─────┴─────┘ 4) В экранном формате: ┌─────┬─────┐ │1 │2 │ │29 │30 │ ├─────┼─────┤ │3 │4 │ │31 │32 │ └─────┴─────┘ -------------------------------- LASER BASIC by OASIS SOFTWARE -------------------------------- ROW SPRITE GENERATOR v1.0 by Олег Рукавишников Барнаул, 1995 -------------------------------- Файл имеет заголовок: *.C start+len=56575 или 56576 - сам Laser Basic. или *.C start+len=65536 - откомпилированные,для использования в стан─ дартном Basic. Печатающая процедура расположена в конце файла, а спрайты располагаются в начале файла. или *.Е start+len=65281 - файл редактора. Структура спрайта: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Номер спрайта (может быть не по порядку) │ │ 1 │ 2 │Адрес заголовка следующего спрайта │ │ 3 │ 1 │Ширина в знакоместах - X │ │ 4 │ 1 │Высота в знакоместах - Y │ │ 5 │X*Y*8│Сам спрайт с атрибутами │ └────────┴─────┴───────────────────────────────────────────────┘ Адрес указывается в расчете на то, что спрайт загружен по адресу, указанному в заголовке файла !!! -------------------------------- ART STUDIO 128 (v 2.01) by James Hutchby (Oxford Computer Publishing), 1985 Beta 128 adaptation by D. Koveos and IndSoft'91 -------------------------------- Файл имеет заголовок: *.C start: Не используется,вместо него - дополнительные 2 символа имени или псевдорасширения ".pad" Структура файла: Начинается как бы с конца,а начало его всегда на 49152. Самый последний байт файла (END) - количество спрайтов. Они идут в таком формате: линия атрибутов, 8 или менее (!) линий пикселов, и т. д. - атрибуты и 8 линий пикселов, а в конце спрайта - также атрибуты и 8 или менее (!) линий пикселов. Причем байты пикселов смещены от своего начального положения относительно атрибутов (чтобы спрайт занимал поменьше памяти), и перед печатью их надо бы сдвинуть. Смещение, а также количество самых верхних и, соот- ветственно, самых нижних линий пикселов высчитывается из извест- ных координат спрайта на экране в пикселах. ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ END-2 │ 1 │Младший и │ │ END-1 │ 1 │старший байты адреса │ │ │ │конца предыдущего спрайта + 1 = │ │ │ │адресу начала данного спрайта │ │ END-3 │ 1 │Высота в пикселах │ │ END-4 │ 1 │Ширина в пикселах │ │ END-5 │ 1 │Смещение по Y относительно верхнего левого угла│ │ END-6 │ 1 │Смещение по X относительно верхнего левого угла│ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- DOMEN OS PINK FLOYD Sprites editor. -------------------------------- Файл имеет заголовок: *.S (.SPR) Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Количество спрайтов - N │ │ 1 │ N*3 │Описатели спрайтов │ │ 1+N*3 │ xxx │Спрайты │ └────────┴─────┴───────────────────────────────────────────────┘ Структура описателя: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Символ (буква или цифра) - │ │ │ │идентификатор спрайта │ │ 1 │ 2 │Смещение до спрайта │ └────────┴─────┴───────────────────────────────────────────────┘ Структура спрайта: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 2 │Размеры в знакоместах - X и Y │ │ 2 │X*Y*8│Пикселы │ │2+X*Y*8 │ X*Y │Атрибуты │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- Spectum Guide v2.0 SGSpriteGenerator v1.0 Maximum/INTEGER in 1998 Формат ZIFF, первая версия -------------------------------- Универсальный формат обмена графической информации с возможно─ стью сделать текстовые комментарии к ней. Состоит из заголовка с типом информации в файле и одной или нескольких частей - HUNKов, содержащих графику или комментарий к нему. В первой версии есть только один тип информации - спрайты. Файл имеет заголовок: *.C start:#9000=36864 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ │ │ Заголовок │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 4 │Идентификатор: "ZIFF" │ │ 4 │ 2 │Длина всего файла минус четыре байта │ │ 6 │ 4 │Тип файла: "SPRT" │ ├────────┼─────┼───────────────────────────────────────────────┤ │ │ │ HUNK 1 (не обязателен) │ ├────────┼─────┼───────────────────────────────────────────────┤ │ n │ 4 │Идентификатор первого HUNKа: "AUTH" │ │ n+4 │ 2 │Его длина минус 4 байта │ │ n+6 │ m │Текстовая строка │ ├────────┼─────┼───────────────────────────────────────────────┤ │ │ │ HUNK 2 │ ├────────┼─────┼───────────────────────────────────────────────┤ │ n │ 4 │Идентификатор второго HUNKа: "DATA" │ │ n+4 │ 2 │Его длина минус 4 байта │ │ n+6 │ 1 │Длина в знакоместах │ │ n+7 │ 1 │Ширина в знакоместах │ │ n+8 │ 1 │#01 - версия │ │ n+9 │ m │Данные │ └────────┴─────┴───────────────────────────────────────────────┘ и так далее... Если далее нет HUNKов, то два нуля - они включены в длину файла. RLE упаковка - берем байт данных: 1) Если его старший бит сброшен, то далее идут несжатые данные, в количестве, содержащемся в младших шести битах взятого байта, плюс один. 2) Если его старший бит установлен,то идущий далее байт повто─ ряется в количестве, содержащемся в младших шести битах взятого байта, плюс один. -------------------------------- Universal Sprites Editor v1.2 by Феськов Кузьма (Студия КФ), Абакан, 1996 -------------------------------- Файл имеет заголовок: *.C Структура файла: Файл состоит из заголовка, таблицы смещений и самих спрайтов, с атрибутами или без. Тавлица смещений может быть отдельная (после заголовка) или сквозная (пара байт перед спрайтом являются указателем на следующий спрайт). В обоих случаях указатели могут быть индексные (указывать смещение) и фиксиро- ванные (указывать на спрайты, загруженные по конкретному адресу - параметру start у заголовка файла в каталоге). Несмотря на наличие соответствующего маркера, высота спрайта всегда указывается в пикселах. Количество строчек атрибутов получается делением на восемь, плюс добавляется еще одна строчка, если установлен хотя бы один из трех младших битов в байте, содержа- щем высоту спрайта. Структура заголовка: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 3 │Идентификатор - стринг "USE" │ │ 3 │ 1 │Флаги: │ │ │ │Бит 0 - высота в знакоместах/пикселях │ │ │ │Бит 1 - размеры спрайтов одинаковые/разные │ │ │ │Бит 2 - атрибуты есть/нет │ │ │ │Бит 3 - таблица отдельная/сквозная │ │ │ │Бит 4 - таблица индексная/фиксированная │ │ 4 │ 1 │Общее количество спрайтов │ │ 5 │ 1 │Высота │ │ 6 │ 1 │Длина │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- TEXT MAKER v1.10f by Delirium Tremens, 1999 -------------------------------- Файл имеет заголовок: *.$ start:49152 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Номер, начиная с 1 │ │ 1 │ 2 │Адрес следующего спрайта │ │ 3 │ 1 │Длина │ │ 4 │ 1 │Высота (в пикселах - всегда 8) │ │ 5 │ XXX │Спрайт с атрибутами │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- SPRITER by Z-Zero SYSTEM Inc. -------------------------------- Файл имеет заголовок: *.C start: 40960=#A000 - вырезалка или 49151=#BFFF - компилер или 38142 - маскер В последнем варианте байты маски и спрайта чередуются друг с другом. Структура спрайта: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Атрибуты есть/нет - #11/#C9 │ │ 1 │ 1 │Ширина │ │ 2 │ 1 │Высота в знакоместах │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- Myth OS Image LiBrary by GS/Myth corp., 07.08.2000 -------------------------------- Авторская информация. Файл имеет заголовок: *.ilb Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ N │Количество спрайтов в файле │ │ 1 │ 2*N │Таблица смещений спрайтов в файле │ │ 1+N*2 │ │Начало данных спрайтов │ └────────┴─────┴───────────────────────────────────────────────┘ Формат спрайта: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Ширина спрайта - X │ │ 1 │ 1 │Высота спрайта - Y │ │ 2 │ X*Y │Атрибуты спрайта │ │ 2+X*Y │ │Данные спрайта, построчно │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- Blade Sprite Designer v1.0 by Сусеков Алексей (R. Blade) SUMSI 27.01.99 -------------------------------- Авторская информация. Файл имеет заголовок: *.C start: 49152 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ N │Количество спрайтов в файле │ │ 1 │ 2*N │Таблица смещений спрайтов в файле │ │ 1+N*2 │ │Начало данных спрайтов │ └────────┴─────┴───────────────────────────────────────────────┘ Формат спрайта: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 1 │Ширина спрайта - X (18 max) │ │ 1 │ 1 │Высота спрайта - Y (13 max) │ │ 2 │X*Y*8│Данные спрайта, построчно │ │2+X*Y*8 │ X*Y │Атрибуты спрайта │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- Generator Sprayts by THD, Москва, 1992 -------------------------------- Файл имеет заголовок: *.C start: 54711 Структура файла: файл состоит из набора спрайтов с небольшим блоком кодов в начале каждого спрайта. Структура спрайта: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 24 │Кодовый блок, в нем: │ │ 17 │ 1 │Высота спрайта (знакомест) │ │ 20 │ 1 │Ширина спрайта (знакомест) │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- Sprites Editor v2.31 by Дмитрий Гультяев, 1995 -------------------------------- Файл имеет заголовок: *.K start: hi - Число спрайтов low - ??? Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ n*2 │ 512 │Смещение до n-го спрайта + #C000 = XXn │ │ XXn+0 │ 1 │Высота спрайта (знакомест) │ │ XXn+1 │ 1 │Ширина спрайта (знакомест) │ │ XXn+2 │ xx │Сам спрайт │ │ ... │... │... │ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- Sprite Maker v1.60 by FREE Group 1998 -------------------------------- Файл имеет заголовок: *.C start: hi - пауза в анимации + 32 low - биты 7-4 - высота (знакомест) биты 3-0 - ширина (знакомест) Структура файла: просто последовательность спрайтов, без атри─ бутов. -------------------------------- Spriter v1.0x by Capry/STALL, 1998-2000 -------------------------------- Информация непосредственно от авторов программы. 1) Файл с одним спрайтом, имеет заголовок: *.s start:0 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 15 │Строка "Made in Spriter" │ │ 15 │ 1 │Признак спрайта "s" │ │ 16 │ 7 │Имя спрайта: "sprname" │ │ 23 │ 1 │Высота в пикселях │ │ 24 │ 1 │Ширина в знакоместах │ │ 25 │ 1 │Опции: бит 0 - маска, бит 1 - атрибуты │ │ 26 │ 3 │Значения не имеют │ │ 29 │ 2 │Длина спрайта в байтах │ │ 31 │ 1 │0 - для центровки по границе 16 байт │ │ 32 │ LEN │Спрайт-маска-атрибуты, линейный формат │ └────────┴─────┴───────────────────────────────────────────────┘ 2) Группа спрайтов, файл имеет заголовок: *.g start: Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 15 │Строка: "Made in Spriter" │ │ 15 │ 1 │Признак группы: "g" │ │ 16 │ 7 │Имя спрайта: "grpname" │ │ 17 │ 1 │0 │ │ 18 │ 1 │Кол-во спрайтов в группе - N │ │ 19 │ 5 │0 │ │ 20 │ N │Анимационная последовательность │ │ 20+N │ XXX │Спрайты с заголовком, каждый имеет структуру, │ │ │ │как и у вышешеприведенного файла со спрайтом │ │ END │ 1 │#FF - конец файла │ └────────┴─────┴───────────────────────────────────────────────┘ 3) "Формат *.G файлов ужасен - это просто дамп памяти :), опи- сывать долго (и самому разбираться уже не охота)" Capry/STALL -------------------------------- FLN пакет v1.0 by Research/Volgasoft -------------------------------- Формат GRF файла. Авторская информация. Файл имеет заголовок: *.C start:#C000 Структура файла: ┌─────────┬─────┬──────────────────────────────────────────────┐ │Смещение │Длина│Назначение │ ├─────────┼─────┼──────────────────────────────────────────────┤ │ 0 │ 1 │N=всего спрайтов (от 1) │ │(i-1)*4+1│ 1 │Ширина в знакоместах i-го спрайта │ │(i-1)*4+2│ 1 │Высота в знакоместах i-го спрайта │ │(i-1)*4+3│ 2 │Адрес i-го спрайта │ │ N*4+1 │ XXX │Спрайты с атрибутами, в линейном формате │ └─────────┴─────┴──────────────────────────────────────────────┘ -------------------------------- Формат "*.smm", применяемый в X-DOS by Boh/Image Crew -------------------------------- Файл имеет заголовок: *.smm Структура файла: ┌─────────┬─────┬──────────────────────────────────────────────┐ │Смещение │Длина│Назначение │ ├─────────┼─────┼──────────────────────────────────────────────┤ │ 0 │ 1 │Неизвестно │ │ 1 │ 1 │Похоже, всегда 0 │ │ 2 │ 1 │Число спрайтов - 1 │ │ 3 │ 1 │Скорость анимации??? │ │ 4 │ 1 │ширина в знакоместах │ │ 5 │ 1 │высота в знакоместах │ │ 6 │ ххх │спрайты, в линейном формате │ └─────────┴─────┴──────────────────────────────────────────────┘ 22222222222222222222222222222222 Мультиколорные редакторы 22222222222222222222222222222222 Редакторы, позволяющие редактировать графику с цветовым разре─ шением более высоким, нежели стандартное: два цвета не на блок 8x8 пикселей, а блоками размером 1x8 или 2x8 пикселей. -------------------------------- MEGA SCREEN MULTICOLOR EDITOR v1.08 & v2.5 by Сергей Крутько (DREAMS SOFTWARE INC.) Distributed by MAGIC SOFT, 1994-1996 -------------------------------- Разные версии записывают файлы в разных форматах. 1) Версия 1.08, некомпилированый. Файл имеет заголовок: *.C start:16384 length:3072 lensec:12 Структура файла: В начале идет пиксельная составляющая - спрайт 16x12 знако- мест. Затем атрибуты, по байту на байт пикселов. Таким образом, цветовое разрешение составляет 1x8. 2) Версия 1.08, компилированый. Файл имеет заголовок: *.C start:58000 length:3325 Структура файла: В начале файла находится кодовый блок. Картинка начинается по смещению #EE от начала файла и имеет такой же формат. 3) Версия 2.5, некомпилированый. Файл имеет заголовок: *.P start:0 length:7168 Структура файла: В начале находится 256 байт заголовка. По смещению #00 - стринг "MEGA-SCREEN FILE". По смещению #60 - стринг: "MEGA-SCREEN MULTICOLOR EDITOR VERSION 2. AUTOR SERGEY "+ "KRUTYKO. IF YOU WANA THE BEST GRAPHICS EDITOR FOR SPECCY "+ "128 THEN LOAD MEGA-SCREEN VERSION 2 (OR 1 - SHIT V". Далее находятся пикселы - спрайт 24x24, а затем атрибуты - в два раза меньше,по одному байту на пару стоящих друг над другом бай─ тов пикселов. Таким образом, цветовое разрешение 2x8. 4) Версия 2.5, компилированый. Файл имеет заголовок: *.C start:* length:7168 Структура файла: Первые 256 байт - блок кодов и заголовок. По смещению #C9 - стринг " MEGASCREEN-2 COMPILER BY SERGEY KRUTYKO FROM D.S.Inc. " Далее идет картинка в таком же формате. -------------------------------- Multicolor Studio 1.208 PHANTOM LORD SOFT Армавир, 1996 -------------------------------- 1) Некомпилированный Файл имеет заголовок: *.$ start:35558 length:5120 Структура файла: Спрайт размером 26x16, далее - атрибуты по байту на пару байт пикселов, но они идут линиями по 28 байт на каждые 26 пар байтов пикселов,и по два байта в конце каждой атрибутной линии не испо─ льзуются. -------------------------------- SpeConvertor (for пц) Aprisobal Минск, 2003 -------------------------------- 8 color editor v0.12 Alone Coder/i8 Рязань, 2004 -------------------------------- 1) Мультиколор во весь экран. Файл имеет заголовок: *.mc length:12288 Экран (спрайтом), потом его атрибуты (спрайтом). 2) 2-экранный мультиколор во весь экран. Файл имеет заголовок: *.mcx length:24576 1-й экран (спрайтом), потом его атрибуты (спрайтом), потом 2-й экран (спрайтом), потом его атрибуты (спрайтом). 33333333333333333333333333333333 BMC - экраны 33333333333333333333333333333333 -------------------------------- ManyColors+ v1.0 a.k.a. X-COLOR by CREATOR, СПб, 1996? -------------------------------- Convert! v-2.0 by Volga Soft Production, СПб, 1997 -------------------------------- AGA v1.0 by J/CIC, Чайковский, 1998 -------------------------------- DBS v0.7 by Alone Coder, 2004 -------------------------------- Пишут и смотрят несколько видов файлов: 1) Файл имеет заголовок: *.Y start:#B800=47104 Три упакованные любым компрессором составляющме в виде экранов без атрибутов (R, G, B). 2) Файл имеет заголовок: *.### или *.# start:0 length:18432 lensec:#48 Структура файла: Три составляющме в виде экранов без атрибутов (R, G, B?). 3) Файл имеет заголовок: *.777 или *.7 start:0 length:18432 lensec:#48 Структура файла: Три составляющме в виде спрайтов 32x24 без атрибутов (R,G,B). 4) Файл имеет заголовок: *.3 start: length:18432 lensec:#48 Структура файла: Три составляющме в виде экранов без атрибутов (B, R, G). 5) Файл имеет заголовок: *.img length:13824 lensec:#36 Структура файла: Два экрана с атрибутами (экран, атрибуты, экран, атрибуты). 6) WSF (картинки для Wolf'2004: пакуемость выше, чем у .img). Файл имеет заголовок: *.С length:13824 lensec:#36 Структура файла: Два экрана с атрибутами (знакоместо 1-го экрана, знакоместо 2-го экрана, потом следующее слева направо знакоместо и т.д.,а в конце лежат атрибуты для 1-го экрана, потом для 2-го). -------------------------------- Con18 (for пц) Alone Coder/i8 Рязань, 2004 -------------------------------- Ecoimg (сокращённый img). Файл имеет заголовок: *.emg length:16384 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 6144│По столбцам лежат пиксельные составляющие двух │ │ │ │экранов: байт за 2 байта 1-го экрана,потом байт│ │ │ │за 2 байта 2-го экрана (байт за два кодируется │ │ │ │по таблице code256, декодируется по таблице │ │ │ │deco256 - файлы в приложении к Info Guide #7), │ │ │ │потом опять 1-го, потом опять 2-го и т.д. │ │ 6144 │ 1536│Атрибуты двух экранов, опять по столбцам, опять│ │ │ │чередующиеся: атрибут 1-го, атрибут 2-го и т.д.│ └────────┴─────┴───────────────────────────────────────────────┘ -------------------------------- Slide Show by Sage Group, Самара, 1998 -------------------------------- Файл имеет заголовок: *.3 start:49152 length:16384 lensec:#40 Структура файла: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 5376│Спрайт R-составляющей размером 32x21 │ │ 5376 │ 5376│Спрайт G-составляющей размером 32x21 │ │ 10752 │ 5376│Спрайт B-составляющей размером 32x21 │ │ 16128 │ 252│Текст к картинке │ │ 16380 │ 4 │Резерв │ └────────┴─────┴───────────────────────────────────────────────┘ Все три спрайта хранятся по третям в экранном виде, задом наперёд,в инверсном виде. Нижние две трети соотвествуют стандар- тным третям экрана, верхняя часть - тоже в экранном виде, байты ненужных знакомест просто пропускаются: т.е. по восемь раз пере─ брасываются 160 байт графики, и к полученному адресу добавляется -96. -------------------------------- MultiStudio v X.X by Disabler/Omega Hackers Group, Ростов-на-Дону, 1997 -------------------------------- Возможны два вида файла: 1) Непакованный Файл имеет заголовок: *.* length:12228 Структура файла: Три спрайта 32x16 - B, R и G составляющие. 2) Пакованный Файл имеет заголовок: *.p start:0 Структура файла: проще не разбираться, а использовать готовый распаковщик: --------------------------Cut >THERE<------------------------- ;DEPACKER FOR ;MULTICTUDIO 2.1 PRO ;FOR PACKED PICTURES "*.p" ;TO 3 -> B.R.G. SPRITES 32*16 - 12288 bytes ALL PAKPIC EQU #7700 ;PACKED PIC DEPPIC EQU #A700 ;DEPACKED PIC ORG #6986 LD HL,PAKPIC PUSH HL EXX POP DE LD B,0 EXX LD HL,DEPPIC LD D,6 DEP5 PUSH HL LD C,0 DEP1 PUSH HL LD B,8 DEP2 EXX LD A,B OR A JR NZ,DEP3 LD A,(DE) CP #9A INC DE JR NZ,DEP4 LD A,(DE) LD C,A INC DE LD A,(DE) LD B,A INC DE DEP3 DEC B LD A,C DEP4 EXX LD (HL),A INC H DJNZ DEP2 POP HL INC HL DEC C JR NZ,DEP1 POP HL LD BC,#0800 ADD HL,BC DEC D JR NZ,DEP5 LD HL,10072 EXX RET --------------------------Cut >THERE<------------------------- -------------------------------- 8 color editor v0.12 by Alone Coder/i8 Рязань, 2004 -------------------------------- Внимание! Для всех графических файлов, если длина в байтах не соответствует длине в секторах, 8col показывает "лишние" сектора как текст-примечание к картинке (конец текста - код #0). 1) Байт на точку. Файл имеет заголовок: *.C start:не важен length:12288 или другая нестандартная (формат только на заг- рузку, но не на выгрузку!) 8-цветный экран 128x96 или 128x(length/128): байты вида %00000grb. 2) Байт на 2 точки. Файл имеет заголовок: *.C start:32768 length:24576 8-цветный экран 256x192: байты вида %0grb0grb (grb левого пик- села, grb правого). 3) Байт на 2 точки (текстуры для Wolf'2004). Файл имеет заголовок: *.S start:0 length:16384 8-цветный экран 256x128: байты того же вида. 4) Упакованный .888. Файл имеет заголовок: *.888 length:длина плавающая Тело файла содержит данные о содержимом последовательно идущих знакомест 8x8 (слева направо, сверху вниз, 32 знакоместа по го- ризонтали и 24 по вертикали). Всего существует 8 цветов - по 2 градации на каждую цветовую составляющую: G, R, B. В теле файла перемешаны 2 потока: битовый и байтовый, аналогично формату hrust2.1 (см. AlCoNews#11). Битовый поток является упра- вляющим, первый байт файла принадлежит ему. Запись о каждом знакоместе состоит из полей: 3 бита - тип цветности (характеризует количество цветов) [опционально] - использованные цвета в порядке увеличения часто- ты (т.е. начиная с самых редких) [опционально] сколько-то бит или, возможно, 24 байта - пиксе- льные данные знакоместа в соответствии с его типом. Типы цветности: 0 - 8-цветное знакоместо, в байтовом потоке лежит 24 байта дан- ных,по 3 байта (в порядке R, G, B) на каждую пиксельную линию знакоместа. (Байтовый поток, кроме как здесь, больше нигде не используется.) Палитра отсутствует. 1 - используется последний использованый не 8-цветный тип цвет- ности, палитра также берётся старая. 2 - одноцветное знакоместо. В палитре один элемент, указывающий этот цвет. Элемент палитры занимает 3 бита: G, R, B. Пиксель- ные данные отсутствуют. 3 - двухцветное знакоместо. В пиксельных данных лежат пиксели слева направо, сверху вниз, по 1 биту на пиксель. 0 - наибо- лее частый пиксель (последний элемент палитры), 1 - наиболее редкий пиксель (первый элемент палитры). 4 - трёхцветное знакоместо. Цвета пикселей кодируются: 0, 10, 11 (в порядке убывания частоты, т.е. в порядке убывания номера в палитре). 5 - четырёхцветное знакоместо. Цвета пикселей кодируются: 00, 01, 10, 11 (в порядке убывания частоты). 6 - пятицветное знакоместо. Цвета пикселей кодируются: 00, 01, 10, 110, 111 (в порядке убывания частоты). 7 - шестицветное знакоместо. Цвета пикселей кодируются: 00, 01, 100, 101, 110, 111 (в порядке убывания частоты). Степень сжатия среднестатистической триколорины несколько силь- нее, чем у hrust2.1, при этом скорость сжатия многократно выше. Распаковщик: ;палитра не запоминается, если ;8 цветов ИЛИ используется старая палитра ;ЦВЕТА В ОБРАТНОМ ПОРЯДКЕ:начиная с редких FROM=#D000 TO=#8000 ORG #6000 TCOL_S ;DS 6 GO LD HL,FROM LD C,128 EXX LD HL,TO LD DE,125 LD C,1 DEP EXX CALL DEP3 CALL NZ,oldcl JR NZ,COLQQ LD B,8 COL80 LD E,(HL) ;R INC HL LD D,(HL) ;G INC HL ;(DE)=%0GRB0grb DUP 4 XOR A RL D RLA RL E RLA RLC (HL) RLA ADD A,A RL D RLA RL E RLA RLC (HL) RLA EXX LD (HL),A INC L EXX EDUP ORG $-2 ADD HL,DE EXX INC HL DJNZ COL80 COLQQ EXX LD A,H INC L,L,L,L JP PE,$+6 SUB 4 LD H,A RES 7,L CP 'TO+96 JP C,DEP CHL LD C,(HL) INC HL RL C RET oldcl LD D,'TCOL_S DEC A JR Z,COLOLD LD LX,A LD E,A DEPTAB CALL DEP3 DEC E LD (DE),A JR NZ,DEPTAB COLOLD LD A,LX LD B,64 CP 4 JR NC,COL45O DEC A JR Z,COL1 DEC A JR Z,COL2 ;2=11 ;1=10 ;0=0 COL3 LD A,#80 CALL DEPCOL0 JR Z,COL3N1 SLA C CALL Z,CHL RLA DEC A COL3N1 CALL PUTCOL DJNZ COL3 RET ;1=1 ;0=0 COL2 LD A,#80 CALL DEPCOL0 CALL PUTCOL DJNZ COL2 RET COL45O JR Z,COL4 RRA JR C,COL5 ;5=111 ;4=110 ;3=101 ;2=100 ;1=01 ;0=00 COL6 LD A,#40 CALL DEPCOL0 CP 2 JR C,COL6N1 DEC A SLA C CALL Z,CHL RLA COL6N1 CALL PUTCOL DJNZ COL6 RET ;4=111 ;3=110 ;2=10 ;1=01 ;0=00 COL5 LD A,#40 CALL DEPCOL0 CP 3 JR C,COL5N1 SLA C CALL Z,CHL RLA SUB 3 COL5N1 CALL PUTCOL DJNZ COL5 RET ;3=11 ;2=10 ;1=01 ;0=00 COL4 LD A,#40 CALL DEPCOL0 CALL PUTCOL DJNZ COL4 RET COL1 LD A,(DE) LD D,A RLCA RLCA RLCA RLCA OR D EXX LD B,8 COL10 LD (HL),A INC L LD (HL),A INC L LD (HL),A INC L LD (HL),A ADD HL,DE DJNZ COL10 EXX RET PUTCOL LD E,A LD A,(DE) EXX RLD LD A,C AND #2A JR Z,$+3 INC L RLC C JR NC,$+3 ADD HL,DE EXX RET DEP3 LD A,#20 DEPCOL0 SLA C CALL Z,CHL ADC A,A JR NC,DEPCOL0 RET 44444444444444444444444444444444 Шрифты и всякое такое 44444444444444444444444444444444 -------------------------------- Font 8x8 - и это не редактор -------------------------------- Для начала вспомним об обычных шрифтах. Файлы имеют заголовок: *.* или *.fnt или *.C start:не используется, заместо него - дополнительные 2 симво- ла имени или псевдорасширения ".fnt" length:168,768,2048 Стандартные UDG и фонты 21, 96 и 256 символов, по 8 байт на каждый. -------------------------------- "Экранный" font 8x8 -------------------------------- Файлы имеют заголовок: *.* length:2048 При содействии с Capry/STALL написано следующее: В фонте есть образы всех 256 символов, первый байт 0-го символа по смещению +#000 второй байт 0-го символа по смещению +#100 ... восьмой байт 0-го символа по смещению +#700 первый байт 1-го символа по смещению +1 первый байт 2-го символа по смещению +2 и т.д. Короче говоря, если напечатать все 256 символов в одной трети экрана (32х8), то дамп 2048 байт экранной памяти и будет "экранный" font 8x8, применяемый в быстрых процедурах печати. -------------------------------- FANTOM by (Алексей ???-Don't remember) -------------------------------- EDIT-16 Редактор шрифтов двойного размера. by Феськов Кузьма (Студия КФ), Абакан -------------------------------- Почти стандартом стал шрифт 2х2 знакоместа - 96 символов: Файл имеет заголовок: *fan.C или *.C length:3072 -------------------------------- Print FX v1.1 by Сергей Ханцис -------------------------------- Файл имеет заголовок: *.F start:#B000=45056 length:#1200=4608 lensec:#12=18 Структура файла: 192 символа по 24 байта на каждый,повернуты на 90 градусов по часовой стрелке и разделены на 2 части по 12 байт: сперва нижняя половинка, а потом - верхняя. -------------------------------- IS DOS PRINT by Shaitan -------------------------------- Файл имеет заголовок: *.gf.C start:0 length:#0A80=2688 lensec:#0B=11 Структура файла: 192 символа по 14 байт, повернуты на 90 градусов по часовой стрелке, каждый символ зеркально отображен относительно горизон─ та. 55555555555555555555555555555555 Картинки стандартного размера 55555555555555555555555555555555 -------------------------------- SCREEN$ - и это не редактор -------------------------------- Файл имеет заголовок: *.* или *.scr length:6912, 6144 lensec:27, 18 Стандартный дамп экранной памяти, с атрибутами или без. В пос- леднем случае экран может быть и в спрайтовом формате - строчка за строчкой, а не по третям. -------------------------------- Excess DE LUXE Paint v1.xxx,v2.x by ZK-SYSTEM/EXCESS TEAM, Казань, 1998-2001 -------------------------------- Файл имеет заголовок: *.edP или *.edp length:13824 lensec:#36=54 Двойной экран в спрайтовом формате,последовательно два спрайта 32х24 с атрибутами. -------------------------------- Gambit v2.2 - Шахматы by TRSOFT/DISCOVERY, СПб, 1998 -------------------------------- Файл имеет заголовок: *.h start:49152 length:1728 lensec:7 Шахматные фигуры 12 штук, вначале белые,потом черные,в формате сперва спрайт 3х3, потом маска, и т.д. Файл имеет заголовок: *.p start:49152 length:4608 lensec:12 Шахматная доска - спрайт 24х24. Немного истории... 27.03.2000 - первая версия в формате 32 символа в строке, рассчитаная на публикацию в журнале Virtual Worlds, но он все не выходил, а редакторов находилось все больше, поэтому текст преобразовался в доку со свободным распространением. Всего 18 форматов. 27.05.2000 - Переход на формат 64 символа в строке, мелкие коррекции и исправления, до бавлено описание редактора спрайтов USE, USS, TM v1.10, SPRITER (by Z-Zero), раздел шрифтов и карти- нок стандартного размера. Всего 27 форматов. Благодарности. Хочется поблагодарить следующих людей, оказавших помощь в добыче графических редакторов: Melted Snow MMA (егошний CD) ZX-Pilot creators/Proxima Ice'Di^Triumph Capry/STALL - описание формата своего собственного редактора Boh/Image Crew Всем другим авторам редакторов, кто не поленился написать подобный хелп. С целью апгрейда данного справочника обращайтесь к распрост─ ранителям или по адресу: 606015, Нижегородская обл. г. Дзержинск пр. Ленина д.6 кв.8 Полякову А. Естественно, апгрейдеры будут тут упомянуты. Можно такое дело делать и по музакам, архивам и пр. NUTS Дзержинск 26.10.2001 Alone Coder Рязань 08.06.2005 \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/888 b/Docs/FORMATS/info_guide/888 new file mode 100644 index 0000000..d1703da --- /dev/null +++ b/Docs/FORMATS/info_guide/888 @@ -0,0 +1,246 @@ + + ╘юЁьрЄ єяръютрээюую ЄЁшъюыюЁр .888 + +╘рщы√ фрээюую ЇюЁьрЄр сєфєЄ ухэхЁшЁютрЄ№ё  ЁхфръЄюЁюь 8col, эр- +ўшэр  ё тхЁёшш v0. ╨рчєьххЄё , яюффхЁцър тёхї ёЄрЁ√ї ЇюЁьрЄют +юёЄрэхЄё , ъръ эр ўЄхэшх, Єръ ш эр чряшё№. + +╟руюыютюъ юЄёєЄёЄтєхЄ! +╥хыю Їрщыр ёюфхЁцшЄ фрээ√х ю ёюфхЁцшьюь яюёыхфютрЄхы№эю шфє∙шї +чэръюьхёЄ 8x8 (ёыхтр эряЁртю, ётхЁїє тэшч, 32 чэръюьхёЄр яю ую- +ЁшчюэЄрыш ш 24 яю тхЁЄшърыш). ┬ёхую ёє∙хёЄтєхЄ 8 ЎтхЄют - яю 2 +уЁрфрЎшш эр ърцфє■ ЎтхЄютє■ ёюёЄрты ■∙є■: G, R, B. + +┬ Єхых Їрщыр яхЁхьх°рэ√ 2 яюЄюър: сшЄют√щ ш срщЄют√щ, рэрыюушўэю +ЇюЁьрЄє hrust2.1 (ёь. AlCoNews#11). ┴шЄют√щ яюЄюъ  ты хЄё  єяЁр- +ты ■∙шь, яхЁт√щ срщЄ Їрщыр яЁшэрфыхцшЄ хьє. + +╟ряшё№ ю ърцфюь чэръюьхёЄх ёюёЄюшЄ шч яюыхщ: +3 сшЄр - Єшя ЎтхЄэюёЄш (їрЁръЄхЁшчєхЄ ъюышўхёЄтю ЎтхЄют) +[юяЎшюэры№эю] - шёяюы№чютрээ√х ЎтхЄр т яюЁ фъх єтхышўхэш  ўрёЄю- + Є√ (Є.х. эрўшэр  ё ёрь√ї Ёхфъшї) +[юяЎшюэры№эю] ёъюы№ъю-Єю сшЄ шыш, тючьюцэю, 24 срщЄр - яшъёх- + ы№э√х фрээ√х чэръюьхёЄр т ёююЄтхЄёЄтшш ё хую Єшяюь. + +╥шя√ ЎтхЄэюёЄш: +0 - 8-ЎтхЄэюх чэръюьхёЄю, т срщЄютюь яюЄюъх ыхцшЄ 24 срщЄр фрэ- + э√ї,яю 3 срщЄр (т яюЁ фъх R, G, B) эр ърцфє■ яшъёхы№эє■ ышэш■ + чэръюьхёЄр. (┴рщЄют√щ яюЄюъ, ъЁюьх ъръ чфхё№, сюы№°х эшуфх эх + шёяюы№чєхЄё .) ╧рышЄЁр юЄёєЄёЄтєхЄ. +1 - шёяюы№чєхЄё  яюёыхфэшщ шёяюы№чютрэ√щ эх 8-ЎтхЄэ√щ Єшя ЎтхЄ- + эюёЄш, ярышЄЁр Єръцх схЁ╕Єё  ёЄрЁр . +2 - юфэюЎтхЄэюх чэръюьхёЄю. ┬ ярышЄЁх юфшэ ¤ыхьхэЄ, єърч√тр■∙шщ + ¤ЄюЄ ЎтхЄ. ▌ыхьхэЄ ярышЄЁ√ чрэшьрхЄ 3 сшЄр: G, R, B. ╧шъёхы№- + э√х фрээ√х юЄёєЄёЄтє■Є. +3 - фтєїЎтхЄэюх чэръюьхёЄю. ┬ яшъёхы№э√ї фрээ√ї ыхцрЄ яшъёхыш + ёыхтр эряЁртю, ётхЁїє тэшч, яю 1 сшЄє эр яшъёхы№. 0 - эршсю- + ыхх ўрёЄ√щ яшъёхы№ (яюёыхфэшщ ¤ыхьхэЄ ярышЄЁ√), 1 - эршсюыхх + Ёхфъшщ яшъёхы№ (яхЁт√щ ¤ыхьхэЄ ярышЄЁ√). +4 - ЄЁ╕їЎтхЄэюх чэръюьхёЄю. ╓тхЄр яшъёхыхщ ъюфшЁє■Єё : 0, 10, 11 + (т яюЁ фъх єс√трэш  ўрёЄюЄ√, Є.х. т яюЁ фъх єс√трэш  эюьхЁр т + ярышЄЁх). +5 - ўхЄ√Ё╕їЎтхЄэюх чэръюьхёЄю. ╓тхЄр яшъёхыхщ ъюфшЁє■Єё : 00, + 01, 10, 11 (т яюЁ фъх єс√трэш  ўрёЄюЄ√). +6 - я ЄшЎтхЄэюх чэръюьхёЄю. ╓тхЄр яшъёхыхщ ъюфшЁє■Єё : 00, 01, + 10, 110, 111 (т яюЁ фъх єс√трэш  ўрёЄюЄ√). +7 - °хёЄшЎтхЄэюх чэръюьхёЄю. ╓тхЄр яшъёхыхщ ъюфшЁє■Єё : 00, 01, + 100, 101, 110, 111 (т яюЁ фъх єс√трэш  ўрёЄюЄ√). + +╤Єхяхэ№ ёцрЄш  ёЁхфэхёЄрЄшёЄшўхёъющ ЄЁшъюыюЁшэ√ эхёъюы№ъю ёшы№- +эхх, ўхь є hrust2.1, яЁш ¤Єюь ёъюЁюёЄ№ ёцрЄш  ьэюуюъЁрЄэю т√°х. + +╨рёяръют∙шъ: + +;ярышЄЁр эх чряюьшэрхЄё , хёыш +;8 ЎтхЄют ╚╦╚ шёяюы№чєхЄё  ёЄрЁр  ярышЄЁр + +;╓┬┼╥└ ┬ ╬┴╨└╥═╬╠ ╧╬╨▀─╩┼:эрўшэр  ё Ёхфъшї + +FROM=#D000 +TO=#8000 + ORG #6000 +TCOL_S ;DS 6 +GO + LD HL,FROM + LD C,128 + EXX + LD HL,TO + LD DE,125 + LD C,1 +DEP EXX + CALL DEP3 + CALL NZ,oldcl + JR NZ,COLQQ + LD B,8 +COL80 LD E,(HL) ;R + INC HL + LD D,(HL) ;G + INC HL +;(DE)=%0GRB0grb + DUP 4 + XOR A + RL D + RLA + RL E + RLA + RLC (HL) + RLA + ADD A,A + RL D + RLA + RL E + RLA + RLC (HL) + RLA + EXX + LD (HL),A + INC L + EXX + EDUP + ORG $-2 + ADD HL,DE + EXX + INC HL + DJNZ COL80 +COLQQ EXX + LD A,H + INC L,L,L,L + JP PE,$+6 + SUB 4 + LD H,A + RES 7,L + CP 'TO+96 + JP C,DEP +CHL LD C,(HL) + INC HL + RL C + RET + +oldcl LD D,'TCOL_S + DEC A + JR Z,COLOLD + LD LX,A + LD E,A +DEPTAB CALL DEP3 + DEC E + LD (DE),A + JR NZ,DEPTAB +COLOLD LD A,LX + LD B,64 + CP 4 + JR NC,COL45O + DEC A + JR Z,COL1 + DEC A + JR Z,COL2 +;2=11 +;1=10 +;0=0 +COL3 + LD A,#80 + CALL DEPCOL0 + JR Z,COL3N1 + SLA C + CALL Z,CHL + RLA + DEC A +COL3N1 CALL PUTCOL + DJNZ COL3 + RET +;1=1 +;0=0 +COL2 + LD A,#80 + CALL DEPCOL0 + CALL PUTCOL + DJNZ COL2 + RET +COL45O + JR Z,COL4 + RRA + JR C,COL5 +;5=111 +;4=110 +;3=101 +;2=100 +;1=01 +;0=00 +COL6 LD A,#40 + CALL DEPCOL0 + CP 2 + JR C,COL6N1 + DEC A + SLA C + CALL Z,CHL + RLA +COL6N1 CALL PUTCOL + DJNZ COL6 + RET +;4=111 +;3=110 +;2=10 +;1=01 +;0=00 +COL5 LD A,#40 + CALL DEPCOL0 + CP 3 + JR C,COL5N1 + SLA C + CALL Z,CHL + RLA + SUB 3 +COL5N1 CALL PUTCOL + DJNZ COL5 + RET +;3=11 +;2=10 +;1=01 +;0=00 +COL4 + LD A,#40 + CALL DEPCOL0 + CALL PUTCOL + DJNZ COL4 + RET +COL1 + LD A,(DE) + LD D,A + RLCA + RLCA + RLCA + RLCA + OR D + EXX + LD B,8 +COL10 LD (HL),A + INC L + LD (HL),A + INC L + LD (HL),A + INC L + LD (HL),A + ADD HL,DE + DJNZ COL10 + EXX + RET + +PUTCOL LD E,A + LD A,(DE) + EXX + RLD + LD A,C + AND #2A + JR Z,$+3 + INC L + RLC C + JR NC,$+3 + ADD HL,DE + EXX + RET +DEP3 + LD A,#20 +DEPCOL0 SLA C + CALL Z,CHL + ADC A,A + JR NC,DEPCOL0 + RET diff --git a/Docs/FORMATS/info_guide/ARITHM.$W! b/Docs/FORMATS/info_guide/ARITHM.$W! new file mode 100644 index 0000000..6c1c58a --- /dev/null +++ b/Docs/FORMATS/info_guide/ARITHM.$W! @@ -0,0 +1 @@ + Арифметическое кодирование www.codenet.ru, автор неизвестен. Публикуется с сокращениями.  Идея арифметического кодирования.  Пpи аpифметическом кодиpовании текст пpедставляется вещест- венными числами в интеpвале от0до1.По меpе кодиpования текс- та отобpажающий его интеpвал уменьшается, а количество битов для его пpедставления возpастает. Очеpедные символы текста сокpащают величину интеpвала исходя из значений их веpоятностей,опpеделяе- мх моделью.Более веpоятные символы делают это в меньшей степени, чем менее веpоятные, и, следовательно, добавляют меньше битов к pезультату. Пеpед началом pаботы соответствующий тексту интеpвал есть [0;1).Пpи обpаботке очеpедного символа его шиpина сужается за счёт выделения этому символу части интеpвала. Hапpимеp, пpименим к тексту "eaii!"алфавита{ a,e,i,o,u,! }модель с постоянными веpоятностями (ширина интервала равна вероятности символа):  "a" [0.0;0.2);  "e" [0.2;0.5);  "i" [0.5;0.6);  "o" [0.6;0.8);  "u" [0.8;0.9);  "!" [0.9;1.0). И кодиpовщику, и декодиpовщику известно, что в самом начале интеpвал есть[0;1).После пpосмотpа пеpвого символа"e"кодиpо- вщик сужает интеpвал до[0.2;0.5),котоpый модель выделяет этому символу. Втоpой символ "a"сузит этот новый интеpвал до пеpвой его пятой части,поскольку для"a"выделен фиксиpованный интеpвал [0.0;0.2).В pезультате получим pабочий интеpвал[0.2;0.26), т.к. пpедыдущий интеpвал имел шиpину в0.3единицы, и одна пятая от него есть0.06.Следующему символу"i"соответствует фиксиpо- ванный интеpвал[0.5;0.6),что пpименительно к pабочему интеpва- лу [0.2;0.26)суживает его до интеpвала[0.23;0.236).Пpодолжая в том же духе, имеем:  В начале [0.0; 1.0 )  После пpосмотpа "e" [0.2; 0.5 )  -"-"-"- "a" [0.2; 0.26 )  -"-"-"- "i" [0.23; 0.236 )  -"-"-"- "i" [0.233; 0.2336)  -"-"-"- "!" [0.23354; 0.2336) Пpедположим, что всё, что декодиpовщик знает о тексте - это конечный интеpвал [0.23354;0.2336).Он сpазу же понимает, что пеpвый закодиpованный символ есть"e",т.к. итоговый интеpвал целиком лежит в интеpвале, выделенном моделью этому символу сог- ласно первой таблице. Тепеpь повтоpим действия кодиpовщика:  Сначала [0.0; 1.0)  После пpосмотpа "e" [0.2; 0.5) Отсюда ясно,что втоpой символ - это"a",поскольку это пpиве- дёт к интеpвалу[0.2;0.26),котоpый полностью вмещает итоговый интеpвал [0.23354;0.2336).Пpодолжая pаботать таким же обpазом, декодиpовщик извлечёт весь текст. Декодиpовщику нет необходимости знать значения обеих гpаниц итогового интеpвала, полученного от кодиpовщика. Даже единствен- ного значения,лежащего внутpи него,напpимеp,0.23355,уже доста- точно. (Дpугие числа -0.23354, 0.23357 или даже0.23354321- вполне годятся). Пяти десятичных цифp, кажется, слишком много для кодиpования текста из4гласных. Однако ясно, что pазные модели дают pазную энтpопию.Лучшая модель,построенная на анализе отдельных символов текста"eaii!",есть следующее множество частот символов:  { "e"(0.2), "a"(0.2), "i"(0.4), "!"(0.2) }. Программа для арифметического кодирования. Показан фpагмент псевдокода, объединяющего пpоцедуpы кодиpо- вания и декодиpования. Символы в нём нумеpуются как1, 2, 3... Частотный интеpвал дляi-госимвола задается отcum_freq[i]до cum_freq[i-1].Пpи убывании i cum_freq[i]возpастает так, что cum_freq[0] = 1.(Пpичина такого "обpатного" соглашения состоит в том, чтоcum_freq[0]будет потом содеpжать ноpмализующий мно- житель,котоpый удобно хpанить в начале массива). Текущий pабочий интеpвал задается в [low; high] и будет в самом начале pавен [0; 1)и для кодиpовщика, и для pаскодиpовщика. К сожалению, этот псевдокод очень упpощен, тогда как на пpак- тике существует несколько фактоpов, осложняющих и кодиpование, и декодиpование. // АЛГОРИТМ АРИФМЕТИЧЕСКОГО КОДИРОВАHИЯ // С каждым симв. текста обpащаться к пpоцедуpе encode_symbol() // Пpовеpить, что "завеpшающий" символ закодиpован последним // Вывести полученное значение интеpвала [low; high)  encode_symbol(symbol,cum_freq)  range = high - low  high = low + range*cum_freq[symbol-1]  low = low + range*cum_freq[symbol] // АЛГОРИТМ АРИФМЕТИЧЕСКОГО ДЕКОДИРОВАHИЯ // Value - это поступившее на вход число // Обpащение к пpоцедуpе decode_symbol(), пока она не возвpатит // "завеpшающий" символ  decode_symbol(cum_freq)  поиск такого символа, что  cum_freq[symbol]<=(value-low)/(high-low)= Half) {  output_bit(1);  low = 2 * (low - Half);  high = 2 * (high - Half) + 1;  }  else break;  } Пpиpащаемый ввод исходных данных выполняется с помощью чи- сла, названного value.Обpаботанные биты пеpемещаются в веpх- нюю часть, а заново получаемые поступают в нижнюю. Вначале start_decoding()заполняетvalueполученными битами. После опpе- деления следующего входного символа пpоцедуpойdecode_symbol() пpоисходит вынос ненужных, одинаковых вlowи вhigh,битов ста- pшего поpядка сдвигомvalueна это количество pазpядов (выведен- ные биты восполняются введением новых с нижнего конца).  for (;;) {  if (high < Half) {  value = 2 * value + input_bit();  low = 2 * low;  high = 2 * high + 1;  }  else if (low > Half) {  value = 2 * (value - Half) + input_bit();  low = 2 * (low - Half);  high = 2 * (high - Half) + 1;  }  else break;  } Доказательство декодиpующего неpавенства. Пусть"[]"обозначает опеpацию взятия целой части - деление с отбpасыванием дpобной части. Полагаем:  (value-low+1)*cum_freq[0]-1 cum_freq[symbol] <= [ ─────────────────────────── ] <  high-low+1  < cum_freq[symbol-1], Другими словами:  (value-low+1)*cum_freq[0]-1 cum_freq[symbol] <= [ ─────────────────────────── ] < (1)  range  < cum_freq[symbol-1],  range - 1 гдеrange = high - low + 1, 0 <= e <= ─────────.  range (Последнее неpавенство выpажения(1)пpоисходит из факта, что cum_freq[symbol-1]должно быть целым). Затем мы хотим показать, что low' <= value <= high',где low'иhigh'есть обновлённые значения дляlowиhigh,как опpеделено ниже.  range*cum_freq[symbol] (a)low' * low + [ ────────────────────── ] <=  cum_freq[0]  range (value-low+1)*cum_freq[0]-1  <= low + ─────────── [ ─────────────────────────── - e ]  cum_freq[0] range  1 из выражения(1)имеем:<= value + 1 - ───────────,  cum_freq[0] поэтомуlow'<=value,т.к.иvalue,иlow',иcum_freq[0] > 0.  range*cum_freq[symbol-1] (a)high' * low + [ ──────────────────────── ] - 1 >=  cum_freq[0]  range (value-low+1)*cum_freq[0]-1 >= low + ─────────── [ ─────────────────────────── + 1 - e] - 1  cum_freq[0] range из выражения(1)имеем:  range 1 range-1 >= value + ─────────── [- ───── + 1 - ─────── ] = value.  cum_freq[0] range range Отpицательное пеpеполнение. Как показано в псевдокоде,аpифметическое кодиpование pаботает пpи помощи масштабиpования накопленных веpоятностей,поставляемых моделью в интеpвале[low;high]для каждого пеpедаваемого симво- ла. Пpедположим,чтоlowиhighнастолько близки дpуг к дpугу,что опеpация масштабиpования пpиводит полученные от модели pазные символы к одному целому числу, входящему в[low;high].В этом случае дальнейшее кодиpование пpодолжать невозможно. Следовате- льно,кодиpовщик должен следить за тем, чтобы интеpвал[low;high] всегда был достаточно шиpок. Пpостейшим способом для этого явля- ется обеспечение шиpины интеpвала не меньшейMax_frequency- ма- ксимального значения суммы всех накапливаемых частот. Как можно сделать это условие менее стpогим? Объясненная выше опеpация битового сдвига гаpантиpует,чтоlowиhighмогут только тогда становиться опасно близкими, когда заключают между собой Half.Пpедположим, они становятся настолько близки, что  First_qtr <= low <= Half <= high < Third_qtr. (*) Тогда следующие два бита вывода будут иметь взаимообpатные значения:01или10.Hапpимеp, если следующий бит будет нулём (т.е.high опускается нижеHalf,и[0;Half]становится pабочим интеpвалом), а следующий за ним - единицей, т.к. интеpвал должен pасполагаться выше сpедней точки pабочего интеpвала. Hаобоpот, если следующий бит оказался1,то за ним будет следовать0.Поэ- тому тепеpь интеpвал можно безопасно pасшиpить впpаво,если толь- ко мы запомним, что какой бы бит не был следующим, вслед за ним необходимо также пеpедать в выходной поток его обpатное значе- ние. Программа пpеобpазует[First_qtr;Third_qtr]в целый интеp- вал, запоминая в bits_to_follow значение бита, за котоpым надо посылать обpатный ему. Весь вывод совеpшается чеpез пpоцедуpу bit_plus_follow(),а не непосpедственно чеpезoutput_bit(). Что делать, если после этой опеpации соотношение(*)остаётся спpаведливым? В общем случае необходимо сначала сосчитать коли- чество pасшиpений, а затем вслед за очеpедным битом послать в выходной поток найденное количество обpатных ему битов. Следуя этим pекомендациям, кодиpовщик гаpантиpует, что после опеpаций сдвига будет или  low < First_qtr < Half <= high, (1a) или  low < Half < Third_qtr <= high. (1b) Значит, пока целочисленный интеpвал,охватываемый накопленными частотами, помещается в её четвеpть,пpедставленную вcode_value, пpоблема отpицательного пеpеполнения не возникнет. Это соответс- твует условию:  Top_value + 1  Max_frequency <= ───────────── + 1,  4 котоpое удовлетвоpяется в пpогpамме,т.к.Max_frequency=2^14-1 иTop_value=2^16-1.Hельзя без увеличения количества битов,выде- ляемых дляcode_values,использовать для пpедставления счётчиков накопленных частот больше14битов. Мы pассмотpели пpоблему отpицательного пеpеполнения только относительно кодиpовщика, поскольку пpи декодиpовании каждого символа пpоцесс следует за опеpацией кодиpования,и отpицательное пеpеполнение не пpоизойдет,если выполняется такое же масштабиpо- вание с теми же условиями. Пеpеполнение. Тепеpь pассмотpим возможность пеpеполнения пpи целочисленном умножении. Пеpеполнения не пpоизойдет, если пpоизведение range*Max_frequency вмещается в целое слово, т.к. накопленные частоты не могут пpевышатьMax_frequency. Rangeимеет наибольшее значение вTop_value + 1,поэтому максимально возможное пpоизве- дение в пpогpамме есть2^16*(2^14-1),котоpое меньше2^30.Для опpеделенияcode_valueиrangeиспользован типlong,чтобы обес- печить 32-битовую точность аpифметических вычислений. Фиксиpованные модели. Пpостейшей моделью является та, в котоpой частоты символов постоянны.Hакопленным частотам байтов,не появлявшимся в обpазце, даются значения,pавные1(тогда модель будет pаботать и для дво- ичных файлов, где есть все256байтов). Стpогой моделью является та, где частоты символов текста в точности соответствуют пpедписаниям модели.Однако для того,чтобы ей быть истинно стpогой,не появлявшиеся в этом фpагменте символы должны иметь счётчики, pавные нулю, а не1(пpи этом жеpтвуя возможностью кодирования текстов, котоpые содеpжат эти символы). Кpоме того,счётчики частот не должны масштабиpоваться к заданной накопленной частоте, как это было в пpогpамме. Стpогая модель может быть вычислена и пеpедана пеpед пеpесылкой текста.Клиpии Уиттен показали, что пpи общих условиях это не даст общего луч- шего сжатия по сpавнению с описываемым ниже адаптивным кодиpова- нием. Адаптивная модель. Она изменяет частоты уже найденных в тексте символов. Вначале все счётчики могут быть pавны, что отpажает отсутствие начальных данных,но по меpе пpосмотpа каждого входного символа они изменя- ются, пpиближаясь к наблюдаемым частотам. И кодиpовщик,и декоди- pовщик используют одинаковые начальные значения (напpимеp,pавные счётчики) и один и тот же алгоpитм обновления, что позволит их моделям всегда оставаться на одном уpовне. Кодиpовщик получает очеpедной символ, кодиpует его и изменяет модель. Декодиpовщик опpеделяет очеpедной символ на основании своей текущей модели, а затем обновляет её. Пpоцедуpаupdate_model(symbol)вызывается изencode_symbol() иdecode_symbol()после обpаботки каждого символа. Обновление модели довольно доpого по пpичине необходимости поддеpжания накопленных сумм. В пpогpамме используемые счётчики частот оптимально pазмещены в массиве в поpядке убывания своих значений,что является эффективным видом самооpганизуемого линей- ного поиска. Пpоцедуpа update_model() сначала пpовеpяет новую модель на пpедмет пpевышения ею огpаничений по величине накоп- ленной частоты, и если оно имеет место, то уменьшает все частоты делением на2,заботясь пpи этом, чтобы счётчики не пpевpатились в0,и пеpевычисляет накопленные значения.Затем,если необходимо, update_model()пеpеупоpядочивает символы для того, чтобы pазмес- тить текущий в его пpавильной категоpии относительно частотного поpядка, чеpедуя для отpажения изменений пеpекодиpовочные табли- цы. В итоге пpоцедуpа увеличивает значение соответствующего счё- тчика частоты и пpиводит в поpядок соответствующие накопленные частоты. Эффективность сжатия. Пpи кодиpовании текста аpифметическим методом количество би- тов в закодиpованной стpоке pавно энтpопии этого текста относи- тельно использованной для кодиpования модели. Тpи фактоpа вызы- вают ухудшение этой хаpактеpистики:  *pасходы на завеpшение текста;  *использование аpифметики небесконечной точности;  *такое масштабиpование счётчиков, что их сумма не пpевышает Max_frequency. Как было показано, ни один из них не значителен. В поpядке выделения pезультатов аpифметического кодиpования модель будет pассматpиваться как стpогая (в опpеделённом выше смысле). Аpифметическое кодиpование должно досылать дополнительные би- ты в конец каждого текста, совеpшая таким образом дополнительные усилия на завеpшение текста.Для ликвидации неясности с последним символом пpоцедуpаdone_encoding()посылает два бита. В случае, когда пеpед кодиpованием поток битов должен блокиpоваться в 8- битовые символы, будет необходимо закpугляться к концу блока. Такое комбиниpование может дополнительно потpебовать9битов. Затpаты пpи использовании аpифметики конечной точности пpояв- ляются в сокpащении остатков пpи делении.Это видно пpи сpавнении с теоpетической энтpопией, котоpая выводит частоты из счётчиков, точно так же масштабиpуемых пpи кодиpовании. Здесь затpаты нез- начительны - поpядка10^-4битов/символ. Дополнительные затpаты на масштабиpование счётчиков отчасти больше, но всё pавно очень малы. Для коpотких текстов (меньших 2^14байт) их нет. Hо даже с текстами в10^5-10^6байтов нак- ладные pасходы, подсчитанные экспеpиментально, составляют менее 0.25%от кодиpуемой стpоки. Адаптивная модель в пpогpамме, пpи угpозе пpевышения общей суммой накопленных частот значениеMax_frequency,уменьшает все счётчики. Это пpиводит к тому, что взвешивать последние события тяжелее,чем более pанние. Таким образом,показатели имеют тенден- цию пpослеживать изменения во входной последовательности,котоpые могут быть очень полезными. (Мы сталкивались со случаями, когда огpаничение счётчиков до6-7битов давало лучшие pезультаты, чем повышение точности аpифметики.) Конечно, это зависит от источни- ка, к котоpому пpименяется модель. Огpаниченность pеализации. Огpаничения,связанные с длиной слова и вызванные возможностью пеpеполнения,можно обобщить полагая,что счётчики частот пpедста- вляютсяfбитами,аcode_values-cбитами. Пpогpамма будет pабо- тать коppектно пpиf<=c-2иf+c<=p,гдеpесть точность арифме- тики. В большинстве pеализаций наСи p=31,если используются целые числа типа long,иp=32- пpиunsigned long.В нашей пpогpамме f=14иc=16.Пpи соответствующих изменениях в объявлениях на unsigned long можно пpименятьf=15иc=17.Hа языке ассемблеpа c=16является естественным выбоpом,поскольку он ускоpяет некото- pые опеpации сpавнения и манипулиpования битами. Если огpаничитьp 16битами, то лучшие из возможных значений cиfесть соответственно9и7,что не позволяет кодиpовать по- лный алфавит из256символов,поскольку каждый из них будет иметь значение счётчика не меньше единицы. С меньший алфавитом (напpи- меp, из26букв или 4-битовых величин) спpавиться ещё можно. Завеpшение. Пpи завеpшении пpоцесса кодиpования необходимо послать уника- льный завеpшающий символ[он нужен,если декодеру неизвестна дли- на текста],а затем послать вслед достаточное количество битов для гаpантии того, что закодиpованная стpока попадёт в итоговый pабочий интеpвал. Т.к. пpоцедуpа done_encoding()может быть увеpена, чтоlowи highогpаничены либо выpажением(1a),либо(1b),ей нужно только пеpедать01или10соответственно, для удаления оставшейся неоп- pеделенности. Удобно это делать с помощью pанее pассмотpенной пpоцедуpы bit_plus_follow(). Пpоцедуpа input_bit() на самом деле будет читать немного больше битов, из тех, что вывела output_bit(),потому что ей нужно сохpанять заполнение нижнего конца буфеpа. Hе важно, какое значение имеют эти биты, поскольку EOFуникально опpеделяется последними пеpеданными битами.  Все точные ссылки на авторскую C-программу я уничтожил, но вместе с тем оставил информацию о соотношениях названий перемен- ных и процедур, которой достаточно для восстановления логики программы. Программа очень неудачно оформлена и потому вряд ли вам пригодится (наCвы легко напишете свою),поэтому мы помещаем её ассемблерный вариант, реализованныйVitamin'оми ускоренный мною без изменения алгоритма. Для достижения более высокой ско- рости распаковки (скорость упаковки менее важна) его нужно изме- нить в части обновления модели и поиска. Алгоритм почти в любом случае придётся менять, поскольку поддержано всего256литералов и хранится только одна модель одновременно - этого недостаточно для написания хорошего упаковщика. См.ARIF16m.Hв приложении. \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/MOA_FS.$W! b/Docs/FORMATS/info_guide/MOA_FS.$W! new file mode 100644 index 0000000..7342a17 --- /dev/null +++ b/Docs/FORMATS/info_guide/MOA_FS.$W! @@ -0,0 +1 @@ + MOA filesystem  Продолжаем начатую в прошлом номере пу─ бликацию форматов дисковых систем.  Структура разметки винчестера  на компьютере Scorpion В системе MS-DOS программы для Спектру─ ма, разумеется,работать без определённой и очень трудоемкой адаптации не могут. Тре─ бовалось создать на жестком диске систему TR-DOS. Авторы Теневого Монитора подошли к решению этой проблемы довольно оригиналь─ но: на винчестере создается последователь─ ность TR-DOS образов дисков, и каждый из этих образов можно "подсоединить" к носи─ телю A, B, C или D, и операционная система TR-DOS будет работать с этим образом, не подозревая,что это не реальный диск. Отсю─ да идет терминология:диск физический (гиб─ кий флоппи-диск) и диск эмулированный (HDD образ).  Файловая структура винчестера Структурная организация размещения на винчестере информации выглядит следующим образом.  1.Создастся глобальный подраздел, нося─ щий всегда название MFS (MOA FileSystem?). Теневой Монитор будет работать только с ним. Кроме этого подраздела на жестком ди─ ске могут находиться подразделы других операционных систем. Таким образом, один винчестер можно использовать как на Спек─ труме, так и на других компьютерах.  2.Внутри глобального подраздела создаю─ тся так называемые локальные подразделы. Они могут быть следующих видов:  -TR-DOS.Этот подраздел содержит в се─ бе последовательность TR-DOS образов дис─ ков (от 1 до 51).  -MicroDos.Как писал автор Теневого Монитора,этот подраздел зарезервирован для совместимости с ПК, использующими эту ОС, и программная поддержка этого подраздела планировалась написаться в дальнейшем. Но до настоящего времени так ничего написано и не было.  -IS-DOS.Подраздел для ОС с одноимён─ ным названием.  -BAD.С помощью этого подраздела на винчестере покрывается область, имеющая сбойные сектора. Способы работы с этой структурой вин─ честера через меню Теневого Монитора и подпрограмму RST 8довольно разнообразны. Здесь же я приведу описание того, как эта структура выглядит "изнутри".  Структура описания подразделов Список глобальных подразделов находится в 0-м относительном секторе (0 цилиндр, 0 головка, 1 сектор) по адресу #01BE и зани─ мает 16 байт, где:  +0 - У MOA 0.  +1 - головка |  +2 - сектор | начала  +3 - цилиндр (?) | подраздела.  +4 - у MOA #53 - MFS.  +5 - ?  +6 - ?  +7 - ?  +8 |  +9 | относительный адрес  +10 | подраздела.  +11 |  +12 |  +13 | Длина подраздела  +14 | (в секторах).  +15 | Всего таких описателей может быть 4. Четвёртый байт #53 - признак подраздела MFS. Смысл 5,6 и 7 байта мне так разгадать и не удалось. Также я не совсем уверен в значении 3-го байта.Тем не менее,2-й и 3-й байты указывают местоположение списка ло─ кальных подразделов. Он занимает 2 сектора (1024 байта).Опи─ сание каждого подраздела занимает 16 байт и выглядит следующим образом.  +0 - тип подраздела:  1 - TR-DOS.  2 - MicroDos.  3 - Is-DOS.  4 - BAD.  +1 |  +2 | относительный адрес  +3 | подраздела.  +4 |  +6 |  +7 | Длина подраздела  +8 | (в секторах).  +9 |  +10 - имя подраздела (6 символов). С помощью 4-байтного относительного ад─ реса мы можем обратиться к началу любого локального подраздела.  Внутренняя структура подразделов Подразделы MicroDos и BAD внутренней структуры не имеют. Подраздел IS-DOS такую структуру имеет, но определяется она цели─ ком и полностью только этой операционной системой.  Структура подраздела TR-DOS Теперь рассмотрим подраздел TR-DOS. Он является одним из центральных подразделов на винчестере, поскольку большинство прог─ рамм работают именно с этой операционной системой. Поэтому его мы рассмотрим наибо─ лее подробно. Структура подраздела такова: в первых двух секторах находится описание TR-DOS образов дисков. Описание абсолютно аналогично по своей структуре описанию ло─ кальных дисков. Каждый диск описан 16 бай─ тами, где +0 - всегда 1 (TR-DOS), +1 - ад─ рес образа диска плюс 1, +6 - длина диска (всегда 1,5,0,0 - поскольку длина TR-DOS образа строго фиксирована: 1280+1 512-бай─ тных секторов), +10 - имя диска. Стандарт─ ное имя - "Disk??", где "??" - порядковый номер диска,но его можно безболезненно для Теневого Монитора менять. Обратите внимание,что к адресу диска на винчестере необходимо прибавлять 1 сектор. Дело в том,что перед каждым диском непоня─ тно зачем существует 512-байтная область, заполненная нулями. Хочу также обратить внимание на макси─ мально допустимое количество образов дис─ ков в TR-DOS подразделе. Мне доводилось встречать мнение,что их может быть больше, чем 51. Объясняю, в чём здесь заблуждение: дело в том,что Теневой Монитор для обраще─ ния к дискам внутри подраздела использует 16-разрядный регистр. Относительно начала подраздела адрес 51-го диска будет #FF33, а адрес 52-го диска был бы #010434. Именно поэтому максимальное количество дисков в подразделе - 51. Vega \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/OLZH.$W! b/Docs/FORMATS/info_guide/OLZH.$W! new file mode 100644 index 0000000..8944b18 --- /dev/null +++ b/Docs/FORMATS/info_guide/OLZH.$W! @@ -0,0 +1 @@ + Оптимальный LZH From : hrumer@gorny.ru  >>Игорь Павлов ведёт проект 7-zip, от него в конференции я >>узнал про алгоритм optimal lzh - когда выбирается >>действительно оптимальный способ подбора строк при уже >>существующем дереве кодов длин и расстояний. DB>ХАЧУэтот алгоритм. Держи! Этот алгоритм реально нужен каждому пакеру на спектруме. Я дол- жен был его реализовать для всех хрумов,хрустов и лазеркомпактов три-четыре года назад. Айяйяй в общем. Для "намертво" зашитых кодов, как это сделано в большинстве пакеров на спеке, этот алгоритм принесёт около, боюсь сказать,2-20%.На пакерах типа RIPдо примерно1-10%.Это навскидку. Конечно, памяти много надо на паковку, тормозить будет серьёзно, но есть различные варианты - на куски какой длины разбить файл и прочее.Да хоть на PC можно паковать. --------хрум-------- Игорь Павлов писал в RU.COMPRESS в 1999 году. Алгоритм оптимального Lempel-Ziv-Huffman кодирования ---------------------------------------------------- 1) Поиск совпадений в словарю осуществляется для каждого смещения. При поиске дополнительно собираем информацию об оптимальных (по расстоянию) совпадениях с длинами от2до длины максимального совпадения. Offsets[] = Get_Longest_And_Other_Good_Matches(); // Offsets.Size = length of longest match. // Offsets[i] = back offset in dictionary for match with len=i. BYTE Get_Current_Literal(); // returns current byte 2) Всегда можем посчитать, сколько предположительно бит займёт любой вариант (match/literal) на основе информации о предыдущих huffman блоках: int Get_Match_Huffman_Price(int Length, int Offset); // Length = length of match // Offset = offset of match; // Result = number of bits for coding this match; int Get_Literal_Huffman_Price(BYTE Literal); // Result = number of bits for coding this Literal; 3) Cтроим оптимальную последовательность кодов на много ходов вперёд. Есть большой массив a[]: a[i] = {  int Price;// Цена пути в битах,чтобы добраться до i-го байта.  struct  {  int Prev;// Позиция,откуда мы прыгаем в текущую(=i) позицию  // для Literal: Prev = i - 1  // для Match'а с длиной Length: Prev = i - Length  int Offset;// Смещ. в буфере(словаре)назад в случае Мatch'а  // для записи Мatch'а от Prev до i  } } a) Для всех элементов a[] устанавливаем Price = бесконечность. b) for(int i=0; i < Big_Value; i++) {  // Существуют некоторые условия досрочного вых. из этого цикла  // Получаем массив Offsets[2..Longest_match_length] смещений в  // буфере (словаре) назад, смотри 1).  Offsets[] = Get_Longest_And_Other_Good_Matches();  for(int Len = 1; Len < Offsets[].Length; Len++)  // Len=1 means Literal  {  // Определяем цену в битах рассматриваемого "прыжка" на Len  // символов вперёд  if (Len == 1) // it's a literal  aPrice = Get_Literal_Huffman_Price(Get_Current_Literal());  else  aPrice = Get_Match_Huffman_Price(Len, Offsets[Len]);  // и вычисляем цену нового кандидата в a[i + Len].  aNewPrice = a[i].Price + aPrice;  if (aNewPrice < a[i + Len].Price )  // Если выгодно старый путь (старая цена может быть даже  // равна бесконечности,т.е.вообще ещё нет пути) заменить  // новым, то меняем a[i + Len], чтобы он указывал на i  {  a[i + Len].Price = aNewPrice;  a[i + Len].Prev = i;  a[i + Len].Offset = Offsets[Len];  }  } } c) Двигаясь по a[] от конца, собираем "оптимальные" match/literal последовательности и кодируем их. End. --------хрум-------- >>В общем, мое отношение смотри выше, но вот есть же другая >>интересная вещь - просто поддержать распаковкуLZMAна >>спектруме. Правда, мне кажется, будет неудобно использовать >>распаковщикLZMAдля программ на спектруме. DB>Но можно применить для журналов или больших справочников. DB>Например,Open Lettersна одном диске ;) >>PS. Перечитал твоё письмо и понял, что исходники тебе >>прислали... DB>Там без поллитры не въедешь -1021файл,3.4мегабайта DB>исходников. Мусорка. Ну, поллитра не проблема :). Там и с поллитрой не въедешь. Ты не пробовал изучить просто декодер, тот, который в файле \SRC\7zip\Compress\LZMA_C\lzmadecode.c,там всего23кб :). \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/Ptdoc.$w! b/Docs/FORMATS/info_guide/Ptdoc.$w! new file mode 100644 index 0000000..abde658 --- /dev/null +++ b/Docs/FORMATS/info_guide/Ptdoc.$w! @@ -0,0 +1 @@ + Формат модуля Pro Tracker v3.7x Указаны смещения до областей в модуле и их длина в байтах (десятичные числа). +0 (13) "ProTracker 3." - идентификационная строка. +13 (17) "6" (или "5", "4", или даже "3" ) - номер подверсии. Следует заметить, что для модулей PTv3.4x и ниже используется другая, "несимметричная" таблица громкости, а в модулях PTv3.3x используется альтернативная частотная таблица "Pro Tracker", не совпадающая с одноименной современной! +14 (16) " compilation of " (необязательное - любой текст этой длины). +30 (32) название модуля (ASCII, lat, неиспользованные символы забиты пробелами). +62 (4) " by " (необязательное - любые 4 символа) +66 (32) имя автора (ASCII, lat, неиспользованные символы забиты пробелами). (то есть первые 98 байт модуля образуют соответствующую строку) +98 (1) Для обычных AY музонов: код #20. Если используется TS: число паттернов N (в текущей версии должно быть #30). Паттерны первого AY нумеруются N-1,N-2,... Паттерны второго AY нумеруются 0,1,2,... В списке позиций стоят паттерны N-1,N-2,... +99 (1) номер частотной таблицы: 0=Pro Tracker, 1=Sound Tracker, 2=ASM or PSC, 3=RealSound. Табличка занимает 192 байта и содер- жит значения периодов для 96 нот,начиная с C-1 (ДО первой окта- вы). Период - значение, обратное частоте ноты, помещаемое в со- ответствующие регистры AY. Младшие байты (здесь и ниже,за одним исключением,которое будет указано) хранятся первыми. Компилятор PT сохраняет таблицу, соответствующую модулю, в тело плейера по относительному адресу 512. Таблицу громкости он сохраняет в том же теле плейера по относительному адресу 256. +100 (1) значение темпа. +101 (1) song end (1=в модуле всего одна позиция) - в плейере не используется. +102 (1) song loop (0=зацикливание на начало). +103 (2) Psa_chn=смещение от начала модуля до таблицы паттернов. +105 (32*2) смещения от начала модуля до сэмплов, начиная с ну- левого сэмпла. По два байта на сэмпл. Нулевой сэмпл в текущих версиях редактора не используется. Для всех неиспользованных сэмплов смещение равно нулю. +169 (16*2) смещения от начала модуля до орнаментов, начиная с нулевого. По два байта на орнамент.Нулевой орнамент - это отсу- тствие орнамента,поэтому данные этого орнамента (см.ниже) соде- ржат 0,1,0 (можно использовать этот орнамент по своему усмотре- нию,НО тогда в сонге нельзя будет использовать сэмплы без орна- ментов).Для всех неиспользованных орнаментов смещение равно ну- лю. +201 (?) список позиций (ордер). Содержит номера паттернов (0...84), умноженные на 3. Таблица завершается кодом #ff. Pro Tracker v3.3x-v3.5x не поддерживает больше 42 паттернов. Pro Tracker v3.6x не поддерживает больше 46 паттернов. Pro Tracker v3.69x, v3.7 не поддерживает больше 48 паттернов. +Psa_chn (?*6) указатель паттернов. Содержит для каждого из име- ющихся паттернов смещения: ++0 (2) до блока данных канала (трека) A ++2 (2) до блока данных канала (трека) B ++4 (2) до блока данных канала (трека) C. Данные по смещению шума (отдельная колонка в редакторе) компи- лируются в канал B. +? (?*?) блоки данных каналов, то есть треки. Трек содержит следующие данные: ================================================================ #00 - конец трека. Pro Tracker не работает с модулями, в которых есть треки больше 64 строк. #01, delay, Lsl, Hsl - эффект Gliss(Slide) вверх или вниз. Delay - время в пятидесятых долях секунды, по истечении которого к периоду ноты будет прибавлена величина Lsl+256*Hsl. Смещение накапливается плейером в соответствующей переменной и прибавля- ется после формирования частоты ноты, т.е.сначала обрабатывает- ся строчка орнамента, а уже потом... v3.7: Если delay=0, то указанное смещение прибавляется к ноте на всём её протяжении (смещение тона для подгонки под огибающие и т.п.). #02, delay, Lmax, Hmax, Lsl, Hsl - эффект Tone Portamento вверх или вниз.Delay - время в пятидесятых долях секунды,по истечении которого к периоду ноты будет прибавлена величина Lsl+256*Hsl. Lmax+256*Hmax - максимальное смещение (беззнаковое), после на- копления которого следует прекратить Portamento (в PT3.6x не используется, т.к. возможно неправильное указание направления). #03, offset - sample offset. Сэмпл начинает играть не сначала. #04, offset - ornament offset. Орнамент начинает играть не сна- чала. #05, YEStime, NOtime - vibrate. нота то звучит, то не звучит. #08, delay, Lsl, Hsl - эффект slide envelope. К значению периода огибающей время от времени прибавляется Lsl+256*Hsl. #09, tempo - указание темпа (в прерываниях на строку). Стандарт- ный плейер меньше tempo=2 не играет. NB: параменты эффектов (#0x) лежат не сразу после кода номера эффекта, а ПОСЛЕ КОНЦА СТРОКИ!!! Если используется несколько эф- фектов на одну ноту (на самом деле так не бывает),то сначала ле- жат параменты последнего эффекта, потом предпоследнего и так да- лее... #10, smp*2 - выключить огибающую, перезапустить орнамент и изменить номер сэмпла. #1x, Henv, Lenv, smp*2 - изменить номер сэмпла, перезапустить орнамент и включить огибающую типа x-1 с периодом Lenv+256*Henv. При включении огибающей она инициализируется, т.е. начинается новый период! #20-#3f - указать смещение шума (бывает только в канале B) #4x - указать орнамент номер x. (огибающая не выключается) #50-#Af - указать высоту ноты и ЗАКОНЧИТЬ анализ текущей строки канала. #B0 - выключить Envelope. #B1, lines - не анализировать канал в течение lines строк. (lines=1 соответствует одной строке). Действует не только на промежуток между этой и следующей нотой, но и далее, пока не указано другое значение lines! #Bx, Henv, Lenv - то же, что #1x, но без сэмпла. То есть просто включить огибающую типа x-1 с указанным периодом. #Cv - указать громкость.(v=0 - пауза и ЗАКОНЧИТЬ анализ строки.) #D0 - ЗАКОНЧИТЬ анализ строки. #D1-#Ef - указать номер сэмпла. #Fx, smp*2 - указать номер орнамента (x) и номер сэмпла. (огибающая выключается) ================================================================ +? (?*(?*4+2)) - сэмплы. ++0 (1) - loop ++1 (1) - end (1=сэмпл из одной строчки) ++2 (?*4) - данные: +++0 (1) sv +- N4 N3 N2 N1 N0 Em +++1 (1) Nm ts ns Tm V3 V2 V1 V0 sv=1 - признак съезжания громкости, +- =1 соответствует её уве- личению; N4-0 - частота шума ИЛИ смещение огибающей (зависит от наличия маски шума): смещение огибающей 0-15 - вниз, 16-31 - вверх (N4 интерпретируется как знак); V3-0 - громкость; Tn, Nm, Em - маски тона, шума и огибающей соотв., причём если маска ра- вна единице,то соответствующий элемент звука выключен; ts, ns=1 - признаки того, что текущее смещение тона или шума/огибающей будет запомнено. +++2 (2) смещение периода тона (положительное - вверх, от- рицательное - вниз). +? (?*(?+2)) - орнаменты. ++0 (1) - loop ++1 (1) - end (1=орнамент из одной строчки) ++2 (?) - данные: смещения в полутонах (0=нет смещения, поло- жительное смещение - вверх, отрицательное - вниз). Alone Coder жду дополнений! Дополнения от 10.xi.02: 1. (Sergey Bulba): Таблица ASM or PSC не имеет отношения к соот- ветствующим редакторам. Модули из этих редакторов следует импо- ртировать с таблицей Sound Tracker. Таблица ASM or PSC рассчита- на так,чтобы при тактовой частоте AY 1.7744 MHz ноты в редакторе совпадали с одноименными нотами фортепиано. (Таблица Real Sound - аналогично, но для 1.75 MHz.) 2. В модуле может использоваться и 0-й сэмпл, если в треке он хранится вместе с орнаментом (можно нулевым). Итого 32 сэмпла. 3. Проверена информация по поводу Portamento, Loop и #B1. 4. Исправлена информация по поводу сэмплов. Дополнение от 24.ii.03: 5. Дополнено по поводу выключения огибающей. Дополнение от 25.iii.03: 6. Стандарт PTv3.6x - 46 паттернов. 7. При переполнении смещения орнамента вниз (точнее, при отрица- тельном номере ноты) подставляется самая низкая нота C-1. При переполнении вверх результат не определён. Дополнение от 26.vii.03: 8. Выше уточнены изменения для PT3.6x. 9. Максимальный размер модуля, который можно загрузить в редак- тор, равен #3300 байт, или #4000 байт для "cjf" версии. Дополнение от 20.iii.04: 10. PT3+67 имеет 48 паттернов, но не гарантируется, что их будет столько же во всех следующих версиях. Дополнение от 29.vi.04: 11. см.про #10 и #B1. 12. в PT3.69 можно указывать номер орнамента без влияния на огибающую. в VTII пока нельзя. все плейеры играют такое. Дополнение от 26.viii.04: 13. на строчках сэмпла, где включен шум, накопленное смещение огибающей игнорируется. Дополнение от 27.x.04: 14. #1x (Sergey Bulba) Дополнение от 6.xi.04: 15. (Sergey Bulba) Почти все таблички сделаны неправильно (не соответствуют идеальной шкале 1750000 и 1773400). Более-менее правильно сделана табличка 1 (SoundTracker), традиционная для ZX Spectrum - она подходит для импорта практически всех существующих на ZX музыкальных редакторов. По сравнению с идеальной шкалой для 1773400 Гц сдвинута почти ровно на один тон вниз. Кроме того, 24-я нота фальшивит (в редакторе обозначена как B-2, из-за сдвига в один тон должна звучать как A-2). Hо, к сожалению, это единственная табличка, которая подходит под 1773400 Гц (фирменный Спектрум 128). Табличка номер 2 практически идеально подходит под частоту AY 1750000 Гц, все ноты звучат именно так, как они и отображаются в редакторе. К сожалению, таблицы нот разных версий Pro Tracker 3 достаточно сильно отличаются (в особенности таблица 2, которая раньше имела полное право называться ASM or PSC и идеально подходила под частоту 1773400 Гц). Табличка 1 в этом смысле уникальна - она одинакова во всех версиях Pro Tracker 3. Табличка #0. Официальное название "ProTracker". Hигде, кроме PT3, не используется. Она не менялась вплоть до версии PT3.4r. Hачиная с других версий PT3.4x и по сей день немного модифицирована. Hе подходит ни под какую из стандартных частот AY. Табличка #1. Официальное название "SoundTracker". Эта табличка плавно перетекла из Pro Tracker 2. Является модификацией таблички от Sound Tracker. Единственная табличка, которая одинакова во всех версиях PT3.xx. Подходит для STC, STP, FTC, GTR, PT2, PT1, FLS, с небольшой натяжкой и под SQT (со второй ноты), ASM и PSC. Табличка достаточно близка к частоте 1773400 Гц, но смещена относительно нее на 1 тон вниз (то есть C-2 звучит как A#1). Hота B-2 (должна звучать как A-2) в этой табличке сильно фальшивит [на 1/9 тона]. Табличка #2. Официальное название "ASMorPSC". Когда она появилась впервые в версии PT3.4r, она являлась простой модификацией таблички ASM (PSC), без первых двух нот и в точности совпадала с рядом для частоты 1773400 Гц. Hачиная с прочих версий PT3.4x и по сей день она кардинально изменилась, вследствие чего для конвертирования ASM и PSC подходит не больше, чем табличка #1. Первая версия хорошо подходила под SQT. Современная табличка #2 идеально подходит под частоту AY 1750000 Гц. Остальные таблички рассчитаны неизвестно под что :( Табличка #3. Официальное название "RealSound". Так же, как предыдущая, впервые появилась в версии PT3.4r и изменилась начиная с прочих версий PT3.4x. Табличка является модификацией таблички #0 и смещена относительно нее на полтона вниз. Соответственно, также не подходит ни под одну стандартную частоту AY. 16. 48 паттернов. 64 строки. В TurboSound модулях под второй чип используются паттерны номер (47-паттерн), в списке позиция стоят именно эти высокие номера. 17 (19 aug 06). Дополнения про PT v3.7: +98; slide с delay=0. \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/RARFOR00.TFI b/Docs/FORMATS/info_guide/RARFOR00.TFI new file mode 100644 index 0000000..9bdf860 --- /dev/null +++ b/Docs/FORMATS/info_guide/RARFOR00.TFI @@ -0,0 +1,550 @@ +...с этого места Alone Coder пересел за +пентагон и продолжил набирать статьи на +нём. Несмотря на сопротивляющуюся клавиа- +туру, это оказалось удобнее :) + + Формат RAR 2.x. + +Мне очень понравился этот формат с точки +зрения быстроты распаковщика, соотнесённой +с качеством сжатия, поэтому я решил вам о +нём рассказать. +Для начала приведу фирменную техническую +информацию,чтобы было немного понятно, что +и где в файле лежит :) + +---------begin of techinfo.txt---------- + +Техническая информация по RAR версии 2.70 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + ОПИСЫВАЕМЫЙ ФОРМАТ АРХИВА ДЕЙСТВИТЕЛЕН + ТОЛЬКО ДЛЯ RAR ВЕРСИИ 1.50 И СТАРШЕ + +========================================== + Формат архивного файла RAR +========================================== + +Файл архива состоит из блоков разной дли- +ны. Порядок следования этих блоков может +меняться, но первым блоком всегда должен +быть блок-маркер, за которым следует блок +заголовка архива. +Каждый блок начинается со следующих полей: + +HEAD_CRC  2 байта CRC всего блока + или его части +HEAD_TYPE  1 байт Тип блока +HEAD_FLAGS  2 байта Флаги блока +HEAD_SIZE  2 байта Размер блока +ADD_SIZE  4 байта Необязательное + поле:добавление + к размеру блока +Поле ADD_SIZE присутствует, только если +(HEAD_FLAGS & 0x8000) != 0 + +Общий размер блока указан в поле HEAD_SIZE +- если (HEAD_FLAGS & 0x8000) == 0,- или +HEAD_SIZE+ADD_SIZE,если есть поле ADD_SIZE +- при этом (HEAD_FLAGS & 0x8000) != 0. + +Во всех блоках следующие биты в HEAD_FLAGS +имеют одинаковое значение: +0x4000 -если установлен, то старые версии + RAR будут игнорировать этот блок + и удалять его при изменении архи- + ва; + если не установлен, то блок копи- + руется в новый архивный файл при + изменении архива; +0x8000 -если установлен, то присутствует + поле ADD_SIZE, + и размер полного блока составляет + HEAD_SIZE+ADD_SIZE. + +Заявленные типы блоков: +HEAD_TYPE=0x72 блок-маркер +HEAD_TYPE=0x73 заголовок архива +HEAD_TYPE=0x74 заголовок файла +HEAD_TYPE=0x75 заголовок комментария +HEAD_TYPE=0x76 электронная подпись +  старого типа +HEAD_TYPE=0x77 субблок +HEAD_TYPE=0x78 информация для +  восстановления +HEAD_TYPE=0x79 электронная подпись + +Блок комментария используется только внут- +ри других блоков. + +Обработка архива происходит следующим об- +разом: +1.Читается и проверяется блок-маркер +2.Читается заголовок архива +3.Читаются или пропускаются HEAD_SIZE-ра- +змер(MAIN_HEAD) байт +4.Если обнаружен конец архива, то обрабо- +тка архива прекращается, иначе читаются 7 +байт в полях: +HEAD_CRC,HEAD_TYPE,HEAD_FLAGS,HEAD_SIZE. +5.Проверяется HEAD_TYPE. +Если HEAD_TYPE==0x74 + прочитать заголовок файла (первые 7 байт + уже прочитаны) + прочитать или пропустить HEAD_SIZE-раз- + мер(FILE_HEAD) байт + прочитать или пропустить FILE_SIZE байт +иначе +прочитать соответствующий блок HEAD_TYPE: + прочитать HEAD_SIZE-7 байт + если (HEAD_FLAGS & 0x8000) + прочитать ADD_SIZE байт +6.Перейти к шагу4. + +========================================== + Форматы блоков +========================================== + +Блок-маркер (MARK_HEAD) +~~~~~~~~~~~~~~~~~~~~~~~ + +HEAD_CRC Всегда 0x6152 +2 байта +HEAD_TYPE Тип заголовка: 0x72 +1 байт +HEAD_FLAGS Всегда 0x1a21 +2 байта +HEAD_SIZE Размер блока = 0x0007 +2 байта +Блок-маркер в действительности считается +фиксированной последовательностью байт: +0x52 0x61 0x72 0x21 0x1a 0x07 0x00 + +(прим.AlCo:удачно подобран CRC!!! Выходит +любопытная последовательность:"Rar!",Esc, +BellиNul,удобная и для визуального опо- +знавания, и для проверки канала передачи +данных на вшивость.) +(прим. Shaitan: собственно разработ- +чик, Евгений Рошал, даного формата перво- +начально и добивался визуального определе- +ни архива. Примерно такая же история и с +другими форматами архивов, и вообще, нали- +чие неповторимой и визуальной сигнатуры в +разного рода файлах уже стало правилом хо- +рошего тона) + +Заголовок архива (MAIN_HEAD) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +HEAD_CRC  CRC полей от HEAD_TYPE до +2 байта  RESERVED2 +HEAD_TYPE  Тип заголовка: 0x73 +1 байт +HEAD_FLAGS  Битовые флаги: +2 байта + 0x01 -Атрибут тома (том + многотомного архива) + 0x02 -Есть архивный коммен- + тарий + 0x04 -Атрибут блокировки + архива + 0x08 -Атрибут непрерывного + (solid) архива + 0x10 -Не используется + 0x20 -Есть информация об + авторе или электронная + подпись (AV) + остальные биты в HEAD_FLAGS зарезерви- + рованы для внутреннего использования. + +HEAD_SIZE Общий размер архивного +2 байта заголовка,включая архивные + комментарии +RESERVED1 Зарезервировано +2 байта +RESERVED2 Зарезервировано +4 байта + +Блок комментария +присутствует, если (HEAD_FLAGS & 0x02)!=0 + +Заголовок файла (файл в архиве) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +HEAD_CRC CRC полей от HEAD_TYPE до +2 байта FILEATTR и имени файла +HEAD_TYPE Тип заголовка: 0x74 +1 байт +HEAD_FLAGS Битовые флаги: +2 байта + 0x01 -файл продолжается из + предыдущего тома + 0x02 -файл продолжается в + следующем томе + 0x04 -файл зашифрован паролем + 0x08 -есть комментарий файла + 0x10 -используется информация + из предыдущих файлов + (флаг непрерывности) + (для RAR 2.0 и выше) + + биты 7 6 5(для RAR 2.0 и выше) + 0 0 0 -размер словаря 64 Кб + 0 0 1 -размер словаря 128 Кб + 0 1 0 -размер словаря 256 Кб + 0 1 1 -размер словаря 512 Кб + 1 0 0 -размер словаря 1024Кб + 1 0 1 -зарезервировано + 1 1 0 -зарезервировано + 1 1 1 -file is directory + + 0x100 -есть поля + HIGH_PACK_SIZE и + HIGH_UNP_SIZE. Эти поля + используются только для + архивирования очень бо- + льших файлов (больше 2 + Гб), для меньших файлов + эти поля отсутствуют. + 0x8000 -этот бит всегда устано- + влен,так как общий раз- + мер блока HEAD_SIZE + + + PACK_SIZE (и плюс + HIGH_PACK_SIZE, если + установлен бит 0x100) + +HEAD_SIZE Полный размер заголовка +2 байта файла, включая имя файла и + комментарии +PACK_SIZE Размер файла в архиве +4 байта (сжатый) +UNP_SIZE Размер исходного файла +4 байта (несжатый) +HOST_OS Использованная при архивиро- +1 байт вании операционная система: + 0 -MS-DOS + 1 -OS/2 + 2 -Win32 + 3 -Unix + 4 -Mac OS + 5 -BeOS +FILE_CRC CRC файла +4 байта +FTIME Дата и время в стандартном +4 байта формате MS-DOS +UNP_VER Версия RAR,необходимая для +1 байт извлечения файла +METHOD Метод сжатия +1 байт +NAME_SIZE Размер имени файла +2 байта +ATTR Атрибуты файла +4 байта +HIGH_PACK_SIZE Старшие 4 байта 64-битного +4 байта размера сжатого файла. + Необязательное значение, + которое присутствует, + только если бит 0x100 в + HEAD_FLAGS установлен. +HIGH_UNP_SIZE Старшие 4 байта 64-битного +4 байта размера несжатого файла. + Необязательное значение, + которое присутствует, + только если бит 0x100 в + HEAD_FLAGS установлен. +FILE_NAME Имя файла - строка + размером NAME_SIZE байт + +Блок комментария +присутствует, если (HEAD_FLAGS & 0x08)!=0 + +Блок комментария +~~~~~~~~~~~~~~~~ + +HEAD_CRC CRC полей от HEAD_TYPE до +2 байта COMM_CRC +HEAD_TYPE Тип заголовка: 0x75 +1 байт +HEAD_FLAGS Битовые флаги +2 байта +HEAD_SIZE Размер заголовка коммента- +2 байта рия + размер комментария +UNP_SIZE Размер несжатого коммента- +2 байта рия +UNP_VER Версия RAR,необходимая для +1 байт извлечения комментария +METHOD Метод сжатия +1 байт +COMM_CRC CRC комментария +2 байта +COMMENT Текст комментария + +Блок дополнительной информации +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +HEAD_CRC CRC блока +2 байта +HEAD_TYPE Тип заголовка: 0x76 +1 байт +HEAD_FLAGS Битовые флаги +2 байта +HEAD_SIZE Общий размер блока +2 байта +INFO Прочие данные + +Субблок +~~~~~~~ + +Объект в архиве (блок или заголовок) может +сопровождаться субблоком. Субблок зависит +от основного объекта. Субблок может быть +удален или перемещен в новой версии архива +при его обновлении. + +Субблок содержит следующие поля: + +HEAD_CRC CRC блока +2 байта +HEAD_TYPE Тип заголовка: 0x77 +1 байт +HEAD_FLAGS Битовые флаги +2 байта (HEAD_FLAGS & 0x8000)==1, + так как полный размер + блока составляет + HEAD_SIZE + DATA_SIZE +HEAD_SIZE Общий размер блока +2 байта +DATA_SIZE Общий размер данных +4 байта +SUB_TYPE Тип субблока +2 байта +RESERVED Должно быть 0 +1 байт +Другие поля Другие поля в зависимости + от типа субблока + +Субблок расширенных атрибутов OS/2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +HEAD_CRC CRC блока +2 байта +HEAD_TYPE Тип заголовка: 0x77 +1 байт +HEAD_FLAGS Битовые флаги +2 байта (HEAD_FLAGS & 0x8000)==1, + так как полный + размер блока составляет + HEAD_SIZE + DATA_SIZE +HEAD_SIZE Общий размер блока +2 байта +DATA_SIZE Общий размер данных +4 байта (сжатый размер расширенных + атрибутов) +SUB_TYPE 0x100 +2 байта +RESERVED Должно быть 0 +1 байт +UNP_SIZE Размер несжатых +4 байта расширенных атрибутов +UNP_VER Версия RAR,необходимая для +1 байт извлечения расширенных + атрибутов +METHOD Метод сжатия +1 байт +EA_CRC CRC расширенных атрибутов +4 байта + +========================================== + Примечания +========================================== + +1.Для обработки SFX-архива нужно пропус- +тить модуль SFX, для чего в архиве осуще- +ствляется поиск блока-маркера.В самом SFX +модуле отсутствует последовательность ба- +йтов блока-маркера +(0x52 0x61 0x72 0x21 0x1a 0x07 0x00). +2.CRC вычисляется с помощью стандартного +полинома 0xEDB88320. В случае,если размер +CRC меньше 4 байт, то используются только +младшие байты. +3.Кодирование метода сжатия: + 0x30 -сохранение (без сжатия) + 0x31 -скоростное сжатие + 0x32 -быстрое сжатие + 0x33 -нормальное сжатие + 0x34 -хорошее сжатие + 0x35 -максимальное сжатие +4.Номер версии RAR,необходимой для извле- +чения, кодируется как 10 * старший номер +версии + младший номер версии. +----------end of techinfo.txt----------- + +Дальше пошла отсебятина: + + Внутренний формат RAR. + +Используется сжатие типа LZ, заключающееся +в копировании некоторых кусков из уже рас- +пакованной части файла под курсор. Ниже +употребляется терминология: +"длина ссылки"(puts)- длина копируемого +куска; +"смещение"(disp)- смещение от курсора до +начала копируемого куска. + +Для уменьшения избыточности LZ кодирования +используются деревья Хаффмана глубиной до +15 бит,в количестве 4 штуки. Эти деревья +носят названия:BD, LD, DD и RD.Первое +применяется для распаковки остальных трёх. +BDсодержит19возможных символов; +LDсодержит298возможных символов; +DDсодержит48возможных символов; +RDсодержит28возможных символов. + +Ниже используется термин: +"ярус"(Row)- совокупность символов в де- +реве, имеющих одинаковую битовую длину. + +Любой упакованный блок,если он не является +вторым и далее в solid архиве, начинается +с блока под названием"упакованные дере- +вья". + + Упакованные деревья: + +1 бит-"multimedia block"flag (0,если +не multimedia: ниже рассматривается только +такой вариант) +1 бит- очистить старый массив длин нулями +(1- не надо) +19x4 бит- деревоBD.Указаны длины в би- +тах для всех19символов (символы расписа- +ны ниже). Алгоритм генерации дерева,исходя +из информации о длинах, довольно хитрый, и +здесь я его приводить не буду. Скажу толь- +ко, что более короткие символы располагаю- +тся в дереве левее (т.е. начинаются скорее +с нуля, чем с единицы), нежели более длин- +ные. + +После того, как вышеизложенная информация +прочитана, начинается работа с большой та- +блицей длин под названиемRT_Table,кото- +рая имеет размер374=298+48+28 байт.В ней +последовательно содержатся длины(0..15) +всех символов деревьевLD, DDиRD. + +Итак, устанавливаем указательiна первый +байт таблицы RT_Tableи читаем символы из +файла, пользуясь деревомBD: + +0..15- прибавить это число к текущей яче- +йке таблицыRT_Tableи перейти к следующей +ячейке. +tab[i]=(tab[i]+num)&15;i++ + +16- скопировать предыдущую ячейкуN+3ра- +за, гдеN (2 бита)хранится в файле сразу +после символа16. +tab[i]=tab[i-1];i++ и т.д. + +17- поместить вZ+3ячеек,начиная с теку- +щей,число0.ГдеZ (3 бита)хранится сразу +после символа17. +tab[i]=0;i++ и т.д. + +18- поместить вZ+11ячеек, начиная с те- +кущей,число0.ГдеZ (7 бит)хранится сра- +зу после символа18. +tab[i]=0;i++ и т.д. + +Заполнение RT_Table заканчивается, когда +обработаны все её374ячейки. + +Таким образом, мы получили из файла струк- +туры всех деревьев. Переводим деревья в +удобный для нас формат(в моём распаковщи- +ке это таблица чисел"LowRowCode",таблица +чисел"RowAdr-(LowRowCode>>Row)"и таблица +"номер листа дерева->символ",гдеRowAdr- +адрес первого символа в ярусе,аLowRowCode +- код,соответствующий самому левому элеме- +нту яруса)и переходим к считыванию упако- +ванных данных. + + Упакованные данные: + +Как выше уже упоминалось, до самих данных +в файле лежат деревья. По тому же условию, +что требуется для наличия деревьев в нача- +ле файла(то есть,"блок не является вторым +или далее файлом solid архива"),следует +(или не следует иначе) обнулить таблицу +предыдущих смещений. Дело в том,что распа- +ковщик всегда хранит4предыдущих реализо- +ванных смещения. Эти смещения -20-битные +числа(максимальная ссылка назад =1 Мб). +Впрочем, я не уверен, что обнулять их так +уж необходимо, но кто знает, что на уме у +упаковщика? + +Читаем из файла токен, пользуясь деревом +LD: + +0..255- просто символ. Помещаем его в вы- +ходной поток. + +256- повтор предыдущего смещения и преды- +дущёй длины ссылки. Реализуем эту ссылку. + +257..260- берём одно из предыдущих 4 сме- +щений (257=самое новое,258=позапрошлое +и т.д.). Читаем токен, пользуясь деревом +RD.Этот токен указывает номер строки в +таблицеmidBIT.Из неё берётся длина ссыл- +ки и количество битов,которые нужно сейчас +дополнительно дочитать из файла,чтобы при- +бавить их к этой длине ссылки. +Потом длина ещё немного корректируется: +еслиdisp>=257,инкрементируем длину; +еслиdisp>=#2000,снова инкрементируем +длину; +еслиdisp>=#40000,ещё раз инкрементируем +длину. +Уфффф. Реализуем ссылку. + +261..268- если вычесть261,получим номер +строки в таблице litBIT.Из неё берётся +смещение и число битов, которые нужно до- +читать из файла для коррекции этого смеще- +ния. Длина ссылки считается равной2.Реа- +лизуем ссылку. + +269- считываем новые деревья (формат см. +выше). Ничего в самом распаковщике не ини- +циализируется! Меняются только деревья! + +270..297- вычитаем270,получаем № строки +вmidBIT,достаём оттуда длину ссылки и +число бит её коррекции. +Инкрементируем длину. +Читаем токен, пользуясь деревомDD.Он за- +даёт номер строки в таблицеbigBIT- берём +оттуда смещение и число битов для его кор- +рекции. + +Еслиdisp>=#2000,инкрементируем длину; +еслиdisp>=#40000,ещё раз инкрементируем +длину. +Реализуем ссылку. + +Распаковка заканчивается, когда извлечено +столько байт распакованного файла, сколько +указано в заголовке этого файла. + +Всё! :) В следующий раз я расскажу вам про +мультимедийную компрессию и шифрование, +если, конечно, сам разберусь :) +                                    \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/SPG0_0.txt b/Docs/FORMATS/info_guide/SPG0_0.txt new file mode 100644 index 0000000..c1101d5 --- /dev/null +++ b/Docs/FORMATS/info_guide/SPG0_0.txt @@ -0,0 +1,54 @@ + .SPG + Данный формат служит для хранения запускаемых +программ на любых носителях (CD/DVD/HDD). Сами +файлы могут быть запущены из WDC в левой панели +простым нажатием на ENTER. +(в WDCv1.06 формат поддержан не полностью: + 1. обрабатывается только первый блок с данными + 2. не учитывается порт X + 3. CRC не проверяется) + +"Spectrum Prog" file format v0.0: + +смещ│длин. + ---+----------------------------------------------- + +0│32 - резерв + +32│12 - идентификатор формата ("SpectrumProg") + +44│1 - версия формата + +45│2 - CRC всего заголовка (512 байт) + +47│2 - обратная CRC (старший байт впереди) + +49│1 - *** + +50│1 - *** + +51│13 - резерв + ---+----------------------------------------------- + +64│2 - адрес запуска + +66│1 - значение порта #7FFD перед запуском + +67│2 - адрес порта X, если = 0 то в порт X зна-е + │ не заносится + +69│1 - значение кот. будет занесено в порт X п-д + │ запуском (если X<>0) + +70│3 - дата (день,месяц,год) + +73│1 - версия сборки + +74│2 - адрес вершины стека(если=0, то не меняем) + │ + +76│2 - резерв + │ + +78│1 - длина блока настроек + │ (если=0, то игнорируем таковые, + │ иначе кидаем n<256 байт в адрес #5B00) +----+-Блок_загрузки*8----------------------------- ++128│2 - адрес загрузки + │ (если <#A000, то идёт завершение обработки + │ блоков загрузки) + │1 - длина блока в 2048 байтных секторах + │1 - номер странички кот. надо включить + │4 - резерв +----+---------------------------------------------- ++192│256- область настроек программы +----+---------------------------------------------- ++448│64 - резерв +----+---------------------------------------------- +Во время запуска программы включен 1 режим прерыва- +ний (I=63). По адресу #6000 лежит керналь вызовов. +--------------------------------------------------- + Budder/23.12.2006 \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/XDELPZ.A80 b/Docs/FORMATS/info_guide/XDELPZ.A80 new file mode 100644 index 0000000..e1328c2 --- /dev/null +++ b/Docs/FORMATS/info_guide/XDELPZ.A80 @@ -0,0 +1,98 @@ +;Декомпрессор для v 3.01 +;HL-откуда DE-куда +;DLPCB DEFM "v301" +DELPZ PUSH DE + LD DE,DLPCB + LD BC,4 + LDIR + POP DE +xpD0 LD A,(HL) + SRL A + JR NC,xpD1 + CALL xpSUB ;short copy + RRA + RL B + AND 7 +xpM2 JR NZ,xpNex + LD A,(HL) + INC HL +xpNex LD C,(HL) + INC HL + PUSH HL + LD H,D + LD L,E + SBC HL,BC + LD B,0 + LD C,A +xpM1 INC BC + INC BC + LDIR + POP HL + EX AF,AF + JR Z,xpD0 + JR NZ,xpDRR +xpD1 RRA + JR C,xpZ1 + RRA + JR C,xpZ2 + JR Z,xpDEND + INC HL +xpDRR LD B,A ;nocompr +xpDL0 LD A,(HL) + INC HL + XOR (HL) + LD (DE),A + INC DE + DJNZ xpDL0 + JR xpD0 +xpZ2 SRL A ;repeat + JR C,xpZ2L + LD C,A + XOR A + EX AF,AF +xpZ22 INC HL + PUSH HL + LD H,D + LD L,E + DEC HL + JR xpM1 +xpZ2L CALL xpSUB + RRA + RL B + LD C,(HL) + JR xpZ22 +xpZ1 SRL A + JR NC,xpTWO + LD C,A ;long copy + INC HL + LD A,(HL) + AND #1F + LD B,A + LD A,C + CALL xpSUB + OR A + JR xpM2 +xpTWO INC A ;два байта + LD C,A + INC HL + PUSH HL + LD H,D + LD L,E + SBC HL,BC + LD C,2 + LDIR + POP HL + JR xpD0 +xpDEND LD HL,DLPCB + LD C,4 + LDIR + RET +xpSUB EX AF,AF + LD A,(HL) + RLCA + RLCA + RLCA + AND 7 + EX AF,AF + INC HL + RET \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/alasmtxt.txt b/Docs/FORMATS/info_guide/alasmtxt.txt new file mode 100644 index 0000000..9c8d615 --- /dev/null +++ b/Docs/FORMATS/info_guide/alasmtxt.txt @@ -0,0 +1,283 @@ +─ Echo35 (2:5029/35.26) ───────────────────────────────────────── ZX.SPECTRUM ─ + Msg : 100 of 107 + From : Alexey Komarov 2:5020/400 23 Apr 02 14:29:48 + To : All 26 Apr 02 01:04:11 + Subj : Fwd: SOURCE: Конвертилка хобеты с программой на ALASM в текст +─────────────────────────────────────────────────────────────────────────────── +From: "Alexey Komarov" + +========================================================================== +* Forwarded by Alexey Komarov +* Newsgroup: relcom.comp.speccy +* From: "Alexander Shabarshin" +* Date: Fri, 12 Apr 2002 16:43:34 +0600 +* Subj: SOURCE: Конвертилка хобеты с программой на ALASM в текст +========================================================================== + +// H2ASM.CPP - Alexander Shabarshin (shaos@mail.ru) 12.04.2002 +// Convert hobeta with ALASM source to text source +// Конвертилка хобеты с программой на ALASM в обычный текст +// Есть недоделки - кто заметил, сообщайте! +// вроде нужная вещь - может кому и пригодится +// если кто может - киньте в fido7.zx.spectrum +// а то мне туда недобраться :) +// http://www.shaos.ru/nedopc + +#include +#include +#include + +char* decode(int c,int col) +{ + static char str[256]; + char *po = str; + *po = 0; + switch(c) + { + case 0x80: strcpy(str," INCLUDE"); break; + case 0x81: strcpy(str," INCBIN"); break; + case 0x82: strcpy(str," MACRO"); break; +// case 0x83: + case 0x84: strcpy(str," RLCA"); break; + case 0x85: strcpy(str," RRCA"); break; + case 0x86: strcpy(str," HALT"); break; + case 0x87: strcpy(str," CALL"); break; + case 0x88: strcpy(str," PUSH"); break; +// case 0x89: +// case 0x8A: + case 0x8B: strcpy(str," DJNZ"); break; +// case 0x8C: +// case 0x8D: + case 0x8E: strcpy(str," LDIR"); break; + case 0x8F: strcpy(str," CPIR"); break; +// case 0x90: +// case 0x91: + case 0x92: strcpy(str," LDDR"); break; +// case 0x93: +// case 0x94: +// case 0x95: +// case 0x96: + case 0x97: strcpy(str," DEFB"); break; + case 0x98: strcpy(str," DEFW"); break; + case 0x99: strcpy(str," DEFS"); break; + case 0x9A: strcpy(str," DISP"); break; + case 0x9B: strcpy(str," ENDM"); break; + case 0x9C: strcpy(str," EDUP"); break; +// case 0x9D: + case 0x9E: strcpy(str," MAIN"); break; +// case 0x9F: + case 0x9F: strcpy(str," (BC)"); break; + case 0xA0: strcpy(str," (DE)"); break; + case 0xA1: strcpy(str," (HL)"); break; + case 0xA2: strcpy(str," DB"); break; + case 0xA3: strcpy(str," DW"); break; + case 0xA4: strcpy(str," DS"); break; + case 0xA5: strcpy(str," NOP"); break; + case 0xA6: strcpy(str," INC"); break; + case 0xA7: strcpy(str," DEC"); break; + case 0xA8: strcpy(str," RLA"); break; + case 0xA9: strcpy(str," RRA"); break; +// case 0xAA: + case 0xAB: strcpy(str," CPL"); break; + case 0xAC: strcpy(str," SCF"); break; + case 0xAD: strcpy(str," CCF"); break; + case 0xAE: strcpy(str," ADD"); break; + case 0xAF: strcpy(str," ADC"); break; + case 0xB0: strcpy(str," SUB"); break; + case 0xB1: strcpy(str," SBC"); break; + case 0xB2: strcpy(str," AND"); break; + case 0xB3: strcpy(str," XOR"); break; + case 0xB4: strcpy(str," RET"); break; + case 0xB5: strcpy(str," POP"); break; +// case 0xB6: + case 0xB7: strcpy(str," EXX"); break; + case 0xB8: strcpy(str," RLC"); break; + case 0xB9: strcpy(str," RRC"); break; + case 0xBA: strcpy(str," SLA"); break; + case 0xBB: strcpy(str," SRA"); break; + case 0xBC: strcpy(str," SLI"); break; + case 0xBD: strcpy(str," SRL"); break; + case 0xBE: strcpy(str," BIT"); break; + case 0xBF: strcpy(str," RES"); break; + case 0xC0: strcpy(str," SET"); break; + case 0xC1: strcpy(str," OUT"); break; + case 0xC2: strcpy(str," NEG"); break; +// case 0xC3: +// case 0xC4: + case 0xC5: strcpy(str," LDI"); break; +// case 0xC6: +// case 0xC7: +// case 0xC8: +// case 0xC9: +// case 0xCA: + case 0xCB: strcpy(str," ORG"); break; + case 0xCC: strcpy(str," EQU"); break; + case 0xCD: strcpy(str," ENT"); break; +// case 0xCE: + case 0xCF: strcpy(str," DUP"); break; + case 0xD0: strcpy(str," (C)"); break; + case 0xD1: strcpy(str," (IX"); break; + case 0xD2: strcpy(str," (IY"); break; + case 0xD3: strcpy(str," AF'"); break; + case 0xD4: strcpy(str," LD"); break; + case 0xD5: strcpy(str," JR"); break; + case 0xD6: strcpy(str," JP"); break; + case 0xD7: strcpy(str," OR"); break; + case 0xD8: strcpy(str," CP"); break; + case 0xD9: strcpy(str," EX"); break; + case 0xDA: strcpy(str," DI"); break; + case 0xDB: strcpy(str," EI"); break; + case 0xDC: strcpy(str," IN"); break; + case 0xDD: strcpy(str," RL"); break; + case 0xDE: strcpy(str," RR"); break; +// case 0xDF: + case 0xE0: strcpy(str," BC"); break; + case 0xE1: strcpy(str," DE"); break; + case 0xE2: strcpy(str," HL"); break; + case 0xE3: strcpy(str," AF"); break; + case 0xE4: strcpy(str," IX"); break; + case 0xE5: strcpy(str," IY"); break; + case 0xE6: strcpy(str," SP"); break; + case 0xE7: strcpy(str," NZ"); break; + case 0xE8: strcpy(str," NC"); break; +// case 0xE9: +// case 0xEA: + case 0xEB: strcpy(str," HX"); break; + case 0xEC: strcpy(str," LX"); break; +// case 0xED: +// case 0xEE: + case 0xEF: strcpy(str," B"); break; + case 0xF0: strcpy(str," C"); break; + case 0xF1: strcpy(str," D"); break; + case 0xF2: strcpy(str," E"); break; + case 0xF3: strcpy(str," H"); break; + case 0xF4: strcpy(str," L"); break; + case 0xF5: strcpy(str," A"); break; + case 0xF6: strcpy(str," P"); break; + case 0xF7: strcpy(str," M"); break; + case 0xF8: strcpy(str," Z"); break; +// case 0xF9: +// case 0xFA: +// case 0xFB: +// case 0xFC: +// case 0xFD: +// case 0xFE: + case 0xFF: strcpy(str," "); break; + default: sprintf(str," |0x%2.2X|",c); + printf("\n\nError %s\n",str); + return NULL; + } + if(col>2) po++; + return po; +} + +int main(int argc,char **argv) +{ + int i,j,k,c; + char hhead[17],name[12],ahead[64],str[256],*po=str; + printf("\n\nH2ASM v1.0, Copyright (c) 2002, Alexander Shabarshin +http://www.shaos.ru\n\n"); + if(argc<3) + { + printf("\n\nH2ASM file.$h file.asm\n\n"); + return 1; + } + FILE *fh = fopen(argv[1],"rb"); + if(fh==NULL) return 0; + FILE *fa = fopen(argv[2],"wt"); + if(fa==NULL) + { + fclose(fh); + return 0; + } + fread(hhead,17,1,fh); + for(i=0;i<8;i++) name[i]=hhead[i]; + int ftyp=hhead[8]; + int fstart=(int)hhead[9]+((int)hhead[10]<<8); + int flen=(int)hhead[11]+((int)hhead[12]<<8); + int blk=hhead[14]; + int check=hhead[15]+(hhead[16]<<8); + for(j=i=0; i<0x0F; ++i) + { + k = hhead[i]; k &= 0xFF; + j += (k * 0x0101 + i); + } + j &= 0xFFFF; + if(j!=check) + { + printf("Illegal checksum in header of hobeta\n"); + } + fread(ahead,64,1,fh); + flen-=64; + printf("Name:%s\n",ahead); + printf("\n"); + int comment,colon,old,quat; + while(1) + { + comment = 0; + colon = 0; + quat = 0; + k = fgetc(fh); + flen--; + j = 0; + old = 0; + for(i=1;i0) str[j++]=' '; + } + else { + if(!comment && !quat && colon==1 && old>=128) str[j++]=' '; + str[j++]=c; + } + if(c==';') comment=1; + if(c=='"') + { + if(quat) quat=0; + else quat=1; + } + } + else { + po = decode(c,++colon); + if(po==NULL) break; + str[j] = 0; + if(colon<2) + { + strcat(str,"\t"); + j++; + } + strcat(str,po); + j += strlen(po); + } + old = c; + } + if(po==NULL) break; + str[j] = 0; + printf("%s\n",str); + fprintf(fa,"%s\n",str); + if(flen<=0) break; + } + fclose(fh); + fclose(fa); + return 1; +} + + +========================================================================== + С уважением, Алексей. + + + + + + + + +--- ifmail v.2.15dev5 + * Origin: OOO Contact company (2:5020/400) + diff --git a/Docs/FORMATS/info_guide/ani.txt b/Docs/FORMATS/info_guide/ani.txt new file mode 100644 index 0000000..c3bb478 --- /dev/null +++ b/Docs/FORMATS/info_guide/ani.txt @@ -0,0 +1,178 @@ +----------------------------- +Формат ani-файлов на спеке +-------------- - - - + ++00 "GIF animation" : сигнатура ++13 =0 ++14 размер по X в знакоместах (1-32) ++15 размер по Y в пикселях (1-192) ++16... данные анимации (кадры) + +анимация представляет собой последовательность кадров +для каждого кадра в начале следуют два байта: + ++0 длительность кадра в 1/50 сек ++1 тип упаковки кадра + +если длительность=255 или тип упаковки нераспознан плейером, то +мультик возвращается на самый первый кадр. + +и конвертер, и бета редактора выбирают наилучший метод упаковки +из 9 имеющихся (по методу сжатия изображения) + +---- тип 0 + +это неупакованый спрайт в линейном формате. Бывает, что кадр ни в какую +ни одним другим методом не жмется. + +При наличии цвета строка атрибутов идёт после каждых 8 строк изображения + +---- тип 1 + +взят из статьи "Сжатие графической информации и что из этого можно получить" +(C) Vitamin/CAIG/2001. +Кадр разбивается на знакоместа (размер по Y увеличивается до ближайшего кратного +8 числа). Рассмотрим упаковку такого знакоместа: +#55,#ff,#55,#ff,#ff,#ff,#50,#05 +начиня со второго байта делаем XOR'инг с предыдущим: +#55,#aa,#aa,#aa,#00,#00,#af,#55 +создадим флаговый байт - отметим 0 байты, которые равны предыдущему, 1 - неравны. +для 1го байта предыдущим считается 0. Только биты в обратном порядке - правый бит +отвечает за первый байт. Получим: +1,1,0,1,0,0,1,1 = #D3 +теперь выводим в поток сначала флаговый байт, а потом - те байты XOR'инга, для +которых установлен бит в флаговом байте: +#D3,#55,#AA,#00,#AF,#55 +в итоге вместо 8 байт знакоместа получили 6 байт в упакованом формате. + +распаковка идет по следующему алгоритму: + +byte=0 +xorbyte=0 +flag=байт флагов +цикл 8 + RR flag + if carry=1 then берем из потока новый xorbyte + byte=byte xor xorbyte + вывод byte на экран +кц + +Количество упакованых блоков, естественно, равно числу знакомест в кадре. +Знакоместа пакуются слева направо сверху вниз (т.е сначала ряд верхних, потом +следующий ряд, и так до низа) + +---- тип 2 + +очень похож на тип 1, но в байте флагов сброшены те биты, соответствующие +нулям в XOR'инге. Т.е для примера из типа 1 флаги будут: +1,1,0,0,1,1,1,1 = #CF +и в поток выдастся +#CF,#55,#aa,#aa,#aa,#af,#55 +тут получилось что выигрыш минимален, но это не значит что он хуже типа 1 + +здесь распаковка такая: + +byte=0 +flag=байт флагов +цикл 8 + RR flag + if carry=1 then byte=byte xor (байт из потока) + вывод byte на экран +кц + +---- тип 3 + +это тот же тип 1, но полученое знакоместо не выводится прямиком на экран, +а накладывается по XOR на соответствующее знакоместо предыдущего кадра. + +---- тип 4 + +аналогично: кадр упакован типом 2 и по XOR накладывается на предыдущий. + +Если кадр меняется не сильно, то в результате его XORинга с предыдущим +кадром получается много пустых знакомест, которые пакуются лучше всего, +и в этом случае тип 3 и тип 4 на голову выше остальных типов упаковки. + +Теперь о новых типах: + +---- типы 5-9 + +это спрессованые типы 1-4. Вводится такое понятие как флаг 2го уровня. +биты этого флага определяют состояние байтов флагов для 8 следующих +за ним знакомест. Если бит=0, то флаг=0 (в этом случае в поток пишется +только цвет, да и то если он есть), а если=1, то флаг не нулевой, и блок +идёт в поток по полной программе (флаг,данные и может цвет) + +На примере: +допустим, упакованый кадр (для широты кругозора будет с неупакованым цветом) начинается так... + +DB %10010000 +DB 1 +DB 2 +DB 3 +DB 4 +DB %00100001,#FF,#55,5 +DB 6 +DB 7 +DB %10000000,#77,1 + +Первый байт - флаг 2го уровня. Смотрим за состоянием битов начиная с нулевого (правого) +0 - блок пустой (типы 5,6) или не меняется (типы 7,8) + из данных блока в потоке только цвет (1) +0 - то же (цвет 2) +0 - то же (цвет 3) +0 - то же (цвет 4) +1 - АГА! блок в поток выложен полностью + берем флаг блока (%00100001) и соответственно типу распаковываем блок. цвет 5 +0 - блок пустой. цвет 6 +0 - блок пустой. цвет 7 +1 - полный блок. (флаг %10000000, данные #77, цвет 1) + +Всё, разобрались с 8 блоками... +Дальше следует то же самое - флаг 2го уровня и всё что к нему прилагается +Конечно, общее число блоков в кадре, не обязательно кратно 8. В таких случаях +ненужные биты последнего флага 2го уровня не учитываются. + +Что мы с этого получаем? Каждый нулевой байт флагов стягивается в 1 бит флага 2го уровня, +но при этом каждый ненулевой распухает до 9 бит. Например, полностью пустой кадр без цвета +ужмется в страшные 64 раза (во-первых пустые знакоместа жмутся в нулевой флаговый байт, а +во вторых каждый нулевой флаговый байт жмется в 1 бит флага 2го уровня) + +---- теперь про цвет + +Под информацию о наличии цвета и его упаковке (да, и это тоже есть!) передают старшие биты +типа кадра. + +b7 = 0 если цветового потока нет (т.е он полностью идентичен потоку предыдущего кадра) + = 1 если он есть +b6 = 0 если цвет не кодируется (т.е за каждым упакованым знакоместом идёт 1 байт цвета) + = 1 если кодируется (пропускаются знакоместа с неизменяющимся цветом) + +а теперь я сказать по бумажка... +при упаковке цвета введен еще и контрольный байт для цвета. весьма и очень похож на +флаг 2го уровня - если в нем бит = 0, то цвет знакоместа не поменялся по отношению +к предыдущему кадру и в потоке отсутствует. А если бит = 1, то вслед за знакоместом +идет его цвет. Как и флаг 2го уровня, флаг цвета встречается каждые 8 знакомест. +Если оба эти флага наличиствуют (напр, тип 5 с упакованым цветом: #С5), то +первым всегда идет флаг 2го уровня, а за ним - флаг цвета. + +Полная схема потока кадра вроде как выглядит так: + +[длительность] +[тип] b0..5-тип упакрвки b6-цвет спрессован b7-цвет присутствует +[флаг 2 уровня] только для типов 5-9 (определяет наличие пар [флаг][блок]) +[флаг цвета] только для спрессованого цвета (определяет наличие компонента [цвет]) +[флаг 1][блок 1][цвет 1] +[флаг 2][блок 2][цвет 2] +[флаг 3][блок 3][цвет 3] +[флаг 4][блок 4][цвет 4] +[флаг 5][блок 5][цвет 5] +[флаг 6][блок 6][цвет 6] +[флаг 7][блок 7][цвет 7] +[флаг 8][блок 8][цвет 8] +[флаг 2 уровня] +... + +Ну и как всегда приоритет в выборе типа упаковки (и изображения, и цвета) - размер... + +Sam Style \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/asc&.W b/Docs/FORMATS/info_guide/asc&.W new file mode 100644 index 0000000..c7cc98c --- /dev/null +++ b/Docs/FORMATS/info_guide/asc&.W @@ -0,0 +1 @@ +ASCLZPAK, MSP1.6, Lazy Pack  ASC Screen Crusher  Один из первых серьёзных экранных паке- ров,ASCLZPAK (1991) определил основные идеи структуры большинства последующих фо- рматов и соответствующих им депакеров.  А именно, хотя данные в файле пока и лежат только байтами,но впервые реализова- на довольно оптимальная последовательность просмотра экрана - ломаными столбцами. При этом экран логически разбивается на3тре- ти и атрибуты,где атрибуты линейны,а трети состоят из столбцов байт. Этот способ даёт возможность сжатия незначительно хуже спо- соба с полными столбцами, зато здесь проще пересчёт линейной модели в реальный экран. Познакомим читателя с идеей линейной модели ZX экрана. Заключается она в том,что каждому адре- су на экране взаимно однозначно соответст- вует виртуальный адрес в линейной модели, причём последовательность адресов экрана, порождаемая порядком просмотра (в данном случае - ломаными столбцами) выглядит на линейной модели последовательностью подряд идущих виртуальных адресов. Т.е.при после- довательном переборе виртуальных адресов линейной модели - адреса на реальном экра- не будут перебираться ломаными столбцами. Разумеется, для этого нужно использовать процедуры пересчета виртуальных адресов в реальные. Как правило, начальные адреса реального и виртуального экранов совпадают, чтобы адреса атрибутов не пересчитывались. Вот как выглядит пересчёт экранного ад- реса из виртуального в реальный поASC'у (страшновато,но примите во внимание,что он первый!): ────────────────────────────────────────── LD A,H AND #58 CP #58 JR Z,atr LD C,A LD A,L AND 7 OR C LD C,A ADD HL,HL ADD HL,HL LD A,H AND #1F LD H,A LD A,L AND #E0 OR H LD L,A LD H,C atr ────────────────────────────────────────── Распаковщик ASCLZPAK,согласно тради- ции,перемещаем и для этого настраивает три пары ячеек программы под текущий адрес. Опасного использования стека нет. Перемещение по экрану ведётся в реаль- ных адресах, и для координации этого (нес- тандартное решение) применено3регистра- счётчика:  A' =8·номер столбца + 3-номер трети;  B' =строка внутри знакоместа;  C' =номер ряда знакомест внутри трети. Упакованные данные располагаются непос- редственно после программы.Формат простой: %0bbbbHHH,LLLLLLLL- ссылка назад, disp= =HHHLLLLLLLL, puts=bbbb+3 %10000000- конец файла %10bbbbbb,байты- bbbbbb байт взять из потока %11bbbbbb,байт- повторить байт bbbbbb+3 раз (можно повторить байт до66раз, т.е. больше, чем через ссылку)  Maxsoft Screen Packer 1.6  Упаковщик Maxsoft Screen Packer 1.6 поддерживает3режима распаковки и в связи с этим3различных распаковщика:  1.Непосредственно на экран, ломаными столбцами;  2.Через буфер ломаными столбцами;  3.Непосредственно на экран в экранной структуре. Последний вариант наиболее прост, но имеет,что понятно, худшее качество сжатия. Распаковка же через буфер ничем принципиа- льно не отличается от распаковки на экран. Поэтому ниже будет рассматриваться именно режим распаковки на экран (1)-RTD в терминологии автора программы (RealTime Depack).Следует отметить, что распаковщик MSP1.6является наиболее запутанным экран- ным распаковщиком из всех, с которыми мы будем иметь дело. Если же сравнивать еще и с кодовыми, то рядом можно поставить разве чтоdeHrust 1.x. В упакованных данных имеется два потока - битовый и байтовый. Выборка битов из по- тока производится парами байт(ADD HL,HL: DJNZ:POP HL:LD B,C),c использованием двух дополнительных регистров:B- счетчик,C- константа16.Начало байтового потока(DEC SP:POP AF)приходится на третий байт фай- ла,после двух первых байт битового потока. В дальнейшем потоки чередуются в зависимо- сти от структуры файла.Битовый поток - уп- равляющий. Для перемещаемости депакера указатель основного стека сохраняется в регистре IY,а не в памяти. Также две смежных яче- йки программы подстраиваются под адрес её расположения: ────────────────────────────────────────── DI CALL #52 DEC SP,SP POP DE LD HL,#110 ADD HL,DE EX DE,HL  LD BC,#98;адресldto ADD HL,BC;(см.ниже) LD (HL),E INC HL LD (HL),D ────────────────────────────────────────── Таким образом реализуется подобие вызо- ва подпрограммыnxtde,которая, как вполне понятно, делает обычную операцию перевода указателя DE на следующий байт экрана по структуре ломаных столбцов: ────────────────────────────────────────── nxtde INC DE LD A,D CP #58 JR NC,atr DEC DE INC D LD A,D AND 7 JR NZ,atr LD A,E ADD A,#20 LD E,A JR NC,sub8 INC E BIT 5,E RES 5,E JR NZ,atr sub8 LD A,D SUB 8 LD D,A  atr JR ...;смещение в этом JR  ;может принимать 2 разл.знач. ────────────────────────────────────────── (атрибуты - линейно). Вызов происходит так: ────────────────────────────────────────── LD A,#8B;смещениеexjr ldto=$+1 ldjr LD (atr+1),A JR nxtde exjr EX DE,HL LD A,#90;смещениеokjr JR ldjr okjr EX DE,HL ────────────────────────────────────────── Указанный фрагмент всегда проходится насквозь, то есть решалась задача именно смещенияОБОИХуказателей -HLиDE(вход- ного и выходного при копировании, соответ- ственно).Это связано с тем,что перемещение по экрану ведётся в реальных адресах,как в ASCLZPAK.  Заголовка у файла нет, следует он непо- средствено за распаковщиком. Первый байт байтового потока (3-й байт файла) является первым байтом экрана,далее по битовому по- току: %0- просто байт (из байтового потока) %100-puts=3 %1010- puts=2 (обратите внимание, код длиннее предыдущего. Это должно означать, что ссылки длиной2встречаютсяреже ссы- лок с длиной3) %1011,байт:-1=конец файла,-2=16-битное значениеputs(POP BC), иначеputs=байт+ +10 (puts=10..263) %1100-puts=4 %1101-puts=5 %11100-puts=6 %11101-puts=7 %11110-puts=8 %11111-puts=9  Если puts не равен2,то производится декодирование старшего байта смещения (по- ложительного disp): %1-0 %0000-1 %0001-2 %00100-3 %00101-4 %00110-5 %00111-6 %010000-7 %010001-8 %010010-9 %010011-10 %010100-11 %010101-12 %010110-13 %0101110-14 %0101111-15 %0110000-16 %0110001-17 %0110010-18 %0110011-19 %0110100-20 %0110101-21 %0110110-22 %0110111-23 %0111000-24 %0111001-25 %0111010-26 %0111011-27 %0111100-28 %0111101-29 %0111110-30 %0111111-31  (ссылки с длиной2 все короткие, т.е. dispH=0) КодыdispH>27нельзя использовать в эк- ране,и это придаёт формату некоторую неже- лательную избыточность. Далее байт из байтового потока опреде- ляет младший байт смещения. Вычитание сме- щения из текущего адреса в виртуальном эк- ране (IXадресует его в линейной модели) реализовано достаточно остроумно: ────────────────────────────────────────── DEC SP POP AF SUB LX CPL CCF LD L,A LD A,HX SBC A,H LD H,A ────────────────────────────────────────── После этого виртуальный адрес вHLпе- ресчитывается в экран и происходит копиро- вание блока. Затем всё описанное повторяе- тся и т.д. Lazy Pack 2.0  К сожалению, этим упаковщиком экранов могут воспользоваться не все - по непонят- ным причинам на большинстве версийTR-DOS программа при сохранении уничтожает ката- лог диска. Но формат заслуживает рассмот- рения.  В формате использованы почти все хоро- шие идеи по сжатию экранов, какие только реализованы вLC5.2,но по длине распако- вщикаLazy 2.0,безусловно, проигрываетLC 5.2. Имеются битовый и байтовый потоки в простейшем варианте: битовый поток извле- кается побайтно в регистрD', B'=счётчик, C'=константа 8 для помещения вB'.Первый байт файла принадлежит битовому потоку. Виртуальный адрес экрана в линейной мо- дели содержится вIX,реальный адрес - в DE. Распаковщик не привязан к экрану, вызы- вается с параметром: HL=адрес упакованного экрана. Не использует стек (входные данные в HL'). Распаковывает на экран#4000,но это число легко исправить на любое кратное #2000.Если немного изменить код, то и на любое кратное#800.Распаковщик достигает перемещаемости, организуя в областиMEMBOT системных переменных бейсика триJPна три внутренние подпрограммы распаковщика,усло- вно назовём ихget,downиbit.Определение своего адреса распаковщик делает черезDEC SP,SP,поэтому нужно проследить,чтобы пре- рывания были выключены.  get(+#aa, #5c97)- извлекает из бито- вого потока в аккумулятор число0...23по следующему дереву: %1-0 %01-1 %0010-2 %0011-3 %000100-4 %000101-5 %000110-6 %000111-7 %00001000-8 %00001001-9 %00001010-10 %00001011-11 %00001100-12 %00001101-13 %00001110-14 %00001111-15 %00000000-16 %00000001-17 %00000010-18 %00000011-19 %00000100-20 %00000101-21 %00000110-22 %00000111-23  down(+#cc,#5c9a)- пересчитать адрес в DE, чтобы он соответствовал следующему байту на экране (в порядке ломаных столб- цов).  bit(+#ea, #5c94)- взять один бит из битового потока (результат во флаге пере- носа). Формат: %1- просто взять байт (из байтового пото- ка); %0- вызываемget. Если результат=7:  Читаем некий byteиз байтового потока.  Если он не-1,то puts=byte+25,иначе  вызываемget(putsH),потом извлекаем из  байтового потокаputsL. Если результат<7:  Прибавляем2,получаемputs=2..8. Если результат>7:  Прибавляем1,получаемputs=9..24. Далее вызываем get(dispH)и берём байт dispLиз байтового потока.Реализуем полу- ченную ссылку и т.д. Специального кода выхода из распаковщи- ка не предусмотрено. Распаковщик сам конт- ролирует окончание экрана.  подготовил А. Кодер \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/chip b/Docs/FORMATS/info_guide/chip new file mode 100644 index 0000000..f422c8c --- /dev/null +++ b/Docs/FORMATS/info_guide/chip @@ -0,0 +1,68 @@ + + ╘юЁьрЄ ьюфєы  Chip Tracker 1.x + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +╨рё°шЁхэшх .CHI + +╠юфєы№ ёюёЄюшЄ шч ўхЄ√Ё╕ї ўрёЄхщ - чруюыютюъ, юЁфхЁ (ёяшёюъ яю- +чшЎшщ), ярЄЄхЁэ√, ё¤ьяы√. ╩рцфр  ўрёЄ№ т√Ёртэхэр яю уЁрэшЎх ёхъ- +ЄюЁют. + +╟руюыютюъ шьххЄ ЁрчьхЁ 1 ёхъЄюЁ: ++0 (8) "CHIPv1.0" ++8 (32) шь  ЄЁхър (Ёєёёъшї сєът т °ЁшЇЄх эхЄ) ++40 (1) tempo + ┬эшьрэшх! ─╬╦╞═╬ ╤╫╚╥└╥▄╤▀, ўЄю tempo шчьхЁ хЄё  т 50-ї фюы ї + ёхъєэф√, їюЄ  тхЁёшш ЁхфръЄюЁр фю 1.3 тъы■ўшЄхы№эю ш яыхщхЁ + 0.01 тхЁёшш шуЁр■Є ёюэу шч-чр фюяє∙хээющ ю°шсъш эхёъюы№ъю ьхф- + ыхээхх! ++41 (1) фышэр ёюэур-1 (яюёыхфэ   шёяюы№чєхьр  яючшЎш ) 0..255 ++42 (1) яючшЎш  чрЎшъыштрэш  (0..255) ++43 (16*4) ярЁрьхЄЁ√ ё¤ьяыют (т яюЁ фъх 0..F): + ++0 (2) яючшЎш  чрЎшъыштрэш  (Ёртэр фышэх фы  эхчрЎшъыхээ√ї) + ++1 (2) фышэр. ╤эрўрыр ьырф°шх срщЄ√, яюЄюь ёЄрЁ°шх. + ─ы  эхшёяюы№чютрээ√ї ё¤ьяыют чфхё№ эєыш. ++107 (31) чрЁхчхЁтшЁютрэю (эєыхт√х срщЄ√). ++138 (16*8) шьхэр ё¤ьяыют (т Єюь цх яюЁ фъх). ╧ю 8 срщЄ эр шь . + ─ы  эхшёяюы№чютрээ√ї ё¤ьяыют чфхё№ яЁюсхы√. + +╤яшёюъ яючшЎшщ шьххЄ ЁрчьхЁ 1 ёхъЄюЁ ш ёюфхЁцшЄ эюьхЁр ярЄЄхЁэют +т яюЁ фъх яЁюшуЁ√трэш . ═юьхЁр ярЄЄхЁэют їЁрэ Єё  ъръ 0..30, +Є.х. эр хфшэшЎє ьхэ№°х, ўхь яюърч√трхЄё  т ЁхфръЄюЁх. ═хшёяюы№- +чютрээ√х яючшЎшш ёюфхЁцрЄ 0. + +╧рЄЄхЁэ√ їЁрэ Єё  фю яюёыхфэхую шёяюы№чютрээюую т ёяшёъх яючш- +Ўшщ. ╩рцф√щ ярЄЄхЁэ чрэшьрхЄ 512 срщЄ, ъюЄюЁ√х ЁрёёьрЄЁштр■Єё  +ъръ фтр чрярЁхыыхыхээ√ї сыюър яю 256 срщЄ. ┬ ярЄЄхЁэх 64 ёЄЁюў- +ъш, ърцфр  шч ъюЄюЁ√ї чрэшьрхЄ 4 яюёыхфютрЄхы№э√ї срщЄр т яхЁтюь +256-срщЄютюь ъєёъх ярЄЄхЁэр ш х∙╕ 4 яюёыхфютрЄхы№э√ї срщЄр тю +тЄюЁюь. ╩рэры√ A,B,C,D їЁрэ Єё  шьхээю т Єръюь яюЁ фъх. ╧Ёшў╕ь +ърэры√ A,D фюыцэ√ шуЁрЄ№ё  ъръ яЁрт√х, р B,C - ъръ ыхт√х. + + ─ы  ърцфющ эюЄ√ ърцфюую ърэрыр: + т яхЁтюь ъєёъх: тю тЄюЁюь ъєёъх: + %nnnnnnCC %ssssPPPP + +nnnnnn - эюЄр (0=яєёЄю, 1=C-1, ... 60=B-5, 63=ярєчр); +ssss - х╕ ё¤ьяы (юс чрЄхы№эю єърчрэ!); +CC - ъюф ъюьрэф√, р PPPP - х╕ ярЁрьхЄЁ: + 00=sample offset. ╤¤ьяы шуЁрхЄё  ё PPPP*512-ую срщЄр, эю т + яюых эюЄ√ фюыцэр ёЄю Є№ эюЄр; + 01=slide down(-) эр PPPP ьшъЁюёряюуют ърцфє■ 1/50 ёхъєэф√; + 10=slide up(+) эр PPPP ьшъЁюёряюуют ърцфє■ 1/50 ёхъєэф√; + ╠шъЁюёряюу - єёыютэр  хфшэшЎр ўрёЄюЄ√ (эх яхЁшюфр!); + ╤ырщф√ фхщёЄтє■Є Єюы№ъю т яЁхфхырї Єхъє∙хщ ёЄЁюўъш. + 11=т ърэрых A - Єхья PPPP (1..15); + т ърэрых D - ъюэхЎ ярЄЄхЁэр (Єхъє∙р  ёЄЁюўър - яюёыхфэ  ); + т ърэрырї B,C - чряЁх∙хэю. + +╤¤ьяы√ їЁрэ Єё  т 8-сшЄэюь схччэръютюь тшфх, яЁшў╕ь ърцф√щ ё¤ьяы +т√ЁртэштрхЄё  яю уЁрэшЎх ёхъЄюЁр (256 срщЄ). ┬ эхшёяюы№чютрээющ +Єръшь юсЁрчюь ўрёЄш яюёыхфэхую ёхъЄюЁр эрїюфшЄё  Єю цх, ўЄю ш т +эрўрых Ўшъыр ¤Єюую ё¤ьяыр. ┼ёыш юэ эх чрЎшъыхэ, Єю Єрь чэрўхэш  +128. ╤юїЁрэ ■Єё  тёх ё¤ьяы√, ъЁюьх яєёЄ√ї. ╠ръёшьєь #BB=187 ёхъ- +ЄюЁют ё¤ьяыют. + +┼∙╕ Ёрч тэшьрэшх! яюёъюы№ъє шч-чр тЄюЁющ ю°шсъш т яЁюуЁрььх Chip +Tracker Compiler v0.01 эх уЁєчшЄ фю ъюэЎр ьюфєыш, шьх■∙шх яєёЄ√х +ё¤ьяы√, яЁшырур■ шёїюфэшъ ¤Єюую яыхщхЁр, т ъюЄюЁюь шьх■Єё  эєц- +э√х шёяЁртыхэш  (ёъюЁюёЄ№ т Єюь ўшёых). diff --git a/Docs/FORMATS/info_guide/dos0.W b/Docs/FORMATS/info_guide/dos0.W new file mode 100644 index 0000000..5794d55 --- /dev/null +++ b/Docs/FORMATS/info_guide/dos0.W @@ -0,0 +1 @@ +Форматы дисков, имеющие FAT  То, что вы хотели знать о дисковых форматах, но не знали, у кого спросить by Nuts -------------- История версий --------------  xx.xx.1998- Первая редакция в формате 42 символа в строке.  хх.хх.1999- Журнальная редакция в формате 32 символа в стро─ ке. ОписаныMS-DOS, iS-DOS, AGAT, DOS 2.9-РАДИО-86РК,SP-DOS- ОРИОН-128,AO-DOS 2.02 (и совместимые с ней MicroDOS, NORD, NORTON, MK-DOS) -BK-11M,CP/M (MICRODOS) -КОРВЕТ, РОБОТРОН, ОРИОН-128, PROFI, ATM-TURBO, ASM (ASC SOUND MASTER), RT11 (РАФОС,ФОДОС, ОС ДВК)-УКНЦ, СМ, ДВК, "Электроника-60М",NEWDOS - письмецо из Нета.  01.06.2000 - Свободно распространяемая версия, 64 символа в строке. Добавлено описаниеAN-DOS(БК-11М).Всего 11 систем.  01.09.2000 - Переформатировано в редакторе Слово и Дело v6.40. Добавлено описание Profi DOS, VFAT (расширение FAT) - длинные имена вWindows.Журнальная версия, кажется, вскоре тоже увидит свет.  14.10.2001 - Журнальная версия вышла в свет. Добавлено описание CP/M 2.3byMichael Markowsky,1995,CP/MиMX-DOSдля компьютераСпециалист-МХ,диски программыRealtime Audio Player, 2000, 2001,Halloween and Triumph.  Ред.:ОписаниеMB02 см. вAdventurer #13.ОписаниеZXVGS- в Inferno#4.Описание CacheVox- в IG#5.У меня также имеется документация поDISCiPLE/+Dна английском, она, возможно, будет опубликована в следующем номере.  18.06.2005(Alone Coder) - Добавлен новый формат каталогов iS-DOS,исправлены многие опечатки.Справочник разбит на4части.  ----------  MS-DOS  ---------- Начнем с того, что все параметры диска хранятся в0-ом секто─ ре 0-ой дорожки.Только дело в том,что количество параметров на─ ращивалось вместе с версиямиMS-DOS,и только в 4-ой версии мож─ но всё узнать о диске. Но поскольку форматерFLOPPY FORMATИвана Рощиназаписывает в этот так называемый BOOT-сектор то же, что и самаMS-DOS,то забудем об этой проблеме и вернёмся к содержанию этого сектора, в чём поможет таблица. ┌────────┬─────┬───────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ДЛИНА│НАЗНАЧЕНИЕ │ ├────────┼─────┼───────────────────────────────────────────────┤ │0 │3 │Команда перехода на код загрузчика │ │3 │8 │Имя программы - форматера │ │#0b │2 │Длина сектора в байтах │ │#0d │1 │Количество секторов в кластере │ │#0e │2 │Количество зарезервированных секторов (начиная │ │ │ │с начала диска) │ │#10 │1 │Количество FAT │ │#11 │2 │Максимально возможное количество файлов в │ │ │ │корневом каталоге │ │#13 │2 │Общее количество секторов на диске │ │#15 │1 │Байт - описатель типа диска │ │#16 │2 │Число секторов в одной FAT │ │#18 │2 │Количество секторов на одной дорожке │ ├────────┼─────┼──────────────────────────────────────> DOS 3.0│ │#1A │2 │Количество головок на диске │ │#1C │2 │Количество спрятанных секторов │ │#20 │4 │Если размер диска >32M,то его размер в секторах│ ├────────┼─────┼───────────────────────────────────────>DOS 4.0│ │#24 │1 │Номер диска (только винчестера) - его номер в │ │ │ │BIOS │ │#25 │1 │Резерв │ │#26 │1 │Сигнатура расширенного сектора, т.е. только то,│ │ │ │что пишет DOS 4.0 и выше, содержит здесь #29 │ │#27 │4 │Серийный номер - пишется при форматировании │ │ │ │диска, содержит индивидуальный номер и дату │ │#26 │11 │Имя диска │ │#36 │8 │Содержит "FAT12 " или "FAT16 " │ └────────┴─────┴───────────────────────────────────────────────┘ Что же обозначают эти цифры... Я старательно буду умалчивать о работе с винчестером. Это не потому, что я по каким-либо соображениям хочу это утаить. Наобо─ рот, ситуация с винчестером весьма поучительна для установки его под другие системы, но и гораздо более сложна для того, чтобы описывать её в обзоре дискетных форматов: там ведь тебе и проб─ лемы наращивания объема,и главный загрузочный раздел с возможно─ стью размещения нескольких операционных систем, и куча форматов при работе с уплотненным диском... А я рассказ веду о дискетах.  Ред.:СтатьяZET-9в этом номере дополняет информациюNuts'а как раз по вопросу о файловой системе на винчестерах. Для начала немного теории. Операционные системы в большинстве своём оперируют не с секторами и дорожками, а со смещениями в абсолютных секторах. Т.е. понятие "дорожка" практически не упот─ ребляется, а существует куча секторов, начиная с нулевого и до какого-то конечного, может быть, стотысячного. Если, скажем, на диске10секторов на одной логической дорожке,считая с нулевого, то нанулевой логической дорожкебудут находится секторас 0-го по 9-ый,на 1-ой логической дорожке-с 10-го по 19-ый,и так далее. Более того,чтобы ограничить количество бит,задающих номер абсолютного сектора, весь диск разделяется на блоки по несколько секторов. Причем нулевой блок может находиться и не в начале ди─ ска - может начинаться с какого-либо абсолютного сектора. Первые сектора как раз и являются загрузочными и информационными. ВMS-DOSтакие блоки называются кластерами. Количество секто─ ров, приходящихся на один кластер, можно узнать из загрузочного сектора. Номер логического сектора, на котором располагается ну─ левой кластер,приходится подсчитывать на основе данных из загру─ зочного сектора, но об этом позже. Такая хитрая разбивка служит для того,чтобы всегда знать сво─ бодные места на диске, и разные куски одного файла записывать в различные области диска, куда только возможно, и собирать его, даже если он не находится на последовательных секторах. Поэтому можно долго не заботиться об очистке диска от удалённых файлов. Чтобы знать место расположения каждого куска файла,служит та─ блицаFAT.Каждый её элемент, начиная с первого, содержит ссылку на тот элемент этой таблицы,где продолжается файл,номер кластера которого соответствует этому элементу таблицы. То есть, если мы узнали,что начало файла находится,скажем,на пятом кластере,то мы загружаем его и смотрим на пятый элемент таблицыFAT.А там зна─ чится, положим,число25.Ну тогда мы спокойно читаем25-ый клас─ тер.И смотрим 25-ый элемент таблицы.А он указывает на номер следующего кластера - он же номер следующего элемента в таблице или число, означающее, что этот кластер является последним для этого файла и больше ничего читать не надо. Он также может ука─ зывать, что данный сектор свободен или помечен как дефектный. Проблема лишь в том, что на дискетах размер одного элемента равен12 битам,и половинки каждого второго байта относятся одна к предыдущему байту, а другая - к следующему. Для определения содержимого элемента таблицы нужно:  1.Умножить данный номер кластера на1.5,получим смещение до пары байтов в таблице, которая содержит номер следующего класте─ ра;  2.Если предыдущий кластер имел нечётный номер (определяется по нулевому биту в номере кластера),то надо использовать12мла─ дших битов этой пары, иначе -12старших. Если полученное значение равно0,то этот кластер свободен. Если #FF8 - #FFF,то это последний кластер файла.#FF0 - #FF7- зарезервированные сектора, в том числе:#FF7- сбойный кластер. Только0-ой элемент этой таблицыявляется исключением. Он со─ держит копию байта-описателя данного диска. Например,для дисков, которые можно прочитать на Спектруме(Ред.:имеется в виду, на Спектруме без доработки для чтения HD-дисков):  ┌─────┬────────────────────────────┐  │Байт:│ Тип диска: │  ├─────┼────────────────────────────┤  │#f9 │ 3'5 720 kb 2SD 9SEC 80TRKS │  │#fa │5'25 320 kb 1SD 8SEC 80TRKS │  │#fb │5'25 640 kb 2SD 8SEC 80TRKS │  │#fc │5'25 180 kb 1SD 9SEC 40TRKS │  │#fd │5'25 360 kb 2SD 9SEC 40TRKS │  │#fe │5'25 160 kb 1SD 8SEC 40TRKS │  │#ff │5'25 320 kb 2SD 8SEC 40TRKS │  └─────┴────────────────────────────┘ Но такие байты имеют и многие другие диски, в том числе и не со стандартной разбивкой. На самом деле в этих байтах-описателях типа используются толькомладшие 3 бита,а старшие биты всегда равны единице. В этом байте... 0-ой бит: 1 - двухсторонний;  0 - односторонний. 1-ый бит: 1 - 8 секторов на дорожке;  0 - не 8. 2-ой бит: 1 - постоянный диск;  0 - сменный диск. Для определения началаFATв загрузочном секторе указывается число зарезервированных и загрузочных секторов. Там же можно найти и количество таблицFAT- для надежности делают несколько копий. После них идет корневой каталог, размер которого можно высчитать из количества файлов в нем. Корневой каталог всегда присутствует на диске. В нем содер─ жится информация о файлах и подкаталогах 1-го уровня. Последние представляют из себя обыкновенные файлы, но с нулевой длиной, их размер определяется по таблицеFAT,и они могут быть сегменти─ рованы - разбросаны по всему диску. В начале каждого подкаталога есть описатели двух файлов:"."и"..". Первый повторяет описа─ ние данного каталога в каталоге более низкого уровня и дублирует информацию об этом каталоге. Второй - содержит описание самого предыдущего каталога-прародителя. Оба они служат для удобной на─ вигации по диску. Если каталог-прародитель лежит в нулевом клас─ тере - то значит, это корневой каталог. В этом каталоге таких ссылок нет, но если диск загрузочный, то там находятся описатели системных файлов. Описатель любого файла или каталога занимает32байта: ┌─────────┬────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ:│ НАЗНАЧЕНИЕ: │ ├─────────┼────────────────────────────────────────────────────┤ │0-7 │Имя файла или каталога большими буквами, остаток│ │ │заполнен пробелами. Если 0-ой байт равен #E5, то│ │ │файл удалён, если #05, то код первой буквы файла│ │ │действительно #E5. Если 0 - место никогда не│ │ │использовалось - конец каталога. │ │8-10 │Расширение. │ │11 │Атрибуты файла. Биты: 0 - только для чтения; 1 -│ │ │скрытый файл; 2 - системный файл; 3 - имя диска в│ │ │первых 11-ти байтах, только в корневом каталоге,│ │ │начального сектора и длины не имеет; 4 - подкаталог,│ │ │не использует поле длины, 5 - архивный файл:│ │ │заархивировали его (для сохранности) или нет. │ │12-21 │Резервируются. │ │22-23 │Время создания или последней коррекции файла,│ │ │хранится как 16-ти битное слово: биты 15-11 - часы,│ │ │биты 10-5 - минуты, биты 4-0 - секунды/2. │ │24-25 │Дата создания файла или его последней коррекции,│ │ │хранится как 16-ти битное слово: биты 15-9 - год,│ │ │начиная с 1980 и кончая 2099 (!!!); биты 8-5 -│ │ │месяц, биты 4-0 - день. │ │26-27 │Номер первого кластера файла, начиная с младшего│ │ │байта. Первые два кластера занимает корневой│ │ │каталог, все файлы начинаются со второго кластера. │ │28-31 │Размер файла в байтах. Первая пара байт содержит│ │ │младшие разряды значения, обе пары байт начинаются с│ │ │младшего байта. Всего длина может достигать до 4│ │ │гигабайт, но на формате 830k используется 20 бит│ │ │максимум. │ └─────────┴────────────────────────────────────────────────────┘ Вот и всё,что надо для работы с диском. Для перехода от номе─ ра кластера к абсолютным секторам нужно отнять2от номера клас─ тера,умножить на количество секторов в кластере и прибавить сме─ щение до второго кластера в абсолютных секторах.Затем полученное число нужно поделить на количество секторов на дорожке. В резу─ льтате получим логическую дорожку, где находится кластер, а в остатке - сектор. Замечу, что в большинстве виденной мною литературы предлага─ лось считать корневой каталог, т. е. несколько самых первых кла─ стеров,- вроде бы и не кластерами. Взамен вводилось понятие на─ чала данных: следующий после каталога второй кластер считается вроде как нулевым, ну, и,соответсвенно,все номера кластеров счи─ таются от него, при помощи приплюсования-минусования размера ка─ талога. Словом, только лишние вычисления. На мой взгляд, если каталог лежит в нулевом кластере, то его и нужно считать за на─ чало данных, а не за что-то особенное. Так сделано, например, в CP/M. Но на самом деле корневой каталог не считается первыми двумя кластерами, а именно особой областью диска, размер которой не кратен размеру кластера. Именно поэтому данные начинаются со второго кластера и смещение до него определяется суммой абсолют─ ного начала корневого каталога и его размера. И приходится производить вычисления. Со времени появления расширений данной файловой системы, ис─ пользуемых в Windows 9X,появилась ещё одна проблема - длинные имена. Старая добраяMS-DOSсправляется с подобной напастью - и, хотя имена файлов выглядят не совсем обычно, тем не менее, ни─ какого мусора между ними не возникает, чего нельзя сказать о многочисленных конвертерах и читалках. Если вкратце, то глюки эти происходят оттого, что в некорректно написанных программах не отлавливаются заголовки, у которых в байте флагов установлен третий бит. Но мне было уж очень интересно,как же всё-таки хранятся длин─ ные имена. Самое интересное, что вопрос этот оказался довольно недокументированным (малопопулярным?) (Ред.:закрытым. Научно─ техническая информация, по законам западного рынка,- объект тор─ говли).Гипотезы я слышал самые фантастические, но точный ответ дала мне документация для ОСLinux,которая поддерживает неско─ лько файловых систем (в основном редкостных и малозадокументиро─ ванных),в том числеVFAT(на которую как раз документашка оказа─ лась). Описание это носит название:  NOTES ON THE STRUCTURE OF THE VFAT FILESYSTEM ---------------------------------------------------------------- (This documentation was provided by Galen C. Hunt and lightly annotated by Gordon Chaffee). Привожу неточный и не дословный перевод:  Данный документ содержит очень упрощенный технический обзор исследований расширенной файловой системы FAT, используемой в Windows NT 3.5and Windows 95. Никакой гарантии относительно корректности информации не дается.  Extended FAT file system почти идентична FAT file system, применяемой в более ранних версияхMS-DOS.Наиболее важным отли─ чием является поддержка имен длиной до255символов, включая пробелы, большие и малые буквы.  Далее следует описание традиционного хедера дляWindows 95: ┌─────────┬────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ:│ НАЗНАЧЕНИЕ: │ ├─────────┼────────────────────────────────────────────────────┤ │0-7 │Имя файла │ │8-10 │Расширение │ │11 │Атрибуты файла │ │12 │Регистр для имени и расширения │ │13 │Время создания (миллисекунды) │ │14-15 │Время создания │ │16-17 │Дата создания │ │18-19 │Дата последней модификации │ │20-21 │Зарезервировано │ │22-23 │Time stamp ??? │ │24-25 │Date stamp ??? │ │26-27 │Номер первого кластера файла │ │28-31 │Размер файла │ └─────────┴────────────────────────────────────────────────────┘  Байт регистра указывает - должны ли быть заглавными буквы имени и/или расширения. Он имеет несколько разные значения в Windows 95иWindows NT.Имя файла в стандарте 8.3, записанное в Windows NTмаленькими буквами, будет показано вWindows 95боль─ шими буквами.  Всё это распространенная и доступная информация.  Вместе с extended FAT system Microsoft добавляет дополни─ тельные заголовки в каталоги (если оно не укладывается в стан─ дарт 8.3), может даже и по нескольку для каждого файла - в зави─ симости от длины имени. Далее эти дополнительные заголовки бу─ дут называться слотами. Упрощенно, слот есть специальный элемент каталога, содержащий до13символов расширенного имени. Их мож─ но представить как дополнительные метки к заголовку соответ─ ствующего файла.Microsoft предпочитает представлять стандар─ тный заголовок 8.3 файла как сокращенное имя(alias),а дополни─ тельные слоты - как имя файла.  Структура слота такова. ┌─────────┬────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ:│ НАЗНАЧЕНИЕ: │ ├─────────┼────────────────────────────────────────────────────┤ │0 │id - идентификатор слота │ │1-10 │5 символов имени (из 13-ти) │ │11 │Атрибут (всегда #0f, см. ниже) │ │12 │Резерв (0) │ │13 │Контрольная сумма alias'а (заголовка 8.3) │ │14-25 │Еще 6 символов имени │ │26-27 │Первый кластер файла (всегда 0, см. ниже) │ │28-31 │Еще 2 символа имени │ └─────────┴────────────────────────────────────────────────────┘  Такая разбивка слотов выглядит несколько иррационально, пото─ му чтоMicrosoftпыталась обеспечить совместимость с более ста─ рыми версиями своего программного обеспечения. Для этого ис─ пользуются следующие приёмы:  1)Байт атрибутов в слоте равен#0F.Это означает, что данный файл является меткой, спрятанным, системным, защищённым от запи─ си, чтобы он игнорировался этим старым ПО как метка диска, хотя, на самом деле, у метки установлен только один бит;  2)Начальный кластер установлен в 0, что невозможно для ДОС'овского файла.  Для того, чтобы старое ПО могло работать с каталогами, а но─ вое - определить,к какому alias относятся расширенные слоты,при─ меняются следующие методы:  1)Размещение. Слоты файла всегда связаны со своимalias.Вдо─ бавок, у каждого слота есть идентификатор id, который показы─ вает порядок этого слота в расширенном имени. Ниже следует при─ мер файла"My Big File.Extension which is long",с порядком сле─ дования хедеров:  <слот #3, id = 0x43, символы = "h is long">  <слот #2, id = 0x02, символы = "xtension whic">  <слот #1, id = 0x01, символы = "My Big File.E">  <нормальный хедер, имя = "MYBIGFIL.EXT">  Это означает, идут с последнего по первый. Слоты пронумерова─ ны с 1 до N. К N'ому слоту добавлено число64=#40,что означает, что этот слот последний.  2)Контрольная сумма. Каждый слот содержит контрольную сумму своегоalias'а8.3, вычисленного по следующему алгоритму:  for (sum = i = 0; i < 11; i++)  {sum = (((sum&1)<<7)|((sum&0xfe)>>1)) + name[i]}  Что означает примерно следующее (для всех11символов): у контрольной суммы оставить0-йи7-йбиты, поменять их местами и добавить код данного символа.  Все расширенные имена хранятся в кодеUnicode,по ДВА байта на ОДИН символ. Конец имени - два нуля, а остаток заполняется байтом#FF. Такой вот перевод. Добавлю, что, форматируя диски вМасдае95, я получил диск, у которого был сброшен4-й битмедиадескриптора (см. выше). Это, очевидно, и является признаком расширенной фай─ ловой системыFAT.  ------------------------  ASC SOUND MASTER  ------------------------ Это вообще-то музыкальный редактор, но вспомнил я,что с неко─ торых версий он вообще-то обладает ещё и своим, известным только автору, дисковым форматом. В редакторе было упоминание о некой версии CP/M того же автора. Системы этой я и в жизнь не видел, но я не нашел причины,чтобы наASM'овских дисках полазать. Соб─ ственно говоря,мне нужды до такого дела нетуть.Да вот компилиро─ вать музоны не всегда нужно под адрес 49152. Мудрые кодеры, надо думать,написали бы свой компилятор - ведь немало их подSTпона─ писали. А вот лазить по хитрому диску никто не захотел - написа─ ли рекомпилер под другой адрес. Я тоже особо возиться не стал, так что, может,в нижеследующем описании шо не так - не проверял пока особо-то. Короче говоря, разбивка диска такая. Нулевая дорожка совсем хитрая:  Первые 8 секторов - по 512 байт;  Последний - на 1024 байта. Остальные дорожки - нормально,10 секторов по 512 байт. На нулевой дорожке располагается каталог. Сколько секторов он может занимать, я не знаю,и при мне последний сектор всегда пус─ товал. На запись в каталоге приходится по16байт. Нулевая запись - первые16байт диска - особые.Там содержится строка:"ADS 1.00"+ +" (C) ASC"- по ней легко определить принадлежность диска к от─ ряду "музыкальных". В остальных записях о файлах: ┌────────┬─────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ЗНАЧЕНИЕ │ ├────────┼─────────────────────────────────────────────────────┤ │0-7 │Имя. │ │8-10 │Расширение. Оно может быть PAT, SAM, IMG, а может - и│ │ │ещё какое. │ │11-12 │(младшие 12 бит) - номер первого блока(кластера) фай-│ │ │ла.О этом см. ниже.Остальные биты 12-го байта - приз-│ │ │нак состояния файла, а именно, если там содержится│ │ │число: 1 - это нормальный файл; 5 - защищённый от│ │ │удаления или записи файл; 0 - удалённый файл. │ │13-14 │Длина файла в байтах. │ │15 │Всегда #00 !!! │ └────────┴─────────────────────────────────────────────────────┘ Теперь пару слов о сегментации. Структура диска удивительно похожа на дискMS-DOS.Куски файла могут занимать произвольное место на диске, а в записи о файле указывается ссылка на первый кусок. Только на данном формате диска размер куска равен одному сектору, и поэтому его номер можно называть номером кластера, номером блока или смещением до абсолютного сектора. Нахождение разбросанных по диску таких вот кусков осуществляется при помо─ щи таблицы, аналогичной FAT-12.Две копии этой таблицы, разме─ ром по5секторов каждая, занимают всю первую дорожку. Когда нужно прочитать файл,номер первого куска которого запи─ сан в каталоге, читают вначале этот первый кусок, а затем опре─ деляют в таблице, что содержится в ячейке с номером,равным номе─ ру первого куска файла. А там содержится номер второго куска. Теперь его читают и повторяют процесс с третьим. И так до тех пор, пока в таблице будет не номер следующего куска, а признак конца файла. При записи в таблице ищут ячейки,содержащие признак незанято─ го места на диске, и записывают в туда номер следующего найден─ ного пустого места, а на сектор соответствующего номеру ячейки таблицы записывают нужную часть файла. Проблема в том, что ячейки имеют размер12 бит = 1.5 байта, поэтому приходится извлекать нужную половинку из трех байт кома─ ндами сдвига. Первая ячейка таблицы всегда содержит число#AC- медиадес─ криптор дляMS-DOS:  #000-признак пустого места на диске;  #FFF-признак конца файла - последняя ячейка,которая содержит номер куска данного файла - последнего куска. Словом,объяснить на словах это трудно. Ежели кому надо разби─ раться - изучайте на практике, а краткое описание я закончил.  ------------------------  Profi DOS  ------------------------ Продолжая разговор о дисках,в которых структураFATаналогич─ наMS-DOS,упомяну и про эту систему. Диски для неё полностью копируют структуруMS-DOS.Системные (загрузочные) файлы хранят─ ся на строго фиксированных местах. Упоминавшиеся в документаш─ ках USER области пока замечены не были, а посему не могу ска─ зать, где в хедере файла хранится номер области, если он хранит─ ся вообще. (Про FAT-системуAN-DOSдляБКсм. в 4-й части) \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/dos1.W b/Docs/FORMATS/info_guide/dos1.W new file mode 100644 index 0000000..3bb29d6 --- /dev/null +++ b/Docs/FORMATS/info_guide/dos1.W @@ -0,0 +1 @@ + iS-DOS & CP/M ...O дисковых форматах...  (продолжение)  -----------  iS-DOS  ----------- Как свидетельствует программаFLOPPY FORMATИвана Рощина,эта DOS поддерживает восемь разбивок диска, которые могут очень даже сильно отличаться друг от друга, т. к. размер сектора может быть как256,так и1024байта (у запускаемых дисков). Количес─ тво секторов при этом будет16или5соответственно. Диск при этом может быть как односторонним, так и двухсторонним. Внимания заслуживает порядок секторов на дорожке. Поскольку диск может быть автозапускаемым, то,хотя на нём и находится по5 секторов на дорожке, последний из них имеет номер9. Теперь рассмотрим структуру диска. Её описание находится на диске с ассемблером iS-DOS.Но оно рассчитано на программиста, работающего непосредственно в этой DOS. Здесь же я изложу основ─ ные факты из этого описания. "Внутри" iS-DOSабсолютно ВСЕ устройства хранения информации представляются набором блоков,по256байт каждый,с номерами от 0 до некого максимального. Положение любого файла и вообще любого нужного места на диске задается смещением относительно начала диска -0-го блока.И измеряется это смещение в этих же блоках по 256байт. Т. е. не так важен размер сектора. Для определения дорожки и сектора можно воспользоваться формулами:  ДОР. = INT(СМЕЩ./ 5120) (или /4096)  СЕКТ. = INT((СМ.-ДОР.*5120)/1024) (или /4096) А остаток от разности между смещением до сектора и смещением до нужного блока даст нам смещение внутри 1024-байтного сектора.  0-ой блок- это 0-ой сектор 0-ой дорожки. В нём содержится: ┌────────┬─────┬───────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ДЛИНА│НАЗНАЧЕНИЕ │ ├────────┼─────┼───────────────────────────────────────────────┤ │0 │2 │Резерв. │ │2 │8 │Имя устройства (диска). │ │10 │3 │Признак iS-DOS: "DSK". По нему можно определить│ │ │ │принадлежность диска к этой системе. │ │13 │3 │[Признак iS-DOS 2000: тоже "DSK".] │ │16 │2 │Резерв. │ │18 │2 │Объем диска в блоках. │ │20 │2 │Номер 0-го блока главного каталога. Для дисков │ │ │ │80TR/DS обычно 3-ий, т.е. тот же 0-ой сектор │ │ │ │для 1024 байтовых секторов. Или же 3-ий - │ │ │ │для 256 байтовых. │ │22 │1 │Количество цилиндров на устройстве (для HDD). │ │23 │1 │Тип диска - биты (0/1): │ │ │ │0-ой - 40/80 дорожек; │ │ │ │1-ый - 1/2 стороны. │ │24 │1 │Размер сектора. 1/2/4: 256/512/1024 байта. │ │25 │1 │Количество секторов на дорожке. │ │26 │1 │Резерв. │ │27 │1 │Контрольная сумма файла ????_dos.sys. Это нечто│ │ │ │вроде MAGIC'а - копия памяти компьютера с │ │ │ │системой. Загружается и разгружается он особыми│ │ │ │программами, а его параметры хранятся в особом │ │ │ │месте. ???? - четыре любых символа. │ │28 │2 │Резерв. │ │30 │2 │Дата (чего ???). │ │32 │32 │Описатель файла(см.ниже) ????_dos.sys (см.выше)│ │64 │16 │Таблица номеров секторов. │ └────────┴─────┴───────────────────────────────────────────────┘  1-ый блок содержитбит-картуустройства: каждый её бит соот─ ветствует своему блоку на устройстве.1 бит/блок: 0 - свободен, 1 - занят. Подобная таблица - битовая карта диска, часто применяется в различных операционных системах. Теперь поговорим о файлах и каталогах. Мы уже знаем,где нахо─ дится главный каталог. Полезно вспомнить, что файлы вiS-DOSбы─ вают не только сегментированными, как вMS-DOS,но и непрерывны─ ми, как вTR-DOS. Т. е. файл может быть разбросан кусками-сегментами по всему диску, будет долго грузиться, и восстановить его после того, как запись в каталоге о нем будет испорчена, крайне затруднительно. Но забот о чистке диска от удалённых файлов почти не станет. Также файл может быть непрерывным, грузиться будет быстро, но проблемы с командой MOVE или,точнее, SQUEEZE (так она называ─ ется в HOBET'е на ПЦ) знакомы всем спектрумщикам (если они не работают под эмулятором). Правда,по некоторым сведениям,эта про─ блема разрешима (см. ниже),но как - пока неизвестно. Большинство (ВСЕ?) конверторы IBM<>ZX работают по принципу условной последо─ вательности секторов файла, а если писать свой конвертер IS<>TR, то можно сделать этот файл и несегментированным, но для полноты картины надо рассказать, каким образом системаiS-DOSсобирает сегменты своих файлов с диска. Так вот, в каталоге описатель такого файла содержит ссылку не на начальный блок файла как такового, а ссылку на особый блок -Таблицу Размещения Секторов Файлаили, как его называют в фир─ менном описании,Блок Описателя Сегментов Файла.0-ой его байт содержит количество сегментов файла - на сколько частей он раз─ бит. Остальные 255 байт содержат853-байтовых записей, каждая из которых описывает свой сегмент файла. Первые два байта каж─ дой содержат номер нулевого блока этого сегмента, а третий - число блоков в сегменте. И для чтения нужного файла нужно сначала определить начало этогоОписателя,затем считать его. Потом организуется цикл по количеству сегментов. По первым двум байтам каждой тройки опре─ деляется начало конкретного сегмента и обыкновенным образом счи─ тывается последовательность секторов,содержащих блоки этого сег─ мента. При необходимости нужно позаботиться об исключении ненуж─ ных остатков первого и последнего секторов. Для последнего бло─ ка это можно сделать простой манипуляцией с адресом загрузки следующего сегмента. А вот с первым сложнее. Придется делать пе─ ремещения командойLDIRили читать сектора в промежуточный бу─ фер. Но в любом случае размер1024байт придется учитывать. Для сохранения файлов придется также побеспокоить битовую ка─ рту диска. Нужно искать незанятые блоки - соответствующий им бит будет сброшен. Его нужно установить, затем заполнить нужную за─ пись вБлоке Описателяили добавить блоков к старой записи. Де─ лать эти операции лучше в ОЗУ. Каталоги, как ни странно, представляют из себя почти обычные файлы, но у них два описателя: внешний - в каталоге-родителе и внутренний - в нем самом. У главного каталога только внутрен─ ний описатель - его 0-ой файл.Именно во внутреннем описателе содержится информация количестве файлов и уровне вложенности. Кроме того, запись о файле/каталоге содержит определяющую метку, показывающую принадлежность файла к определенной группе (см. ни─ же). Следует также помнить об ограничениях: кол-во файлов в ка─ талоге - до128,уровень вложенности - до6.Каталог тоже может быть сегментированным или несегментированным. Теперь подробнее о структуре описателя файла. Замечу, что в описании структуры записи внутреннего описателя каталога мне не всё стало ясно. ┌────────┬─────┬───────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ДЛИНА│ОПИСАНИЕ │ ├────────┼─────┼───────────────────────────────────────────────┤ │0 │8 │Имя файла │ │8 │3 │Тип файла │ │11 │1 │Регистр состояния файла: │ │ │ │бит (0/1) │ │ │ │0 - удалён/существует │ │ │ │2 - защищён от чтения (1) │ │ │ │3 - защищён от записи (1) │ │ │ │4 - видимый/скрытый файл │ │ │ │5 - файл/каталог (корневой файл) │ │ │ │6 - сегментированный/несегментированный │ │ │ │7 - защищён от удаления (1) │ │12 │2 │Адрес загрузки по умолчанию │ │14 │3 │Длина │ │17 │2 │Номер Блока Описателя Сегмента или 0-го блока │ │ │ │файла - если файл непрерывен │ │19 │1 │"Special" │ │20 │6 │Резерв │ │26 │2 │Контрольная сумма файла │ │28 │2 │Время │ │30 │2 │Дата │ └────────┴─────┴───────────────────────────────────────────────┘ Дата и время кодируются,как вMS-DOS.Контрольная сумма, воз─ можно, тоже. Вот что известно про описатель внутреннего каталога: ┌────────┬─────┬───────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ДЛИНА│ОПИСАНИЕ │ ├────────┼─────┼───────────────────────────────────────────────┤ │0 │8 │Имя текущего каталога. │ │8 │3 │Его тип (пробелы). │ │11 │1 │CSR (атрибуты ???) каталога. │ │12 │2 │CBNN (похоже, начальный блок) каталога - │ │ │ │прародителя. │ │14 │2 │Размер каталога (в байтах). │ │16 │1 │Уровень вложенности каталога (до 6) │ │ │ │ [или 0 для iS-DOS 2000]. │ │17 │2 │Номер блока описателя сегмента. (Это интересно.│ │ │ │Каталог может быть непрерывным, тогда здесь │ │ │ │может быть и номер первого блока. Но тогда для │ │ │ │определения в CSR должны быть биты состояния.) │ │19 │2 │Номер 0-го блока каталога (это тогда зачем?). │ │21 │1 │Общее число файлов. │ │ │ │(включая сам каталог и удалённые). │ │22 │1 │Число файлов │ │ │ │(без каталога и удалённых). │ └────────┴─────┴───────────────────────────────────────────────┘  Ред.:Структура каталогов на дискахiS-DOSпоздних версий (к ним относятся"Open Letters") несколько изменилась. ПлагинxISD HalfElf'а к Far'у понимает "новый"iS-DOS (2000)и позволяет копировать с/на него файлы. Дополнение по исходникамxISD: │23 │1 │levelChic (уровень вложенности каталогов до 32)│ │24 │6 │Резерв. │ │30 │2 │Дата. │ └────────┴─────┴───────────────────────────────────────────────┘ Цитата изА. Леонтьева:"24.12.96 уровень вложенности каталога перенесен из 16-го байта описателя файла в 23-ий,т.к.16-ый байт, строго говоря, является старшим байтом длины файла и, хотя ката─ логи и не бывают длиной более 16 блоков, но при отладке программ бывали случаи,когда это совмещение изрядно вредило.<...>в ста─ рой системе через открытый как файл каталог становятся доступны для чтения и, что самое страшное, для записи блоки, находящиеся далеко за пределами каталога!"  -----------------------  CP/M (MICRODOS)  ----------------------- В том или ином виде эта система использовалась на огромном количестве компьютеров. Многие зарубежные и отечественные произ─ водители ПК пытались использовать эту систему на своих компьюте─ рах. Пытались делать это и наСПЕКТРУМ'е.Но тогда были чудес─ ные времена, когда форматMS-DOS,а равно и её возможности, был лишь сладкой мечтой. Сама фирмаIBMиспользовала эту систему при помощи восьмидюймовых дисководов. Тем не менее, старая восьмиразрядная система,казалось бы,дол─ жна прекрасно подходить для многих простых компьютеров. В неко─ тором роде, это правильно. Но правильнее сказать, что её возмож─ ности по осовместимливанию разных компьютеров весьма скромны. Система эта создавалась для работы с текстовыми терминалами. У неё нет средств работы с графикой! Да и с большим количеством памяти могут возникнуть проблемы. Осталось только элементарная совместимость по общей памяти, тексту и формату диска. Но и тут совместимость мизерная. На СПЕКТРУМ'евесьма затруднительно вывести80символов в строке. Но самым интересным оказался вопрос дискового формата. Всё дело в том, что на восьмидюймовых дисках было77дорожек и на каждой размещались26секторов по128байт. Вроде бы, проблема разрешима, и диски можно прочитать. Однако почитаем соответствующую литературу. Весьма часто можно видеть ссылку на такую книгу:  Уейт М. Ангермейер Дж.  Операционная система CP/M.  Пер. с англ. М: Радио и связь, 1986. Но при детальном осмотре оказалось, что это явно пособие в работе, но не по программированию в этой системе. Такой же оказалась книга:  Н. В. Макарова и др. Работаем на персональном компьютере  РОБОТРОН 1715 Л: Машиностроение, 1989. Похоже, что эта книга писалась во времена, когда под словом КОМПЬЮТЕР понималась: Большая, Очень Умная, Дорогая и Сложная Машина с Большим Экраном Типа Калькулятора Для Бухгалтера. Еще можно упомянуть подробную и научную, но устарелую и удалённую от практики книгу: Дейтел Г. М. Введение в операционные системы. Пер. с англ. под  ред. В.С. Штаркмана. М: Мир, 1987 В 2 т. Несколько устарелая, на мой взгляд, но весьма полезная для создателей ОС книга. Но описываемые там методы весьма сложны, и на практике описывается как раз стараяCP/Mпод восьмидюймовик. В результате становится понятно,что в этой системе разные ма─ шины используют практически любой возможный формат разбивки дис─ ка. Только на РОБОТРОН'естандартно их три. Немного отличаются методы сегментации.В результате существуют две модели компьютера КОРВЕТ,не совместимые между собой (когда-то мне об этом поведа─ ла учительница информатики из нашей школы).Но сКОРВЕТ'омкак со школьным компьютером и так почти покончено, ибо существует масса несовместимых между собой школьных агрегатов. А ведь постановка CP/MнаКОРВЕТназывалась одной из самых удачных. Называлась те─ ми, кто её присобачивал к компьютеруОРИОН-128,на котором не только дисков, но и контроллеров с портами существует пяток вер─ сий. То же самое можно сказать и о других компьютерах. Поэтому трудновато будет запустить наРОБОТРОН'еи даже наКОРВЕТ'eиг─ ру отPROFIилиATM-TURBO. Но оказывается, что некоторая совместимость есть, формат дис─ ков, описываемый ниже, хотя и является наиболее применительным для КОРВЕТ'а,вполне читаем и на других компах, несмотря на то, что их операционки называются, вроде бы,по разному:CP/M (-80)и MICRODOS,к тому же разных версий. Стало понятно, что читать диски от разных компов можно, но как их различать - неизвестно. Вот и приходится с трудом разбираться, что к чему. Про КОРВЕТ и ОРИОН немало говорилось в журналахРАДИОи РАДИОЛЮБИТЕЛЬ.Я также пытался изучить диск отPROFI,но с ним у меня получилась печальная история. Я попросил сделать копию это─ го единственного диска при помощиNEXTCOPY.В результате исход─ ный диск испортился, а на мой диск скопировались пара дорожек, содержащих каталог. И при помощи его я и узнал общие принципы хранения информации на таком диске. Разбивка была, как и наКОРВЕТ'еи других машинах,на5секто─ ров по1024байта. И такой формат следует признать общим. Описа─ тели каталога состояли из32байтов, из которых16последних яв─ но описывали блоки, на которых были расположены байты. И только много позже я узнал некоторые подробности. К этой поре я уже походил в библиотеку и уже поставил себе эмулятор этой системы:MYZ80 v 1.0bySimeon Cran.Он,правда, использовал виртуальный диск, который не совсем похож на реальные. Но неко─ торые интересные вещи я оттуда извлек. Потом я подробно изучил документацию кКОРВЕТ'уи ещё много чего выяснил. Все осложняет наличие самых разнообразных единиц измерения: от записей по128байт до экстентов и блоков по32(16) Кби4(2) Кб.И похоже,что все размеры отличаются в зависимости от версии. Но общие принципы не меняются. Где-то на диске расположен ка─ талог: уPROFIна второй дорожке, уРОБОТРОН'ана третьей. На файл уделяется по32байта, но в старых системах было и по 33. Описатель содержит в себе цепочку байтов - последова─ тельность блоков, в которых помещается файл. Таким образом, на диске эмулятора можно было создавать файлы до32768(16384)байт длиной. Но для систем с жесткими дисками максимальная длина упо─ минаемая длина достигала8Мб.Также ограничивается и размер дис─ ка: около256Мб.Но и эту проблему можно преодолеть увеличением размера блоков. Также упоминается возможность создавать цепочки из нескольких описателей для одного файла, всего до16.А от─ дельные куски больших файлов получили название экстентов. На следующий описатель раньше указывал 33-ийбайт. Позже за это стал отвечать байт с другим номером. Каталоги в этой системе не поддерживаются. Но существует одна примечательная возможность. Дело в том, что раньше на одну маши─ ну приходилось по множеству пользователей. А даже гибких, не то что жестких, дисков было мало. Надо было решать вопрос о разде─ лении данных на дисках. Поэтому было решено разбить диск на нес─ колькоUSER-областей,всего до16,но теоретически до255.Ката─ лог был общим, но в описателе каждого файла содержалась пометка принадлежности файла к определенной области. Таким образом, на одном жестком диске существовало несколько логических, как и в MS-DOS.Но диск при этом рассматривался как единое целое, и про─ цедуры загрузки, записи и удаления файлов, а также чистящие ути─ литы, не определяли принадлежность файла к определенной области, и разделение было чисто внешним. Теперь можно рассмотреть описатель файла более подробно: ┌────────┬─────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ЗНАЧЕНИЕ │ ├────────┼─────────────────────────────────────────────────────┤ │0 │Он как раз и содержит номер USER - области, к кото-│ │ │рой принадлежит файл. Используя его можно организо-│ │ │вать не очень развесистую, но весьма обширную струк-│ │ │туру каталогов. Все системы ограничивают число облас-│ │ │тей до 15, но при помощи небольшой переделки эту циф-│ │ │ру можно увеличить до 255. Если файл удалён, то нуле-│ │ │вой его байт равен #E5. │ │1-8 │Имя файла. │ │9-11 │Расширение. Cтаршие биты этих байтов содержат атрибу-│ │ │ты: 9-ый - только чтение, 10-ый - системный файл. │ │12 │Номер текущего экстента, номер того 16-килобайтного│ │ │блока файла,которому соответствует текущий описатель.│ │13-14-15│Системная информация. Судя по документации для Кор-│ │ │вет'а, байт 13 указывает количество байтов в послед-│ │ │ней записи файла, общее число которых также содержит-│ │ │ся в байте 15. │ │ │ Но при детальном исследовании выяснилось, что байт│ │ │15 содержит длину данного экстента в записях, по 128│ │ │байт каждая. Максимально это число достигало 128, и│ │ │при большей длине создавался новый экстент. │ │16-31 │Карта размещения файла. Она состоит из восьми пар│ │ │байт, каждая из которых содержит значения блока, на│ │ │котором содержится часть файла. В эмуляторе размер│ │ │блока равен 4096 байт, на РОБОТРОН'е и КОРВЕТ'е -│ │ │2048 байт. │ └────────┴─────────────────────────────────────────────────────┘ Остаток сектора может быть заполнен кодом#E5. В принципе, данной информации уже достаточно и для чтения, и для записи файлов. Тем не менее, в старых системах на диске также размещалась битовая карта на243байта. Каждый её бит от─ вечал за кластер из8секторов(8*128=1024).При записи файла устанавливался первый найденный сброшенный бит, и в описатель заносился номер соответствующего блока. Однако для записи нового файла достаточно просканировать ка─ талог, хотя эту операцию не совсем удобно реализовать програм─ мно, к тому же надо пропускать удалённые файлы. Лучше сначала создать таблицу свободных блоков в памяти и сделать это при пер─ вом же прочтении диска, а затем, используя и корректируя её в памяти, перезаписывать только изменённый каталог. Поэтому я не нашел больше никакого упоминания об подобной таблице размещения в более поздних моделях компьютеров. Тем не менее, нельзя не сказать,что данная система использует самый оригинальный способ сегментирования. Прочие системы раз─ мещают информацию о сегментах либо в общей таблице,и тогда ката─ лог так или иначе ссылается на один из её пунктов. Другие содер─ жат её на отдельных секторах для каждого файла, и в каталоге де─ лается ссылка на такие сектора. Но при копировании разумно было бы рассматривать такие сектора как сегменты файла.iS-DOSв этом смысле весьма оригинальна - использует и таблицу,и сектора, а также позволяет создавать вообще несегментированные файлы. Её авторы, по-видимому, изучали CP/M,но принятый на ней способ сегментации так и оказался уникальным. В документации наКОРВЕТстандартным также являлся самый пер─ вый сектор на диске - его128байт содержат размеры всех облас─ тей на диске: размер секторов в байтах, количество их на до─ рожках - и если эта информация вместе с форматом каталога яв─ ляется более-менее стандартной, то можно постараться и написать универсальную читалку-писалку на диски всех систем, претендую─ щих наCP/Mсовместимость. В этом секторе содержится: ┌───────┬───────────────┬─────────────────────────────────────┐ │Байты │Стандартно │Назначение │ ├───────┼───────────────┼─────────────────────────────────────┤ │0-1 │0 или #BE80 │Адрес загрузки ОС │ │2-3 │0 или #BF00 │Адрес запуска ОС │ │4-5 │0 или #0D │Количество секторов под ОС │ │6 │0 │Код диаметра НГМД (133 мм) │ │8 │0 │96 дорожек на дюйм (=1 для 48 дор.) │ │9 │1 │Данные вектора перевода секторов │ │ │ │(0 - не используется) │ │10 │3 │Размер сектора: │ │ │ │(0 - 128 байт │ │ │ │ 1 - 256 │ │ │ │ 2 - 512 │ │ │ │ 3 - 1024) │ │11 │1 │Двухсторонний НГМД (четные дорожки │ │ │ │сверху, 0 - односторонний) │ │12-13 │5 │Количество секторов на дорожке │ │14-16 │0080 │Количество дорожек на одной стороне │ │ │ │(TPD, TPD'=2TPD) │ │16-17 │40 │Количество логических записей по 128 │ │ │ │байт на дорожке (SPT) │ │18 │4 │Фактор сдвига ( =LOG2(BLS/128) ) │ │19 │15 │Маска расположения блока данных │ │ │ │( =BLS/128-1 ) │ │20 │0 │Маска размера блока │ │ │ │( =BLS/1024-1-DSM/256 ) │ │21-22 │#187 │Количество блоков данных на диске │ │ │ │( DSM=SPT*(TPD'-OFF)*128/BLS-1 ) │ │23-24 │#7F │Число элементов оглавления минус 1 │ │ │ │( DRM ) │ │25-26 │2 │Количество блоков под оглавление │ │ │ │( =32*DRM/BLS) │ │27-28 │#0020 │Размер вектора контроля оглавления │ │ │ │(Контрольная сумма каталога?) │ │29-30 │3 │Количество дорожек под операционную │ │ │ │систему, включая нулевую (OFF) │ │31 │#E7(#F1) │Контрольная сумма этого сектора │ │32-128 │0 │Резерв для вектора перевода секторов │ └───────┴───────────────┴─────────────────────────────────────┘ Осталось невыясненным, где хранитсяBLS- размер блока дан─ ных (2048/4096) как таковой. Но его можно рассчитать из19-го байта - маски блока данных. Прошло время, и у меня появились также диски от других CP/M/MICRODOS-совместимых систем:Вектор-06Ц, АТМ и Скорпион. Под Вектор-06Цу меня был эмулятор с внешней программойMST, работающей с егошними дисками. Но, к сожалению, наиболее глюч─ но она работает в процессе форматирования дисков - много везде плохих дорожек,а в других системах диск форматируется нормально. Посему точно ничего сказать не берусь, но каталог,вроде бы,стан─ дартный.Потом накачал ещё кучу софта и даже отформатировал диск. Но никаких существенных признаков при этом не проявилось, да софта полезного было очень мало, так что пока вопрос остается открытым. Под АТМдиски я форматировал Honey Commander'ом v1.0,како─ вая версия ещё работала на любом 128'ом. Диск - как вTR-DOS:16 секторов по256байт, блоки вроде по4096,но НИКАКОГО признака для их определения, кроме байтов#E5в начальных секторах. Рабо─ тать с ними, в общем,возможно. Установленныеседьмые битыпервых двух букв расширения файла соответствуют атрибутамREAD ONLYи SYSTEM,что для вышеупомянутого коммандера означаетHIDDEN:файл с таким битом просто так в каталоге уже не показывается. Так же, как и вКОРВЕТ'е,используются байты12и15описателя файла. ПодСкорпCP/Mадаптировал г-нMOAаж в 1992. Плохо это или нет, да только образчик такого диска у меня пока один, под наз─ ванием типа SEXDEMO- есть на нем какие-то картинки и музоны, пара исполняемых файлов... Только вотСкорпа-то у меня нетуть, под эмулем прут какие-то READING ERRORS 8-!, а при детальном ос─ мотре файлов в них обнаружились то ли разрывы, то ли дырки,заби─ тые нулями. Да и структура каталога заметно отличалась от стан─ дартной: в табличке описания местонахождения блоков файла на диске было заметно, что на каждый блок уделяется не по паре байт, а по одному байту. Это и понято: при размере блока 4096 байт на диске их поместится около150.Но эти разрывы в катало─ ге, заполненные нулями, заставляют меня подождать других образ─ цов или информации. Чуть позже я достал прогуTT 3.02,в кою была встроена возмо─ жность читатьCP/M-овские диски. И, как оказалось,читает она их неплохо, несмотря на разрывы. При небольшом взломе оказалось, что процедура чтения довольно хитра. Детально я разбираться не стал,потому как стал сильно сомневаться в достоинствах этой сис─ темы. Снова диски CP/M PROFI появились у меня благодаря г-ну Melted'у Snow,за что ему большой thanks. Были это диски от про─ фийной якобыSP-DOS with Concurent BIOS(или что-то там такое - в общем, всё та жеCP/M). При их рассмотрении выяснилось ниже─ следущее. Во-первых, каталог находится на первых четырех секторах нуле─ вой дорожки. Формат оного каталога соответствует стандарту. Во-вторых, размер блока -2048байт, то бишь,каталог занимает первые два блока: нулевой и первый. В-третьих, стандартная разбивка,- вроде бы, пять секторов по 1024 байта. Но на нулевой дорожке последний сектор всегда имеет нумер девять. Ясно, что вышепоименованный сектор служит для ав─ тостарта из под TR-DOS- на ЗАГРУЖАЕМЫХ дисках там всегда си─ дит файлBOOTK(или что-то в этом духе). А на незагружаемых дис─ ках там может размещаться любой файл, что создает некоторую трудность при его чтении - приходится делать корректировки. Но достоинством такого диска (он,похоже,был отформатирован не стандартным, в смысле, не системным форматером) было чередование секторов 1:1 и без всяких смещений. У загрузочного диска (он уже, скорее,был отформатирован стандартно) было смещение-1(или 6- на первой дорожке1,2,3,4,5;на второй2,3,4,5,1).Я дописал программку дляSOFTCOPY- первый диск читался гораздо быстрее второго. Конечно, когда пишешь какой нибудь хитрый автоподстраи─ вающийся лоадер, сей факт не имеет никакого значения, но факт остаётся фактом. Далее у меня появились эмуляторы и диски отОРИОН'а.Как ока─ залось, их структура полностью идентична дискамКОРВЕТ'а,только в загрузочном секторе прописан другой адрес для загрузки систе─ мы и, соответственно, изменилась контрольная сумма; как считать её - всё так же неизвестно. Кроме того, от Capry/STALL получены диски и информация о Спектрум-совместимом ПК"Кворум".Как оказалось, эти диски тоже совместимы по формату сКОРВЕТ'овскими, естественно, со своим клоном операционной системы. Аналогичная ситуация и с версией CP/M для компьютера Специалист-МХ.Образец диска можно взять по адресу:  [http://avshsoftware.by.ru/download/bst_cpm0.zip] Но у него есть ещё и собственная ДОС (см. ниже). Другое дело CP/M 2.3 byMichael Markowsky (KLUG),1995. На Klug BBSможно найти документацию на переработкуПентагонапод эту систему и образ диска с системой и утилитами. Содержимое этой BBS можно найти в Интернете по адресу:  [ftp://osin.iasnet.ru/klug/] Там в подкаталоге SINCLAIR есть файлы:ZXCPM.LZH,SYSZXCPM.LZH иZXCPM.ZIP,в них - всё необходимое. Опознать дискету можно, например, по стрингу "CP/M BIOS "+ "Ver 2.3, Michael Markowsky (C) 1995",находящемуся по смещению #297=663,в нулевом секторе нулевой дорожки. Экстенты начинаются с 4-ой дорожки, 0-го сектора- там находится каталог. Размер каталога -2экстента.Размер экстентов -2сектора, т.е., как обычно, -2 Кб. Какой же из всего этого следует вывод?  CP/M-совместимость компьютера абсолютно ничего не говорит о разбивке его диска.Но в целом приведенной информации должно хва─ тить для работы хотя бы со стандартнымиКОРВЕТ'овскими дисками. А точнее,для работы сCP/Mпридется написать настроечный модуль, определяющий или запрашивающий подвид системы и настраивающий системные переменные. А уж потом универсальная программа при помощи этих переменных будет работать практически с любымCP/M диском. Примером такой программы может служить писишная22Diskby Sydex, inc. Она, в частности может работать сCP/Mкомпьютеров Spectrum +3 иAmstrad.Есть также и конфигурация дляPROFI.Но, как известно, PC is... \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/dos2.W b/Docs/FORMATS/info_guide/dos2.W new file mode 100644 index 0000000..bffce25 --- /dev/null +++ b/Docs/FORMATS/info_guide/dos2.W @@ -0,0 +1 @@ +АГАТ,РАДИО,SP-&MX-DOS,RT-11  ...О дисковых форматах...  (продолжение)  ------------------------  Realtime Audio Player  a project by PSB^Halloween  vizualize by blade^triumph  2000, 2001, Halloween and Triumph  ------------------------ Этот плейер работает с дисками своего формата, и записана на них музыка в WAVE-виде. Описание - непосредственно из документа─ ции к программе. Дорожек80,стороны2(обязательно), сектора такие: ┌──────────┬─────┐ │физ.номер │длина│ │ 0 │ 128 │ │ 1 │1024 │ │ 2 │1024 │ │ 3 │1024 │ │ 4 │1024 │ │ 5 │1024 │ └──────────┴─────┘ Т. е. на диске800 kпод данные(беззнаковый wav,8 bit,mono) ина 0-й дороге 0-й сектор- информационный. На остальных треках его создавать не обязательно. Кстати,0-й- это, в смысле, на самом деле (физически) нулевой, т.е. если пользоваться#3D13,то его надо указывать как-1 (#FF).Формат info-сектора такой: ┌────────┬─────┬───────────────────────────────────────────────┐ │Смещение│Длина│Назначение │ ├────────┼─────┼───────────────────────────────────────────────┤ │ 0 │ 15 │Идентификатор "RAP format v1.0" │ │ 15 │ 1 │Номер диска │ │ 16 │ 32 │Название "TRACK: ..." │ │ 48 │ 11 │Время "TIME: MM:SS" │ │ 59 │ 2 │Частота дискретизации (rate) wav'а │ │ 61 │ 21 │Количество дорог на каждом из дисков │ └────────┴─────┴───────────────────────────────────────────────┘ Номер диска задаётся числом от0до20(всего21диск), а количество дисков определяется количеством байт, не равных#FF, по смещению +61.Таким образом, info-сектора каждого из дисков одного и того жемузона отличаются только номером(+15). Таким образом, определить диск этот можно, но не по0-му сектору нулевой дорожки,как это можно сделать со всеми другими системами, а специально читая#FF-ыйсектор.  -----------------  DOS ПК "АГАТ"  ----------------- Все данные о нём я почерпнул в книге: Мымрин М.П. Конструкция, применение, программирование и ремонт  ПЭВМ "АГАТ". М.:Машиностроение, 1990 г. Книга эта весьма подробная и содержит полную информацию об этом ПК, включая схему и разные доработки, а также тексты кое-каких прог. Формат диска:35 дорожек (а может быть, физически-то и все 40),на каждой по10секторов по256байт. И, скорее всего, одна сторона. Из этих дорожек нулевую, первую и вторую занимает ДОС, а каталог находится в самой середине диска - на17-ойдорожке. Причем всё указывает на то, что секторы его идут в обратном порядке: начинается он на 15-омсекторе и, если он помещается на одной дорожке, оканчивается на0-ом. В начале сектора расположены три важных байта.1-ый- признак продолжения каталога: если он равен нулю, то процесс считывания секторов каталога можно прекращать. Иначе вовторомитретьем байтах содержатся дорожка и сектор продолжения каталога. И вот, если каталог находится только на одной дорожке, то на всех сек─ торахвторой байтссылается на17-уюдорожку, атретий байт бо─ лее старшего сектора - на более младший:2-ой байт 15-го сектора равен 14,указывая, что следующий сектор каталога находится на 14-ом секторе.Аналогичным образом 14-ый сектор ссылается на 13-ый, 13-ыйна12-ыйи т.д., а вот 0-ой сектор ссылается на 15-ый,будто бы каталог закольцован. (Но я надеюсь, что первый его байт равен нулю.) Иначевторойитретий байтынулевого сек─ тора содержат дорожку и сектор продолжения каталога. После этих трех байт идут8зарезервированных байт, а затем поле описателей файлов. На каждый файл отводится по36байт, а именно: ┌─────────┬────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ:│ НАЗНАЧЕНИЕ: │ ├─────────┼────────────────────────────────────────────────────┤ │ 0 │Номер дорожки и ... │ │ 1 │номер сектора размещения файла. Кроме того,1-ый байт│ │ │описателя удалённого файла увеличивается на 160, и│ │ │данные о нем сохраняются. Отсюда видно, что теорети-│ │ │чески можно использовать и дисководы на 80 дорожек,│ │ │или двухсторонние на 40, но не 80TR/DS, или уж файлы│ │ │при этом удаляются по-другому. │ │ 2 │Тип файла: │ │ │2 (1-ый бит) - бейсик; │ │ │4 (2-ой бит) - двоичный (0 - текстовый); │ │ │7-ой бит - защита от записи. │ │ 3-32 │Имя файла. │ │ 33-34 │Длина файла в секторах. │ │ 35 │Резерв. │ └─────────┴────────────────────────────────────────────────────┘ Только вот неизвестно: то ли один описатель файла может нахо─ диться на разных секторах, то ли остаются свободные байты. И насчет сегментации. Каталог явно может быть сегментирован─ ным. Но вот файлы... В вышеупомянутой книге содержится не сов─ сем понятное объяснение. Первые два байта описателя могут содер─ жать ссылку на ссылку размещения файла. Т. е. они указывают на расположение (дорожку и номер) того сектора, в байтах 13-ом и14-омкакового содержатся дорожка и сектор, где начинаются или продолжаются данные. Но тогда как это различить? Как определить занятость секторов при записи нового файла, и вообще почему13-ыйи14-ый байтысектора, отведенные по данные файла, используются для других целей? Может быть это особые сектора, содержащие только ссылки, или на это используют─ ся пропавшие байты в секторах каталога? Впрочем, вопрос о сегментации файлов, хотя и является самым сложным, является также наименее освещённым в литературе. Как показали дальнейшие исследования дисков отAPPLE 2,их формат действительнно совместим или совпадает с вышеприведённым. Кодировка текста в каталоге (и не только):большие буквы ASCII+ + 128.  ------------------------  DOS 2.6 (РАДИО-86РК)  ------------------------ Основным достоинствомРАДИО-86РКявляется подробное описание в массовом радиожурнале. И описание его ДОС найдено там же:  РАДИО 93 г., номер 1, стр. 13-16. Ну так вот...80 дорожек:чётные(0, 2, 4...)- сверху,нёчет─ ные - снизу. Пять секторов по512байт -FMметод записи. Поря─ док секторов:0,3,1,4,2. Карта и каталог диска находится на32-ой дорожке.Карта - на 0-омеё секторе. Это160 байт,описывающих занятость секторов на соответствующей дорожке. Каждый из пяти младших битов отвечает за свой сектор. Например, первой дорожке соответствует первый байт этого сектора. Пусть значение нулевого байта равно#1E (11110 bin). Это означает, что заняты сектора1,2,3,4,но не0.Значение#1F (11111 bin)означает, что все сектора заняты.#0B (01011 bin)- сектора0,1,3и т.д. Затем идёт каталог диска. На каждый файл выделяется28байт: ┌────────┬─────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ЗНАЧЕНИЕ │ ├────────┼─────────────────────────────────────────────────────┤ │0 │Дорожка и ... │ │1 │...сектор следующего сектора каталога. Если 0-ой байт│ │ │равен нулю, то это значит, что продолжения не будет. │ │2-5 │Резерв, заполнен #00. │ │7-16 │Имя файла, остаток заполнен #00. │ │17 │Т.н. нулевой файл - если файл удалён, то первый байт │ │ │его имени равен #FF, а сюда записывается первая буква│ │ │его имени. │ │18-20 │Расширение файла. │ │21-22 │Дорожка и сектор размещения т.н. T/S LIST (см. ниже).│ │23-24 │Адрес загрузки. │ │25-26 │Длина в секторах. │ │27 │Атрибуты файла. │ └────────┴─────────────────────────────────────────────────────┘  T/S LISTили, точнее,TRACKS/SECTORS LIST- список дорожек и секторов, на которых содержится нужный файл. Первые два байта этого сектора содержат ссылку на продолжение этого списка, иначе это нули. Далее идет некоторое количество пар байт (а точнее, это количество содержится в описателе файла). Каждая пара содер─ жит дорожку и номер очередного сектора файла. Ну, а признаком окончания списка служат два нуля. Не могу только сказать, как располагаются описатели файлов по секторам: то ли впритык, и тогда один описатель может быть на двух разных секторах, или же в каждом секторе каталога остаются неиспользованные байты. Однако в любом случае каталог оставляет немало байт для всякого секретного использования.  ------------------------  SPDOS (ОРИОН-128)  ------------------------ Описание из журналаРАДИО №°2/93. Система эта предназначалась для быстрой дискофикацииОРИОН'а, при совместимости со старым ПО. В дальнейшем она была заменена на более распространенную системуCP/M.Но вопрос о её профес─ сиональности, совместимости и прогрессивности слишком отдалён от темы и в дальнейшем может быть изложен лишь касательно формата диска. А пока речь пойдет про её предшественицу. Две стороны,80 дорожек.Пять секторов по1024байта. Все счисление ведется в блоках - секторах по1024байта,- и положе─ ние на диске задается смещением в этих блоках. Вся нулевая доро─ жка зарезервирована:блоки 0-9не используются. На первой нахо─ дятсядва каталогавместе с картой диска(по 2 Кб):резервныйна секторах 1 и 2 (блоки 10 и 11)иосновнойна секторах6и7 (блоки 15 и 16).И на дорожках с2-ойпо79-ю(блоки 20 - 799) размещается область данных -780 Кб. В каталоге находится до78описателей файлов, по16байт в каждом, а именно: ┌────────┬─────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ЗНАЧЕНИЕ │ ├────────┼─────────────────────────────────────────────────────┤ │ 0-7 │Имя файла. Если первый его байт равен #E5, то этот │ │ │файл удалён, а если - #00, то значит, каталог окон- │ │ │чился. │ │ 8-9 │Адрес загрузки файла. │ │ 10-11 │Размер файла в байтах. │ │ 12 │Атрибуты файла: │ │ │7-ой бит - защищён от записи; │ │ │4-ый бит - файл создан фиктивно - только в каталоге. │ │ 13-15 │Зарезервированы. │ └────────┴─────────────────────────────────────────────────────┘ Замечу, что78*16=1248.Это означает, что в каталоге осталось ещё800байт места. И вот780из них используются для размеще─ ния таблицы размещения файлов. Если её байты условно пронумеровать от20до799,получим прямое соответствие между каждым байтом и блоком на диске. Если значение какого либо байта равно#E5,то соответствующий ему блок свободен, а если его значение -#FF,то он дефектный. Ина─ че его значение будет от1до78,в соответствии с тем, какому файлу этот блок принадлежит, или, точнее, номеру позиции этого файла в каталоге. Таким образом, совсем не нужно записывать положение первого сектора (блока) файла или создавать таблицу расположения секто─ ров каждого файла. Для чтения файла нужно определить его поряд─ ковый номер в каталоге, если он неизвестен, а затем сканировать таблицу расположения файлов, и, найдя искомый номер, загрузить блок, соответствующий смещению от начала таблицы, не забыв при─ бавить20.И продолжать такое сканирование-считывание, пока весь файл не будет загружен. А для записи нового файла нужно в этой таблице искать свободные блоки, соответствующий им байт будет равен #E5. Естественно, надо пропускать занятые и дефектные блоки. И при верификации записанного файла можно даже параллельно помечать обнаруженные дефектные сектора! Примечательна возможность создания фиктивного файла - только в каталоге. Но этот бит обязательно нужно учитывать, дабы не ис─ кать блоки, принадлежащие несуществующему файлу. Также надо не забыть о большом количестве свободного места на начальных дорож─ ках. Свободное место можно с толком использовать для различных защит и даже вирусов, хотя, к сожалению, максимально возможный размер секторов не позволяет форматировать секторы, изменяющие какие либо данные в памяти скрыто от чужих глаз. В итоге можно только сказать: зачем использовать старую сис─ тему CP/M,если эта система совместима со старыми наработками и её развитие могло бы привести к лучшим результатам? Это я к то─ му, что на СПЕККИтакая же ситуация с операционками, и если уж кто хочет сделать новую, то пусть учтет подобную ситуацию.  ------------------------  MX-DOS  ------------------------ Эта ДОС предназначена для компьютераСпециалист-МХ.Образец эмулятора этого компьютера можно взять по адресу:  [http://avshsoftware.by.ru/download/spmx_v42.zip] А образец диска (один диск в двух частях):  [http://avshsoftware.by.ru/download/bst_mx0_0.zip]  [http://avshsoftware.by.ru/download/bst_mx0_1.zip] Разбивка диска стандартная:162 дорожки с двух сторон,5 секторов, по1024байта каждый. Опознать диск можно по стрингу"Dos_MX V3.6",который находи─ тся по смещению5,в нулевом секторе нулевой дорожки. Файловая структура дисков весьма необычная: файл позициониру─ ются с точностью до байта. Дело в том,что файловая система осно─ вывается на структуре ROMDISK'а для этого компьютера. Структура заголовка файла: ┌─────────┬────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ:│ НАЗНАЧЕНИЕ: │ ├─────────┼────────────────────────────────────────────────────┤ │ 0 │3 байта #D3 - признак заголовка │ │ 3 │9 байт имени │ │ 12 │3 байта расширение │ │ 15 │Если #8C - файл, если #8B - подкаталог │ │ 16 │3 байта - дата в BCD виде: старшие 4 бита - десятки,│ │ │младшие 4 бита - единицы │ │ │(например, число 21 будет #21) │ │ 24 │2 байта - стартовый (начальный) адрес файла │ │ 26 │2 байта - конечный адрес │ │ 28 │2 байта - контрольная сумма │ └─────────┴────────────────────────────────────────────────────┘ Назначение остальных байтов неизвестно, требуется дополните─ льная информация.  ------------------------  RT-11 (Рафос, Фодос)  ------------------------ Прежде всего попались мне в руки диски отДВК.Но они были совершенно нечитаемые, несмотря на то, что об их совместимости со стандартными форматами разбивки упоминалось не раз. Чуть больше повезло мне с дисками отУКНЦ.Читались они прос─ то прекрасно, углядывалось имя диска, загрузчик... Но не было никакого намека на присутствие каталога. В дальнейшем у меня появился доступ к этим машинам и специалист по ним. Но в доку─ ментах на них я не нашёл никакой пользительной информации на нужную тему и, даже отформатировав диск и записав на него извес─ тные файлы с известным каталогом, я не нашёл его на диске как таковой. Была только какая-то таблица, структурой напоминавшая то ли каталог, то ли таблицу размещения файлов, которой, кстати, быть не должно, т. к., по полученной информации, структура диска напоминает СПЕКТРУМ'овский. Потом у меня завёлся эмулятор ОС RT-11,совместимой с форматомFODOSнаУКНЦ,да ещё и конвертил─ ка с дисков такого формата. Но опять же ни доки, ни каталога, а только чушь всякая. В общем, вопрос тут остался открытым, и пока имелись ещё кое-какие надежды. Целый год я надеждами этими жил,а потом опять пошёл в библио─ теку. Перерыл целую кучу книжек. Вначале выяснилось, что, в об─ щем-то, все идет от этой самойRT-11,а от неё "откопировались" всякие тамРАФОС, РАФОС 2, ФОДОС, ФОДОС 2, ОС ДВКи чего-то там ещё - в общем, всё то, что использовалось на старых машинахСМи серии "Электроника".На них, как, впрочем, и на MS-DOS,и на CP/M,более важной казалась программная совместимость. В резуль─ тате - опять секреты, а может - стыдно кому за содранное с инос─ транных образцов. Словом, про диски от сих совместимых ОС сказано мало. Самую подробную информацию я отыскал в справочнике:  Операционная система СМ ЭВМ РАФОС Составители: А.И. Валиков, Г.В. Вигородчик, А.Ю. Воробьев, А.А. Лукин под общ. ред. В.П.  Семина. М:Финансы и статистика, 1984 г. - 207 с. Оказывается,системаРАФОСможет ещё работать с дисками ДОССМ иЕС ЭВМ.Скорее всего, это тоже влияет на хитрый формат катало─ га. Почему его нигде не видно? Да дело в том, что все символьные строки упакованы в хитрый (и, похоже, старющий) такой код - RADIX-50.Практически это небольшая компрессия: три буквы - в два байта. Но набор букв, между прочим, состоит не из32симво─ лов (по пять бит на букву, да ещё бит в паре байт остается, а раскодируется всё простым тебе сдвигом - для каталога вроде дос─ таточно). Но нет, тут используется набор из40символов: букв, цифр и три спецзнака. Вроде, нужно6бит на символ - в два байта не втиснуться. Но это - если работать сдвигами, а если умноже─ нием - то получится:  40*40*40 = 64 000 - вполне двухбайтное число. И получаем:  Код_Первой_Буквы*1600 +  +Код_Второй_Буквы*40 +  +Код_Третьей_Буквы = Более#FFFFникак не получится, если код буквы лежит в диапа─ зоне от0до39! У"пробела" код -ноль,у буквA-Z- коды от1до26.Далее идут спецсимволы: "точка в кружочке",по-нашему"$"- код27, "точка"- код28,"/"- код29- этим символом замещают символы, не имеющие аналогов в кодеRADIX-50.Ну, а цифры"0"-"9"- коды 30-39. Кодирование и декодирование осуществляется операциями умноже─ ния и деления. Дальше - проще. Весь диск разбит на блоки по512байт, наУКНЦэто - размер сектора, и нумеруются эти блоки от нуля и до некоторого максиму─ ма - общего числа блоков. Число это зависит от количества доро─ жек и секторов на них:10или9.  Блок 0- загрузочный сектор. Начинается он с кода#A0,есть и другие примечательные байты, но как по ним определять количес─ тво сторон, дорожек и секторов - пока неизвестно.  Блок 1- содержит: в конце - имя пользователя, диска и опе─ рационной системы, а в начале - таблица замещения дефектных бло─ ков. Как в ней кодируются эти плохие блоки - нигде не написано, кроме того, там присутствуют кое-какие всегда постоянные байты.  Блоки 2-5- сама система или пусто, если диск не загрузочный. Начиная сблока 6находится каталог. Он состоит из одного или нескольких сегментов - каждый по1024байта -2 блока.Количес─ тво сегментов может задаваться при инициализации диска. Принято, что вся информация в каталоге двухбайтная - всего512 слов(пар байт) в сегменте. Первые5слов - служебные: ┌────────┬─────────────────────────────────────────────────────┐ │Слово │ЗНАЧЕНИЕ │ ├────────┼─────────────────────────────────────────────────────┤ │1 │Число сегментов в каталоге. │ │2 │Номер следующего сегмента: сегменты образуют список,│ │ │последний сегмент имеет номер ноль. │ │3 │Количество занятых сегментов, изменяется только в│ │ │первом сегменте. │ │4 │Число дополнительных байт в каждой записи о файле.│ │ │Система использует 14 байт - 7 слов на файл, но спе-│ │ │циальные программы могут иметь свои сегменты со своей│ │ │длиной описателя файла. │ │5 │Номер начального блока первого файла данного сегмента│ └────────┴─────────────────────────────────────────────────────┘ Стандартная запись о файле -7слов: ┌────────┬─────────────────────────────────────────────────────┐ │Слово │ЗНАЧЕНИЕ │ ├────────┼─────────────────────────────────────────────────────┤ │1 │Тип записи в файле: │ │ │#0100 - временный файл, при нем используется слово 6;│ │ │#0200 - удалённый файл - пустое место на диске; │ │ │#0400 - нормальный файл; │ │ │#8400 - READ ONLY; │ │ │#0800 - конец сегмента, но не каталога, конец ката-│ │ │лога определяется, если сегмент этот - последний ис-│ │ │пользованный. Не обязательно используется весь сег-│ │ │мент до конца - перевод на новый сегмент, возможно, с│ │ │другой длиной описателя файла, может произойти в лю-│ │ │бом месте. │ │2-4 │Имя и расширение в коде RADIX-50 - 6 и 3 символа. │ │5 │Длина файла или пустого места. │ │6 │Для временного файла в младшем байте - номер канала,│ │ │связанного с этим файлом задачи, номер которой - в│ │ │старшем байте. │ │7 │Дата создания файла: биты 0-4 - год-1972 (т.е. 1972 -│ │ │2004),биты 5-9 - день (1-31),биты 10-14 - месяц(1-12)│ └────────┴─────────────────────────────────────────────────────┘ Могут быть и дополнительные байты. Положение файла на диске приходится определять сложением длин файлов, начиная с первого файла данного сегмента и по файл, иду─ щий перед заданным, плюс5-ое словоданного сегмента. Похоже на мотание ленты в магнитофоне по счётчику; впрочем, данная ОС ве─ дёт своё летоисчисление с ленточных времен. Напоследок добавлю, что в ОСРАФОСвозможны виртуальные дис─ ководы - файлы, структура которых повторяет разбивку диска. Это только подтвердилось, когда я немного ознакомился с БК-11М,на котором тоже можно запустить эту систему. Но пока это только небольшие обмолвки в документации на другие системы. Посему не известны ни подробности функционирования системы на БК,ни форматы первых блоков системы. \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/dos3.W b/Docs/FORMATS/info_guide/dos3.W new file mode 100644 index 0000000..2646efc --- /dev/null +++ b/Docs/FORMATS/info_guide/dos3.W @@ -0,0 +1 @@ + БК & NEWDOS; эпилог...  ...О дисковых форматах...  (окончание)  ------------------------ АО-ДОС версии 2.02  ------------------------ Формат её каталога совместим сMicroDOS, NORTON, NORD, MK-DOS - имеются в виду другие БК'шные системы. Диск может быть 40/80-дорожечным, 1/2-сторонним.10 или 9 секторов по512 байт. Проблема заключается в существовании двух вариантов диско─ вых форматов: расширенного и стандартного. Последний формат как раз и исследовался, и похоже, что при этом используется только определённая разбивка:10секторов. Ещё одной проблемой было то, что дляБКосновной системой счисления является восьмеричная,каждый раз на это нужно обращать внимание. Положение на диске задается в смещениях в блоках по512байт. Пересчёт ведётся по формулам:  ДОРОЖКА = INT(СМЕЩЕНИЕ/10)  СЕКТОР = СМЕЩЕНИЕ-ДОРОЖКА*10 Впрочем,положение на диске легко определяется "на глаз": пер─ вые две цифры десятичного числа - дорожка, а последняя - сектор. На нулевом блоке(0 дор. 0 сект.)размещается системная инфо─ рмация и начало каталога. Первые 4 байтаиспользуются только для загрузочного диска, у него: ┌────────┬─────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ЗНАЧЕНИЕ │ ├────────┼─────────────────────────────────────────────────────┤ │0-3 │Коды команды перехода на загрузчик. │ │4 │Определяет тип формата: если там 26, то формат расши-│ │ │ренный, а на изучаемом мною диске там было число 32.│ │ │Поэтому расскажу об отличиях. Как свидетельствует до-│ │ │кументация, при расширенном формате: │ ├────────┼─────────────────────────────────────────────────────┤ │5 │Описывает разбивку диска. Там содержится размер до-│ │ │рожки диска в секторах, плюс установлен 7-ой бит, ес-│ │ │ли диск односторонний. │ │6-7 │Размер сектора в байтах. │ │8 │Количество дорожек. │ │10 │Зачем-то зарезервирован. │ │ └─────────────────────────────────────────────────────┤ │ В моем варианте формата я увидел на месте этих байт│ │ стринг "AO-DOS".Далее соответствие восстанавливается.│ ├────────┬─────────────────────────────────────────────────────┤ │12 │Имя диска (12 байт), которое показывается оболочкой│ │ │DOS SHELL для этой системы. │ │24 │Содержит количество записей в каталоге. │ │26-27 │Номер первого свободного блока на диске. │ │256-257 │Байты #2E и #A7 - число 123456 в восьмеричной систе-│ │ │ме. Это признак данной ОС. │ │310 │Недокументированная пара байт - количество свободных│ │ │блоков на диске. │ │320 │И далее находится каталог. │ └────────┴─────────────────────────────────────────────────────┘ Структура его весьма оригинальна. Несмотря на то,что в систе─ ме могут создаваться каталоги с уровнем вложенности как минимум до128,все записи о всех файлах на диске находятся в едином ка─ талоге. Каждый подкаталог, вне зависимости от уровня вложеннос─ ти, имеет свой индивидуальный номер, записанный в описателе дан─ ного каталога. И каждый файл или подкаталог имеет ссылку на свой родительский каталог. На запись в каталоге отводится24 байта: ┌────────┬─────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ│ЗНАЧЕНИЕ │ ├────────┼─────────────────────────────────────────────────────┤ │ 0-1 │В инструкции они называются словом признаков (16│ │ │бит). Если запись описывает подкаталог, то младшие│ │ │семь бит нулевого байта содержат порядковый номер│ │ │этого подкаталога, иначе в нем задействованы только│ │ │нулевой, первый и седьмой биты. Тогда их значение та-│ │ │ково: 0-ый бит - признак защищённого файла, 1-ый -│ │ │спрятанного, а 7-ой бит - признак сбойного блока. │ │ │ Младшие 7 бит первого байта содержат номер роди-│ │ │тельского подкаталога, вне зависимости от того, о чём│ │ │запись: о файле или о каталоге. 7-ой бит этого байта│ │ │свидетельствует о том,что данный файл удалён. Удалён-│ │ │ные каталоги вычищаются чисто физически, и стандартно│ │ │они не должны содержать файлов. А вновь создаваемые│ │ │каталоги чисто физически помещаются не в конец списка│ │ │всех файлов, а после последней записи о каталоге. │ │ │ На практике оказалось, что при удалении файлов оба│ │ │эти байта принимают значение #FF. │ │ 2-15 │Имя файла. Расширения как такового вообще нет. Байты│ │ │эти могут содержать коды любых знаков и цифр, вклю-│ │ │чая точку, которая может отделять псевдорасширение,│ │ │которое может быть любой длины. В общем, эти байты│ │ │служат для визуальной идентификации файла. │ │16-17 │Номер первого занимаемого файлом блока. Для подката-│ │ │лога это всегда число #14. │ │18-19 │Количество блоков, расходуемых на файл. Для подката-│ │ │логов оно всегда равно нулю. │ │20-21 │Содержат адрес загрузки, который всегда уменьшается│ │ │до чётного числа. │ │22-23 │Содержат длину файла, которая должна быть меньше│ │ │32768. │ └────────┴─────────────────────────────────────────────────────┘ Как видим, нет никаких признаков, что файлы и каталоги могут быть сегментированными. Да и в её описании говорится:"Система использует алгоритм записи файла, позволяющий оптимально ис─ пользовать дисковое пространство, не прибегая к помощи утилит сжатия, и снимающий необходимость контроля за состоянием катало─ га диска".Тайна этого алгоритма мною не раскрыта. На диске нет ничего похожего на карту диска. Возможно, система пытается запи─ сать новый файл на место удалённого, подходящего по размерам, и какая-то часть диска пропадает зря. И действительно, стирая и записывая файлы, я убедился, что меньшие по размеру файлы записываются на место уже удалённых, больших их по размеру. Если же файл не помещался, запись проис─ ходила на новые сектора, уменьшая свободное дисковое простран─ ство, и запись добавлялась в конец каталога. А если записыва─ лись маленькие файлы, то их описатель занимал место удалён─ ного, и, если после этой операции оставалось место от удалённо─ го файла, то запись о поместившемся новом файле добавлялась пос─ ле старой. Таким образом, файлы шли в последовательности положе─ ния их относительно начала диска. Оставшаяся от удалённого фай─ ла "дырка" между блоками могла использоваться для записи поме─ щающихся в неё файлов, хотя в каталоге о ней записи не было. Кроме того, в конце каталога был найден эдакий конечный файл. Первые два байта его были равны#FF.Байты16и17у его описа─ теля содержали номер первого свободного блока, а байты18и19 - количество свободных блоков. Эту информацию можно использовать для работы с диском. Осталось только сказать, что система автоматически создаёт полную копию нулевой дорожки, которая располагается на дорожке номер1.Причём на обоих последний сектор, похоже, не используе─ тся, поскольку он заполнен байтом#00,тогда как неиспользуемое место в каталоге заполнено байтом#F6.  ------------------------  NEWDOS  ------------------------ Привожу одно письмо.В нём предлагается новый формат диска для Спектрума. "Привет All !  Я тут pазpаботал новый фоpмат хpанения имени файлов на диске и хочу, чтоб вы его посмотpели и оценили все возможные недостат─ ки. Может быть, что добавить или убpать нужно,как на Ваш взгляд?  Hа диске может находиться либо 64 файла,либо 64 диpектоpии по 16 файлов в каждой, итого максимум 1024 файла на один диск. Мо─ жет быть и pазбpос файл-диpектоpия, т. е. не что-нибудь одно, а всё вместе. В созданной уже диpектоpии создать ещё одну нельзя, а можно записать 16 файлов. Эти огpаничения сделаны для облегче─ ния pаботы в последующем пpи написании какого-либо софта под этот фоpмат, а также для уменьшения занимаемого дискового пpос─ тpанства.  За счёт этого фоpмата мы теpяем ещё 9 доpожек, т. е. first track на диске будет 10.  Тепеpь опишу фоpмат названия диpектоpии и файла: DIRECTORY; +#00 - file mask:  #00 - end of catalog or directory;  #01 - deleted file or directory;  #02 - directory;  #03 - file don't delete;  #04 - hidden file or directory. +#01-#14 - directory name of 20 symbols; +#15-#17 - type of 3 symbols; +#18-#1A - create date DD-MM-YY; +#1B - not used; !!! +#1C - files in directory; +#1D - directory length of sectors; +#1E - first sector; +#1F - first track. FILES: +#00 - file mask:  #00 - end of catalog or directory;  #01 - deleted file or directory;  #02 - directory;  #03 - file don't delete;  #04 - hidden file or directory. +#01-#14 - file name of 20 symbols; +#15-#17 - type of 3 symbols; +#15= 'B'-'BAS' for basic file  'C'-'COM' for code file  'D'-'DAT' for data file +#18-#19 - start address file; +#1A-#1B - bytes length file; +#1C - number directory for this file; +#1D - lenght of sectors; +#1E - first sector; +#1F - first track.  То бишь, тепеpь имеем 20 символов имени, 3 символа тип и кучу файлов на диске.  Как вы на это смотpите?  Лично я завтpа начинаю писать пеpвоначальную пpогpаммную под─ деpжку, котоpая впоследствии станет одной из доpаботок нового DOS'a, а Phantom Ltd начнет писать COMMANDER под этот фоpмат." А вот и ответ на это письмо:  "Я бы на твоём месте сделал бы следующее: 512 байт на сектор, 10 секторов на дорожке, формат диска MS-DOS. Это сразу решит вопрос переносимости файлов между всеми остальными досами. Кро─ ме того, нет ограничений на количество файлов на диске - ограни─ чено только количество файлов/директорий в корневом каталоге. Подумай о пользователях HDD - им опять резать винт на ломтики по 640 Кб?  Теперь насчёт формата каталога. Берётся оригинальный формат MS-DOS, и в него вносятся следующие исправления: вместо времени создания файла записываем стартовый адрес (такой вариант давно и успешно применялся на БК). Кроме того, в MS-DOS в записи о фай─ ле пустует ещё 10 байт, так что развернуться можно. IK> Эти огpаничения сделаны для облегчения pаботы в последую─ IK> щем пpи написании какого-либо софта под этот фоpмат, Софт нужно писать под операционку, а не "под формат". IK>+#15= 'B'-'BAS' for basic file IK> 'C'-'COM' for code file IK> 'D'-'DAT' for data file Планируется ли использование нового доса как замены TR-DOS? Если нет, то про бейсик можно сразу забыть. IK>+#1E - first sector; IK>+#1F - first track. Зачем повторять чужие ошибки? Линейное расположение файлов сей─ час не актуально.  __ __/ / Powered [pepsi inside] \_\/ by MOTOROLA [smoking suxx]" Надеюсь, тут суть понятна без особых комментариев, но всё-та─ ки, поддерживать эти форматы или не поддерживать??? Как заметил Time Keeper,письмо это взято из конференции REAL.SPECCY,и подобных писем там немало.Как по его личному мне─ нию, так и по мнению множества других людей, самый лучший фор─ мат для винчестера - этоMS-DOSFAT,т.к. будет большая совмес─ тимость сПЦ- можно легко переносить информацию в виде ОБРАЗОВ ДИСКОВ и подключать их к операционной системе тем или иным обра─ зом (напрямую, через RAM-Disk). Сделаю и я небольшую заметку: винчестер режут на ломтики как раз наБК,каждый ломтик - образ диска - именуется своей буквой, большой или маленькой. И вообще, если работать с винтом, то надо и на ломтики делить (для старых систем, и программы поддержки контроллеров винта наСпекеделают примерно так же) и новый фор─ мат диска придумывать - для новых операционок.А уж будут ли лом─ тики эти в виде файлов или раздельчиков - вопрос к разработчику, уже сейчас реализован и тот, и другой вариант. Таким образом, описание файловой системы, предлагаемой выше, можно рассматривать и как предмет дискуссии, так и призыв к дей─ ствию. Здесь он присутствует как практический пример и пособие - на тот случай, если кто-то этот формат вздумал поддерживать. Но самое интересное: автор этого опуса откликнулся, и его личность установлена:Himik's ZxZ.  ------------------------  AN-DOS  ------------------------ Самое время вспомнить опять оБК.AN-DOSи есть та система на БК,о которой вспоминали чуть выше. Она действительно ис─ пользует систему размещения файлов при помощиFAT,как уMS-DOS (иASC SOUND MASTER). В структуре диска произошли лишь незначительные изменения. В загрузочном секторе для команды перехода на загрузчик ис─ пользуются не 3,а 4 байта: #A0, #00, #1E, #01,и далее идёт стринг "ANDOS".Затем всё как обычно, включая метку диска и признак"FAT12".Только разброс параметров: всегда по две FAT, размером по1200байт(424кластера по4сектора),размер катало─ га -7секторов. Кроме того, используется только корневой каталог. Подкаталоги кодируются в стандартной дляБКсистеме. У каждого каталога и подкаталога есть свой индивидуальный номер. А у каждого подката─ лога и файла есть ссылка на номер их каталога-прародителя (в котором они находятся). Поэтому произошли небольшие изменения в структуре каталога: ┌─────────┬────────────────────────────────────────────────────┐ │СМЕЩЕНИЕ:│ НАЗНАЧЕНИЕ: │ ├─────────┼────────────────────────────────────────────────────┤ │11 │Атрибуты файла. Бит 3 - признак подкаталога AN-DOS. │ │12-19 │Резервируются. MS-DOS зануляет их ??? │ │20 │Признак подкаталога и одновременно его номер. │ │21 │Номер родительского подкаталога. │ │22-23 │Адрес файла или имя дисковода для ссылки - перехода│ │ │на него. У ссылки тоже установлен третий бит, но у│ │ │подкаталога байты 12-31 занулены. │ └─────────┴────────────────────────────────────────────────────┘ СтруктураFATсистемы аналогичнаMS-DOS,а структура подката─ логов похожа наAO-DOS.Т.е. НА ДИСКЕ имеется один-единственный каталог. У каждого подкаталога в нём есть свой порядковый номер в резервируемой области хедера, промаркирован он как метка дис─ ка, и MS-DOS его не кажет. А у каждого файла в хедере хранится номер подкаталога, где он находится. Разбивка эта является чисто визуальной: если система пишет файл и ищет - нет ли уже файла с таким же именем,- то она сканирует все файлы, не глядя на под─ каталоги.  ------------------------  ЭПИЛОГ  ------------------------ На этом я пока заканчиваю своё повествование. В разное время я имел доступ к дискам и компьютерам самых разных систем,а также к эмуляторам. И здесь изложены, пожалуй, далеко не все известные мне форматы дисков. Многое я узнал при помощи эмуляторов наIBM ПЦ.Надо сказать, при их помощи можно изучить такие системы, которые мало кто ви─ дел вживую, или такие,чьи носители информации не способствуют их изучению наСПЕКТРУМ'е. Например,в компьютереCOMMODORE 64используется хитрый диско─ вод, подключенный к специальной шине компьютера шестью провода─ ми. Оригинальны и форматы диска: на дорожках1-17располагается 21сектор по256байт,18-24-19секторов,25-30-18,и на ос─ тальных по17,причем дорожки36-40- нестандартные. Поэтому там используются виртуальные диски и файлы - в виде файлов формата MS-DOS.Эмулятор имитирует работу настоящих дисководов, картрид─ жей и кассет, используя информацию из этих файлов. Но при этом возможно подключение настоящих дисководов и кассет при помощи принтерного порта. Существуют даже специальные программные обо─ лочки, которые позволяют объединять стандартные и нестандартные устройства под общим интерфейсом и производить удобный перенос информации между ними. А ещё существуют и совместимые дисководы, винчестер и даже конверторы из/вMS-DOS,но, насколько я понял, они гораздо более редкие. Поэтому только стандартными просмотрщикамиMS-DOSможно изу─ чать виртуальные диски. Хотя, например,компьютерыMSXиспользуют диски,весьма похожие наMS-DOS'овские,да и автор ОС обоих систем, вроде,общий,несмо─ тря на то, чтоMSX'ная, вроде бы, называется CP/M.Виртуальные же диски не всегда являются полной копией реальных и,может быть, мне захочется копаться на реальных при помощиСПЕКТРУМ'а. А форматы кассет и картриджей вообще не поддаются нормальным исследованиям. Правда, кому нужно старьё1980-1984годов? Ещё попадался мне компутер такой -ATARI XE 130.Был при нём и дисковод, и дискеты, и даже кое-какая русскоязычная доку─ ментация. Но дисковод был внешний, соединительные кабели куда-то делись. Дискеты читались с трудом, а кроме того, они использо─ вались как две односторонние. Короче, чего я там на них ни прочитал, но каталога нигде не нашёл. А в документации вот как раз про него - ни слова. В общем, если найдется какой специа─ лист, то продолжим об этом разговор. А то, что я уже начал пи─ сать по сию тачку, к сожалению, стёрлось. Как показали копания в эмуляторских образцах - каталог содержится где-то в середине ди─ ска и имеет довольно простую структуру. Имеются образцы и немного документации про дискиSAM Coupe'и DiSCIPLE Plus.Их особенностью является порядок следования логи─ ческих дорожек: дорожки0-79находятся на одной стороне диска, а дорожки80-159- на другой. Но малое количество документации не стимулирует детальное их исследование. ДляOpus Discoveryнет даже образцов, а только несколько ути─ лит с краткой документашкой и дизассамблер ПЗУ. И опять же - не знаю, стоит ли с ними возится. И ещё,читал я хорошее описание старинного такого компа:ИСКРА 224 называется. Кое-кто говаривал, что работал с ним. И стоило бы о нём рассказать, хотя бы из принципа о необходимости рас─ пространения полезной (ли) информации. Да вот только я даже не знаю, подключаются ли к нему FDD 5'25",и насколько он сейчас распространён, чтобы им кто-либо заинтересовался, хотя бы из праздного интереса. То же, впрочем, можно и сказать о всех вышеперечисленных тач─ ках. Но я могу с уверенностью сказать, что кто-нибудь каким-ли─ бо образом имеет к ним доступ, а о других подобных машинах не знает или не хочет знать, несмотря на то, что популярность неко─ торых из них даже на текущий момент может быть весьма велика в определённых слоях. И доступность свежего программного обеспече─ ния к ним, а также подробная информация о них и кооперирование с более мощными и современными системами помогут продлить инте─ рес к ним,особенно если переход на вышеупомянутые мощные системы по каким-либо причинам невозможен. И информацией можно и нужно делиться про все платформы, и кооперированию их как раз и помогают различные описания всевоз─ можных стандартов и форматов. Особо важно, по-моему, рассказать проПЦ'шные форматы. Но дело в том, что такие интересные вещи зачастую остаются без внимания теми, у кого они есть,но их долго ищут те, которым они нужны. А те, кто может что-то сказать по поводу дисков от вышепере─ численных, а также и других компьютеров, могут писать об этом мне,NUTS'у. Я с удовольствием приму все дополнения,добавления, поправки, исправления и критику.  Ред.:Не забудьте и мне чиркнуть письмецо, в редакцию. Было бы очень полезно издать справочник по разного рода форматам в бумажном виде. Уже сейчас я собрал более300kZX-публикаций на эту тему.  ------------------------  Благодарности  ------------------------ Как уже внесшим вклад в это пользительное дело, хочется ска─ зать большое спасибо:  Unbeliever'у- за его CD-R, содержавший, в частности, разный эмуляторный софт и, соответственно, авторам этого софта;  Ивану Рощину- за его форматер;  Евдокимову Алексею- за его программу'AFRODITA 3.0'; и всем тем, кто помогал мне форматировать диски в разных системах, а в частности:  Melted Snow(сотоварищи) -Profi CP/M (Concurent BIOS);  Ice'DI'Griz/3umph(сотоварищи) -Profi DOS(когда-то не про─ дававшаяся);  Capry/STALL- информация оCP/Mдля Спектрум-совместимого ПК "Кворум". ------------------------ Wanted !!!!  ------------------------ Информация о дисках всех систем и платформ, особенно наБКи ДВК(CSI, RT-11, ОС ДВК)иZX Spectrum(D80, Opus Discovery). С целью апгрейда данного справочника обращайтесь к распрост─ ранителям или по адресу:  606015, Нижегородская обл.  г. Дзержинск  пр. Ленина д.6 кв.8 Полякову Алексею  mailto:nuts_@pochtamt.ru Естественно, апгрейдеры будут тут упомянуты. Можно такое дело делать и по музакам, архивам и пр. Nuts,1998-14.10.2001 гг. Дата последней редакции: 18.07.2005(Alone Coder) \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/formaty.W b/Docs/FORMATS/info_guide/formaty.W new file mode 100644 index 0000000..62dd6ec --- /dev/null +++ b/Docs/FORMATS/info_guide/formaty.W @@ -0,0 +1 @@ + Форматы упакованных данных Форматы упакованных данных на ZX Spectrum Как я успел понять, моим статьям хвата- ет сухости изложения. В силу этого,как мне удалось прикинуть, даже будучи склеенными вместе, они не соберутся и в самую малень- кую книжку. Возможно, это происходит из-за того, что я опускаю незаметные для себя детали? Если так, тогда то, что я пишу,без моей консультации не прочитать... Прискорбно. Тем не менее, я отважился на создание ещё одного пространного опуса,претендующе- го на полезность в смысле общего развития. Не беда,если ничего в нём написанное вы не сможете запомнить (я и сам мало что оттуда помню, оттого и начал записывать). Это не стихотворение, которое надо выучить на урок, и не похождения с мечом и бластером. Тут просто даётся некоторая рассеянная ин- формация относительно возможности выраже- ния в словах (назовём этот процесс "верба- лизацией") некоторых структур,которые тру- дно в определённом смысле "пощупать".Заод- но по прочтении читатель сможет отдалённо представить себе сам метод анализа и,собс- твенно,изложения такого рода структур,хотя я, как автор,на указанном особенно не кон- центрировался. Обратите также внимание,что материал не исчерпывающ.  Следует, помимо всего прочего, избегать взглядов типа "а на самом деле...",особен- но касательно терминологии. Использованную терминологию я приведу здесь же, она обра- зована в контексте лично моего мышления и может не соответствовать интуитивной для читателя,тем более если он обладает специ- фическим образованием в этой области.Одна- ко,насколько известно мне,ранее опытов по- добного рода вербализации почти не произ- водилось, и в силу этого общепринятой тер- минологии не существует. Исходные же текс- ты, распространявшиеся на аналогичных пра- вах, читабельными не являются. Итак, мои термины:  disp(displacement - смещение)илиdist (distance - расстояние)- характеристика смещения от текущей позиции выходного по- тока (восстанавливаемого файла) до повто- ряемого фрагмента в LZ77-основанных мето- дах.(Каковые методы,собственно,и состоят в том,чтобы время от времени копировать фра- гменты откуда-то сзади куда-то вперёд, а именно "под курсор",то есть в оную текущую позицию.) Если передdispя ставлю минус, это означает,что данная характеристика уже имеет отрицательный знак и для получения адреса фрагмента ПРИБАВЛЯЕТСЯ,а не отни- мается из текущего адреса.  dispH, dispL- старший и младший байты disp.  putsилиlen- длина повторяемого фраг- мента. Фрагмент может копироваться поверх себя. Самый типичный такого рода случай возникает приdisp=1и сводится к повтору одного и того же байта. За указаниями типаdisp4илиlen7скры- вается количество бит в данном числе.  дерево (tree)- структура, используемая для хранения информации о том,как двоичные коды различных длин представляют некий на- бор символов (литералов). Рассматривались ФаноиХаффманом.Метод построения дерева, предложенный Фано,в общем случае хуже Хаф- фмановского, т. к. для последнего доказана оптимальность. ПоХаффманудерево строится последовательным объединением двух редчай- ших узлов с суммированием их частоты для использования этой суммарной частоты на последующих объединениях. По Фано,если читателя это заинтересует, дерево строится последовательным разделением отсортирован- ного по частотам списка литераловПРИБЛИ- ЗИТЕЛЬНО ПОРОВНУна левую (нулевую) и пра- вую (единичную) подветвь. Деревья же, если перейти к практике,могут храниться множес- твом способов - указателями, ярусами или вообще неявно.  %- двоичное представление;  #- шестнадцатиричное представление.  битовый поток- данные, извлекаемые по- битно (например,сдвигом);  байтовый поток- данные,извлекаемые по- байтно (что,очевидно,быстрее). Существует несколько способов совмест- ного использования обоих типов потоков в одном файле с последовательным доступом. (Кем эта идея реализована впервые, предпо- ложить трудно.)Это, например, простейший способ:  1.Из файла извлекается байт-буфер для битового потока, и указатель смещается;  2 и далее.Байты адресуются указателем. Биты же извлекают из байта-буфера, при его исчерпывании действуют аналогичноп.1. ...и его вариация,где вместо "байта-бу- фера битового потока" фигурирует "слово- буфер"(16 бит). В форматах, использующих оба потока в смешанном виде, важен порядок извлечения данных из них. Я не уточняю этот порядок в текстах, просто пишу структуру кода именно в нужном порядке. Т.е. если написано:  ─────────  %xxxx,dispH3- ссылка такая-то.dispLв байтовом потоке.puts=столько-то,  ───────── то понимать следует, что сначала из би- тового потока считывается%xxxx,dispH3,и уже потом из байтового -dispL. Как правило,биты извлекаются слева нап- раво(7,6,...или15,14,...).Исключением является компрессорRIP 0.2x,где это про- исходит наоборот. Но об этом будет написа- но отдельно.  А. Кодер \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/grf_eng.txt b/Docs/FORMATS/info_guide/grf_eng.txt new file mode 100644 index 0000000..c46701b --- /dev/null +++ b/Docs/FORMATS/info_guide/grf_eng.txt @@ -0,0 +1,46 @@ + + Beginning Quantity Meaning + ============ ======== ============ + #0000 #30(16x3) Palette. 16 triads of G,R,B colors + encoded as ASCII digits: + "0"(#30) - color is off + "1"(#31) - dark color + "2"(#32) - normal color + "3"(#33) - bright color + ╦■сюх фЁєуюх чэрўхэшх яЁшЁртэштрхЄё  + єЄшышЄющ GRFVIEW ъ "3". + + #0030(*) #03 "GRF" + + #0033(*) #01 Recommended attribute for background + (for small pictures) + + #0034(*) #01 Recommended border (#00-#0F) + + #0035 #4B Not used + + #0080(**) #01 X-coord (0-79) of top left corner of + the picture in bytes (=8 pixels) + + #0081(**) #01 Y-coord (0-199) of top left corner of + the picture in pixels + + #0082 #01 WIDTH (1..80) in bytes (=8 pixels) + + #0083 #01 HEIGHT (1..200) in pixels + + #0084 WIDTH*HEIGHT Pixels. Column #0 (HEIGHT pixels) then + column #1 ... column #(WIDTH-1). + +#84+WIDTH*HEIGHT #nnnn Attributes. The same but RLE encoded: +consists of pairs of bytes, in which the first byte in pair encodes number of repetitions of +second byte. + + +There are viewers of this format for CP/M (GRAF.COM), TASiS (grfview) +and TR-DOS (MCX viewer). + +By now I should save the screenshot from RetroX when the picture is ready then cut +it in Photoshop, make 16 color palette and save the +picture in 8bpp format. Then I run my utility RetroXtoGRF +http://alonecoder.nedopc.com/zx/retroxtogrf.rar diff --git a/Docs/FORMATS/info_guide/grfview.txt b/Docs/FORMATS/info_guide/grfview.txt new file mode 100644 index 0000000..d20a43f --- /dev/null +++ b/Docs/FORMATS/info_guide/grfview.txt @@ -0,0 +1,106 @@ + +╙ЄшышЄр GRFVIEW яЁхфэрчэрўхэр фы  яЁюёьюЄЁр ьюэюїЁюьэ√ї шыш +ЎтхЄэ√ї (ьєы№ЄшъюыюЁэ√ї) ърЁЄшэюъ т ЇюЁьрЄх CP/M-ЁхфръЄюЁр GRAF +т Ёхцшьх 640x200. ┬ ёрьющ ёЁхфх CP/M фрээ√х ърЁЄшэъш шьх■Є Ёрё- +°шЁхэшх BLK, юфэръю т OS TASiS юэю чрЁхчхЁтшЁютрэю чр фЁрщтхЁрьш +фшёъют√ї єёЄЁющёЄт ш, ўЄюс√ шчсхцрЄ№ яєЄрэшЎ√, чфхё№ шь с√ыю +яЁшётюхэю "ётюсюфэюх" Ёрё°шЁхэшх GRF - яЁюшчтюфэр  юЄ эрчтрэш  +ЁхфръЄюЁр. ╧ю¤Єюьє, яЁш яхЁхэюёх ърЁЄшэюъ шч CP/M т TASiS эх чр- +сєф№Єх ёьхэшЄ№ Ёрё°шЁхэшх! + +╬Єъєфр ьюцэю Ёрчфюс√Є№ GRF/BLK-Їрщы√? + +1) ═рЁшёютрЄ№ ёрьюёЄю Єхы№эю т уЁрЇшўхёъюь ЁхфръЄюЁх GRAF. + +2) ╤ъюэтхЁЄшЁютрЄ№ т CP/M шч шёїюфэ√ї ╠╬═╬╒╨╬╠═█╒(!) PCX-Їрщыют +яЁш яюью∙ш ёяхЎшры№эющ, яЁшырур■∙хщё  ъ ЁхфръЄюЁє єЄшышЄ√ +PCXBLK.COM. ╤рью-ёюсющ, Єръшь ёяюёюсюь ьюцэю яюыєўшЄ№ Єюы№ъю ью- +эюїЁюьэ√х ърЁЄшэъш. ═ю шї ьюцэю тЁєўэє■ ЁрёъЁрёшЄ№ тёх т Єюь цх +ЁхфръЄюЁх. + +3) ╤ъюэтхЁЄшЁютрЄ№ т RetroX (ЁхфръЄюЁ -> Import Picture -> Settings -> +ZX Clones Special -> TurboATM Multicolor Polychrome)... р яюёъюы№ъє ёюїЁрэ Є№ +юэ эх єьххЄ, Єю ёфхырЄ№ ёъЁшэ°юЄ, юсЁхчрЄ№ ърЁЄшэъє (°шЁшэр фюыцэр фхышЄ№ё  +эр 8, р т√ёюЄр эр 2), ёюїЁрэшЄ№ т ЇюЄю°юях т ЇюЁьрЄх bmp 8bpp (0-щ ЎтхЄ +цхырЄхы№эю яЁшэєфшЄхы№эю чрфрЄ№ ў╕Ёэ√ь), яюЄюь ёъюэтхЁЄшЁютрЄ№ єЄшышЄющ +RetroX to GRF. + + ╘╬╨╠└╥ BLK(GRF)-╘└╔╦└ + ===================== + + ╤ьх∙хэшх ╩юы-тю ╟эрўхэшх + ============ ======== ============ + #0000 #30(16x3) ╧рышЄЁр. ╧ЁхфёЄрты хЄ ёюсющ 16 ЄЁюхъ + чэрўхэшщ GRB-ЎтхЄют (шьхээю т Єръюь + яюЁ фъх), яЁхфёЄртыхээ√ї т тшфх ёшь- + тюыют ASCII: + + "0"(#30) - ЎтхЄ (G,R шыш B) т√ъы■ўхэ + "1"(#31) - ЎтхЄ эшчъющ шэЄхэёштэюёЄш + "2"(#32) - ЎтхЄ т Ёхцшьх BRIGHT 0 + "3"(#33) - ЎтхЄ т Ёхцшьх BRIGHT 1 + ╦■сюх фЁєуюх чэрўхэшх яЁшЁртэштрхЄё  + єЄшышЄющ GRFVIEW ъ "3". + + #0030(*) #03 ╠хЄър "GRF" - ючэрўрхЄ, ўЄю чр эхщ + ёыхфє■Є фтр чэрўр∙шї срщЄр + + #0033(*) #01 ╨хъюьхэфєхь√х рЄЁшсєЄ√ (INK & PAPER) + чрфэхую Їюэр, эр ъюЄюЁ√щ эрырурхЄё  + шчюсЁрцхэшх. └ъЄєры№эю фы  ърЁЄшэюъ, + яю ЁрчьхЁє ьхэ№°шї 640x200. + + #0034(*) #01 ╨хъюьхэфєхь√щ ЎтхЄ сюЁф■Ёр (#00-#0F) + ╠юцхЄ с√Є№ ръЄєры№эю яЁш шёяюы№чютр- + эшш эхёЄрэфрЁЄэющ ярышЄЁ√. + + #0035 #4B ═х шёяюы№чєхЄё . ╠юцхЄ с√Є№ чрсшЄю + ы■с√ь ьєёюЁюь. + + #0080(**) #01 X-ъююЁфшэрЄр (0-79) ыхтюую тхЁїэхую + єуыр т√тюфшьющ ърЁЄшэъш, шчьхЁ хьр  + т ёЄюысЎрї (1 ёЄыс= 8 яшъё= 1 срщЄ) + + #0081(**) #01 Y-ъююЁфшэрЄр (0-199) ыхтюую тхЁїэхую + єуыр т√тюфшьющ ърЁЄшэъш, шчьхЁ хьр  + т ёЄЁюўърї (1 ёЄЁ = 1 яшъёхы№) + + #0082 #01 WIDTH - °шЁшэр ърЁЄшэъш т ёЄюысЎрї + (юЄ 1 фю 80) + + #0083 #01 HIGH - т√ёюЄр ърЁЄшэъш т ёЄЁюўърї + (юЄ 1 фю 200) + + #0084 WIDTH*HIGH ╨рёЄЁ ьюэюїЁюьэюую шчюсЁрцхэш . + ╧ЁхфёЄрты хЄ ёюсющ яюёыхфютрЄхы№- + эюёЄ№ ёыхтр эряЁртю ёЄюысЎют юЄ + 1 фю x (x = WIDTH), ёюёЄю ∙шї шч + y срщЄют ърцф√щ (y = HIGH), ёўшЄр  + ётхЁїє тэшч. + +#84+WIDTH*HIGH #nnnn ╨рёЄЁ рЄЁшсєЄют. ╧юыэр  рэрыюуш  + ЁрёЄЁр ьюэюїЁюьэюую шчюсЁрцхэш  яю + ёЄЁєъЄєЁх, ё Єющ ыш°№ ЁрчэшЎхщ, ўЄю + юэ яЁшырурхЄё  т єяръютрээюь яю ьх- + Єюфє RLE тшфх. ╥ю хёЄ№, яЁхфёЄрты хЄ + шч ёхс  яюёыхфютрЄхы№эюёЄ№ фтєїсрщЄ- + э√ї ёыют, яхЁт√щ срщЄ т ърцфюь шч + ъюЄюЁ√ї ючэрўрхЄ ъюышўхёЄтю (1-255) + яюёыхфютрЄхы№эю шфє∙шї юфшэръют√ї + срщЄют рЄЁшсєЄют, р тЄюЁющ срщЄ - + ёюсёЄтхээю, ёрью чэрўхэшх рЄЁшсєЄр. + +---------------------------------- +╧Ёшьхўрэш : + +*) ═╬┬╬┬┬┼─┼═╚┼ ёяхЎшры№эю фы  єЄшышЄ√ GRFVIEW. ┬ юЁшушэрых - +эхшёяюы№чєхь√щ єўрёЄюъ. ╠юцхЄ с√Є№ чрсшЄ ы■с√ь ьєёюЁюь. + +**) ═хюс чрЄхы№э√х ярЁрьхЄЁ√ X ш Y ърЁЄшэъш, юёюсхээю фы  єЄшыш- +Є√ GRFVIEW, уфх шчюсЁрцхэшх ртЄюьрЄшўхёъш ЎхэЄЁшЁєхЄё , т ёююЄ- +тхЄёЄтшш ёю ётюшьш урсрЁшЄрьш. + +**************************************************************** +  2006, ЇхтЁры№. ╥шьюэшэ ╠ръёшь/NedoPC group +**************************************************************** +P.S. ╤ЄрЁЄют√щ рфЁхё COM-Їрщыр т TASiS - 24000DEC diff --git a/Docs/FORMATS/info_guide/howpack.W b/Docs/FORMATS/info_guide/howpack.W new file mode 100644 index 0000000..45c85d6 --- /dev/null +++ b/Docs/FORMATS/info_guide/howpack.W @@ -0,0 +1 @@ + Пишем архиватор  Практические принципы LZ упаковки  Прежде я рассказывал вам о распаковке и о структуре упако─ ванных данных. Пришло время поговорить и о том, как эти данные получаются.  0.  LZ(A. Lempel, J. Ziv)- способ упаковки, при котором в файле отыскиваются повторяющиеся фрагменты, группируются, как правило, в ссылки (естественно, не всё можно представить как ссылки - бу─ дут и отдельные символы), параметры каковых ссылок кодируются, как правило, по Хаффману.  Ссылка- факт наличия повторяющегося фрагмента (подстроки): содержит расстояниеdisp(от указателя текущей позиции упаковщи─ ка или распаковщика назад до момента встречи такого же куска) и длинуlen(сколько, собственно, байт совпало).  Окно,оно жеобъём словаря- максимальное расстояниеdispдля ссылок. Дальше упаковщик не ищет, а в кодировании обычно не пре─ дусматривает кодов для указания более далёких ссылок.  Метод Хаффмана(D.A. Huffman)- способ энтропийного кодирова─ ния, в котором длины символов (литералов) различны (но всегда имеют целое количество бит): для частых - короче, для редких - длиннее. А отличается он от аналогичных (например, от кода Фано) тем, что коды (а вернее, длины символов,т.к. все варианты набора кодов при данном наборе длин символов равновыгодны) выбраны самым эффективным образом, короче не придумаешь.  Дерево- совокупность кодов всех используемых символов при кодировании по Хаффману. Дерево можно хранить самыми различными способами. При распаковке удобнее всего как настоящее дерево (встретили0- переходим на байт вперёд, встретили1- переходим вперёд на столько, сколько указано в текущей ячейке). При упако─ вке - как таблицу (каждому символу соответствует некий код и его длина). В упакованном файле - в сжатом виде (перечисляются длины всех символов,и эта последовательность как-то кодируется,хотя бы тоже по Хаффману, с более коротким деревом - так вRIPиRAR). Пример дерева канонического вида, т. е. где ярусы углубляются слева направо, а внутри яруса символы отсортированы по алфавиту (именно такое дерево применяется вRAR):  корень  / \  / \ / \  1-й ярус (в нём пусто)  e /\ /\ /\ 2-й ярус  a b d f h/\  3-й ярус  c g  4-й ярус Ход по дереву налево кодируется нулём, направо - единицей. Здесь код символа"e"-00,а код символа"h"-110.И т.п.  1. Упаковывать, как мы понимаем, можно из одного места памяти в другое, можно в памяти с нахлёстом на исходные данные (теряя в качестве упаковки), можно из памяти в файл, можно из файла в память, можно из файла в файл. Из файла упаковывать весьма проб─ лематично и медленно, поскольку затрудняется поиск повторяющихся фрагментов, поэтому в архиваторах практикуют подгрузку обрабаты─ ваемого файла так, чтобы в памяти всегда имелось его содержимое от текущего указателя назад на длину окна. Для этого достаточно иметь буфер чуть больше размера окна. Но его не так легко обра─ ботать: при зацикленном окне процедура поиска повторов будет ве─ сьма сложной, а при незацикленном его надо регулярно сдвигать (и не только его, но и хэш-таблицы, о которых ниже), что очень медленно. Поэтому, а также из-за наложения упакованных данных на неупакованные, я пока не поддержал зацикленный словарь вZXRarи фактически режу файл на кусочки по127-128секторов. Как искать повторы? Поиск напролом(CPIRилиCPDR)- нетороп─ ливый процесс, скорость которого падает в квадрате от размера окна.John у нас употребляет выражение:"пакует медленно, как PCD"- это сказано о поиске напролом. Ускоряют поиск с помощью ключей и таблиц хэширования, о которых я сейчас расскажу.  Таблица ключей. Это очень распространённая идея. Суть её в том, что группа байт (здесь 2или3байта; а вALASM'е,например, до58,поско─ льку ключ используется для поиска меток по имени) кодируется несколькими битами ключевой суммы (разумеется, для разных групп байт эти коды могут совпадать). Создаём таблицу, в которой при каждой ключевой сумме будет записан адрес, по которому она в последний раз встретилась, или адрес ниже начала окна в против─ ном случае. Таким образом, прочитав2-3байта из-под указателя текущего положения в файле, мы можем быстро найти адрес,по кото─ рому с высокой вероятностью будут такие же2-3байта. Подробнее проALASM: ────────────────────────────────────────────────────────────────  Таблица меток состоит из64или128(зависит от версии) спис─ ков,которые объединяют метки с одинаковыми ключевыми суммами.Это не нужно для показа меток, например,STSплюёт на эту структуру.  +0-младшие 6 бит- длина всей метки (т.е. длина имени метки плюс5). Еслибит 6=1,то метка - имя макроса, еслибит 7=0,то метка определена.STSна это тоже плюёт. Для последней (с точки зренияSTS'а) метки+0содержит0.Hа нейSTSостанавливается.  +1,2-ЧИСЛО, т.е. содержимое метки.STSползёт по меткам,пока число не совпадёт с нужным ему.  +3,4-адрес следующей метки в ЭТОМ списке.STS'уне нужен, т.к. он движется по всем спискам и вообще в обратном порядке.  +5-имя метки задом наперёд.  ВSTS 5.x, 7.x:в ячейке #fe88 номер первой страницы меток (для порта #7ffd), номера остальных страниц не передаются; в ячейках#fe7c, 7dадрес хвоста таблицы меток, с которого начина─ ется поиск(+1).  Unreal Speccy (v0.27) ищет в#17, #57страницах STSи берёт данные о странице и адресе начала таблицы меток из него. ────────────────────────────────────────────────────────────────  Таблица хэширования. Каждой ячейке окна приводится в соответствие ещё2байта, в которых дан адрес СЛЕДУЮЩЕЙ (назад) ячейки, в которой2-3байта образуют ту же ключевую сумму.  2или3байта следует выбрать для хэширования? Это на любите─ ля. ВHrust 2.x было2байта, и2-байтные короткие ссылки(а2- байтные ссылкивсегда короткие - не дальше256байт, иначе выго─ днее просто закодировать эти2символа) искались в основном цик─ ле поиска. ВZXRar-3байта,и2-байтные ссылкиищутся в отдель─ ном цикле. В этом случае режим упаковки.rzx(для текстов - там 2-байтных ссылокнет) работает несколько быстрее, но режим.rar (для всего остального,там такие ссылки есть) - несколько медлен─ нее. В исходникеZXRar можно включить 2-байтные ключи, но режим .rarот этого не ускоряется, он всё равно организован отдельно (поиск2-байтных ссылокведётся, если обычным поиском ничего хо─ рошего не найдено). Можно,конечно,организовать две хэш-таблицы и две таблицы ключей - одна пара для поиска2-байтныхсовпадений, вторая - для всех остальных. Но нужно больше памяти -2..5допо─ лнительных килобайт. Итого получаем размер требуемой памяти:window*3+keys,что для 12-битных ключей и 32-килобайтного словаря даёт32*3+8=104k. ВHrust 2.xиспользуются 13-битные ключи (занимают страницу), в ZXRar- 11-битные (занимают 2/3 экрана).В том же исходникеZXRar можно включить 13-битные ключи, которые будут лежать в верхней памяти. Разницы в скорости между 11- и 13-битными ключами прак─ тически нет (насколько помню, по замерам было около5%). Как видим, в128kпамяти можно этим методом обработать только 32k,от силы40kокно. Возможно, поэтому придётся в скором вре─ мени перейти на упаковщики, рассчитанные на256kмашины. Метод поиска с хэшированием работает медленнееCPIR/CPDRна длинных группах повторяющихся байт. Кто подскажет решение, как ускорить? ВZXRarэто очень заметно!А.В. Кадачпредлагает огра─ ничивать поиск по хэшам несколькими десятками прыжков, соответс─ твенно, с потерей качества сжатия... Hrumer>  Я дляLaser Compactдумал обойти проблему следующим образом:  По-особому относиться к последовательностям байтAAAAAA...и ABABABAB...,длинойL,больше определенной,подбираемой на тестах (думаю, от3..5байт). Они очень часто встречаются в картинках.  При заполнении таблицы - той, где лежат адреса предыдущих вхождений символа (или символов, если хэширование идёт не по одному байту):  Заполнять адрес для первогоА.Вместо адреса для второгоА записываем длину последовательности байтовААА... (ABAB...).При поиске ранее записанная длина последовательности используется для точного определения адреса, где находится искомая строка. Пример такой: ранее встретилась посл.AAAAAAAB.Текущая посл.: AAAAC.В результате сравниваем строкиAAAABиAAAAC.Естествен─ но, про то, что A у нас совпадают, мы знаем. Остаётся сравни─ вать с символовВиС.А вдруг они совпадут,и длина последовате─ льности будет равна5,или больше...  Ну а самый большой выигрыш получается из-за того, что в этой таблице нет частых ссылок, присущих при обработке вышеуказанных последовательностей. По сути, мы не забиваем таблицу в некоторых местах. А для того, чтобы качество паковки не падало, надо всё же заполнять таблицу для символовAA,предшествующих символуB из последовательности AAAAAAAB.Хотя это не обязательно, и есть несколько вариантов, можно подумать и поэкспериментировать. Мно─ гое зависит от того, по скольким байтам происходит хэширование.  Поскольку уLCпоиск идет ещё и "вверх ногами", то схема была чуть сложнее, да и то - расписана только на бумаге. К сожалению, я её так и не реализовал.Сейчас всё написано по памяти,некоторые моменты я опустил.  Еще могу дополнить: возможно, более оптимальным будет то, что под повторяющиеся символы типаAAAAAдлиной больше определенной лучше завести отдельную таблицу в256элементов. Это поле для экспериментов, опять же.  2.  Hrust кодирует ссылки сразу же после того, как он их нашёл. Но его деревья фиксированные. Для серьёзного же архиватора перед кодированием нужно строить оптимальные деревья. Где хранить ин─ формацию, на основе которой мы будем их строить, и где хранить информацию, которую мы, собственно, будем кодировать? Ведь мы кодируем не сам исходный файл, а LZ поток со ссылками, а искать ссылки по второму разу накладно, не так ли? Поэтому нужно при LZ-просмотре файла запоминать:  1.Количество вхождений всех символов текста и всех спецкодов LZ (статистик может быть несколько: например, спецкоды смещений вRARкодируются отдельным деревом).  2.ВЕСЬ LZ-поток в неупакованном виде (для этого нужен допол─ нительный буфер, не совпадающий с буфером окна. Можно, конечно, залезать и на начало буфера окна, следя в LZ-поиске за его изме─ няющимся размером, но тогда сжатие будет хуже). Всех символов, включая спецкоды LZ, может быть больше256,поэтому я, например, вZXRarхраню лишний, 8-й, бит отдельно, для чего организуется перемежаемый битовый поток а-ля Hrust.В том байтовом потоке (без 8-го бита) должны лежать параметры LZ-спецкодов, т.е. длина ссылки (если она не задана в LZ-спецкоде явно) и смещение.  Только просмотрев существенную часть файла (десятки кило─ байт), можно строить дерево Хаффмана и кодировать полученный LZ- поток по Хаффману, записывая в.rar-архив. Потом можно начинать новый LZ-поток и новую статистику. Метод Хаффмана я уже описывал в общий чертах вIG#5.Суть его вот в чём.  1.Разные байты, в зависимости от их вероятности, кодируются кодами разной длины.  2.Длины кодов в потоке каждый раз не лежат, взамен имеется двоичное дерево самого общего вида: если прочитали из потока нуль, то идём по дереву налево, если единицу - направо. Дошли до листа - конец; в листе записан символ (байт). Как хранить дерево в потоке, я уже рассказывал в Inferno#4(в описании формата .rar).Как его хранить в памяти - дело конкретного распаковщика, но лучше всего применять декодеры из распаковщиковderipили smallunr.Дерево в них следующее. Каждый узел -4 байта;2бли─ жайших его потомка корня лежат в начале буфера дерева:2 байта для левого и2 байта для правого потомка; в "потомках" записан либо символ (тогда2-йбайт<#40), либо адрес, где этот потомок хранится как узел (тогда2-йбайт равен старшему байту адреса).  3.Коды Хаффмана, в отличие от неоптимальных кодов Шеннона- Фано, выбираются следующим образом.В неком буфере для сортировки имеем таблицу символов и их вероятностей; объединяем2самых редких символа и сохраняем их в ту же таблицу как узел дерева, вероятность которого равна суммарной вероятности этих символов,- старые же символы удаляем из списка; далее опять ищем2самых редких символа (символом можно считать и уже полученный узел де─ рева) и так же объединяем их; и так далее,пока не останется один узел, который объединять уже не с чем - это и будет наше дерево. Хранить список-дерево во время такой сортировки лучше по4 байта на каждый элемент.2 байта на частоту,2 байтана содержимое (номер символа или адрес левого потомка, правый же - четырьмя байтами дальше). Соответственно,после объединения символов/узлов они переносятся в другой буфер, который организуется в конце буфера, где мы держим символы, и растёт сверху вниз. Символы же надо отсортировать по вероятностям (т. е. на практике - частотам встречи в файле) заранее, и вносить объединённый узел в нужное место списка, в соответствии с его вероятностью. После такой сортировки мы не можем сразу сохранить дерево по стандартуRar/Rip.Стандарт у них такой, что (при описании дере─ ва) для каждого символа в упакованный файл сохраняется лишь дли─ на этого символа (от0до15,где0- символ отсутствует).А сим─ волы распределяются на каждом ярусе (совокупности символов рав─ ной длины) в алфавитном порядке. ВRip- в обратном алфавитном, но это не суть важно. Поэтому дерево нужно перестроить, предва─ рительно найдя длины всех литералов. Делается это так. В соответствии с первым деревом (полученным после сортировки) составляем таблицу: для каждого символа - его длина(1..255). Составляем её от нашего корневого узла (который, как вы понимае─ те, сейчас один-одинёшенек лежит в начале буфера для сортировки) псевдорекурсивно: в начале обхода сохраняем в стеке"некий код"; идём налево и при этом сохраняем в стеке путь направо (адрес и текущую глубину); дойдя до листа (символа), дальнейшую дорогу выясняем из стека, а если там"некий код",то дерево кончилось.  Кадач говорит в своей кандидатской диссертации(с. 60),что есть способ нахождения длин всех литералов без занудного про─ цесса поиска-объединения-выкидывания-сдвига (то есть вообще без составления первого дерева), но самого способа не приводит. Дальше, каким бы способом мы ни строили первое дерево, всё же нужно удалить ярусы выше 15-го,потому что15- максимальная длина символа, разрешённая вRar, Ripи им подобных упаковщи─ ках. Мой способ следующий. При вышеописанном построении табли─ цы длин символов параллельно будем строить таблицу количества символов для каждой конкретной длины. Составили? Прекрасно. Ищем самую длинную длину, которая вообще есть. Допустим, что такой длине (назовём еёN+1) соответствуетCсимволов. Это нехорошо; эти символы надо опустить на уровень (ярус) ниже (наN-й) за счёт поднятия символов длинойN-1(поднимаем тоже наN-йуро─ вень). На каждые 2опущенных символа длинойN+1(а их числоC, козе понятно,чётно) приходится1поднятый символ длинойN-1.Это было бы прекрасно, если бы символы длинойN-1всегда можно было найти. Однако их иногда не хватает (может и вообще не быть), поэтому приходится довольствоваться поднятием символов длиной N-2(поднимаем наN-1-йуровень): на каждый такой поднятый сим─ вол приходится 4 опущенных символа длиныN+1.Если нетN-2, берёмN-3- на каждый такой поднятый приходится8опущенныхN+1. И так далее. В конце концов, после нескольких операций по опус─ канию символов максимальной длины, длин>15не остаётся.  Здесь "опускание" на ярус - это движение вверх по вышеприве─ дённому рисунку. Дело в том, что деревья принято рисовать вверх корнем. Имея массив длин символов, упаковщик может составить массив кодов символов: начиная с1-гояруса, идя по ярусу в алфавитном порядке, присваиваем символам коды от0и далее(после0следую─ щий код будет1- итого два кода,но1используется только в слу─ чае, если дерево имеет только1-йярус, т. е. имеется всего два символа).Допустим, мы нашли на1-мярусе один символ, следова─ тельно, не нашли применения коду1.Приписываем к этому коду но─ лик (итого получаем10) и идём так же по2-муярусу, присваивая символам коды от10до11(если бы не было символов на1-мяру─ се,то мы перебирали бы коды00, 01, 10, 11).Допустим,что мы не нашли на 2-м ярусе ничего. А наш заготовленный код, как я уже говорил,10.Приписываем к нему нолик, идём на следующий ярус... И т.д. Можно начинать с15-гояруса и перебирать коды, начиная с 111111111111111.Результат будет тот же, потому что наш массив длин символов взят не с потолка - ведь мы строили полностью забитое дерево, а значит, все коды обязательно заняты.ZXRar,во всяком случае, начинает с15-го.  3. Стратегий упаковки (т.е. стратегий выбора оптимального разби─ ения текста на "лоскутки") существует несколько. Самая простая реализована во всех спектрумовских упаковщиках, кроме, наверно,RIP(например, она есть вZXRar:режимFast). Стратегия такова. Ищем внутри окна (допустим, ищем от текущего указателя назад, всё дальше и дальше) вхождение подстроки, лежа─ щей под указателем. Допустим, нашли мы его на расстоянииdisp,а совпало в этом вхожденииNсимволов. Запоминаем этот результат. Ищем следующее вхождение.Смотрим,ЛУЧШЕ ли оно,чем уже найденное. Понятие "лучшести" для упаковщиков с фиксированными деревьями совершенно однозначно: меньше бит нужно для кодирования такой ссылки (хорошо) или больше (плохо)? Для упаковщиков типаRIPи RARситуация сложнее.Во-первых,ясно,что при нашем поиске назад нахождение ссылки (вхождения) с той же длиной,какую уже находили (N),ничего для упаковки не даёт,ибо из двух ссылок равной длины (N)выгоднее взять ту,в которой более близкое смещение. Аналоги─ чно для ссылок,у которыхNещё меньше. О ссылках длиной2вообще разговор отдельный.Во-вторых,считаем, что увеличение длины(N) на 2символа - это выгодно (хотя, строго говоря, это не всегда так).Затем(в-третьих)после некоторых экспериментов выясняется, что увеличивать длину ссылки на1выгодно, только если старая ссылка имела большой disp.Точнее: после ссылки со смещением #ff00..#ffff- если новая ссылка не дальше,чем на#f400;а после ссылки со смещением #fe00..#feff- если новая ссылка не дальше, чем на#e800. После нахождения лучшей ссылки мы должны не только запомнить саму ссылку в LZ-потоке,но ещё и дополнить хэш-таблицу и таблицу ключей для каждого из символов найденной строки. Если же мы не нашли хорошей ссылки и предпочли закодировать символ, то допол─ нить таблицы нужно только для одного текущего байта и только для одного ключа, соответствующего этому месту текста (т.е. ключа, формируемого из текущего байта и одного-двух следующих). Старый адрес, лежавший в таблице ключей по этому ключу, мы должны поло─ жить в хэш-таблицу по текущему адресу, а сам текущий адрес - в то самое место таблицы ключей.Процедура поискаДмитрия Пьянкова, переделанная мною для ZXRar,обновляет эту таблицу для одного текущего адреса (см. на входе и выходе в процедуру). Но можно сделать это и снаружи процедуры. Следующая стратегия применяется в пцшной библиотекеZlib,а также вZXRar(может быть, и в пцшном Rar) в режимеBest.Это "Lazy evaluation".Суть стратегии в том, что, найдя ссылку,мы её не сразу вносим в поток, а сперва пробуем посмотреть,что получи─ тся, если мы закодируем текущий символ как символ,а ссылку будем искать со следующего байта. Сравнивая две найденные оптимальные ссылки (одна от текущего указателя, другая - от следующего бай─ та),принимаем решение,какая из них выгоднее. Может быть,выгоднее 2-я. Что значит "выгоднее" в этом случае? Чешем в затылке и раз─ биваем диапазон всех возможныхdispна поддиапазоны, для каждого из которых методом научного тыка находим максимальныйdisp,ко─ торый даст выигрыш при увеличении длины(N)на1символ. ВZXRar до последних версий был настройщик, в котором клиент мог было подбирать эти пределы для собственного развлечения,но никто,нас─ колько я знаю, этим развлекаться не стал. Поэтому настройщик уб─ ран.Во всяком случае,настройки для методаRar(для естественного для него разбиения на диапазоны) приведены в help'е кZXRar: ──────────────────────────────────────────────────────────────── Настройки: Верхние две - границы,выше которых разрешается увеличивать длину ссылки на единицу (в главном цикле) после нахождения ссылок со смещением #ffxx и#fexxсоответственно. Увеличение на2, 3,... происходит без вопросов, так как выгодно. Остальные15- границы,выше которых разрешается увеличивать дли─ ну ссылки на единицу (вlazy evaluation,только для режимаbest) после нахождения ссылок в диапазонах:  #ff80-#ffff  #ff00-#ff7f  #fe80-#feff  #fe00-#fe7f  #fdxx  #fcxx  #fa00-#fbff  #f800-#f9ff  #f400-#f7ff  #f000-#f3ff  #e800-#efff  #e000-#e7ff  #d000-#dfff  #c000-#cfff  #a000-#bfff Учтите, что при пересечении границы#e000сдвигается кодируемая длина. Т. е. неизвестно, какую ссылку закодировать выгоднее: (#dxxx,5)или(#exxx,4). Старые настройки (до 07-й версии):  F0 E8 FE F8 F4 F4 FA FA F8 F4 F0 E8 E0 D0 C0 A0 80 Новые настройки:  F4 F0 FD F4 F0 F0 FA FA F8 F4 F0 E8 E0 D0 C0 A0 80 ──────────────────────────────────────────────────────────────── ДляRIPдиапазоны кодируются так же, поэтому разбиение анало─ гично, и выгоднейшие настройки, видимо, будут близки к этим. Сложно сочетать этот метод с хэшированием: приходится восста─ навливать состояние таблиц после 2-го поиска, если 1-й оказался выгоднее(ведь дальше выполняется процедура обновления таблиц по всем символам 1-й ссылки,кроме 1-го! А 2-й как раз туда входит). Точнее говоря, нужно восстановить таблицу переходов по ключам (поиск занёс туда текущий адрес). Хотя поиск ещё занёс старый адрес, бывший там, в хэш-таблицу, но никакого влияния это не оказывает:его всё равно пришлось бы туда занести по самой логике составления хэш-таблицы. За обновление таблиц для всех символов ссылки, кроме 1-го, вZXRarотвечает циклFILPO1. СтратегияLazy evaluation в1.5Ў2раза медленнее обычной, но даёт заметный выигрыш в упаковке. Лучшая стратегия,"Оптимальный LZH",описана вIG#6.На ZX она пока нигде не реализована. Обращаю внимание! Распаковщику абсолютно не важно,какой стра─ тегией пользовался архиватор, разница - только в размере архива! Это замечание приходится делать, потому что есть люди, путающие стратегию с методом сжатия (см. об этом в журналеiS-Files ##1и 3). А раз есть такие люди, то,вероятно,есть и источник подобной дезинформации. Собственно говоря, такие люди тоже представляют из себя источник дезинформации - для своих читателей.  4. Следует сказать немного слов и о том, как создать сам архив, точнее, содержащий его файл с заголовками. Когда от пользователя получена команда на упаковку, наша про─ грамма должна проверить наличие архива с указанным именем на диске. Если таковой отсутствует, то нам, по логике вещей,следует его создать (коротенький файл, состоящий только из заголовка ар─ хива). Если его создать нельзя или же он есть,но не в конце дис─ ка,то самый простой выход - ругнуться и перейти в начальную точ─ ку программы (показ каталога и т.п.). Если его создать можно или он уже есть в конце диска, то надо продолжить операцию. Не воз─ браняется и стереть одноимённый архив, создав при этом новый в конце диска. Переносить же старый архив в конец диска - сомните─ льное удовольствие, поскольку архивы бывают большие, а дискета не резиновая. Продолжая размышление, можем предложить создать новый сателлит старого архива(сателлит - файл с тем же именем, но с изменённой 1-й буквой расширения: 0, 1, 2 и т.д., рассмат─ риваемый TR-DOS-программами как продолжение предыдущего файла)с отрывом от него,хотя обрабатывать такие разделённые куски архива будет не очень просто. Отдельный разговор - упаковка наHDD,там можно развернуться во всю силу. Для поиска файла на диске TR-DOSпредоставляет функцию#3d13 C=#A,она возвращает в регистреCномер элемента каталога, сов─ падающего с заданным(#5cdd-e5)или#FF,если такого нет. Как создать файл? Есть2принципиально различных способа.1-й опять-таки предоставляет TR-DOS:функция#3d13 C=#B, HL=адрес начала файла в памяти,DE=длина.2-й- ручное формирование дес─ криптора в каталоге. Номер этого дескриптора берём из ячейки#e4 системного сектора (здесь и далее -8-й сектор 0-й дорожки,счи─ тая оба числа с нуля),сектор и дорожку - из#e1/2.После ручного создания дескриптора следует записать вслед за ним байт#0и исправить три значения в системном секторе:free(#e5/6),первый свободный сектор и его дорожка(#e1/2),количество файлов(#e4). Теперь внимание! Поскольку в наш архив могут попадать упако─ ванные блоки длиннее объёма непрерывной памяти, то дописывать файл нам обязательно придётся по частям, верно? Значит,нам нужна подпрограмма записи байта в "выходной поток", которая будет пи─ сать в буфер памяти,пока он не переполнится,а когда переполнится - сваливать его весь на дискету(и переустановить указатель,ука─ зывающий, в какое место памяти писать, на начало нашего буфера памяти).При окончании же упаковки - выгружать ту часть буфера, которая заполнена(если там действительно что-то заполнено. Выг─ ружать 0 байт бессмысленно),после чего заново сформировать дес─ крипторЫ файлОВ (!) и системный сектор. Почему множественное чи─ сло? Потому что архив при добавлении нового блока мог превысить 255секторов (или255*Nсекторов, смотря по числу уже имевшихся кусков). В его обработке есть опять-таки два варианта: либо счи─ тать за начало файла тот сателлит (кусок), которые был последним на момент начала упаковки, либо считать за оное начало действи─ тельное начало файла. В последнем случае перед созданием новых дескрипторов нужно просмотреть все старые. Беда ещё такая, что в нашем архиве, разбитом на куски по255 секторов, мы априорно не знаем расширение последнего куска. Факт наличия архива-то мы определить можем, а вот спозиционироваться на последний кусок - уже проблемы...Всё-таки нужен ручной поиск. Что служит начальным содержимым буфера? Правильно, служит им последний недозаполненный сектор архива, который мы предварите─ льно считаем с диска. Если мы архив создаём, то читать не надо - этот недозаполненный сектор мы сами только что и записали, а со─ держит он заголовок архива. ВZXRarвсё это организовано несколько сложнее из нужд скоро─ сти. Но для начала всё равно пришлось писать медленный вариант, иначе просто невозможно отладить программу. Обработку переполнения диска можно организовать по-всякому, на любителя. Простейший вариант - запомнить положение стека в начальной точке программы (см. про неё выше) и вываливаться туда при обнаружении ситуации переполнения. При этом архив, вероятно, будет стёрт, а может, и не будет, зависит от того, в каком сос─ тоянии вы оставляли0-ю дорожкуперед упаковкой блока.  5. Немного отходя от темы, сделаю небольшое замечание по поводу swap'а при распаковке. Одним словом, как это реализовано в ZXUnRar? ────────────────────────────────────────────────────────────────  Подгрузка с диска идёт черезLOADBLK(это подгрузка самого архива, к свапу она не относится). Свап реализован в нескольких циклах типа  out frPG  ld a,(de)  out curPG  ld (hl),a  inc e  call z,restore  inc l  call z,store  Это операция копирования подстроки выходного файла откуда-то сзади в текущий адрес. Здесь DE- это входной адрес. В одном случае он лежит в самом выходном буфере, а в другом - в буфере подгрузки. (Трек-сектор для подгрузки вычисляется мудрёно,чем вы можете полюбоваться в исходникеZXUnRar,я сам там путаюсь :))  restore занимается подгрузкой следующего сектора из свопа. storeувеличиваетH,и если оно превысило предел (выходной буфер переполнился), записывает весь буфер в файл. Свопом, понятное дело, является сам этот самый выходной файл. ──────────────────────────────────────────────────────────────── Желаю вам приятного архиваторописания ;) Включайте свои аласмы - и в путь... A. Coder \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/hrumhrst.W b/Docs/FORMATS/info_guide/hrumhrst.W new file mode 100644 index 0000000..e8cb883 --- /dev/null +++ b/Docs/FORMATS/info_guide/hrumhrst.W @@ -0,0 +1 @@ + Hrum & Hrust  Hrum 3.5i  Для распаковщикаHrumавтором заявлена особенно высокая скорость:33 k/с.К сожа- лению,я не обладаю информацией,какие имен- но типы данных имелись в виду,но в общем и целом автор прав - это самый быстрый LZ- распаковщик с битовым потоком. За счёт уп- рощенного в связи с этим формата он также и чрезвычайно короткий. К несчастью,автор- ский пакет не предлагает распаковщика без перекидывания для использования его на не- сколько блоков. Перекидывание - функциональная черта очевидных предшественников Hrum на ниве сжатия 48k игрушек.Идеология этого процес- са такова: кодовый блокОБЯЗАНнаходиться непосредственно за распаковщиком;распаков- щик при запуске перекидывает свою активную часть в тихое место(как правило,#5bxx),а упакованный блок - в конец выделенной па- мяти для распаковки; все адреса для этого рассчитаны заранее (пакером) и лежат в те- ле распаковщика.  ВHrumвведено три оригинальных ухищре- ния:  1.5 байт конца файла (это важная часть файла, создаваемая для разрыва между адре- сами "откуда" и "куда распаковывать") ко- пируются вместе с распаковщиком в "тихое место" одной командойLDIR.  2.Предложен ещё более короткий способ реализации стандартного дерева из16вари- антов, с которым мы ещё встретимся: ────────────────────────────────────────── LD E,1 pair LD A,#80 pair0  RLA JR C,pair0;2 прохода CP 3 ;A=0..3 JR C,treeend ADD A,E LD E,A XOR C ;=#10 !!! JR NZ,pair treeend ADD A,E ──────────────────────────────────────────  Хитрость в командеXOR C.Т.е. получи- лось короче,чем вPCD6.2(там былоSUB 15) и тем более чем вMS Pack(там не было ци- кла и был лишнийXOR A). KонстантаC=#10 используется и в другом месте: при обрабо- тке битового потока.  3.Один и тот же цикл взятия3-4бит (ближе к концу распаковщика) используе- тся как для взятияdispH(приputsЄ4),так и для взятияdispL(приputs=1),причём за всю работу этого цикла ни разу не портится флагZ!В этом флаге и лежит признак, что делать с результатом... Словарь (окно) всего4k. Имеется два чередующихся потока данных: битовый и байтовый. Битовый поток хранится кусками по16бит и снимается в регистро- вую пару HL.Пока HLсдвигается,16бит отсчитываются в регистреBкомандойDJNZ. Когда они кончаются, из потока берётся но- вое значениеHL.  Упакованный блок с распаковщиком содер- жит: Инициализацию распаковщика. Активную часть распаковщика. 5 байтконца файла. 2 байтаначала битового потока. 1 байт- первый байт файла.  И далее согласно битовому потоку: %1- вставить байт из байтового потока. %000,-disp3- копировать 1байт с адреса минус1..8. %001- копировать 2байта:-disp8берется из байтового потока. %010- копировать3байта аналогично. %01100- копировать Nбайт (Nберётся из битового потока,N=0- конец файла).Здесь и далее после определения длины произво- дидся гадание по биту из битового потока: %0--dispLберётся из байтового потока; %1- аналогично, но перед этим -dispHв количестве 4бит берётся из битового по- тока. Обратите внимание,избыточность фор- мата:-dispH=#FFкодируется двояко, автор сэкономил 1байт распаковщика. Непонятен также юмор автора с командойRES 5,A,ко- торая могла бы выглядеть какLD A,#1f. %01101- копировать4байта как выше. %01110- копировать5. %0111100- копировать6. %0111101- копировать7. %0111110- копировать8. %011111100- копировать9. %011111101- копировать10. %011111110- копировать11. %01111111100- копировать12. %01111111101- копировать13. %01111111110- копировать14. %01111111111- копировать15.  Hrust 1.x  Распаковщик Hrust 1.x - самый хитрый распаковщик на ZX. Несмотря на небольшой размер, он вполне способен запутать любого заглянувшего. Уникальность формата в том,что он прямо предназначен для сжатия кодов.Для этого он снабжён кодами копирования с разрывом, ка- ких больше нигде нет. Дополнительно приме- нены расширяющиеся коды смещений,которые в начале файла короткие и указывают недале- ко, а ближе к концу - длинные. В авторском комплекте имеется два рас- паковщика - с входным потоком в стеке и с входным потоком вIX.Еще один распаковщик в виде бейсик-загрузчика сделал из первого Alone Coder.Все они эквивалентны. Распаковщик начинается с переброски упакованного блока в конец памяти,выделен- ной для распаковки. Переброска идёт только в случае, если адрес конца упакованного блока изначально меньше адреса конца памя- ти для распаковки. Бейсик-вариант этого фрагмента не содержит,там нужно самому ко- нтролировать,чтобы упакованный блок в про- цессе распаковки не портился.Тем не менее, есть шанс, что он запорется и в авторских распаковщиках, после переброски. Для этого конец блока должен плохо паковаться. Битовый поток берётся кусками по16 бит.C содержит константу16. Dсодержит один сброшенный бит,положение которого от- носительно левого края байта определяет длину расширяемых ссылок. ИзначальноD=#bf (назовём это состояние "2 бита расширяемой ссылки"),далее периодически происходитRRC D("3..8 бит расширяемой ссылки"). Упакованные блоки имеют заголовок: +0"HR". +2распакованная длина. +4упакованная длина. +6шесть последних байт блока. +12два байта начала битового потока. +14первый байт блока. +15сами упакованные данные.  Обработка упакованных данных осуществ- ляется согласно указаниям битового потока: %1- получить байт из байтового потока и поместить куда распаковываем. %000,-disp3- копировать 1байт со смеще- ния-1..8 %001- копироватьC=2байта.dispкодируе- тся так: %00Ў%01:-dispH=#fdЎ#fe, -dispLв битовом  потоке; %10:-dispH=#ff,далее исходя из байтово-  го потока: числа <#e0 понимаются как  -dispL (ссылка обычная), Є#e0 хитро:  RLCA:XOR C,при A=-1 расширяется длина  ссылки, иначе SUB 15и получаем-dispL=  =#b2Ў#ee(ссылка со вставным байтом:байт  из$-disp,байт из байтового потока,байт  из$+2-disp); %11,-disp5:обычная ссылка (через%10та-  кие короткиеdispописать нельзя); %010- копироватьC=3байта. Здесь и далее dispкодируется так: %00:-dispH=#fe, -dispLв битовом потоке; %01:-dispH=#ff,далее исходя из байтово-  го потока: числа <#e0 понимаются как  -dispL (ссылка обычная), Є#e0 хитро:  RLCA:XOR C,при A=-1 расширяется длина  ссылки (на самом деле не используется),  иначе SUB 15 и получаем-dispL=#b1Ў#ef  (со вставным байтом:байт из$-disp,байт  из байтового потока, байт из$+2-disp); %10,-disp5; %11:расширяющаяся ссылка.-dispHберётся  из битового потока, число битов согласно  D (#bf..#fe соответствует 2..8 бит).  -dispL берётся из байтового потока. В  остальном ссылка как ссылка. %01100- копировать C=4 байта как выше. Здесь и далее коды ссылок со вставным ба- йтом невыгодны, но есть. %01110- копировать5. %0111100- копировать6. %0111101- копировать7. %0111110- копировать8. %011111100- копировать9. %011111101- копировать10. %011111110- копировать11. %01111111100- копировать12. %01111111101- копировать13. %01111111110- копировать14. %01111111111- копировать15. И особенные случаи: %01101000001111- конец файла. %0110100,len7- еслиlen7>15,тоlenбудет равноlen7*256+байт_из_байтового_потока. В любом случае результат ляжет вBC,а далее см. случаи сlen=3..15. %0110101xxxx-12Ў42(чётное число) байтов из байтового потока. %011011,-disp4:ссылка со вставным байтом: байт из$-disp,байт из байтового потока, байт из$+2-disp.Сделано из-за того, что в%001предусмотрены только-dispL=#b2.. #ee,причем чётные, а в%010только#b1.. #ef,нечётные.  Hrust 2.x  Формат предназначался для сжатия текс- тов.Несмотря на то,что авторский упаковщик был неудобный,а формат(1998)с появлением RIP(2000) иZXRar(2003)устарел, он всё же стал единственным действительноСТАНДА- РТНЫМформатом упакованных данных на ZX. И не только для текстов.  Одних упаковщиковHrust 2.xсейчас из- вестно девять (!), все они выросли из кода оригинального упаковщика. Количество же программ,поддерживающих формат на распако- вку, я не определил.  Идеология принята противоположнаяHrum: выгрузка упакованных блоковТОЛЬКОбез ра- спаковщика, распаковщик отдельный,не испо- льзует стек. Может быть, из-за сочетания этих идей формат победил остальные? На практике имеется две версии заголов- ков упакованных блоков:v2.1иv2.3.Стан- дартом является первая.Вторая используется только в архивахHrip.  v2.1: смещение длина  +0 3 "hr2";  +3 1 "1". Если bit7=1, то файл был просто "сохранен"; (а значит - w[+4]=w[+6])  +4 2 длина исходного файла;  +6 2 длина упакованного файла;  +8 w[+6] упакованный файл. Перед упакованным блоком хранятся пос- ледние6байт файла,сами эти6байт не па- куются. Максимальная длина повторяющегося фраг- мента,кодируемого одной ссылкой:4095байт (#fff).Максимальная ссылка назад:-65535 байт (окно в авторском упаковщике:16384 байт, в других известных упаковщиках дос- тигает32768,но уменьшается при приближе- нии упакованного куска к непакованному - упаковка идет в тот же буфер) 011000nnnn- несколько непакованных байт, а точнее,12+nnnn*2(не более42,как ви- дно), в байтовом потоке - эти байты. 1- просто один непакованный байт (в бай- товом потоке - этот байт). 000xxx-1повтор(xxx=disp3). 001-2повтора (в байтовом потокеdisp8). 010...-3повтора. 01101...-4повтора. 01110...-5повторов. 0111100...-6повторов. 0111101...-7повторов.  и т.д. 01111111110...-14повторов. 01111111111...-15повторов. 011001...- от16до255 повторов (в бай- товом потоке - число этих повторов). 011001...- от256до4097повторов (в ба- йтовом потоке: сначала старший байт,потом младший байт числа повторов. Очевидно,что старший байт всегда меньше16,что позво- ляет отличить последовательность от пре- дыдущего случая). 011001- это также конец файла,если байт в байтовом потоке равен нулю. Из этого, в частности,следует,что последний байт упа- кованного блока всегда равен нулю. Выше под многоточием понималось следую- щее указаниеdisp'а(отрицательного): 1-disp8(#ff00-ffff)в байтовом потоке. 011x-disp9(#fd00-feff),гдеx- старший разряд(0соответствует#fd),остальные8 - в байтовом потоке. 010xx-disp10(#f900-fcff),гдеxx- ста- ршие разряды(00соответствует#f9),ос- тальные8- в байтовом потоке. 001xxx-disp11(#f100-#f8ff), где xxx- старшие разряды(000соответствует#f1), остальные8- в байтовом потоке. 000xxxx-disp12(#e200-#f0ff),гдеxxxx- старшие разряды(0001соответствует#e2), остальные8- в байтовом потоке. 0000000-disp16,хранится в байтовом по- токе,сначала старший байт,потом младший. v2.3/Hrip: Файл разбивается на блоки. У каждого блока свой заголовок.Блоки могут быть раз- ной длины. Желательно, однако, чтобы длина блока была кратна#100.Просто упакованный файл длиной более#а000также разбивается на блоки. Последовательно записанные блоки образуют упакованный файл,а последователь- ность упакованных файлов - архив.  Заголовок блока:  -------------------- +0(5)- "Hrst2". +5(1)- байт флагов: bit0=1:блок сохранен без сжатия; bit1=1:блок в файле был последним; bit5=1:файл удален. +6(2)- длина исходного блока. +8(2)- длина упакованного блока (без дли- ны заголовка). +10(1)- длина дополнительной информации:  ----- +11(2)- CRC16 упакованного блока (можно быстро проверить сохранность архива); +13(2)- CRC16 исходного блока; +15(14)- дескриптор файла (как в TR-DOS).  ----- +[+10]+11(берем байт из[+10],прибавляем 11)- упакованный блок. Длина дополнительной информации равна: =0 для просто пакованных файлов; =2 +хотим иметь CRC16 упакованного блока; =4 +еще и знаем CRC16 исходного блока; =18+знаем имя файла. В Hripмаксимальный размер блока -16k без заголовка. Заголовок занимает29байт. В заголовке блока хранится следующая допо- лнительная информация: CRC пакованного,CRC исходного, копия заголовка из каталога. Параметр в заголовке файла, отвечающий за реальную длину блока,должен быть кратен 256.  Заголовок архива:  -------------------- IDARCH DB "HRi" IDALL DB 0;количество файлов в архиве ;(используется вHrip'епри дополнении ;архива, чтобы не было больше255файлов) SMESH DB 0;см.далее LAST DW 0;см.далее CAT DB 0;1- каталог есть в архиве, ;0- каталог отсутствует. Следующая формула показывает, как можно определить конец архива (в байтах от нача- ла архива): END_ARCH=[LAST]*256-(256-[SMESH]) bytes Расположение каталога,если таков прису- тствует,можно определить по формуле:  START_CAT=[LAST]*256 bytes  Формат каталога:  -------------------- Заголовок каталога: IDCAT DB "Hrip" FILES DB 0;файлов в архиве= IDALL SECLEN DB 0;длина каталога в секторах. Далее идет список файлов в архиве, в следующем формате: IDFILE DS 11;имя файла SMSEC DW 0;на сколько секторов от ;начала архива находится файл SMBYTE DB 0;в каком байте в этом секторе LENPACK DB 0;длина упак. файла в секторах LENREAL DB 0;реальная длина файла в сект. Смещение файла относительно начала ар- хива вычисляется по следующей формуле:  SM_FILE=[SMSEC]*256+[SMBYTE] bytes Количество файлов задается в переменной FILES(в заголовке каталога), но этого ма- ло,необходимо,чтобы был0после последнего описателя файла.  Подготовил А. Кодер Hrumer: По-моему,Сергей Муллин мне в свое время писал, что код дехруста позволяет и "сужать" коды - если переполнить регистр, который отвечает за хранение длины кодов. Hужно просто вставить подряд несколько кодов расширения, и получим сужение. Hо я не проверял :) Можно это было бы использовать при резкой смене содержимого - код - графика - текст. Если снова встретилась, например, графика - расширяем код. \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/lc45.W b/Docs/FORMATS/info_guide/lc45.W new file mode 100644 index 0000000..1dae009 --- /dev/null +++ b/Docs/FORMATS/info_guide/lc45.W @@ -0,0 +1 @@ + Laser Compact и итоги  Laser Compact 4.0  Я не интересовался более старыми верси- ями, хотя и застал их появление. Поэтому начну сразу с 4-й.Формат у неё простой (информация лежит целыми байтами),зато код распаковщика очень любопытен. Как и в описанных ранее экранных комп- рессорах,LC рассматривает 6912 экран в виде трёх 8-знакоместных линий, состоящих из столбцов байт, и лежащих далее линейно адресуемых атрибутов. Файл начинается байтом,который содержит старший байт значения разрыва между нача- лом атрибутов и окончанием экрана.  0=full screen  1=нижние 2/3  2=нижняя 1/3  8=верхние 2/3  9=средняя 1/3  16=верхняя 1/3 Байт этот используется в распаковщике сам по себе,а заодно пересчитывается в ад- рес начала экрана и его высоту: ──────────────────────────────────────────  LD A,(HL)  LD LX,A;разрыв  AND 3  RLCA  RLCA  RLCA  OR 64  LD D,A;начало экрана  LD E,0  LD A,(HL)  INC HL  AND #FC  LD C,A  LD A,88  SUB C  LD C,A;конец экрана ────────────────────────────────────────── Распаковщик отличает от предшественни- ков тот факт, что адрес на экране пересчи- тывается из виртуального на каждом байте: из регистровHL(виртуальный адрес откуда) иDE(куда)рассчитывается адресDE'. ──────────────────────────────────────────  LD A,H LD A,D  CP C;конец экрана  CP C  JR NC,──────┐ ┌────JR NC,  XOR L │ │ XOR E  AND #F8 SCF │ AND #F8  XOR L PUSH AF XOR E  EXX ADD A,LX EXX  LD D,A EXX LD D,A  EXX LD D,A EXX  XOR L EXX XOR E  XOR H POP AF XOR D  RLCA LD A,E RLCA  RLCA ┌────JR NC, RLCA  EXX───┘ LD A,L ┌──EXX  LD E,A JR─────┘ LD E,A ────────────────────────────────────────── Напомню,чтоLXдля полного экрана равен 0. Процедура перехода к следующему адресу отсутствует.Это дало возможность,не сильно раздувая распаковщик, реализовать ссылку с копированием байтов задом наперед. Что ещё более интересно,код режима работы основно- го цикла распаковщика всё время хранится во флагах:  Z, NC- повтор одного байтаA  Z, C- копированиеHL--вDE++  NZ, NC- брать байты непосредственно из потока (HL')  NZ, C- копированиеHL++вDE++ Число проходов цикла в любом случае ле- жит вB. После первого байта, который описан вы- ше, в потоке лежит упакованный экран,зако- дированный следующим образом: %11000000- конец экрана; %11xxxxx0,байты (NZ, NC)- просто байты из потока. Число байтов%xxxxx=1..31; %11xxxx01,байт (Z, NC)-%xxxx=2..16 оди- наковых байт; %11000001,длина,байт (NZ,NC)- до256оди- наковых байт(0=256); %11xxxx11 (Z, NC)-%xxxx=1..15нулей; %11000011,длина (Z, NC)-16..256нулей; %0pppphhh,%llllllll (NZ,C)- короткая ссы- лка:-disp=%11111hhhllllllll, puts=%pppp+ +1=2..16; %10ppphhh,%llllllll (Z, C)- короткая ссы- лка к копированием в обратном порядке: -disp=%11111hhhllllllll, puts=%ppp+1; %00000HHH, %ppppppph, %llllllll (NZ, C)- длинная ссылка:-disp=%1111HHHhllllllll, len=%ppppppp+1, %10000HHH,%ppppppph,%llllllll(Z,C)- длин- ная ссылка с копированием в обратном по- рядке, аналогично.  Недостаток формата в большом количестве способов записать одно и то же.Кроме того, хотя0кодируется просто,специальных кодов для#ffне предусмотрено. Идея не доведена до конца...  Laser Compact 5.2  В данной версии исключены коды обращён- ного копирования, но добавлена упаковка ссылок по Хаффману.В связи с этим,в сорев- новании междуLC4.0иLC5.2может выиграть как тот, так и другой.  С появлением Burial Laser Compactфор- матLC5.2стал почти стандартом. "Почти" потому, что так и не было согласовано рас- ширение (уHrumer'а.PLC,уSinn'а.plc), а универсальный просмотрщик BV так и не научился раскрывать этот формат. Как и раньше,LCрассматривает экран в виде3(впрочем, зависит от того,экран это или часть) линий ломаных столбцов плюс ат- рибуты. Преобразование адресов для этого выгля- дит следующим образом (почти полностью со- впадает сLC4.0): ──────────────────────────────────────────  LD A,D  CP HX  JR NC,───────┐  XOR E │  AND #F8 │  XOR E │  LD B,A EXX  XOR E ADD A,E  XOR D EXX  RLCA LD B,A  RLCA LD C,E  LD C,A │  └────┬─────┘  │ ────────────────────────────────────────── Внутри экрана, если представить его ли- нейным по ломаным столбцам (т.е. так, как его проходит распаковщик), опять действует сжатие из семейства LZ.Размер словаря #1700байт, максимальная строка -255/256 байт. (При смещении>768длина строки ко- дируется как на единицу меньшая.) Битовый и байтовый потоки реализованы аналогично форматуHrust2.x,за исключени- ем того,что в одной из ветвей чтения бита:  SLA D  JR NZ,$+6  LD D,(HL)  INC HL  RL D вместоRLиспользуетсяSLI(т.к. начальное значениеDравно 0,а не128). Программа ZX_Emul 0.33не всегда эмулирует этот фра- гмент правильно. Это происходит,по-видимо- му, из-за неправильного выставления флагов после команды SLI D.ЗаменойSLIнаRL(с предварительным занесением 128в регистр D)эту проблему удаётся решить. В приложе- нии вы сможете найти патчи кZX Guide##3,4 в виде секторов, которые нужно записать на указанное место диска. Внутри распаковщика действует не только отрицательное смещение, как это обычно у Hrumer'а,но и отрицательная длина ссылки (циклINC LX:JR NZ).Это связано с тем,что старший байт смещения и длина ссылки изв- лекаются одним и тем же участком кода. Ко- дируются же они по следующей таблице:  (см. циклDLC5,который проходится рас- паковщиком 2 раза подряд, один раз для -puts=LX,второй раз для-dispH=A') ──────────────────────────────────────────  код -disp puts  1 FFxx 2  011 FExx 3  001 FDxx 4  01011 FCxx 5  01001 FBxx 6  00011 FAxx 7  00001 F9xx  байт*  0101011 F8xx 8  0101010 F7xx 9  0101001 F6xx 10  0101000 F5xx 11  0100011 F4xx 12  0100010 F3xx 13  0100001 F2xx 14  0100000 F1xx 15  0001011 F0xx 16  0001010 EFxx 17  0001001 EExx 18  0001000 EDxx 19  0000011 ECxx 20  0000010 EBxx 21  0000001 EAxx 22  0000000 E9xx 23 ────────────────────────────────────────── (*)чтение байта из байтового потока; если он равен нулю,распаковка прерывается,иначе после декрементирования взять его за АНТИ- длину ссылки. Т.е. тот самыйLX,который увеличивается до достижения нуля. После получения-dispHиз байтового по- тока извлекается-dispL.Как уже было от- мечено, приdisp>768увеличиваетсяputs.  С учётом всего сказанного формат читае- тся следующим образом:  Заголовок: +0"LCMP5" +5длина файла,начиная с поля "код размера экрана" +6длина дополнительной области заголовка, которая может начинаться после этого бай- та.(На практике[+6]=0,и доп.область от- сутствует.) Фрагмент распаковщика, учиты- вающий эту деталь формата,несколько избы- точен:LD A,(HL):INC HL:LD E,A...В неко- торых случаях выгодно отрезать как заго- ловок,так и начало самого распаковщика. +7+[+6]код размера экрана. Благодаря ост- роумному решению равен старшему байту расстояния от окончания пиксельной части экрана до атрибутов.6 возможных значений:  0=full screen  1=нижние 2/3  2=нижняя 1/3  8=верхние 2/3  9=средняя 1/3  16=верхняя 1/3 Декодируется так:x&3=0/1/2- номер нача- льной трети;x&#FC=0/8/16- работать до строки24/16/8соответственно. +8+[+6]1-й байт экрана в несжатом виде. +9+[+6]первый байт битового потока и т.д.  Битовый поток: %1- взять байт из байтового потока; %0, -puts, -dispH, %x(признак направления копирования:0- как  обычно,1- в обратном порядке),-dispL(из байтового потока) - ссылка назад с копированием. Коды дляdispиputsприведены в таблице выше. Приdisp=1 ипризнаке направления = 0,очеви─ дно, происходит повторение предыдущего байта...  Несколько слов о самих идеях сжатия...  Поскольку относительный процент атрибу- тов в картинке невелик, создание особого способа сжатия не было для них целесообра- зно. Между тем, если использовать сжатие байтового потока по Хаффману, специфичес- кие атрибутные байты в состоянии испортить всё дерево. Это мысль номер раз.  Установленный факт, что не обязательно пользоваться упаковщикомLCради достиже- ния близких к предельным (хотя кто знает, каковы они?) степеней сжатия. Разложив не- сколько экранов по столбцам и наXORив друг на друга соседние байты, мы обычно получа- ли массив, сжимаемый программойZXRar(в режимеRar) до объёмов менее полученных Laser Compact'ом.Но некоторым экранам XOR оказался противопоказан. Конечно, выигрыш надо было бы считать по сравнению с файла- миLC5.2,упакованными с помощью lazy eva- luation или другого "умного" метода опти- мизации ссылок,но пока такогоLCнет (рав- но как и такогоHrust1.x).Это мысль номер два.  В связи с предыдущим высказывалось пре- дположение, что наXORивание0,1битов сто- лбца слева на6,7биты столбца справа даст более эффективное дерево. Опыты не дали лучшего качества сжатия, возможно, лишь потому, что атрибуты не были отделены. Это мысль номер три и задел для будущих экспе- риментов.  подготовил А. Кодер Hrumer: //Распаковщик картинок LaserCompact5.2. // Си версия: Hrumer & HalfElf. 25.02.2005 typedef unsigned char BYTE; typedef unsigned short WORD; BYTE *lc_d_input; BYTE lc_d_tagbyte; BYTE lc_d_index; // преобразование 000СгСтолбРядЛин в 000СгЛинРядСтолб WORD getrealadr(WORD virtadr, WORD lb, WORD sc) { WORD realadr; if (virtadr < lb) { WORD Lin = (virtadr & 0x0007) << 8; WORD Ryd = (virtadr & 0x0038) << 2; WORD Stolb = (virtadr & 0x07C0) >> 6; WORD Sg = virtadr & 0x1800; realadr = Sg | Lin | Ryd | Stolb; } else { realadr = virtadr + sc; } return realadr; } BYTE lc_d_getbit(void) { BYTE bit[] = {0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01}; if (lc_d_index == 0) lc_d_tagbyte = *lc_d_input++; BYTE tmp = (lc_d_tagbyte & bit[lc_d_index]) == 0 ? 0 : 1; lc_d_index = (lc_d_index + 1) % 8; return tmp; } BYTE getcode(void) { BYTE tmp = 0xFE; for( int i = 0; i < 3; ++i) { if( lc_d_getbit() ) return tmp+1; tmp = (tmp << 1) | lc_d_getbit(); } return ((tmp << 1) | lc_d_getbit()) + 9; } BYTE getlen(void) { BYTE len = getcode(); if (len == 0x100 - 7) { len = *lc_d_input++; --len; } else { if (len > 0x100 - 7) --len; } return len; } int delc52(BYTE* source, BYTE* destination) { lc_d_index = 0; BYTE *lc_d_output = destination; lc_d_input = source + source[7] + 9 ; WORD sc = (lc_d_input[-1]) << 8; WORD to = (sc & 0x0300) << 3; WORD lb = (sc ^ 0x1800) & 0xFC00; lc_d_output[getrealadr(to++, lb, sc)] = *lc_d_input++; while(true) { if (lc_d_getbit()) { lc_d_output[getrealadr(to++, lb, sc)] = *lc_d_input++; } else { BYTE len = getlen(); if (len == 0xFF) break; WORD dist = getcode() << 8; BYTE napr = lc_d_getbit(); dist |= *lc_d_input++; len = -len; dist = -dist; if (dist > 768) ++len; WORD from = to-dist; do { lc_d_output[getrealadr(to++, lb, sc)] = lc_d_output[getrealadr(from, lb, sc)]; from += napr ? -1 : 1; --len; } while (len>0); } } return 0; } \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/megalz b/Docs/FORMATS/info_guide/megalz new file mode 100644 index 0000000..4fa247c --- /dev/null +++ b/Docs/FORMATS/info_guide/megalz @@ -0,0 +1,52 @@ +MegaLZ + +Формат пакованного файла: + +первый байт копируется в выход +второй - идёт в биты + +биты в байте битов - со старшего. +Если нужен бит, а его уже нет (все 8 кончились) - то новый байт выбирается +из потока. Оттуда же выбираются и байты, обозначенные - но только +после выборки всех битов ссылки. + +В формате ссылок: - байт, который выбирается из потока + +1 - копировать в выход. +000abc - копировать 1 старый байт по смещению FFF8+[abc] от текущей позиции в выходе + (abc==000 - смещение FFF8, abc==111 - FFFF) +001 - копировать 2 байта по смещению FF00+ (-1..-256) +0100 - копировать 3 байта по смещению FF00+ +0101abcd - копировать 3 байта по смещению (F[abcd]-1)*256+ (-257..-4352) + +более длинные ссылки удобно представить в виде 3 частей: + +префикс: 011 + +длина ссылки: +1a -> 4+[a] +01ab -> 6+[ab] +001abc -> 10+[abc] +0001abcd -> 18+[abcd] +00001abcde -> 34+[abcde] +000001abcdef -> 66+[abcdef] +0000001abcdefg -> 130+[abcdefg] (тут длина не более 255!) + +смещение: +0 - FF00+ назад (-1..-256) +1abcd - (F[abcd]-1)*256+ (-257..-4352) + + +Метка конца потока: + +011000000001 + + +примеры: + +000111 - повторить последний байт +001 - повторить последний байт дважды (смещение=-1, длина 2) + +011 001101 10000 - ссылка длиной %101+10 = 15 байт со смещением -4352 + +Lord Vader \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/mspack.W b/Docs/FORMATS/info_guide/mspack.W new file mode 100644 index 0000000..1f8f1e1 --- /dev/null +++ b/Docs/FORMATS/info_guide/mspack.W @@ -0,0 +1 @@ + MS Pack 01.96 MS Pack 01.96  По мнениюHrumer'а,автора упаковщиков Hrust,лучшим компрессором текстов на ZX до2000года былMS Pack.Жаль,конечно,что Hrumerникогда не писал статей по вопросам компрессии и не стал отвечать на мои воп- росы лично, а ведь его имя и программы всплывают в этом разделе уже не первый раз. Однако,что же представляет собой фор- мат компрессораMicrospace? Распаковщик, к сожалению,неоптимален по длине. Структура переходов поддаётся опти- мизации, лишнийXOR A,малополезное сохра- нениеHL'...Но скорость декомпрессии при- личная - например,для упаковки ПЗУMS Pack и сегодня почти незаменим. Ведь в нём сло- варь, в отличие от Hrum,составляет всю длину файла. Конечно,это сказалось на ско- рости самого упаковщика. Хэширования для ускорения поиска повторов нет ни вHrum, ни вMS Pack. Имеются битовый и байтовый потоки,бито- вый поток выбирается по 2 байта. Для рабо- ты используется стек (принцип ADD HL,HL: DJNZ:POP HL:LD B,C).  Упакованный блок должен лежать после распаковщика (Hrum-подобный принцип). Бу- дем отсчитывать байты от начала распаков- щика: +#e9- адрес,по которому лежат5байт кон- ца файла. Точнее,адрес+4, т.к.байты копи- руются черезLDDR.Почему5байт не лежат непосредственно без указателя? Тем более что4байта (или даже6,если в конце де- компрессора неJP,аRET)до упакованного блока не используются? Если бы5байт ко- нца файла лежали впритык за депакером, их не пришлось бы и перебрасывать! Так что это решение авторов довольно странно. +#eb-2байтаHLдля перемещения упако- ванного блока (с помощьюLDDR); +#ed-2байтаDE,аналогично; +#ef-2байтаBC,аналогично; +#f1- адрес, куда распаковывать(DE'); +#f3- первые2байта битового потока. Далее согласно битовому потоку: %0- просто байт (из байтового потока); %100-puts=2.Короткая ссылка: disp8 в байтовом потоке(1..256,причём0соотве- тствует1и т.д.!); %101-puts=3; %110-puts=4; %11101-puts=5; %11110-puts=6; %1111100-puts=7; %1111101-puts=8; %1111110-puts=9; %111111100-puts=10; %111111101-puts=11; %111111110-puts=12; %11111111100-puts=13; %11111111101-puts=14; %11111111110-puts=15; %11111111111-puts=16; %11100- взять некийbyteиз байтового по- тока. Если-1,то прервать распаковку. Если-2,то следующие 2байта в байтовом потоке - это puts, иначе puts=byte+17= =17..270.  Потом для всех ссылок,кромеputs=2(для неё выше было написано особо), следующим образом вычисляетсяdisp(учтите, что вMS Packdispнестандартный - он вычитается из адреса-1! Именно поэтому вputs=2уточне- но, что чему соответствует!): %1- аналогичноputs=2; %0000-dispH=1,здесь и далееdispLберё- тся из байтового потока послеdispH; %0001-dispH=2; %00100-dispH=3; %00101-dispH=4; %00110-dispH=5; %00111-dispH=6; %010000-dispH=7; %010001-dispH=8; %010010-dispH=9; %010011-dispH=10; %010100-dispH=11; %010101-dispH=12; %010110-dispH=13; %0101110-dispH=14; %0101111-dispH=15; %0110000-dispH=16; ... %0111110-dispH=30; %0111111-dispHиз байтового потока.  подготовил А. Кодер \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/partitii.W b/Docs/FORMATS/info_guide/partitii.W new file mode 100644 index 0000000..a709262 --- /dev/null +++ b/Docs/FORMATS/info_guide/partitii.W @@ -0,0 +1 @@ + Партиции Расположение разделов  на винчестере ZET-9 12.03.2005 Last edit 22.05.2005  Информация получена опытным путем и ча─ стично из книг по MS-DOS.  Касается стандартных пц-винтов,т.е.вин─ тов,разделы на которых создавались на пц с помощью программfdisk, Partition magicи подобных им.  Лирическое отступление Стандартное создание разделов на пц программойfdisk.  fdisk.exe- это стандартная программа, она есть на загрузочной дискете MS-DOS. После работы этой программы на винте ВСЯ ИНФОРМАЦИЯ БУДЕТ УНИЧТОЖЕНА!  1)Создаём основной раздел (он называет─ ся "первый"). Если он будет единственным, отводим под него весь винт. Если нужны ещё разделы, то отводим под него часть винта - например,20%.  В программеfdiskможно создать только один основной раздел. Поэтому, если нужны ещё разделы, переходим к созданию дополни─ тельных.  2)Создаём дополнительный раздел - под него обычно отводится вся оставшаяся часть винта.  Теперь начинаем создавать ещё разделы - они будут созданы как бы внутри дополните─ льного раздела. В программе fdiskони на─ зываются логическими дисками.  3)Создаём логические диски в любом ко─ личестве (по одному), главное,чтобы их об─ щий объём не превышал объём дополнительно─ го раздела (программа всё равно это не по─ зволит сделать).  В итоге получаем на винте один основной раздел и несколько дополнительных разде─ лов. С помощью программыPartition Magicмо─ жно делать много всякого, при этом в неко─ торых случаях инфа на винте остаётся - это главное отличие её отfdisk.И ещё одно отличие: можно создать несколько основных разделов - максимум 4 (если не создавать дополнительных разделов),или на уже сущес─ твующем винте (на котором есть 1 основной раздел и несколько дополнительных) создать ещё 2 основных раздела (например, за счёт уменьшения длины первого основного разде─ ла) - тогда на винте будет 3 основных и несколько дополнительных разделов. Основные разделы Самый первый сектор на винте - этоMBR (главная загрузочная запись -Master Boot Record). В самом начале сектора может быть ка─ който пц-шный загрузчик длиной#01BEбайт. По смещению#01BEот начала этого (пер─ вого) сектора располагается таблица разде─ лов длиной 64байта. Последние 2 байта в секторе -#55,#AA.Если их нет,значит,этот винт "нестандартный" (для пц), и определи─ ть,какие есть разделы на винте,скорее все─ го, не получится, но можно попробовать.  Таблица разделов Её длина64байта.Всего в ней отводятся записи для четырех разделов.На каждый раз─ дел - по 16 байт. Запись содержит в себе несколько полей с данными. Смещение Длина Название поля от начала поля, таблицы байт  0 1 Признак активности раздела - флаг. ;Принимает значения0(неактивный) или#80 (активный).Активным может быть только один из разделов. BIOS на пц будет производить загрузку кода из этого раздела.  1 3 Начало раздела в формате CHS. ;Эти 3 байта содержат значения для регист─ ров цилиндра,головки и сектора (Cyl, Head, Sec - сокращенно CHS),которые надо заслать на винт для чтения первого сектора этого раздела: -1-й байт - это номер головки (использу─ ется 4 младших бита); -2-й байт: младшие 6 бит - номер сектора; биты 6, 7 - это биты 8, 9 номера цилиндра для регистров цилиндра (они соответствуют битам 0, 1 в регистреCylinder Hi); -3-й байт - это биты 0..7 номера цилинд─ ра для регистров цилиндра (этот байт зано─ сится в регистрCylinder Low). Смещение Длина Название поля от начала поля, таблицы байт  4 1 Системный байт. ;Байт указывает на тип раздела. Значения: 0 - необычный раздел; 1 - первичный раздел DOS(FAT12)(основной) размером 0..15 Мбайт; 4 - первичный раздел DOS(FAT16)(основной) размером 16..32 Мбайт; 5 - расширенный разд.DOS (дополнительный) размером 0..2 Гбайт; 6 - "огромный" разд.DOS(>32Мb) (основной) размером 32 Мбайт..2 Гбайт (FAT16); #0B - основной (FAT32), размер 512 Мбайт..2 Терабайта (это значение использовалось в OS/2); #0C - основной (FAT32), размер 512 Мбайт..2 Терабайта (это значение используется сейчас во всех Windows для больших винтов); #0E - основной (FAT16),размер 32 Мб..2Г; #0F - расширенный (дополнительный),0..2Г; #83 - так обозначается основной раздел при разбивке винта в системе Linux; #85 - так обозначается раздел для свопа при разбивке винта в системе Linux. Смещение Длина Название поля от начала поля, таблицы байт  5 3 Конец раздела в формате CHS. ;Эти 3 байта значения для регистров голов─ ки, сектора и цилиндра указывают на конец раздела: -1-й байт - это номер головки (использу─ ется 4 младших бита); -2-й байт: младшие 6 бит - номер сектора; биты 6, 7 - это биты 8, 9 номера цилиндра для регистров цилиндра (они соответствуют битам 0, 1 в регистреCylinder Hi); -3-й байт - это биты 0..7 номера цилинд─ ра для регистров цилиндра (этот байт зано─ сится в регистрCilinder Low). Смещение Длина Название поля от начала поля, таблицы байт  8 4 Число секторов до начала раздела. ;Число секторов по 512 байт, которое надо пропустить до начала этого раздела.Это по─ ле используется в режиме LBA вместо знач-й из поля "начало раздела в формате CHS". Фактически это номер блока в режиме LBA- адресации (блоки нумеруются от нуля).  12 4 Количество секторов в данном разделе. ;Длина раздела в секторах по 512 байт. Вот такие 16байт в каждой записи для каждого из существующих разделов. Разделы можно определять по системному байту: если он равен0- значит, раздела нет; если он равен5- значит,это дополни─ тельный раздел; другое значение - основной раздел. По координатам начала раздела (CHS или LBA) нужно загрузить сектор - это первый сектор раздела, называется онBoot Record (загрузочная запись) илиBoot Sector(заг─ рузочный сектор). Формат Boot-сектора рас─ смотрен в конце статьи.  Дополнительные разделы Для работы с дополнительными разделами необходимо:  1)В MBR,в таблице разделов найти раздел со значением системного байта, равным5 (или#0C,или#0F) - это байт по смещению 4 от начала записи об этом разделе;  2)Взять информацию о начале раздела из поля "начало раздела" (в формате CHS или LBA). Эта информация для дополнительного раздела указывает не на начало дополните─ льного раздела, а на сектор,который содер─ житSBR (Secondary Boot Record).  При работе в режиме LBA нужно запомнить это значение, оно понадобится нам позже. Назовём егоADRES_LBA;  3)Загрузить сектор SBR.Этот сектор име─ ет структуру почти такую же,как MBR, но не содержит загрузчика, и в таблице разделов (расположенной по смещению#01BEот начала этого сектора) используются только первые две записи (в отличие от MBR, где исполь─ зуются 4 записи) по16байт каждая.  Последние 2 байта сектора SBR равны #55,#AA.Записи содержат поля, аналогичные полям в MBR. При этом первая запись содер─ жит информацию об этом дополнительном раз─ деле, а вторая запись указывает на следую─ щую SBR (при наличии нескольких дополните─ льных разделов).В SBR для последнего допо─ лнительного раздела используется только первая запись;  4)Если это тот дополнительный раздел, который нам нужен, переходим к пункту5. Иначе:  ищем следующий дополнительный раздел; берём из 2-й записи в таблице разделов значение "начало раздела" из соответствую─ щего поля, причём,если режим CHS, то сразу загружаем следующую SBR. В режиме LBA надо сложить это значение со значением ADRES_LBAи присвоить полученный результат переменнойADRES_LBA- и только после это─ го загрузить SBR. Далее переход на началo этого пункта;  5)Берём из 1-й записи в таблице разде─ лов начало этого раздела из соответствую─ щих полей и загружаем Boot-сектор этого раздела.  Внимание! Поле "начало раздела в фор─ мате CHS" (по смещению1от начала записи) указывает на первый сектор этого дополни─ тельного раздела.Просто используем его для загрузки Boot-сектора. Поле "начало раздела в формате LBA" (по смещению8от начала записи) содержит чис─ ло секторов до начала дополнительного раз─ дела, но не от начала винчестера (!), а от значенияADRES_LBA.Поэтому,чтобы получить реальное количество секторов до начала до─ полнительного раздела, складываем эти два значения и потом загружаем Boot-сектор. Теперь, когда загружен Boot-сектор нуж─ ного нам раздела, из него берём всю инфор─ мацию о файловой системе FAT на этом раз─ деле. Структура раздела такая.  -1-й сектор раздела - это Boot-сектор;  -Несколько неиспользуемых секторов (они могут отсутствовать - их кол-во узнаем из двух байт по смещению14от начала в Boot- секторе);  -1-я копия FAT;  -2-я копия FAT;  -Корневой каталог;  -Данные. Примечание: При использовании винчестера с другой файловой системой (не FAT) необходимо в драйвере винчестера запомнить значение ко─ личества секторов до начала раздела (если используется формат CHS, то надо пересчи─ тать начало раздела в CHS в формат LBA), и при обращении к разделу драйвер будет при─ бавлять это значение к номеру сектора, ко─ торый необходимо загрузить/записать. Точно так же делать это при работе с дополните─ льными разделами FAT (см.примечание к сме─ щению#1Cв Boot-секторе).  Формат Boot-сектора  Внимание! Формат этого сектора справед─ лив для файловых систем FAT12 и FAT16. Здесь длина сектора - 512 байт. Boot-сектор - это первый сектор на дис─ кете с файловой системой FAT12 (дискета MS-DOS). На винчестере с файловой системой FAT12 или FAT16 это первый сектор раздела (не путать с первый сектором винчестера, в котором расположена MBR). Содержит следующие данные: Смещение Длина Hазначение 0 3 Команда перехода на код загрузчика. 3 8 Идентификатор системы (имя программы - форматера). ;Обычно"MSWIN4.1". #0B 2 Длина сектора в байтах. ;Обычно512. #0D 1 Количество секторов в кластере. ;Для дискеты=1; ;Для HDD (FAT12)=8; ;Для HDD (FAT16) может быть4,8,16,32,64. #0E 2 Количество зарезервирован─ ных секторов. ;Это число секторов до 1-й копии FAT (на дискете это фактически номер сектора, где FAT; на винчестере - количество секторов от начала раздела).Не может быть равным0. #10 1 Количество FAT. ;Обычно2. #11 2 Максимально возможное количество файлов в корневом каталоге. ;Для дискеты обычно56; ;Для HDD обычно512. #13 2  Общее количество секторов  на диске. ;Для дискеты и для винчестера объёмом до 32 Мбайт; если >32 Мбайт,то это поле соде─ ржит0, 0). #15 1  Код формата (байт-описатель типа диска) ──────────────────────────────────────────  Значение этого байта такое: #F0 - Гибкий диск,2 стороны,18 секторов  на дорожке; #F8 - Жёсткий диск; #F9 - Гибкий диск,2 стороны,15 секторов  на дорожке; #FC - Гибкий диск,1 сторона,9 секторов  на дорожке; #FD - Гибкий диск,2 стороны,9 секторов  на дорожке; #FE - Гибкий диск,1 сторона,8 секторов  на дорожке; #FF - Гибкий диск,2 стороны,8 секторов  на дорожке. ────────────────────────────────────────── #16 2 Число секторов в одной FAT. #18 2 Количество секторов на одной дорожке. ;Для дискеты=9; ;Для HDD - это параметрSec. #1A 2 Количество головок на диске. ;Для HDD - это параметрHead. #1C 4 Количество специальных (скрытых) секторов. ;Очень важный параметр для винчестера - это количество секторов до начала раздела. Внимание! Для основных разделов это реаль─ ное число секторов от начала винчестера до этого раздела. Для дополнительных разделов это число совпадает со значением поля "Ко─ личество секторов до начала раздела", взя─ тым из таблицы разделов в SBR. #20 4 Кол-во секторов на диске. ;Используется,если размер винчестера >32M. #24 1 ID накопителя (номер диска для винчестера в BIOS). ;первый =#80. #25 1  Резерв. #26 1  Сигнатура расширенного  сектора, т.е. только то,  что пишет DOS 4.0 и выше,  содержит здесь#29. #27 4  Порядковый номер тома. ;Серийный номер - пишется при форматирова─ нии диска, содержит индивидуальный номер и дату. #26 11  Имя диска. #36 8 Содержит"FAT12 "или  "FAT16 ".  Дополнение: Было замечено, что винчестеры,поддержи─ вающие режим LBA, при создании на них раз─ делов получают следующий параметр. Начало первого основного раздела ВСЕГДА имеет значение#3F(в поле "количество се─ кторов до начала раздела") ицилиндр 0, головка 1,сектор 1(в поле "начало раздела в формате CHS"). Такое наблюдалось на следующих винтах: DHAA-2270 (258 Mb); IBM-DB0A-2540 (541 Mb); IBM-20 (20 Gb); Maxtor (40 Gb); Western Digital (160 Gb). Как следствие - на некоторых винтах (маленьких - 200-500 метров) нельзя в ре─ жиме CHS использовать поле "начало раздела в формате CHS", так как на самом деле на─ чало раздела не там, но можно использовать поле "количество секторов до начала разде─ ла", но только в том случае,если винт под─ держивает режим LBA (т.е. работать с ним в режиме LBA).  Ещё про Boot-сектор Под Boot-сектором буду понимать все се─ ктора до начала первого основного раздела. На винтах с FAT16 используется только самый первый сектор, остальные сектора до начала раздела свободны. На винтах с FAT32, кроме самого первого сектора, ещё используется сектор 6- там хранится копия самого первого сектора (ко─ пия таблицы разделов),а всекторе 2содер─ жится дополнительная информация от количе─ стве свободного места на диске, о первом свободном кластере на диске. Содержимое 2-го сектора (считая сектора с первого): Смещение Длина Значение 0 4 #41,#61,#52,#52 ;Идентификатор доп.сектора. 4 480 ;Поле зарезервировано (нули). #01E4 4 #61,#41,#72,#72 ;Идентификатор доп.сектора. #01E8 4 ;Свободно кластеров на диске.Если это поле имеет значение#FFFFFFFF- надо вычислять. #01EC 4 ;Номер кластера на диске, с которого начи─ нать поиск свободного кластера. Если это поле имеет значение #FFFFFFFF- значит, надо вычислять. #01F0 12 ;Поле зарезервировано (нули). #01FC 4 #00,#00,#55,#AA ;Идентификатор доп.сектора. Errata IG#8: Оказывается, и на FAT32 все сектора в цилиндре0,кроме самого первого - свобод─ ны, а указанные там сектор2 (считая от единицы) и сектор6(считая от единицы) - это сектора от начала раздела, и они суще─ ствуют внутри каждого раздела. На секторе6хранится копия boot-секто─ ра (т.е. самого первого сектора этого раз─ дела). А в статье указано, что в секторе6 - копия таблицы разделов. Я наконец-то узнал,где хранятся старшие два байта номера кластера вFAT32(там же 4байта): оказывается, в резервной области из десяти байт, по смещению+20,+21от на─ чала элемента каталога. \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/pcd6_2.W b/Docs/FORMATS/info_guide/pcd6_2.W new file mode 100644 index 0000000..d9c3e21 --- /dev/null +++ b/Docs/FORMATS/info_guide/pcd6_2.W @@ -0,0 +1 @@ + PCD v6.2 Powerful Code Decreaser v6.2  Упаковщик в своё время использовался для сжатия RGB картинок(.Y).Возможно, им упакованы многие журналы. Возможно, именно здесь появилось стандартное дерево из16 вариантов,которое впоследствии попало вMS Pack, Hrum, Hrust...Не берусь утверждать ничего... В комплекте с компрессором прилагаются распаковщики в исходниках. Это решает мно- гие проблемы,давая возможность выбрать,как использовать распаковщик. Распаковщики не- достаточно оптимизированы,но наличие исхо- дников позволяет решить и этот вопрос. Имеются битовый и байтовый потоки,бито- вый поток выбирается по 2 байта. Для рабо- ты используется стек (принципDJNZ:POP HL: LD B,C:ADD HL,HL). Упакованный блок начинается с5байт, относящихся к концу файла, потом лежат2 первых байта битового потока. Далее согласно битовому потоку: %1- просто байт (из байтового потока); %000,xxxx-puts=1.Сверхкороткая ссылка с disp=xxxx+1=1..16; %001-puts=2.Короткая ссылка,dispLизв- лекается из байтового потока. Если-1,то выход из распаковщика,иначеdispLна еди- ницу больше прочитанного; %010-puts=3.Здесь и далее следующим об- разом определяетсяdisp:из байтового по- тока считываетсяdispL,аdispHиз бито- вого потока по дереву:  %0-dispH=0,  %1000-dispH=1,  %1010-dispH=2,  %1100-dispH=3,  %1110-dispH=4,  %1011000-dispH=5, и т.д. Коды начинаются с единицы и имеют структуру:2 информационных бита,1бит признака окончания(0=окончание)и т.д.До 8битdispH. Крупный недостаток - совер- шенно не используются коды,начинающиеся с %1001... %01101-puts=4; %01110-puts=5; %0111100-puts=6; %0111101-puts=7; %0111110-puts=8; %011111100-puts=9; %011111101-puts=10; %011111110-puts=11; %01111111100-puts=12; %01111111101-puts=13; %01111111110-puts=14; %01111111111-puts=15; %01100- взять некийbyteиз байтового по- тока. Если0,то считать 2байтаputsиз байтового потока, иначеputs=byte+15.  подготовил А. Кодер \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/rip0.W b/Docs/FORMATS/info_guide/rip0.W new file mode 100644 index 0000000..5d3a22e --- /dev/null +++ b/Docs/FORMATS/info_guide/rip0.W @@ -0,0 +1 @@ + RIP 0.2x и mRIP  Real Information Packer 0.2x  Автор программы -Роман Петров(Йошкар- Ола), тёзка и однофамилец йошкар-олинского композитора Megus'а.Человек-загадка. На- писав единственную программу, он скрылся в неизвестность, и тут же возникли вопросы: откуда такой уровень программирования? ко- гда и как настолько ювелирно настроены па- раметры сжатия? почему условия инкремента длины ссылки с точностью до плюс-минус ба- йта совпали с аналогичными условиями в фо- рматеRar2.x,хотя к моменту появленияRIP этот формат отнюдь не был обнародован?  В любом случае,это один из самых мощных компрессоров на ZX,победить его сейчас мо- жет толькоZXRar,причём, будьZXRarнапи- сан раньшеRIP,ещё неизвестно,кто бы кого победил... На маленьких файлахRIPпринци- пиально выгоднее - из-за меньшего объёма деревьев и длины распаковщика. Существует3распаковщикаRIP:оригина- льныйv0.21размером#121,с параметрами в HL(откуда) иDE(куда);DERIP+++.Hразме- ром#112(в отличие от предыдущего, позво- ляет задать адрес деревьев независимый от адреса распаковщика); иv0.25,пришиваемый к упакованному файлу наподобиеHrum,дово- льно неоптимальный. Гвоздь формата - настоящие произвольные деревья, хранящиеся в файле в упакованном виде, совсем как в архивахZip, Rarи т.д. Процедура построения дерева в сущности ге- ниальна. Приводить её здесь не имеет смыс- ла,она повторена в исходникахDERIP, mRIP, RZXSFXи т.п. Без её невероятной лаконич- ности сама идея использования произвольных деревьев в кодовых компрессорах осталась бы бессмысленной. Считалось бы, что таких деревьев достойны лишь архиваторы. Вместе с тем, пользователю нового комп- рессора пришлось привыкнуть к новой проб- леме: найти #5C0байт(#5C2вDERIP+++.H) памяти под деревья.Это уже не256байт под активную часть распаковщика, как вHrust1. Нет, такой крупный объём надо где-то выде- лять. Например,на экране.Не всегда это до- пустимо. Вероятно, из-за таких проблемRIP не получил большого распространения при сборке электронной прессы. Другая проблема - скорость распаковки. Она значительно ниже,чем у старых компрес- соров, даже ниже, чем у программыUnRar. Этот недостаток нельзя устранить - он свя- зан с принципиальным отсутствием в упако- ванном файле байтового потока. Начинают влиять циклы обработки деревьев, а ускоре- ние их возможно лишь ценой существенного увеличения распаковщика и буфера под де- ревья.  Биты читаются из байта начиная от 0-го, т.е. нестандартно. Формат: +0(2)-UnpLen,распакованная длина; +2(2)-PakLen,упакованная длина, считая со следующей ячейки(+4); +4- начало информации о деревьях.18че- тырёхбитных чисел (тетрад), указывающих количество бит в хаффмановских кодах у дерева,используемого для извлечения рабо- чих деревьев. Для каждого из кодов0...17 хранится длина в битах (0- код не испо- льзуется; чем чаще код,тем он должен быть короче). Из этих тетрад однозначно строится де- рево,по которому будут считаны аналогичные данные о288+32символах рабочих деревьев. Конечно, тех аналогичных данных (они лежат далее) не обязательно288+32байт (в смыс- ле, символов Хаффмана) - они хитро закоди- рованы:0..15- просто код длины, типа тех тетрад;16- конец информации;17- повто- рить ещё2раза предыдущую длину. Дерево из288литералов условно назовём maintree,а дерево из32- простоtree. Деревья строятся из длин по следующим правилам:  1.Если дерево нарисовать так,что корень будет сверху, единицы справа,а нули слева, то левые подветви должны быть не длиннее правых. Нижняя же кромка веток дерева дол- жна плавно опускаться (глубина увеличива- ться) слева направо.  2.Внутри ярусов (совокупностей листьев, имещих одинаковую глубину) действует сор- тировка: меньшие коды символов справа от больших.Т.е.наоборот относительноRar.Это связано с сокращением распаковщика. После того,как вся информация о деревь- ях считана, извлекаются байты конца архива (в обратном порядке) по деревуmaintree, сразу же закидываются в стек.Любой литерал Є256- конец этого процесса, и начинается собственно распаковка. Распаковка происходит циклами,каждый из которых начинается с чтения символа по де- ревуmaintree: 0..255- просто байт.Поместить его в выхо- дной поток; 257..260-puts=1..4.Далее по деревуtree считывается код длиныdisp:  0- использовать старыйdisp;  1..4-disp=1..4  5,7,...,31-dispвида%10..,от3до16  бит.Дочитываются недостающие битыdisp,  начиная со старших;  6,8,...,30-dispвида%11..,от3до15  бит. Аналогично. Отсюда видно, что раз-  мер окна не превышает49151. Эта кодировкаdispполностью соответству- ет форматуRar(см.Inferno#4).Более то- го, почти(256<>257)совпадает следующее: ПриdispЄ256 инкрементируется puts.При dispЄ#2000ещё раз инкрементируетсяputs! Реализуется копирование. 261,263,...,287- коды длин puts (puts= =%10..)от3до16. Дополнительно считы- ваются (соответственно)1..14бит для по- дцепления к%10..Далее считываетсяdisp, как выше; 262,264,...,286- аналогично,ноputs=%11.. От3до15бит. Далееdisp,как выше; 256- окончить распаковку. После распаковки из стека вынимаются байты конца файла (максимальное число мне неизвестно).  mRIP (mrip4.H) Формат отличается от оригинальногоRIP следующими деталями:  1.НетUnpLen, PakLenв начале;  2.Нет байтов конца файла в начале;  3.Нет кода "повторить предыдущийdisp";  4.Нет коррекцииputsприdispЄ#2000;  5.Тетрады длин кодов дерева для постро- ения рабочих деревьев лежат в обратном по- рядке. В результате депакер уместился в бей- сик-блоке,и был создан удобный автосборщик для системных программ. На маленьких прог- раммах он выигрывает уRIP'аодин сектор за счёт размера распаковщика. На длинных теоретически может проиграть. Но на прак- тике до этого не доходит из-за ограничений на размер файла, пакуемогоmRIP.Вот что его ограничивает:  mRIPне перемещает блок перед распаков- кой, поэтому адрес окончания упакованного блока должен быть выше адреса окончания распаковки. А адрес окончания упакованного блока зависит не от вас, а от длины этого упакованного блока плюс меткаOTKUDA.А эта метка (в текущей версии#AA00) в свою очередь зависит от максимального размера блока и метки maintree(в текущей версии #f881), т.к. при распаковке генерируются деревья,которые где-то нужно хранить,а за- чернить экран не получается: не хватает места в секторе бейсика. Ограничения есть не только при распако- вке, но и при упаковке: при упаковке очень большого файла может не хватить памяти. Можете надеяться упаковать память от#6000 до#E000(pg0),но никак не всю память.  Для подключенияmRIPк программе нужно:  1.Определить меткиbegin, end, GO- ра- змеры программы и адрес её запуска;  2.Сформировать имя программы в#5CDD;  3.В начале программы установить стек, раскрасить экран и бордюр, разобраться с константами клавиатуры:REPPERиREPDEL... ЖелательноLD (IY+1),#CCдля безбоязненно- го использования вашей программой памяти #5bxx.СамmRIPвсего этого не делает;  4.В конце главного исходника поместить INCLUDE "mrip*". Рекомендуется писать именно"mrip*",а не"mrip4",поскольку версия mRIP может меняться. Если вы будете,например,распрос- транять свои исходники, у получателя может оказаться другая версия,ему придётся куда- то лезть,что-то исправлять... (Большинство народу терпеть не может всякие телодвиже- ния.) И вам же будет удобнее обновлять ве- рсииmRIPна своих дисках.Зачем обновлять? Иногда очень неприятно рыться,искатьСАМУЮ РАСПОСЛЕДНЮЮ версию по всем дискам, а там сплошь всё старые да древние... Если определена меткаmake,сборка про- изойдёт и без нажатияCaps Shift- можете использовать для распространения сmkace- подобными сборщиками. Для организации отладочного запуска,ко- торый меняет код программы,вписывайте (ес- ли нужно) послеINCLUDEследующее:  ORG $  CALL 8026  JP NC,nenado  <ваши pokes>  JP GO Ограничение на размер - не пересекайте адрес#5c00.  подготовил А. Кодер \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/trf.TXT b/Docs/FORMATS/info_guide/trf.TXT new file mode 100644 index 0000000..180f99d --- /dev/null +++ b/Docs/FORMATS/info_guide/trf.TXT @@ -0,0 +1,5 @@ +чряєёърхь√щ Їрщы фы  DNA OS ш iS-DOS. + +яхЁт√х ЄЁш срщЄр - t,r,f +фрыхх фтр срщЄр - ёЄрЁЄют√щ рфЁхё,фрыхх - ёрь ъюфютющ сыюъ. + diff --git a/Docs/FORMATS/info_guide/v384.W b/Docs/FORMATS/info_guide/v384.W new file mode 100644 index 0000000..ffe1ea8 --- /dev/null +++ b/Docs/FORMATS/info_guide/v384.W @@ -0,0 +1 @@ + 384x304 viewer Данная программа позволяет просматри─ вать цветные картинки,по размерам превыша─ ющие экран (имеется два режима -256x192и 384x304,они переключаются кнопкой"0"). Программа оформлена в виде исходника (т.е. черновой вариант, с которым можете поэкс─ периментировать и вы - он прекрасно про─ комментирован), названия файлов картинки указываются вINCBIN'ахв конце. Картинка должна иметь форматch$,структуру которо─ го я сейчас расскажу. +0"chr$" +4ширина в знакоместах +5высота в знакоместах +6размер знакоместа в байтах:  8=ч/б,  9=цветное,  18=2-экранное цветное. +7все знакоместа, слева направо, сверху вниз. Программа с примером картинки лежит в приложении, в архиве .rar. Исходник конвертора из четырёхimgв один ch$ прилагается.ch$такого размера как раз занимает почти всю свободную 128k память, не занятую режимом384x304. Кроме того, конвертировать обычный эк─ ран вch$умеет новая версия моего экран─ ного конвертораto8c. Alone Coder \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/videos.W b/Docs/FORMATS/info_guide/videos.W new file mode 100644 index 0000000..f0a9449 --- /dev/null +++ b/Docs/FORMATS/info_guide/videos.W @@ -0,0 +1 @@ + Видео для ZX  Об упаковке видео для ZX  Упаковка видео для ZX не нужна при проигрывании видео сIDE устройств, поскольку их объёмы очень велики, а скорость обмена с ними достаточно высокая, чтобы добавить даже звук (для упакован─ ного видео сложно выдавать отсчёты цифрового звука с постоянной скоростью). Но распространять ZX-программы большим тиражом реа─ льно только на дискетах, что даёт свои ограничения: программа должна иметь скромные размеры, исчисляемые от долей дискеты до3 дискет, а видеоролики нужно, соответственно, паковать. Особенно нужно паковать ролики к небольшим программам - наподобие газеты. Ведь нелепо занимать роликом больше половины объёма релиза.  Общая идея упаковки по знакоместам Интуитивно понятно, что хранить в видеоролике надо только изменяющиеся места, но как кодировать, какое место изменилось, а какое нет? Банальный XOR кадра на кадр никакого выигрыша в разархивированном размере не даёт, разве что в архивированном. Соответственно, возникает идея как-то помечать изменившиеся кле─ точки, конечно, размером не в пиксель, а, скажем,8x8пикселей - знакоместами оперировать очень удобно. Идея стара, как мир, она использовалась ещё в екатеринбургскомBomber'еи описана в ка─ ком-то дремучем номереPlutonium'а. Естественно, в настоящем видео экран прямо "дышит", картинка изменяется по всей площади. Поэтому нужно запоминать не все из─ менившиеся знакоместа, а только те, которые изменились сильно. То есть разница между текущим изображением в этом знакоместе и желаемым изображением составляет большеNпикселов или большеN цветовых градаций, считаемых как4·dG+2·dR+dB(гдеdG, dR, dB- ошибки по цветовым составляющим). В принципе, я использовал другую формулу ошибки:2·dG+dR+dB,результат был не хуже. Главный вопрос в этом методе: КАК эффективнее хранить инфор─ мацию о том, какие знакоместа изменились? Иногда изменившиеся знакоместа располагаются группами, иногда врассыпную.  Управляющий поток Для этого создаём управляющий поток или набор спецкодов, вно─ симый в видеопоток. Первое лучше, поскольку (см. также об этом ниже) характеристики потока знакомест и потока,описывающего гео─ метрию картинки (в каком бы то ни было виде) существенно различ─ ны,что влияет на степень будущего сжатия этих потоков (сейчас мы занимаемся кодированием, а сжатием результата займёмся потом). Сообщу сразу лучший найденный в результате экспериментов спо─ соб кодирования:  1.Для ч/б видео: 0..84 - пропустить 0..84 знакомест, новое - нестандартное; 85..169 - пропустить 0..84 знакомест, новое - стандартное; 170..254 - пропустить 0..84 знакомест, новое - 0-е стандартное  (пустое); 255 - конец кадра.  2.Для цветного видео: 0..54,55..109 - атрибут #01..#37,#41..#77. Нестандартное  знакоместо; 110..164,165..219 - атрибут #01..#37,#41..#77. Стандартное  знакоместо; 220..255 - пропуск 1..36 знакомест. О том, что такое стандартное и нестандартное, расскажу ниже, потерпите...  Как получить набор кадров из ролика Хотя почти все видеоролики имеют одинаковые расширения.avi или.mpg,у них внутри могут применяться десятки различных мето─ дов сжатия. Ни один из них не является общепринятым стандартом. Разработчики методов сжатия распространяют свои кодеки (кодер, декодер) в виде драйверов подWindows.Соответственно,юзер часто должен перед просмотром нового фильма слазить в инет и скачать новые версии кодеков. Проигрыватели даже имеют наглость лезть за этим в инет без спроса. Некоторые кодеки, заявленные как новые версии старых, не играют ролики старых версий, поэтому иногда приходится жонглировать этими кодеками, переустанавливая одну версию за другой. Параноидальные капиталисты организовали два "стандарта" коде─ ков. Один вариант декодирует на какой-то больной экранный кон─ текст, с которого невозможно снять скриншот (видать, чтобы не нарушали копирайт авторов фильма).Этими кодеками пользуется ста─ ндартный Windows Media Player.Другой вариант (он, наверно, до─ роже, но у нас структуру сдирания за это денег организовать пока не успели) декодирует в массив (который проигрыватель отображает самостоятельно), что даёт возможность юзеру снять снапшот,а про─ грамме - записать видео по кадрам. Естественно, нам нужен второй вариант. Далее, требуется Virtual Dub.Никакие редакторы видео с кра─ сивым интерфейсом на практике никуда не годятся - в них нет выг─ рузки покадрово и очень ограничено число фильтров.Virtual Dub- небольшая и мощная программа, которая не страдает этими недоста─ тками. Правда, она поглючивает: сохраняет последовательность ка─ дров не в указанную директорию, а в ту,куда последний раз сохра─ няли avi; а вместо bmp может сохранить непонятный формат,связан─ ный с используемым методом сжатия (поэтому перед сохранением по─ следовательности кадров сжатие нужно выключить). Впрочем, возмо─ жно,что по крайней мере первый глюк относится к одной конкретной версии. Перед выгрузкой покадрово (save image sequence) вы должны произвести следующие действия:  1.Удалить ненужные фрагменты фильма;  2.Добавить фильтрnull transform,кадрирующий картинку (обре─ зающий кадр), чтобы в кадр не попали чёрные поля сверху и снизу (такие бывают) или какая-нибудь "фирменная" эмблемка в уголке (такие тоже бывают: о том, что капиталисты - параноики, я уже сказал выше. Между прочим, это умственное расстройство - лейбло─ копирайтомания - по моим наблюдениям, очень заразное и чрезвы─ чайно тяжело лечится).  3.Добавить фильтр, масштабирующий картинку: лучше всего,чтобы ширина стала256пикселей, высота - любая.  4.По вкусу добавить размазывание картинки во времени, таких фильтров там два вида: motion blur(накладывается2соседних кадра) иtemporal smoother(накладывается до4соседних кадров, причём сила эффекта настраивается). Это особенно нужно в том случае, если на картинке "прыгает" яркость (рисованный советский мультфильм или совсем старая плёнка). Учтите, что выгрузка покадрово требует много мегабайт диско─ вого пространства, не жадничайте - тысячи кадров вам,скорее все─ го, ни к чему, достаточно нескольких сотен.  Shiru Otaku предложил, как можно вытащить кадры, не имея Virtual Dub(маленькими процедурками на Си). ────────────────────────────────────────────────────────────────  Ты указываешь номер кадра в фильме, принимающий буфер, вызы─ ваешь декодер - получаешь кадр. Hесколько строк кода. #include  //#pragma comment(lib,"vfw32.lib") //это стандартная либа,можешь  //просто в проект включить, можешь (в msvc) через прагму... AVISTREAMINFO vzx_pstream; PAVISTREAM vzx_avi; PGETFRAME vzx_frame; int vzx_width,vzx_height,vzx_msek,vzx_allframes;//параметры ви-  //део, определяются на открытии файла char* vzx_data;//указатель на память,куда будут пихаться данные  //(не забудь выделить эту память!)  открываем файл: AVIFileInit(); if(AVIStreamOpenFromFile(&vzx_avi,szFile,streamtypeVIDEO,0, OF_READ,NULL)!=0) //не вышло открыть файл AVIStreamInfo(vzx_avi,&vzx_pstream,sizeof(vzx_pstream)); vzx_width=vzx_pstream.rcFrame.right-vzx_pstream.rcFrame.left;  //ширина кадра vzx_height=vzx_pstream.rcFrame.bottom-vzx_pstream.rcFrame.top;  //высота кадра vzx_allframes=AVIStreamLength(vzx_avi); //сколько всего кадров vzx_msek=AVIStreamSampleToTime(vzx_avi,vzx_allframes)/ vzx_allframes; //сколько мсек на кадр (отсюда знаем и fps) vzx_frame=AVIStreamGetFrameOpen(vzx_avi,NULL); if(vzx_frame==NULL) //не вышло открыть кадр из файла (например,  //кодека нету)  читаем кадр: LPBITMAPINFOHEADER lpbi; lpbi=(LPBITMAPINFOHEADER)AVIStreamGetFrame(vzx_frame,  номер кадра); vzx_data=(char*)lpbi+lpbi->biSize+lpbi-> biClrUsed*sizeof(RGBQUAD); //получили указатель на память, где  //лежит декодированный кадр, в виде rgbquad - r,g,b,0  закрываем файл: AVIStreamGetFrameClose(vzx_frame); AVIStreamRelease(vzx_avi); AVIFileExit();  Собственно, и всё. Hичего сложного. Errata IG#8: Была пропущена инструкция: что делать, когдаAVIStreamOpenFromFile(...)!=0.Прог─ рамма должна выглядеть примерно так: bool vzx_avi_open(LPCSTR szFile) { vzx_hdd=DrawDibOpen(); AVIFileInit(); if(AVIStreamOpenFromFile(&vzx_avi,szFile, streamtypeVIDEO,0,OF_READ,NULL)!=0) {  MessageBox (HWND_DESKTOP,  "Failed To Open The AVI Stream",  "Error",MB_OK);  return vzx_ok=false; } ... } ────────────────────────────────────────────────────────────────  Конверсия в ZX экран Поскольку существуют различные виды рисунка видеокадров (съё─ мка, с крупными или мелкими деталями, с хорошим или плохим осве─ щением, контурный мультфильм, рендеренный мультфильм...), сущес─ твуют и разничные критерии качества переноса картинки на ZX. Я сначала конвертировал довольно экзотическим алгоритмом,име─ ющим даже некий параметр подавления очанковки (аналогbright, применяемый на этапе дизеринга). Но позже, после написания кон─ вертора статичных экранов,я взял алгоритм уже из него (ordered/ diamondвариант - потому чтоФлойд-Штейнбергнепригоден для упа─ ковки). Об этом конверторе и его алгоритме я напишу в другой статье. Естественно, пришлось внести некоторые различия. По-видимому,нужно запрещать использовать дополнительные цвета (сумма которых равна белому) в качестве атрибутов в знакоместе (за исключением случаяink=7,paper=0). Художники их практически не применяют, а их постоянное перемаргивание с ч/б (компьютер не сможет понять, что лучше, даже при незначительных изменениях видеокадра) ничего хорошего для упаковки не даст. Аналогично с красно-зелёными и красно-синими знакоместами. Применение в одном знакоместе цветов, отличающиеся только си─ ней составляющей,однозначно нужно запретить,такие тонкости прак─ тически не заметны в видео.  Стандартные знакоместа  4байта на знакоместо - слишком расточительно, если учитывать тот факт, что знакоместа могут часто иметь весьма похожие рисун─ ки. Хотелось бы кодировать хотя бы половину знакомест одним бай─ том. Как? Изначально я нарисовал9равномерно штрихованных знакомест,от чёрного до белого. Это логично. Они действительно часто исполь─ зуются.Но в сумме по ролику они не охватывают даже половины всех знакомест, поэтому необходимо было нарисовать ещё. Первая идея была - автоматизировать этот процесс. В то время я по просьбеSlip'апытался сделать видео для иг─ ры, заставку с военным сюжетом. Нужные фрагменты я достал из фи─ льма"Wild Wild West" ("Дикий Дикий Запад").Slipразрешил испо─ льзовать 256k,и мне хотелось реализовать ролик подлиннее. На тот момент видео ещё не очанковывалось (см. следующую главку), потому что я ещё не придумал способ генерации таблицы перевода 2байтов в1.Соответственно, нестандартные знакоместа занимали аж по8байт. Я включил9стандартных знакомест в поток нестандартных (зап─ ретив в верхней строчке знакоместа использовать несколько редких кодов вроде%10100101,каковое ограничение на глаз незаметно) и огранизовал ещё один 1-байтный код, за которым должен был следо─ вать номер знакоместа в кольцевом списке. Кольцевой список соде─ ржал 256знакомест, изначально был пустой, и пополнялся только нестандартными знакоместами, встреченными в потоке. Если упаков─ щик находил похожее (не обязательно идентичное - разница могла достигать6пикселов) знакоместо в кольцевом списке, он ставил в поток этот хитрый код и номер. Тот ролик имел плохое качество и не пошёл в игру, его128k вариант ещё лежит у меня на дисках в собранном виде. Каковы ошибки этого метода? Почему он при архивации даёт сли─ шком большую длину файла?  1.Стандартными становятся наборы знакомест,вовсе не охватыва─ ющие весь спектр самых распространённых форм знакомест.Они вооб─ ще получаются практически случайными,а полезные знакоместа могут совсем не попасть в список (их могли ненароком заменить при упа─ ковке на какое-нибудь корявое и волосатое знакоместо, отличающе─ еся на6пикселов).  2.Коды стандартных знакомест и номера в кольцевом списке по─ падают в тот же поток, что и байты нестандартных знакомест. А у них совершенно различные математические свойства! Например,номер в кольцевом списке - число равномерно распределённое. А коды стандартных знакомест мало того, что делают изодногораспреде─ ления частот байтов -два распределения (для верхнего байта и для всех остальных), - но ещё и разрушают структуру потока этих самых байтов,из-за чегоLZсжатие может весьма и весьма потерять в силе.  3.В таком видео нельзя зациклить нужные фрагменты - потому что состояние кольцевого списка в первый и во второй проход бу─ дет разное.  4.Сама идея потока байт никуда не годится - например, чётные байты распределены совершенно не так, как нечётные.Vitaminпоз─ же предложил наXORивать соседние байты друг на друга, при этом равномерная штриховка превращается в последовательность одинако─ вых байт.  Очанковка Я решил пойти по более трудному пути: найти256стандартных пар байт (нижний-верхний), чтобы любую пару байт можно было с некоторой не очень большой ошибкой привести к одной из стандарт─ ных. Вообще-то это очень перспективное направление: например, так можно запаковать крупные спрайты в играх,они станут в2раза меньше по объёму и при этом не станут выводиться медленнее. Сделал так:  1.Штрихованную картинку превращаем в чанки2x2(на глаз почти незаметно, если нет тонких линий).  2.Сортируем625возможных комбинаций чанков по частоте встре─ чи на каком-нибудь видео или картинке (результат будет использо─ ваться и для других картинок и роликов).  3.Начиная с самых редких, отсеиваем те комбинации, которые почти совпадают с какой-нибудь другой комбинацией (отличаются однойпиксел·градацией).  4.Из оставшихся отсеиваем те, которые отличаются от какой-ни─ будь другой комбинации двумяпиксел·градациями. В результате сохраняем 2таблицы: одна для кодирования (из 625-вариантных комбинаций пересчитывает в 256-вариантные),вторая для декодирования (из256вариантов пересчитывает в2байта). Обе лежат в приложении. Первая -Code256.dat.Изменениям левых чанков соответствуют бОльшие изменения номера комбинации, то есть нужно использовать множители125, 25, 5и1 для градаций левого, средних и правого чанков соответственно. Вторая -deco256.C.В ней нижние байты лежат через256байт после верхних. Прилагается также исходник интро к журналу (там видео закодировано без сжатия (энтропийного кодирования) поХаф─ фману,так что программа короткая и понятная).  Сжатие по Хаффману Возможно направления экономии: экономия памяти и экомония ме─ ста на диске. Если ролик короткий, то лучше его хранить в памяти в распакованном виде (без сжатияХаффманом),а на диске - вRar. Так убиваются два зайца: ролик занимает меньше места на диске и меньше тормозит при проигрывании. Но если он длинный, то и в па─ мяти надо хранить сжатым поХаффману.А сжатым поLZлучше не хранить - ему для распаковки нужно окно, поэтому выигрыш в сжа─ тии "скомпенсируется" потерей памяти под нужды окна. А у нас вся память, насколько возможно, отведена на хранение видео. Если же ролик сверхдлинный (с подгрузкой), по можно использовать иLZ. Сжатие видеопотока поХаффмануя применил в роликеDimon128 (с ParaDIGMus'03).Этот ролик я подготавливал одновременно с на─ писаниемZXRar,поэтому упаковщик поХаффмануу меня был в исхо─ днике. Поток "стандартных" знакомест в этом ролике не упакован (он и не упакуется), атрибутный тоже (хотя он упаковался бы в2 раза).  ZXRar может, в отличие от своего пцшного прообраза, паковать чистымХаффманом,не отступая при этом от форматаRar.Для этого установите окно LZ-метода равным0 k.При этом видеопоток, нап─ ример, для нашего интро сжимается лучше, чем настоящим методом Rar.Если же использоватьLZ,рекомендуется обрабатывать знако─ места не строками, а столбцами - так сжатие эффективнее! Я так сделал и в конверторе,и в интро,хотя безLZэто не обязательно - только замедляет распаковку.  Снова стандартные знакоместа И вот мне наконец-то стукнула в голову идея, какие знакоместа должны быть стандартными. Цветопереходы! Цветопереходы в16направлениях, между5основными градациями серого, на3-5основных позициях от центра знакоместа - их вовсе не так много! Изначально я нарисовал512знакомест,не считая9старых. Сде─ лал я это наbmp-картинке, разместив знакоместа(4x4)сеткой с промежутком в1пиксел между знакоместами. Понятно,что многие (сразу не предскажешь,какие) из этих рису─ нков используются настолько редко, что хранить их в распаковщике просто невыгодно (1символ в деревеХаффманазанимает4байта,а само знакоместо -4 "очанкованно-задокированных" или8обычных байт, при том что даёт после упаковки выигрыш где-то2байта на каждое вхождение - следовательно, надо не меньше5-7вхождений для какой-нибудь выгоды). Но как выяснить, какие из них лишние? Мысль:знакоместо может не использоваться,а)если такая форма вообще непопулярная;б)если такая форма редка именно в конкрет─ ном видео;в)если все такие рисунки выгоднее передать близкими по форме знакоментами. Некоторые знакоместа, получившиеся сильно (меньше4пиксе─ лов·градаций разницы) похожими на другие знакоместа набора, я сразу пометил красным пятнышком снизу. Пытаемся в упаковщике применить все знакоместа и подсчитываем для каждого из них число вхождений, на экран выводим, какие из них редкие. После этого убираем редкие знакоместа с картинки (целыми группами симметрии, поскольку переходы влево, вправо, вверх и вниз должны быть равновероятны по большому счёту). Точ─ нее, утаскиваем их на перифериюbmp- вдруг потом пригодятся? Далее перезапускаем наш конвертор видео, прогоняем на том же ро─ лике, смотрим длину выходных потоков в упакованномRar'омвиде - выиграли или проиграли?- и статистику знакомест. Убираем редкие, возвращаем удалённые,если ошиблись в предположении об их невыго─ дности,снова перезапускаем конвертор,и так далее. Задача-минимум - получить<=256знакомест, задача-максимум - получить самые вы─ годные256знакомест (или меньше256,если выгодно меньше). Хотелось получить ровно256стандартных знакомест,но не вышло - для выбора наиболее полезных (наименее бесполезных) из кучи выброшенных нужно слишком долго перебирать варианты на разных видеороликах, у меня нет такого количества свободного времени. А выигрыш будет - копеечный, где-то около1-2процентов по самой оптимистической оценке... Аналогичные проценты, если совсем не хватает памяти, проще выиграть за счёт незаметного на глаз сни─ жения качества ролика, для чего и придуманы настройки стратегии конверсии. Сравнив результаты на нескольких видео, я вообще бросил это занятие - поиск эффективнейших стандартных знакомест - поскольку типов картинок бывает огромное количество. На всякий случай я просто добавил (чтобы стандартных знакомест было256) в набор знакоместа для контурной анимации (белые линии на чёрном фоне). Паковать такие ролики нужно (см. ниже про настройки) с парамет─ рами:standard error dots = 9;иstandard error,соответственно, 9·4 = 36.  Стратегия конверсии Ошибки представления, как я уже говорил,удобнее всего считать по формуле:ошибкасинего+ошибкакрасного+ошибказелёного·2.Можно с коэффициентами1, 2, 3соответственно, можно1, 2, 4соответс─ твенно. Стандартное знакоместо выгодно, если:  ошибкастандартного-ошибканестандартногоStErLevel (чуть сниженное качество на быстрых движениях) иначе если стараяошибка>BadErLevel[,задержка>BadDelay(маленькая задержка)] (основная ветка, аналогично простому методу упаковки. Может чуть отставать от ветки со стандартным знакоместом) иначе если стараяошибка>GoodErLevel, задержка>GoodDelay (большая задержка) (стирание небольших дефектов на медленных движениях) иначе если новое - стандартное, (стараяошибка-ошибка)>0, задержка>ClDelay (стирание отдельных пикселов, оставшихся на сплошном фоне - их не снимает никакая другая ветка алгоритма).  Рекомендации по настройке параметров стратегии Нельзя задавать для стандартных знакомест предел ошибки ниже, чем для"good"знакомест. Из-за этого"good"будут просто пере─ хватывать часть знакомест, которые МОГЛИ БЫ быть закодированы стандартными (т. е. более коротко). При конверсии мультика про дядю Фёдора нужно было убрать постоянное изменение цвета стен (ведь это рисованный мультик).Для этого я применил вVirtual Dub фильтр temporal smoother с параметром 9,а в своём конверторе поставил оба предела на уровень20(а для"bad"-50). Задержку для "good" ставил 1,для "bad"-0,а для"pixels"(напомню, "pixels"- это тоже стандартные знакоместа, только без предела ошибки - снимает шальные пиксели, этого фильтра нет вVideo Stu─ dio)-9.Средний объём кадра даже без упаковки составил240 байт (с упаковкой -150). Это при запрете ярко-белого. А с ним (так картинка кажется объёмнее) -285и200байт на кадр соотве─ тственно. Можно учитывать тот факт, что ошибки на периферии менее заме─ тны, чем в центре. Как этим воспользоваться, решайте сами: можно увеличивать задержки(delays)при удалении от центра (расстояние можно грубо посчитать как суммуdx+dy,гдеdxиdy- расстояния от центра по соотв. оси в знакоместах), а можно при удалении от центра повышать лимиты на ошибки. Я экспериментировал в этим на роликах в final cut'е Wolf'2004,но это годится не для всех видеосюжетов.  Как соединить все потоки в один Хранить 3 раздельных потока неудобно: их трудно загнать в странички (приходится начинать с некруглых адресов, т. е. резать файлы побайтно),а при проигрывании страницы постоянно щёлкаются. Если бы они не щёлкались, производительность видеоплейера была бы больше. Сразу отметаем идею об одном потоке, генерируемом ещё на ста─ дии упаковки (с последующим сжатием файлаrar'ом). Потому что это в чистом виде проигрыш - помесь разнородных потоков с разны─ ми свойствами пакуется хуже, чем эти потоки по отдельности. Сле─ довательно, нужно именно чередовать байты (или биты) трёхуже сжатых потоков. Для формирования такой чехарды нужна отдельная программа,удобнее всего в виде исходника. Если чередовать именно биты, то распаковщик будет короче - можно пользоваться одной и той же процедурой выборки битов для всех потоков, заодно хранить текущий сдвинутый байт в одном и том жеA'(см. описание распа─ ковщиков Hrust вIG#5), да и вообще, даже декодерХаффманаза счёт этого использовать один-единственый.  Рекомендации по проигрыванию видео Информация о кадре для среднего цветного видео с медленно движущейся камерой составляет в распакованном виде около500 байт, считая все 4потока: управляющий/атрибутный, чанковый и знакоместный. Это значит, что в хорошо упакованном видео мы на 3.5 MHz сможем играть до20 fps(самая удобная реализация деко─ дирования поХаффманудекодирует до10 k/с). Выбранную скорость воспроизведения нужно поддерживать постоянной в среднем, подсчи─ тывая фреймы (дляIM 1- системная переменнаяFRAMES: 23672/3/4, для IM 2легко можете реализовать аналогичную). Реализуется эта синхронизация путём записи в23672числа0с последующим контро─ лем получившегося там в конце построения кадра числа (назовём это числоM). Если оно(M)меньше заданногоN (N=5для10 fps), то ожидаем до заданного (т.е. до5). Если больше заданного - то кадр не успел построиться за нужное время (может быть,он "ключе─ вой": сменилась вся картинка), и на следующем цикле нужно вместо нуля записать в 23672 числоM-N.Вот такой фрагмент (в конце обработки кадра):  LD A,(23672) <┐  SUB N │  JR C,─────────┘  LD (23672),A  0надо заносить только в начале проигрывателя видео, до цикла обработки кадров. Источником синхронизации может служить и дисковод,если с него постоянно идёт подгрузка (как в ролике"Locomotion"или в демо "Power Up"). Размер упакованного кадра даже теоретически можно подгонять к фиксированному числу секторов - хотя и очень трудно. Если памяти не хватает, первый кадр можно грузить прямо в экран,а потом запускать видео со следующего кадра. Всё-таки пара килобайт на дороге не валяется. Но на диске такое видео займёт столько же места. Мой упаковщик (наDelphi) - это не релиз,а чисто эксперимен─ тальная вещь, после моих объяснений вы сами сможете написать такой же. Но всё-таки помещаю исходники в приложение - лучше меняйте по готовому, зачем тратить время на написание того, что уже написано? А пределов экспериментам нет - я не полностью реализовал даже своих идей упаковки (например, нет даже простейшего скроллинга, который очень требуется на многих роликах), у вас же могут поя─ виться ещё более интересные идеи. Если придумаете что-то удачное - пишите нам... A. Coder \ No newline at end of file diff --git a/Docs/FORMATS/info_guide/xlpz b/Docs/FORMATS/info_guide/xlpz new file mode 100644 index 0000000..3a237a0 --- /dev/null +++ b/Docs/FORMATS/info_guide/xlpz @@ -0,0 +1,114 @@ +─хъюьяЁхёёюЁ ╠хфэюэюуютр, шёяюы№чютрт°шщё , яю-тшфшьюьє, т "╫╕Ё- +эюь ┬юЁюэх", ы■сюя√Єхэ Єхь,ўЄю сшЄют√щ яюЄюъ т хую ЇюЁьрЄх юЄёє- +ЄёЄтєхЄ - эхёьюЄЁ  эр юёэютрээюх эр LZ ёцрЄшх. ╟р ёў╕Є ¤Єюую яю- +ыєўхэ эхъюЄюЁ√щ т√шуЁ√° т ёъюЁюёЄш ш яЁюшуЁ√° т яыюЄэюёЄш. + +┬ ЄхъёЄх ъюььхэЄрЁшш: ц╕ыЄ√х - ртЄюЁёъшх, чхы╕э√х - ьюш. + +;─хъюьяЁхёёюЁ фы  v 3.01 +;HL-юЄъєфр DE-ъєфр +;DLPCB DEFM "v301" + +DELPZ PUSH DE + LD DE,DLPCB + LD BC,4 + LDIR + POP DE +xpD0 LD A,(HL) + SRL A + JR NC,xpD1 + CALL xpSUB ;short copy + RRA ;%AAAlenB1 + RL B ; ^^^nopacked + AND 7 +xpM2 JR NZ,xpNex ;len<=9 + LD A,(HL) ;len>9 + INC HL +xpNex LD C,(HL) ;disp (ё єў╕Єюь B) + INC HL + PUSH HL + LD H,D + LD L,E + SBC HL,BC + LD B,0 + LD C,A +xpM1 INC BC + INC BC ;>=3 + LDIR + POP HL + EX AF,AF' + JR Z,xpD0 + JR NZ,xpDRR ;nocompr 1..7 + +xpD1 RRA + JR C,xpZ1 + RRA + JR C,xpZ2 + JR Z,xpDEND ;%xxxxx000 + INC HL +xpDRR LD B,A ;nocompr 1..31 +xpDL0 LD A,(HL) + INC HL + XOR (HL) + LD (DE),A + INC DE + DJNZ xpDL0 + JR xpD0 + +xpZ2 SRL A ;%xxxxx100 ;repeat + JR C,xpZ2L + LD C,A + XOR A + EX AF,AF' +xpZ22 INC HL + PUSH HL + LD H,D + LD L,E + DEC HL + JR xpM1 + +xpZ2L CALL xpSUB ;%xxxX1100 + RRA ; ^ + RL B ;0/1 + LD C,(HL) + JR xpZ22 + +xpZ1 SRL A ;%xxxxxx10 + JR NC,xpTWO + LD C,A ;%xxxxx110 ;long copy + INC HL + LD A,(HL) + AND #1F + LD B,A + LD A,C + CALL xpSUB + OR A + JR xpM2 + +xpTWO INC A ;фтр срщЄр %xxxxx010 + LD C,A ;=1..32 + INC HL + PUSH HL + LD H,D + LD L,E + SBC HL,BC + LD C,2 + LDIR + POP HL + JR xpD0 + +xpDEND LD HL,DLPCB ;%xxxxx000 + LD C,4 + LDIR + RET + +xpSUB EX AF,AF' ;яюьхёЄшЄ№ 3 ёЄ.сшЄр Єхъє∙хую срщЄр т A' + LD A,(HL) + RLCA + RLCA + RLCA + AND 7 + EX AF,AF' + INC HL + RET + \ No newline at end of file diff --git a/Docs/FORMATS/mod.rar b/Docs/FORMATS/mod.rar new file mode 100644 index 0000000..73ba60c Binary files /dev/null and b/Docs/FORMATS/mod.rar differ diff --git a/Docs/FORMATS/scl.hdr b/Docs/FORMATS/scl.hdr new file mode 100644 index 0000000..f576376 --- /dev/null +++ b/Docs/FORMATS/scl.hdr @@ -0,0 +1,23 @@ + + .SCL файлы + ---------- + +Фоpмат scl пpидyмал Pavel Nedelin (Paul Pavlov) и пока менять его +не собиpается :) (велика коллекция сконвеpченых файлов) + +Стpyктypа следyющая: +- пеpвые 8 байт - SINCLAIR (отсюда и pасшиpение - scl :) +- байт 9 - число блоков +после чего: +- заголовок 1-го файла (14 байт из каталога без track/sec) +[заголовок 2-го файла, ...] +затем: +- кодовый блок 1 +[кодовый блок 2, ...] +и наконец: +- последние 4 байта - контpольная сyмма (аpифметическая) + +В отличие от таповского фоpмата заголовки не пеpемешиваются +с кодовыми блоками - для yдобства посектоpного копиpования +в tr-dos или на trd. + diff --git a/Docs/FORMATS/scr.hdr b/Docs/FORMATS/scr.hdr new file mode 100644 index 0000000..69fbdc6 --- /dev/null +++ b/Docs/FORMATS/scr.hdr @@ -0,0 +1,25 @@ + + .SCR-файлы + ----------- + + .SCR-файлы - это дампы памяти первых 6912 байтов Спектрумовского ОЗУ. + Связь между координатами x и y и адресами в дисплейном файле следующая: + + 16384+INT (x/8)+1792*INT (y/64)-2016*INT (y/8)+256*y + + Я понимаю, что это не лучший способ рассказывать об организации экрана + Спектрума, но если очень напряженно помозговать над этой формулой, то + из нее можно "вытянуть" всю необходимую информацию. Младшие три бита + координаты x определяют какой бит в адресе соответствует данному + пикселу. Такая побитная раскладка отвечает большей части экранной + памяти: 256*192/8=6144 байтов. Остальные 768 байтов хранят информацию о + цветовых атрибутах экрана. Адрес в файле атрибутов, соответствующий + координате x,y может быть найден по формуле: + + 22528+INT (x/8)+32*INT (y/8) + + Младшие три бита в байте атрибутов определяют цвет переднего плана + (цвет включенных пикселов). Биты 3-5 соответствуют цвету фона. Бит 6 - + бит яркости, а бит 7 - признак мигания. Если он включен, то через + каждые 16/50 долей секунды ULA переключает цвета переднего и заднего + плана. diff --git a/Docs/FORMATS/sna b/Docs/FORMATS/sna new file mode 100644 index 0000000..dcf7e42 --- /dev/null +++ b/Docs/FORMATS/sna @@ -0,0 +1,79 @@ +======================================================================= +| Forwarded by Vyacheslav Mednonogov (2:5030/675.30) +| Area : ZX.SPECTRUM.ARCHIVE (ZX.SPECTRUM.ARCHIVE) +| From : Michael Markowsky, 2:5020/378 (10 Oct 96 18:12) +| To : All + Subj : .SNA +========================================================================= +Hello, All! + +Раз уж ут пошел pазгов-файлах, то вот его фоpмат (из интеpнетовского +SPECTRUM.FAQ, в котоpом, сpеди пpочего, описаны фоpматы pазличных снапшотов): + +===================================================================== +2. Mirage Microdrive .SNA format used by Spectrum 1.7 and JPP + Notice, that in Intel CPUs the least significant byte goes first. + When the registers have been loaded, a RETN command is required to + start the program. IFF2 is short for interrupt flip-flop 2, and for + all practical purposes is the interrupt-enabled flag. Set means + enabled. + +ffset Size +------------------------------------------------------------------------------ +0 1 db I +1 8 dw HL',DE',BC',AF' +9 10 dw HL,DE,BC,IY,IX +19 1 db Interrupt (bit 2 contains IFF2, 1=EI/0=DI) +20 1 db R +21 4 dw AF,SP +25 1 db IntMode (0=IM0/1=IM1/2=IM2) +26 1 db BorderColor (0..7, not used by Spectrum 1.7) +27 49152 RAM dump 16384..65535 +------------------------------------------------------------------------------ +Total: 49179 bytes +============================================================================== + +Кстат, желающие могу этот FAQ: + +SPE_FAQ.LZH 249696 [004] comp.sys.sinclair + Sinclair ZX Spectrum FAQ + v.2.7 (February 13 1995) + +А есл у кого-то естьвежий FAQ, то хоpошо бы его сюда закинуть или в +файлэху. + +est wishes! Mi-+- + + Origin: KLUG's BBS _ 0:00-7:30 _ USR Courier V.Evr HST DS (2:5020/378) + +==========ReadMeAgai============================================== + + t Msg, All! + + + + [I---------------ячим приветом, Слава! + Виртуальная Реальная Единица <-------- Hеяркий Жемчуг + mailme: copper_feet@mail.ru icq#me: 81191986 + +--- GNS-2000 v.3.00. * Origin: -= MADE BY COPPER FEET =- (2:5030/675.30) + + + +struct hdrSNA128 { + unsigned char i; + unsigned short althl, altde, altbc, altaf; + unsigned short hl, de, bc, iy, ix; + unsigned char iff1; /* 00 - reset, FF - set */ + unsigned char r; + unsigned short af, sp; + unsigned char im,pFE; + unsigned char page5[PAGE]; // 4000-7FFF + unsigned char page2[PAGE]; // 8000-BFFF + unsigned char active_page[PAGE]; // C000-FFFF + /* 128k extension */ + unsigned short pc; + unsigned char p7FFD; + unsigned char trdos; +// unsigned char pages[PAGE]; // all pages, except already saved + // (m.b. 5 or 6 pages) +}; diff --git a/Docs/FORMATS/tap.hdr b/Docs/FORMATS/tap.hdr new file mode 100644 index 0000000..49d04e5 --- /dev/null +++ b/Docs/FORMATS/tap.hdr @@ -0,0 +1,66 @@ + + .TAP-файлы: + ----------- + + Эти файлы содержат блоки данных, сохраненных как бы на ленту. Все + блоки начинаются с двух байтов, в которых указано сколько байтов за + ними следует (не считая этих двух байтов). Затем идут сами данные, + включающие флаговый байт и байт контрольной суммы. Байт контрольной + суммы получается в результате последовательной операции XOR для всех + байтов, включая флаговый байт. Например, если вы захотите выгрузить + пару байтов из ПЗУ командой: SAVE "ROM" CODE 0,2, то получите в + результате: + + |-----Данные, генерируемые Спектрумом--| |---------| + + 13 00 00 03 52 4f 4d 7x20 02 00 00 00 00 80 f1 04 00 ff f3 af a3 + + ^^^^^...... длина первого блока (19б.=17б.хэдер+флаг+контр.сумма) + ^^... флаговый байт (00 для хэдера, ff для блока данных) + ^^ первый байт хэдера, указывающий на тип данных + + имя файла ..^^^^^^^^^^^^^ + информация в хэдере.......^^^^^^^^^^^^^^^^^ + к.с. хэдера.................................^^ + длина второго блока............................^^^^^ + флаговый байт 2-го блока..............................^^ + первые два байта ПЗУ....................................^^^^^ + контрольная сумма первых двух байтов и флагового байта........^^ + + + Эмулятор всегда считывает байты с начала блока. Если загружается + меньше байтов, чем есть в наличии, то лишние байты пропускаются и + последний загруженный байт рассматривается как контрольная сумма. Если + запрашивается на загрузку больше байтов, чем есть в наличии, то + загружающая процедура прерывается с включением флага, + свидетельствующего об ошибке ввода с ленты. Обработку ошибки + производит вызываемая Z80 процедура. + + Обратите внимание на то, что можно объединять .ТАР-файлы простым + "пристегиванием" их друг к другу, например так: + + COPY /B FILE1.TAP + FILE2.TAP ALL.TAP + + Для полноты картины я включу сюда же и структуру хэдера. Он всегда + состоит из 17 байтов: + + Байт Длина Описание + 0 1 Тип файла (0,1,2 или 3) + 1 10 Имя файла (если меньше 10 символов, вставляются + пробелы ) + 11 2 Длина блока данных + 13 2 Параметр 1 + 15 2 Параметр 2 + + Тип файла 0,1,2,3 соответствует: программе, числовому массиву, + символьному массиву, блоку кодов. Экранные файлы SCREEN$ + рассматриваются как файлы кодов, начинающиеся в 16384 и имеющие длину + 6912 байтов. Если файл является программой, то параметр-1 содержит + номер строки автостарта или число, большее, чем 32768, если номер + строки автостарта не указан. параметр-2 содержит смещение адреса + программных переменных относительно адреса начала программы. Для блока + кодов параметр-1 содержит адрес, из которого этот блок выгружался, а + параметр 2 содержит число 32768. Для файлов данных (массивов) байт, + расположенный в позиции 14 содержит имя переменной. + + diff --git a/Docs/FORMATS/trd.hdr b/Docs/FORMATS/trd.hdr new file mode 100644 index 0000000..04402a4 --- /dev/null +++ b/Docs/FORMATS/trd.hdr @@ -0,0 +1,102 @@ + + .TRD файлы + ---------- + + Элемент каталога. + ───────────────── + Каждому файлу в облаcти каталога cтавитcя в cоответcтвие так + называемый элемент каталога, pавный 16 байтам. Таким обpазом на одной + диcкете, незавиcимо от объема, может быть запиcано до 128 файлов. В + таблице пpиведен фоpмат элемента каталога. Этих данных вполне доcтаточно + для опиcания любого возможного файла. + ╔═════════╤═════╤═════════════════════╗ + ║Cмещение │Длина│ Hазначение ║ + ║от начала│ │ ║ + ╟─────────┼─────┼─────────────────────╢ + ║ #00 │ 8 │ Имя файла ║ + ║ #08 │ 1 │ Тип файла ║ + ║ #09 │ 2 │ Паpаметp START ║ + ║ #0B │ 2 │ Паpаметp LENGTH ║ + ║ #0D │ 1 │ Количеcтво cектоpов ║ + ║ #0E │ 1 │ Hомеp 1го cектоpа ║ + ║ #0F │ 1 │ Hомеp доpожки ║ + ╚═════════╧═════╧═════════════════════╝ + Элементы каталога pаcположены в том поpядке, в каком хpанятcя + файлы. Еcли этот поpядок наpушить, то TR-DOS будет пpавильно cчитывать + инфоpмацию, но в некотоpых cлучаях возможны cбои. Байт cо cмещением #00 + иcпользуетcя ОC для задания cпециальных атpибутов файлу. Для pеально + cущеcтвующего файла этот байт cодеpжит пеpвый cимвол его имени. Пpи + удалении файла в этот файл запиcываетcя 1. Hепоcpедcтвенно за поcледним + файлом должен cтоять нулевой байт. По значению этого файла некотоpые + команды TR-DOS опpеделяют pазмеp каталога (CAT, LIST). Однако команды, + выполняющие загpузку файлов пpоcматpивают вcе элементы каталога, вне + завиcимоcти значения байта #00. + Cлужебный cектоp. + ───────────────── + Cлужебный (девятый cектоp в облаcти каталога) иcпользуетcя cиcтемой + для хpанения инфоpмации о cамой диcкете. В таблице пpиведен его фоpмат: + ╔═══════════════╤═══════╤═══════════════════════════════════════════╗ + ║Cмещение от │ Длина │ Значение ║ + ║начала cектоpа │ │ ║ + ╟───────────────┼───────┼───────────────────────────────────────────║ + ║ #00 │ 1 │ Байт 0 ║ + ║ #01 │ 224 │ Hе иcпользуетcя (заполнено байтом 0) ║ + ║ #E1 │ 1 │ Hомеp пеpвого незанятого cектоpа на диcке ║ + ║ #E2 │ 1 │ Hомеp доpожки пеpвого незанятого cектоpа ║ + ║ #E3 │ 1 │ Тип диcкеты ║ + ║ #E4 │ 1 │ Количеcтво файлов ║ + ║ #E5 │ 2 │ Количеcтво cвободных cектоpов ║ + ║ #E7 │ 1 │ Идентификационный код TR-DOS (#10) ║ + ║ #E8 │ 2 │ Hе иcпользуетcя (заполнено байтом 0) ║ + ║ #EA │ 9 │ Hе иcпользуетcя (заполнено байтом 32) ║ + ║ #F3 │ 1 │ Hе иcпользуетcя (заполнено байтом 0) ║ + ║ #F4 │ 1 │ Количеcтво удаленных файлов ║ + ║ #F5 │ 8 │ Hазвание диcкеты ║ + ║ #FD │ 3 │ Hе иcпользуетcя (заполнено байтом 0) ║ + ╚═══════════════╧═══════╧═══════════════════════════════════════════╝ + Как видно из таблицы, в cлужебном cектоpе cиcтемой иcпользуютcя + лишь неcколько байт, значения оcтальных не важно. Иcключение cоcтавляет + байт cо cмещением #00. Его значение вcегда должно быть нулевым. + Два байта #E1 и #E2 указывают начало cвободной облаcти на диcке. + Пpи cоздании файла их cодеpжимое пеpепиcываетcя в байти #0E и #0F + элемента каталога. Объем cвободной облаcти хpанитcя в двух байтах cо + cмещением #E5. + Байт #E3 cодеpжит тип диcкеты, котоpый завиcит от пpименяемого + диcковода. Пеpед любой опеpацией c диcкетой cиcтема "наcтpаиваетcя", + cчитывая cлужебный cектоp и пpовеpяя значение этого байта. + ╔══════════╤════════════════════════════╗ + ║ Значение │ Тип диcкеты ║ + ╟──────────┼────────────────────────────╢ + ║ #16 │ 80-доpожечная, 2-cтоpонняя ║ + ║ #17 │ 40-доpожечная 2-cтоpонняя ║ + ║ #18 │ 80-доpожечная 1-cтоpонняя ║ + ║ #19 │ 40-доpожечная 1-cтоpонняя ║ + ╚══════════╧════════════════════════════╝ + Два байта в cлужебном cектоpе отведено для хpанения инфоpмации о + количеcтве файлов на диcкете. В байт cо cмещением #E4 запиcано чиcло + pеальных элементов каталога, т.е. дейcтвительно cвязанных c файлами. + Байт #F4 хpанит чиcло удаленных файлов. Узнать чиcло файлов можно вычтя + значение байта #F4 из значения байта #E4. + Пpи cоздании нового файла, значение байта #E4 увеличиваетcя на + еденицу. Когда же пpоиcходит удаление файла, возможны два ваpианта. + Пеpвый, более пpоcтой - еcли удаляетcя поcледний файл на диcке. В этом + cлучае из байта #E4 вычитаетcя еденица, а в пеpвый байт, cвязанного c + файлом элемента каталога, запиcываетcя 0. Пpи этом облаcть, занимаемая + файлом, оcвобождаетcя, и воccтановить такой файл можно только в том + cлучае, еcли на диcкету не было cделано поcледующих запиcей. Еcли же + удаляетcя не поcледний, то еденица будет добавлена в байт cо cмещением + #F4, а в пеpвый байт cвязанного элемента каталога запишетcя 1. + Физичеcкого удаления не пpоизойдет, и файл по пpежнему будет занимать + меcто на диcке. Hе увеличитcя, еcтеcтвенно, и объем cвободной облаcти. + Веpнуть такой файл пpоcто - необходимо воccтановить пеpвый байт элемента + каталога (не забыв уменьшить на 1 байт по cмещению #F4), но cделать + это можно только до выполнения команды MOVE. + Для идентификации диcкеты cлужит байт cо cмещением #E7. Hекотоpые + ОC имеют cходный физичеcкий фоpмат. Что бы отличить "cвои" диcкеты от + "чужих" TR-DOS каждый pаз пpовеpяет этот байт. + Заданное в команде FORMAT имя диcка хpанитьcя в cлужебном cектоpе + cо cмещением #F5. Имя дополняетcя cпpава пpобелами до 8 байтов. + + +Вcегда Ваш, RomanRom2 + diff --git a/Docs/FORMATS/z80.hdr b/Docs/FORMATS/z80.hdr new file mode 100644 index 0000000..03fa349 --- /dev/null +++ b/Docs/FORMATS/z80.hdr @@ -0,0 +1,177 @@ + + .Z80-файлы + ----------- + + Старый формат файлов .Z80 (для версий до 1.45) выглядит так: + + Смещение Длина Описание + + 0 1 Регистр А + 1 1 Регистр F + 2 2 Регистровая пара BC (сначала младший, т.е. С) + 4 2 Регистровая пара HL + 6 2 Программный счетчик (РС) + 8 2 Указатель стека (SP) + 10 1 Регистр прерываний I + 11 1 Регистр регенерации R (Бит 7 - не значащий) + 12 1 Bit 0 : Равен 7-му биту регистра R + Bit 1-3: Цвет бордюра + Bit 4 : 1- впечатан БЕЙСИК SamRam + Bit 5 : 1- блок данных компрессирован + Bit 6-7: Не значащие + 13 2 Регистровая пара DE + 15 2 Регистровая пара BC' + 17 2 Регистровая пара DE' + 19 2 Регистровая пара HL' + 21 1 Регистр А' + 22 1 Регистр F' + 23 2 Регистр IY (Сначала младший) + 25 2 Регистр IX + 27 1 Триггер прерываний, 0=DI, иначе EI + 28 1 Триггер прерываний IFF2 (роли не играет) + 29 1 Bit 0-1: Режим прерываний (0, 1 или 2) + Bit 2 : 1=эмуляция 2-го выпуска Спектрума + Bit 3 : 1=Двойная частота прерываний + Bit 4-5: 1=Высокая видеосинхронизация + 3=Низкая видеосинхронизация + 0,2=Нормальная + Bit 6-7: 0=Курсор/Protek/AGF- джойстик + 1=Кемпстон-джойстик + 2=Sinclair-левый джойстик + 3=Sinclair-правый джойстик + + Ради совместимости если байт 12 равен 255, то он принимается равным 1. + После этого 30-байтного хэдера следуют 48 килобайтов Спектрумовской + памяти. Если бит-5 12-го байта равен 1, то дамп памяти идет в + компрессированном формате. Метод компрессии очень прост. Заменяются все + последовательности идущих подряд пяти одинаковых байтов. Вместо них + производится запись ED ED xx yy. Здесь ED ED - это префикс, xx - + коэффициент повтора, а yy - повторяющийся байт. Итак, кодируются только + последовательности из пяти повторов или более. Исключением являются + последовательности из байтов, равных ED. Даже если это только два + байта, все равно они пакуются ED ED 02 ED. И последнее правило: любой + байт, непосредственно следующий за ED, не упаковывается в общий блок. + Например, у нас есть последовательность ED 00 00 00 00 00 00. Она не + пакуется, как ED ED ED 06 00, а пакуется как ED 00 ED ED 05 00. Блок + заканчивается концевым маркером 00 ED ED 00. + + Такой формат файлов .Z80 использовался версиями эмулятора до 1.45. + Начиная с версии 2.0 в связи с поддержкой файлов оттисков памяти, + снятых со 128-го Спектрума, появился новый формат. этот новый формат + используется для всех оттисков, неважно 48-ых или 128-ых. Но эмулятор + по-прежнему понимает и старый формат. + + Несмотря на то, что эмулятор понимает старый формат, сам он никогда + файлов .Z80 в старом формате не производит. Но при желании новый формат + можно конвертировать в старый (конечно только для 48К-файлов), если + использовать утилиту ConvZ80. + + Новый формат начинается с такого же 30-байтного хэдера, что и + приведенный выше. Но теперь биты 4 и 5 флагового байта (12-го) уже не + имеют значения, а байты 6 и 7 равны нулю, что говорит о том, что это + файл в новом формате. + + За первыми 30-ю байтами следуют дополнительные: + + Смещение Длина Описание + + * 30 2 Длина дополнительного блока (см. ниже) + * 32 2 Программный счетчик + * 34 1 Аппаратный режим (см. ниже) + * 35 1 В режиме эмуляции SamRam содержит битовое + состояние микросхемы 74ls259. + В режиме 128К содержит последний вывод на + порт 7FFD. + * 36 1 Содержит 0FF, если впечатано ПЗУ Интерфейса-1 + * 37 1 Бит 0: 1 если включена эмуляция регистра R + Bit 1: 1 если включена эмуляция LDIR + * 38 1 Последний вывод на порт 7FFD. + * 39 16 Содержимое регистров музыкального сопроцессора + 55 2 Счетчик тактов (младший) + 57 1 Счетчик тактов (старший) + 58 1 Флаговый байт. Используется Спектатором + (эмулятор Спектрума для компьютеров QL) + При загрузке Z80 его игнорирует, а при выгрузке + выставляет в нем 0. + 59 1 0FF, если впечатано ПЗУ "Гордон" + 60 1 0FF, если впечатано ПЗУ М128. Должно быть 0. + 61 1 0FF, если 0-8191 - ОЗУ + 62 1 0FF, если 8192-16383 - ОЗУ + 63 10 Клавиши, заданные в качестве пользовательского + джойстика. + 73 10 Клавиатурные данные для клавиш, указанных + выше. + 83 1 Тип устройства "Гордон". 0=Disciple + Epson, + 1=Disciple + HP, 16=Plus D + 84 1 Статус кнопки INHIBIT интерфейса Disciple + : 0=интерфейс отключен, за исключением джойстиков + : 0FF=подключен + 85 1 Флаг INHIBIT интерфейса Disciple + : 0=ПЗУ может быть впечатано; + : 0FF=не может быть впечатано. + + + Значение содержимого позиции 30 равно 23-м для версии эмулятора 2.01 + и равно 54-м для версии 3.0. Позиции, помеченные знаком "*", + соответствуют хэдеру версии 2.01 и интерпретируются версией 3.0 точно + так же, за исключением байта 34: + + Число Значение в версии 2.01 Значение в версии 3.0 + + 0 48k 48k + 1 48k + If.1 48k + If.1 + 2 SamRam 48k + M.G.T. + 3 128k SamRam + 4 128k + If.1 128k + 5 - 128k + If.1 + 6 - 128k + M.G.T. + + Старший байт счетчика тактов отсчитывает такты по модулю 4. Сразу + после того, как ULA генерирует свое прерывание (каждые 20 + миллисекунд), он равен трем и увеличивается на единицу через каждые + пять эмулируемых миллисекунд. В эти интервалы, равные 1/200 секунды, + младший байт счетчика считает от 17472 до нуля, что и дает 69888 + тактов на кадр. + + Байт 60 должен быть нулевым, поскольку содержимое ОЗУ устройства + Multiface 128 не сохраняется в файле-оттиске. Если M128 был впечатан в + момент сохранения оттиска, эмулируемая программа скорее всего не будет + работать при последующей загрузке. + + Байты 61 и 62 - функции прочих флагов, таких как байт 34, 59, 60 и 83. + + После хэдера идут блоки памяти, каждый из которых содержит упакованные + данные 16-килобайтного блока. Компрессия производится по старой схеме, + за исключением конечного маркера, который теперь отсутствует. + Структура блока памяти следующая: + + Байт Длина Описание + + 0 2 Длина данных (без этого трехбайтного хэдера) + 2 1 Страничный номер блока + 3 [0] Упакованные данные + + Нумерация страниц зависит от аппаратного режима: + + Стр. В режиме 48 В режиме 128 В режиме SamRam + + 0 48K ПЗУ ПЗУ (старое) 48K ПЗУ + 1 ПЗУ Интерфейса-1, ПЗУ Disciple или ПЗУ Plus D, + в соответствии с тем, что задано + 2 - ПЗУ (новое) ПЗУ SamRam (BASIC) + 3 - page 0 ПЗУ SamRam (монитор,..) + 4 8000-bfff page 1 Обычные 8000-bfff + 5 c000-ffff page 2 Обычные c000-ffff + 6 - page 3 Теневые 8000-bfff + 7 - page 4 Теневые c000-ffff + 8 4000-7fff page 5 4000-7fff + 9 - page 6 - + 10 - page 7 - + 11 ПЗУ Multiface ПЗУ Multiface + + В режиме 48К выгружаются страницы 4,5 и 8. В режиме SamRam сохраняются + страницы с 4 по 8. В режиме 128К - все страницы с 3 по 10. Концевой + маркер отсутствует. + + + diff --git a/Docs/FORMATS/zxword_driver b/Docs/FORMATS/zxword_driver new file mode 100644 index 0000000..c7cd234 --- /dev/null +++ b/Docs/FORMATS/zxword_driver @@ -0,0 +1,48 @@ + Как написать собственный драйвер. + + Если ваша схема подключения принтера отличается от вышеприве- +денной,то во избежании переделок в компьютере, следует создать свой +драйвер. Это небольшая программа в машинных кодах, расположенная с +адреса #5B01 и имеющая длину не более 255 байт. (Это неиспользуе- +мая область буфера ZX-принтера). В начале программы расположите +точки входа,по которым редактор будет обращаться к драйверу: + + + #5B01 - инициализация порта; + #5B03 - передача байта из регистра А в порт принтера; + Процедура инициализации должна настроить программируемый порт +(если таковой имеется), проверить готовность принтера и при необхо- +димости выдать на принтер управляющую последовательность. Эта про- +цедура ничего не возвращает. + Процедура передачи байта на принтер должна ожидать его готов- +ности и передать байт в порт принтера со стробированием. Процедура +должна прерываться нажатием BREAK или при возникновении ошибки. +Если байт по каким-либо причинам не передан в порт принтера, проце- +дура возвращает указатель "С" установленым. + Обе процедуры могут модифицировать любые регистры процессора. +В случае удачного завершения второй процедуры флаг "С" должен сбра- +сываться. Процедура передачи байта в принтер вызывается с запрещен- +ными прерываниями. + В приложении приводится пример составления драйвера для прин- +тера EPSON-LX, подключаемого по вышеприведенной схеме через адаптер +КР580ВВ55, имеющий адреса: + Порт А - #3F; + Порт В - #5F; + Порт С - #7F; + Упр.слово - #FF. + + + При написании драйвера не допускаются: +1.Возможность безвыходного зацикливания; +2.Возможность выхода в бейсик (по RST #08 или через дно стека); +3.Изменение типа прерывания; +4.Разрешение прерываний во время передачи данных через интерфейс; +5.Обращение к DOS; +6.Переназначение каналов и потоков, а также их открытие или закры- + тие; +7.Программные прерывания (RST #NN); +8.Модификация указателя стека или регистровой пары IR; +9. арушение стека; +10.Модификация памяти за пределами буфера ZX-принтера. (Впрочем, + если необходимо, используйте нижние 2/3 экранной области. Это, + разумеется, неэстетично, но безболезненно). diff --git a/Docs/FORMATS/zxzip.hdr b/Docs/FORMATS/zxzip.hdr new file mode 100644 index 0000000..fd99998 --- /dev/null +++ b/Docs/FORMATS/zxzip.hdr @@ -0,0 +1,468 @@ + + .ZXZIP файлы + ------------ + + Стpуктуpа файлового заголовка аpхивов ZxZip + +╔══════╤═══════════════╤════════════════════════════════════════════╗ +║Offset│ Field │ Description ║ +╟──────┼───────────────┼────────────────────────────────────────────╢ +║ +00 │ filename │ ║ +║ +08 │ extension │ ║ +║ +09 │ start address │ Пpосто копия 14 байт тpдосного файлового ║ +║ │ /basic length │ заголовка ║ +║ +0B │ length │ ║ +║ +0D │ sect.length │ ║ +╟──────┼───────────────┼────────────────────────────────────────────╢ +║ +0E │ packed size │ Размеp упакованного файла ║ +╟──────┼───────────────┼────────────────────────────────────────────╢ +║ +10 │ CRC-32 value │ Значение контpольной полиномиальной суммы ║ +╟──────┼───────────────┼────────────────────────────────────────────╢ +║ +14 │ pack method │ Метод упаковки: ║ +║ │ │ 0 - Stored 1 - LZPress ║ +║ │ │ 2 - Shrunk 3 - Implode ║ +╟──────┼───────────────┼────────────────────────────────────────────╢ +║ +15 │ flags │ Разное ;-) ║ +║ │ │ bit0 - binary/text bit1..7 - reserved ║ +╚══════╧═══════════════╧════════════════════════════════════════════╝ + + Исходная длина файла опpеделяется по сл.алгоpитму: +1) Пpедполагаемая длина (для BASIC: w[+09]+4, для остальных: w[+0B]),если ей в +точности соответствует длина в сектоpах, указанная в b[+0D]; +2) Значение b[+0D]*256 если соответствия нет. +Аpхив стpоится из последовательно идущих частей, состоящих из заголовкаи блока +компpессиpованных данных длиной w[+0E]. +// b[+xx] - байт по смещению xx; w[+xx] - слово по смещению xx + +─ NETMAIL (2:5015/97) ─────────────────────────────────────────────── NETMAIL ─ + Msg : 2 of 71 +3 Rcv Pvt + From : Michael Kondratyev 2:5030/299.18 Пят 31 Июл 98 04:45 + To : Roman Khroupnin 2:5015/97 Вcк 02 Авг 98 05:32 + Subj : SN102, ZXZIP inside +─────────────────────────────────────────────────────────────────────────────── +Hi Roman, + + RK> Иcходя из таблицы я понял что это данные конкpетно по *.ZXZ (на PC). + + эти данные конкpетно по внутpенней стpуктуpе. поскольку длина тpдосного файла +небесконечна, заголовков получается несколько, но все одно стоит понимать как +единый файл. + + RK> обpазом пpи пpоcмотpе хобетного ZXZIP аpхива в начале файла можно + RK> обнаpyжить cначала имя оного, а затем ZIP. Лично меня это долго + RK> cбивало c толкy пока я допеp в чем тyт cyть). + + в том и суть. как и в овеpлеях к zxunzip48 можно пpочесть 'ovl'. ненужное поле +используется для дополнительной идентификации. + + RK> Т.е. cитyевина cледyющая: + RK> - в ZXZIP аpхиве нет инфоpмации о количеcтве файлов в аpхиве, нет CRC + RK> вcего аpхива, нет оpигинального кода-деcкpиптоpа как y вcех PC + RK> аpхиватоpов + + нет. абсолютный последовательный поток. так когда-то было удобнее. когда +делалось. в конце концов, зачем обязательно во всем уподобляться дpугим +аpхиватоpам? а на синклеpе тогда, в 1992-93 году (а может и до сих поp) никаких +дpугих аpхиватоpов не было (или я не нашел?). + + RK> - нет инфоpмации о четыpех байтах [+10] (CRC-32 value). Что это з + RK> CRC? + RK> Только заголовка, как в хобетных файлах? Тела файла-аpхива? Того и того? + +только тела файла. исходного. + + RK> И каким обpазом она вычиcляетcя? + + стандаpтно, кpоме одной мелочи. мелочь - не инвеpтиpуется по окончании. +сэкономлена типа паpа байт кода ;) + + RK> - кто задает байт [+14]? ZXZIP пpи yпаковке? Это метод каким был + + все что не пеpвые 14 байт тpдосного заголовка естественно задает zxzip. откуда +им еще взяться-то? + + RK> yпакован файл, т.е. задаетcя yже поcле yпаковки? Или этот метод + RK> задаетcя(бyдет задаватьcя) в командной cтpоке? + + как упакован, так и есть, стpанный вопpос. из методов лишь #3 (и, понятно, #0) +поддеpжан в 86х веpсиях; а в общем-то и pедко на пpактике встpечаются аpхивы с +дpугими (#1 вообще откpовенное гавнецо, атавизм). + + RK> - не понятно назначение байта [+15]. + + в нулевом бите хpанится флаг текстовости файла (в общих чеpтах - это +пpеобладание ascii символов). менять не pекомендуется, поскольку это еще и +используется как паpаметp упаковки. + + RK> - ZXUNZIP может pаcпаковывать только вcе файлы cpазy. + + да. хотя бы потому, что я не пpедставляю, как задавать имена (там могут быть +хоть сто одинаковых, напpимеp). + но можно это обойти, допустим, сделав свой вpеменный аpхив из нужных для +pаспаковки файлов. + + RK> паpаметpы TYPE и START обpазyют ZIP? А где гаpантия того что больше никто + RK> иcпользyет эти паpаметpы? Что никакой там Майкл Джекcон из Авcтpал + +пpезеpватив на свечку надеваешь ;) + + RK> хобетными файлами. C *.ZXZ аpхивами в этом cлyчае облом. Их конечно можно + RK> "пpевpатить" в хобетный файл, а кто знает что это за *.ZXZ файл? Может это + + в пpинципе, они особенно и не нужны - это чисто пpомежуточный тип. с ним было +пpоще pаботать в не-тpдосе. + + RK> я пpикалываюcь, вон COMMAND.COM пеpеименовал... + + опять же, защититься от изобpетательного идиота пpи всем желании не получится. +а между пpочим, я еще ни у кого .zxz не встpечал. + + RK> - поcемy еcть мыcль в качеcтве pешения вопpоcа о подлинноcти ZXZIP + RK> аpхива pешить cледyющим обpазом; (тепеpь по баpабанy, хобетный это файл + RK> или ZXZ) c cамого начала аpхива пpовеpить этy cамyю CRC-32 y пеpвого же + + можно и так. только сначала пpидется этот файл pаспаковать. хотя, может +найдешь застоpенный.. + я в анзипе изначально пpовеpяю по целостности аpхива и по соответствию +packed/unpacked size (пеpвая д.б. меньше для пакованных и pавна для стоpенных) + + RK> - далее, тепеpь на pyках мы имеем два, пpактичеcки pазных аpхиватоpа, + RK> о + RK> из котоpых пакyет только по одномy файлy и только в ZXZ аpхивы. Дpyго + + моpаль пpост: никогда никому не давай сыpых и пpомежуточных веpсий. тот, +котоpый по одному, пpедназначен для его удаления, как абсолютно левый пpодукт. +для меня его уже нет. стандаpт для хpанения тpдосных синклеpных файлов - это +хобета, а значит, pаботать надо только с ней. + + RK> Че делать бyдем? + +пpодолжать дискуссию, веpоятно. + + кстати, еще о стандаpтах хобетных $z - по моему pешению, многотомные должны +быть по pасшиpению $z0..$z9, однотомные - $z + + и еще, пока не забыл, пpо известную ошибку в анзипе. появилась она поскольку я +абсолютно не пpовеpял досовские веpсии и состоит в особенности мсдоса плевать +на наличие pасшиpения если имя девайсовое. типа, com1.$c или prn.$b. то есть +таких он пpосто не pаспакует. + + +Bye, Michael. + +─ NETMAIL (2:5015/97) ─────────────────────────────────────────────── NETMAIL ─ + Msg : 3 of 71 -2 Snt Pvt Loc + From : Roman Khroupnin 2:5015/97 Втp 04 Авг 98 16:23 + To : Michael Kondratyev 2:5030/299.18 Втp 04 Авг 98 16:51 + Subj : SN102, ZXZIP inside +─────────────────────────────────────────────────────────────────────────────── +Хай Michael! + + MK> в том и сyть. как и в овеpлеях к zxunzip48 можно пpочесть 'ovl'. + MK> ненyжное поле использyется для дополнительной идентификации. +Понятно. Тогда давай оcтановимcя на том что ZIP иcпользовать никто не бyдет. + + RK>> - ZXUNZIP может pаcпаковывать только вcе файлы cpазy. + MK> да. хотя бы потомy, что я не пpедставляю, как задавать имена (там + MK> могyт быть хоть сто одинаковых, напpимеp). +Hy и что. Вcе их и pаcпакyй. Hо в большинcтве, я бы cказал абcолютном, +одинаковые файлы вcтpечаютcя кpайне pедко. + + MK> но можно это обойти, допyстим, сделав свой вpеменный аpхив из нyжных + MK> для pаспаковки файлов. +Хмм... не понял. А как его cделать? Именно из _нyжных_ файлов, т.е. я должен +как то yказать эти файлы? Я так пpедcтавлял это cебе - pаcпаковать вcе во +вpеменнyю диpектоpию, а потом в текyщyю пеpепиcать "нyжные". А вpеменнyю +диpектоpию гpохнyть. + + MK> опять же, защититься от изобpетательного идиота пpи всем желании не + MK> полyчится. а междy пpочим, я еще ни y кого .zxz не встpечал. +Что ж, тогда отказываемcя от них как от клаccа :) + + MK> я в анзипе изначально пpовеpяю по целостности аpхива и по + MK> соответствию packed/unpacked size (пеpвая д.б. меньше для пакованных + MK> и pавна для стоpенных) +А как пpовеpить целоcтноcть аpхива? +Вcе таки мне кажетcя пpоще вcего, и yдобней иметь CRC вcего аpхива. +Вот тебе и целоcтноcть и оpигинальный деcкpиптоp. + + MK> тот, котоpый по одномy, пpедназначен для его yдаления, как абсолютно + MK> левый пpодyкт. для меня его yже нет. стандаpт для хpанения тpдосных + MK> синклеpных файлов - это хобета, а значит, pаботать надо только с ней. +Этот абзац надо включить в доки по пакетy ZXZIP, в фак и в доки к навигатоpy :) + + RK>> Че делать бyдем? + MK> пpодолжать дискyссию, веpоятно. + + MK> кстати, еще о стандаpтах хобетных $z - по моемy pешению, многотомные + MK> должны быть по pасшиpению $z0..$z9, однотомные - $z +Тогда такой вопpоc. Еcли файл (yже пакованный) не yбиpаетcя в аpхив (>255), +что делаешь? Разpезаешь и оcтаток в $zn? Или таких pазpывов y тебя нет в +пpинципе? Еcли pазpезаешь то как идентифициpyешь оcтаток (в дpyгом $z) и как +потом cклеиваешь в UNZIP? +И еще. Ты cледyющим томам пpиcваиваешь имя "********". Тепеpь cмотpи cитyевина: +запаковал я что нить в многотомный аpхив. Cкажем тот же ZED. Потом запаковал +еще демy какyю нибyдь тоже в многотомный аpхив. Т.е. понятно да, полyчил дофига +файлов "********". Как мне тепеpь их отличить, для ZED и для демы? + + MK> и еще, пока не забыл, пpо известнyю ошибкy в анзипе. появилась она + MK> посколькy я абсолютно не пpовеpял досовские веpсии и состоит в + MK> особенности мсдоса плевать на наличие pасшиpения если имя девайсовое. + MK> типа, com1.$c или prn.$b. то есть таких он пpосто не pаспакyет. +Пpо то как он не может pаcпаковать файл com1 хоть напишет? +Я в навигатоpе обошел это пyтем добавления к имени таких файлов cвое +cобcтвенное же имя. Т.е. имя - com1, cтанет com1com1 и т.д. + + +RomanRom2@usa.net [Team МАЗДАЙ - РУЛЕЗ] [Team женщин - любить] + +--- GoldED 3.00.Beta1+ + +─ NETMAIL (2:5015/97) ─────────────────────────────────────────────── NETMAIL ─ + Msg : 8 of 71 Rcv Pvt K/s + From : Michael Kondratyev 2:5030/299.18 Вcк 09 Авг 98 20:24 + To : Roman Khroupnin 2:5015/97 + Subj : SN102, ZXZIP inside +─────────────────────────────────────────────────────────────────────────────── + + Hello Roman! + +Tue Aug 04 1998, Roman Khroupnin состряпал(а) письмо к Michael Kondratyev: + + RK>>> - ZXUNZIP может pаcпаковывать только вcе файлы cpазy. + MK>> да. хотя бы потомy, что я не пpедставляю, как задавать имена (там + MK>> могyт быть хоть сто одинаковых, напpимеp). + + RK> Hy и что. Вcе их и pаcпакyй. Hо в большинcтве, я бы cказал абcолютном, + RK> одинаковые файлы вcтpечаютcя кpайне pедко. + + а, все одно тяжелей было бы пользователю объяснить, что надо для +boot B задавать "boot B", а для boot "1" C - "boot \"1\"C", a пpо все +звезды/вопpосы и пpочие вилдкаpты он может забыть. лучше пусть сам выбиpает из +готовых нужные.. + + MK>> но можно это обойти, допyстим, сделав свой вpеменный аpхив из нyжных + MK>> для pаспаковки файлов. + + RK> Хмм... не понял. А как его cделать? Именно из _нyжных_ файлов, т.е. я + RK> должен как то yказать эти файлы? Я так пpедcтавлял это cебе - pаcпаковать + RK> вcе во вpеменнyю диpектоpию, а потом в текyщyю пеpепиcать "нyжные". А + RK> вpеменнyю диpектоpию гpохнyть. + + так пpосто вытаскиваешь из аpхива фpагменты, относящиеся к нужным файлам, +сцепляешь и делаешь из этого тот самый вpеменный аpхивъ. + + MK>> я в анзипе изначально пpовеpяю по целостности аpхива и по + MK>> соответствию packed/unpacked size (пеpвая д.б. меньше для пакованных + MK>> и pавна для стоpенных) + + RK> А как пpовеpить целоcтноcть аpхива? + RK> Вcе таки мне кажетcя пpоще вcего, и yдобней иметь CRC вcего аpхива. + RK> Вот тебе и целоcтноcть и оpигинальный деcкpиптоp. + + а мне значит тогда казалось, что четыpе байта доpоже. все pавно я бы не стал +эту сумму пpовеpять (если pаботал с дискетами, поймешь почему). + + MK>> тот, котоpый по одномy, пpедназначен для его yдаления, как абсолютно + MK>> левый пpодyкт. для меня его yже нет. стандаpт для хpанения тpдосных + MK>> синклеpных файлов - это хобета, а значит, pаботать надо только с ней. + + RK> Этот абзац надо включить в доки по пакетy ZXZIP, в фак и в доки к + RK> навигатоpy :) + + да куда угодно, лишь бы польза с того была. а то вон одних фоpматов дисков уже +наплодили сколько.. + + MK>> кстати, еще о стандаpтах хобетных $z - по моемy pешению, многотомные + MK>> должны быть по pасшиpению $z0..$z9, однотомные - $z + + RK> Тогда такой вопpоc. Еcли файл (yже пакованный) не yбиpаетcя в аpхив + RK> (>255), что делаешь? Разpезаешь и оcтаток в $zn? Или таких pазpывов y тебя + RK> нет в пpинципе? Еcли pазpезаешь то как идентифициpyешь оcтаток (в дpyгом + RK> $z) и как потом cклеиваешь в UNZIP? И еще. Ты cледyющим томам пpиcваиваешь + +в анзипе все пpосто - кончился один - откpываем следующий и дочитываем из него. +смотpи сам, если чего поймешь: + +=========== Вырежь и сохрани =========== +int ZOpen(void) +{ + long l; + unsigned char hbf[17]; + int i; + unsigned short hsum=0; + static char c=0; + + if(hZipFile) {_dos_close(hZipFile); hZipFile=0;} + + if(iZipVol==2) + { + if(c>9) return _ZERR_TOOLONG; + szZipName[strlen(szZipName)-1]=c+'0'; + } + + if(_dos_open(szZipName, O_RDONLY, &hZipFile)) {hZipFile=0; return _ZERR_OPEN;} + + l=filelength(hZipFile)-17; + + if((l-256)&0xffff00ffl) return _ZERR_BADHOB; + + _dos_read(hZipFile, hbf, 17, (unsigned *)&i); + + for(i=15; --i>=0; hsum+=hbf[i]); hsum+=(hsum<<8)+105; + + if((hsum!=(unsigned short)hbf[15]+(((unsigned short)hbf[16])<<8)) || + l!=((unsigned short)hbf[13]+(((unsigned short)hbf[14])<<8))) return +_ZERR_BADHOB; + + uZipLeft=(unsigned short)hbf[11]+(((unsigned short)hbf[12])<<8); + + if((l255) || + c?memcmp(hbf,"********ZIP",11):memcmp(hbf+8,"ZIP",3)) + return _ZERR_NONZIP; + + if(!c) for(i=0;i<8;i++) ArcName[i]=PRINTABLE(hbf[i]); ArcName[8]=0; + + if(iZipVol==2) {c++; if(uZipLeft!=0xff00) iZipVol++;} + + return 0; +} + +int ZRead(unsigned char *bf, unsigned int n) +{ + int i; + unsigned int nx; + + if(!hZipFile && i=ZOpen()) return i; // gotta open first + + if(!usZipLeft) + { + if(iZipVol!=2) return 0; // correct eof + if((i=ZOpen())==_ZERR_OPEN) return 0; // correct eof + else if(i) return i; + } + + for(;;) + { + nx=(uZipLeft>n)?n:uZipLeft; + + _dos_read(hZipFile, bf, nx, (unsigned *)&i); + + bf+=nx; n-=nx; uZipLeft-=nx; + + if(!n) return -1; // read okidoki + + if(iZipVol!=2) return _ZERR_UNEXPEOF; + + if((i=ZOpen())==_ZERR_OPEN) return _ZERR_VOLMISS; + else if(i) return i; + } +} +=========== Вырежь и сохрани =========== + + RK> имя "********". Тепеpь cмотpи cитyевина: запаковал я что нить в + RK> многотомный аpхив. Cкажем тот же ZED. Потом запаковал еще демy какyю + RK> нибyдь тоже в многотомный аpхив. Т.е. понятно да, полyчил дофига файлов + RK> "********". Как мне тепеpь их отличить, для ZED и для демы? + + в тpдосе - по поpядку, сначала идет с именем, за ним со звездами. сохpанять +этот поpядок - дело хозяйское. в хобете - имя хобетное будет естественно у всех +********, зато имя досовское будет у всех pазное. напpимеp, у zed будут +zed.$z0, +zed.$z1, zed.$z2..., а у демы demo.$z0, demo.$z1.. ну pазве тpудно отличить? + + RK> Пpо то как он не может pаcпаковать файл com1 хоть напишет? + + конечно, но не то напишет. пеpебpав все возможные pасшиpения (в смысле .$e?, +?={' ','0'..'9','a'..'z'}) сделает вывод о чpезмеpной популяpности данного +имени +;). + + RK> Я в навигатоpе обошел это пyтем добавления к имени таких файлов cвое + RK> cобcтвенное же имя. Т.е. имя - com1, cтанет com1com1 и т.д. + +можно еще как у pика, добивать до 8 символов подчеpкиваниями. + + + With best wishes, Michael. + +--- + +─ NETMAIL (2:5015/97) ─────────────────────────────────────────────── NETMAIL ─ + Msg : 13 of 71 Rcv Pvt K/s + From : Michael Kondratyev 2:5030/299.18 Пят 14 Авг 98 20:07 + To : Roman Khroupnin 2:5015/97 + Subj : SN102, ZXZIP inside +─────────────────────────────────────────────────────────────────────────────── + + Hello Roman! + +Tue Aug 11 1998, Roman Khroupnin состряпал(а) письмо к Michael Kondratyev: + + MK>> а, все одно тяжелей было бы пользователю объяснить, что надо для + MK>> boot B задавать "boot B", а для boot "1" C - "boot \"1\"C", a + MK>> пpо все звезды/вопpосы и пpочие вилдкаpты он может забыть. лyчше пyсть + MK>> сам выбиpает из готовых нyжные.. + + RK> Hе, не понял. Вот cмотpи, имеем аpхив из cледyющих файлов: + +да не о том я - дабы избежать глюпых вопpосов 'как задать имя?' я pешил что +лучше никак. + + RK> boot B + RK> boot1 B + RK> boot2 B + RK> boot3 B + RK> boot B + RK> Может такая cитyация быть? Вполне. Вот "пользователь" как ты говоpишь, в + RK> MSDOS в навигатоpе отмечает только пеpвый файл и говоpит - pаcпаковать. + +если так (здесь и ниже подpазумется, что я все-таки когда-то вставлю pаботу с +именами) - pаспакуются оба + + RK> Тепеpь фоpмиpyетcя командная cтpока типа zxupzip arc.$z [boot B] + RK> (или + RK> "boot B", как больше нpавитcя). + + пеpвый ваpиант может и смотpится кpасивее, но сишный паpсеp комстpоки я +пеpеписывать из-за такой мелочи точно не хочу. + + RK> Далее zxunzip пpобегает по вcемy аpхивy + RK> и выдеpгивает пеpвый и, cоответcтвенно, поcледний файл. Какие + RK> пpоблемы? В TR-DOS c pаcположением одинаковых файлов нет пpоблем, в + RK> MS-DOS поcледний запишетcя c именем boot_001.$b Ы? + + если в чистый каталог - пеpвый будет boot.$B, втоpой boot.$B0; если уже таких +было - будет последовательно искать свободные. возможно пpидется анализиpовать +stdout от него, чтобы понять, как конкpетно получилось.. + + RK>>> А как пpовеpить целоcтноcть аpхива? + + RK> Так вcе-таки как же? + +только если пpобежать от начала до конца, как pанее и говоpил. или ты пpо +'zxunzip -t'? ;) + + MK>>>> кстати, еще о стандаpтах хобетных $z - по моемy pешению, + MK>>>> многотомные должны быть по pасшиpению $z0..$z9, однотомные - $z + + RK> Кcтати, дальше что? $za..$zz? + + попpобуй, он тебе сам скажетъ. не забывай, что это аpхиватоp для тpдосных +синклеpистов и сколько будет 2544/255 + + RK>>> дофига файлов "********". Как мне тепеpь их отличить, для ZED и + RK>>> для демы? + MK>> в тpдосе - по поpядкy, сначала идет с именем, за ним со звездами. + MK>> сохpанять этот поpядок - дело хозяйское. + + RK> Хоpошо, еcли таки этот поpядок вдpyг не cоблюден, что тогда? Cообщение об + RK> ошибке, мол одного из томов нет? + +а, все что угодно. но ошибка какая-то возникнет навеpняка. + + + With best wishes, Michael. + +--- Полковник на физзарядке, форма одежды номер 2.50.A0611+ + diff --git a/Docs/FORMATS/╨а╨░╤Б╤И╨╕╤А╨╡╨╜╨╕╤П ╤Д╨░╨╣╨╗╨╛╨▓ TR-DOS.html b/Docs/FORMATS/╨а╨░╤Б╤И╨╕╤А╨╡╨╜╨╕╤П ╤Д╨░╨╣╨╗╨╛╨▓ TR-DOS.html new file mode 100644 index 0000000..43ec22e --- /dev/null +++ b/Docs/FORMATS/╨а╨░╤Б╤И╨╕╤А╨╡╨╜╨╕╤П ╤Д╨░╨╣╨╗╨╛╨▓ TR-DOS.html @@ -0,0 +1,2967 @@ + + + + + + + + + +╨рё°шЁхэш  Їрщыют TR-DOS + + + + + + +
+ + +
+╤ЄЁрэшЎр ╚трэр ╨ю∙шэр > +╤ЄрЄ№ш > +
+
+ +

й ╚трэ ╨ю∙шэ, ╠юёътр

+ +
+ + + + +
ZXNet: 500:95/462.53
E-mail: bestview@mtu-net.ru
WWW: http://www.ivr.da.ru
+
+ +

╨рё°шЁхэш  Їрщыют TR-DOS

+ +

(л╨рфшюы■сшЄхы№. ┬р° +ъюья№■ЄхЁ╗ 12/2000, л╨рфшюьшЁ. ┬р° ъюья№■ЄхЁ╗ 9/2001 +(яюф яёхтфюэшьюь BV_Creator). л╨рфшюьшЁ. ┬р° ъюья№■ЄхЁ╗ +2Ч5/2005)
─юяюыэхээр  ш шёяЁртыхээр  тхЁёш . ─рЄр яюёыхфэхую +ЁхфръЄшЁютрэш : 20.06.2005.

+ +

╧ЁхфёЄрт№Єх ёхсх Єръє■ ёшЄєрЎш■: тёЄЁхЄшыё  трь TR-DOS-Їрщы, р +ўЄю т э╕ь эрїюфшЄё  Ч эхяюэ Єэю. ╧юяЁюсютрыш яюёьюЄЁхЄ№ +ёюфхЁцшьюх Ч ш єтшфхыш Єюы№ъю, ўЄю ¤Єю эх ЄхъёЄЕ ╫Єю фхырЄ№ +фры№°х? ╤ЄхЁхЄ№ ¤ЄюЄ Їрщы? ▌Єю, ъюэхўэю, яЁю∙х тёхую, фр ш ьхёЄю эр фшёъх +юётюсюфшЄё . :Ц) ═ю ъЄю чэрхЄ, ўхую т√ яЁш ¤Єюь ыш°шЄхё№? ┬фЁєу Єрь +с√ыю ўЄю-Єю яюыхчэюх шыш їюЄ  с√ шэЄхЁхёэюх?

+ +

├юЁрчфю яЁртшы№эхх эх ёЄшЁрЄ№ эхчэръюь√щ Їрщы ёЁрчє, р яЁшёьюЄЁхЄ№ё  +ёэрўрыр ъ хую Ёрё°шЁхэш■. ╥юуфр, тюёяюы№чютрт°шё№ яЁштхф╕ээющ т ¤Єющ ёЄрЄ№х +ЄрсышЎхщ Ёрё°шЁхэшщ, т√ ёьюцхЄх ёфхырЄ№ т√тюф√ ю Єшях ёюфхЁцр∙хщё  т Їрщых +шэЇюЁьрЎшш ш ю Єюь, ё яюью∙№■ ъръшї яЁюуЁрьь ё эшь ьюцэю ЁрсюЄрЄ№.

+ +

└ ъръ хую єтшфхЄ№, ¤Єю Ёрё°шЁхэшх? л╫Єю чр уыєя√щ +тюяЁюё?╗ Ч яюфєьрхЄх т√. ═ю эх тё╕ Єръ яЁюёЄю, ъръ ьюцхЄ +яюърчрЄ№ё  ё яхЁтюую тчуы фр. :Ц) ─хыю тюЄ т ў╕ь: шчэрўры№эю т +TR-DOS Ёрё°шЁхэшх Їрщыр с√ыю юфэюёшьтюы№э√ь, фр ш ёрьшї +Ёрё°шЁхэшщ с√ыю тёхую ўхЄ√Ёх. ┬ фры№эхщ°хь ¤Єюую яюърчрыюё№ ьрыю, ш +ёюЇЄюяшёрЄхыш Ёх°шыш єтхышўшЄ№ фышэє Ёрё°шЁхэш  фю ЄЁ╕ї ёшьтюыют Ч +ъръ т MS-DOS. ═ю тэюёшЄ№ шчьхэхэш  т ╧╟╙ TR-DOS, +ўЄюс√ юсхёяхўшЄ№ тючьюцэюёЄ№ ъюЁЁхъЄэющ ЁрсюЄ√ ё ЄЁ╕їёшьтюы№э√ьш Ёрё°шЁхэш ьш +ёЁхфёЄтрьш юяхЁрЎшюээющ ёшёЄхь√, эшъЄю эх ёЄры. ╤ юфэющ ёЄюЁюэ√, ¤Єю +яЁртшы№эю Ч тхф№ ы■сюх шчьхэхэшх ╧╟╙ ьюцхЄ яЁштхёЄш ъ +эхЁрсюЄюёяюёюсэюёЄш єцх ёє∙хёЄтє■∙шї яЁюуЁрьь. ═ю ¤Єю цх яЁштюфшЄ ш ъ +юяЁхфхы╕ээ√ь эхєфюсёЄтрь Ч яЁш т√яюыэхэшш ъюьрэф√ лCAT╗ +яюърч√трхЄё  ыш°№ яхЁт√щ ёшьтюы Ёрё°шЁхэш  ърцфюую Їрщыр. ╙тшфхЄ№ Ёрё°шЁхэшх +яюыэюёЄ№■ ьюцэю Єюы№ъю ё яюью∙№■ ёяхЎшры№э√ї +яЁюуЁрьь-юсюыюўхъ Ч эряЁшьхЁ, ьюхщ яЁюуЁрьь√ +BestView.

+ +

═хёъюы№ъю ёыют ю ЄрсышЎх. ╬эр ёЇюЁьшЁютрэр яю ёыхфє■∙хьє +яЁшэЎшяє: хёыш шьххЄё  TR-DOS-яЁюуЁрььр, юсЁрсрЄ√тр■∙р  Їрщы√ ё +фрээ√ь Ёрё°шЁхэшхь, Єю юэю тъы■ўрхЄё  т ЄрсышЎє. ╥ръшь юсЁрчюь, ъЁюьх +шчтхёЄэ√ї ьэх эр ¤ЄюЄ ьюьхэЄ лўшёЄю ёяхъЄЁєьютёъшї╗ Ёрё°шЁхэшщ, +Єрь юърчрышё№ ш Ёрё°шЁхэш  эхъюЄюЁ√ї Єшяют Їрщыют, ъюЄюЁ√х тяхЁт√х яю тшышё№ +эр фЁєушї ъюья№■ЄхЁэ√ї яырЄЇюЁьрї (AMiGA, PC). ╧Ёш ¤Єюь т ЄрсышЎх єърчрэ√ ш +эрчтрэш  TR-DOS-яЁюуЁрьь фы  ЁрсюЄ√ ё Єръшьш Їрщырьш (эряЁшьхЁ, +Їрщы√ ё Ёрё°шЁхэшхь лzip╗ ьюцэю юсЁрсрЄ√трЄ№ ё яюью∙№■ яЁюуЁрьь√ +pkUNZIP 1.41 Fast). ╥ръцх фы  ьэюушї Ёрё°шЁхэшщ т ЄрсышЎх єърчрэю шї +яЁюшёїюцфхэшх, р Єръцх яЁштюфшЄё  шэЇюЁьрЎш  ю ЇюЁьрЄх Їрщыют ё фрээ√ь +Ёрё°шЁхэшхь шыш єърч√трхЄё , уфх х╕ эрщЄш.

+ +

╨рё°шЁхэш  т ЄрсышЎх яхЁхўшёыхэ√ т рыЇртшЄэюь яюЁ фъх. ╤шьтюы +л?╗ т Ёрё°шЁхэшш юсючэрўрхЄ, ўЄю эр хую ьхёЄх ьюцхЄ с√Є№ ы■сющ +ёшьтюы.

+ +

╥рсышЎр ьюцхЄ юърчрЄ№ё  яюыхчэющ ш ртЄюЁрь яЁюуЁрьь т ёыєўрх, ъюуфр +тючэшърхЄ эхюсїюфшьюёЄ№ т√сюЁр Ёрё°шЁхэш  фы  лётюхую╗ ЇюЁьрЄр +Їрщыют. ╫Єюс√ шчсхцрЄ№ яєЄрэшЎ√, Ёрё°шЁхэшх ыєў°х т√сшЁрЄ№ ышсю х∙╕ эх +чрфхщёЄтютрээюх, ышсю эршсюыхх яюфїюф ∙хх яю ёь√ёыє.

+ +

╧Ёштхф╕ээр  т ЄрсышЎх шэЇюЁьрЎш  ёюсЁрэр шч Ёрчышўэ√ї шёЄюўэшъют ш яю +ёюсёЄтхээ√ь эрсы■фхэш ь. ╨рчєьххЄё , юэр эх  ты хЄё  рсёюы■Єэю яюыэющ (ш   эх +ьюує урЁрэЄшЁютрЄ№, ўЄю ъръшх-ышсю єърчрээ√х т ЄрсышЎх Ёрё°шЁхэш  +эх шёяюы№чє■Єё  фы  фЁєушї Ўхыхщ), яю¤Єюьє яЁшё√ырщЄх єЄюўэхэш  ш +фюяюыэхэш  Ч юэш тющфєЄ т яюёыхфэ■■ тхЁёш■ ¤Єющ ёЄрЄ№ш, ъюЄюЁр  +сєфхЄ Ёхуєы Ёэю т√ъырф√трЄ№ё  эр ью■ web-ёЄЁрэшЎє.

+ +

╫рёЄ№ шэЇюЁьрЎшш ьэх яЁхфюёЄртшыш Dmitriy Nesmachny, Eugene Palenock, +Spectre, Vitamin/CAIG/2001, Kirill Frolov. ┴ыруюфрЁ■ шї чр яюью∙№!

+ +
+A   +B   +C   +D   +E   +F   +G   +H   +I   +J   +K   +L   +M   +N   +O   +P   +Q   +R   +S   +T   +U   +V   +W   +X   +Y   +Z +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
╨рё°шЁхэшх╩юььхэЄрЁшщ╧Ёюшёїюцфхэшх Ёрё°шЁхэш ╚эЇюЁьрЎш  ю ЇюЁьрЄх шыш ёё√ыър эр эх╕
#╘рщы яЁ ьюую шыш яюёыхфютрЄхы№эюую фюёЄєяр. ╬фэю шч ўхЄ√Ё╕ї +ёЄрэфрЁЄэ√ї Ёрё°шЁхэшщ TR-DOS. └.╦рЁўхэъю, ═.╨юфшюэют. лZX Spectrum ш TR-DOS +фы  яюы№чютрЄхыхщ ш яЁюуЁрььшёЄют╗. ╤╧с, л╧шЄхЁ╗, +1994.
#?┬ЄюЁр  ўрёЄ№ 255-ёхъЄюЁэюую Їрщыр, ъюЄюЁ√щ с√ы яЁхюсЁрчютрэ +т ЇюЁьрЄ hobeta ё яюью∙№■ яЁюуЁрьь√ Godzilla.┬ЄюЁющ ёшьтюы Ёрё°шЁхэш  Ч ¤Єю Ёрё°шЁхэшх шёїюфэюую Їрщыр (хёыш +юэю фюяєёЄшью т MS-DOS). ┼ёыш є шёїюфэюую Їрщыр с√ыю +ЄЁ╕їёшьтюы№эюх Ёрё°шЁхэшх, Єю ёюїЁрэ хЄё  Єюы№ъю яхЁт√щ хую ёшьтюы.╬ ЇюЁьрЄх hobeta Ч ёь. Ёрё°шЁхэшх л$?╗.
$▌ъЁрэ, єяръютрээ√щ ъюьяЁхёёюЁюь ASC Screen Crasher, схч Ёрёяръют∙шър +(Єръшх Їрщы√ ёючфр╕Є яЁюуЁрььр Quick Screen Viewer 1.0). Alone Coder. лASC, MSP, LAZY╗. ▌ыхъЄЁюээ√щ цєЁэры +Inferno #5. ╤ююЄтхЄёЄтє■∙р  ўрёЄ№ ¤Єющ ёЄрЄ№ш Єръцх фюёЄєяэр +эр ёрщЄх http://zxdocs.fatal.ru, +т Ёрчфхых лFormats╗ (рЁїшт лASC.zip╗).
$?╘рщы т ЇюЁьрЄх hobeta.
╧ЁюуЁрьь√ фы  юсЁрсюЄъш: +Hobeta 1.1, Godzilla 2.0 Pro, File Extractor.		┬ЄюЁющ ёшьтюы Ёрё°шЁхэш  Ч ¤Єю Ёрё°шЁхэшх шёїюфэюую Їрщыр (хёыш +юэю фюяєёЄшью т MS-DOS). ┼ёыш є шёїюфэюую Їрщыр с√ыю +ЄЁ╕їёшьтюы№эюх Ёрё°шЁхэшх, Єю ёюїЁрэ хЄё  Єюы№ъю яхЁт√щ хую ёшьтюы.┬эрўрых Ч 17-срщЄэ√щ чруюыютюъ, +р чр эшь Ч ёюфхЁцшьюх тёхї ёхъЄюЁют шёїюфэюую Їрщыр. +╬ ёЄЁєъЄєЁх чруюыютър ьюцэю єчэрЄ№, эряЁшьхЁ, шч FAQ ъюэЇхЁхэЎшш +ZX.SPECTRUM. ╥рь яЁштюфшЄё  ш яЁюЎхфєЁр эр рёёхьсыхЁх Z80 +фы  т√ўшёыхэш  ъюэЄЁюы№эющ ёєьь√ чруюыютър.
>╠юфєы№ (яырушэ) фы  уЁрЇшўхёъюую ЁхфръЄюЁр Burial Gfx Editor +тхЁёшш 2.x. ╤ь. фюъєьхэЄрЎш■ ъ ЁхфръЄюЁє.
+RGB-¤ъЁрэ, ёючфрээ√щ т яЁюуЁрььх Multistudio.  
0??, 1??, Е╘рщы√-яЁюфюыцхэш  фышээюую Їрщыр. (╥ръ ъръ фышэр Їрщыр +т TR-DOS эх ьюцхЄ яЁхт√°рЄ№ 255 ёхъЄюЁют, сюыхх фышээ√х +Їрщы√ яЁшїюфшЄё  яЁхфёЄрты Є№ т тшфх эхёъюы№ъшї Їрщыют.)╧хЁтр  ЎшЇЁр Ч эюьхЁ Їрщыр-яЁюфюыцхэш  (эрўшэр  +ё 0), р яюёыхфэшх фтр ёшьтюыр Ёрё°шЁхэш  Ч Єръшх цх, +ъръ є шёїюфэюую Їрщыр.╧ЁюёЄю ўрёЄ№ шёїюфэюую Їрщыр, эшъръющ ёыєцхсэющ шэЇюЁьрЎшш +эх фюсрты хЄё .
33-color screen (Їрщы√ ё Єръшь Ёрё°шЁхэшхь ёючфр■Є +яЁюуЁрьь√ JPEG viewer, 8 color editor).╬Є л3-color screen╗.╥Ёш ¤ъЁрээ√ї Їрщыр схч рЄЁшсєЄют, юфшэ чр фЁєушь: ёэрўрыр +ёшэ   ёюёЄрты ■∙р  шчюсЁрцхэш , яюЄюь ъЁрёэр  ш чхы╕эр . ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.
3CS3-color screen.╧хЁт√х ёшьтюы√ юЄ л3╗, лcolor╗, +лscreen╗. 
888╙яръютрээ√щ 3-color screen (ёючфр╕Єё  яЁюуЁрььющ 8 color +editor).┬шфшью, юЄ эрчтрэш  яЁюуЁрьь√.╤ь. ¤ыхъЄЁюээє■ урчхЄє AlcoNews #13.


A

+A   +a   +A??   +add   +alm   +AMP   +ani   +ans   +asc   +asm +
A + + + + + +
1)рЁїшт LZ-Compressor.
+		╬Є лarchive╗ (лрЁїшт╗).╬яшёрэшх ЇюЁьрЄр рЁїштр: +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ц срщЄ√ #7F, #20;
Ц ёЄЁюър лby V.Gamazov╗;
Ц срщЄ√ #01, #00, #08, #22;
Ц 1 срщЄ Ч ъюышўхёЄтю Їрщыют т рЁїштх;
Ц фрыхх шфєЄ юяшёрЄхыш Їрщыют: +
+ + + + + + + + + + + + + + + + + + + + + +
Ц 14 срщЄют Ч фрээ√х ю Їрщых, тч Є√х шч ърЄрыюур +фшёър (шь , Ёрё°шЁхэшх, ёЄрЁЄют√щ рфЁхё, фышэр т срщЄрї, фышэр +т ёхъЄюЁрї);
Ц 2 срщЄр Ч фышэр єяръютрээюую (шыш ёюїЁрэ╕ээюую +схч ёцрЄш ) Їрщыр т срщЄрї, ьырф°шщ срщЄ їЁрэшЄё  яхЁт√ь;
Ц 1 срщЄ Ч ъюэЄЁюы№эр  ёєььр (ёяюёюс яюфёў╕Єр ьэх +эх шчтхёЄхэ);
Ц 1 срщЄ Ч фышэр шёїюфэюую Їрщыр т ёхъЄюЁрї (Є.х. фышэр +эхяюёЁхфёЄтхээю яръєхьющ шэЇюЁьрЎшш; юэр ьюцхЄ эх ёютярфрЄ№ ё фышэющ +т ёхъЄюЁрї, єърчрээющ т ърЄрыюух: Єръ, хёыш фышэр +т ърЄрыюух Ч 0 ёхъЄюЁют, Єю фышэр т ёхъЄюЁрї +т√ўшёы хЄё , шёїюф  шч фышэ√ Їрщыр т срщЄрї);
Ц срщЄ√ #00, #00 (тю тё ъюь ёыєўрх, тю тёхї шчєўхээ√ї ьэющ рЁїштрї +юэш с√ыш эєыхт√ьш; эрчэрўхэшх шї ьэх эх шчтхёЄэю).
+
+
Ц яюёых тёхї юяшёрЄхыхщ Їрщыют эрїюфшЄё  ъюььхэЄрЁшщ ъ рЁїштє +(юЄ 0 фю 37 ёшьтюыют);
Ц срщЄ #00;
Ц фрыхх шфєЄ ёюсёЄтхээю єяръютрээ√х Їрщы√: +
+ + + + + + + + + +
Ц 1 срщЄ Ч яЁшчэръ лЇрщы ёюїЁрэ╕э +схч ёцрЄш ╗ (0 Ч эхЄ, 1 Ч фр);
Ц єяръютрээ√щ (ышсю ёюїЁрэ╕ээ√щ схч ёцрЄш ) Їрщы (хую фышэр єърчрэр +т юяшёрЄхых); ЇюЁьрЄ єяръютрээ√ї фрээ√ї ьэх эх шчтхёЄхэ.
+
+
+
+
+ + + + + +
2)шёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т ЇюЁьрЄх юфэюую +шч рёёхьсыхЁют: TASM 3, TASM 4 (by XLD), TASM 4 +(by RST7), GENS. ╙ЄюўэшЄ№, т ЇюЁьрЄх ъръюую шч рёёхьсыхЁют +яЁхфёЄртыхэ ЄхъёЄ, ьюцэю яю ёЄрЁЄютюьє рфЁхёє Їрщыр: фы  TASM 3 +юэ Ёртхэ 39221, фы  TASM 4 (by XLD) Ч 40872, +р фы  TASM 4 (by RST7) ёЄрЁЄют√щ рфЁхё Ч ¤Єю +эр ёрьюь фхых эюьхЁ ёЄЁюъш ЄхъёЄр, эр ъюЄюЁющ эрїюфшыё  ъєЁёюЁ яхЁхф +ёюїЁрэхэшхь Їрщыр (Єю хёЄ№ чртхфюью ьхэ№°хх ўшёыю, ўхь 39221 +шыш 40872). ─ы  Їрщыют GENS ёЄрЁЄют√щ рфЁхё ьюцхЄ с√Є№ Ёртхэ 0, +Єюуфр, ўЄюс√ эх яхЁхяєЄрЄ№ шї ё Їрщырьш TASM 4 (by RST7), +эрфю яЁютхЁ Є№ ёюфхЁцшьюх Їрщыр.
+		╬Є лassembler╗ (лрёёхьсыхЁ╗).

╬яшёрэшх ЇюЁьрЄр TASM 3.

+

╤ЄЁюър Ч срщЄ ё фышэющ ёЄЁюъш, ёюфхЁцшьюх ёЄЁюъш (тючьюцэю, +яєёЄюх), срщЄ ё фышэющ ёЄЁюъш. ╧юф фышэющ ёЄЁюъш шьххЄё  т тшфє +шьхээю фышэр Єюую ёюфхЁцшьюую ёЄЁюъш, ъюЄюЁюх їЁрэшЄё  т Їрщых, +р эх ъюышўхёЄтю ёшьтюыют т ЄхъёЄютюь яЁхфёЄртыхэшш ёЄЁюъш. +╩юэхЎ ЄхъёЄр Ч фтр срщЄр #FF.

+

┬ ёюфхЁцшьюь ёЄЁюъш ярЁр срщЄют #0A, x ёююЄтхЄёЄтєхЄ +x яЁюсхырь, срщЄ√ #20Ч#7F Ч ъюф√ ёююЄтхЄёЄтє■∙шї +ASCII-ёшьтюыют, срщЄ√ #80Ч#E6 Ч ъюф√ Єюъхэют.

+

╤яшёюъ Єюъхэют (ёшьтюыюь л_╗ фы  єфюсёЄтр юсючэрўхэ +яЁюсхы): A, ADC_, ADD_, AF', AF, AND_, B, BC, BIT_, C, CALL_, CCF, CP_, CPD, +CPDR, CPI, CPIR, CPL, D, DAA, DE, DEC_, DEFB_, DEFM_, DEFS_, DEFW_, DI, +PHASE_, DJNZ_, E, EI, UNPHASE, EQU_, EX_, EXX, H, HALT, HL, I, IM_, IN_, INC_, +IND, INDR, INI, INIR, IX, IY, JP_, JR_, L, LD_, LDD, LDDR, LDI, LDIR, M, NC, +NEG, NOP, NV, NZ, OR_, ORG_, OTDR, OTIR, OUT_, OUTD, OUTI, P, PE, PO, POP_, +PUSH_, R, RES_, RET, RETI, RETN, RL_, RLA, RLC_, RLCA, RLD, RR_, RRA, RRC_, +RRCA, RRD, RST_, SBC_, SCF, SET_, SLA_, SP, SRA_, SRL_, SUB_, V, XOR_, Z, +INCLUDE_, INCBIN_.

+

╬яшёрэшх ЇюЁьрЄр TASM 4 (by XLD).

+

╘юЁьрЄ юЄышўрхЄё  юЄ ЇюЁьрЄр TASM 3 (ёь. т√°х) ыш°№ Єхь, ўЄю +фюсртыхэю 10 эют√ї Єюъхэют, ъюфшЁєхь√ї срщЄрьш #E7Ч#F0: SLI_, INF, LX, +HX, LY, HY, DB_, DM_, DS_, DW_.

+

╬яшёрэшх ЇюЁьрЄр TASM 4 (by RST7).

+

╘юЁьрЄ яюїюц эр ЇюЁьрЄ TASM 3 (ёь. т√°х). ╬Єышўш  ёыхфє■∙шх: +т ёюфхЁцшьюь ёЄЁюъш ярЁр срщЄют 1, x ёююЄтхЄёЄтєхЄ x +яЁюсхырь, р срщЄ√ 2Ч31 юсючэрўр■Є ёююЄтхЄёЄтхээю юЄ 2 +фю 31 яЁюсхыют. ┬ ёяшёъх Єюъхэют тьхёЄю DEFM_ Ч DEFMAC_, +тьхёЄю PHASE_ Ч DISPLAY_, тьхёЄю UNPHASE Ч ENDMAC.

+

╬яшёрэшх ЇюЁьрЄр GENS.

+

╘юЁьрЄ яюїюц эр ЄхъёЄют√щ, Єюы№ъю т яхЁт√ї фтєї срщЄрї ърцфющ +ёЄЁюъш їЁрэшЄё  х╕ эюьхЁ (ьырф°шщ срщЄ їЁрэшЄё  яхЁт√ь). ═юьхЁр +єяюЁ фюўхэ√ яю тючЁрёЄрэш■ ш эх ьюуєЄ с√Є№ сюы№°х 32767. ╩рцфр  +ёЄЁюър чрърэўштрхЄё  срщЄюь 13.

a╚ёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т ЇюЁьрЄх рёёхьсыхЁр +MASM 1.1.╬Є лassembler╗ (лрёёхьсыхЁ╗).

╧єёЄр  ёЄЁюър Ч срщЄ 0. ═хяєёЄр  ёЄЁюър Ч срщЄ +ё фышэющ ёЄЁюъш, ёюфхЁцшьюх ёЄЁюъш, срщЄ ё фышэющ ёЄЁюъш. +╧юф фышэющ ёЄЁюъш шьххЄё  т тшфє шьхээю фышэр Єюую ёюфхЁцшьюую +ёЄЁюъш, ъюЄюЁюх їЁрэшЄё  т Їрщых, р эх ъюышўхёЄтю ёшьтюыют +т ЄхъёЄютюь яЁхфёЄртыхэшш ёЄЁюъш. ╩юэхЎ ЄхъёЄр Ч +срщЄ #FF.

+

┬ ёюфхЁцшьюь ёЄЁюъш ярЁр срщЄют #0A, x ёююЄтхЄёЄтєхЄ +x яЁюсхырь, срщЄ√ #20Ч#7F Ч ъюф√ ёююЄтхЄёЄтє■∙шї +ASCII-ёшьтюыют, срщЄ√ #80Ч#F6 Ч ъюф√ Єюъхэют.

+

┴рщЄ√ #60Ч#7F ьюуєЄ Єръцх шэЄхЁяЁхЄшЁютрЄ№ё  ъръ ъюф√ Ёєёёъшї сєът: ▐, +└, ┴, ╓, ─, ┼, ╘, ├, ╒, ╚, ╔, ╩, ╦, ╠, ═, ╬, ╧, ▀, ╨, ╤, ╥, ╙, ╞, ┬, ▄, █, ╟, +╪, ▌, ┘, ╫, ┌.

+

╤яшёюъ Єюъхэют (ёшьтюыюь л_╗ фы  єфюсёЄтр юсючэрўхэ +яЁюсхы): A, B, C, D, E, H, L, I, R, XH, XL, YH, YL, IX, IY, AF', AF, HL, DE, +BC, M, NC, NV, NZ, P, PE, PO, V, Z, SP, {_, ORG_, PHASE_, UNPHASE, AND_, ADC_, +SBC_, ADD_, SUB_, XOR_, OR_, CP_, LD_, IM_, RST_, EI, DI, EXX, EXA, INF, LDIR, +LDDR, OTIR, OTDR, OUTI, OUTD, RETI, RETN, INIR, INDR, CPIR, CPDR, NEG, CPD, +CPI, IND, INI, LDD, LDI, CCF, CPL, DAA, HALT, NOP, RLA, RLCA, RRA, RRCA, SCF, +RLD, RRD, EX_, RET, CALL_, JP_, PUSH_, POP_, INC_, DEC_, OUT_, IN_, DJNZ_, +JR_, BIT_, RLC_, RRC_, RL_, RR_, SLA_, SRA_, SLI_, SRL_, RES_, SET_, EQU_, +BEGIN_, END, INCBIN_, INCLUDE_, DB_, DEFB_, DEFS_, DEFW_, DS_, DW_, DOWN_, +UP_, SYSTEM, STOPKEY.

A??aЁїшт LZ-Compressor.╤ЄрЁЄют√щ рфЁхё рЁїштр LZ-Compressor ёютярфрхЄ +ёю ёЄрЁЄют√ь рфЁхёюь яюёыхфэхую яюьх∙╕ээюую т ¤ЄюЄ рЁїшт Їрщыр. +┬ Ёхчєы№ЄрЄх є рЁїштр ьюцхЄ яюыєўшЄ№ё  лёьх°рээюх╗ +ЄЁ╕їёшьтюы№эюх Ёрё°шЁхэшх, яюёыхфэшх фтр ёшьтюыр ъюЄюЁюую Ч +Єръшх цх, ъръ є яюёыхфэхую яюьх∙╕ээюую т ¤ЄюЄ рЁїшт Їрщыр.╤ь. Ёрё°шЁхэшх лA╗, яєэъЄ 1.
add╠юфєы№ (яырушэ) фы  уЁрЇшўхёъюую ЁхфръЄюЁр Burial Gfx Editor +тхЁёшш 3.0x.┬шфшью, юЄ лaddition╗ (лфюяюыэхэшх╗).╤ь. фюъєьхэЄрЎш■ ъ ЁхфръЄюЁє.
alm╚ёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т ЇюЁьрЄх рёёхьсыхЁр ALASM +фы  X-DOS.
+╧ЁюуЁрььр фы  юсЁрсюЄъш: BestView (ё х╕ яюью∙№■ ьюцэю яЁюёьюЄЁхЄ№ +alm-Їрщы, ъюэтхЁЄшЁютрЄ№ хую т ЄхъёЄ).		╬Є эрчтрэш  рёёхьсыхЁр.╤ь. Ёрё°шЁхэшх лH╗. ╟рьхўє, ўЄю +т alm-Їрщых яю ёьх∙хэш■ 8 ёюфхЁцшЄё  ёЄЁюър +лalm╗, р эх лH╗.
AMPлPLAYERS.AMP╗ Ч сшсышюЄхър ьюфєыхщ (яыххЁют, +Ёрёяръют∙шъют ш фЁ.) фы  яЁюшуЁ√трЄхы  ZX AMP.╬Є эрчтрэш  яЁюшуЁ√трЄхы .├фх эрщЄш юяшёрэшх ЇюЁьрЄр,   эх чэр■, эю ьюує яюёютхЄютрЄ№ +шчєўшЄ№ шёїюфэ√щ ЄхъёЄ яЁюуЁрьь√ фы  ёсюЁъш Їрщыр +лPLAYERS.AMP╗ шч юЄфхы№э√ї ьюфєыхщ (Їрщы +лAMPCREAT.H╗) ш яюяЁюсютрЄ№ ёрьюёЄю Єхы№эю ЁрчюсЁрЄ№ё  +т ЇюЁьрЄх.
ani╘рщы ё рэшьрЎшхщ, ёючфрээ√щ яЁюуЁрььющ GIF convertor/animator.╬Є лanimation╗ (лрэшьрЎш ╗).╘юЁьрЄ юяшёрэ т фюъєьхэЄрЎшш ъ яЁюуЁрььх. ╥ръцх т ъюьяыхъЄ +яюёЄртъш яЁюуЁрьь√ тїюфшЄ шёїюфэ√щ ЄхъёЄ яЁюшуЁ√трЄхы  +ani-Їрщыют.
ansANSI-уЁрЇшър.
+╧ЁюуЁрььр фы  юсЁрсюЄъш: ANSI viewer/player 0.3G beta.		╬Є лANSI╗. + + + + + + + + + +
1)ёь. фюъєьхэЄрЎш■ ъ ANSI viewer/player 0.3G beta.
2)http://www.codenet.ru/progr/video/ansi.php
+
asc╩юьяшышЁютрээ√щ ьєч√ъры№э√щ ьюфєы№, эряшёрээ√щ т ЁхфръЄюЁх ASC Sound +Master, схч яыххЁр, тючьюцэю, ё фюсртыхээющ шэЇюЁьрЎшхщ +ю эрчтрэшш ш ртЄюЁх ьюфєы .
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лasc╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator.		╬Є эрчтрэш  ЁхфръЄюЁр.╚эЇюЁьрЎш■ ю ёЄЁєъЄєЁх чруюыютър asc-Їрщыют ьюцэю эрщЄш +т ёяЁртъх ъ AY Emulator (Ёрчфхы л╘юЁьрЄ√ +Їрщыют╗). ├фх эрщЄш сюыхх яюыэюх юяшёрэшх ЇюЁьрЄр,   эх чэр■, +эю ьюує яюёютхЄютрЄ№ яюёьюЄЁхЄ№ шёїюфэ√х ЄхъёЄ√ ьєч√ъры№эюую ЁхфръЄюЁр +Vortex Tracker II фы  PC (юэш фюёЄєяэ√ эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗). ╧юёьюЄЁхт т Їрщых лtrfuncs.pas╗, +ъръ яЁюшёїюфшЄ шьяюЁЄшЁютрэшх asc-ьюфєыхщ яЁш шї чруЁєчъх +т ЁхфръЄюЁ, ьюцэю яюяЁюсютрЄ№ ЁрчюсЁрЄ№ё  т шї ЇюЁьрЄх.
asm + + + + + +
1)шёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т юс√ўэюь ЄхъёЄютюь +ЇюЁьрЄх.
+		╬Є лassembler╗ (лрёёхьсыхЁ╗).╤ь. Ёрё°шЁхэшх лTXT╗.
+ + + + + +
2)шёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т ЇюЁьрЄх рёёхьсыхЁр +ZX ASM 3.10.
+		╬Є лassembler╗ (лрёёхьсыхЁ╗).╤ь. Ёрё°шЁхэшх лzas╗.


B

+B   +b   +bbs   +big   +bin   +bit   +blu   +bmp   +brg +
B╧ЁюуЁрььр эр ┴хщёшъх. ╬фэю шч ўхЄ√Ё╕ї ёЄрэфрЁЄэ√ї Ёрё°шЁхэшщ +TR-DOS.╬Є лBASIC╗ (л┴хщёшъ╗). + + + + + + + + + +
1)└.╦рЁўхэъю, ═.╨юфшюэют. лZX Spectrum ш TR-DOS +фы  яюы№чютрЄхыхщ ш яЁюуЁрььшёЄют╗. ╤╧с, л╧шЄхЁ╗, +1994.
2)эхьэюую шэЇюЁьрЎшш ю ёЄЁєъЄєЁх схщёшъ-Їрщыют хёЄ№ +т фюъєьхэЄрЎшш ъ ьюхщ яЁюуЁрььх BestView.
+
b + + + + + +
1)ъюьрэфэ√щ Їрщы ё яЁюуЁрььющ фы  ютхЁых  лbatproc╗ +ъ EMS.
+		╬Є лbatch file╗ (лъюьрэфэ√щ Їрщы╗). 
+ + + + + +
2)ёшэ   ёюёЄрты ■∙р  3-color screen.
+		╬Є лblue╗ (лёшэшщ╗).╧ЁхфёЄрты хЄ ёюсющ ¤ъЁрээ√щ Їрщы схч рЄЁшсєЄют. ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.
bbsлfiles.bbs╗ Ч ЄхъёЄют√щ Їрщы ё ъЁрЄъшьш +юяшёрэш ьш Їрщыют, ёюфхЁцр∙шїё  т рЁїштх шыш ърЄрыюух, +т ъюЄюЁюь ¤ЄюЄ Їрщы Ёрёяюыюцхэ.╬Є лBBS╗ Ч лBulletin Board System╗ +(л¤ыхъЄЁюээр  фюёър юс· тыхэшщ╗).┬ ърцфющ ёЄЁюъх ёюфхЁцшЄё  шэЇюЁьрЎш  юс юфэюь Їрщых: ёэрўрыр +шь  ш Ёрё°шЁхэшх, яюЄюь юфшэ шыш эхёъюы№ъю яЁюсхыют, +р чр эшьш Ч ъюььхэЄрЁшщ ъ Їрщыє
big╚чюсЁрцхэшх (ў/с шыш ё рЄЁшсєЄрьш), °шЁшэр ш/шыш т√ёюЄр +ъюЄюЁюую т Ўхыюх ўшёыю Ёрч сюы№°х, ўхь є ¤ъЁрэр ZX Spectrum. +╧ыю∙рф№ шчюсЁрцхэш  Ч эх сюыхх 9 ¤ъЁрэют. ╤ючфр╕Єё  яЁюуЁрььющ +УbigФ view.╬Є лbig╗ (лсюы№°ющ╗).┬ эрўрых Їрщыр Ч чруюыютюъ: яхЁт√щ срщЄ Ч 0, хёыш +шчюсЁрцхэшх ў/с, ш л+╗, хёыш ё рЄЁшсєЄрьш; чрЄхь +3 срщЄр Ч ЁрчьхЁ√ шчюсЁрцхэш  (эряЁшьхЁ, л2*2╗). +╧юёых чруюыютър Ч єяръютрээ√х ¤ъЁрэ√ т ЇюЁьрЄх Laser Compact +5.2 (ёь. Ёрё°шЁхэшх лPLC╗).
bin─тюшўэ√щ Їрщы (эряЁшьхЁ, ё ёюфхЁцшь√ь ╧╟╙).╬Є лbinary╗ (лфтюшўэ√щ╗).─тюшўэ√щ Їрщы.
bit├ЁрЇшўхёъшщ Їрщы (эрсюЁ ёцрЄ√ї ёяЁрщЄют) фы  шёяюы№чютрэш  +т ёшёЄхьх Quick HyperText.╬Є эрчтрэш  шёяюы№чєхьюую ьхЄюфр ёцрЄш  (bitpack).http://zxdocs.fatal.ru, Ёрчфхы +лFormats╗ (рЁїшт лbit.zip╗).
blu╤шэ   ёюёЄрты ■∙р  3-color screen (Їрщы√ ё Єръшь +Ёрё°шЁхэшхь ёючфр■Єё  яЁюуЁрььющ JPEG/GIF laboratory).╬Є лblue╗ (лёшэшщ╗).╧ЁхфёЄрты хЄ ёюсющ ¤ъЁрээ√щ Їрщы схч рЄЁшсєЄют. ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.
bmp├ЁрЇшўхёъшщ Їрщы т ЇюЁьрЄх BMP.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: Bitmap Viewer 2.0 BETA, +ZX<>BMP Converter 2.0, BMP 3-COLOR 1.0, +BMP service 1.0.		╬Є лbit map╗ (лсшЄют√щ ьрёёшт╗).http://forum.alpe.ru, Ёрчфхы +л╘юЁьрЄ√ Їрщыют╗, Єхьр лGraphics File Formats╗.
brg3-color screen.лb╗ Ч юЄ лblue╗ +(лёшэшщ╗), лr╗ Ч юЄ лred╗ +(лъЁрёэ√щ╗), лg╗ Ч +юЄ лgreen╗ (лчхыхэ√щ╗).╥Ёш ¤ъЁрээ√ї Їрщыр схч рЄЁшсєЄют, юфшэ чр фЁєушь: ёэрўрыр +ёшэ   ёюёЄрты ■∙р  шчюсЁрцхэш , яюЄюь ъЁрёэр  ш чхы╕эр . ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.


C

+C   +c   +CHI   +chr   +cht   +Ckt   +COD +
C╩юфют√щ Їрщы. ╬фэю шч ўхЄ√Ё╕ї ёЄрэфрЁЄэ√ї Ёрё°шЁхэшщ +TR-DOS.╬Є лcode╗ (лъюфют√щ╗).╬ўхэ№ ьэюушх яЁюуЁрьь√ шёяюы№чє■Є ¤Єю Ёрё°шЁхэшх, Єръ ўЄю ЇюЁьрЄ +Їрщыр чртшёшЄ юЄ ъюэъЁхЄэющ яЁюуЁрьь√, т ъюЄюЁющ юэ с√ы ёючфрэ.
c + + + + + +
1)яЁюуЁрььр эр ╤ш.
+		╬Є эрчтрэш   ч√ър яЁюуЁрььшЁютрэш . 
+ + + + + +
2)тхъЄюЁэ√щ °ЁшЇЄ т ЇюЁьрЄх CHR, ёючфрээ√щ т ЁхфръЄюЁх Chr +Editor.
+		┬шфшью, юЄ эрчтрэш  ЇюЁьрЄр °ЁшЇЄр.╤ь. Ёрё°шЁхэшх лchr╗.
CHI╠єч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Chip Tracker 1.x.╬Є эрчтрэш  ЁхфръЄюЁр.╘юЁьрЄ юяшёрэ т ¤ыхъЄЁюээющ урчхЄх AlcoNews #26.
chr┬хъЄюЁэ√щ °ЁшЇЄ т ЇюЁьрЄх CHR.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: Chr Editor 1.50, ChrPrint 1.06, Burial +Gfx Editor.		╬Є лcharacter╗ (лёшьтюы╗). + + + + + + + + + +
1)http://forum.alpe.ru, Ёрчфхы +л╘юЁьрЄ√ Їрщыют╗, Єхьр л╤ЄЁєъЄєЁр Їрщыр °ЄЁшїютюую ЇюэЄр +ЇшЁь√ Borland╗.
2)http://www.codenet.ru/progr/formt/chr.php
+
cht╩юьяшышЁютрээ√щ Їрщы Quick HyperText.╧хЁтр  сєътр Ч юЄ лcompiled╗ +(лъюьяшышЁютрээ√щ╗), ёыхфє■∙шх фтх сєът√ Ч +юЄ лHyperText╗.http://zxdocs.fatal.ru, Ёрчфхы +лFormats╗ (рЁїшт лcht.zip╗).
Ckt╧юўЄют√щ яръхЄ (ёь. Ёрё°шЁхэшх лpkt╗). +┴єф№Єх тэшьрЄхы№э√: эх ърцфр  яЁюуЁрььр, яюффхЁцштр■∙р  ЄЁ╕їёшьтюы№э√х +Ёрё°шЁхэш  Їрщыют, яЁртшы№эю юЄюсЁрчшЄ ¤Єю Ёрё°шЁхэшх эр ¤ъЁрэх. +╥ръ ъръ т э╕ь ёюўхЄр■Єё  яЁюяшёэ√х ш ёЄЁюўэ√х сєът√, юэю ьюцхЄ +с√Є№ ёюўЄхэю эхфюяєёЄшь√ь, ш Єюуфр т√ єтшфшЄх ыш°№ яхЁт√щ хую +ёшьтюы Ч лC╗.╥ръшь ёЄрэютшЄё  Ёрё°шЁхэшх pkt-Їрщыр яюёых хую шчтыхўхэш  +шч рЁїштр ё яюью∙№■ ёЄрЁ√ї тхЁёшщ яЁюуЁрьь√ pkunzip.╤ь. Ёрё°шЁхэшх лpkt╗.
COD├ЁрЇшўхёъшщ Їрщы (ёяЁрщЄ).┬шфшью, юЄ лcode╗. 


D

+D   +DAT   +diz   +doc   +drv   +dsc +
D + + + + + +
1)╫шёыютющ шыш ёшьтюы№э√щ ьрёёшт. ╬фэю шч ўхЄ√Ё╕ї ёЄрэфрЁЄэ√ї +Ёрё°шЁхэшщ TR-DOS.
+		╬Є лdata╗ (лфрээ√х╗).└.╦рЁўхэъю, ═.╨юфшюэют. лZX Spectrum ш TR-DOS +фы  яюы№чютрЄхыхщ ш яЁюуЁрььшёЄют╗. ╤╧с, л╧шЄхЁ╗, +1994.
+ + + + + +
2)фтєї¤ъЁрээр  ърЁЄшэър.
+		╬Є лdouble╗ (лфтющэющ╗).─тр ¤ъЁрээ√ї Їрщыр, юфшэ чр фЁєушь (ю ЇюЁьрЄх ¤ъЁрээюую +Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗).
DAT╘рщы ё фрээ√ьш (Єръюх Ёрё°шЁхэшх шёяюы№чєхЄё  т яЁюуЁрььрї Video +Studio, Orion).╬Є лdata╗ (лфрээ√х╗).╘юЁьрЄ Їрщыр чртшёшЄ юЄ ъюэъЁхЄэющ яЁюуЁрьь√, т ъюЄюЁющ юэ с√ы +ёючфрэ.
diz╥хъёЄют√щ Їрщы ё ъЁрЄъшь юяшёрэшхь ёюфхЁцшьюую рЁїштр +шыш ърЄрыюур, т ъюЄюЁюь юэ Ёрёяюыюцхэ.╬Є лDescription In ZIP File╗ (л╬яшёрэшх +т ZIP-Їрщых╗).╤ь. Ёрё°шЁхэшх лTXT╗.
doc + + + + + +
1)фюъєьхэЄ т ЇюЁьрЄх ЄхъёЄютюую ЁхфръЄюЁр Microsoft Word.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: WordCon, ACE (ё яюью∙№■ яырушэр +лaceFROM╗).
+		╬Є лdocument╗ (лфюъєьхэЄ╗).┬ ьюхщ ёЄрЄ№х л╧ЁюёЄхщ°шщ ъюэтхЁЄюЁ +DOC Ц> TXT╗ (л╨рфшюьшЁ. ┬р° ъюья№■ЄхЁ╗ +10/2003) яЁштюфшЄё  эхьэюую шэЇюЁьрЎшш, яюыєўхээющ юя√Єэ√ь яєЄ╕ь, +ю ЇюЁьрЄх DOC-Їрщыют Microsoft Word т ъюфшЁютъх +Unicode. ╥ръцх Єрь юяшёрэ яЁюёЄхщ°шщ, эю яЁшуюфэ√щ тю ьэюушї ёыєўр ї +рыуюЁшЄь ъюэтхЁЄшЁютрэш  Єръшї Їрщыют т ЄхъёЄ ш яЁштхф╕э шёїюфэ√щ +ЄхъёЄ (эр Turbo C) яЁюуЁрьь√-ъюэтхЁЄюЁр (ёЁрчє +юуютюЁ■ё№, ўЄю эх тёх Їрщы√ юэ ъюэтхЁЄшЁєхЄ яЁртшы№эю).
+ + + + + +
2)юс√ўэ√щ ЄхъёЄют√щ Їрщы.
+		╬Є лdocument╗ (лфюъєьхэЄ╗).╤ь. Ёрё°шЁхэшх лTXT╗.
drv─ЁрщтхЁ яЁшэЄхЁр фы  рёёхьсыхЁр ZX ASM 3.10.╬Є лdriver╗ (лфЁрщтхЁ╗). 
dsc─тєї¤ъЁрээр  ърЁЄшэър (Єръюх Ёрё°шЁхэшх шёяюы№чєхЄё  т JPEG +convertor).╬Є лdouble screen╗ (лфтющэющ ¤ъЁрэ╗).─тр ¤ъЁрээ√ї Їрщыр, юфшэ чр фЁєушь (ю ЇюЁьрЄх ¤ъЁрээюую +Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗).


E

+E   +err   +exe +
E╤юїЁрэ╕ээюх ёюёЄю эшх шуЁ√ ELITE 3 (эютюёшсшЁёър  тхЁёш ).╬Є эрчтрэш  шуЁ√.╤ь. яшё№ью Eugene Palenock т ъюэЇхЁхэЎшш ZX.SPECTRUM: http://www.google.ru/groups?hl=ru&
+lr=&ie=UTF-8&inlang=ru&selm=985209677%40f2065.
+n5020.z2.FidoNet.ftn
errлcompile.err╗ Ч Їрщы ё шэЇюЁьрЎшхщ +юс ю°шсърї ъюьяшы Ўшш, ёючфртрхь√щ рёёхьсыхЁюь +ZX ASM 3.10.╬Є лerror╗ (лю°шсър╗). 
exe╚ёяюыэ хь√х Їрщы√ рёёхьсыхЁр ZX ASM 3.10.╬Є лexecutable╗ (лшёяюыэ хь√щ╗). 


F

+F   +fls   +FNT, fnt   +fr0, fr1, Е   +ftc +
F + + + + + +
1)ьєч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Sound Tracker Pro.
+		  
+ + + + + +
2)ёяЁрщЄ, ёючфрээ√щ т ЁхфръЄюЁх Sprite Master.
+		  
fls╠єч√ъры№э√щ ьюфєы№, эряшёрээ√щ т ЁхфръЄюЁх Flash Tracker.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лfls╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator.		╬Є эрчтрэш  ЁхфръЄюЁр.├фх эрщЄш юяшёрэшх ЇюЁьрЄр,   эх чэр■, эю ьюує яюёютхЄютрЄ№ +яюёьюЄЁхЄ№ шёїюфэ√х ЄхъёЄ√ ьєч√ъры№эюую ЁхфръЄюЁр Vortex Tracker II +фы  PC (юэш фюёЄєяэ√ эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗). ╧юёьюЄЁхт т Їрщых лtrfuncs.pas╗, +ъръ яЁюшёїюфшЄ шьяюЁЄшЁютрэшх fls-ьюфєыхщ яЁш шї чруЁєчъх +т ЁхфръЄюЁ, ьюцэю яюяЁюсютрЄ№ ЁрчюсЁрЄ№ё  т шї ЇюЁьрЄх. ╥ръцх, +тючьюцэю, юърцхЄё  яюыхчэ√ь шёїюфэ√щ ЄхъёЄ юЁшушэры№эюую яыххЁр +fls-ьюфєыхщ Ч юэ фюёЄєяхэ эр Єюь цх +ёрщЄх (рЁїшт лFLSPlayer.rar╗).
FNT, fnt╨рёЄЁют√щ °ЁшЇЄ.╬Є лfont╗ (л°ЁшЇЄ╗).╘юЁьрЄ Їрщыр чртшёшЄ юЄ ъюэъЁхЄэющ яЁюуЁрьь√, т ъюЄюЁющ +юэ ёючфрэ шыш шёяюы№чєхЄё  (яЁюуЁрььр, ъюэхўэю, ьюцхЄ яюффхЁцштрЄ№ +ш эхёъюы№ъю Ёрчышўэ√ї ЇюЁьрЄют). ═ряЁшьхЁ, т рёёхьсыхЁх +ZX ASM 3.10 шёяюы№чє■Єё  fnt-Їрщы√ фышэющ #800 срщЄют, +ёюфхЁцр∙шх шчюсЁрцхэш  256 ёшьтюыют 6x8, яю 8 срщЄют эр ёшьтюы +(ьырф°шх фтр сшЄр ърцфюую срщЄр эх шёяюы№чє■Єё  +ш Ёртэ√ 0).
fr0, fr1, Е└Ёїшт ё яюўЄют√ьш яръхЄрьш, ёЇюЁьшЁютрээ√щ т я ЄэшЎє.╧хЁт√х фтр ёшьтюыр Ч юЄ лFriday╗ +(ля ЄэшЎр╗), ЄЁхЄшщ ёшьтюы Ч эюьхЁ Їрщыр (эрўшэр  +ё 0).╘юЁьрЄ рЁїштр чртшёшЄ юЄ шёяюы№чютрээюую рЁїштрЄюЁр. ╘юЁьрЄ яюўЄют√ї +яръхЄют (pkt-Їрщыют) Ч ёь. Ёрё°шЁхэшх +лpkt╗.
ftc╠єч√ъры№э√щ ьюфєы№ т ЇюЁьрЄх ЁхфръЄюЁр Fast Tracker.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лftc╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator, р т Fast Tracker шёяюы№чєхЄё  +Ёрё°шЁхэшх лY╗.		╬Є эрчтрэш  ЁхфръЄюЁр.├фх эрщЄш юяшёрэшх ЇюЁьрЄр,   эх чэр■, эю ьюує яюёютхЄютрЄ№ +яюёьюЄЁхЄ№ шёїюфэ√х ЄхъёЄ√ ьєч√ъры№эюую ЁхфръЄюЁр Vortex Tracker II +фы  PC (юэш фюёЄєяэ√ эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗). ╧юёьюЄЁхт т Їрщых лtrfuncs.pas╗, +ъръ яЁюшёїюфшЄ шьяюЁЄшЁютрэшх ftc-ьюфєыхщ яЁш шї чруЁєчъх +т ЁхфръЄюЁ, ьюцэю яюяЁюсютрЄ№ ЁрчюсЁрЄ№ё  т шї ЇюЁьрЄх. ╥ръцх, +тючьюцэю, юърцхЄё  яюыхчэ√ь ЄхъёЄ фшчрёёхьсышЁютрээюую юЁшушэры№эюую яыххЁр +ftc-ьюфєыхщ Ч юэ фюёЄєяхэ эр Єюь цх +ёрщЄх (рЁїшт лFTCPlayer.rar╗).


G

+G   +g   +gif   +grn   +GTR, gtr +
G╤яЁрщЄ, ёючфрээ√щ т ЁхфръЄюЁх Sprite Edit.┬шфшью, юЄ лgraphics╗ (луЁрЇшър╗, +луЁрЇшўхёъшщ╗). 
g╟хы╕эр  ёюёЄрты ■∙р  3-color screen.╬Є лgreen╗ (лчхы╕э√щ╗).╧ЁхфёЄрты хЄ ёюсющ ¤ъЁрээ√щ Їрщы схч рЄЁшсєЄют. ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.
gif├ЁрЇшўхёъшщ Їрщы т ЇюЁьрЄх GIF.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: GIF convertor/animator 0.21 (by SAM +style), JPEG/GIF laboratory 1.5 (by SAM style), GIF screenТs +viewer (by DIS/XPJ) (эрёъюы№ъю ьэх шчтхёЄэю, ¤Єр яЁюуЁрььр фюёЄєяэр +ыш°№ т шёїюфэ√ї ЄхъёЄрї т ЇюЁьрЄх рёёхьсыхЁр ALASM, Єръ ўЄю +яхЁхф чряєёъюь яЁшф╕Єё  трь х╕ юЄъюьяшышЁютрЄ№).
+╩ёЄрЄш, хёЄ№ х∙╕ GIF viewer яюф IS-DOS.		╬Є лGraphics Interchange Format╗ Ч +л╘юЁьрЄ юсьхэр уЁрЇшўхёъшьш фрээ√ьш╗. + + + + + + + + + +
1)http://forum.alpe.ru, Ёрчфхы +л╘юЁьрЄ√ Їрщыют╗, Єхь√ л╬с· ёэхэшх LZW ш GIF╗ +ш лGIF89a Specification╗.
2)http://zxdocs.fatal.ru, Ёрчфхы +лFormats╗ (рЁїшт лGIF.zip╗).
+
grn╟хы╕эр  ёюёЄрты ■∙р  3-color screen (Їрщы√ ё Єръшь +Ёрё°шЁхэшхь ёючфр■Єё  яЁюуЁрььющ JPEG/GIF laboratory).╬Є лgreen╗ (лчхы╕э√щ╗).╧ЁхфёЄрты хЄ ёюсющ ¤ъЁрээ√щ Їрщы схч рЄЁшсєЄют. ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.
GTR, gtr╠єч√ъры№э√щ ьюфєы№ т ЇюЁьрЄх ЁхфръЄюЁр Global Tracker.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лgtr╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator, р т Global Tracker шёяюы№чєхЄё  +Ёрё°шЁхэшх лGTR╗.		╬Є эрчтрэш  ЁхфръЄюЁр.═хъюЄюЁр  шэЇюЁьрЎш  ю ЇюЁьрЄх ёюфхЁцшЄё  т шёїюфэюь ЄхъёЄх +юЁшушэры№эюую яыххЁр gtr-ьюфєыхщ Ч юэ фюёЄєяхэ +эр ёрщЄх http://bulba.at.kz, +т Ёрчфхых л╧ЁюуЁрььшёЄє╗ (Їрщы лGTRPlayer.rar╗). +╥ръцх ьюує яюёютхЄютрЄ№ яюёьюЄЁхЄ№ шёїюфэ√х ЄхъёЄ√ ьєч√ъры№эюую ЁхфръЄюЁр +Vortex Tracker II фы  PC (юэш фюёЄєяэ√ эр Єюь цх ёрщЄх). +╧юёьюЄЁхт т Їрщых лtrfuncs.pas╗, ъръ яЁюшёїюфшЄ +шьяюЁЄшЁютрэшх gtr-ьюфєыхщ яЁш шї чруЁєчъх т ЁхфръЄюЁ, +ьюцэю яюяЁюсютрЄ№ ЁрчюсЁрЄ№ё  т шї ЇюЁьрЄх.


H

+H   +h   +h00, h01, Е   +hrp   +hmp   +htm +
H╚ёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т ЇюЁьрЄх рёёхьсыхЁр +ALASM. ╨рчьхЁ Їрщыр эх яЁхт√°рхЄ 16 ╩┴. ╚эЇюЁьрЎш  +ю ЇюЁьрЄх Ч ёь. Їрщы лALstr+.H╗ +шч ъюьяыхъЄр яюёЄртъш ALASM; Єрь цх эрїюфшЄё  ш яЁюЎхфєЁр +яЁхюсЁрчютрэш  ёЄЁюъш шч ЇюЁьрЄр ALASM т юс√ўэ√щ ЄхъёЄ.
h┴шсышюЄхър, яюфъы■ўрхьр  ъ яЁюуЁрььх эр ╤ш.  
h00, h01, Е╧Ёюфюыцхэшх рЁїштр, ёючфрээюую фхью-тхЁёшхщ HRIP.┴єътр лh╗ Ч юЄ лhrp╗, ёыхфє■∙шх фтх +ЎшЇЁ√ Ч эюьхЁ Їрщыр-яЁюфюыцхэш  (эрўшэр  +ё 0).╧ЁюёЄю ўрёЄ№ рЁїштр, схч фюяюыэшЄхы№эющ ёыєцхсэющ шэЇюЁьрЎшш.
hrp└Ёїшт HRIP.╬Є эрчтрэш  рЁїштрЄюЁр.

╤ь. фюъєьхэЄрЎш■ ъ рЁїштрЄюЁє HRIP (Єрь юяшёрэр ёЄЁєъЄєЁр +рЁїштр ш яЁштхфхэ√ шёїюфэ√х ЄхъёЄ√ яЁюЎхфєЁ єяръютъш ш Ёрёяръютъш). +▌Єє фюъєьхэЄрЎш■ ьюцэю эрщЄш, эряЁшьхЁ, эр ёрщЄх http://zxdocs.fatal.ru, т Ёрчфхых +лFormats╗ (рЁїшт лHRIP.zip╗).

+

╟рьхўє, ўЄю т фюъєьхэЄрЎшш (Їрщы лHRIP_DOC.WRD╗ +шч ъюьяыхъЄр яюёЄртъш HRIP 1.05) яЁштюфшЄё  ёыхфє■∙р  ЇюЁьєыр +фы  т√ўшёыхэш  фышэ√ рЁїштр т срщЄрї схч єў╕Єр ърЄрыюур:

+

END_ARCH=[LAST]*256Ц(256Ц[SMESH]).

+

┬ фхщёЄтшЄхы№эюёЄш цх юэр фюыцэр т√уы фхЄ№ Єръ:

+

END_ARCH=[LAST]*256Ц(256Ц[SMESH]), хёыш [SMESH]>0;

+

END_ARCH=[LAST]*256, хёыш [SMESH]=0.

+

╚ыш Єръ:

+

END_ARCH=[LASTЦ1]*256+[SMESH], хёыш [SMESH]>0;

+

END_ARCH=[LAST]*256, хёыш [SMESH]=0.

+

┴хч тхЄтыхэш  ¤Єр ЇюЁьєыр ьюцхЄ с√Є№ чряшёрэр Єръ:

+

END_ARCH=[LAST]*256Ц((256Ц[SMESH]) mod 256).

+

╬ ЇюЁьрЄх ёюсёЄтхээю єяръютрээ√ї фрээ√ї Ч +ёь. Ёрё°шЁхэшх лp╗, яєэъЄ 1 +(т HRIP шёяюы№чєхЄё  Єръющ цх ьхЄюф ёцрЄш , ъръ +т HRUST 2.1, юЄышўшх Єюы№ъю т ЇюЁьрЄх чруюыютър єяръютрээюую +сыюър).

hmp╘рщы-яЁюхъЄ Quick HyperText.╬Є лHelp Maker Project╗ (Ёрсюўхх эрчтрэшх Quick HyperText +System Ч Help Maker).╘рщы яЁхфёЄрты хЄ ёюсющ HRIP-рЁїшт (ёь. Ёрё°шЁхэшх +лhrp╗).
htmHTML-Їрщы.
+╧ЁюуЁрььр фы  яЁюёьюЄЁр: BestView, эрўшэр  ё тхЁёшш 2.15 (юэр +яЁхюсЁрчєхЄ HTML т ЄхъёЄ).		╬Є лHTML╗ (лHyper-Text Markup +Language╗ Ч л ч√ъ ЁрчьхЄъш ушяхЁЄхъёЄр╗).HTML 4.01 Specification (http://www.w3.org/TR/1999/
+REC-html401-19991224/). ╨єёёъшщ яхЁхтюф фюёЄєяхэ эр ёрщЄх http://pyramidin.narod.ru.


I

+I   +i   +img   +imp   +ini   +ion +
I + + + + + +
1)ё¤ьяы фы  ьєч√ъры№эюую ЁхфръЄюЁр Super Sonic.
+		  
+ + + + + +
2)юЎшЇЁютрээ√щ ё¤ьяы фы  ьєч√ъры№эюую ЁхфръЄюЁр +Instrument.
+		╬Є эрчтрэш  ЁхфръЄюЁр. 
+ + + + + +
3) Ёы√ъ фы  Їрщыютющ юсюыюўъш Windows 2000 (эх яєЄрЄ№ +ё юфэюшь╕ээющ ╬╤ фы  PC!) ;Ц).
+		  
i + + + + + +
1)шэёЄЁєьхэЄ фы  уЁрЇшўхёъюую ЁхфръЄюЁр Graphic Station.
+		╬Є лinstrument╗ (лшэёЄЁєьхэЄ╗). 
+ + + + + +
2)лzxamp.i╗ Ч Їрщы эрёЄЁюхъ яЁюшуЁ√трЄхы  +ZX AMP.
+		┬шфшью, юЄ лinitialization╗ +(лшэшЎшрышчрЎш ╗).╥хъёЄют√щ Їрщы. ╙чэрЄ№ юс юяшё√трхь√ї т э╕ь ярЁрьхЄЁрї ьюцэю +ышсю шч ъюььхэЄрЁшхт т ёрьюь ¤Єюь Їрщых, ышсю шч фюъєьхэЄрЎшш +ъ ZX AMP.
img + + + + + +
1)фтєї¤ъЁрээр  ърЁЄшэър (Єръшх Їрщы√ ьюцэю юсЁрсрЄ√трЄ№ т уЁрЇшўхёъюь +ЁхфръЄюЁх Burial Gfx Editor 3.0x).
+		╬Є лimage╗ (лшчюсЁрцхэшх╗).─тр ¤ъЁрээ√ї Їрщыр, юфшэ чр фЁєушь (ю ЇюЁьрЄх ¤ъЁрээюую +Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗).
+ + + + + +
2)ў╕Ёэю-схыюх шчюсЁрцхэшх, ёючфрээюх яЁюуЁрььющ JPEG +convertor.
+╧Ёшьхўрэшх: яюёых img-Їрщыр ьюцхЄ ёыхфютрЄ№ Їрщы +ё Ёрё°шЁхэшхь лsat╗ Ч ¤Єю +яЁюфюыцхэшх img-Їрщыр.
+		╬Є лimage╗ (лшчюсЁрцхэшх╗).╤эрўрыр Ч 12-срщЄэ√щ чруюыютюъ: ёЄЁюър +лJPG img╗, эєыхтющ срщЄ, 2 срщЄр Ч °шЁшэр +шчюсЁрцхэш  т срщЄрї (фы  яюыєўхэш  °шЁшэ√ т яшъёхырї ¤Єю +чэрўхэшх эрфю єьэюцшЄ№ эр 8) ш 2 срщЄр Ч т√ёюЄр +шчюсЁрцхэш  т яшъёхырї. ╟эрўхэш  їЁрэ Єё  т ЇюЁьрЄх льырф°шщ +срщЄ яхЁт√ь╗. ─рыхх Ч ёрью шчюсЁрцхэшх, яю ёЄЁюърь, +ётхЁїє тэшч.
imp╠юфєы№ ъюэтхЁЄшЁютрэш  ЄхъёЄют фы  рёёхьсыхЁр +ZX ASM 3.10.╬Є лimport╗ (лшьяюЁЄшЁютрЄ№╗). 
iniлhmledit.ini╗ Ч Їрщы ё эрёЄЁющърьш ЁхфръЄюЁр +Quick HyperText.╬Є лinitialization╗ (лшэшЎшрышчрЎш ╗). 
ionлdescript.ion╗ Ч ЄхъёЄют√щ Їрщы ё ъЁрЄъшьш +юяшёрэш ьш Їрщыют, ёюфхЁцр∙шїё  т рЁїштх шыш ърЄрыюух, +т ъюЄюЁюь ¤ЄюЄ Їрщы Ёрёяюыюцхэ.╬Є лdescription╗ (люяшёрэшх╗).┬ ърцфющ ёЄЁюъх ёюфхЁцшЄё  шэЇюЁьрЎш  юс юфэюь Їрщых: ёэрўрыр +шь  ш Ёрё°шЁхэшх, яюЄюь юфшэ шыш эхёъюы№ъю яЁюсхыют, +р чр эшьш Ч ъюььхэЄрЁшщ ъ Їрщыє


J

+jpe   +JPG, jpg +
jpe├ЁрЇшўхёъшщ Їрщы т ЇюЁьрЄх JPEG.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: ёь. Ёрё°шЁхэшх лjpg╗.		╨рё°шЁхэшх лjpeg╗, юсЁхчрээюх фю ЄЁ╕ї ёшьтюыют.╤ь. Ёрё°шЁхэшх лjpg╗.
JPG, jpg├ЁрЇшўхёъшщ Їрщы т ЇюЁьрЄх JPEG.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: JPEG viewer 0.42, JPEG convertor maximum, +JPEG/GIF laboratory 1.5.		╬Є лJPEG╗ Ч лJoint Photographic Experts +Group╗.http://forum.alpe.ru, Ёрчфхы +л╘юЁьрЄ√ Їрщыют╗, Єхьр лJPEG File Interchange +Format╗.


K

+kbd +
kbd╘рщы ё юяшёрэшхь Ёрёъырфъш ъыртшрЄєЁ√ фы  ЁхфръЄюЁр Quick +HyperText.╬Є лkeyboard╗ (лъыртшрЄєЁр╗). 


L

+L   +lst +
L─юяюыэшЄхы№эр  шэЇюЁьрЎш  (эрчтрэшх ьюфєы  ш шь  ртЄюЁр) +фы  эхъюьяшышЁютрээюую ьєч√ъры№эюую ьюфєы , ёючфрээюую т ЁхфръЄюЁх +Sound Tracker 3. ╚ь  L-Їрщыр Єръюх цх, ъръ +є ёююЄтхЄёЄтє■∙хую Їрщыр ё ьюфєыхь. 60-срщЄэ√щ Їрщы. ╤юфхЁцшьюх: ёЄЁюър лNAME OF +SONG:╗, яЁюсхы, 10-ёшьтюы№эр  ёЄЁюър ё эрчтрэшхь +ьюфєы , яюёыхфютрЄхы№эюёЄ№ срщЄют #20, #20, #FF, #00, #20, #A8, #10, #12, +ёЄЁюър лCOMPOSED BY:╗, яЁюсхы, 12-ёшьтюы№эр  ёЄЁюър +ё шьхэхь ртЄюЁр, яюёыхфютрЄхы№эюёЄ№ срщЄют #20, #20, #FF.
lst + + + + + +
1)ёяшёюъ ьюфєыхщ (яырушэют) фы  уЁрЇшўхёъюую ЁхфръЄюЁр Burial Gfx +Editor 3.0x.
+		╬Є лlist╗ (лёяшёюъ╗).┬ фюъєьхэЄрЎшш ъ BGE 3.05 ёърчрэю Єюы№ъю, ўЄю +лэр тшф Їрщы ёьрїштрхЄ эр ЄхъёЄют√щ, эю ¤Єю Єюы№ъю +эр тшф, Єръ ўЄю яЁртшЄ№ хую т ЄхъёЄютюь ЁхфръЄюЁх   ъЁрщэх +эх Ёхъюьхэфє■╗. ┬ю тё ъюь ёыєўрх, т√ ьюцхЄх яюяЁюсютрЄ№ +шчєўшЄ№ шёїюфэ√х ЄхъёЄ√ BGE 3.05, фюёЄєяэ√х эр ёрщЄх Open +Source ZX (http://opensourcezx.narod.ru), +ш ёрьюёЄю Єхы№эю ЁрчюсЁрЄ№ё  т ЇюЁьрЄх.
+ + + + + +
2)яыхщышёЄ фы  яЁюшуЁ√трЄхы  ZX AMP.
+		╬Є лlist╗ (лёяшёюъ╗). 


M

+M   +m   +me   +mo0, mo1, Е   +mod   +mon   +MOV   +MPP   +MPS +
M + + + + + +
1)ьєч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Super Sonic.
+		╬Є лmodule╗ (льюфєы№╗). 
+ + + + + +
2)ьєч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Pro Tracker 2.
+		╬Є лmodule╗ (льюфєы№╗).VfNG/NEW. ╬яшёрэшх ЇюЁьрЄр ьюфєыхщ Pro Tracker 2.101. ▌ыхъЄЁюээр  урчхЄр +Echo #2. (┬ ¤Єющ ёЄрЄ№х яЁштюфшЄё  ш шёїюфэ√щ ЄхъёЄ яыххЁр ¤Єшї +ьюфєыхщ.)
+┬√°хєърчрээр  ёЄрЄ№  Єръцх фюёЄєяэр эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗ (рЁїшт лPT2Docs.rar╗).
m╠єч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Pro Tracker 3.╬Є лmodule╗ (льюфєы№╗). ╬яшёрэшх +ЇюЁьрЄр, р Єръцх шёїюфэ√х ЄхъёЄ√ яыххЁют тїюф Є т ъюьяыхъЄ яюёЄртъш +яюёыхфэшї тхЁёшщ ЁхфръЄюЁр Pro Tracker 3 (эр ьюьхэЄ эряшёрэш  ¤Єшї +ёЄЁюъ яюёыхфэ   тхЁёш  Ч 3+69). ═хъюЄюЁ√х ётхфхэш  +юс юёюсхээюёЄ ї яЁюшуЁ√трэш  ьюфєыхщ ьюцэю эрщЄш т фюъєьхэЄрЎшш +ъ ьєч√ъры№эюьє ЁхфръЄюЁє Vortex Tracker II фы  PC (http://bulba.at.kz), р Єръцх т ьюхщ +ёЄрЄ№х л╧юёЄЁюхэшх ЄрсышЎ√ уЁюьъюёЄш +т яыххЁх Pro Tracker 3╗ (л╨рфшюьшЁ. ┬р° +ъюья№■ЄхЁ╗ 4/2004).
meлread.me╗ Ч ЄхъёЄют√щ Їрщы.╬Є ёыютр лme╗.╤ь. Ёрё°шЁхэшх лTXT╗.
mo0, mo1, Е└Ёїшт ё яюўЄют√ьш яръхЄрьш, ёЇюЁьшЁютрээ√щ т яюэхфхы№эшъ.╧хЁт√х фтр ёшьтюыр Ч юЄ лMonday╗ +(ляюэхфхы№эшъ╗), ЄЁхЄшщ ёшьтюы Ч эюьхЁ Їрщыр (эрўшэр  +ё 0).╘юЁьрЄ рЁїштр чртшёшЄ юЄ шёяюы№чютрээюую рЁїштрЄюЁр. ╘юЁьрЄ яюўЄют√ї +яръхЄют (pkt-Їрщыют) Ч ёь. Ёрё°шЁхэшх +лpkt╗.
mod╠єч√ъры№э√щ ьюфєы№ т ЇюЁьрЄх MOD.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: MOD player 2.01, MODТS player, PLAYMOD, +AMMY>PT2, Riff Tracker.		╬Є лmodule╗ (льюфєы№╗). + + + + + + + + + + + + + +
1)ёь. ¤ыхъЄЁюээ√щ цєЁэры ZX Format #7 (т Ёрчфхых +л╧ЁюуЁрььшёЄрь╗).
2)ёь. ¤ыхъЄЁюээє■ урчхЄє Odyssey #8.
3)http://www.codenet.ru/progr/formt/mod1.php
+
mon╠юэшЄюЁ-юЄырфўшъ фы  рёёхьсыхЁр +ZX ASM 3.10.╬Є лmonitor╗ (льюэшЄюЁ╗). 
MOV╧ЁюхъЄ фы  яЁюуЁрьь√ Video Studio.╬Є лmovie╗ (лЇшы№ь╗). 
MPP╤яшёюъ яЁюшуЁ√трхь√ї ьєч√ъры№э√ї ьюфєыхщ (playlist) +фы  Mm<M Player.┬шфшью, ёюъЁр∙хэшх юЄ лMm<M Player playlist╗. 
MPS╠єч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Pro Sound Creator.лM╗ Ч юЄ лmodule╗ +(льюфєы№╗), чрЄхь лPS╗ Ч юЄ эрчтрэш  +ЁхфръЄюЁр.╘юЁьрЄ юяшёрэ т ¤ыхъЄЁюээющ урчхЄх C-Net +Week #8.


N

+nfo +
nfo╥хъёЄют√щ Їрщы ё ъЁрЄъшь юяшёрэшхь ёюфхЁцшьюую рЁїштр +шыш ърЄрыюур, т ъюЄюЁюь юэ Ёрёяюыюцхэ.╬Є лinformation╗ (лшэЇюЁьрЎш ╗).╤ь. Ёрё°шЁхэшх лTXT╗.


O

+╬   +o   +OVL   +ovl   +ovr +
╬ + + + + + +
1)ютхЁыхщ ъ EMS.
+		╬Є лoverlay╗ (лютхЁыхщ╗). 
+ + + + + +
2)эрсюЁ ютхЁыххт рёёхьсыхЁр ALASM.
+
o + + + + + +
1)ьєч√ъры№э√щ юЁэрьхэЄ, ёючфрээ√щ т юфэюь шч ЁхфръЄюЁют: Pro +Tracker 2, Pro Tracker 3, Sound Tracker, Sound Tracker Pro, Global +Tracker.
+		╬Є лornament╗ (люЁэрьхэЄ╗).╙ ърцфюую ЁхфръЄюЁр ётющ ЇюЁьрЄ.
+─ы  Pro Tracker 3: яхЁт√х 64 срщЄр Їрщыр Ч ёьх∙хэш  +т яюыєЄюэрї (ёю чэръюь) фы  ърцфющ шч 64 яючшЎшщ +юЁэрьхэЄр, фрыхх 1 срщЄ Ч эюьхЁ яючшЎшш эрўрыр Ўшъыр (ёўшЄр  +ё 0) ш 1 срщЄ Ч ъюышўхёЄтю шёяюы№чєхь√ї яючшЎшщ +т юЁэрьхэЄх (хёыш єьхэ№°шЄ№ хую эр 1, яюыєўшь эюьхЁ яючшЎшш ъюэЎр +Ўшъыр, ёўшЄр  ё 0).
+ + + + + +
2)ютхЁыхщ Їрщыютющ юсюыюўъш Windows 2000 (эх яєЄрЄ№ ё юфэюшь╕ээющ +╬╤ фы  PC!) ;Ц).
+		╬Є лoverlay╗ (лютхЁыхщ╗). 
OVL╬тхЁыхщ Їрщыютющ юсюыюўъш Consul Commander.╬Є лoverlay╗ (лютхЁыхщ╗).╤ь. фюъєьхэЄрЎш■ ъ Consul Commander.
ovl + + + + + +
1)ютхЁыхщ яЁюуЁрьь√ File Extractor.
+		╬Є лoverlay╗ (лютхЁыхщ╗).╬тхЁыхщ яЁхфёЄрты хЄ ёюсющ яЁюЎхфєЁє т ьр°шээ√ї ъюфрї. ─юъєьхэЄрЎш■ +яю эряшёрэш■ ютхЁыххт ъ File Extractor 1.1b ьюцэю эрщЄш +т ¤ыхъЄЁюээюь цєЁэрых Inferno #1. ┬ File Extractor 2.1b +ёЄЁєъЄєЁр ютхЁыххт с√ыр шчьхэхэр!
+ + + + + +
2)ютхЁыхщ рёёхьсыхЁр ZX ASM 3.10.
+		╬Є лoverlay╗ (лютхЁыхщ╗). 
ovr╬тхЁыхщ фхью-тхЁёшш рёёхьсыхЁр +ZX ASM 3.10.╬Є лoverlay╗ (лютхЁыхщ╗). 


P

+P   +p   +p_?   +pcx   +pht   +PKT, pkt   +PLC, plc   +PPS   +psc   +pt1   +pt2   +pt3   +ptn   +PVD +
P + + + + + +
1)ърЁЄшэър, єяръютрээр  ъюьяЁхёёюЁюь Laser Compact 4.0, 5.0 +(схч Ёрёяръют∙шър).
+		╬Є лpacked╗ (лєяръютрээ√щ╗).Alone Coder. лLC 4.0 ш 5.2╗. ▌ыхъЄЁюээ√щ цєЁэры +Inferno #5.
+ + + + + +
2)єяръютрээ√х фрээ√х.
+		╬Є лpacked╗ (лєяръютрээ√щ╗).╘юЁьрЄ чртшёшЄ юЄ ъюэъЁхЄэющ яЁюуЁрьь√, ё яюью∙№■ ъюЄюЁющ +яЁюшчтюфшырё№ єяръютър. ╬яшёрэшх эхъюЄюЁ√ї ЇюЁьрЄют єяръютрээ√ї фрээ√ї ьюцэю +эрщЄш т ёЄрЄ№ ї Alone CoderТр т ¤ыхъЄЁюээюь цєЁэрых +Inferno #5.
+╧Ёшьхўрэшх: ё яюью∙№■ ьюхщ яЁюуЁрьь√ BestView ьюцэю яюяЁюсютрЄ№ яюыєўшЄ№ +шэЇюЁьрЎш■ ю Єюь, ъръющ яЁюуЁрььющ єяръютрэ сыюъ фрээ√ї ш ъръют√ +ярЁрьхЄЁ√ ¤Єюую сыюър.
p + + + + + +
1)фрээ√х, єяръютрээ√х яю ьхЄюфє Hrust 2.1.
+		╬Є лpacked╗ (лєяръютрээ√щ╗). + + + + + + + + +
1)╚эЇюЁьрЎш  ю ЇюЁьрЄх, ъюЄюЁє■ юяєсышъютры Dima Bystrov (Alone Coder) +т ъюэЇхЁхэЎшш ZX.SPECTRUM:
+http://groups.google.com.ru/groups?hl=ru&lr=&ie=
+UTF-8&inlang=ru&frame=right&th=ce60012b87049f8b&
+seekm=1032491796%40p26.f35.n5029.z2.ftn
2)Alone Coder. лHrum ш Hrust╗. ▌ыхъЄЁюээ√щ цєЁэры +Inferno #5.
+
+ + + + + +
2)ярЄЄхЁэ, ёючфрээ√щ т ьєч√ъры№эюь ЁхфръЄюЁх Pro Tracker 3.
+		╬Є лpattern╗ (лярЄЄхЁэ╗). 
+ + + + + +
3)лsetup.p╗ Ч Їрщы ё эрёЄЁющърьш яюўЄютюую +ЁхфръЄюЁр Lara Croft.
+		 ╥хъёЄют√щ Їрщы. ╙чэрЄ№ юс юяшё√трхь√ї т э╕ь ярЁрьхЄЁрї ьюцэю +шч фюъєьхэЄрЎшш ъ Lara Croft.
+ + + + + +
4)лpost.p╗ Ч срчр фрээ√ї яюўЄютюую ЁхфръЄюЁр Lara +Croft (хёыш тё  срчр эх єьх∙рхЄё  т юфэюь Їрщых, Єю эр фшёъх +сєфхЄ эхёъюы№ъю Їрщыют лpost.p╗).
+		 ├фх эрщЄш юяшёрэшх ЇюЁьрЄр,   эх чэр■, эю т√ ьюцхЄх +яюяЁюсютрЄ№ шчєўшЄ№ шёїюфэ√х ЄхъёЄ√ Lara Croft, фюёЄєяэ√х эр ёрщЄх Open +Source ZX (http://opensourcezx.narod.ru), +ш ёрьюёЄю Єхы№эю ЁрчюсЁрЄ№ё  т ЇюЁьрЄх.
p_?╙яръютрээ√щ Їрщы. ╠хЄюф єяръютъш Ч Hrust 2.1. ╥ръющ ЇюЁьрЄ +шёяюы№чєхЄё  т яЁюуЁрььрї Quick Commander ш Real Commander.┴єътр лp╗ Ч юЄ лpacked╗ +(лєяръютрээ√щ╗), р ЄЁхЄшщ ёшьтюы Ёрё°шЁхэш  Ч ¤Єю +Ёрё°шЁхэшх шёїюфэюую Їрщыр (хёыш є шёїюфэюую Їрщыр с√ыю ЄЁ╕їёшьтюы№эюх +Ёрё°шЁхэшх, Єю ёюїЁрэ хЄё  Єюы№ъю яхЁт√щ хую ёшьтюы).╤ь. Ёрё°шЁхэшх лp╗, +яєэъЄ 1.
pcx├ЁрЇшўхёъшщ Їрщы т ЇюЁьрЄх PCX.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: PCX viewer 1.0 (by ZMAN\U.C.G.), PCX viewer +1.6 (by BrainWave), PCX Show 1.1 (by Johnny Graphics), PCX viewer +1.0 (by C.D.L. Lab), PCX converter 3.41 (by E.Kulikaev), +Brujeria 1.0 (by ALFF/RD/CPU), PCX viewer 2.04 XM (by S.F.D.) +(фы  ЁрсюЄ√ ё ¤Єющ яЁюуЁрььющ шчьхэшЄх Ёрё°шЁхэшх Їрщыр +ё лpcx╗ эр лX╗), Excess de luxe paint +PCX view utility v1.1 (by Konstantin Zuykov aka ZK +System).		╬Є лPiCture eXchange format╗. + + + + + + + + + + + + + +
1)фы  ўрёЄэюую ёыєўр  (ў/с шчюсЁрцхэшх 256x192 ё ярышЄЁющ тшфр +0,0,0, 1,1,1, Е, 255,255,255) эхяюыэюх юяшёрэшх ЇюЁьрЄр ьюцэю эрщЄш +т ьюхщ ёЄрЄ№х л┬√тюф +ў╕Ёэю-схы√ї шчюсЁрцхэшщ ё уЁрфрЎш ьш  ЁъюёЄш╗ +(л╨рфшюьшЁ. ┬р° ъюья№■ЄхЁ╗ 8Ч10/2002). ╥рь цх яЁштхфхэ√ +яЁюЎхфєЁ√ эр рёёхьсыхЁх Z80 фы  ЁрсюЄ√ ё Єръшьш +pcx-Їрщырьш.
2)http://forum.alpe.ru, Ёрчфхы +л╘юЁьрЄ√ Їрщыют╗, Єхьр лZSoft PCX File Format╗.
3)http://www.codenet.ru/progr/formt/pcx1.php
+
phtHTML-Їрщы.
+╧ЁюуЁрььр фы  яЁюёьюЄЁр: BestView, эрўшэр  ё тхЁёшш 2.17 (юэр +яЁхюсЁрчєхЄ HTML т ЄхъёЄ).		╨рё°шЁхэшх лphtml╗, юсЁхчрээюх фю ЄЁ╕ї ёшьтюыют.╤ь. Ёрё°шЁхэшх лhtm╗.
PKT, pkt╧юўЄют√щ яръхЄ.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: ZED, Lara Croft.		╬Є лpacket╗ (ляръхЄ╗). + + + + + + + + + + + + + +
1)Randy Bush. УA Basic FidoNetо Technical StandardФ (http://www.ftsc.org/download/docs/fts-0001.016).
2)http://www.google.ru/groups?hl=ru&lr=&ie=
+UTF-8&inlang=ru&selm=918296780%40p2.f1331.
+n5020.z2.ftn (Єрь ьюцэю эрщЄш юяшёрэш  ёЄЁєъЄєЁ фрээ√ї фы  ЁрсюЄ√ +ё pkt-Їрщырьш эр ╤ш ш ╧рёърых).
3)ёь. ¤ыхъЄЁюээє■ урчхЄє Body #22.
+
PLC, plc╩рЁЄшэър, єяръютрээр  яю ьхЄюфє Laser Compact 5.2, +схч Ёрёяръют∙шър.┬шфшью, лp╗ Ч юЄ лpacked╗, +р лlc╗ Ч юЄ лLaser Compact╗. + + + + + + + + + +
1)фюъєьхэЄрЎш  ъ Laser Compact 5.2.
2)Alone Coder. лLC 4.0 ш 5.2╗. ▌ыхъЄЁюээ√щ цєЁэры +Inferno #5. ╥ръцх ¤Єр ёЄрЄ№  фюёЄєяэр эр ёрщЄх http://zxdocs.fatal.ru, т Ёрчфхых +лFormats╗ (рЁїшт лLC4-5.zip╗).
+
PPS╧рЄЄхЁэ, ёючфрээ√щ т ьєч√ъры№эюь ЁхфръЄюЁх Pro Sound Creator.лP╗ Ч юЄ лpattern╗ +(лярЄЄхЁэ╗), чрЄхь лPS╗ Ч юЄ эрчтрэш  +ЁхфръЄюЁр. 
psc╠єч√ъры№э√щ ьюфєы№ т ЇюЁьрЄх ЁхфръЄюЁр Pro Sound Creator, +ъюьяшышЁютрээ√щ схч яыххЁр.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лpsc╗ фы  Єръшї ьюфєыхщ +яЁшэ Єю т яыххЁх AY Emulator, р т Pro Sound +Creator шёяюы№чєхЄё  Ёрё°шЁхэшх лMPS╗.		╬Є эрчтрэш  ЁхфръЄюЁр.╤ь. Ёрё°шЁхэшх лMPS╗.
pt1╠єч√ъры№э√щ ьюфєы№ т ЇюЁьрЄх ЁхфръЄюЁр Pro Tracker 1.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лpt1╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator.		╬Є эрчтрэш  ЁхфръЄюЁр.├фх эрщЄш юяшёрэшх ЇюЁьрЄр,   эх чэр■, эю ьюує яюёютхЄютрЄ№ +яюёьюЄЁхЄ№ шёїюфэ√х ЄхъёЄ√ ьєч√ъры№эюую ЁхфръЄюЁр Vortex Tracker II +фы  PC (юэш фюёЄєяэ√ эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗). ╧юёьюЄЁхт т Їрщых лtrfuncs.pas╗, +ъръ яЁюшёїюфшЄ шьяюЁЄшЁютрэшх pt1-ьюфєыхщ яЁш шї чруЁєчъх +т ЁхфръЄюЁ, ьюцэю яюяЁюсютрЄ№ ЁрчюсЁрЄ№ё  т шї ЇюЁьрЄх. ╥ръцх, +тючьюцэю, юърцхЄё  яюыхчэ√ь ЄхъёЄ фшчрёёхьсышЁютрээюую юЁшушэры№эюую яыххЁр +pt1-ьюфєыхщ Ч юэ фюёЄєяхэ эр Єюь цх +ёрщЄх (рЁїшт лPT1Player.rar╗).
pt2╠єч√ъры№э√щ ьюфєы№ т ЇюЁьрЄх ЁхфръЄюЁр Pro Tracker 2, +ъюьяшышЁютрээ√щ схч яыххЁр.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лpt2╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator, р т Pro Tracker 2 шёяюы№чєхЄё  +Ёрё°шЁхэшх лM╗.		╬Є эрчтрэш  ЁхфръЄюЁр.╤ь. Ёрё°шЁхэшх лM╗, +яєэъЄ 2.
pt3╠єч√ъры№э√щ ьюфєы№ т ЇюЁьрЄх ЁхфръЄюЁр Pro Tracker 3, +ъюьяшышЁютрээ√щ схч яыххЁр. ╠юфєы№ ьюцхЄ с√Є№ эряшёрэ т ЁхфръЄюЁх +Vortex Tracker II.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лpt3╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яЁюуЁрььрї AY Emulator ш Vortex Tracker II, +р т Pro Tracker 3 шёяюы№чєхЄё  Ёрё°шЁхэшх лm╗. +─ы  чруЁєчъш т Pro Tracker 3 ьюфєы  ё Ёрё°шЁхэшхь +лpt3╗ эрфю шёяюы№чютрЄ№ яєэъЄ лDecompiler╗ +(яЁш чруЁєчъх ўхЁхч лDisk Options╗ ЁхфръЄюЁ ю°шсюўэю +ЁрёяючэрхЄ pt3-Їрщы ъръ ярЄЄхЁэ, Єръ ъръ яхЁтр  сєътр +Ёрё°шЁхэш  Ч лp╗).		╬Є эрчтрэш  ЁхфръЄюЁр.╤ь. Ёрё°шЁхэшх лm╗. ┼ёыш ьюфєы№ +эряшёрэ т Vortex Tracker II, Єю т эрўрых ьюфєы  тьхёЄю +ёЄЁюъш лProTracker 3.x compilation of ╗ (уфх +x Ч эюьхЁ яюфтхЁёшш) ьюцхЄ с√Є№ ёЄЁюър лVortex +Tracker II 1.0 module: ╗ шыш лVortex +Tracker II 1.0a module:╗.
ptn╧рЄЄхЁэ, ёючфрээ√щ т ьєч√ъры№эюь ЁхфръЄюЁх Global Tracker.╬Є лpattern╗ (лярЄЄхЁэ╗). 
PVD╙яръютрээ√х фрээ√х яЁюхъЄр фы  яЁюуЁрьь√ Video Studio.лP╗ Ч юЄ лpacked╗ +(лєяръютрээ√щ╗), лV╗ Ч +юЄ лVideo╗, р лD╗ Ч +юЄ лdata╗ (лфрээ√х╗). 


Q

+qht +
qht╘рщы Quick HyperText.╬Є лQuick HyperText╗.╤ь. фюъєьхэЄрЎш■ ъ ёшёЄхьх Quick HyperText, р Єръцх чфхё№: +http://zxdocs.fatal.ru, Ёрчфхы +лFormats╗ (рЁїшт лqht.zip╗).


R

+R   +r   +rar   +RCM   +red   +rgb   +rzx   +rom +
R╚ёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т ЇюЁьрЄх рёёхьсыхЁр +STORM 1.2d.┬ючьюцэю, юЄ сєът√ лR╗ т эрчтрэшш рёёхьсыхЁр. 
r╩Ёрёэр  ёюёЄрты ■∙р  3-color screen.╬Є лred╗ (лъЁрёэ√щ╗).╧ЁхфёЄрты хЄ ёюсющ ¤ъЁрээ√щ Їрщы схч рЄЁшсєЄют. ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.
rar└Ёїшт RAR.
+╧ЁюуЁрььр фы  юсЁрсюЄъш: UNRAR 0.57.		╬Є эрчтрэш  рЁїштрЄюЁр. +
+ + + + + + + + + +
1)ёь. Їрщы лTechNote.txt╗ шч ъюьяыхъЄр яюёЄртъш +WinRAR.
2)Alone Coder. л╨рёъЁєўштрхь RAR╗. ▌ыхъЄЁюээ√щ цєЁэры +Inferno #4. ▌Єр ёЄрЄ№  Єръцх фюёЄєяэр эр ёрщЄх http://zxdocs.fatal.ru, т Ёрчфхых +лFormats╗ (рЁїшт лRAR2_x.zip╗).
+
+

╥ръцх ё юЇшЎшры№эюую ёрщЄр (www.rarlab.com) ьюцэю ёърўрЄ№ шёїюфэ√х ЄхъёЄ√ +Ёрёяръют∙шър эр C++. └ т ъюьяыхъЄ яюёЄртъш ёяхъЄЁєьютёъюую +UNRARТр тїюф Є шёїюфэ√х ЄхъёЄ√ Ёрёяръют∙шър эр рёёхьсыхЁх +Z80.

RCM╠юфєы№ фы  Real Commander.┬шфшью, ёюъЁр∙хэшх юЄ лReal Commander Module╗.╤ь. фюъєьхэЄрЎш■ ъ Real Commander.
red╩Ёрёэр  ёюёЄрты ■∙р  3-color screen (Їрщы√ ё Єръшь +Ёрё°шЁхэшхь ёючфр■Єё  яЁюуЁрььющ JPEG/GIF laboratory).╬Є лred╗ (лъЁрёэ√щ╗).╧ЁхфёЄрты хЄ ёюсющ ¤ъЁрээ√щ Їрщы схч рЄЁшсєЄют. ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.
rgb3-color screen.лr╗ Ч юЄ лred╗ +(лъЁрёэ√щ╗), лg╗ Ч +юЄ лgreen╗ (лчхыхэ√щ╗), +лb╗ Ч юЄ лblue╗ +(лёшэшщ╗).╥Ёш ¤ъЁрээ√ї Їрщыр схч рЄЁшсєЄют, юфшэ чр фЁєушь: ёэрўрыр +ъЁрёэр  ёюёЄрты ■∙р  шчюсЁрцхэш , яюЄюь чхы╕эр  ш ёшэ  . ╬ ЇюЁьрЄх +¤ъЁрээюую Їрщыр Ч ёь. Ёрё°шЁхэшх лscr╗.
rzx└Ёїшт RAR, ёючфрээ√щ ёяхъЄЁєьютёъющ яЁюуЁрььющ RARDEMO.лr╗ Ч юЄ лRAR╗, +лzx╗ Ч юЄ лZX Spectrum╗.╤ь. Ёрё°шЁхэшх лrar╗.
rom╤юфхЁцшьюх ╧╟╙.╬Є рссЁхтшрЄєЁ√ лROM╗ (л╧╟╙╗).─тюшўэ√щ Їрщы.


S

+S   +s   +sa0, sa1, Е   +sat   +scl   +SCR, scr   +sht   +skn   +sna   +spr   +sqt   +stc   +stp   +su0, su1, Е +
S + + + + + +
1)ьєч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Sound Tracker.
+		╬Є эрчтрэш  ЁхфръЄюЁр.╤ь. фюъєьхэЄ лSOUNDTRACKER TECHNICAL +REFERENCE╗ Ч хую ьюцэю эрщЄш эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗ (рЁїшт лSTDocs.rar╗).
+ + + + + +
2)эрсюЁ ёяЁрщЄют, ёючфрээ√щ т уЁрЇшўхёъюь ЁхфръЄюЁх Burial Gfx +Editor.
+		╬Є лsprite╗ (лёяЁрщЄ╗).├фх эрщЄш юяшёрэшх ЇюЁьрЄр,   эх чэр■, эю т√ ьюцхЄх +яюяЁюсютрЄ№ шчєўшЄ№ шёїюфэ√х ЄхъёЄ√ BGE 3.05, фюёЄєяэ√х эр ёрщЄх +Open Source ZX (http://opensourcezx.narod.ru), +ш ёрьюёЄю Єхы№эю ЁрчюсЁрЄ№ё  т ЇюЁьрЄх.
+ + + + + +
3)шчюсЁрцхэшх, ёючфрээюх т уЁрЇшўхёъюь ЁхфръЄюЁх 8 color +editor.
+		 ╤ь. фюъєьхэЄрЎш■ ъ 8 color editor.
s╤¤ьяы фы  юфэюую шч ьєч√ъры№э√ї ЁхфръЄюЁют: Pro Tracker 2, +Global Tracker, Digital Music Maker, Sound Tracker, Sound Tracker Pro, Pro +Tracker 3.╬Є лsample╗ (лё¤ьяы╗).╙ ърцфюую ЁхфръЄюЁр ётющ ЇюЁьрЄ.
+─ы  Pro Tracker 3: яхЁт√х 256 срщЄют Їрщыр Ч фрээ√х +фы  ърцфющ шч 64 яючшЎшщ ё¤ьяыр, яю 4 срщЄр эр яючшЎш■: +яхЁт√х 2 срщЄр Ч ёьх∙хэшх ўрёЄюЄ√ (яюыюцшЄхы№эюх Ч тэшч, +юЄЁшЎрЄхы№эюх Ч ттхЁї, ьырф°шщ срщЄ їЁрэшЄё  яхЁт√ь), ёыхфє■∙шщ +срщЄ: 7-щ ЁрчЁ ф Ч ьрёър Єюэр (0 Ч хёЄ№, +1 Ч эхЄ), 6-щ ЁрчЁ ф Ч ьрёър °єьр +(0 Ч хёЄ№, 1 Ч эхЄ), 5-щ ЁрчЁ ф Ч +ьрёър юушср■∙хщ (0 Ч хёЄ№, 1 Ч эхЄ), ьырф°шх 5 +ЁрчЁ фют Ч ўрёЄюЄр °єьр шыш, хёыш ьрёър °єьр Ёртэр 1, ёьх∙хэшх +(ёю чэръюь) ўрёЄюЄ√ юушср■∙хщ (яюыюцшЄхы№эюх Ч тэшч, +юЄЁшЎрЄхы№эюх Ч ттхЁї). ╤ыхфє■∙шщ срщЄ: 7-щ +ЁрчЁ ф Ч яЁшчэръ ёьх∙хэш  уЁюьъюёЄш (1 Ч фр, 0 Ч +эхЄ), 6-щ ЁрчЁ ф Ч эряЁртыхэшх ёьх∙хэш  уЁюьъюёЄш +(1 Ч єтхышўхэшх, 0 Ч єьхэ№°хэшх), 5-щ +ЁрчЁ ф Ч яЁшчэръ лчряюьэшЄ№ ёьх∙хэшх уЁюьъюёЄш╗ +(1 Ч фр, 0 Ч эхЄ), 4-щ ЁрчЁ ф Ч +яЁшчэръ лчряюьэшЄ№ ёьх∙хэшх ўрёЄюЄ√ °єьр/юушср■∙хщ╗ (1 Ч +фр, 0 Ч эхЄ), ьырф°шх 4 ЁрчЁ фр Ч уЁюьъюёЄ№. ╧юёых фрээ√ї +ю яючшЎш ї їЁрэшЄё  1 срщЄ Ч эюьхЁ яючшЎшш эрўрыр Ўшъыр +(ёўшЄр  ё 0) ш 1 срщЄ Ч ъюышўхёЄтю шёяюы№чєхь√ї яючшЎшщ +т ё¤ьяых (хёыш єьхэ№°шЄ№ хую эр 1, яюыєўшь эюьхЁ яючшЎшш ъюэЎр +Ўшъыр, ёўшЄр  ё 0).
sa0, sa1, Е└Ёїшт ё яюўЄют√ьш яръхЄрьш, ёЇюЁьшЁютрээ√щ т ёєссюЄє.╧хЁт√х фтр ёшьтюыр Ч юЄ лSaturday╗ +(лёєссюЄр╗), ЄЁхЄшщ ёшьтюы Ч эюьхЁ Їрщыр (эрўшэр  +ё 0).╘юЁьрЄ рЁїштр чртшёшЄ юЄ шёяюы№чютрээюую рЁїштрЄюЁр. ╘юЁьрЄ яюўЄют√ї +яръхЄют (pkt-Їрщыют) Ч ёь. Ёрё°шЁхэшх +лpkt╗.
sat╧Ёюфюыцхэшх фышээюую img-Їрщыр, ёючфрээюую яЁюуЁрььющ JPEG +Convertor (ёь. Ёрё°шЁхэшх лimg╗, +яєэъЄ 2).╬Є лsatellite╗ (лёяєЄэшъ╗).╧ЁюёЄю ўрёЄ№ Їрщыр, схч фюяюыэшЄхы№эющ ёыєцхсэющ шэЇюЁьрЎшш.
scl╘рщы-лъюэЄхщэхЁ╗, ёюфхЁцр∙шщ юфшэ шыш эхёъюы№ъю +Їрщыют TR-DOS.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: File Extractor, SCL 0.1.		╬Є лSinclair╗. + + + + + + + + + + + + + +
1)ёь. фюъєьхэЄрЎш■ ъ яЁюуЁрььх AMD Copier 0.01 фы  PC +(эрщЄш х╕ ьюцэю эр ёрщЄх Virtual TR-DOS Ч http://zx.da.ru).
2)ёь. FAQ ъюэЇхЁхэЎшш ZX.SPECTRUM.
3)ёь. Їрщы лDOCS\SCL.HDR╗ шч ъюьяыхъЄр яюёЄртъш +яЁюуЁрьь√ ZX Spectrum Navigator фы  PC (эрщЄш х╕ ьюцэю +эр ёрщЄх http://sn.nnov.ru).
+
SCR, scr▌ъЁрээ√щ Їрщы Ч ъюяш  ёюфхЁцшьюую ¤ъЁрээющ ярь Єш +ZX Spectrum (#1B00=6912 срщЄют, шыш #1800=6144 срщЄр Ч +схч рЄЁшсєЄют).╬Є лscreen╗ (л¤ъЁрэ╗).╬ ёЄЁєъЄєЁх ¤ъЁрээющ ярь Єш ьюцэю яЁюўшЄрЄ№, эряЁшьхЁ, т ъэшух +л╧хЁёюэры№э√щ ъюья№■ЄхЁ ДZX-SpectrumУ. +▌ыхьхэЄрЁэр  уЁрЇшър╗ (╠юёътр, л╚эЇюЁъюь╗, 1992). ▌Єр ъэшур +т ¤ыхъЄЁюээюь тшфх фюёЄєяэр эр ёрщЄх Virtual TR-DOS (http://zx.da.ru).
shtHTML-Їрщы.
+╧ЁюуЁрььр фы  яЁюёьюЄЁр: BestView, эрўшэр  ё тхЁёшш 2.17 (юэр +яЁхюсЁрчєхЄ HTML т ЄхъёЄ).		╨рё°шЁхэшх лshtml╗, юсЁхчрээюх фю ЄЁ╕ї ёшьтюыют.╤ь. Ёрё°шЁхэшх лhtm╗.
skn╤ъшэ фы  яЁюёьюЄЁ∙шър Їрщыют Quick HyperText.╬Є лskin╗. 
snaSnapshot (Їрщы, т ъюЄюЁюь чряюьшэрхЄё  ёюёЄю эшх ¤ьєышЁєхьюую +л╤яхъЄЁєьр╗: ёюфхЁцшьюх ярь Єш, чэрўхэш  ЁхушёЄЁют яЁюЎхёёюЁр +ш эхъюЄюЁр  фЁєур  шэЇюЁьрЎш ).
+╧ЁюуЁрььр фы  юсЁрсюЄъш: File Extractor 1.1b.		╬Є лsnapshot╗.╬яшёрэшх ЇюЁьрЄр SNA 48K Ч ёь. фюъєьхэЄрЎш■ +ъ ¤ьєы ЄюЁє JPP; юяшёрэшх юЄышўшщ ЇюЁьрЄр SNA 128K +юЄ 48K Ч ёь. фюъєьхэЄрЎш■ ъ ¤ьєы ЄюЁє UKV (хую ьюцэю +эрщЄш, эряЁшьхЁ, эр ёрщЄх Virtual TR-DOS Ч http://zx.da.ru).
spr╤яЁрщЄ т ЇюЁьрЄх яЁюуЁрьь√ Spriter (by Studio Stall). ╘рщы√ +ё Єръшь Ёрё°шЁхэшхь ёючфр╕Є яЁюуЁрььр JPEG convertor.╬Є лsprite╗ (лёяЁрщЄ╗). 
sqt╩юьяшышЁютрээ√щ схч яыххЁр ьєч√ъры№э√щ ьюфєы№, эряшёрээ√щ +т ЁхфръЄюЁх SQ Tracker.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лsqt╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator.		╬Є эрчтрэш  ЁхфръЄюЁр.├фх эрщЄш юяшёрэшх ЇюЁьрЄр,   эх чэр■, эю ьюує яюёютхЄютрЄ№ +яюёьюЄЁхЄ№ шёїюфэ√х ЄхъёЄ√ ьєч√ъры№эюую ЁхфръЄюЁр Vortex Tracker II +фы  PC (юэш фюёЄєяэ√ эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗). ╧юёьюЄЁхт т Їрщых лtrfuncs.pas╗, +ъръ яЁюшёїюфшЄ шьяюЁЄшЁютрэшх sqt-ьюфєыхщ яЁш шї чруЁєчъх +т ЁхфръЄюЁ, ьюцэю яюяЁюсютрЄ№ ЁрчюсЁрЄ№ё  т шї ЇюЁьрЄх. ╥ръцх, +тючьюцэю, юърцхЄё  яюыхчэ√ь ЄхъёЄ фшчрёёхьсышЁютрээюую юЁшушэры№эюую яыххЁр +sqt-ьюфєыхщ Ч юэ фюёЄєяхэ эр Єюь цх +ёрщЄх (рЁїшт лSQTPlayer.rar╗).
stc╩юьяшышЁютрээ√щ схч яыххЁр ьєч√ъры№э√щ ьюфєы№, эряшёрээ√щ +т ЁхфръЄюЁх Sound Tracker шыш Super Sonic.
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лstc╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator.		┬шфшью, сєът√ лst╗ т Ёрё°шЁхэшш Ч +юЄ эрчтрэш  ЁхфръЄюЁр Sound Tracker, р лc╗ Ч +юЄ лcompiled╗ (лъюьяшышЁютрээ√щ╗).╤ь. фюъєьхэЄ лSOUNDTRACKER TECHNICAL +REFERENCE╗ Ч хую ьюцэю эрщЄш эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗ (рЁїшт лSTDocs.rar╗).
stp╩юьяшышЁютрээ√щ схч яыххЁр ьєч√ъры№э√щ ьюфєы№, эряшёрээ√щ +т ЁхфръЄюЁх Sound Tracker Pro. ┬ючьюцэю, ё фюсртыхээющ шэЇюЁьрЎшхщ +ю эрчтрэшш ш ртЄюЁх ьюфєы .
+╧Ёшьхўрэшх: Ёрё°шЁхэшх лstp╗ фы  Єръшї ьюфєыхщ яЁшэ Єю +т яыххЁх AY Emulator.		╬Є эрчтрэш  ЁхфръЄюЁр.VfNG/NEW. л╬ ЇюЁьрЄх ьєч√ъры№э√ї ьюфєыхщ Sound Tracker Pro +by KSA software╗. ▌ыхъЄЁюээр  урчхЄр Echo #3. (┬ ¤Єющ +ёЄрЄ№х яЁштюфшЄё  ш шёїюфэ√щ ЄхъёЄ яыххЁр ¤Єшї ьюфєыхщ.)
+┬√°хєърчрээр  ёЄрЄ№  Єръцх фюёЄєяэр эр ёрщЄх http://bulba.at.kz, т Ёрчфхых +л╧ЁюуЁрььшёЄє╗ (рЁїшт лSTPDocs.rar╗).
+┼ёыш т ьюфєы№ с√ыр фюсртыхэр шэЇюЁьрЎш  ю эрчтрэшш ш ртЄюЁх, Єю +яю ёьх∙хэш■ 10 юЄ эрўрыр ьюфєы  (чфхё№ ш фрыхх чэрўхэш  єърчрэ√ +т фхё Єшўэюь тшфх) эрїюфшЄё  ёЄЁюър лKSA SOFTWARE COMPILATION +OF╗, фрыхх яЁюсхы ш, эрўшэр  ёю ёьх∙хэш  38, ёыхфєхЄ +25-ёшьтюы№эр  ёЄЁюър ё шэЇюЁьрЎшхщ ю эрчтрэшш +ш ртЄюЁх ьюфєы .
su0, su1, Е└Ёїшт ё яюўЄют√ьш яръхЄрьш, ёЇюЁьшЁютрээ√щ т тюёъЁхёхэ№х.╧хЁт√х фтр ёшьтюыр Ч юЄ лSunday╗ +(лтюёъЁхёхэ№х╗), ЄЁхЄшщ ёшьтюы Ч эюьхЁ Їрщыр (эрўшэр  +ё 0).╘юЁьрЄ рЁїштр чртшёшЄ юЄ шёяюы№чютрээюую рЁїштрЄюЁр. ╘юЁьрЄ яюўЄют√ї +яръхЄют (pkt-Їрщыют) Ч ёь. Ёрё°шЁхэшх +лpkt╗.


T

+T   +t   +tab   +tap   +tcp   +th0, th1, Е   +tif   +trd   +tu0, tu1, Е   +TXT   +txt   +tzx +
T + + + + + +
1)ЄхъёЄют√щ Їрщы.
+		╬Є лtext╗ (лЄхъёЄ╗, +лЄхъёЄют√щ╗).╤ь. Ёрё°шЁхэшх лTXT╗.
+ + + + + +
2)ьєч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Digital Music +Maker шыш Instrument.
+		  
t╥хъёЄют√щ Їрщы, ёючфрээ√щ т ЁхфръЄюЁх Microeditor.╬Є лtext╗ (лЄхъёЄ╗, +лЄхъёЄют√щ╗). 
tab + + + + + +
1)ЄрсышЎр яхЁхъюфшЁютъш фы  ЄхъёЄютюую ЁхфръЄюЁр Horror +Word.
+		╬Є лtable╗ (лЄрсышЎр╗). 
+ + + + + +
2)лt_mac.tab╗ Ч ЄрсышЎр ьръЁюёют фы  ютхЁых  +лmacro.ovl╗ ъ рёёхьсыхЁє +ZX ASM 3.10.
+
tap╬сЁрч ьруэшЄюЇюээющ ыхэЄ√.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: TAP2DISK, +TAP 0.3, File Extractor.		╬Є лtape╗ (лыхэЄр╗). + + + + + + + + + +
1)ёь. фюъєьхэЄрЎш■ ъ ¤ьєы ЄюЁє лZ80╗.
2)ёь. Їрщы лDOCS\TAP.HDR╗ шч ъюьяыхъЄр яюёЄртъш +яЁюуЁрьь√ ZX Spectrum Navigator фы  PC (эрщЄш х╕ ьюцэю +эр ёрщЄх http://sn.nnov.ru).
+
tcp╬тхЁыхщ фы  Turbo Commander.╧хЁт√х фтх сєът√ Ч тшфшью, юЄ эрчтрэш  яЁюуЁрьь√. 
th0, th1, Е└Ёїшт ё яюўЄют√ьш яръхЄрьш, ёЇюЁьшЁютрээ√щ т ўхЄтхЁу.╧хЁт√х фтр ёшьтюыр Ч юЄ лThursday╗ +(лўхЄтхЁу╗), ЄЁхЄшщ ёшьтюы Ч эюьхЁ Їрщыр (эрўшэр  +ё 0).╘юЁьрЄ рЁїштр чртшёшЄ юЄ шёяюы№чютрээюую рЁїштрЄюЁр. ╘юЁьрЄ яюўЄют√ї +яръхЄют (pkt-Їрщыют) Ч ёь. Ёрё°шЁхэшх +лpkt╗.
tif├ЁрЇшўхёъшщ Їрщы т ЇюЁьрЄх TIFF.
+╧ЁюуЁрььр фы  юсЁрсюЄъш: Screen Viewer 3.0 beta.		╧хЁт√х ЄЁш сєът√ рссЁхтшрЄєЁ√ лTIFF╗ (лTagged Image File +Format╗).http://forum.alpe.ru, Ёрчфхы +л╘юЁьрЄ√ Їрщыют╗, Єхьр лTag Image File Format Rev +4.0╗.
trd╬сЁрч фшёър TR-DOS.
+╧ЁюуЁрььр фы  юсЁрсюЄъш: File Extractor 1.1b.		╧хЁт√х ЄЁш сєът√ рссЁхтшрЄєЁ√ лTR-DOS╗.┬ Їрщых їЁрэшЄё  ёюфхЁцшьюх тёхї ёхъЄюЁют фшёър TR-DOS, +схч ъръющ-ышсю фюяюыэшЄхы№эющ ёыєцхсэющ шэЇюЁьрЎшш.
tu0, tu1, Е└Ёїшт ё яюўЄют√ьш яръхЄрьш, ёЇюЁьшЁютрээ√щ тю тЄюЁэшъ.╧хЁт√х фтр ёшьтюыр Ч юЄ лTuesday╗ +(лтЄюЁэшъ╗), ЄЁхЄшщ ёшьтюы Ч эюьхЁ Їрщыр (эрўшэр  +ё 0).╘юЁьрЄ рЁїштр чртшёшЄ юЄ шёяюы№чютрээюую рЁїштрЄюЁр. ╘юЁьрЄ яюўЄют√ї +яръхЄют (pkt-Їрщыют) Ч ёь. Ёрё°шЁхэшх +лpkt╗.
TXT╥хъёЄют√щ Їрщы.╬Є лtext╗ (лЄхъёЄ╗, +лЄхъёЄют√щ╗).╩рцф√щ ёшьтюы ъюфшЁєхЄё  юфэшь срщЄюь, ёюуырёэю шёяюы№чєхьющ ъюфшЁютъх +(ры№ЄхЁэрЄштэр  ъюфшЁютър DOS, Windows-1251, KOI8-R +ш Є.ф.). ┴рщЄ 9 Ч Єрсєы Ўш , яЁш яхўрЄш Їрщыр юс√ўэю +шэЄхЁяЁхЄшЁєхЄё  ъръ яхЁхьх∙хэшх ъєЁёюЁр тяЁртю эр сышцрщ°є■ яючшЎш■, +ъЁрЄэє■ 8 (яЁш эєьхЁрЎшш яючшЎшщ ё 0). ╩юф ъюэЎр ёЄЁюъш (т яюёыхфэхщ +ёЄЁюъх хую ьюцхЄ эх с√Є№) Ч шыш срщЄ 13, шыш срщЄ 10, +шыш ярЁр срщЄют 13,10. ╘рщы ьюцхЄ чрърэўштрЄ№ё  ёяхЎшры№э√ь ёшьтюыюь ъюэЎр +Їрщыр: срщЄюь 26 (яЁшэ Єю т MS-DOS) +шыш срщЄюь 3 (яЁшэ Єю т IS-DOS).
txt + + + + + +
1)юс√ўэ√щ ЄхъёЄют√щ Їрщы.
+		╬Є лtext╗ (лЄхъёЄ╗, +лЄхъёЄют√щ╗).╤ь. Ёрё°шЁхэшх лTXT╗.
+ + + + + +
2)ЄхъёЄют√щ Їрщы, ёючфрээ√щ т ЁхфръЄюЁх +ZX ASM 3.10.
+		╬Є лtext╗ (лЄхъёЄ╗, +лЄхъёЄют√щ╗).╤ь. Ёрё°шЁхэшх лzas╗.
tzx╬сЁрч ьруэшЄюЇюээющ ыхэЄ√.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш: File Extractor 1.1b, +TAP 0.3.		лt╗ Ч юЄ лtape╗ +(лыхэЄр╗), р лzx╗ Ч +юЄ лZX Spectrum╗.─юъєьхэЄрЎш  т ЇюЁьрЄх HTML: +http://www.worldofspectrum.org/TZXformat.html
+─юъєьхэЄрЎш  т ЇюЁьрЄх TXT: +ftp://ftp.worldofspectrum.org/pub/sinclair/
+formats/TZXformat113.txt.zip


U

+U +
U─тєї¤ъЁрээр  ърЁЄшэър, єяръютрээр  ё Ёрёяръют∙шъюь.┬ючьюцэю, юЄ лdoUble╗ (лфтющэющ╗). 


V

+v   +vi1   +VSP +
v┬хъЄюЁэюх шчюсЁрцхэшх, ёючфрээюх т уЁрЇшўхёъюь ЁхфръЄюЁх +Burial Gfx Editor.╬Є лvector╗ (лтхъЄюЁэ√щ╗).├фх эрщЄш юяшёрэшх ЇюЁьрЄр,   эх чэр■, эю т√ ьюцхЄх +яюяЁюсютрЄ№ шчєўшЄ№ шёїюфэ√х ЄхъёЄ√ BGE 3.05, фюёЄєяэ√х эр ёрщЄх +Open Source ZX (http://opensourcezx.narod.ru), +ш ёрьюёЄю Єхы№эю ЁрчюсЁрЄ№ё  т ЇюЁьрЄх.
vi1─рья ьшъЁюёїхь√ CMOS.
+╤ючфр╕Єё  яЁюуЁрььющ CMOS Commander.		╬Є эрчтрэш  ёютхЄёъюую рэрыюур ьшъЁюёїхь√ CMOS (512┬╚1).┬ Їрщых ёюфхЁцрЄё  чэрўхэш  тёхї 64 ЁхушёЄЁют CMOS, ърцфюх +чэрўхэшх чрэшьрхЄ юфшэ срщЄ.
VSP├ыртэ√щ Їрщы яЁюхъЄр фы  яЁюуЁрьь√ Video Studio.╬Є лVideo Studio Project╗.http://zxdocs.fatal.ru, Ёрчфхы +лFormats╗ (рЁїшт√ лVSP.ZIP╗ +ш лVSP7.zip╗).


W

+W   +wav   +we0, we1, Е   +WRD +
W╥хъёЄют√щ Їрщы, ёючфрээ√щ т ЁхфръЄюЁх ZX Word +шыш Modern Word.╬Є эрчтрэш  ЁхфръЄюЁр.╤ь. Ёрё°шЁхэшх лTXT╗.
wav╟тєъютющ Їрщы т ЇюЁьрЄх WAV.
+╧ЁюуЁрььр фы  юсЁрсюЄъш: WAV Player.		╬Є лwave╗ (лтюыэр╗). + + + + + + + + + + + + + +
1)http://forum.alpe.ru, Ёрчфхы +л╘юЁьрЄ√ Їрщыют╗, Єхьр лWAVE File Format╗.
2)ёь. ёЄрЄ№■ л╬яшёрэшх ЇюЁьрЄют чтєъют√ї Їрщыют т√сюЁюъ +(ё¤ьяыют)╗ т ¤ыхъЄЁюээюь цєЁэрых Inferno #1.
3)http://www.codenet.ru/progr/formt/rawsam.php
+
we0, we1, Е└Ёїшт ё яюўЄют√ьш яръхЄрьш, ёЇюЁьшЁютрээ√щ т ёЁхфє.╧хЁт√х фтр ёшьтюыр Ч юЄ лWednesday╗ +(лёЁхфр╗), ЄЁхЄшщ ёшьтюы Ч эюьхЁ Їрщыр (эрўшэр  +ё 0).╘юЁьрЄ рЁїштр чртшёшЄ юЄ шёяюы№чютрээюую рЁїштрЄюЁр. ╘юЁьрЄ яюўЄют√ї +яръхЄют (pkt-Їрщыют) Ч ёь. Ёрё°шЁхэшх +лpkt╗.
WRD╥хъёЄют√щ Їрщы.╬Є лword╗.╤ь. Ёрё°шЁхэшх лTXT╗.


X

+X   +x   +XAS, xAS   +XaS, xaS +
X├ЁрЇшўхёъшщ Їрщы т ЇюЁьрЄх PCX.
+╧ЁюуЁрьь√ фы  юсЁрсюЄъш Ч ёь. Ёрё°шЁхэшх +лpcx╗.		┬шфшью, юЄ сєът√ лX╗ т эрчтрэшш ЇюЁьрЄр.╤ь. Ёрё°шЁхэшх лpcx╗.
x╤црЄ√щ уЁрЇшўхёъшщ Їрщы т ЇюЁьрЄх PCX.
+─ы  яЁюёьюЄЁр шёяюы№чєщЄх PCX viewer 2.04 XM +(by S.F.D.).		┬шфшью, юЄ сєът√ лX╗ т эрчтрэшш ЇюЁьрЄр. 
XAS, xAS╚ёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т ЇюЁьрЄх рёёхьсыхЁр XAS.╬Є эрчтрэш  рёёхьсыхЁр.╤ь. фюъєьхэЄрЎш■ ъ рёёхьсыхЁє XAS. ┬ фюяюыэхэшх ъ ¤Єющ +фюъєьхэЄрЎшш яЁштюцє ёяшёюъ Єюъхэют (юэш ъюфшЁє■Єё  срщЄрьш #80Ч#F6): +LDIR, LDDR, LDI, LDD, CPIR, CPDR, CPI, CPD, INIR, INDR, INI, IND, OUTI, OTIR, +OUTD, OTDR, RETI, RETN, NEG, RLD, RRD, PUSH, POP, ADD, SUB, ADC, SBC, AND, OR, +XOR, CP, INC, DEC, BIT, RES, SET, RLC, RRC, RL, RR, SLA, SRA, SLI, SRL, LD, +EX, IN, OUT, IM, RST, DJNZ, JP, JR, CALL, RET, EXX, CPL, DAA, RLCA, RRCA, RLA, +RRA, NOP, HALT, DI, EI, SCF, CCF, ORG, ENT, EQU, WORK, DB, DW, DM, DS, !ASSM, +!CONT, LTEXT, LCODE, BC, DE, HL, IX, IY, SP, AF, (C), B, C, D, E, H, L, (HL), +A, (BC), (DE), HX, LX, HY, LY, I, R, NZ, Z, NC, PO, PE, P, M, !ON, !OFF, (SP), +AF', USEL, IFNZ, IFZ, MAKE.
XaS, xaS╠ръЁюё√ фы  рёёхьсыхЁр XAS.╬Є эрчтрэш  рёёхьсыхЁр.


Y

+Y +
Y + + + + + +
1)ьєч√ъры№э√щ ьюфєы№, ёючфрээ√щ т ЁхфръЄюЁх Fast +Tracker.
+		 ╤ь. Ёрё°шЁхэшх лftc╗
+ + + + + +
2)RGB-¤ъЁрэ, єяръютрээ√щ ё Ёрёяръют∙шъюь.
+		  


Z

+z80   +zas   +ZIP   +zip   +zxz +
z80Snapshot (Їрщы, т ъюЄюЁюь чряюьшэрхЄё  ёюёЄю эшх ¤ьєышЁєхьюую +л╤яхъЄЁєьр╗: ёюфхЁцшьюх ярь Єш, чэрўхэш  ЁхушёЄЁют яЁюЎхёёюЁр +ш эхъюЄюЁр  фЁєур  шэЇюЁьрЎш ).
+╧ЁюуЁрььр фы  юсЁрсюЄъш: RUN .Z80 0.1.		╬Є эрчтрэш  ¤ьєы ЄюЁр лZ80╗, т ъюЄюЁюь шёяюы№чєхЄё  +¤ЄюЄ ЇюЁьрЄ. + + + + + + + + + +
1)ёь. фюъєьхэЄрЎш■ ъ ¤ьєы ЄюЁє лZ80╗.
2)ёь. Їрщы лDOCS\Z80.HDR╗ шч ъюьяыхъЄр яюёЄртъш +яЁюуЁрьь√ ZX Spectrum Navigator фы  PC (эрщЄш х╕ ьюцэю +эр ёрщЄх http://sn.nnov.ru).
+
zas╚ёїюфэ√щ ЄхъёЄ рёёхьсыхЁэющ яЁюуЁрьь√ т ЇюЁьрЄх рёёхьсыхЁр +ZX ASM 3.10.╬Є эрчтрэш  рёёхьсыхЁр.

╘юЁьрЄ яюїюц эр ЄхъёЄют√щ. ╬Єышўшх т Єюь, ўЄю срщЄ 6, +чр ъюЄюЁ√ь ёыхфєхЄ срщЄ x, юсючэрўрхЄ xЦ#80 +яЁюсхыют, р юфшэ шч срщЄют 2, 3, 4, 5, чр ъюЄюЁ√ь ёыхфєхЄ +срщЄ x, юсючэрўрхЄ Єюъхэ ё эюьхЁюь xЦ#20 (хёыш +эєьхЁютрЄ№ Єюъхэ√ ё 0), яЁшў╕ь юЄ чэрўхэш  срщЄр яхЁхф x +чртшёшЄ ёяюёюс т√тюфр ¤Єюую Єюъхэр: хёыш срщЄ Ёртхэ 2 шыш 4 (Є.х. +0-щ сшЄ ёсЁю°хэ), Єюъхэ т√тюфшЄё  ёЄЁюўэ√ьш сєътрьш, +р хёыш 3 шыш 5 (Є.х. 0-щ сшЄ +єёЄрэютыхэ) Ч яЁюяшёэ√ьш; хёыш срщЄ Ёртхэ 4 шыш 5 (Є.х. +1-щ сшЄ ёсЁю°хэ), Єюъхэ т√тюфшЄё  ё яЁюсхыюь яюёых эхую, +р хёыш 2 шыш 3 (Є.х. 1-щ сшЄ +єёЄрэютыхэ) Ч схч яЁюсхыр.

+

╤яшёюъ Єюъхэют: LD, EX, IM, RST, RET, ADD, ADC, SUB, SBC, AND, XOR, OR, CP, +PUSH, POP, INC, DEC, IN, OUT, JP, CALL, JR, DJNZ, RLC, RRC, RL, RR, SLA, SRA, +SLI, SRL, BIT, RES, SET, NOP, HALT, DI, EI, RLCA, RLA, RRCA, RRA, EXX, DAA, +CPL, CCF, SCF, LDI, LDIR, LDD, LDDR, CPI, CPIR, CPD, CPDR, NEG, INF, INI, +INIR, IND, INDR, OUTI, OTIR, OUTD, OTDR, RETI, RETN, RLD, RRD, ORG, EQU, DB, +DW, DS, DEFB, DEFW, DEFS, INSERT, INCLUDE, IF, IFDEF, IFNDEF, IFUSED, IFNUSED, +ELSE, ENDIF, MAKE, B, C, D, E, H, L, (HL), A, XH, XL, YH, YL, (IX, (IY, (BC), +(DE), I, R, AF, BC, DE, HL, IX, IY, SP, (SP), AF', (C), NZ, Z, NC, C, PO, +PE, P, M, PHASE, UNPHASE, DC, ENT, REPEAT, ENDR, LOADTAB, MACRO, ENDM, CREATE, +MAKELAB, SAVEOBJ, EXITM, IFP, EXA, RETZ, RETNZ, RETC, RETNC, RETM, RETP, +RETPO, RETPE, JPZ, JPNZ, JPC, JPNC, JPM, JPP, JPPO, JPPE, CALLZ, CALLC, CALLM, +CALLPE, CALLNZ, CALLNC, CALLP, CALLPO, JRZ, JRNZ, JRC, JRNC.

+
ZIP└Ёїшт ZXZIP.╬Є эрчтрэш  рЁїштрЄюЁр.╤ь. Їрщы лDOCS\ZXZIP.HDR╗ шч ъюьяыхъЄр яюёЄртъш +яЁюуЁрьь√ ZX Spectrum Navigator фы  PC (эрщЄш х╕ ьюцэю эр ёрщЄх +http://sn.nnov.ru). ╥ръцх єърчрээ√щ Їрщы +фюёЄєяхэ эр ёрщЄх http://zxdocs.fatal.ru, т Ёрчфхых +лFormats╗ (рЁїшт лZXZIP.ZIP╗).
zip└Ёїшт PKZIP.
+╧ЁюуЁрььр фы  юсЁрсюЄъш: pkUNZIP 1.41 Fast. ┼ёыш эєцэю Єюы№ъю яюёьюЄЁхЄ№ +юуыртыхэшх рЁїштр, Єю ¤Єю ьюцэю ёфхырЄ№ ё яюью∙№■ BestView.
+(╧Ёшьхўрэшх: ьюцхЄ тёЄЁхЄшЄ№ё  ш рЁїшт ZXZIP ё Єръшь +Ёрё°шЁхэшхь.)		╬Є эрчтрэш  рЁїштрЄюЁр.─юъєьхэЄрЎш  т ЇюЁьрЄх HTML: +http://www.pkware.com/products/enterprise/
+white_papers/appnote.html
+─юъєьхэЄрЎш  т ЇюЁьрЄх TXT: +http://www.pkware.com/products/enterprise/
+white_papers/appnote.txt +
zxz└Ёїшт ZXZIP (т MS-DOS ш IS-DOS +¤Єш рЁїшт√ ўрёЄю їЁрэ Єё  шьхээю ё Єръшь Ёрё°шЁхэшхь). ╧хЁхф +ЁрёъЁ√Єшхь рЁїштр эр ZX Spectrum эрфю шчьхэшЄ№ хую Ёрё°шЁхэшх +эр лZIP╗, р хёыш рЁїшт фышээхх 255 ёхъЄюЁют, Є.х. хёЄ№ +Їрщы√-яЁюфюыцхэш , Єю шї эрфю яхЁхшьхэютрЄ№ +т л********.ZIP╗.╬Є эрчтрэш  рЁїштрЄюЁр.╤ь. Ёрё°шЁхэшх лZIP╗.
+
+ +

╙яюь эє ю фЁєушї шёЄюўэшърї, т ъюЄюЁ√ї ьюцэю эрщЄш шэЇюЁьрЎш■ ю +Ёрё°шЁхэш ї Їрщыют ш/шыш ю ЇюЁьрЄрї фрээ√ї, шёяюы№чєхь√ї эр яырЄЇюЁьх ZX +Spectrum.

+

1. FAQ ъюэЇхЁхэЎшш ZX.SPECTRUM.

+

2. ╨рчфхы лFormats╗ эр ёрщЄх http://zxdocs.fatal.ru.

+

3. ╩рЄхуюЁш  л╘юЁьрЄ√ фрээ√ї╗ эр ёрщЄх http://zx.org.ru.

+

4. ╨рчфхы л╤ЄрэфрЁЄ√╗ эр web-ёЄЁрэшЎх http://kampi.bancorp.ru/project/zx/.

+ +
+ + +
+

─Ёєушх ьюш ёЄрЄ№ш ю TR-DOS:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1. 

л─юёЄєя ъ +яюЁЄє #1F т TR-DOS 5.03╗. +лZX-╨хт■╗ 1Ч2/1997.

2. 

л╬ ёюъЁр∙хэшш +тЁхьхэш ЇюЁьрЄшЁютрэш ╗. лZX-╨хт■╗ +1Ч2/1997.

3. 

лTR-DOS: ъръ эх фюяєёЄшЄ№ +ю°шсъш?╗. лZX-╨хт■╗ +5Ч6/1997.

4. 

л╨рсюЄр ё фшёъюь яЁш тъы■ў╕ээ√ї +яЁхЁ√трэш ї╗. Adventurer #9, л╫╕Ёэр  +тюЁюэр╗ #3, л╨рфшюы■сшЄхы№. ┬р° ъюья№■ЄхЁ╗ 6/2000 +(фюяюыэхээр  тхЁёш ).

5. 

л┬√тюф +ЄЁ╕їёшьтюы№э√ї Ёрё°шЁхэшщ Їрщыют т юяхЁрЎшюээющ ёшёЄхьх +TR-DOS╗. л╨рфшюы■сшЄхы№. ┬р° ъюья№■ЄхЁ╗ +7/2000.

6. 

л╙ёютхЁ°хэёЄтютрээ√щ рыуюЁшЄь юяЁхфхыхэш  ёьхэ√ +фшёър╗. л╨рфшюы■сшЄхы№. ┬р° ъюья№■ЄхЁ╗ 9/2000.

7. 

л╬сЁєсрхь +Їрщырь ДїтюёЄУ╗. л╨рфшюьшЁ. ┬р° ъюья№■ЄхЁ╗ +4/2002.

8. 

л╚ёяюы№чютрэшх шчс√Єюўэющ шэЇюЁьрЎшш фы  чр∙шЄ√ +Їрщыют юЄ яютЁхцфхэшщ╗. л╨рфшюьшЁ. ┬р° ъюья№■ЄхЁ╗ +11/2002.

9. 

л╧ЁютхЁър ъюЁЁхъЄэюёЄш Їрщыютющ ёЄЁєъЄєЁ√ фшёъют +TR-DOS╗. л╨рфшюьшЁ. ┬р° ъюья№■ЄхЁ╗ +6/2004.

+
+
+
+ +
+ + +
+╤ЄЁрэшЎр ╚трэр ╨ю∙шэр > +╤ЄрЄ№ш > +
+
+ + + + \ No newline at end of file diff --git a/Docs/SPECTRUM.CFG b/Docs/SPECTRUM.CFG new file mode 100644 index 0000000..ec2e18f --- /dev/null +++ b/Docs/SPECTRUM.CFG @@ -0,0 +1,11 @@ +Sprinter ZX +c:\zx\roms\SP_128.BIN +c:\zx\roms\SP__48.BIN +c:\zx\roms\SP_TRD.BIN +c:\zx\roms\SP_EXP.BIN +c:\zx\roms\SP_EXP.BIN +c:\zx\roms\SP_EXP2.BIN +/turbo /7FFD /ret-fn +; + + diff --git a/Docs/changes.txt b/Docs/changes.txt new file mode 100644 index 0000000..7ee174c --- /dev/null +++ b/Docs/changes.txt @@ -0,0 +1,5 @@ + + поддержка SCL + + мелкий рефакторинг + fix поддержка неполной дешифрации AY (Atarin запел) + fix баг с зависанием по CAD в режимах без портов спринтера (спасибо Блэйду) + \ No newline at end of file diff --git a/Docs/xFFD.txt b/Docs/xFFD.txt new file mode 100644 index 0000000..d07d9cb --- /dev/null +++ b/Docs/xFFD.txt @@ -0,0 +1,49 @@ +Pentagon & Scorpion + + #7FFD +bit0 \ +bit1 - ╨╜╨╛╨╝╨╡╤А ╤Б╤В╤А╨░╨╜╨╕╤Ж╤Л ╨Ю╨Ч╨г, ╨┐╨╛╨┤╨║╨╗╤О╤З╨╡╨╜╨╜╨╛╨╣ ╨▓ ╨▓╨╡╤А╤Е╨╜╨╕╨╡ 16 ╨Ъ╨С ╨┐╨░╨╝╤П╤В╨╕ ╤Б ╨░╨┤╤А╨╡╤Б╨░ #C000 +bit2 / + +bit3 - ╨▓╤Л╨▒╨╛╤А ╨╛╤В╨╛╨▒╤А╨░╨╢╨░╨╡╨╝╨╛╨╣ ╨▓╨╕╨┤╨╡╨╛╤Б╤В╤А╨░╨╜╨╕╤Ж╤Л. ╤Б╤В╤А╨░╨╜╨╕╤Ж╨░ 5 / ╤Б╤В╤А╨░╨╜╨╕╤Ж╨░ 7 +bit4 - ╨╜╨╛╨╝╨╡╤А ╤Б╤В╤А╨░╨╜╨╕╤Ж╤Л ╨Я╨Ч╨г. BASIC128 / BASIC48 + +bit5 \- ╨╖╨░╨┐╤А╨╡╤Й╨╡╨╜╨╕╨╡ ╤А╨░╤Б╤И╨╕╤А╨╡╨╜╨╜╨╛╨╣ ╨┐╨░╨╝╤П╤В╨╕ (48K ╨╖╨░╤Й╤С╨╗╨║╨░) ╨┐╤А╨╕ ╨▒╨╗╨╛╨║╨╕╤А╨╛╨▓╨░╨╜╨╜╨╛╨╣ ╨┐╨░╨╝╤П╤В╨╕ > 128 ╨║╨▒, ╨╕╨╜╨░╤З╨╡ ╤Б╤В╨░╤А╤И╨╕╨╣ ╨▒╨╕╤В ╨╜╨╛╨╝╨╡╤А╨░ ╤Б╤В╤А╨░╨╜╨╕╤Ж╤Л +bit6 - ╨╕╤Б╨┐╨╛╨╗╤М╨╖╤Г╤О╤В╤Б╤П ╨┐╤А╨╕ ╤А╨░╤Б╤И╨╕╤А╨╡╨╜╨╕╨╕ ╨┐╨░╨╝╤П╤В╨╕ ╨┤╨╛ 512K ╨▓ ╨▓╤Л╨▒╨╛╤А╨╡ ╨╜╨╛╨╝╨╡╤А╨░ ╤Б╤В╤А╨░╨╜╨╕╤Ж╤Л +bit7 / + + + #1FFD +bit0 тАУ ╨╛╤В╨║╤А╤Л╨▓╨░╨╡╤В ╨┤╨╛╤Б╤В╤Г╨┐ ╨╜╨░ ╤З╤В╨╡╨╜╨╕╨╡ ╨╕ ╨╖╨░╨┐╨╕╤Б╤М ╨▓ ╤Б╤В╤А╨░╨╜╨╕╤Ж╤Г RAM0 ╨╕╨╖ ╨╛╨║╨╜╨░ CPU0 (#0000-#3FFF). +bit1 тАУ ╨┐╤А╨╕ D1=1 ╨┐╨╛╨┤╤Б╤В╨░╨▓╨╗╤П╨╡╤В ╨▓ ╨╛╨║╨╜╨╛ CPU0 ╤Б╨╡╤А╨▓╨╕╤Б╨╜╤Г╤О ╤Б╤В╤А╨░╨╜╨╕╤Ж╤Г ╨╕╨╖ ╤В╨╡╨║╤Г╤Й╨╡╨│╨╛ ╨▓╤Л╨▒╤А╨░╨╜╨╜╨╛╨│╨╛ ╨▒╨░╨╜╨║╨░ ╨Я╨Ч╨г (ROM2) +bit2 - ╨╜╨╡ ╨╕╤Б╨┐╨╛╨╗╤М╨╖╤Г╨╡╤В╤Б╤П +bit3 - ╨╕╤Б╨┐╨╛╨╗╤М╨╖╤Г╨╡╤В╤Б╤П ╨║╨░╨║ ╤Б╨╕╨│╨╜╨░╨╗ ╨┐╨╡╤А╨╡╨┤╨░╤З╨╕ ╨┤╨░╨╜╨╜╤Л╤Е TxD ╨┐╤А╨╛╨│╤А╨░╨╝╨╝╨╜╨╛╨│╨╛ ╨╕╨╜╤В╨╡╤А╤Д╨╡╨╣╤Б╨░ RS232 + +bit4 - 1 - ╨┐╨╛╨┤╨║╨╗╤О╤З╨░╨╡╤В ╤Б╤В╤А╨░╨╜╨╕╤Ж╤Г ╨Ю╨Ч╨г ╨▓ ╨▒╨░╨╜╨║╤Г 3, ╨╜╨╛╨╝╨╡╤А ╤Б╤В╤А╨░╨╜╨╕╤Ж╤Л ╨▓ bit 2..0 #7FFD +bit5 - ╨╕╤Б╨┐╨╛╨╗╤М╨╖╤Г╨╡╤В╤Б╤П ╨║╨░╨║ ╤Б╨╕╨│╨╜╨░╨╗ ╨╕╨╜╤В╨╡╤А╤Д╨╡╨╣╤Б╨░ ╨┐╤А╨╕╨╜╤В╨╡╤А╨░ STROBE +bit6 - ╨╜╨╡ ╨╕╤Б╨┐╨╛╨╗╤М╨╖╤Г╨╡╤В╤Б╤П +bit7 - ╨╜╨╡ ╨╕╤Б╨┐╨╛╨╗╤М╨╖╤Г╨╡╤В╤Б╤П + + ; LD A,#E2 ; ROM-ID - BASIC 128 + ; LD B,#42 ; page + ; CALL SET_ROM + + ; LD A,#E3 ; ROM-ID - BASIC 48 + ; LD B,#43 ; page + ; CALL SET_ROM + + ; LD A,#E1 ; ROM-ID - TR-DOS + ; LD B,#44 ; page + ; CALL SET_ROM + + ; LD A,#E0 ; ROM-ID - EXPANSION + ; LD B,#45 ; page + ; CALL SET_ROM + + ; LD A,#EB ; ROM-ID - BIOS-1 + ; LD B,#46 ; page + ; CALL SET_ROM + + ; LD A,#EF ; ROM-ID - BIOS-2 + ; LD B,#47 ; page + ; CALL SET_ROM \ No newline at end of file diff --git a/macroses/accelerator.a80 b/macroses/accelerator.a80 new file mode 100644 index 0000000..f8171a6 --- /dev/null +++ b/macroses/accelerator.a80 @@ -0,0 +1,71 @@ +; Макросы акселератора для красоты)) + +;--------[выключить акселератор]-------- + MACRO ACC_Off + ld b,b + ENDM +;--------------------------------------- + +;---------[режим приема байта]---------- + MACRO ACC_SetBlockSize + ld d,d +; включает акселератор в режим приема +; байта размера блока далее следует +; команда типа LD A,dat, где dat и будет +; новым размером блока. Если размер +; блока был установлен ранее, его можно +; не устанавливать. + ENDM +;--------------------------------------- + +;-------[заполнение одним байтом]------- + MACRO ACC_FillOneByte + ld c,c +; Операция Fill. Последующая команда +; типа LD (HL),A приведет к заполнению +; указанного ранее количества байт +; значением A + ENDM +;--------------------------------------- + +;----[заполнение вертикальных линий]---- +;Операция Fill для графического экрана. + MACRO ACC_FillScreenOneByte + ld e,e +; Последующая команда типа LD (HL),A +; приведет к заполнению значением A +; вертикальных линий экрана указанным +; ранее количеством байт + ENDM +;--------------------------------------- + +;----------[копирование блока]---------- + MACRO ACC_CopyBlock + ld l,l +; Последующая команда типа LD A,(HL) +; приведет к заполнению ОЗУ акселератора +; данными из адреса (HL), а команда типа +; LD (DE),A приведет к перезаписи данных +; из ОЗУ акселератора в основное или +; видео-ОЗУ. + ENDM +;--------------------------------------- + +;---[копирование графического блока]---- + MACRO ACC_CopyScreenBlock + ld a,a +; копирование блока для граф. экрана. +; Последующая команда типа LD A,(HL) +; приведет к заполнению ОЗУ акселератора +; данными из адреса (HL), а команда типа +; LD (DE),A приведет к перезаписи данных +; из ОЗУ акселератора в видео-ОЗУ +; вертикальными линиями. + ENDM +;--------------------------------------- + +;--------------[Reserved]--------------- + MACRO ACC_Reserved + LD H,H + ENDM +;--------------------------------------- \ No newline at end of file diff --git a/macroses/macros.a80 b/macroses/macros.a80 new file mode 100644 index 0000000..b8fc631 --- /dev/null +++ b/macroses/macros.a80 @@ -0,0 +1,73 @@ +; + MACRO FRAM_ON + IN A,(FastRAM_ON) + IF Emulator + PUSH BC + PUSH AF + LD BC,#1FFD + XOR A + OUT (C),A + OUT (FastRam_BANK0),A + POP AF + POP BC + ENDIF + ENDM + + MACRO FRAM_OFF + IN A,(FastRAM_OFF) + IF Emulator + PUSH BC + PUSH AF + LD BC,#1FFD + LD A,1 + OUT (C),A + XOR A + OUT (FastRam_BANK0),A + POP AF + POP BC + ENDIF + ENDM +; +; + MACRO PrintProc + + MODULE PrintF +;--------------------------------------- +printstr: +; в рег. HL адрес на печатаемый буфер + LD C,Dss.PChars + jp ToDSS +;--------------------------------------- + +;--------------------------------------- +; в рег. A число печатаемое как hex +printhex: + LD D,A + RRCA + RRCA + RRCA + RRCA + AND #0F + ADD A,#30 + CP #3A + JR C,.PRNH1 + ADD A,7 +.PRNH1: + CALL .PRINT_CHAR + LD A,D + AND #0F + ADD A,#30 + CP #3A + JP C,.PRINT_CHAR + ADD A,7 + JP .PRINT_CHAR +; в регистре A символ для печати +.PRINT_CHAR: + LD BC,#0182 + JP ToBIOS +;--------------------------------------- + ENDMODULE + + ENDM +; +; \ No newline at end of file diff --git a/spectrum.asm b/spectrum.asm new file mode 100644 index 0000000..241c290 --- /dev/null +++ b/spectrum.asm @@ -0,0 +1,1177 @@ +/* + + .----------------. .----------------. .----------------. .----------------. .----------------. .----------------. .----------------. .----------------. + | .--------------. || .--------------. || .--------------. || .--------------. || .--------------. || .--------------. || .--------------. || .--------------. | + | | _______ | || | ______ | || | _________ | || | ______ | || | _________ | || | _______ | || | _____ _____ | || | ____ ____ | | + | | / ___ | | || | |_ __ \ | || | |_ ___ | | || | .' ___ | | || | | _ _ | | || | |_ __ \ | || ||_ _||_ _|| || ||_ \ / _|| | + | | | (__ \_| | || | | |__) | | || | | |_ \_| | || | / .' \_| | || | |_/ | | \_| | || | | |__) | | || | | | | | | || | | \/ | | | + | | '.___`-. | || | | ___/ | || | | _| _ | || | | | | || | | | | || | | __ / | || | | ' ' | | || | | |\ /| | | | + | | |`\____) | | || | _| |_ | || | _| |___/ | | || | \ `.___.'\ | || | _| |_ | || | _| | \ \_ | || | \ `--' / | || | _| |_\/_| |_ | | + | | |_______.' | || | |_____| | || | |_________| | || | `._____.' | || | |_____| | || | |____| |___| | || | `.__.' | || ||_____||_____|| | + | | | || | | || | | || | | || | | || | | || | | || | | | + | '--------------' || '--------------' || '--------------' || '--------------' || '--------------' || '--------------' || '--------------' || '--------------' | + '----------------' '----------------' '----------------' '----------------' '----------------' '----------------' '----------------' '----------------' + + */ +/* +To do: + SYS: + [ ] - задавать CONFIG_DE перед запуском спектрума и в перехватчике ресета + images: + [+] - Load SCL image + [ ] - Load TAP image + [ ] - Load SNA file +; + features: + [ ] - When image filename exist, then instead of SPECTRUM.CFG loads image_filename.cfg if exist too + [ ] - Выдавать сообщения на языке установленном в CMOS + [ ] - Менять спектрумовскую палитру +*/ + +; +; Compilation parameters +;*************************************** + DEVICE SPRINTER +; MMU 2 e, 0 ; нулевая страница в банку 2 и проверка на границы +; OUTPUT './Build/new.bin' +;*************************************** + +; +; Defines section +;*************************************** + ifndef DEBUG : define DEBUG 0 : endif + ifndef EMULATOR 0 : define EMULATOR 0 : endif + define EXE_HEADER 1 +; define NEED_LOADER 1 +; define NeedSafePort_Y 0 +;*************************************** +; + +; +; Included constants section +;*************************************** + include 'Shared_Includes/constants/sp2000.inc' + include 'Shared_Includes/constants/dss_equ.inc' + include 'Shared_Includes/constants/BIOS_equ.inc' +;*************************************** +; + +; +; Included macroses section +;*************************************** + include 'Shared_Includes/macroses/macros.z80' + include 'Shared_Includes/macroses/accelerator.z80' +;*************************************** +; + +; Included LUA section +;*************************************** + includelua +;*************************************** +; + +; +; Standart EQU section +;*************************************** +org_addr EQU #8000+CLP_Buffer +code_addr EQU BEGIN +stack_point EQU #BFFE +stack_buffer EQU 64 +program_start EQU BEGIN +;*************************************** +; + +; +; Program EQU section +;*************************************** +NAME_CFG_LINE EQU 0 +BASIC128_LINE EQU 2 +BASIC_48_LINE EQU 4 +TRDOS_LINE EQU 6 +EXP_LINE EQU 8 +BIOS_LINE EQU 10 +BIOS2_LINE EQU 12 +OPTIONS_LINE EQU 14 +;*************************************** +; + +; +; Program EQU section +;*************************************** + INCLUDE 'version.inc' +;*************************************** +; + +; +; Code start section +;[]-------------------------------------------------------------------[] + IF EXE_HEADER + include 'Shared_Includes/constants/EXE_Header.z80' + ORG org_addr + ELSE + ORG org_addr - CLP_Buffer + ENDIF + +BEGIN: + LD (LINE_X),IX + + LD HL,START_MSG + LD C,5Ch + RST ToDSS + + IN A,(SLOT3) + LD (SAVE_SLOT3),A + + JP COMAND_LINE +ERROR_FILE: + LD HL,ERROR_FILE_MSG_X + LD C,5Ch + RST ToDSS + LD HL,ONE_FILE + LD C,5Ch + RST ToDSS + + LD HL,ERROR_FILE_MSG + JP EXIT_ALL + +END_CNF_ERROR: + LD HL,ERROR_CNF +; JP EXIT_ALL +EXIT_ALL: +; PUSH HL +;---------------------[test!!!!!]------- + ; LD A,0 + ; LD C,BIOS.EMM_FN3 + ; RST ToBIOS ; освободить e: + ; LD A,(SAVE_SLOT3) + ; OUT (SLOT3),A +;--------------------------------------- + +; POP HL + LD C,Dss.PChars + RST ToDSS + +;---------------------[test!!!!!]------- + + ; ld a,(CurDisk_Save) + ; ld c,Dss.ChDisk + ; RST ToDSS + ; jr nc,1f + + ; ld hl,ERROR_FILE2_MSG + ; LD C,Dss.PChars + ; RST ToDSS +;--------------------------------------- + +1: LD BC,Dss.Exit + RST ToDSS + +COMAND_LINE: + LD HL,(LINE_X) + LD A,(HL) + AND A + JR Z,NO_FIL + DEC A + JR Z,NO_FIL + + INC HL + INC HL + + CALL FIND_FILES + + LD HL,(CNF_NAME) + LD A,Spec_Page + CALL READ_FILE_1 + JP NC,CONTINUE + +NO_FIL: + LD HL,CNF_FILE + LD A,Spec_Page + CALL READ_FILE_1 + JR C,ERROR_FILE + JP CONTINUE + +FIND_FILES: + PUSH HL + + LD (X_FILE),HL + LD DE,0 + LD (IMAGE_FLAG),DE + LD (IMAGE_NAME),DE + LD (CNF_NAME),DE + LD B,A + JR NO_NEXT + +FIND_T_LOOP: + LD A,(HL) + INC HL + CP "." + CALL Z,POINT_F + CP 20h + CALL Z,BLANK_X + CP 9 + CALL Z,BLANK_X + CP 10 + CALL Z,BLANK_X1 + CP 13 + CALL Z,BLANK_X1 + JR Z,END_NO_IMAGE + +NO_NEXT: + DJNZ FIND_T_LOOP + +END_NO_IMAGE: + POP HL + LD A,(CNF_NAME+1) + AND A + RET NZ + LD A,(IMAGE_NAME+1) + AND A + LD DE,(X_FILE) + JR Z,CNF_ALL + LD DE,CNF_FILE +CNF_ALL: + LD (CNF_NAME),DE + RET + +BLANK_X: + LD (X_FILE),HL ; найден пробел, имя файла - снова +BLANK_X1: + DEC HL + LD (HL),0 + INC HL + RET + +;------------------------------------[v] +POINT_F: + LD A,(HL) + + CP 't' + JR Z,.TRD + CP 'T' + JR Z,.TRD + + CP 's' + JR Z,.SCL + CP 'S' + JR Z,.SCL + + CP 'z' + JR Z,.CNF + CP 'Z' + JR Z,.CNF +.exit: + DEC HL + LD A,(HL) + INC HL + RET + +.SCL: + ld de,IMAGE_FLAG + ld a,1 + ld (de),a +.TRD: + LD DE,(X_FILE) + LD (IMAGE_NAME),DE + JR .exit + +.CNF: + LD DE,(X_FILE) + LD (CNF_NAME),DE + JR .exit +;------------------------------------[^] + +LINE_ZX: DB "ZX Spectrum PAGES",0 +LEN_LINE_ZX EQU $-LINE_ZX +;********************************************* + +MSG_EXIT1: + db 13,10,"EXIT without run",13,10,0 +MSG_EXIT2: + db 13,10,"Выход без запуска" +CR_LINE: + db 13,10,0 + +START_MSG: + db 13,10,'SPECTRUM launcher v',SP_VERSION,'.' + db 13,10,'(c) Sprinter Team.' + db 13,10,'Written by Ivan Mak.' + db 13,10,'Modified by Anatoliy Belyanskiy.' + db 13,10,BUILD_DATE,' - ', __TIME__, 13, 10, 0 + +ERROR_FILE_MSG_X: + db 13,10,"Error in file: ",0 +ERROR_FILE2_MSG_X: + db 13,10,"Ошибка в файле: ",0 +ERROR_FILE_MSG: + db 13,10,"Unable to work.",0 +ERROR_FILE2_MSG: + db 13,10,"Работа невозможна.",0 + +ERROR_CNF: + db 13,10,"Unexpected CNF file end.",0 +ERROR_CNF2: + db 13,10,"Неожиданный конец CNF файла.",0 + +NO_MEM_MSG: + db 13,10,"The spesial pages are already used." + db 13,10,"Clear memory and restart spectrum.exe again.",0 +NO_MEM_MSG2: + db 13,10,"Специальные страницы уже заняты." + db 13,10,"Очистите память и перезапустите spectrum.exe снова.",0 + +MSG_NORMAL: + db 13,10,"All files has been read successfully.",13,10 + db "MODE: ",0 +MSG_NORMAL2: + db 13,10,"Все файлы считаны нормально.",13,10 + db "Конфигурация: ",0 +MSG_NO_MEM: + db 13,10,"No memory space for image or",0 +MSG_NO_MEM2: + db 13,10,"Не хватает памяти для образа или",0 +MSG_LOAD_IMAGE: + db 13,10,"Image loading: ",0 +MSG_LOAD_IMAGE2: + db 13,10,"Загрузка образа: ",0 + +MSG_ZX_EXIT: + db 13,10,"EXIT from Spectrum configuration",0 +MSG_ZX_EXIT2: + db 13,10,"EXIT from ZX mode",0 + +PROGRES_IND: + db '░',0 ; 176 + +MEM_BLK: BYTE 0 +LINE_X: WORD 0 +X_FILE: WORD 0 +CNF_NAME: WORD 0 +IMAGE_FLAG: BYTE 0 ; 0 - trd, scl - 1, sna - 2, tap - 3 +IMAGE_NAME: WORD 0 +IMAGE_HANDLER: BYTE 0 +SAVE_SLOT3: BYTE 0 +LEN_CNF: WORD 0 +A_LINES: WORD 0,0,0,0,0,0,0,0 +;********************************************* + +CONTINUE: ; CNF файл прочитан, DE - длина CNF + LD (LEN_CNF),DE + + LD HL,#C000 + LD DE,A_LINES + LD C,8 +LOOP_A: + LD B,120 ; строки не более 120 символов + EX DE,HL + LD (HL),E + INC HL + LD (HL),D + INC HL + EX DE,HL +LOOP_L: + LD A,(HL) + CP 13 + JR Z,N_LINE + CP 10 + JR Z,N_LINE + CP 0 + JP Z,END_CNF_ERROR + INC HL + DJNZ LOOP_L + +N_LINE: + LD (HL),0 + INC HL + LD A,(HL) + CP 13 + JR Z,N_LINE + CP 10 + JR Z,N_LINE + DEC C + JR NZ,LOOP_A + +; выделено 8 строк в CNF +;************************************* + + LD HL,(A_LINES+BASIC128_LINE) ; 2-я строка - имя файла BASIC128 + LD A,#42 + CALL READ_FILE_1 + LD A,Spec_Page + OUT (SLOT3),A + JP C,ERROR_FILE + + LD HL,(A_LINES+BASIC_48_LINE) ; 3-я строка - имя файла BASIC 48 + LD A,#43 + CALL READ_FILE_1 + LD A,Spec_Page + OUT (SLOT3),A + JP C,ERROR_FILE + + LD HL,(A_LINES+TRDOS_LINE) ; 4-я строка - имя файла TR-DOS + LD A,#44 + CALL READ_FILE_1 + LD A,Spec_Page + OUT (SLOT3),A + JP C,ERROR_FILE + + LD HL,(A_LINES+EXP_LINE) ; 5-я строка - имя файла EXPANSION + LD A,#45 + CALL READ_FILE_1 + LD A,Spec_Page + OUT (SLOT3),A + JP C,ERROR_FILE + + LD HL,(A_LINES+BIOS_LINE) ; 6-я строка - имя файла BIOS + LD A,#46 + CALL READ_FILE_1 + LD A,Spec_Page + OUT (SLOT3),A + JP C,ERROR_FILE + + LD HL,(A_LINES+BIOS2_LINE) ; 7-я строка - имя файла BIOS2 + LD A,#47 + CALL READ_FILE_1 + LD A,Spec_Page + OUT (SLOT3),A + JP C,ERROR_FILE + +; файлы считаны +;************************************* + + LD HL,MSG_NORMAL + LD C,Dss.PChars + RST ToDSS + + LD HL,(A_LINES+NAME_CFG_LINE) + LD C,Dss.PChars + RST ToDSS + + LD HL,CR_LINE + LD C,Dss.PChars + RST ToDSS + +; LD A,(SAVE_SLOT3) +; OUT (SLOT3),A + +;************************************* + + LD A,Spec_Page + OUT (SLOT3),A + LD HL,(A_LINES+OPTIONS_LINE) ; строка параметров + +LOOP_PAR1: + LD A,(HL) + CP "/" + JR Z,PARAM_TEST + CP 0 + JR Z,PARAM_END + CP 13 + JR Z,PARAM_END + CP 10 + JR Z,PARAM_END + INC HL + JR LOOP_PAR1 + +PARAM_TEST: + INC HL + PUSH HL + + LD IX,PARAMS +NEXT_PAR: + LD E,(IX) + LD D,(IX+1) + +LOOP_PAR2: + LD A,(DE) + CP (HL) + JR NZ,PARAM_E1 + INC HL + INC DE + JR LOOP_PAR2 + +PARAM_E1: + CP 255 + JR NZ,NO_PAR + LD A,(HL) + CP 20h + JR Z,PARAM_E2 + CP 0 + JR Z,PARAM_E2 + CP 13 + JR Z,PARAM_E2 +NO_PAR: + POP HL + PUSH HL + INC IX + INC IX + INC IX + INC IX + LD A,(IX+1) + AND A + JR NZ,NEXT_PAR + POP HL + JR LOOP_PAR1 + +PARAM_E2: + EX (SP),HL ; новое HL - сохраняется! + + LD A,(IX+3) + LD (IX+2),A ; parameter alternate! + + LD L,(IX) + LD H,(IX+1) + + LD C,Dss.PChars + RST ToDSS + + POP HL + JR LOOP_PAR1 + +;************************************ + +PARAM_END: + + LD A,#E2 ; ROM-ID - BASIC 128 + LD B,#42 ; page + CALL SET_ROM + + LD A,#E3 ; ROM-ID - BASIC 48 + LD B,#43 ; page + CALL SET_ROM + + LD A,#E1 ; ROM-ID - TR-DOS + LD B,#44 ; page + CALL SET_ROM + + LD A,#E0 ; ROM-ID - EXPANSION + LD B,#45 ; page + CALL SET_ROM + + LD A,#EB ; ROM-ID - BIOS-1 + LD B,#46 ; page + CALL SET_ROM + + LD A,#EF ; ROM-ID - BIOS-2 + LD B,#47 ; page + CALL SET_ROM + + LD HL,(IMAGE_NAME) + LD A,H + OR L + JP Z,SKIP_IMAGE + + LD C,SLOT3 + IN B,(C) + PUSH BC + + CALL READ_IMAGE + POP BC + OUT (C),B + JP C,ERROR_FILE + +SKIP_IMAGE: + LD A,(No_run_+2) + AND A + LD HL,MSG_EXIT1 + JP Z,EXIT_ALL + + JP SET_RELOAD_PROG + +; LD HL,MSG_NORMAL +; JP EXIT_ALL + +;*************************************************** + +; JP 0 + +;******************************************** + +SET_ROM: + ; out B - old ROM-page + DI + +; PUSH BC +; PUSH AF + +; LD A,CNF_0 +; OUT (SYS_PORT.ON),A +; LD A,10h +; LD BC,7FFDh +; OUT (C),A + +; POP AF +; POP BC + +; LD C,0F8h +; CALL 3D13h + +; PUSH BC +; PUSH AF + +; LD A,0 +; LD BC,7FFDh +; OUT (C),A +; LD A,CNF_0 +; OUT (SYS_PORT.OFF),A +; +; POP AF +; POP BC +; RET + + EX AF,AF' + + IN A,(SLOT3) + PUSH AF + + LD A,DCP_PAGE ; установить новую + OUT (SLOT3),A + + LD A,(#C400) ; сохранить то что было + LD L,A + LD A,(#C600) + LD H,A + + EX AF,AF' ; страница + + LD (#C400),A ; установить порт ROM + LD (#C600),A + EX AF,AF' + + LD A,B + LD BC,0 + EX AF,AF' + IN A,(C) + EX AF,AF' + OUT (C),A ; установить новый ROM + EX AF,AF' + LD B,A + + LD A,L + LD (#C400),A ; вернуть порт + LD A,H + LD (#C600),A ; вернуть порт + + POP AF + OUT (SLOT3),A + + RET + +;******************************************** +READ_IMAGE: + LD DE,ONE_FILE + LD BC,128 + LDIR + LD HL,ONE_FILE + + LD A,1 + LD C,Dss.Open + RST ToDSS + RET C + + LD (IMAGE_HANDLER),A + + ld a,(IMAGE_FLAG) + and a + jr z,.Load_TRD + + CP 1 ; check if SCL + jp z,Load_SCL +; jp Error_Flag ;!!!!!!!!!!!!!!!! + +.Load_TRD: + LD A,(IMAGE_HANDLER) + LD C,Dss.Move_FP + LD B,2 + LD HL,0 + LD IX,0 + RST ToDSS ; найти длину файла + RET C + + PUSH IX + POP DE + +;--------------[new_code]--------------- + call Get_RAM_Disk_E + ret c + + jp Load_IMAGE_File +;--------------------------------------- +Get_RAM_Disk_E: +; hl:de - размер файла в байтах + LD A,D + ADD A,A + ADC HL,HL + ADD A,A + ADC HL,HL + + LD A,D + AND 3Fh + OR E + JR Z,.skip_inc + INC HL +.skip_inc: ; HL - длина файла в страницах + LD A,H + AND A + JR NZ,ERROR_NO_MEM + LD A,L + AND A + JR Z,ERROR_NO_MEM + PUSH AF +;*************************************** +; освободить ram-disk e: +.free_disk: + DI + LD A,0 + LD C,BIOS.EMM_FN3 + RST ToBIOS ; освободить e: +;!!!!!!!!!!!!!!!!!!!!!! ; назначать другой рамдрайв, свободный? +;*************************************** + POP AF + LD B,A ; запросить память у bios-а + LD A,0 + LD C,BIOS.EMM_FN2 ; и подсоединить к e: + RST ToBIOS + JR C,ERROR_NO_MEM + LD (MEM_BLK),A + +;--------------[new_code]--------------- + ret +;--------------------------------------- + +Load_IMAGE_File: + LD A,(IMAGE_HANDLER) + LD C,Dss.Move_FP + LD B,0 + LD HL,0 + LD IX,0 + RST ToDSS ; установить указатель на 0 + RET C + + LD HL,MSG_LOAD_IMAGE ; loading image + LD C,Dss.PChars + RST ToDSS + + LD A,(MEM_BLK) + +.load_loop: + PUSH AF + OUT (SLOT3),A + + LD A,(IMAGE_HANDLER) + LD HL,#C000 ; грузить 16k + LD DE,#4000 + LD C,Dss.Read + RST ToDSS + JR C,ERROR_IN_READ + + LD HL,PROGRES_IND ; loading progress + LD C,Dss.PChars + RST ToDSS + + DI + POP AF +.scl_read_next: + LD C,BIOS.GetMemPageNext + RST ToBIOS + + CP #FF + JR NZ,.load_loop + + LD HL,CR_LINE ; loading + LD C,Dss.PChars + RST ToDSS + + LD A,(IMAGE_HANDLER) + LD C,Dss.Close ; закрыть файл + RST ToDSS + + RET C +; ret + +Set_RAM_Dsk_EtoA: + DI + LD A,0 + LD B,0 + LD C,BIOS.RAMD_TO_DRV ; назначить e: на a: + RST ToBIOS + AND A + RET + +ERROR_IN_READ: + POP AF + JR ERROR_IMAGE_X + +ERROR_NO_MEM: + LD HL,MSG_NO_MEM + LD C,Dss.PChars + RST ToDSS +ERROR_IMAGE_X: + LD A,(IMAGE_HANDLER) + LD C,Dss.Close ; закрыть файл + RST ToDSS + SCF + RET + +SAV_PG3X: db 0 +;******************************************** +READ_FILE_1: + LD DE,ONE_FILE + LD BC,128 + LDIR + LD HL,ONE_FILE + OUT (SLOT3),A + +READ_FILE: + + LD A,1 + LD C,Dss.Open + RST ToDSS + RET C ; ошибка, если нет файла + + LD (FILE_HANDLE),A + LD A,(FILE_HANDLE) + + LD HL,0C000h + LD DE,4000h + LD C,Dss.Read + RST ToDSS + RET C ; ошибка при чтении + + PUSH DE + + LD A,(FILE_HANDLE) + LD C,Dss.Close + RST ToDSS + + POP DE ; длина считанных данных + RET ; ошибка при закрытии или Ok + +FILE_HANDLE: db 0 + +;******************************************** +;******************************************** + +EXIT_TO_DSS: + DI + LD SP,#BFF0 + LD A,CNF_0 + OUT (SYS_PORT.OFF),A + + ld a,(#FFF0) + out (SLOT0),a + + LD B,3 ; IBM_PAL + LD A,0 + LD C,#A6 ; SET_standard_PAL + RST ToBIOS + + LD A,3 ; OPEN_TXT + LD B,0 + LD C,#50 + RST ToDSS + + LD C,#56 ; CLS + LD DE,0 + LD HL,#2050 + LD B,7 + LD A,#20 + RST ToDSS + + LD HL,MSG_ZX_EXIT + JP EXIT_ALL + +SET_RELOAD_PROG: + DI + + LD A,Spec_Page + OUT (SLOT3),A + + LD A,"Z" + LD (#FFFE),A + LD A,"X" + LD (#FFFF),A + + LD A,(Ret_fn_+2) + AND A + LD DE,RESET_TO_ZX ; адрес программы перезапуска для ret-zx + JR Z,NO_RET_FN + LD DE,EXIT_TO_DSS ; адрес программы перезапуска для ret-fn + +NO_RET_FN: + LD (#FFF4),DE ; адрес программы возврата + IN A,(SLOT0) + LD (#FFF0),A ; DOS-PAGE + IN A,(SLOT1) + LD (#FFF1),A ; + IN A,(SLOT2) ; сохранить страницу + LD (#FFF2),A ; программы для возврата + IN A,(SLOT3) + LD (#FFF3),A ; + +;******************************************** + +RESET_TO_ZX: + DI + LD SP,#BFF0 + + ld a,high ZXKeys.Line_7 + in a,(ZXKeys) + and #1F + cp #1E + jr z,EXIT_TO_DSS + + LD A,CNF_0 + OUT (SYS_PORT.ON),A ; System-page on & CNF = 0 + +;-------------[TEST ATARIN]------------- +; #c0fd - +#05ED +; фикс неполной дешифрации порта #FFFD (пишут в #C0FD) +; [x] добавлен порт #C0FD во все карты портов + + ld bc,SLOT3 + in b,(c) + + ld a,DCP_PAGE + out (c),a + +; !HARDCODE далее всё наскоряк и захардкожено +; !TODO переделать под новую функцию дешифрации + ld a,#90 ; AY-8910-port (FFFD) + ld hl,#C000 + #05ED ; CNF 0 + ld (hl),a + + ld h,#c0 + #15 ; CNF 1 + ld (hl),a + + ld h,#c0 + #25 ; CNF 2 + ld (hl),a + + ld h,#c0 + #35 ; CNF 3 + ld (hl),a + + out (c),b +;--------------------------------------- + + LD A,(Ret_zx_+2) + LD B,A + LD A,(Ret_fn_+2) + XOR B + LD B,A + LD A,Conf_port.RET_PORT + CALL SET_ROM ; включить возврат + + LD A,CNF_3 + OUT (SYS_PORT.ON),A ; System-page on & CNF = 3 + + XOR A + OUT (BorderColor),A ; border-0 + OUT (RGADR),A ; Screen-page = 0 + OUT (RGMOD),A ; Screen-mode-page = 0 + LD BC,1FFDh + OUT (C),A ; Scorpion-port = 0 + LD BC,7FFDh + OUT (C),A ; pentagon-port = 0 + + LD A,(Int_or_+2) + AND A + LD A,#FA ; original waits on + JR NZ,ORIG1 + LD A,#FE +ORIG1: + LD BC,Port_All_Mode + OUT (C),A ; ACC-Off + + LD BC,CBL.SYS_PORT + LD A,0 + OUT (C),A ; CBL-off + + LD A,#12 ; FDD-720 + LD C,BIOS.FN_TURBO + RST #18 + +;---------------[test!!!!!]------------- + LD C,BIOS.HDD_PART ; IDE-1/IDE-2 + LD A,0 ; --> IDE-1 + RST #18 +;--------------------------------------- + +;****************************** + XOR A ; Set ZX-Palette + LD B,2 + LD C,#A6 + RST 18h + + LD A,(Int_or_+2) + AND A ; 3 + JR NZ,Original + LD A,(Int_sc_+2) ; 1/2 +Original: + LD C,#F2 ; -> INT for Pentagon or Scorpion + RST #18 + + LD HL,#4000 ; clear ZX-Spectrum screen + LD DE,#4001 + LD BC,#1AFF + LD (HL),L + LDIR + + LD HL,#4104 ; Screen-1 + LD BC,#0480 + LD E,0 + RST #18 + + LD HL,#5104 ; Screen-2 + LD BC,#0480 + LD E,0 + RST #18 + + XOR A + OUT (RGADR),A + OUT (RGMOD),A +;************************************************ +; Инициализация страниц + + DI + LD A,0 + OUT (SLOT0),A + LD A,5 + OUT (SLOT1),A + + XOR A + LD BC,#1FFD + OUT (C),A ; #1FFD + LD B,#7F +LOOP_P1: + OUT (C),A ; #7FFD + OUT (SLOT3),A + INC A + CP 8 + JR NZ,LOOP_P1 + + LD B,#1F + LD A,#10 + OUT (C),A ; #1FFD + LD A,8 + LD B,#7F +LOOP_P2: + OUT (C),A ; #7FFD + OUT (SLOT3),A + INC A + CP 16 + JR NZ,LOOP_P2 + XOR A + OUT (C),A ; #7FFD + LD B,#1F + OUT (C),A ; #1FFD + +; Все RAM, кроме BANK2 - в ней программа! +;*********************************************** + + LD HL,PROG_STARTS + LD BC,PROG_STARTS.Length + LD DE,#FF00 ;!!!!!!!!!! + LDIR + + LD A,(Line312_+2) + OUT (Port_VSYNC),A + + LD A,(P_7FFD_+2) ; - Pentagon off + LD BC,#7FFD + OUT (C),A + + LD A,(Turbo__+2) ; 3 - turbo + + LD HL,(Sprint_+2) ; +04h - Sprinter-ZX + ADD A,L ; +0Ch - Scorpion/Pentagon + + LD HL,(P_1FFD_+2) ; +40h - Scorpion port off + ADD A,L + + LD HL,(Mem512_+2) ; +80h - Pentagon-512 on + ADD A,L + + LD E,A + LD A,(To_trd_+2) + LD D,A +; + JP #FF00 ;!!!!!!!!!! + +;*************************************** +PROG_STARTS: + LD A,2 + OUT (SLOT2),A + LD A,E + OUT (SYS_PORT.OFF),A ; System-port + LD A,D + AND A + JP Z,0 + LD A,#10 + LD BC,#7FFD + OUT (C),A + LD HL,0 + PUSH HL + JP #3D29 ; RESET to TR-DOS + +.Length EQU $-PROG_STARTS + ASSERT PROG_STARTS.Length < #100, 'PROG_STARTS too big!!!' +; +; +; Если параметр задан, то выбирается значение Y +PARAMS:; Y / N ; тут значения для ключей записываются как 16 бит значение, значит обратный порядок байтов +Turbo__: dw Turbo_, #0302 ; включить TURBO +Line312_ dw Lines312, #6141 ; включить 312 строк +Sprint_: dw Sprint, #040C ; включить Sprinter +P_7FFD_: dw P_7FFD, #0030 ; включить 7FFD +P_1FFD_: dw P_1FFD, #0040 ; включить 1FFD +Mem512_: dw Mem512, #8000 ; включить 512k +To_trd_: dw To_trd, #0100 ; вoйти в TR-DOS +Int_sc_: dw Int_sc, #0102 ; включить INT "по-скорпионовски" +No_run_: dw no_run, #00FF ; не запускать +Int_or_: dw Int_or, #0300 ; включить INT "Original" +Ret_zx_: dw Ret_zx, #4100 ; включить возврат в ZX страница (#41) должна совпадать с ret_fn_ +Ret_fn_: dw Ret_fn, #4100 ; включить возврат в FN страница (#41) должна совпадать с ret_zx_ + dw 0,0 ; end marker + +Turbo_: db "turbo", 255,0 +Lines312: db "lines312", 255,0 +Sprint: db "sprinter", 255,0 +P_7FFD: db "7FFD", 255,0 +P_1FFD: db "1FFD", 255,0 +Mem512: db "mem512", 255,0 +Int_sc: db "int-sc", 255,0 +To_trd: db "to-trdos", 255,0 +no_run: db "no-run", 255,0 +Int_or: db "origin", 255,0 +Ret_zx: db "ret-zx", 255,0 +Ret_fn: db "ret-fn", 255,0 + +;ZX_PROG_LEN EQU $-RELOAD_PROG + +;/Turbo /Lines312 /Sprinter /7FFD /1FFD /Mem512 /Int-Sc /To-TRDOS /no-run /origin /ret-zx /ret-fn + +CNF_FILE: db "SPECTRUM.CFG",0 +ONE_FILE: ds 128 +; +; +; + +; + IFDEF NEED_LOADER +Loader_length EQU $-BEGIN + ELSE +Loader_length EQU 0 + ENDIF +;----------------------------------------------[End Loader section] +; + STACK_CHECK_MACRO stack_point, stack_buffer +; Code after Loader +;[]-----------------------------[PLUGINS]-----------------------------[] + + INCLUDE 'trdscl.a80' + +;[]-------------------------------------------------------------------[] +; Code end section +; OUTEND +; SAVEBIN 'Build/test.bin', exe_header, $-exe_header +; \ No newline at end of file diff --git a/trdscl.a80 b/trdscl.a80 new file mode 100644 index 0000000..3556fc7 --- /dev/null +++ b/trdscl.a80 @@ -0,0 +1,336 @@ +; Cлужебный (девятый cектоp в облаcти каталога) иcпользуетcя cиcтемой +; для хpанения инфоpмации о cамой диcкете. В таблице пpиведен его фоpмат: +; ╔═══════════════╤═══════╤═══════════════════════════════════════════╗ +; ║Cмещение от │ Длина │ Значение ║ +; ║начала cектоpа │ │ ║ +; ╟───────────────┼───────┼───────────────────────────────────────────║ +; ║ #00 │ 1 │ Байт 0 ║ +; ║ #01 │ 224 │ Hе иcпользуетcя (заполнено байтом 0) ║ +; ║ #E1 │ 1 │ Hомеp пеpвого незанятого cектоpа на диcке ║ +; ║ #E2 │ 1 │ Hомеp доpожки пеpвого незанятого cектоpа ║ +; ║ #E3 │ 1 │ Тип диcкеты ║ +; ║ #E4 │ 1 │ Количеcтво файлов ║ +; ║ #E5 │ 2 │ Количеcтво cвободных cектоpов ║ +; ║ #E7 │ 1 │ Идентификационный код TR-DOS (#10) ║ +; ║ #E8 │ 2 │ Hе иcпользуетcя (заполнено байтом 0) ║ +; ║ #EA │ 9 │ Hе иcпользуетcя (заполнено байтом 32) ║ +; ║ #F3 │ 1 │ Hе иcпользуетcя (заполнено байтом 0) ║ +; ║ #F4 │ 1 │ Количеcтво удаленных файлов ║ +; ║ #F5 │ 8 │ Hазвание диcкеты ║ +; ║ #FD │ 3 │ Hе иcпользуетcя (заполнено байтом 0) ║ +; ╚═══════════════╧═══════╧═══════════════════════════════════════════╝ + STRUCT SEEK +FirstFreeSec BYTE 0 +FirstFreeTrk BYTE 1 +DiskType BYTE #16 +AllFilesNum BYTE 0 +FreeSectors WORD 0 ; beta version +TRDOS_ID BYTE #10 +notuse1 WORD 0 +notuse2 BLOCK 9,32 +notuse3 BYTE 0 +DelFilesNum BYTE 0 +DiskName TEXT 8, {" "} ; beta version + ENDS + +/* +SYS_SECTOR: + DB 0 + BLOCK 224,0 +.FirstFreeSec: DB 0 +.FirstFreeTrk: DB 1 +.DiskType DB #16 ; #16 = 80-2, #17 = 40-2, #18 = 80-1, #19 = 40-1 +.AllFilesNum: DB 0 +.FreeSectors: DW 2544 + DB #10 + DW 0000 + BLOCK 9,32 + DB 0 +.DelFilesNum: DB 0 +.DiskName: BLOCK 8,32 + BLOCK 3,0 +; +*/ + +; ╔═════════╤═════╤═════════════════════╗ +; ║Cмещение │Длина│ Hазначение ║ +; ║от начала│ │ ║ +; ╟─────────┼─────┼─────────────────────╢ +; ║ #00 │ 8 │ Имя файла ║ +; ║ #08 │ 1 │ Тип файла ║ +; ║ #09 │ 2 │ Паpаметp START ║ +; ║ #0B │ 2 │ Паpаметp LENGTH ║ +; ║ #0D │ 1 │ Количеcтво cектоpов ║ +; ║ #0E │ 1 │ Hомеp 1го cектоpа ║ +; ║ #0F │ 1 │ Hомеp доpожки ║ +; ╚═════════╧═════╧═════════════════════╝ +/* +CAT_ELEMENT: +.Name BLOCK 8,32 +.Type DB 0 +.Start DW 0000 +.Length DW 0000 +.Sectors DB 0 +.FirstSector DB 0 +.FirstTrack DB 0 +*/ + + STRUCT CAT_Elements +Name block 8 +Type BYTE +Start WORD +Length WORD +Sectors BYTE +FirstSector BYTE +FirstTrack BYTE + ENDS + + STRUCT SclOffsets +ID BLOCK 8 +Files BYTE +FileBlock CAT_Elements + ENDS +; 655360 kb = 160 tracks * 16 sectors * 256 bites +; 80 tracks * 2 heads * 16 sectors * 256 bites = 655360 kb +; Page = 64 sectors = 4 tracks + +;-----------[] +Load_SCL: +;-------[Метка диска - имя файла]------- + ld hl,ONE_FILE + ld de,SCL_Buffer + ld bc,#0300+Dss.EX_Path + rst ToDSS + jr c,.skip + + ld hl,SCL_Buffer + ld a,'.' + ld bc,0008 + ld de,SYS_SECTOR.DiskName +.loop: + cp (hl) + jr z,.skip + ldi + jp pe,.loop + +.skip: +;-------[проверка хедэра SINCLAIR]------ + + ld a,(IMAGE_HANDLER) + ld hl,SCL_Buffer + ld de,8 + ld c,Dss.Read + rst ToDSS + ret c ; обработчик ошибки + + ld hl,SCL_Buffer + ld de,SCL_HEADER + ld b,8 +.check_header: + ld a,(de) + cp (hl) + jr nz,.error_header + inc hl + inc de + djnz .check_header + jr .get_size +.error_header: + scf + ret + +;------[вычисление размера для TRD]----- +.get_size: +/* ld a,(IMAGE_HANDLER) + ld hl,0 + ld ix,SclOffsets.Files + ld b,l + ld c,Dss.Move_FP + rst ToDSS ; указатель на байт количества блоков (файлов) + ret c ; обработчик ошибки!!!!! +;*/ + ld a,(IMAGE_HANDLER) + ld hl,SCL_Buffer + ld de,#701 + ld c,Dss.Read + rst ToDSS ; !FIXIT сделать контроль ошибки? ; читаем байт количества блоков (файлов) +; + ld a,(SCL_Buffer) + ld l,a + xor a + ld h,a +; + add hl,hl ;*2 + push hl + add hl,hl ;*4 + ld d,h + ld e,l + add hl,hl ;*8 + add hl,de ;*12 + pop de + add hl,de ; в HL значение A*14 + + add hl,bc + + ld de,SclOffsets.FileBlock + add hl,de ; в HL размер от начала SCL до начала блока данных (header_length) + push hl +; + ld a,(IMAGE_HANDLER) + ld hl,0 + ld ix,4 ; игнорим контрольную сумму scl файла + ld b,2 + ld c,Dss.Move_FP + rst ToDSS ; указатель на конец файла + jr nc,1F ; обработчик ошибки!!!!! + + pop hl + ret + +1: push ix + pop de ; значение младших 16 бит размера файла + ex (sp),hl ; значение header_length в HL, старшая часть размера файла на стеке + ex de,hl ; в HL значение младших 16 бит размера файла, в DE - header_length + + sbc hl,de + ld de,0 + ex (sp),hl ; младшая часть размера файла на стеке + sbc hl,de ; в HL старшая часть размера файла + + ex (sp),hl ; старшая часть размера файла на стеке + ld de,#1000 + add hl,de + + ex (sp),hl ; младшая часть размера файла на стеке + ld de,0 + adc hl,de + pop de ; тут в hl:de размер для trd + +;--------------------------------------- + + call Get_RAM_Disk_E + ret c ; обработчик ошибки!!!!! + +Convert_SCLtoTRD: + + LD A,(MEM_BLK) + out (SLOT3),a ; вставляем первую страницу RAM-диска + + ld hl,SCL_Buffer + ld b,(hl) ; CAT_Elements + inc hl + ld de,#C000 ; RAM-drive's track 0 + ld ix,SYS_SECTOR + ld (ix+SEEK.AllFilesNum),b +.cat_loop: + push bc + ld a,(hl) + CP 1 + jr nz,1F ; this file is not deleted + inc (ix+SEEK.DelFilesNum) +1: ld bc,CAT_Elements-2 ; ld bc,#0D + ldir ; copy 14 bites of scl files table to trd image catalog + + ld a,(SYS_SECTOR.FirstFreeSec) + ld (de),a + ld c,a ;!---[v 1] + inc de + ld a,(SYS_SECTOR.FirstFreeTrk) + ld (de),a + inc de ; Pointer on next filename in RAM drive + + dec hl ; set to number of sectors + ld a,(hl) ; get file length in sectors from scl-table + and #0F + add a,c ;!---[^ 1] + ld c,a ;!---[v 2] + and #0F + ld (SYS_SECTOR.FirstFreeSec),a + ld a,#F0 + and c ;!---[^ 2] + jr z,1F + inc (ix+SEEK.FirstFreeTrk) +1: ld a,(hl) + srl a + srl a + srl a + srl a + add a,(ix+SEEK.FirstFreeTrk) + ld (SYS_SECTOR.FirstFreeTrk),a + + inc hl ; Pointer on next filename in SCL_Buffer + pop bc + djnz .cat_loop + + xor a + ld (de),a ; file table end marker +;--------------------------------------- + +; Доделать!!!!! +; SYS_SECTOR.FreeSectors + +; push hl ; байт в буфере откуда в SCL начинаются данные (HL-SCL_Buffer) +; push de ; байт в ram диске trd где заканчивается таблица последнего файла + + xor a + ld de,SCL_Buffer-8 ; вычисляем значение смещения в файле из значения смещения в буфере + sbc hl,de + push hl + pop ix + + ld a,(IMAGE_HANDLER) + ld hl,0 + ld B,L ; b=0 - от начала файла + ld c,Dss.Move_FP + rst ToDSS ; указатель на первый байт данных + jr nc,1F ; обработчик ошибки!!!!! + + pop de + ret + +1: di + ld hl,SYS_SECTOR_START + ld de,#C800 ; sys sector of tr-dos disk in bank3 of ram-disk + ACC_SetBlockSize + ld a,0 + ACC_CopyBlock + ld a,(HL) + ld (DE),a + ACC_Off +; ei + + LD A,(IMAGE_HANDLER) + LD HL,#D000 ; догрузить до конца страницы + LD DE,#3000 + LD C,Dss.Read + RST ToDSS + JP C,ERROR_IN_READ ; обработчик ошибки!!!!! + + LD HL,MSG_LOAD_IMAGE ; loading image + LD C,Dss.PChars + RST ToDSS + + LD HL,PROGRES_IND ; loading TRD + LD C,Dss.PChars + RST ToDSS + + DI + LD A,(MEM_BLK) + jp Load_IMAGE_File.scl_read_next + +;-----------[] + +SCL_HEADER: DB 'SINCLAIR' +;------------[переменные]--------------- +SYS_SECTOR_START: + DB 0 + BLOCK 224,0 +SYS_SECTOR SEEK +SYS_SECTOR_END: BLOCK 3,0 + +SCL_FILE_ID: DB 0 +;-----------[в самый конец]------------- +SCL_Buffer EQU $ + assert SCL_Buffer+#701 < #C000, "Buffer out of mem bank 2" + + + diff --git a/version.inc b/version.inc new file mode 100644 index 0000000..fc36338 --- /dev/null +++ b/version.inc @@ -0,0 +1,8 @@ +; + LUA ALLPASS + local date, month, year = Get_date_RU(sj.get_define("__DATE__")) + sj.insert_define("BUILD_DATE", "'" .. date .. "." .. month .. "." .. year .. "'") + ENDLUA + + DEFINE SP_VERSION "2.01 beta build" +; \ No newline at end of file