а они (биосы) это используют ?Цитата:
Сообщение от PPC
а то в Корвете и ром это использует (настраивает параметры)
и биосы cp/m честно читают и настраивают контроллер.
микродосы как раз не все.
Вид для печати
а они (биосы) это используют ?Цитата:
Сообщение от PPC
а то в Корвете и ром это использует (настраивает параметры)
и биосы cp/m честно читают и настраивают контроллер.
микродосы как раз не все.
В биосах, которые шли с МикроДОС 3.1 было ЕМНИП жёстко прошито 80 дорог 5 секторов 2 стороны.Цитата:
Сообщение от esl
Но я знаю один биос, который и читает и настраивает. Патамучта кгхм... писал его я и ISA :-)
Биос сохранился, а вот сырки-нет. Это год 92-93й где-то был.
Вдогонку: биос называется Bold BIOS 3.что-то. В роботах на .fdd тоже Bold BIOS, но не тот, а ver.2.0, потому что 3.x мы не довели, но как раз с ВГ93 вроде всё доделали.
Внесу свою лепту в начавшийся оффтоп.
Давно интересовал вопрос - почему плагин для фара (автор FANSoft) видит все файлы на образах, а плагин для WC/TC (автор Error404) иногда не видит файлы в юзерах кроме 0го. Да, плагин Errora для ориона, не для вектора, но в чем разница?
Плагин для фары тоже не всегда видит все файлы, даже в нулевом юзвере.
Интересно, что и в самом МикроДОСе 3 известные мне варианта утилиты dir бывает пропускают файлы, причём разные. С dir можно погрешить на find first/next хоть для каких-то имплементаций, но похоже, это-только следствие. Хоть бери и пиши собственный dir с чтением области директории. Удивительно, но встроенная команда "D", похоже всегда видит все файлы как и power. Проблема с юзерами кроме нулевого, возможно того-же рода, что бага в CP/M, перекочевавшая и в МикроДОС, когда файл больше экстента не в нулевом юзвере при чтении сообщается в FCB как занимающий один экстент.
У роботов теперь есть svn репозиторий:
http://robotz.googlecode.com/svn/
Кому интересны сырки (их есть), забирайте в удовольствие:
svn checkout http://robotz.googlecode.com/svn/ robotz-read-only
Wiki страничек пока нету, это следующий этап. Вкратце для тех, кому интересно покопаться в сырках:
Весь код намеренно в досовской кодировке. В /tools/cross/win32/codepage лежит всё необходимое для поддержки кодировки и перекодирования в Векторовский КОИ-8 и обратно.
В /tools/cross/win32/CEdit/ лежат файлы для поддержки syntax hiliting для ассемблера i8080 в редакторе Crimson Editor.
В /bin лежат скрученные 7-zipom CP/M тулы для компиляции из DOSbox через CPM->DOS утилиту 22nice. На 32-битных процах 22nice можно пускать без ДОС бокса, прямо с командной строки.
NB!
1. Роботам нужна библиотека GML. Построенный объектный файл лежит в /Robotz/GML.REL, исходники и include файлы - в каталоге /GML.
Для компиляции роботов каталог /GML должен быть размечен (в DOSBox) как диск A. Проще всего это сделать, запустив файл setenv.bat из каталога /Robotz сразу после запуска ДОС бокса.
2. Сама библиотека GML из под 22nice построится с ошибками. Её можно строить только под МикроДОС или CP/M в эмуле или на реале.
Мини-апргейд для версии 0.56
http://robotz.googlecode.com/svn/trunk/updates/
Ради интереса, попробовал реализовать идею SES: полуэкранный 8-цветный дабл-буфферинг, озвученную ivagor-ом в этом посте.
Подкрячил сегодня рендерер. Да, получилось 8 цветов без мырганья, но стало заметно медленней. Настолько, что медлительность скролла начинает серьёзно добивать. Если убрать полупрозрачные оверлеи поверх тайлмапа, то терпимо, но с ними уйдёт туча эффектов (субтайловые спрайты, стёкла, передний план).
Всё-таки для динамических игр со скроллом на Векторе такой подход вряд-ли годится, а вот для стратегий - возможно применим.
Мне кажется, что нечто эксолоноподобное в таком режиме вполне реализуемо
а можно подробностей немного про этот режим, а то не понятно вне контекста вектор ...Цитата:
Сообщение от PPC
Попробую. Правда, я не лучший объяснятель, но всё-же. Если что, спрашивайте, да и ivagor тут рядом.Цитата:
Сообщение от esl
Дальше - не реклама ;)
Видеоадаптер Вектора-06ц/06ц-02 (существенные для эффекта вещи):
- 256-цветная палитра из 332 цветового пространства
- аппаратный вертикальный скроллинг на произвольное количество строк
- 4 видеоплоскости по 8К каждая
- 2 видеорежима, высокого и низкого разрешения.
В режиме низкого разрешения, цвет пиксела на экране формируется как значения битов в плоскостях с координатами пиксела. Единичные биты в соответствующих плоскостях дают весовые коэффициенты 8,4,2,1, что приводит к 16 возможным комбинациям. Очень похоже на EGA.
При использовании всех 4х плоскостей это позволяет выводить до 2^4 = 16 из 256 различных цветов одновременно, простым программированием палитры (2х-байтовый регистр-секвенсор: номер цвета, значение и так 16 раз).
Количество цветов на экране можно уменьшать тем-же программированием палитры. Скажем, если в палитру запихнуть следующие 16 цветов, то получится 8-цветный режим:
100 101 102 103 104 105 106 107 100 100 100 100 100 100 100 100
При этом видео плоскость с весовым коэффициентом 8 может быть использована как обычный RAM (маскирование цветом).
Идея состоит в следующем: 3 плоскости отводятся под изображение.
Экран делится пополам по горизонтали. Изображение будет в пол-экрана высотой и на всю ширину.
Одна плоскость отводится под "полумаску": в ней рисуется прямоугольник на всю ширину и половину высоты экрана.
Палитра перепрограммируется каждый кадр таким образом, чтобы получилось 8 цветов, но половина экрана (верх или низ) всегда была замаскирована цветом. Скажем, если под маску выбрана плоскость с цветовым весом 8, то вторая палитра к 3-х цветному примеру выше, будет выглядеть как
100 100 100 100 100 100 100 100 100 101 102 103 104 105 106 107
Отрисовка всегда идёт в замаскированную цветом половину экрана. В это время на экране "размаскированное" изображение. По окончанию отрисовки кадра, выполняется перепрограммирование палитры и аппаратный скроллинг экрана на пол высоты. Profit. Полуэкранный 8-цветный double video frame buffer.
Уфф :). Надеюсь, не затуманил ещё больше.
В принципе, код я не потёр ещё, и могу завести в репозитории branch и кинуть туда для изучения, если хотите. Все основные изменения - в файле SLR.mac (SLR - это Sprite Level Renderer, a не Single Lens Reflex ;) ). Простое сравнение в каком-нить WinMerge всё покажет лучше 1000 слов. Заливать?
---------- Post added at 20:20 ---------- Previous post was at 20:12 ----------
ivagor, да, согласен, но там ведь нет скроллинга, как такового. Только чтобы спрайты не мерцали, наверное.Цитата:
Сообщение от ivagor
Но всё-таки стратегия будет сиять в этом режиме. Там скорость скроллинга не так важна, как отсутствие мерцания. Самое то вроде.
Ну будет fps в районе 6-8, ведь не смертельно. Зато - субтайловые оверлеи на все 8 цветов и абсолютно без мырганья... эх, красота ведь!
Похоже под стратегиями ты в первую очередь имеешь ввиду rts, но, например, для civilization можно обойтись и без буферизации и использовать все 16 цветов. Если не считать отсутствия программистов есть еще небольшое техническое препятствие - отсутствие нормального стандартного способа подключения мышки. Хотя, конечно, можно и без мышки
Не обязательно real time, хотя в первую очередь их. Бывают и "пошаговые" стратегии со скроллом, им тоже совсем ведь не помешает отсутствие мырганья. Мышь, мне кажется, куда меньшая проблема чем, "отсутствие программистов". В конце концов, она решаемая. Либо отдельной платой, либо 8259 на какой нибудь из IRL. Ну а программисты-это да. Вряд-ли кто-то будет сейчас учить всю Векторовскую тряхомудию. Мне просто нравится Вектор. Он няшный в смысле программания, да и от работы отдыхаешь после чудовищных микроконтроллеров. Поэтому и балуюсь. Когда время свободное есть. А его мало, увы.
Хотя, конечно, было бы приятно, если бы появлялись новоделы. Железо и муляторы-это замечательно, но без софта-увы.
Для цивы вполне подошел бы незамысловатый скролл по типу болдера. В идеальном мире лучше с буферизацией, но для многих применений (если без промежуточного стирания или восстановления фона, например под спрайтами) сойдет и простая перерисовка отличающихся тайлов. Кстати, я не интересовался, сколько занимают тайлы цивы, может в 16 цветном варианте они и не влезут (наряду с картой и всем остальным) в стандартный квазидиск, хотя тут может помочь и простейшее кеширование. Ну и немного провокативности - двумерные движки это хорошо, но трехмерные круче (хотя и не всегда) :)
---------- Post added at 09:11 ---------- Previous post was at 09:03 ----------
И еще у меня что-то типа дежа вю, вроде мы уже это обсуждали :)
Цива, сим сити, Europe in Flames (она вообще пошаговая и гексагонная), Дюна, Warcraft... жанр разработан, было-б только желание да время.
Да, уже обсуждали и мышей и rts и программистов :)
Но раз Гондурас так беспокоит, это означает, что он вызревает ;)
Кстати, кроме мышей и программистов, с Вектором есть ещё одна проблема: как показывает мой скромный опыт, она куда серьёзнее, чем мне представлялось поначалу. Очень скуден выбор средств разработки и обработки. Изображений, музыки, спец-эффектов. В какой-то малой мере, я, возможно, улучшил ситуацию. Но, как показала практика, на разработку средств разработки зачастую уходила половина времени разработки. Каламбур в стиле поручика Ржевского :)
Проблема в том, что Вектор очень "специфичен". Огромная видеопамять по меркам 8-битной машинки, обилие периферии и чертовски медленный процессор. Как у Киплинга-черепаха Неспешная :).
Поэтому битмапы надо "готовить", за звук бороться и т.д. и т.п. А на всё это нужен тулкит. Стандартным фотожопом и вав-редактором дело не заканчивается.
Плюс, даже библиотек нормальных не было. Вот поэтому, в том числе, я и отделил половину роботов в отдельную библиотечку.
Насчёт размеров. Да влезет, я думаю. В роботах вон картинки по 24К без сжатия хранятся в дополнение к текстурам тайлов, оверлейных альфа-текстур и спрайтов. Да ещё 2 фонта, один из которых-по 2 битмапа на букву. Влезет, ну и подкачку с диска замутить дело теперь нехитрое.
Насчёт 3х мерных, а точнее-псевдо 3х мерных движков.... ты как в воду глядишь :)
Третий день читаю про raycasting. Встречно-провокативное: у нас есть оптимизированный тобой амбал 3д, но ему, мне кажется, пошло бы к лицу текстурирование, bumpmapping и фильтры для освещения. Как ambient, так и texture-shaded. Только вот удастся ли со всем этим взлететь на 3х мегагерцах? А так-да, трёхмерные безусловно круче.
Амбал3D это вдохновляющий пример, но ошибка со щелями в стенах портит впечатление. Судя по еще одному примеру (только со спектрума) - wolf3d 48 - текстурированный рейкастинг на векторе вполне возможен (в эмуляторе спектрума Фролова работает, на 580ВМ80 будет медленнее, но думаю не хуже чем в 1,5 раза, если постараться). Насчет дальнейших наворотов - разве что для маленьких картинок и на скорости в 1-2 fps. Но интересно было бы взглянуть
Еще и векторное 3d было бы неплохо, тем более линии можно сделать разноцветные. Только программирование для 580ВМ80 меня сейчас не соблазняет
Да, там жёлтым бъёт при определённых углах как серпом. Я прочёл и перевариваю уже 3ю статью про raycasting. В какой-то было и про арктангенс и про ошибки со щелями из-за устранения анизотропии косинусом.
Векторное 3d будет чудовищно медленным при более-менее сносном количестве вертексов. На Векторе есть starwars, но там очень примитивные wireframes. Я тут на днях игрался со скоростной линией по Брезенхейму на одну плоскость. Выложено в GML/graph/LinBPP.mac Уверен, что её можно ускорить. Если заинтриговало, погляди.
Да, ты вроде с головой ушёл в digital design. Это само по себе тоже неплохо, но позволю процитировать: "программистов нет", а новые, думаю вряд ли появятся. Я просто констатирую. ;)
Желтым заметнее, но там в зависимости от места и синее просвечивает и красное
По поводу честного 3d. Star wars я как раз вспомнил и отсутствующую на векторе элиту. На текстурированные треугольники вряд ли хватит скорости (хотя в какой-нибудь демке интересно было бы посмотреть), а на вектора бы скорости хватило
Насчет "ушел с головой" в околоплисовость - тут совпало, что и мне интересно и для работы полезно. А наработки для ВМ80, к сожалению, проблематично использовать на работе
И насчет программистов - все же нельзя полностью исключить, что кто-то (еще кроме тебя :) ) из активно программивших для вектора в конце 80х - 90х захочет тряхнуть стариной
Я прикидывал насчёт векторной графики. В среднем по больнице, быстрый вывод произвольной линией в пол длины экрана по Брезенхейму даёт около 200 линий в секунду. Собственно, там в файле LinBPP.mac есть растактовка, и из неё получается, что уже один порядок с физическим пределом-просто записью в видеопамять. Возможно, вывод можно ещё ускорить сменив алгоритм. Скажем, в 2 раза (я бы поглядел за счёт чего, но допустим). Итого при 20fps получится 20 линий на кадр, если ничего больше не делать. IMHO для полноценного игрового 3д такого недостаточно. Дему можно замутить с предварительно обсчитанными координатами. Повторять элиту, когда есть уже starwars с похожим количеством полигонов смысла мне кажется не очень много.
Ну а насчёт кого-то из 80х-90х, было бы здорово, конечно. Те, с кем я встречался, были в восторге от того, что есть эмули и всё такое, но потом честно признавались: "ничего не помню" :).
Посему, мне кажется, что если тебе реально "хотелось бы посмотреть", то просто надо сесть и сделать. Как там у svofski ... "больше игр нет". Только теперь это можно сказать и про программеров :)
По элите количественных оценок сам я не делал, но рассуждаю так - спектрум несколько быстрее вектора, но по словам Кладова, в спековской элите многое оптимизируемо. Правда он использовал выигрыш для нововведений, а можно просто ускорить. Star wars хорошо, что есть на векторе, но с элитой не сравнить
Сесть и сделать - все зависит от текущего соотношения между ленью и желанием что-то посмотреть (сделать). Локальные нарушения равновесия в пользу сделать вполне возможны
Перед тем, как приступить к тотальной перекройке рендерера на субтайловый режим, профиксил за выходные всё, что не нравилось, и выкладнываю новую версию 0.58. Floppy disk image и список внесёных изменений в 1м сообщении этой ветки.
Для тракинга истории changelog 2х предыдущих версий перемещён сюда.
------------------
v. 0.56a 01.07.2014
------------------
Добавлено:
1. Звуковые эффекты и визуальные эффекты полупрозрачности в меню опций
2. Дополнительные звуковые эффекты на события в игре
3. 2-bit 9kHz звуковой DAC драйвер для воспроизведения вокала на i8253
4. 2-bit 9kHz звуковой DAC драйвер для воспроизведения вокала на Сovox
5. Инсталляционный скрипт
Изменено:
1. Изображение заднего плана в меню опций на "The Guardian" by Nikolai Nazarov
2. Цвета палитры в главном меню на оттенки серого
3. Цвета в меню "Read This"
Теперь в игре есть инсталляционный скрипт install.sub, который запускается автоматически при первой загрузке с диска и устанавливает драйвера, настраивает меню опций и кое-что ещё. При успешной инсталляции скрипт запустит игру и всё должно работать. По умолчанию ставятся следующие драйвера:
1. Sound Effects - через i8253
2. Vocal Sound в заставке 2-bit 9kHz DAC driver для i8253.
возможные альтернативы:
1-bit 7kHz DAC sound driver через бипер
2-bit 9kHz DAC driver для Covox
3. Background Sound - STM через плату Sound Tracker
возможные альтернативы:
Background Sound - STM через плату R-Sound 2
Для того чтобы поменять драйвера на альтернативные, нужно отредактировать инсталляционный файл install.sub, раскомментарив соответствующие строчки, сохранить файл и запустить его из командной строки MicroDOS следующим образом:
a:<install.sub
------------------
v. 0.57a 02.17.2015
------------------
Изменено:
1. Звуковые драйверы загружаются многоцветным шрифтом, ядро игры - нормальным
2. Файлы с вокалом переименованы в boot.sd1 и boot.sd2
Добавлено:
1. Драйвер многоцветного шрифта
2. Для вокальных драйверов, полосы на бордюре промодулированы дополнительным набором полос поверх с разной шириной и цветом в зависимости от громкости звуковой дорожки.
Мелкая имха по поводу темпов музыки - самые быстрые как-то уж очень-очень быстры
На самом деле, опции, управляющей темпом там быть вообще не должно. Это опция-временный костыль, за который мне в общем-то стыдно, о чём я недвусмысленно написал в комментах к этому куску ;) кода.Цитата:
Сообщение от ivagor
В зависимости от сложности уровня, (геометрия, количество обрабатываемых событий, etc.), время на рендеринг картинки уходит разное. На самом деле, разные фреймы также занимают не одинаковое время: в каких-то фреймах обрабатываются включившиеся по триггерам события, или просто есть вывод тайлов переднего плана с альфа каналом (дорогое удовольствие). Кроме этого, нужно ещё учитывать тип процессора и тактовую частоту. Всё бежит неуклюже с запрещёнными прерываниями.
Я делал вариант, который бежит, в основном, с разрешёнными прерываниями, но управление их разрешением и запрещением отнимает драгоценные такты. Ясно, что когда идёт вывод тайла стеком из банка, прерывания нужно запретить, потом - снова разрешить так как к этому времени, вполне может натикать interrupt request. Потом-снова запретить для следующего тайла, и так - до бесконечности. В общем, кадр в секунду на этом теряется так как мест, где это надо делать за фрейм набегает много :). В принципе, я оставил возможность к такому варианту вернуться: в коде библиотеки GML есть такой conditional O_DION, и надо просто поглядеть, где он используется для разрешения прерываний.
Канал таймера, как в порте Exolon, мне терять было жаль: звуковые эффекты на таймере и так бедноваты, а с двумя каналами, будет ещё хуже.
Видится вот такой более-менее сносный вариант: при старте уровня, проверить, используется ли таймер каким-нибудь из драйверов (сейчас это SFX драйвер), и временно, этот драйвер вырубить на некоторое количество фреймов, чтобы дать возможность рендереру пробежать с разными кадрами. За время пробега, измерить, сколько "абстрактных тайлов" укладывается в прерывание с учётом обработки событий, триггеров и отрисовки оверлеев/спрайтов. Это среднее использовать как счётчик тайлов при выводе. Ясно, что это-средняя температура по больнице (какой-нибудь спрайт с NPC, или большой оверлей внесёт тормоза), но пока лучшей идеи у меня нет.
Заниматься этим всем мне не очень хотелось, поэтому просто вставил примитивный костыль с задержками (которые ешё и криво работают при смене CPU или тактовой частоты). Пока могу ввести понятие нижней границы в опцию меню с диапазоном, хотя, особо не очень хочется вот именно этим заниматься сейчас.
PPC, а если использовать метод Медноногова в работе с прерываниями?
Можно чуть раскрыть, в чём суть метода?Цитата:
Сообщение от jerri
при выводе спрайтов через стек пара ВСЦитата:
Сообщение от PPC
через которую рисуем должна всегда соответствовать содержимому стека
единственное я смутно представляю работу прерываний на Векторе.
и текст дам в z80 кодировке
итак работа со спрайтами
грубо говоря берем простейший вывод спрайта
через стек
если внезапно придет прерывание то спрайт будет испорченКод:;hl адрес спрайта
;de координата
ld (ret_sp0),sp
ld sp,hl
ex de,hl
pop de
ld (hl),e
inc h
ld (hl),d
...
pop de
ld (hl),e
inc h
ld (hl),d
ld sp,$
retsp equ $-2
ret
теперь даже в случае прихода прерывания искажений спрайта уже не будетКод:;вот это вешаем на прерывание
ISR_sub
di
ex (sp),hl ;обмениваем вершину стека и содержимое HL
ld (imm_jp),hl
pop hl ;заменяем испорченное слово спрайта
push bc ;на текущее слово находящееся в BC
ld (imm_sp),sp
ld sp,ISR_sp
;здесь идет обработка прерывания
; ...
;----------------------------------
ld sp,$
imm_sp equ $-2
ei
jp $
imm_jp equ $-2
;теперь немного меняем процедуру рисования спрайта
;hl адрес спрайта
;de координата
ld (ret_sp0),sp
ld c,(hl)
inc hl
ld b,(hl)
inc hl
ld sp,hl
ex de,hl
ld (hl),c
inc h
ld (hl),b
...
pop bc
ld (hl),c
inc h
ld (hl),b
ld sp,$
retsp equ $-2
ret
Там обычное кадровое прерывание. Приходит 50 раз в секунду, если прерывания разрешены.Цитата:
Сообщение от jerri
Спасибо за пример. Подход понятен, но вот так в лоб он на Векторе (в роботах) работать не будет, и свалится вот из-за этого кода:
Дело в том, что спрайт (тайл) не лежит в основном ОЗУ Вектора. Он - в одном из 64К банков квазидиска. Доступ туда довольно хитрый: стековые команды типа push, pop, ex (sp),hl работают с памятью квазидиска, в то время как ld reg,(hl) будет работать с основным ОЗУ. Поэтому в <BC> будет значение из ОЗУ, а не из банка памяти.Код:ld c,(hl)
inc hl
ld b,(hl)
Кроме того, прерывание (в общем случае) выполняется с отключёнными банками, в то время как выход из него должен вернуть назад режим адресации соответствующего банка, из которого читается спрайт. Увы, регистра статуса включённого банка в Векторе нет. Есть только регистр управления включения доступа к банку, и чтение из него запрещено. Криволапо в общем. Хотя это всё решаемо.
В принципе - спасибки, подход навеял на некоторые размышления. Просто вот так, в лоб не выйдет :).
Очевидное (тупое) решение - запретить прерывания на время задания стека на исходник спрайта (в КД), т.е. EI будет перед первым POP читающим данные спрайта. Наверно можно как-то изящнее
---------- Post added at 17:36 ---------- Previous post was at 17:20 ----------
Кстати, с адаптером z80 Фролова спековский вариант можно использовать практически дословно, т.к. он может читать из КД через ld r,(hl)
---------- Post added at 17:55 ---------- Previous post was at 17:36 ----------
Или так: при старте уровня "закешировать" в основном озу по 2 первых байта из всех актуальных для уровня спрайтов
ну есть шанс потерять прерывание...Цитата:
Сообщение от ivagor
а так да
Код:di
ld sp,hl
pop bc
ei
а что за квази диск из которого такие трудности?Цитата:
Кстати, с адаптером z80 Фролова спековский вариант можно использовать практически дословно, т.к. он может читать из КД через ld r,(hl)
ei можно поставить перед pop bc, ухода на обработчик прерывания после ei не будет. Но вариант с "кешированием" еще лучше (если хватит места в основном озу).Цитата:
Сообщение от jerri
Квазидиск (или электронный диск, как его в основном называли авторы) - дополнительное озу на 256 Кб, из которых часть доступна обычным образом, а полностью - через стековые операции.
Тогда приходим к тому, с чем боремся - по паре di/ei на вывод тайла :)Цитата:
Сообщение от ivagor
На самом деле, я сейчас поглядел на код, и вижу, что при запрещённых прерываниях, можно выкинуть переключения квазидиска туда-сюда на выводе каждого тайла. Там вся бодяга из-за каких-то 2х пар push/pop во внешнем цикле вывода во вьюпорт. На стеке хранится начало тайлмапа и координата тайла в видео ОЗУ. Само переключение - это 40 тактов, плюс push/pop дважды - ещё 48 (на Векторе). Итого 88. Можно в 68 всё уложить, если использовать ячейки памяти. Это 20 тактов экономии на тайл. Но всяко с запрещёнными прерываниями.
Тогда надо иметь 2 рендерера и определять, какой адаптер квазидиска установлен. Совместимость со "стандартным" Кишинёвским адаптером я терять не хочу. В общем-то, такое обдумывалось.Цитата:
Сообщение от ivagor
Кстати не такая уж и плохая идея на самом деле. Изящно. Может получиться. Правда, "актуальных для уровня спрайтов" там 512 только для тайлов (задний и передний планы уровня) плюс спрайты. Легко пара килобайт выходит.Цитата:
Сообщение от ivagor
Да, но длительность нахождения в режиме с запретом прерываний при таком подходе все же значительно меньше, соответственно намного меньше и вероятность пропуска прерыванияЦитата:
Сообщение от PPC
В глобальной картине "мира" роботов, применительно к выплёвыванию во вьюпорт и неравномерностью саунд трека, это будут копейки по сравнению с тем, как сейчас :)
В общем, пищи для размышлений достаточно. Если кто-то хочет поучаствовать, глядеть надоть на процедуру с меткой Render: в прикреплённом файле (кодировка 866, ДОС-овская).
тогда да
вот такой вариант
Код:
;hl адрес спрайта+2
;bc первая пара спрайтов (а что делать если урезание будет)
ld (ret_sp0),sp
ld sp,hl
ex de,hl
ld (hl),c
inc h
ld (hl),b
...
pop bc
ld (hl),c
inc h
ld (hl),b
ld sp,$
retsp equ $-2
ret
Если в основной памяти нет места под "кеш" начала спрайтов/тайлов, то можно так: "кеш" (в данном случае скорее резерв) хранить в КД, при выводе спрайта/тайла прерывание не запрещать, а в обработчике прерывания проверять sp. Если sp "неудачный", то восстановить начало спрайта из резерва. Очевидный недостаток - обработчик прерывания немного распухнет и замедлится.
UPD: Непринципиальная поправка - в данном случае восстанавливать из резерва придется не начало текущего спрайта, а конец предыдущего.
не....Цитата:
Сообщение от ivagor
концепт неверный
со спрайтами работаем по методе Медноногова
но после каждого спрайта держим 2 байта пустых.
чтобы при установке при приходе прерывания в этом месте
чтобы испорченная пара байтов не принадлежала спрайтуКод:ld sp,hl
pop bc
так вобще хорошо! Незначительное увеличение сложности расчета адреса спрайта, зато обработчик прерывания можно упроститьЦитата:
Сообщение от jerri
В общем, мне кажется, что проще всего на момент вывода во вьюпорт подменять ISR на специальный вариант, использующий память вместо стека для сохранения вообще всех регистров, затем - выключить квазидиск, переключиться на свой локальный стек. А по концу ISR просто восстанавливать все регистры и режим КД и делать jmp, как выше.
По окончании вывода во вьюпорт - вернуть на вектор ISR7 нормальную ISR.
Тогда не надо делать промежутки между спрайтами.
Как-то так:
Можно вместо IsLastWord использовать факт, что тайлы выводятся на совершенно определённые адреса видеопамяти, и анализировать регистр <L>Код:di
shld TheHL
lda IsLastWord
jnz skipRestore
pop h
push b
SkipRestore:lxi h,0
dad sp
shld TheSP
lxi h,0
dad d
...
DB (lxi)
TheHL: DW 0
...
PPC, мне кажется ты вчера помнил, а сейчас как-то забыл (работа наверно влияет) про запись в стек текущего адреса при начале обработки прерывания.
Так я вроде запорченный спрайт восстанавливаю. Просто если SP уже переключен, то этого делать не надо. А в качестве индикатора, надо ли восстанавливать стек, можно использовать в ISR, скажем, значение старшего байта <SP>. Или что-то не так?Цитата:
Сообщение от ivagor