Ringo Render 64x48

Всем привет!

Сегодня я немного расскажу про то как устроен рендер в нашей совсем недавно вышедшей игре Ringo.
Если вдруг пропустили то посмотреть/поиграть можно здесь

К сожалению исходники настолько запутаны, уплотнены и пестрят ошибочными комментариями из прошлых итераций движка что вряд ли кому-то помогут разобраться. Да и сам я на данный момент уже плохо помню как там и что работает. Но так как уже несколько человек попросили меня рассказать про рендер то я попробую осветить хотя бы базовые моменты которые помогли достигнуть результата.


Читать дальше →

BACK TO THE PET - дневник разработки (часть 1/2)

Написал и выставил на CAFe 2022 полноформатное демо для редкой в наших краях платформы, одного из древнейших персональных компьютеров — Commodore PET 4032. Монохромный текстовый режим 40x25 без возможности загрузки шрифта, никаких аппаратных скроллов, однобитный бипер на выходе последовательного порта, 32 килобайта ОЗУ, в которые помещается все 4 минуты демо без дозагрузок.



На это раз я решил не делать традиционный making of, чтобы его написание не затянулось на год после релиза, с мучительными воспоминаниями о подробностях позапозапрошлого проекта. Вместо этого я в очередной раз попытался вести полноценный дневник разработки, записывая мысли непосредственно в рабочем процессе, и в кои-то веки удалось довести документируемый таким образом проект до завершения. Записи до 06.09 сделаны по памяти, до того момента я ещё не определился, что и в каком формате буду делать. Осторожно: плохо структурированное чтиво эпических размеров.


Читать дальше →

Exact emulation of the Snow effect

At the beginning of this year I promised to publish details of the exact snow effect emulation after publication of a new version of my emulator. Well, I changed my mind, the publication of new version of the emulator is planned later, and the details of the exact snow effect emulation I publish now, along with the update of my emulator Spectramine (1.05), in which the correct emulation of the snow effect was first implemented, and my snow effect tests, which are modifications of the snow test with a tuning table.

The snow effect is caused by the interference of two processes — reading screen data by the ULA and memory regeneration by the processor. Under certain conditions, the bits 6..0 of the register R are picked up in the bits 6..0 of the screen memory address set by the ULA on the address bus. In the course of my research, another effect was revealed, determined by the same reasons. I called it the double effect — under certain conditions, the interference of reading ULA screen data and memory regeneration leads to the fact that ULA cannot read the data of the next bar of pixels, and instead displays a bar of pixels with the data read earlier. This effect is perfectly visible on the ULA128 test written by azesmbog/zebest.

And now the actual results of the research — the necessary information for exact emulation of the snow effect.

A prerequisite for the snow effect: at 16/48/128/+2 machines snow appears if register I contains a value that, if it taken by the high byte of address, points to an address in the slow memory. For Spectrum 16/48 these are addresses #4000..#7FFF, for 128/+2 these are also addresses #C000… #FFFF, if a slow memory page is paged there, for 128/+2 these are pages with odd numbers — 1,3,5,7 (not 0,2,4,6).

There is no snow/double effects on Amstrad's black machines (+2A/+2B/+3/...) and on any ZX Spectrum clones except maybe those that based on original ULA.

Additionally, it turned out that on some 128 machines the snow effect leads to a hang / reset of the computer, and on some — it works ok.

Now about the snow phases. Snow phase means how a 4-tacts operation code fetching cycle overlaps an 8-tacts screen drawing cycle by ULA.

So:
1) If the 4th cycle of the operation code fetching cycle coincides with the 3th cycle of the 8-tacts output cycle of 16 pixels, this leads to snow effect — in the pixels1/attributes1 addresses the bit 6..0 of address is replaced with the current contents of the bits 6..0 of register R (it should already be increased in this operation code fetching cycle).

2) If the 4th cycle of the operation code fetching cycle coincides with the 5th cycle of the 8-tacts output cycle of 16 pixels, then this leads to a double effect — the pixels2/attributes2 data will not be read, and the screen bar with pixels1/attributes1 data will be re-displayed.

3) For the remaining variants of overlapping the operation code fetching cycle with the ULA screen drawing cycle, the ULA works normal, without snow and duplicate.



I express my gratitude to Pheel (Alexander Filyanov) and balford (Brendon Alford), who, at my request, launched my tests on their machines, and shot the results in the videos. Also to NEO_SPECTRUMAN, TheMartian and Guesser, for help with a question of register R's participation in the snow effect.

My emulator Spectramine (1.05) with correct snow can be downloaded here: files.fm/u/r7cymnn9m

Snow tests, the old one and my modifications of it, and ULA128 test:
zx-pk.ru/attachment.php?attachmentid=77971&d=1666205428

Sorry for long wait and bad english)

(Snow.tap test is not entirely correct — under certain conditions there will be no running columns on the screen, which is due to the absence of alignment to the beginning of the frame. Try to load it with pressed Ctrl. Very fast running columns on the screen immediately after loading the tests are caused by an imperfect pause acceleration code between the tape blocks during loading).

TheMartian's addition:
— Pixels and attributes are read in «bursts». First the RAS signal is asserted, and the raw address, (that's bits 6-0 of the video address), are set. Then the CAS signal is asserted twice, setting a column address (bits 13-7) which can point to a pixel byte and its attribute. The first CAS pulse is for the data byte, the second for the attribute, only bits 13-7 change.
— In RFSH cycles MREQ is asserted, and MREQ controls (is) RAS, and since MREQ is low in the first half of T4 it cancels contention, but it proceeds keeping fixed bits 6-0.
— So if it happens on this 3rd pixel cycle T-state, it's the first pixel/attribute burst, the RAS asserted the refresh address, so you get snow.
— If it happens on this 5th pixel cycle T-state, the RAS is kept low between the first and second bursts, so it keeps the bits 6-0 of the video address for the second burst. So, duplicate.
Also: www.zxdesign.info/dynamicRam.shtml

Recommendation for game writers — to avoid the snow effect you need to make sure that the register I does not point to slow memory, and the interrupt vector does not get into the slow memory. It is safer and easiest to place it in addresses $8000… $BFFF (register I within $80… $BF) — on machines with snow it's always fast memory page.

Area 5150 - демо для PC XT/CGA и музыка для PC Speaker

Демогруппы CRTC и Hornet, выпустившие нашумевшее в 2015 году демо 8088 MPH, меняющее представление о возможностях PC XT и CGA, собрались с силами и выпустили своё свежайшее творение на ту же тему — Area 5150. Оно выставлялось на демопати Evoke 2022 и заняло там первое место в категории демо для альтернативных платформ (куда свалено в кучу всё, что не современный PC), обойдя даже весьма креативную работу 420 Years Of Teletext.



Читать дальше →

Немного про чанки на ZX Spectrum (и творчество нашей микро-команды Sage Group)

by Monster^Sage

Что такое чанки можно прочитать здесь (первое, что было найдено по теме на просторах интернета). Мало ли, вдруг эту статью будут читать те, кто не знаком с темой.

Речь пойдет полутоновые чанки и про эффект, который был реализован в “электронной газете” BornDead #05. Точнее про его историю. Как это выглядело можно посмотреть в видео-варианте этого номера газеты. Или для ЛЛ сразу на gif-ке ниже:



На тот момент (более двадцати лет назад, конец 1998 года…), мода на 4x4 чанки была в самом разгаре. Уже вышли такие шедевры, как Shit 4 Brainz, Power Up, Refresh, Forever, а впереди были еще более крутые работы, такие как Napalm, Dogma и т.п. с активным использованием таких чанков.

Конечно же хотелось сделать что-то подобное, но на полноценное демо или добротное интро катастрофически не хватало свободного времени. И одновременно хотелось чем то удивить аудиторию. А иначе какой смысл?

После просмотра эффектов в таком формате постоянно оставалось ощущение, что это слишком медленно, слишком низкий fps, не хватает динамики. 3D эффекты вообще выглядели как “пошаговая стратегия”. Приемлемый fps получался, если рисовали через линию, но выглядело это “темнее” и хуже. Можно рисовать через линию один кадр, только четные линии, а потом следующий – нечетные (интерлейсинг), чтобы получить визуально полноценную картинку. Но в таком случае всё будет “размытым”, эдакий motion blur, что тоже выглядит так себе на динамичных эффектах.

Читать дальше →

Биперные истории

Уже больше десяти лет я плотно занимаюсь темой биперной однобитной музыки на ZX Spectrum и других платформах — все эти движки, трекеры, треки, альбомы и прочие плагины. Всё это время меня постоянно не спрашивают, как же я докатился до жизни такой в эпоху могучих TS, TSFM, NeoGS, мегабайтов и мегагерцев. Но вам всё равно придётся это узнать, потому что это прошлое, в котором мне интересно покопаться и напомнить о нём самому себе, а знакомство с чужой историей нередко позволяет читателям освежить в памяти и их собственные первые впечатления.

Читать дальше →

Обзор архитектуры бортового компьютера КК Аполлон

Решил копнуть в историческую историю и рассмотреть архитектуру и систему команд бортового компьютера космического корабля Аполлон.
Последний пока компьютер который летал на Луну вместе с людьми. Сокращённо он называется AGC (Apollo Guidance Computer).
Было два поколения его — Block I и Block II. Второе было существенной доработкой первого и именно оно летало на Луну, поэтому рассматривать буду только его.

Читать дальше →

Famicom/NES/Денди: битва за Status Bar

На Famicom/NES/Денди было одно сильно аукнувшееся гейм–девелоперам упрощение/удешевление — вместо четырёх экранных областей объёмом 4Кб выстроенных квадратом между которыми был возможен бесшовный скроллинг (с прокруткой) в консоли оставили только 2Кб VRAM и, таким образом, было только две экранных области с бесшовным скроллингом.
Т.е. виртуальный задний фон мог бы иметь такую раскладку:

(глубже теорию вопроса можно изучить в статье про графическую архитектуру Famicom/NES)
Но в итоге оставались только две эффективных области из этих четырёх. Причём коммутацией линий картриджа их можно было выстроить как вертикально так и горизонтально (оставшиеся области «зеркалились»). Таким образом чисто вертикальные или чисто горизонтальные скроллеры реализовывались легко из коробки, но с произвольным скроллингом возникал целый ряд проблем которые решали кто как.

Читать дальше →