Хотелка

Хочется компилить и отлаживать в 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). Добавить в него параметр

"runTaskInsteadOfDebug": true

4. Нажать Shift+Ctrl+P (или ваш шоткат для поиска команд) и выполнить Preferences: Open Keyboard Shortcuts (JSON). Добавить в него:
   

   
           {
               "key": "f5",
               "command": "workbench.action.tasks.runTask",
               "when": "config.runTaskInsteadOfDebug && taskCommandsRegistered",
               "args": "Compile and run"
           }
       

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

По сравнению с другими, ранее описанными мной архитектурами, архитектура Sony Playstation 1 (PSX) — сравнительно современная. И дело даже не в годе выпуска (1994) — скорее это общее ощущение сочетания новых возможностей и исчезновения привычных старых, которые были типичными для компьютеров и приставок предыдущей эпохи.

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

На днях выпустил свой новый альбом биперной музыки для ZX Spectrum 48K — Ear Shaver. По сути не только новый, но первый, так как мои предыдущие около-биперные релизы были или компиляциями разрозненных треков, или были альбомами, но для других платформ. На этот же раз я целенаправленно делал именно альбом, сразу много треков в более-менее общем звуке и концепции, и именно для ZX Spectrum.

Послушать без дополнительных прелюдий можно в прикреплённом видео (которое здесь почему-то не видно) или на разнообразных музыкальных площадках.


Не планировал писать очередной making of, но начал делать некоторые заметки для релизных текстов, лично для себя, и как-то само написалось – привычка страшная сила.

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

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

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

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

Что получилось…
Читать дальше →

После некоторого перерыва, решил вернуться к Vectrex. Аналоговость и ламповость (в буквальном смысле) манит. Поскольку Dihalt, на который планировалась работа, назначен на начало января, хотелось сделать что-то новогоднее. Снег, особенно много — не лучший выбор для векторных устройств, так что ёлка мне показалось лучшим вариантом. Рисовать её прямыми векторами не очень интересно, решил кривыми, тем более технология была более-менее отработана в предыдущих работах (Electric Force, Springs ). В данном случае, однако, трудность была в том, что кривые должны быть не какие-нибудь случайные, а вполне конкретные, причём разные.

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

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

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

Статья на Demoscene.ru и последующее обсуждение в tg-чатике CAFePARTY

Demoscene.ru — MasterMentor: Я подниму Cцену с колен* или Make Scene great again**!

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



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


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

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.

Обзор графических работ с zxgfx compo #5 от moroz1999 в Telegraph