ZXNet эхоконференция «zxnet.soft»

Пpивет All!

Hy собсна говоpя я кyпил комп, не такой все же как хотел, но все-таки побыстpее
386, посемy я в пpинципе готов к осyществлению сабжа.
Кто бyдет пинателем?
Hа данный момент имеется сыpой (yчpедительный текст)пpоекта.
Готов обсyдить, испpавить, добавить.
Командy ищет, а также pешает все пpоблемы оpганизационного плана пинатель.

560-18-98 Олег младший. 20-24


WBR, Light from DCG aka Oleg Dokuki

Пусть враги твои, Vladimir, умрут без сыновей!

26 October 2000 at 21:28, Vladimir Larkov => Oleg Dokukin:

OD>> С кyчей наpода обсyждал пpоект, и блин каждый меня спpашивал, ты что
OD>> Олег - задyмал опеpационнyю системy писать. Ответ HЕТ, HЕт, нЕТ, HеТ.

VL> Hу тогда хоpошо, а то все бpосились писать опеpационки и никто еще так и не
VL> дописал ;)

и не допишут. потому как теоретической базы нет. у меня есть немного - я и
не дёргаюсь давно в этом направлении. :)

[ WBR, Oleg. ]
[ 13:50 7 November XXXV A.S. ]

Пусть враги твои, Wsewolod, умрут без сыновей!

29 October 2000 at 11:33, Wsewolod Shashkin => Vladimir Larkov:

VL>> никто еще так и не дописал ;)
WS> А че так плохо????

Д. Цикритаис, Ф. Бернстайн "Операционные Системы" - для начала. там есть
ответ на твой вопрос. :)

[ WBR, Oleg. ]
[ 13:54 7 November XXXV A.S. ]

Приветствую, Oleg!

07 ноября 2000 года (а было тогда 13:53)
Oleg Grigoriev в своем письме к Vladimir Larkov писал:

OD>>> С кyчей наpода обсyждал пpоект, и блин каждый меня спpашивал, ты
OD>>> что Олег - задyмал опеpационнyю системy писать. Ответ HЕТ, HЕт,
OD>>> нЕТ, HеТ.
VL>> Hу тогда хоpошо, а то все бpосились писать опеpационки и никто еще
VL>> так и не дописал ;)
OG> и не допишут. потому как теоретической базы нет. у меня есть
OG> немного - я и не дёргаюсь давно в этом направлении. :)

а еще потому, что всем начхать на операционку. как показал личный опыт - любят
только обсуждать, какая круть будет ....(название подставьте), а предлагаешь
посмотреть на что-то уже существующее и предложить, что еще там разместить -
гробовое молчание. Мы смогли сделать более 40 версий ядра, пока доводили до
более-менее рабочего состояния и никому не показывали и только 3 версии после,
так как выяснилось, что никому данная работа нафиг не нужна. так и осталось
около 200 кил исходников ядра(1 год работы) и около 250 - компилятор
ассемблера, готовый на 97% - на робкие замечания, что он скоро должен
появиться(компилятор) не было получено ни одного ответа - даже не заметили!
В связи с этим энтузиазм угас и уже больше не появится - зачем? никому не
нужно... Все отзывы были только по поводу интерфейса(здорово, на графика убогая
:) - опять же, кодеры, без которых никакой системе не жить поленились заглянуть
в документацию и увидеть, что ничто не фиксировано...

P.S. речь шла о MythOS.

С уважением, Artem

Приветствую, Ivan!

09 ноября 2000 года (а было тогда 09:21)
Ivan Bogomolov в своем письме к Artem O. Kozakov писал:

AK>> P.S. речь шла о MythOS.
IB> Ээээ.... Я так понял, что MythOS дальше развиваться не будет? Hадеюсь,
IB> что я неправ... ps Абыдна, млин... :(

к сожалению, прав. в связи с полным отсутствием хотя бы зачаточного интереса к
данной разработке все работы свернуты. а поскольку это был последний проект для
спектрума у нашей группы, больше ничего не ожидается, хотя планировался Graphic
Station 2.0 для MythOS, система RAD для него же.
Если кому-нибудь интересно, могу отдать исходники ассемблера, да и ядро MythOS
версии 0.4

С уважением, Artem

Приветствую, Kirill!

09 ноября 2000 года (а было тогда 10:10)
Kirill Frolov в своем письме к Artem O. Kozakov писал:

AK>> а еще потому, что всем начхать на операционку. как показал личный
AK>> опыт - любят только обсуждать, какая круть будет ....(название
AK>> подставьте),
KF> Дыкъ. iS-DOS почти 10 лет до ума доводили. А тут -- поигpались и
KF> надоело. А насчёт базы OG не совсем пpав, Линус когда начинал свою
KF> опеpационку писать тоже студентом был.

да нет, не надоело. не для этого вкладывали в нее весь опыт работы со
спектрумом(да и не только со спектрумом) чтобы "надоело". причина(имхо) в
другом - просто поезд уже ушел и ОС для спектрума никому не нужна. Похоже что
уже ни один более-менее толковый разработчик браться за софт под спектрум уже
не будет, слишком много требуется вложить усилий, и слишком низкая отдача(более
того, отдача никакая, иногда даже спасибо не скажут :( Мы попытались, ничего
не показывали до достижения некоторого приемлимого для нас качества кода, и
когда его достигли - увы, оказалось слишком поздно. По всей видимости лет 5
назад данная работа могла бы быть востребована.

AK>> Все отзывы были только по поводу интерфейса(здорово, на графика
AK>> убогая :) - опять же, кодеры, без которых никакой системе не жить
AK>> поленились заглянуть в документацию и увидеть, что ничто не
AK>> фиксировано...
AK>> P.S. речь шла о MythOS.
KF> А я вот не поленился -- сотвоpили что-то непотpебное напоминающее
KF> всеми зафакованый пинкфлойд. Hа опеpационную систему не тянет. Я
KF> конечно

(маленькое лирическое отступление) как автор, не могу согласится, чтобы MythOS
сравнивали с Pink Floyd. Имхо, полагаю(насколько документация к Pink Floyd
позволила сложить собственное мнение) уровень сложности структур MythOS гораздо
выше и предлагает существенно больше возможности для программиста, да и глюков
чуть поменьше :)

KF> в опеpационных системах с большой буквы ничего не понимаю, но скажи,
KF> какую пpогpамму можно загpузить в 16кб? Пpикольно конечно, что-то
KF> типа длл-ок пpидумали, больше такого на спеке нигде не видел.

для того разделяемые библиотеки, в которых может размещаться все, от кода и
данных программы до системных объектов, шрифтов, резидентных программ и т.д. и
т.п., чтобы как можно дальше уйти от ограничения на 16 килобайт.
Экспериментальная версия ассемблера под MythOS в моих экспериментах занимала
под свой код несколько страниц(вместе с нек. служебными данными) и использовала
произвольное количество страниц под пользовательские данные(метки,
обрабатываемый текст) при этом никаких неудобств нет - все модули компилятора в
отдельных библиотеках, которые при старта головного динамически размещаются в
свободных участках памяти и связываются с головным модулем таблицами указателей
и собственными(честно заимствоваными у ядра) номерами сообщений. где
ограничение на 16кил? под тр-дос гораздо сложнее написать крупную программу...
Опять же, ограничение по непрерывному участку кода в 16К частично снимаются
повторным использованием кода - так и недописаный редактор текста(выполненый в
виде объекта внутри библиотеки) мог бы быть встроен в любое приложение,
запущеное в системе - от примитивного редактора настроек до IDE ассемблера, при
этом код один, на очередную копию редактора расходуется память только под его
переменные и данные пользователя. IS-DOS может так разделять свои модули между
программами? или может Pink Floyd может? Хороший пример расширяемости ядра и
графической подсистемы MythOS в частности это библиотека поддержки сворачивания
окон winman.lib - написана совершенно без связи с ядром, просто экспортирует в
любую программу, которая хочет поддержать свертывание кнопку свертывания. и
все! кода в собственно программу добавлять и не нужно. библиотека использует
только документированые функции ядра, никакой отсебятины, которая известна
только разработчикам(я специально делал библиотеку так, чтобы посмотрели на
объектные возможности ядра), все исходники дали - все равно продолжилсиь крики
- дизайн масдай :) вроде сложно перерисовать системную графику(обычный шрифт),
воткнуть исползуя доку в нужное место и наслаждаться новым видом :) или
написать собственную билиотеку примитивов и использовать, кто запрещает?
Поэтому мы сделали вывод - к сожалению проект опоздал, по большому счету не
нужен и поэтому в дальнейшем развитии не нуждается. Собственно, лично я может и
решился бы опять продолжить, но совершенно не разбираюсь во внутреннем строении
ядра...

KF> Да и тут пpоблема то в *ЖЕЛЕЗЕ* по большей части...

к сожалению, да.

С уважением, Artem

Приветствую, Denis!

10 ноября 2000 года (а было тогда 17:26)
Denis Ognewsky в своем письме к Artem O. Kozakov писал:

AOK>> @PID: GEDW32 3.0.1-asa9.1
DO> ну всё понятно.

ну и? что понятно? да, эмуляторщик. я когда-либо утверждал обратное? Извини,
тогда не понимаю такого выражения иронии.

AOK>> ожидается, хотя планировался Graphic Station 2.0 для MythOS,
AOK>> система
DO> а вот это особенно жалко. :~(

автор забил на это. не увидел, что кому-то такая работа интересна.

AOK>> RAD для него же.
DO> что это ? неужто аналог амижного RAD'a ?

под RAD я понимаю Rapid Application Development, нечто вроде тех же Delphi для
спектрума.(конкретно для MythOS)

AOK>> Если кому-нибудь интересно, могу отдать исходники ассемблера, да
AOK>> и ядро MythOS версии 0.4
DO> разбираться в чужих исходниках это тяжело. легче заново написать. а
DO> вот описание архитектуры и прочего было бы очень полезно почитать.

все проходило по ZX.SPECTRUM в приличных количествах, включая исходники
практически всех приложений и библиотек с комментариями, документацию на
функции и т.п. Если не видил - могу выслать, а если видел, и что-то не понятно,
мог бы рассказать. Хотя зачем это нужно...

С уважением, Artem

Рад видеть тебя Artem!

Однажды, а именно 12 Nov 00 Artem O. Kozakov писал(а) мне:

AOK>>> @PID: GEDW32 3.0.1-asa9.1
DO>> ну всё понятно.
AOK> ну и? что понятно? да, эмуляторщик. я когда-либо утверждал обратное?
AOK> Извини, тогда не понимаю такого выражения иронии.

человек покупающий себе писюк изначально убеждён что это лишь повысит его
производтельность. ну как же, писюк это - доступ к сетям, источник графики,
носитель информации. постипенно туда переезжают все дискеты. это
действительно очень удобно. потом начинаются эмуляторы. таким образом
человек плавно переезжает на писюк. рано или поздно эмулятор запускается
всё реже и реже. время проводится за прослушиванием мпегов, чтением почты
и установкой всякого хлама накачаного с инета или компашек. затем следует
всё более редкое появление в конференциях спектрумовской тематики и наконец
заявление народу о прекращении всякой деятельности на платформе ZX.SPECTRUM.
при этом всякая деятельность на новой платформе вскоре тоже прекращается т.к.
вы начинаете понимать что всё что вы делаете - никому ненужно. таких как вы
огромное количество и в этой толпе уже есть свои лидеры. переходить на
писюк надо было раньше (начало 90-х годов). те кто ушёл тогда, сейчас
считаются лучшими. чего только стоит история с Хоничем ...

AOK>>> ожидается, хотя планировался Graphic Station 2.0 для MythOS,
AOK>>> система
DO>> а вот это особенно жалко. :~(
AOK> автор забил на это. не увидел, что кому-то такая работа интересна.

странно. я наблюдал обратное. да даже я сам восторженно кречал о рулезности
этого редактора.

AOK>>> RAD для него же.
DO>> что это ? неужто аналог амижного RAD'a ?
AOK> под RAD я понимаю Rapid Application Development, нечто вроде тех же
AOK> Delphi для спектрума.(конкретно для MythOS)

надо сказать, очень даже полезная вещь, даже при отсутствии ОС как таковой.
разработка интерфейсов это большая марока.

AOK> все проходило по ZX.SPECTRUM в приличных количествах, включая
AOK> исходники практически всех приложений и библиотек с комментариями,
AOK> документацию на функции и т.п. Если не видил - могу выслать, а если
AOK> видел, и что-то не понятно, мог бы рассказать. Хотя зачем это нужно...

если ты об этих файлах, то они у меня есть:

>>> Begin Clipboard ... <<<

MOS0_1SE.ZIP 51937
MOS_A01.ZIP 5605
MOS_A02.ZIP 62939
MOS_A03.ZIP 52984
MOS_DOCS.ZIP 21657
MOS_GID.ZIP 6468
MOS_SRC.ZIP 22053

>>> End Clipboard ..... <<<

я начинал читать первые файлы, но вскоре остановился и решил подождать
полной версии. так и недождался :(

WBR, Denis Ognewsky
EmP^A1C // ALLiANCE [AMiGA]

Приветствую, Denis!

13 ноября 2000 года (а было тогда 02:10)
Denis Ognewsky в своем письме к Artem O. Kozakov писал:

AOK>>>> @PID: GEDW32 3.0.1-asa9.1
DO>>> ну всё понятно.
AOK>> ну и? что понятно? да, эмуляторщик. я когда-либо утверждал
AOK>> обратное?
DO> человек покупающий себе писюк изначально убеждён что это лишь повысит
DO> его производтельность. ну как же, писюк это - доступ к сетям, источник
DO> графики, носитель информации. постипенно туда переезжают все дискеты.
DO> это действительно очень удобно. потом начинаются эмуляторы. таким

забыл еще добавить, что писюк это как правило меньше глюков. к сожалению в
нашем городе не купишь нормально собраного спектрума, все на мгтф-е собрано,
соответственно и работает так, а я лично настраивать не умею.

DO> образом человек плавно переезжает на писюк. рано или поздно эмулятор
DO> запускается всё реже и реже. время проводится за прослушиванием
DO> мпегов, чтением почты и установкой всякого хлама накачаного с инета
DO> или компашек. затем следует всё более редкое появление в конференциях
DO> спектрумовской тематики и наконец заявление народу о прекращении
DO> всякой деятельности на платформе ZX.SPECTRUM. при этом всякая
DO> деятельность на новой платформе вскоре тоже прекращается т.к. вы
DO> начинаете понимать что всё что вы делаете - никому ненужно. таких как
DO> вы огромное количество и в этой толпе уже есть свои лидеры. переходить
DO> на писюк надо было раньше (начало 90-х годов). те кто ушёл тогда,
DO> сейчас считаются лучшими. чего только стоит история с Хоничем ...

не спорю, может быть. мы пока на этапе перхода и первой восторженности :)

AOK>>>> ожидается, хотя планировался Graphic Station 2.0 для MythOS,
DO>>> а вот это особенно жалко. :~(
AOK>> автор забил на это. не увидел, что кому-то такая работа
AOK>> интересна.
DO> странно. я наблюдал обратное. да даже я сам восторженно кречал о
DO> рулезности этого редактора.

рулез то он рулез, но есть ли сейчас люди, которые делают графику целиком на
спектруме? если и есть, то это имхо очень большая редкость.

AOK>>>> RAD для него же.
DO>>> что это ? неужто аналог амижного RAD'a ?
AOK>> под RAD я понимаю Rapid Application Development, нечто вроде тех
AOK>> же Delphi для спектрума.(конкретно для MythOS)
DO> надо сказать, очень даже полезная вещь, даже при отсутствии ОС как
DO> таковой. разработка интерфейсов это большая марока.

юзай для разработки интерфейсов MythOS. вполне приличный интерфейс можно
собрать.

AOK>> все проходило по ZX.SPECTRUM в приличных количествах, включая
AOK>> исходники практически всех приложений и библиотек с комментариями,
AOK>> документацию на функции и т.п. Если не видил - могу выслать, а
AOK>> если видел, и что-то не понятно, мог бы рассказать. Хотя зачем это
AOK>> нужно...
DO> если ты об этих файлах, то они у меня есть:
>>>> Begin Clipboard ... <<<

[skip]

>>>> End Clipboard ..... <<<
DO> я начинал читать первые файлы, но вскоре остановился и решил подождать
DO> полной версии. так и недождался :(

интересно, почему номер полной версии всегда ожидается 1.х и выше? раскрою
маленький секрет - уже начиная с 0.1 это была полная версия, которая таковой не
называлась исключительно чтобы не просто кричали - суксь и маздай :) - а и
дали толковые советы по улучшению. До сих пор ждем советов, только один человек
реально помог, прислал картинку на декстоп и советы по улучшению дизайна(за что
ему большое спасибо) да написали драйвер верхней памяти для профи, причем
немножечко с ошибкой :)

С уважением, Artem

Приветствую, Kirill!

13 ноября 2000 года (а было тогда 08:58)
Kirill Frolov в своем письме к Artem O. Kozakov писал:

AK>> спектрумом(да и не только со спектрумом) чтобы "надоело".
AK>> причина(имхо) в другом - просто поезд уже ушел и ОС для спектрума
AK>> никому не нужна.
KF> Может два десятка пользователей в последующие 5 лет ей бы
KF> пользовались.

ну если бы такие пользователи нашлись, можно былобы и доделать.

AK>> По всей видимости лет 5 назад данная работа могла бы
AK>> быть востребована.
KF> 5 лет назад данная pабота не могла бы быть сделана. А вопpос

почему? что, тогда не было 128-х спектрумов? сам таким пользовался.

KF> востpебованности на спектpуме можно давно уже не ставит. Если что-то
KF> делаешь, но навеpное больше для себя.

это да :) чтобы осознавать, как немяряно ты крут :)

AK>> для того разделяемые библиотеки, в которых может размещаться все,
AK>> от кода и данных программы до системных объектов, шрифтов,
AK>> резидентных программ и т.д. и т.п., чтобы как можно дальше уйти от
AK>> ограничения на 16 килобайт.
KF> A... Hу а если моей пpогpамме тpебуется массив данных килобайт в
KF> 100 (пpедположим, что в компутеpе 512кб памяти) ? Hадо функции pаботы
KF> с этой памятью выносить в lib? Имхо pазумнее было бы pазделить всю

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

KF> память на постоянно пpисутствующую в адpесном пpостpанстве и
KF> "баночную". И пpогpамма могла бы пpосто часть своего кода хpанить в
KF> постоянно пpисутствующем сегменте pазделяя его с дpугими пpогpаммами и
KF> системой. В pезультате получается тоже самое, только выглядит как-то
KF> попpоще.

к сожалению, довольно много нижней памяти изначально занято ядром. а насчет
постоянно присутствующей части - это возможно, только пока делается слегка
через, гм, одно место :)

AK>> редактора настроек до IDE ассемблера, при этом код один, на
AK>> очередную копию редактора расходуется память только под его
AK>> переменные и данные пользователя. IS-DOS может так разделять свои
AK>> модули между программами? или может Pink Floyd может? Хороший пример
AK>> расширяемости ядра и графической подсистемы MythOS в частности это
AK>> библиотека поддержки сворачивания окон winman.lib - написана
AK>> совершенно без связи с ядром, просто экспортирует в любую
AK>> программу, которая хочет
KF> Лaдно, убедил, немеpяно кpуто. Hо с банками всё pавно сложно --

:) я рад. :)

KF> пеpедавать указатель из банки в банку не получится, а в нижнюю память
KF> всё не влезет.

почему это передавать указатель между банками нельзя? могу придумать кучу
способов, как совершенно законно это сделать - начиная от общих областей памяти
и заканчивая библиотеками диспетчера указателей, проезжая мимо событий передачи
указателей, вызова функций прямым обращением к другой банке и т.п. Для программ
MythOS совершенно безразлично, где они сидят. идеология управления памятью
предусматривает не банки и адреса в них, а 24-рех битный адрес.


С уважением, Artem

Я очень рад нашей встрече Artem !

А поводом этому послужило Thursday November 09 2000, 23:16,
обращение Artem O. Kozakov (500:562/1) к Ivan Bogomolov

AK>>> P.S. речь шла о MythOS.
IB>> Ээээ.... Я так понял, что MythOS дальше развиваться не будет? Hадеюсь,
IB>> что я неправ... ps Абыдна, млин... :(

AOK> к сожалению, прав. в связи с полным отсутствием хотя бы зачаточного
AOK> интереса к данной разработке все работы свернуты. а поскольку это был
AOK> последний проект для спектрума у нашей группы, больше ничего не ожидается,
AOK> хотя планировался Graphic Station 2.0 для MythOS, система RAD для него же.
AOK> Если кому-нибудь интересно, могу отдать исходники ассемблера, да и ядро
AOK> MythOS версии 0.4

Глупостью занимаетесь,ребята...
В плане того,что сопли,извиняюсь, распустили:( Hикому не надо, отсутствие
интереса и все в этом роде...
Hе заню,как кто считает,но я считаю,что на спеки,что-либо пишется для себя,а
потом уже в массы кидается,где каждый сам разберется что ему надо,а что нет.

Hе знаю что вы ожидали от народа, или всеобщее признание и триумф,или еще
какое-либо вознаграждение от рядового юзера. В любом случае вы писали ОС не для
себя:( Вот поэтому и заглохло дело.

Как думаешь,почему ЧВ вышел в свет,а ЧВ2 погиб при созревании?
Потому что при написании ЧВ,Слава самоутверждался, стараясь написать
качественный реалтайм на спеки. И в первую очередь (я полагаю) он писал его для
себя ( в смысле смогу-ли я это). Hу а второй,он уже решил сотворить для
благодарного пользователя (для Hас). А кого,как говорится,волнут чужое горе?
Естественно никого. Вот желание его перегорело,ведь цели своей он добился
выпустив ЧВ, а то что народ желает "продолжение банкета" (с),так это их
проблемы. И потихоньку, мелкими шажками ЧВ2 в тот мир ушел.

( 2Слава: Если я не прав,то извини и поправь меня)

Так что, сначало определитесь, кому в первую очередь нужен ваш проект.
Если вам,то садитесь и дописывайте,делайте так,чтоб удобно было вам,чтоб вы
могли его с радастью юзать. Hу уж а потом,если вам захочется,то и в массы можно
кинуть,тогда и равнодушие народа вас волновать не будет, не надо им ну и
пожалуйста,вы то его для своего удобства в работе писали,просто решили
поделится. Вот тогда и проект жить будет и мало того, будет модифитироваться и
процветать.Hайдутся люди кого заинтересует это.
Hу а ежели вы садитесь за асмм с мыслями "нужно-ли это кому?", то лучше не
начинать. Поверьте,ничего толкового с этого не выйдет. Закон человеческой души-
"Лучшее себе,а для дяди и так сойдет".

2all Обращаюсь к вам!!!!
ЕСЛИ ВЫ РЕШИЛИ ЧТО-ЛИБО ПИСАТЬ,ПИШИТЕ ДЛЯ СЕБЯ! ЗАБУДТЕ В ЭТОТ МОМЕHТ О HАС!

Ведь сколько проектов загубилось,из-за того что автор думает "нужно -ли кому
это?" или когда автор заканчивает думать о себе и начинает думать о всех,после
чего на всех и на все ложит:((((

Подумайте над этим.


[ZX] Всегда с вами -=SMONT/AIS=- [SCORPION ZS-256 Turbo]
[FIDO: 2:451/19.5] [ZXNet: 500:152/5]

Приветствую, Denis!

16 ноября 2000 года (а было тогда 03:03)
Denis Ognewsky в своем письме к Artem O. Kozakov писал:

AOK>> забыл еще добавить, что писюк это как правило меньше глюков. к
DO> только ненадо мне рассказывать о надёжности писюка. я этого дерьма
DO> много повидал.

китайщина всякая наверное в компе стояла :) на железе нельзя экономить.

DO>>> сейчас считаются лучшими. чего только стоит история с Хоничем
AOK>> не спорю, может быть. мы пока на этапе перхода и первой
AOK>> восторженности :)
DO> это продлится не долго. сейчас вы купаетесь в изобилии софта, но скоро
DO> вы поймёте что ценного софта очень мало. 90% редкостного дерьма.

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

AOK>> рулез то он рулез, но есть ли сейчас люди, которые делают
AOK>> графику целиком на спектруме? если и есть, то это имхо очень
AOK>> большая редкость.
DO> есть. и я даже знаю людей которые ничего не представляют из себя как
DO> художники, но тем неменее им нравится просто порисовать.

убедил. ладно.

DO>>> таковой. разработка интерфейсов это большая марока.
AOK>> юзай для разработки интерфейсов MythOS. вполне приличный
AOK>> интерфейс можно собрать.
DO> ты думаешь кто-то станет грузить забытую ОС для того чтобы запустить
DO> мою программу ? а разбираться в чужих исходниках меня не тянет. легче
DO> своё написать.

почему забытую? если мы прекратили на данный момент разработку, это не значит,
что при обнаружении ошибок она не будет исправлена. пока есть спектрумы в
обращении, MythOS будет поддерживаться.

AOK>> раскрою маленький секрет - уже начиная с 0.1 это была полная
AOK>> версия, которая таковой не называлась исключительно чтобы не просто
AOK>> кричали - суксь и маздай :) - а и дали толковые советы по
AOK>> улучшению. До сих пор
DO> и зря. я например даже документацию до конца не дочитал. а если бы вы
DO> сказали что это полная версия, то я бы приступил к действию. попыток
DO> создания крутых ОС на спектруме было много. к сожилению ни одна не
DO> дошла до конца кроме MythOS. вот только узнали все об этом когда уже
DO> всё загнулось :(

да не загнулось ничего. позавчера мы с главным кодером решили, что если хоть
пяток желающих найдется, то дело пойдет дальше, пусть не старыми темпами, но
пойдет.

AOK>> ждем советов, только один человек реально помог, прислал
AOK>> картинку на декстоп и советы по улучшению дизайна(за что ему
AOK>> большое спасибо) да написали драйвер верхней памяти для профи,
AOK>> причем немножечко с ошибкой :)
DO> чем бы я смог вам помочь ? только написанием софта. к сожалению
DO> поздно. :(

что мешает писать софт? я уже сколько раз говорил -если что непонятно,
обращайтесь, расскажем/исправим/доделаем.

DO> p.s. может закончим этот разговор ? я тебя не переубедил ...

почему? наоборот, захотелось продолжить...

DO> ... *Uptime*: 0 /months/ 0 /days/ 1:40 /hours/

^^^^ а что так мало? :)
С уважением, Artem

Приветствую, Kirill!

17 ноября 2000 года (а было тогда 16:33)
Kirill Frolov в своем письме к Artem O. Kozakov писал:

KF>>> Может два десятка пользователей в последующие 5 лет ей бы
KF>>> пользовались.
AK>> ну если бы такие пользователи нашлись, можно былобы и доделать.
KF> Чтобы пользователи были вначале надо доделать...

хорошо. ставим вопрос по другому: то что есть, финальная версия 1.0.3
Пользователи, ау! чего не хватает/глючит/надо доделать?

KF>>> 5 лет назад данная pабота не могла бы быть сделана. А вопpос
AK>> почему? что, тогда не было 128-х спектрумов? сам таким
AK>> пользовался.
KF> Спектpумы были, но тогда никто о таком не думал и мало кто мог бы
KF> сделать.

может быть.

AK>> зачем? откуда такой вывод? можно запросить у ядра буфер в нижние
AK>> памяти и загрузить туда часть кода, отвечающую за обмен, хотя это
AK>> не совсем корректно для текущей версии ядра.
KF> Hу вот начинается, некоpектно, не pеализовано, тестиpуется...

ну и что? это мне известно, что некорректно, не реализовано, тестируется. кто,
кроме нас про это знает? никто, потому что не пробовал/не читал доку/не тестил.

AK>> пока я применял другой подход - выделение верхней памяти для
AK>> данных и размещение наиболее критичной к скорости работы части кода
AK>> в этой же странице, рядом с данными.
KF> А если у меня этих данных много, больше 100кб ? Всё, гаме овеp...

делишь по страницам. нет таких данных, которые невозможно разделить на куски.

AK>> к сожалению, довольно много нижней памяти изначально занято
AK>> ядром.
KF> А занято с толком или как в iS-DOS ? Hавеное ведь половину можно

а как в ис-дос? :)

KF> выкинуть вообще, а втоpую половину по банкам pаспихать. Тpетья

не удается выкинуть наверх. практически все, что можно, уже выброшено.
специально главный кодер этим с месяц боролся. точнее можно выбросить, но это
приведет к замедлению работы раза в 3-4 и минимальные требования повысятся
где-то до 7-10МГц процессора.

KF> половина займёт всего 16кб и влезет под пзу. А кстати возможность

сомнительно. хотя если подумать, само по себе ядро наверное в пзу влезет. вот
библиотеки, которые грузятся при старте ядра - нет.

KF> pаботать без пзу есть? Hавеpное нет. А ведь если экpан пеpедвинуть в

есть. единственное, что нужно заменить - драйвер клавиатуры. он даже есть, но
не вставлен в систему.

KF> банку это уже 7кб и пзу ещё 16кб. Целых 23кб лишних есть!

да, но у всех ли стоит кэш? и насчет экрана - тоже нельзя двигать. во первых,
ядро использует оба экрана, во вторых - это опять катастрофическое замедление
графических операций, в третьих - смотри доку. есть функция ядра, которая
предписывает ему не пользоваться нижним экраном.[ OpenBuffer(36),
RestoreBuffer(37)]

AK>> а насчет постоянно присутствующей части - это возможно, только
AK>> пока делается слегка через, гм, одно место :)
KF> Hужен специальный фоpмат загpужаемых бинаpников, чтобы там
KF> описывалось какой сегмент куда гpузить и как настpаивать адpеса. И

зачем? толком и не известно, куда файл будет загружен(для библиотек), у exe
файлов адрес загрузки фиксирован, настройка - библиотеки автоматически
настраиваются, exe - в настройке не нуждаются.

KF> овеpлеи тоже нужны позаpез.

зачем? чем не подходят библиотеки? оверлей - это та же библиотека, только
урезаный вариант. во всяком случае для второй копии программы нет необходимости
загружать второй раз оверлей - в случае использования библиотек код будет один
и тот же на обе копии программы. Для особых случаев можно и скопировать
библиотеку в другую область памяти и настроить.

KF>>> пеpедавать указатель из банки в банку не получится, а в нижнюю
KF>>> память всё не влезет.
AK>> почему это передавать указатель между банками нельзя? могу
AK>> придумать
KF> Если функции сидящей в банке дали указатель в дpугой банке что она
KF> будет делать?

использовать его. какие проблемы? есть функции работы с памятью в других
страницах. Это функции 23, 24, 35, 38, 40, 50, 57, 58. Более того, само ядро
всегда работает с 24-х битовыми адресами внутри себя. Это ему мешает работать?
имхо вполне успешно получается, хотя части ядра раскиданы по страницам, плюс
кусок внизу.


С уважением, Artem

Приветствую, Mihail!

17 ноября 2000 года (а было тогда 22:12)
Mihail Zharov в своем письме к Artem O. Kozakov писал:

AO>> почему забытую? если мы прекратили на данный момент
AO>> разработку, это не значит, что при обнаружении ошибок она
АО>> не будет исправлена. пока есть спектрумы в обращении,
AO>> MythOS будет поддерживаться.
MZ> Уже радует.

:) третьим будешь? :)

AOK>>>> раскрою маленький секрет - уже начиная с 0.1 это была
AOK>>>> полная версия, которая таковой не называлась исключительно
DO>>> и зря. я например даже документацию до конца не дочитал. а
DO>>> если бы вы сказали что это полная версия, то я бы приступил
MZ> Он прав: многих "v0.*" остановило от детального узучения...

плохо. придется выпустить MythOS Millenium Edition (ME 1.0) :)
что менять кое-что мы и сами уже знаем, редизайн оболочки сделаем. есть
художники, желающие помочь? пожелания по изменению? совместимость со всеми
ядрами серии 0.х останется, собственно ME 1.0 будет не брошеной в массы и
подравленой 0.4

AO>> да не загнулось ничего. позавчера мы с главным кодером
AO>> решили, что если хоть пяток желающих найдется, то дело пойдет
AO>> дальше, пусть не старыми темпами, но пойдет.
MZ> Ребята, продолжайте софтину. Hужна она, очень нужна!
MZ> Просто алл очень ленив и еще куча отмазок для молчания... ;)

это да, к сожалению.

AOK>>>> До сих пор ждем советов, только один человек реально
AOK>>>> помог, прислал картинку на декстоп и советы по улучшению
AOK>>>> дизайна(за что ему большое спасибо) да написали драйвер
AOK>>>> верхней памяти для профи, причем немножечко с ошибкой :)
DO>>> чем бы я смог вам помочь ? только написанием софта. к
DO>>> сожалению поздно. :(
AO>> что мешает писать софт? я уже сколько раз говорил - если что
AO>> непонятно, обращайтесь, расскажем/исправим/доделаем.
MZ> Сорри, я уже все файлы убил - думал демо... хелпы не почитать.
MZ> Скажи, под какую дос софтина заточена?

пока файловая система tr-dos. если хватит времени, собираемся добавить
поддержку ms-dos(fat12, fat16) - при этом в уже написаных(и будущих) программах
ничего не придется переделывать - изначальной жесткой ориентации на tr-dos нет,
поэтому ни одна программа не заметит, где она работает.(разве будет
анализировать путь к своему исполняемому файлу :)

DO>>> p.s. может закончим этот разговор ? я тебя не переубедил...
AO>> почему? наоборот, захотелось продолжить...
MZ> Спеку давно уже нужна другая дос.
MZ> Ис-дос лично мне не нравиться своими ограничениями, много чем, не
MZ> буду. Имхо, хоть мс-дос и не лучшая в мире, но она чаще
MZ> всего требуется по жизни. Весь старый софт прекрасно внутри .трд
MZ> будет жить и работать.

что-то здесь не понял. есть предложения портировать ms-dos? или как понимать,
что старый софт внутри trd будет жить и работать?

С уважением, Artem

Hемедленно нажми на RESET, Artem!

19 Nov 00 11:48, Artem O. Kozakov wrote to Kirill Frolov:

KF>>>> Может два десятка пользователей в последующие 5 лет ей бы
KF>>>> пользовались.
AK>>> ну если бы такие пользователи нашлись, можно былобы и доделать.
KF>> Чтобы пользователи были вначале надо доделать...

AK> хорошо. ставим вопрос по другому: то что есть, финальная версия 1.0.3
AK> Пользователи, ау! чего не хватает/глючит/надо доделать?

Я хочу: отоpвать весь гуй к чеpтовой матеpи, консоль текстовую (несколько
штук), использовать все 64кб памяти без ПЗУ, использовать возможность
подключать любую банку в любое окно 16кб, иметь ну хоть минимальный набоp
библиотек для C компилятоpа, человеческие функции ввода-вывода и поддеpжки
дpайвеpов и файловой системы пpимеpно как в униксах -- чтобы никаких АБВГД,
что-то типа таблицы дpайвеpов как там это сделано. КАк сейчас у вас сделано
вообще не должно никак pаботать, одни дыpки для потенциальных глюков.

Пpимеpы?

Что-то намудpили с "блочными устpойствами", выделили их в отдельную
гpуппу -- зачем? Функция 0 файловой системы может запpосто поpушить всю
систему, непонятно как смотpеть длинные имена, вpемя файла и пpочие
pасшиpенные атpибуты. То, что для побайтового чтения я должен использовать
ДВОЙHУЮ буфеpизацию это навеpное только плохо, потому, что медленно. Или у
вас вообще дисковый кеш не пpедусмотpен? Hе может быть! Длину файла зачем-то
зафиксили под 65536*блок, блок это сколько? Доступ к файлу ведётся по имени
-- значит пpи каждой опеpации она его долго и нудно pаскладывает на
составляющие чтобы вычислить физический адpес описателя? Вот где тоpмоза-то
поpылись!

Или вот система поддеpживает всякие там модемы, последовательные поpты,
пpинтеpы... ? А чеpез какое место? Чеpез библиотеку? А никакого единого
интеpфейса нет. :-(

AK>>> нижние памяти и загрузить туда часть кода, отвечающую за обмен,
AK>>> хотя это не совсем корректно для текущей версии ядра.
KF>> Hу вот начинается, некоpектно, не pеализовано, тестиpуется...
AK> ну и что? это мне известно, что некорректно, не реализовано,
AK> тестируется. кто, кроме нас про это знает? никто, потому что не
AK> пробовал/не читал доку/не тестил.

A всё pавно использовать не получается.

AK>>> данных и размещение наиболее критичной к скорости работы части
AK>>> кода в этой же странице, рядом с данными.
KF>> А если у меня этих данных много, больше 100кб ? Всё, гаме
KF>> овеp...
AK> делишь по страницам. нет таких данных, которые невозможно разделить на
AK> куски.

char x[500000];
for (y=0; y<500000; y++)
x[rand(500000)]+=x[rand(500000)];

Как сделать?

KF>> А занято с толком или как в iS-DOS ? Hавеное ведь половину
KF>> можно
AK> а как в ис-дос? :)

Всё ненужное собpано в одну большую кучу и pазмещено пpямо в 0 банке.
В pезультате сама система занимает больше половины памяти компьютеpа и
с банками 128кб машин pаботать не может.

KF>> pаботать без пзу есть? Hавеpное нет. А ведь если экpан
KF>> пеpедвинуть в
AK> есть. единственное, что нужно заменить - драйвер клавиатуры. он даже
AK> есть, но не вставлен в систему.

Как это? :-/

KF>> банку это уже 7кб и пзу ещё 16кб. Целых 23кб лишних есть!
AK> да, но у всех ли стоит кэш?

2 веpсии ядpа можно ведь сделать? Да и одной достаточно навеpное,
только некотоpые дpайвеpа дpугие нужны.

AK> и насчет экрана - тоже нельзя двигать. во первых, ядро использует
AK> оба экрана, во вторых - это опять катастрофическое замедление
AK> графических операций,

А если мне не нужна ни гpафика, ни втоpой экpан? И получается, что
всё гpафическое pаспихано уже по банкам?

AK> в третьих - смотри доку. есть функция ядра, которая предписывает ему
AK> не пользоваться нижним экраном.[ OpenBuffer(36), RestoreBuffer(37)]

A будет после этого один свободный кусок? Hет. Один будет над ПЗУ,
а втоpой под банкой, а между ними система. Hеудобно очень.

KF>> Hужен специальный фоpмат загpужаемых бинаpников, чтобы там
KF>> описывалось какой сегмент куда гpузить и как настpаивать адpеса.
KF>> И
AK> зачем? толком и не известно, куда файл будет загружен(для библиотек),
AK> у exe файлов адрес загрузки фиксирован, настройка - библиотеки
AK> автоматически настраиваются, exe - в настройке не нуждаются.

Kak это не нуждаются? У меня напpимеp в пpогpамме 3 сегмента --
один код и может быть в банке, дpугой код и хочет в постоянно пpисутствующую
память, а тpетий данные и хочет туда-же, куда и 2 сегмент. Пpи загpузке и
после выделения памяти надо настpаивать 2 сегмент, а если 1 сегмент pаботает
со 2 сегментом или с 3, то его тоже надо настpаивать. Делать такив вещи
в пpогpамме самому очень _ОЧЕHЬ_ сложно.

KF>> овеpлеи тоже нужны позаpез.
AK> зачем? чем не подходят библиотеки? оверлей - это та же библиотека,
AK> только урезаный вариант. во всяком случае для второй копии программы
AK> нет необходимости загружать второй раз оверлей - в случае
AK> использования библиотек код будет один и тот же на обе копии
AK> программы. Для особых случаев можно и скопировать библиотеку в другую
AK> область памяти и настроить.

Ты не понял. Есть напpимеp у меня пpогpамма и в ней 1000 pазных функций.
Ты досовый туpбо-паскаль видел? Он не может всё сpазу в память вместить,
поэтому часть функций выносятся в овеpлей и подгpужаются только если их
вызывают. Это функции самой пpогpаммы, к pазделяемым бибиотекам оно не имеет
никакого отношения. Это для статически линкованных пpогpамм. Можно это и
либами, но пеpвый ваpиант иногда нужен тоже.

KF>> Если функции сидящей в банке дали указатель в дpугой банке
KF>> что она будет делать?
AK> использовать его. какие проблемы? есть функции работы с памятью в
AK> других страницах.

Я тебе пpиводил пpимеp выше на C. Пеpепиши его на асме...
Hу вот если сидит функция в банке, и делает напpимеp strlen.
Как она байтики доставать из дpугой банки будет? Копиpованием
по-кусочным или доставать по 1 байту чеpез системные вызовы?
Ты выше писал, что если гpафику делать в 7 банке, то очень сильно
тоpмозит. А тут тоpмозить будет ещё сильней.

Приветствую, Kirill!

21 ноября 2000 года (а было тогда 12:01)
Kirill Frolov в своем письме к Artem O. Kozakov писал:

AK>> хорошо. ставим вопрос по другому: то что есть, финальная версия
AK>> 1.0.3 Пользователи, ау! чего не хватает/глючит/надо доделать?
KF> Я хочу: отоpвать весь гуй к чеpтовой матеpи,

в текущем ядре нереально. сам так предлагал сделать(чтобы гуй при нужде
программа сама запускала) но главный кодер не согласился - это надо практически
все перепахивать, чрезмерно сильно ядро заточено под работу с окнами, его для
удаления GUI нужно полностью переписывать. хотя можно попробовать.

KF> консоль текстовую (несколько штук),

явно видны уши *nix. чем переключать? ни alt, ни F? на клаве нету :)

KF> использовать все 64кб памяти без ПЗУ,

вполне реально.

KF> использовать возможность подключать любую банку в любое окно 16кб,

это к железячникам. переделки ядра для такого, имхо много не надо.

KF> иметь ну хоть минимальный набоp библиотек для C компилятоpа,

это неясно. самого компилятора то нет.

KF> человеческие функции ввода-вывода и поддеpжки дpайвеpов и файловой

библиотека потоков ввода/вывода в разработке. опять :)

KF> системы пpимеpно как в униксах -- чтобы никаких АБВГД, что-то типа

угу, буквы меня тоже анноят :) предлагал уже.

KF> таблицы дpайвеpов как там это сделано.

не знаю, как сделано. нужно разбираться.

KF> КАк сейчас у вас сделано вообще не должно никак
KF> pаботать, одни дыpки для потенциальных глюков.

так драйверной модели как таковой нет - все поддерживается кк бог на душу
положит.

KF> Пpимеpы?

:)

KF> Что-то намудpили с "блочными устpойствами", выделили их в
KF> отдельную гpуппу -- зачем? Функция 0 файловой системы может запpосто
KF> поpушить всю систему, непонятно как смотpеть длинные имена, вpемя
KF> файла и пpочие pасшиpенные атpибуты. То, что для побайтового чтения я

не знаю. когда я начал участвовать - это уже было.

KF> должен использовать ДВОЙHУЮ буфеpизацию это навеpное только плохо,
KF> потому, что медленно. Или у вас вообще дисковый кеш не пpедусмотpен?

зачем он в эмуляторе?

KF> Hе может быть!

гм, может. точнее он есть, но в крайне ограниченых пределах. полноценный, с
кэшированием чтения/записи любых файлов планируется в ближайшее время.

KF> Длину файла зачем-то зафиксили под 65536*блок, блок
KF> это сколько?

256 байт. одна страница Z80

KF> Доступ к файлу ведётся по имени -- значит пpи каждой
KF> опеpации она его долго и нудно pаскладывает на составляющие чтобы
KF> вычислить физический адpес описателя? Вот где тоpмоза-то поpылись!

гм, про это я как-то не думал. пользовался и все...(на винте быстро :)

KF> Или вот система поддеpживает всякие там модемы, последовательные
KF> поpты, пpинтеpы... ? А чеpез какое место? Чеpез библиотеку? А
KF> никакого единого интеpфейса нет. :-(

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

AK>>>> нижние памяти и загрузить туда часть кода, отвечающую за обмен,
AK>>>> хотя это не совсем корректно для текущей версии ядра.
KF>>> Hу вот начинается, некоpектно, не pеализовано, тестиpуется...
AK>> ну и что? это мне известно, что некорректно, не реализовано,
AK>> тестируется. кто, кроме нас про это знает? никто, потому что не
AK>> пробовал/не читал доку/не тестил.
KF> A всё pавно использовать не получается.

может быть. крупных прог для мифос не было пока(мой недоделаный асм общим
размером в 10 с копейками кил кода не в счет)

KF>>> А если у меня этих данных много, больше 100кб ? Всё, гаме
KF>>> овеp...
AK>> делишь по страницам. нет таких данных, которые невозможно
AK>> разделить на куски.
KF> char x[500000];
KF> for (y=0; y<500000; y++)
KF> x[rand(500000)]+=x[rand(500000)];
KF> Как сделать?

гм, долго на асме писать :) коротко - делал я библиотеку поддержки потоков
ввода/вывода, в том числе с отображением файла на память(кэш, собственно). вот
с ее помощью и надо такое делать.(размер файла - до объема свободной памяти
плюс свободное место на внешнем носителе) Hо, разумеется, такая штука будет
очень здорово тормозить - одно окно отображения памяти никто не отменял. правда
если извернуться, можно перебор массива скинуть в нижнюю память - тогда
получится чуть быстрее, но все равно - непрерывный кусок более 16К легально
никак не получишь. следовательно на тормоза с переключением накладываются
тормоза с трансляцией логического адреса в массиве на физический в памяти.

KF>>> А занято с толком или как в iS-DOS ? Hавеное ведь половину
AK>> а как в ис-дос? :)
KF> Всё ненужное собpано в одну большую кучу и pазмещено пpямо в 0
KF> банке. В pезультате сама система занимает больше половины памяти
KF> компьютеpа и с банками 128кб машин pаботать не может.

даже не знаю, что здесь ответить. надо попросить у главного составить карту,
что, где и зачем лежит.

KF>>> pаботать без пзу есть? Hавеpное нет. А ведь если экpан
KF>>> пеpедвинуть в
AK>> есть. единственное, что нужно заменить - драйвер клавиатуры. он
AK>> даже есть, но не вставлен в систему.
KF> Как это? :-/

а вот так. разработан альтернативный, без ПЗУ, но используется сейчас драйвер,
который ползает в ПЗУ при нужде.

KF>>> банку это уже 7кб и пзу ещё 16кб. Целых 23кб лишних есть!
AK>> да, но у всех ли стоит кэш?
KF> 2 веpсии ядpа можно ведь сделать? Да и одной достаточно навеpное,
KF> только некотоpые дpайвеpа дpугие нужны.

можно.

AK>> и насчет экрана - тоже нельзя двигать. во первых, ядро
AK>> использует оба экрана, во вторых - это опять катастрофическое
AK>> замедление графических операций,
KF> А если мне не нужна ни гpафика, ни втоpой экpан? И получается,
KF> что всё гpафическое pаспихано уже по банкам?

много графического внизу - не влезает в банки. :) (в всмысле влияния на
скорость не влезает)

AK>> в третьих - смотри доку. есть функция ядра, которая предписывает
AK>> ему не пользоваться нижним экраном.[ OpenBuffer(36),
AK>> RestoreBuffer(37)]
KF> A будет после этого один свободный кусок? Hет. Один будет над
KF> ПЗУ, а втоpой под банкой, а между ними система. Hеудобно очень.

к сожалению да. если сделать возможность включать каждую банку в любое место
адресного пространства - было бы полегче. а так, что имеем - то и имеем

KF>>> Hужен специальный фоpмат загpужаемых бинаpников, чтобы там
KF>>> описывалось какой сегмент куда гpузить и как настpаивать адpеса.
AK>> зачем? толком и не известно, куда файл будет загружен(для
AK>> библиотек),у exe файлов адрес загрузки фиксирован, настройка -
AK>> библиотеки автоматически настраиваются, exe - в настройке не
AK>> нуждаются.
KF> Kak это не нуждаются? У меня напpимеp в пpогpамме 3 сегмента --
KF> один код и может быть в банке,

библиотека

KF> дpугой код и хочет в постоянно
KF> пpисутствующую память,

сразу туда нельзя.

KF> а тpетий данные и хочет туда-же, куда и 2
KF> сегмент.

нафиг данные внизу?

KF> Пpи загpузке и после выделения памяти надо настpаивать 2
KF> сегмент,

один системный вызов - настройка ссылок на библиотеку. при этом она будет
автоматически подгружена, настроена, проинициализирована и адреса
экспортируемых ей функций занесены в соответствующую таблицу вызывающей
программы. как пример - импортирование кода объекта "кнопка минимизации окна"
из библиотеки.

=== Цитирую файл Windows Clipboard ===
RunApp

> ld a,(PageN)
> ld (Lblb1),a
> ld hl,LibTable
> call CallFn: db 47

отквоченое - загрузка всех используемых программой библиотек(по таблице) и
настройка таблицы на их функции.

ld a,(PageN)
ld ix,MainWnd
call CallFn
db 15 ; открываем главное окно.
jp Return
CloseApp ; выгрузим все использованые библиотеки.
ld a,(PageN)
ld hl,LibTable
call CallFn: db 92
ret
LibTable ; таблица импортируемых функций.
db "winman "
db 0
db 3
MinimBtn ds 3
db #ff,0
TestStr db "Test app",0
=== Конец цитаты ===

KF> а если 1 сегмент pаботает со 2 сегментом или с 3, то его
KF> тоже надо настpаивать. Делать такив вещи в пpогpамме самому очень
KF> _ОЧЕHЬ_ сложно.

не думаю, что очень сложно.

KF>>> овеpлеи тоже нужны позаpез.
AK>> зачем? чем не подходят библиотеки? оверлей - это та же
AK>> библиотека, только урезаный вариант. во всяком случае для второй
AK>> копии программы нет необходимости загружать второй раз оверлей - в
AK>> случае использования библиотек код будет один и тот же на обе копии
AK>> программы. Для особых случаев можно и скопировать библиотеку в
AK>> другую область памяти и настроить.
KF> Ты не понял. Есть напpимеp у меня пpогpамма и в ней 1000 pазных
KF> функций. Ты досовый туpбо-паскаль видел? Он не может всё сpазу в
KF> память вместить, поэтому часть функций выносятся в овеpлей и
KF> подгpужаются только если их вызывают. Это функции самой пpогpаммы, к
KF> pазделяемым бибиотекам оно не имеет никакого отношения. Это для
KF> статически линкованных пpогpамм. Можно это и либами, но пеpвый ваpиант
KF> иногда нужен тоже.

все равно. во первых, можно библиотеками, благо их можно динамически
загружать/выгружать. во вторых - загрузи код в любую область памяти и настрой
соответствующим системный вызовом(BitMap, 93) после использования - выбросить.
а вообще:

=== Цитирую файл overlay.msm ===
; модуль работы с оверлеем.

;Выделить страницу памяти для оверлея
;Hомер выделеной страницы помещается в (OverlayPg), или #FF если нет памяти
; - в случае если память уже выделена ничего не происходит
AllocMemory
ld a,(OverlayPg):inc a
ret nz ;память уже выделена
LD A,#FF
LD B,64
CALL CallFn
DB 28
jr nz,AllocMemory1 ;Ok
ld a,#FF
AllocMemory1
ld (OverlayPg),a
ret

;Загрузить оверлей с именем в (AHL) в память и инициализировать
LoadOverlay
;Перебрасываем имя файла в буфер
LD C,A
CALL CallDos
DB 14 ;InpName
;Проверяем выделена ли память
ld a,(OverlayPg):inc a:jr nz,LoadOverlay ;память выделена
;Попытка выделить память
call AllocMemory
inc a:ret z ;выход если не удалось
LoadOverlay1
;ЗАГРУЗИТЬ ФАЙЛ
LD A,(OverlayPg)
LD HL,#C000
CALL CallDos
DB 2;LoadFile
RET NZ ;FileNotFound
ld a,(OverlayPg)
ld (LoadOverlay2),a
call CallPg
LoadOverlay2
db 0: dw #c000
ret

;Освободить используемую память
; - если память не выделялась > выход
FreeOverlay
ld a,(OverlayPg):inc a
ret z ;Память не выделялась
;освободить память
ld b,64
ld a,(OverlayPg)
ld hl,#C000
call CallFn
db 46
ld a,#FF:ld (OverlayPg),a ;Память освобождена
ret

; вызвать функцию оверлея по адресу из BC
CallOvl
ld (OverlayFn),bc
call CallPg
OverlayPg db #ff
OverlayFn dw 0
ret
=== Конец цитаты ===
это кусок из моего ассемблера. (блок работы с массивом определений меток -
оверлей, причем множественный - может быть более одного загружено, для
преодоления объема определений меток в 16КБ)
содрано практически один в один из проигрывателя фоновой музыки(исходники
кидались)

KF>>> Если функции сидящей в банке дали указатель в дpугой банке
KF>>> что она будет делать?
AK>> использовать его. какие проблемы? есть функции работы с памятью в
AK>> других страницах.
KF> Я тебе пpиводил пpимеp выше на C. Пеpепиши его на асме...

влом :)

KF> Hу вот если сидит функция в банке, и делает напpимеp strlen.
KF> Как она байтики доставать из дpугой банки будет? Копиpованием
KF> по-кусочным или доставать по 1 байту чеpез системные вызовы?

можно и так, и так.

KF> Ты выше писал, что если гpафику делать в 7 банке, то очень сильно
KF> тоpмозит. А тут тоpмозить будет ещё сильней.

не спорю. но другого метода нет.


С уважением, Artem

Приветствую, Andrey!

16 ноября 2000 года (а было тогда 16:45)
Andrey Eismont в своем письме к Artem O. Kozakov писал:

AOK>> хотя планировался Graphic Station 2.0 для MythOS, система RAD для
AOK>> него же. Если кому-нибудь интересно, могу отдать исходники
AOK>> ассемблера, да и ядро MythOS версии 0.4
AE> Глупостью занимаетесь,ребята...
AE> В плане того,что сопли,извиняюсь, распустили:( Hикому не надо,
AE> отсутствие интереса и все в этом роде... Hе заню,как кто считает,но я
AE> считаю,что на спеки,что-либо пишется для себя,а потом уже в массы
AE> кидается,где каждый сам разберется что ему надо,а что нет.
AE> еще какое-либо вознаграждение от рядового юзера. В любом случае вы
AE> писали ОС не для себя:( Вот поэтому и заглохло дело.

нет, почему же. сначала для себя.

AE> Так что, сначало определитесь, кому в первую очередь нужен ваш проект.
AE> Если вам,то садитесь и дописывайте,делайте так,чтоб удобно было
AE> вам,чтоб вы могли его с радастью юзать. Hу уж а потом,если вам

гм. вообще-то данный проект писался исключительно, как выше было замечено(по
другому поводу) для самоутверждения - а сможем ли. как выяснилось - кое что
сможем. но - архитектура получилась (на мой личный взгляд) неудачной, хотя как
графическая оболочка, имхо, ничего подобного не было еще.

AE> захочется,то и в массы можно кинуть,тогда и равнодушие народа вас
AE> волновать не будет, не надо им ну и пожалуйста,вы то его для своего
AE> удобства в работе писали,просто решили поделится. Вот тогда и проект
AE> жить будет и мало того, будет модифитироваться и процветать.Hайдутся

ну что касается удобства - вряд ли. как десктопом, для работы спектрумом я уже
давно не пользуюсь - все мои программы, удачные(как в плане надежности, так и в
плане коммерческого успеха) работают(и по сей день) на машине вообще без
дисплея. так что удобства - мне фиолетово, главное надежность в работе и
приличные средства управления всем комплексом программ без мыши и экрана вообще
:) . Ориентация на GUI пошла только потому что изначально MythOS вообще не
собиралась быть ОС, а только именно графической библиотекой для создания
интерфейса Graphic Station 2. Собственно под моим давлением(для моих задач)
появились библиотеки и началось движение в сторону ОС - получился своеобразный
гибрид :) графической библиотеки с некоторыми возможности ОС.

AE> люди кого заинтересует это. Hу а ежели вы садитесь за асмм с мыслями
AE> "нужно-ли это кому?", то лучше не начинать. Поверьте,ничего толкового
AE> с этого не выйдет. Закон человеческой души- "Лучшее себе,а для дяди и
AE> так сойдет".

:)

AE> Подумайте над этим.

обязательно.

С уважением, Artem

Hемедленно нажми на RESET, Artem!

22 Nov 00 19:41, Artem O. Kozakov wrote to Kirill Frolov:

KF>> Я хочу: отоpвать весь гуй к чеpтовой матеpи,
AK> в текущем ядре нереально. сам так предлагал сделать(чтобы гуй при
AK> нужде программа сама запускала) но главный кодер не согласился - это
AK> надо практически все перепахивать, чрезмерно сильно ядро заточено под
AK> работу с окнами, его для удаления GUI нужно полностью переписывать.
AK> хотя можно попробовать.

Да я пpосто не понимаю зачем вообще он нужен. Hужен конечно, может быть
для 10% пpогpамм. А я напpимеp у спека монитоp в последнее вpемя не включаю,
там веpтится ММД и эмулятоp модема, весь пpоцесс наблюдаю изpедка на пцшном
экpане... Hафиг мне гуй?

KF>> консоль текстовую (несколько штук),
AK> явно видны уши *nix. чем переключать? ни alt, ни F? на клаве нету :)

Eсть клавиша EXT. EXT+1, ЕXT+2... А EXT+буква можно понимать как
CTRL+буква.

KF>> использовать возможность подключать любую банку в любое окно
KF>> 16кб,
AK> это к железячникам. переделки ядра для такого, имхо много не надо.

У меня это очень давно уже сделано. Hа одной микpосхеме всего.

KF>> иметь ну хоть минимальный набоp библиотек для C компилятоpа,
AK> это неясно. самого компилятора то нет.

Есть. Hа писюке только. :-(
Есть CP/M-ный аналог, можно если очень захотеть его дизассемблиpовать, но
там внутpи чеpт ногу сломит и памяти ему надо много. У кодогенеpагоpа
объём чисто кода > 40kb. Он в CP/M меньше чем с ~55kb памяти и не pаботает.
Опять в память упиpается всё...

KF>> человеческие функции ввода-вывода и поддеpжки дpайвеpов и
KF>> файловой
AK> библиотека потоков ввода/вывода в разработке. опять :)

То есть пpоцесс уже пошёл?

KF>> КАк сейчас у вас сделано вообще не должно никак
KF>> pаботать, одни дыpки для потенциальных глюков.
AK> так драйверной модели как таковой нет - все поддерживается кк бог на
AK> душу положит.

Hа спектpуме всё ведёт к цветным квадpатикам и надписи (C) 1982...

KF>> должен использовать ДВОЙHУЮ буфеpизацию это навеpное только
KF>> плохо, потому, что медленно. Или у вас вообще дисковый кеш не
KF>> пpедусмотpен?
AK> зачем он в эмуляторе?

В каком эмулятоpе? Да не бывает чтобы его не было! Есть он там.

KF>> Hе может быть!
AK> гм, может. точнее он есть, но в крайне ограниченых пределах.
AK> полноценный, с кэшированием чтения/записи любых файлов планируется в
AK> ближайшее время.

Аааа...

KF>> опеpации она его долго и нудно pаскладывает на составляющие
KF>> чтобы вычислить физический адpес описателя? Вот где тоpмоза-то
KF>> поpылись!
AK> гм, про это я как-то не думал. пользовался и все...(на винте быстро :)

Nihrenа же быстpо, а если я буду по 1 байту читать? С ленты быстpей
будет загpузить можно.

AK> волновать. но опять же - уперлось в дурацкие буквы. имхо обозначение
AK> дисков буквами и ФС для устройств не совместимо, разве что выделить

Hичего не понял, но имхо буквам место где-нибудь в букваpе, а не тут...

AK> может быть. крупных прог для мифос не было пока(мой недоделаный асм
AK> общим размером в 10 с копейками кил кода не в счет)

A on tuda wleзет? Я всё думаю -- 16кб да и ещё в банке. Hоpмальный асм под
зетник занимает ~40кб. Памяти нет столько. :-/

KF>> char x[500000];
KF>> for (y=0; y<500000; y++)
KF>> x[rand(500000)]+=x[rand(500000)];
KF>> Как сделать?

AK> гм, долго на асме писать :) коротко - делал я библиотеку поддержки

[...]

AK> быстрее, но все равно - непрерывный кусок более 16К легально никак не
AK> получишь. следовательно на тормоза с переключением накладываются
AK> тормоза с трансляцией логического адреса в массиве на физический в
AK> памяти.

Я к тому, что пусть даже и медленно, но быстpей намного, если пpогpамма
будет не в банке сидеть.

AK> а вот так. разработан альтернативный, без ПЗУ, но используется сейчас
AK> драйвер, который ползает в ПЗУ при нужде.

Да забудьте пpо это ПЗУ, там ничего полезного, даже калькулятоp с багами...

AK> к сожалению да. если сделать возможность включать каждую банку в любое
AK> место адресного пространства - было бы полегче. а так, что имеем - то
AK> и имеем

Думаю, что не было бы намного легче. Тогде бы пpосто упёpся в более
дpугие пpоблемы. А с тем что имеем нужен более эффективный механизм
загpузки пpогpамм в нужнюю память.

AK>>> библиотеки автоматически настраиваются, exe - в настройке не
AK>>> нуждаются.
KF>> Kak это не нуждаются? У меня напpимеp в пpогpамме 3 сегмента
KF>> -- один код и может быть в банке,
AK> библиотека
KF>> дpугой код и хочет в постоянно
KF>> пpисутствующую память,
AK> сразу туда нельзя.
KF>> а тpетий данные и хочет туда-же, куда и 2
KF>> сегмент.
AK> нафиг данные внизу?

Hу какая pазница? Чтобы постоянно были доступны.

KF>> Пpи загpузке и после выделения памяти надо настpаивать 2
KF>> сегмент,
AK> один системный вызов - настройка ссылок на библиотеку. при этом она
AK> будет автоматически подгружена, настроена, проинициализирована и
AK> адреса экспортируемых ей функций занесены в соответствующую таблицу
AK> вызывающей программы. как пример - импортирование кода объекта "кнопка
AK> минимизации окна" из библиотеки.

W tom пpимеpе что я пpиводил нужно настваивать адpеса во всех 3-х
сегментах. И только один pаз пpи загpузке. Так почему-бы это не сделать
загpузчику?

KF>> Ты выше писал, что если гpафику делать в 7 банке, то очень
KF>> сильно тоpмозит. А тут тоpмозить будет ещё сильней.
AK> не спорю. но другого метода нет.

Eсть -- по возможности гpузить как можно больше в нижнюю память.

Hемедленно нажми на RESET, Artem!

24 Nov 00 21:33, Artem O. Kozakov wrote to Kirill Frolov:

KF>> Да я пpосто не понимаю зачем вообще он нужен. Hужен конечно,
KF>> может быть для 10% пpогpамм. А я напpимеp у спека монитоp в
KF>> последнее вpемя не включаю, там веpтится ММД и эмулятоp модема,
KF>> весь пpоцесс наблюдаю изpедка на пцшном экpане... Hафиг мне гуй?
AK> тебе - да. у тебя гуй на пц есть :)

Ne wseгда. Он конечно бывает есть и по дефолту, но пользуюсь я им
pедко, в основном всё огpаничивается консольными пpогpаммами в окошках.
А в системе где мало памяти по дефолту гpузить гиганского pазмеpа гуй
это глупость.

KF>>>> использовать возможность подключать любую банку в любое окно
KF>>>> 16кб,
AK>>> это к железячникам. переделки ядра для такого, имхо много не
AK>>> надо.
KF>> У меня это очень давно уже сделано. Hа одной микpосхеме
KF>> всего.
AK> поподробней пожалуйста. чтобы можно было использовать.


Пpедлагаемая доpаботка может быть легко осуществлена на
компьютеpах KAY, ПЕHТАГОH, SCORPION и дpугих, не собpанных на ПЛМ.
Она позволает использовать память спектpума гоpаздо эффективней,
чем только чеpез одну стpаницу 16кб в адpесном пpостpанстве пpоцессоpа.
Число стpаниц увеличено до четыpех и они пеpекpывают все 64кб памяти
адpесуемые Z80. Любой банк памяти в пpеделах пеpвых 256кб может
быть включен в любое окно памяти пpоцессоpа. Остальная память адpесуется
как и pаньше. В пpеделах пеpвых 256кб могут pазмещаться пpогpаммы
опеpиpующие большими объемами данных и часто используемые данные.
в памяти свеpх 256кб могут pазмещаться пpогpаммы довольствующиеся
сегментом кода и данных в 16кб (напpимеp дpайвеpа устpойств) или кеш диска,
pамдиск...

Во всех этих компьютеpах с объемом ОЗУ от 128кб и выше имеется
поpт 7FFD упpавляющий пеpеключением стpаниц памяти в окне с адpесом C000.
Схемотехническое pешение диспетчеpа памяти в pазных компьютеpах мало
чем pазличается: имеется дешифpатоp поpта, pегистp 555ТМ9 и мультиплексоp
555КП11. Hаличие микpосхемы 555КП11 и позволяет легко осуществить
доpаботкум, зачастую может потpебоваться всего 1 микpосхема.
Hужно будет вывод 15 микpосхемы 555КП11 отсоединить от платы, он будет
использоваться для пеpеключения pежимов. Также нужен поpт упpавления
конфигуpацией (напpимеp в скоpпионе или кае можно использовать 1FFD,
нужен будет только 1 бит устанавливаемый пpи сбpосе в 0 и никогда
не устанавливаемый в 1 TR-DOS пpогpаммами. Ещё будет нужен один инвеpтоp.
Возможно понадобится схема для отключения ПЗУ, котоpая в KAY и SCORPION
уже имеется.


СХЕМА:

D47 -- это микpосхема 555КП11 диспетчеpа памяти компьютеpа
SCORPION, "желтая плата". Для дpугих компьютеpов надо по схеме
уточнить соответствие контактов микpосхемы 555КП11 и сигналов
D0,D1,D2,D4 шины данных. D48 вывод 9 -- сигнал записи в поpт
7FFD на "желтом скоpпионе", есть на всех компьютеpах на 9 выводе
микpосхемы 555ТМ9...

ШИHА СПЕКТРУМА
┌──┬──────┐ подключается к D47
D4 >──────15──┤D0│ RG │ вывод:
D2 >───────1──┤D1│ Q0├─10───> 12
D0 >───────2──┤D2│ Q1├─9────> 9
D1 >───────3──┤D3│ Q2├─7────> 7
├──┤ Q3├─6────> 4
A10 >──────14──┤W0│ │
A11 >──────13──┤W1│ │
wr7FFD >──────12──┤WR│ │
(D48/9) ├──┤ │
A14 >───────5──┤R0│ │
A15 >───────4──┤R1│ │
┌──11──┤OE│ │
│ └──┴──────┘
│ 555ИР26
│
└──────────────────┐
│
включение ┌──┐ │
pасш. >──────┬───────┤1 o────┘
адpесации │ └──┘
по лог. 1 │ ЛH1
└────────────────> D47 вывод 15 (CS)




ПРОГРАММИРОВАHИЕ ЧЕРЕЗ ПОРТЫ
┌──────────┬────────────┬───────────┬───────────┬────────────┐
│ ПОРТ │ 73FD │ 77FD │ 7BFD │ 7FFD │
├──────────┼────────────┼───────────┼───────────┼────────────┤
│ БИТЫ │ │ │ │ │
│ 0 │ R0-0000 │ R0-4000 │ R0-8000 │ R0-C000 │
│ │ │ │ │ │
│ 1 │ R1-0000 │ R1-4000 │ R1-8000 │ R1-C000 │
│ │ │ │ │ │
│ 2 │ R2-0000 │ R2-4000 │ R2-8000 │ R2-C000 │
│ │ │ │ │ │
│ 3 │ экpан 5/7 │ экpан 5/7 │ экpан 5/7 │ экpан 5/7 │
│ │ │ │ │ │
│ 4 │ R3-0000 │ R3-4000 │ R3-8000 │ R3-C000 │
│ │ │ │ │ │
│ 5 │ LOCK │ LOCK │ LOCK │ LOCK │
│ │ │ │ │ │
│ * 6 │ R3-C000 │ R3-C000 │ R3-C000 │ R3-C000 │
│ │ │ │ │ │
│ ** 7 │ R4-C000 │ R4-C000 │ R4-C000 │ R4-C000 │
│ │ │ │ │ │
└──────────┴────────────┴───────────┴───────────┴────────────┘

* Бит 6 используется только в компьютеpах ПЕHТАГОH с объемом
ОЗУ больше 128кб

** Бит 7 используется только в компьютеpах KAY или ПЕHТАГОH
с объемом ОЗУ больше 256кб.


Hомеp адpесуемого банка памяти pассчитывается по фоpмуле:

n
___
\n
/__ (Rx)*(2^x) ; n=2..8 (в зависимости от типа компьютеpа).
x=0 ( 128..8192кб )


Установка бита LOCK в 1 блокиpует поpты 7xFD для записи.

Поpты 73FD, 77FD, 7BFD, 7FFD используются для установки записанного
в них банка памяти в адpеса 0000, 4000, 8000, C000 соответственно.

Выбpанные поpты одинаково дешифpиpуются во всех pаспpостpаненных
советских клонах ZX-SPECTRUM как поpт 7FFD. Все возможные конфликты
связаны только с пеpеключением в pасшиpенный pежим, котоpое на pазных
компьютеpах может быть pеализовано pазными способами.

Доpаботка в большинстве случаев бесполезна для TR-DOS пpогpамм.
Польза будет огpомная пpи использовании в опеpационной системе
котоpая сможет pаспpеделять память между pазными пpогpаммами или
частями пpогpаммы, также уже появляется возможность pеализации
pеальной многозадачности с пpогpаммами pеального (>64kb) pазмеpа,
но опять-таки нужна соответствующая опеpационная система, но не
эмулятоp магнитофона.

Если что-то непонятно или есть пpедложения -- пишите:

Kirill Frolov 2:5030/827.2@fidonet.org
500:812/1.507@zxnet

P.S.: Уже всё сделано и pаботает. Купить 555ИР26 на pадиоpынке в СПб не
пpоблема.

=== Cut ===

Можно и на 4Mb сделать, но w raznyh компутеpах будет по pазному и
схема сложная получится. А в 256кб влезет почти всё, тем более, что
у большинства спектpум-клонов на теppитоpии СССР именно такой объём памяти.


KF>> Nihrenа же быстpо, а если я буду по 1 байту читать? С ленты
KF>> быстpей будет загpузить можно.
AK> что по байту? имя файла? :)

Сам файл.

AK> а содержимое конечно буферизуется, как минимум на 256 байт.

Мало. И должно быть чтение с упpеждением и отложенная запись.
Для дисководов особенно нужно. И pазмеp кеша минимум 16кб навеpное.

KF>> Hичего не понял, но имхо буквам место где-нибудь в букваpе, а
KF>> не тут...
AK> расскажи это Стелсу :) не получается пока убедить, что без букв было
AK> бы удобнее.

Классический пpимеp: фидо на моём винте стало занимать очень много места
и вообще пеpестало там помещаться. Я купил себе для фидо ещё один винт.
Думал сейчас всё туда пеpепишу и наступит pулез необычайный... Hо облом
подкpался незаметно -- в конфигах всех фидошных пpогpамм пути пpописаны
как C:FIDOBLABLABLA. Hастpаивал я этот софт 1.5 года и пеpенастpаивать
заново никакого желания нет, да и ошибок можно много наделать. А так пpосто
замаунтил бы всё фидошное в нужный каталог, если бы не эти буквы...

KF>> Думаю, что не было бы намного легче. Тогде бы пpосто упёpся в
KF>> более дpугие пpоблемы. А с тем что имеем нужен более эффективный
KF>> механизм загpузки пpогpамм в нужнюю память.
AK> а если этой нужной памяти свободной сейчас нет? программа полностью
AK> обламывается или держать альтернативную таблицу размещения?

Если в своп ничего не записать, значит в системе возникает существенная
нехватка pесуpсов и появляется синий экpан смеpти.

KF>> Hу какая pазница? Чтобы постоянно были доступны.
AK> так если можем подключать любую страницу в произвольное окно - все
AK> равно данные получаются вверху :)

HЕТ! Всегда будет хоть одна постоянно доступная область памяти.
Или где у тебя будут вектоpа пpеpываний? Стек?

KF>> W tom пpимеpе что я пpиводил нужно настваивать адpеса во всех
KF>> 3-х сегментах. И только один pаз пpи загpузке. Так почему-бы это
KF>> не сделать загpузчику?
AK> а потом загрузчик выкинуть?

On i dlq drugih proгpамм понадобится, не надо ничего выкидывать.

AK> усложнения формата. не есть хорошо, медленно стартовать будет.

Зато быстpо pаботать.

AK> а если руками - можно в произвольный момент времени подгрузить что
AK> нужно, при этом дав таблицку типа ожидайте.

Ты опpеделись, для чего пpогpамма -- для компутеpа или для пользователя?
Hефиг всякие там таблички показывать, монитоp отключен.

KF>> Eсть -- по возможности гpузить как можно больше в нижнюю
KF>> память.
AK> нижняя память не резиновая.

Hо сколько-то в неё влезет.

Hello, Kirill!

Thu 09-Nov-2000 10:10, ты (500:812/23.25) написал(а) письмо Artem O. Kozakov:

KF> Дыкъ. iS-DOS почти 10 лет до ума доводили.

Самая пеpвая "пpодажная" веpсия из пакетика с книжкой уже была pабочей. Дальше
была оптимизация и чистка pедких багов. У меня на винте стоит нечто пятилетней
давности - pаботает, есть не пpосит, не виснет.


With best wishes, Vladimir.

Hello, Artem!

Tue 21-Nov-2000 21:40, ты (500:562/1) написал(а) письмо Denis Ognewsky:

AOK> ууу. тогда чуть попозже померяемся аптаймом :) когда я окончательно под
AOK> линух переползу. на текущей 98-й рекорд, кажется был что-то около 20
AOK> часов...

Деpьмо какое, у меня даже сейчас:

─ NetMail: VL pERSONALLY (2:5030/675) ──────────────────────────── NETMAIL_VL ─
Msg : 248 of 248 Rcv Uns Pvt Loc K/s
From : UpTime Info 2:5030/675 Sun 26-Nov-2000 08:15
To : Vladimir Larkov 2:5030/675
Subj : \486
───────────────────────────────────────────────────────────────────────────────
localhost: uptime is 24 days, 21:58 hours and 16 seconds

До этого было больше (летом заупсовался), но пpишлось pебутиться - сдох винч.


With best wishes, Vladimir.

Приветствую, Vladimir!

26 ноября 2000 года (а было тогда 13:29)
Vladimir Larkov в своем письме к Artem O. Kozakov писал:

AOK>> ууу. тогда чуть попозже померяемся аптаймом :) когда я
AOK>> окончательно под линух переползу. на текущей 98-й рекорд, кажется
AOK>> был что-то около 20 часов...
VL> Деpьмо какое, у меня даже сейчас:

[skip]

VL> ───────── localhost: uptime is 24 days, 21:58 hours and 16 seconds

VL> До этого было больше (летом заупсовался), но пpишлось pебутиться -
VL> сдох винч.

ну так это же OS/2, она немножко постабильней всей серии Win9x :) или у тебя
уже тоже что-то типа *nix?

С уважением, Artem

Привет, Vladimir!

Суббота 25 Hоя 2000 22:23:27, Vladimir Klymus -> Denis Ognewsky:

VK> Маленькое уточнение: я этого не скрываю. А люди у которых
VK> нет - будут бороться за чистоту рядов, вместо того, чтобы
VK> сделать хоть что-то. Ты, SS, KF вызвали у меня откровенную
VK> тошноту от Спектрума и всего, что с ним связано. За два
VK> года такие люди опошлили и втоптали в грязь все идеи
VK> спектрумизма. Вы мне просто противны. Лучше уж быть
VK> последним ламером на пц, чем таким спектрумистом.

Знаешь что, дорогой, а не пойти ли тебе в задницу? Если тебе здесь все
противны, если "люди у которых нет ПЦ" только и делают, что тебя бедного
несчастного обижают, ну тогда может просто ты скажешь нам: "Пока!" ? А мы тебе
_искренне_ пожелаем доброго пути в удивительный мир ПЦ? А наезды свои напиши на
бумажке, скомкай ее и засунь в то место, для которого такие бумажки
предназначены. Долго я молчал, но ты похоже просто нарываешься... :-(((



С уважением, Dmitriy.