horizontal scrolling on ST

[ljbk]

I hope i have been clear enough.
Paulo.

You kidding, right?
Seriously, there's no 71/50 check at line cycle 376 ("position 293") in Steem for now, that could be the problem.
By the way, despite working on Steem I don't really understand ST assembly .

Ooops, sorry !

The 71/50 switch to open the right border works differently from the 60/50.
You can set $FFFF8260 to 2 at any time before a certain MMU time spot but you can not set it back to 0 before that same spot but you can set it much later.
With the 60/50 switch, you have to set the $FFFF820A to 0 a one of two time spots and then you can set it back to 2 any time after that.
For one of the 60 Hz spots, the 293, you do not need to have an EXG instuction or any instruction taking 6, 10, 14, 18, 22, ... cycles.
For the other one, either 291 in WS1 and WS3 or 295 in WS2 and WS4, you do.
You can check that some of the scan lines in the Nostalgic Demo main menu set the Right Border 60 Hz at 291 while for others it does it at 293.
For WS1 and WS3 that's fine. For WS2 and WS4, with my machine, it does not work ...
As far as i know Enchanted Land uses the 71/50 switch to open the Right Border for the sync scrolling. I do not know which time Nick selected but it works on my 1040STF Revision C.

So going back to the tests, the switchs are done at the places indicated:
-71/50 at 295/305;
-71/50 at 297/305;
-60/50 at 295/305;
and the MMU counter at $FFFF8209.w is read at the end of that line.
It can be either $CC: 204 or $A0: 160.
The combination of the three results is then tested:
WS4: CCA0CC
WS3: CCA0A0
WS2: CCCCCC Right Border is always open
WS1: A0A0A0 no case where Right Border was open

Better now ?

Paulo.

[npomarede]

As far as i know Enchanted Land uses the 71/50 switch to open the Right Border for the sync scrolling. I do not know which time Nick selected but it works on my 1040STF Revision C.

The 71/50 switch used in Enchanted Land is only present in the self calibration code (at the time the thalion intro appears). There's a bug in the self calibration code that puts the 71/50 stabiliser at the wrong position, thus opening the right border a second time (as well as removing left border on the next line).
But the self calibration correctly computes the usual 60/50 switch's position to remove right border, and this timing is used in the game, but the stabiliser is at a fixed position (doesn't use the result of the calibration part). During the game, sync scrolling uses "classic" 60/50 switch for right border, not the 71/50 variation.
The calibration only checks that ff8209 is changing to assert that right border was removed, so my guess is that Nick never noticed he found a new border removal at that time

Nicolas

[ljbk]

@ Nicolas and Steven Seagal

Hi !



From what i read from you, it seems that both Hatari and STeem use the same cycle scale:
Classic Right Border openning:
- 60 Hz effective at MMU cycle 376;
- 50 Hz effective at MMU cycle 384 (or afterwards);

This would mean that for the Overscan Demos (1990 version), you should have:
- 71 Hz effective at MMU cycle 004 to open the Left Border (that does not work on STE);
- 50 Hz effective at MMU cycle 012;
- 60 Hz effective at MMU cycle 376 to open the Right Border;
- 50 Hz effective at MMU cycle 384;
- 71 Hz effective at MMU cycle 444 to stabilize;
- 50 Hz effective at MMU cycle 456;

This would mean that for the Overscan Demos (2004 STE version) and most fullscreens, you should have:
- 71 Hz effective at MMU cycle 000 to open the Left Border (that works on STE);
- 50 Hz effective at MMU cycle 012;
- 60 Hz effective at MMU cycle 376 to open the Right Border;
- 50 Hz effective at MMU cycle 384;
- 71 Hz effective at MMU cycle 444 to stabilize;
- 50 Hz effective at MMU cycle 456;

This would finally mean that for ULM fullscreens (like the Dark Side Of the Spoon intro), you should have:
- 71 Hz effective at MMU cycle 508 to open the Left Border;
- 50 Hz effective at MMU cycle 012;
- 60 Hz effective at MMU cycle 376 to open the Right Border;
- 50 Hz effective at MMU cycle 392;
- MEDIUM RES effective at MMU cycle 440 to stabilize;
- LOW RES effective at MMU cycle 456;


If this is true, then the translation from my cycle scale to yours is simple :

Emulators_cycle = (cycle_Paulo + 83) mod 512

All the time spots i refer correspond to the effective change or completion of the instruction.

Another way to see if we are talking the same is the counter reading of the MMU FFFF8209 register at each cycle via a move.b (An),Dn:
Paulo_cycle / Emulator cycle / Value read for the 1st normal line in PAL for all wake up states:
291 / 374 / $9C
293 / 376 / $9C
295 / 378 / $9E
297 / 380 / $9E
299 / 382 / $A0 : 160 : end of line;
301 / 384 / $A0 : 160 : end of line;


Please confirm this or not ...



Paulo.

[npomarede]

@ Nicolas and Steven Seagal
Hi !

From what i read from you, it seems that both Hatari and STeem use the same cycle scale:
Classic Right border openning:
- 60 Hz effective at MMU cycle 376;
- 50 Hz effective at MMU cycle 384 (or afterwards);

Hello

I ran the test you sent me :

Code: Select all

sync_rt:
	move.b	d0,(a4)			08	293		Set 60 Hz
	move.b	d2,(a4)			08	301		Set 50 Hz

color_rt:
	move	d4,(a0)			08	293		Set color $700
	move	d3,(a0)			08	301		Set color $777

In that case, I get this in Hatari :

Code: Select all

cpu video_cyc= 32628 372@ 63 : $0b7da8 : 1880                                 move.b    d0,(a4)
sync=0x00 video_cyc_w=32632 line_cyc_w=376 @ nHBL=63/video_hbl_w=63 pc=b7daa instr_cyc=8
detect remove right 56<->460
cpu video_cyc= 32636 380@ 63 : $0b7daa : 1882                                 move.b    d2,(a4)
sync=0x02 video_cyc_w=32640 line_cyc_w=384 @ nHBL=63/video_hbl_w=63 pc=b7dac instr_cyc=8

-> the move.b 60 Hz starts at cycle 372 and the write is effective at cycle 376
-> the move.b 50 Hz starts at cycle 380 and the write is effective at cycle 384

So yes, this gives Emulators_cycle = (cycle_Paulo + 83) mod 512

As you know, a write to ff8240 for example is not effective immediately, result will be seen a few pixels later.
So, from an emulation point of view, using pixels as time scale is more complex : you need to know the delay after a write and add this to your emulator. Of course, Hatari and Steem are handling this delay correctly, else all plasma demos / spectrum 512 like images would look wrong.

But when starting to code an emulator from scratch, you will most likely reach a precise cpu emulation with correct cycles first, and then fine tune the pixel delay later ; even if knowing where the write is effective in the CPU is more complex (require to know how the microcode works), it's much easier to use cycle 0-512 as a time scale, because you only rely on 1 parameter, not 2 with the pixels delay.

Nicolas

[Dio]

You said you would prefer that the SW uses a less as possible the A23 which means as less changes to $FFFF820A/60 as possible.
Some of the lines sizes available are not stable with the minimum sync/resol switches: if you use them once it might work but if you repeat their use, like 2, 3, 4, ... the Shifter goes to one of the funny states : interleaved shifted lines at different positions or vertical bands of border with also different shifts ...
This can be avoided for most cases with a stabilizer and that means most of the times two extra accesses to $FFFF8260.
For your HW tests, do you prefer the unstable versions with less HW access or the more stable ones (at least with my machine and WS2)

I'd prefer a single write per line case, as long as the shifter can be consistently reset at VBLANK - not just because of the triggering but also because it's ideal to try to measure the effects of a single write. Don't care how much it scrambles the display (an LCD monitor isn't going to explode due to bad syncs).

[ljbk]

So yes, this gives Emulators_cycle = (cycle_Paulo + 83) mod 512

As you know, a write to ff8240 for example is not effective immediately, result will be seen a few pixels later.
So, from an emulation point of view, using pixels as time scale is more complex : you need to know the delay after a write and add this to your emulator. Of course, Hatari and Steem are handling this delay correctly, else all plasma demos / spectrum 512 like images would look wrong.

But when starting to code an emulator from scratch, you will most likely reach a precise cpu emulation with correct cycles first, and then fine tune the pixel delay later ; even if knowing where the write is effective in the CPU is more complex (require to know how the microcode works), it's much easier to use cycle 0-512 as a time scale, because you only rely on 1 parameter, not 2 with the pixels delay.

Nicolas

Thanks for confirming !

You are one of the emulators specialist so you should know what's best.
I will try to use your scale for explains.
By the way, the display delay can vary to -1 pixel and so that is why we can get the funny dots on screen with Spectrum 512 and similar code (also on STE).

Now, back to the 4 wake up states and to the emulator possible implementations of the hardware behaviour here is a piece of "kind-of-C" pseudo-code on how i would implement the Short Right and Right Border openning.
This is only meant to try to help, nothing more.

"
switch (wake_up_state):
{
case 1:
get_color_line_sync_spot = 54;
get_mono_line_sync_spot = 54;
short_right_spot = 372;
6050_right_border_spot = 376;
7150_right_border_spot = 376;
break;
case 2:
get_color_line_sync_spot = 56;
get_mono_line_sync_spot = 58;
short_right_spot = 374;
6050_right_border_spot = 378;
7150_right_border_spot = 380;
break;
case 3:
get_color_line_sync_spot = 54;
get_mono_line_sync_spot = 56;
short_right_spot = 372;
6050_right_border_spot = 376;
7150_right_border_spot = 378;
break;
case 4:
get_color_line_sync_spot = 56;
get_mono_line_sync_spot = 56;
short_right_spot = 374;
6050_right_border_spot = 378;
7150_right_border_spot = 378;
break;
}

...

if ((cycle == get_mono_line_cycle_sync_spot) && (FFFF8260 == 02)) video_mode = mono;
if ((cycle == get_color_line_cycle_sync_spot) && ((FFFF8260 == 00)||(FFFF8260 == 01)))
{
if (FFFF820A = 0) video_mode = NTSC else video_mode = PAL;
}
...
if ((video_mode == PAL)
{
...
if ((mmu_reading) && (cycle == short_right_spot))
{
if (FFFF820A = 0) mmu_reading = false;
}
if ((mmu_reading) && (cycle == 6050_right_border_spot))
{
if (FFFF820A = 0) 6050_right_border_open = true;
else 6050_right_border_open = false;
}
if ((mmu_reading) && (cycle == 7150_right_border_spot))
{
if ((!6050_right_border_open) && (FFFF8260 != 2)) mmu_reading = false; // starts border
}
...
}
"

Hope it helps.


Paulo.

[ljbk]

@Dio

Hi !

Please check the attached zip and tell me what you think about it for your tests.

Keys:
- the 13 keys between Escape and Backspace for the 13 line sizes: 0, 14, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206 and 230;
- F1 to F10 for special cases: 204 + stab, 204 + stab + blank, 204 + stab + right blank, 0(7150), 0(7150) + blank, 160(start at NTSC spot (like line 162) and end like line 158), 204(71/50), noline1, noline2, sync204stb(like a RESET);
- HELP to activate or deactivate Blank for most line types;
- UNDO to activate or deactivate Right Blank for most line types;
- SPACE to quit;

The special line occurs at the end of the light blue band just before the start of the orange band. Check the 54, 56 or 80 bytes lines to locate the partial 16 pixels blank due to the switch of FFFF8260 to 2.

All the lines are stable for WS1, that seems to be a wake up state where everything is much more stable than with WS2, except 54 bytes with right blank. With WS2, you might have more problems, especially with 186 bytes and 230 bytes line since there is no stabilizer included. I did not test the program with WS3 and WS4 but there should be no problems there.
If you do tests with WS2, don't do the tests immediatly at "power on" since i have detected that in that case the Shiter tends so stabilize with time (i am not kidding) especially when changes to FFFF8260 and the 2 value (71 Hz) are involved. The response to a simple 71/50 switch at the middle of the bitmap reading will change with time. If you test it at "power on" you get one type of instability. One hour later, you might get another type. After some time it stabilizes. This does not happen with the other WS: 1, 3 and 4.

At the top you can see Wx where x is the wake up state, Fx (with x = 1,2,3,4,5,6,7,8,9,A,B,C...) to identifiy the line type, 3 digits with the expected line length and 5 digits with the MMU read bytes during the frame.

I can take the bee out

Paulo.

[Dio]

Brilliant. I got all the ST stuff out of the garage last night and I've captured a few traces tonight to make sure everything' running OK. I'll take a look at this over the weekend.

That things change over time is almost certainly some transition being very close to the point at which it's checked and so there's a setup time violation - therefore as the chips warm up and the propagation delays change slightly, the signal moves from one side of the line to the other. This happens in the Spectrum, for example, where the INT signal arrives about 40ns before a clock pulse, but the setup time window on the Z80 CPU is 80ns, and so some Z80s get the interrupt on one clock, some get it on the other clock, and a few go from one to the other as it warms up.

That's actually useful data because it lets you ID exactly where the signal test boundary is. With a can of freeze spray applied to a few different chips, you might be able to move it from one to the other with that.

[ljbk]

@ Nicolas and Steven Seagal

Hi !


The attached file contains everything you need to emulate the behaviour from my STF in PAL except the Shifter instabilities caused by resolution changes (shiftings, bands, interleaved shifting).

Together with the program i made for Dio, you have everything to adapt the emulators if you can and wish.

Nicolas, as i have your email, i will send you a test program so that you can check your STF behaviour.

Any questions, please ask.


Paulo.

[Dio]

Just to clarify, when you say 'rev C' do you mean C070523-001 Rev C? I think C070789 may have a Rev C too and possibly some others of the later boards.

My initial testing will be on a C070523 Rev D STFM (an early one). I also have a slightly later (judging by the date and a few minor component tweaks) C070523 Rev D STF which I plan to try (since it has an NTSC master clock crystal and no clock nudger) although I'm not sure how easy it will be to test that since I can only use that with a mono monitor so I will be testing blind. I have a couple of 70789s too but I don't plan to test those separately unless we see strong evidence there's different behaviour on the later borads.

[ljbk]

Just to clarify, when you say 'rev C' do you mean C070523-001 Rev C? I think C070789 may have a Rev C too and possibly some others of the later boards.

I have a C070523-001 machine like the first 1040STF you can find here:
http://www.atari-forum.com/wiki/index.p ... _revisions

[ljbk]

Hi !

Again for emulator programmers, i wish to add that the "kind-of-C" pseudo code has one flaw.
It might never happen but one has to consider the following case:

cycle 360 : FFFF8260: $00 -> $02
cycle 368 : FFFF820A: $02 -> $00
cycle 376 : FFFF820A: $00 -> $02
cycle 384 : FFFF8260: $02 -> $00

The change at cycle 368 should cause a line 158 type ending (1 word less going to the Shifter).
But in fact we get a Right Border openning due to the FFFF8260 change to $02.
So aparently, any changes to FFFF820A, will only be considered by the GLUE at the moment when FFFF8260 comes back to 0 or 1.
The same kind of timing overlaps may occur at the start of the screen for the 0 bytes line case.



Now regarding the 4 bit stuff and WS1, it seems to be an impossibility to get the -4 shift. The -12, -8 and 0 cases work fine. We can still get advantage of 0 / -8 cases .
Up to now, i could not find 1 case where the -4 shift occurs at any instability phase even for 1 VBL frame no matter what kind of destabilizer i use.
Even the 162 bytes line case and the 206 one, that cause without anything else than the early start screen start, and eventually the right border openning, a shift of the screen 4 pixels to the left in WS2, will not do that in WS1 as we get a normally placed screen.
You will say that Alien managed the 4 cases in his fullscreen (Let's do the Twist Again in PYM).
That's right but the fullscreen display does not have the same timings inside the Shifter. The screen is like 1 pixel shifted to the right. I can notice that with ease with my 40 inch LCD TV.
So i guess i am stuck with making this work as best as i can with WS2, WS4 and who knows may be the almost unreachable WS3 (with my machine).


Paulo.

[Steven Seagal]

Please confirm this or not ...



Paulo.

To confirm, the best way is to post parts of Steem's powerful shifter events report:

Disk A: Amiga Demo
Line 008 - 376:S0000 388:S0002 512:T0010

Disk A: Overscan Demos STF
Line -25 - 004:R0002 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 512:T2011

Disk A: Overscan Demos STE
boot
Line -25 - 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 508:R0002 512:T2011
menu
Line -17 - 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 512:R0002 512:T2011

Disk A: Darkside of the Spoon
Line -10 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011

Cycles are when writes "hit". Fortunately it's the same in Steem and Hatari.

About your program and your table, gimme some time!

[Steven Seagal]

The 71/50 switch to open the right border works differently from the 60/50.
You can set $FFFF8260 to 2 at any time before a certain MMU time spot but you can not set it back to 0 before that same spot but you can set it much later.
With the 60/50 switch, you have to set the $FFFF820A to 0 a one of two time spots and then you can set it back to 2 any time after that.
For one of the 60 Hz spots, the 293, you do not need to have an EXG instuction or any instruction taking 6, 10, 14, 18, 22, ... cycles.
For the other one, either 291 in WS1 and WS3 or 295 in WS2 and WS4, you do.
You can check that some of the scan lines in the Nostalgic Demo main menu set the Right Border 60 Hz at 291 while for others it does it at 293.
For WS1 and WS3 that's fine. For WS2 and WS4, with my machine, it does not work ...
As far as i know Enchanted Land uses the 71/50 switch to open the Right Border for the sync scrolling. I do not know which time Nick selected but it works on my 1040STF Revision C.

So going back to the tests, the switchs are done at the places indicated:
-71/50 at 295/305;
-71/50 at 297/305;
-60/50 at 295/305;
and the MMU counter at $FFFF8209.w is read at the end of that line.
It can be either $CC: 204 or $A0: 160.
The combination of the three results is then tested:
WS4: CCA0CC
WS3: CCA0A0
WS2: CCCCCC Right Border is always open
WS1: A0A0A0 no case where Right Border was open

Better now ?

Paulo.

Yes knowing what to look for I could have the bees shift in WU1 and 2.
Steem doesn't handle WU3 and 4.
In fact the 71/50 switch was already in Steem, I had just disabled it...

The story is told here:
http://ataristeven.t15.org/Steem_35_com ... -up_states_

[ljbk]

Yes knowing what to look for I could have the bees shift in WU1 and 2.
Steem doesn't handle WU3 and 4.
In fact the 71/50 switch was already in Steem, I had just disabled it...

The story is told here:
http://ataristeven.t15.org/Steem_35_com ... -up_states_

Hello !

You can handle the WS you wish.
An emulator should behave like the machine itself: waking up in a WS without the user choice.
I have a few tricks to try to get the one i want but it does not always work.

Now regarding your article there is one thing wrong.
Excepting the original 4bit.prg and its small variation in June 2013 where the return to TOS is intended to be WITH shifted screen and messed up bitplanes, this will not happen in any other case.
You might notice that in most programs, especially the ones handling special Shifter conditions like fullscreens i always set the rate to 60Hz during 1 VBL before setting it back to 50 Hz on the next VBL to exit to TOS or to go to the next screen.
I was already doing this in 1990 in the Overscan Demos.
This process is the most reliable one to reset the Shifter.
With this i am sure i proceed to the next screen (or to TOS) with the screen at the right place and not bitplanes data inside the Shifter buffer registers.
That is now also done before and after the code that will detect the wake up state to make sure that the detection occurs with the Shifter reset and that the detection mechanism will not affect the following code.


Now, regarding the unstabilizer (LO->MED->LO), it will work at any cycle spot during the screen display (MMU reading) as long as the values 1 and 0 are set in FFFF8260 while the MMU is reading data for the Shifter.
If when the line starts, the resolution was already 1, it will also work but in a slight different way that is not as stable and so i will not use it.
As you probably understood the obtained shift and number of words retained in the Shifter will only depend on the cycles between the two HW updates:
8 -> 2 words -> -8
12 -> 3 words -> -12
16 -> 4 words -> 0
20 -> 5 words -> -4
The value 4 is impossible to do via SW (i think): update the same memory place with 4 cycles between both updates.
If it would be possible you would get the -4 case.
The same effect can be achieved with LO -> HI -> LO but it is much more unstable and can lead with ease to the Shifter special states: bands, interleaved shifts ...
There also, there is a slight difference between the case where the HI was already set when the line starts or if it is set during the line display.
So i only plan to use the LO-> MED -> LO case with both changes during the line display (MMU reading) but i can not say for sure that will always use the same cycles for the HW updates.


Paulo.

[troed]

2- 14 (NEW);

I had my hopes up! :/ I'm guessing you're doing a long left border 71/50? (I've always thought what happens is it reaches the 0-byte line position and the line is then turned off completely [i.e, black]). That line causes discolorization on my setup, an STF connected via SCART to an LCD-TV. I assume it messes with the color pulse timing somehow. What's strange is that the effect is like turning off the blue channel and does so for the next 32 lines (!) - but that's likely due to the internal workings of the LCD.

Picture attached from your test program which displays the same issue. It looks the same in cold/warm wakeup (which according to your new detection program is wakeup3 and wakeup4 apparently - thanks for that! ).

DSC_0256.jpg

I tried briefly separating it into one left border and one 0-byte switch to avoid color modification but no luck.

What's interesting is if this only happens on my setup All other combinations work fine.

/Troed

[ljbk]

2- 14 (NEW);

I had my hopes up! :/ I'm guessing you're doing a long left border 71/50? (I've always thought what happens is it reaches the 0-byte line position and the line is then turned off completely [i.e, black]). That line causes discolorization on my setup, an STF connected via SCART to an LCD-TV. I assume it messes with the color pulse timing somehow. What's strange is that the effect is like turning off the blue channel and does so for the next 32 lines (!) - but that's likely due to the internal workings of the LCD.

Picture attached from your test program which displays the same issue. It looks the same in cold/warm wakeup (which according to your new detection program is wakeup3 and wakeup4 apparently - thanks for that! ).

DSC_0256.jpg

I tried briefly separating it into one left border and one 0-byte switch to avoid color modification but no luck.

What's interesting is if this only happens on my setup All other combinations work fine.

/Troed

Hi !

Yes, you get a blank line always but i do not get that color problem with my 1040STF and a Sony 40 inch LCD that is about 5 years old. I will try to check with another TV.
Regarding on how it is done, you can check the XLS file i posted above:
- FFFF8260 goes to 2 as with Left Border openning;
- FFFF8260 goes back to 0 much later around 48 cycles after but before the 0 byte spot (there are many possibilities: just check the XLS);
Just by curiosity, what do you get selecting a normal 160 bytes line and pressing HELP or UNDO to allow the blank or right blank ? Do you get the same color problems ?

Paulo.

PS:
Just checked the 14 bytes line among other things with another TV (20+ years small Sony CRT).
I get a different effect from yours: i get a small distortion to the right and then the screens goes left to the correct position after a few lines. This does not happen with the LCD.
I get the same effect for the "noline2" case and for the 0 bytes + blank case (again please check the XLS file).
All the rest seems to work.
Anyway, the 14 bytes line is not very important. It would only be needed to get the sync scrolling to work with 4 lines for all 128 cases and not only 127 as it is possible since 2006.

[troed]

Regarding on how it is done, you can check the XLS file i posted above:
- FFFF8260 goes to 2 as with Left Border openning;
- FFFF8260 goes back to 0 much later around 48 cycles after but before the 0 byte spot (there are many possibilities: just check the XLS);

Heh! I was so excited for a solution to the 14 byte line I didn't even see the excel sheet (and I will have to look in my code to see how "long" the long left border line I remember was, but I'm sure you're right. The discolorization looks exactly the same)

Just by curiosity, what do you get selecting a normal 160 bytes line and pressing HELP or UNDO to allow the blank or right blank ? Do you get the same color problems ?

No, both those work out just fine. I've never seen a color issue like this one except with the 14 byte line. It would be interesting to scope the position of the generated color pulse.

(I also got into wakeup state 2 just now - it's the same)

/Troed

edit: Come to think of it, I'm using RGB SCART so whatever happens that causes the blue channel to go missing isn't a color pulse. I think. Others understand that better than I do ...

[Steven Seagal]

Hello !

You can handle the WS you wish.
An emulator should behave like the machine itself: waking up in a WS without the user choice.
I have a few tricks to try to get the one i want but it does not always work.

This could be an advanced option ("random WU") but first we need to be able to really emulate them.

Now regarding your article there is one thing wrong.
Excepting the original 4bit.prg and its small variation in June 2013 where the return to TOS is intended to be WITH shifted screen and messed up bitplanes, this will not happen in any other case.

Too bad, it was the funniest aspect.

You might notice that in most programs, especially the ones handling special Shifter conditions like fullscreens i always set the rate to 60Hz during 1 VBL before setting it back to 50 Hz on the next VBL to exit to TOS or to go to the next screen.
I was already doing this in 1990 in the Overscan Demos.
This process is the most reliable one to reset the Shifter.
With this i am sure i proceed to the next screen (or to TOS) with the screen at the right place and not bitplanes data inside the Shifter buffer registers.
That is now also done before and after the code that will detect the wake up state to make sure that the detection occurs with the Shifter reset and that the detection mechanism will not affect the following code.

No, I hadn't noticed, so you say 1 full 60hz frame + 1full 50hz frame = shifter reset?
This isn't tracked in Steem for the moment but could (should) be done.

Now, regarding the unstabilizer (LO->MED->LO), it will work at any cycle spot during the screen display (MMU reading) as long as the values 1 and 0 are set in FFFF8260 while the MMU is reading data for the Shifter.
If when the line starts, the resolution was already 1, it will also work but in a slight different way that is not as stable and so i will not use it.

As you probably understood the obtained shift and number of words retained in the Shifter will only depend on the cycles between the two HW updates:
8 -> 2 words -> -8
12 -> 3 words -> -12
16 -> 4 words -> 0
20 -> 5 words -> -4

Something like that but some shifts were wrong.

The value 4 is impossible to do via SW (i think): update the same memory place with 4 cycles between both updates.
If it would be possible you would get the -4 case.
The same effect can be achieved with LO -> HI -> LO but it is much more unstable and can lead with ease to the Shifter special states: bands, interleaved shifts ...
There also, there is a slight difference between the case where the HI was already set when the line starts or if it is set during the line display.
So i only plan to use the LO-> MED -> LO case with both changes during the line display (MMU reading) but i can not say for sure that will always use the same cycles for the HW updates.


Paulo.

For LO/MED/LO it should be alright, because the test is relative, it doesn't depend on cycle at, eg 80.
It works with both v5 and v0, where the cycles are different.

[Dio]

Realistically, anything which interferes with either the colour burst or the sync timings is illegal always; if you do want to widen the window to allow that sort of thing, then the only thing you should be testing on is a CRT with good old fashioned analogue decoding. That any antique computer works on any LCD TV or monitor is a pretty big surprise given the liberties video system engineers took with TV standards.

I haven't had time to run the program on the logic analyser, but I did do a lot of pipe cleaning at 50Hz verifying various timings. A few things observed:
Vertical timing: 3 sync, 25 blank, 38 top border, 200 screen, 45 lower border, 2 blank
the latency from the last LOAD (of a group of 4 planes) to the pixel of the read data appearing on the RGB pins is 2 clocks when the DE to load latency is 6 clocks
Horizontal timing, starting from the start of HSYNC: 5us sync, 5us blank, DE activated after 3.5us, DE active for 40us, BLANK active after 9us, HSYNC after 1.5us; in clocks, that's 40 / 40 / 28 / 320 / 72 / 12.
VSYNC starts 104 cycles after the start of the previous line's HSYNC, so that's 4 cycles before DE would be activated. It is likely that this is the point at which the H counter is reset (and V incremented) so one would expect that the horizontal period would be determined at about this point.

[ljbk]

No, I hadn't noticed, so you say 1 full 60hz frame + 1full 50hz frame = shifter reset?
This isn't tracked in Steem for the moment but could (should) be done.

Spending a full frame at 60 Hz starting at VBL when you were at 50 Hz and returning to 50 Hz at the start of next VBL, resets the Shifter for sure with my machine.
My guess is that only 1 line, at least with the MMU reading, totally spent at 60 Hz (with the GLUE sending HSYNC signal for a NTSC line), will be enough to reset the Shifter but that is a guess and not something tested !

Paulo.

[ljbk]

@Troed

Hi !

I don't know if you noticed my edit above:


"
Just checked the 14 bytes line among other things with another TV (20+ years small Sony CRT).
I get a different effect from yours: i get a small distortion to the right and then the screens goes left to the correct position after a few lines. This does not happen with the LCD.
I get the same effect for the "noline2" case and for the 0 bytes + blank case (again please check the XLS file).
All the rest seems to work.
Anyway, the 14 bytes line is not very important. It would only be needed to get the sync scrolling to work with 4 lines for all 128 cases and not only 127 as it is possible since 2006.
"

Paulo.

[ljbk]

I haven't had time to run the program on the logic analyser, but I did do a lot of pipe cleaning at 50Hz verifying various timings. A few things observed:
Vertical timing: 3 sync, 25 blank, 38 top border, 200 screen, 45 lower border, 2 blank
the latency from the last LOAD (of a group of 4 planes) to the pixel of the read data appearing on the RGB pins is 2 clocks when the DE to load latency is 6 clocks
Horizontal timing, starting from the start of HSYNC: 5us sync, 5us blank, DE activated after 3.5us, DE active for 40us, BLANK active after 9us, HSYNC after 1.5us; in clocks, that's 40 / 40 / 28 / 320 / 72 / 12.
VSYNC starts 104 cycles after the start of the previous line's HSYNC, so that's 4 cycles before DE would be activated. It is likely that this is the point at which the H counter is reset (and V incremented) so one would expect that the horizontal period would be determined at about this point.

Hi !

My MMU reads 46 lines of data if i open the Lower Border.

The H period is determined at the red spot in the XLS file a few cycles before DE is normally activated.
That spot is also next to the place of the clean 0 bytes line.

Paulo.

[troed]

I don't know if you noticed my edit above:

"
Just checked the 14 bytes line among other things with another TV (20+ years small Sony CRT).
I get a different effect from yours: i get a small distortion to the right and then the screens goes left to the correct position after a few lines. This does not happen with the LCD.
I get the same effect for the "noline2" case and for the 0 bytes + blank case (again please check the XLS file).
All the rest seems to work.
Anyway, the 14 bytes line is not very important. It would only be needed to get the sync scrolling to work with 4 lines for all 128 cases and not only 127 as it is possible since 2006.
"

You're right - I missed it Actually going to 4 true lines would've been a nice accomplishment, sorry for spoiling the party It seems the sync is affected and while I never searched extensively for a possible split into two separate switches maybe you already have enough info in the table to know it can't be done. It seems my theory about it being left border + 0 was only half wrong, according to your table it's "left border + 0 & blank" instead of "left border + line 000" as I remembered.

/Troed

[ljbk]

You're right - I missed it Actually going to 4 true lines would've been a nice accomplishment, sorry for spoiling the party It seems the sync is affected and while I never searched extensively for a possible split into two separate switches maybe you already have enough info in the table to know it can't be done. It seems my theory about it being left border + 0 was only half wrong, according to your table it's "left border + 0 & blank" instead of "left border + line 000" as I remembered.

/Troed

Going to 4 lines(sync + 3) for all 128 cases is possible but i have to use the STOP pattern recognition to identify the "random" cycle after the STOP instructions before the TOP border openning.
Instead of syncing with the MMU, you get from a table you built during calibration, the "random" wait cycle the STOP will cause at that particular frame. This way you will be synched before the top border is openned thus allowing you to have all 12 valid line sizes for the first line that is normally the sync_with_MMU line.
This was discussed on this fórum in 2006 with ijor. It works on my STF but i never published the program as i do not think it is worth it because even for less than 200 fullscreen lines, you would need the STOPs that will cost you more than to use the 5th line for sync scroll.

In this 4 bit special case, as you have more shifter unstability entering at line 0, you just forget about the 4 lines and try to do the best you can with 5. Then the 6th line is the controlled unstabilizing one.

Paulo.