In al, 0x92;включаем A20 вот тут она поменяла свой смысл?

Вот тут такой кусок? in al, 0x92 or al, 2 out 0x92, al

извините что встреваю в разговор, а такой вопрос родился, out/in и mov это не одно и тоже т.е. можно ли в порт так записать: mov [0x92], al и вместо in mov al, [0x92]

Нет. mov al, [0x92] это будет (в реальном режиме) "записать в al байт из памяти по адресу ds:0x92"

Раз уж ты изучаешь как расставить пиксели на экране в режиме int 10h, #3, чтобы они образовали окружность, то полагаю что вскоре ты захочешь раскрасить эти пиксели по своему усмотрению. И тут тебе на помощь придут VGA порты: 3C8h, 3C9h. В этом режиме, в ДОСБОКСЕ, одновременно можно отобразить всего 256 цветов из 262144 возможных. Но в чистом ДОСе и в этом видеорежиме одновременно можно замутить до 64000 уникальных цветов, но это уже прибегая к некоторым хитростям. Итак, цвета программируются последовательно, а значения RGB лучше задавать заранее (подготовить палитру) в памяти и в нужный момент программировать их через порт 3C9, туда через этот порт можно отправить до 768 байт. Порт 3C8h — индексный, т.е. в него ты записываешь адрес от 0 до 255, начиная с которого нужно начинать записывать байты через порт 3C9h. Вся прелесть в том, что тебе не нужно заморачиваться с инкрементом индекса в 3C8h, как только ты запишешь значение в 3C9h, в 3C8h автоматически произойдёт инкремент индекса. Поэтому если ты укажешь начальный адрес — 0 (из 256 возможных), то можешь последовательно отправлять в порт 3C9 все 768 байт. Каждый адрес принимает последовательно три байта (R,G,B). 768 байт — это 256×3 ячеек, т.е. 256 для R, 256 для G, 256 для B. И программируются , цвета поочерёдно: (R,G,B),(R,G,B),(R,G,B)... Каждый цвет программируется тремя значениями RGB, каждое из этих значений лежит в диапазоне от 0 до 3Fh, отсюда и ограничения на количество цветов 64^3=262144. А поскольку ячеек 768, то 768/3=256 цветов. А вот пример программирования VGA через эти порты: mov dx, 3C8h xor al, al out dx, al — будем шить с самого начала. inc dx — 3C9h mov cx, 300h — 768 байт mov si, — адрес палитры из 768 байт rep outsb — зашить последовательно все 768 байт В итоге каждый цвет пикселя будет определяться значением от 0 до FFh.

Ух, ты спасибо большое! это примерно, то о чем я думал, сохраню эту инструкцию, она точно пригодится для экспериментов :)

имеешь в виду что можно вывести 256 разных цветов пикселей одновременно на экран, выбрав их из палитры в 65535 возможных цветов? вот это от 0-63h это яркость я так понял от 0 до 100 для каждого цвета из трех? это фотошоповскую палитру напоминает кстати :)

Нет. Без усилий ты можешь запрограммировать любые 256 цветов из 64^3=262144. При этом яркость каждого цветового канала от 0 до 63. С усилиями, можно всунуть 64000 из тех же 262144 уникальных цветов (т.е. каждый пиксель своим цветом). Палитра 256 цветная. Но занимает в памяти в три раза больше места. 256×3=768.

а ошибся, 262144 цвета, что то в голове было откуда то 65535, да интересно и вроде не очень сложно, надо запробовать :) Ну да я посмотрел, от 0-до63 в хексе это 100 уровней в dec скажем от самого темного красного до самого светлого 100 градаций, правильно я мыслю?

Не, яркость в диапазоне 0-3Fh, т.е. 64 уровня.

а ты правильно там вверху написал, что значение каждого цвета лежит в пределах от 0 до 63h ? а то я его в dec перевел

0-0% (черный), 63 - 100% яркости (синего,зеленого, красного)

Да я там много чего уже подкорректировал с момента написания...)

а ну правильно, чтобы клевая инструкция получилась куда можно будет всегда заглянуть! :)

Вот вчитываюсь, и родился вопрос, когда уже палитру залил значит в видеокарту, потом надо достать цветную точку и нарисовать ее в видеопамять, вот типа такого механизм? mov ax, 3c8h in ax,10 ;сместиться на 16 индекс палитры mov cx, 3 ; установим счетчик на 3 цикла считывания байтов rgbread: mov dl, 3c9h ;скопировать в dl адрес порта out bl, dl; скопировать тек знач. в порте 3c9h (r,g или b цвета пикселя) в регистр bl (при этом в порте 3с8h должно что-то инкрементироваться, чтобы след. итерацией считался байт следующего из трех цветов)? mov di, vid_mem_addr; установить di на адрес нужного пикселя на экране mov [di], bl; записать один из трех байтов в область видеопамяти inc byte di; увеличить на байт адрес di loop rgbread drawtoscreen: .. а потом как то вывести видеопамять на экран, учитывая частоту развертки и обратный ход луча :)) или это уже должно быть на экране? типа такого? прошу не судить строго, это родил мозг человека без доступа к компьютеру и никогда ничего подобного не делавшего :))

))) Нет, так однозначно не сработает) Да и не нужно. Всё гораздо проще: Вот ты окружность рисовал? А не задумывался почему она уже нарисовалась каким-то цветом и без того, что ты описал выше? Хм... Видимо там уже прошиты какие-то цвета, не так ли? И ты каким-то из этих цветов уже рисуешь эту окружность? В том коде, что рисует окружность, есть такая команда: mov b,[bx][di], 64h Что в исходнике выглядит так: mov byte [di+bx], color — именно эта команда выводит в адреса A000:0000-F9FF пиксель, цвет которого изначально был зашит производителем по смещению 64h. Почему выбрали 64h? Да потому что это более-менее яркий, нейтральный цвет похожий на белый. Все остальные цвета там бледные и мутные, так уж решил производитель по каким-то своим соображениям. Если подитожить: 1. Зашил 256 цветов по индексам 0..255 2. Вывел пиксель mov [di], al — где al это твой цвет от 0 до 255. DI — адрес от 0 до F9FFh Всё просто)

Ох, здорово, как все продумано, а я как раз сейчас размышлял об этом, почему там колор только 1 байт, а это значит просто индекс из 3c8h получается выводим в замапленную область видеопамяти! А я какой-то фигни понаписал :)

Помню давным давно, у меня под дос была программа autodesk animator pro вроде называлась, там помимо прочего, прежде чем рисовать, надо было набрать палитру, я только сейчас подумал, что это как-то связано было с ограничением видео режима, а в фотошопе кстати можно сохранять палитры 256 цветов, интересно какой там формат записи в rgb режиме, а так было бы удобно, набрал палитру, сохранил в файл и потом залил в участок памяти, откуда уже можно в видеокарту заливать

Попробуй сохранить картинку в формате pcx. Там вроде будет то что ты ищешь. Это будет статическая палитра для конкретной картинки. К примеру мне этого мало и приходится кодом генерить нужную палитру, что значительно уменьшает вес всей программы и при этом в нужный момент я получаю ту палитру, которая необходима.

Аниматор про работал с 256 цветовой палитрой, bmp. В то время поддержка канального цветового представления практически отсутствовала.

Вот нашёл время, точнее прогнал лень и попробовал замутить несколько палитр по 256 цветов.

Блин! Сто двадцать семь мегов!

Два килобайта?😁крутяк

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

Интересно, переходы плавные и в динамике а я думал что просто палитра типа меняется а экран не очищается а просто перекрашивается где надо, но для динамики такое не прокатит ведь, так в чем твое ноухау если не тайна? :)

Три 64-х градиента (R,G,B) двигаются поочерёдно вверх/вниз на 128 шагов. Получается 128×3×2=768 шагов полный период, всё равно что 768 палитр. Здесь одна палитра = 64×3 белых + 64×3 градиент + 128×3 = 768 байт. Исходя из этого можно попробовать посчитать сколько всего уникальных цветов.

Ничего не понятно но очень интересно :)

В общем через определённый промежуток времени перешиваешь значения в портах на другие. Со стороны выглядит как три лифта в 128-ми этажном здании: пока один идёт вверх, другие два стоят. Потом другой идёт и снова два стоят. И таким образом через 6 поездок всё повторяется по кругу. 6 = 3 лифта (RGB) × 2 направления.