Thanks for reporting !

I will be far from my STF until tuesday so nothing new to be expected until then.
Paulo.
Moderators: Zorro 2, Moderator Team
But of course. I couldn't stay away - SYNC (heh) technology has always been one of my favourite playthings on the STljbk wrote:Thanks for reporting !
Of course, you're right. I just picked up on the shifter and I have no idea whether that's really the case. I'm already worried about killing my STF with all the power cycling and will not try artificial cooling of the chips thoughDio wrote:Is there research to demonstrate that it's specifically the shifter (e.g. by freeze spray)? If not, we should use 'system' instead of 'shifter' to avoid introducing imperfect terminology. I think Paolo has already shown some evidence there are multiple warming curves in play with his results that start in one state then move through multiple other states.
I lied! But I think this post will be worth ittroed wrote:Alright, my last update on ULM stabilizers and sync scrolling
I looked at this cycle-exact option in WinUAE, maybe I don't understand it well but I think it's "cycle-accurate" in the same way that we try and have MFP and blitter cycle-accurate in ST emu. I doubt CPU emu is stopped every 4 cycles. Imagine in how many times instructions like MUL or DIV would complete? And how to come back at the exact same point of the instruction?npomarede wrote: Many demos often draw on the same screen at the same time it is displayed, but as long the content of the screen is not updated on the same HBL it's supposed to be displayed, it won't give any problem.
This is required for performance reason ; else it would require to either check if any write is in an interval corresponding to the current HBL data, or render each line every 4 cycles for example, which would kill performances and make emulation really sloowww (but for example, WinUAE has an optionnal "cycle exact" mode that "refreshes" each HW component every 4 cycles, as would do a real machine where the BUS would be shared between cpu, gfx, dma, ...) (updating every component each 4 cycles is also much more complex as it requires a really accurate emulation of each part, down to the cycle level).
The method consisting of forcing an intermediate video rendering when a write is detected in the correct RAM interval is certainly much easier, I might add it to Hatari some day.
Nicolas
Testing results follow:ljbk wrote: Here is a ULM stabilizer version of the 4 bit sysncroller (4 pixel case / program only).
I will update the post above with WS1 as well after this post. No temperature instability for hi/lo or ULM.Thanks for your tests.
I will need some time to read carefully your posts.
Alright - I'll put that onto an image on the HxC as well and have it prepared for next timeAs for the tests programs, the best one to detect the current WS and one of the sub wake up states is BEEMOVE0. It uses the LO/MED/LO unstabilizer which fails in one of the sub wakeup states i called "band".
That "band" substate existing for all WS is aparently imune to cold/warming/warmed phases.
If no "bands" appear, then you are most probably is a "normal" substate condition and there you have cold/warming/warmed phases.
I did some quick tests just now. I'll just dump the info here since you can make a lot more sense of it than Iljbk wrote: Just as a curiosity, what CPU speed does the program posted here (http://www.atari-forum.com/viewtopic.php?f=15&t=24862) returns for your machine ?
This would help in locating your machine in the several HW revisions. Later STs have 8.021247 MHz CPUs. Nicolas STF has a 8.010 MHz CPU. Mine has a 8.0071 MHz CPU. May be some HW revisions are more prone in waking up in WS2 and some more in WS3 and so on ...
Don't bother repeating that for all WS.troed wrote:
I did some quick tests just now. I'll just dump the info here since you can make a lot more sense of it than I
In sequence, during the first few minutes after the first boot of the day:
HWTEST4:
WS3 cold:
VBL Cycles: 160256 (160256@8MHz)
MFP_VBL CLOCK: 8020978 (IF CPU @ 8MHz)
MFPCALC CLOCK: 8020978
TIME_LP CLOCK: 8021204
WS2 cold:
TIME_LP CLOCK: 8021180
(repeated twice, the other values the same)
WS3 cold:
MFP_VBL: 8021101
MFPCALC: 8021101
TIME_LP: 8021180
WS3 cold:
VBL Cycles: 160256 (160256@8MHz)
MFP_VBL CLOCK: 8020978 (IF CPU @ 8MHz)
MFPCALC CLOCK: 8020978
TIME_LP CLOCK: 8021204
(i.e same as the first)
It seems that your WS3 cold is behaving like a WS1 ... This i never got but as it is very dificult for me to get WS3 may be the machine was always warm enough when i got it.troed wrote:
For all of these tests I also ran BEEMOVE0 at each boot:
WS3 cold: -4 fail (all boots)
WS2 cold: 0 works, -4 fail, -8 and -12 banded (both boots)
(where "fail" indicates a bitplane shift and no difference in position)
Caveat: Previous testing (yesterday, see above) got me both working and non-working -4 shifts while both in WS3 cold and WS3 warm. They could happen on successive boots right after each other.ljbk wrote: It seems that your WS3 cold is behaving like a WS1 ... This i never got but as it is very dificult for me to get WS3 may be the machine was always warm enough when i got it.
BEESCRT:ljbk wrote:- WS1 allows to proceed if you wish;
- TAB switches stabilizer;
- LEFT and RIGHT arrows force scroll direction;
- info displayed on screen:
1st line: unstabilizer(H,M) / stabilizer(H,U) / wake up state(1,2,3,4) / shift(0,1,2,3)
H: high / M: medium / U: ULM
shift 0->0 / 1->-4 / 2->-8 / 3->-12
2nd line: 5 groups of 2 numbers with each pair of numbers meaning a line type for the "classic" sync scrolling combinations and that looks like a tennis 5 set result
So if there is a line combination that does not work with the 4 stabilizer/unstabilizer combinations you can provide me these 10 numbers and i will identify it.
The answer is, for my machine, yes for WS2, WS3 and WS4 and no for WS1.Dio wrote:Isn't the NTSC 160 offset by -4 compared to the PAL 160...?
Interesting to see you can have a WS3 cold where all works and a WS3 cold that behaves like WS1 ....troed wrote:
BEESCRT:
WS3 cold: -4 fails. Nothing makes a difference.
WS3 cold: all works. Switching stabilizer (TAB) doesn't change anything (unstabilizer, ESC, does)
WS2 cold: One sync combo fails - striped. 66 26 62 00 44 (TAB/ESC doesn't fix it)
WS2 cold: One sync combination "flashes" briefly before stabilizing: 66 66 62 00 64
But only if it comes after 64 64 64 64 64 - and not after having switched stabilizer with TAB. I.e, only happens in one scroll direction and with the default stabilizer.
(All tests were done within minutes and I'm confident the mode was "cold" throughout)
/Troed
My bad - I didn't test BEEMOVE this time around when I got the working/not working WS3s. I will do so next time.ljbk wrote: Interesting to see you can have a WS3 cold where all works and a WS3 cold that behaves like WS1 ....
Did you see any difference with BEEMOVE (bands / no bands) ?
Yes - it was actually when making sure of that I noticed the other one. Do note though, the "striped" one was completely unstable. The other one that only flashed (for one VBL I assume) stabilized immediately.Are you sure the first WS2 cold happens in both scrolling directions ?
In fact i only "stabilize" lines at the normal spots when the right border is open (204, 206 and 230).troed wrote:Yes - it was actually when making sure of that I noticed the other one. Do note though, the "striped" one was completely unstable. The other one that only flashed (for one VBL I assume) stabilized immediately.ljbk wrote:Are you sure the first WS2 cold happens in both scrolling directions ?
I also only stabilize lines where the left border has been removed (so, not 54) - which is purely due to historical reasons and "knowledge" we had in 1989 that is most likely completely irrelevant today. But, "don't change stuff that [seems to] work" ..
/Troed
I'm only able to profile W1 so far, but the timing indicates that it should be visible here too. Both DE and LOAD start 4 clocks early and the line length remains 64us, 512 cycles.ljbk wrote:The answer is, for my machine, yes for WS2, WS3 and WS4 and no for WS1.Dio wrote:Isn't the NTSC 160 offset by -4 compared to the PAL 160...?
A 162 bytes line (start like NTSC and end like normal PAL) will be shifted 4 pixels to the left for all WS except WS1.
Now, if really show a NTSC line with the with the respective HSYNC and 508 cycles, i don't known if the screen will start earlier or not.