ZX Time #12 27 мая 2003

Программирование

                                        
          Несколько слов об ОС          
         ----------------------         
               Demon/DPC                
                                        
   И вновь возвращаюсь к теме ОС, подня-
той в ZXT#11...                         
                                        
   Bce  конечно  хорошо  IDE,  CD-ROM, и
прочие  радости.  Но при установке новой
операционной системы на Спектрум возник-
нет  проблема  наполнения ee программным
обеспечением.  Естественно,  никто  и не
подумает вдруг перелетать на голую ось и
тем  более писать софт под нее. Решением
данной  проблемы  мне  видится  эмуляция
диска  трдос  в  верхней  памяти, но для
этого  потребуется  минимум  1 мегабайт,
или  512кб c ограничениями. Данным обра-
зом  сделано  в КАЯХ производства нашего
незабвенного  NEMO.  Идея, как я считаю,
отличная. Эл. диск уже реализован в про-
шивках трдос версий 5.12, 5.13F, 5.1ЗFm,
может  еще  в  каких-нибудь.  Но  не это
главное. Выглядеть это будет так: загру-
жаем ОС, копируем спец. утилитой TRD или
SCL  файл на эл. диск и стартуем c него.
Дешево и сердито. Только надо будет пре-
дycмотрeть  подключение эл. диска на лю-
бой  драйв (А,B,С,D - для  трдос, для ОС
может быть другое обозначение), так  как
вешать его только на какой-то определен-
ный  драйв  нецелесообразно: поставим на
А - реальный  дисковод  обрyбим, на дру-
гой - лишимся  возможности грузить прог-
раммы, жестко привязанные к диску А. Так
же  должен  осуществляться  перехват  по
портам  ВГ, это все реально осуществимо,
соответствующей перепрошивкой ПЗУ. Слышу
недовольные  крики:"...Y  меня нет прог-
рамматора",  и  т.п. Его недолго собрать
(кому  надо схему вышлю), или можно най-
ти  где  записать - это  все мелочи, тем
более если ставить новую ОС, то по-любо-
му надо зашивать ee в ПЗУ 128-го Басика,
все равно его никто не юзает.           
                                        
   Теперь надо остановиться на следующем
вопросе.  Стоит  ли  прошивать ОС вместо
128 Басика? Ответ однозначно положитeль-
ный. ОС не будет занимать место в нижней
памяти,  что  при  бЧкб доступной памяти
очень  удобно.  Да  и крах системы тогда
невозможен.  Конечно,  не  надо все пол-
ностью  зашивать в ПЗУ - только консоль,
основные   драйвера,  и  таблицу  вызова
стандартных подпрограмм. При этом нужно,
чтобы  можно  было  заменить стандартные
драйвера на более новые, и т. д.        
                                        
   Например,  y нас прошит драйвер верх-
ней памяти под 128-ой Спектрум. И тут мы
берем и расширяем память до 1мб! Записы-
ваем  в autoexec.bat (или как там он бу-
дет  называтья, это сути дела не меняет)
команду  установки драйвера памяти 1мб -
и готово.                               
                                        
   И еще один плюс ОСи в ПЗУ. Уже многое
было  сказано  о  реализации многозадач-
ности, хотя бы псевдо. О реальной много-
задачноcти не стоит и говорить, так как:
во-первых Спекрум хоть и сильная машина,
но реальную многозадачность для реальных
(простите  за тавталогию) задач не потя-
нет.  Есть  опыты, осуществляющие вытес-
няющyю  многозадачность,  но  сама  сис-
тема,  контролирующая  процессы пожирает
основное  машинное  время  и, собственно
говоря,  на сами процессы не хватает ре-
cypcob.                                 
                                        
   Ладно, я отвлекся. B пользу ПЗУ гово-
рит  еще  и следующее. Y меня есть нара-
ботки,  осуществляющие пceвдомногозадач-
ность.  Система находится в #47 странице
памяти  по  порту  #7FFD и вызывается по
MAGIC.  Bce  работает  замечательно (кто
хочет  протестировать - могу прислать, к
компу  требования  такие:  trdos  версии
5.12,  5.13 и 512 или более килобайт па-
мяти), но есть один глюк (хорошо ловится
в ZX-Amp'e, когда играет музыка без пле-
ера),  происходит  разрушение программы,
по причине того, что возврат в программу
из  системы происходит c нулевой страни-
цей  памяти.  ПЗУ  позволяет  определить
нужную страницу и выполнять выход из си-
стемы без краха программы.              
                                        
   Так  же  есть наработки в области ОС.
Исследуется код NeOS, мною принято рeшe-
ние продолжить проект NeOS v2.0 даже без
исходников, найдена авторская документа-
ция  по  NeOS,  скажу, что очень и очень
неплохая  задумка,  при  чем уже реально
работающая.  Только  нет  драйверов  под
msdos,  isdos, hdd, cdrom, но это вопрос
времени.  Если  y кого-то есть что-то по
NeOS - присылайте.  Если  кому-то  нужна
имеющаяся  инфа  по NeOS, то обращайтесь
ко  мне. Будет сделана качественная под-
держка проекта в интернете. Пока на этом
все. Продолжение следует...             
                                        
   P.S. Мой e-mail: demon_zx@fromru.сом 
                                        
                 - - -                  
                                        
     Комментарии к статье Demon'а:      
    -------------------------------     
             Денис Токарчук             
                                        
   Во-первых,   хочу  выразить  огромную
благодарность  Диме  за  его статью. Во-
вторых,  хочу отметить, что изложенные в
ней концепции во многом повторяют конце-
пцию ОС, над которой работаем мы (Kille-
гам и я). Однако, есть некоторые места в
материале  Димы, c которыми можно nocno-
рить.                                   
                                        
   Например,  по-поводу TR-DOS. Он пред-
лагаeт  практически  эмулировать  работу
команд TR-DOS'а. Зачем?  Ведь TR-DOS ни-
куда  не девается - ОС-то мы зашиваeм на
место  Basic128.  Поэтому,  я  предлагаю
сделать так. Перед  запуском tr-dos-про-
граммы,  система "перекидывает" все свои
переменные  в  верхние  страницы памяти,
производит паccивизацию активной и фоно-
вых  задач (все их переменные и сами за-
дачи также располагаются в верхних стра-
ницах  памяти в текущем состоянии), пре-
дyпрeждаeт  пользователя  о том, что TR-
DOS-программа  может  повредить данные в
верхних  страницах  памяти  и, установив
все переменные и данные BASIC48, "отдает
ему  управление" (можно  сказать, форми-
рует  в  BASIC'e  своеобразный  boot). А
когда  работа c TR-DOS-программой завeр-
шeна, пользователь жмет привычный RESET.
Управление  опять  передается  ОС,  та в
свою очередь проверяет состояние верхних
страниц  памяти  и "восстанавливает" все
процессы.  По-моему, это оптимальный вы-
ход из ситуации.                        
                                        
   Если  же  действовать  по предложению
Demon'а - эмуляция вызовет лишь hecobme-
ctumoctb.                               
                                        
   Теперь  о многозадачности. Я согласен
c  тем,  что вытесняющая многозадачность
(далее ВМ) - это невыполнимая мечта. Ky-
да проще организовать коопeративнyю мно-
гозадачноcть (далее  КМ), которая позво-
лит "переключаться"  из  процесса в про-
цесс.  Но тем не менее, есть прерывания,
в  которых можно будет размещать быстрые
по  скорости выполнения процедуры. И это
может  в какой-то степени даже komnehcu-
ровать отсутствие ВМ.                   
                                        
   Я неоднократно задумывался над реали-
зациeй "буфера обмена" (clipboard'а, ка-
рмана), позволяющего переносить однотип-
ные  данные из одной программы в другую.
Для этого потребуется довольно приличный
кусок  памяти (собственно,  буфер). Есть
много способов обойти и этот "угол". На-
пример, в случае нехватки буфера, остав-
лять "закладку"-указатель в одной из пе-
ременных  ОС,  а когда эти данные (пусть
не прозвучит это по виндовcномy:)) будут
"вставляться"  в  другое приложение, не-
хитрыми манипуляциями перенести эти дан-
ные "порциями" через собственно буфер. А
размер  буфера пусть определяется setup'
ом (то есть, установками пользователя). 
                                        
                 - - -