ZXNet эхоконференция «code.zx»

Hello, Paul!

13-10-97 ты писал про "система аля бут"

PF> рам диск 8 страница и выше
PF> оверлеями там может висеть что
PF> угодно ... так что ничего
PF> особенно конкретного сказать немогу.

PF> если если интересные мысли - пишите ,
PF> только без мата :)

Мысли, конечно, есть. Я так понял, что это
будет типа прога с возможностью работы с
файлами тр-дос + рам диск + оверлеи?
Если "да", то тогда imho 128К не потянет.

-= РАМ ДИСК =-

Если представить себе для чего
нужен рам-диск:
1.для копирования файлов
2.для быстрой загрузки оверлеев.

3.для совмещения (1)+(2) необходимо как
минимум 512К, т.к. даже 256К не хватит, не
то что 128К.

-= ОВЕРЛЕИ =-

1. безусловно разные диск-доктора,
трек-копировщик и т.д.
2. простенький текстовый редактор по возможностям
сравнимый с ZxAsm'ом.
3. калькулятор (хорошо бы уровня
Scientific в Вындоузе).
4. конвертеры файлов (разные асмы в
текст и обратно в асмы/ музыкальные
туды-сюды/ картинки BMP-PCX-итд <=>speccy)
5. простенькие игрушки (вот я прикольнулся
над ZxAsm3.10 demo/MineSweeper :)
6. работа с МС-дос/ИС-дос дисками

больше чего-то в голову ничего не лезет :)

-= КОHЦЕПЦИЯ СИСТЕМЫ =-

1. абсолютно необходимо, чтобы система была
максимально открытой и гибкой. Это означает,
что каждый, обладающей достаточной
квалификацией мог без изучения трассерами
и дизассемблерами кода системы написать
оверлей под свои нужды. Потому, что не
так важны возможности системы в смысле
функций, как возможности системы по
управлению и взаимодействию оверлеев.
2. каждый оверлей должен иметь свою
область данных. Даже если один оверлей
запущен 2 раза (не знаю пока для чего
это может понадобиться, но может) каж-
дый должен иметь свою область!
3. особое внимание уделить живучести
системы. При вылете одного оверлея -
система должна его завершить/закрыть и
продолжать работу.

PS: то, что я сейчас написал в последнем
разделе походит на требования например
к Вындоуз. Hа самом деле это не совсем
так. Это требования к любой открытой
системе, а ты я думаю задумал именно
такую. Если я не прав - скажи!

Жду ответа, Valker/Style Group

-+- ZxAsm'овский редактор

Hi Valentin!

PF>> рам диск 8 страница и выше
PF>> оверлеями там может висеть что
PF>> угодно ... так что ничего
PF>> особенно конкретного сказать немогу.

PF>> если если интересные мысли - пишите ,
PF>> только без мата :)

VP> Мысли, конечно, есть. Я так понял, что это
VP> будет типа прога с возможностью работы с
VP> файлами тр-дос + рам диск + оверлеи?
VP> Если "да", то тогда imho 128К не потянет.

и здесь можно извернуться :) оставить
страницу на такой случай , сейчас
про тесте машины, если страниц более 5
то она вырезает из таблицы доступных
все 128 страницы .

VP> -= РАМ ДИСК =-

VP> Если представить себе для чего
VP> нужен рам-диск:
VP> 1.для копирования файлов
VP> 2.для быстрой загрузки оверлеев.
VP> 3.для совмещения (1)+(2) необходимо как
VP> минимум 512К, т.к. даже 256К не хватит, не
VP> то что 128К.

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

при 256<>1024 кб 128 память остется в
системе под оверлеи .

VP> -= ОВЕРЛЕИ =-

VP> 1. безусловно разные диск-доктора,
VP> трек-копировщик и т.д.

это в системе будет.

VP> 2. простенький текстовый редактор по возможностям
VP> сравнимый с ZxAsm'ом.

а вот из за этого я и задумал оверлейную
систему.

VP> 3. калькулятор (хорошо бы уровня
VP> Scientific в Вындоузе).

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

VP> 4. конвертеры файлов (разные асмы в
VP> текст и обратно в асмы/ музыкальные
VP> туды-сюды/ картинки BMP-PCX-итд <=>speccy)

и это надо.

VP> 5. простенькие игрушки (вот я прикольнулся
VP> над ZxAsm3.10 demo/MineSweeper :)
VP> 6. работа с МС-дос/ИС-дос дисками

тока не думайте что я сразу все напишу,
это что мне одному надо .

VP> больше чего-то в голову ничего не лезет :)

VP> -= КОHЦЕПЦИЯ СИСТЕМЫ =-

VP> 1. абсолютно необходимо, чтобы система была
VP> максимально открытой и гибкой. Это означает,
VP> что каждый, обладающей достаточной
VP> квалификацией мог без изучения трассерами
VP> и дизассемблерами кода системы написать
VP> оверлей под свои нужды. Потому, что не
VP> так важны возможности системы в смысле
VP> функций, как возможности системы по
VP> управлению и взаимодействию оверлеев.

а конкретней ,сейчас оконник работает
сл.образом :

rst 16
db 3,1,1,1,1,1,"handle",0,"text",0
код ^ ^ ^ ^ ^ ^ ^ ^ ^ ^конец
коорд. y ┘ │ │ │ │ │ │ └текс окна
коорд. x ┘ │ │ │ │ └код конца
размер по y ┘ │ │ └ заголовок окна
пазмер по x ┘ └ цвет окна

снимать можно только последнее
поставленое окно ,и оч просто :

rst 16
db 4

окно с опросом клавиш , задается как
и обычное но код 5 , и прога не выйдет
из рисования окна пока не будет нажата
нужная клавиша "enter" -подтверждение
"edit" - отмена , и списка букв
которые отмечены в тексте окна типа:

db "drive A ( )",13
db "drive B ( )",0

или

db "eXit to dos ( )",13
db "exit to Basic ( )",0

то-есть на заглавные буквы ,а сковочки
нужны для отображения "метки" ,их можно
не ставить , но тода будет непонятно
что выбрано . по возврашению процедура
вернет в регистр А код нажатой клавиши,
если нажат "enter" или 0 если отмена.

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

db "Tested drive [√]",0

как в TXT_WRTd :) ну мысля понравилась.

все изменения заносятся в _текст_
_окна_! то-есть если надо выяснить
состояние какого либо пункта ,то 1:
отсканировать окно на это дело и 2:
ввести переменную в текс окна и
по ходу дела проверять ее состояние.

под буффер для окон выделена 7 страница.

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

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

VP> 3. особое внимание уделить живучести
VP> системы. При вылете одного оверлея -
VP> система должна его завершить/закрыть и
VP> продолжать работу.

ну это не выньдоус или какая другая ос,
здесь о "вылете" должен заботится
оверлей .а система как сможет это обработает.

VP> PS: то, что я сейчас написал в последнем
VP> разделе походит на требования например
VP> к Вындоуз. Hа самом деле это не совсем
VP> так. Это требования к любой открытой
VP> системе, а ты я думаю задумал именно
VP> такую. Если я не прав - скажи!

по больше части прав , но давай
конкретней ,чо как где ...

▌▌║▌█▐│▌▌▐▐ WiTh The BeST wIsheS fROM
▌▌║▌█▐│▌▌▐▐ *C*R*E*A*T*O*R*
▌812/03.00▐


-+- zxasm+ плюсовой

Hi All!

Короче за каких-то 14 часов ,многое
переменилось, теперь при открывании
окна не надо указывать длины по x и y,
процедура их сама найдет, длинна по x
вычисляется по длинне "handle", а высота
по количеству строк в "text+1 .
Окна могут открываться в 32 и 64 символа,
русские буквы не могут встречаться в
тексте окна с опросом клавиш, только
в обычных окнах и в формате xas'a.
поддержка других кодировок под бооольшим
вопросом, только в оверлейных прогах.
скорее всего можно будет менять адрес
фонтов.

а конкретней ,сейчас оконник работает
сл.образом :

rst 16
db 3,1,1,1,"handle",0,"text",0
код ^ ^ ^ ^ ^ ^ ^ ^конец
коорд. y ┘ │ │ │ │ └текс окна
коорд. x ┘ │ │ └код конца
│ └ заголовок окна
└ цвет окна

снимать можно только последнее
поставленое окно, и оч просто :

rst 16
db 4

сейчас доделаю снятие всех окон
одной командой типа:

rst 16
db 6

окно с опросом клавиш, задается как
и обычное но код 5, и прога не выйдет
из рисования окна пока не будет нажата
нужная клавиша "enter" -подтверждение
"edit" - отмена, и списка букв
которые отмечены в тексте окна типа:

db "drive A ( )",13
db "drive B ( )",0

или

db "eXit to dos ( )",13
db "exit to Basic ( )",0

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

db "eXit to dos [ ]",13
db "exit to Basic [ ]",0

то-есть на заглавные буквы, а скобочки
нужны для отображения "метки", их можно
не ставить, тогда выход из опроса
будет осуществлен на нажатие клавиши
без подтверждения "enter"ом.
по возврашению процедура
вернет в регистр А код нажатой клавиши
или 0 если отмена.
для разделения групп пунктов надо
отделять их "------", вот так:

db "eXit to dos [ ]",13
db "exit to Basic [ ]",13
db "-----------------",13
db "exit to Basic [ ]",13
db "eXit to dos [ ]",13
db "exit to Basic [ ]",0

Здесь будут выбираться либо между двумя
верхними или тремя нижними пунктами.

как в TXT_WRTd :) ну мысля понравилась.

все изменения заносятся в _текст_
_окна_! то-есть если надо выяснить
состояние какого либо пункта, то 1:
отсканировать окно на это дело и 2:
ввести переменную в текст окна и
по ходу дела проверять ее состояние.

под буффер для окон выделена 7 страница.

▌▌║▌█▐│▌▌▐▐ WiTh The BeST wIsheS fROM
▌▌║▌█▐│▌▌▐▐ *C*R*E*A*T*O*R*
▌812/03.00▐


-+- zxasm+ плюсовой