больше тем о видеокартах богу видеокарт! ;)
Вид для печати
больше тем о видеокартах богу видеокарт! ;)
дурость, однозначно, оно не влезет между ног а плата сбоку от переходника, всем не угодить
и нафик? оно по шине ограничено все, 3,5/3 потолок, 2 такта никак, минимум 6 + выборка 7 итого 13, профит никакой, div/mul это может и внешняя железка, запись в порты в любом случае быстрее чем программно, блочные команды это DMA
- - - Добавлено - - -
вот и я думаю, каждый имеет право на тему с видокартой
Вби, а у тэсэлыча блиттер-то не настоящий!
Смотрел программирование блиттера для Direct? Блиттер не оперирует адресами, а геометрическими областями поверхностей.
Не ну можно конечно сделать zx-spectrum+ на 150 корпусах и видеокарту на 200 корпусах, в принципе классно получится.
Плисину на dip-40 СТАВЯТ, и стоит она там по диагонали, а не так давно кристалл плисины ставили прям в корпуса dip-40 и dip-48 (на заказ).
LDIR прекрасно делается за 2 такта на байт, плюс первых 2 такта на выборку самой команды.
Блочный команды это не DMA, LDIR это DMA а блочные команды это всякие or, and, xor, rotate для блока данных, компрессия и всё такое.
Короче, надо делать Метеор и посмотреть как на него игры будут переделывать :)
Давай еще раз. Спектрум расчитан на частоту доступа к памяти максимум 3,5/3такта, железные ограничения, циклы памяти, паралельная работа видеогенератора. Итд, то есть ldir минимум это 3+3 выборка 3+3 пересылка одного байта, то биш 12 тактов.
Далее, тут пропихивали идею про блиттер, блиттер это куто но это тормоз, 20 летней давности технология.
Процеессор пока рисует сцену, должен ждать блиттер, опрашивая статус или висеть в wait, в крайнем случае прерывание, но это все бесполезно тратит время проца.
Есть альтернатива, аля дисплей лист, но если его делать аппаратно, это опять же какие то нелепые ограничения с кучей расходов ресурсов плис.
Отсюда вывод в видяхе должен быть свой процессор, который может по данным от z80 (организованных как удобно ему) строить сцену, хочется гоночный движок, не вопрос, хочется изометрическую игрушку или сроллер, все можно сделать практически не напрягая z80, но просто блиттер + проц в видяхе, это не даст максимум выжать, нужны внутренние блоки памяти и аппаратные механизмы для растеризации этих блоков в кадровый буфер. Все это упрощает программу для Z80 и можно максимум из железа выбить.
- - - Добавлено - - -
даже вопрос о умножениях/делениях можно снять с Z80
- - - Добавлено - - -
Это можно назвать метеором, а не текущие унылые фантазии
"тормоз" по сравнению с чем? с шейдерными монстрами из миллиардов транзисторов?
блиттер просто сделать и просто программировать, это главное
тупо очередь (даже не законченных команд, а отдельных записей в регистры), не нужна на это куча расходов
но и даже просто висеть в вайте - всё равно в конечном итоге быстрей в разы, чем отрисовать процом то же самое
(запросто еще и времени для него останется больше в кадре)
каких команд? их реализация в железе потянет на сожность процессора простого, не проще сразу процессор вставить? И нафик нужен блиттер который просто куски копирует, а я может свет хочу, туман там итд.
Даже в 2d графике можно много ресурсоемких вещей найти
тормоз по сравнению с тем что можно сделать, зачем ограничивать себя?
а можно и не висеть а заниматься чем то полезным а более быстрый проц у которого скажем регистровый файл подключен на прямую к блиттеру делает это быстрее
- - - Добавлено - - -
Банальный пример,
нужно нарисовать заник с водичкой там туманом, ну 2-3 слоя.
Спрайты и передний план тоже полупрозрачый.
пусть 16 бит память, работаем исключительно пакетами и потерь 0), возьмем кусок 32х32 пикселя.
1. Выводим задник, 1024 цикла
2. Выводим полупрозрачную водичку, 1024 чтение + 1024 запись результата
3. Выводим туман, 1024 + 1024
4. Выводим спрайт, пусть занимает половину 512
5. Выводим полупрозраный передный план 1024+1024
итого 7.5к тактов, + на чтение патернов спрайтов итд, пусть разные 4.5к тактов итого 12 к тактов
теперь если мы обрабатываем эту всю историю в внутренем буфере в 1к байт
4.5к чтение патернов + 1024 запись итого 5.5к профит в раза.
Далее, если патерн повторяющийся к примеру 16х16, профит с буфером еще больше, а если тума и водичка еще и генерятся процом в видяхе ... (хотя тут может быть выгоднее прочитать)
переброски блока, каких еще-то?
проще начинать с малого (и такое-то никак не могут асилить)
так затем и нужен, чтобы можно было потом добавить новых возможностей
для них та же база будет нужна - счётчики, блоки чтения и записи, интерфейс
поконкретнее - по сравнению с тем, что можно сделать с миллиардом транзисторов и вагонищем свободного времени?
какой нафиг "более быстрый проц подключенный к блиттеру напрямую"? девайс нужен подключаемый в системный разъём!
насчёт скорости - всё упрётся в ПСП в конечном итоге, а чтобы проц компа не ждал, так и очереди хватит самой тупой
притом очередь почти уже дисплейлист, если в озу девайса запоминать, не хватает только управления указателем
С туманами это проще взять GeForce 210, а нам пока хватит обычной переброски блоков, вставлять в ПЛИС процессор а зачем тогда нужен Z80 ? можно тогда всё на том проце сделать.
Небольшая очередь приёма данных решает проблемы задержки, для ПЛИС в этом нет никаких проблем, там более никто не запрещает включить IM 1 и на какое нибудь прерывание повесить освобождение видео для приёма данных.
"Давай еще раз. Спектрум расчитан на частоту доступа к памяти максимум 3,5/3такта, железные ограничения, циклы памяти, паралельная работа видеогенератора. Итд, то есть ldir минимум это 3+3 выборка 3+3 пересылка одного байта, то биш 12 тактов."
Как это? пересылка одного байта в мультиплексоре команд занимает 2 технических такта системы при 8 битной шине данных, видеопамять подключена к видео плис, как там у неё работает регенерация видеопамяти проблемы именно этой плис.
речь шла о z80 на Fpga в панельке, так что проблема регенерации и доступа шины в полный рост, а если нужен быстрый Z80 и побоку на гнилое барахло с антресоли, так вообще не понятен вопрос
тут на форуме куча плат есть и конфигуации к ним, берите nextZ80 на opencores подходящую плату и вперед
Вот оказывается чего уже существует и даже продаётся:
http://excamera.com/sphinx/gameduino/
Небольшой процессор для всяких эффектов туда тоже встроен. В теории можно припаять проводки к jtag и перепрограммировать FPGA во что-то другое, может даже поддерживающее 3D. Единственный минус в том, что рулить этим безобразием можно только через SPI, потому что кроме него на разъёмы мало чего выведено, но возможно что добавление небольшой CPLD эту проблему позволит решить.Код:video output is 400x300 pixels in 512 colors
all color processed internally at 15-bit precision
compatible with any standard VGA monitor (800x600 @ 72Hz)
background graphics
512x512 pixel character background
256 characters, each with independent 4 color palette
pixel-smooth X-Y wraparound scroll
foreground graphics
each sprite is 16x16 pixels with per-pixel transparency
each sprite can use 256, 16 or 4 colors
four-way rotate and flip
96 sprites per scan-line, 1536 texels per line
pixel-perfect sprite collision detection
audio output is a stereo 12-bit frequency synthesizer
64 independent voices 10-8000 Hz
per-voice sine wave or white noise
sample playback channel
Так я и говорю что всё это сейчас не проблема, оригинального zx-spectrum давно уже ни у кого нет, но некоторые почему то за него цепляются, сейчас любую шнягу можно сделать на плис, обкатать и потом просто заказать штамповку, приложив немного усилий к самой концепции zx-spectrum не так сложно вывести её хотя бы на минимальный комфортный уровень, не отходя при этом от сути открытого программирования с минимальными затратами.
Вот с этой шняги
https://www.youtube.com/watch?v=awgw1lj7KKI
Кстати этой шняге уже лет 6
zst, 286 и 386 это тоже священные компы. пусть Интела вернутся к истокам и сделают для них апгрейды, то вот фигня, я GeForce 1060 не могу к ним подключить...
это убого, вот на что ровняться надо https://www.youtube.com/watch?v=h42neZVvoMY
ППц у вас тут баталия. Где быстрая карта?) в Какой Пятилетки?) Я устал ждать=)
Отсутствие терпения это исключительно твоя проблема.
Чтобы карта получилась быстрой, делать её нужно медленно! ) Чем медленнее делается карта, тем более быстрой она в итоге получится.
ZX SPECTRUM тоже не быстро делался. Прежде чем он увидел свет в 82 году, его двадцать лет разрабатывали в тайных лабораториях Скотланд-Ярда!
Так а что там с Метеором? может быть всё и НЕплохо с ним? может достаточно исключить программную работу и перевести всё на аппаратную?
В старых играх расположение байтов в спрайте может быть каким угодно. Там трудно сделать аппаратное копирование. Придется программно.
Кроме этого для доработки старых игр надо спрашивать разрешение издательства. Я спросил у одного - разрешение не дали.
Аппаратно можно только для новых игр делать. Для этого надо выбрать расположение байтов в спрайте. Чтобы сделать аппаратное копирование надо дублировать в видеокарте основную память 48К. Тогда придется уменьшить количество слоев с 7 до 8.
Давайте для новых игр делать. Тогда тема про устранение клешинга в старых играх теряет смысл.
- - - Добавлено - - -
Еще нужна программа для рисования спрайтов в формате 2 бита на точку.
Можно конечно по два байта на точку, но размер игры увеличится в 8 раз.
Придется спрайты загружать в память видеокарты. 128 К * 8 = 1 М.
Тогда у нас половина статики уйдет на спрайты. Останется 4 слоя.
С SDRAM пока возиться не охота.
Если 4 слоя будет мало - тогда спрайты будем хранить в SDRAM.
- - - Добавлено - - -
Ранее предлагали хранить несколько спрайтов на одной картинке и в памяти хранить так, чтобы можно было легко переходить к точке справа и к точке снизу. Оба байта цвета точки будут располагаться в одном слове SRAM. Надо выбрать ширину картинки со спрайтами, чтобы видеокарта знала смещение к точке снизу. Размер 2 в степени n, то есть 256, 512 и т.д.
Наверно лучше 256 как ширина экрана.
- - - Добавлено - - -
Нельзя дорабатывать чужое произведение искусства без разрешения автора. Нельзя выкладывать видео без разрешения автора. Нельзя ...
- - - Добавлено - - -
В оригинальном ZX Spectrum и ZX Spectrum+ ПЗУ можно отключать. И обеспечить загрузку и чтение из видеокарты. Но к компьютеру может быть подключена плата типа divIDE, divMMC, Interface 1 bis и т.п. Они могут мешать, так как подключают вместо основного ПЗУ свое ПЗУ и ОЗУ. Как быть ?
Так бы можно было через окно вместо ПЗУ расширить память компьютеров с 48К.
- - - Добавлено - - -
Может разработать свою плату для загрузки вместо вышеуказанных? При этом 8 К выделить для расширения памяти, а 8 К на адресацию регистров видеокарты.
- - - Добавлено - - -
Или если старые игры мы не переделываем, то для адресации регистров Метеора занять адреса старого экрана с 4000.
- - - Добавлено - - -
Если нужно будет перемещать начало блока регистров можно будет использовать адрес порта с A0=0. Например, 0111 1110. Видеокарта проанализирует 8 младших битов адреса. И если это ее адрес, она сформирует сигнал IORQGE для блокировки порта 1111 1110 в ULA.
- - - Добавлено - - -
Для загрузки спрайтов в видеокарту использовать устройство USB-RECORDER или FAST PC LOADER. Загрузку начинать как стандартный TAP, а затем переходить на FAST скорость. Адрес порта выбрать аналогичный, например, 1011 1110. Тогда можно будет использовать загрузку блоками по 256 байтов с помощью команды INIR. 1М тогда будет грузиться быстро.
Жесть, магнитофон и производные забыть как страшный сон
[/QUOTE]
Для загрузки спрайтов в видеокарту использовать устройство USB-RECORDER или FAST PC LOADER. Загрузку начинать как стандартный TAP, а затем переходить на FAST скорость. Адрес порта выбрать аналогичный, например, 1011 1110. Тогда можно будет использовать загрузку блоками по 256 байтов с помощью команды INIR. 1М тогда будет грузиться быстро.[/QUOTE]
Лично мне было бы удобно работать с образом графики подключаемым к устройству A/B/C/D через TR-DOS и запихивать в карту данные по необходимости через порт или область DMА, которую видит видео-карта.
С другой стороны из области фантазий касательно загрузок… Предположим есть образ игры/программы (TRD/FDI и др), а также образ файла(ы) расширенной графики (условно ZGX). Оба файла хранятся в одной и той же директории на устройстве (HDD). Игра/программа загружаются как обычно средствами TR_DOS после подключения образа, а вот ZGX файл(ы) графики загружается параллельно самой картой. Разумеется, для такой автоматизации нужен стандарт/формат ZGX файла, который карта сможет понимать. Карта должна видеть подключаемый образ на HDD и его рут и соответственно подгружает при нахождении там ZGX файл(ы).
Вон неужели разумность пошла, что надо комплексно всё делать :)
Просто сделать видеокарту ничего не даст, надо всю систему под неё подкатывать, при этом оставив саму оригинальность, то есть работа с экраном и с TR-DOS и с Basic, ну естесно малость доделанные :)
В TR-DOS же работают каналы # ? можно же по каналу загрузить? хотя есть и есть то там ограничение 16 бит на адрес, надо мудрить что-то.
п.с. https://www.youtube.com/watch?v=GvBlba9i8EI
отсыпте мне тоже вашей травки, чтоли?! иметь винт и грузить образ трд в трдос. это надо иметь ооочень извращённую фантазию)))Цитата:
Оба файла хранятся в одной и той же директории на устройстве (HDD). Игра/программа загружаются как обычно средствами TR_DOS после подключения образа, а вот ZGX файл(ы) графики загружается параллельно самой картой.
не проще ли сразу работать через апи того, что с винтом работает (тот же вилд командер или что там ещё есть)... блин, ну изврат.
Nesser, вот объясни мне, есть рабочее апи под винт. можно файло (не трд) грузить прям мегабайтами прям с винта. раскладывать файлики по папочками и из них аккуратно всё подгружать. для чего извращения с образами трд и трдосом, если есть винт? а ещё большим извратом, заставлять видеокарту читать файл с винта. т.е. карта должна иметь какое то представление об ФС, кластерах, секторах (в том числе, фрагментированность файла). потому, делитесь травкой, я тоже хочу прИхода такого, мегаизвратного)))
Дело не в траве... хотя понимаю вашу реакцию... "Не грози Южному централу, попивая сок у себя в квартале..." :) много иллюзий насчет API/// Если закрыв Wild Commander, вы бы в операционной системе оказались, которая какой-то командой файлы графики подгружала, тогда "матрац скурил".. НО работа с файлами на большинстве платформ реализуется через образы. Смысл в том, что без дополнительных примочек для Пентево/EVo народ скорее всего будет работать именно через TR_DOS (мое мнение) и даже на других ZX-совместимых. Ну или просто кто-то взял и решил вдруг прошить EVO какой-то другой платформой (то же Scorpion например)... Именно в этом случае Backdoor нужен в виде обычных образов с загрузкой данных через порты карты... А так ессно можно и на более высоком уровне загонять в карту (дело в конкретной реализации и в том, с чем вы работаете в данный момент /сжатый файл для запуска и исполнения кода, который ничего не знает про вилд коммандер и завершение работы будет через резет или это временный образ для работы и потом будет запуск ТРДОС с последующей работой в образе и/или отскок в Wild Commander///. без "Лукавого" - тот же Wild Commander работает с образами в каких-то случаях (он же не является операционной системой), не используя прямой запуск программ сжатых ... Можно и Sprinter еще вспомнить... да хоть PC... там одних образов Alcohol, Power ISO обвешаться ... Образ диска - это контейнер, а операционная система все равно работает с устройством{пусть и виртуальным}.. )... Да и потом... к Wild Commander надо будет плагин свой "стряпать", чтобы он знал что с файлами графики делать и как в память карты грузить, а в противном случае в каждой проге надо будет лепить модуль, который конфиг компа обрабатывает и держит в себе процедуры работы с HDD, принимая решение по графике. Короче, ТР-ДОС + порты как базовый вариант наверное бы устроил многих, а потом при наличии энтузиазма и времени можно что угодно "кнопить" в асме...
Образ ТРД если только для защищённого диска годится, для обычного диска достаточно иметь просто папку с названием диска, тр-дос имеет доступ только к этой папке, размер папки до 80 или до 256 дорожек. Все старые проги прекрасно будут работать по такой системе и запись будет нормально отрабатываться.
Я не говорил что видюха должна читать файлы :) я говорил что должна быть интегрированная в ТР-ДОС опция по передачи данных в ВИДЕОПАМЯТЬ, а что там будет происходить после, уже проблема видеопроца.
понятно. ты трдос никогда в руках не держал. трдос не знает про винты и другие девайсы. он знает только про дисководы и дискеты и только в своём формате. никаких 80 или 256 дорожек в папке на винте нет и быть не может. почитай про винты и файловые системы (тот же фат16 или фат32). вопросы отпадут сами собой.Цитата:
тр-дос имеет доступ только к этой папке, размер папки до 80 или до 256 дорожек
и ещё не понял прикола про переделку трдоса под видеокарту...
Что зацепились за какой то никому не ведомый трд, нужно нормальные образы юзать vhd к примеру
- - - Добавлено - - -
либы с api можно с C# портировать
Как не держал, а как же демки с параллельной загрузкой, папки на диске тырдос и таблица секторов :)
Я говорю что тырдос надо ДОДЕЛАТЬ для загрузки в видеопамять, что бы можно было ту же картинку с бОльшими цветами или с бОльшим разрешением сразу просматривать на экране.
При чём тут что знает винт а что не знает, он и про FAT ничего не знает, файл всё равно загружается через пзу тырдоса.
- - - Добавлено - - -
Всё правильно он говорит, работа с HDD, Card Reader и всякой шнягой должна быть прописана в пзу, в тырдос уже походу не влезет, надо что-то думать, кидаешь запрос на загрузку и само должно грузить, при чём максимум не 64кБ а как минимум до 16мБ (по 24 бита адрес и длина).