Тогда чего (народ) волнуется о сложности реализации сумматора ???
Вид для печати
Тогда чего (народ) волнуется о сложности реализации сумматора ???
"Что то игривое у меня настроение" типа будем делать из "гов.. и палок" ???
Я понимаю теплый ламповый звук - но тут или Z80 оригинал или что-то из современного плисового. Сорри если кого обидел...
Я про них и говорю, но дело даже не в них а в концепции :)
Z80 оригинал ещё никто не отменял, вот только частоту поднять до 20 надо, а что плохого если рассыпуха запихнута в плисину, и что бы программно было как можно проще, пока что я не видел какого то простого для программирования предложения.
- - - Добавлено - - -
Я пока не понял каким образом вы собираетесь подкрашивать игру на программном уровне, да и зачем это? ради 1 жёлтого спрайта диззи который ужасным образом клешует с зеленым деревом? В других играх всё равно заднего фона практически нет.
Моя непонимать как вы это собрались делать.
п.с. хочу текстовый режим больше чем 32x24 :) хочу редактор ассемблера с вкладками для подпрограмм и готовыми процедурами видеовывода, работы с hdd и sd, звуком и бла бла бла :D
Основная проблема экрана ZX Spectrum - клешинг атрибутов. Это связано с тем, что в квадрате 8 на 8 точек могут быть точки только двух цветов. Поэтому движение цветных персонажей по цветному фону невозможно. Или они изображаются с клешингом. Было бы хотя бы 3 цвета на знакоместо...
Поэтому для добавления нового режима без клешинга нужна видеокарта Meteor.
Она позволит убрать клешинг в старых цветных играх и упростит разработку новых.
Количество цветов в спрайтах ограничено до трех, а в тайлах до четырех. Но есть отличие от Денди, где всего 12 цветов на спрайты и 12 цветов на тайлы из 64 цветов. В новой видеокарте активные/рабочие 4 цвета можно менять в любой момент. Так можно отобразить на одном экране до 32768 разных цветов.
У Денди также ограничение на количество спрайтов в строке не более 8. У меня спрайты рисуются на слои программным способом с элементами ускорения. Что упрощяет вывод спрайтов в старых играх. В дальнейшем рисование спрайтов можно проапрегейдить до блиттера.
Разрешение увеличивать пока не надо. Максимум разрешение 256 х 224. Вдруг кто захочет сделать BATTLE CITY 2.
Вместо аппаратных спрайтов Денди будут использоваться 8 слоев с возможностью наложения с использованием прозрачного цвета.
Наверно для построения уровней можно будет использовать редакторы, написанные для Денди.
на дворе стоял 2016 год, но спектрумисты всё пытались сделать из Спектрума пародию на приставки тридцатилетней давности :v2_dizzy_facepalm:
это как при наличии нормального большого бассейна внутрь поставить маленький надувной и водой наполнить только его
основная проблема Спектрума и спектрумистов - их ограниченность ;)
+100500 :D
Если уж решили и делать так делайте сразу нормально, я к примеру не хочу лопатить nether earth (самая распространённая русифицированная версия была мной переведена :D ) только ради того что бы убрать клешинг на жёлто-черном экране, мне его проще сделать заново если будет нормальная аппаратная организация спрайтов 8 бит на точку. То же самое и с soldier of fortune, exolon, r-type, renegade, zybex и т.д. их проще нахрендячить заново, заодно может и серию сделать. Но только не на программном экране. Я сожму спрайты с 1 байтом на пиксель плавающим битом, потом распакую сразу в память видеокарты, и пусть она мне по команде рисует спрайт из адресу туда куда мне надо.
Хочу так :)
И да, никаких С++ и прочей лабуды.
Я даже за то что бы делать вызовы через какой нибудь отключаемый RST, с пзу сейчас проблем явно нет, да и если стоит плис, пусть она с флешки в озу кинет прошивку при старте.
Я с tr-dos биосом не разбирался, но он там что действительно на все 16 кБ ? или его можно нормализовать и пихнуть туда и ide и sd на fat`е ? тем более от ВГ достаточно кинуть всего 1 проводок на прерывание, и не ждать пока она там бамбук курить, считала байт - кинула прерывание - забрали байт - занимаемся своими делами.
Порядок надо в системе навести, программ с использованием пзу бейсика и тр-дос по пальцам пересчитать можно, (демы с параллельно-корявой загрузкой с диска я не считаю, 1 проводок от ВГ до CPU решает все проблемы) да и в свойствах файла не проблема прописать байтик совместимости с программным считыванием, один хрен сейчас 16 килобайтовыми образами пзу никого не удивить, на самую примитивную dip флешку их больше 64 впихивается.
Ну это так, дурные мысли в голову лезут.
тебе проще, а кому-то интересно перелопатить, но ведь можно сделать, чтоб удобно было тем и другим
и ты тоже)) 8 недостаточно для нормальной, а 16 и на физическую память лучше ложится
а зачем, пускай пожатыми и хранятся, а блиттер распакует при отрисовке (заодно на память меньше нагрузка)
ох, о чём я... тут вообще, вон, не понимают, зачем он нужен, и что сможет даже самый простой...
- - - Добавлено - - -
не, столько в наш плисовый бассейн не поместится :p
Не надо так реагировать на слово Денди или приставка. Клешинга там нет. Что полезного в графике Денди можно использовать и улучшить:
Цвета:
Спектрум: 1 бит на цвет точки. Атрибут на область 8х8 точек, 15 цветов, яркость общая для PAPER и INK. Малополезный FLASH. Атрибут хранится в памяти.
Денди: 2 бита на цвет точки. Атрибут на область 16х16 точек, 3 цвета + прозрачный из 12 цветов для тайлов из 64 возможных. Атрибут хранится в памяти.
Метеор: 2 бита на цвет точки. Атрибут на область 8х1 точек, рабочие 4 цвета из 32768, любой из четырех можно указать как прозрачный. Атрибут не хранится в памяти, а перекрашивает точки в 4 цвета при рисовании тайла или спрайта.
Скроллинг:
Спектрум: программный, при этом атрибуты не двигаются.
Денди: один слой с аппаратным скроллингом, атрибуты двигаются вместе с тайлами.
Метеор: до 8 слоев с аппаратным скроллингом, двигается весь слой, состоящий из точек по 16 бит на точку.
Спрайты:
Спектрум: программно по маске. Читается байт из экрана, накладывается графика по маске и записывается результат на экран. При цветных спрайтах появляется клешинг атрибутов. Координаты вычисляются по сложной формуле, что замедляет вывод. Чтобы не было мерцаний надо успеть нарисовать спрайт до луча телевизора. Или использовать второй экран для 128К версии.
Денди: 64 аппаратных спрайта размером 8 х 8 точек. У всех спрайтов общие 12 цветов из 64 возможных. Координаты задаются аппаратно. Если в строке больше 8 спрайтов, то они исчезают или мерцают.
Метеор: для рисования спрайта указываются координаты спрайта, размеры, 4 цвета, затем копируются данные спрайта командой LDIR. Возможно несколько вариантов копирования, например, данные можно писать по одному адресу. Можно без изменений использовать спрайты с маской при доработке старых (уже написанных) игр. Спрайты можно накладывать, цвет спрайта можно менять в процессе рисоания. В слое возможно до 32768 цветов. 2 экрана в каждом слое. Чтобы не было мерцаний один экран отображается, а на другой в это время рисуются новые спрайты.
Много чего нет. Например, нормального контроля каждого пикселя. И даже тайлов не хватает на весь экран.
Ага, полезного в восемьдесят лохматом году, когда память была очень недешёвой и очень медленной.
Что в ней СЕЙЧАС полезного по сравнению с нормальным блиттером в хайколоре?
то, что ты описал для метеора - не атрибут и не совместимо с процедурами в играх спектрума
Нахрена СЕЙЧАС аппаратный скроллинг? Нам что, не хватает скорости памяти, чтобы "двигать" через произвольное обновление?
Зачем так? В старых играх с наскока неприменимо (там не координаты, там адреса в оригинальной раскладке).
А если уж код и переделывать настолько, то ради полноцветного блитинга, а не ради жалкого двухбитного цвета.
Заодно и костыли типа аппаратного скроллинга можно выкинуть.
Предлагаю предусмотреть и 8 слоев с аппаратным скроллингом и блиттер в каждом слое. Неспользуемые слои будем отключать для освобождения времени на работу блиттера. Программист сам выберет, каким способом будет создавать изображение.
В старых играх по координатам вычислялся адрес спрайта на экране, читался байт из памяти экрана, читалась маска, накладывалась на байт с экрана, читался байт спрайта, накладывался на результат, результат записывался на экран. Все это занимает много памяти и выполняется медленно.Цитата:
Зачем так? В старых играх с наскока неприменимо (там не координаты, там адреса в оригинальной раскладке).
А если уж код и переделывать настолько, то ради полноцветного блитинга, а не ради жалкого двухбитного цвета.
Заодно и костыли типа аппаратного скроллинга можно выкинуть.
Я предлагаю упростить расчеты и рисование спрайта. Мы будем использовать координаты. Вместо вычислений с маской мы просто будем записывать маску и байт спрайта в видеокарту. Поэтому новая процедура рисования спрайта будет короче и выполняться быстрее. То есть, скорость работы игры не уменьшится.
Давай пока блиттер отложим на следующий этап. На первом этапе устраним клешинг программным способом с элементами ускорения, описанным выше. Но это все программная реализация. Нам сейчас надо доделать аппаратные задачи и спроектировать плату. Желательно предусмотреть заранее аппаратные требования для типовых игр уровня Денди и PC времен MSDOS 6.22. Дальше предлагаю не усложнять требования.
Сейчас для 8 слоев предусмотрена быстрая 10 ns память SRAM объемом 2M. Предлагаю подумать о выборе:
1. Для блиттера увеличить в два раза скорость операций чтения и записи из/в SRAM за счет удвоения ширины шины данных с 16 до 32. Для этого добавить еще SRAM 2M. Читаться и писаться будет по две точки вместо одной.
2. Добавить SDRAM 32M для памяти тайлов/спрайтов и буфера VGA. Читаться и писаться будет по одной точке.
Предлагаю не тащить в девайсы пыльный старый ненужный мусор, не превращать в свалку древних костылей, и не ломать о них здоровые ноги.
Ты так не упрощаешь, а усложняешь задачу для "модернизатора старых игр". Ускорять при модернизации нужно мало где, раз уж Спектрум успевал и в оригинале. Самое простое - найти код, непосредственно записывающий в экран, остальное дольше и неприятнее, а ты предлагаешь до координат цепочку раскручивать, процедуры полностью переписывать, да еще подойдёт не каждый формат у спрайтов. И хоть альтернативная раскладка (в отличие от совершенно лишних слоёв) полезна, но как дополнение, а не как единственный вариант. Ты не там предоставляешь выбор для программиста.
Ну, отложи пока. Но только не тащи подпорки и костыли при этом на его место.
Желательно начинать с уяснения потенциала современного железа, а не с "неусложнения" наугад до уровня пародии на приставки или старые песюки.
Предлагаю выкинуть бесполезные слои на мороз.
у тебя же ног у плис не хватало)))
и еще с выравниванием возиться? лучше подумать на тему будущего блитинга с распаковкой
что еще за тайлоспрайты опять полезли?
Хорошо, что у меня Спринтер и таких вот "денди" костылей у меня там нет. читать с экрана байт для выделения маски, что за вздор? куча разной фигни не нужной. ббррррр.
это тоже очередной костыль. ТСлаб тоже сделал подобный баян в своём конфиге, только в дма, который умеет только по 2 байта (кратность 2 байта). если надо кратно 1 байту, то ловим пачку багов. нет уж, сами с этим играйтесь...Цитата:
Читаться и писаться будет по две точки вместо одной.
Sayman, баян баяном, но проц при пересылке остаётся свободным.
а что за пачка багов, расскажи?
мне для расширения кругозора интересно.
Hacker VBI, непосредственно про баги может рассказать автор. лично я такое наблюдал. к примеру, в демке ротатора, которую там на форуме выложил любезно с исходниками jerry. белые дыры при вращении спрайта - вина не кодера или алгоритма, а железа. учитывая пересылку строго по 2 байта, очень сильно мне бы не хотелось громоздить спрайты, как пример, кратные 2 байтам. очень сильно не хочется извращаться на предмет "подстраиваться под какую то кратность" там, где без неё реально можно было бы обойтись. на спринтере при пересылке данных проц тоже отдыхает. тот же дма, только обозвали его тут модным в то время словом "акселератор". только он пересылает данные с точностью до байт и нет потребности в отдельных извратах.
Sayman, ты бред несёшь.
Эффект я видел. Дма там юзается только для обновления фона. Вот обсуждение этого эффекта
Слова джерри: "ДМА да использую чтобы восстановить фон. но восстанавливаю с запасом ибо лень считать было"
Читай за DMA, а не придумывай и выдавай выдумки за правду.
Hacker VBI, я сижу в отладчике и вижу как оно работает.
если ты считаешь. что я гоню отсебятину, обрати внимание на мануалы и факи от тслаба:
Цитата:
Q: Почему в регистрах младших битов адресов не используется 0-й бит?
А: Для получения наибольшего быстродействия и минимальных затрат логики ДМА работает с 16-битными данными, следовательно адреса четные.
Записывая в младший байт регистра адреса число, младший бит НЕОБХОДИМО занулять.
Sayman, окей, я тоже.
ты видишь вот этот набор:
dup пицот
pop hl
ld (hl),a
edup
и дальше
dup стопицот
pop hl
sub e
jr nc,$+3
ld (hl),b
add a,c
edup
и это по твоему всё дма?
Hacker VBI, об чём речь?
баг дма с кратностью в 1 байт:
Вложение 57916
а всего лишь-то поменял длину транзакции на 1 байт (т.е. сделал кратность в 1 байт).
про остальное даже говорить не хочу...
Sayman, доку читать приучен?
"Скорость пересылки составляет 7 Мгц, копирование происходит по два байта (16 бит) при условии что в этот такт к памяти нет обращения от ЦПУ, видео или ТСУ.
В среднем: 4 байта — 2 такта, дма обращается к озу за 1 такт 7 мгц, 16 бит, для пересылки надо 2 обращения
Получаем: скорость DMA 7 МБ/с"
это не баг, дядя.
я вот не могу укусить себя за локоть. это тоже баг?
Найдем.
Я про скорость копирования писал. За 10 ns можно будет прочитать в два раза больше данных.Цитата:
и еще с выравниванием возиться? лучше подумать на тему будущего блитинга с распаковкой
А блиттер что пересылать будет ?Цитата:
что еще за тайлоспрайты опять полезли?
- - - Добавлено - - -
Это в стандартном режиме Спектрума надо читать с экрана и накладывать байт маски и байт спрайта. Я предлагаю байт маски и спрайта просто переслать в видеокарту.
Есть способ рисовать спрайты с точностью до точки. При этом память сможет записывать 2 точки.Цитата:
это тоже очередной костыль. ТСлаб тоже сделал подобный баян в своём конфиге, только в дма, который умеет только по 2 байта (кратность 2 байта). если надо кратно 1 байту, то ловим пачку багов. нет уж, сами с этим играйтесь...
- - - Добавлено - - -
В Метеоре скорость пересылки при одном банке SRAM составит до 7*14=98 Мбайт/c. С двумя банками 196 Мбайт/c. В моменты, когда не идет чтение слоев для вывода на телевизор и нет записи от Z80. Точка занимает 2 байта.
Сколько памяти SRAM и SDRAM желательно установить для игр?
ну, нормально. картинка рассыпалась вся и это не баг.Цитата:
это не баг, дядя.
на картинке, я ещё раз повторю - баг работы дма тсконфы. я указал вместо кратного 2м байтам размер транзакции, кратность в 1 байт (младший бит = 1). в результате картинка при работе дма разрушилась вся. включая выводимый спрайт, хотя он, вообще-то, якобы не должен быть разрушен. а ты мне про:
ты тоже не всё в доке читаешь. там же чёрным по белому: "...и минимальных затрат логики ...". вот с этого и надо было начинать писать, а не мегагерцы.Цитата:
Скорость пересылки составляет 7 Мгц
и почему движок тупо не игнорирует 0й бит, а позволяет ему участвовать в операциях? что, опять программист должен побеспокоиться о заднице железячника?
Sayman,
я вижу по твоему размытому скриншоту следующее:
- странная палитра, она прописана вообще? правильно отправлена в систему? она для этого изображения? правильно ли установлены биты регистра palsel для неё?
- что с очисткой экрана, не нужно?
- доку писал я, и она проверялась TSL
но продолжим:
кратность пересылки - 2 байта. даже если ты указываешь 0 длину - это 2 байта. установить 1 байт нереально.
так же, указав нечётный адрес источника или приёмника - всё выравнивается системой (это относится к "0й бит" ).
пример бага в студию, ща разберём все допущенные тобою ошибки.
Hacker VBI, окэй, сейчас всё перепроверю (но проверяю один фиг по эмулю, т.к. реального тсконфига у меня нет)
Sayman, ок.
заодно проверь следующее:
- Какая видеопага включена для отображения
- в каком она режиме (16/256 цветов)
- в какой паге ты производишь обновление памяти экрана.
- значения в G X/Y Offset, это интересно - возможно в них не 0, и у тебя сдвинуто положение экрана.
ну и стоит исходить из архитектуры системы, а не своих ожиданий и настроений.
а эмуль - это нормально.
уухх сколько переменных то)))))
тем временем, косяк был мой. не скажу в чём.
заодно подсчитал. что спринтер тратит 22.5 такта на пересылку 256 байт. если я верно понимаю, те же 256 байт ТС перекинет уже за 128 тактов? или я опять не так подсчитал?!
А спринтере 96 битная память?
- - - Добавлено - - -
Это примерно 12 байт за такт памяти
s_kosorev, я мог ошибиться в расчётах. я же переспросил там в конце, что я опять не так подсчитал?
я исходил из двух вещей. первое, это по мануалу:
второе, по исходнику, опять-таки если верно прочитал исходник на ahdl, память с акселем работают на 42мгц, а не 7 как у ТС (со слов Хакера).Цитата:
Скорость работы акселератора ограничивается только физической
скоростью работы основного ОЗУ. Определить примерное время работы команды с
акселератором можно по такой формуле:
Время работы = время работы команды без акселератора + время работы
акселератора
Время работы акселератора = число пересылаемых байт /7 микросекунд
попробуй это всё переведи в такты. тоже хочется узнать, где же тут истина.
так же могу сказать одну вещь, что если на ТСконфе после транзакции нужно ожидать прерывание от ДМА (типа он закончил пересылку данных, опрос статуса дма на предмет бита busy), то тут ожидать этого не нужно. выполнив последнюю команду при которой данные улетают куда надо, я могу выполнять любое другое действие сразу, без ожидания.
т.е. чтобы скинуть сколько-то байт (или заполнить или скопировать), я делаю примерно так:
никакого ожидания битов и статусов. после ld b,b волен делать что угодно.Код:di ;обязательно, иначе батхерт
ld d,d ;включить аксель
ld a,cnt ;сколько...
ld l,l ;просто копируем
ld a,(hl) ;в этот момент альтера перехватила команду и записала cnt байт из озу в свою память
ld (de),a ;а тут она после перехвата делает запись из своей памяти в озу
ld b,b ;отключение акселератора
Да и сам Хакер тоже не совсем верно подсчитал производительность дма. считать надо с учётом всех участвующих команд проца+время ожидания бита статуса.
единственное, думаю, что ТСный дма будет иметь выигрыш на больших объёмах транзакций. т.е. если я верно прочитал мануал, можно задавать для дма количество выполняемых транзакций (это кроме размера самой транзакции). в то же время, на спринтере именно такого параметра нет. т.е. макс.256байт и всё. потом, если надо, иди на новый круг выполняй процедуру.
s_kosorev, гугл с тобой не согласен. он мне подсказывает, что до 30мгц и выше при 60нс. уже как бы не 10мгц. и там речь идёт про fpm, а edo модули на спринтере не работают.
в описании на спринтера сказано, что память работает на своих запредельных частотах. в исходнике есть сигнал clk42. Иван говорил про него, что это 42мгц. в общем. открой исходник acceler.tdf, там есть ответ для тебя...
кстати, Иван писал об этом, что когда он там платы запускал, он тестировал на них разные модули СИММ. какие-то заводились сразу, какие-то тупили. закономерности он не выявил, но думаю, что в этом и причина, что некоторые модули не заводились на таких частотах.
есть рандомный доступ, там где полный ras-cas а есть пакетные разные оптимизации, когда выбран ряд уже, так вот полный ras-cas потолок 7-10 мгц, внезапно даже у DDR4
- - - Добавлено - - -
Хотя не, обманул, пересчитал для DDR4 из шустрых, полный цикл аналогичный классической DRAM (тобишь вообще без каких либо оптимизаций) аж 26мгц скорости дает при рабоче 2133мгц :)
s_kosorev, а я не буду спорить. я вот что вижу по исходнику, вижу, что это работает. а подробности уже не так важны. если по исходнику на память подают 42мгц. значит там 42мгц. реализация всё ровно. снимем замеры, посмотрим.
какая там память?
- - - Добавлено - - -
Нашел что Sprinter 2000 использует simm72
Берем даташит на первую попавшуюся микруху 60нс
курим доку http://prntscr.com/c7ml8g и внезапно видим 90-110нс что то около 10мгц
42мгц это модуль может работать на такой частоте, но не сама память, модуль может юзать 6 тактов своего клока на 1 цикл памяти
s_kosorev, Время работы акселератора = число пересылаемых байт / 7 микросекунд = 256/7 = 36.57142857142857 микросекунд . переведи в такты. это будет физически возможная (рабочая) скорость работы акселератора у спринтера. остальное для меня китайская грамота.
это я ещё не упоминал о том, что видеопамять тут на сраме...
так если цикл 7мкс это 140 кб/с
т.е. примерно в 50 раз медленней чей 7мб/с