SCENEgraphy 01/2024

SCENEgraphy

Представленный на демопати DiHalt 2024 электронный журнал для ZX Spectrum «**/?\**» и доступный для прочтения только на реальных компьютерах и эмуляторах теперь доступен в печатном виде. Если вы всё ещё не удосужились загрузить журнал на своём любимом ZX Spectrum и почитать от души, то возможно, в электронном виде печатного издания вам это будет сделать удобнее.

В публичный доступ журнал вышел 9 января 2024 года и вот, 20 января 2024 я представляю вам его «печатную» версию.

Это всего лишь моя интерпретация «печатного» издания, в том виде в котором лично я его вижу. Буду рад, если такой вид журнала кому-то тоже будет полезен.

SCENEgraphy 01/2024

VS Code: Запуск Unreal по F5

Хотелка


Хочется компилить и отлаживать в Unreal Spectrum проекты для Спектрума в Visual Studio Code тем же хоткеем, который я использую для других языков.

Проблема


Я давно освоил Visual Studio Code и использую ее, например, для проектов на Python. При этом все мои проекты для Спектрума жили в Sublime Text с расширением Z80Asm от Breeze, и я решил смигрировать их в более привычный VS Code.

В VS Code есть понятие Build Task, позволяющее запустить только компиляцию workspace (и, вообще говоря, выполнить любую команду shell) и отдельно debugger'ы, свои для каждого типа workspace. Если для языка установлено отладочное расширение, то по F5 (у меня клавиатурная тема от MSVS) workspace компилится при наличии изменений, и сборка запускается в отладчике. А запускать вместо отладчика команду shell (и Unreal Spectrum) нельзя, нужно отладочное расширение. Итого: для Python использую F5, для Z80 — Shift+Ctrl+B, и постоянно путаю их.

Чуть подробнее

Для разработки на Z80 есть расширение Z80 Macro-Assembler, которое понимает синтаксис Z80 и имеет еще всяческие фишки (подробнее про это писал камрад sq в статье Как быстро настроить среду разработки на ZX: Visual Studio Code + Z80MacroAsm boilerplate). Однако расширения, позволяющего запускать Unreal Spectrum в качестве отладчика нет.
Переопределить шоткат F5 для проекта невозможно, глобально переопределить его на Build Task — тоже не выход, потому что оно тогда будет так работать и для всех остальных языков.
Надо сделать как-то так, чтобы для workspace Z80 F5 вызывал Build Task, в котором можно выполнить команду shell и запустить что хочется, а для других проектов поведение оставалось прежним: компиляция (если есть) и запуск отладчика из расширение.

На просторах Интернета накопал способ переопределить шоткат для проекта, которым на всякий случай делюсь. Суть способа такая:
  • пользовательские шоткаты переопределяют системные, при этом, если условие when для пользовательского шотката не выполнено, то работает штатный шоткат из клавиатурной схемы;
  • условие вычисляемое, в нем можно использовать настройки, в том числе, и уровня проекта;
  • суть решения: добавляем в проект некоторую кастомную настройку, наличие которой является условием пользовательского шотката на запуск Build Task, а при ее отсутствии работает штатный шоткат VS Code для запуска дебаггера.


Инструкция


  1. Нажать Shift+Crtl+B (или ваш шоткат для билда) чтобы появилось предложение создать tasks.json. Если дефолтные таски в конфигах самой VS Code уже есть, то, по Вашему вкусу, можно либо добавлять новые таски туда, либо создать в проекте файл .vscode/tasks.json.
  2. Вставить в tasks.json пример сборочных тасков из справки extension'а Z80 Macro-Assembler и настроить его на свой вкус. Для настройки шотката интересен только параметр label. Назовем его, например, Compile and run. В параметр command пишется shell-команда, которую хотим прикрутить к шоткату
  3. Нажать Shift+Ctrl+P (или ваш шоткат для поиска команд) и выполнить Preferences: Open workspace settings (JSON). Добавить в него параметр
  4. "runTaskInsteadOfDebug": true
  5. Нажать Shift+Ctrl+P (или ваш шоткат для поиска команд) и выполнить Preferences: Open Keyboard Shortcuts (JSON). Добавить в него:
    
            {
                "key": "f5",
                "command": "workbench.action.tasks.runTask",
                "when": "config.runTaskInsteadOfDebug && taskCommandsRegistered",
                "args": "Compile and run"
            }
        

  6. Собственно, все. Теперь в проектах, в которых есть .vscode/settings.json с параметром «runTaskInsteadOfDebug»: true, по кнопке F5 будет вызываться таск с именем Compile and run, а в проектах без этой опции — отладчик по умолчанию для workspace.Например, я себе в проектах Saboteur сделал по F5 сборку и запуск отладочной версии, по Ctrl+F5 — релизной, а по Shift+F5 — только компиляцию без запуска.

shuran33 interviews Beaver

Друзья, всем большой привет! Что-то давно не выкладывал статьи-интервью с художниками, буду исправляться. В январе 2023 года в окрестностях Нижнего Новгорода на демопати DiHalt я обратил внимание на работу неизвестного мне автора, чей стиль рисования мне очень приглянулся. Для себя сделал пометочку, что обязательно нужно разобраться кто он, откуда? И вот у меня выдалось немного свободного времени и я решил его разыскать, а потом взять интервью.



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

Обзоры и оценки жюри, а также результаты zxgfx compo #7



Публикую обзоры жюри и оценки на графические работы zxgfx compo #7. Результаты в конце статьи. В этот раз оценка работ проводилась не зрителями, а жюри из числа вызвавшихся членов канала @zxgfx. При этом условие было только одно — в жюри может быть тот, кто не нарисовал на компо. Наверное этим и объясняется такой баланс количества участников конкурса и жюри — 3 участника (8 работ) и 9 человек жюри. Но, надо сказть, быть в жюри оказалось не проще. Дело даже не в оценивании и написании обзора. На это у каждого ушел наверное просто 1 вечер. Проблема жюри — больше в обсуждении выставленных оценок и подходов к оцениванию.

Все началось достаточно легко. Создали отдельный telegram-канал для жюри. Кто-то спросил «как оцениваем», я с ходу предложил — давайте оценим по трем критериям:
1. Соответствие условиям конкурса
2. Техника
3. Оригинальность/общее впечатление от работы.
Бросил и забыл. Обсуждения критериев не было, потом один за другим посыпались обзоры. Понятное дело, никто не читал обзоры друг друга, чтобы они не повлияли на собственные. В результате мы получили следующее:
Я сам решил отказаться от первого критерия. Двое жюри последовали моему примеру. А Schafft просто выбрал другие, на самом деле, более интересные критерии. Это все произошло абсолютно независимо и без какого-либо обсуждения.

Что мы получили в итоге — текстовая часть без претензий, мнения всех членов жюри. А вот цифровые оценки — … Вот тут-то мы и поимели некоторое обсуждение, или оно нас. Закончилось тем, что все же большинством членов жюри мы решили, что первый критерий (Соответствие условиям конкурса), во-первых, не может иметь балльную оценку, а во-вторых, является слишком формальным и применять его не следует, поскольку большинство считает все работы соответствующими теме конкурса («Пейзаж»). Поэтому решено было отбросить первый критерий и оценки посчитать на основе оставшихся — среднее по каждому жюри (кроме sq, у него уже стояла авторская общая оценка, не равная среднему отдельных компонент). Ну и общие результаты также по среднему баллу.

Что получилось…
Читать дальше →
  • avatar
  • [просмотров: 2425]
  • 0
  • +35

Первый ZX Spectrum в 2021. Часть 0.

Так сложилось, что ZX Spectrum'a у меня раньше никогда не было. Еще учась в школе, я с БК-0010 сразу «перепрыгнул» на x86 (Robotron, Amstrad, далее — везде). Поэтому в то время, когда на территории exUSSR бушевала популярность ZX, у меня дома уже были довольно актуальные тайванские 286/386/486/etc и на их фоне ZX меня абсолютно не впечатлил, как, впрочем, и 8/16 битные игровые консоли. Игры казались ужасно примитивными, Турбо Паскаль не работал… Даже недолгий период интереса к демосцене в конце 90-х, правда не ушедший далее чтения сценерских электронных журналов, проходил исключительно на х86.

Читать дальше →
  • avatar
  • [просмотров: 2089]
  • 1
  • 0
  • +12

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). upd.: And page from where the snow bytes are fetched is that the register I pointed to.

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

Update: Recently (04.2023) yet another snow peculiarity was open. When register I points to slow memory page on 128 machine, the page from where the snow bytes are fetched depends from: 1) on which slow page register I points; 2) what screen is active.
The table shows needed memory page for snow bytes fetching:
I-pointed page Screen 0(page 5) Screen 1(page 7)
1 1 3
3 1 3
5 5 7
7 5 7
In this table rows mean slow page number on which register I points to, columns mean active screen number, table cells mean from what page the snow bytes are fetched. Thanks to TheMartian, IceKnight and Richard Chandler for participation.

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.

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

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

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

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

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

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

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

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

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

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