Going back to the sync switches business and the impact in horizontal scrolling, i have just found out that i can detect via SW not 2 but 4 different wake up states for my Atari 1040 STF Rev. C !!!
The first difference is detected like before via the effects in the updates of sync register at address $FFFF820A.
There are two sets of timings: the early one and the late one. Let's call them early_820A and late_820A.
The reason for this is that the FFFF820A register is located only in GLUE that works at 8 MHz directly with the CPU, so it can be updated at CPU cycles 0, 2, 4, 6, ... so the preceding multiple of 6 instruction as impact on the timing of the update inside GLUE afecting the generation of the Display Enable signal that will then trigger the Shifter and the MMU.
That is also confirmed by the fact that only data bits 0 and 1 enter the GLUE allowing the updates of significant bits in FFFF820A and FFFF8260: the registers that are needed to produce the VSYNc, HSYNc and DE signals.
The MMU on its own will only allow the CPU access to the main memory, Shifter registers and internal counters registers (including the video address registers $FFFF820x) on mutiple of 4 cycles. This can be on cycles 0, 4, 8, 12, ... or 2, 6, 10, 14, ...
On the other multiple of 2 cycles, the MMU is reading data for the Shifter if Display Enable is active: 2, 6, 10, 14, ... or 0, 4, 8, 12, ...
As to go synchro code we sync with the $FFFF8209 register, we in fact sync with the MMU.
In one of these two FFFF820A set of timings, we can see that the TOS screen appears 2 pixels shifted to the right from RESET. This means that the MMU is two CPU cycle late in providing the data to the Shifter compared to the other FFFF820A set of times. So if we sync with a delayed MMU, we have to do the FFFF820A changes 2 cycles ealier in GLUE for this set of timings. And that is exactly what happens, the same effects are available but we have to do everything 2 CPU cycles earlier.
So we have:
- early_820A that corresponds to the old wake up state 1 where the screen appears shifted 2 pixels to the right;
- late_820A that corresponds to the old wake up state 2 (the most frequent with my machine) where the Nostalgic Main Menu does not work correctly;
The second difference is detected via the effects in the updates of resolution register at address $FFFF8260.
There are three sets of timings: the early one, the middle one and the late one. Let's call them early_8260, middle_8260 and late_8260.
The reason for this is the fact that this register consists in fact of two registers: the GLUE_8260 and the Shifter_8260.
The GLUE_8260 can be updated every 2 cycles and is used to produce the VSYNC, HSYNC and DE signals.
The Shifter_8260 can only be updated every 4 cycles when the MMU allows it: on cycles 0, 4, 8, 12, ...
or cycles 2, 6, 10, 14, ...
So we can have at least for periods of 2 cycles:
Glue_8260 / Shifter_8260:
Low / Low
Low / Med
Low / High
Med / Low
Med / Med
Med / High
High / Low
High / Med
High / High
So depending if the updates to $FFFF8260 are done at the same time inside GLUE and the Shifter or are 2 cycles later in the Shifter, we have at least two different situation that combined with a possible delay between the MMU and GLUE (see above) lead to at least 3 different set of timings for effects with updates to $FFFF8260 register.
Early_8260, middle_8260 and late_8260 set of timings allow the same effects but with 2 clock cycles between them of difference.
So we have the following combinations:
early_820A / early_8260 that corresponds to wake_up state 1 (dificult to get with my machine)
early_820A / middle_8260 that corresponds to wake_up state 3 (less common form of wake_up state 1)
late_820A / middle_8260 that corresponds to wake_up state 4 (less common form of wake_up state 2)
late_820A / late_8260 that corresponds to wake_up state 2 (the most common with my machine)
I attach a program that can detect the current wake up state.
There are other wake up states but that can not be detected by SW because they correspond to discrepancies between the internal cycle of the Shifter that works at 32 MHz and the wake up status of GLUE and the MMU.
An example of this is the funny Spectrum 512 dots. It depends if the write of the color register (ordered to the Shifter by the MMU in the CPU R/W multiple of 4 CPU cycle) happens before the color register is read to produce the RGB signal. In most cases the video signal was already produced so the color only really changes at pixel + 1. But sometimes it already occured so you get the new color for pixel 0 (funny color) or as the GLUE HSYNC/DE signals are not as precise as the Shifter clock, you get something in the middle (sometimes correct color / sometimes not). These flashing pixels or 16 pixels vertical black bars (see below) due to diferente internal Shifter cycles and relative GLUE unprecision (compared to the Shifter) can also be triggered by the motor of the drive to be active or not.
Another example of internal Shifter cycle is the type response and the timing of it to resolution changes while Display Enable is active:
- what to do if N pixels of the 16 where outputed in Low resolution and now we get High ?
- what to do if N pixels of the 16 where outputed in Low resolution and now we get Med ?
- what to do if N pixels of the 16 where outputed in Med resolution and now we get High ?
- what to do if N pixels of the 16 where outputed in Med resolution and now we get Low ?
- what to do if N pixels of the 16 where outputed in High resolution and now we get Med ?
- what to do if N pixels of the 16 where outputed in High resolution and now we get Low ?
N can be 0, High resolution shifting and ouputing occurs at 32 MHz,Med resolution shifting and ouputing occurs at 16 MHz and Low resolution shifting and ouputing occurs at 8 MHz.
Experience shows that the data comming from the MMU goes to internal register(s) before it is loaded to the ouput register(s) where it is shifted every 1, 2 or 4 Shifter cycles.
Experience also shows that if less than 4 words are required to complete the 4 words needed to produce Low resolution bitmap, the screen will start earlier by 12, 8 or 4 cycles depending on the words needed from the MMU.
Experience also shows that it is possible to force that buffered data out at least with some wake up states by means of the stabilizer (wake up 2 at least), forcing the Shifter to wait for new fresh 4 words from the MMU before displaying the bitmap.
There are some other possible impacts of having these old words inside the Shifter like vertical black bars: 16 pixels or bitmap, 16 black pixels. Again, this depends on internal Shifter start/reset cycle and it can not be detected by the SW. It can happen that for the same wake up state (1, 2, 3 and 4) we can have situations where the extra words at start lead to screen shift, lead to vertical bars, screen shift for line N and a diferent shift for line N+1, vertical bar for line N and a 16 pixels shifted vertical bar for line N+1 ...
There are at least 16 sweet spot timings in a normal hozintal line (512 cycles) where you can do effects: 5 with FFFF820A and 11 with FFFF8260 like Left Border, Right Border, stabilizer, BLANK line, 0 bytes line, start like if 60 Hz, end like if 60 Hz ... and i am counting of 1 for the dozens of 71/50 or 60/50 switches for each case.
For the purpose of 4 bit sync scrolling for normal screen, i have seen it work with wake up state 2 (most of the times), wake up state 4 (always), wake up state 3 (only once).
I have never seen it work for wake up state 1 (at least -4 shift never worked).
Sorry if you found this uninteresting.
You do not have the required permissions to view the files attached to this post.