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.
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.
