Exact emulation of the Snow effect.

[NEO SPECTRUMAN]

You mean d7 of register R

yep (>d7<d6 d5 d4 d3 d2 d1 d0)

doubting Thomas

nope
you just doesn't provide correct test

[Weiv]

nope
you just doesn't provide correct test

My test is correct enough) You just don't understand it

[Weiv]

In SpecIde it works, does not show any snow. I'd have to try it on a real machine, maybe this weekend.

There is the snow in first screen column but on 48 machines it is visible only on late timings machines. On 128 machines it is visible for both of timing types. (On my emulator, of course).

[Weiv]

Awesome

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

TonyB in discord channel pointed out, that the CAS and RAS were swapped in this explanation. I think that people who understand the text above also understand this mistake, and who don't understand also don't care)

Also: http://www.zxdesign.info/dynamicRam.shtml

[TheMartian]

TonyB in discord channel pointed out, that the CAS and RAS were swapped in this explanation. I think that people who understand the text above also understand this mistake, and who don't understand also don't care)

Also: http://www.zxdesign.info/dynamicRam.shtml

Yeah, my bad, I spoke from memory. (I spoke *about* memory *from* memory, ). The general idea is the same, though. The RAS signal holds the low bits, the CAS signal latches the high bits twice: First pixels, then attributes.

My main source of information here was precisely Chris Smith's book too I've based my own emulator on his schematics and descriptions. He did an amazing work; the accuracy of the result is incredible!

Now, it'll be some time until my emulator SpecIde does the snow effect properly. I've implemented the snow/duplication feature already, but it is shifted one column to the right. I'm going to need to rework some of the lousy design I did in the glue logic. At least, I'm learning a lot...

[TheMartian]

Hi all,

Long time, no see...

I just wanted to say that SpecIde, since the last couple of commits, emulates (*almost*) perfectly the snow effect.

- It emulates perfectly the snow in 48K models, with programs such as snow_mod.tap, snow.tap, etc.
- It also emulates snow correctly in 128K models when RAM 5 or 7 (I think) are paged in (I = 0xFE): ula128.tap.
- However, when RAM 1 (or 3) are paged in (I = 0xFE), it still generates a slightly different pattern. (The Ninja Warriors menu screen, for instance; or Ninja Hamster 128K while loading)

If you want to check, for the moment, you'll need to build from sources! (I was updating the libraries and environment for Windows builds and broke stuff... sorry!

A couple of pictures:



Let's hope I can dedicate more time to the emulator from now on...

Also, thanks to all the people who helped in describing the Snow Effect (thanks, especially, @Weiv)

[TheMartian]

BTW, I had the snow effect shifted one column later because the condition determining whether will snow or not happens about four pixels before the ULA reads video data.

[Weiv]

- However, when RAM 1 (or 3) are paged in (I = 0xFE), it still generates a slightly different pattern. (The Ninja Warriors menu screen, for instance; or Ninja Hamster 128K while loading)

Yes, I saw on video by @ICEknight that snow on his spanish 128 in The Ninja Warrior is different than in my emulator. I thought that it was another version of the game or maybe spanish 128, but your mention of the difference make me think again about it. My experiments with my emulator let me decide that in described situation (register I points to upper memory window) bytes for snow are fetched from current memory page in upper memory window (not from active screen page as I thought).

Thank you! And thanks to @ICEknight for his video.

[TheMartian]

@Weiv, check the load process of Ninja Hamster 128K.

- First page to load is RAM1. Snow appears as it loads.
- Second page to load is RAM3. If snow comes from the RAM in C000-FFFF, then there should be no snow, but there is from the beginning of the block.

I've done something like getting the data from the (pagenumber & 0x5), and it does the trick. However, the pattern is a little different.

[TheMartian]

Also, yes, thanks to @ICEknight for the videos! Invaluable help!

[Weiv]

@Weiv, check the load process of Ninja Hamster 128K.

- First page to load is RAM1. Snow appears as it loads.
- Second page to load is RAM3. If snow comes from the RAM in C000-FFFF, then there should be no snow, but there is from the beginning of the block.

I've done something like getting the data from the (pagenumber & 0x5), and it does the trick. However, the pattern is a little different.

I can't check the load process of the game on real hardware directly. In my emulator the snow appears a bit after the beginning of the both blocks (when addresses $D800..$DAFF are load). If you state that the snow appears directly at beginning of the second block then it's kind of strange, I can't figure it out.

[Ast A. Moore]

I can't check the load process of the game on real hardware directly. In my emulator the snow appears a bit after the beginning of the both blocks (when addresses $D800..$DAFF are load).

Sounds about right. Here’s the video of the loading process of Ninja Hamster I made a few years back on my Toastrack.

[Weiv]

Sounds about right. Here’s the video of the loading process of Ninja Hamster I made a few years back on my Toastrack.

Thank you! It's exactly as in my emulator for both first blocks of the game with non-standart loader. Even that the snow appears firstly in first half of every screen third, then in second one.

[TheMartian]

Yeah, but between the first and second blocks it keeps snowing.

[TheMartian]

Here: https://drive.google.com/file/d/11lMpWq ... p=drivesdk

[Weiv]

Here: https://drive.google.com/file/d/11lMpWq ... p=drivesdk

Thank you! I'll think about it.

[Pegaz]

@TheMartian

Hi Marta, it's nice to have you back and bring more perfection with SpecIde.
Unfortunatelly, I definitely can't manage to compile on Windows.
I see that you also had some problems while compiling, but if you can please provide a Windows binary, I'd really like to try these new improvements.
btw, I tried this NinjaHamster128k example on the latest SpecEmu, but I can't see this snow effect.
Are yours and Weiv's emulators the only ones with this level of snow accuracy ?

[Weiv]

@TheMartian , I made a new test to solve from what page snow bytes are fetched when register I points to upper memory window, and also to compare vary snow patterns. If you will have time and wish please run the test on your real 128 and make a video of it so we will have a new info about that snow case. There: https://zx-pk.ru/attachment.php?attachm ... 1680636053

Asm source of the test:

Code: Select all

		org $8000

		di
		ld bc,$7FFD
		ld l,1

l2		ld a,l 
		or $10
		out (c),a

		ld a,l
		rlca 
		rlca 
		rlca 
		add a,l
		ld h,a

		ld de,$D800

l1		ld a,h
		ld (de),a

		inc de
		ld a,d
		cp $DB
		jr nz, l1

		inc l
		inc l
		ld a,l 
		cp 9
		jr nz,l2
		

		ld a,#FF
		ld i,a
		ld h,0
l5		ld l,1
		
l4		ld a,l
		out ($FE),a

		or $10
		or h
		ld bc,$7FFD
		out (c),a

		ld de,#B800
		ld b,d

l3		ld a,(de)
                nop
		djnz l3
		inc e
		jr nz,l3
		inc d
                ld a,d
		cp $C8
		jr nz,l3

		inc l
		inc l
		ld a,l 
		cp 9
		jr nz,l4

		ld a,h
		xor 8
		ld h,a
		jr nz,l5
		
		ld a,$3E
		ld i,a
		ei 
		ret

About The Ninja Hamster - it seems like when page 3 is starting to load the snow bytes are fetched from page 1 because it's the almost only page with some data at the moment (except page 2 with loader and rom pages).

[TheMartian]

I'll give it a try tomorrow.

I'll also check the ZX Spectrum 128K schematics (IC27, IC29 and IC30 - That's the PCF1306P ZX8401, the 10H8 HAL and the 74LS157 selector)...

[TheMartian]

@Weiv You got it.
https://drive.google.com/file/d/12GLwh9 ... p=drivesdk

I am also trying to decipher the schematics. Wish me luck.

[1024MAK]

I'll also check the ZX Spectrum 128K schematics (IC27, IC29 and IC30 - That's the PCF1306P ZX8401, the 10H8 HAL and the 74LS157 selector)...

Related: WoS forum “The I register pointing to $40–$7f causes ULA snow and a crash. Or does it?”

Mark

[TheMartian]

Maybe the link is bad?

[Weiv]

@Weiv You got it.
https://drive.google.com/file/d/12GLwh9 ... p=drivesdk

I am also trying to decipher the schematics. Wish me luck.

Thank you very much! And good luck!

[Ast A. Moore]

Maybe the link is bad?

Here. All fixed.

[1024MAK]

Link was missing

Try now