stella
stella copied to clipboard
stella-emu
RSYNC
For reference, this affects 'Extra Terrestrials' (the ET sprite doesn't pick up the background pellets) and 'Fatal Run' (only 261 scanlines per frame are shown, instead of 262). These both work in the old core; refer to TIA::waitHorizontalRSync() in the old core for comments and further explanation.
Implemented in bd46bb4 . The implementation is basically at the same level as the old core, i.e. there is no simulation of the "secondary effects" mentioned by Omegamatrix --- the line in which rsync is strobed is treated as a full line.
Actually, there's a TEST ROM that does show secondary effects, whereas the old core did not. RSYNCtest.zip
With the current code, the vertical bar moves across the screen when pressing fire, just like an actual console. With the old core, the bar didn't move at all.
Interesting, I didn't try that one. After taking a second, closer look at the old implementation, I retract my statement: the new implementation is significantly more correct. The old implementation basically treats RSYNC like a WSYNC shortened by one CPU cycle and halts the CPU until the end-of-line is reached.
However, this is wrong: what happens is that RSYNC resets the hsync counter to its wrap-around value without halting the CPU, thus causing a shift between the sprite scan counters and hsync. As hsync determines playfield position, this shifts the sprites relative to the playfield --- this is what causes the vertical bar to move in the testcase you linked (and this is the way it is implemented in the new core).
What is missing are the effects that can cause the TV to temporarily lose sync on RSYNC.
Another interesting observation is a glitch that shows up in eshu's paranoid demo with the new RSYNC implementation.
Without RSYNC:
With RSYNC:
After staring at our TV for several minutes, I am pretty sure that the glitch actually matches real hardware. Our LCD shows bad shadowing effects for NTSC signals, so it is a bit hard to tell, but comparing to the paddle position clearly shows that the ball is indeed moved to the left by one pixel relative to the paddle :smirk:
After some cleaning up on my OSX machine, I came across another test case, with source and snapshots, for RSYNC functionality. It looks to work the same on hardware and the current code, but I'm posting it here just in case I misplace it again.
Fatal Run displays 313 (except for the title screen) scan lines in the PAL version (which would result into color loss ), I suppose that's due to RSYNC emulation. Fatal Run (Ultimate Driving) (1989) (Atari) (PAL).zip
What happens on real hardware? Can we confirm that it should (or should not) be running at 313 lines??
No color loss on real PAL hardware.
BTW: Color loss existed in 4.7.3. too, so IMO no reason for any further delay.
@DirtyHairy, maybe you could look at this when you get a chance?
I'm still working on the phosphor stuff, and have to complete the remaining TODO items for 5.0 Due to RL issues, I definitely won't be finished this week; maybe June 27 or so. But at this point it's probably best to just say the end of June for the new release.
The code does:
lda #$03
sta VSYNC
sta VSYNC ; 313 lines code has RSYNC here (and the 262 lines NTSC version too!)
sta WSYNC
sta WSYNC
sta WSYNC
lda #$00
sta VSYNC
BTW: The 262 (according to Stella) lines NTSC version switches on PAL between color and grey frequently. Frequency is different between screens, so it might be related to the too short (varying) VSYNC signal.
And it displays some weird green line in the top left corner of the mission briefing screen. Most likely a sync artifact.
This definitely needs more research.
Odd theory: Maybe RSYNC only works on NTSC? And on PAL it behaves like VSYNC?
I'll try to take a look at it these days. I am still sick at home anyway, so I guess I'll be having more spare time than usual anyway :smirk: As a sidenote I just tried and cannot get the PAL version to display anything beyond the title screen on Stella 4 at all. Scanline count is 313 for me in Stella 4, too, but the screen is black.
Odd theory: Maybe RSYNC only works on NTSC? And on PAL it behaves like VSYNC?
I am pretty sure that it works the same on PAL as it does on NTSC. When implementing this, I tried the RSYNC testcases on my PAL Jr., and they behaved as expected. However, I am not sure what RSYNC does to the TV signal. RSYNC (as far as we know) sets the TIA main counter close to its trip point and causes the scanline to end two pixel clocks later. At this point, the TIA will start sending a HSYNC signal.
I am not sure what such shortened scanlines do to the TV signal. I could imagine that (in particular if RSYNC is triggered during HSYNC) this additional short line does not trigger color loss. Does anyone know enough about PAL to understand color loss from first principles?
As a sidenote I just tried and cannot get the PAL version to display anything beyond the title screen on Stella 4 at all. Scanline count is 313 for me in Stella 4, too, but the screen is black.
That's a known initialization bug, enter and leave the debugger, then you can see the screen in grey.
Does anyone know enough about PAL to understand color loss from first principles?
Not more than Wikipedia will tell you too. :)
Not more than Wikipedia will tell you too. :)
Too bad :smile: Well, I guess the first thing I'll to is writing a test program that checks this hypothesis.
@DirtyHairy, no rush on this, and not worth holding up the 5.0 release. So only if you have enough time (and energy) to do it. I would much rather that #150 is fixed for 5.0.
I connected my cheap logic analyzer to a PAL Vader running "Fatal Run":
The device only has 8 digital channels available and max samplerate is 24MHz
I connected 6 channels as follows (from top to bottom in the pics):
TIA pin 25 (R/W line)
TIA pin 11 (3.54 MHz oscillator input)
TIA pin 2 (video SYNC output)
TIA pin 3 (RDY output)
TIA pin 9 (COLOR output)
TIA pin 6 (phase 2 clock input generated by the 6507)
It seems that strobing RSYNC causes the scanline to end after 36 color clocks. Then there are 3 other scanlines with VSYNC on and 309 with VSYNC off.
@ale-79 Which screen did you test? The timing is a bit different for each screen. 312 lines on title, 313 (according to Stella) on mission briefing and in game screens.
Does that mean the scanline count (when rounded) would be 312, and hence color loss doesn't happen?
There is no color loss, that's for sure.
The problem is, that RSYNC is involved. Else we could experiment to find the exact values where a scanline aborted by enabling VSYNC counts and where not.
In pre9 the debugger tells me that RSYNC updates the Scan Cycle from 8,10 or 14 to 22, from 48 to 51 and from 32 to 35. @DirtyHairy Can you explain that?
So effectively we have ~312.16 scanlines here, correct?
From the point of view of the TIA I think that's correct, as the RSYNC causes the counter to reset and start a new scanline before the current one is completed.
But I don't know how the TV reacts to the resulting signal, that is if this "short" line actually causes an horizontal retrace of the electron beam or not.
Moreover this is happening with VSYNC turned on, and in that case the output of the TIA is already a bit different from the TV standard. (Setting VSYNC in the TIA just inverts the SYNC output, so that the signal is HIGH during the period of time when the horizontal sync pulse should happen and LOW for the rest of the scanline, while on TV standard VSYNC is obtained by prolonging the HSYNC pulses).
@ale-79 Awesome! Just to make sure that I am interpreting this correctly:
- ~63 musec: RDY goes high, the previous WSYNC (write at 0x7DCC) ends
- ~68 musec: HSYNC pulse start, SYNC goes low
- ~68 musec + epsilon: write to VSYNC (0x7929), SYNC is inverted and goes high
- ~72 musec: write to RSYNC (0x792B).
- ~72.5 musec: HSYNC pulse end, SYNC goes low
- ~78 musec: HSYNC pulse start, SYNC goes high
This confirms the emulation which sets the line counter to 225, effectively cutting short the current line. I think what happens is that this short line doesn't have the same effect on the color decoder as a full line and doesn't cause color loss.
We can test this by creating a test program that displays 312 scanlines + RSYNC, with the delay between the previous WSYNC and RSYNC adjustable. This way we can determine the trip point (and check how much it varies between different TVs). We should also check whether it makes a difference if the RSYNC happens during or after VSYNC. I can do this when I find time (unless someone beats me to it :smirk:).
@thrust26 I just checked; "Scan Cycle", "Pixel Pos", "Color Clock" are buggy immediatelly after a RSYNC; there is a bookkeeping offset that ensures that the virtual electron beam doesn't jump for the remaining two pixels and that is taken into account in the wrong place (debugger only). The fix seems trivial enough, but I want to look at it tomorrow with fresh eyes in order to make sure that I am not breaking anything else.
@ale-79 unrelated: is this a Saleae Logic 8? Does it work well with Linux? If so, I'd be considering getting one myself :innocent:
Is there anyone besides me around who can check on real hardware (PAL console and CRT)? I will be on vacation for 4 weeks starting this Friday. With no access to real hardware.
I have a PAL Jr., but of course, I can only test on our LCD, and I am not sure if it is going to show color loss at all :smile: However, I don't think we are in a hurry, and I would suggest that we post our test on AAge anyway in order to find out how different CRTs react --- I wouldn't be surprised if there are differences.
@thrust26 Have a nice vacation! :palm_tree:
@DirtyHairy Thanks! Will do.
And you should really get yourself a CRT. You often get them for free or very little money: https://www.ebay-kleinanzeigen.de/s-tv-video/koeln/preis::10/sony-trinitron/k0c175l945 (smaller ones are more expensive than big ones!) Or get an even better Sony PVM: https://www.ebay-kleinanzeigen.de/s-anzeige/sony-pvm-1454-qm/660623152-175-18674
It's not so much the money, but more the space it's going to use up. We have history of two households that have merged into one in our current flat which, as a result, is already pretty much full. Consequently, we are on a permamanent quest of throwing out stuff to make room for our daughter's toys --- coming home from work with a CRT won't sell very well :smirk:
However, if all goes well, we're going to move next summer, and then there's gonna be a separate room for my stuff, and that'll gonna include a CRT :stuck_out_tongue: