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

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

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

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.

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

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

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

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

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

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

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

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

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

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

Принципы кодирования инструкций Intel x86(-64) или "ехал префикс через префикс"

Введение

С давних пор меня интересовало то как процессоры Intel x86 кодируют свои инструкции.
Будучи в детстве владельцем клона ZX Spectrum я уже тогда сталкивался с таблицами кодов инструкций его процессора Z80, как например тут: clrhome.org/table/
В таком виде очень хорошо просматривается принцип кодирования этих инструкций — наглядно видно как они упорядочены и по каким битам раскиданы.
Но вот для x86 таких таблиц как то не удавалось найти, а то как эти коды пояснялись в руководствах от самого Intel было несистематизировано и поэтому не воспринималось.
Однако пару месяцев назад я наконец то наткнулся на табличный вид однобайтовых инструкций от i8086 до i386, поразглядывал его и проникся тем что тут и как кодируется.
Более того — в процессе этого обзорного ознакомления я проникся еще тем как эволюционировала система команд x86 с поколениями процессоров и решил вкратце эти вехи законспектировать тут. Это ни в коем случае не полное справочное руководство, но скорее обзорное знакомство вместе с историческим экскурсом которое возможно поможет кому то быстро понять основные принципы кодирования инструкций x86 перед более углубленным изучением по таблицам.

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

Мой виртуальный 16-битный "компьютер мечты" - SimpX

Исходники: github.com/aa-dav/SimpX
Онлайн-версия: aa-dav.github.io/ (первая загрузка будет долгой, но потом закешируется)
В веб-версии рекомендую сразу нажать меню View->Set 400% чтобы выправить соотношение сторон.
Выбираем в левом списке редактора файлы test0x.asm и нажимаем меню Emulator->Compile and run чтобы увидеть результат.
Если активирована не английская раскладка клавиатуры — ввод с кнопок может не работать (это важно для последних тестов).
Так же еще замечу, что в веб-версии в коде могут некорректно отображаться табуляции — это некритично и вызвано разным отношениям к пикселям в среде Qt в stand-alone и wasm вариантах. В stand-alone всё визуально корректно.
Описание процессора — Simpleton (4) и его ассемблера уже было.

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

Бесконечные ZX Spectrum-демо на коленке



Несколько лет назад у меня возникла идея создать некий сервис, где будут круглосуточно крутиться спектрумовские демo. Хотелось, чтобы была возможность в любой момент просто воткнуть канал и там постоянно что-то транслировалось бы. Поднимать сервак дома, конечно же, никакого желания не было, потом вылезли какие-то другие бытовые вопросы, ну и в итоге я благополучно забил на это дело.

Пару месяцев назад я случайно наткнулся на статью одного человека, который запускал круглосуточную трансляцию на YouTube по другой тематике, и меня эта идея снова зацепила. Что в итоге было сделано: взят нужный VPS, развёрнут весь необходимый софт, зарегистрирован канал Speccy247, отобраны первые 50 штук демо, трекмо и иже с ними, а также пару игр с интересными на мой взгляд интрухами. Настроен UnrealSpeccy, который каждые 300 секунд запускает следующую программу в плейлисте. Вот такой был механизм с самого начала :)

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