еще раз, ну на кой ляд Вам эти слои ? зачем Вы пытаетесь прикрутить к платформе заведомо дорогую, не оправданно сложную в понимании , для кодеров железяку?
Вид для печати
Что же пишешь да все не в тему, только ими и пользуюсь, полно, - вот 1000шт тебе хватит ? - https://www.olx.ua/obyavlenie/prodam...tml#823535c782
Какие SD куда, речь карте для удобной переделки старых игр.
Усе говорю только с ZST по существу, загадили тему творцу :v2_sick:
Если делать на армах, то существует модуль stm32f429 discovery, у нас он правда стоит несколько подороже 3000, но 8Мб памяти, дисплей 320x240x18 bit и микроконтроллер 180МГц на плате имеются. К сожалению свободных ног там остаётся мало, поэтому подключить к ZX-bus можно только через буферные регистры с мультиплексором(для чтения по частям) или последовательной выдачей(SPI может работать со скоростью до 45Мбит). Второй вариант возможно сделать так, что данные будут попадать в память микроконтроллера чисто аппаратно(таймеры с управлением буферными регистрами и SPI вполне справятся), не отвлекая от рисования картинки. У микроконтроллера имеется DMA2D, который может заполнять буфер каким-то фиксированным цветом, копировать из другого буфера или комбинировать данные из двух буферов с учётом прозрачности. Выходной буфер у него всегда формата (A)RGB по 2,3,4 байта на точку, а у входных дополнительно есть еще форматы когда в буфере только яркость, альфа или яркость+альфа по 1 или 2 байта на точку(4 или 8 бит на яркость/альфа). Перед наложением яркость может преобразовываться в (A)RGB через палитру на 16 или 256 цветов. То есть со спрайтами это агрегат справится ничуть не хуже плис, поскольку всё упирается в пропускную способность памяти. Подключение к дисплею на плате сделано через нормальные RGB сигналы, HSync и VSync тоже в наличии, и когда станет ясно что оно работает, можно отключить дисплей и вывести всё на монитор.
Но, еще раз повторюсь, более перспективный вариант это сделать для начала программный эмулятор, чтобы все желающие смогли поработать с метеором и высказать свои замечания/пожелания.
Шутка повторенная 3 раза в 3 раза смешней?
А какой у пентагона стандарт? 7FFD ? а раскадровка вообще не в тему, у видеокарты своя раскадровка.
А 7FFD как бе загажен не только памятью, а какой ещё у него стандарт?
А по сути AY и ВГ не производятся, их надо уже в ПЛИС прятать.
Чем не устраивает SD против НГМД ? Программа всё равно не видит с чего она читается. А юзать обсыпавшиеся НГМД с которых вдруг внезапно обвалятся все исходники что-то не хочется, какой год выпуска самой МОЛОДОЙ дискеты? а сколько срок годности магнитного напыления?
Зачем пихать несколько разных чипов памяти маленького объёма если ОДИН ЧИП бОльшего объёма и быстрее и дешевле, лишних 3 ноги адреса некуда завести?
Зачем вообще 2 микросхемы для видео? всё равно надо сначала считать пиксель и обработать его (поллитру проверить или прозрачность) а потом уже или выводить его или не выводить, за 1 такт переносом из одной микры в другую ничего не получится, придётся общую частоту уменьшать что бы в задержку проверки уложиться.
1000 дискет по 640 кб сколько стоят? через сколько они посыпятся? 1000*0,64 = 640 мБ, такая флешка стоит 50 рублей и при топорной эмуляции через 50-рублёвый микроконтроллер даёт 1 мбайт/сек скорости.
zst
Концепт далее -
Аппаратный спрайт по адресу в памяти экрана и по X,Y экрана
Аппаратная точка
Аппаратная линия
Разные варианты CLS
Заполнение экрана выбранным цветом
--------------
Если пойти дальше -
И сделать аппаратный Fill в выбранной области, треугольнике,круге и т.д.
Вообще стоит хорошо подумать о возможности добавления новых команд, остаются на это ресурсы ?, это даст хороший задел на будущее (при написании управляющей программы для карты, что бы из за одной команды весь код не перелапачивать)
джваюштак :v2_dizzy_facepalm: карту надо делать для СОФТА, а не для железа!
если нет понимания, что не надо характеристики девайса подгонять под завалявшиеся детальки
ну каких тебе примеров-то и зачем? как работали группами по восемь пикселей на Спеке, так и на девайсе будем работать
вот при чём тут восьмиБИТНОСТЬ аккумулятора, когда смысл его при работе с графикой - восьмиПИКСЕЛЬНОСТЬ!
в карте свой "аккумулятор" на восемь ПИКСЕЛЕЙ (неважно какой разрядности), адреса и маски берём со Спека
а тебе зачем восьмибитность пикселей-то? пикселю в аккумулятор зачем влезать? у тебя мячта спрайтики попиксельно рисовать? :D
Нет, карту мы делаем с учетом имеющихся исходных ресурсов ZX и его архитектуры - дисковод, телевизор.
Все что иначе, это не ZX-Spectrum, а другая машина, вам нужна full hd, 4k ? - разрабатывайте, мне такое не надо, автору по моему тоже. Если автору мои идеи нафиг не нужны, я естественно и продолжать настаивать не буду в отличии... Разобравшись в с помощью автора в принципе работы, я прежде чем начать писать так и спросил, а не закидываю из страницы в страницу автора дерьмом... -
Есть точка по адресу #0000 с цветом #00 надо поменять на #ff
-----------------------
ld de,#0000
ld hl,pix
ld a,(hl)
ld (de),a
ret
pix defb #ff
---------------------
И так
--------------------
ld a,#ff
ld hl,#0000
ld (hl),a
ret
----------------------
ld b,#ff
ld hl #0000
pix ld a,b
ld (hl),a
djnz pix
ret
----------------------------
Напишите эти три варианта для 16 битного цвета только на асме, а не языком по тексту.
Давай пока остановимся на аппаратной точке, не все сразу.
Давайте немного изменим распределение памяти. На каждую точку по 8 бит. В слое будет 2 буфера/экрана по 256х256х1=64Кбайт. То есть один слой 128К. Всю память разделим условно на 8 слоев по 128К. Для каждого слоя своя палитра. Программист сам выбирает, сколько слоев надо для игры. Неспользуемые слои использовать для хранения спрайтов.Цитата:
Аппаратная линия
Разные варианты CLS
Заполнение экрана выбранным цветом
--------------
Если пойти дальше -
И сделать аппаратный Fill в выбранной области, треугольнике,круге и т.д.
Вообще стоит хорошо подумать о возможности добавления новых команд, остаются на это ресурсы ?, это даст хороший задел на будущее (при написании управляющей программы для карты, что бы из за одной команды весь код не перелапачивать)
Посчитаем, сколько условных спрайтов размером 8х8 точек влезет в память размером 128К. 128К / 64 = 2К. Для сравнения у Денди 256 спрайтов и 256 тайлов, то есть 512. А у нас в 4 раза больше. Хватит на 4 уровня с разными спрайтами. Но у нас даже круче - мы сможем использовать сразу все. Всего 8 банков по 256 символов.Т.е. 1 банк - буквы, 2 банк - тайлы фона, 3 банк - спрайты ГГ и т.д.
Если спрайты большего размера - то использовать под спрайты больше памяти вместо слоев. Для разных игр комбинация количество слоев - объем под спрайты будет разное.
Для 8-ми битной графики надо несколько палитр. Для каждого слоя будем выбирать свою. Хранить в формате 256 байтов для R, 256 байтов для G, 256 байтов для B в трех блоках внутренней памяти FPGA.
Столько цветов надо только для просмотра полноцветных картинок, и то, в таком случае никакая палитра не нужна, а смотреть HiColor в разрешении 256х192 это более чем смешно, в таком разрешении на экран влезет максимум 49152 цветов, всё что свыше будет незаметно для глаза из-за низкого разрешения, поэтому максимум что надо для динамической графики это 32768 цветов 5-5-5 и 1 бит прозрачность+техническая палитра.
Цвета в 24 бита при таком разрешении абсолютно бесполезны, тогда надо поднимать хотя бы до 800x600 и то это будет чисто статическая картинка.
Прямой вывод пикселя нужен только для барсика или накидать малость звёзд ну и всякие рамочки статические, эта малоёмкая процедура сжирает процессорного времени на 2 порядка больше чем требуется для самого вывода, имхо, только немного и не динамично.
Зачем такое ограничение по ёмкости памяти для спрайтов? память же линейна, счётчики сделать 24 бита [16 Мб максимум адресуемой] (32 бита для такой системы уж слишком жирно).
Указатель на параметры спрайта в памяти видео, по сути это и не спрайты а картинки, размер получается любой, вплоть до того что полноразмерная картинка (аля задний фон windows) выводится за пару команд, в памяти CPU при этом нет ничего связанного с графикой, если и всю музыку и звуки хранить в памяти АудиоCPU то 64 Кб для кода более чем за глаза, да и к примеру сделать 4 банка по 16 Кб CPU раздельно устанавливать в линейной памяти, тогда можно фигачить кода в принципе безгранично много (в прочем ничего нового в 128 Кб иначе и не сделаешь :) ).
Аппаратную линию сделать тоже не очень сложно, для рисования требуется задать 4 переменные: X, Y, dX и dY, далее видеокарта вычисляет len=max(abs(dX),abs(dY)), делит dX и dY на len, и записывает точки добавляя dX и dY к X и Y. Если добавить еще один блок вычисляющий координаты точки для чтения, то у нас будет почти готовый блок текстурирования, способный рисовать даже с поворотом.
[add]
Можно обойтись даже без деления, найти минимальное 2^n>=len и просто сдвинуть dX и dY на n, чтобы перемещаться с шагом не более 1 точки. А для рисования четырёхугольника по точкам A,B,C и D, нужно начинать двигаться из точки P=A с шагом S=(B-A)/2^n, для перехода к следующей линии увеличивать P на (C-A)/2^n, и корректировать шаг S прибавляя ((D-C)/2^n-(B-A)/2^n)/2^m. Для 8 разрядных координат достаточно будет 24х битной арифметики.
Только всё это надо подгонять для нормального управления ИЗ Z80, то есть и систему надо подгонять :)
Nesser, а что две скобки )) вместо диззи лень поставить?
какой смысл? и что за странноватый "учёт" такой? дисковода на "исходном" спектруме не было, а "исходный" телевизор - вообще аналоговый (точность цвета ограничена только шумом)
мне достаточно и подмножества возможностей "исходного телевизора", то есть 360x288 (x256) "квадратных" пикселей в хайколоре :p
при такой постановке вопроса лучшим "16-битным" ответом будет:
ld hl,цвет
ld (0),hl
:D
не вижу смысла для представленных "вариантов" бесполезно-сферовакуумного кода
где контекст? запись пикселя - это часть какой-то многопиксельной операции
(при которых числовое выражение цвета вообще не важно чаще всего)
Из таких ответов и состоит вся эта тема, - хочу так, или не вижу смысла :) на одного делающего 1000 помошников :D - https://vk.com/video125972_164806403
Вопрос к ZST как на данный момент вам видится 16 битная организация цвета в памяти карты ?
Имеется в виду прямая адресация в область экрана, через окно.
лично я хочу решений таких, от которых больше реальной пользы
так, 16 бит на пиксель позволяет, кроме прочего, задавать несколько 256-цветных палитр
и потом временно работать в рамках одной палитры, изменяя только младшие биты индекса
то есть полностью имитировать "восьмибитную организацию цвета", если приспичит
а вот 8 бит не позволит имитировать "16-битную организацию цвета", хоть расшибись
это всё, что нужно знать по поводу выбора разрядности пикселя :v2_smoke:
http://davidnaylor.org/temp/all16777216rgb-diagonal.png
256 квадратов по 65536 оттенков
16 миллионов цветов.....зачем столько? :) их всё равно отличить невозможно, максимум что надо это 32768, по 5 бит на цвет, а уже в 8 битах брать из них какие надо, по сути цветов то надо всего 30-40, остальные ихние яркости.
А вообще
https://ru.wikipedia.org/wiki/%D0%A6...B5%D0%BB%D1%8C
Человек всё равно оттенки синего видит мало, красного больше а зелёного ещё больше, то есть по сути 2 бита-синий, 3 бита-красный, 3 бита-зелёный, итого 8 бит перекрывающие все нужные цвета и оттенки.
Для PC да, для ZX мне 256 цветов хватит даже без палитры (а с палитрой и 16 хватит) у nes вообще по моему 14 цветов,споем опять- экран 256x192 8 бит 48кб, а 16 бит с вашим желанием 360x288 это 202 кб экран, очередной (ну неужели ни кто не читает ?) раз - у наших zx дисковод 640кб
почему ни кто не дружит с калькулятором !!! три ваши картинки и все....
Пусть автор если желает конечно делает, и потом вы радостно будите писать софт из выше приведенных РЕАЛИЙ:v2_dizzy_coder:
Прямой адресации к экрану не будет. Для Z80 лишние вычисления адреса из координат ни к чему. Для рисования точки и спрайта достаточно указать X и Y. Видеокарта дальше работает сама. Координаты X и Y по одному байту.
Видеовыход аппаратно будет 15 бит, т.е. 32768 оттенков.
Палитра 3 х 8 битов. Младшие 3 бита аппаратно отбрасываются.
В слоях, раз мы уменьшили объем памяти, точки хранятся по 8 бит на цвет точки.
Чтобы палитра фона не зависела от палитры ГГ или меню управления в каждом слое своя палитра.
не согласен, мало даже трёх бит, а два на синий - и того хуже; разница в восприятии оттенков начинает сказываться даже после хайколорной битности цвета
у nes своя палитра на каждый тайл (первый хинт)
иииии что? у атари диск был вовсе 90кб, а цветов, однако, больше чем у Спека в 17 раз (второй хинт)
почему кое-кто не дружит со своей памятью и не задаётся вопросом, а как в спектрумовских 48кб играх без подзагрузок умещалось несколько десятков экранов? :v2_dizzy_facepalm:
какой бред... примеры спрайтов "в спеке" величиной 128x128 в студию! :D
ну да, 16 бит больше одного бита в 16 раз - иииии что?
в спекоиграх графика обычно занимала до 20кб
умножаем на 16, получаем только половину дискеты
даже в совершенно несжатом виде
zst, как я понимаю, такую команду как "нарисовать спрайт" видеокарта выполняет долго, значит однозначно нужна будет очередь команд, скорее всего из обращений к шине Z80. Если отслеживать обращения к шине, то видеокарта без проблем может строить у себя копию памяти Z80, значит для загрузки данных тормозные ldir не нужны, достаточно просто указать, что данные с таких-то адресов мы хотим загрузить в палитру или текстуру. Если для Z80 переключались страницы, то предварительно можно считать нужный блок данных командами POP, потратив всего по 5 тактов на байт, и у видеокарты снова будет корректная копия нужного нам участка памяти Z80. Если координаты спрайтов лежат в памяти Z80, то перемещение можно сделать просто записью новых координат и вызовом команды "нарисовать несколько спрайтов".
Можно пойти еще дальше, сделав списки команд и их аргументов, в списке для каждого байта указывается адрес откуда его брать, это может быть ссылка на константу(например для кода команды), ссылка на ячейку видеокарты или памяти Z80, или даже ссылка на какой либо байт из последних операций на шине Z80. Последняя возможность позволит вычисляемые аргументы просто заталкивать в стек или ячейки памяти в том порядке, как удобно программе, список всё переставит как нужно, и использовать A, HL и прямую адресацию для этого будет уже совсем не обязательно. Ну а далее видеокарте выдаётся команда выполнить список номер N, видеокарта собирает все байты команды и выполняет. Еще полезная возможность будет выполнять команду из памяти Z80, то есть где-то лежит команда со всеми аргументами, а мы видеокарте просто сообщаем её адрес, после чего можно подправить некоторые аргументы и выполнить снова.
много вы наработаете без прямого доступа к памяти.
кроме того - самое узкое место щас у вас, это бутылочное горлышко в 256 байт для "указать X и Y. Видеокарта дальше работает сама. "
То есть, вышли на то, что нету идеи по принципу передачи параметров :)
В ZX-Evo достаточно нормальный принцип передачи параметров? (я сам ещё на нём не :v2_dizzy_coder: )
А что вообще передавать то надо? :)
Память только статика 4 микросхемы SRAM: 4 * 512K = 2М можно распределить так:
Слои экрана: 4 слоя по 2 блока по 256 * 256 точек по 2 байта = 1 M
Спрайты: 512 K
Буферы для вывода на VGA: 2 буфера VGA размерами по 320 * 240 точек по 2 байта = 300 K округляем до 512 К
Переброска аппаратная ? :)
Слабый вброс
Работаю потихоньку. Был в "отпуске". Надо было доделать ремонт в квартире. Через месяц ожидается рождение третьего ребенка.
Извините за задержку. Спаянные платы будут отправляться на этой неделе.
Приобрел лицензионную программу sPlan 7.0 - надеюсь процесс разработок немного ускорится.
Метеор, наверно будет все-таки для шины ZST-BUS на Upgrading Board для компьютеров ZX Spectrum и Ленинград.
При желании плату расширения можно будет подключить также и к Фениксу, Каю и Скорпиону.
Подключаться будет шлейфом IDC-40 в панельку вместо Z80 на плате компьютера. А Z80 переставляется в панельку на Upgrading Board.
К сожалению, совместимость с шиной NEMO-BUS может пострадать, так как в слоты расширения можно будет подключать не только 5V устройства, но и 3V3. Часть сигналов в разъеме уйдет на эту дополнительную шину данных. Сигналы шины адреса и шины управления с Z80 будут усилены с помощью буферов 74LVC245.
...
Новости сайта:
161128 По просьбам покупателей изготовлена партия печатных плат LENINGRAD-2010.
Записано несколько видеоуроков для освоения программы sPlan 7.0.
https://www.youtube.com/watch?v=iwI6HiKSejg
161116 Начато распространение лицензионных копий программ Sprint-Layout 6.0 и Splan 7.0.
160929 Добавлена возможность оплаты через PayPal.
Подробности на сайте http://www.zxkit.ru
- - - Добавлено - - -
Наверно надо сделать оба способа. Программно-аппаратный для сохранения размеров программы при сохранении скорости и аппаратный для ускорения с увеличением объема программы.
VIDEODAC переделан. Вместо сборок по 270 Ом 5% будут резисторы по 536 и 270 Ом 1%.
Аналоговые сигналы RGB будут подаваться на разъем IDC-16M. Цоколевака еще не придумана.
Разъем VGA будет устанавливаться на корпус компьютера и соединяться с платой Метеора шлейфом IDC-16.
http://www.youtube.com
Надо доделать бюджетный вариант "METEOR-1":
Шина: ZX-BUS / NEMO-BUS
FPGA: Циклон 4
RAM: 2 x SRAM 256K x 16bit = 1 Mбайт
VIDEO_OUT: VGA FULL HD 1920x1080, масштабирование экрана Спектрума в 4 раза
VIDEO_DAC: R-2R на резисторах 0603 1% по 5 бит на цвет.
EXT_CONNECTOR: IDC-16, 7 линий с FPGA и питание +5V.
Подключение разъема VGA: на заднюю стенку корпуса через шлейф IDC-10.
Расход памяти 1М:
512 Kбайт - два слоя графики по два экрана размером по 256 x 256 точек по 15 бит на точку.
300 Кбайт - два буфера VGA размером 320 х 240 точек по 15 бит на точку.
32 Кбайт - копии двух экранов Спектрума 128К.
180 Kбайт - свободная память
Дополнительные сигналы освободил за счет мультиплексирования шины адреса.
Распределение выводов FPGA:
http://savepic.ru/12524184m.png
НЕ маловато памяти ?
- - - Добавлено - - -
И как же 16М цветов?
А почему картридж? Его впарить можно? SDCard доступнее
Картирдж будет работать на Ленинграде и ZX-SPECTRUM. Там нет SD.
И с SD картами я еще не разобрался. ПЗУ проще.