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


тема: система аля бут



от: 812/19.14
кому: Paul Falcon
дата: 14 Oct 1997
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'овский редактор

от: 812/03.00
кому: Valentin Pimenov
дата: 17 Oct 1997
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+ плюсовой

от: 812/03.00
кому: All
дата: 17 Oct 1997
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+ плюсовой




Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Похожие статьи:
Железо - Еще раз о "TURBO" в SCORPION ZS 256.
Советы экспертов - по стратегической игре Wellingsto at Waterloo.
Железячный фронт - Новый контроллер винчестера с произвольным доступом из TR-DOS.
interview - chasm.cpu
Боль - Холодное осеннее утро.

В этот день...   8 мая