А что мешает хранить в карточке спрайты последовательно вместе с их размерами, находить нужный спрайт по номеру независимо от его размера и размера предыдущих спрайтов и отказаться от команд установки размеров при выводе на экран? Можно использовать в карточке таблицу смещений загруженных спрайтов для ускорения поиска. Для меня это был бы самый лучший вариант. Плюс, сделать команды для вывода окна спрайта.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Коль ужо у вас блиттер, дык сделайте же дисплей лист сто раз задолбался повторять.
Код на микроязыке парсера, который он обрабатывает, начиная с начала фрейма, выгребает последовательно параметры каждого описанного там объекта, пинает соответствующий этому объекту обработчик, передавая ему параметры.
А чтоб милому слоупочному зетнику было удобно апдейтить массивы обжектов, располагать их по удобным адресам, а в конце массива команда а-ля джамп на следующий.
Блин, не делайте еще одно унылое поделие. Сделайте НОРМАЛЬНУЮ архитектуру.
---------- Post added at 04:28 ---------- Previous post was at 04:26 ----------
А, все время забываю спросить - сорцы изделия будут доступны?
Вопрос: управление будет вестись по заданным адресам в пространстве памяти Z80? Т.е. т.н. экранная область ZX48 (начиная с #4000)? Хотелось бы уточнить этот момент, логично перехватывать обращения в новом режиме к карте не по физическим адресам в пространстве ZX48 (#4000-#5aff), а именно обращения к видеостраницам (5 и 7) причем с завязкой на бит 3 порта #7ffd. Т.е. чтоб при поднятом в 1 этом бите управление видеокартой велось бы через включенную страницу 7, чтоб видео память была так сказать теневой со стороны софта. А при опущенном в 0 бите 3 #7ffd управление велось бы через 5ю страницу с проекцией на #4000. таким образом можно высвободить все пространство 64 кб под код. Что не маловажно при написании программ на том же SDCC, язык C не предусматривает фрагментацию кода.Сообщение от zst
Последний раз редактировалось Дмитрий; 26.06.2013 в 13:56.
Вольфы работают без извратов. Можно даже под ось переделать.
---------- Post added at 13:18 ---------- Previous post was at 13:14 ----------
Даже аппаратный. Я опубликовал схему аппаратного мультиколора в 2002 году и с тех пор только я и написал под неё софт. Один. Который и без неё прекрасно работает. Называется Hexagonal Filler.
Поэтому позже я доработал аппаратный мультиколор в цвет на точку а-ля АТМ.
у меня была идея сделать сигнал наподобие IORQGE - только вместо IORQ завести MREQ, вот какие из этого возникают преимущества:
1.в начале включили какой то бит в каком то порту - после чего чтение опкодов и данных происходит по прежнему из памяти зетника, а вот вся запись в память ловится видюхой, и при этом в основную память ничего не пишется, отсюда вытекает что видеопамять можно нарезать по 64к.
2. вся память зетника отведена под код - нет видеобуфера в основной памяти.
можно сделать даже 2 бита под это со всеми комбинациями:
00 - резерв (либо нет записи вообще)
01 - запись только в видеопамять
10 - запись только в основную память (после сброса)
11 - пишем и туда и сюда.
короче маска сигнала MREQ получается ).
Последний раз редактировалось shurik-ua; 26.06.2013 в 14:33.
а вот iar вроде бы имел поддержку страниц...
shurik-ua, V9990 спокойно ловит линейные и прямоугольные блоки данных по OUTI, причём с разными режимами наложения. Удобнее некуда.
---------- Post added at 13:28 ---------- Previous post was at 13:27 ----------
Вступай в NedoPC
это хорошо, но я не совсем о поддержке страниц... а о фрагментации кода до #4000 и после, какой-то из современных компиляторов это умеет? если да, то вопрос отпадает.
Уже сделал прозрачную работу с TAP и TRD на винте и сетевую карту?
Лучше работать вместе. Новый софт должен работать на всём новом железе, а для этого оно должно быть совместимо.
До #4000 ПЗУ и отключать его не все клоны умеют.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
