C-Net Week #24 28 июня 2007

Софт

Doors kick start - новая ОС для Спектрума - DoorsAQUA 7.1, быть или не быть? Breeze разьясняет.

Вот  мы и подошли к финальной,
так   сказать,  заключительной
части     нашего    небольшого
издания CWEEK#24.

А   на   последок,  я  оставил
немного  вкусненького  ;)  так
сказать  писча для ума :D Итак
встречаем...


DoorsAQUA 7.1

Многие уже, наверное, потеряли
всякую    веру    и    надежду
в  ожидании  такого  чуда, как
"Doors     OS".     Да,    это
действительно   самый  большой
долгострой     на    платформе
zx-spectrum.    Не    хочется,
конечно,        оправдываться,
но разработка затянулась из-за
ряда  причин:  это и банальное
отсутствие знаний на то время,
но  ряд  новых  идей, и многое
другое.   Всё  вместе  начиная
с  1995 года заставляло не раз
пересматривать     ядро,    да
и  систему  в  целом   с нуля,
а время-то уходило...

Последние наработки отличаются
координальным образом, от всех
предыдущих.   Раньше  основной
целью            преследовался
графический          интерфейс
-  окошки. Нет, я не собираюсь
отказываться   от   этой  идее
совсем,   просто  она  немного
уходит  на второй план. Но обо
всём по прядку.

Всё  началось  не  так  давно,
а  если быть точнее, то где-то
с   1-го   мая  :)  когда  мне
написал  AlCo  с  вопросом "не
завалялось  драйвера  HDST под
ATM,   хотелось  бы  исходники
новых   драйверов  под  HDST".
HDST   -   это   моя  софтинка
(HardDist Search&Test) которая
по   средствам   подключенного
драйвера      HDD     пытается
обнаружить        подключенный
HardDisk    и   CD-Rom,   если
операция   успешна,  выводится
заводская     информация    по
параметрам данного устройства.
Так вот, найдя сорцы последней
версии   HDST   и   драйверов,
я  несколько  прифигел от кода
:)    и   по   правде   говоря
не   совсем   хотелось   такое
"чудо"  отдавать  в массы, так
в такой свалке кода и процедур
понять   что-то  очень  сложно
:(  да  и  кроме того так и не
удалось   собрать   сие   чудо
в   sjasmplus.   Посему   было
принято  решение  привести это
в   более-менее  божеский  вид
(снабдив некоторым количеством
комментариев),   правда,  были
некоторые          ограничения
по   срокам,   так   как  AlCo
планировал     вставить    сей
продукт в InfoGuide#10. Как вы
уже поняли, в сроки я всё-таки
не уложился...

Но не будем о грустном. Что же
всё-таки  заставило,  затянуть
с  выпуском HDST 0.10 ? Как вы
уже  могли догадаться, я решил
перевести HDST на новые рельсы
- а именно использовать движок
Doors, так как HDST достаточно
простое   приложение,  которое
использует несколько драйверов
для    своей    работы.    Так
появилась  идея  дописать ядро
DOORS,  оно немного отличается
от     первоначальных     идей
7й   реализации,   и   поэтому
промаркировано, как 7.1.

Ядро  Doors  7.1  представляет
собой    модульную   структуру
и   располагается  в  основной
памяти    с    адреса   #8000.
От  версии  7  остался  только
менеджер  памяти - memManager.
У   которого   есть  несколько
функций:            initMemory
(инициализировать и постороить
карту   памяти),   memAllocate
(запросить  свободную память),
memFree (освободить занимаемую
память),            memSetBank
(установить    текущий    банк
памяти).   Вообще   memManager
до конца не дописан и в данном
билде (build) не используется.

Основной  упор  в  этом билде,
был  сделан  именно  на работу
с     устройствами,    поэтому
основной  и  главный компонент
менеджер      устройств      -
devManager.  Начиная  с адреса
#5B00      хранится      карта
драйверов,             которая
инициализируется   с   помощью
команды    initDrvMap.   Карта
драйверов  занимает  256  байт
и разбита на блоки по 3 байта.
Первые  2 байта адрес драйвера
в  памяти,  3й  байт  -  номер
банка   памяти.   Всего  можно
адресовать  85 устройств, если
же  этого  на  каком-то  этапе
проекта  будет  не достаточно,
можно  изменить  размер  карты
и    её   место   расположения
(drvMapSize  и drvMap), правда
придётся     перекомпилировать
ядро.  С помощью команд addDrv
и    delDrv   можно   добавить
и    соответственно    удалить
устройство из карты драйверов.
Команда  statDrv  возвращает 0
,    если    операция   прошла
успешна.    При    инсталляции
драйвера   ему   присваивается
номер   (ID   -   два   байта)
к  которому  можно  обратится,
драйвера               которые
вкомпилированы  в  ядро  имеют
статический  ID и не меняются.
С   помощью   команды  lastDrv
можно     узнать    количество
установленных        устройств
в системе.

Обращение      к      драйверу
устройства          происходит
по  средствам команды callDrv.
В аккумуляторе (A) мы передаём
команду  устройству, они могут
быть:
-initDev    -    инициализация
устройства;
-readDev   -  получить  данные
из устройства;
-sendDev  -  отправить  данные
в устройство;
-statDev  - получить состояние
устройства  (statOK-устройство
готово  к  работе,  statError-
устройство  завершило операцию
с      ошибкой,      statBusy-
устройство             занято,
statTimeout-        устройство
зависло  и  вышло  по timeout,
statNoDevice-устройство
отсутсвует);
-infoDevDrv     -     получить
информацию      о     драйвере
устройства;
-statDevAdv     -     получить
расширенные  данные  об ошибке
(более  подробные  данные  что
произошло,    например,    при
ошибке   чтения  с  диска  тут
могут    быть   указаны   трек
и сектор где произошел сбой);
-readDevPorts    -    получить
состояние   портов  устройства
(сделано    для    IDE)   если
устройство   не   поддерживает
такую        функциональность,
вернётся ошибка;
-selMaster      и     selSlave
- позволяют переключится между
несколькими      устройствами,
на  одной  шине  (сделано  для
IDE).      Если     устройство
не      поддерживает     такую
функциональность,     вернётся
ошибка.
-infoDevice     -     получить
описание устройства;

Вот   такая  в  принципе  пока
функциональность, приведу  тут
небольшой пример:

; инициализируем менеджер
; драйверов
ld a,initDrvMap
call devManager

; инсталлируем драйвер консоли
ld hl,drvConcole
ld a,addDrv
call devManager

; инсталлируем драйвер
; клавиатуры
ld hl,drvKeyboard
ld a,addDrv
call devManager

В     принципе     всё     это
(инициализировать     менеджер
драйверов,   драйвер  консоли,
драйвер  клавиатуры)  не надо,
так    как    это   происходит
автоматически    при    старте
системы     и    инициализации
керналя,    и    здесь    дано
в качестве примера.

Что  бы  отправить блок данных
в    консоль    (в    HL   -ID
устройства,         B-комманда
драйверу,  DE  -  адрес  блока
данных,  A - команда менеджеру
драйверов):

ld hl,#0000
ld b,sendDev
ld de,dataBlock
ld a,callDrv
call devManager

dataBlock
       dw dataBlock2-dataBlock
       db "Hello World!"
dataBlock2

В первых двух байтах dataBlock
хранится  длина  блока данных.
Использовать    маркёр   конца
(типа     #00     или     #FF)
принципиально  я  не стал, так
как  данные  могут  быть какие
угодно  (а  не  только  текст)
и   соответственно  отправлять
их  можно  тоже  куда  угодно,
в    любое    устройство,    а
не только в консоль.

Другой  пример  чтения данных,
используя  драйвер  клавиатуры
(в    HL    -ID    устройства,
B-комманда     драйверу,    DE
-   адрес   блока   данных,  A
-       команда      менеджеру
драйверов):


ld hl,#0001
ld b,readDev
ld de,buffer ; временный буфер
ld a,callDrv
call devManager

buffer dw #01
       db #00

Как   и  в  случае  с  записью
данных,  при  чтении  в buffer
-  первые  два байта указывают
на   длину   блока.  Пока  эта
функциональность   реализована
не  во всех драйверах, поэтому
данные     могут    быть    не
актуальны.   Однако   реальные
данные    всегда    идут    со
смещением buffer+2.

Ну вот пока и всё по менеджеру
устройств.  Как  я писал выше,
некоторые   драйвера  встроены
в ядро и имеют статические ID,
вот они:

#0000 - console driver
#0001 - keyboard driver
#0002 - IDE driver
#0003 - ATAPI driver

Конечно,  их  можно  изменить,
пересобрав ядро. Однако делать
это    не   стоит,   так   как
некоторые     эти     драйвера
несколько  связаны между собой
и чётко знают , что #0000- это
консоль,     #0001    -    это
клавиатура.    Например    для
отображения   тех   же  ошибок
используется  консоль,  а  при
выводе   большого   количества
текста,  консоль может ожидать
нажатие  любой клавиши (аналог
"SCROLL  ?"  в BASIC). Правда,
без   проблем  можно  перебить
адрес  драйвера  для  ID #0000
и  тем  самым  отправить вывод
данных    в    другое   место,
например,     если    загружен
графический          интерфейс
в отдельное окошко.

Вообще  модульная система ядра
позволяет без проблем собирать
ядро  под  разные  модификации
спектрума.    Например,    для
консоли   можно   использовать
не    только    спектрумовский
стандартный      экран,     но
и     различные    расширенные
(384x304,  512x192),  а вместо
стандартной  клавиатуры  можно
использовать  расширенную  или
от ATM-Turbo. Тоже справедливо
и  для  драйверов IDE и ATAPI,
главное         придерживаться
некоторых  стандартов  которые
я    заложил    в    структуру
драйверов.

В    комплекте    пока    идут
драйвера:    Console    Driver
(Standart ZX Screen), Keyboard
Driver (Standart ZX Keys), IDE
Driver    (NEMO/KAY),    ATAPI
Driver  (NEMO/KAY).  Несколько
позже    я    добавлю   другие
вариации,  пока  же  если есть
желание  можно  написать свои.
Сделать  это  можно  посмотрев
сорцы      уже      написанных
драйверов, однако дополню:

У  драйвера консоли и драйвера
клавиатуры             похожая
функциональность,      поэтому
важно              реализовать
функциональность   -  initDev,
readDev,   sendDev,   statDev,
infoDrv, statDevAdv, например:

_drvConsole
ld a,b
; инициализация устройства
cp initDev
jr z,_initCon
; получить данные из
; устройства
cp readDev
jp z,_readCon
; послать в устройство блок
; данных
cp sendDev
jp z,_sendCon
; получить состояние
; устройства
cp statDev
jp z,_statCon
; получить информацию
; о драйвере устройстве
cp infoDrv
jp z,_infoCon
; получить расширенные
; данные об ошибке
cp statDevAdv
jp z,_statConAdv
; не известная команда
ld a,statError
; устанавливаем ошибку!
ld (conStatus),a
ret

У   драйвера   IDE   и   ATAPI
несколько          расширенная
функциональность -


_drvIde
ld a,b
; инициализация устройства
cp initDev
jr z,_initIde
; получить данные
; из устройства
cp readDev
jp z,_readIde
; послать в устройство
; блок данных
cp sendDev
jp z,_sendIde
; получить состояние
; устройства
cp statDev
jp z,_statIde
; получить информацию
; о драйвере устройства
cp infoDevDrv
jp z,_infoIde
; получить расширенные
; данные об ошибке
cp statDevAdv
jp z,_statIdeAdv
; получить сосотояние
; портов устройства
cp readDevPorts
jp z,_readIdePorts
; выбрать master устройство
cp selMaster
jp z,_sel_master
; выбрать slave устройство
cp selSlave
jp z,_sel_slave
; получить информацию об HDD
cp infoDevice
jp z,_infoHardDisk
; не известная команда
ld a,statError
; устанавливаем ошибку!
ld (ideStatus),a
ret

В   следующем   билде   фунции
selMaster   и  selSlave  будут
заменены  на функцию selBusDev
(select  Bus  Device)  то есть
на     вход    подаём    номер
устройства  на  шине (в данном
случае  0  -  master, 1-slave)
и  выбираем.  Думаю, это будет
идеологически  правильно,  так
как,  например, на устройствах
типа  SCSI  может быть гораздо
большее  число  устройств, чем
2.    Кто   знает   ;)   может
к  спектруму  подключат и SCSI
в ближайшее время...

В  приложении  к  этому номеру
вы      найдёте     небольшое,
но  работоспособное приложение
HDST (HardDisk Search & Test).
Для   тех,   кто   не   вкурсе
напомню,    данная   программа
определяет   наличие  жесткого
диска   и   cd-rom.  Если  они
присутствуют,        выводится
инженерная  информация об этих
устройствах.   Данная   версия
(0.10)      практически     не
отличается по функциональности
от  предыдущей.  Основная идея
была     это     использование
настоящего   ядра  Doors  7.1.
В  качестве  примера  есть три
скомпилированные  версии  ядра
с  поддержкой контроллеров HDD
-      для      NemoKAY     ,
ScrorpionSMUC и ATM-2+. Скажу
сразу,  что  я очень торопился
с    выпуском    cweek   (итак
затянулось    на   4   недели)
и   поэтому  драйвера  немного
не      дописаны,     да     и
функциональность   ядра   (как
вы       могли       заметить)
минимальная.  По этой же самой
причине   пока  не  выкладываю
сорцов.   В   ближайшее  время
(я   так   надеюсь)  допишутся
до  конца драйвера, ну а пока,
я   надеюсь,   данная   версия
заработает     на     реальном
спектруме,    так    как   всё
тестировалось    в   эмуляторе
Unreal Speccy.


На  этом  пожалуй  я и закончу
рассказ  о  Doors 7.1, напомню
только      что      подробную
информацию     можно     найти
на    официальной    страничке
проекта  -  DoorsAQUA Project

 twilight.org.ru/doors_aqua/