DEB - ассемлер нового поколения...

[ASMAN]

Низкий поклон, Всем !

Давно читаю эту рубрику и не очень понимаю что значит "нового поколения" ? Это асм занимающий в памяти НОЛЬ байт ???

Сколько помню себя, для меня в асме были главные два пункта 1.Качество компиляции, 2.Скорость компиляции ! Поэтому я давно колебался между TASM'омо и ALASM'ом, но когда узнал, что в аласме из-за однопроходности получается множество проблем, так и остался в TASM'е ... А вообще-то, всё, что мы делали с ребятами, так это просто переделывали TASM на 512 и компилировали любых размеров файлы ... Мне кажется, что стоит на этом поставить акцент ... Поскольку каждый из нас пишет под 128, и если у него отобрать хотя бы одну страничку, то будет много расстройств. А фреймовый скрол, конечно, велеколепная вещь, но только не в ущерб памяти.

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

Извеняюсь а свои пять копеек ... Но всё же память на Speccy, это драгоценная вещь, а особенно когда ебе 70 =) шутка ...

Круто! Я не догодался! Вот вам и КЛАССНЫЕ советчики! Сделаем так! Завтраже займусь прогой генерации скрола вверх/вниз! Спасибо! побольше бы таких!
Правда будет проблемка! А если ты захочешь узнать по какому адресу находится та или иная метка ? А тут ее уже после компиляции забила прога скрола ? Подумаем как можно выкрутится...

[Advertiser]

[Robus]

Снова низкий поклон !!!

Круто! Я не догодался! Вот вам и КЛАССНЫЕ советчики! Сделаем так! Завтраже займусь прогой генерации скрола вверх/вниз! Спасибо! побольше бы таких!
Правда будет проблемка! А если ты захочешь узнать по какому адресу находится та или иная метка ? А тут ее уже после компиляции забила прога скрола ? Подумаем как можно выкрутится...

Вообще-то, если уж смотреть совсем в корень проблемы, то можно пойти очень неординарным путём ... Может это натолкнёт тебя на новые мысли ...

Попробуй сделать моментальную компиляцию ... То есть, если кто-то пишет JP Start, то так и сохраняешь 195,lo,hi ... Только Lo/Hi, будет указывать на таблицу меток, от которой никак не уйти. Конечно тогда возникают трудности с ремарками ... Но и тут можно обойти проблему, просто сделай ещё один буфер, где будут лежать ремарки а заодно и DB, с указанием на строку, где её набивали ... Я понимаю, что редактирование такого извращённого текста будет сложным, но экономным. На встречу этой идеи могу предложить другой метод редактирования текста, что ускорит обработку редактирования в тысячи раз, а если быть точным, то по сути в бесконечность ... Представь себе, что у тебя есть кусок памяти в 40000 байт, куда загружен текст в конец этого блока. При нажатии вниз, ты всего-то переносишь в начало блока строку. Ежели кто-то набивает текст, то ты просто в конец текущей строки добавляешь байты (текст). Просто человек при редактировании всё равно пользуется переходом вверх/вниз, а тебе всего-то нужно перенести пару байт соответствующей строки.

00000 ... ORG 16384
00002 ... LD HL,16384
00005 ... LD DE,16385
00008<--- Тут курсор
39992 ... LD BC,6911
39995 ... LD (HL),L
39996 ... LDIR
39998 ... DI
39999 ... HALT

Ежели кто-то нажал вниз будет:

00000 ... ORG 16384
00002 ... LD HL,16384
00005 ... LD DE,16385
00008 ... LD BC,6911
00011<--- Тут курсор
39995 ... LD (HL),L
39996 ... LDIR
39998 ... DI
39999 ... HALT

То есть, по-сути, всё, что остаётся это просто высветить текст, или перенести его скроллом, и высветить только одну строчку, которую редактируем !

Конечно я утрировал, поскольку там есть и ORG, его то же нужно как-то закодировать, но это дело техники ... Если тебя это заинтересовало, то могу дать уже готовый текстовый редактор, который я делал в 94-ом году. Там, кстати, сделан совершенно любой шрифт по X и Y, только нарисовать и всё. Причём, каждая буква может быть своего размера. В турбо, при условии, что высота шрифат 2 пиксела, получается один фрейм, при скроллировании. Если взять фонт высостой в 6 пикселей, то получается один фрейм и без турбо. Там применён этот метод редктирования, но я совсем не помню, сколько он при этом жрёт памяти, но один фрейм гарантирую. Я всегда свои тексты набивал в нём, поскольку очень люблю один фрейм !!!

[elf/2]

Попробуй сделать моментальную компиляцию ... То есть, если кто-то пишет JP Start, то так и сохраняешь 195,lo,hi ... Только Lo/Hi, будет указывать на таблицу меток, от которой никак не уйти.

похоже не формат текста в сторме. только там авторы пошли дальше: они в таком случае даже 195 не хранят
хотя метки в тексте хранятся как текст (правда сильно перекодированный). а вот числа именно так, плюс 1 байт с указанием системы счисления (hex, dec, bin, char)

[ASMAN]

похоже не формат текста в сторме. только там авторы пошли дальше: они в таком случае даже 195 не хранят
хотя метки в тексте хранятся как текст (правда сильно перекодированный). а вот числа именно так, плюс 1 байт с указанием системы счисления (hex, dec, bin, char)

Так у меня почти все команды занимают 3 байта! Так что проблемы с кодом не будет!

[ASMAN]

Снова низкий поклон !!!



Вообще-то, если уж смотреть совсем в корень проблемы, то можно пойти очень неординарным путём ... Может это натолкнёт тебя на новые мысли ...

Попробуй сделать моментальную компиляцию ... То есть, если кто-то пишет JP Start, то так и сохраняешь 195,lo,hi ... Только Lo/Hi, будет указывать на таблицу меток, от которой никак не уйти. Конечно тогда возникают трудности с ремарками ... Но и тут можно обойти проблему, просто сделай ещё один буфер, где будут лежать ремарки а заодно и DB, с указанием на строку, где её набивали ... Я понимаю, что редактирование такого извращённого текста будет сложным, но экономным. На встречу этой идеи могу предложить другой метод редактирования текста, что ускорит обработку редактирования в тысячи раз, а если быть точным, то по сути в бесконечность ... Представь себе, что у тебя есть кусок памяти в 40000 байт, куда загружен текст в конец этого блока. При нажатии вниз, ты всего-то переносишь в начало блока строку. Ежели кто-то набивает текст, то ты просто в конец текущей строки добавляешь байты (текст). Просто человек при редактировании всё равно пользуется переходом вверх/вниз, а тебе всего-то нужно перенести пару байт соответствующей строки.

00000 ... ORG 16384
00002 ... LD HL,16384
00005 ... LD DE,16385
00008<--- Тут курсор
39992 ... LD BC,6911
39995 ... LD (HL),L
39996 ... LDIR
39998 ... DI
39999 ... HALT

Ежели кто-то нажал вниз будет:

00000 ... ORG 16384
00002 ... LD HL,16384
00005 ... LD DE,16385
00008 ... LD BC,6911
00011<--- Тут курсор
39995 ... LD (HL),L
39996 ... LDIR
39998 ... DI
39999 ... HALT

То есть, по-сути, всё, что остаётся это просто высветить текст, или перенести его скроллом, и высветить только одну строчку, которую редактируем !

Конечно я утрировал, поскольку там есть и ORG, его то же нужно как-то закодировать, но это дело техники ... Если тебя это заинтересовало, то могу дать уже готовый текстовый редактор, который я делал в 94-ом году. Там, кстати, сделан совершенно любой шрифт по X и Y, только нарисовать и всё. Причём, каждая буква может быть своего размера. В турбо, при условии, что высота шрифат 2 пиксела, получается один фрейм, при скроллировании. Если взять фонт высостой в 6 пикселей, то получается один фрейм и без турбо. Там применён этот метод редктирования, но я совсем не помню, сколько он при этом жрёт памяти, но один фрейм гарантирую. Я всегда свои тексты набивал в нём, поскольку очень люблю один фрейм !!!

Супер! Прибей файлик! Я посмотрю! Мне какраз нужен сейчас отличный скролл...

[ASDT]

"Схемы выкладывать я не имею права." Правда смешно Гы-гы-гы
Уж если кто правда пишет игры - может в "железе" отпишите,
какое расширение видео может быть нужно ...

[Jack Ketch]

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