ZX Time #11

Тема ОС - Решились мы все-таки на организацию специального раздела для обсуждения темы, которая, несмотря на смелые заявления некоторых личностей,тем не менее очень волнует спектрумистов.

                               Тема >ОС<
----------------------------------------
                                        
    В ранней юности мышцы своих челюстей
    Я развил изучением права,           
    И так часто я спорил с женою своей, 
    Что жевать научился на славу!       
                          /Льюис Кэррол/
                                        
   Редактор: Решились мы все-таки на ор-
ганизацию специального раздела для обсу-
ждения темы, которая, несмотря на смелые
заявления некоторых личностей,тем не ме-
нее  очень волнует спектрумистов. В этом
разделе  будут  помещаться  различнейшие
заметки,  суждения,  примеры, дискуссии,
комментарии, и т.д., касающиеся реализа-
ции на Спектруме новой операционной сис-
темы. Поэтому обращаюсь ко всем небезра-
зличным - ПИШИТЕ!!!                     
                                        
   Первая  статья  в  данном  разделе  -
размышления   Владислава   Семченко   из
г.Харькова   о  реализации  т.н.  ZerOS.
Предоставляем ему слово:                
                                        
                 - - -                  
                                        
ZerOS                                   
----------------------------------------
                      Владислав Семченко
                                        
   Поскольку адресное пространство памя-
ти  Z80  ограничено  16-ю  разрядами или
бЧКб, то заполнение этого минимума еще и
OS'ью крайне нежелательно с точки зрения
программиста  на  ассемблере.  По  моему
скромному мнению именно проблема нехват-
ки  памяти и является причиной, по кото-
рой  на  Speccy  не прижилась ни одна из
ОSей, предложенных в свое время програм-
мистами. Конечно можно возразить, что на
Speccy  можно  установить 128Кб и более,
но  не  следует  забывать, что это будет
отображаемая  память  в  отличие от бЧКб
памяти  прямого доступа. Иначе говоря, у
процессора   нет   средств  эффективного
обращения  к памяти свыше бЧКб. Доступ к
остальному   объему  производится  через
механизм подмены страниц памяти, то есть
-  через очень быстрое блочное устройст-
во. Линейное адресное пространство свыше
бЧКб,  которое имеется у Z380 и eZ80, не
в счет, поскольку пока базовым процессо-
ром Speccy является только Z80.         
                                        
  Описываемая ниже идея позволяет отдать
в распоряжение задачи пользователя прак-
тически все  бЧКб адресного пространства
памяти процессора, и при этом достаточно
комфортно разместить OS.                
                                        
   Итак, к сути идеи. Для простоты изло-
жения  материала  считаем, что компьютер
содержит  две области памяти, назовем их
полями  (field), объемом по бЧКб каждая.
Каждое из полей в равной степени принад-
лежит процессору,  располагается во всем
его адресном пространстве и не пересека-
ется со  своим дублером. Эти две области
памяти располагаются как бы на двух сто-
ронах одной монеты никогда не встречаясь
друг с  другом. Последнее утверждение не
совсем верно, но об этом чуть ниже. Одно
из полей закреплено за ОSью, а второе за
задачей/задачами пользователя.          
                                        
  Система взаимоотношения  полей напоми-
нает механизм подмены страниц памяти, но
во-первых производится  замена  не  1бКб
страницы, а  сразу  всех бЧКб, во-вторых
переключение полей осуществляется не че-
рез  порт, а  через команду проца RST 0,
которая почти  никогда  не используется.
Такое   решение  позволяет  упростить  и
ускорить  механизм  обмена  полей,  а  в
дальнейшем  избавит от головной боли при
переходе на Z380 или eZ80.              
                                        
  Как известно,  по  команде  RST 0 и по
RESET (а также  по  TRAP  в Z380 и eZ80)
процессор производит  выборку  команды с
адреса #0000,  устанавливая  все разряды
шины адреса  в "0".  Это свойство мы ис-
пользуем для управления работой триггера
переключения полей.                     
                                        
  А теперь настало время объяснить - как
это все  работает на практике. Предполо-
жим,  что процессор выполняет программу,
находясь в поле field0. Встречая команду
RST 0 процессор кладет содержимое регис-
тра  РС  на  вершину стека и переходит к
выполнению   команд,  начиная  с  адреса
#0000.  В  тот момент, когда все разряды
шины  адреса  устанавливаются в "0", со-
провождаемые  активными  сигналами MREQ,
RD и М1, происходит переключение тригге-
ра и подмена поля field0 на field1.  При
этом процессор продолжит выполнение про-
граммы,  находясь  уже  в  поле  field1.
Возврат в поле field0 также производится
по команде RST 0 (см.рис.).             
                                        
+->#0000+-------+ +->#0000+-------+     
|       |field 0| |       |field 1|     
|       |       |-+       |       |----+
|       +-------+         +-------+    |
+--------------------------------------+
                                        
  Основная проблема при переключении по-
лей  -  сохранение  и запись содержимого
регистра указателя вершины стека. Дело в
том, что производя обмен полей мы теряем
стек! Каждое  поле будет вынуждено иметь
свой  стек. Кроме того, из этого следует
и то, что передача параметров через стек
также оказывается невозможной - парамет-
ры  необходимо  передавать  в регистрах.
Процедура обслуживания стека может иметь
примерно такой вид:                     
                                        
0000     LD (nn),SP   ;сохранение SP    
                      ;"старого" поля   
0003     LD SP,(mm)   ;восстановление SP
                      ;"нового" поля    
0006     RET          ;переход к под-   
                      ;программе        
                                        
   Данный фрагмент должен присутствовать
в начале обоих полей. Это позволит рабо-
тать  OSu и задаче пользователя дополняя
друг друга. Важно только чтобы OSb перед
окончанием  своей  работы кидала на свой
стек  адрес обработчика программных пре-
рываний и только потом передавала управ-
ление  задаче пользователя. Если Вас та-
кой вариант не устраивает, то в поле OSu
можно  разместить такую процедуру обслу-
живания стека:                          
                                        
0000     LD (nn),SP   ;сохранение SP    
                      ;"старого" поля   
0003     LD SP,(mm)   ;восстановление SP
                      ;"нового" поля    
0006     JR 0008      ;                 
0008     ..........   ;обработчик преры-
                      ;ваний            
                                        
  Как уже  было  сказано, поля field 0 и
field1 независимы друг от друга и в при-
нципе не должны пересекаться, но абсолю-
тная ортогональность  полей  невозможна.
Дело в  том,  что  поле OSu должно иметь
доступ к  полю задачи ну хотя бы с целью
установки процедуры  обслуживания стека,
не говоря уже о том,что все процедуры по
загрузке/выгрузке массивов  памяти  поля
задачи  пользователя, а также выполнению
ряда других задач, должна  выполнять OSb
из своего поля.                         
                                        
  Для  программистов,  которые  пожелают
воспользоваться  данной идеей и быть мо-
жет  напишут OSb для Spectruma, хотелось
бы порекомендовать придерживаться следу-
ющего назначения при использовании реги-
стров  при  передаче параметров, которое
во  многом  совпадает с предложенным Zi-
logom для макрокоманд процессора:       
                                        
  I      - номер программного прерывания
  IX/IY  - функция прерыания            
  А/А'   - аргумент                     
  ВС/ВС' - счетчик                      
  DE/DE' - приемник                     
  HL/HL' - передатчик                   
  F/F'   - флаги                        
  РС     - счетчик команд               
  SP     - указатель вершины стека      
  R      - счетчик                      
                                        
  В заключении  хотелось бы сказать, что
данная фишка не носит вредного атависти-
ческого действия  и  софт написанный под
нее  не потребуется переделывать при пе-
реходе  на  Z380 и eZ80. Кроме того, при
переходе на новые процессоры само устро-
йство автоматически исчезает! Все дело в
том, что  при  использовании Z380 и eZ80
меняется обработчик по адресу #0000, ко-
торый уже  будет  не  только сохранять и
восстаавливать значение SP,но и при каж-
дом обращении по RST 0 сменять адрес пе-
рехода процессора в диапазоне 1бМб.     
                                        
                 - - -                  
                                        
  Редактор: А следующий материал предос-
тавил для публикации ставший в последнее
время "неимоверно"   плодовитым  автор -
KilleRam (целых две!!! статьи за неделю!
Если учесть, что я одну несчастную заме-
тку из него "выбивал" несколько месяцев,
то  это "пришествие мыслей" просто удив-
ляет:)))).                              
                                        
  Статья KilleRam'а соединяет в себе не-
сколько тем, непосредственно связанных с
проблемой  ОС на Спектруме. Возможно не-
которые темы покажутся уж больно неправ-
доподобными (как  и мне), но как утверж-
дает сам Коля, все вполне реализуемо!   
                                        
                 - - -                  
                                        
Почему???                               
----------------------------------------
              Николай Дворник /К!LleR@М/
                                        
  Вы  спросите:"почему статья называется
"ПОЧЕМУ?!!".  Отвечаю - потому что в ней
я расскажу  про то, что меня бесит. А на
данный момент меня раздражают две вещи: 
                                        
1. Отсутствие нормальной ОС на SPECCY:  
  а) отсутствие многозадачности;        
  б) неудачно   организованое   дисковое
     пространство;                      
  в) закрытая архитектура;              
  г) отсутствие развитой системы драйве-
     ров;                               
2. Проблема "SPECCY INTERNET EXPLORER". 
                                        
             Вопрос первый              
            ---------------             
          Многозадачность и ОС          
                                        
  Я  уже не могу молчать, так как в ред-
акцию  газеты пришло огромное количество
несколько некорректных откликов по пово-
ду статей про ОС и реализацию многозада-
чности... Если кто-то думает, что SPECCY
в  этом вопросе проигрывает иным платфо-
рмам,  то  предлагаю либо прекратить чи-
тать эту статью, либо ознакомиться с ни-
жеприведенным  текстом, где я постараюсь
изложить свою позицию по этому поводу.  
                                        
  Во-первых, я допускаю, что многозадач-
ность  будет  и не realtime, но зато она
серьезно  облегчит работу на нашем ТИТА-
НЕ,  хотя, на системных задачах realtime
просто-напросто ZARULIT!!!              
                                        
      Как я себе это представляю:       
     -----------------------------      
                                        
  1. Идет исполнение программы:         
    а) программа  написана   специальным
       стилем.  Точнее - все  на JR'ах и
       мы  спокойно, в любой момент вре-
       мени кидаем ее в свободную память
       и продолжаем исполнение;         
                                        
    б) прога написана стандартно, но  ее
       длина  указана с учетом стека ис-
       пользуемых  ячеек  памяти.  Ясно,
       что  при этом стек и ячейки лежат
       "недалеко" от основной программы.
                                        
  2. Пришли  прерывания.  Ясно,  что  не
     IM2, а специальные (например, "при-
     ручим" NMI, или контроллер прерыва-
     ний, что-то вроде IM2, но с возмож-
     ностью  задания  временных интерва-
     лов)  идем на обработчик, ДИСПЕТЧЕР
     ЗАДАЧ,  он программу останавливает,
     сохраняет  РС в таблицу (RELOCATION
     TABLE, о формате позднее), длина  в
     ней  уже записана изначально, запи-
     сывает  в какой банк она будет рез-
     мещена (разбивать  MEMORY  на банки
     по  1бкб или блоки переменной длины
     (256-16384Ь - еще не решено), в ка-
     ком  банке она должна исполняться и
     с  какого адреса должна размещаться
     записано изначально. При переключе-
     нии между задачами текущая приоста-
     навливается по вышеуказанной схеме,
     а  та,  на которую переключились, в
     соответствии с RT перебрасывается и
     запускается с адреса последнего ос-
     танова.                            
                                        
  3. Весь процесс повторяется занаво.   
                                        
  Задачи не могут пересекаться областями
данных,  совместно  можно   использовать
буфер  и  экран:), все это контролирует-
ся  ДИСПЕТЧЕРОМ  и  СИСТЕМНЫМ МОНИТОРОМ.
Хочу всем "несогласным" сказать, что это
все  не  чес - все написано и проверено,
работает,  как  говорит  VNN - "чикы-пы-
ки!".                                   
                                        
             Вопрос второй              
            ---------------             
        SPECCY INTERNET EXPLORER        
                                        
  Вы,  наверное, скажете, что это бред и
от  части будете правы (поймете почему).
Я  хочу  заметить,  это один из проектов
над которыми я работаю. На данный момент
я изучаю по-немногу ТСР/IP-протоколы (уж
больно    их    плохо    расписали    на
CODENET.RU).                            
                                        
  Я  не предлагаю сделать копию mustdie'
евского.  Напротив - я  предлагаю  отка-
заться  от  HTML,  JAVA,  FLASH (хотя со
временем  HTML можна зафигачить), и соз-
дать свой формат гипертекста, основанно-
го  на управляющих кодах (по типу неско-
лько  дополненного формата текста, кото-
рый  ТЫ сейчас читаешь) с поддержкой за-
качки и т.д.                            
                                        
  Вы  спросите - почему  INTERNET,  а не
FIDO,  ZX-NET и т.д.?  Да потому что они
не  такие глобальные и организация в них
WEB-структуры будет затруднительна.     
                                        
  Как  вы  уже  поняли I-NET в описанной
мной  системы используется как поисковик
и  никто не сможет просматривать SPECCY-
сайты  на других платформах (они ж тупые
уроды:)). Вы скажете, что Z80 не потянет
скорости I-NET'а?  Решение такое: ставим
DMA и модем с АТМ'а (тот, что сделан как
ЦАП-АЦП)   и  получаем  такие  скорости,
что даже ZyXEL Prestige DeLUXE будет со-
сать:),  нам-то  всего-то  надо  текст в
спец.формате перетянуть с сервака, а Z80
его обработает, а файл закачать - вообще
ерунда!!!                               
                                        
  Главная  проблема: создать свой сервак
(идеал - LINUX) и размещать на нем стра-
ницы за небольшую плату. Почему за плату
вы наверное поняли.                     
                                        
  Почему не на халявных серваках? Да по-
тому  что они размещают рекламу на твоей
странице, а в таком формате страницы это
не реально.                             
                                        
                 - - -                  
                                        
  Редактор:  Я  нарочно  не  комментирую
статью KilleRam'а, хотя у меня прямо-та-
ки  язык чешется:)... Хочу чтобы вы, чи-
татели,  сами  высказали свое мнение обо
всем вышесказанном.                     
                                        
   И  последнее,  что  я хотел сделать -
это  произвести  небольшой  обзор писем,
пришедших  в  редакцию,  касающихся ОС и
многозадачности.                        
                                        
   Одним из первых по этому поводу напи-
сал Михальченков Дмитрий:               
                                        
    МД:"1. На счет статьи о ОСке. Дело в
том,  что  убить БасикЧ8 в пользу ОСи не
удастся! Да действительно басик уже  из-
жил  себя, на нем сейчас практически нет
программ, но...  Когда я начинал кодить,
то обильно юзал подпрограммки из ПЗУ ба-
сика, а вы не такие были? И что мы полу-
чим, если грохнем его? Получим более 50%
нерабочего софта..."                    
                                        
   DWT:  Скажу  даже  больше - не пойдут
все 90% программ! Интересно, где я пред-
лагал  убивать  BASIC48?!!  Я всего лишь
писал о том, чем служит BASIC48 совреме-
нному (подчеркиваю - СОВРЕМЕННОМУ) Спек-
труму. И, повторюсь, он служит запускал-
кой программ в машинном коде. Но идти на
такую  радикальную  меру, как устранение
BASIC48  - это более чем глупо и недаль-
новидно. Ведь это породит не только лиш-
ний,  извиняюсь, геморрой (придется хотя
бы  основные  системки  переделывать под
нужды новой ОС), но и тотальную несовме-
стимость  -  что вызовет полную апатию к
новой ОС у пользователя.                
                                        
   МД:"Есть два выхода:                 
1) Писать так, чтоб все процедуры  оста-
лись  на  своих  местах... - маразм! Это
просто адское мучение! А выигрыш все од-
но получится нулевой, практически. Такая
история  была  уже с ПЗУ TR-DOS для Бай-
тов.  У  нормальных  Байтов ТР-ДОСи нет,
они  поставлены  на  СР/М, да и порты на
контроллере  совсем  другие  -  так  что
просто так ПЗУ ТРДОС не поставишь... Что
делать?  Находчивые спектрумисты ухищри-
лись  и  написали  новую ПЗУ ТР_ДОС, где
все адреса портов переводятся из станда-
ртных  для ТРДОС под адреса своего конт-
роллера. При этом заработала лишь 70-80%
из всего софта, что ни делай, а предска-
зывать трудно..."                       
                                        
   DWT:  А  по  сему - BASIC48 оставим в
полном  покое!  Мы  не  в коем случае не
должны терять совместимость с программа-
ми, написанными под TRDOS&BASIC48!      
                                        
   МД:"2)  Не  трогать  ПЗУ  БейсикЧ8, а
посмотреть в сторону ПЗУ Б128..."       
                                        
   DWT: Именно это я и предлагаю!       
                                        
   МД:"...либо  придумать  что-то ориги-
нальное.  Ведь  нормальную  ОСь в 16к не
заткнешь,  по любому придется дрова гру-
зить, а лучше всего оставить в ПЗУ толь-
ко универсальные дрова, тест компа,  ка-
кой-нибудь  дебагер-монитор  и загрузчик
ОСи..."                                 
                                        
   DWT:  Можно  и так. А лично я считаю,
что  в ПЗУ должны находиться только важ-
нейшие и неменяющиеся со временем проце-
дуры  (допустим, обращение с дисководом,
драйвер  клавиатуры,  и другое), а также
"механизм" обращения к ресурсам системы,
также  желательно независимый от "манев-
ров времени". Все остальное - на внешних
накопителях либо на ROM-диске.          
                                        
   МД:"...Мне  кажется второй способ бу-
дет  выгоднее.  Что  мы получим прописав
ОСь в ПЗУ - очередную ТРДОС или хуже то-
го  - бейсикЧ8-2! Я не любитель ИС-ДОСа,
но  она  отличалась  особой  универсаль-
ностью  уже тем, что не зависела от ПЗУ,
не считая hdd версии, но и там был толь-
ко  загрузчик,  который можно было заме-
нить загрузкой с дискеты... Для начинаю-
щих ПЗУ бейсика - это важнейшая база!"  
                                        
   DWT: Нет, не получим бейсикЧ8-2. Хотя
бы из-за того, что сейчас цели несколько
другие.  Да  и  средства  их  достижения
(технологии кода) тоже несколько выше.  
                                        
   Следующее, довольно интересное и кон-
структивное  письмо  прислал Дмитрий Те-
рентьев (DEMON/DPC):                    
                                        
    ДТ:"...Меня как и всех волнует судь-
ба всеми нами любимого Speccy, поэтому я
вам  и  пишу.  Давно стало всем понятно,
что  на  одном тр-досе далеко не уедешь,
прогресс ид т впер д, а мы стоим на мес-
те  (мы  - это спектрумисты), точнее, на
фронте операционных систем подвижек нет.
Вот  этот-то  вопрос меня больше всего и
волнует.  Медленно,  но  уверенно растут
аппаратные  возможности  нашего  Speccy.
Память  метр и больше, кмос часы, звуко-
вые  карты (General и DMA USC), аппарат-
ный  мультиколор  и  многое  другое.  Да
только  тр-дос  с флоповодами на 5 и 3.5
дюйма,  предел которой 800 кило, то есть
менее,  чем 1 мегабайт, что согласитесь,
не есть хорошо..."                      
                                        
   DWT:  Тут Дмитрий затронул весьма ин-
тересную  и очень спорную тему. Проблема
"роста железа без роста программных тех-
нологий" на мой взгляд является одной из
самых  острых.  И это касается не только
Спектрума. Вернее даже Спектрума в мень-
шей  степени. Ведь он смог продемонстри-
ровать  очень  и очень многое как раз не
развиваясь  в  техническом плане. Имея в
своем    арсенале   оригинальный   экран
256х192,  быстродействие 3.Sмгц и память
в  128кб наши программисты смогли выжать
из  Спектрума  казалось  бы  просто  не-
вероятные   вещи.  Что  касается  других
платформ  (РС например), то "у них" рост
"железячных  технологий" всегда опережал
рост  технологий программирования (далее
ТП).  Я боюсь ошибиться, но по-моему эти
самые  ТП переживают "обратный процесс",
то есть по-просту - деградируют. "Ихним"
производителям  легче  (и, вероятно, де-
шевле)  увеличить тактовую частоту и па-
мять,  нежели  вылизать программный код.
То  есть,  если бы "потолком" "у них" на
протяжении   допустим  7-8  лет  был  бы
Pentium-100 с 8 мегабайтами ОЗУ и увели-
чивать эти показатели было бы ой-как до-
рого и бесперспективно, то ТП значитель-
но  выросли  бы  на  несколько лет. Ведь
"выше  крыши"  не  полезешь,  а  по сему
просто  пришлось бы искать какие-то пути
оптимизаций.  Что касается Спектрума, то
у  нас  все  с точностью до наоборот - в
плане ТП развитие если не стопроцентное,
то  уж  точно больше, чем пятидесятипро-
центное.  Следовательно, пора наращивать
железо.  Но внутренняя организация Спек-
трума, его схематическое решение, а так-
же особенности, в которых он появился на
территории современного СНГ не позволяют
серьезно  и,  что главное, безглючно на-
растить  его технические характеристики.
Но  тем не менее, память, звук и некото-
рые  другие характеристики удалось более
или  менее  успешно  нарастить.  Однако,
стала актуальна проблема стандартизации.
ОС Спектрума не предусматривала дальней-
шего "апгрейда железа" и тем более в та-
ких  "особенных"  условиях  как  у нас -
только  стандартов  расширенной памяти с
десяток!  Из  которых  как  минимум один
(Pentagon-1024)  обнаружить  невозможно,
если только не знаешь, что этот мегабайт
у тебя есть (из-за "защелки 48"). Вывод?
Нужна  новая ОС и она была нужна еще лет
шесть назад!..                          
                                        
   ДТ:"...Вывод:  нужна новая операцион-
ная система! И ОС которая будет обслужи-
вать, как дисковые накопители (FDD, HDD,
CD-ROM), так и память компьютера, задача
программистов  сразу  упростится,  им не
надо  будет  ломать голову над тем какие
порты  расширения памяти на том или ином
компе и как определить сколько там кило-
байт,  ОС  предоставит  эти сведения ему
(конечно при наличии драйвера)..."      
                                        
   DWT:  Как  мне  кажется,  сведения  о
компьютере  должны  быть  сформулированы
(сконфигурированы)  самим  пользователем
при  начальной  инициализации ОС (допус-
тим,  что  эти сведения и драйвера будут
прошиты либо в самой ОС, либо в ROM-дис-
ке).  Просто  у  запускаемых программ не
будет  возникать каких-либо вопросов по-
поводу "железа", а следовательно - проб-
лема стандартизации будет исчерпана.    
                                        
   ДТ:"...Сразу  решится проблема диско-
вой  памяти,  винт на 1Г сейчас стоит не
более  300р.  CD-ROM - музыку послушать,
и на болванках архив спектрумовских про-
грамм  в  TRD-образах хранить. Некоторые
скажут,  CD  - это лишнее, но CD х2, х4,
х8  тоже недорого стоят, а интерфейс вс 
равно  тот  же  - IDE. Теперь о файловой
системе.  Файловая  система  должна быть
FAT32  (на  винте, на дискетах FAT12), а
тр-досовая система тоже должна поддержи-
ваться (ну куда без этого), но для поль-
зователя  она  должна быть прозрачна, то
есть  он  может о ней и не знать, но вс 
должно работать..."                     
                                        
   DWT:  По-поводу FAT32 и FAT12. На мой
взгляд,   нет  смысла  использовать  эти
структуры  для Спектрума. Ему необходима
несколько   другая,  рассчитанная,  если
можно так сказать на спектрумовский "ме-
нталитет" система. Естественно  "апгрей-
дить  TR-DOS"  дело бесперспективное, но
разработать  нечто  более  подходящее по
духу  для него вполне возможно. Ведь чи-
тать  и  "понимать"  MS-DOS на Спектруме
все-таки  "тормозно" - там много такого,
что  Спектруму  просто не нужно. Однако,
упрощать  FAT12  не  следует - это будет
лишь мутацией.                          
                                        
   ДТ:"...На  CD-ROMax  файловая система
не  FAT,  а какая-то другая (по слухам),
но  я  не  уверен,  если  кто-то  что-то
знает,   то   просьба   кинуть  на  мыло
(demon_zx@fromru.сом).                  
                                        
   Впрочем  все  эти  идеи  не мои - это
концепция NeOS, может кто слышал, но по-
хоже этот проект заглох.                
                                        
   ВНИМАНИЕ!!!  Если  этот  текст читают
авторы  этой  системы  - просьба отклик-
нуться  или  хотя бы исходники прислать,
если  вы  не  хотите этот проект продол-
жать.                                   
                                        
   Мораль  сей басни такова: нужна новая
операционная   система,  чтобы  Спектрум
жил, и участие в е  создании должны при-
нять  все  спектрумисты,  не кодом - так
идеей.   Предлагаю   в   ZX-Time  ввести
отдельный  раздел  для  обсуждения этого
вопроса,  в  котором  будет оттачиваться
концепция ОС.                           
                                        
   Также  идеи  можете  присылать на мой
адрес:   demon_zx@fromru.сом.  Да  и  не
только идеи по этому вопросу, можно про-
сто  так  писать, хоть буду знать что не
только я один остался на Спектруме.     
                                        
   А  в Курске похоже все кроме меня за-
били на Спектрум :..-(, если это не так,
адрес выше."                            
                                        
   DWT: Спасибо за хорошее письмо.      
                                        
   Ну  вот,  пожалуй,  и все на сегодня.
Очень ждем писем!                       
                                        
                 - - -