за юлу плюс обеими руками за
на рассыпухе
к ULA + барсики есть, игрушки есть
ПДП есть схема у велесофт, ничего сложного
только где сам чип брать
Чорный Кот гдето в своих эмпиреях , к простым смертным не спускается
Вид для печати
за юлу плюс обеими руками за
на рассыпухе
к ULA + барсики есть, игрушки есть
ПДП есть схема у велесофт, ничего сложного
только где сам чип брать
Чорный Кот гдето в своих эмпиреях , к простым смертным не спускается
и зачем для какой то унылой ULA+ делать видеокарту? любители ЛА3 не поймут что такое FPGA
а можно и не так заполнять)) а ты подгоняешь управление девайсом под частный случай - нинада так делать!
потому и жёсткие, что выбираются один раз на всю игру
"как-то странно" заполнять экран непременно "без промежутков", когда в играх (втч Диззи) дофига экранов полупустых :D
я ж сказал - список пар "координаты, номер объекта" (и по номеру из массива прочие параметры взять)
для объектов одинакового размера, как ты хотел, можно тупо сделать сразу массив адресов изображений
остальные все параметры одинаковы, а экранный адрес в цикле меняешь сам
да размер тут совершенно же ни при чём, отрисовка - по порядку перекрытия у объектов
да здесь на форуме всегда народ общался "на ты"
блиттер может выводить изображения где угодно, заставлять его печатать "строками" - НЕлогично
нет, не хватит - ну, вот я, например, желаю кучу перекрывающихся слоёв (и даже независимых отдельных объектов) :p
---------- Post added at 02:24 ---------- Previous post was at 02:20 ----------
это можно делать в обычной памяти, а пассивные девайсы проще присобачить к любому спектруму
где проблема, вызвал простенькую процедуру, она кидает, времени на это уйдёт немного
"мелкий" доступ по одному объекту (или даже частичному параметру) тоже нужен (а точнее даже - необходим!)
а ресурсы железяки небесконечны, так что - только в качестве необязательной примочки, а не основы
---------- Post added at 02:25 ---------- Previous post was at 02:24 ----------
проще вейтить проц при переполнении буфера, всё равно оно маловероятно
разве что нарочно бомбить девайс переброской кучи огромных блоков
не, в простейшем варианте как раз в порты, буфер же прозрачно работать должен
есть он, или без него видеокарта всё успевает - программисту разницы никакой
---------- Post added at 02:28 ---------- Previous post was at 02:25 ----------
издиваишси? :) ну при чем тут видеокарта
wait проца как защиту от переполнения буфера
+ хорошо бы строчное прерывание
Размер тайлов выбирает разработчик игры и может изменить в любой момент
Промежутки после перехода в другое место может потребоваться заполнять черным тайлом, чтобы затереть предыдущую картинку (на этом месте в предыдущей картинке могло быть дерево или другой объект). Если наносим уже второй слой (этой же картинки) также построчно - можно использовать нулевой прозрачный спрайт. Или указывать координаты для каждого одиночного тайла. Можно конечно заполнить экран черным цветом, а потом рисовать одиночные объекты. Это выбирает разработчик игры - как ему удобно, так и заполняет. Новый графический режим только ускоряет вывод тайлов и спрайтов.Цитата:
"как-то странно" заполнять экран непременно "без промежутков", когда в играх (втч Диззи) дофига экранов полупустых :D
Дело в том что предлагаемый графический режим так тоже может, он используется для печати одиночных тайлов и спрайтов. Но для быстрого заполнения всего экрана и введена построчная печать, также как и печать вертикальными столбиками из тайлов. Согласитесь, если тайлы идут друг за другом, то координаты следующего тайла на экране может вычислять сама видеокарта. Если же указывать их для каждого тайла в строке - это замедлит вывод.Цитата:
я ж сказал - список пар "координаты, номер объекта" (и по номеру из массива прочие параметры взять)
для объектов одинакового размера, как ты хотел, можно тупо сделать сразу массив адресов изображений
остальные все параметры одинаковы, а экранный адрес в цикле меняешь сам
Печать строками и столбцами введена для ускорения вывода нескольких графических объектов.Цитата:
да размер тут совершенно же ни при чём, отрисовка - по порядку перекрытия у объектов
блиттер может выводить изображения где угодно, заставлять его печатать "строками" - НЕлогично
нет, не хватит - ну, вот я, например, желаю кучу перекрывающихся слоёв (и даже независимых отдельных объектов) :p
Я ведь и так предлагаю кучу перекрывающихся слоев и независимых объектов. Прозрачный цвет позволяет накладывать объекты без клешинга атрибутов. Указываем координаты на экране с точностью до точки для каждого объекта и печатаем по номеру. Не по адресу, а по координатам и номеру. А видеокарта/видеорежим сам определяет адреса. Ведь так проще и быстрее ?
Как выводить тайлы на экран построчно, столбиками или указывая координаты каждого - это выбор разработчика игры. Режим должен поддерживать все три вида печати. Это сделано для обеспечения скорости и гибкости построения экрана. Все это вместе с прозрачным цветом на краях тайлов и спрайтов, а также прозрачный тайл/спрайт с нулевым номером позволяет строить практически любые экраны в играх.
---------- Post added at 08:05 ---------- Previous post was at 06:58 ----------
Посмотрите там, может поможет. ULA + это всего лишь палитра. Она не облегчает написание игр. Мы хотим при той же графике упростить и ускорить построение изображений.
а если тайлы шестигранные? есть же куча игрушек где они именно такие
---------- Post added at 07:47 ---------- Previous post was at 07:31 ----------
опять же это какое то жесткое ограничение, т.е. нельзя карту бомбить большими изображениямии, а мочему собстно? Да и что такое большие? Это те что карта не успеет вывести пока проц не подаст следующую команду, ну к примеру какая та играшка, которой надо вывести ну 50-70 спрайтов, 32х32 на экран, карта однозначно не будет успеваь их походу отрисовывать, фифи переполнить нараз.
Вообще с портами работать это на самом деле криво, даже если эти порты в память отражены, нужно работать с командами и аргументами, а это поток команд с разным числом аргуметов, а еще лучше это высокоуровневый DisplayList
---------- Post added at 07:49 ---------- Previous post was at 07:47 ----------
экран 320х240 при тайле 8х8 это надо карте подать 40х30=1200 комнд, а если слове 3-4? ну блин тоже же глупо, проще такие тривиальные вещи как вывод мелких тайлов в цикле, обучить карту делать через КА
http://s020.radikal.ru/i704/1506/23/897b5c6723fdt.jpg
Нужно при печати очередной строки тайлов сместить координаты начала строки на требуемое место.
Тайлы произвольной формы надо вписыть в прямоугольный тайл и лишние части закрасить прозрачным цветом.
Можно для неизменяемой части экрана создать описание в виде строки данных типа SIZE, 8, 8, SPR_ADDR, 1, 2, PRINT, AT, X, Y, 1, 2, 3, 4, 5, ENTER, PRINT, 3, 4, 5, 6, 7, AT, Y2, X2, SPR_ADDR, 7, 8, SIZE, 20, 20, PRINT, 1, ... END.Цитата:
опять же это какое то жесткое ограничение, т.е. нельзя карту бомбить большими изображениямии, а мочему собстно? Да и что такое большие? Это те что карта не успеет вывести пока проц не подаст следующую команду, ну к примеру какая та играшка, которой надо вывести ну 50-70 спрайтов, 32х32 на экран, карта однозначно не будет успеваь их походу отрисовывать, фифи переполнить нараз.
Вообще с портами работать это на самом деле криво, даже если эти порты в память отражены, нужно работать с командами и аргументами, а это поток команд с разным числом аргуметов, а еще лучше это высокоуровневый DisplayList
---------- Post added at 07:49 ---------- Previous post was at 07:47 ----------
экран 320х240 при тайле 8х8 это надо карте подать 40х30=1200 комнд, а если слове 3-4? ну блин тоже же глупо, проще такие тривиальные вещи как вывод мелких тайлов в цикле, обучить карту делать через КА
Можно описать так 15 экранов и разместь в SD-RAM. Тогда при переходе Диззи в очередное место передавать видеокарте адрес описания фона этого места и команду типа DRAW_LOCATION. После этого сразу команды печати спрайтов объектов.
Для какой из конфигураций?
"METEOR"??? Почему не "болид" тогда? Неудачное название, это даже не объект какой-то там, а явление возникающее при сгорании... Не хотелось бы это явление наблюдать при подключении карты.
Параллельно не потяну, задача хоть и простая, но не из легких. Свои мысли устройства я наглядно изложил здесь в виде схемы.
Для VGA не хватает выводов, разве что 6bpp получится (решается простым переходником HDMI2VGA), выхлоп переходника можно на шурупы, чтобы карта не выпадала и всё хорошо.
Будет 60Гц как у нормальных людей, а 50Гц смотреть и фапать через SCART или S-Video с выхода видео компа, он то у нас будет свободный, я планирую TV подключить двумя шнурками VGA/SCART комп и HDMI для DivGPU или exGPU или как там по понятней карту назвать...
Большая скорость кого/чего? Во первых плохое соотношение цены и функционала. Уже лучше VNC2, дешевле и в разы для этого случая лучше.
Добавил в схему CP2104, раз нужна возможность отладки и загрузки обновлений или обмен данными с PC (USB-UART).
Раз пошла такая пьянка с U16, то мне лучше идти по пути совместимости обвеса и простоты. Т.к. отлаживать видео режим мне придется на U16, соответственно делать новую конфигурацию спека с этим режимом.
зачем ты вообще принуждаешь разработчика выбирать какой-то общий (пусть даже на время) размер?
ускорять и делать удобным нужно вывод ЛЮБЫХ объектов в ЛЮБОМ порядке
а ты хочешь один частный случай в ущерб другому - нинада так делать!
так - не может, блиттер выгодней запускать выдачей приёмника чем источника
можно быстро с промежутками печатать один объект, а потом к другому переходить
это как "быстрый" бег в грязи по колено вместо "медленной" ходьбы по дороге :D
а зачем им друг за другом идти так часто, чтобы обращать на это внимание?
вычисление координаты - это копейки, но из-за обязательного вывода ненужных тайлов они накапливаются
ты пойми: для разгрузки медленного z80 выгодней очистить полностью фон и вывести поменьше крупных объектов!
нифига не проще и не быстрее, а ты снова "улучшаешь" частный случай в ущерб ВСЕМУ!
а если вывод не в экран, а в буфер прямоугольный, а потом уже его на экран?
а если крупные объекты для начала конструируются из мелких, а после вывод?
а если у разраба более трёхсот объектов разных размеров?
или вовсе нарезаемых из большой картинки как ему нужно
как их напечатать по номерам?
как уже мной было сказано выше, для скорости гораздо выгодней не мельчить
а для гибкости в построении любого экрана хватит одного универсального интерфейса
---------- Post added at 18:36 ---------- Previous post was at 18:27 ----------
можно, но бессмысленно, потому что емнип блиттер с современной доступной памятью в одном кадре успевает обновить площадь экрана несколько раз, для over 95% игрушек этого хватит, притом место в буфере по ходу отрисовки даже очень крупных спрайтов всё же постепенно освобождается
к портам доступ нужен как ни крути, разраб может хоть скриптами хранить экраны, всех его хотелок не предусмотришь, и чем более высокоуровневый и специализированный интерфейс, тем больше шансов чем-то не устроить больше людей, в чём-то накосячить и недодумать
повторю, проще и быстрей не мельчить, и вообще отказываться от тайлов
или так :D только всё же лучше прямоугольником
Для работы видеокарта должна знать размер тайла/спрайта.
Чтобы можно было заполнить экран графикой, а не пустотой.Цитата:
а зачем им друг за другом идти так часто, чтобы обращать на это внимание?
При вводе параметров каждого тайла загрузка на Z80 тоже увеличивается.Цитата:
вычисление координаты - это копейки, но из-за обязательного вывода ненужных тайлов они накапливаются
ты пойми: для разгрузки медленного z80 выгодней очистить полностью фон и вывести поменьше крупных объектов!
Размер тайла выбирает разработчик игры, а не я.Цитата:
как уже мной было сказано выше, для скорости гораздо выгодней не мельчить
а для гибкости в построении любого экрана хватит одного универсального интерфейса
Доступ к портам медленнее, чем к ячейкам памяти, поэтому параметры и данные и передаются через область атрибутов стандартного экрана.Цитата:
к портам доступ нужен как ни крути, разраб может хоть скриптами хранить экраны, всех его хотелок не предусмотришь, и чем более высокоуровневый и специализированный интерфейс, тем больше шансов чем-то не устроить больше людей, в чём-то накосячить и недодумать
повторю, проще и быстрей не мельчить, и вообще отказываться от тайлов
или так :D только всё же лучше прямоугольником
Тайлы используют для экономии места на графику. Если рисовать каждый экран одним куском даже 8 мегабайтов не хватит.
я вот даже теряюсь, какой тут размер тайла выбрать http://pscd.ru/uploads/posts/2012-02...-edition-1.png
или тут
http://www.fresher.ru/images6/igrofr...-90-x/63_4.jpg
а в таком варианте?
http://spectrum4ever.org/files/screens/x1/2830/65.png
---------- Post added at 20:29 ---------- Previous post was at 20:28 ----------
почему именно через область атрибутов?
---------- Post added at 20:31 ---------- Previous post was at 20:29 ----------
5тыс записей в память будет медленней чем 100-200 записей в порт
почему это я? я не железячник, для меня это дебри. если к спектруму или какому клону 3д прикрутят, я может чёнить накидаю под это дело. а сам мутить железки - вот уж нет.Цитата:
Тогда прикручивай ordroid-w
а пока с вашими тайлами и фиксированными размерами мне и на спринтере удобно и хорошо.
Цифры и буквы - это тоже тайлы. Вы ведь не будете рисовать текст в виде картинки. Вы его печатаете из одних и тех же букв. И тексты можно писать разные. При этом средний размер памяти на изображение будет меньше, чем целыми картинками. Так в играх печатают огромные площади фона из нескольких типов тайлов.
Чтобы не занимать адреса старых и будущих устройств, чтобы был разнообразный способ адресации к ячейке разными командами на выбор программиста и меньше тратить времени на команды.Цитата:
почему именно через область атрибутов?
5тыс записей в память будет медленней чем 100-200 записей в порт
100-200 записей в область памяти быстрее, чем 100-200 записей в порт !
LD (BC), A ; 7 тактов
OUT (C),A ; 12 тактов
ладно, проектируйте как виднее, по всей видимости видеокарта будет ограничена пониманием вещей zst а не физическими возможностями
на колу мочало, начинай сначала... смысл блиттера в переброске блоков любых размеров
зачем карте с растровым экраном и блиттером знать размер фиксированного тайла?
и вообще "знать", как разработчик хочет работать с графикой?
это и без дурацких тайлов прекрасно делается, притом с меньшими нагрузками на процессор
а как раз твой способ приводит к худшим тратам времени на кучу мелких пустот
а все параметры не надо передавать, только те, что с прошлыми не совпали
и нагрузки уменьшаются многократно с ростом площади печатаемых объектов
нееет, так ему придётся выбрать из-за тебя!
хотя мог бы ничего и не выбирать, но твои ошибки его заставят
ты хоть иногда читаешь, что я пишу? все порты на память отображаются!
кроме одного, через который (однократно) и происходит выбор окна для них
и не надо будет лезть в атрибуты, лучше бы подумал о совместимости
8 мег это 4 194 304 двухбайтных пикселя, что больше чем игровая площадь всех экранов у Диззи-5 :p
а нарезкой даже очень крупными объектами - в разы меньше, так что нету никакой необходимости в мелкотайлах
непонятно лишь, зачем пытаться ускорить то, что в ускорении не нуждается
даже просто Спектрум, самый обычный, текст и то выводит вполне приемлемо
дык влезая в атрибуты, ты как раз адреса "старого устройства" (экрана) и занимаешь
и уничтожаешь притом возможность быстрой адаптации старых игр
---------- Post added at 07:37 ---------- Previous post was at 07:29 ----------
между прочим, я не первый раз отмечаю феномен зашоренности приставками
но обычно жертвы жаждут спрайтиков аппаратных, "шоб как на любимой %consolename%"
а тут случай уникальный на моей памяти - изувечить блиттер до их подобия :v2_wacko:
Ребята, вы извращаетесь сильно. Сделайте для начала простую макетину с необходимым обвесным минимумом, прикрутите к какому-нить пню128 или профику или к фениксу или к недоЭве и испытывайте начиная с какого-то минимального функционала. Сделайте хотя бы подобие спринтеровской графики. А то тайлы, спрайты, блиттеры. вы так ещё пару веков будете мусолить эту тему. будет железка для обкатки, тогда и говорите про навороты. если известна память, какая плисина ещё там всякое, вкарячте простой блиттер, самый простой, хоть от спринтера хоть какой. а потом уже дальше ехать.
Сложновато (да и не нужно) разбивать графику на куски по 256 значений.
Я прикинул, номер спрайта нужен не 256 значный, а двух байтовый.
С двухбайтовым всё норм.
При печати строки спрайтов, посылать карте 2 байта номера спрайта.
Всё ж у zst, при печати тайлами строки,
адреса считаются автоматом, т.е. это чуть быстрее.
Пример кода приведи, чтоб понятнее было.
как там у Леся Подерев'янського - "скорость охреневающая" )
Единственное отличие какое я вижу - там байт на точку и палитра, здесь 2 байта и без палитры.
И да судя по бурным дебатам я думаю что тайлы здесь не к месту - они лишь дополнительный промежуточный уровень абстракции - поэтому лучше без тайлов
Смотрю, интереса к карте здесь не у кого нет, будет ещё один хлам пылится, а времени и средств на её разработку потрачу не мало. Да и как показало время, всё что разработал тяну сам. Так что парни я тут пас. Создавайте соответственно тему на kickstarter, как к примеру на это барахло Bluetooth ZX Spectrum, собирайте средства на разработку, заинтересовывайте разработчиков и тех кто готов их поддержать, а иначе дела тут не будет. Не ценят здесь халяву...
DjVu говоришь :) :
IPVC http://zx-pk.ru/showthread.php?t=15176
http://zx-pk.ru/attachment.php?attac...5&d=1325174293
IPVC2 http://zx-pk.ru/showpost.php?p=401000&postcount=60
TSXB http://forum.tslabs.info/viewtopic.php?f=6&t=233
https://dl.dropboxusercontent.com/u/.../IMG_4888s.JPG
Не парни, лучше я сделаю конфигурацию того что выше для U16, дешевле и практичней получится.
http://zx-pk.ru/attachment.php?attac...6&d=1401869377
это всё не существующие девайсы, прототипы и не более. в массах нет, особенно ТСлабовой железки. он до сих пор там парится с ней судя по их форуму.Цитата:
DjVu говоришь
а что мешает сделать нормальный девайс для любого клона? что за ограничение такое?Цитата:
лучше я сделаю конфигурацию того что выше для U16
А что такое "нормальный девайс для любого клона"?
Ограничение - формула (сколько сейчас просят за zx-evo или клон, zx-spectrum + стоимость нормального девайса + стоимость разработки и ПО). Не, парни, уже лучше взять новое железо и не городить велосипед под ёлку. Спектрум пусть остаётся спектрумом, не нужен этот велосипед никому ещё с 1980-го :) Вы сообщения наверно с IBM PC 16bit + "нормальный девайс для любого PC" набираете здесь? :)
Ответ Иви на вопрос - "Что ты знаешь про zx-spectrum"
Вложение 52679
Я аж офигел от ответа :)
http://www.existor.com/ru/
MVV, а ты в ahdl разбираешься?
ну была мысль, но сейчас разборки тут учиняю. есть некоторые непонятки по работе с некоторыми железками, а сам я в ahdl не шарю и соответственно не знаю толком, как к ним обращаться. например, с теневой памятью (типа кэш). знаю, что для включения одной страницы нужно делать in a,(#fb). а как включать ещё 2 страницы (всего по описанию доступны 3 страницы), я не могу понять. ну и так по мелочам ещё тут есть. помог бы кто... ну и да, можно было бы портировать его на другую базу какую-то, тот же реверс.Цитата:
Думаешь Sprinter портировать как zx-evo?
ну, во-первых, "чуть", во-вторых, хранить экраны тайловыми строками неэффективно
нужно будеть больше номеров отправлять, и в итоге получается не быстрее
мы же это обсуждали давным-давно
ld bc,#port - единственный реальный порт вк
ld a,#XX - старший байт диапазона
out (c),a
всё, после этого запись по любому адресу #XX00-#XXFF
будет трактоваться видеокартой как запись в порт
с соответствующим номером (младший байт)
---------- Post added at 04:28 ---------- Previous post was at 04:15 ----------
а как с ней можно при 15-16bpp? :)
или ты об чём говоришь
Т.е. если у меня на U16 вывод 24bpp, то мне нужно перед выводом добавить память по 256 байт на каждый цвет?
r((x<=7)..0)->[addres(7..0),data(7..0)->R(7..0)
g((x<=7)..0)->[addres(7..0),data(7..0)->G(7..0)
b((x<=7)..0)->[addres(7..0),data(7..0)->B(7..0)
Я могу рассматривать сейчас это для U16. Не вопрос, можно сделать. Есть двухпортовая память 1 блок M9K=1024x9бит 9-й бит палитры к примеру задействовать как альфа. Получится 4-ре страницы палитры. Чтобы не использовать 3-ри блока, можно увеличить в трое частоту выборки выходных данных палитры (256х3=768 байт), это уже техническая сторона решения...
Спецификация этого "нового графического режима" есть?
Если нет, то для начала хотя-бы нужно привязаться к одному из стандартных видео разрешений. Взять к примеру индустриальный стандарт VGA 640х480@60Hz 24bpp, Pixel freq.=25.175 MHz(округлим под PLL до 25МГц).
Получается, что максимальное разрешение 640х480 24bpp, сюда теперь можно вложить несколько видео режимов, к примеру так:
1) 640х480
2) 320x240
3) ZX-Spectrum screen (x2 = H:32+256+32; V=24+192+24)
4) ZX-Spectrum screen (х1 = 4-ре поля H:32+256+32; V=24+192+24):
Фото режимов 3 и 4
Блиттером. Операция наложения с частичной прозрачностью "блока" из единственной точки на часть экрана.
Это лучше не через физическую палитру, а распаковкой сжатых изображений.
Так можно заменять раскраски (в том числе частично), не то что яркость.
Сорри, весь тред не осилил, но расскажу мнение адаптатора игр на примере Саботера 2. Мне было бы очень кайфово и быстро адаптировать Саботера, если бы можно было:
1. Сказать видеокарте, что у меня n тайловых слоев.
2. Отправить ей тайлы 8x8 для каждого слоя
3. Замапить куски ОЗУ на тайловые буфера для слоев.
4. Получить от карты момент окончания отрисовки экрана чтобы включить другую страницу с тайлмапами в момент отрисовки бордюра.
Это позволит мне отключить рендерер. А, чтобы оптимизировать вывод тайлов в тайлмапы, было бы неплохо, чтобы сами тайлмапы были размером больше, чем 32x24, желательно раза хотя бы в 3. Чтобы не париться с клиппированием.
PS Не претендую на то, что так оно будет удобно для всех игр. С Elite такое явно не прокатит, ей нужен 3D-успоритель :)
То есть для гашения нужна команда, по которой видеокарта должна будет пройтись по всем точкам экрана: прочитать точку из буфера экрана, уменьшить число в каждом канале RGB на 1 и записать обратно в буфер экрана. За 31 цикл с паузами для обеспечения нужной скорости можно плавно погасить весь экран.
---------- Post added at 23:39 ---------- Previous post was at 23:25 ----------
INT надо подавать после отображения на телевизоре правой нижней точки экрана 256х192 ?
Т.е. каждую локацию подготовить в виде таблицы 32х24 тайла (768 на экран) и загрузить в SDRAM в буфер локаций. Дополнительные слои делать с прозрачными цветами и прозрачным спрайтам № 0. После этого для копирования из буфера локаций в буфер экрана достаточно будет указать адрес локации. После перехода в новое место скопировать в буфер экрана нижний слой, потом спрайты героев, потом верхний слой. Я правильно понял?Цитата:
Это позволит мне отключить рендерер. А, чтобы оптимизировать вывод тайлов в тайлмапы, было бы неплохо, чтобы сами тайлмапы были размером больше, чем 32x24, желательно раза хотя бы в 3. Чтобы не париться с клиппированием.
PS Не претендую на то, что так оно будет удобно для всех игр. С Elite такое явно не прокатит, ей нужен 3D-успоритель :)
Сколько примерно надо локаций?
Сколько байтов надо на номер тайла ?
Перечислите, пожалуйста, названия игр, для которых такой способ тоже подойдет.
А для каких нужен другой способ ?
Какой ?
Кто-бы что тут не говорил... вот рабочий пример, можно попробовать в конфигурации Zet:
Взято отсюда: http://devotes.narod.ru/Books/3/ch05_10d.htmКод:; fadeout.asm
; выполняет плавное гашение экрана
.model tiny
.code
.186 ; для команд insb/outsb
org 100h ; СОМ-программа
start:
cld ; для команд строковой обработки
mov di,offset palettes
call read_palette ; сохранить текущую палитру, чтобы
; восстановить в самом конце программы,
mov di,offset palettes+256*3
call read_palette ; а также записать еще одну копию
; текущей палитры, которую будем
; модифицировать
mov cx,64 ; счетчик цикла изменения палитры
main_loop:
push cx
call wait_retrace ; подождать начала обратного хода луча
mov di,offset palettes+256*3
mov si,di
call dec_palette ; уменьшить яркость всех цветов
call wait_retrace ; подождать начала следующего
mov si,offset palettes+256*3 ; обратного хода луча
call write_palette ; записать новую палитру
pop cx
loop main_loop ; цикл выполняется 64 раза - достаточно для
; обнуления самого яркого цвета (максимальное
; значение 6-битной компоненты - 63)
mov si,offset palettes
call write_palette ; восстановить первоначальную палитру
ret ; конец программы
; процедура read_palette
; помещает палитру VGA в строку по адресу ES:DI
read_palette proc near
mov dx,03C7h ; порт 03C7h - индекс DAC/режим чтения
mov al,0 ; начинать с нулевого цвета
out dx,al
mov dl,0C9h ; порт 03C9h - данные DAC
mov cx,256*3 ; прочитать 256 * 3 байта
rep insb ; в строку по адресу ES:DI
ret
read_palette endp
; процедура write_palette
; загружает в DAC VGA палитру из строки по адресу DS:SI
write_palette proc near
mov dx,03C8h ; порт 03C8h - индекс DAC/режим записи
mov al,0 ; начинать с нулевого цвета
out dx,al
mov dl,0C9h ; порт 03C9h - данные DAC
mov cx,256*3 ; записать 256 * 3 байта
rep outsb ; из строки в DS:SI
ret
write_palette endp
; процедура dec_palette
; уменьшает значение каждого байта на 1 с насыщением (то есть, после того как
; байт становится равен нулю, он больше не уменьшается из строки в DS:SI
; и записывает результат в строку в DS:SI
dec_palette proc near
mov cx,256*3 ; длина строки 256 * 3 байта
dec_loop:
lodsb ; прочитать байт,
test al,al ; если он ноль,
jz already_zero ; пропустить следующую команду
dec ax ; уменьшить байт на 1
already_zero:
stosb ; записать его обратно
loop dec_loop ; повторить 256 * 3 раза
ret
dec_palette endp
; процедура wait_retrace
; ожидание начала следующего обратного хода луча
wait_retrace proc near
push dx
mov dx,03DAh
VRTL1: in al,dx ; порт 03DAh - регистр ISR1
test al,8
jnz VRTL1 ; подождать конца текущего обратного хода луча,
VRTL2: in al,dx
test al,8
jz VRTL2 ; а теперь начала следующего
pop dx
ret
wait_retrace endp
palettes: ; за концом программы мы храним две копии
; палитры - всего 1,5 Кб
end start
Ну, это так для примера, чтобы понятнее было как оно в реале на пальцах по простому работает.
У меня уже написаны модули текстового и графического режимов для VGA 640x480@60Hz (ссылка).
Текстовый режим 80х30 16 цветов, под текст и атрибуты используется 4800 байт, символы с атрибутами хранятся линейно - символ 0, атрибут 0, символ 1, атрибут 1, ... символ 2399, атрибут 2399. Реализован аппаратный курсор, может принимать два вида - большой и подчеркивание.
Графический режим 640х480@60Hz 24bpp, используется 921600 байт, точки хранятся линейно - (R,G,B); (R,G,B); ...
Попробую сделать ещё палитру. У кого есть желание и FPGA платы могут уже подключаться, есть возможность попробовать свои силы и научить нас чему-то...