Просмотр полной версии : Новый формат графического изображения для ZX совместимых компьютеров.
Молодость моя (начало 90-х) прошла с компьютером ZX-spectrum (уже не помню название клона),
причем с переделанным цветным телевизором Юность Ц-401 в качестве монитора.
Ностальгия по тем временам до сих пор не дает покоя.
Так как по работе иногда приходится иметь дело с видеографикой,
а так же в качестве хобби занимаюсь разработкой FPGA процессоров и
компьютеров на них, постоянно сталкиваюсь с проблемой нехватки графический ресурсов.
Экспериментировал с разными форматами представления изображения,
занимался аппаратными кодеками и векторными сопроцессорами.
На плате с FPGA, помимо своих проектов компьютеров, зашиваю и HDL клоны ZX спетрумов.
На форуме часто вижу предложения по улучшению графики существующих игр на спектруме.
Экспериментируя с разными принципами сжатия изображения обнаружил один очень подходящий
способ улучшить изображение спектрума. Суть в следующем.
Растр 256 х 192 элементов изображения с одним битом на элемент сохраняется,
а атрибуты знакомест меняются на атрибуты блоков. Знакоместо 8х8 делится на четыре
блока 4х4. Атрибуты блока представляются четырьмя байтами (2 байта на INK и 2 байта на PAPER)
в формате RGB565. Формат можно изменить на RGB555 зарезервировав один бит на прозрачность.
Таким образом объем растра сохранился (0х1800), а объем атрибутов вместо 0х300 стал 0х3000.
Для непрерывности загрузки экрана я поставил область новых атрибутов в начало перед растром.
Размер всего изображения стал 0х4800, где первые 0х3000 - область атрибутов блоков,
а последующие 0х1800 - область растра. В FPGA версиях ZX спектрума изображение нужно загружать
с адреса 0х1000, чтобы VGA контроллер работал по адресам 0х1000...0х5800. ROM по адресам
0х0000...0х4000 используется процессором только по чтению. Можно ли новый формат реализовать в
"железных" клонах - не знаю. Но в видеокартах наверное можно. В эмуляторах - тоже.
При таком формате изображения конфликт атрибутов уменьшается, хотя не исчезает полностью.
Зато количество цветов становится 64К для INK и 64К для PAPER при RGB565.
HDL контроллер VGA на новый формат пока не сделал, чтобы проверить реально. Но написал
конверторы на Си (в Widows) для преобразования картинок RGB888 в новый формат и обратно.
Как причешу - выложу. По образованию я радиотехник, а не программист.
Пока использую расширение файлов нового формата <>.scn. Может надо как-то по другому?
Не знаю нужна ли шапка у файла нового формата для указания информации об изображении.
Вот несколько примеров преобразования (слева оригинал RGB888, справа обратное преобразование в RGB888):
59475
59476
59477
59478
Выкладываю программу для Windows (Visual Studio) с преобразованиями из BMP24 в SCN и обратно.
https://cloud.mail.ru/public/6Lt6/6reBxdpCv
https://cloud.mail.ru/public/79DU/LAzM1EScC
P.S. На авторские права не претендую.
Данный формат можно использовать где угодно и кем угодно.
Оспаде, да что же вы мучаетесь с этими атрибутами. сделайте уже нормальный 256x192x8bpp. fpga не дистрофичные, всё что угодно туда влезет. чё на LE-то экономите. вам же их не паять.
да что же вы мучаетесь с этими атрибутами.
экран получается в 2раза меньше,чем нормальный 256x192x8bpp,и страница под атрибуты одна всего+совместимость с оригиналом.Правда смутно себе представляю ,как на z80 ,это все добро ,обрабатывать быстро.
Кто писать-то будет подо все это?
экран получается в 2раза меньше,чем нормальный 256x192x8bpp,и страница под атрибуты одна всего+совместимость с оригиналом.Правда смутно себе представляю ,как на z80 ,это все добро ,обрабатывать быстро.
это всё даже не проблема. главное - нет никаких клешенгов и тупых атрибутов. каждая точка своим цветом. это же и красиво и удобно. а учитывая, что есть весьма дешёвые и жирные плисины, никто не мешает туда засунуть какой-нить мелко блиттер.
если вам нафиг блиттеры не нужны и вам хочется пихать данные самолично прям в экран, то для чем вы извращаете этот режим? чем тогда стоковый 256на192 не угодил? расширьте его палитру, а остальное не трогайте.
и ещё не понятно, почему все как огня боятся палитру 888? на моей памяти только 1 клоноавтор сделал полную палитру - Ivan Mak. У остальных вечно какие-то отмазки.
Lethargeek
21.01.2017, 16:10
атрибуты были актуальны в 80-е как способ сэкономить на скорости и размере памяти под экран, что уже бессмысленно в наше время
а тем более выдумывать новые несовместимые по адресации атрибуты, смысл имеет только старые немного улучшить, встраивая в новый режим
преобразование в RGB888
"Екорный бабай" , когда вы успокоитесь с вашими идеями, посмотрите на SAM COUPE, ALEST 5, SPRINTER
под атрибуты написано много софта. избавиться от них врядли получится, мне в zxpoly когда разрабатывал видеорежимы то понравился режим когда атрибуты с 4х экранов ложатся шахматкой, получается 512x384 и при этом в 8 на 8 можно играться с цветами и миксовать и совместимость со старым софтом сохраняется что недоступно тому же spec256 который только красит
https://github.com/raydac/zxpoly/blob/master/docs/screenshots/zxw_zxpoly512x384.png?raw=true
Smalovsky
22.01.2017, 01:11
Я размышлял на одном спектрумистском чате :
<small> Сильно, много 4 байта на атрибуты блока. Надо было байт на инк и байт на папер.
<small> Два байта на атрибуты блока. Старший бит яркость, семь младших цвета как у сэмкупа.
<small> Размещать расширенные атрибуты в теневом экране в адресах стандартного экрана.
<small> Переключение экран/атрибуты через порт.
При уменьшении атрибутов блока до 1 байта как на INK, так и на PAPER, резко ухудшается качество изображения.
На картинках слева направо RGB888 RGB565 RGB332:
59499
59498
59497
59496
59495
59494
под атрибуты написано много софта.
да как вас самих от таких идей на изнанку не выворачивает. всё хотите "антиклешинг" какой то создать или что? делайте нормальный режим. атрибуты пусть в 128м остаются.
Lethargeek
22.01.2017, 15:41
При уменьшении атрибутов блока до 1 байта как на INK, так и на PAPER, резко ухудшается качество изображения.
На картинках слева направо RGB888 RGB565 RGB332:
а при размытии (методом флойд-стейнберга, например) качество подтягивается к лучшему
и раз уж начал резать атрибут знакоместа, так не останавливайся уже, на все 64 части его дели :)
тогда выйдет что-то наподобие этой схемы:
http://zx-pk.ru/threads/21462-bystraya-videokarta-quot-meteor-2013-quot.html?p=869225&viewfull=1#post869225
http://zx-pk.ru/threads/21462-bystraya-videokarta-quot-meteor-2013-quot.html?p=870718&highlight=#post870718
При уменьшении атрибутов блока до 1 байта как на INK, так и на PAPER, резко ухудшается качество изображения.
Ближайшим соседом - да, а флойдом будет очень неплохо. Я сам экспериментировал с 256х192х8 бит на точку в виде RGB323 и RGB332, последнее лучше получается. А для игр и программ тем более нормально. Правда, со скоростью засада.
У вас тоже со скоростью засада - крутить столько атрибутов тоже не быстро. А если использовать ускоритель, то можно и без атрибутов, сразу 8 бит прямо RGB332 или через палитру, так даже копир будет проще - копировать надо только одну область.
Smalovsky
22.01.2017, 20:45
Короче, моё предложение: Атрибуты - байт на инк и байт на папер для области 4x4 пикселя. Расширенные атрибуты в теневой страницы по адресам графического экрана спектрума. Переключение страниц через порт. Для расширения цвета палитра в 256 шестнадцатибитных цветов( например, сделать отображаемой на память через управляющий регистр как в тсконфе).
Расширенные атрибуты в теневой странице могут адресоваться по следующим схемам:
010|бит переключения байта инк/папер|6 бит для номера ряда знакомест| 6 бит для номера столбца знакомест.
При такой схеме адресации адресное пространство атрибутов делится на две области. Одна область для байт инк( или папер по выбору), другая для байт папер( или инк по выбору). Выбор областей для инк или папер можно делать через управляющий регистр.
010|6 бит для номера ряда знакомест| 6 бит для номера столбца знакомест|бит переключения байта инк/папер
6 бит для номера столбца знакоместа + бит переключения байта инк/папер = 7 бит для слошной нумерации столбцов знакомест(0, 2, 4, ... - инк(папер), 1, 3 , 5, ... - папер(инк)). Выбор порядка следования инк старший или инк младший можно делать через управляющий регистр.
При такой адресации байты атрибутов идут линейно подряд.
И того - графическая информация 6144 байта, расширенный атрибуты 6144 байта. ОбЪём данных не превышает объёма данных для аппаратного мультиколора, но при этом клешинг частично устраняется немного сбалансированней чем у мультиколора.
Вот как решил вопрос с палитрой тэсэлыч:
Q: Как загрузить палитру?
А: Поскольку палитра хранится во внутренней памяти FPGA, надо включить отображение оной на память процессора. Для этого надо записать в регистр FMAddr (0x15AF) значение 0001bbbb, где bbbb - 4 старших бита адреса, куда мапится массив палитры, а 1 - разрешение записи. Например: значение 0х18 откроет палитру на запись с адреса 0х8000, а 0х10 - с 0х0000. После записи палитры в FMAddr надо записать 0 для отключения маппинга.
Палитра работает ТОЛЬКО на запись. Чтение из выбранной памяти равносильно чтению из ПЗУ/ОЗУ, которое там находится.
Надо посмотреть как выглядят 256 цветные изображения с учётом палитры.
Расширенные атрибуты в теневой страницы по адресам графического экрана спектрума. Переключение страниц через порт. Для расширения цвета палитра в 256 шестнадцатибитных цветов
Т.е., предлагается сделать палитру к палитре? :)
Smalovsky
22.01.2017, 22:09
AzAtom, ты ничего не знаешь о палитре VGA или BMP для 256 цветов?
Почитай, разберись.
Smalovsky, знаю, конечно. И там нет никаких атрибутов. Там число в пикселе является номером цвета в палитре. А ты пишешь, что есть атрибуты и ещё Для расширения цвета палитра в 256 шестнадцатибитных цветов
А у спектрума атрибут и есть по сути палитра, только для 8х8 пикселей и цветов мало. Потому и спрашиваю.
- - - Добавлено - - -
Кстати, кто-то пробовал стандартный атрибут переделать из FBIIIPPP в RGB IIIIPPPP, оставив те же знакоместа? Ведь, по сути, мерцание применяется очень редко, мало кому оно нужно.
Smalovsky
22.01.2017, 22:31
AzAtom, ну дык байт для инк или папер тоже является номером цвета в палитре, которая хранится в памяти фпга. Чего непонятного? Новые атрибуты в теневой странице кодируются как байт для инк и байт для папер. Палитра для палитры это ещё как понять область управляющей информации(однобитный цвет или выбор инк|папер).
Жалко что человек удалил сообщение. Я хотел написать что дальше.
Чего непонятного?
Не совсем понятно, зачем городить огород. Автор темы уже предложил по 16 бит на инк и 16 бит на папер. По количеству цветов будет как у тебя. Правда, объём атрибутов будет в 2 раза больше, надо будет ещё одну теневую область подключать. Да, есть над чем подумать. :)
Хотя, лично моё мнение, хватит 8 бит атрибута на инк и 8 бит на папер без расширения палитрой. Просто преобразовать прямо RGB332.
Smalovsky
22.01.2017, 23:16
AzAtom, палитра для атрибутов это не ноу-хау. Например, палитра для цветов атрибутов используется в ulaplus. Есть поддержка в эмуляторе.
https://sites.google.com/site/ulaplus/home
Такая технология имеет большой плюс - палитровые эффекты. Например, что бы сделать эффект плавного затемнения для моей программной модели нужно периодически переписать 512 байт для палитры(256x2). Это лучше, чем периодически перелопачивать 12 кб атрибутов как предполагается в оригинале.
James DiGreze
23.01.2017, 08:52
Кстати, кто-то пробовал стандартный атрибут переделать из FBIIIPPP в RGB IIIIPPPP, оставив те же знакоместа? Ведь, по сути, мерцание применяется очень редко, мало кому оно нужно.Такое появляется как побочный эффект реализации режима Alco 16C.
В первое сообщение вставил проект для преобразования bmp в scn и обратно.
Не знаю как передать параметры программе, поэтому названия файлов задаются в исходнике.
Вроде, системный массив argv[] содержит в 0 элементе имя исполняемого файла и дальше переданные параметры. http://cppstudio.com/post/421/
- - - Добавлено - - -
Ynicky, твой новый формат изображения для спектрума очень тесно связан с необходимостью аппаратного вмешательства. То есть, нужен такой новый графический режим, который нативно отображал бы на экране данные из этого нового формата без необходимости преобразования данных перед загрузкой в видеопамять. В этом случае добро пожаловать в пересекающуюся тему Новый принцип устранения клешинга (http://zx-pk.ru/threads/26792-novyj-printsip-ustraneniya-kleshinga.html).
http://cppstudio.com/post/421/
Это пример для консоли. Я свой проект сделал из примера на неконсольное приложение.
Понятно. Ну тогда наверное есть какой-либо визуальный компонент диалог открытия файлов.
Для примера сделал из первой картинки, слева направо, сверху вниз: RGB888, далее RGB332 методами Флойда-Стейнберга, сеткой, случайный шум, ближайший сосед.
Как видно, даже для фото получается вполне неплохо.
59840
- - - Добавлено - - -
Блин, сайт пережимает картинки, хуже видно точки.
Smalovsky
23.02.2017, 11:52
AzAtom, учитывал атрибут 4 на 4(или 4 на 2) ?
Smalovsky, без атрибутов, просто 8 бит на пиксель, RGB332.
Переделал программы в первом посте для работы с командной строки.
При написании видеоконтроллера оказалось, что на частоте работы 25 МГц
ему не хватает производительности. Решил переделать атрибуты с одним
байтом на INK и одним на PAPER. В этом случае как растр так и атрибуты
занимают по 0x1800 байтов. Общий размер - 0x3000. Поэтому поместил
в файле SCN атрибуты после растра, чтобы изображение умещалось
в одну страницу 16 кБ. Сделал проект на плате Марсоход3.
Архитектура - как у Spectrum128, только вместо BASIC128 пока написал
простенький монитор. Память ROM (монитор 16 кБ), BASIC48 (16 кБ),
VRAM (две страницы по 16 кБ) и быстрая нижняя память RAM
(две страницы по 16 кБ) занимают внутреннюю память FPGA.
Остальные 28 страниц RAM по 16 кБ находятся во внешней SDRAM.
видеоконтроллер работает в 2-х режимах: стандартном и расширенном.
Пока не могу проверить BASIC48, так как не знаю что нужно сделать
в мониторе для его запуска. Значение 0x33 в порт #7FFD записываю.
А что нужно еще - не знаю. В интернете не нашел.
Может кто знает как из BASIC128 попасть в BASIC48?
Программы для Windows (Visual Studio) с преобразованиями
из BMP24 в SCN8 и обратно:
59845
59844
Картинки:
59846
59847
Smalovsky
23.02.2017, 21:45
Ynicky, может, лучше атрибуты не 4 на 4, а 8 на 2( в тандартном знакоместе получается тоже 4 атрибута как и при атрибуте 4 на 4) ?
может, лучше атрибуты не 4 на 4, а 8 на 2
Мне кажется, качество по горизонтали будет плохое, а по вертикали хорошее.
И конфликт атрибутов по горизонтали останется прежним.
Хороший вариант получается если в растре использовать два бита на пиксель.
При этом в стандартном знакоместе (8х8) будет не 2 атрибута (INK и PAPER), а четыре.
При байтовом размере атрибутов изображение не будет превышать 16 кБ.
И конфликта атрибутов не будет, если следовать следующим правилам:
- 1 атрибут на фон и 3 атрибута на спрайт;
- 2 атрибута на фон и 2 атрибута на спрайт;
- 3 атрибута на фон и 1 атрибут на спрайт;
Smalovsky
24.02.2017, 00:11
Ynicky, при двух битах на пиксель старые методы кодирования графики не подойдут. Количество байтов под атрибуты 768х4х2=6144 при байт на инк и байт на папер. Растр 6144х2=12288 байт.
Если делать атрибут 8 на 2, то будет подобие аппаратного мультиколора с расширенными атрибутами. Но есть плюс - есть наработки для мультиколора в движке нирвана с размером чанка 8 на 2( биколор). Там режим программный, а при аппаратном ускорении высвободится больше быстродействия. Вот ссылка про движок
http://zx-pk.ru/threads/22175-novyj-multikolornyj-dvizhok-nirvana.html
спрайты в мультиколоре 8 на 2.
http://speccy.info/w/images/3/3c/NirvanaSprites.gif
Наработки программные с нуля не надо писать будет.
Lethargeek
24.02.2017, 01:12
Если делать атрибут 8 на 2, то будет подобие аппаратного мультиколора с расширенными атрибутами.
а если делать атрибут 1 на 1, то получится подобие целого вороха режимов, в том числе пока еще не придуманных :D
Smalovsky
24.02.2017, 01:25
а если вспомнить
Вот если бы увеличить цветовое разрешение в два раза (то есть поделить знакоместо
на четвертушки - и для каждой свой атрибут) - качество картинки сразу резко
улучшится, угловатость практически сойдет на нет, мелкие спрайты можно раскрасить.
И чанки цветные сделать!
Lethargeek
24.02.2017, 01:47
а если вспомнить
и внимательно посмотреть на дату...
- - - Добавлено - - -
элементная база сильно с тех времён изменилась (и вероятно, позволяла больше даже тогда)
Smalovsky
24.02.2017, 01:54
элементная база сильно с тех времён изменилась (и вероятно, позволяла больше даже тогда)
позволяла конечно, но никто не делал. А то что наделали уже не считают спектрумом - атрибутов-то нет!
Lethargeek
24.02.2017, 01:57
не считают спектрумом - атрибутов-то нет!
не поэтому, а потому что программируется иначе
не поэтому, а потому что программируется иначе
не поэтому а потому что "элементарная база изменилась" и стало не интересно программировать под монстра (его место занял orange pi)
Smalovsky
24.02.2017, 13:20
Я немного упрощенно написал про атрибуты.))
Проблема в том, что при значительном изменении графического режима значительно возрастает объём графической информации. При этом для работы с такими объёмами памяти схема подключения дополнительных страниц спектрума 128 неудобна, поэтому разработчики гибридов делают свои уникальные менеджеры страниц, способных подключать любую страницу в любой из четырёх банков адресного пространства. И как следствие схема подключения страниц спектрума 128 лежит в этих гибридах балластом, как и ПЗУ спектрума 128.
Единственный выход - не отдалятся слишком далеко от видеорежима спектрума.
Lethargeek
24.02.2017, 15:07
не поэтому а потому что "элементарная база изменилась" и стало не интересно программировать под монстра (его место занял orange pi)
Как раз поэтому - потому что монстры программируются иначе (а раз так - зачем в них собственно Спек?)
Проблема в том, что при значительном изменении графического режима значительно возрастает объём графической информации. При этом для работы с такими объёмами памяти схема подключения дополнительных страниц спектрума 128 неудобна, поэтому разработчики гибридов делают свои уникальные менеджеры страниц,
Смотря в чём измерять "объём графической информации". Если в ПИКСЕЛЯХ, то он вовсе может не измениться, и обрабатываться аналогично Спеку, и с не меньшей скоростью, чем на Спеке. Только нужен не очередной менеджер страниц, а специальный "менеджер" операций с ПИКСЕЛЯМИ (и неважно, сколько бит на пиксель тогда приходится).
Alex Rider
25.02.2017, 02:12
Значение 0x33 в порт #7FFD записываю.
А что нужно еще - не знаю. В интернете не нашел.
Может кто знает как из BASIC128 попасть в BASIC48?
Если насовсем, то out (#7ffd),#20. Если на чуть-чуть, то out (#7ffd),#10 - туда, out (#7ffd),#00 - обратно
- - - Добавлено - - -
Пока не могу проверить BASIC48, так как не знаю что нужно сделать
в мониторе для его запуска.
Запоздалая мысль. out (#7ffd),#33 включит BASIC48 (и страницу 4 в #c000, не знаю зачем тебе это), но сброс не сделает, продолжит исполнение в другой ROM со следующего после out адреса. А что там в ROM1? Если хочешь сброс, делай out либо в RAM, либо в том адресе ROM0, после которого ROM1 уйдет на сброс (например, затолкай в стек #0000 и переключись там, где в ROM1 по следующему адресу будет ret). Переключение в RAM надежнее.
Alex Rider, спасибо за подсказку.
Сделал так:
0048 BASIC48
0048 31 00 3D ld SP,#3d00
004B 3E 33 ld a,#33
004D 01 FD 7F ld bc,#7ffd;
0050 ED 79 out (c),a
0052 C9 ret
Так как команда ret имеет еще 2 чтения адреса, то записывать в стек #0000 нельзя.
ПЗУ уже переключилось на BASIC48, а там по начальным адресам не нули.
Нашел в BASIC48 место с нулями - #3d00, и записал это в стек.
После этого сработало как надо.
Если делать атрибут 8 на 2, то будет подобие аппаратного мультиколора с расширенными атрибутами.
Сделал преобразование блоков в 8х2.
Вот что получилось.
Слева направо: RGB888, блоки 4х4, блоки 8х2.
59865
59866
59867
59869
59871
59872
59873
59874
В принципе разница у 4х4 и 8х2 минимальная.
Alex Rider
26.02.2017, 06:02
Так как команда ret имеет еще 2 чтения адреса, то записывать в стек #0000 нельзя.
ПЗУ уже переключилось на BASIC48, а там по начальным адресам не нули.
Нашел в BASIC48 место с нулями - #3d00, и записал это в стек.
После этого сработало как надо.
Ага, точно. Важно еще, что в ROM1 по адресу 0052 тоже ret. Собственно, в твоем мониторе ret по 0052 не сказать, чтобы нужен, но и не возбраняется. Если надо сэкономить, можно попробовать так (пишу без отладки, из головы):
org #0273
ld a,#30
ld bc,#7ffd
out (c),a
rst #0
По адресу #027a лежит #c7 = rst #0, что тоже сброс. Но да, #c7 встречается нечасто, поэтому куда угодно этот кусок не засунешь.
004B 3E 33 ld a,#33
А зачем #33? При переходе в ROM1 с #c000 включится страница 3 - это так специально надо?
А зачем #33? При переходе в ROM1 с #c000 включится страница 3 - это так специально надо?
Я думал, что в Spectrum-е 48K используется 1, 2 и 3-я страницы. А так как у меня 3-я страница находится в быстром внутреннем ОЗУ FPGA, то я ее и подключил. Хотя программе все равно 0-я или 3-я страницы. Во внутренней памяти у меня находятся 2, 3, 5, и 7-я страницы.
P.S. Забыл еще сказать. Процессор у меня стоит nextZ80, работающий на частоте 40 МГц с каждым вторым wait стейтом при работе с внутренними ROM и RAM. При работе с внешней SDRAM wait останавливает процессор на 10 тактов из 11. При переходе на BASIC48 - тоже на 10 из 11 с внутренней памятью (3,64 МГц).
gurfunkel
26.02.2017, 08:53
В принципе разница у 4х4 и 8х2 минимальная.
Да нет, у 8х2 сильнее заметна "пикселизация", т.е. квадраты видны.
Alex Rider
26.02.2017, 13:10
Я думал, что в Spectrum-е 48K используется 1, 2 и 3-я страницы.
Нет, в 48К (точнее, после установки 5 бита #7ffd) все равно какая страница включена, но единственная - #7ffd после этого блокируется, и до аппаратного сброса страницу поменять не получится. Оригинальный BASIC48 ничего про страницы не знает, какую впечатали, той и пользуется.
Сейчас работаю над новой конфигурацией ts-conf для плат ReVerSE и DivGMX. Конфигурация будет на базе двух ядер Next (оптимизированный NextZ80, уменьшено время выполнения некоторых команд, добавлен кеш и дополнительные команды) по 42/50MHz с графикой 256х192 8bpp (256 цветов) с последующим переходом на 640х480 8/15/24bpp (16M цветов) для возможности реализации игр подобных StarCraft с минимальными изменениями графики.
Здравствуйте, vlad. У меня стоит Ваш процессор на VHDL. А зачем 2 ядра? Какие функции у каждого?
Если смогу адаптировать Вашу новую конфигурацию в Марсоход3, было бы здорово.
Hacker VBI
26.02.2017, 13:58
Сейчас работаю над новой конфигурацией ts-conf для плат ReVerSE и DivGMX. Конфигурация будет на базе двух ядер Next (оптимизированный NextZ80, уменьшено время выполнения некоторых команд, добавлен кеш и дополнительные команды) по 42/50MHz с графикой 256х192 8bpp (256 цветов) с последующим переходом на 640х480 8/15/24bpp (16M цветов) для возможности реализации игр подобных StarCraft с минимальными изменениями графики.
довольно интересно. а сколько таких ядер в чип влезет безболезненно?
Smalovsky
26.02.2017, 20:51
Ynicky, я вот подумал, что 4х4 является симметричным( расположение атрибутных областей в одном знакоместе симметрично - две по горизонтали и две по вертикали) и представление программной модели более проще чем у 8х2. У режима 8х2 в одном знакоместе четыре атрибутных области расположенных по вертикали, а по горизонтали укладывается только одна, то есть режим не симметричен и его программная модель сложнее.
Для симметричного 4x4 можно в играх хоть вид сбоку, хоть сверху, а для несимметричного 8х2 только с боку( при виде сверху персонаж игры будет отображаться по разному в зависимости от его ориентации из-за несимметричности расположения атрибутных знакомест 8х2). Можно конечно для 8х2 и вид сверху в играх, но тогда теряется преимущество перед обычным видеорежимом.
Хотя плюс 8х2 наличие программных наработок, которые можно взять за основу. Нужно посоветоваться с экспертами какой размер атрибутной области нужен. Например, Денис Грачёв изучал мультиколор 8х2( я об этом что-то читал) для движка нирвана. Может, он напишет своё мнение. Я посоветуюсь, по возможности, с алоне_кодером.
А я тут решил еще один эксперимент сделать.
Если оставить знакоместа как есть (8х8), только атрибуты сделать по 2 байта (64К на INK и 64K на PAPER), размер изображения станет равен 0х2400 (9216) байтам. Совсем не много. Зато картинки остаются вполне смотрабельными.
(Но это так - зарядка для мозгов.):v2_dizzy_wall:
Слева направо: RGB888, RGB565_4x4, RGB565_8x8:
59883
59884
С первого взгляда концепция нового изображения годится разве что для full screen video (через какой-нибудь datagear), потому что attribute clash критически сказывается на графике которая двигается попиксельно. Впрочем, у ZX если графика занимает четко несколько знакомест и шаг движения только по знакоместам то никакого attribute clash нету, значит тут можно будет двигать предметы с шагом 4pix ну и размер теперь можно делать кратный четвертям знакоместа. Другое дело что размер атрибутов вырос в 8 раз?, в принципе можно это компенсировать через турбо процессора. Т.е. вроди как идея имеет смысл. Надо обкатать в эмуляторах чтобы прикинуть какая частота процессора будет нужна.
Lethargeek
27.02.2017, 10:02
С первого взгляда концепция нового изображения годится разве что для full screen video (через какой-нибудь datagear), потому что attribute clash критически сказывается на графике которая двигается попиксельно. Впрочем, у ZX если графика занимает четко несколько знакомест и шаг движения только по знакоместам то никакого attribute clash нету, значит тут можно будет двигать предметы с шагом 4pix ну и размер теперь можно делать кратный четвертям знакоместа. Другое дело что размер атрибутов вырос в 8 раз?, в принципе можно это компенсировать через турбо процессора. Т.е. вроди как идея имеет смысл. Надо обкатать в эмуляторах чтобы прикинуть какая частота процессора будет нужна.
Какой смысл - "как бездарнее потратить ресурсы плис"? Уже есть режимы с цветом на точку, где графика ворочается процессором в общей памяти - вообще без атрибутных ограничений, двигать можно с шагом 1-2pix, но софта под них - alone coder наплакал. В то время как на исторический Спектрум игорей клепают десятки в год, всё под тот же самый старый экран, всё под те же самые 3.5мгц. Потому что лень кодить под несовместимый режим, потому что у классики на порядок больше аудитория, потому что выходить за рамки классики неспортивно... Из всех новшеств только юла+ довольно регулярно поддерживается, ибо просто и наличие некритично. При несоблюдении этих принципов любой монстр неизбежно будет мертворождённым (в лучшем случае - кумиром немноголюдной секты с автором-первосвященником во главе).
Какой смысл - "как бездарнее потратить ресурсы плис"?
Про ПЛИС забудь, интерес падает и уже почти 0, так же как и эмуль. Про 16c и ATM ega тоже можно забывать, так как даже такой крутой alone не смог ниче туда портировать (не хватает скорости? не удобно? х.з.). Eсли запилить шото по моще типа как у MSX2+, и в таком же виде как divide, то как раз оно пойдет пачкой так же как и сам divide (даже если плата будет размером с 2 harlequin-a).
Lethargeek
27.02.2017, 22:09
Про ПЛИС забудь, интерес падает и уже почти 0, так же как и эмуль.
ну, автор пишет же в заглавном посте про плис
Про 16c и ATM ega тоже можно забывать, так как даже такой крутой alone не смог ниче туда портировать (не хватает скорости? не удобно? х.з.).
А также времени, ведь кроме собственно кодирования заново даже тайминги надо распланировать по-другому. Ящетаю, что взлететь способно сейчас лишь то, что позволит без больших усилий улучшить графику даже старых игр, доступных только в виде бинарника, с минимальным изменением оного (в идеале - вовсе без изменений). Что значит - автоматически и для новых (каковые пишут всё равно под старый стандартный Спек).
То есть нужен некий "внешний" девайс, у себя внутри рисующий улучшенную картинку "по мотивам" нарисованного на Спеке. Причём даже не подробно проработанная железка, а минимальный общий стандарт на простые пиксельные операции в духе Спека и "подсказки" или "теневые команды", выполняемые параллельно с кодом на Спеке, и на механизм предварительной загрузки данных в девайс. Само железо может быть и разным теоретически, с разными нативными наворотами, разными физическими режимами и способами доступа к ним. Лишь бы только успевало за Спеком пиксели в своём формате модифицировать, и чтобы узнавался оригинал.
Smalovsky
27.02.2017, 22:44
Lethargeek, ну вперёд. Никто тебе мешать не будет. Ты начинал про парабайты и парабиты. Может, есть смысл это развить на базе внешнего арма?
- - - Добавлено - - -
Хорошо бы 4х4 256 обкатать в эмуляторе.
Ynicky, тут мне написали, что нужно потестить изображение на картинках где много мелких разоцветных деталей. Сомневаются в видеорежиме...
Ynicky, тут мне написали, что нужно потестить изображение на картинках где много мелких разоцветных деталей. Сомневаются в видеорежиме...
Давайте пример, сделаю.
Smalovsky
27.02.2017, 23:33
vlad, может, у тебя есть идея нового видеорежима?
Уже вступил в клан тэсэлыча?
- - - Добавлено - - -
Я помню таких залётных зст отправлял сразу на тсу. )) И как результат много людей заинтересовалось Метеором.
Smalovsky
27.02.2017, 23:50
Ynicky, найди 256 цветное изображение с мелкими деталями и обработай. Нужно посмотреть на сколько изменится клэшинг( в смысле какое преемущество 4х4 над обычным экраном).
Можешь перевести в 256 цветов изображение которое ты привёл, а потом обработать конвертером.
Lethargeek
28.02.2017, 00:00
Lethargeek, ну вперёд. Никто тебе мешать не будет. Ты начинал про парабайты и парабиты. Может, есть смысл это развить на базе внешнего арма?
Смысла нету, то был просто пример, сильно устаревший за много лет. И я ж не железячник, куда "вперёд"? У меня сейчас больше культурологический интерес к феномену спектрумонстростроения, когда вроде бы неглупые люди (раз уж в электронике понимают) раз за разом наступают на те же грабли. Интересно, что творится у них в мозгах.
Smalovsky
28.02.2017, 00:34
Есть идея. ))
Для планшета написать приложение. В этом приложении есть универсальный движок, который выводит высококачественные предворительно загруженные в него изображения на экран. Так вот спектрум соединяется с планшетом через какой нибудь интерфейс с протоколом.
В спекрумовской игре в точках программы, где есть вывод изображения сам код вывода игнорируется полностью как и спектрумовская графика, а вместо него вставляются команды протокола вывода изображения планшетом в определённую позицию.
Получается от начальной игры нужна только логика, а хранение и вывод изображений производит планшет. Команды протокола должны быть простыми, например, нарисовать изображение номер такое-то в позиции такой-то. Для этого можно задействовать несколько портов.
Короче, сами высококачественные изображения в высоком разрешении можно хранить в специальном пакете с настройками. Пакет создаётся для отдельной игры. Для движка на планшете есть возможность открывать разные пакеты к разным играм. Пакеты хранятся на планшете не нужно ими забивать память спектрума.
Надеюсь, вы меня поняли( особенно тэсэлыч).
Lethargeek
28.02.2017, 03:31
В спекрумовской игре в точках программы, где есть вывод изображения сам код вывода игнорируется полностью как и спектрумовская графика, а вместо него вставляются команды протокола вывода изображения планшетом в определённую позицию.
Это против принципа простоты - как можно меньше обязательной работы при адаптации (что не исключает необязательной). В старый код на Спеке лучше не лезть, его нужно только синхронизировать с кодом, выполняемым на планшете (россыпь спецкоманд по ключевым точкам, где на Спеке пишутся или читаются пиксели).
Так вот спектрум соединяется с планшетом через какой нибудь интерфейс с протоколом.
Собственно, хватит самого простого устройства, тупо ретранслирующего планшету состояние спектрумовской шины на каждом такте. Что на ней данные, а что команды - софт разберётся.
Получается от начальной игры нужна только логика, а хранение и вывод изображений производит планшет.
И здесь тоже не нужно обязательных лишних действий. Не у всех есть время и желание рисовать. Графику можно и у Спектрума "подсмотреть" (что не запрещает частичной или полной её замены).
Команды протокола должны быть простыми, например, нарисовать изображение номер такое-то в позиции такой-то. Для этого можно задействовать несколько портов.
На самом деле это не упрощение; по крайней мере, не для адаптации старых игр. Операции в стандартной спековской графике производятся над группой из 8 пикселей, то же самое обязательно должно уметь и устройство. Остальное - в качестве приятного дополнения.
Для этого можно задействовать несколько портов.
Хватит одного настоящего, чтобы в памяти задавать окно для отображаемых XX00-XXFF
Короче, сами высококачественные изображения в высоком разрешении можно хранить в специальном пакете с настройками. Пакет создаётся для отдельной игры. Для движка на планшете есть возможность открывать разные пакеты к разным играм. Пакеты хранятся на планшете не нужно ими забивать память спектрума.
Всё же загружать пакет со Спектрума уметь нужно, тем более что графики в нём может не оказаться, только теневой код.
- - - Добавлено - - -
Я бы начал с простого видео режима 256 цветов, 256х192 8 бит на точку, 2 видео буфера по 48К и парочкой палитр. Этого вполне хватит для начала, чтобы понять, нужно ли ещё что-то для Спектрума или нет. Сделать это уже можно на DivGMX.
Может лучше начинать не с "простого" в смысле слабых характеристик, а с удобного для кодера-спектрумиста?
Ynicky, найди 256 цветное изображение с мелкими деталями и обработай. Нужно посмотреть на сколько изменится клэшинг( в смысле какое преемущество 4х4 над обычным экраном).
Не совсем понял что нужно.
Привожу пример обработки спрайта.
Вверху оригинал, внизу после обработки.
59893
P.S.
Моя программа просто переводит картинки в новый формат.
Например для заставки.
Чтобы прочувствовать клэшинг, нужно сделать демострашку.
Собственно я это и хочу сделать, но я никогда раньше не программировал
на ассемблере для спектрума. Нужно сначала много изучить.
P.P.S.
А клэшинг проявляется там где в блоке есть 3 или более цветов.
Про ПЛИС забудь, интерес падает и уже почти 0, так же как и эмуль.
сидит, значит такой, чувак, за Пентагоном-128+бетадиск+трдос 5.04+ау+2 флоппика 5.25.
дискеты за последние 20 лет просто исчезли как вид со всех прилавков магазинов. у чувака всего то осталось пара десятков дискет. а поскольку чувак ярый противник всего нового (винт, гс, мыша, сд-карты, новая графика и всё остальное т.к. всё это на плисах нынче да и просто чувак против всего нового, ведь спектурм+винт = не спектрум, типа), то вынужден гонять переодически на одни и те же диски свои архивы со своего пц. раз за разом мятерясь. что какой-то образ не может нормально развернуться т.к. на пц тупые утилиты, да ещё и под дос.
да и сам пентагон весьма древний, 90х годов постройки. перепаянный на 1024 раза. всё жутко тупит, глючит. комп страшно не то, чтобы двигать, даже дышать на него (ибо любая вибрация и изменение положение ведёт к зависанию и матрацу).
А по соседству есть чувак, у которого спековское железо чуть более современное. это то же спек, только "новодел". и винт у него есть и гска и мыша и клава удобная от пц и глаза он об старый элт телевизор не ломает и все образы у него прям со спека стартуют (за редким исключением есть некоторые диски требующие развернуться на дискету, но для этого у этого чувака есть десяточек запасных дискет для таких манипуляций). и всё у него работает и ничего не глючит.
говоря про плисы, вы наверно имеете в виду, что лучше быть чуваком номер 1?)))
я тот самый чувак номер 2. всё работает. ничего не глючит. стоит проц z80, есть ВГ93. всё железное. никаких эмуляторов. почему это плохо и почему вы своими высказываниями толкаете людей на "соплестроение" с результатом как у пациента номер 1?
Ynicky, все конвертированные картинки в формат "с атрибутами" просто пиксельные каши. смотреть страшно. забудьте про атрибуты. для расширения палитры есть ULA+. хотите больше - мутите цвет на точку или спользуйте уже ранее созданные режимы. Алоний весьма много сделал дем и игр для АТМовского режима. посетите его сайт или сайт АТМ. Если что, есть даже рабочий вариант рейкастинга под АТМ3 (бейс конфа для эвы) весьма шустрый (хоть и метод вывода жутко извратный).
другое дело, что нынче народ тут сидящий это не активные пользователи/кодеры/железячники, а скорее коллекционеры. важным элементом является собрать себе в коллекцию какую то железку или клона, запустить пару разу и потом кинуть на полку пылиться. потом процесс начинается с начала. даже если будет создана какая-то новая ультракрутая железка со всеми там режимами совместимости. её соберут, проверят и кинут на полку. потом опять начнут стонать - дайте мне крутую железку.
Smalovsky
28.02.2017, 13:43
Ynicky, ну, мне кажется не совсем корректно переводит у тебя конвертер цвет. У вертолёта внизу появился серый цвет с зеленоватым оттенком, хотя можно было залить такие участки серым.
И ты переводил раньше с ргб888 в 256 цветов. Это некорректно, так как только при упрощении цвета будет теряться качество. Поэтому ты должен переводить 256 цветов на каждый пиксель в 256 цветов 4х4. Попробуй конвертировать скрины с досовких игр с 256 цветами или с амиги.
Операции в стандартной спековской графике производятся над группой из 8 пикселей, то же самое обязательно должно уметь и устройство.
Устройство не обязано это делать. Обычно за вывод спрайтов отвечают процедуры на асме , типа, PUT и пр.. Так вот, достаточно заменить всю процедуру командой протокола и не лезть в копирование байтов на спектруме.
Было время, когда я мечтал о новом видео режиме с цветом на точку для Спектрума, выкладывал здесь даже фото видео контроллера на дискретках (https://github.com/mvvproject/Library-Modules/blob/master/fdc_hdc/va1_2.txt). Помню тот день, когда на экране монитора появилась первая 16 цветная картинка 512х256 с цветом на точку
чтото никак не могу "открыть" по нормальному эту схему, она там немного покареженная? или я чтото не то делаю? кодировка DOS и все? или еще чтото надо?
Lethargeek
28.02.2017, 17:44
Устройство не обязано это делать. Обычно за вывод спрайтов отвечают процедуры на асме , типа, PUT и пр.
Обязано. Графика - не только вывод готовых спрайтов, но и вычисляемые рисунки.
Так вот, достаточно заменить всю процедуру командой протокола и не лезть в копирование байтов на спектруме.
Досконально разбираться с логикой процедур - лишняя необязательная работа.
Начинать которую всё равно с поиска команд записи отдельных байт в экранную область.
- - - Добавлено - - -
также у планшетных приложений возможны лаги с разрывами потока информации от компа, что изрядно понижает ценность идеи
omercury
28.02.2017, 21:58
она там немного покареженная?
Юникод.
Обычным виндовым блокнотом.
упс, файл великоват...
https://yadi.sk/i/xgScdYdY3Eowzt
Lethargeek
09.03.2017, 14:50
только вспомнил, а ведь атрибуты 4x4 (и даже 4x2) ведь уже в железе реализованы, хоть и с ограниченной цветностью:
http://www.fruitcake.plus.com/Sinclair/Spectrum/Spectra/SpectraInterface.htm
надо ли говорить, что софта для него чуть более чем нисколько...
Конвертанул их конвертером.
С наилучшим результатом вот что получилось:
60028
60029
Размер изображения при этом ровно 16К байт.
только вспомнил, а ведь атрибуты 4x4 (и даже 4x2) ведь уже в железе реализованы, хоть и с ограниченной цветностью:
http://www.fruitcake.plus.com/Sinclair/Spectrum/Spectra/SpectraInterface.htm
надо ли говорить, что софта для него чуть более чем нисколько...
Хорошо, есть стандартный экран с атрибутами, есть 16к вместо ROM, как это использовать? в моей поделке можно отключить, 32K,24К,16К как в нижней так и верхней памяти, можно читать например из CPU0 и писать по этим адресам, но уже в VRАМ, но в стандартном ZX так не сделать.
Smalovsky
10.03.2017, 20:29
надо ли говорить, что софта для него чуть более чем нисколько...
Две игры и несколько утилиток. Есть даже игровой редактор.
Софт (http://www.fruitcake.plus.com/Sinclair/Spectrum/Spectra/SpectraInterface_Software.htm)
Редактор (http://www.fruitcake.plus.com/Sinclair/Spectrum/Spectra/SpectraInterface_Software_GameDesigner.htm)
Редактор, скорее всего, на основе AGD или совместимый. Интересно дальнейшее развитие карты.
- - - Добавлено - - -
Ynicky, я не понял... Ты уменьшил количество цветов?
Ynicky, я не понял... Ты уменьшил количество цветов?
Нет, это в SPECTRA их меньше (64).
Ynicky,
Smalovsky,
Цена решения не адекватна, подходит к "фирмовым" машинам, у кого есть "спектра?"
Smalovsky
11.03.2017, 22:10
Есть идея, что бы Ynicky поделился разработкой с vlad. Если есть у vlad есть желание, то он мог бы перенести новый видеорежим в DivGMX.
Есть идея, что бы Ynicky поделился разработкой с vlad
Нет проблем. Только в моей разработке нет ничего нового кроме VGA контроллера, работающего с двухпортовой внутренней памятью.
60860
60075
- - - Добавлено - - -
А это управление режимами видеоконтроллера и ПЗУ:
oMode <= not sport_7ffd(4);
oRomEn <= not sport_7ffd(4); --- (x7ffd/D4 = '0')
oBasicEn <= sport_7ffd(4); --- (x7ffd/D4 = '1')
Сделал небольшую демонстрацию - движение шарика по блокам. Специально, чтобы хорошо был виден конфликт атрибутов.
https://youtu.be/BxeSyjHRxLA
60346
60347
60348
Добавил в видеоконтроллер дополнительный отключаемый слой для спрайтов.
Цвет одной точки растра в нем кодируется 2-мя разрядами. Адресация линейная во всем экране.
Четыре атрибута (четыре цвета) задаются на знакоместо 8х8 в формате RGB332.
Если какая-либо точка знакоместа задается атрибутом (цветом) = 0, то она прозрачная.
Т.е. если спрайт не целиком покрывает знакоместа, то он может состоять из 3-х цветов,
плюс прозрачный. В таком случае отпадает необходимость в маске. Тайлы могут состоять
из 4-х цветов. Размер растра слоя равен 0х3000, атрибутов - 0хС00.
В итоге дополнительный слой занимает чуть меньше 16К байт. Фон (назначаем его нулевым слоем)
может быть как у стандартного экрана ZX спектрума, так и в новом формате
(4 блока на знакоместо по 2 атрибута RGB332 на блок). Конфликт атрибутов с двумя слоями
полностью исчезает. Доработал видеоконтроллер для работы с двумя слоями.
Со стороны видеоконтроллера 0-й слой начинается с адреса 0х4000, а 1-й - с 0х0000.
Видеоконтроллер работает с 2-мя двухпортовыми блоками внутренней памяти по 16К байт на слой.
Для простоты пока не стал подключать еще 2 страницы видеопамяти для работы с переключаемыми
кадрами.
Исходник нового видеоконтроллера прилагаю:
60864
https://youtu.be/T-Md-8mrFO4
Раскрасил первый экран и спрайт главного героя игры Exolon в цвета, для того чтобы
представить как бы выглядела игра с новыми видеорежимами.
Из меня художник и программист еще тот, но потенциальные возможности можно увидеть.
https://youtu.be/0SmRfFoaE2c
60704
60705
Lethargeek
19.04.2017, 23:53
exolon - явно неудачный пример, там и в оригинале графика от клэшинга не страдает, ну да ладно, главный вопрос в другом:
чем всё это в принципе отличается от б-гомерзких тайлоспрайтов тс-конфы, и зачем еще один подобный режим?
и зачем еще один подобный режим?
Не наигрался в молодости - интересно!
Lethargeek
20.04.2017, 07:30
Не наигрался в молодости
не наигрался в проектирование режимов, штоле? :D
- интересно!
интерес-то в чём? очередной заведомо бесперспективный и несовместимый с прошлыми аналогами режим под силу каждому второму радиотехнику, этим спектрумистов не удивишь
"Оконтурил" спрайт. На светлом фоне стал лучше виден.
60719
NEO SPECTRUMAN
21.04.2017, 00:15
интерес-то в чём? очередной заведомо бесперспективный и несовместимый с прошлыми аналогами режим
КАЖДОМУ СПЕКТРУМИСТУ ПО ВИДЕО РЕЖИМУ!!!
КАЖДОМУ СПЕКТРУМИСТУ ПО ВИДЕО РЕЖИМУ!!!
Каждому пикселю, по видео режиму, каждому режиму по со спектрумисту, каждому пограмисту по спектруму!
Lethargeek
21.04.2017, 09:53
КАЖДОМУ СПЕКТРУМИСТУ ПО ВИДЕО РЕЖИМУ!!!
Каждому пикселю, по видео режиму, каждому режиму по со спектрумисту, каждому пограмисту по спектруму!
такЪ победимЪ!
NEO SPECTRUMAN
21.04.2017, 16:24
Каждому пикселю, по видео режиму, каждому режиму по со спектрумисту, каждому пограмисту по спектруму!
за свою жизнь спектрумист должен
похоливарить на тему что лучше звучит AY, YM или бипер
похоливарить на тему АТМ это не спектрум
похоливарить в теме про концепцию своей новой видео карты
за свою жизнь спектрумист должен
похоливарить на тему что лучше звучит AY, YM или бипер
похоливарить на тему АТМ это не спектрум
похоливарить в теме про концепцию своей новой видео карты
так точно!
так, где там AY vs YM?
Автору топика огромное спасибо за проделанную работу!
Если он нуждается в какой то железяке и пусть напишет в ЛС.
или просто получит не большой, но приятный подарок, который сможет использовать в своих проектах.
:v2_dizzy_yes:
В видеоконтроллер добавил еще один слой.
Модифицировал проект MVV 128-го спектрума с esxdos для платы Марсоход3.
Нашел у себя исходник демонстрации разрабатываемой игры танк от Dr.bars.
Наверно, где-нибудь в интернете. Изменил под новые режимы.
В левом верхнем углу экрана вывожу первый слой с 4-х цветными тайлами.
Нулевой оставил стандартный ZX. А во второй слой вывожу спрайт 3-х цветного танка.
Пока не сделал плавное движение танка, но увидеть работу можно и так.
Исходник нового видеоконтроллера:
60968
Totem:Если он нуждается в какой то железяке и пусть напишет в ЛС.
или просто получит не большой, но приятный подарок, который сможет использовать в своих проектах.
Давно хочу ReVerSE-U16. Если бы кто продал собранную плату.
Видео:
https://youtu.be/bOczsp-yVp8
Ynicky, может интересно?
Интересно, слежу с самого начала.
Собранных сейчас нет, могу собрать, но нужны микросхемы...
А в Москву отправить сможете?
Ynicky, Могу поделиться EPM3256-144, не "шик модерн", но спек влезет без проблем.
Ynicky, Могу поделиться EPM3256-144, не "шик модерн", но спек влезет без проблем.
К сожалению сам собрать плату не смогу, да и хотелось бы проверить все проекты на ReVerSE. И поучаствовать в разработке новых конфигураций.
К сожалению сам собрать плату не смогу, да и хотелось бы проверить все проекты на ReVerSE. И поучаствовать в разработке новых конфигураций.
http://zx-pk.com/forum/viewtopic.php?f=7&t=6976&p=73059&hilit=Reverse#p73059
Немного доработал демо.
https://youtu.be/JuuDSIm-fEg
Выкладываю проекты на Visual Studio преобразований BMP24 в формат SCN (2 бита на пиксель / 4 атрибута на знакоместо) и обратно, а также преобразование спрайтов в ASM, проект демо танк и HDL проект для платы Марсоход3.
Может кому-то пригодится.
61055
61056
61057
61058
https://cloud.mail.ru/public/AbWQ/aKYZdSvLf
Дабы не плодить темы, напишу здесь.
Поразбирался немного со Spec256.
Так как не нашел описания на форматы изображения и фона, сделал программу конвертирующую файлы фона <>.BXX в BMP24. Все фоны 12-ти игр оказались размером 320х200 (старый ДОСовский формат с палитрой в 256 цветов).
Программу прилагаю:
61252
Получается, чтобы сделать аппаратный эмулятор Spec256, нужен нижний слой для фона, чтобы экран спектрума накладывался на него.
А вот некоторые картинки фонов игр:
61249
До кучи сделал обратное преобразование фона Spec256 из BMP24 в BXX.
С той палитрой, что у Владимира Кладова в эмуляторе EmuZWin не так уж и плохо получаются картинки после преобразования. Так что можно делать (менять) фоны к играм.
61253
Вот пример. Сверху оригинал, снизу после преобразования в BXX и обратно в BMP24.
61254
Чтобы не пропали даром мысли по поводу еще одного формата - выкладываю здесь.
61818
NEO SPECTRUMAN
27.07.2017, 22:12
программу конвертирующую файлы фона
фотошоп?
фотошоп?
Вопроса не понял. К сожалению фотошопа у меня нет и что он может не знаю.
Просто конвертировал оригинальные файлы своей программой.
Поэкспериментировав с различными форматами графических изображений, а также количеством слоев
остановился на следующем:
Нижний слой (Layer 0) имеет формат 4 цвета (RGB332) на знакоместо 8x8 (2 бита на пиксель,
4 байта на атрибуты знакоместа). У меня он используется, как правило, для фона.
Следующий слой (Layer 1) - стандартный экран ZX spectrum-а. Его я использую, как правило,
в качестве вывода текстовой информации. Черный цвет в этом слое сделал прозрачным,
чтобы проглядывал фон (Layer 0). Верхний слой (Layer 2) также имеет формат 4 цвета
на знакоместо как и нижний. Его я использую для вывода спрайтов. Они имеют 3 цвета
на знакоместо + прозрачный (черный). Для рисования черного цвета в спрайтах я использую
код %00100100 (RGB332), т.е. темно-коричневый. В качестве прозрачного цвета можно использовать
любой другой (например сиреневый), только это надо будет учесть в видеоконтроллере. Количество
верхних слоев можно увеличивать насколько хватит аппаратных возможностей. Сейчас слои 0 и 2
занимают по #3C00 (15360 байтов). Их я расположил в банках 13 и 15 соответственно. Включением
и выключением слоев пока управляют биты 5 и 6 регистра #1FFD. Для переключения банков
используются биты 7,6,2-0 регистра #7FFD.
Новые программы запускаю как и стандартные с microSD карточки под DiVMMC. Для написания программ
использую sjasm под оболочкой RadASM. В качестве аппаратуры использую плату Марсоход3 с шилдом
разъемов PS/2 и подпаянным на проводах переходником SD в microSD. Свой проект сделал на основе
проектов MVV.
Для демонстрации новых возможностей решил написать свою игру HeliCop (Полицейский Вертолет)
со следующим сюжетом:
Летящий полицейский вертолет борется с гангстерами, едущими на машинах по дороге (первый уровень).
По той же дороге могут двигаться и обычные машины. Задача - уничтожить гангстеров, при этом
не расстреливать мирные машины. Гангстеры также могут стрелять по вертолету. Количество
выстрелов у вертолета ограничено для каждой миссии (уровня). При уничтожении гангстеров очки
прибавляются, а при случайном уничтожении мирных машин - вычитаются. Вычитаются они и при
попадании гангстеров по вертолету. Пока игра имеет начальные зачатки, которые можно посмотреть
на следующем видео:
https://youtu.be/IWhifDmZHqc
Пока нет вспышек выстрелов и подсчета очков, нет других уровней, меню и заставки игры.
Если есть желающие поучаствовать в развитии этой игры - добро пожаловать. Один я буду ее делать
долго. Не хватает программистских знаний. И художник из меня не очень.
Проект игры прикреплен:
62122
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot